End-to-End Thinking or: “Developing Solutions the right way”

Written by Carl Stolze and Alexander Gehret — also available on LinkedIn

When you are reading this, there is a high likelihood you are working for a larger corporate (or one of its suppliers). Whether you are just starting or up in the higher ranks, you most likely want to deliver great service to your customers. At least, you had that desire once. But then, processes got in the way. Be it complex to navigate IT systems or you have to adhere to so many checks and balances, that you cannot serve your customers at all. Or, there are so many options to choose from when serving your customers, that you do not even know which one to pick.

Considering the underlying processes, there is a lot of talk about them, but they are seldom truly understood. The infamous, satirical picture on process modelling shows a highly sophisticated process model that at the end, points to a box “and then a miracle occurs” to get the result.

Does that sound familiar to you?

You got endless definitions of how to do things, but to get stuff done, it is always better to know someone?

Or there are well defined and implemented systems in place, but the real calculus is done in Excel (maybe even full of macros and obscure functions)?

You might feel overwhelmed, frustrated and you are tempted to just accept, that these challenges will never get addressed and that the situation will just stay how it is right now.

Well, the truth is, you are not alone.

Navigating today’s IT world, we (Carl Stolze and Alexander Gehret), can understand that frustration. We have felt that way too. Processes are getting increasingly complex. And at some point, it felt like our work would not add any value to customers at all.

However, we teamed up to provide a way out of this anxiety. Pooling our combined experience of more than 20 years, we both have been with companies striving, but also struggling. We worked directly at the interface between business and IT so often, that we believe we now know what creates these challenges and that we might have found a way out.

In this article, we want to outline the three key challenges you will need to address to get back to creating value, instead of struggling over complex processes.

We promise, reading the below won’t hurt and we do not try to sell you anything. Just read through it and find out, if that makes sense to you. If it does, let us know and if you want to have a chat about it, reach out to us.

If it does not make sense, all you did was wasting 10 minutes max on reading through it. In that case, you might want to let us know, too.

Problem 1: Missing user perspective

Reading through the news on the internet, you might ask yourself: how can this be a problem? These days, every larger enterprise seems to be focussing on putting “the customer first”. Buzzwords like “User-Centric Design” or job offers such as “Product Owners” who should represent the customer are everywhere.

The challenge: while they should represent the customer, in the end, Product Owners (or similar roles) can only represent themselves and what they think the customer might desire. Of course, there are companies such as Apple, who are good at creating markets for desires nobody knew that they existed, but more often than not, we fail to understand the customer.

Take a banking app for example that offers you the option to trade securities. In the classic and still dominating approach, you will be asked to specify the market for executing your order before placing it. That is great if you are a trained trader and know what exactly this is about. If you are an average (retail) investor, however, you just wanna buy some shares and most likely you are not so much interested in whether you pay 1 or 2 cents more (or even higher commissions and fees whatsoever). That is a complication, which would be well better suited for a dedicated expert mode. FinTechs like Robinhood, TradeRepublic or Scalable Capital now take the market by storm by reducing exactly that complexity.

The lesson learned from that? Talk to your customers! Invite them for demo sessions of your products. Don’t tell us you can’t. We heard most of the excuses. My favourite: “We serve the ultra-wealthy, we cannot just ask them for their input”. You can! Especially these people will be more than happy to help build a product, which is exactly tailored to their needs! (Sometimes your customers could also be the internal business department, but also they are worth talking to, before developing the next feature for the reporting dashboard nobody has ever asked for.)

Problem 2: Missing End-to-End Perspective

Why do companies such as Apple or Tesla adopt the “No-Silo”-Rule? Because silos limit your perspective on the whole process. Everyone only looks at their departments, but never at the whole picture. When the headlights engineer as an example is not responsible for repairing the car, you will potentially arrive at a design, where repairing the headlights is not feasible anymore. (Sounds familiar to someone out there?)

You will have to focus on the full end-to-end process from building to operating and repairing the car, to arrive at a truly great product. However, that clarity is missing more often than not. If in doubt, pick any process you like and ask for a full end-to-end description of it. And don’t be fooled. Just because some process documentation ends at one point, the process does not necessarily end there too.

Let’s take customer onboarding for example: Does that process stop, once the customer is a client with the company? Of course not. The data entered during that process is the foundation for everything else coming afterwards. Hence, every data point missing must be collected manually afterwards.

