BPM can make the difference between success and failure in a business.
But, there are pitfalls that need to be avoided.
The little Red Hen said “Who will help me develop my processes?. “Not I,” barked the dog.”Not I,” meowed the cat. “Not I,” quacked the duck. “Then I will,” said the little red hen. So the little red hen developed, managed and owned her processes, all by herself.
In the area of Business Process Management (BPM), functional units typically are unable to develop, manage and own their processes.
Usually, they have to go cap in hand and explain their process needs to IT who then write a software application specification. Months/years later the unit takes delivery of an airplane when what they really wanted was a submarine, no one can/will agree to use it and that is the end of that “project”.
Some functional units, on the other hand, using current BPMs’ (not legacy BPMs’) are able to map out their processes, improve them, put them in service and proceed to improve productivity, increase throughput, reduce errors, improve compliance with internal rules and regulations and achieve interoperability.
Easy for me, difficult for you? Well, it depends.
The one hurdle functional units face is the configuration of branching decision points along BPM best practice protocols. Here, good intentions are not always enough, so no harm going to IT for help, particularly with rule sets that engage different sub-protocols on the basis of real-time data. Without branching decision points, your process will be useless unless you have a purely straight-thru process.
Sure, some IT departments would find it more interesting to develop an application from scratch, just as they might find it interesting to develop the next-generation Ferrari in their garages, but whereas a grandiose project is likely to take years and cost heaps of money, a rule set at a decision point is likely to take ½ an hour, a few hours or a couple of days, worst case, to build and test.
Now, if a functional unit does not have at least one person who is able to “think” process, then they pretty much have to go to an internal BI unit, or to an outside consultant, or to IT, providing they don’t end up having to give IT a course on “what’s a process?”
The fundamental question of course is “Do you need processes?” – the easy answer is yes, if you want to do the right things, the right way, at the right time, using the right resources with a view to getting consistent good outcomes.
Now is a good time for you to start documenting your best practices and getting your workflows to work for you instead of you working with some third-party’s notion of what your workflows should be.