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.
All Things D
ARS Technica
Engadget
GigaOM
Mashable
TechCrunch
The Verge
Venture Beat
Wired
Chris Brogan
Brian Solis
Chris Dixon
Clay Shirky Blog
HBR Blog
IT Redux
Jeremiah Owyang
Radar O'Reilly
Seth Godin Blog
SocialMedia Today
Solve for Interesting
The TIBCO Blog
Lifehacker
Process as a class of Master Data is a concept so strange to most people that it can raise eyebrows or invoke zero reaction.
Back in 2005, at the inaugural Gartner BPM summit in Washington DC, I used the concept in a workshop that I was running and it was a useful linchpin for the workshop was running regarding our Process approach at a major US tech company I was working for then. And it’s a solid idea. Process is a class of master data. Everybody knows the chaos that that can ensue in Order to Cash if you don’t have such fundamentals in place as Customer, Product and Vendor master data. You have one single data set, you limit who can maintain it but let everyone use it.
Now apply that thinking to process (and, by the way, I mean ALL process not just the 20% that is automated but the 80% that is people doing things manually) and you can start to bring effeciences that will benefit your customers and stockholders. If you don’t have master data, you audit reports will likely be uncomfortable reading.
Isn’t that what marks out Master Data sets? If it is then there’s no question that Process is another class of master data.
No let’s go back to the basic question do you document it before you fix it?
Mostly I would say yes. If you don’t understand what you do today, how can you fix it? I agree with that, mostly. But I also think that sometimes (often) there’s a larger elephant in the room we may understand what we do but do we understand why? ‘But we’ve always done it that way!’ is a common problem when process improvement initiatives are under way.
Sometimes, it’s just easier to proceed on the basis that we know the current process is so broken, that the reasons for doing it that way are a mystery to nearly everyone, that it’s easier to start with a blank page and build the process that will please your customers. You just need to keep an eye out that you don’t recreate the problems you set out to fix
Oh, and then make sure you treat it as a class of master data
When trying to leverage a process frameworks, an organization should adopt the framework before attempting to adapt it to their needs. This finding from last year’s study on using process frameworks to get real work done is as counter-intuitive as your proposal here. However, both that finding and your proposal result in significant value for organizations. Implementing and managing change is one of the most complex and least understood aspects of business process management, yet one of the most important.
Right on Chris. Another discovery…the lack of understanding of the importance of visibility of how work is done. If you do not know what you have you can not fix it nor management it effectively. Visibility is very important.
BTW John G Tesmer, I agree with your perspective on Change Management.