ITコーディネータの動き方 導入編

プロジェクトの最後の仕上げとして、ITCは構築されたシステムの導入を支援することになった。システム構築自体については開発ベンダが責任を持つが、これを実際の業務に使えるように企業に導入していくのはユーザが主体となって取り組まなければならない仕事である。
導入には社内で様々な作業が必要となるが、特に、現業部門の協力が不可欠なものが多い。そのため、社内のベクトルをひとつにあわせて導入に向けた協力体制 を整備していく必要がある。しかし、プロジェクトメンバーは現業部門には無理は言いにくいし、言われる側からしても、社内の人間、特に職級が下のものから あれこれ言われると正論であっても(正論であるからか)面白くはない。そこで、ITCには第三者の立場で、現業部門とプロジェクトとの間の調整役として動 くことが求められてくる。

導入のタスク
導入までに必要な作業には、大きく分けると「移行」「展開と研修」「受入テスト」がある。「移行」にはシステムを動かすために必要なデータを準備する 「データ移行」と現行業務から新システムを使った新業務に運用を切り替える「業務移行」とがある。
システム稼動に失敗する例には、ベンダ側の不手際で構築が遅れる場合だけでなく、ユーザが「移行」に手間取って切替が遅れてしまうケースや、「受入テス ト」や「展開と研修」が不十分なために導入後に業務運用に支障をきたし、それで現場が混乱してシステムが信頼をなくしてしまうようなケースも多い。
これらはユーザが主体となって進める作業であり、安定したシステム稼動を実現するにはユーザ側での十分な準備が必要になる。
以下、それぞれの作業について、取組みの概要と留意点を説明していく。

(1)データ移行
新システムに必要なデータの登録は以下のような手順で進めた。

○移行対象の決定

先ず、移行の対象を決定した。検討についてはマスタ系(例 商品や顧客などの基本情報)とトランザクション系(例 注文や在庫など取引によって発生する処理情報)に分けて進めた。
(マスタ系)
新システムで使用するマスタ類を確認し、現行システムのマスタと対比して同じものは流用できるように準備した。
同じマスタであっても、現行マスタには既に使用されていないのに削除されずに残っているものも多くある。そのため、この機会に不要なものは整理しておくこ とも進めた。ただ、マスタによっては選別に時間がかかるものもあるので、取りあえず全件を移行しておくという対応をとったものもある。
マスタについては全件を移行するのか、必要な分だけに絞り込むのかという方針は決めておき、絞り込む場合には現行マスタを精査する時間を確保しておく必要がある。
(トラン系)
トラン系については履歴を持つかどうかを先ず決定した。履歴がなくてもシステム上の処理ができない訳ではないが、過去情報の分析や参照ができたほうが処理 が楽になる場合もある。ただ、履歴を持つ場合にも過去何年分を持つのかを決めなければならない。あまりに古い履歴まで持つことは、意味もなく移行の努力が 無駄になるので見極めが必要である。

○移行手順の決定

次に、移行対象となったデータごとに移行方法を決めた。
移行方法には、新旧システム間で連携を行う方法、新システムの画面から直接に打ち込む方法、CSV(エクセルシート)に整理して読み込ませる方法などがある。
・システム間連携にはベンダ側でのプログラム作成が必要なので、ボリュームが多いなどで他の手段では手間がかかるとか、形式が似通っていて簡単にロジック で変換できるなどの条件が揃ったものだけに適用した。
・エクセルシートは対象データがある程度のボリュームがあり、ちょっとした加工も必要な場合に適用した。この移行用シートの作成はデータ内容の判断ができ る各部署に依頼したが、取込はプロジェクトの窓口担当者が各部のシートまとめたうえで、開発ベンダに依頼する手順にした。個別にすると混乱するし、責任を 明確にする意図もあった。
・件数の少ないものは、新システムの画面入力で対応した。整合性のチェックも入力時にかかるのでデータの信頼性は高くなる。このためマスタの入力機能につ いては本体に先行して開発できるようにベンダと調整した。

○移行スケジュールの作成

移行方法を決めた後、どのデータを何時までに仕上げるかについて、マスタの論理的な前後関係や各部の担当者の負荷も見ながらスケジュールを立てた。
システム間連携の場合は、新旧システムのベンダ間での調整も必要になる。
エクセルの取り込みの場合にも開発とのスケジュールを調整しておかないとベンダの混乱を招くので注意が必要。開発中は割り込みの仕事は嫌われる。

