新システムの稼働前に準備しておきたいこと
ソフトウェアをサーバーに配置しても、すぐに業務を切り替えられるわけではありません。利用するアカウント、データの入力先、処理途中の仕事の扱いを、担当者が理解している必要があります。これらが曖昧なままでは、テスト済みのシステムでも注文の見落としや部門間の情報の食い違いが起こりかねません。
本番稼働とは、実際の業務を従来のやり方から新しいやり方へ移すことです。そのため、業務、技術、サポートの担当者が一緒に計画する必要があります。この記事では、受注管理ソフトウェアを入れ替える架空の企業を例に、切替前、切替中、稼働後に準備したいことを説明します。
1. システムと利用者の準備を確認する
稼働日を決める前に、新システムで必ず行えなければならない業務を確認します。受注管理の例なら、担当者が注文を登録し、管理者が承認し、倉庫へ正しい出荷数量が届く必要があります。各画面が正常に開いても、注文が一連の流れを通らなければ十分ではありません。
各部門の責任者が、自分たちの業務に関わる確認結果を承認します。技術側は稼働環境、接続、エラーの監視を確認し、業務側は数値や処理の流れを確認します。未解決の問題には、影響、暫定対応、続行を認めた人を明記します。反対意見が出ていないことを、すべての部門の準備が整ったという意味に受け取らないようにします。
例えば、表示ラベルの色が違っていても誤解を招かなければ、後で修正できる場合があります。一方、倉庫へ誤った数量を送る問題は、稼働を見送る理由になり得ます。これは影響を考えるための例であり、すべての案件に共通する許容基準ではありません。判断する人が、残る問題の結果を理解していることが重要です。
利用開始を承認する前に、実際の利用者が重要な場面を試し、期待する結果を記録しましょう。システムの受入テスト、何を確認する？では、その確認の準備を説明しています。「テスト済み」という報告だけでなく、業務を実行できると確認した結果に基づいて、開始を判断するためです。
利用者側の準備も必要です。アカウントでログインでき、担当業務に合った権限があり、職場の機器で使えることを確認します。担当者にはサンプルの注文で練習してもらい、困ったときの相談先も伝えます。画面のボタンを紹介するだけでは、顧客からの変更依頼や注文の保留といった場面には対応しにくいでしょう。
2. 切替の手順と担当者を決める
切替の計画には、作業の順番、実施者、確認者、次の段階へ進める条件を記載します。この例なら、旧システムの注文更新を止め、最終データを取り出し、新システムへ移し、照合後に利用開始を知らせる流れが考えられます。あくまで説明用の手順であり、実際のシステムに合わせた確認が必要です。
各段階の完了が何を意味するのかも、関係者でそろえます。「データ移行済み」とは、取込みが終わった状態でしょうか。それとも注文件数や債権残高まで確認した状態でしょうか。「利用可能」は、ログインできるだけなのか、新しい注文が正しく倉庫へ届くと確認できた状態なのか。完了条件を明記すると、一方が終わったつもりで、次の担当者が待ち続ける事態を防げます。
特に、切替中に発生する取引をどこへ記録するかを決めます。データを抽出している間も営業が旧システムへ入力し続けると、その後の注文が新側へ移らない場合があります。両方への入力を認めるなら、重複を防ぐための識別と照合が必要です。新システムへのデータ移行、何を確認する？では、データの締め、追加分の確認、利用前の照合を説明しています。
切替の日時は業務の周期に合わせ、週末なら適しているとは考えないようにします。小売業では週末が最も忙しいかもしれず、経理は決算や月次締めの時期に止められない場合があります。確認者とサポート担当者が、その時間帯に対応できることも必要です。顧客が少ない時間でも、結果を確認する人が不在なら作業は長引きます。
技術作業だけでなく、一連の流れを練習する
本番の切替前に、適切な環境で計画を試すか、関係者で各手順をたどり、不明な点を見つけます。担当者は、所要時間、誰の対応を待つのか、どこへ連絡するのかを把握する必要があります。例えば、データの確認者が倉庫の始業後にしか対応できないと分かったら、稼働前に予定や担当を見直します。
拠点や利用者のグループごとに導入する場合は、代表的な業務があり、支援しやすい最初のグループを選びます。拡大する前に、次の拠点では機器、承認方法、データの共有範囲が違わないかを確認します。段階導入は一度に影響を受ける人数を抑えられる一方、移行中は新旧の進め方を調整する作業が増えます。
3. 切替がうまく進まない場合に備える
計画には、いつ止めるのか、誰が決めるのか、その間の業務をどう続けるのかを明記します。受注の例なら、新しく登録した注文が倉庫へ届かない、最終数値に説明できない差異がある、といった場合に入力を続けてよいかを責任者が判断できる必要があります。各部門が独自に対応を選ぶ状態は避けましょう。
開始前に延期する、新システムを一時停止して修正する、用意した代替手段へ戻す、という三つの対応を分けて考えます。選択は問題の種類、すでに発生したデータ、残り時間によって変わります。新しい取引を記録した後は特に、旧システムへ簡単に戻せるとは限りません。
例えば、新しいソフトウェアで何件か注文を登録した後に問題が見つかったとします。その注文を反映せず旧システムを再開すると、倉庫が見落とす可能性があります。照合せず再入力すれば、二重配送につながりかねません。戻す計画では、新しいデータをどう保存し、確認し、どこへ移すかまで決めます。技術側と業務側が同じ方法に合意している必要があります。
代替手段を実行する時間も確保します。切替の予定時間を使い切ってから判断すると、次の勤務が始まるまでに復旧できないかもしれません。問題が深刻になるのを待たず、試行で確認した所要時間をもとに、警告を出す条件と判断期限を決めておきます。
バックアップが代替策として役立つのは、必要なデータを戻し、システムを使える状態にできる場合です。障害に備えるデータのバックアップと復元では、実際の問題でコピーを使う前に確認したいことと、復元を試す方法を説明しています。
4. 稼働後の業務を確認し、利用者を支える
利用開始後は、注文が正しい部門へ届いているか、処理が止まった注文がないか、担当者が手書きなどで補っていないかを確認します。画面にエラーが出ないだけでは、全体が正常とは判断できません。特に部門をまたぐ処理は、業務側と運用側で重要な取引を一緒に確認します。
稼働直後は、問い合わせの窓口と振分け担当を決めます。注文が見つからない原因は、権限の不足、未移行データ、絞込み方法への不慣れなど、さまざまです。すべてをソフトウェアの不具合として報告すると、技術側が誤った原因を調べることになります。操作、共有してよい注文番号、発生時刻など、確認に必要な情報を報告してもらい、機微な情報を広く参加できるチャットへ送らないよう案内します。
残る問題は、解決するか、合意した対応が整うまで追跡します。一時的に注文を手書きで受けるなら、後で照合して登録する人を決めます。この作業を省くと、暫定対応で受けたデータが失われかねません。同じ操作ミスが繰り返される場合は、個別に回答するだけでなく、手順書や仕事の組み立てを見直す必要があるかもしれません。
切替時の支援を終える前に、運用側がアカウント、手順、連絡先、未解決事項の一覧を受け取っているか確認します。警告の監視、ソフトウェアの更新、支援に含まれる範囲も合意しておきます。ソフトウェア保守には何が含まれる？では、利用開始後も続く作業を整理しています。
予定していた日数が過ぎたという理由だけで、支援を終えないようにします。重要な取引を確認したか、業務を妨げる問題を解消したか、運用側が残件を引き受けられるかなど、合意した条件を確認します。未達なら、責任者が追加で必要なことと支援の継続方法を決めます。
Fenixと導入を準備する際は、止められない業務、切替の予定、各部門で確認を承認できる人の三点から整理できます。それをもとに、実際の運用に合った日程、開始条件、問題発生時の対応を一緒に検討します。
