The Maintenance Manager’s View

Peter was particularly interested in Paul's perspective and stance toward the project. Paul had worked at this refinery for the last 15 years, and he knew every piece of equipment in it. He was involved in the company's move to implement an ERP maintenance system about five years ago, and Paul was aware that Proclndustries was looking to change the way it managed equipment and processes in the plant through more and better data analysis.

Peter invited Monica to attend this meeting. In the meeting, Paul explained to Peter and Monica that the maintenance crew was always busy repairing equipment. He said that the operations crew was always pushing the units— compressors, feeders, and pumps—close to their operating limits and equipment ratings to meet production schedules.

Paul said his team used the ERP system to define equipment repairs and to generate work orders for these repairs, but the ERP covered only a section of the refinery that was recently refurbished. For that section, maintenance crews had data about the number of hours machines were operating. For the other sections, the maintenance personnel had the option to manually enter process equipment operating conditions, if and when those conditions were available. However, the maintenance staff did not have easy access to realtime data or historical trend data. The result was that they performed equipment maintenance on a time-based schedule predicated on their experience with the equipment.

Paul showed Peter the refinery's downtime reports. These reports spelled out how Paul's maintenance team had to adjust their work schedule so that different refinery sections met daily production requirements.

The maintenance crew worked more like a fire brigade, rushing from one crisis to another, Peter thought. These up-and-down cycles also meant the equipment would deteriorate faster than if the maintenance and operations crews had a steady flow of information, such as how long machines had been running and the real-time health status of those machines. Peter thought this could be an opportunity for Paul to start digitizing equipment and letting the maintenance people configure notifications.

"The data is there. It's collected, but it's not readily available for our group to analyze or to be used by anyone else," Paul said.

Peter said he thought these problems were not unusual. He noted that this lack of visibility into maintenance, combined with the other issues he had heard so far, was building a case to justify the needed investments—the purchase of new sensors, networks, and software upgrades—required for digital transformation.

Peter sensed he would have to find common ground with Paul. Peter needed a way to explain to him that once they installed and classified the major pieces of equipment, the workflow would be easier, given timely access to equipment behavior. Peter would train the team to help them understand the digital data infrastructure project and each person's role as it related to the project going forward: what they could expect, how to utilize it, and how it would benefit them. (See the box "Building a Business Case for Digital Data Infrastructure.")

BUILDING A BUSINESS CASE FOR DIGITAL DATA INFRASTRUCTURE

Collecting all the pros and cons for the project allows a project leader to make an argument that is both specific to the company's needs and relevant to its broader market position. Here are some key questions to answer:

  • • Why are these investments important?
  • • What will be the payoff in terms of costs avoided or revenue gained?
  • • What difference does this make in the competitive position of the company?
  • • What are the costs and potential benefits of taking no action?
  • • What are the sustainable risks to the company of maintaining the status quo?
 
Source
< Prev   CONTENTS   Source   Next >