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:
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.
- 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.
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.
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
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.
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:
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.”
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.
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.
Domain-complete: a solution addresses all major aspects of a
Feature-complete: a solution has all the functionality.
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.