In theory, integrated computer systems enable multiple uses for any single piece of data that is input only once. Data becomes available wherever it needs to be in whatever business process is integrated into the whole. In a sense it is like our brains – information and experience is registered once and available for access whenever needed for any purpose. Integrated systems should make our lives at work easier, but they seldom do that. Integrated business computer systems are very complex and can be very difficult to use. Imagine that they must support many separate business processes and departments, all of whom have different “languages” and ways of doing things.
One major system (and there are several like this) began its life catering to a single business process – accounting. It has obvious utility in finance and accounting and is relatively easy for accountants to use it. Then it expanded. Accounting processes handle transactional data with transactions generated by a variety of different groups. It makes a lot of sense to integrate data from all those transactions into the same system where it can all be accounted for. Purchasing, stores and inventory management were relatively straightforward to integrate and they all involve use of financial transactions. So far all the integration was taking place among business processes that shared some common language and all dealt directly with dollar valued transactions, had to track taxes, etc.
Another of the major systems available today started in the management of human resources. In HR, there are transactions involving money, pension funding, payroll deductions, etc. so it made sense to expand that system into finance and accounting. Payroll and employee transactions require employee information. Although not so straightforward as the various financial processes, HR could be integrated too. People are used everywhere in the business – training, operations, maintenance, marketing, accounting, etc. They show up in HR systems and in financial systems.
Several other systems began in the management of maintenance – some initially for plant environments, others for mines and others still for linear and fleet assets. There is a natural need to have parts for work order completion so integration with MRO spares, inventory management and spares replenishment, then purchasing all follow naturally. But some of those functions were already handled in the financially based integrated system. A decision is needed whether to manage parts from within the maintenance system or the financial system. People are deployed on work orders for job execution by trade. That information could come from either the maintenance work force table in the maintenance system, from a similar table in finance or a similar one in HR. Another decision – which should we use? If aspects of maintenance are contracted out, as they often are, then how is that handled and where? Managing the work isn’t the same as doing the work yourself.
Integrated systems are necessarily complex and therefore expensive. They take a long time to implement, there are often mistakes made and delays to their “go live” dates. These projects often go over budget and run late. Full functionality isn’t always implemented, and in haste to make up for lost time in implementation, some functionality is often foregone. In some cases the user training is cut back substantially to help recover schedule and budget. Some of the benefit generating capabilities are lost. Long implementation times means that business is effectively put on hold while you mess around with computers. What benefits are lost as you do that? Are these complex systems really worth it?
In the finance world there is a need to exercise tight controls over financial transactions. Arguably it is the financial functions that require the most rigorous management. Since everything we do in business either makes or spends money, it makes sense that finance be at the “hub” (if you will) of all business processes. The world’s biggest and most complex integrated business system is based on a financial system. It is also a complicated system to set up and to use.
In the world of maintenance and reliability we use work orders (transaction gathering documents) on which we accumulate, hours, costs, and time. Those are created to correct or mitigate problems with our physical assets (corrective and proactive tasks). Our reliability engineers need good failure data to help with reliability enhancement efforts. It makes sense that information should come from failure events, which are managed using work orders. But the work orders don’t necessarily track to failure modes – the very events those reliability engineers need to deal with.
If you use one of the more successful improvement initiatives – reliability centered maintenance (RCM), you’ll be working in the realm of failure modes. Failure modes occur and lead to the need for various work and spending transactions, but they are events, not transactions. Proactive work to mitigate failures and their consequences is triggered automatically and performed on work orders. But those work orders don’t necessarily relate to only one failure mode, or even one particular part, assembly, equipment or system. A PM work order to carry out vibration analysis, for example, might cover dozens of pieces of equipment and multiple failure modes in each one.
Once we get into the realm of the physical, we are not dealing with straightforward transactions that all have common measures related to the transaction like the dollar. In fact, we may be avoiding costs by mitigating risks – something that accounting does NOT account for. We may be generating extra revenue by our actions, but there’s no way to link our actions on a work order to a revenue gain elsewhere in the company. While there are relationships between our actions and the results, those relationships are often not direct and don’t lend themselves well to integration into transaction management systems that must tie to some sort of asset against which costs and expenditures are accrued.
Another big challenge with integrated systems is that their complexity “under the covers” often means complex and sometimes counter-intuitive user interfaces. Many maintainers complain about the interfaces on their integrated maintenance management modules. The terms “user hostile”, and “clunky” are often used. The difficulty of using the system as perceived by the user is a major hurdle to getting them to use it. The result is that in many cases the systems are not used fully, are bypassed (lots of spreadsheets anyone?) and the data they contain is unfit for any intended purpose.
When dealing with highly specialized disciplines such as reliability and maintenance, it may not always make sense to work within the constraints of an integrated business system. None of the major integrated systems actually include full RCM functionality for a good reason. It just doesn’t fit their dollar based transactional model. Failure modes are not equal to dollars, yet they are the “currency” of reliability and there is no table of exchange rates.
If you are considering new system capabilities to support your improvement efforts in maintenance, or to sustain your operational availability, give thought to whether or not it makes sense to integrate your new support systems. It may not work well, if at all, and it will almost surely cost a great deal.
Leave a Reply