BPMS Usage Patterns

I’ve been catching up on the replays of some webinars, and today went through BPM Institute’s one on BPMS usage patterns (free, but registration required), featuring Dr. Ketabchi of Savvion.

Dr. K started with a short definition of BPM, including the business value, then a bit about Savvion and their products; you can skip through to the 24-minute point on the replay if you’re already up to speed on this.

He describes seven key BPMS usage patterns:

  • Human-centric (which may be long-running)
  • Document-centric
  • System-centric
  • Decision-centric
  • Case management
  • Project-centric
  • Event-centric

Although all of the vendors and analysts have their own spin on this, looking at usage patterns when selecting a BPMS is important to ensure that you end up with a system that can support most or all of your usage patterns.

The first three of these (human, document and system) are very well understood, but the others require a bit more explanation

Case management, on the other hand, requires extensive analytics about the cases to be handled as well as a fairly comprehensive interface for agents to use when handling the case, and potentially handling the customer simultaneously. This is not just about a transaction being processed through a BPMS, but potentially a set of interacting transactions and ad hoc collaboration, as well as documents and other data or content. There’s been a lot written on case management BPM lately, including a new OMG RFP for case management; this has become strangely high-profile lately.

Decision-centric BPM is heavily based on rules, either based on data or events, where complex decisions need to be evaluated either for automated processing or to present to a user for further decision-making or work. In the past couple of years, we’ve increasingly seen the integration of business rules with BPMS, with some BPMS vendors including full business rules capabilities directly in their product, while others integrate with one or more of the mainstream BRMS platforms.

Project-centric BPM is a view that’s a bit unique to Savvion, a crossover between project/portfolio management and BPMS that includes resource optimization across processes, milestones definition and other project management-like techniques within the context of a process. Think of these as long-running processes that the process owners think of as projects, not processes, but where these projects always follow a pre-defined template. Mapping the GANTT chart to a process map isn’t that big of a step once you think of the projects as processes, and can provide an alternative view for monitoring the progress of the project/process.

Event-centric BPM is usually focused on improvement of existing business processes: taking various sources of events, including processes, then analyzing them to pinpoint bottlenecks and present the results to a user in a monitoring dashboard. This is the monitoring and optimization part of the model-execute-monitor-optimize cycle of BPM.

I’m not sure that I agree that decision-centric and event-centric are unique BPMS usage patterns: I see decisioning as part of the normal operation within most processes, particularly system-centric processes; event-centricity seems to be the monitoring and feedback end of any other type of process as well. In other words, these two aren’t really usage patterns, they’re functionality that is likely required in the context of one of the other usage patterns. Although Forrester split out human-centric and document-centric as two unique patterns a couple of years ago, I would argue that document-centric is just a subset of human-centric (since realistically, you’re not going to be doing a lot of document processing without people involved) rather than its own unique pattern. Similarly, project-centric processes are a type of long-running human-centric processes, and may not represent a unique usage pattern, although I like the visualization of the process in a project-like GANTT chart view.

Not every company has every usage pattern, or doesn’t consider every usage pattern to be mission-critical, but it’s important to keep in mind that although you start with one or two usage patterns, it would be hugely beneficial to be able to expand to other usage patterns on the same BPMS platform. A lot of companies that I’ve seen focus on just a human-centric (or even worse, a more limited document-centric) solution for a specific workflow-type application, or a system-centric service orchestration solution for their straight-through processing; inevitably, they end up regretting this decision down the road when they want to do other types of BPM, and have to either buy another BPMS solution to address those needs, or try to bash their current solution (with a ton of customization) into a usage pattern for which it was never intended.

Some interesting thoughts in this webinar about usage patterns. As the BPM suites (mostly formerly the “pure plays”) battle against the stack vendors, the issue of which usage patterns are covered by which product is coming to the fore.

Disclosure: Savvion is a customer for whom I have created podcasts and performed strategic analysis, although I was not compensated in any way for writing this webinar review (or, in fact, anything else in this blog).

3 thoughts on “BPMS Usage Patterns

  1. Sandy, thanks for this review. I tend to agree that event- and decision-centric should be considered functionality rather than entirely separate usage-types. If anything, I would say that the analysis part of event-centric can be used to optimize a human-centric process by including automated decisions into that process, i.e. business rules automation as part of the process.

    Regarding Case Management and the interest of late, I personally believe that part of the increased interest is that companies are becoming more sophisticated as they implement BPM, and that is leading them to realize the limitations of a rigid model-driven approach. Structure is good, necessary and valuable, but only when it doesn’t impinge on the ability to effectively get the work done. Case Management seems to address some of the flexibility limitations in most BPMS by adding the ability to handle the “on the fly” behaviors that are necessary in many real-world processes.

    I’d also say that this same sophistication on the part of the companies implementing BPM solutions is part of why we’re hearing more about Dynamic and Unstructured BPM as well.

  2. What’s now being labelled “case management” likely grows out of the older “collaborative BPM” category. Lots of activity in that space now.

    More BPMS vendors are trying to cover more of these usages patterns in order to stay relevant for their customers (or at least stay on Gartner’s MQ), and customers need to start rejecting the vendors that provide only a single type of BPM functionality. Too often, the first BPMS vendor into a large organization becomes some sort of corporate standard, and if it can’t do a decent job of all of the types, then there are some pretty disastrous projects.

Leave a Reply