Why do certain processes perform beyond expectations while others never get really off the ground and, even after years of their implementation, seem to be in their infancy? Often the reason is that the system has either been overfraught with expectations or an inadequate organizational setup has been chosen to perform the process - or both.

While it is accepted that a technical device is designed for a specific purpose, there is the notion that business processes (especially the ones with a high share of manual work) are able to adapt to an infinite number of different requirements or should easily support variations thereof. With a greater variety of the services rendered, the efficiency drops, and the management becomes difficult. Efforts to improve the process become very hard since the exception becomes the standard. In total, the complexity grows and, if the process owner can afford it, this shall be remedied with more resources (e.g. process improvement engineers) that further increase the organization's complexity. As a consequence, the system moves further away from what can be considered a high-performance work system.  

How can this be avoided, and what needs to be done to build high-performance work systems?

The first question that needs to be answered is the most obvious one - what shall the process actually be doing? The demand needs to be presented and reasonably be challenged. The (internal) customer must be clear about what is essential and which exceptional cases/needs could be avoided or bundled with other features. It needs as well to be clarified how much variation of the specifics shall be expected over time – as of a certain point, considering an operational segmentation instead of adding more requirements to an individual process should be considered.

Any minute invested here will pay back multiple times. This is probably the most critical step to get to a high-performance work system. The joint effort is to reduce the complexity of what the process shall be producing as an output.    

Once the service portfolio has been defined, it’s time to simplify the organizational structure. Due to the lower complexity of the execution, the organization can as well be simplified – less ambiguity allows to delegate decisions to the people actually doing the work, much fewer exceptions make queries less necessary and ultimately non-value-adding roles (which have been created to manage the complexity that the process owner can stay afloat) do get now the time for assignments that really improve the execution of the defined service.  

When both actions have been brought together, the new process will become part of a high-performance work system. The throughput will become scalable, the quality will improve, and work-satisfaction will increase since the ownership of the process can be transferred back to the people executing the task.  If carefully managed, the process will then as well be able to adapt to changes – however, replacing an existing feature with a new one must not be mistaken with adding new features.