Is integration the silver bullet that ensures your software investment will be protected against future change in your business? The reality as I see it is that a large gap exists between what the vendors mean when they claim to have software integration capabilities, and the actual needs of companies which are in the process of evaluating these vendors.
Firstly, at a technical level any piece of software will integrate with any other piece of software, given enough time and effort in programming an interface. Absurd as this may seem, it does illustrate that definitions of integration can vary wildly. The answer is in understanding whether the integration effort will result in added value; that is whether the benefits will outweigh the costs of the integration.
When we think about the different types of integration, it becomes obvious that many exist. For example, we could be talking about simple information aggregation - that is delivering processed data to the end-user through a common application interface (a set of reports or a portal). At another level, we may be talking about master data synchronisation between two systems. For example, an asset register may be the source of a master equipment list used to populate a plant maintenance system. The third example is the most intimate and complex level of integration. This is real process integration, whereby the two or more systems take turns in executing parts of a coherent end-to-end business process. This type of integration often requires the systems to share the same fundamental assumptions about how the overall processes, data flow and user interaction should be structured.
Unfortunately, IT specialists tend to take too theoretical an approach to integration. In the real world, many organisational, cultural and other factors come into play when deciding on how deeply two systems should be integrated. Let me further explain using the example mentioned above: the possible integration between an asset register and an equipment database in a plant maintenance system. Before simply assuming that these two systems "must" be integrated, it is important to step back and get some perspective.
Asset registers are financial tools to aggregate the value of assets in the business for the purposes of determining book value, depreciation and wear and tear tax allowances, among others. Here simplicity is essential, and in my experience it is often enough to group whole areas of plant into single assets, since this area of plant will start up, run and be decommissioned at the same time. The financial manager who maintains the asset register strives towards accuracy and reconciliation between plant assets and the balance sheet.
When we think about the different types of integration, it becomes obvious that many exist.
Gavin Halse, MD, ApplyIT
An equipment list for engineering or maintenance purposes, on the other hand, must be as detailed as possible to assist the technical staff in their jobs of designing and maintaining the plant. For example, a single compressor may consist of hundreds of associated components, each critical to the maintenance of that item. Engineering staff seek to add or modify detail without any hindrance; it is of secondary interest to them what the depreciated value of the item is. Their objective is to ensure that the item is maintained as cost-effectively as possible and they are therefore focused on the income statement and less on the balance sheet.
In this example the two departments (financial and engineering) with their different objectives may find themselves fundamentally in disagreement if the asset register and equipment list are tightly integrated into a single set of master data. The business value of doing this is indeed questionable, considering the new red tape that the engineer will now need to go through to add/remove or modify a piece of equipment. To keep the balance sheet accurate will require an extensive set of financial processes that accurately account for assets that are being maintained, replaced or swapped out as part of routine operations. Most plant accountants are more pragmatic and simply aggregate this detail into a single asset - perhaps the whole compressor unit.
The lesson is always to examine very carefully the assumptions before undertaking an integration project. You may incur substantial costs and end up with negative business value. Always question the underlying logic of integrating systems simply because it can be done. Technocrats will indiscriminately integrate anything to anything; it has even been suggested that plant instrumentation can be integrated to automate financial statements. An ambitious concept like this has limited real practical value in most resource-constrained manufacturing companies I have encountered. A more pragmatic and balanced approach is required.
Share