TPMイニシアチブが失敗することがある理由

最近の記事で、私はプラントの信頼性管理方程式にオペレーターを関与させることについての私の見解を提供しました。開始するのに最適な場所は、操作を標準化することにより、オペレーターが正しく一貫して動作するようにすることです。

次のステップは、検査、プロアクティブな作業の識別、作業の優先順位付け、および計画を行う信頼性にオペレーターを関与させることです。次に、見た目が良ければ、オペレーターが関与するメンテナンスに進むことができます。このメンテナンスでは、オペレーターが従来のメンテナーの代わりに特定のメンテナンスタスクを実際に実行します。

リーン生産方式の一環としてオペレーター主導の信頼性を実装している人にとっては、おそらくこれをTotal Productive Maintenance（TPM）と呼んでいます。よくある落とし穴を回避するために、TPMイニシアチブが失敗することがある理由についていくつかの観察結果を提供します。決して網羅的ではありません。

1）運用（本番）管理はOEEを所有していません： これは間違いなく最も重要な要素です。運用/生産管理チームが設備総合効率またはOEE（可用性x歩留まりx品質）を推進する責任を負わない場合、TPMは機能しません。

一般に、リーンおよびプラントの信頼性管理イニシアチブは、この場合は機能しません。信頼性とOEEは「メンテナンス」ではなく、決してそうではありませんでした。運用では、TPMが信頼性を促進する方法、信頼性がリーンを促進する方法、およびリーンが利益を促進する方法を認識する必要があります。オペレーターをTPMイニシアチブに参加させるための緊急性を持っている必要があります。

2）チームはTPMの内容と理由について教育を受けていません： 上記のように、一般的な信念に反する信頼性は、単にメンテナンスの同義語ではありません。メンテナンスとは、機器を稼働状態に戻すことです。信頼性とは、そもそも機能の喪失を回避することです。歴史的に「修正」担当者と定義されてきた保守チームにとって、信頼性は彼らの自己認識に挑戦します。心理学は強力なものです。

彼らは、「物事が失敗していなければ、私の価値貢献は何ですか？」と考えています。同様に、信頼性の方程式に操作を含めることの明らかな重要性にもかかわらず、オペレーターはこれを理解するのに苦労することがあります。双方の所有権が必要です。

3）オペレーターが関与するメンテナンスを開始できない： 多くの場合、TPMイニシアチブは保守部門によって推進され、運用とオペレーターが関与する信頼性の向上をスキップします。 Leeryの運用監督者やオペレーターは、これを策略と見なすことがよくあります。メンテナンスは、運用にその仕事をさせようとしています。

イニシアチブがメンテナンスマネージャーの上から推進されている場合でも、運用はメンテナンスを非難する傾向があり、責任を回避してそれを放棄しようとしていると主張します。適切な操作を標準化することから始めるのが最善です。

そこから、検査を実施し、作業完了の優先順位を設定し、機器を清掃することで、オペレーターを信頼性に関与させます（検査が容易になります）。オペレーターが関与するメンテナンスを徐々に容易にし、実際にメンテナンス作業を実行します。

4）検査が技術的になりすぎ、複雑になりすぎる： 組織は、振動分析やサーモグラフィなどのクールな予知保全技術に夢中になっています。そのため、基本的な目視検査やゲージベースの検査をスキップして、ハイテク技術にすばやく移行することがよくあります。

これは、特にオペレーターレベルではうまく機能しません。組織は、高度に技術的な資料でオペレーターを訓練するために多額のお金と時間を浪費することになります。彼らは圧倒され、落胆します。

高度な技術的監視を容易にし、ほとんどの努力を基本に集中させるのが最善です。ヒントとして、すべての検査をバイナリにします-はいまたはいいえ。定量的なデータでもこのように扱うことができます。たとえば、「気温は華氏130度から135度の間です-はいまたはいいえ」。シンプルにしてください。

5）TPMの展開は表面的なものです： 多くの場合、プラントでは、TPMの非常に表面的な実装が見られます。したがって、総合的生産管理ではなく、「完全に塗装された機械」を入手します（信頼できるプラントの仲間を聞いたことがあります） コラムニストのジョン・シュルツは何度も言います。

通常、これらは短期的な「ウィンドウドレッシング」イニシアチブであり、永続的な価値を生み出さず、組織を苦しめます。そのため、将来、TPMの実装を本格的に試みた場合、組織は「そのTPMを試しました。もの、そしてそれはうまくいきませんでした。」

6）検査結果と事前の作業識別はどこにも行きません： チームがオペレーターレベルで検査と作業識別プロセスを実施し、結果を無視することは、反対の動機付けになります。これは、TPMイニシアチブを停止するための迅速な方法です。オペレーターは興味を失い、作業を完了できないか、検査を「鉛筆でむち打ち」ます。

あなたは本当に彼らを責めることができますか？事実上無意味な仕事をするのが好きな人は誰もいません。 TPMプログラムがフラストレーションから失速するのを防ぐために、検査に対応し、オペレーターが特定しているプロアクティブな作業を完了するバックエンド機能があることを確認してください。

7）報酬構造の不整合： 何十年もの間、私たちは報酬システムの問題とミスアライメントを抱えてきました。設計チームは、最低の購入価格で機能的な機能を実現することで報われます。それが運用および保守管理者にもたらす下流の問題と、真のライフサイクル所有コストを気にしないでください。

生産チームは、製品の需要があるかどうかに関係なく、彼らの行動が資産の健全性に与える影響を尊重せずに、生産数を達成することで報われます。メンテナンスチームは、信頼性ではなく、常に失敗に対して報われてきました。

彼らは、機器が壊れたとき（残業）、不便な時間に修理するために経営陣から「アタボーイ」（もちろん残業代を受け取っている間）で追加料金を受け取ります。あなたが失敗に対して報われていたなら、あなたは信頼性を望みますか？ステップアップして、10％または20％の減額を志願しますか？

人々は、彼らの行動で何をするかについて、彼らのリーダーが彼らの言葉で言うことにほとんど注意を払っていません。リーダーシップチームが信頼性を求めているが、外的および内的の両方で失敗の代償を払っている場合、失敗が発生します。システムが壊れているため、修正する必要があります。 TPMは、不整合な報酬構造で生きることはできません。

これらの洞察が、リーン生産方式の一環としてTPMを実装する際に役立つことを願っています。