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)
- Case management
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).