Uncovering the True Differentiation in #BPM Products
- February 8, 2012
- 0 Comments
Neil Ward-Dutton of MWD Advisors is attempting to uncover for their customers the true differentation between BPM vendors. This isn’t easy – partly because they can all hide behind a common modeling paradigm (BPMN, among others), and an expert in any one of them might be able to build a solution to a given business process problem.
But to actually deliver on the promise of re-use, agility, and scale, if the BPMS doesn’t support your efforts organizationally you will run into roadblocks that have consequences… We’ll get to those in a moment… Here’s Neil’s take:
Most of what I’ve heard in discussion around this point focuses primarily on implications for the time to deliver projects: in other words, don’t think that once you’ve created a BPM and model your even close to finished application for real-world deployment. However there is a bigger issue at stake here, which is: exactly what kind of provision a given BPM technology platform makes for the specification of those items in the list above – and specifically, to what degree you’re encouraged to design and (when necessary) code these items so that each kind of concern is kept separate from all the others.
The quality of this “separation of concerns” in design might not make a huge amount of difference when you first start in implementation, but it can become incredibly important over time. And support for it turns out to be one of the most important (to my mind) differentiating points between BPM technology platforms.
Neil has hit it exactly. The separation of concerns seems like quibbling between different philosophical approaches at first – but it is more important than that. But when the separation of concerns is poor, or when the support for agility is poor, what are the consequences?
- The level of product and technical expertise you need to maintain your solutions goes up. You can’t easily integrate people who are new to BPM to your project, and even when you do they have to be incredibly skilled computer scientists.
- The level of specific knowledge required of your business (and your technical hacks) is too high to easily bring new people into the project. Anything they touch may have unintended consequences – sometimes far reaching and affecting more than just the process they intended to affect.
- Fear of change. If a small change can have broad negative consequences or unintended side-effects outside of the process we’re editing, we will fear changing it. We lose agility. We might abandon a common implementation in exchange for process-specific implementations – and therefore losing the benefits to efficiency that re-use provide.
- Testing overhead. If a small change in one process or process area can affect a broad array of other processes, the testing overhead is quite high. Essentially I have to re-test everything.
But these are just the tactical problems. The real problem is that your BPM team won’t achieve the business outcomes you’re looking for – the I in ROI will be more expensive, the time to market slower, and the R lower. It can wipe out much of the promise of BPM in the first place.
You can see some of this differentiation when you hear pundits and gurus talk about how “rigid” BPMS’ are – this says more about the BPMS they’ve been using than it does about the notion of a BPMS. Meanwhile, some of us are pretty happy with how flexible our BPMS is… draw your own conclusions.
Neil’s next point:
Of course, because almost all BPM technology platforms centre implementation work around a graphical process model there is always likely to be a clean separation between definition of process and all of the other important design elements I’ve listed. But whereas some platforms provide a rich, well structured asset repository and clean design tools that implement the principle of “a place for everything, and everything in its place”, other platforms really provide quite weak facilities of this kind. With this latter group of platforms, it’s still theoretically possible to create process applications that are relatively easy to maintain; but designers and developers are going to be pushing against the tools available rather than working with them.
Reading this, it reminds me how much hue and cry there was over a certain company with a BPM product, buying an upstart company with an allegedly overlapping BPM product…. There was real differentiation in the process repository and in the basic architecture of the design environment. But it was the kind of differentiation that customers and analysts would often miss – because the value isn’t as apparent in iteration 1 of project 1 (although it is apparent if you do them side by side). It becomes much more apparent in iterations 3 and 4, projects 5 and 6. If you’ve owned a BPM product for more than a year and you’re still looking at getting process #1 deployed, I’d recommend two things:
- See about getting some professional help from a boutique consultancy focused on project success. If you’re already working with one, consider a new one.
- If that doesn’t get you on the path to more productivity and better use of your product, consider a different BPM platform. You might have picked the wrong one.
Meanwhile, keep an eye on MWD’s research and their attempts to delve into the real differentiation between BPM vendors, and don’t just get caught up in the bright shiny features they’ll parade in front of us.