○移行用シートの作成

先ず、システム設計で定義された新マスタの項目を見て、必須項目を確認し、そのソース(どこからもってくるか)を検討した。必須項目以外については、未決 でも運用後の設定で対応できるので、慌てて埋める必要はないとした。
この移行項目をもとに移行用エクセルシートを作成した。入力する現場の負荷を軽減するために、現行システムからのデータ流し込みで埋まる部分はなるだけ埋 めるようにした。また、業務的にはひとつのデータとして扱っているものがシステム上は複数ファイルに分かれる場合があったが、これも各部での処理がしやす いように作成用シートは一本にまとめ、取り込み時に窓口担当で分割するようにした。
こうして作成した移行用シートを各部へ配布し、新規項目の追加や見直しによる修正を行ってもらい、移行データを完成させた。

○移行の検証(移行処理後)

移行データの取り込みはベンダに依頼したが、移行データが正しく登録されているかどうかは移行シートを作成した各部で確認しなければならない。
特に、エクセルを使用した場合には項目のズレなどが発生しやすいので注意が必要だった。
移行作業の完了の都度、各部で新システムの画面から参照したり、確認用リスト(ベタ打ち)を出力して登録内容を確認してもらった。

(2)研修と展開
新システムをスムーズに運用するには、各部署が新システムを意識した業務運用のイメージを描いて準備をしておく必要がある。そのために、各部への事前の十 分な情報提供(展開)と研修を実施することが重要だった。

○展開の準備

・個別の業務ごとに新システム後の業務運用イメージをメンバーが中心になって各部署で描いておくようにした。ここでは新業務フローをもとに、イレギュラー も含めて詳細に運用を検討してもらった(これはテスト時のシナリオのもとにもなった)。
・特に、購買や営業など外部との接点のある部署については、関連する外部(得意先や仕入先)に対して影響が生じる部分を確認しておくようにお願いした。
・業務運用の検討を通じて生じた懸念点や不安になる事項は整理し、プロジェクトを通じて対応を検討して共有するようにした。

○展開

・展開は一般ユーザへの意識付けという意味もあるので、グループウェアなどによる一方的な情報提供だけでなく、キャラバンとして各部へ出向いたり、システ ムの概要ができあがった段階(画面や帳票が固まる時期)に説明会を実施するなどのイベントも設定した。
・先に述べたように購買や営業は仕入先や得意先に対して、変更によって影響が出る内容を事前に説明しておく必要があった。特に、仕入先については小規模な 企業も多いので十分な根回しをしておかないと混乱することも考えられるし、彼らの協力を得られないと本来の納期短縮が実現できないこともあるので、十分な 配慮をした。ついてこられないような外注先には切捨てるか判断し、それが無理なら個別フォローも実施した。

○研修の準備

・研修ではプロジェクトメンバーが先ずベンダから教育を受けて各業務の内容を覚え、これを現場に教えていく流れをとった。
・先ず、研修対象者を確認(対象部署と研修が必要な機能の整理)し、講師になるメンバーの稼動状況もみて実施スケジュールを作成した。
・次に、集合研修を行う場所と端末、研修環境を準備した。経営層の理解もあって、このために大会議室を2週間程度確保して研修場所にあてることができた。
・研修用のマニュアルも準備した。ベンダが作成するマニュアルはあくまでシステム操作だけなので、どんな時にどうするという業務的な説明までは期待できな い。業務運用からみたシステムの使い方については業務フローをもとにして各部のメンバーで作成するようにした。

○研修の実施

スケジュールにしたがって集合研修を実施した。研修に並行して各部に端末展開が始まったので、時間を決めて自由に操作をしてもらいシステムに慣れてもらうようにもした。
また、特定部署に関する業務については、集合研修とは別に現場に赴いて教育研修を実施したものもあった。

(3)受入テスト

システムの導入に先立って、業務運用を確認するテストを行った。これは、ユーザが主体となって業務フローをベースに実際に新システムにデータを投入して機能を確認するものである。
ユーザも参加するので、ろくに動かないシステムでは付き合う時間が無駄になる。システム自体のテストはベンダ側で完了していることが前提であった。ユーザ ではそれまでに業務運用を固め、テストで確認したいケースを準備しておいた。
テスト環境は本来ならデータ移行している本番系とは別に持てればよいが、費用もかかるので、開発ベンダと調整して本番系と兼用とし、テスト実施後に初期状態に戻すような運用をお願いした。
運用テストの流れは以下のとおりである。(テスト計画書については別紙サンプルを参照)

