According to just about every industry consultant I’ve ever known, businesses are supposed to have well-defined processes that move the work along in a series of orderly steps. Those who execute the various steps are fungible — interchangeable, except for the specific skills and knowledge they use to carry out their role in the grand process.
It’s actually more than that: Businesses, many assert, are nothing more than collections of processes — equivalent, perhaps, to a physicist asserting that the universe is nothing more than its energy flows. Matter, in this view, is only important as the stuff energy acts on to demonstrate its presence.
But matter does matter, and the universe, we’re starting to realize, consists of far more than matter and energy: There’s dark matter, dark energy, antigravity (Einstein’s cosmological constant), and virtual particles (which are matter, but only temporarily). Not to mention the additional 6 spatial dimensions beyond length, width, height and time that string theory requires. The universe is, clearly, far stranger than it appears. Not as strange as the average corporation, to be sure, but strange nonetheless.
But I digress.
Viewed from one, narrow angle, businesses are collections of processes. It’s a useful perspective for organizational engineering. It’s dreadfully incomplete, though, when your goal is to actually improve things. That’s because the starting point for an efficient business isn’t the design of efficient processes. That comes second.
What comes first? Trust among the parties who design the process, staff it, and use it. Relationships, to choose a word. Anyone who has been through a successful process redesign and implementation knows this, although many don’t know they know it.
Successful process redesigns involve all stakeholders, or at least representatives of all stakeholder groups. There are three reasons for doing so. The first, least important reason is that every stakeholder group knows something nobody else knows, and unless the process design takes that something into account, it won’t be able to accommodate all of the situations the world will throw at it.
The second, more important reason is to build confidence in the new process on the part of all stakeholders. Without that confidence, everyone will simply do things the old way, because they know it works and have no faith in the newly designed alternative.
The third, most important reason is to build relationships — to build trust on the part of everyone involved in each other. Those who make use of the process have to trust those who staff the process to do their work properly, just as those who staff the process need to trust that those who make use of it won’t bypass it the moment it appears the least bit inconvenient. Those who staff the process also have to trust each other — trust, that is, that all will play their parts properly.
That’s a whole lot of trust for a corporate environment. Is it any wonder one of the most important skills in many corporations is knowing how to bypass the formal processes and procedures, using relationships to “get things done”?
But every time someone bypasses the processes and procedures to get things done they damage the organization a bit. If the processes and procedures are badly designed that might be a good idea: Damaging a mindless bureaucracy is akin to damaging a logjam. Damage isn’t always a bad thing.
Most processes and procedures, however, are appropriate for the situation, simply inconvenient to those who, accustomed to privilege, are looking for inappropriate attention or importance. Each time one of them bypasses the process, it breaks the whole system a little more.
That brings up one of the most difficult challenges faced by any process engineer: Determining whether the existing process really is sufficiently broken that it should be replaced, or whether the problems aren’t with the process, but with the relationships among those who are supposed to use it.
If the problems are with the relationships, redesigning the process will only improve the situation by accident. If the problem does, on the other hand, involve an inefficient process, one of the first places to look when finding ways to streamline the workflow is to eliminate delays created by the need for multiple signatures and approvals — the result, ironically enough, of distrust.
Which is to say, many bad process designs are both the result of a lack of trust, and its cause.