Working with clients and working on a couple of proposals this week, I was struck by comments coming from very senior people. The first was: “All that workflow documentation is so time-consuming and tedious” and the second was: “The price could be lower if it weren’t for all that business process analysis.” Comments like this require swift and comprehensive attention lest BPM fall out of favor with those who develop budgets.
By show of hands, who has ever paid someone-an outside consultant-to document their workflows? Is it any more time-consuming or tedious than the work of an accountant? How about a lawyer? Ever hired a marketing consultant? Ever hired a developer or programmer to crack custom code? Is workflow documentation more or less time-consuming or tedious (expensive)? The answer is NO. This is an example of bad judgment. The judgment of someone who tried it (BPM) him/herself and got stuck in the “weeds” and burned out. It’s especially bad judgment when the work being done (and questioned) involves the automation of terribly inefficient manual processes that produce myriad quality concerns. How do you say “duh” in .NET?
It Takes Vision and Skill
I think the best workflow and business process analysts are visual. They can “see” the big picture and the composition they are creating and they think spatially. They can whip through a workflow MUCH FASTER than the clients I quoted earlier can write and edit a procedure. Another factor contributing to speed might be special handling of the BPM tools expert analysts should be using – including MS Visio.
Purpose and Context: Elements of Good Judgment
I read a very good article on the context of project management at the Project Management Hut today (http://www.pmhut.com) and was reminded of the importance of purpose and context in business process analysis and management. My point is: the degree to which I capture and document data/information in a workflow or process diagram is a reflection of the purpose and context of the diagram. In other words, as the purpose for documentation varies, the degree of detail and notation will vary.
Consider the following over-simplified examples:
- When the purpose for my documentation is to create efficiency, I will note value-stream mapping elements
- When the purpose for my documentation is the automation of a workflow or process, I will document rules and functional requirements in a JAD (joint application design) session so my developers or vendors can develop the system I need.
- When the purpose for my documentation is compliance with the law, I will supplement my simple diagram with a professional narrative and policy language.
- When my purpose is innovation, I will document the essence of the process and allow my team to play with it until the future state materializes.
- When my purpose is quality improvement or performance improvement, I will gather and document key measures and metrics and follow Six Sigma rules for notation concerning DMADV (define, measure, analyze, design and verify) for example.
Not the Kitchen Sink
There is so much you can do with workflow and business process documentation and analysis. This is a great field and we have a wide array of tools and methodologies. Remember that we don’t have to use all of our tools and approaches all of the time. Use your best judgment. It’ll help calm peoples’ nerves.