Recently I have been seeing a large number of links to Ross Mayfield’s blog post called the End Of Process. The article seems to go into a number of different directions but at the heart I think is that organizations put too much faith in rigid processes and that is generally bad. I would partially agree. Any rigid process is a bad thing. Unless you can guarantee that none of the variables you encounter in your business will ever change, then a rigid process is almost always a bad thing. But the simplification of that idea into “The End of the Process” I totally disagree with.

Processes are good, automating those processes (where appropriate) is good (Hopefully you will use my employer’s toolset to do it, but there are plenty of competitors here too). But never give in to the process and accept that it can never change. Change is good.

So I mentioned ‘where appropriate’. Where is it appropriate to document a process and where is it appropriate to automate it? I would like to think that it is always good to document significant processes, as long as everyone involved knows its a living document that will change as all the variables (internal and external people, places, rules, etc) change. What is a significant process? Well, I think that any series of steps you perform over and over again for a while is significant enough. And if more than one person is involved, the chances of it being significant goes way up. The point of the documentation is to ensure that you remember the process,and/or the organization doesn’t fail when you get hit by a bus. Another perhaps more important reason is to enable everyone to see how a process works and who to go to for more information on any of the steps.

Now that you have a document, when is it ‘appropriate’ to create an automated workflow? Well, anytime you automate something its going to have a cost. Even with such easy to use tools as Captaris Workflow, its going to take time and money to get it done right and to manage it. So if the return on investment is acceptable, it probably makes sense to automate that process. But again, processes should not be rigid and whatever framework you choose for your workflow, it should be able to accept changes easily. The costs of these changes should be figured into your ROI calculations.

What are some typical processes that are good candidates for automation? Many of our customers get excited about being able to easily create workflows around their expenses, travel, and legal processes. Chances are, the way you purchase plane tickets has been roughly the same for the last few months and will probably be roughly the same for a few more months.  Same can be said for your expenses and for getting documents approved by your lawyers. Each of these processes often involve several people and at any step, some people will want to know where everything is. They all take time to complete and being able to shave a few minutes or days off a process often equates to real costs being saved. Processes like these are good candidates for automation.

But one of the processes mentioned in the article is exactly the type of process that should never be automated. In fact, since there is a strong tendency to put too much faith in anything in print, there may be reason not to ever document it.  The processes is that around innovating. I don’t know how an organization could ever put a process in place around innovating. Perhaps Ross was referring to taking an idea that has been fleshed out to the next level, but as he mentioned, there are so many exceptions to the rules here that a defined process probably harms more than helps.

I think Ross and I are saying roughly the same thing. But I think lots of readers have latched on to the title and read more into that without actually looking at the article. Processes are here and will always be here. We need them to get the more regular parts of our working lives done. I like processes because I don’t want to have to reinvent how to get something done every time I want to get it done.