ECR/ECO（設計変更）の申請フロー設計｜影響範囲・承認・通知を“漏らさない”

設計変更は「図面を直す」だけでは終わりません。
BOM、工程、検査、試験、規格、在庫、出荷、客先提出物──どこか1箇所でも漏れると、現場が後で爆発します。
ECR/ECOのWeb化で狙うのは、スピードよりも 影響範囲を漏らさないこと。そのための項目と画面の作り方をまとめます。

1. ECRとECOを分ける（混ぜると事故る）

現場でありがちな失敗が「とりあえず変更します」でECO相当まで進んでしまうことです。
運用としては、次のように分けた方が回ります。

• ECR：変更要求（なぜ必要か、どこが困っているか）
• ECO：変更指示（何をどう変えるか、いつ切り替えるか）

ECR段階では“影響が分からない”のが普通です。だからこそ、ECOに上げる前のチェックを仕組みにします。

2. 入力項目（ECR）：まずは「理由」と「現象」を揃える

ECRの段階で必要なのは、設計案よりも「何が起きているか」です。
不具合起点なら、受付（RMA）と同じテンプレが流用できます：不具合受付フォーム。

• 変更理由（不具合／コスト／入手性／規格改定／顧客要求など）
• 対象（品番、図番、現行Rev）
• 現象・困りごと（再現条件、写真・ログ）
• 希望時期（いつまでに、なぜその期限か）

3. 影響範囲チェック（ECO）：ここを“チェックリスト”にする

ECOで一番価値が出るのは、影響範囲の棚卸しです。
自由記述だけだと漏れるので、項目としてチェックさせます（Yes/No/要調査）。

• BOM影響：部材置換、代替品、調達先（AVL）
• 工程影響：作業手順、治具、検査ポイント
• 試験影響：再評価が必要か（DVP&Rへのリンク）
• 規格影響：認証・宣言書の更新要否
• 在庫影響：旧品の払い出し、廃棄、区分け
• 客先影響：通知、承認、提出物（PSW等）

4. 承認ルート：固定ルートより「条件分岐」が効く

承認が形骸化するのは、関係ない人まで承認に入ってしまうからです。
条件分岐の例を挙げます。

• 規格影響がYes → 規格認証/品質保証を必須承認
• サプライヤ変更がYes → 購買/品質（SQE）を必須承認
• 客先提出がYes → 営業/CSを必須承認

この条件分岐が作れると、承認が“仕事”になります。インテンスで作る場合も、最初は分岐を少なめにして、詰まりポイントが見えたところから増やすやり方が多いです。

5. 切り替えタイミング：いつから新Revかを曖昧にしない

設計変更で揉めるのは「いつから切り替えるの？」です。
ECOには切り替え条件を必須にします。

• 切り替え日（出荷基準／製造基準）
• 切り替え条件（ロット、シリアル、受注番号、工場など）
• 旧品の扱い（使い切り／隔離／廃棄）

6. 通知：関係者の“見落とし”を前提にする

通知は送ったつもりで終わりがちです。そこで、通知対象を仕組み側で決めます。
例えば「在庫影響Yesなら倉庫・出荷」「工程影響Yesなら製造」「規格影響Yesなら認証担当」など。
通知が多すぎると無視されるので、条件付きが効きます。

まとめ

ECR/ECOを回すコツは、設計案の良し悪しより「影響範囲を漏らさない」ことにあります。ECRで理由と現象を揃え、ECOで影響チェックをYes/No/要調査で持ち、条件分岐の承認にする。切り替え条件を必須にして、通知も条件付きで絞る。
製造業の運用を止めずに整理したいなら、製造業向けシステム開発例の文脈と相性が良いです。