I read an interesting series of posts from Scott Francis of BP-3 and Max Puscher of ISIS discussing the business value behind BPM. Max’s post is from 2010, but it raised an interesting thought that I think is worth looking at. I won’t post the whole thing here, but the gist of the article is this:
We are…going backwards with BPM to Tayloristic management concepts.
What is wrong with the idea of BPM as implemented in many BPMS, is that huge amounts of time have to be spent to analyze process flowcharts that the people then have to adhere to…Only a small percentage of work (20%) might be that stable…
The most popular fad is now to buy drop-in process packages for BPMS to speed up implementation… Businesses often buy ERP because they are buying the hardcoded processes to improve the way their businesses work, lacking the skill to do it themselves. That is all the hardcoded processes a business can survive. Encoding more processes in BPM is not beneficial.
…the greatest of people WILL BE held back by the bureaucracy of methodology and by those hardcoded processes made for low-cost, unskilled, and simply replaceable staff.
The solution in Max’s post is:
Technology must allow processes to evolve to any structure they might need at any point in time without bureaucratic overhead. The focus must be not to cut cost, but to make the best people (knowledge workers) the most productive and effective. The most important knowledge workers of a business are at the top management level.
I think there are two things to think about here. First, does modeling a process restrict innovation? And second, should the focus of IT be on enabling top management to be more productive and effective?
Let’s talk about process modeling first. To start with, the solution you pick to model your process in makes a big difference. Having done my share of ERP implementations, I can tell you that if you’re trying to solve the same kind of problems with BPM that ERP addresses, you’re probably not doing it right. Done right, BPM and ERP solve two completely different challenges. ERP should focus on those processes that are non-differentiating, or things that for regulatory reasons have to be the same as your competitors. Examples include basic accounting and payroll functions. It’s not so much that customers of ERP lack the skill to implement these in BPM – it’s an economic decision to leverage something off the shelf. When ERP fails, it’s usually because it has been overly customized and expanded beyond these basic, non-differentiated business processes. You can also crash and burn when you try to turn BPM into an ERP or CRM system with massive prepackaged processes that take months to implement and millions to deploy. And in the process, you’re killing any chance of differentiation in that process. Large, complex, prepackaged BPM applications are like a 1976 Thunderbird – fast to get started, but don’t try to make a turn or it’s game over.
And does modeling a process inhibit innovation? I couldn’t disagree more. Done correctly, modeling a process is about quickly understanding something that was previously not collectively understood. This collective understanding doesn’t inhibit new ideas – it does the opposite. You may decide that it does not make sense to implement the process in a BPMS, but often you will discover ways to innovate by having the dialog. The trick is to engage all stakeholders (not just a few process experts) in a timely and cost-effective way. If it takes two months to model a process, you’re doing it wrong. BPM isn’t the answer to EVERY problem out there. But if it is a differentiating process, I’ve seen first-hand how it can have a positive impact for people.
Moving on to the second point, about how IT should focus on enabling top management. Again, I have to disagree. IT’s unbalanced focus on top management has been the problem! When you have employees purchasing their own iPads, using services like Yammer, gmail, etc and basically circumventing IT, what do you think that is saying? It probably isn’t a revolt against BPM. Furthermore, the economics of most packaged applications make it impossible for more than a few knowledge workers to have access to the systems that a typical company spends the majority of their IT budget to maintain. Even large-scale deployments of packaged apps usually only reach 20% of all employees. What about everybody else that participates in a business process? You’re on your own, or you use a point app that is disconnected from the overarching process. This is exactly the space that BPM can address. Because IT involvement is not mandatory for every change to a process, the incremental cost of BPM drops as you scale it out to more users. Making better information available to the people closest to the process is the key to agility. What good is knowing a shipment will be late if only the CEO knows about it? Isn’t that information more valuable to the warehouse manager?
Done wrong, BPM can be exactly what Max Puscher describes – a Tayloristic soul-sucking waste of everyone’s time. But you could say that about a lot of software products! After all, most software is about helping you to do your job better. If you botch it up, it will make your job harder, not easier. But done right – with broad participation, focusing on differentiating processes, and putting more power into the hands of people closest to the process – BPM can be a powerful tool for innovation.