{"id":1560,"date":"2022-10-24T17:27:02","date_gmt":"2022-10-24T17:27:02","guid":{"rendered":"https:\/\/janbosch.com\/blog\/?p=1560"},"modified":"2022-10-29T19:03:34","modified_gmt":"2022-10-29T19:03:34","slug":"boost-your-digitalization-modularize-processes","status":"publish","type":"post","link":"https:\/\/janbosch.com\/blog\/index.php\/2022\/10\/24\/boost-your-digitalization-modularize-processes\/","title":{"rendered":"Boost your digitalization: modularize processes"},"content":{"rendered":"\n
\"Photo
Photo by Raphael Koh on Unsplash<\/figcaption><\/figure>\n\n\n\n

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\u2019m a strong proponent of automating everything repetitive, there\u2019s a \u201cdirty little secret\u201d 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.<\/p>\n\n\n\n

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.<\/p>\n\n\n\n

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 \u201cstinkers.\u201d Implementations of automated processes can easily end up in the same situation.<\/p>\n\n\n\n

Third, in the implementation of data pipelines, we\u2019ve 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\u2019s 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.<\/p>\n\n\n\n

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\u2019t 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\u2019t 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.<\/p>\n\n\n\n

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.<\/p>\n\n\n\n

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\u2019t need continuous change is software that nobody uses. Any piece of software that\u2019s 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\u2019s 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.<\/p>\n\n\n\n

Although the automation of repetitive activities is critical for virtually all companies, there\u2019s 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\u2019s 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\u2019t grow stale!<\/p>\n\n\n\n

Like what you read? Sign up for my newsletter at jan@janbosch.com<\/a> or follow me on janbosch.com\/blog<\/a>, LinkedIn (linkedin.com\/in\/janbosch<\/a>), Medium<\/a> or Twitter (@JanBosch<\/a>).<\/em><\/p>\n","protected":false},"excerpt":{"rendered":"

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\u2019m a strong proponent of automating everything repetitive, there\u2019s a \u201cdirty little secret\u201d around automation that … Read more<\/a><\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"generate_page_header":"","footnotes":""},"categories":[8,10],"tags":[],"_links":{"self":[{"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/posts\/1560"}],"collection":[{"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/comments?post=1560"}],"version-history":[{"count":2,"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/posts\/1560\/revisions"}],"predecessor-version":[{"id":1565,"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/posts\/1560\/revisions\/1565"}],"wp:attachment":[{"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/media?parent=1560"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/categories?post=1560"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/tags?post=1560"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}