Blinkered Process and the Tonga


“If a man never contradicts himself, the reason must be that he virtually never says anything at all.”



An abiding fond memory of growing-up on the outskirts of Bombay was the rides in a one-horse buggy called “Tonga”. These were fragile buggies, and as you climbed into one, there was this nervous moment during which you half expected to fall backwards on to the street. The indiscipline on the street meant that practically all the horses employed to pull these buggies wore blinkers. The blinkers restricted their vision by blanking out any distractions from the corner of the eyes that might startle the horse. The horse focused in the direction the tongawala (or buggy driver) steered.

The task of getting his fare safely to the destination was a complex process; it was a time of undisciplined road travel environment consisting of other Tongas, cars, buses, lorries, weather, and of course people. Although, the word process would suggest, “a series of steps to achieve a particular goal”, it was anything but just a series of steps. It was unlikely that the same response would always solve problem created by events occurring along a typical journey. The numbers of parameters that come into play when an untoward event occurred were dependent uniquely on that event. No two journeys between two endpoints via the same route would be guaranteed to have the same events, or the same parameters for the events. An experienced tongawala was able to avoid many of these events unscathed, due only to the tacit knowledge he accumulated over the years of driving a Tonga in different conditions. It should be noted that the task generated by the untoward event was a collaborative task; it required the reactions of the horse and similar deft response from the tongawala to avoid the consequences.

If the tongawalas got together to create a procedural document for training novice tongawalas, well it would mostly fail. The document would be forever incomplete, because of the innumerable parameters for every single event that have to be documented. More than that each event documented would be out of date as soon as it is documented.

But, for all this wealth of (tongawala!) experience we still advocate a mechanism of, find the goal, leading to model, leading to action. We ignore the complex nature of the domain, and attempt to bend the problem space into a nice straight line (or many connected straight lines – putting it technically, piecewise linear) with a beginning, an end, and a series of well-defined steps (or so we tell ourselves) in between. We like the sense of control this gives us over the process, building for change be damned, and while we are at it let’s also ignore tacit knowledge; let’s just ensure individuals do what we want them to do. The biggest bugbear is change, but then we hardly care that obsolescence is built into products we purchase, so why not apply the same logic. Let’s not worry about change, let’s just replace, or worse still imagine that the model represents a quilt and just keep adding patches. This form of process design emphasises resistance to change, advocates absence of change, and not mastery over change.IIA_Spaghetti_Bowl

Not all processes are complex in nature, but the nature of business would suggest that change is inevitable even when the process is simple. But, how simple is simple? Would a process with well-defined tasks of a thousand be simple or is that too large and hence complex? Or perhaps we should look for sub-goals and therefore for sub-processes? Before we know it we find our process becoming messier and spaghetti like. Even the tongawala knows that traveling on a country lane with no traffic isn’t a cakewalk; he still has to be aware of events that could lead to a tumble, like the odd ditch.

Perhaps the blinkers go further back (at least in western thought), if the creation of the world was the goal with a procedure / model, and whose enactment led to fact; surely a humble business process cannot go wrong with the same application. Ignoring the complex nature of the problem domain does not future proof the implemented solution. It leads to the contrary situation of keeping the wheels of the organisation turning for a time, while also like Alice in wonderland, not going anywhere.





About KM Mukku

Kick-start, build and manage teams in product development (particularly in the financial domain), and enjoy all in adaptive case management, business process design and business process improvement. Currently holding the position of CTO at coMakeIT.
This entry was posted in BPM, process design and tagged , . Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s