This content is part of the Essential Guide: What's the state of the art in ERP trends?
Evaluate Weigh the pros and cons of technologies, products and projects you are considering.

Successful ERP system integration relies on the right ERP philosophy

Better integration is a main reason for ERP installations. But that doesn't mean the problems will miraculously end at go-live.

Trying to integrate different enterprise software packages can cause some people to start detecting conspiracies.

Todd Park is vice president of information technology at W&W/AFCO Steel, a steel manufacturer based in Oklahoma City. His company has three main enterprise software packages, and enterprise resource planning (ERP) system integration is no fun. Park explained that his company has often tried to set standards for importing data from one application to another, but then it will all just break.

Why? According to Park: bug fixes, software upgrades, and small data changes among other things.

"Suddenly there's an extra space after a comma and all your fields are out of alignment," he said. "It's just a continuous pain in the rear."

So how is Park a conspiracist? Well, conspiracist might be a strong word, but he has suspicions. He thinks software companies update their products often without really caring about quality or backward compatibility. Then when their customers have issues with ERP system integration, the vendor can justify the large maintenance costs they charge to fix it all.

"They're all the same," he said. "They have to continue to justify maintenance costs and keep that number up."

ERP system integration can be a major headache for companies like Park's, and it's a major improvement goal for them moving forward. According to Panorama Consulting Solutions' 2013 ERP Report, one of the top reasons for implementing ERP was to "better integrate systems across multiple locations." That reason was third highest behind improving business performance and replacing a legacy ERP system, both of which may be rooted in integration issues as well. Furthermore, the top benefit realized by implementing ERP, according to the survey of 172 respondents, was "availability of information." That speaks to Park's issues of data validation.

Have an ERP system integration philosophy

Patricia Dues doesn't think of ERP as an application. For Dues, the deputy chief information officer for the City of Las Vegas, ERP is a philosophy.

According to her, vendors have an ERP philosophy, and so end users should as well. Some vendors focus on excelling in one small niche of the ERP market. For example, one of the vendors that W&W/AFCO Steel uses is Sage Construction and Real Estate, a financial software package previously called Timberline that services the construction and real estate industries. That is a very specific niche.

On the other hand, huge ERP vendors such as Oracle and SAP want to be everything ERP for everyone. SAP has ERP software packages for financials, human capital management and operations -- and those are just some of the broad categories that have sub-packages beneath them.

Each philosophy has its benefits and its drawbacks. Going with a product like Sage's means you're getting software that has been designed for a specific task in your specific vertical industry. The big ERP players have worked their way into vertical industries through development and acquisitions, but may not be at the same level as a best-of-breed product that has focused on its niche for years. The drawback is that if you have several different niche applications, your IT staff may spend more time on ERP system integration, developing workarounds to get the software products to share data with one another.

Going with a big ERP product means you'll have one ERP vendor to deal with when there are problems, and hopefully ERP system integration will be easier because it is theoretically all one big application. However, that is not always the case. Oracle, for example, has built its large application portfolio through several acquisitions over the years, then placing them under the Oracle umbrella. But the name on the front doesn't necessarily mean the technology in the back will work well together. That is why Oracle has spent a lot of time and money developing its Fusion Middleware platform, which ties all the disparate Oracle applications together.

Dues said that working for a government agency such as the City of Las Vegas means that "you can't have just one vendor. It's just not possible."

"But we try to buy from one vendor as much as possible, because integration is easier," she added. "That is how our ERP philosophy has been established."

Dealing with disparate applications is almost inevitable, and Dues gave an example. When a criminal is arrested in Las Vegas, he gets booked into the court system using software from Motorola called OffenderTrak. Dues said it would be nice to have an ERP vendor that could handle all aspects of public safety, "but there isn't one we've found that met all our needs."

OffenderTrak creates an initial record on a criminal, which is processed into a customized written application that the court uses. That record tracks the criminal through the court system. Meanwhile, the City of Las Vegas has a neighborhood services division that has information on how safe certain neighborhoods are. It needs to access those criminal records -- built on a customized application, which imported data from Motorola OffenderTrak -- to see where certain crimes happen and where certain criminals live.

