Whether you rely on the workflow component of an enterprise content management (ECM) tool or on the heavy-duty functionality of a business process management (BPM) product, there are some best practices to be aware of to help ensure your envisioned deployment becomes a reality.
Herewith, some advice on how to win, how (not) to fail, best practices, who’s winning, etc., culled from Doculabs’ consulting work for clients representing each of these categories.
1. Profile your candidate processes and then fit to the right kind of BPM tool. This is critical as an early step. How do you profile? There are good and bad ways to do this, but here’s a simple and effective way that we use. You need to look at more than just “scalability,” but your analysis has to be simple and fast. So classify your processes as to where they fit in the following dimensions: 1) pervasiveness (scalability in terms of numbers of users), 2) level of capabilities (basic to advanced; specific to general), and 3) types of users and applications (knowledge or process). Then use the right tool for that fit. Every BPM tool has a different profile regarding where it fits great, where it fits okay (and can be used if you already have it in your portfolio), and where it would be a disaster.
2. Focus on blocking and tackling first – and don’t be seduced by razzle-dazzle. What’s most important is the blocking and tackling: the proven ability to manage processes in production without faltering as the requirements increase in scale and complexity. Everything else is secondary. I’ll repeat this: you should focus on what will lead to successful execution in production, more than on attractive but unproven features. Some of the attractive secondary capabilities include analytics and reporting, “advanced case management”, “social workflow”, and integration with social media, as well as other high-profile features of the process management market today. It’s okay to go after these secondary benefits on top of the foundational blocking and tackling – but make sure you don’t fail in production first. Most BPM products fail in two ways: either they may provide the foundation without differentiators, or they provide the sexy differentiators without the foundation (which is far worse).
3. If you do BPM in the cloud, address the five primary issues. The five primary issues for cloud-based BPM today are:
- Security, segmentation, and confidentiality
- Business continuity (i.e. disaster recovery) and availability
- Accountability (whose neck is on the line when there’s a problem)
- Flexibility and customization
- Vendor, product, and project risk are the big issues for cloud-based BPM. “Vendor risk” means your initiative will fail because the vendor dies or gets bought; “product risk” means that your initiative fails because the offering (the “product”) fails to be adequate; “project risk” means that your initiative fails because the vendor doesn’t provide adequate service and support.
4. Apply the “3-Year Rule”. This is a simple, effective way to help ensure you’re controlling vendor, product, and project risk – and following tips #2 and #3 above (i.e. blocking and tackling versus razzle- dazzle, and cloud versus non-cloud). Ask yourself: Has any BPM offering from this vendor been successful in production for 3 years? Most BPM vendors fail this test – so are just trying a different approach (“advanced case management”). The safest approach is to go only with products (this also means cloud services) that have been in successful production for 3 years. An aggressive but still risk-controlling approach is to go with a product (or cloud service) that has not passed the 3-year test, but which comes from a vendor that has a track record of at least one 3-year stretch in production. Stay away from vendors who can’t even do this much.
5. In most cases, it’s best to do BPM in two steps. It’s often best to digitize the paper-laden process first, and then live with the new electronic environment for 6 months or so before redesigning and automating the processes. This has three benefits:
- It avoids the cliché situation of “automating the paper process” – i.e. badly designing the new process because you haven’t properly understand the impact that electronic documents will have.
- It’s often necessary for change management. Let the workers adjust to the new electronic environment before they take the next dramatic step of automation. This is an application of the best practice rule that’s been learned after considerable expenditure of blood and tears: In order to optimize the two requirements of full worker participation (everyone plays the game) and high work quality, you should focus on participation first, and then incrementally ratchet up the expectations and responsibilities of high quality. If you try to optimize both too early, you will fail.
- You should proceed in your BPM implementation in relatively small steps (“baby” steps are best), which allow you to stop at any step and declare victory. Half-completed workflow projects are not “’halfway there” – they are failures. Not only did they break the old process, but the old process has not been replaced with an adequate new one. Digitizing first and then pausing provides a good way to control this risk.
6. Design information lifecycle management and records management (RM) into the workflow. The processes worth automating are going to have high-value, high-risk content and documents, so you’re going to have to address their risk and regulatory requirements at some point anyway. RM is most successful when the documents to be managed for RM are already under the control of a structured process and a managed document system. The context of the process and systems that they are in allows you automate most of the stuff you need to do for RM, so users don’t have to waste time being file clerks and records managers.
7. Always design to optimize partial failure. Almost everyone – 100 percent of the vendors and 99 percent of organizations – assume that the new process and technology will work as advertised. They then analyze the efficiency impacts based on that assumption in their business cases, operational planning, etc. But the systems never work exactly as planned. It may be an acceptable or even happy failure, in that what happens is okay or even better than anticipated – but your final production process always differs from how it was originally designed. And the impact, usually, is bad. So be sure to model failure and “half-baked” scenarios that require exception-handling. Make sure you can optimize a completely uneventful, successful implementation. But have lots of “Plan Bs.”