ERP知識シリーズ 運用モデル評価 その２：実施計画と進め方
運用モデル評価は姿勢を切り替える工程です。
これまでの検証は、用意された枠組みの中で確認していく側面が強くありました。しかし運用モデル評価では、自分たちで考え、運用を成立させるための条件を整理していく段階に入ります。
しかし、この切り替えは容易ではありません。判断が必要な場面ほど結論は出にくくなり、議論は現行の感覚に引き戻されやすくなります。運用モデル評価は、そうした“運用の現実”が初めて表に出てくる工程でもあります。
では、この工程をどのように進めていくのか。順を追って見ていきます。
運用モデル評価実施計画立案
計画書の基本的な枠組みは、ERP以外の一般的なプロジェクト計画と変わりません。ところがERP導入になると、「何を書けばよいかわからない」という声が上がります。ERP導入がはじめてであれば戸惑いもあります。しかし、「システムは専門家の領域だ」という思い込みが重なると、自分たちで整理できる部分まで手が止まってしまいます。
ここで思い出したいのが、アルプスの少女ハイジのクララです。歩く力がまったくなかったわけではなく、一歩を踏み出すきっかけと支えが必要だっただけでした。
運用モデル評価も同じです。最初からすべてをITベンダーに任せるのではなく、まずは自分たちで論点を整理し、判断材料を揃える。わからない点を明確にした上で協力を求める。その姿勢を、ここでは“クララ作戦”と呼びます。
このときITベンダーに求めたいのは、評価の主役になることではなく、ユーザー企業が一歩を踏み出すための“支え方”です。ペーターが山の道をよく知る案内役として伴走し、アルムおんじが要所で本質を見抜いて背中を押すように、論点を整理するための問いを返し、判断に必要な材料を揃える支援に徹してもらう。主語はあくまでユーザー企業に置いたまま、転びやすい場所だけを支える。その距離感が、クララ作戦を成功へと導くのです。
そして、その一歩が具体的な形になるのが実施計画です。計画書には、運用モデル評価の目的、スケジュール、体制と役割、実施準備（業務シナリオや検証用データ）、実施内容、実施環境、障害対応、管理方法を整理します。
ビジネスプロセスフローとシナリオの関係
運用モデル評価の開始時点では、CRPを通じてビジネスプロセスフロー（いわゆるフローのレベル2）が揃っている前提に立ちます。運用モデル評価で検証するシナリオは、このレベル2のフローにある分岐を、漏れなく辿るように一覧化していきます。
ここで有効なのが、シナリオ一覧×フロー分岐のクロスチェックです。まず実業務を想定してシナリオを一通り書き出し、それがビジネスプロセスフローのどの分岐に対応するのかをマッピングする。すると、シナリオの抜けも、フローの抜けも、どちらも見つけやすくなります。
シナリオを一覧化するための洗い出しには、以前解説した「トリガーイベント」の考え方を用います。シナリオを「どのタイミングで、何をきっかけに、どんな情報処理が始まるか」という起点から整理すると、慣習的な手順に引きずられず、必要な論点が立ち上がりやすくなります。
検証用データ
検証用データの準備は、対象マスタの選定、シナリオを実現するためのデータセット設計、そしてデータ量の前提整理という三つの観点で進めます。
対象マスタの選定：
まず、運用モデル評価で使用する主要マスタを決めます。ここで重要なのは、現行システムのデータをそのまま持ち込まないことです。運用モデル評価は、ブループリントで定義したマスタ構造やコード体系に準拠した状態で、To-Be運用が成立するかを確認する工程だからです。そのため、顧客・仕入先・品目・BOM・倉庫やロケーション・価格条件・勘定科目や分析軸などは、ブループリントで定義した粒度・分類・コード体系に従って準備します。あわせて、CRPで検証し、成立すると確認できた前提やルールをそのまま引き継ぐことが重要です。
データセット設計：
次に、シナリオに沿って分岐が発生するよう、トランザクションデータを設計します。例えば、欠品対応のシナリオであれば在庫数量を受注数量より少なく設定します。納期変更や品質不良、入荷遅延といった例外処理を確認したい場合には、それらが起きる前提条件をデータで再現します。この様に、判断や例外が自然に発生する状態を意図して組み立てます。
データ量の前提整理：
そして最後がデータ量です。運用モデル評価の段階では、データ移行リハーサルが未実施のため、最初から本番相当のデータ量を用意できない前提に立つ必要があります。一方で、「生産負荷は本番相当のデータ量でないと検証できない」という声が出やすい領域でもあります。
ここでのポイントは、運用モデル評価は“性能検証”ではなく、運用が成立することを確認することです。したがって対処は、データ量そのものを増やすことではなく、「同じ論点を、運用モデル評価の範囲で確認できる形に工夫することです。例えば、次のような対応が現実的です。
- 対処策①：代表パターンの圧縮
本番の全パターンを再現するのではなく、負荷に影響する要素（特定の製造ライン、BOM、段取り制約、外注や分納など）を代表パターンとして抽出し、少量でありながらも“難所”を再現します。 - 対処策②：時間軸の圧縮
需要を長期間に広げて入力する代わりに、短い期間に需要を寄せて、計画ロジック上の混雑（例外やアラートが発生する状況）を意図的に作ります。 - 対処策③：コピー生成で増やす
正確なデータを手入力で一件ずつ増やすのではなく、テンプレート化したオーダーを複製する、過去の検証データをシナリオの目的に沿って再利用するなど、準備負荷を抑えながら、検証に必要な最小限のデータ件数を確保します。
性能そのもの（処理時間・同時接続・バッチ時間など）の検証は、システム統合テストなど別の工程で扱う前提を明確にしておくと、運用モデル評価の目的がぶれにくくなります。
実施内容と部門横断の進め方
運用モデル評価は、受注から出荷、発注から支払、生産計画から製造実績、会計までがつながる部門横断での進行です。部門横断である以上、それぞれの立場や利害が働きます。評価結果が出てから判断しようとすると、結論はブレやすくなります。そのため、あらかじめ受入基準を定めておきます。何をもって合格とするのかを先に明確にしておくことで、評価を主観や力関係に左右されにくいものにします。MoSCoWを受入基準として先に置く、という考え方と同じです。
実施結果の整理も、最初から分類を決めておきます。受入基準に満たなかった場合に「どの評価になるのか」「次に何をすべきか」が見える形で整理しておくことが重要です。例えば、評価分類は「合格／条件付き合格／要再検証／保留」といった形で揃えます。さらに再検証が必要な場合は、データの作り直しなのか、シナリオの見直しなのか、ルールの確定が先なのかといった前提を整理します。あわせて、その論点が運用ルールなのか、教育なのか、マスタ整備なのか、拡張判断なのかも切り分けておきます。そして、評価結果には画面キャプチャなどのエビデンスを残し、「何を見て、どのように判断したのか」を後から追える状態にしておきます。
こうしておくことで、運用モデル評価は単なる「課題の洗い出し」ではなく、次の打ち手が明確になった評価結果の積み上げになっていきます。
障害発生時の対応
運用モデル評価中に障害が出たとき、悲観的に捉える必要はありません。運用開始後も、問い合わせ・障害・変更要求は必ず発生します。運用モデル評価は、運用を成立させる実践ですから、障害対応もその一部として扱う準備をします。
その準備とは、可能な範囲で最低限の枠組みを整えることです。この段階では、まだ正式なヘルプデスク体制が整っているわけではありません。したがって、まずは「起票手順」「一次切り分けの観点」「共有・記録のためのエビデンスの取り方」までを定めておきます。評価の中で発生した事象を、再現可能な形で残せる状態にしておくことが、この工程での目的です。
環境設定（運用モデル評価前提）
運用モデル評価は、CRPで使用してきたトレーニング用環境を用いて実施します。同時期にITベンダーは開発環境で拡張機能開発を進めているため、評価対象となる環境を明確に定め、その前提を揃え、プロジェクトメンバーへ事前に周知します。
期間（いつからいつまで）：
まず、運用モデル評価を実施する期間を明確にします。トレーニング用環境をいつからいつまで利用するのかを定め、プロジェクトメンバーへ事前に共有しておきます。評価期間を明確にすることで、他の活動との重複を防ぎます。
用途（何に使うか）：
次に、用途を明確にします。トレーニング用環境は、業務シナリオの実行や手順確認、判断ポイントのすり合わせといった運用モデル評価のために使用します。一方で、インターフェースや帳票などの開発作業は開発環境で行います。
利用ルール（間違い防止）：
そして最後に、利用ルールを定めます。ERPには会社コードや事業所、拠点、倉庫など、利用範囲を識別する定義が存在します。どの環境で、どの会社コードや区分を使用するのかを事前に統一し、資料や会話、画面共有の際にも必ず環境名を明示します。
再利用（繰り返し評価するための策）：
また、評価用に準備した初期データや主要な設定は、どの環境に登録されているのかを整理し、繰り返し利用できる状態にしておきます。
管理方法
最後に、計画を“実行可能な運用”へ落とすのが運営管理です。進捗は、個別部門の完了報告だけではなく、シナリオ単位での消化状況、評価分類の分布、未解決論点の滞留箇所が見える形で整理します。ダッシュボード的に可視化しておくと、部門横断の依存関係や再検証の波及を早い段階で発見できます。
あわせて、障害管理（インシデント管理）も運営管理に含めます。運用モデル評価は、運用の練習なので、障害の扱い方も練習対象になります。ここまでを一つの運営サイクルとして回すことで、会議体の連携や運営の要点（論点の受け渡し、決定事項の固定、宿題の回収）が機能しやすくなります。
次回：運用モデル評価の完了基準を「成果物」に落とす
その１で整理した通り、運用モデル評価の完了基準は「操作マニュアルを作成できるレベルに到達していること」でした。
次回（その３）では、運用モデル評価の結果を、どのように第3層（オペレーションフロー）や操作マニュアルへ落とし込み、運用の自走につなげていくかを整理します。
