プログラム開発が完了し、ベンダーから急かされるフェーズです。
ここからは一気に本稼動へ向けて進んでいくことになります。
同時並行でにやるべきことが多く、混乱しそうになりますが、冷静にこなしていけば大丈夫です。
テストの実施
前フェーズでの準備を生かし、淡々とやります。作成したテストシナリオを各部門で実施してもらいます。
情シス業務部分のテストも忘れずに。
下記の二重入力作業もあるので、テストシナリオができていて、テストがスムーズに実施できることがプロジェクト成功の前提になります。
逆に言えば、テストシナリオの出来が不十分だと、非常に苦しい思いをすることになります。
バグなのか、仕様変更なのか
テストをしているとさまざまな課題が出てきます。今までと同様、各チームから上がってくる課題は、すべてExcelなどで記録しておきます。
その課題はバグなのか、仕様変更なのか。ベンダーともめる永遠のテーマです。
これまでのフェーズで、こちらがきちんと作業していれば、基本的に細かい不具合はバグと認定され、ベンダーもすぐに修正するはずです。
現場からの「使い物にならない！」と言った根本的な問題は、その言葉をそのまま受け取ることはできないでしょう。
要件定義や仕様策定の際にきちんと検討されていなかったためと考えられるからです。そもそも議題に挙げていなかったり、または詳細まで詰めて考えていなかったり。
遅くともテスト作成の時に気づけば、ベンダーはまだ開発中ですので、交渉の余地はあったかもしれませんが。
どちらにせよ手遅れなのです。
この件に限っては、珍しく(笑)ベンダー側に立ちます。
プログラム修正するにも予算はないですし、慌てて修正することで、却って別のトラブルを誘発する可能性があるからです。
ひとまずは「本稼動後に考えましょう」と現場をなだめ、時間を稼ぎます。
そのまま運用でカバーできるなら、本稼動後もそのままにします。
問題となり続けているなら、プログラム修正予算を確保し、実装します。
予算確保の際は、もちろんいきさつも経営層に説明する必要がありますので、きちんと記録しておきましょう。大金を使ったばかりなので、そう簡単に追加投資に許可は下りないでしょうから。
ベンダーは所詮外部の人です。こちらから積極的に議題に挙げていかないと、最後にこういうことになるのです。
グレーゾーンを残しておいて、こちらに良いことは何もありません。その曖昧さはすべて、QCDのどれかの形をとって、こちらに押し付けられると考えてよいです。
二重入力
新旧システム両方に入力を行います。データは突き合わせて、本稼動に移行してよいかの判断材料にします。
「二重入力」とベンダーはあっさりと言いますが、現場の負担は相当なものです。
それぞれのチームは自分たちの伝票入力とチェックで手一杯となります。
そうなると、データの突き合わせにおいて、全体をチェックできる人は情シス以外いません。
ベンダーは合計金額くらいはやるかもしれませんが、それ以上に細かい突き合わせはしません。冷たいですね。
新旧システムのデータが合致しないと、いつまで経っても新システムに本番移行できません。
プロジェクトを早く終わらせるために、ここは情シスが腹を括って皆のために手を動かしましょう。
具体的には、ExcelマクロやAccessなどで突合チェックデータを作って、毎日メンバーに配信します。
二重入力期間中は、旧システムのデータが正なので、旧システムを中心としたチェックデータを作ります。
新旧システムのベンダーが同じなら、どうやってデータ突き合わせをすると正確か、どのデータをチェックすべきか、相談したほうが良いです。
販売システムですと、受注・仕入データを月次/日時単位・取引先単位・明細単位などの複数の切り口でチェックデータを作ると良いです。
大きな単位でズレを発見し、明細単位まで追跡することができるので、現場も修正入力しやすくなります。
私は以前の会社では以下6種類のチェックデータを毎日作ってメンバーに配信しました。
①【月次合計】仕入先ごとの仕入金額
旧仕入先コード、旧仕入先名、旧仕入金額、新仕入先コード、新旧仕入金額
→仕入金額の一致チェック
②【月次合計】得意先ごとの売上金額・粗利金額
旧得意先コード、旧得意先名、旧売上金額、旧粗利金額、新得意先コード、新売上金額、新粗利金額
→売上金額、粗利金額の一致チェック
③【日次合計】仕入先ごとの仕入金額
旧仕入計上日、旧仕入先コード、旧仕入先名、旧仕入金額、新仕入先コード、新仕入金額
→仕入金額の一致チェック
④【日次合計】得意先ごとの売上金額・粗利金額
旧売上計上日、旧得意先コード、旧得意先名、旧売上金額、旧粗利金額、新得意先コード、新売上金額、新粗利金額
→売上金額、粗利金額の一致チェック
⑤【日次明細】仕入先ごとの仕入金額
旧仕入先コード、旧仕入先名、旧商品コード、旧商品名、旧仕入金額、旧仕入計上日、旧伝票番号、新仕入先コード、新商品コード、新商品名、新仕入金額、新仕入計上日、新伝票番号
→仕入金額、仕入計上日の一致チェック
⑥【日次明細】得意先ごとの売上金額・粗利金額
旧得意先コード、旧得意先名、旧商品コード、旧商品名、旧売上金額、旧粗利金額、旧売上計上日、旧伝票番号、新得意先コード、新商品コード、新商品名、新売上金額、新粗利金額、新売上計上日、新伝票番号
→売上金額、粗利金額、売上計上日の一致チェック
ここでマスタのコードを変更していると、間にコード変換処理をかませる必要が出てきます。
だからプロジェクト中にマスタのコード変更はやらないほうが良いのです。
「ほぼデータが一致している」と判断できれば、本稼動に移行することになります。
※「完全にデータが一致している」ではないところがミソです。
マニュアル作成
マニュアル作成は、各チームの責任です。キックオフミーティングで言ってあるはずです。
関連記事：
ただ実はテストシナリオが充実していれば、マニュアルの骨子はできたも同然なんですよね。
頻度の高い業務から順にテストシナリオを作っているはずです。
全部のマニュアルは作れないにしても、2割の主要業務を押さえれば、全体の8割はカバーできるはずです。パレートの法則ですね。
各チームがどう動くかはわかりませんが、どちらにせよ情シス用のマニュアルは早めに作ったほうが良いです。
ここから本稼動に入ってしばらく経つまで、他部門のフォローをする必要が出てきます。
いくら事前に手作業が来ないように予防していたとしても、最後は情シスがやらざるを得なくなることも多いです。
手作業が集中しても、新システムの情シスルーティンワークは継続しなければならないのです。
ひとり情シスは誰も助けてくれないので、安定的に新システムのルーティンワークをこなす必要があります。
マニュアルがあれば、作業に迷ったり間違ったりするリスクを最小限にでき、最短で作業することができます。
そうなれば他部門のフォローに注力できます。
関連記事：
その他データ移行もありますが、それはベンダーさんにお任せで(笑)
いよいよ本稼動です。
関連記事：
