評価するには曖昧すぎる例
「ブラケットを更新してください。新しい仕入先のほうが良く、急いで必要です」
これでは、対象品目、現行リビジョン、変更理由、適合性の根拠をレビュー担当者が推測しなければなりません。緊急だからといって、こうした情報不足が解消されるわけではありません。
設計変更要求フォーム
何を変えるか、なぜ重要か、どの管理対象品目が影響を受けるかを説明します。実施が承認される前に、設計部門が提案を評価できる十分な情報を提供してください。
5ユーザーまで無料。クレジットカードは不要です。
コードを書かずに、項目・ワークフロー・ダッシュボードを調整できます。 1,000以上のアプリテンプレートと活用例を見る
ログインして Jodoo の例を確認できます。画面上の製造記録は架空のものです。
レビュー担当者に問題の再構成をさせない
有効なレビューを開始できる申請
「BRK-104（リビジョンB）の代替サプライヤーを評価してください。この提案は、ブラケットの仕様と組立作業指示書に影響します。進行を決める前に、サプライヤー認定の根拠をレビューしてください。既存在庫の扱いは購買部門が確認する必要があります。」
この提案は、技術承認や在庫の扱いがすでに決まったように見せかけず、レビュー可能な変更を明確にしています。
レビュー内容を左右する事実を記録する
| 情報 | 入力する内容 | 重要な理由 |
|---|---|---|
| 管理対象品目 | 有効な部品、図面、作業指示書を選び、現行リビジョンを保持します。 | レビュー担当者が変更前の基準を把握し、古いリビジョンに基づく提案を検出できます。 |
| 変更理由 | 希望する解決策だけでなく、確認された問題や業務上のきっかけを記述します。 | 提案された変更が実際の課題に対応しているかをチームで評価できます。 |
| 変更案 | 何が変わるのか、関連するどの文書や工程に影響し得るのかを説明します。 | 技術部門が調査すべき範囲を特定できます。 |
| 変更区分ごとの詳細 | サプライヤー変更では、候補サプライヤーと認定資料を指定します。工程変更では、影響を受ける工程を指定します。 | あらゆる項目への入力を求めるのではなく、その変更に必要な質問だけを表示できます。 |
| 優先度と根拠資料 | 緊急度を示し、裏付け資料を添付または参照します。 | レビュー担当者が作業の優先順位を付け、提案の根拠を確認できます。 |
Jodoo は申請番号を生成し、選択した品目の現行リビジョンを自動入力します。申請者は識別子を調べたり製品情報を入力し直したりせず、変更内容の説明に集中できます。
提案を承認・差し戻し・却下し、その後の処理を正しく進める
具体的な提案を提出する
申請者は品目を選択し、該当する項目を入力します。このフォームは評価の出発点であり、生産変更の指示ではありません。
不足情報を解消する
範囲や根拠が不明確な申請は、レビュー担当者が差し戻せます。修正内容を記録して同じ申請を再提出することで、やり取りが複数の関連しない版に分散するのを防ぎます。
判断を記録する
承認された ECR は、ECO を準備する際に選択できます。却下した提案には理由を残し、実施済みの変更であるかのように扱わないでください。
実施範囲は別途定義する
次のツールを使用して 設計変更指示テンプレート 影響を受けるリビジョン、各部門のレビュー、在庫の処置、実施責任を明確にします。申請の承認だけでは、新しいリビジョンはリリースされません。
よくある3つの状況を誤ったプロセスに入れない
要件がまだ不明確な場合
必須項目を埋めるためだけに、品目やリビジョンを作り上げないでください。有用な申請は問題を説明できますが、管理された実施には対象範囲の特定が必要です。
生産現場で直ちに封じ込めが必要な場合
次の 品質・不適合管理プロセス で当面のリスクを封じ込めます。恒久的な変更を評価している間、ECR を不適合材料の使用許可として扱ってはいけません。
別の種類の申請が必要な場合
次の 変更申請テンプレート集 には、価格、設計、逸脱に関する申請が含まれます。管理対象の設計リビジョンが起点でない場合は、必要な判断に合ったフォームを選んでください。
技術者の申請方法に合わせてフォームを調整する
権限を持つ業務管理者は、Jodoo で区分の選択肢、ヘルプ文、条件付き質問、レビュー担当者の割り当てを変更できます。サプライヤー認定工程を追加する工場なら、その根拠資料をサプライヤー変更のときだけ求められます。工程チームなら、現場で使用する工程識別子を追加できます。
最初のフォームは入力できる程度に簡潔にしつつ、レビューの判断に必要な情報は削除しないでください。技術者と申請者の両方で試行し、添付メールを読まなくても提案内容を理解できることを確認します。
設計変更申請に関するよくある質問
ECR と ECO は何が違いますか？
ECR は変更を提案し、評価すべき理由を示します。ECO は承認された範囲と実施計画を定めます。呼称は組織によって異なるため、自社で定義を合わせてください。この例では ECR の受理後に ECO を準備できますが、それだけで製造切替が許可されるわけではありません。
申請者が変更後のリビジョンを把握していない場合はどうしますか？
現在の管理対象品目を特定し、変更案を明確に説明します。申請を完成させるためだけにリビジョンを作らないでください。実施指示が承認される前の評価段階で、設計部門が予定リビジョンと影響範囲を確認します。
仕入先変更の申請にはどのような根拠資料が必要ですか？
変更先候補の仕入先と管理対象品目を特定し、サンプル検査、材料仕様、適合性評価など、レビュー可能な認定資料を添付または参照します。不足資料は保留として明示します。申請者が評価根拠を提示し、資格を持つレビュー担当者が十分かどうかを判断します。
緊急の不具合なら変更レビューを省略できますか？
緊急性に応じて対応優先度を上げるべきですが、必要な判断を黙って省いてはいけません。承認済みの品質手順で直近のリスクを封じ込めたうえで、恒久的な設計変更や工程変更が必要かを評価します。この ECR 例は、管理仕様からの逸脱を許可するものではありません。
プロジェクト変更要求と同じものですか？
いいえ。このフォームは管理対象品目と現在のリビジョンを起点にします。プロジェクト変更要求は通常、範囲、コスト、日程を扱います。製品、図面、作業指示書のリビジョンを変えない場合は、より一般的な変更要求プロセスを使用してください。
サンプルから始め、自社向けに調整する
フォームと関連レコードをプレビューできます。「サンプルデータ付きでインストール」を選ぶと、App をワークスペースにコピーし、実際の申請者とレビュー担当者を割り当てて、レビュー工程を試せます。メンバーフィールドとワークフロータスクは、公開プレビューではなくインストールした App で使用されます。