BPM on ERP (Part 2 of 2)

In part 1 of this blog, we discussed unique value that BPMS bring to ERPs. Based on our customer engagements we have come across 3 distinct scenarios, through which organizations can realize value to BPMS on ERP.

– These scenarios are:

• Scenario 1: BPMS used to capture add-on Process.
• Scenario 2: BPMS used to capture end to end Process to provide visibility into entire process, leaving the part of process within ERP as-is.
• Scenario 3: Rip and Replace – Only use ERP to execute transactions while BPMS becomes the front-end for all process participants.

– Let’s look at each of this in little more detail:

• Scenario 1:

In this case, Process starts in BPMS and culminates and culminates with some transaction in ERP or Process gets initiated as a result of some transaction in ERP and completes in BPMS. To capture this kind of process in ERP would call for lot of customization of ERP (as we saw in part 1). Let’s take example of Vendor Registration. We have seen that organization use spread sheet that traverses through various approvals before it comes in hand of ERP specialist responsible for maintaining Vendor Masters of ERP. Lack of automated process that involves several checks and balances and approvals before registering a vendor, introduces lot of process inefficiencies. It is very difficult to automate this process in ERP, given complex hierarchy (that change often) and rules through which approvers are determined. One of Nividous customers faced similar issue, where this process was still manual. As result of delays in vendor registration, it resulted in significant delays in downstream manufacturing due to lack of supplies.

• Scenario 2:

This is what we call a “Big Process”. Consider process of Order to Cash or Procure to Pay. These are very large processes that invariably go through multiple systems and part of process it already implemented in ERP (or other system). However, there are parts which are not automated at all and are resulting inefficiencies due to weak system hand offs or manual interventions. In order to improve these processes, organizations want to gain end-to-end visibility. However, it is becomes difficult to justify rebuilding such process entirely in BPMS. This scenario calls for BPMS’s ability to capture end to end process and also its ability to represent and drive a set of activities that are performed in other systems (in a way Proxy step) trough some kind of messaging. Today’s BPMS (what Gartner calls intelligent BPM or iBPM).

• Scenario 3:

As name of scenario suggests, this means re-engineering entire process in BPMS. This invariably means that organization had done unnatural act of over customizing ERP and it is now becoming very difficult to maintain and change solution and there is pressing need to relook at entire solution. There are several examples of this scenario. However, in our case we came across customer who had attempted to customize ERP to capture Employee On-boarding and Off-Boarding process in ERP! Once can easily imagine that it was bound to be disaster. It took some amount off boarding before organization took painful decision to invest in rebuilding process solution using BPMS. Solution obvious interacts at various points with ERP to push and pull data, however, process involves most of the steps that need to be performed outside of ERP.

When Organization is evaluating BPMS based solution, they should keep above 3 scenarios in mind and take right approach depending on which scenario fits the need of hour.

Gartner has recently came out with iBPM (intelligent Business Process Management) Magic Quadrant and have put down requirements that iBPM platforms should meet. In next BPM blog, we plan to share our thoughts around iBPM.