Six Barriers to BPM Adoption in the Enterprise
- October 7, 2008
- 10 Comments
Round Table sessions at the conference didn’t go as expected due to the turnout. At our new, combined table, we discarded the prescribed topics and chose our own: talking about the barriers to successful BPM adoption. Our table, by chance, was comprised entirely of vendors and consultants (a vendor fest).
In no particular order:
- The Sophomore Effect. Most companies are successful with their first BPM project. They tend to focus on something fairly attainable and have good alignment and staffing for the first project. They get an unmitigated success, but as soon as it goes live, the team that was supposed to get all the learning about BPM and form the core of a Center of Excellence is reassigned to everyday work within the organization. That might be back to their business units or to other applications or support functions in IT. As a result, when the second BPM project comes along, the staff has to be re-incarnated. Often the actors are all new, or mostly new, and you don’t get the benefit of expertise gleaned from the first project.
- The Bowflex Coat Rack Effect. BPM is not a pill. Its exercise. But companies are always looking for the quick fix. If you want to be successful with BPM, you have to work at it, you have to have discipline, to really reap the rewards over time. After all the biggest ROI %’s don’t come from the 1.0 release of each process, but from the point-releases – the 1.1 and 1.2 releases for example, or the 2.0 release.
- The Used-Car Effect (or, my preference: The Little Red Wagon Effect). Often a company can’t come up with the budget to buy new software (Capex) but they have maintenance dollars that can be appropriated for other purposes. This can end up being more expensive in the long-run, but in the short term it lets the company get going at a lower price entry point. The used car analogy is that you keep investing in keeping the used car running rather than buying a new one. The little red wagon analogy is simply the “if it ain’t broke don’t fix it” theory.
- The Bus Brake Effect. In many companies, the BPM project can be halted by almost anyone that is involved in the project. We called this the Bus Brake Effect because everyone on a city bus can be stopped by each person pulling the brake cable at each interesection. Making progress quickly depends on everyone on the bus withholding their right to pull the cable. In the BPM world, this means convincing all the different parties to participate – the Compliance group, Governance, Security, Integration teams, the Line Manager in the Business, the Champion, and other Business stakeholders. Its quite a list of people that can raise exceptions to your deployment progress, or essentially veto progress if they don’t agree to staff their responsibilities to your process.
- The Sharepoint Effect. This is almost the opposite of the Bus Brake Effect. Where the bus brake effect concerns too many vetos and not enough yes-votes, the Sharepoint Effect represents the unbridled proliferation of ungoverned, adhoc processes using unmanageable technology. Sharepoint becomes a substitute for process, or a substitute for the Excel-based or Access-based processes of the past. However, there’s no way to find the appropriate Sharepoint site for the appropriate process or process task. The general consensus was that Sharepoint does more harm than good. UPDATE: Now the real worry in many big IT groups is that BPM will be another Sharepoint – leading to unrestrained anarchy of adoption by business users. See below for solutions, but I don’t believe this is the danger that IT departments worry it will be, because of the nature of BPM installations and deployments.
- The AA Effect. Ok this wasn’t part of our Round Table but probably should have been. For BPM adoption, the first step is to admit you have a process problem (in some circles, we call these “problems” opportunities). If you can’t do that, then you’re not receptive to really making the changes your business needs.
Ok, so we’ve listed the effects that act as barriers or resistance to BPM adoption. What can we do about them?
- The Sophomore Effect and the Bowflex effect really require similar treatment to avoid. Preventative measures are key. Education helps managers avoid this, but more importantly, plan for more work than the first roll-out, and staff that additional work with the same team, BEFORE the rollout. By having the staffing plan extend to work for a 1.1 release, or extend to work on the next process immediately following, the time for people to “return to the day-to-day busines” is reduced. The temptation is reduced as well. And the longer these people are focused on process improvement, the less likely they are to be re-allocated. The third tactic pays off in the long run, but is not preventative – and that is to make sure you measure the process, so that you have real measurable results to communicate to the executive team and justify getting your crack team together to deliver additional results.
- See above.
- The Used Car Effect – the coping mechanism here is, if you can’t beat them, join them. Sell software in ways that these corporations are prepared to buy – as a subscription, for example, or SaaS. It may be more expensive for the customers in the long run to rent rather than buy, but in the short term they have predictable, smaller, expenses, and it becomes an ongoing budget item to plan for. I think this is a tough one to fight head on with a customer. If they have a certain way of funding projects, usually the best bet is to play ball with their predilections.
- The bus brake effect – the best advice we have here is to “paint the matrix green”. Which is a fancy way of saying, make a matrix of all the people you need to support your project or contribute to your project, and then make sure you get each of them to truly agree to do so. You have to watch out for those who say yes, but do “no”. But fundamentally you have to build consensus in your process/project. Still, this is a tough one to conquer. Lots of moving parts are required to make BPM projects a success, so I feel it is particularly susceptible to this kind of failure.
- The Sharepoint Effect requires the company to take control of its own destiny – vendors can’t do this for them. One of the better ideas was to have governance around creating Sharepoint portals – that you can set one up if you implement and stand up a real process associated with that portal. But with respect to BPM, IT can manage the assets that run the processes, and the process for putting those assets into production, and still give the business the flexibility and room to breathe to create the right kind of process assets to be promoted…
- The AA Effect. Well, since this is just my own personal addition to the list, I’ll just tackle this one with my own opinion. If you don’t believe you have a process problem, or you don’t believe there is much room for improvement (a gentler way of saying the same thing – because implicitly if you think you don’t have any problems, that you also have no opportunities to improve!), try doing a kaizen event, or a business process discovery session. Establish measures for your process and see if you still feel that there aren’t opportunities for improvement. The good news is, figuring out whether or not you have a process opportunity/problem does not require buying a lot of software and making a big infrastructure investment – it just requires bringing in an expert or consultant for a short period of time to do some discovery and size the opportunities for you…
Now, the real story is this. All of the solutions just require one thing from an organization and its vendors: Leadership. I don’t mean, necessarily, upper management or “champion” when I say leadership. I just mean leadership in its most basic form. Someone on your team, or someone outside your team, will have to lead, to create consensus, to see these effects before they fully stop your progress and plan the path around them or through them. Not to mention, you need an aspirational view of what you can achieve in your organization with business process improvement – and that, too, requires leadership.