変更管理に関する8つの一般的な誤解

プラント担当者の変更管理について言及するときはいつでも、通常、いくつかの予測可能な応答の1つを受け取ります。知識のある人は、OSHA 1910.119（a）（2）の規制を引用し、それらは「対象となるプロセス」ではないため、適用されないことを教えてくれます。もう1つのよくある回答は、「図面管理手順がありますが、それに追いつく必要のない年数とリソースがかかるため、はるかに遅れています。」です。他の人は、彼らのマネージャーが小さなプロジェクトや変更を承認するための完全に素晴らしい手順を持っていると私に言うでしょう。そして、車の灰皿を埋め尽くすペニーとニッケルについてひそかに考える人もいます。

では、変更管理（MOC）とは何ですか？ソースに戻ると、OSHA 1910.119（l）（1）は、MOCの要件を次のように設定しています。手順;そして、対象となるプロセスに影響を与える施設への変更。」

その短い説明は多くの領域をカバーしていますが、プロセスの安全性を高めるためだけに公布されたため、「カバーされたプロセス」への法的適用を制限しています。施設が「対象プロセス」のOSHA要件を満たしている読者は、MOCの詳細な要件をよく知っています。そうでなければ、まだ動作していません。そして、最近の歴史の中で最悪の労働災害の多くが根本的な原因としてMOCプロセスの失敗を引き起こしていることを皆さんが知っていることを願っています。一部の情報筋によると、業界における重大な重大事故の80％は、制御されていない変化に関連しているとのことです。したがって、MOCは、事故を防ぐことで報われる一種の生命保険と考えることができます。

ただし、この記事では、対象となるプロセスのMOCの複雑さに焦点を当てていません。そして、それは安全だけに向けられているのではありません。それでは、MOCが業界に「必須」ではないのに、なぜMOCについて話し合うのでしょうか。つまり、法的要件に関係なく、すべてのビジネスが潜在的な損失を管理する必要があるためです。また、適切に適用されたMOCは、ほとんどすべてのビジネスにとって優れた費用効果の高い損失防止プロセスです。これは、損失除去プロセスを完全に補完するプロセスです。そして、私たちは皆、安全で環境にやさしいことを望んでいますよね？

MOCは、現在存在するものへの変更のみに対処することに注意してください。新しいプロセスや設備の設計は、まったく別の問題です。そして、MOCの議論の目的のために、既存のシステムのパフォーマンスのレベルは、十分ではないにしても、少なくともよく知られた、よく知られた美徳と悪徳を持っていると仮定する必要があります。

では、非規制用語でのMOCとは何ですか、そしてそれは実際に誰に適用されますか？この簡単な定義で作業してみましょう。MOCは、施設またはプロセスの構築、運用、管理、または修復の方法に加えられた変更の結果として、安全性、健康、または環境の低下を含むビジネス損失を防止または軽減するためのプロセスです。規制要件はさておき、適切なMOCプロセスを実施しない余裕のある競争力を維持することを目的としたビジネスはありません。要するに、MOCは安全性にとって意味があり、経済的にも意味があります。 MOCプロセスはあなたのビジネスにとって意味がありますか？

「変更」とは何ですか？
「変更管理の最も難しい部分は、変更を認識することです。」 プログラムの最も重要な出発点は、管理したい「変更」を構成するものを組織に明確に定義することです。または、もっと簡単に言えば、どのような変更がMOCプロセスに該当し、どのような種類の変更が該当しないのでしょうか。明確な定義の欠如は、MOCプログラムの有効性を効果的に損ない、不必要な分析の麻痺を招き、プロセスをバイパスしたい人のための抜け穴を作成します。

多くの異なるソースからの変更の多くの定義があります。ビジネス上の利益および規制上の先例と一致する用語で変更を定義することは、サイトのリーダーシップの責任です。どのようなリスクを管理したいのですか。また、管理しなかった場合、どのような変更を行うと、それらのリスクが高まりますか。そうして初めて、「変更」として合理的に定義される可能性のある活動を明確に特定できます。特定されたら、可能な限り最も単純でわかりやすい言語で伝える必要があります。
少し面倒ですが、リストまたは例の表を使用します。多くの場合、ポイントを伝えるために必要です。資格を得るために、ハードウェアの一部に「変更」が発生する必要はないことに注意してください。ソフトウェア、手順、およびプロセスパラメータはすべて、ハードウェア以外の変更の例であり、多くの場合、厳密に制御する必要があります。

