|
６ 故障の管理
１ 故障状況の共有化
処理場で毎日点検を行うのですが、点検中に小さな故障から大きなものまでなにがしかの故障を発見します。
故障などは、毎日、「業務連絡ノート」（その日の作業や不具合を記入）が存在し、その日の担当職員全員に引き継がれ「情報共有」されます。
が、過去に書かれた故障で緊急性がない場合等、古くなった懸案事項はその後はアップデートされないケースがあります。
このため、同じ内容をノートに記入してしまい「前にその内容は報告されている」と同僚に指摘される事になります。
業務に集中すべき反省点ですが日々なかなか継続していくことが難しいのが現実です。
故障は、
・引き継がれている故障もあれば、新規のものもあります。
・ささいなトラブルもあれば、プラントの停止に至る故障もあります。
・短時間の対応できるのも長期に時間を有するものもありあります。
・緊急に対応しなければいけないものもあります。
・そのままでも当面運転に支障ないく修理工事の計画に入れるものもあります。
この雑多な故障をどのように「情報共有」していくのか。
また、故障に対処をどのように管理していくのか。
その故障を誰が担当していくのか。
など、故障の差配が問題にもなります。
日々、作業調整を担当しているものの悩みです。
２ 故障状況掲示板 その１
故障状況の共有化として何かいいものはないかと考え、最初に思いついたのは、以下のような処理場全体を描いたボードに
故障ピンを立てる「故障状況掲示板」のイメージです。
参考としては自動車生産現場なのか石油プラントなのか不明ですが、テレビで見た記憶です。
故障が発生するとボードに「日付と番号」をつけた故障ピンを立てます。
故障の対応状態により、ピンの色を変えて行きます。
ピンの数が多く立つ場所は、その設備が故障が頻発しており、設備の修理や改善が必要となります。
欠点として一目見ただけでは、故障の内容が分かりません。
ピン立てには「ピンの色と日付と番号」程度の情報し明示できません。このため故障の内容については別途リストが必要になります。
この方式ですが、さらに以下の支障があります。
（１）そもそもピンを立てる設備全体の詳細な絵を描くのが大変。
（２）ピンを差し替えたりその都度、フォローに手間がかかる。
以上のことから現実的に運用していくのが難しく、他の職員の拒絶反応がでそうなので幻の案となりました。
ただうまく使えこなせれば、単純に「カッコいい」ような気もします。
なお、以下の図は当時は完成しなかったイメージ図です。
３ 故障状況掲示板 その２
次に考えたのが以下のような「故障状況掲示板」（白板にテプラで表示）です。こちらは実際に運用しています。
ホワイトボードに以下のような区分けを行い「故障連絡票」をマグネット付きクリップで貼り付けるようにしたものです。
上記のような設備分けを考慮しなかったので、作成に時間はかかっていません。
故障状況掲示板の「項目」の意味と利用方法
（１）日常・定期点検等の故障
日常点検や定期点検等の故障を発見した場合は発見者が「故障連絡票」に記入してここに添付。
（２）緊急修理が必要な故障
発見した故障で緊急修理や応急修理が必要な場合はここに添付。
（３）調査・修理が必要な故障（修理工事を含む）
現場で調査を行い、修理工事が必要な故障また、再調査が必要な場合はここに添付。
（４）詳細不明な故障（様子見）
調査しても原因がはっきりせず、復帰してしまう故障。長期的にモニアリングが必要な故障。運転継続が可能な場合はここに添付。
（５）修理を要するが緊急時運転可能な故障
自家用発電設備、ポンプ、送風機などで故障修理まで時間がかかる故障で緊急時に運転ができる場合はここに添付。
なお、運用方法の主な取り決めは以下のようにしました。
今、振り返ると掲示板の項目や連絡票の内容等、こなれない部分があり検討の余地がかなりあります。
全体的な仕組みにもセンスがありませんが若かりし日の思い出です。これもでも本人は大まじめです。
当時、設置場所は日常的に目に付きやすい場所として中央監視制御室に設置することにしました。
こちらの有用性は、
プラントの運用に直接影響のない故障や不具合（例えば建屋の不良箇所や管廊の亀裂の水漏れなど）でも、どこかでは直さなければいけない不具合も管理できます。
不具合は何ヶ月、場合によっては年単位でしか解決できないものです。日常点検では当たり前になり忘れ去られるものも確認できます。
この、掲示板があると過去に発見した不具合箇所と同じものかの確認ができたり、今後どのようにしようとしているかが見えてきます。
残念なのは、１年ほど経って掲示板の運用手順が確立してきたと思ったのですが、ほどなく別の職場に異動となりました。
４ 掲示板のその後
|
十年近く経過して、元の職場に異動してきたのですが、残念ながらこの仕組みは継続されていませんでした。
掲示板は、中央監視制御室の片隅に追いやられ別の掲示物（裏面利用）として利用されていました。
新しい考えを継続して行くには、それなりのモチべーションとフォローが必要です。
掲示板を使用しなくなった理由を見知った職員もいるので聞けないことはなかったのですが、ねほりはほり尋ねることはしませんでした。
「７ 合理性と不合理性」
当初も懸念していたのですが、
たぶん、「業務連絡ノート」に記入された部分との「２重管理の手間」がいやがられたのだと推測しています。
また、そこまでしなくても故障の把握が可能との考えがあったのかもしれません。
対応を怠るとなかなか減らない古い「故障連絡票」が掲示板に残ります。
組織的に機能しないとなかなか解決に至らな不良箇所が出てきます。（不都合な真実）
このため、担当者がどのように処置すべきかなかなか見つけるのに苦労が出てきます。
試行期間が短く、組織的業務の中に織り込むことが確立できなかった結果でもあります。
さらに、物事は追加だけでなく減らすという業務の省力化がセットになっていないとなかなか受け入れてもらえません。
改善案には、今回のようにうまくいかない事もあります。空回りすることも多々あります。
ただ、漫然と現状追認の仕事のやり方に不満を持つよりは生産的と考えます。
マンネリとなりがちな維持管理の中で発案が少しでも役に立てば小さな「承認欲求」が満たされることもあります。
|
５ 今後の展開
この失敗事例は、アナログ過ぎたことも敗因かもしれません。
現在では、ＯＡ機器を駆使することによって手間が克服できるようになっています。
故障状況掲示板の「その１」でも「その２」でもパソコン上に表示させることはそれほど難しいことではありません。
オンラインでプラントとリンクするのか。オフラインとするのかは別として、「業務の引き継ぎノート」・「掲示板」・「故障報告書」等が一体とすることも可能と考えます。
ただ、勤務した職場でも部分部分のＯＡ化をしてきていますが、全体を統合している処理場を中々見ません。
全国にはさらに優れた実用レベルのシステムを具体化された処理場があると思われますが細かい情報は伝わってきません。
システム化を進める上で誰がシステム設計を構築するのかの問題はいつも残ります。
企業に作らせるとなれば現状ではかなりの費用と大きな期待値（便利になっているはず）が要求されることになります。
直営で構築すると期待値は低くすること（以外と便利）は可能ですが、複数の職員の気力と努力が必要です。
|