Don’t Automate a Broken Process

“Don’t automate a broken process” seems like a pretty sensible bit of advice, and yet spending large sums of money on technology to automate broken processes is exactly what many organizations keep doing.

The “transformation” of business processes is something almost every executive and organization seems to want. There are also plenty of ideas or mindsets about how to go about accomplishing this major change in performance. Needless to say context is important: the nature of the sector, the state of finances of the organization, the history of the organization (things like whether there have been acquisitions, labor disputes etc.), the personalities, backgrounds and biases of leadership, how middle managers actually behave and work day-to-day etc.

In reflecting on what has worked and what has not worked over the past 25 years I have found a number of ideas insightful and helpful in understanding the reasons why some efforts worked out better than others. In their book This is Lean Niklas Modig and Par Ahlstrom discuss an idea, a framework, that does, in my opinion, provide a very powerful way of both defining how an organization ought to approach the transformation of business processes.

The diagram below is my interpretation of the ideas Modig and Ahlstrom outline in their book. In summary, it urges organizations to approach transformation in two major phases of thinking and effort:

1. Create a true end-to-end flow of value starting and ending with the final customer of the product or service and involving every actor both inside and outside of the organization.  FOr the most part this phase does not use any significant new technological tools (e.g. new software etc.) but instead gets everyone involved in the end-to-end value stream to understand what a good lean flow looks and feels like, to learn the principles that enable lean flow (such as leveling activity and demand), and to build the mindsets, HR practices, daily habits,and model of managership and leadership required of a well-functioning end-to-end flow.
2. Apply technology, as required and pragmatically available, to take advantage of technology (such as digitizing data and using automation tools) that enables further gains in performance of the end-to-end value stream.

I’ve lived through and seen first hand the fall-out from not considering the implications behind these ideas. Here are a few to consider:

• Technology, often a “silver bullet” software package, is selected early on as the primary vehicle for transforming the process. It is believed that the software will enforce the changes in behavior and activity because it will require certain things to be done in certain ways and in a certain order, presumably improving the process. Among the many problems of this approach, perhaps the biggest is that the technology is selected by people who have little or no hands-on experience in what a true end-to-end lean flow process looks like and feels like. Technology is purchased and installed and then the organization might provide education on and exposure to lean flow principles. Invariably stakeholders (especially frontline users) will then say that had they known what lean flow looked like and its benefits they would have approached the selection of technology enablers very differently.
• Because the idea and reality of a cross-functional end-to-end process is not addressed upfront, the kind of technology that is selected and how it is set-up and used often reinforces and perpetuates long-standing functional silo habits and mindsets. The new technology often inadvertently hardens the walls between functions making lean flow even harder to achieve, harming not only the customer experience but also productivity, the very thing the technology was supposed to bolster.
• The mindset to focus on functional roles, rather than the end-to-end process as a complete ecology, and the desire to realize functional efficiency gains early (to “show early wins”) typically causes organizations to perpetuate and/or create functional efficiency metrics (e.g. number of widgets processed for a given functional role) which has the perverse effect of putting the focus on a silo rather than the flow through the whole end-to-end system. In response, these functional roles often play the numbers game to push more widgets through but often at the expense of quality, thus killing overall productivity and harming the actual end-to-end lead time for the customer.

There are many other implications but that, I hope, provides some idea of the unintended consequences of reaching first for technology rather than first building the knowledge and culture of a cross-functional end-to-end lean flow approach and then leveraging technology from a position of better understanding of what lean flow really looks and feels like rather than selecting, configuring, implementing and using technology through the lens of siloed functional thinking.

To avoid automating a broken process, first build the organizational experience of creating an end-to-end lean flow before reaching for the cheque book to buy big-ticket technology. Indeed, you might find that you need less new technology than you thought because you end up improving the existing process to a far greater extent than originally assumed.