ハードウェアを扱う場合、OSHA 1910のソースドキュメントでは、変更を「現物での交換」（RIK）ではなく、さらにRIKを「設計仕様を満たす交換」と定義しています。 RIKは通常、形状、適合性、機能が同一の機器またはコンポーネントを指します（F3と呼ばれます）。しかし、この非常に狭いハードウェアベースのアプローチよりも変更すべき点があります。 OSHAの変更の定義は、技術、手順、および化学物質（より広義には原材料として解釈されます）も指します。明らかに、「変更」の定義にはハードウェアだけではありません。 MOCプロセスの「変更」に使用される最良の正式な定義は、OSHA 3313で公開された説明にあります。「変更とは、既存のシステム内のコンポーネント、変数、またはプロパティの変更または調整です（明確に定義された境界または責任）。」

すべてのビジネスにはリスクエクスポージャーの異なる領域と望ましくない結果の異なる許容度があるため、リスクを評価し、制御されていない変更に対する許容度を定義するのは各ビジネスの責任です。ビジネスが管理したいと思うかもしれない種類の変更のいくつかの（しかし、すべてを含むわけではない）例は次のとおりです。

• 新しいプロセス機器または重要なビジネスシステム（ソフトウェアを含む）の追加
• プロセス機器または部品の「現物ではない」交換
• プロセス機器の変更またはマイナーな追加
• 重要なビジネスシステム（手続き型またはソフトウェア）の変更またはマイナーな追加
• インフラストラクチャ/非プロセス機器の変更またはマイナーな追加
• プロセス制御および/または計装の変更（制御戦略を含む）
• テクニカルMROの仕様または調達の変更
• 重要なプロセスパラメータの動作制限の変更（標準操作手順[SOP]で指定された範囲外）
• 安全システムの変更（インターロック、シャットダウン、火災または爆発の抑制など）
• 標準操作手順（緊急手順を含む）の改訂
• サイトレベルの組織構造の変更
• メンテナンス手順の変更
• 原材料/コンポーネントの仕様または調達の変更
• ユーティリティシステム（空気、電気、ガス、水、蒸気など）への変更または新しい接続。
• 重要なデータネットワークへの変更または新しい接続
• QA手順または重要なテスト機器の変更

プロセス設計の早い段階で学際的なチームが数時間の質の高い「もしも」ブレーンストーミングを行い、ビジネスに適した定義と例を開発することで、多大な利益が得られます。

「一時的な」変更についてはどうですか？
MOCを実装するときに適用するこの重要な概念を覚えておいてください。一時的な税金ほど永続的なものは世界にないのと同じように、MOCプロセスから逃れた「一時的な変更」ほど永続的な変更はありません。経験によれば、実際には、元の状態に復元されるまで一時的なものであることが意図された永続的な変更のみがあります。発生するすべての制御されていない変更の中で、「一時的な」変更は、事故や事故の最も有害で最も頻繁な原因です。したがって、制御システムの「一時的な」変更は、MOCプロセスから除外されるべきではありません。

では、日常業務を実行するために行わなければならない一時的な変更に対処するにはどうすればよいですか。定期的なメンテナンスを実行するためのインターロックバイパス？それが本当に日常的なものである場合、あなたが持っているのは、SOPからの定期的な逸脱の永続的な状態です。そして、それに対処する正しい方法は、状況を恒久的な変化として扱い、適切な保護手段を備えた承認された手順に組み込むことです。何かが非定型の一時的な変更として意図されている場合は、それを変更として扱います。 OSHA 3133は、説明の中で次のように述べています。「MOCの手順では、一時的な変更の終了時に機器と手順が元の状態に戻るようにする必要があります。」歴史と慎重さは、「一時的な」変更は、ビジネスに最大のリスクをもたらすため、MOC手順に特別な注意を払って「永続的な」ものとして管理する必要があることを示唆しています。

