Run better business processes with a BPMS, not a programmer

A few days back, my colleague Steve McDonald asked me a question that went something like: "Do companies need BPMS to make their processes work better, or can you just write custom applications that represent the process?". Well obviously we both have a bias towards the BPMS, but I believe its for good reason - I have wielded a compiler at some point in my career and I can honestly say that the results were 'variable'. So we agreed that having the structure and tooling of a strong BPMS in place allows you to concentrate on the business problem you are trying to solve, rather than the mechanics of writing code and pure custom apps.

Look at any organization and you'll see that business processes do run without a BPMS, as loosely organized paper and email based processes based around a custom Access database application. Many low volume processes that we see in organizations, around processes in HR and Finance for example are commonly run in this way. Making a business case to improve these processes is difficult since it depends mostly on soft metrics like enforceability, compliance and visibility, and taking them the extra step with a complete BPMS may be considered unnecessary.

Now consider a high volume process handling thousands of insurance claims per day. Typically this is a process that has evolved to incorporate human interaction, system to system integrations, paperless operation and fully managed business processes. The business case for BPMS implementation and the measure of its success is metrics like reduced cost and time to process a claim, improved capacity, reduced errors, less customer service call center abandoned calls. These are not metrics that can be achieved without a BPMS – actively executed and managed processes are essential to ensure that the claims process runs like a well oiled machine. There is no room for unnecessary activities to be performed by the process users, either in receiving or delivering work to the right place, or in the oversight to ensure that the process runs as it should.

Attempting to put a process application together out of component parts, a bit of process execution here, a bit integration there, and some loosely defined reporting over the top, is a bit like the factory workers building a BMW attempting to build a luxury car using tools they had brought in from their home garages that morning. Even with a strong process, and great components, who knows whether they would have enough ratchets and the right size spanners to put the car together successfully. I'm sure there would be a lot of use of the 'leather hammer'.

The strength of a BPMS comes from being to apply the management discipline of BPM to the best technology to really ensure that a well oiled process can roll high quality product out the door, and at every stage you can have visibility and control to ensure this happens. Having great visibility over the crew of BMW workers with inadequate tools is probably as unsuccessful as knowing the crew have great tools, but having no idea whether windshields, wheels and brakes have been delivered for them to actually assemble the car. A carefully selected BPMS (not the one you selected to handle 100 travel expense claims a day) can provide the tools and visibility to deliver the business objectives for highly efficient, cost effective and visible business processes.

Technorati tags: BPM BPMS

A post from the Improving New Account Opening blog