- 切替責任者とGo/No-Go条件を決めた
- データ凍結と最終照合の手順を通した
- 延期・切戻しの条件と判断時刻を決めた
ERP本番切替計画について、申込や依頼の前に確認しておきたい項目を整理しました。条件を一つずつ照合して、納得できる選択につなげましょう。
図の項目を使い、候補ごとの回答を同じ条件で記録してください。不明点を残したまま進めず、追加費用・契約条件・利用後のサポートまで確認してから最終判断します。
切替計画は担当者と時刻まで書く
本番切替では、環境を公開するだけでなく、旧システムの停止、データ抽出、最終変換、残高確認、利用者への案内、連携再開が連続します。各作業に開始条件、担当者、想定時間、完了証跡、次の作業への依存関係を付けます。
週末や月末を選ぶ場合は、休日対応、取引先の営業日、銀行・物流の締め、利用者の交代勤務を確認します。複数拠点で時間帯が異なるときは、全社共通の切替時刻と個別担当を明示します。
データ凍結と差分の扱いを決める
旧システムの入力を止める時刻と、止められない業務をどう処理するかを決めます。凍結後に生じた注文・入出庫・入金などの差分を、いつ誰がどの方法で新システムへ反映するか、リハーサルで確かめます。
最終移行では、件数、金額、残高、在庫、未処理伝票など、業務ごとに必要な照合を行います。差異が出た場合は許容範囲、再抽出の条件、確認責任者を明確にし、合格を口頭だけで判断しないようにします。
Go/No-Goと切戻し条件を事前に決める
切替の可否は、システムが起動したかだけで決まりません。重要なテストの合格、データ照合、利用者権限、連携先、問い合わせ体制、重大課題の状況を基準に判断します。
業務停止を続けることができない場合に、旧環境へ戻すのか、新環境で限定運用を続けるのかを比較します。切戻しを選べる期限、旧環境へ戻すデータ、切替後に登録された取引の扱い、承認者を切替前に決めます。
リハーサルで実測し、手順を修正する
計画表の所要時間は想定だけで確定させず、テスト環境で同じ順番を実行して実測します。データ量やネットワーク条件が本番と異なる場合は、差と追加余裕を見積もります。
リハーサルでは、担当者が不在、データに差異、連携停止、利用者がログインできないといった状況も演習します。作業のやり直しや連絡遅延を記録し、手順書、連絡網、切替判断時刻へ反映します。
- 切替日程・作業順・完了条件・責任者
- 入力凍結・差分取込・最終照合の手順
- Go/No-Go条件と判断参加者
- 障害連絡・延期条件・切戻し期限
- 旧データの参照・保存・利用終了条件
稼働直後の支援と改善を切替計画に含める
稼働初日は、問い合わせの受付時間、緊急度、担当者、ベンダーへの連絡経路を周知します。重要業務の状況を決まった時刻に確認し、未処理件数やエラーを早めに把握できる一覧を用意します。
安定化期間の終了条件を、経過日数だけでなく重要な締め処理や月次業務の完了で定めます。初期課題を優先順位付けし、データ修正、教育追加、機能改善へ振り分けて通常運用へ引き継ぎます。
切替リハーサルで所要時間を測る
本番切替と同じ担当者、権限、連絡方法、データ量をできるだけ再現してリハーサルを行います。マスタ、残高、未完了伝票、添付ファイルなど対象データごとに抽出、変換、取込、照合の所要時間を測り、どの工程が全体日程を押すか確認します。手順書の記載と実際の画面が合わない箇所、判断が必要になった箇所、待ち時間を記録し、次のリハーサルまでに修正します。
リハーサルは一度で終えず、重大な差異が解消されたかを再実行します。件数一致のほか、残高合計、代表取引の追跡、連携先の処理状態、未完了データの例外を確認します。切替日が決まってから初めて必要人員が足りないと判明するのを避けるため、休憩や交代要員も含めた実働計画を作り、夜間・休日対応が契約範囲に含まれるか確認します。
Go/No-Goとロールバック条件
切替の実施判断は、重大な不具合件数、データ照合、権限、連携、問い合わせ体制、未解決リスクなど、測定できる条件で決めます。会議の参加者と最終決定者を事前に指定し、条件が満たされない場合に延期する権限を誰が持つかを明確にします。売上機会を逃したくないという理由だけで条件を曖昧にせず、延期した場合の代替業務と顧客への案内も事前に用意します。
切戻しが可能な時間、判断する時刻、戻すデータ、旧システムへ再入力する対象を決めます。新旧両方へ同じ取引を入力すると不整合が起きるため、どちらを正本とするか、切戻し境界後の伝票をどう回収するかを手順化します。切戻しが現実的に不可能な場合は、その理由と代替復旧策、追加承認者を明示し、経営層がリスクを理解したうえでGo判断を行えるようにします。
稼働初日の支援と安定化
稼働直後は、問い合わせ窓口、業務別の一次対応、技術担当、ベンダーの連絡先を一本化します。問い合わせ票には、業務、発生時刻、対象伝票、緊急度、回避手段、担当者を記録し、同じ問題が複数部門で起きているかを見ます。朝会では件数だけでなく、出荷や締めなど停止すると影響が大きい業務を優先して確認し、決定事項と次の更新時刻を利用者へ周知します。
最初の数週間は、通常の改善要望と稼働阻害の不具合を分けて扱います。旧手順へ戻す必要がある場合は、対象業務、期間、二重入力の解消方法、終了判断を記録し、例外運用が恒久化しないようにします。安定化終了の条件は、重大障害ゼロだけでなく、主要業務の処理完了、データ照合、問い合わせの減少、運用担当への引継ぎ完了などで判断し、移行プロジェクトから通常運用へ責任を移す会議を設けます。
切替当日の状況を一元管理する
切替当日は、工程の開始・終了時刻、担当者、件数照合、発生課題、判断、連絡先を一つの進行表へ集めます。工程の遅れが後続作業に与える影響を責任者が判断し、現場への案内は確定情報と次回更新時刻を分けて伝えます。予定外の手作業が発生したら対象データと入力先を記録し、復旧後に二重登録や取りこぼしがないか照合して、安定化レビューへ引き継ぎます。
参考にした公式情報
制度・仕様は更新されるため、実施前に最新の公式情報を確認してください。
本記事は一般情報です。個別の法務・税務・労務・契約判断を代替しません。制度変更や自社への適用は、最新の公式情報と専門家にご確認ください。