Restore basic conditions, often shortened as RBC, is a very philosophical way in TPM.
A person who has grown with TPM must have this philosophical way of thinking. It clearly makes them different from other methodologies such as Six Sigma. In this writing, I would like to share my thoughts about RBC along my 17 years growing with TPM.
In 2019, I joined a Six Sigma Green Belt class. As someone who grew up with TPM, I tried to digest the DMAIC steps used in team improvement. Like other improvement team steps outside TPM, I couldn’t find the “restore basic conditions” step there. Then I asked the trainer about the philosophy of RBC, trying to help him understand what RBC is, and where it might fit in DMAIC.
He thought for a moment and answered, “Maybe it can be close to a quick win.” In Six Sigma DMAIC, quick win is a sub-step in “Define,” where before doing deep analysis, we solve what is obvious.
After completing the course, I realized that quick win might include some RBC activities, but definitely it is not the same. Perhaps RBC can unintentionally be covered by some activities, but it is not formally there.
The same question appeared when I moved to another company with a very strong continuous improvement culture. That company used 8 steps, and again I questioned myself: where is “restore basic conditions” placed among those 8 steps? Fortunately, some employees there also had grown up with TPM, and finally we agreed to put RBC activities in the 3rd step, which in Bahasa we called Anakonda – Analisa Kondisi yang Ada.
I noticed that originally, the 3rd step in the 8-step improvement route was not intended for RBC. It was supposed to be the step where we grasp the phenomenon of what actually happens. But as we analyze what is happening and compare it with what should happen, we will naturally identify some basic conditions that need to be restored.
Japanese people, before improving something, always make sure that basic conditions are achieved first.
Tokutaro Suzuki in his book TPM in Process Industries gave a strong statement based on actual facts: that 70–80% of problems in a company are solved just by restoring basic conditions. It is simple and logical: if we can solve 80% of our problems (for example, reducing cost, increasing utilization, etc.) just by restoring basic conditions, why should we start with something else?
The question then appears: what is the definition of basic conditions, and how can we restore them?
I admit, based on my experience, it is easier to explain the practical activities of restoring basic conditions rather than to provide an exact definition. At one occasion, I had a deep talk with my former boss, who was an ex-P&G employee and contributed to developing IWS (Integrated Work System).
IWS itself is a strong system developed by P&G, based on their 30 years of experience with TPM combined with other methodologies such as Six Sigma, Lean, etc.
As the new Indonesia IWS Manager appointed by him, I asked, “How do you define basic conditions?”
After a long discussion, argument, and debate, we finally came to a definition that might not be written in any TPM book:
Basic conditions are when we have gone through the associated machine and can find no more tagging (abnormalities) through deep checking.
But then more questions appeared: someone who is “awam” (not an expert) in the machine might spend the whole day checking and still not find any abnormalities. In that case, of course, we cannot say the machine is at basic conditions. We realized the statement was incomplete.
After thinking more deeply, we realized the previous definition was almost correct, but missing one key point: who should do the deep checking. The correct definition is:
Basic conditions are when subject matter experts of the associated machine have thoroughly checked it and can no longer find tagging (abnormalities).
Another experience that made me contemplate about RBC is related to team improvement. In my journey with TPM, pillars work to eradicate losses through team improvement. I have gone through many improvements, and the pattern is always the same: after setting up data collection and understanding the current situation, which allows us to forecast the target, the next activity is always restoring basic conditions in the critical areas associated with the loss.
It is common in TPM organizations: go directly to the critical areas (often machines), seek abnormalities (tagging), and fix them.
Based on long experience, I truly agree with many TPM experts that 70–80% of problems can be solved just by making sure basic conditions are achieved. Once, I experienced a chronic quality problem that had existed for years. It was solved just by discovering a wrongly installed gasket before a static mixer. Before the team improvement, many activities had already been done: analysis, brainstorming, etc., but the real problem was basic conditions.
If you ask me what is the unique characteristic of TPM team improvement: it really emphasizes restoring basic conditions. Actually, not only team improvement; the core of most TPM activities is to make sure machines, processes, and materials are at the level of basic conditions.
In 2017, I was appointed as National IWS Manager at a world-leading cigarette company in one country. As someone who had grown up strongly with TPM, I needed to adapt a bit to IWS.
As mentioned before, IWS—often called TPM of P&G—is P&G’s journey of 30 years with TPM.
I had to calibrate some terminology, which sometimes was different but actually had the same meaning. For example, they use “defects” instead of “tagging,” or “PdM (Product Defect Matrix)” instead of “QA Matrix.” I was not too concerned about different terms.
But what surprised me was when I tried to understand their team improvement method, called UPS (Unified Problem Solving). Like other methodologies, it has structured steps—but there is no specific step that mandates restoring basic conditions.
How could a system inherited from 30 years of TPM experience not have RBC? It seemed impossible. I thought, “There must be an answer.”
Then I found it: in IWS, the people in the line must apply what is called IPS (Initial Problem Solving) for every problem they face daily.
What is IPS? IPS is a form that asks the operator to check:
- Whether the machine was operated according to standard
- Whether maintenance was done according to standard
- Whether the raw materials are within specifications
- Whether CILT activities were implemented according to standard
- Whether process parameters are within standard
- Whether there are no abnormalities (tagging/defects)
As TPM implementers believe, if we make sure these aspects are in basic conditions, we should be able to solve 80% of problems.
IWS also believes that if a problem is found in daily life, it should be solved through IPS. Only when IPS cannot solve it, the team launches UPS.
In my first year in IWS, some operators complained: “Should we fill out the IPS form so many times for the same recurring problem? It feels ridiculous.” At that time, the form was filled manually with a pen, and they were bored.
I paused and reflected: What is actually wrong?
The real question was: Why can’t IPS solve the problem?
Then I checked the stack of IPS forms. I found several root causes, but the main issue was: they didn’t understand the philosophy behind IPS. They didn’t know that IPS was meant to ensure basic conditions were restored. Nobody taught them properly.
For example, in the IPS form, there are cells for “Where?” and “Where not?” Why do we have to fill them?
Imagine we want to solve a specific product defect, like cigarettes with oil spots. The team in the shift knows they must look for abnormalities (tagging). But where should they start?
If the defect appears on all lines, it might come from a previous process common to all lines. But if it happens only on Line 6 and not Lines 1–5, the operator must focus inspection on Line 6.
This helps direct the genba activities: go to Line 6, find abnormalities, and fix them.
Unfortunately, in practice, the operators saw IPS as just paperwork to reach KPIs, not as a tool to restore basic conditions and eliminate problems.
I strongly believe every element of OE (Operational Excellence) needs managers who understand the philosophy of every tool and can explain it simply.
Back to UPS: in IWS, UPS should be launched only when IPS can’t solve the problem. But sometimes, people skip directly to UPS analysis, assuming IPS has already ensured basic conditions, when in fact it hasn’t.
In TPM, pillars aim to eradicate losses. Autonomous Maintenance (AM) helps organizations eliminate losses due to failure to maintain basic conditions. Through AM steps (1–7), employees are trained to care for machines, starting with cleaning and inspection, supported by a strong tagging system.
One company once asked me: if they don’t implement TPM or IWS, can they still make sure basic conditions are achieved?
Yes, they can. I suggest strengthening the PM system and implementing a solid tagging system. But the hardest part is ensuring leaders truly “buy in” to this philosophy. Sometimes, it might even require hiring leaders with proven experience in these systems.