But how do we bridge that gap? Certainly not by introducing a (or yet another) middle office. Instead of two parties not talking to each other, you will have three afterwards. We would suggest, to start by documenting really everything on a high enough level in a simple way. Post-its on the wall might be enough. Event storming might be a great technique to start with. Do that, but make sure to involve the people who are involved in the process (yes, really involved operational persons, not their superiors steering operations on some abstract level). Those, who live that process day-in and day-out to make sure you capture everything that matters.

Afterwards, at least everyone has a clear end-to-end view. However, you need to make sure, that end-to-end view gets optimised continuously and that people start talking across borders. Having said that: look at reducing borders by restructuring departments, involving incentives which foster teamwork and change the office layout to allow spontaneous communications. Work with networking coaches to create a culture of sharing and continuous improvement from the sales funnel, to the very end of your engagement with the customer.

Problem 3: Missing Link & Bad processes

Having thought about the customer and after breaking up silos, we need to bring all together and bring the better version to life. But there is a danger in this step: It is very appealing for the bureaucrats to take over on require some super complex, highly formalized process modelling. Or some software vendor talked some people into believing that if you just model everything right, everything can be automated. So let’s take these two major pitfalls apart.

First, when you want to bridge the gaps, it’s not about choosing the right modelling language for processes. It about breaking the silos (as mentioned before) and agree on what has to be done. Agree on it and write it down. A simple PowerPoint with a few boxes and arrows can be sufficient. And sometimes even bullet points in an email. You just have to agree. Of course, there are benefits from using a truly standardized modelling language like BPMN. It can be used in a simple form that is as easy to understand as a freestyle slide. Yet it can be enhanced and detailed into the most complex form. But remember start simple. Do not get lost in the rabbit hole of formal process modelling.

Second, there is something you have to get a clear picture of the data involved in the process(es). If the underlying data is not agreed on, all the beautifully discussed process steps and forks are meaningless if the semantics of the data involved is not cleared up before. Take as an example what is a name? Is it the combination of a given name, middle name(s) and surname? Or just the surname? And all separated? Or put together as one long string? Even this classic example is up to today an often under-defined data point leading to endless discussions.

So what to do? Building up formalized (and maybe even normalised for those geeks) data models from scratch? Usually, it is sufficient to start with a simple list of data points (or fields) used throughout the process. Then you can derive a data structure and that often leads to a better understanding of the relations. To be blunt here: the understanding of entities (like customers, items, etc.) and relations between them (for example orders) is one of the most underrated (and often misunderstood) techniques when bringing end-to-end processes to live. Yes, it’s less sexy to discuss data types and definitions of fields first than to discuss about how important one’s process step is, but is tremendously more valuable.

Third, with a grossly defined process and a good understanding of the underlying data, the next step is to bring the process to live. Be it as a prototype within your favourite UX discussion tool (e.g., Figma) or implemented already with some basic functionality as a proof-of-concept or MVP. Having confirmed it’s feasible and workable, you are ready to go. And if you want to automate, yes things get more formal, but first, confirm the process is working rather than doing the 120% solution from the beginning.

To conclude our ride her: It’s a way of thinking, getting down to what is important and has to be done. Write down the important steps. Talk to each other, break the silo. Write it down. Get the underlying data right. Go to work.

About the authors

Dr Carl Stolze works on his mission to make IT work and let digitalisation become a reality. Currently, he works as IT project manager at pbb Deutsche Pfandbriefbank (a leader in Commercial Real Estate Financing) and member of its digitalisation network. Carl has extensive experience in IT project management, the design of complex IT landscapes as well as consulting at the intersection of business and IT. Carl was part of the core team of BCG Platinion’s banking practice, managed a university spin-off consultancy and developed web-based applications himself. To disseminate some knowledge on how to work with data, Carl started the website tabellendoktor.de to provide hands-on help for those working with Excel, databases and data in general. Carl graduated and holds a PhD in Information Systems (Wirtschaftsinformatik).

Alexander Gehret is a Manager of BCG Platinion’s banking practice. He has a proven track record of managing complex, large-scale IT programs in Europe and the Middle East. Before BCG he worked for the Swedish IT-Consultancy Acando (now part of CGI) and Hewlett Packard. Alexander holds an MBA in General Management and a Bachelor’s degree in Applied Computer Science.