※このフェーズは長いので、3つに分けて書きます。
user-phase2

システムはアプリケーションだけでは使えません。データが必要です。

マスタデータ、在庫データ、債務・債権データなどを現行システムから持ってこなければいけません。

データ移行は典型的なグレーゾーン

かなり重たい作業ですが、システムの仕様策定のほうに集中してしまい、つい見落としがちです。
移行費用を見積に入れるよう必ず議題に上げるべきです。

ここで議題に上げておかなければ、後から追加しにくくなります。結構な費用がかかるからです。

それでも安いものです。情シスが四苦八苦しながらデータ整備するのに比べれば。
これも経営者の理解を得づらいところです・・・


私のときは販売管理システムの受注残・発注残データの移行を見落としました。ベンダーに泣きついて作業をお願いしました。

事前にベンダーが指摘してくれなかったのも原因です。面倒な作業なので、わざとグレーゾーンにしているのです。
ベンダーから積極的に言ってくることはありません。フェーズの最後の最後で「移行データの準備をお願いします」としれっと言ってきます。

こちらから早めに言うしかありません。
具体的にどのデータを、どのように移行するのかをはっきりさせておくべきです。


移行費用を払っているにも関わらず、「Excelフォーマットを用意するので、現行データを加工してそのフォーマットに入力してくれれば、それを新システムに移行します」とぬけぬけと言ってくるケースもありました。

その加工部分が一番大変な作業なのに。何度も罠にかかり泣かされました。ホントベンダーは汚いです。

ベンダー主体ですべてのデータを移行させる

情シスで移行作業を行うのは、大変な労力がかかります。

以降のフェーズでも、こういったグレーゾーン作業のしわ寄せはすべて情シスに押し付けられます
ベンダーも打ち合わせの場で煮詰まると「それは情シス作業ですかね・・・」と簡単に言い放ちます。


上流フェーズからこのような細かい作業を安請け合いしていたら、間違いなく破綻です。誰かに頼ろうにも、ひとり情シスにマンパワーはないのです。

細かい作業は基本受けないように立ち回る必要があります。

別に情シスがサボろうというわけではないのです。
予期せぬところで、手を動かさなければいけない場面が必ず出てきます。そのときのためにも余力を残しておく必要があるのです。


すべてベンダー主体で移行されるように全力でもっていきましょう。上司を使いベンダー営業を動かすなど、なりふり構わずで良いと思います。


もし今回のプロジェクトが基幹システムの更改で、新旧システムのベンダーが同じ場合、
データ移行をやってもらえなければ、同一ベンダーにする理由が無いです。

プロジェクトを振り出しに戻すくらいの気迫で主張すべきです。


もしこの交渉に失敗すると、以降のフェーズでデータ移行作業の負荷が増えることになります。
情シスが現場レベルで手を動かしている時点でプロジェクトは終わっています。

情シスは全体のコントローラーに徹するべきです。
この辺も経営者の理解があると良いのですが・・・


このフェーズでは、開発範囲の拡大を抑えつつ、情シスに細かい作業が来ないようにするのが目標と言えます。


次のフェーズに進みます。要件定義と並んで重要なフェーズです。

関連記事:
基幹システム導入 仕様策定3/3-データ移行内容の明確化(この記事)