Part 1: What is Interoperation (and why should I care)?
If you read my “Don’t Wait, Integrate” and “Go Native AND Integrate” blog series, then welcome to the sequels. Unlike most sequels, these won’t be just a rehash of the originals. There is so much new ground to cover! Platform evolution, cloud commerce and middleware, indirect access, and IoT are on the minds of many IT professionals these days, and I hope to give you a glimpse of what eLogic is doing in this new series of blogs.
In this initial post, I plan to reframe the integration problem in terms of interoperation. According to Wikipedia, the definition of interoperation is “the setup of ad hoc components and methods (i.e. services) to make two or more systems work together as a combined system with some partial functionality during a certain time, possibly requiring human supervision to perform necessary adjustments and corrections.” That definition succinctly captures the straight talk about CRM to ERP interoperation in general, so let me break it down for you piece by piece:
Ad hoc components and methods – “Ad hoc” characterizes the bespoke integrations which are among the most prevalent and what most providers offer. This isn’t just customized field mapping; this is a completely custom definition of what the integration provides and how it works. Solutions typically include only current state requirements identified by the business with little or no thought given to future requirements. And few enterprises can anticipate the “gotchas” that await them just over the horizon.
In contrast, vendor developed integration has a general-purpose specification that entails what the integration provides and how it works. For example, the vendor provides the CRM, the ERP, and the middleware to connect them. While this is not ad hoc integration, it is still subject to the rest of the interoperation definition below.
Make two systems work together – CRM and ERP systems each play specific roles; that is why they are not combined into a single system. Making them work well together requires a deep understanding of the processes that each do independently and the processes where they must work in collaboration. The primary design consideration is which system is the master for which data and transactions. In reality, there is rarely a simple division of this ownership.
When designing integration, it can be tempting to build ERP functionality into CRM and vice versa “to make the integration work better”. In fact, this only makes the whole solution more complex and difficult to train or maintain. Keep in mind that you have significantly different users in each system. Expecting CRM users to understand or provide ERP relevant data is often challenging at best. I will discuss specific examples of these topics in my next blog.
With some partial functionality – CRMs and ERPs necessarily share only a small subset of functionality (see previous paragraph). Beware however that even shared functionality may work differently in CRM and ERP (even when a single vendor provides the CRM, ERP, and middleware). This is especially true with nuanced functionality like pricing, costing, configuration, engineer to order, etc.
Integration is only relevant to a partial scope (of shared functionality). There are a lot of data and transactions in ERPs that CRMs don’t care about. Take products for example. CRMs care about saleable materials (and often only materials sold in certain regions through certain channels). ERPs also have all sorts of other materials like raw components, subassemblies, etc. There are many reasons not to inundate CRM with extraneous ERP data.
During a certain time – “Wait a minute, my integration isn’t running all of the time?” Even if your middleware is running, your integrated systems may not be (for planned or unplanned reasons). Integration must always account for this possibility and provide for queueing and reprocessing of data (including scenarios where the middleware was not running). Following such outages, it is critical to confirm that the systems are back in synch. Another question is whether you need integration to support initial data loading from ERP to CRM.
Requiring human supervision – All enterprise systems require some level of human supervision, and integration is no different. Integration will continually encounter exceptions that are beyond its intended scope. Most of these exceptions and their resolution process will be anticipated in well-designed integration, but there will be at least of few that cannot be. Inconsistencies can also be introduced by unexpected errors occurring in the integrated systems or middleware. These errors must be identified and resolved.
Perform necessary adjustments and corrections – Integration is typically built to automatically synchronize common create, change (and possibly delete) transactions. However, uncommon transactions are not supported by integration and require manual adjustments and corrections to keep systems in synch. Examples of these transactions include changes to system settings, data archiving, mergers or divestitures, system upgrades, database level repairs, etc. Perhaps the most common adjustment is reprocessing of data after a system outage, exception, or error.
As you can begin to see, it takes a lot of knowledge and expertise to achieve robust interoperation of CRM and ERP systems. You might conclude that only a single vendor providing the CRM, ERP, and middleware can achieve the required robustness at an affordable price. Not really. Single vendor landscapes are subject to the same interoperation challenges. We have seen this firsthand working with our customers. We steer customers around these pitfalls in the same way we do in the integration that we provide. And the latest integration technologies make it far more economical for us to provide it.
Microsoft Dynamics 365 to SAP ERP integration has long been a forte of eLogic with our deep business and technical knowledge of each platform. In recent years, several competitors have joined the market with offers that claim to solve this integration problem but they don’t elaborate on the problem or specifically how they solve it. Beware of claims like “we can connect anything to anything”. The subtext is “we will figure it out while we build it for you”.
To again stand apart from this growing competition, we developed a new generation of cloud based services to enable our Microsoft Dynamics 365 to SAP integration. We took a step back to reexamine our near decade of experience integrating these systems and then applied some new thinking within the enabling technologies that are now available. As a result, we built our new solution on the Microsoft Azure platform with the goal to achieve new levels of interoperation.
In my next blog, I will get into specific details about interoperating platforms and the advantages our solution provides by leveraging the latest available technologies. Thanks for reading.