Quit trying to pimp the workflow

Why forcing a technology solution to fix your workflow is a waste of time and money

A conversation that seems to crop up on a fairly regular basis is one that I am sure most of you are familiar with. It goes along the lines of...

"We need to make process X more efficient, let's get a super whizz application installed that will make it easier to do things and will let us do all these other things at the same time."

My response is nearly always in the form of a question, and nearly always the same question.

"Before you run off and do that can you tell me exactly what the process is and what your problems with it are?"

It's right about then that I see a lot of puzzled looks and head scratching starts. A sudden realisation occurs that when they actually think about it the workflow, it isn't really that well defined and the problems with it are actually more fundamental business wide issues, rather than specific issues with the actual workflow.

Sadly what often happens next is many rounds of discussions trying to argue that even if the problem space isn't 100% defined, application Y is bound to make things a bit better which is surely better than nothing at all, isn't it?

The answer to that position is a resounding 'No, it won't!', followed by a slap to the head for even suggesting that it would. The fundamental mistake that most businesses make in operations these days is patching workflow problems with perceived "silver bullet" technology. Also when I say "workflow problems" in reality it's usually only the symptoms of the underlying problems that are being addressed rather than the true cause. You have to dig deeper.

The first and most important thing to do is actually to step back. Getting a higher level view of the overall situation before getting down to the nuts and bolts makes sure you're not busy defining your way into a dead end, or working on only part of the actual process in question. Invariably workflows do not work in isolation, so having an understanding of the different workflow couplings and integrations is essential.

Once you have a handle on the entire problem space, then you can get down to defining the actual workflow you are trying to address. There are many ways to achieve this, but one method that is as good as any is to grab pencil and paper and actually map it all out in one or several flow diagrams.

Now we're getting somewhere. The problem space is understood, we have a visual definition of what the actual workflow is, now what? Time to implement that super whizz application because we have a definition to work with. Wrong. The next step is to implement the workflow using minimal technology, just enough to make it work, aided with manual processes, and simple technical additions, nothing fancy. This is the validation and testing phase. If you have truly understood your workflow and got that definition right, even a fairly manual process will still give you tangible improvements over the old broken way you were doing things. It's not exciting, it's not flashy but it works. And importantly it's probably cost you nothing other than some management time to setup and actually fix your workflow.

If you haven't got things right it should be fairly obvious and also simple, cheap and quick to amend how your doing things to get it right.

So what about the flashy technology. Well, assuming your new semiautomated workflow is doing well, then you should have confidence that you understand your system now and are therefore in a strong position to move to the next stage of full automation. From here on in your are looking at a cost/benefit analysis to pick the right time to invest in the right technological upgrade to get that final level of workflow optimisation. You're no longer trying to fix problems, but improve efficiency in an already well established and functional workflow.