Skip to Content

The current technology status and maturity and available IT platforms within the organization

As already mentioned in the previous paragraph current maturity determines whether an enterprise BPMS selection is on the cards. This also applies to the technology maturity and the currently available IT platforms. There is no major vendor of ERP, ESB or Document management that does not offer a BPMS in its full platform. In many cases the platform itself is managed as a “business process platform” and there a BPMS is simply one of the required components. This means that in all probability there will be several different candidate BPMS solutions available to a company based on current licensed platforms alone. It then makes sense to start in the early phases of BPMS usage to focus on these available platform solutions and not to confuse and complicate matters by casting a wider net and starting RFP processes. In general the advice is to start using the available BPMS solutions based on the concrete use cases identified with the technology already in place or licensed or potentially available. The vendors with which the organization has licensed software platforms will be willing to provide very easy and low threshold licensing models for these early projects so that a business case can be made for tactical “bowling alley” implementations of BPMS. Care should be taken to communicate clearly to all parties involved that the platform choice is not final and that the role played is that of a “pilot” implementation.

One characteristic of the BPMS technology used in this way is that it will communicate natively with the associated overall platform. For example, use of NetWeaver BPM in combination with a NetWeaver based SAP platform landscape will make it easy to integrate and use familiar technologies such as ABAP Web Dynpro and SAP Portal, Universal Worklist and the PI Enterprise Services Repository. This will ensure that the use of new technology and lack of experience and knowledge will not hamper implementation of these first BPMS projects. In the same line of thinking, deploying a .Net based Microsoft SharePoint add-on BPMS for scenarios close to the SharePoint environment will make it easier for developers in that area to align the BPMS platform with the overall Microsoft architecture in place in the organization.

Key message is that it is not a bad thing to use different technologies in this phase. It is part of gaining experience, projects are tactical by nature and should cover their own business case. There is as yet no need for an enterprise investment in BPMS in this phase. Doing these projects will help though in establishing the roadmap and laying the ground work for enabling a good choice later on when BPM is an established business priority.  

Costs associated with investing and running the BPMS platform in the existing context

Some BPMS platforms are very expensive, while others are very cheap. The costs in licensing vary wildly. Some BPMS platforms are primarily sold as vertical industry process solutions, where the business solution is what the customer buys, and the underlying BPMS is just the technology used. These solutions are usually priced completely different from open source BPMS or the BPMS solution belonging to an ERP vendor platform. 

As already stated when deploying a BPMS in early tactical projects the licensing costs will not be prohibitive. All platform vendors want to be chosen as enterprise BPMS for large companies so they will offer excellent deals that make it possible to achieve a positive business case even for relatively small projects.

This does not mean that the longer term costs should not be taken into consideration. For a vendor like SAP, the revenue coming from NetWeaver BPM will always be a marginal affair. Enterprise customers will have enterprise deals, and using Composition Environment / NetWeaver BPM will just be a small part of total licensing and maintenance to be paid to SAP. The pricing for SAP NetWeaver BPM is based on a per CPU basis. You can deploy high volume processes on NetWeaver BPM with just one or two CPU’s, meaning that licensing costs will be very limited.

For “pure play” BPMS and BPMS coming from the ESB vendors this is different. Their pricing models depend totally on the integration and orchestration capabilities they provide with their platform. This results in significantly higher total cost of ownership for these “pure play” BPMS platforms, when compared to using NetWeaver BPMS. 

The known and validated vendor product roadmaps and embedded BPMS capabilities in available products and platforms

The capabilities for BPMS are still developing in each platform and toolset. Every vendor’s BPMS has different sets of capabilities and different speed of development. When looking at a selection method and process for an enterprise BPMS it is crucial to look at each vendor’s product roadmap and strategic positioning of BPMS. A company with an SAP-centric IT landscape should be aware of the SAP roadmap for BPMS which is based on close integration between the Business Suite application functionality and what SAP calls “Orchestration”.  In SAP’s view of Orchestration it is not only a process orchestration tool, but also the glue that holds together the different delivery channels of SAP functionality: On Premise, On Demand, On Device, guarding consistency, integration and manageability.

To achieve this, the roadmap points towards the realization of a Business Process Library which is supported by implemented scenarios across the different delivery channels. Modeling of these scenarios is then centralized using the Business Process Library, as shown in the picture below, taken from the recent TechEd presentation PMC101.

 

