システム開発■ 本稼働準備完了！・・・？
移行リハーサルの結果を踏まえてプログラム、移行手順書などを修正して本番への備えは完璧。
・・・まぁ、システム的にはってことですが。
実際には、運用面の問題が大きいのでそちらが難しいんですよね。
■ 教育
何よりも、子会社の人たちにシステムの操作方法を覚えてもらわなければなりません。という事で、移行プログラムの開発と並行して現地に出向いて教育を実施しました。
・・・私以外の人が。いや、流石に移行プログラムの面倒とユーザー教育を並行して行う余力は無かったです。
移行リハーサルが終わった状態の開発環境を使って、実際に本稼働した後の状態を見て（触って）もらいながら教育を実施して貰ったのですが、かなり不安が残る結果だったそうです。
実際の所、グループウェアとかなら簡単なのですが、実際の業務と密接に関係する基幹システムの教育って難しいんですよね。よほどやる気のある人でなければ、本稼働前の教育なんて聞き流す人が多いし、実際に使ってみないと分からないことが多いですから。
■ 移行処理
移行処理は３回に分けて実施します。移行システム自体はシステム稼働中でも動くように設計したのですが、何があるか分からないので、システムの使用者が少ない休日にぶつけて、一週間に一度の移行処理を実行します。
・・・休日でもシステムは動かしているので、休日出勤している人には苦情を言われましたけど仕方がないです。
本当は、連休辺りで一度に移行処理を行うことが出来ればよかったのですが、運用面を考えると無理があったので分割実行です。それぞれの内容は下記の通りです。
■ マスタ系の移行（９月下旬）
環境整備の意味合いを込めて、各マスタ群の作成を行います。組織マスタとか、倉庫マスタとか、合併に伴って組織が増えるので、それに合わせて必要なマスタ群を作成します。この辺りは通常のオペレーションで実行します。
本題は、取引先マスタの移行（これは移行プログラムで行う）です。
本当は、この処理を単独で行う必要はなかった（普通は、次の移行処理に合わせても良い）のですが、移行データの精度が非常に悪いので、あえて単独で実行して各部署の人に状態を見てもらった方が良いという判断です。
・・・ここは、実際に色々とありました（あまり思い出したくない）。
■ 在庫、契約の移行（１０月初旬）
子会社には９月末の在庫を１０月の月初で固めてもらって、それを使って在庫を移行します。後は、未成工事の契約データも移行します。前週のマスタ系の移行と合わせて、これでユーザーがシステムを使用する下準備が整ったことになります。
債権債務が固まるまで待ってから一気に移行する手もあるのですが、それを待っていると受発注が止まってしまいます。
旧システムで入力、移行後に新システムで再入力という手間という面もあるのですが、過去にシステムの考え方の違いで金額に差異が出たりと多くの問題が出ることが分かっていたので、可能な限り早い段階で解放したかったんです。
って事で、ここからが本稼働です。教育に出向いていたメンバーが再度現地に出向いて、本稼働支援を行います。基幹システムの難しいところは、システムの操作方法だけでなく実際の商流、物流が複雑に絡むところで、この辺りは営業部隊からも本稼働支援のためのメンバーが出向いてい対応していたそうです。
・・・そして私は本社で移行後のシステムのお守り。
■ 債権債務、手形の移行（１０月中旬）
残りは債権債務と手形の移行です。ここまで来ると難しいことは無いので、単純に移行プログラムを流すだけです。債権債務については、決まるまでに時間が掛かると思ったので後ろにずらしたのですが、手形については前週に実行した方が良かったかもしれません。
手形が期日を迎えた時に行う処理が色々あるのですが、移行時点で期日を迎えていた手形をどう扱うのかっていう詰めが甘くて、移行後に手形の管理部門と色々と話し合う形になりました。
■ 後書き
私個人の性格もあるのですが、職務の内容的に本社に残って作業を行うことが多いです。というか、基幹システムの担当になってから出張した記憶が無い。
今回も現地に出向かずに本社で作業をしていたのですが、子会社の拠点の長（親会社から出向した方）に「お前はいつくるんだ」とか言われちゃいました。
行かないんじゃなく、行けないんです。目には見えないかも知れませんが、そちらに出向いたメンバーより多くの仕事を請け負っているんです！
・・・なんて思っても口に出せないですしね。やれやれです。
前回：子会社との合併に伴うシステム移行 No15 移行リハーサル
次回：子会社との合併に伴うシステム移行 No17 移行後
投稿記事の一覧：http://harikofu.web.fc2.com/
--- blog end ---
スポンサードリンク
0
0
