製品の設計変更では、図面やBOMを更新するだけでなく、製造工程、検査方法、認証書類、在庫、仕掛品、取引先への案内なども確認しなければなりません。変更内容が小さく見えても、関連する部門や文書は広範囲に及ぶことがあります。
メールや口頭で設計変更を進めていると、変更理由や承認結果は残っていても、その変更がどの業務へ影響するのか、旧版の部品をどう扱うのか、いつ新しいRevへ切り替えるのかが明確にならない場合があります。
たとえば、図面は新しいRevへ更新された一方で、製造現場には旧版の作業手順書が残っている、検査部門が変更を知らず従来の条件で試験している、倉庫にある旧部品の使用可否が決まっていない、といった状態です。
ECR/ECOをシステム化する目的は、申請書を電子化することだけではありません。変更理由、影響範囲、承認、実施条件、関係者への通知、変更完了までを同じ案件として確認できるようにすることが重要です。
この記事では、製造業におけるECR/ECOの一般的な考え方を基に、申請項目、影響確認、承認ルート、Rev切替、旧品処置、通知、変更完了の管理方法を解説します。
設計変更の申請フローを作る際は、最初にECRとECOの役割を決めます。両者を区別せず、ひとつの申請書で変更提案から実施指示まで行うと、検討中の内容と実施が決まった内容が混在します。
ECRを起票した時点では、変更方法や影響範囲が確定していないことがあります。その状態で実施日や在庫処置まで入力必須にすると、根拠のない予定が登録されたり、入力欄を埋めるためだけの回答が記載されたりします。
ECRでは変更の必要性を検討し、技術的な対応案と影響範囲を確認した後、実施する変更をECOとして確定する流れが分かりやすいでしょう。
画面イメージ：ECRとECOの役割を分ける
変更の検討段階と、承認後の実施指示を分けることで、未確定情報と確定事項を区別できます。
ECRを使用せず、軽微な変更をECOから開始する企業もあります。その場合は、どの条件ならECRを省略できるのかを規程として決めておく必要があります。
ECRの目的は、設計者に変更案を提出させることだけではありません。まず、なぜ変更を検討する必要があるのかを関係者が確認できる状態にします。
起票者が営業、品質保証、製造、購買など設計部門以外の場合、具体的な設計変更案を提示できないこともあります。そのため、ECRでは解決方法よりも、現在の問題、要求内容、発生条件を記録できる項目が必要です。
「コストを下げたい」「不具合があった」といった短い記載だけでは、変更の必要性や優先度を判断できません。対象数量、現在の不良率、部品の供給終了日、顧客から求められている回答期限など、判断に必要な背景を記録します。
変更理由を自由記述だけで登録すると、後から「部品廃止に伴う変更」「品質不具合に伴う変更」などを抽出できません。
変更理由には選択項目を設け、詳しい事情を自由記述で補足する構成が適しています。
分類項目があれば、変更理由別の件数や承認期間も集計できます。ただし、分類だけでは具体的な事情が分からないため、説明欄は別に設けます。
ECOでは、「何をどの状態からどの状態へ変更するのか」を明確にします。
「最新図面へ変更」「一部寸法を修正」だけでは、承認者や製造部門が変更内容を判断できません。変更箇所をマーキングした図面、変更前後の数値、BOMの差分などを添付し、確認対象を明確にします。
複数の品番や図面をひとつのECOで変更する場合は、対象ごとに変更前Revと変更後Revを記録します。代表品番だけを記載すると、派生製品や共通部品への反映状況を確認できなくなるためです。
設計変更で確認漏れが生じやすいのは、設計者が直接管理していない業務への影響です。図面とBOMは確認されても、製造手順、検査条件、認証書類、旧在庫、顧客への申請が対象から外れることがあります。
影響範囲を自由記述だけで回答すると、起票者が思い付いた内容しか記録されません。あらかじめ確認対象を一覧にし、それぞれの状態を登録できるようにします。
画面イメージ：影響範囲を「該当」「非該当」「要調査」で確認する
| 確認項目 | 状態 | 確認する内容 |
|---|---|---|
| BOMへの影響 | 該当 | 部材置換、数量変更、代替品、承認済み調達先の変更があるか |
| 製造工程への影響 | 要調査 | 作業手順、設備、治具、製造条件、検査箇所を変更する必要があるか |
| 試験への影響 | 該当 | 設計検証、妥当性確認、DVP&R、試験成績書の更新が必要か |
| 規格・認証への影響 | 非該当 | 認証、届出、宣言書、適合証明、顧客提出書類の更新が必要か |
| 在庫・仕掛品への影響 | 要調査 | 旧品、仕掛品、発注残、支給品の使用可否と処置を確認する |
| 顧客への影響 | 該当 | 事前通知、承認申請、サンプル提出、切替日の合意が必要か |
判断できない項目を無理に「非該当」とせず、担当者と期限を設定して調査できるようにします。
「影響なし」という判断にも確認が必要です。規格への影響を設計担当者だけで判断するのではなく、必要に応じて品質保証や認証担当者が確認します。
システム上では、状態だけでなく、判断した担当者、判断日、判断理由を記録できるようにします。後から条件が変わった場合も、当時どの情報を基に非該当としたのかを確認できます。
すべてのECOを同じ承認ルートにすると、関係のない部門まで毎回確認することになり、承認に時間がかかります。一方、設計部門だけで承認すると、製造、品質、購買、営業などに関係する条件を確認できません。
基本となる承認者を決めたうえで、影響範囲に応じて必要な部門を追加する方法が考えられます。
画面イメージ：影響範囲に応じて承認者を追加する
変更に関係する部門だけを承認へ加えることで、必要な確認を行いながら不要な待ち時間を減らせます。
承認ボタンを押すだけの運用では、各承認者が何を確認すべきか分かりません。
たとえば購買部門であれば、価格、納期、発注残、代替調達先を確認します。品質保証部門であれば、再試験、認証、顧客提出物、検査規格への影響を確認します。
承認画面に部門別の確認事項を表示すると、承認の目的を明確にできます。
差し戻し時は、単にステータスを「差し戻し」に変更するだけでなく、不足している情報、再確認が必要な項目、修正後の提出先を記録します。
再申請時には、前回から変更された箇所を確認できるようにすると、承認者が申請書全体を読み直す必要がありません。
ECOが承認されても、それだけでは新しいRevを使用できるとは限りません。図面、部品、製造設備、検査方法、顧客承認などの準備が完了してから切り替える変更もあります。
そのため、「実施予定日」だけでなく、どの基準で新Revへ切り替えるのかを記録します。
画面イメージ：切替条件と旧品処置を分けて記録する
日付だけでなく、どの製品から新Revになるのかを特定できる条件を記録します。
「5月1日から変更」と記載されていても、5月1日に製造する製品から変更するのか、5月1日に出荷する製品から変更するのかで対象が異なります。
製造日、完成日、検査日、出荷日など、何を基準にした日付なのかを明記します。
変更内容によっては、一部の工場や製造ラインで先行導入し、結果を確認した後に全体へ展開する場合があります。
この場合は、対象拠点、先行期間、評価項目、全体展開の承認条件を記録します。単一の切替日だけでは管理できないため、段階ごとの実施状態を確認できるようにします。
設計変更後も、倉庫や製造現場には旧Revの部品、仕掛品、完成品が残っていることがあります。新しい図面を発行しただけでは、これらを使用してよいのか判断できません。
ECOでは、在庫の種類ごとに処置を決めます。
部品在庫だけでなく、発注済みで未入荷の部品、外注先にある支給品、製造途中の仕掛品、出荷待ちの完成品、補修用部品も確認対象になります。
廃棄や追加工で費用が発生する場合は、数量、金額、負担部門、承認者も記録します。
設計変更に伴って更新する情報は、図面やBOMだけではありません。
ECOの承認と同時にすべての文書が更新されるとは限りません。そのため、関連文書ごとに更新担当者、期限、更新後Rev、完了日を管理します。
旧版の文書は削除するのではなく、使用停止の状態にし、変更前後の関係を確認できるようにします。現場で旧版を誤って使用しないよう、最新版の識別方法や配布先の更新も必要です。
ECOの承認後、関係者へ一斉メールを送るだけでは、受信者が自分に必要な対応を判断できない場合があります。
通知は影響範囲に応じて送信先を決め、通知本文に担当者が確認すべき内容を記載します。
画面イメージ：影響範囲に応じて通知先と依頼内容を変える
通知された事実だけでなく、受信者が何を確認し、いつまでに回答するのかを記載します。
通知本文には、少なくとも次の情報を含めます。
通知先を増やしすぎると、自分に関係のない通知が多くなり、重要な連絡も読まれにくくなります。承認が必要な人、作業が必要な人、情報共有だけでよい人を分けることも検討します。
ECOは、承認された時点で完了とは限りません。承認後に、図面発行、BOM更新、部品手配、作業手順書改訂、在庫処置、顧客通知などが残っています。
承認済みと変更完了を別の状態として管理します。
変更完了の条件として、次のような項目を確認します。
完了条件を満たしたことを変更責任者が確認し、完了日を登録します。未完了の作業がある場合は、担当者と期限を明示したまま管理します。
変更を実施した後に、不具合率、作業時間、試験結果、顧客からの反応などを確認する場合があります。
特に品質不具合の対策として行った設計変更では、変更した事実だけでなく、当初の問題が改善されたかを確認する必要があります。評価対象、確認期間、判定結果をECOや関連案件へ記録します。
供給停止、重大不具合、法令対応などでは、通常の承認順序を待てないことがあります。ただし、緊急であることを理由に、変更内容や対象範囲を記録しない運用にすると、後から影響を確認できません。
緊急変更では、承認者や事前確認を限定する代わりに、次の項目は記録します。
暫定変更を恒久的な変更として継続する場合は、後から正式な影響確認と承認を行います。
設計変更管理をシステム化する際、最初からPDMやPLMと同等の機能を作ろうとすると、入力項目や承認条件が多くなり、導入までに時間がかかります。
現在メールやExcelで管理している場合は、まず次の範囲から始める方法があります。
運用開始後に、承認に時間がかかっている工程、確認漏れが多い項目、二重入力が発生している情報を確認し、必要に応じて条件分岐、通知、文書管理、他システムとの連携を追加します。
一方、すでにPDM、PLM、ERP、生産管理システムを利用している場合は、同じ品番、BOM、Rev情報を新しいシステムへ重複登録しない構成を検討する必要があります。どのシステムを正本とするのかは、実装前に決めるべき設計事項です。
ECR/ECOの申請フローでは、設計変更の内容だけでなく、その変更が製造や品質、調達、在庫、顧客対応へ与える影響まで確認する必要があります。
ECRでは変更の理由と発生事象を記録し、ECOでは変更前後のRev、影響範囲、承認者、切替条件、旧品処置を確定します。判断できない影響項目は「要調査」とし、担当者と期限を設定します。
また、ECOは承認された時点で終了ではありません。図面・BOM・作業手順書の更新、試験、在庫処置、顧客通知などが完了し、実際の切替対象を確認できる状態になってから完了とします。
設計変更管理をWebシステム化する場合は、現在使用している申請書をそのまま画面へ置き換えるのではなく、どの段階で何を確定し、どの部門が何を確認し、承認後にどの作業を完了させるのかを先に確認することが重要です。
製造業における設計変更、品質管理、文書管理、部門間の申請業務をシステム化する例については、 製造業向けシステム開発例 でも紹介しています。