Investments in technology are major business decisions that should not be taken in a vacuum.
Although this sounds obvious, examples of digital transformation projects that achieve their objectives are sparse. Despite the ample warning signals, why are organizations still unable to achieve technical transformations to their full potential?
The truth is that when the scapegoating begins, the train has already left the station. Dig a little deeper, beyond the “tech didn’t understand the business requirements” and the “the business didn’t define their requirements well”, and there we find a more comprehensible truth. The organization has tried to lift-and-shift legacy process and organization into a new business system. They forgot to consider how work should be simpler and organizational structures more aligned to the actual customer journey. It’s not just about tech.
Take a step back
To understand what that means, we need to take a step back and consider the interconnectedness of these three dimensions: people, process and technology.
Your existing ERP, CRM or customer facing-product has evolved over time, constantly iterated to shift organizational and customer demands. But as in physics, entropy is inherent in every system over time.
Entropy is a fancy word for chaos. So in our very nature, chaos is inevitable! Now apply this same thinking to an already complex organization. Suddenly the political agendas, personal ambitions and the loudest voice in the room dictate how teams, systems and processes look.
As the key players responsible for the current state come and go, processes become more and more complicated. For example, think of a customer service team that does not feel supported by the current IT team, they will come up with their own solutions. An Excel spreadsheet here, a sub-process there and than another SaaS tool to connect them. Technology decisions made in a vacuum happen outside the holistic IT strategy your CIO is trying to pursue.
When lifting-and-shifting to a new system, it is exactly these bad practices that will be carried over into the new solution. Simply because ‘that’s how it works’ or ‘that’s how it’s always been’.
A way forward
It is important to acknowledge that there is no blame here. We do what we have to do to move things forward. We do what we must do to achieve the incentives we were given.
Ultimately, it is the customer who suffers from this. They stumble through their customer journey not knowing who to speak with, repeating themselves and feeling like you don’t really know who they are.
It is therefore that we should not just speak of legacy technology, but also legacy process, and legacy organization. What is the solution? How do we avoid building new spaghetti?
Avoiding organizational debt
Often overlooked is the organizational debt organizations accumulate over time. Why are teams structured in a certain way around the customer journey? Why are OKRs, KPIs and incentive structures the way they are? What profile and skillsets have been hired for in the past that dictate the way people think today? Or even: which business leaders did not get along well and avoided each other to further silo the organization?
The starting point should be a blank slate. What are we really trying to do, what does the customer really want and what would be the best way to structure the organization around this?
With a 50 million dollars in your pocket, how would you design an organization that disrupts your current business? You probably know the answer, so start there. What you’ll be left with is a more lean organization and a happier customer. From there, it’s much simpler to design end-to-end KPIs, processes and systems.
Avoiding process debt
Business process re-engineering is a well-established discipline in academic literature. However, it is strikingly difficult for organizations to re-engineer the way they work. The reason for this is that processes cut across all functions of an organization. Process is either in service of the customer or in service of operating the company. The high-level of interdependencies of processes across functions requires a cross-functional initiative.
But more than cross-functional, process re-engineering is the work of a Monk, a Preacher and a Leg breaker.
There is a level of detail and complexity only a Monk has the attention span for. The road is long and dark, and only a preacher can bring a beacon of light to see the end of the tunnel. Finally, there are a number of difficult questions that only a Leg breaker is not afraid to ask. With all these skills coming together in a cross-functional team, work can begin to eliminate, simplify, standardize, consolidate and automate processes, prior to implementing a new system.
Avoiding technical debt
Finally, after averting process and organizational debt, the next step is to avoid technical debt. This is a massive hurdle to pass in its own right, but with a clear vision for organization and process, it comes down to drawing up a holistic architecture and a series of build vs. buy decisions. There are many nuances and “it depends” here, but a few rules of thumb apply:
- Have a business plan and a technical architecture to avoid fragmentation of your application landscape and
- Choose a technology stack (Salesforce, Oracle, SAP) and stick to it. The more system integrations you build, the more overhead and inertia you create.
- When considering buying or building a solution, keep in mind the nature and complexity of the core activity of your business. A rule of thumb: if you’re not a technology company, avoid building your own technology.
- When buying a solution, seek to use as much out-of-the-box process as possible, and when customizing try to do this through configurations and not custom coding.
If at the end of these three exercises you have identified that, all along, your business is right where it needs to be: congratulations! If it is not: congratulations!
In both cases you have gained a deeper understanding of what makes your organization tick, you’ve have laid the ground work for a successful transformation and have aligned the organization to a shared objective. You are not taking technology decisions in a vacuum.
You have avoided replacing old spaghetti with new spaghetti!