Figure 3 PMC101 overview of Process Modeling

This view unifies the different modeling styles, roles and responsibilities in a comprehensive BPM architecture. From free format Collaboration and initial process design to formal executable process modeling, documentation and deployment, to process execution and runtime monitoring all is unified in one concept.

So if you have a substantial SAP platform footprint, with the Business Suite as the basis of your core process automation, this roadmap view from SAP should be taken into serious consideration when deciding on an enterprise BPMS. In the next few years, according to the SAP roadmap for BPM and the Business Suite, the orchestration layer will become ever more important and the overall delivered process scenarios will increasingly build on this hybrid model of On Premise, On Demand and On Device, facilitated and aligned by the Orchestration layer which consists of NetWeaver CE, and the Business Process Library with Solution Manager underneath to keep it all together.

The announced closer integration of NetWeaver BPM and PI is also a significant step in this direction.  

It is crucial to understand that a simplistic platform selection process focusing on current platform capabilities which does not take the SAP Roadmap for Orchestration into account will be flawed. This even applies if for some reason SAP abandons the current technologies and acquires a third party toolset to fulfill the orchestration role. Even then the overall concept of Orchestration using a Business Process Library will be paramount to SAP’s product architecture. 

The availability of people with BPM(S) skills and BPM(S) competence development

To implement BPMS in the right way, you need the right people with the right skills. Therefore, the selection of a BPMS platform should also take into account what the technology skills and experience is that the organization has available. This applies not only to the design and implementation, but equally to the managed operations side of BPMS. Introducing new platforms without any associated internal expertise will result in bad performance and high managed operations costs. The availability in the market of experienced consultants and consultancy organizations with a firm commitment to the technology platform, i.e. a high quality ecosystem, is a critical success factor.

Certainly in the pilot-phase tactical implementations of Moore’s “Bowling Alley” the choice should be for a BPMS platform which has good support from the ecosystem. Bad quality implementations will result in loss of buy in and lost momentum for BPMS success.  

Conclusions

This article has investigated a number of criteria for selection of an Enterprise BPMS for organizations with a heavy SAP footprint. It has argued that first of all a final selection of an enterprise BPMS should not be undertaken before a number of tactical projects have delivered demonstrable business value (Moore’s “Bowling Alley”). In fact it will be beneficial if multiple technologies are “tested” in actual processes. Special licensing deals with vendors will make the business case for this approach easier.

In an SAP-centric environment there are a number of arguments for at least implementing the SAP NetWeaver BPMS in early tactical projects:

  • Most organizations using SAP are still low on BPMS maturity
  • The additional costs for using SAP NetWeaver BPMS are low compared to other BPMS platforms
  • The use cases for tactical process improvement are pretty basic and usually focus on task automation, process transparency and especially user interaction simplification, which are all capabilities already available in the SAP BPMS
  • This means NetWeaver BPMS functionality is “good enough” to cover the requirements for these use cases
  • The available knowledge and experience for SAP-centric organizations will be good enough to be able to leverage out of the box integrations with PI, SAP Portal, BW and SAP ERP
  • In an increasing number of domain products SAP is leveraging NetWeaver BPM out of the box so building NetWeaver BPM expertise is helpful when considering domain solutions like GRC, Identity management and MDM
  • SAP NetWeaver BPM is based on BPMN 2.0 so skills developed in modeling using this standard will not be lost if a non-SAP solution based on BPMN is ultimately chosen as Enterprise BPMS.

So, is this an advice to choose for the SAP BPMS stack? Yes, if you are relatively new to BPMS and you are an SAP-centric organization and the criteria mentioned above apply, this is the most sensible decision, certainly if you are in the “Bowling Alley” phase of BPM adoption, the use cases are mostly based on Integration-centric processes and you need a number of BPMS success stories.

If your identified business use cases are high on Case Management characteristics it would make more sense to enter the bowling alley with a specific Case management solution (such as for example the Dutch platform of Be Informed).

Also, if the core applications in your organization are not SAP-based, probably early pilots with another BPMS platform based on Open Source or from your ESB vendor make more sense.

The most pressing advice however is to enter the “Bowling Alley”, identify the high value scenarios and start on the BPMS journey.

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