"All these things have to come together, mostly for reporting," Dues said.

Get ready for cloud ERP integration

Coming up on the radar, if it isn't there already, are cloud applications that must integrate into an ERP system. According to Floyd Teter, executive vice president of strategy and products and EiS Technologies Inc. and a well-known Oracle applications expert, it's a problem.

Teter said that Oracle has GoldenGate for replication and Oracle Data Integrator for big data migrations, but both of those are hard to do when a cloud vendor -- not just Oracle but any cloud vendor -- won't allow you to have access to your database on the cloud. The cloud vendor may offer you a Software-as-a-Service model, providing you with applications and a browser but no back-end control. Then they say they'll push data out to you on a periodic basis.

"Well, once a quarter, once a month, that's not going to cut it," Teter said. "[We're] talking about multiple times a day."

Teter added that Web services such as representational state transfer and Simple Object Access Protocol are not designed to move a lot of data or to provide heavy volume with small chunks of data.

"So performance slows down," Teter said. "That's the biggest issue. I think as we see the cloud mature, we'll see some resolution to that, but right now I think that is one of the big hurdles."

Dig Deeper on Oracle applications implementation and upgrades

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

Have you had issues with ERP integration? Tell us about them in the comments.
Most of the time the same information is coded differently in different ERP solutions.
Nice article and balanced, I thought. The major issue that’s overlooked is without application-level standards (e.g. an agreed upon template for one maintenance work order system to pass information to another GL) the majority of integration challenges will not go away. For integrations to have "backward compatibility", every vendor would have test each of their new releases with every release of every application a particular customer has! That’s why customers who choose to go “best of breed” or allow departments to buy their own “favorite” products are signing up to be a systems integrator whether they know it or not.

btw, the cloud really doesn’t do nothing to fundamentally change this so integrations won’t be materially different there than they were in browser systems; client/server; mainframes etc. Call it by whatever term de jour you like, but when you want a product developed by Group A to speak to Product B developed by another group, you have to design an interface, code it and test it. Every time either group makes even the slightest change that affects the transfer of information, the link is prone to break. (Note the customer’s remarks about the placement of commas!)

These opinions are mine and do not reflect the positions or policies of my employer.
Speaking as a software architect, there is no good solution to on-premise integration with ERP software. At my company I do the integration rework myself. That saves us the cost of bringing in a consultant and it only takes a few weeks out of my year. If you can afford your own developer, that would be one way to go.

I remember one company I worked with where they sent us information in XML format by email a few times a week. Occasionally they would drastically change the format of the XML (added elements, removed elements) which caused problems with the integration code. The change would only last one day and then it would revert back to the original agreed on format. I asked them about it and the vendor didn’t’ even know about the changes. They repeatedly said nothing has changed. But this kept occurring every few weeks. Eventually, I just enhanced the code to detect and handle either of their formats. And that fixed the problem. We had this problem even thou the version of our HR software didn’t change. So I would suggest making your integration code very flexible and allow for variations and future changes, when possible.

Another example is one project where I had to pull data from one application and feed it into another. A common situation. Because, I heard that we might be upgrading the system within a year I wrote the code to handle future changes. I did this by reading in the source data, transforming it as needed, and then I stored it in a new table. All the other applications that needed this data could access the data in that new table. It worked great. Of course, you can only do this with data where it isn’t important that the data be live. In my case, since I was copying the data into a new table meant the data would always be a few hours out of date. But that was ok for my customers. When the time came to upgrade our system, I only had to change the code that transformed the data and stored it in my new table. All the other applications that made use of the data didn’t have to change at all. The key concept here, is the data was already de-normalized and transformed into the format we needed. If the vendor upgrades their software, it doesn’t matter as much because I only had to change a small part of the code. I didn’t have to change all the applications that consumed the data.