MOCに関する8つの一般的な誤解
1）「しかし、私は実際の変更を行っていません。少しだけ良くしています。」
部品/機器/ビジネスシステムを作業開始前とまったく同じように残していない場合（もちろん、修理の対象となった損傷がない場合）、変更を加えたことになります。 。変更がMOCプロセスの範囲に含まれるかどうかは、手順で設定された基準によって決まります。採用するデフォルトのアプローチは、構成、形状、適合、機能、材料、または手順の変更は、手順の基準を調べて別の方法で証明されるまで、MOCの対象であると想定することです。

制御されていない「一時的な変更」に次ぐ、意図的なマイナーな改善は、MOCの失敗のカテゴリに分類されるインシデントの2番目に大きな原因としてランク付けされます。全体的な運用状況と環境を徹底的に評価しなければ、ある意味で「より良い」というのは、実際にはそれほど悪くはなく、別の意味でははるかに悪いと誰が言うのでしょうか。 1人の患者に与えられた同じ薬は強力な治療法になる可能性があります。別の人にとっては、それは致命的な毒かもしれません。同じことが、善意であるが管理されていないマイナーな「改善」、特に特に危険な材料の代替にも当てはまります。この一般的な落とし穴を認識して回避するようにすべてのレベルの担当者に教えてから、厳密に実施してください。規則を破ったことで人々を懲らしめることを好む人は誰もいません。特に彼らがそれを改善の精神で行う場合はそうです。しかし、今夜誰かが帰宅しないことを家族に伝えなければならないのは非常に悪いことです。

2）「私ははるかに遅れており、MOCを始めることができません。改訂されていないすべての図面に追いつくことは決してありません。」
ドキュメント管理は、適切に設計されたMOCプロセスを補完するプロセスであり、MOCについて言及するときに人々が最初に考えることがよくあります。ドキュメントを更新する必要性は確かにMOCの頻繁な結果であり、プロセスと機能の長期的な整合性に必要ですが、MOCではありません。

ドキュメント制御プロセスを使用してMOCを実装する場合、多くの場合、前の人からかなりの混乱を継承します。図面がない、不正確な図面、古いドキュメント.. 。あなたはそれに名前を付けます。状況が悲惨な場合、システムの重要度に基づいている場合は、是正措置を優先することを余儀なくされる可能性があります。一部は修正する必要がない場合があり、修正されることはありません。確かに、重要な情報が発見されたときにそれを修正する方法は、作業管理手順に簡単に組み込むことができ、組み込む必要があります。ただし、悪い習慣を続けてタスクに追加しないでください。

過去に起こったことを変更することはできません。過去の過ちを修正または軽減するためのビジネスケースが存在する場合は、そうしてください。 MOCは将来の損失防止に関するものです。したがって、どの組織でもできることの1つは、今すぐMOCの実装を開始することです。今日は、明日のためにさらに多くの問題を作成するのをやめる日です。簡潔な民俗の知恵は、「本当の大きな穴を埋める必要がある場合、最初にすべきことは、それを深く掘り下げるのをやめることです」と述べています。同じことが貧弱なMOCによって作成されたギャップにも当てはまります。大きくするのはやめましょう。

3）「MOCの評価を待つ時間がありません。これは緊急事態です！」
緊急時は、確立されたMOCプロセスによって課せられる自己規律が最も必要なときです。旅客機に飛行中の問題がある場合、パイロットは最初に頭に浮かぶことをしません。むしろ、彼らはチェックリストを引き出して考え、そして行動します。 「緊急事態」があるとき、そうすべきです。置換を可能にするこの「マイナーな変更」は、正しいパーツを取得する場合と比較して、実際に多くのダウンタイムを節約するのでしょうか。小さな変更は、予想よりもはるかに時間がかかることがよくあります。

