想定した会社(架空)
| 業種・規模 | 自動車部品製造(二次サプライヤー)・従業員 約180名 |
| 基幹システム | IBM i(AS/400)。RPGで作られた受発注・在庫・出荷管理、稼働 約25年 |
| ドキュメント | 導入時の仕様書はあるが、その後の改修が反映されておらず実態と不一致 |
| 人 | 基幹を触れるのは再雇用の田中さん(64歳・架空)ただ一人。受注の例外判断も事実上、田中さんの頭の中 |
| 受注チャネル | 電話・FAXが中心。特急対応や代替品の可否は都度判断 |
この構成は、当社が相談の場でよくうかがう条件を組み合わせたものです。もし貴社に似ているなら、この記事の進め方はそのまま検討のたたき台になります。
問題は「システムが古い」ではなく、「判断が属人化している」
このモデル企業で本当に怖いのは、サーバーの故障ではありません。田中さんの退職です。頭の中には、たとえばこんな判断が入っています。
- 特急対応の可否。「この得意先のこの品番なら、在庫を先に回してもラインに影響が出ない」という組み合わせの勘所。
- 欠品時の代替提案。図面上は同等でも「あの客先は代替品を嫌う」「この用途なら一つ上の等級で通る」という経験則。
- 得意先ごとの暗黙ルール。伝票にない締め時間、検収の癖、値引きの経緯。
仕様書を書き直すだけでは、この層は残りません。プログラムの外にある「判断」だからです。
進め方: 読み取り接続から、判断の構造化へ
Legacy Bridgeの標準の進め方(5つの段階)に沿って、このモデルケースでは次のように進みます。
第1段階〜第2段階: 診断と読み取り接続
まず現状・投資判断診断で、基幹の環境と「判断がどこに住んでいるか」の所在マップを作ります。そのうえで読み取り専用のアカウントを発行してもらい、受発注・在庫・出荷のデータを参照できる状態を作ります。基幹への書き込みはせず、業務はこれまでどおりです。
第3段階: 判断パターンの抽出
ここがこのモデルの中心です。過去数年分の伝票と出荷実績をAIで読み、「田中さんが例外対応をした形跡」を洗い出します。並行して本人へのヒアリングを行い、記録と突き合わせて、判断を「条件と結論」の形に書き起こしていきます。
ポイントは、文書化を田中さんの宿題にしないことです。記録から仮説を作るのはAIの仕事、正しいかを確かめるのが田中さんの仕事という分担にすると、現場の負担が大きく変わります。
第4段階〜第5段階: 台帳化と、日常業務への組み込み
整理した判断は「判断ルール台帳」として残し、受注担当が使う照会画面に組み込みます。定型の判断はAIが候補を提示し、台帳にない例外だけが人に回る形です。
成果物のイメージ: 判断ルール台帳(抜粋・架空)
| 場面 | これまで(頭の中) | 構造化後 |
|---|---|---|
| 特急依頼(得意先A・品番X系) | 「Aさんなら受けて大丈夫」 | 在庫が安全在庫+20%以上、かつ当日出荷便に空きがあれば受注可。それ以外は人へ |
| 欠品時の代替提案 | 「この用途なら上位等級で通る」 | 代替可否マトリクス(品番×得意先×用途)。マトリクス外は人へ |
| 判断に迷う例外 | 田中さんに聞く | 台帳に「未確定」として記録し、月次で本人と確定。台帳が育ち続ける仕組みにする |
実際の台帳の項目立ては、診断で貴社の業務に合わせて設計します。
効果の考え方(モデル上の仮定)
このモデルでは、仮に「在庫・納期の電話確認が1日40件、1件3分」とすると、月間でおよそ44時間が確認作業に使われている計算になります(営業日22日)。読み取り接続で担当者が自分で照会できるようになれば、この時間の多くを削れる可能性があります。
ただし、これはモデル上の仮定です。貴社の数字での試算は、サービスページの費用試算か、無料適合相談でどうぞ。そして金額よりも大きいのは、「田中さんが退職しても、判断の骨格が会社に残る」ことです。ここは金額に換算しにくいからこそ、経営判断が要る部分だと考えています。
このモデルケースからの学び
- 順番が大事。いきなり「文書化しましょう」ではなく、読み取り接続でデータを見える化してから判断の抽出に進むと、記録と突き合わせられるので精度も納得感も上がります。
- ベテランの役割は「書く人」ではなく「確かめる人」。負担の設計を間違えると協力を得られません。
- 台帳は完成しない。例外を拾い続けて育てる運用まで含めて設計します。