When we work we actually execute one (or more) of the "business processes" of our company. I think that "business processes" are, actually, part of the plumbing of each enterprise. At a point that, sometimes, it is "hard" to describe it because we sort of "live it".
So, in that matter, BPM should be the obvious fit.
The fact that it is has been "hard" to introduce it in the enterprises makes me thinking to the following:
- A business process which is not documented gives the possibility to be "adapted" more rapidly. Actually, a pre-requisite for adopting BPM will be to document what needs to be automated and managed
So, the perception may be that the company would be “more agile” if something could be changed without running into a big Change Management process.
One could, also, think that something that is “not documented” may not be accountable also…. but this may certainly be the “bad guy” who speaks in my head…
- A significant business process often spans several domains.
Formally describing it may introduce negotiation issues across departments and may imply some organizational changes.
- Once a process is described and ready to be deployed, an owner will likely be required.
The owner may not be clearly identified yet and this may require some further negotiation. And may imply,once again, some organizational changes…
- As Nicholas Carr was saying in his book “The Big Switch”, it is easier today for companies to adapt themselves to the business processes embedded in the CRM and ERP tools they buy instead of investing time to describe and negotiate company specific business processes….
This said, I think that the maturity of the market and the maturity of the products are now helping a lot in the adoption.