子会社との合併に伴うシステム統合 No24 データ関連図

■　移行データ

細かいデータの抽出条件は分からないことが多いのですが、必要なデータについては見えてきました。前回うまくいった方法を変える必要はないので、今回も残高だけを持ってきます。

売掛残高、買掛残高、手形、在庫、工事契約、・・・主なものは、この位かな？

実際には、請求残高、検収残高みたいなのもあるといえばありますが、このあたりは売掛残高、買掛残高と連動させるので難しく考えなくて良いです。お客さんの締日に合わせて残高を作ろうとするのは無謀で、単純に月末日で切ってやれば良い話です。

この辺りは割り切りですね。

ここで無理に、売掛残高は月末で切って、請求残高は締日ごとに云々と移行しようとすると、請求書の明細に出力するデータはどうするんだとか、難しくなりすぎます。

同じ理由で並行稼働も避けるべき。移行後のシステムに不安を覚えて、旧システムと並行入力して数値が合うか見たいという案が出たりもしますが、システムの考え方が違うのですから、あちことで差異が出るのが目に見えてます。無駄に混乱するだけです。

実態と移行した残高が異なっていても、B/S、P/Lとさえ一致していれば、後は移行後に訂正伝票を入力して辻褄を合わせることが出来ますからね。

■　関連図

少し話が逸れましたね（苦笑）

ともあれ、必要な残高データの大枠が見えてきたので、簡単に関連図（相関表って方が適切かな？）を書いてみました。

移行先のテーブルは、前回の合併（子会社との合併に伴うシステム移行　No1　始まり）で把握済みなので、それにぶつけるデータが存在しているのか図にしていきます。

こうやって抜けが無いことを確認します。続けて、変換するために必要なコード変換について考えてみます。まぁ、コード変換と言っても、結局は取引先マスタに繋がるのですが。

・・・うーむ、やはり取引先マスタについて詳細に分析しないと、先に進めないな。

■　後書き

合併する会社が同業種なだけあって、追加開発が必要な機能が無い感じです。話を聞いた中では、この機能は必要だとか言うのですが、少し突っ込んで聞くと特定の人しか使っていないとか、過去の経緯がそうだったとか、そんなのばかりです。

良くあるのが請求書のレイアウト。ちょっと変わった集計の仕方をしていて、本当に必要なのか担当者に聞くと「お客さんが必要だと言っている、絶対に必要だ」の一点張り。

でも、嘘。実際にお客さんに聞いてみると、「そんな要望をした覚えは無い」で話が終わりました。結局、担当営業が確認するのを面倒がったりしただけでした。

相手の言葉を真に受けて追加開発を検討するのであれば、それが本当に必要な機能なのがしっかりと確認した方が良いでしょうね。

前回：子会社との合併に伴うシステム統合　No23　議事録の書き方
次回：子会社との合併に伴うシステム統合　No25　メーカーのWEBシステム

投稿記事の一覧：http://harikofu.web.fc2.com/

--- blog end —