Better Operations, Better Decisions, Better Results!
Affordable Software Integration Solutions

Challenges to Successful Business Software Integration

There are five principal challenges to successful integration projects:

  • Scope
  • Process “Blind Spots”
  • Cultural Issues and Terminology
  • Model Disconnects
  • Technology

Click on the headers below for detailed information.

Expand all Collapse all

1. What is the scope?

Surprising though it might seem, many integration projects start before the business really understands what problem (or problems) they are trying to solve by integrating. This is especially true in large corporations where, for example, improved integration is a corporate I.T. strategy, and the project in question is simply the “next cab off the rank.”

In some cases, the project team simply takes on far too much, attempting to find each and every touch point between the systems and planning to address them all. The net result can be a project that can never be delivered within the planned budget and schedule constraints.

 
2. Process Blind Spots

The implementation of large scale systems like Enterprise Resource Planning (ERP) or Customer Relationship Management (CRM) often begins by mapping out the company's business processes. Each high level process is broken down into small processes and, ultimately, into activities. Then the activities are mapped onto capabilities of the software system and, eventually, automated. Where a process cannot be automated by the system in question, the most common solution is to mark that as interface to an external system. The process map stops at that point.

However, business processes don't just stop because the ERP (or other) system doesn't have the functionality to automate the entire process. No, they continue on in other more-specialized environments: such as Manufacturing Execution Systems (MES), specialized software packages, robots etc. The team mapping out the processes can become so focused on their project that they develop blind spots and ignore the rest of the process.

Not only can this lead to inefficiencies in the practical execution of the processes, but in some cases can impact other processes. For example:

  • Suppose a process map shows that the final step of a process is for the ERP system to print a report. On further analysis we might find that someone types data from that report into another application. We have essentially introduced a manual step into the process which may become a bottle neck and/or a source of error.

This poor understanding of the end-to-end processes can have secondary, unpredictable results. In one real life example:

  • A process called for shipment records to be finalized on the fourth day of the month (for the previous month). This process was mapped out almost entirely in the ERP system, with an interface to download the results to a production system. Another process called for the production facility to finalize its inventory postings by the end of the third day. This process was managed almost entirely outside of the ERP system and appeared on the process map as an interface.

Had the processes been fully mapped out, the team would have found that the shipment record data was an essential input to the inventory calculation process. So the demand for the production site to close inventory on day three when they were dependent upon a process that did not close until day four was impossible to meet.

Even though the process maps showed the necessary interfaces, they did not show the interdependency of the two processes. This problem was not detected until the entire system went live and the company attempted to close the first month’s books.

 
3. Cultural Issues and Terminology

In large manufacturing organizations, the world of the corporate offices is very different from that of the manufacturing sites. The problems faced and conquered on a daily basis by production personnel are very different from those addressed by corporate strategists. Safety and production continuity are the watchwords of the shop floor, where things can change in the blink of an eye.

Even though the manufacturing sites use standard Information Technology offerings in their administrative offices and to manage many of their daily tasks, there are also highly specialized technologies applied in most production facilities. Whether they are conveyers, packing machines or process control systems; these technologies require a very different set of skills to operate and maintain than the more run of the mill I.T. personnel have to offer. As such, the production sites often develop dedicated groups who are responsible for this specialized equipment. A line is effectively drawn between corporate I.T. and plant specialists and turf wars are commonplace.

Over time, the vocabulary used by corporate decision makers; I.T. personnel; plant supervisors and plant technologists becomes highly specialized and jargonized presenting significant barriers to effective communication. Worse, some words and phrases will be used by several groups but will have subtly different interpretations, which can result in one side misinterpreting the others. For example:

  • The term “real time” when used by corporate I.T. personnel generally means that information is presented to users as and when they request it and is updated within a few minutes of new data being available. To a chemical plant control room operator, though, "real time" means what is happening now: what is the current temperature and pressure in a reactor; what is the current level in a tank? Telling him that the tank has overflowed ten minutes after it happened just isn't good enough. Yet, if you were to hold a requirements meeting with both groups represented the term could be discussed happily by both groups, with neither group realizing that they each mean something entirely different.

This combination of cultural barriers and conflicting lexicons can undermine project progress; presenting artificial barriers to accurate requirements analysis and potentially resulting in lack of "buy in" to the project from one faction, or another.

 
4. Model Disconnects

Every software system has some model of the real world: a CRM system will model a company's customers and their organizations and (perhaps) the company's products and services; a production planning system will model the workstations/equipment; operations and materials; etc. The level of detail in the model will generally be based upon the needs of that system. For example, an inventory tracking system needs to know the capacity of a hopper or drum (and perhaps its dimensions) but a CMMS system will need to know about all of the spare parts (covers; hinges; nuts and bolts) required to maintain that hopper. Similarly, a supply chain management system will need to know how much inventory a plant has by product but not in which hopper/hoppers the inventory is stored.

Sometimes this difference in model granularity can present a barrier to integration. For example:

  • Let’s say that a company’s ERP system tracks shipments of finished goods from the manufacturing site by recording the marketing part numbers delivered to customers. The same physical product could be sold to many different customers in different configurations and for different prices. However, the manufacturing site doesn’t usually care how the product was sold – they just need to know the total of the total number of physical products shipped. The shipment records use marketing model numbers, but the production site wants to know physical part numbers. Before the shipment records can be used by the production site, we need to translate marketing model numbers into their physical equivalents.

Even where the model granularity is the same in two given systems, there are still naming issues to deal with. For example:

  • A manufacturing company with production sites in, say, Mexico and Arizona may choose to name all products and raw materials with a standard material code (say a 10 digit number). However, suppose that the Manufacturing Execution Systems (MES) at each site were implemented by local contractors who chose English and Spanish names for the materials. Before messages can be exchanged between the sites MES and the ERP system, the names must be translated from English/Spanish into their 10 digit equivalent.
 
5. Integration Technology

The last challenge to successful integration is that of the technology used to implement the solution. Oddly enough, many project teams jump straight to this question and spend much more of their time and attention on technology than on addressing the other, very real, challenges to success.

While not surprising, this emphasis on solving the technology problem is unnecessary. Certainly, there have been integration projects that ran into technical difficulties, but in general the technology issues have merely exacerbated underlying scope, process, cultural or model issues.