By design, ERPs are created to act as the “source of truth”. This design becomes a challenge when the customer has multiple ERP solutions. Each ERP wants to be the master. Most ERP vendors provide an integration to most popular ERP systems but these integrations are point integrations at best. “Best of Breed” may be a viable option. However, many ERP integration cost analyses only focus on a small area and do not calculate the true cost of ownership. The purpose of this article is to elaborate on the Total Cost of Ownership (TCO) for integrating multiple ERP systems to ensure informed decisions are made by customers.
Clearing up the Myth of Seamless Integration
Seamless integration is more of a marketing label and is not a technically accurate statement that defines Out-Of-The-Box (OOTB) integrations between multiple ERPs. This is based on my hands-on experience and scars earned from ERP implementations across on-premise and cloud deployment models. For our discussion, I will focus on the two extremes of ERP integration maturity. Consider the following illustration.
To create a seamless integration between different ERP solutions with different propriety data models requires each ERP solution to “think” they are the source of truth. This requires synchronization across setup (i.e. configuration, workflow, security) and transactions (originating in source ERP system and confirmation/completion transactions in target ERP system).
Deep integration enables the ability to synchronize and transfer data at multiple layers required for an enterprise ERP solution. Point integration only provides the basics to send and receive business transaction data. In general, point integration has limited support across the entire enterprise level. Therefore, additional efforts (manual) are required to keep configuration, workflow and security data synchronized between the multiple ERPs.
ERP configuration is an integration level that is typically understated in terms of importance. Many point integration designs leave configuration synchronization as a manual task that the customer performs. Consider the following illustration:
Given the cost of developing a deep integration between separate ERP systems, a majority of implementations go with the manual route to keep configurations in sync. This tactical decision will have an impact to business users moving forward.
Calculating Total Cost of Ownership for Integration between Multiple ERPs
Another area that is typically underestimated is the true cost of integrating multiple ERP systems. Most estimates focus on only one phase of the TCO for ERP integration:
|Initial Cost||Even with ERP vendors providing SOAP/REST wrappers or web services, effort is required for configuration, testing and validation.|
|Configuration Cost||The majority of OOTB ERP integration does not include Master Data Management (MDM) features required to keep multiple ERP systems in sync. This requirement is typically addressed manually. Manual updates involve time in data entry and coordination. Manual updates provide an opportunity for data error.|
|Technical Maintenance Cost||Assuming a Cloud delivery model, ERP updates are more frequent then traditional on-premise delivery models. On average, a competent Cloud ERP vendor will provide two updates per year. In general Cloud ERP vendors will provide an update that has been tested on a “general” configuration and transaction profile. Thus, a “mature” customer will perform some level of testing with each release.|
|Functional Maintenance Cost||This can be an area with a potential of wild speculation. Taking a pragmatic approach, I will only consider the additional manual effort required to coordinate key enterprise functionality including: data analysis, workflow administration, security administration, and data integrity. I understand that there are additional software solutions (i.e. cogs) that you can add to address the gap(s). However, I consider the additional costs as a missed opportunity to invest in innovation. Besides, just as with a physical machine, the more technical cogs you add to a solution the greater number of potential failures you create.|
Given the above elaboration, consider the following TCO analysis:
Consider what other ERP industry experts have stated:
“Integration costs, which include both year zero installation and continued operational expenses, can be as much as 40x each application’s initial cost.” IDC
“Corporate developers spend approximately 65 percent of their effort building bridges between applications.” Gartner
“Mixed-vendor environments can cost 4x as much as a single-vendor.” IDC
“In a survey of 100 CIOs and IT managers from 84 companies by software vendor intersystem, 67 percent answered “yes” to whether strategic integration project have been held back due to excessive software and services cost.” ComputerWorld
Far too often, ERP business cases only capture the initial cost(s) of multiple ERP integration, which is a disservice to key decision makers. Yet, I want to be transparent to you the reader in stating that my above analysis is a broad, general estimate at best. I have attached the cost model I used for this analysis. Feel free to prove it out for your environment.
Limited ERP Integration Results in Limited ERP Functionality and Added Complexity
Implementation services are by far one of the largest costs of an ERP solution. As such, customers will inherently look to keep implementation costs as low as possible. Corners will be cut and scope will be kept to a minimum. The tragedy here is that decisions are made without all the facts and limitations fully elaborated.
Let’s frame our discussion around a frequent ERP deployment scenario. Let’s say that we have a customer selecting two separate ERP systems for a best-of-breed approach. We also assume that the customer is not interested in building a deep integration between the ERP systems and will only utilize the OOTB point-integration services. The customer has a vague understanding that they are required to perform some manual synchronization of configuration setups across both ERPs. Both ERPs go live and functional business tasks are handled competently by both ERPs. The constraints reveal themselves when business activities and decisions cross multiple business processes. In general, these constraints make themselves evident in the following functional categories:
Granted, there are plenty of technical solutions out in the market to address these functionality gaps. However, consider the IT technology complexity considerations:
Just because there is a technical fix to solve the gap does not validate the need. Not convinced? Consider the following customer comments regarding the limitations that ERP integrations can impose:
“We purchased about 3 best-of-breed solutions in the areas of Asset management, Financials and Human Resource management. We have spent over ~N25M, over 12 months to implement, N2M+/yr for support/upgrades per solution, a whooping N35M for integration and it still does not do what we want.
This is the second time we have gone through the integration cycle yet our systems cannot deliver the real-time, asset-driven, consolidated information that narrows the horizon of data into seconds/minutes, not batched hours/days or a week’s worth of data whose latency effectively negates the ability to react with any effectiveness.
The CEO has asked that we look for a single source ERP that is highly flexible and extensible. He is seriously searching for a LONG TERM solution. At this point, he does not care if it is the ‘best’ in a specific area; he wants a robust, single source ERP that can meet all the needs of the company without the headache of integration.” Source: Infoware.
The bottom-line question you need to ask yourself is “Are the additional complexity and dependencies worth the effort?” This is a question that should be answered at the enterprise level, not the business functional (siloed) level.
Recommendations for Customers
Customers should challenge their ERP vendors and System Implementation (SI) partners on their 3rd party integrations. Following are key points for consideration:
- Understand exactly what is provided and not provided with OOTB ERP integrations.
- Quantify the effort required on the customer to address the gaps in OOTB integrations.
- Reducing technology complexity is the greatest enabler for reducing business costs and maximizing business agility.
- Warning! Short-term thinking usually results in siloed thinking, which typically results in business limitations and lack of flexibility.
Challenge to ERP Vendors and SI Partners
I can appreciate that providing additional information and guidance may potentially slow down the ERP selection cycle. However, I believe that we (including myself) are duty bound to provide complete guidance to ensure a customer makes an informed decision. Following are key points for consideration:
- Identify the functional limitations within your solution for a multiple ERP environment.
- Explicitly define the levels of support for multiple ERPs across all levels (configuration, security, workflow, originating transactions, closing transactions).
- Explicitly quantify the level of effort for customers to support OOTB point integrations for ERP systems.
- Quantify the TCO for ERP point integrations versus ERP deep integrations.
In general, enterprise ERP solutions inherently support deep integration between their modules based on their design on a common data model. Regarding whether to pursue a multiple ERP versus a single ERP approach, I take a results-oriented approach – whichever strategy adds the greater impact (%) to the Income Statement is the right choice.
On a practical note, when ERP vendors state their solutions integrate with competitor’s ERP products/solutions, it is important to understand to what level of integration is provided OOTB. Put yourself in the shoes of ERP vendor. How easy would you make your ERP system integrate with a competitor’s offering? Due diligence is required on every party (ERP vendor, SI Partner, Customer) to ensure that a complete set of information is provided to make an informed decision.
“In God we trust, all others must bring data.” – W. Edwards Deming