システム移行フェーズ
システム移行フェーズでは、システムを稼働させ、ユーザに対しシステムの利用を許可します。
システム移行は旧システムがある場合は、業務を停止し旧システムを停止した上で、移行を行います。
業務の停止時間をできるだけ短い時間で済ませるために、タイムスケジュールを作り、分単位の作業となる場合があります。
段取りのミスなどによって、計画通りに作業が進まないと、業務に大きな影響を与える事になります。
事前のリハーサルを十分行い、ミス無く移行できるように準備しましょう。
システム移行手順書の作成
システムを移行するための手順書を作成します。
サーバー、アプリケーション、開発したアドオンの設定など様々な手順が出来上がります。
決められた時間内に、これらの作業が終了しなければならないので、タイムチャートを準備をする必要があります。
また、これらの作業要員の確保も必要です。
誰が、いつどの作業をするか、手順書とその担当を決めておきます。
体調不良などの不測の事態も考慮して複数人で対応できる体制が必要です。
システム移行リハーサル
タイムテーブル通りに作業が進むか、リハーサルを実施します。
何度もリハーサルを行い、実際のタイムテーブル通りに作業が進むか確認します。
リハーサルは、実際に運用する本番環境でできれば良いですが、今動いているシステムとの入れ替えをする場合は、本番環境でリハーサルはできません。
リハーサル用のサーバーを準備するなどしてリハーサルを実施します。
本番環境とリハーサル環境の差が、実際にシステム移行する際に大きな問題になる場合があります。
差を明らかにして、どう対応するか、作業者が分かるような手順書を準備しましょう。
システム、データ移行
新しい環境にシステムを構築します。
同時に、準備した既存のデータを移行します。
新しいシステムを構築し、データを移行するには数日かかる場合があります。
よって、業務を行っている平日ではなく、ゴールデンウィークや、夏休み、冬休みなどの長期の休みを使ってシステム、データ移行を行う事が一般的です。
限られた時間内に移行を終了しなければならないので、作成した移行手順書に従って段取り良く作業を実施します。
システム、データの移行が終わった後は、構築された新システムが正常に動作するかテストも必要です。
全て移行が終了し、テストも完了した段階で、プロジェクトで新しいシステムの稼働判定を行い、新システムを稼働します。
稼働判定は、プロジェクトオーナーに参加していただき、新システムが稼働することを承認してもらうと共に、新システムが稼働したことを社内にお披露目しましょう。
もしシステム移行に失敗した場合の事も考慮し、コンティンジェンシープランを準備しましょう。
思わぬ不具合が発生し、どうしても新システムへの移行ができない場合もあります。
そのような状態になった場合に、旧システムへ戻す手順などの準備をしましょう。
新システムへの移行には何が発生するか分かりません。
通常業務に影響が出ないようにする、それが大事なことです。
ユーザー教育
新システムが稼働する前に、ユーザーへの教育を実施します。
教育なしに、新システムをユーザーに使わせるわけにはいきません。
ユーザー数が数十人規模のシステムであれば、集合教育を数回実施すれば良いですが、1,000人規模のユーザー数となると、計画的に教育を実施する必要があります。
教育資料、教育環境、教育する指導員、教育時のユーザーのサポート要員、場所の確保など、教育するためには多くの準備が必要です。
また、導入するシステムが複数拠点にまたがる場合は、各拠点に上記の準備が必要です。
ユーザー教育は思っている以上に工数がかかりますので、十分注意してください。
運用/保守フェーズ
システムを導入し、新しい業務の運用を開始します。
導入直後でユーザーがまだシステムの使い方に慣れず、システムの初期不具合が発生する時期と、ユーザーがある程度システムの使い方に慣れ、システムが安定して運用できる時期で運用の進め方が違います。
短期、長期の運用体制を作り、ユーザーの質問に対して即座に対応できる体制を作りましょう。
システムを導入することも大切ですが、安定してシステムを稼働することも大事な仕事です。
特別サポート体制の構築/特別サポート体制
新システム導入直後は１週間から１ヶ月の間は、システムの不具合が発生する可能性が大いにあります。
いくらテストを十分にやったとしても、ユーザーの思わぬシステムの使い方、思わぬデータの入力によって、不具合が発生します。
新システム導入直後には不具合はある、と思って特別なサポート体制を構築しましょう。
「特別」とは、不具合発生時の速やかなエスカレーションルートの構築です。
不具合を発見したユーザーから管理者、管理者からプロジェクトの窓口、そしてベンダーとこれらの情報のルートを確立してください。
また、発生した不具合に対して、業務をどうするかを決める必要があります。
発生した不具合で出来上がったデータをどうするか、このまま業務を継続するか、この業務だけ新システムを使わないで、元の業務に戻すか、など動いている業務を停止するわけには行かないので、短時間での判断が必要です。
このような判断プロセスと、その判断結果を全ユーザーに伝える手段を準備してください。
新システム特別サポート体制の期間は毎日定例を設け、プロジェクト全体で稼働状況の確認し共有するなどをしましょう。
ユーザーの使用状況をよく観察し、何かあったら即対応できるような体制を構築してください。
運用/保守
稼働後１ヶ月程度経って、システムの不具合が落ち着いたところから通常の運用保守体制に移行します。
この後は、このシステムの運用が終了するまで、運用保守が続きます。
運用保守は思った以上に業務があります。
基本的にはユーザーから問い合わせ対応、新規ユーザーの登録と教育などユーザーのサポート業務、ハード面では、定期的なハードウェアのバックアップや保守業務などです。
また、新システムを使ってみると、想定した業務やシステムの仕様では実際の業務ができない場合や、システムの動きが想定したものと違うなどの場合があります。
確実に仕様から逸脱している場合は、ベンダーに修正を依頼できますが、ユーザー側の要求が間違っている場合は、システムの変更はできません。
このような場合に、業務をどのようにして成り立たせるのかを決定し、ユーザーに伝える必要があります。
このような問題が多く発生するので、ユーザーからの声を聞き取り、改善する仕組みづくりが必要です。
月１回程度このような問題の共有をする場を設けましょう。
新しいシステムを一方的にユーザーに使わせるのではなく、ユーザーの声を聴くことも大事です。
これらの活動は次の改善に繋がっていきます。
まとめ
システム導入の日程の全体感を出しました。
大方の方が「え！、こんなにかかるの？」と思ったと思います。
ベンダーがネットに紹介している日程を見ると「最短３ヶ月で導入！」なんてキャッチフレーズで勧誘されているところもありますが、これは全く失敗が無い場合の導入事例か、全体日程の中の設計、プログラミングの部分だけを切り出して言っている日程だと思います。
騙されてはいけません。
システム導入は思ったよりも時間がかかります。
覚悟しましょう。
あとは、この全体感をつかんだ上で、きちんとプロジェクト管理、日程管理をすることです。
それはまた別な記事で書いて行こうと思います。