I was recently asked, “Do you ‘fix’ processes before implementing a business process management system (BPMS)?” This is a very good question and something that sparks great debates whenever it comes up….how much time should be spend documenting processes that exist, especially if processes are seriously flawed?

I’ve said many times that if you don’t start with the processes you have, good or bad, it is tough to create something better from scratch, have it make sense, and at the same time understand the path to get there.

The reason people have this debate is a symptom of the bigger problem…that process data usually hasn’t been captured, owned, and change managed in a way that even allows for what I’m advocating. Those who argue for a clean sheet of paper don’t see process data in the right way.

Master data history

Looking back at how we treat data, it was easy to move from written ledgers to centralized accounting data, and from the rolodex to centralized CRM data. Before automation, process was drawn by hand, stored in written SOP’s and in static diagrams and never made the switch to centralized data.

That’s a shame, because business process is, essentially, critical enterprise data that absolutely can and must be centralized and treated the same way as customer, employee, financial and other data. You wouldn’t have duplicate employee, customer or financial data, but it is quite common to have process data in fragments and duplicated around the enterprise.

The original question

Going back to the original question…after data on existing processes is captured in a centralized, governed way as “master data”, processes can be ‘fixed’. It can be done as evolution to the right answers that is non-disruptive (and lower risk) and makes sense for all stakeholders.

Lacking this approach, process data will continue to be something organizations struggle to manage and communicate.