BPM and ERP: How to Integrate? An Analysis

Blog: BPM Leader

While discussing an engagement with a client project manager, there was a question about how the BPM approach would work with ERP. The client project manager went a step further. He asked if I have a guideline on when and how to integrate with ERP. As I explained examples of what has been done and where, thoughts started crystalizing around this article.

Context for integration

When we are in a transformation project, the objective is to implement the process for making some changes to the process object or a case. After the changes to the case are done during the process, the need is always to update the changed data to the LOB applications. These LOBs (line of business) applications could be custom-built, ERP or Domain Specific Applications (like PLM, Core Banking etc.).

Questions to address

As a part of BPM life cycle, should the implementation of the process go for a direct update? And when should that be? As a first step, the advice would be to go for an inbound connection. Once business has confidence in the processes implemented, we should try for a direct update. Direct update builds lot of confidence … and it needs lot of confidence It can shake up the entire BPM setup, if things go south, so extreme care is needed.

Once you have crossed the first stage and are now ready to update directly to ERP, the next question would be: how to go about it? There are 2 approaches that we follow. We can either use an integration layer or go for web services exposed (most of the applications have standard web services for key functionalities).

Going a step further, we would ponder when to use which of the approaches (Integration Layer or Web Services). Based on experience across multiple engagements and clients, we can fit the integration approach into three broad scenarios:

Common integration scenarios

Scenario A: There have been many situations where the application in question does not offer any web-services. That can happen when it is a legacy application or when its a very data-intensive application. In most cases, it happens with custom LOB systems. In such cases, we went through an integration layer to meet application needs. The integration layer made perfect sense as it managed the file-driven integration. Tools like Informatica’s make a good use case here.
Scenario B: in many situations, the application to be integrated with available web services / BAPIs. In most of the not-so-old SAP instances, BAPIs are exposed. In such cases, we can directly go through the web services to integrate. Many BPM tools have out of the box SAP connectors, which makes this integration very cost effective and easy to implement.
Scenario C: In few scenarios, where the upstream/ downstream application is in another network (like DMZ) and the BPM application is in a home network (like Intranet), using web services becomes more difficult from security and implementation’s perspective. In such cases, an integration layer to connect the applications between the networks makes a very good use case.

To summarize, as we go along the maturity phases in a BPM life cycle, integration becomes more and more important. Many of the BPM stories falter at integration related situations. Some have very severe impact on credibility of the entire story. While the objective has been to address most common scenarios, there could be scenarios which don’t fit into any of the above three mentioned.

Feel free to add more and we can debate on how to go about them!!

pixelstats trackingpixel