One of the most common issues I hear when working with distributed organizations is how many problems are caused by the lack of standardization of process. Each of the units is operating in a different manner and feels those differences are important. However, there seems to be a common assumption that when we see an organization without standardization in its processes that there is some purposeful design behind those differences and variations.
More often than not, I am finding that often these differences in approach are simply the summation of rampant unguided best intentions rather than appreciation for needed process nuance or some desire for autonomy or rebellion against standardization or centralization. It is not about being different as much about a collection of decisions which led to a result. It is differences without design.
Often the instinctive approach (what I’ve been asked to help with) is to create a single process and mandate its use in hopes of achieving efficiency improvements. However, even in organizations where this is politically tenable, there is still a significant change management cost and a one-size-fits-all approach may not be ideal, or even an improvement. The pushback to this is often felt as “see, they just want to be different.”
Many times there are historical reasons why these local aberrations occurred. Maybe at one point there wasn’t a central group to handle the service or offering and therefore various groups and individuals had to provide the service on their own. Sometimes the central service was poorly supported or became inflexible as growth expanded the scope of services and products being offered.
Whatever the reason, this situation is painful for everyone. These individuals and groups likely designed their process without expertise and guidance and find themselves with a bad process and limited central support (while being yelled at for being difficult). At the same time, the central administration is trying to herd the cats of multiple processes and manage the output, integration, and reporting of disparate process systems.
In the end, both groups complain about the other side and the lack of appreciation for the challenges the situation is creating. To make matters worse, there are some who are being served by this array processes who are actually happy because they have complained enough that a group or individual has adapted the way they work to do exactly what is desired. Those being served are livid that anyone is even thinking of making changes.
Since the local groups are often frustrated with their own processes and the administrative burden which comes with them, they can be open to change, with some caveats. The key is to find a design approach with fits all (or at least most) of the differences which are likely to exist. This doesn’t necessarily mean that a one-size fits all is the way to go or that each group needs a custom process. If one process is too rigid, and scores of processes are unsupportable, we find something in the middle. More often, I am finding that the standardized “archetype”, or menu, approach offers a solution from which everyone benefits.
These archetypes are a menu of standard processes which allow each group to select the approach which best fits their situation. For example, instead of a single sales processing function, there might be versions of the process for a variety of use cases like commodity orders, custom orders, consulting services, and so forth. The carrot is that if you use one process design, there is central support, tools, clear guidelines, and so forth. Choose to be on your own, and you lose all that support (and will continue to be yelled at for being difficult or held hostage by a particularly difficult customer who will yell if you try to make improvements). Most of the time, groups can become open to centralization, as long as there is a process design approach that considers their needs.
In short, we must appreciate, but not be tied to, the differences in how processes are executed. With an understanding of the broad context, we often have the opportunity to design solutions which deliver the benefits (if not the ideology) of centralization, while still being flexible. Different and design are not antonyms.