評価中に品目が変更された場合
新しい現行リビジョンに照らして提案を再評価します。古い変更前後の指示をそのまま適用してはいけません。提案が不要になったのか、修正が必要なのか、別の変更と統合できるのかを明確にします。
サプライヤー変更を申請からリリースまで追跡します。各段階で現行リビジョン、在庫判断、未完了の生産作業を明確に保ちます。
ログインして Jodoo の例を確認できます。画面上の製造記録は架空のものです。
| 用語 | 目的 | 混同してはいけないもの |
|---|---|---|
| ECR:設計変更申請 | 変更を提案し、評価が必要な理由を説明します。 | 変更済みの部品や指示書を使い始める許可。 |
| ECO:設計変更指示 | 承認された範囲と実施作業を定義します。 | 影響品目がすべてすでに有効になったことの証明。 |
| ECN:設計変更通知 | 有効になった変更と、その適用対象を周知します。 | 未解決の技術判断や実施証拠の代わり。 |
これらの名称は会社によって異なります。文書を統合したり、別の名称を使ったりしても構いません。ただし、提案・実施承認・有効化の判断は明確に区別し、生産を変更する人が何を受け取ったか理解できるようにしてください。
この架空例では、チームが現在リビジョンBの BRK-104 ブラケットについて、代替サプライヤーを認定しようとしています。申請者は業務上の理由、変更案、認定資料を記録します。どの図面や品目に関する提案なのかを、技術部門に推測させてはいけません。
当面の封じ込めと恒久的な変更を分けてください。現行材料が安全でない、または不適合である場合は、技術評価と並行して該当する品質手順に従います。
技術部門は、申請が評価できるだけ具体的かを判断します。範囲や根拠が不足していれば差し戻します。申請の承認は ECO の準備を可能にしますが、購買や生産に切り替えを指示するものではありません。
次のツールを使用して 設計変更要求フォーム を使用して、提案とレビューを関連付けて管理します。
ブラケットは B から C に変わり、組立作業指示書にも独自のリビジョン変更が必要です。品質、製造、購買への影響をレビューします。変更区分ごとに同じレビューリストを使うのではなく、実際に判断が必要な部門を特定します。
在庫のブラケット40個と WIP 12個は分けて記録します。製造部門が手直し方法を決めたからといって、購買部門の在庫使い切り判断が未決である事実を消してはいけません。
品目ごとの範囲、処置、責任、予定切り替えを合意します。完了件数だけでなく、各部門評価の内容を確認します。どの作業をリリース必須とするかを決めます。
次の ECO テンプレート は、こうした判断を整理する枠組みを提供します。作業を準備している間は、現行リビジョンを変更しないでください。
必要な指示書を更新し、認定または検査を完了し、材料の処置を決め、関係者に周知します。各作業を割り当て、証拠をレビューします。App の図面変更例では、初品検査が代替ゲージを待っています。ECO の実施承認だけでは、そのタスクは完了しません。
次の 改訂した指示書と受領確認のための文書管理プロセスを使用します。設計変更 App はリリース判断を記録しますが、別個の文書ライフサイクルを代替しません。実施結果が不十分なら、期限に間に合わせるために重要作業を任意扱いにせず、修正のため差し戻してください。
これから有効になる品目、リビジョン、運用上の境界を特定します。現行リビジョンが開始時点と一致し、必須作業が検証済みであることを確認します。元リビジョンからリリース済みリビジョンまでの履歴を保持し、実際に使う人へ有効な指示を伝えます。
この例は、すでに有効になったリリースを記録するもので、将来の有効化を予約するものではありません。複数品目を同時かつ不可分に変更する必要がある場合や、別システムがリビジョンを管理する場合は、その統制を別途設計・検証してください。
| 役割 | 判断または作業 | 保持する証拠 |
|---|---|---|
| 申請者 | 問題と変更案を説明します。 | 現行品目、理由、裏付け情報、修正内容。 |
| 技術レビュー担当者 | 技術的な妥当性と影響範囲を評価します。 | レビューの根拠と提案リビジョン。 |
| 部門レビュー担当者 | 品質、供給、製造への影響を解決します。 | 各部門の所見と処置判断。 |
| 実施担当者 | 割り当てられた変更作業を実行します。 | 結果、完了の証拠、例外事項。 |
| リリースレビュー担当者 | 準備状況と適用境界を確認します。 | レビュー済みリリースと保持されたリビジョン履歴。 |
| 変更コーディネーター | 不足している判断をフォローし、関連業務をつなぎます。 | 未完了のレビュー、重要作業、エスカレーション記録。 |
小規模なチームでは1人が複数の役割を担うこともありますが、どの立場で何を判断しているかは手順上明確にします。本番利用前に、システム上のタスク割り当てと権限を合意した責任分担に合わせて設定してください。
新しい現行リビジョンに照らして提案を再評価します。古い変更前後の指示をそのまま適用してはいけません。提案が不要になったのか、修正が必要なのか、別の変更と統合できるのかを明確にします。
在庫判断を未決のまま残し、遅延をコーディネーターに見えるようにします。材料の処置が承認済みだと仮定せず、安全に進められる作業を判断します。
具体的な修正内容を示して作業を差し戻します。不合格結果とその後の証拠を保持し、最終的なリリース判断を追跡できるようにします。
問題を封じ込め、追跡可能な是正変更または承認済みの復元手順を使用します。以前のリリースを消したり、履歴が曖昧になる形でリビジョン記号を再利用したりしないでください。
| 指標 | 定義方法 | 解釈方法 |
|---|---|---|
| レビュー所要時間 | レビュー種別ごとに、判断日時から申請日時を差し引きます。 | 情報待ちの時間とレビュー担当者待ちの時間を分けます。 |
| 申請差し戻し率 | 同一対象期間に修正のため差し戻された申請数 ÷ レビュー済み申請数。 | 率が高い場合、申請者の能力だけでなく、フォームの質問が不明確、または根拠資料が不足している可能性があります。 |
| リリース必須作業の未処理件数 | 未完了の重要実施作業を、ECO と期限別に集計します。 | 実施承認済みだが停止中の変更と、まだ評価中の変更を区別します。 |
| 実施リードタイム | 実際のリリース日時から ECO の実施承認日時を差し引きます。 | 同種の変更を比較します。図面修正とサプライヤー認定では、必要な作業が異なります。 |
これらはレポート設計のための定義であり、サンプルから得られた実績値ではありません。期間を比較する前に、対象集団、稼働カレンダー、中止した変更の扱いを定めます。ダッシュボードは大きな数値を表示するだけでなく、次の行動を選べるものにします。
現行リビジョンが分かっている部品または作業指示書を1件選び、少人数のレビュー担当者で試します。通常ケース、差し戻し、実施作業の停止を一通り確認します。生産担当者には、コーディネーターに聞かずに有効なリビジョンを特定し、旧在庫の扱いを説明してもらいます。
実際の手順で必要な範囲だけ、Jodoo の項目、区分、ビューを調整します。CAD 管理、ERP 取引、規制対応の検証は、適切なシステムと専門家の担当範囲に残します。最初のチームが安定して運用できてから展開を広げてください。
いいえ。名称は組織によって異なります。重要なのは、変更提案、承認された実施範囲、発効した変更の通知を区別することです。一つの文書を使う場合も、段階と判断責任でこの三つを明確に分けてください。
調整担当者を一人決めて進行を管理しますが、技術判断や各部門の判断は、それぞれの資格を持つ人に委ねます。購買部門は供給状況と在庫消化を確認できますが、設計上の適合性を自動的に承認する立場ではありません。
リリース前に必須の作業と、リリース後も妥当に継続できるフォローを分けます。変更後の検査方法の検証は必須でも、長期的な仕入先実績の確認は必須でない場合があります。期限に間に合わせるためすべてを任意扱いにせず、判断理由を残してください。
適切な品質手順で問題を封じ込め、追跡可能な新しい変更または承認済みの復元手順で、リリース済みリビジョンを評価します。以前のリリース根拠を消したり、旧リビジョン番号へ密かに戻したりしないでください。
一つの部品または作業指示書の変更を、小規模なレビュー担当と明確な製造引継ぎで試します。順調なケースだけでなく、差し戻された要求や停止した実施タスクも含めます。チームが現行リビジョンとその理由を説明できてから範囲を広げてください。