There’s an increasing push from top management to integrate plant systems, CMMS/EAM software, and other business systems such as those in payroll, purchasing, finance, etc. In addition, there’s a growing desire for communication between systems on the plant floor.
The need for communication between applications can create serious challenges for companies and their IT departments. Most companies use separate software applications for each department and functional area. The result is often a combination of old and new systems, enterprise suites, dedicated software/hardware such as PLCs, and homegrown software. In the past, achieving integration was difficult for IT, and the cost and complexity of integration kept it out of reach for most companies.
Now, new technologies and standards are changing this picture, giving businesses numerous options for integrating at a reasonable cost. In the past decade, integration suites have become popular. These consist of a middleware application server that schedules and exchanges data between different applications. These tools seek to deliver the integration benefits of an enterprise suite without tying a company to a single vendor’s applications. An integration suite can simultaneously share data between payroll, accounting and scheduling software. But while these can deliver strong benefits, they can also be expensive and complicated.
Newer integration alternatives can move data in and out of applications using common industry-standard technologies such as XML (extensible markup language), ODBC (open database connectivity), and even simple delimited data files. Data is then easily shared with other applications. This approach delivers key benefits of integration, yet is less expensive and easier to implement than other alternatives.
XML: This is a highly flexible text format for publishing and sharing data. XML makes it possible for applications from different vendors to exchange data by providing an intermediate standard that both applications can use. It makes communications between systems easier and less expensive because the same free, commonly used standard can be used by multiple applications.
Web services: This software standard uses a group of business logic packages to support communications over a network. Various open standards are used to make communication possible between applications running on different operating systems. With integration software that makes use of Web services, applications can share data across an internal network or the Internet.
Database connectivity: Most integration suites and some generic integration tools support communications between two databases using standards like ODBC.
Flat data files: Some older applications do not support XML and Web services. Many of these can import and export data using Microsoft Excel spreadsheets or simple delimited text files. Integra-tion suites and generic integration tools can manage the sharing of data by passing these files between two systems. This option should be used only if there are no other integration technologies that can be used. It is often useful, though, for importing data from external sources such as vendors.
An integration strategy
An integration solution requires a realistic plan that reflects true needs and available resources. Consider the following:
• Which applications and types of data need to be interfaced? Some applications may need to be tightly integrated and others may only need to occasionally share data.
• Which applications and functions should be integrated first? Don’t attempt to integrate an entire plant or even one department right away. Start with a plant function that would benefit the most from integration. Create an implementation schedule that ties systems together in a systematic manner.
• Do you need a complex or simple level of integration? A realistic level of integration may yield 90% of the benefits of a more complex integration at a fraction of the cost and time. Take a close look at how much data you really need to share.
• Are there dependencies? The implementation priority may need to be driven by the technological realities of your systems. For example, the first choice for integration may be the most technologically difficult to implement, so it may be smarter to choose another system for the first project.
• Do all applications support the same standards? The capabilities of your applications need to affect the priorities in your implementation plan and your choice of implementation software. Some implementation software supports a variety of technologies, while other software only supports one or two.
An integration method
Enterprise suite: Upper management will choose to implement an enterprise suite; they should know that integration alternatives exist. For example, many of the modules in the suite for departments such as HR or finance may be full-featured, but plant modules may be weak and incomplete compared with a strong CMMS or EAM system. An integration suite or generic integration tools offered by some CMMS and EAM vendors could enable the plant to have the best tools for the job, while providing upper management the integrated data it needs.
Middleware integration suite: Research the adapters offered by vendors and make sure there is one for every application that needs to be integrated, including potential future applications. Verify the specific application versions that each adapter is written for; an adapter written for a slightly different version of your software may not work. Ensure that the full system is exposed via the adapter.
Generic integration tools: Make sure the vendor supports industry standards such as XML, Web services, ODBC, and others. Also, find out if the tools are easy to use. Ideally, those familiar with the application should be able to use the integration tools. You shouldn’t need a highly paid database administrator to set up and use them.