Organizations are increasingly seeing the benefits of implementing an enterprise BPM execution platform to create agility, streamline end to end business processes and address specific pain points in current processes. Even though adding a BPMS increases the IT landscape complexity the associated benefits in efficiency and effectiveness are potentially far bigger.
In many companies with a heavy SAP systems footprint there is currently discussion about the selection and implementation of an enterprise BPM platform. This article explores some of the things that should be considered when deciding on an Enterprise BPMS platform in an SAP-centric environment.
Business Process Management as a discipline should of course always be driven from the business perspective. In terms of choosing a BPM Suite software platform, however, the focus is in many cases on the IT side. Platform selection focuses primarily on IT oriented features and functions of the platform. Too often questions about the Why of the platform are left unanswered.
This short series of blogs explores how to approach a BPMS platform selection process in an SAP-centric environment, and identifies potential pitfalls and risks.
A repeating pattern
Back in the early 2000s a lot of companies selected and implemented Enterprise Application Integration (EAI) tools. In many cases these companies chose a “pure play” EAI platform even when they had “wall to wall” business applications from the same vendor (SAP, Oracle) and this vendor also had integration tools available.
The arguments used in these situations were usually about better functionality and technical superiority.
In the early adoption period the EAI tools were mainly used for developing and managing interfaces between applications. Later they morphed into Enterprise Service Buses and started to manage SOA services and repositories. Because SAP was late to the market with EAI and Service Bus many SAP customers chose a then “pure play” product from vendors like BEA, WebMethods or Tibco. Also in environments where SAP is not the core application suite non SAP solutions were implemented.
Today we see the same pattern emerging in the BPMS selection process in the “enabling IT platform” case. Companies establish a set of functional and technical criteria and then score the competing platforms on these criteria. The context of the evaluation is the quality of the products themselves.
This is typical of the early adoption phase of a technology. If the BPMS product type would be fully mature today, contextual criteria would become much more important. Functional and technical capabilities would be commodities, like ESB technologies (almost) are today. Decisions would be taken based on real BPM requirements, in business use case and enterprise architecture categories.
As it stands now, solution platform selection more often than not results in architectural alignment issues, roadblocks to efficient and smooth BPM implementation, and higher overall costs than would be incurred if and when a holistic and roadmap-based approach would be taken.
The following blogs will cover these subjects:
In the second blog I will cover the characteristics and capabilities of BPMS systems, presented in context of the overall IT architecture as represented in the industry standard CORA model (www.coramodel.com).
In a third and fourth blog I will cover the set of real selection criteria that should be part of any serious BPMS platform choice process.