この「迅速な回避策」が実際にかかる時間、金額、リスクの増加を現実的に評価してください。緊急時に楽観的になるのは良いことです。最悪の事態に備えるのが最善です。ことわざにあるように、「海から遠く離れた漏れのある船に乗っている場合は、天国に向かって祈るのが最善ですが、岸に向かって漕ぐのが最善です。」 「一時的な」バイパスに関連するビジネスへのリスクは、時間の節約に値しますか？ 「特別な操作手順」によってリスクを許容可能なレベルに本当に制御できますか？

事故報告によると、バランスの取れた評価なしに圧力の下で行われた急いでの決定が、多くの深刻な問題の根源になっています。 。規律ある方法で考える時間は無駄な時間ではありません。また、MOCプロセスが効率的である場合、それが真の緊急事態であるまれな場合に、進行を過度に妨げることはありません。必要に応じて緊急作業命令を承認して発行する手順があるのと同様に、優れたMOC手順には、実際の緊急事態に対処するメカニズムがあります。しかし、そのメカニズムはMOCを無視することであってはなりません。 1回の「緊急事態」の間に、より大きく、より深刻な2回目の緊急事態に備えるための便宜を許可しないでください。地雷を植えるためだけに爆弾を解体しないでください。

頻繁に障害が発生し、対処が必要な場合、予期しない障害から回復するために深夜の部品交換を常に行う必要がある場合、または一定の場合不安定なコンポーネントや原材料に対応するためのプロセス変更？次に、MOCを無視したり、アナーキーをサポートするMOCプロセスを設計したりしないことが課題になります。むしろ、効果的な根本原因障害分析（RCFA）プロセスと、慢性的な障害を排除するための予防保守/予知保全プログラムを実装することにより、これらの状況を排除することに注力する必要があります。次に、MROプロセスの欠陥を修正して、常に適切なパーツを使用できるようにします。そして最後に、標準的な作業手順と材料サプライヤー認定プログラムを使用してプロセスを安定させる必要があります。

4）「このフォームを承認に回すには時間がかかり、何もできません。」
効果的なMOCプロセスには、適切なレベルの承認とコミュニケーションが必要です。不十分に設計されたMOC承認手順は、変更が発生した後に変更を通知する必要性と、変更が発生する前に承認する必要性を混同します。必要な承認のレベルは、変更とそれに関連する潜在的なリスクの両方に適切である必要があります。また、目前の状況に合わせて調整できるように、十分な柔軟性が必要です。承認者の数を最小限に抑え、適切な承認者にします。その後、MOCプロセスを安全に合理化できます。

5）「しかし、私のエリアマネージャーはすでに変更のための資金を承認する必要があります。」
決定を下す権限と、その決定を下すために必要な知識を持っていることを混同しないでください。すべての変更、そして多くの場合最も重要な変更が、資金提供の承認を通過するわけではありません。多くの場合、変更を加えるリスクや変更の技術的妥当性を評価するのに最も有能な人は、エリアマネージャーではなく、それに最も精通しているオペレーター、メカニック、スーパーバイザー、またはエンジニアです。

マネージャーは非常に有能であり、特定の変更のすべての側面または結果について1人の人が有能であることはめったにありません。効果的なMOCプロセスでは、適切な指定されたリソースが提案された変更のバランスの取れた評価に関与していることを確認するのはマネージャーの責任です。承認権限は評価能力に次ぐものであり、バランスの取れたチームは、1人の賢い個人に依存するよりも一貫して良い結果をもたらします。

6）「私たちは倉庫/軽工業/データですセンター/修理施設。 …危険なものはありません。」
MOCは、変更に関連する潜在的な自傷行為によるビジネス上の損失をすべて防止または軽減するためのプロセスであることを忘れないでください。プロセスの安全性だけでなく、他にも損失があります。制御されていないプロセス変更により、製品の汚染または欠陥が原因で大切な顧客を失う場合、それは損失です。データセンターがダウンしていて、電気図面が変更に追いついていないためにトラブルシューティングに数分ではなく数時間かかる場合、それは損失です。自動スタッカーがダウンしていて、「小さな変更」が必要な深夜の部品交換により、在庫のある唯一の交換部品が適合しなくなったため、製品を出荷できない場合は損失になります。文書化されていない制御ソフトウェアへの変更により、最新のセキュリティパッチがインストールされているときに自動テストマシンが失敗した場合、それは損失になります。これらはすべて実際の例であり、リストは無限です。変更によって環境に危険な状況が発生する可能性はわずかですが、施設やプロセスが主要な任務に失敗すると、私たち全員が失うものがあります。

