Automation is central for companies that are digitalizing, and new technologies, including natural language processing and image recognition as well as robotic process automation, allow us to automate processes that were impossible or prohibitively expensive to automate earlier. Although I’m a strong proponent of automating everything repetitive, there’s a “dirty little secret” around automation that few talk about: once automated, companies often seek to avoid changing and evolving these processes as it involves potentially significant costs and risks. I see at least three key causes: deeply integrated implementations, lack of competence and interdependencies.
Especially consultants, but also IT staff employed at your company, often are extremely focused on the task at hand and finishing it. They largely or completely ignore the long-term consequences and implications. Project management tends to have the same priorities as any future changes to the resultant work product will be part of a new project and thus the problem of another project manager. Consequently, the implementation of processes that are automated tends to have a very short-term focus, resulting in implementations that do the job but are highly integrated and interconnected. This lack of modularization causes any changes to require significant effort.
A second challenge is that the people who did the original implementation often move on, either internally or externally, and consequently are no longer available when changes are required. As nobody really knows how the automated process works in practice, no one dares to touch the implementation as it may lead to unintended negative consequences. In software engineering, components that nobody dares to touch out of fear of breaking their functionality are referred to as “stinkers.” Implementations of automated processes can easily end up in the same situation.
Third, in the implementation of data pipelines, we’ve seen several cases where people build undocumented dependencies on existing pipelines as they need some of the data flowing through them for their own purposes. In process automation, it’s often quite easy to insert triggers for other automated processes. If this is done in an implicit and undocumented fashion, it creates a spaghetti network of dependencies between different processes that complicates changing these processes as any change will most likely break something.
The reason companies should worry about hard-to-change processes is that these easily evolve into a competitive disadvantage. As the world moves on, better ways of doing things are developed that can’t be capitalized on. Also, it becomes difficult to be innovative as many innovations require changes to at least some processes in the organization and these can’t be evaluated as the associated cost is simply too high. So, the very thing that initially brought efficiencies and speed easily evolves into an anchor that slows everything down.
To address this, there are at least two main principles to observe: modularization and continuous investment. First, any design problem needs an architectural approach that defines the key principles. For anything in software, modularization is key. The notion of modularization is often poorly understood, but at its core, it comes down to decoupling units of functionality that are likely to change independently of each other and defining interfaces that allow one side to change without affecting the other side of the interface. Once automated, processes become software too and need to follow the same modularization principle.
Second, many IT-heavy companies tend to operate in a project-centric way. The products coming out of these projects are considered to be static and not requiring change. More than 50 years of software engineering research have clearly shown that the only software that doesn’t need continuous change is software that nobody uses. Any piece of software that’s in use needs a constant flow of investment to keep it up to date. This collides with the project-centric way of working and it’s generally much better to take a product-centric approach where there are teams associated with each product. This maintains competence and ensures that the automated process is constantly updated to meet the current needs.
Although the automation of repetitive activities is critical for virtually all companies, there’s a risk that years of investment in process automation result in an unwieldy, impossible-to-change IT landscape. This is a major competitive risk as it causes companies to resist changes due to the associated costs and risks and unduly drives up the cost of innovation efforts. To address this, companies need to embrace at least two principles: modularization and continuous investment. It’s not, as Charles Darwin wrote, survival of the fittest, but rather survival of the fitting. Species that are unable to adapt fast enough to changing circumstances go extinct and the same is true for companies. Don’t grow stale!
Like what you read? Sign up for my newsletter at jan@janbosch.com or follow me on janbosch.com/blog, LinkedIn (linkedin.com/in/janbosch), Medium or Twitter (@JanBosch).
