It seems in the world of BPM that we end up with something cool and new every so often, or some major software update/release on a regular basis and yet - despite the best efforts of many people - I don't think anyone has solved the undying problem of getting BPM into the organisation at the right levelI've talked in the past about BPM by stealth, where I have implemented BPM at a low level in the organisation as a means of seeding the capability in the business. This can then lead to growth at a larger level. The downside to doing that is that we end up with BPM being implemented in several smaller “bottom-up” implementations. These are better than nothing, but can lead to silo mentality in the organisation. Ideally we would enter the business at the top level of Management and get buy-in and sign-off at the board level to implement across the organisation. Obviously this is a major nut to crack when trying to put forward the Tao of BPM, but I believe it is one thing that is absolutely vital to happen
The problem is that the benefits of BPM at this level are not always obvious. The work involved in documenting and managing a whole enterprises process is huge. It is, without doubt though, the best approach to take. This can be either with an outside-in approach or an inside-out approach (and the merits of each of these are discussed endlessly across the BPM world). But holistically the benefit to the organisation has to come from integrating and managing the whole of the business, not just small silos.
The problem is that the huge amount of work involved in doing this is something that the top level of management will often baulk at approving. Because, despite the amount of work and effort that we in the BPM community have put in to promoting the benefits of our product, there is still an approach held by many vendors that implementing the software solution is the aim of BPM. This means that the focus is on the nuts-and-bolts of BPM/BPMS systems rather than the holistic approach of ensuring the best thing is being done for the business.
And I can understand why. When the CIO looks to the project manager to see how the project is progressing he’s going to want to see metrics reflecting the successful implementation of licences or affiliates/sites to a particular software tool. After all, nobody ever got promoted from project manager because the project they had for implementing an ERP system successfully reviewed how six affiliates could improve their cash-flow. They got promoted because they actually improved the cash-flow and implemented something to make sure this happened (usually a piece of software).
The same thing happens in BPM. Projects are deemed to be successful not because somebody was able to improve a process (even though that is the end result of the work), but because a piece of software was implemented and the users are using it.
I worked for an American multi-national organisation for some years and they replaced their ERP system with a competitors tool. The competitors tool was no better than the one they had in places already (in fact in some respects it was worse). After several years of work the global organisation had created ancillary processes and work abounds to deal with the fact that the required software didn't work. Overall the project was a waste of a large amount of money and the benefits were never going to be materialised. BUT, the software had been implemented successfully across the globe and the project was deemed a success. We can argue for days about the relative merits of different pieces of software and whether the project should have been approved at all, but this doesn't change the fact that the negative aspects of the implementation (frustration, need for work around, user dissatisfaction etc) we're outweighed at the senior management level by the fact that software had been successfully implemented. This was despite the fact that the company was (allegedly) spending over $100,000 per week on external consultants to do this.
I was in meetings recently with a software vendor and we were discussing the barriers that they were hitting when trying to get their software into various businesses. It fell very neatly into the points that I have raised here in this post, namely: We want to get in at the top but were being forced in at the bottom level
So how do we get the business to understand that BPM as a capability is an enterprise-wide requirement rather than a project specific need? How do we get the CIO to sign-off on implementing BPM across the organisation rather than approving just a project to implement software?
It's the million dollar question (quite literally).
Here's my solution: We don't.
This is like the old eastern saying “How do you eat an elephant? One piece at a time”. We can't go around trying to push the CIO’s into doing what we want, anymore than they can push their boards into doing what they want. There is always a cost/benefit that needs to come with projects like these. This is the reason the software implementations are always looked at from a deliverables point of view. Tangibles are the thing that the CIO will be looking at. A process is not a tangible thing that an be seen and held for inspection (although some would say that a process diagram is a tangible, and I accept that).
The simple fact of the matter is that I don't think the software vendors are doing a good enough job of selling BPM as a concept to C-level management. They seem to think that showing an expense claim process with the appropriate approvals and routing will convince a CxO to spend a fortune on putting such a thing into their organisation. It won't. What the vendors and the consultants - and I include myself in that group - need to do is to position the capability of BPM as a prerequisite to implementing a tool or solution. They need to be able to enumerate the tangible benefits to having a good BPM capability in an organisation, and they need to be able to show good case studies about where this has happened and what the benefits were. A good case study is not a vendor-provided example of where their software has caused a company to become mildly excited about the potential. A good case study is independent, non-vendor specific, and covers more than just the software solution.
Only then will we be able to go to the CIO (Or any other member of the board) and show them why they need to be looking seriously at BPM.
Or am I completely off-base?
Reminder: 'The Perfect Process Project Second Edition' is now available. Don't miss the chance to get this valuable insight into how to make business processes work for you. Click this link and follow the instructions to get this book.
All information is Copyright (C) G Comerford
See related info below
