Skip to Content

Real BPMS selection criteria

The selection and implementation of a BPMS platform within an organization is dependent on a clear and limited set of criteria which must be addressed. These are:

  1. The Business Requirements and identified Use Cases for BPMS functionality for the next 2-3 years
  2. The current Maturity level in BPM concepts within the organization
  3. The current technology status and maturity and available IT platforms within the organization
  4. Costs associated with investing and running the BPMS platform in the existing context
  5. The known and validated vendor product roadmaps and embedded BPMS capabilities in available products and platforms
  6. The availability of people with BPM(S) skills and BPM(S) competence development

Based on an evaluation of potential BPMS investments against this set of criteria a balanced decision on the way forward in any given situation can be made.

In this blog the first three criteria sets will be discussed. In the final blog in this series I will discuss criteria sets 4-6 and will come to some conclusions.

Business Requirements and Use cases for BPMS functionality for the next 2-3 years

If used in the right way, the main benefits the use of a BPMS delivers are the following:

  • Processes will run faster, with a significant percentage going straight through without human intervention
  • Processes will have a higher delivered quality (fewer errors)
  • Process status will be more transparent and visible
  • User interaction with a process will be a lot simpler and will only happen when really required
  • Process execution will be highly agile and flexible and not based on any fixed transactional flow

In different types of processes these benefits will apply to different degrees.

BPM expert Bruce Silver (see ) distinguishes between 4 process types:

  • Task Routing (basic workflow),
  • Production Workflow (such as Accounts Payable),
  • Case Management (emphasizes content, collaboration, and unstructured processes),
  • Integration-Centric processes (such as order to cash).

In an SAP-centric environment you will typically find all of these process types, but the SAP footprint will be heaviest in the process types Production Workflow and Integration-centric Processes. These processes are typified by high volumes and a need for speed and efficiency. In many cases the standard SAP transactional flow of the end to end process will be “broken”.  ERP processes are generally managed by process (step) statuses and document flows. For each step in the process there are operational reports and lists that show the work in progress and determine next steps. The routing of these steps is mostly done through authorizations and job roles. You could say that any participant in a process will see their part of the process and will receive their tasks as thrown over the wall. The first time they will see them is when they appear in the operational list or transaction screen in SAP. The structure of the end to end process is implicit in the ERP system. The user has to “discover” their part in the process by paying close attention to their operational reports and transactions.

If we look at the potential role of BPMS in the different process types the benefits are clear: 

Benefit type

Task Routing

Production Workflow

Case Management

Integration Centric

Processes will run faster, with a significant percentage going straight through without human intervention





Processes will have a higher delivered quality (fewer errors)





Process status will be more transparent and visible





User interaction with a process will be a lot simpler and will only happen when really required





Process execution will be highly agile and flexible and not based on any fixed transactional flow





Table 1: Benefit types mapped to Process types


In the table above it is stated that the integration centric workflows, so typical for ERP, can benefit substantially from the use of a BPMS.

Traditionally most implementations of BPMS have focused on the other types of BPM process types. Apparently when looking at potential use cases for BPMS the focus has been more on human workflow-oriented and case management process types.

To ensure that the right business use cases are identified it is necessary to analyze also the Integration Centric process types, so to look into the end to end process chains like  Order-To-Cash, Procure-To-Pay and Record-To-Report.

A good way to do this is by applying methods like Process Discovery to existing process chains and to identify those process improvements that are relatively easy to implement yet add the most value (see figure 2 below)



Figure 2 Process Discovery to establish value


Of course the other process types also should be taken into account, especially because if the apparent value case for BPMS is more about case management than anything else a different BPMS technology choice is probably on the cards as when Integration Centric processes are dominant. 

So before any BPMS package selection is undertaken, there should be at least a high level overview of  business use cases of the four defined process types as well as an idea about the relative importance of each process type for the organization.

 The current Maturity level in BPM concepts within the organization

 The choice for an “Enterprise BPMS” seems like a logical thing: choose and invest in one platform  that will cover all requirements. Typically investments of this kind are made to serve the business for a number of years. This means that if you invest in such a platform too early, when the business still has no good use cases identified, you will spend a lot of money for nothing. On the other hand, if you wait until there is sufficient demand, you will lag behind competitors and lose money that way. So there must be a “sweet spot” to be identified when the choice for an enterprise solution is just right.

Geoffrey Moore (Crossing the Chasm, 2002) has shown that for innovations to really spread, a chasm of acceptance has to be crossed. After a new technology is introduced, it will take a number of clearly visible successes to enable a new technology to take off. This applies to both the industry in general and individual organizations. Buy in for using a new technology will only become substantial after some demonstrable early successes have been realized.

Because of this it is much more important to show early results in practice than to focus initially on which enterprise platform should be chosen. In reality, any platform will do as long as the results are there. Only after the organization has achieved a certain level of experience and maturity in BPM should a final decision on an enterprise BPMS be made.

The “sweet spot” in maturity for choosing an enterprise BPMS is defined by the following criteria:

  • There is an established practice of top down harmonized Business Processes, with identified process owners in the business
  • There is a BPM center of excellence or at least an identified group in the organization that have the responsibility to implement and manage process improvements
  • The IT enterprise architecture is based on post-SOA concepts with a clearly identified role for a separate orchestration layer and a separate Presentation layer
  • The enterprise applications supporting the core processes are web based and SOA-enabled

If these elements are not in place, BPMS should be handled as a tactical concern and this then leads to use of possibly multiple technologies in separate use cases. For instance, projects could be undertaken leveraging SAP BPMS for specific SAP-based integration-centric processes, or a Microsoft SharePoint add-on solution could be used for certain task-based workflow processes, or a WebMethods solution for production workflow in combination with several different back ends.

Usually good licensing deals can be made for these early “pilot” like BPMS implementations. It is not required nor is it advised to make a final choice for an enterprise BPMS before the right maturity level in BPM is reached.

These early pilots using “any technology” should however always be managed in terms of a holistic BPMS roadmap. They should be used to show the value, in terms of Geoffrey Moore, to fulfill the role of “Bowling Alley” where highly visible projects return great business value so that the general value of BPMS is acknowledged in the organization.

Given the current early phase of BPM maturity most business cases for BPMS are in the tactical area, with a specific focus on Simplification scenarios for the user. These requirements generally do not ask for advanced BPMS functionalities (such as simulation), but make use of basic BPMS functionalities such as UI simplification and automating decisions and process steps by business rules and back end integration across applications.

To report this post you need to login first.

Be the first to leave a comment

You must be Logged on to comment or reply to a post.

Leave a Reply