子会社との合併の伴うシステム統合 No33 社内手続き

■　マスタ登録

システム統合では、まずマスタ系を移行して、それをベースにして各種データを移行するという流れになります。さて、ここでちょっとした問題になるのは、マスタ登録の社内ルールです。

取引先マスタの審査、与信の審査、商品マスタの審査、在庫マスタの・・・と、本来であれば登録するための社内手続きが存在するかと思います。

今回の合併は、親会社が子会社を吸収合併という形なので、親会社側で子会社のマスタを受け入れる必要があるのですが、それに対して通常の社内手続きを通そうというのは無謀です。

かと言って、何も手続きを踏まないというのも、それはそれで問題になりそうです。

■　理想

方法は色々とありますが、例えば事後申請を認めてもらう申請を上げておいて、移行処理が終わった後で移行したマスタの一覧表を作成し、それを使って申請を行う方法がスマートかと思います。

そもそも、会社として合併という方針を打ち出した時点で、お互いのマスタをくっ付けることを会社は認めていると考えられないかと思うのです。そうでないと、取引が継続できないですし。

基本はこの方法なのですが、実際にはなかなか難しいようです。

■　現実

システム統合の実作業を行う情報システム部と、会社の上位層は、筋を通せば問題ないと答えそうなのですが、各マスタの審査を請け負っている部署は色々と思うところがあるようで、やれ「この条件変更を行う場合には＊＊の申請が必要だ」とか、「＊＊の承認がないと出来ない」とか、色々と言うわけです。

そして、ちょっと困るのが、事前に登録される情報を見たいからと、移行後の形式に合わせたデータの提供を依頼された時です。移行後の形式を作るためには移行プログラムが必要で、その中で採番やコード変換などをしていた場合には、提供自体ができないです。

さて、困ったね。

■　後書き

各部署が形式論に拘るのは、立場を考えると理解できなくもありません。それでも、膝を交えて話せば理解を示すケースが多かったです。

ま、冷たい事を言うと、どこかの部署が頑強に抵抗した結果としてマスタ移行が出来なかった場合。それによって、現実の運用が止まってしまったとなると、今度は別の責任問題が・・・ってことな訳ですし、頷かざるえないという事情がありますからね。

ただ、重要だったのは「形式を整えること」でした。担当ベースや立ち話のような形で話して、さも依頼は終わったって考えていた人がいたのですが、これ、後で揉めました。

そうなるのが目に見えていたので、何度も「事前の調整としては良いけど、正式な依頼なら立ち話で終わらせないで、部署の長を交えた会議体を開いた方が良い。でないと後で祟りますよ」って言っていたんですけどね。悪い意味で予想通りの結果になりましたよ。

・・・結局、上司と俺が入って話を通しましたけど、本当に勘弁してほしい。

前回：子会社との合併の伴うシステム統合　No32　移行リハーサル（本番）
次回：子会社との合併の伴うシステム統合　No34　移行１回目

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

--- blog end —