rg My name is Gábor Rósa. I’m a mechanical engineer and spent my professional career in various positions dealing with maintenance in the oil & gas industry. I’m also a LEAN engineer and the founder of LEANtenance Consulting Ltd.

From Profession to Obsession

The following four assignments had the biggest impact on how I perceive maintenance and LEAN:

1. Planning

The company I was working for had around a hundred white-collars whose everyday task was to provide plans (as quotations) for the clients. This involved dozens of own workshops and a couple hundred contractors.
I was responsible to standardize the process, eventually it led to the development of a standardized planning / quotation system.

My key takeaway: processes involving more than a few people should not be covered only by policies and procedures, there should be a system in place that makes the process standardized, measurable and streamlined.

2. Scheduling
Consultants from T.A. Cook reviewed how maintenance is executed at our company and pointed out the utmost importance of scheduling:
- it is about the most valuable asset: the time of the blue-collars (and the contractors’ and the clients’);
- it is the apex of the maintenance process since it accumulates almost all problems.

I was responsible for the development and implementation of the scheduling system. There was a lot of experience to gain, since reality beat quite a few seemingly fantastic ideas. Ever since I’m passionate about maintenance scheduling.

My key takeaway: systems should be domain-complete first and feature-complete later, otherwise any level of initial acceptance will deteriorate.

3. Norms / maintenance language

Maintenance service cost was calculated based on contracted hourly rates and the actual durations. However, clients usually operate on a maintenance budget, thus not only cost is important, but so is predictability. Therefore, the decision was made to replace the actual durations with predictable „average / norm” durations. A standardized norm system had to be created together with the clients and I became responsible to carry it out.
The number of stakeholders in the project was high, because it involved several sites and dozens of workshops from multiple countries. It was quite an iteration.

My key takeaway: introducing ideas with multiple stakeholders can lead to theory-crafting. Then there is an exponential relationship between the number of stakeholders and the time-need for actual results. Thus, instead of ideas, detailed proposals or usable prototypes should be introduced.

4. LEAN

I was part of a McKinsey led LEAN project for a year. That was my first encounter with LEAN and I instantly fell in love with it. I wanted to learn it all, so I took a LEAN postgraduate course and became a LEAN engineer.
Parallelly I was appointed as the LEAN manager of the company. I had the opportunity to put quite a few LEAN ideas into action and witness successes and failures.

My key takeaway: LEAN can be an umbrella for buzzwords or can be the renaissance of common sense. Introducing new ideas is easy, introducing sustainable new ideas not so much.

The question that changed it all

“Instead of focusing on maintenance cost, what has to be done to ensure a 2-3% measurable efficiency improvement per year?”

Although the question was not directed to me, I didn't have an answer. It stuck with me ever since and changed my understanding of maintenance and LEAN:

1. Maintenance efficiency should and could not be derived from maintenance cost:

Since the opposite was the common view (Solomon Study, etc.), I simply accepted that. The question made me realize that maintenance cost is more of a financial decision than anything else.
My perspective was changed from “how much money is spent” to “how well is money spent.”

2. Something was fundamentally wrong, the focus was misplaced for years:

I felt that everything I did (e.g. the previously described assignments) dealt with a second step and a fundamental first step was missing.
In other words: we were working on going faster, but the direction was overlooked.

3. My grasp on LEAN wasn't that firm evidently:

LEAN is continuous improvement. Since we continuously improved most processes, I believed what we were creating was LEAN maintenance.
But our core function - maintenance - was overlooked. It is repetitive, yet getting better at it was not addressed. The question revealed that I misunderstood continuous improvement, thus LEAN.

It made me obsessed with LEAN maintenance and eventually led to the foundation of LEANtenance Ltd.

An example: inaccurate equipment data leads to low quality plans, low quality plans lead to low quality scheduling.

LEANtenance framework

Domain-complete: a solution addresses all major aspects of a given topic.
Feature-complete: a solution has all the functionality.

The idea for implementing the scheduling system was simple:
domain complete
But I got carried away and prioritized new features:
domain complete

Months have gone by and the scheduling system was not domain-complete: in a heavily contractor dependent field the contractors were not included.
The workshop leaders were forced to use an incomplete system and fill in the gaps however they could. They couldn’t reap the "promised benefits".

Instead of going after features, the contractors should have been included, even if in the most simplistic way.