Spending time on the problem definition means the RealityChart is concise and the time to develop it is less of a drain. Take this instance:

A forward thinking maintenance manager dedicated two hours, every two weeks, to run RCA workshops. The whole engineering team, him included, were “encouraged” to participate. The goal?  To understand and resolve the small, niggling, day to day issues.

It was a “show and tell” affair, where the technicians would bring failed items, and the group would try to implement solutions. They set about it with little structure and a “problem-solution” mentality. I suggested introducing some structure and so we ran the Apollo Root Cause process, building the chart on the workshop wall, get to a point of ignorance and then use the following fortnight to gather the evidence, to revisit it next time.

One of the technicians complained about the dry break couplings used on the tanker offloading systems. “They want changing, they’re dreadful, and they cost around £5,000. They fail every month or two and there are four in use on the plant”. Ignoring the solution the technician gave, it was a great definition and a significant problem – let’s crack on with the RealityChart then?

I use post-its to define the problem and significance. I always stick to the process and use it – if only to keep the problem visible to everyone. And I’m a firm believer in using the terminology of the participants so the problem definition began “offloading couplings are dreadful”. We added the where and the when then moved onto the significance.

“Well……..actually…… I’ve started repairing them, rather than throwing them away”
What does that involve? “I change the ‘O’ rings”

“How much do they cost?”   “£10” – low significance, there then!
A failure every 1-2 weeks, how much downtime does the failure it cost?

“Well, when it starts getting tight to use, I’ve asked the operator to tell me and I plan some time with him”– excellent, no real downtime then either!
Presumably the time to repair has some effect on the plant?  While you are repairing the couplings you are not supporting production?

“Well….. No, not really, it’s a fairly quick job”

So we needed to find solutions to ‘dreadful offloading couplings’ trying to save the business £10 per month with no down time and no significant impact on production?

Yeah, well…. but they’re still dreadful” said the technician.

The rest of the team pointed out that he’d already investigated it, found robust solutions and implemented those solutions! All that needed doing was to communicate the success.

A quick learning slide and the new ‘best practice’ shared across the site. “Problem” solved. You don’t get a more concise RealityChart than that!

 

Stewart Stephen

Reliability Engineer, UK

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Post Navigation