In short: Buy-In. We are working with a large financial institution automating a number of their processes. Everytime we touch a new department or involve new staff they have to be treated as a new customer and the selling process begins all over again. Without the same level of Buy-In at each touch point there will be significant resistance to scaling the effort across the enterprise.
I agree with buy-in or even, "sticky buy-in" where the process-centric thinking sustains versus being filed away as the always new business pressures mount. The constant fire fighting in organizations; the doing more with less situation can really hinder adoption, CPI, etc.
my 2 cents
In my opinion, the biggest barrier to BPM scalibility is poor knowledge management.
Let me explain myself: knowledge management is all about taking advantage of the konwledge that already exists within an organization (and its processes) and using that knowledge to train new employees, make decisions and all sorts of actions that benefit the company.
That way we don't have to reinvent the wheel every time we want to do something. If we learn to use that knowledge and manage it properly, we can escalate. But if we don't use knowledge management, we won't know which processes are repetitive and hence best to automate.
Knowledge management allows us to produce more with the same resources, in less time and more efficiently. And don't forget that knowledge management requires of document management.
that was too easy, Peter! :-)
of course it's about buy-in when scaling within organizations, but .... (you knew this was coming) low buy-in is actually a symptom.
I could think of reasons that are actually drivers of a low buy-in:
1/ a BPM initiative that creates too much planning overhead - BPM steering committees, process maturity frameworks, project managment, consulting disclaimers etc --> this sends to the organization the signal of yet another expensive, passing, management fad;
2/ focus on the wrong first processes - either too heavy (prone to failure) or too easy (prone to irrelevance);
3/ too little attention to the entarch design - BPM is being done in isolation to the overall enterprise landscape;
4/ vendor lock-ins - the customer uses that tool because it was part of a larger licensing package, not because it's the right tool for the job;
5/ a solution that does not sufficiently involve the actual front people - the ones that are operating the solution first-hand.
I'm all out, but I'm sure there's more.
Barriers to BPM scaleability? For sure there are all good answers here, but I submit that the answer we need is one concerning BPM specifically.
Otherwise, we've just added to the mountain of literature on good project management, good project selling and good project governance. And we have nothing to take the bank specifically about BPM-as-a-unique-and-powerful-technology. (@Patrick and @Bogdan go in the direction of being BPM-specific.)
My answer in the first version of @Peter's BPM forum scaleability question was that BPM is a fundamentally different and powerful technology. And that BPM opens a door to a new way of focusing on business.
Specifically managers begin to see their role as being in the "process manufacturing business".
From this fresh managerial mindset then will come a demand for the technology products that are purpose-built for building processes.
And then scaleability is only a question of organizing.
Having a proper foundation (this word is borrowed from Gary), of course. Even with a strong buy-in a dog-house can’t be transformed into a nice apartment block.
See the 3th law of BPM in [ref1].
Could the mess of legacy tarnish the potential of scaling BPM across the organisation. The silo mentality could be a real barrier as scaling BPM can cross silos even challenge old style management. The BPM thinking breaks down business activity into relativity.small yet very focused areas of activity reflecting how people actually work together in relatively small groups. This creates the challenge to convince the business that the required connectivity is possible across the whole organisation. This approach to next generation enterprise software will require old "IT" to change until then therein lies the biggest barrier....?
I have to disagree with several of the responses, for a change, since complaining about the lack of ‘buy-in’ doesn’t answer the question. In fact, as Bogdan points out, an organisation might have good reasons to resist scaling BPM across the organisation. If the answer to Peter’s question is ‘because they don’t want it!’ then perhaps we should think about why not.
I believe the biggest barrier to scaling BPM across the organisation is that BPM as it is usually imagined, practiced and embodied in software products and IT systems is simply too heavyweight to be broadly relevant. Instead, only rare situations will provide a sufficient return on the huge investment that is usually required to implement any kind of BPM.
The way forward is to recognise that there are, say,Four kinds of business process software. To scale across the organisation, we have to be able to scale solutions down to be useful for smaller lower-budget problems, as well as mega-projects and consultant armies that implement traditional BPM. Otherwise, trying to get widespread BPM adoption in an organisation remains as wrong headed as trying to replace every little spreadsheet in the organisation with a relational database would be. (AndThere’s more than one kind of database.)
Scaling BPM across and down obviously isn’t principally about software tools, though. A more important challenge for the BPM community (even if it is fifteen years late), is to move on from old-fashioned and discredited waterfall IT project delivery approaches. We need some kind of agile BPM. I therefore would love to see a question about that on this forum:
How can BPM apply and benefit from the principles of theManifesto for Agile Software Development?
I like Neil Ward-Dutton's thought on the matter. He said basically this: there are about 15% of organization that have an appetit to change in their DNA. And they are yours (addressing to BPM vendors and consultants). But the rest 85% won't buy it whatever you do.
I'm afraid Neil is right. I've seen too many times the dream that successful BPM project would lead to another larger project until the whole organization would fit into the BPM scope didn't come true.
What can be done about it?
Several things, if talking statistically:
- Digital disruption changes the percentage above to more favourable.
- We (the BPM industry) must make another breakthrough. BPM makes process change 10 times easier comparing to ERP but it's not enough for the majority. We must make another qualitative leap in terms of ease of use and implementation speed. BPM+ACM blend, social+gamification, perfect mobile UX, subscription+IDE in a browser - we are moving in all these directions but we aren't there yet.
- BPM consultants and implementation partners should realize that BPM is more a social endeavor than technological. Some BPM professionals today position themselves as change management specialist first and foremost and I believe it makes a lot of sense.
Yet within a given organization, little can be done if you hit the cultural barrier. Because as someone rightfully said, "culture is a read-only attribute".
Many good thoughts here, but to add an orthogonal idea: user interface. Process implementers seem to spend far too little time on their e-forms and other UI elements (see my blog post, "Your Users Hate Your E-Forms"). If the UI is subpar, adoption will suffer. If adoption is poor, expansion is unlikely and scalability is, well, moot.