When processes are beyond the reach of automation

Some processes are too deeply embedded into an organization's fabric for overnight fixes -- and needs a lot of support and business justification.

I recently had the opportunity to visit London with my family, and was quite impressed by the vibrancy of the city, its cleanliness, and its world-class transportation system. I also had the opportunity to sit in on a EuroCloud session led by ZDNet colleague Phil Wainewright and Vinnie Mirchandani, author of the just-published book The New Polymath: Profiles in Compound-Technology Innovations.

London's "tubes" were clean, quiet, and comfortable with upholstered seating, and got us everywhere we needed to go, with ample connections to other lines or bus routes.

More than anything, the most obvious distinctions from the United States, or continental Europe, are the currency and traffic regulations. The currency is one thing (the British refused to join the Eurozone and stuck with their tried-and-trusted pound -- which may be a plus these days). But the road system raises some interesting thoughts.

The British drive on the left. The US and rest of EU drive on the right. I'm not going to say one way is right over the other, but I wondered what would happen if one or the other attempted to convert. If a future phase of the Chunnel -- in which cars could drive directly between the UK and France -- was constructed, it would be interesting to imagine how drivers would make the transition once they make the crossing.

Suppose, hypothetically, that the EU dictated that the UK had to change its roads to have drivers drive on the right, as with the other nations?  There would be utter chaos, confusion, and crashes.  There would be a lot of money spent on new road signs and markings.  It will all be the mother of all process changes.

Just as cowpaths get paved, many embedded processes are too difficult to alter, and automation simply speeds up efforts, but doesn't resolve discrepancies. And, of course, there's the argument that "we've always done it this way," which could be made in any country about their left or right-hand-side driving.

In fact, travel first started on the left many centuries ago, in medieval times, as a way to ensure that one's right hand was free to draw a sword or weapon as a defense (since most people are right-handed).  Right-sided driving only started in colonial America because with larger wagons used in frontierland, drivers required longer whips for the sets of horses. You didn't want your whips becoming ensnared with those of others you were passing.

So, this all started a long time ago. And a conversion from left-side driving to right-side driving would be a monument process change.  Let's consider how BPM principles could be applied against such an undertaking:

Justify the project for business purposes: A rational business justification could not be made, other than compliance with EU mandates. The only possible remote business benefit would be to auto companies that would not have to have separate production systems for cars with right-sided and left-sided steering wheels.

Cost-justify the undertaking: Would likely blow national and town budgets for new or moved signs, repainting, and repositioning traffic lights -- as well as all the engineering studies that go with it.

Build support and get sign-on from affected constituencies: No support likely in the case of the UK public.

Replace manual processes with as much automation as possible: Traffic regulation is increasingly being accomplished with automatic traffic lights and traffic cameras for congestion and red lights. Conversion would be less onerous than with physical assets.

This is not meant to slam left-side driving as seen in the UK, Australia, Japan, and India. We could be talking about switching from right-side driving in North America. The point is that some processes are so deeply embedded that change is untenable. In this case, changing a process does not pass muster.  There would have to be support, political will, and an immense desire to make the change. Every organization has its own unique processes that can't be automated away by the latest packages. Are there processes in your organization that are simply unmovable, or simply aren't worth the cost of change?

(Photo of a London street by the author. Note that the cars on on the right-hand side of the street... it was one-way.)