「鈴木さん、以前少しお話した在庫管理システムの入れ替えですが、立ち上げ日程がうまくスケジューリングできなくて困っているんです。」と電話をかけてこられたお客様がいらっしゃいました。以前セミナーに参加されていたお客様でしたが、当時あまり詳しい情報はお聞きしていなかったので、その背景を細かく把握したところ、以下のような状況でお困りでした。

開発作業は１月に終了する
ユーザーテストは２月に実施できる
その期間は２ヶ月あれば十分なので、年度初めに稼働開始できる
ところが、期末棚卸の数字を現在のシステムに入れないと決算できない
期末決算を現在のシステムで行うためには、新システムとの並行稼動期間が必要となる
それには工数的に対応しきれない
・・・・・・・・・・・・・

まるで解の無い問いの様な「どうどうめぐり系」の問題です。そもそも、システム入れ替えのプロジェクト日程計画をシステム開発会社さんに任せたのがまず間違いの始まりです。
システム開発会社さんは、その責任範囲上、システム開発や稼働に関わる部分をとても丁寧に検討してくれます。しかし、導入する会社の内部事情を事細かく把握し、システム切り替えがどこまで影響してゆくかを予想することはほとんど不可能です。
また、システム導入を推進する責任者の方も、会社全体の仕事の流れに関する知識が無いと、影響範囲を想定することはかなり困難です。その「無い無い」づくしのコンビが日程計画を立ててしまうと、このようなトラブルに発展することは良くあることです。

商品アイテムの数が限られている・システムを使う人も数人しかいない・システムの切り替え時期は繁忙期ではない

といった極めて限定的な条件の会社であれば、あまり目くじらをたてて細かく検討することは無いかもしれませんが、それ以外の普通の企業にとって、システムの切り替えはかなり微妙で難しいものですし、システム変更の影響範囲を予想することを常日頃やっていない方にとっては、かなり難しいことです。
そのような状態に陥らないための方法は何か？秘訣めいたものはあまりなく、直感で切り込んでいくと結構整理できるのですが、まずは会社の年間スケジュールをカレンダーに書くことから始めるべきです。

棚卸しはいつか？
繁忙期はいつか？
会計年度は？
（万が一）システムが止まっても大丈夫な日は？
データを旧システムから新システムに移行する日数は？
在庫アイテムに新たにラベルを貼る場合、その工数が確保できる日は？

といった、あまりシステムに関係無いと思われることまで含めて年間タスクを拾い出し、立ち上げのための社内作業を想定し、それを日程計画にする、といった作業を「システム立ち上げ計画の立案前」、もっと言えば「システム開発の発注前」に行うしかありません。
「何をそんな先まで・・・」と言われることが多いのですが、それを軽視していると実に痛いしっぺ返しが来る、というお話でした。
実際にあった怖い話　なので、ぜひ参考にしていただければと思います。