The interplay between technological innovation and organizational change can be both fascinating and multi-faceted. To understand how to get the most out of automated processes and make them highly efficient, Alexandre Nevski sits down with Filipe Lopes, Enterprise Architect Director at Capgemini. He explains the importance of test automation in the short segment dedicated to tools, the benefits of taking smaller steps, and why proactive communication must never be set aside. Filipe also discusses why businesses should always allot resources to invest in skilled and talented people, who will be the ones to maximize the impact of digital innovations.
—
Welcome to a new episode of the show. The interplay between digital transformation and organizational change can be both fascinating and multifaceted. When your people seek efficiency gains, do they automate the as-is? Do they have enough time to reconsider your processes for the digital era?
We’ll be exploring these questions with our guest, Filipe Lopes. He shares a real-life story where key aspects combine in ways that many of you will recognize, tight budgets, numerous stakeholders, ambitious schedules, and only one team to deal with these competing priorities. As always, we follow up the intrigue with a practical discussion. My guest recommends taking smaller steps, communicating proactively, and investing in people. You won’t want to miss his passionate advocacy for test automation in the short segment dedicated to tools.
An Enterprise Architect Director at Capgemini, Filipe has over twenty years of IT and consulting experience. He specializes in aligning business strategies with agile methodologies to achieve swift returns on investment. His expertise is not just technical. He actively coaches his clients to implement business change effectively and navigate the transformation with confidence. Without further ado, here’s my conversation with Filipe Lopes.
Filipe, welcome.
Thank you.
Thank you for coming onto the show. I was looking forward to this conversation because you’re one of the most experienced architects out there. You’ve held positions with global consultancies, systems integrators, and software vendors and clients. Can you start by giving the audience an idea of what type of systems you are specializing in?
I’ve been, over the years, working on a specific type of software that enables us together with the team, the business, and the customer to automate some kind of process of processes, like opening a bank account or someone onboarding. In the old times, it would be emails, conversations, text messages, and documents sent through. At some point, system A gets into action, but system A is not connected to system B and system C. We don’t have a process orchestration system to guide all these steps across multiple systems, multiple teams, and multiple people.
What about your role? For instance, in 2023, you took up a position as an enterprise architect. How has your role evolved over the years?
When I started to work on this technology, I was not a junior anymore already. I have worked on development and mostly web. I’ve gathered some experiences on websites or web applications. I use a bit of my seniority of working with customers on the front end to be in a comfortable position with this technology to guide them through this process.
I started as already a senior, but starting in this new technology. After multiple projects, certifications, or exposure in life, working with people, then my role was evolving a bit. I have different roles that’s completely different from technical. I was trying to set up a center of excellence in a certain company. I also worked on the business side of things as well sometimes, but I always came back to what I liked best on the technical architecture side.
I also had the pleasure to work with you. I am slowly trying to guide my way through how to make high-level decisions for customers, going through the decision process in terms of we stick to a way and stick to a direction and try to be as flexible as possible, and trying to accommodate the changes that are coming through.
With that, we wanted to talk about the interplay between technological innovation and organizational change. Let’s start with covering the basics. How do you define those two terms in the digital transformation context?
Many times, the biggest challenge is that we get into a customer at a certain point, not in the beginning of the conversation, but a bit after the beginning of the conversation when they already need some technology insights or some help regarding technology. The most important thing is not the technology per se. Digital transformation moving towards a more digital organization or to be more digital is to be more efficient as to have people working on the right things, not doing, for example, repetitive tasks or to have a lot of screens with a lot of data.
It’s a little bit like how we automate and apply technology versus what we can do with a technology that changes people’s work, descriptions, and activities.
Exactly, in life at work in general. Someone who spends their time doing repetitive tasks before we had automation in different aspects of technology are going to system A, entering some records and some data, going to system B, entering some data, copy paste into some clipboard or whatever some notes, and then putting it into application C and so on.
—
In this segment as we navigate the stories, I advise to use discretion with names and specifics. That way, we can bring our audience authentic insights while upholding the highest standards of privacy and respect for all individuals involved. With that in mind, can you think of an example of a past project where the organizational change was not considered enough at the beginning?
Yes. On the previous project, we were receiving some documents that we were validating. Once they’re validated and/or approved, depending on the document, the division, or the business rules, we would send to the system of records saying, “This is approved from our side. It’s done. You need to process on your side now.”
The purpose of that solution, application, or project was to improve the automation to have one central system that people would access from all over the world. Any division can access one application instead of having 10 or 20 different systems that people would work on and integrate this however it would need to be integrated.
Was that a project that went very smoothly?
There are always challenges and things we can improve. Namely about automation, an application starts to get complicated or get quite big. One of the biggest challenges for me was to successfully test it and be better at it and be more efficient. Automation is one of the things that I have close to my heart. That was one of the challenges.
At the beginning, we had a lot of senior people. It’s very hard to maintain that because there’s always, at some point, some budget considerations. As normal in all projects, the beginning starts very well, and then it starts to get real life. Namely, at some point, when we were trying to really focus on commissioning the legacy system, we weren’t that strict anymore with automating or making things better. The focus was more, “We need to decommission the system. We need to roll this out to as many divisions as possible, as fast as possible, the ones which were being supported by the old system.”
All projects start very well, then it starts to get like real life.
Particularly in one of the divisions, we didn’t have so much support and many aspects to provide a better solution for them. We recorded the fact that they processed documents through our system, but we did not make their lives better. They were still doing a lot of manual work. That’s life. It happens sometimes. We can work, support, and improve their life after, but at the time, we were not able to because we work on many different fronts. It becomes a complex application. We need to deliver certain features and new features to other divisions. We worked on a lot of good features. We could not focus on everything.
Can you elaborate on the interplay between the tech innovation and the organizational change at that point?
That part of the organization already, they were not that focused on real digitalization. They were not ready yet, and that’s the challenge. Normally, parts of the organization are not at that moment ready to get digital. It was important to get these documents processed. That’s their focus. No matter how they were processed, they needed to be processed. That was critical for the organization. They were not secondary parts.
The fact is that they were not ready, and we needed to get them on a new solution, however it was, to be a step closer to decommissioning the old solution. They had a plan, even with these different types of formats of documents that they sent to us to help them at some point. We wanted to have that part of this general solution because it was a valid requirement. It was not something completely different that we would never use. It was a value requirement that we could use for other divisions, but at that moment, it was not the primary focus for other divisions.
How do you define that? Is that related to working with documents versus working with structured data? How do you see it?
If they were ready for digital innovation, they would provide time, capacity, and budgets. It’s not the people that were not ready. It’s the organization. That part of the organization was not ready.
Hypothetically, had there not been these budgetary constraints, what kind of improvements could there have been? Let’s try and look at them from a business perspective. Not features, but what kind of capabilities would have been unlocked for that organization had there been time and resources for that part?
They would have to do much less manual work, for sure. It’s still data that we’re receiving. It’s still the same type of data that we’re receiving in a slightly different format. Given time and budget, it would also have been a very cool thing to adjust to something different because that would come to us more in the group of data. Imagine. You have this insurance for one person or insurance for a group of people. Instead for one person, you get group insurance. It’s still the same data model inside, but you get bulk information instead of one single record. That’s cool to have done it.
Generalizing to more of your experience, is that something that happens often?
Yes. Sometimes, we always have to sacrifice a bit at first and see the big picture, like, “What is really important here?” Sometimes, a small detail or a small part, or smaller parts of the application or the solution, we need to have a more tactical approach to make it work because we can’t address it all. It’s true that tactical solutions sometimes tend to stay on, unfortunately. They’re like, “It’s working. Don’t touch it.”
Sometimes, we have to sacrifice a bit to see the big picture.
Tactical solution can be a euphemism.
You cannot make it all sometimes because usually, you always have some kind of limit from the budget perspective. It’s very rare that we can make a solution that addresses all sorts of business problems.
What’s the conclusion to draw from the story?
We need to try to help the team, the customer, and the organization as best as we can. Are we addressing the main topics that they asked us for help for? We want to improve automation. We want to have some kind of solution that is better than they had. There is a difference between the as-is process and the to-be process. We made an improvement. We need to focus on the big picture. How can we first keep improving? Are there things that they’re still lacking or things that we can improve on how to work together? We need to focus on that. We need to focus on what we can control.
One thing we cannot control is budget or capacity. We focus on what we can control and help them on that. If there are still, at that moment, so many defects because of quantity versus quality, we focus on that. We focus on improving as much as we can the application tool to be more stable, technical depth, or whatever it is. The part we can control, we address that. It’s important for us to feel realized as the team in general or the customer to feel that they have achieved something so the users have less complaints or whatever. Let’s focus on what we can deliver.
If you found the story valuable to you so far, please like and subscribe to help us reach a wider audience.
—
In this segment, we like to unpack the tools or technologies that we have mentioned in the previous segment. You’ve mentioned test automation. I’m really curious to explore that subject together. Why should an organization care about test automation? Is it the technical people that benefit from it because they get productivity increases, etc. or are there benefits for other parts of the organization as well in your opinion?
In my opinion, that saves money. For example, you start building bits of components of the solution bit by bit. You start to split things apart. You’re like, “This is a part that works on this process or this data entity, or this type of business process,” and so on. If you have an API path of that process, you want to have it tested properly end-to-end or component-by-component.
When you have a component which is stable, even if it’s stable, let’s say you don’t apply test automation and you have a team of ten testers. Even if a component is stable, they still have to test it in every release. If the component is stable and you build a set of automated tests, and nothing changes on that component or nothing big so you don’t have to update the automated test as well, that part you don’t touch anymore. You don’t need a couple of testers to address that component anymore. That runs automatically. It mandates that you don’t spend anymore.
It also saves time.
For the testers, it’s really hard to obtain and achieve 100% coverage in test automation. If you achieve 50%, I don’t think that’s an outrageous number to achieve. It’ll save you 50% of the time and 50% of the manpower. The people who are testing are doing end-to-end testing more safely, so in their life, it’s better. There’s not so much one test manager who signs a lot of tests like, “You do this 50 tests.” It’s like, “Let’s, in the test automation tool, do the things that we don’t need to touch now. Let’s work on the new tests and the new features and then slowly also to the test automation tool. Instead of doing the test manually one time, let’s go through the tool.”
It is hard to achieve 100% coverage in test automation. However, achieving 50% is not that outrageous and will save you a lot in terms of time and manpower.
If you have the right tool, you can also build it in components and also reuse them. You don’t need to do so much so new. You still use, for example, the component for the testing. The logging, you don’t need to do that again every single test and so on. Instead of going to manual testing, you add a few more to test automation and do the more interesting tests that you want to do. In repetitive tests like testing, if the date needs to be in the past and nothing in the future, the form is validated, or it has a proper set of addresses, it is not worth spending people’s time doing these repetitive tests every single release.
Thanks for clarifying what test automation is, what the benefits are, and how to approach it. I usually keep this segment short. However, if you want to know more about test automation, feel free to leave us a comment. Maybe we’ll post some additional material about it for that.
—
In the third and final segment, we aim to provide practical advice to our audience. Let’s go back to that interplay between technological innovation and organizational change. What are the key messages you would want to leave our audience with?
The main challenges are the people in higher management, etc., need to address some business objectives. They want to improve customer retention or less costs or automation so that their people work better and more efficiently, improving that in multiple steps. Organizations get more mature, so their steps further.
The biggest problem is, at the beginning, you have an empty paper. How do you do that? First, you don’t need to know everything. You need to try to find people who know a bit more about that inside the organization or outside the organization. This is our purpose. This is our objective. How do we reach that? It’s not only about technology. It’s also about making the organization more efficient.
Digital innovation is not only about technology. It is also about making an organization more efficient.
It’s not easy to transform an organization with 100,000 people or 200,000 people from day to night in six months or one year. Let’s do baby steps. When the customer has an application for you or a purpose but they’re not sure, they ask you, “Can you do a proof of concept?” You’re like, “Let’s do a proof of concept. In one month, let’s focus on these three key things and let’s try to put them together. We’ve done it. We were successful. We proved to you it works. Now, let’s make a real project.”
It’s the same thing for an organization for a digital transformation. We’re like, “Pick a hotspot or something that we can make a quick win out of, something not too expensive, and prove it works. Let’s pick up a team and change the way they work. How can we make their life better and more efficient? We change the way they work together and collaborate. It could be tools or training. However it is, let’s make that team better.”
From that team, it’s like, “We proved this works. How can we make that for the rest of the organization? Let’s make a target. In five years, we will try to get here or in one year, let’s try to get here. In the target of five years, let’s see how we get and slowly try to get to where we want to get to in 10 or 15 years. It doesn’t matter the time.” It matters that we slowly make people better in an organization as well as happier and more efficient.
Sometimes, I see that business leaders struggle with the concept of baby steps. In principle, they agree, but when you’re saying, “Improve the life of this team and not yet the others,” they’re struggling to imagine how that’s possible because they’re using the same tool. They see issues with one team using one tool and other teams using something else because maybe the data is not shared or something like that. Why do you think this is a difficult concept to grasp more for business leaders than for digital transformation leaders, or maybe you don’t think so or your experience is different?
You’re right. In other parts of organizations, it’s like, “They are getting some cool stuff. What about us? Are we getting left out or what?” Sometimes, when someone needs to communicate something that is not comfortable, it really matters to me when I’m the receiver of that communication how things are communicated. It’s not only about what is communicated. I give a lot of attention to how it’s communicated.
If the organization, the leaders, or the high management communicates things well from the start, they say, “We are going to do this because we cannot address the whole organization right now. We are a large organization. We cannot change the lives of everyone in a day. In order for us to prove ourselves that we can do this, we need to get a quick win.” It is something like, “Let’s prove to ourselves that we can do this with a team or a division.”
It’s something relatively achievable in a relatively small timeline. It’s something that will help us to address the rest of the organization. Don’t worry. We are trying to make your life better, but it takes time in order to convince stakeholders, board members, or so on. You need to have a successful storm, no matter what it is. Digital transformation, a program, or a transformation of any kind is built on successful stories.
Do you have any other advice we would want to leave our audience with?
Many times, the challenge is about, “Are people not ready yet?” You should always get your people trained not only in technology but in different types of methodology and work and on how to work together differently, how to work remotely together, how to collaborate, and how to make work more efficient. Your organization is built on people. If your people are better, your organization automatically becomes better. You need to sometimes get help from outside, but always keep in mind that you also need to improve your people with the process. The more included and more collaborative they are, the better they feel in general if they are part of the solution.
This is the most fundamental advice we can give. This is the end of the interview. It’s been an absolute pleasure. Thank you very much for coming to the show.
Thank you for having me.
—
That’s it for this episode. I hope my conversation with Filipe inspired you to treat organizational change as an integral part of digital transformation. To make it easier, he recommends communicating proactively and investing in people as you take one small step after another on your transformation journey. We have more exciting topics and guests lined up, so stay tuned for more tales of innovation that inspire, challenge, and transform. Until next time, peace.
Filipe Lopes stands at the forefront of Enterprise Architecture, leveraging over 20 years of IT and consulting experience to steer companies through digital transformation. As the Enterprise Architect Director at CapGemini, he specialises in aligning business strategies with agile methodologies to achieve swift returns on investment and adapt seamlessly to market changes. His expertise is not just technical; it’s about enabling businesses to navigate through transformation with confidence. Filipe’s role extends beyond consulting, as he actively coaches clients, helping them to grasp and implement business changes effectively, thereby ensuring lasting success in the digital age.