7）「しかしMOCは勝ちました考えられるすべての問題を把握できるわけではないのに、なぜそれを行うのですか？」
あなたは絶対に正しいです。あなたの最善の努力にもかかわらず、いくつかの問題は検出されないままになります。しかし、MOCを行わないと、何人がすり抜けてしまいますか？リスク管理とは、オッズを変更してあなたに有利になるようにすることです。この議論は水を保持しません–一部の人々がエアバッグに対して使用する議論にすぎません：「彼らは展開して事故を引き起こすかもしれないので、私はそれらをオフにします。」統計は、MOCがないことをサポートしている以上に、その考え方をサポートしていません。

では、意図しない結果を見逃した場合はどうなりますか？複雑なシステムにおけるMOCの貴重な追加の利点は、RCFAを実行する場合です。変更による悪影響があり、原因がすぐに特定できない場合、行われたすべての意図的な変更のリストがあれば、RCFAははるかに迅速に実行されます。そして、その時は本当のお金になることができます。あるケースでは、MOCレコードを調査することで、一連のプロセスプラントの障害の根本原因を見つけるために必要な時間が数週間短縮されました。ダウンタイムによる損失を回避するために1日あたり25万ドルで、MOCの取り組みは、問題を防ぐことはできませんでしたが、かなりの投資収益率を実現しました。

8）「これは単なるソフトウェア/手順の変更です。パイプなどを交換していたわけではありません。承認したり文書化したりする必要はありません。」
MOCの対象ではなかったソフトウェアまたは手順の変更により、多くの業界で非常に重大なインシデントと重大な損失が発生しました。さらに、ドキュメントまたはコードが変更され、変更が反映されているからといって、変更がドキュメント化されているとは限りません。コード内のコメントとドキュメント内のリビジョンフラグにより​​、検索者は変更を探すことができます。しかし、ソフトウェアや手順の変更が適切にレビューされていないために予期しない問題が発生した場合、それはどのようなメリットがありますか？

何千行ものコードを探して必死に検索しているときに、生産ラインをダウンさせましたか？制御エンジニアが別の仕事に出る2か月前に行った変更は？特にプログラマーや制御エンジニアは、MOCを十分に考慮せずにソフトウェアを「いじくり回す」傾向があります。これは、プロセス制御だけでなく、重要なビジネスシステムソフトウェアにも当てはまります。潜在的なリスクが存在し、それを正当化する場合は、コード行の変更を安全シャットダウンシステムの再配線と同じように扱います。同じレベルの精査と管理を受ける必要があります。

結論
結論として、適切に設計されたMOCプロセスは、あらゆるビジネスにとって不可欠な損失防止ツールです。特定の危険な産業だけのものではありません。このプロセスは、今日の変更に起因する将来の損失を回避したいすべての企業に適用されます。 MOCは、変更を妨げるほど使いにくい、または使いにくいものである必要はありません。過去の脱落を簡単に補うことはできず、将来のリスクを減らすだけです。したがって、効果的かつ効率的なMOCプロセスの開発と実装を開始する時期は今日です。

この記事は、Life CycleEngineeringのニュースレターRxTodayの7月版に最初に掲載されました。

作者について：
Sam McNairは、ライフサイクルエンジニアリング（LCE）のシニアコンサルタントです。プロフェッショナルエンジニアであり、認定されたメンテナンスと信頼性のプロフェッショナルであるサムは、ディスクリート製造、化学プロセス産業、鉱業、機械プロセス、自動化、航空、建設、ユーティリティで32年以上の経験があります。サムは、保守機能と製造機能の統合に焦点を当てた信頼性エンジニアリングを専門としています。あなたは[email protected]でサムに到達することができます。ライフサイクルエンジニアリングの詳細については、www.LCE.comにアクセスしてください。