What I learned this week … came from PLM Processes: Flowchart vs. Rule-based? from Oleg in PLM Twine. He discusses rule-based business processes for PLM, which immediately 
set off red flags in my head based on past experience. Oleg made me think about two different experiences I have in the same context, and it made me shudder. Why? I have seen rules go wrong too many times. And I have seen workflow processes go wrong just a many times.
Workflow Warnings
As Oleg knows, I am bit of a process weenie. Years at Andersen Consulting (the part that is now Accenture) will do that to you. I am 100% in favor of defining processes as a part of implementing business change and supporting technology. But here are some tidbits that I think are worth sharing:
- Define All Processes – Technology implementations should be process driven. Unless you define how the technology helps the business, you won’t get the most out of it.
- Automate Some of Them – Not all processes should be workflows. While workflow is a great tool to automate and enforce processes, don’t overdo it. I have seen people implement workflow for workflow’s sake. It should be used as needed to improve efficiency and process adoption, but don’t workflow everything.
- Don’t Sweat the Exceptions – There are times where humans need to step in to make decisions and alter workflows. Don’t try to handle every exception condition. If you can identify them and send an alert, great. But most importantly make sure you have flexibility to alter a workflow based on business needs. This is where I see rules-based processes go wrong. Companies try to make rules cover too much, get too complex, and end up being hard to maintain, outdated, and eventually ignored.
The combination of workflow and rules can be very powerful, but can also lead to a resource sinkhole of if not approached cautiously. This is true for the process / rule authors and those that execute them alike.
Implications for Manufacturers
Define your processes. Use workflow where it makes sense. Keep it simple. Don’t try to do too much. Don’t forget that in many scenarios people make better decisions in context than any pre-determined set of rules can handle – don’t tie their hands. If you have standard operating procedures that you need to follow, you may need to document process exceptions. But don’t entirely lock them down in the system. Exceptions will happen, and if the system doesn’t accommodate the real world it will just happen outside of the system in an unmanaged way.
So those are my quick reactions to Oleg’s post, I hope you found it interesting. His post is worth reading if you haven’t already. But I get scared when I see the opportunity for things to go astray. And workflow and rules are a great candidate for bad things to happen. And this is from a self-admitted process weenie!