ERP知識シリーズ 運用移行②：運用移行方針を実践する
なんといっても難しいのは、決めた方針を実践することです。
前回は、プロジェクト発足時に決めておく運用移行方針について整理しました。本稼働日、体制、教育、周知、現場準備。運用移行には、早い段階で方向性を揃えておきたい論点が数多くあります。
ただ、方針は決めただけで自然に進むものではありません。今回の投稿では、前回整理した運用移行方針をどのように実践するのかについて解説します。
運用移行方針で議論が止まってしまう理由
議論が運用移行方針から先に進まないのは、システム構築のように着手のイメージが見えにくいからです。拠点の展開方法、並行稼働の可否、切り戻し計画。どれも重要な論点ですが、判断基準がないままでは、何から進めればよいのか分かりません。プロジェクトのスケジュールを組むITベンダーに、その経験がない場合は、運用移行方針が誰からも議論に上がらないまま、時間だけが過ぎてしまうのです。これは、“実践”のノウハウがないと進まないということです。
従って、ここからは実践の具体例として、「他プロジェクトとの調整」「並行稼働の可否」「工場展開」「切り戻し計画」の四つを取り上げて話を進めていきます。
他プロジェクトとの調整
構想策定の段階では、ERP導入と並行して進む他プロジェクトを全て洗い出します。新工場や新倉庫の立ち上げ、周辺システムの入替など、ERP導入と時期が重なる可能性のあるプロジェクトを対象にします。
この段階で決めるのは、ERPを他プロジェクトに合わせて稼働させるのか、あえて時期を分けるのかという基本方針です。ここは、システムに関係していれば時期を合わせたくなるところです。例えば、倉庫の新設であれば、入出庫指示や在庫管理を行う以上、ERPとWMSのシステム間連携が稼働当初から必要だと考えるでしょう。
一方で、倉庫稼働と同時に荷扱量を一気に増やさないのであれば、ERPとWMSをその時点で連携させず、ERPで出力した入出庫指示を使ってマニュアル対応する、という進め方も考えられます。
つまり、判断基準になるのは、同時に立ち上げる場合の作業量と、それを支えられるリソースキャパです。そのリスクを吸収できるのであれば同時稼働、吸収しきれないのであれば時期を分ける。このように考えると、方針を決めやすくなります。
プロジェクト開始後は、その方針をもとに、日程とリソースの具体的な調整へ入ります。どの時期に人材が競合するのか、互いのプロジェクトのマイルストーンをどこで合わせるのか、その時の成果物は何になるのか、先に稼働する側の安定化にどれだけの期間を見るのか、片方のプロジェクトが遅れたらもう片方は稼働するのか否か。こうした条件を並べていくと、互いのシステムの歩調が整い、遅れリスクの対策が明確になっていきます。
並行稼働の可否
構想策定の段階で、旧システムと新システムを一定期間同時に動かすかどうかを決めておきます。これは見積やスケジュールに影響するため、RFPに記載すべき前提条件です。
やってはいけないのは「安心感だけ」で並行稼働は必要と決めることです。この判断を下すプロジェクトは多くありますが、経験上、プロジェクトの中で「リソース的にやりきれない」となってしまうことも多いのです。
そのため、並行稼働の可否は、そもそも並行稼働が成り立つのか、という論点で整理します。例えば、どれだけの期間並行するのか、その間のリソースを確保できるのか、といった点です。加えて、旧システムと新システムを同時に稼働させた時に、他システムがその両方と連携できるのかも確認が必要です。この二つが成立しなければ、そもそも並行稼働はできません。
次に、プロジェクト開始後の整理についてです。
並行稼働するのであれば、旧システムと新システムのどちらを正として運用するのか、どういった条件（月次締めの金額が新旧一致するなど）になったら旧システムを止められるのか、を決めます。特に並行稼働は、始めることより終わらせることの方が難しいです。なかなか踏ん切りがつかず、半年以上並行稼働していたプロジェクトもあります。
並行稼働を行わない場合は、最終データ移行をいつ行うのか、在庫精度を高めるために直前で棚卸しを行うのか、切替後の出荷済み未請求などのデータをどう扱うのか、旧システムを参照専用で残すのか、といったことを具体的に詰めていきます。
並行稼働を行わない場合、その分、経営リスクは大きくなるので、その軽減策を十分に計画しておくことが重要です。ユーザーの習熟度が高まれば、混乱は減ります。習熟度を高めるためには、マニュアルの整備も万全にしておきます。データ移行はリハーサルを繰り返し、エラーをとことん減らします。仮にエラーが発生しても、即座に対処できるレベルまで高めておきます。万が一問題が発生しても、“切り戻し”リハーサルを行っておけば、切り戻しの判断、その後のシステムやデータ戻しの手順もこなせるでしょう。
切り戻し計画
構想策定の段階で、切り戻しを想定するかどうか、そしてその考え方をどう置くかを決めます。これは旧システム側の保守体制や予算に影響するため、前提条件として早めに置いておく必要があります。なお、前述の通り、並行稼働しないのであれば、切り戻し計画は必須になります。
プロジェクト開始後は、切り戻しを実際に使える手順へ落としていきます。
ここで整理するのは、まず判断条件です。本稼働後、新システムがどの状態になったら切り戻しを実施するのか、誰がその判断をするのか、どこまで戻すのか。これを先に決めておかないと、本稼働で問題が起きた時に切り戻しの判断ができないまま、新システムをずるずる継続してしまい、元に戻せないという最悪の事態に陥ります。
次に必要になるのが、戻し方の整理です。入力し終えた受注は旧システムに戻すのか、出荷はその日の分だけ止めるのか、生産実績や請求処理はどこで区切るのか。運用移行における切り戻しは、単にシステムを前の状態へ戻すことでは足りません。どの業務を、どの単位で、どこまで戻すのかを決めておく必要があります。
さらに、その連絡の流れを決めます。経営層、現場、IT、ベンダー、外部取引先のどこへ、どの順番で連絡するのか。切り戻しはシステム作業だけで終わる話ではなく、業務と周知が連動します。
最後に整理するのが、切り戻し後の再開条件です。旧運用に戻した後、何を確認できたら再度新しい運用へ進むのか。再開判断を誰が行うのか。ここまで定まって、運用としての切り戻し手順は実際に使えるものになります。
業務領域や拠点の展開方針（工場展開）
構想策定の段階では、一括展開にするのか、段階展開にするのかを決めます。これも全体スケジュールや支援体制に影響するため、早い段階で方向性を持っておく必要があります。
工場展開を例にすると、前の記事でも取り上げた、「工場間でBOMを跨ぐかどうか」が焦点になります。ここに、一括展開か段階展開かを掛け合わせると、工場展開の考え方は四つのパターンに分かれます。
まず、工場間でBOMを跨がない場合です。この場合は、工場ごとに業務やデータのまとまりを切り分けやすいため、段階展開を取りやすくなります。どの工場から先に立ち上げるかという順序も、プロジェクトの中で決めることができます。プロジェクト開始後は、その順序を決めるための基準を揃えます。導入しやすさ、効果の出やすさの二軸を中心に、他工場への波及のしやすさ、現場の受入体制、支援要員の確保のしやすさ。実際にこれらの評価項目を20から30上げ、重み付けし数値化して評価します。こうした観点で整理すると、先行工場に向いている拠点と、後続にした方が良い拠点の判断をつけやすくなります。先行工場で確認する項目、引継ぎ方、支援の入り方を整理して、次へつながる形にしていく。その積み上げが、段階展開の特性を活かして運用移行の質を高めるのです。
次は、同じく工場間でBOMを跨がない場合で、一括展開を選ぶケースです。全工場を同時に立ち上げるため、教育、データ移行、現地支援を一斉に整える必要はありますが、工場間のBOM整合を気にせずに済む分、業務設計としては整理しやすい面があります。したがって、BOMを跨がない場合は、一括展開も段階展開も取り得ますが、順次進めやすいのは段階展開の方です。
次に、工場間でBOMを跨ぐ場合です。この場合は、段階展開の難易度が一気に上がります。例えば、製品製造工場（組立や充填）を先に稼働し、中間品製造工場を後にすると、新旧BOMのどちらも用いて所要量展開や原価積み上げ計算を行うことになります。これが難易度を高くする要因です。工場間でBOMを跨ぐ場合、先に新しい運用へ入った工場と、まだ旧運用で動いている工場が混在するため、中間品の受け渡し、在庫の持ち方、原価の計算、実績の扱いが複雑になります。正直、こういった運用移行は避けるべきです。結局のところ、移行そのものの難易度を取るのか、稼働時の混乱範囲の抑制を取るのかという話になります。
そのため、工場間でBOMを跨ぐ場合は、一括展開の方が現実的な選択肢になりやすいです。全工場を同時に立ち上げれば、新旧BOMが混在する期間を作らずに済みます。ただし、その分、教育、データ移行、現地支援を全工場分まとめて整える必要があり、本稼働時の負荷は大きくなります。つまり、BOMを跨ぐ場合は、一括展開の方が業務設計としては整理しやすい一方で、立上げ時の準備負荷は重くなります。
それでも、工場間でBOMを跨ぐ構造の中で段階展開を選ぶのであれば、新旧システムのインターフェーステスト、データ移行、運用ルールをしっかり整備していきます。どの工場が旧BOMで動き、どの工場が新BOMで動くのか。その状態で、所要量展開、原価計算、在庫受け渡し、実績収集をどう成立させるのか。ここを曖昧にしたままでは進められません。このパターンは、四つの中で最も難易度が高いと認識しておくべきでしょう。
こうして方針は実践に変わる
この四つに共通しているのは、構想策定で方向性を決め、プロジェクト開始後に実施できる形へ落としていくという流れです。
方針だけでは、まだ正論の段階です。そこから先に進めるには、条件を揃え、順番を決め、担当と手順を明らかにする必要があります。
まとめ
前回の記事で扱ったのは、運用移行方針を決めることでした。今回扱ったのは、決めた方針をどう実施事項へ変えていくかです。
運用移行が難しいのは、方針を立てることより、その方針を本当に進めることにあります。プロジェクトの中では、方向性を確認するだけで終わらせず、条件、順序、担当、手順まで落としていく必要があります。
次回は、運用移行方針を前提に、工場、物流センター、店舗、事務所、さらに仕入先や顧客といった外部アクターも含め、何を準備し、どこに注意を払うのかを解説します。
