生産において、緊急調達はめったに自発的に発生することはありません。その原因には、生産計画の変更、消費基準の誤り、供給業者の遅延、設備の故障、またはタイミングの悪いリクエストが含まれます。こうしたリクエストが全体のプロセスとは別に処理されると、問題が発生します：電話、メッセンジャー、ばらばらのスプレッドシートや個人的なやり取りで。
その結果、認可された計画は作業の指針として機能しなくなります。調達担当者は最も喧しいリクエストに乗り換え、倉庫は矛盾する指示を受け取り、管理者は不足や超過の後にその結果を見ることになります。一方で、緊急性は常に重要性を意味するわけではありません：一つの秩序なしでは、緊急なニーズを十分な計画不足から区別するのは困難です。
計画外調達のリスク
- 残高やオープン発注の確認なしでの発注の重複；
- 単一のステータスがないための承認の遅延；
- 変更の全歴史なしでの手動による供給計画の調整；
- 供給業者に対する不明確な優先順位と不完全なコンテキスト；
- 逸脱の原因と発信者を迅速に特定できないこと；
- 不完全なデータに基づく予算、期間、リスクに関する決定。
主な課題は、迅速性と管理を統合することです。生産には迅速な応答が必要ですが、加速は限度、承認ルート、根拠の確認を放棄することを意味するべきではありません。ルールがプロセスに組み込まれていない場合、企業は本当に重要なニーズを遅らせるか、混沌とした支出を許可することになります。
OpenBoxがリクエストを管理される枠組みに戻す方法
「リクエスト管理」プログラムでは、緊急ニーズは属性、責任者、および段階を持つオブジェクトとして定義されます。ユーザーは、何が必要で、どの部門または生産タスクのためで、どのくらいの量が、いつまでに必要かを指定します。必要に応じて、緊急性の理由を記録し、確認材料を追加します。
やり取りの代わりに一元化リクエスト
すべてのリクエストは指定されたフォームを通過し、変更の履歴が保存されます。調達担当者は作成者、優先度、期限、承認者、関連ポジション、および現在のステータスを確認できます。これにより、確認の回数が減り、元データの確認なしに調達を開始することが防がれます。
ルールによるルーティング
リクエストは部門、金額、カテゴリー、ニーズのタイプ、または緊急性の指標に基づいて送信できます。標準的および計画外のリクエストに対して異なるルートが設定されます。緊急リクエストには、根拠の指定と必要な管理者の参加を必須にできます。これにより、例外が静かに通過することなく、プロセスのコントロールされる部分となります。
供給計画との連携
管理者は全体像を得ます：何が計画され、何が追加され、どのリクエストが承認され、どれが既に調達に渡されたか。変更はローカルファイルに失われず、ニーズの歴史の一部となります。これにより、注文だけでなく、その理由についても議論できるようになります…
現在のプロセスの調査から始め、1種類のリクエストに対するパイロットルートを設定することができます。これにより、実際の作業でアプローチを検証し、必要なルールを特定し、スケーラビリティの基盤を準備できます。