Max often writes provocatively, and this one is no exception. I think if one reads his work and takes the big ideas without getting hung up on a few of the specifics that might cause debate, there's a lot to take away and internalize.
As an aside, I find it interesting how often BPM is characterized as being a rigid Tayloristic approach to business - but this is never how we approached BPM at BP3, so I have a hard time relating to this point of view - it sort of assumes that we can't learn from Taylor and Drucker (and others) at the same time, and benefit from more than one process improvement theology. If I can sum up the criticisms (not from Max's post, I'm borrowing from many discussions on blogs):
- BPM is rigid, like a Taylor management-by-science-gone-bad approach.
- BPM can't be about managing to objectives, like Drucker would suggest
- Knowledge workers can't be managed by a process, or by BPM
- Creative processes can't be managed by a process, or by BPM
Of course, those of us who do BPM "right" look at it a bit differently:
- BPM is about adapting to the change that is happening in and around your business.? It is scientific in that it puts value on real data, but it does not believe in replacing human judgment and decision making and subjective valuations. It is not about automating people out of the process - it is about putting the right information in front of them at the right time so that they can do their job more effectively, and make good decisions.
- BPM can be about whatever you decide to focus on - managing to objectives or managing a prescribed process - much depends upon the kind of work you're tackling.? Clearly, handling financial transactions there really shouldn't be a lot of variance in executing account transfers. But deciding how to handle a customer complaint may leave a lot of room for judgment.? And deciding what the objectives are for a line of business is a process that has much wider latitude.
- Knowledge workers interact with processes all the time.? If the process is to support knowledge work, it has to be quite different from one that is quite constrained and repetitive - but that isn't the same thing as saying it can't be done.? ACM proponents prefer to talk about this as a separate discipline than BPM - which may leverage the same software tools.? That's fine - but the point is, there are software tools that market themselves as BPMS packages that *do* support knowledge work, and there are BPM professionals (like BP3) who build and support knowledge worker processes day-in and day-out.
- Creative efforts can absolutely be managed by process.? If anyone thinks Einstein and Edison didn't have a process to guide their efforts, they haven't studied these two.? Genentech and Apple both have repeatable processes to guide their innovation and creative efforts.? Do they use a BPMS? Likely not, but I don't despair about that because the penetration of BPMS packages into the market is still small relative to the potential market size, and just because someone doesn't use a tool doesn't mean it can't be useful to that purpose.
Lest it look like I am writing the above as a disagreement with Max, I don't believe that's the case - I just want to set the background for some of the general points made against BPM, and my feelings about those points.? Here are some great points from Max that I think a lot of people could learn from:
There are BPM proponents who say that using structured process should be seen as applying experience. I disagree, because a rigid procedure that may have worked in the past is not goal oriented. Experience is something one gains as a person and is not something one can copy. Applying experience happens by people at each singular activity towards the goal. Experience won?t get encoded into process flowcharts during analysis.
Very true.? BPM proponents *should* be applying experience to their work, but that does not mean that a well-built structured process replaces experience.? Max's points illustrate why it is so important to have experience in general, and specifically with BPM deployments, in order to understand these finer points.
The higher you go in the management hierarchy, the less predefined processes you will find, need and be able to work with. Otherwise, why would one need management and executives? That?s why I am opposed to best practices that are no more than an average of past approaches now being applied to a specific situation without being sure of its applicability.
Again, great points.? Part of the reason processes higher in the organization don't get defined as well as because there isn't economy of scale at that level.? But at organizations like GE, they have very evolved processes around developing their executive management team and the bench for each role.? So processes that *do* have scale continue to get process attention. And yet, the decisions made about each of these individuals involve subjective as well as objective data.
The complexity of current information technology leads consultants and analysts to propose that IT has to be rigidly managed as a business resource only and is ideally outsourced or ?cloudsourced?. This approach certainly kills inhouse innovation.
This reminds me of how some organizations react to complexity by enforcing rigid gateways between project approval, requirements, design, development, testing, and user acceptance... Instead of adopting an agile development approach.
I propose that if executives chose to manage by orthodox (BPM) process management, they chose to ignore the knowledge between the ears of the people that count ? their employees and customers!
Executives and management at all levels have to value the knowledge and experience of the people in their businesses - and use software to help them, rather than hinder them.? Thanks to Max for another really interesting read in the BPM/ACM/Adaptive Process discussion.