In this post, I will discuss how an ERP application and a BPM product can co-exist together with each piece catering to their strenghths.
ERP or BPM?
I had read the post by my fellow blogger Anders on whether BPM should follow ERP (https://www.bpmleader.com/2012/05/24/bpm-follows-erp-are-you-serious/). Of course he is absolutely right, ERP implementations mostly take too much time and come over budget because of a lack of a process driven driven approach and requirements soon getting outdated/irrelevant due to the long implementation time span.
Most large companies have already made significant investments in one ERP or another (SAP, Oracle) and they will not be replacing their ERP system anytime soon, unless there are compelling reasons. For some newer small and mid-sized companies especially in the healthcare market, many are starting with a BPM product to fulfill their solution requirements rather than with an ERP product, more because it meets their needs rather than due to any BPM/Process driven philosophy. BPM companies sell the solution and not the product, while highlighting the process centric, iterative, and flexible approach to developing the process.
Of course one can make custom changes to the ERP tool, which we all know can not only get very expensive but also prevent migration to the next higher ERP version if not done correctly. BPM offers a more flexible and faster approach.
Three examples for co-existence
Here are some of the ways a BPM product can be used along with an existing ERP solution:
1) Extending the ERP solution
In many cases, the ERP product may not cater to either the front-end or end-of-life processes. For example in case of mortgages or asset backed lending solutions,while ERP provides a rigorous backend solution, you may need a front end solution to cater to quotes for example, or exchange/submission of documents during the intial screening process. The entire front end process can be created out of a BPM tool integrated to the backend ERP. In cases where there are company specific processes (e.g. a three-tier approval process for funding to investors in case of mortgage backed securities), data can be extracted out of ERP to the BPM tool where the approval process is configured – after requisite approvals, the BPM can trigger the right process either within ERP or independently.
A BPM tool could be configured for end-of-life processes as well – example end of lease activities. To extend product life cycle, a company may decide to go into the sale of assets returned. These processes can be configured within the BPM tool after extracting the right data from the ERP solution.
2) Adding additional services
Say, you are a mortgage or leasing company and want to offer insurance. Since this is not your core business , the back end ERP would not have this capability built into the system. Again data from the ERP system can be extracted and used to create another process within the BPM tool catering to insurance- eg calculating the premiums , sending out letters to customers, billing for additional insurance and ensuring that the receipts are accounted for correctly – just some of the steps involved in this process. Some of these activities may require changes to the core ERP system, others can be handled via the BPM tool. Idea is to reduce code changes to the ERP (too expensive) and configure the BPM tool to meet process needs.
3) Integrating with enterprise services
Many companies are moving to sets of core enterprise services which are standards for the company. Some examples include credit scoring processes, document management processes etc, depending on the business the company is in. Some of these services could also be provided by the ERP application, but the company may prefer to use the standard service due to use of proprietary algorithms. In these cases the BPM tool can act as the integrating mechanism between these enterprise services and the ERP module. There is plenty of material on links between BPM and SOA and the synergy between the two, so I won’t go into the details here.