
■ データ全体
色々とデータを分析してみたのですが、流石にパッケージだけあってデータが綺麗。例えば、「債権残高として存在する取引先は、かならず取引先マスタに存在する」とか。コード自体に特殊な意味を持たせていないし(一桁目が1だったら***を表すとか)、文字コードとかも意識しなくて問題なさそう。
ただ、抽出できるデータレイアウトが綺麗じゃないのが引っかかるかな?
明細データ中に全社合計とかの行が存在していたりとか、子会社では使っていない項目(列)が大量に存在していたりとか。これは、共通のルールでデータを整形するシステムを用意した方が良いかな?
■ 差異の洗い出し
細かく差異を洗い出していくと、やっぱり色々と出てきました。
例えば、債権債務の残高の集計単位が違います。親会社は課単位で、子会社は支店単位で残高管理している(組織は、部門>支店>課)。これが逆だったら単純に支店に集約して移行すれば良かったんだけどね。
他にも、考え方の違いがたくさんあるので、どうしたものやら。
■ データのモデル化
移行に関するノウハウも無いし、必要な情報が揃っている訳でもないので、どうしていいかさっぱり分かりません。かと言って、情報収集ばかりで考え込んでいても何も話しは進みません。そこで、後で無駄になっても良いと言うつもりで形を作ってやろうと考えました。
とりあえず、取得したデータを組み合わせて擬似的なデータ連携図(ER図みたいなもの)を作って、そこから抽象化して移行先のシステムとの関係を表せないだろうか?
■ 後書き
仕事をしていると、今回のように教科書にのっていない問題の解決策を求められる事が出てくるのですが、私の場合は自分なりの考えで資料を作っちゃうことから始めます。と言うのも、大抵の人は自分で考える事をしない、または問題が発生してから考える(文句を言う)ってスタンスなので待っていても誰も何もしてくれません。
そこで、このまま進んだらこうなるんだよっていうモノを提示することで、意見や考えを引き出してやるんです。お喋りの上手い人なら立ち話でどうとでもするのでしょうが、私のように口べたで非社交的な人間には別の手段が必要なのです。
前回:子会社との合併に伴うシステム移行 No2 分析
次回:子会社との合併に伴うシステム移行 No4 必要な物(データ)とスケジュール
投稿記事の一覧:http://harikofu.web.fc2.com/
--- blog end ---
スポンサードリンク


