Information Need Drives Data Flow

By G. C. Skipper, Contributing Editor | September 28, 2010
Pat Crail, CEM, John R. Jurgensen

Pat Crail, CEM and fleet information manager, has succeeded in putting an end to the old lament, "data rich and information poor." He did it by flip-flopping where he starts the process.

You don't need a magic wand to turn data into useful information. The trick, though, is knowing how to go about it.

At John R. Jurgensen Cos., Pat Crail, CEM and fleet information manager, has succeeded in putting an end to the old lament, "data rich and information poor." He did it by flip-flopping where he starts the process.

Many fleet managers, he says, start out with the data, distill it, and then combine it with other data to create information. When you do this, however, you set off an avalanche of data barreling down from your accounting system, your machine systems, work-order systems, and other sources.

"These fleet managers then try to figure out what to do with all that data," Crail says. "This approach is getting harder and harder to do as we move into the telematics age." He is in a good position to know since he is on the AEMP technology task force working on telematics protocol. "The difficulty in starting with data is the sheer volume," he says. "It is incredible."

A better approach, in Crail's opinion, is to start with the information end of the spectrum. "You will find you can get by with much less data and can focus on making the data you have as accurate as it can be," he says.

Consider what information you need, what information the users need, and who needs to see what within your company. Once these questions are answered, Crail says, work backward to determine what data fulfills the needs of the different users and what format works best for each user.

"Rather than trying to make use of all the data and all the cool things you can do with it, start with what it is you need to know, who needs to know it, and where you can go to get the data that will provide the needed information."

For example, an hour-meter reading from a piece of equipment in and of itself is only a meaningless number, he says. Various levels of management, however, have different needs and to each of them the number represents different information. A supervisor, whose primary job is to dispatch technicians, needs to know what machines are due for service, when they are due, and what service is to be performed.

"For him, you combine a couple of pieces of data and get that information to him," Crail says. "You show him the last time a machine was serviced at what hour-meter reading, the current hour-meter reading for each of the machines, and combine that with a preventive maintenance schedule that tells him when the machines are due and where the machines currently are located."

A middle manager, by comparison, may need the hour-meter reading in the context of major component life. How many hours are on the engine since the last rebuild? How many hours on the transmission since the last rebuild? This gives him a quick reference as to component age.

"When the middle manager looks at a machine to make a repair decision, he has some idea how old the components are and whether or not the machine is getting close to a rebuild," Crail says.

A fleet manager also needs the hour-meter readings, but he is more concerned with fleet average age of each equipment class and how that age is dispersed within a specific class, says Crail. "He's looking for what machine needs replacing and what machines need repairing."

Crail says the format for the information depends on the user. For example, a supervisor responsible for scheduling PMs needs a report, whereas a fleet manager dealing with large groups of data needs a graphic representation that makes it easier to understand and display the information.

Other users might find it faster and more useful to pull information off a computer screen when it's needed.

In his company, Crail makes the decision on who needs what and in what format. His decision is based on a number of factors — for instance, regular discussions with the shop staff to determine if they are getting what they need.

"We talk about whether the format being used is a good one," he says. "Is the information relevant and is there any information they need that is not being provided?"

Other factors that might play into Crail's decision are management-driven topics, such as clearly conveying to workers that, "this is how we want to run our railroad."

Turning data into actionable information requires certain basics or standards if the technology is to be of any help in managing a fleet, he says.

"Answering this question is the backbone of the telematics standards the AEMP technology task force is working on now with OEMs," Crail says. "We are pulling together basic pieces of data that provide the bulk of the information a fleet needs to operate. They include the previously mentioned hour-meter or odometer readings; location of the vehicle based on GPS information or job numbers, depending on how the company is organized; fuel consumption, which is becoming more and more important as fuel costs rise; and cost information, such as owning and operating costs, plus all the subcategories that go under that."

In addition, fleet managers should have access to repair data from work-order systems, Crail says. "They need to know such things as proactive repairs (these are planned and implemented, such as major overhauls and maintenance) versus reactive repairs (work done on equipment that breaks down)."

But, says Crail, gathering the data is perhaps the biggest hurdle that must be overcome. "Any time a human being is involved in the process, you have the chance of human error," he says.

At Jurgensen, all this has been more than just a better way to build a mouse trap. It has meant Crail can make faster and better management decisions.

Six or seven years ago, in anticipation of what they might need in the future, Crail and the management team put category codes into their work-order system. "For instance, a shop foreman would fill out a repair form that told us whether a repair was proactive or reactive. Another code we entered identified downtime, if any, associated with the repair. Did it break down on a shift where it was expected to run?

"We put these codes in place several years before we had the capability of using the information. What's important is to realize you are looking at historical data, and the sooner you put the codes in place, the sooner you start building a database. We got those up and running right away," he says.

Over the years the results have allowed the company to quantify the effects of a proactive/reactive ratio, says Crail. "It tells us how much money was spent, how much of the effort was proactive, how much was reactive, and it helped us quantify spending additional efforts on proactive maintenance, on downtime, and overall machine lifecycle costs."

One thing he discovered was that "the tail was wagging the dog," says Crail. "Most of our work was reactive and not enough proactive work was done as far as PMs were concerned. By having all that coding in place, we assigned one technician as a full-time PM inspector."

Once he identified the problem and started putting in more time on the proactive process, Crail saw a substantial drop in total maintenance cost fleet wide. During the first year alone downtime fell 20 percent. "The first year after the PM problem, the machines were breaking down less, and when they did, the breakdowns were less severe."

Crail has seen other positive results from using this approach to turning data into actionable information and he expects to see more.

"We view this as a continuous improvement cycle," he says. "It is never finished."