エンジニアリング変更を管理する
設計変更や技術変更を適切な統制のもとで進める。理由とリスクを添えて起票し、それが生む技術的な疑問をRFIで解消し、コストや工期への影響を変更指示に反映する。
仕組みをステップごとに
プラットフォーム全体で3ステップ - 各ステップで何をするか、そしてなぜ重要か。
統制のもとで変更を起票する
変更管理(MoC)提案された変更について管理変更(MOC)記録を起票し、何がどう変わるのか、その理由、そして安全・運用・設計上のリスクを明確に記載する。作業に着手する前にレビューへ回すこと。
理由: 管理ステップを飛ばしたエンジニアリング変更は、善意の修正が安全性や法令適合性を損なう結果につながりやすい。この記録は、リスクが検討され、変更が単に実施されただけでなく正式に承認されたことの証拠となる。
技術的な疑問を解消する
RFI変更が生じさせる未解決の技術的な疑問(寸法、取り合い、仕様など)についてそれぞれRFIを起票し、詳細が確定する前に設計者から書面で回答を得ます。すべてのRFIを元の変更に紐づけたままにします。
理由: 仮定の上に組み立てられた変更は、手戻りの種です。設計責任者からの記録に残る回答を得ることが、同じ疑問が現場で再び蒸し返されるのを防ぎます。
影響を変更指示に反映する
変更指示書変更がコストまたは工期を動かす場合は、価格付きの影響と工程への影響をとらえた変更指示を起票し、元の変更記録に紐づけます。影響が実質ゼロであれば、それも記録します。
理由: 技術的な側面は解決していても、金銭面は未解決のまま残ることがあります。変更指示こそが、承認済みの変更を合意済みのコストと変更後の期日に変え、いつの間にか自社の負担になることを防ぎます。