○テスト計画を作成してプロジェクトで確認

テスト計画書でテストの目的と方針を確認し、想定サイクル(日次、週次、年次)、体制と参加部署、スケジュール、合格基準(リリース判定基準)などを定めた。

○テストシナリオ(テストケース)を洗い出し

テスト対象の業務の流れ(シナリオ)を設定し、その中で確認したい項目(テストケース)ごとに、確認内容、確認用の入力、確認する出力と基準(何をもって OKとするか)を整理した。ケースには通常ケースと例外ケースを用意した。
・通常ケース
業務フローにそって通常データが正しく処理されるかを確認するもの。疎通確認とも言う。
・例外ケース(特殊なケース)
各業務担当者で気になる点を洗い出し、その確認用のケースを設定するもの。あらかじめ確認したい事柄(懸念事項)は各部で整理しておいてもらった。
・分担については、シナリオにそって業務間の流れを確認するためのテストケースはプロジェクトで、個別機能を確認するためのテストケースは各担当で設定す ることにした。また、他システム間の連携も確認対象として、忘れずにテスト範囲に含めるようにした。このために他システムの担当(ベンダ)との調整も必要 であった。

○テストデータを準備

・テストケースごとに投入用データを準備
テスト時に画面から投入するものは、ケースごとに画面のハードコピーを用意して入力項目を書き込んでおいた。また、検証用に上記に対するアウトプットイメージ(正解イメージ)も用意しておいた。
・処理確認用データを準備
一覧式の帳票や画面の確認には、ある程度のボリュームが必要なので予めデータを準備しておいた。これには、移行が済んでいる過去実績データを流用して対応した。
・サイクル管理表の作成
テストの想定日ごとに投入データや確認ポイントなど詳細な手順を整理したものを作成した。これはテスト開始時に、参加者全員での事前確認会にも使用した。

○テストの実施

サイクル管理表の手順にしたがってテストを実施していった。
入力して、結果を確認し、問題なければ確認用にチェックする。障害を発見した場合には問票を発行し、障害への対応と管理はベンダにお願いした。
テスト期間中は朝会を開いて当日のテスト内容を確認し、生じた問題はその日の夕会で確認した。
なお、SOX法からみで、テストケースやテストデータ及び結果は監査証跡として整理・保管しておく必要があったので、実施者にもその意味を説明して保管(勝手に捨てないこと)をお願いしておいた。

(4)業務移行(リリース)
運用テストで新業務の実施検証が完了し、テスト計画書で設定されたリリース基準に照らして、システムの品質も一定レベルのものと確認されると、役員会での 承認を受けたうえで運用テストを終了しリリース作業に移った。
リリースとは新システムの実運用を開始すること、旧システムを使用している現行業務から新システムを使った業務に切替を行うことである。

○リリース計画の作成

これに先立って、リリースの手順書(リリース計画)を作成し、必要な準備作業を洗い出しておいた。テストは十分に行ったが、それでも本番で障害が発生する こともあるので、トラブル時の連絡網も作成し、現場に通知書とともに配布した。
○リリース準備
リリース作業では、先ず、開発ベンダがテスト中に行った修正を反映させた最新バージョンにプログラムを更新し、テストで使用したデータを消去して本番用データをセットしてシステム環境を初期化する。
次いで、旧システムで未完了の受注分などを登録して準備を完了する。
そして、翌日の朝から新規データ入力を開始する、という手順になる。
ただ、いきなり切り替えて失敗すると影響が大きいので、数日前にリハーサルを行い、手順に問題がないかを確認しておいた。

○リリース
リリース当日はITCもメンバーと待機していたが、大きな問題もなく一日の運用が終了した。
その後、週次や月次の処理も大きな問題もなく過ぎ、6ヶ月後の期末の処理に問題がなければ、システム導入は一応の完了となり、次の実運用と効果検証(モニタリング)のフェーズに入ることになる。

シェアする

  • このエントリーをはてなブックマークに追加

フォローする