◆めざせ、ワンタッチ段取り
運用試験の最後には、システムの本番移行が待ち受けている。全くの新規システムであれば、さほど問題も無いかもしれないが、既存のシステムからデータを移行するような場合には、周到な準備が必要である。切替時のリスクを最小にするには、新旧システムを一定期間並行稼動するのが一番良いが、利用者には二重作業の負担を強いることになる。また、システムの性格上、並行稼動が困難な場合も少なくない。そこで、切替のリスクを最小にするには、工作機械の段取りの考え方が参考になる。
トヨタ方式では、この段取りを如何に効率よく実施するか研究を重ねた末、従来は３～４時間かかっていたものを、１０分以内にまで短縮した。これを「シングル段取り」と言う。さらに、これを推し進めて極限まで短縮したのを「ワンタッチ段取り」という。システムの切替も、理想はワンタッチ段取りである。これを実現する考え方は、まず、段取り作業を外段取りと内段取りに分ける。外段取りとは、機械を止めなくても実施できる事前準備作業である。内段取りとは、機械を止めて行わなければならない作業である。段取り作業を分析し、できるだけ外段取り作業の比率を増やし、機械を止めて行う内段取りの時間を極限まで短縮する。
これを、例えば、データベースの移行に当てはめてみると、まず、毎日動いているデータと、そうでないデータを選別する。毎日動いていないデータは、切替日以前に移行を完了して、検証する。毎日動いているデータは、休日や夜間など切替の直前にデータを移行する。その場合も、移行プログラムを先頭から一気に流すようなことをせず、事前に実行できる部分と、そうでない部分に分けて、できるだけ事前に実行しておく。データベースへの登録直前までのデータを作成しておき、切替ではデータベース更新作業のみを実行する。あるいは、データベースだけを事前に移行し、その後、切替日までは、既存のデータベースの毎日の更新差分を、新データベースに反映し同期をとっておき、切替日は、画面などのユーザ・インターフェースのみを切り替える。画面の切替も、メニュー以外の画面は、事前に全て切替を完了して検証しておき、切替の直前にメニュー画面だけを切り替える。リスクを緩和するには、切替日も連休明けに設定するなどの配慮が必要となる。
そもそも、リスク管理の観点からすれば、こうした移行に関わるリスクと準備作業についての検討を、移行間際になってからやっているようでは遅い。移行に対する条件や要件は、要件定義や要求仕様に盛り込むべき内容でもある。例えば、新データベースを設計する時に、既存のデータを、どのように移行すべきかを考えて設計しなければならない。特に、データの識別子が、変更されるような場合、機械的な変換だけでは済まないケースもある。
事業所毎の人事マスタを、全社統一マスタに移行するようなケースでは、既存マスタの識別子が、社員番号であると、事業所間で重複した社員番号を持っている可能性がある。これを、全社統一マスタの識別子を社員番号のみにした場合、全社で一意に識別できるように再設定しなければ、データが重複して移行が不可能となる。これは、周辺の業務や関連システムを考えると膨大な作業が発生する。このようなことが、移行間際に発覚した場合、切替は数ヶ月遅れることになる。
ＥＲＰパッケージ導入で、移行時に問題になるのが、こうしたケースである。既存のデータベースの識別子とＥＲＰの持つそれが、異なるのである。既存のデータの粗さが、ＥＲＰよりも粗い場合は問題ないが、逆の場合は、ＥＲＰに合わせるためには、既存のデータを、なんらかのルールで集約しなければならない。この集約が問題となる。データの粗さは、管理精度を表す。これを集約するということは、管理精度が粗くなるということであり、これが、自社にとって受け入れ難いのであれば、ＥＲＰ稼動は中止する しかない。
移行間際に窮地に追い込まれないように、自社開発であっても、パッケージ導入であっても、移行時の検討がなされているかどうか、ぜひ、仕様書のレビュー項目に追加していただきたい。特に、データベースの識別子が異なる場合、新旧のデータが１：１対応であるか、１：Ｎ対応であるか、Ｎ：１対応であるか、Ｎ：Ｎ対応であるか、「粗さ」はどうなるか、移行によるデータの集約・分割は問題ないかなどが重要な検討項目になる。
コメント