Case Studies in Maintenance and Reliability: A Wealth of Best Practices. V. Narayan

designed for easy use

      •They give benefits larger than the input effort to all levels of user and have support of all levels in the organization

      •They are a good cultural and organizational fit

      •One-stop shop for all required data

      •Critical to day-to-day activities, to ensure use; this prevents them being bypassed and valuable data and history lost

      •The systems contain “used” indicators of performance

      •All significant activities, events, and performance are made visible

      6-A.5 Creation and Implementation of the Computer System

      •Project management: A key factor in bringing success was that users ran the project in partnership with the IT group. This notion, which these days is called “client-led,” is very different from “client-centered” where users (the clients) are consulted rather than direct ing and managing. The modern term “client-led” is chosen to em phasize that clients are in control of the total process. System analysts and other specialists provide the clients with methodologies, tools, and techniques necessary to manage and control the process.

      •We felt instinctively that this was the right approach; modern system development is aligning on this style. Today’s arguments for this approach include:

      •An organization’s information system needs are difficult to define (especially by an outsider)

      •IT analysts tend to drive for technological solutions

      •Modern information systems must take account of the intertwined mix of hard needs, soft issues, and individual agendas

      •Introducing new methods brings feelings of insecurity that need to be managed effectively

      •Data and System Development Roadmap: It had been found that data was in a whole series of unconnected data islands with a variety of data definitions, preventing effective transfer and correlation of data. A project to rationalize data definitions and produce a consistent refinery data model was set up to run in parallel with the creation of small business systems. Prime focus was put on data that would be used in performance indicators to drive business improvements. A simplified overview is shown as Figure 6-A.1

Figure 6-A.1 Data Overview

      It was necessary to have an overview of the refinery needs. This overview is shown in Figure 6-A.2

      We prepared a road-map of the systems to give a visual picture of the end results (see Figure 6-A.3).

      6-A.5.1 Use of Prototyping Techniques

      There are some myths, which, if not recognized, lead inevitably to problems in developing systems:

      •Users know exactly what they want.

      •All users have identical needs.

      •Users can effectively communicate their needs to computer people.

      •Users needs never change.

Figure 6-A.2 Major Applications for Process Industry

Figure 6-A.3 System Roadmap

      Few users can design a new information system in an abstract atmosphere. But this is what the standard “efficient” way of developing an information system asks for. It asks you to identify and freeze requirements. If you can’t visualize it but are forced to guess anyway, it is not surprising that end results are unsatisfactory.

      A tangible demonstration to the users of what the system will do, and how, is essential to build confidence. Also essential is the ability to quickly change things to achieve a better optimization, either because the world changes or because your idea of what you want the system to do, and how, changes.

      If you are buying an off-the-shelf system, things can be easier; we bought these where possible. We seemed to be ahead of the game in a number of cases so we had to create a number of our own systems, in areas such as

      •Overtime.

      •Scaffolding

      •Permits

      •Maintenance workflow and productivity

      •Contractor management

      •Equipment data

      •Risk-based inspection

      The prototyping approach to system development can provide a flexible way of creating systems. It assumes that change is inevitable and uses software which produces working systems quickly, but with an inefficient use of computer resources. It does this by its approach (see Figure 6-A.4) and through the use of a 4th or 5th generation language.

      The steps in the approach and time scale for developing a typical small system are shown in Figure 6-A.5

Figure 6-A.4 Prototyping Approach to Application Development

Figure 6-A.5 Prototyping Development Time Scale

      6-A.6 Training

      People need familiarity and confidence in the work flow, new business processes, procedures, and the new computer systems which are supporting them. We found that it is not effective to leave all this to the vendor.

      A coordinated approach was found to be a winner, where the vendor acted as the technical expert training IT people; and site personnel were taught by the site’s focal points.

      Notes:

      1.Site focal points were chosen because of commitment to the cause and interest in success. They were usually people of stature and informal leaders in their groups. There would be a focal point in each geographical and discipline area. We did not choose those who were computer geeks.

      2.IT personnel received extensive training on hardware, software, back ups, software, and language from the vendor. This could take a month depending on prior knowledge.

      3.The system administrator had a week of intensive training at the vendor’s office on configuration and optimization.

      4.User focal points had a week of on-site training by the vendor.

      5.Managers and supervision had a day learning how to use the system and a day on how to extract benefits.

      6.Technicians, operators. etc., were trained by focal points. The amount of training for an individual varied with the number of functions she or he used, and could vary from two hours to a week. We found we needed to allow one hour of training for each piece of functionality used and then allow for another hour of practice.

      It is important to focus training on the specific needs of the group. It is not cost effective to try to train everyone to do everything. If the function is not practiced within a few weeks (or, in all likelihood, days!), the learning is lost. Several training packages, each focused on particular user types, should be made up from combinations of basic modules. For example, for a CMMS, you might select

      •Work request creation, scheduling, executing

      •Updating