基幹システム導入、ベンダーが一番力を入れるところですね。金額が大きいですからね。
でもどうもベンダーとはペースが合わないんですよね。
何故合わないんだろうと考えると、フェーズ認識がユーザ側と違う気がします。
導入スケジュールというと、ベンダーは以下のような線を引いてきます。
このスケジュールの実際を見てみましょう。
ユーザ側が、
「要件定義開始まで、まだ○週間ゆっくりできるな・・・」
「ベンダーはプロだから、全部お任せで大丈夫だな・・・」
と思うと、破綻の第一歩です。
中小企業を相手にするベンダーには、ユーザ側が望むような要件定義をする力はありません。
あっても要件定義ができる優秀なSEは中小企業にはアサインされません。
そもそも要件定義せず、いきなり基本設計するベンダーもいます。
「画面どうしますか」的な基本設計が始まります。
彼らは現状のシステムをベースに次のシステムを考えます。
加えてユーザからは、現状システムへのうらみつらみもこめた要望が上がってきます。
だから必ずコスト増になります。
膨らんだ開発費用の見積を見て、経営層からは「コストダウンしろ」と軽く言われます。
画面の項目をちょっと削ったり、帳票を数票廃止する程度では、焼け石に水です。
結果、無理やり機能を削るため、
ユーザにExcelでの手作業など、余計な運用を強いることになります。
「運用で回避」ってやつです。
このフェーズではユーザもまだ新システムでの運用がイメージできていないので、事の重大さに気づいていないです。
・新システムにユーザの要望を盛り込む → きちんと要件定義できている？
・最初から運用で回避 → きちんと実運用のイメージができている？
大きな爆弾が2つセットされた状態となりました。
何とか要件定義・基本設計を終わったことにして(笑)、ベンダー側が開発作業に入ると、打ち合わせ頻度も減ります。
たまに仕様確認をされる程度になります。「プロにお任せ♪」ほっと一息です・・・
これが破綻に拍車をかけます。次のフェーズでしっぺ返しを食います。
前フェーズでユーザ同士の議論が紛糾しているような致命的な状況だと、
一息すらつけず、仕様策定しながら開発を行います。
当然仕様変更による手戻りも増えます。この時点で既に破綻していると言えます。
「『仮』だからまだ余裕あるな」と思いますよね。そんなことはありません。
ベンダーは既にシステムは動いていると称し、プログラム開発遅れなど、前フェーズまでの自分たちの失敗を棚に上げて、検収を急かしてきます。
ユーザ側は開発されたプログラムに、仕様と違う点やバグがないかを短期間で確認しなければなりません。
確認するとなった場合、ユーザに「適当に触って確認してみてください」で済ませられるでしょうか。
無理ですよね。確認が不十分だと、以降のフェーズで「仕様と違う」「エラーが出る」が連発し、まともに運用できない羽目になります。
この期間は新旧システムの並行稼動がなされることが多いです。新旧両方のシステムへのデータ投入が行われ、データの突合せをし、本稼動できるか判断します。
要は二重入力を行うのです。ユーザは同じ伝票を2回打つことになります。この負担の大きさは想像に難くないでしょう。
通常は月次の確認ということで、1ヶ月程度の期間ですが、データの不一致が続くようですと、さらに二重入力期間が続くことになります。
この
・検収を非常に短期間で行わなければならない
・検収と同時に二重入力を行わなければならない
という事実をベンダーは最初の提案時に詳細に説明しないです。本当のことを言うと受注できないからでしょう。汚いですね。
更に本当ならこのフェーズで、マニュアル作成もしなくてはなりませんが、たいていは余力が無いので、「後で作ろう」となります。
こんな余裕の無い状態ですと、本稼動後もトラブルが続き、結局マニュアルがないままズルズル行ってしまいます。
マニュアルがないと異動等で新しい人が来ても正しい使い方がわからず、知識の継承が行われなくなります。
次第に「何故この処理をしているのか」をユーザ自身で説明できなくなります。
そうなると次のシステム更改時に、機能の費用対効果が判断できず、現状維持を選択せざるを得なくなります。
それにより開発コストが膨らみます。
被害がずっと続いていくのです・・・
その他に、マスタ移行・残データ移行など落とし穴はありますが、またの機会にお話します。
このままでもう十分破綻が見えていますから。
上記のようなステップを踏んでくると、QCD（Quality：品質、Cost：費用、Delivery：納期）の1つ以上が破綻しているはずです。
本稼働できないです。とりあえず延期で先送りするくらいでしょうか。
皆さんご存じの失敗プロジェクトの状況です。
この記事の最初に貼った上の図は、ベンダーのためのスケジュールなんです。
ユーザ側の事情は考慮されていません。
ところがこういうスケジュールが書かれた提案書に、経営者も簡単に騙されてしまいます。
経営者にここを理解してもらうのが一番難しいです。
ではどう対処すべきか。
私は以下の図でスケジュールを考えています。
次回以降フェーズを1つ1つ見ていきます。
でもどうもベンダーとはペースが合わないんですよね。
何故合わないんだろうと考えると、フェーズ認識がユーザ側と違う気がします。
導入スケジュールというと、ベンダーは以下のような線を引いてきます。
このスケジュールの実際を見てみましょう。
要件定義・基本設計
ユーザ側が、「要件定義開始まで、まだ○週間ゆっくりできるな・・・」
「ベンダーはプロだから、全部お任せで大丈夫だな・・・」
と思うと、破綻の第一歩です。
中小企業を相手にするベンダーには、ユーザ側が望むような要件定義をする力はありません。
あっても要件定義ができる優秀なSEは中小企業にはアサインされません。
そもそも要件定義せず、いきなり基本設計するベンダーもいます。
「画面どうしますか」的な基本設計が始まります。
彼らは現状のシステムをベースに次のシステムを考えます。
加えてユーザからは、現状システムへのうらみつらみもこめた要望が上がってきます。
だから必ずコスト増になります。
膨らんだ開発費用の見積を見て、経営層からは「コストダウンしろ」と軽く言われます。
画面の項目をちょっと削ったり、帳票を数票廃止する程度では、焼け石に水です。
結果、無理やり機能を削るため、
ユーザにExcelでの手作業など、余計な運用を強いることになります。
「運用で回避」ってやつです。
このフェーズではユーザもまだ新システムでの運用がイメージできていないので、事の重大さに気づいていないです。
・新システムにユーザの要望を盛り込む → きちんと要件定義できている？
・最初から運用で回避 → きちんと実運用のイメージができている？
大きな爆弾が2つセットされた状態となりました。
開発
何とか要件定義・基本設計を終わったことにして(笑)、ベンダー側が開発作業に入ると、打ち合わせ頻度も減ります。たまに仕様確認をされる程度になります。「プロにお任せ♪」ほっと一息です・・・
これが破綻に拍車をかけます。次のフェーズでしっぺ返しを食います。
前フェーズでユーザ同士の議論が紛糾しているような致命的な状況だと、
一息すらつけず、仕様策定しながら開発を行います。
当然仕様変更による手戻りも増えます。この時点で既に破綻していると言えます。
仮稼働
「『仮』だからまだ余裕あるな」と思いますよね。そんなことはありません。ベンダーは既にシステムは動いていると称し、プログラム開発遅れなど、前フェーズまでの自分たちの失敗を棚に上げて、検収を急かしてきます。
ユーザ側は開発されたプログラムに、仕様と違う点やバグがないかを短期間で確認しなければなりません。
確認するとなった場合、ユーザに「適当に触って確認してみてください」で済ませられるでしょうか。
無理ですよね。確認が不十分だと、以降のフェーズで「仕様と違う」「エラーが出る」が連発し、まともに運用できない羽目になります。
この期間は新旧システムの並行稼動がなされることが多いです。新旧両方のシステムへのデータ投入が行われ、データの突合せをし、本稼動できるか判断します。
要は二重入力を行うのです。ユーザは同じ伝票を2回打つことになります。この負担の大きさは想像に難くないでしょう。
通常は月次の確認ということで、1ヶ月程度の期間ですが、データの不一致が続くようですと、さらに二重入力期間が続くことになります。
この
・検収を非常に短期間で行わなければならない
・検収と同時に二重入力を行わなければならない
という事実をベンダーは最初の提案時に詳細に説明しないです。本当のことを言うと受注できないからでしょう。汚いですね。
更に本当ならこのフェーズで、マニュアル作成もしなくてはなりませんが、たいていは余力が無いので、「後で作ろう」となります。
こんな余裕の無い状態ですと、本稼動後もトラブルが続き、結局マニュアルがないままズルズル行ってしまいます。
マニュアルがないと異動等で新しい人が来ても正しい使い方がわからず、知識の継承が行われなくなります。
次第に「何故この処理をしているのか」をユーザ自身で説明できなくなります。
そうなると次のシステム更改時に、機能の費用対効果が判断できず、現状維持を選択せざるを得なくなります。
それにより開発コストが膨らみます。
被害がずっと続いていくのです・・・
その他に、マスタ移行・残データ移行など落とし穴はありますが、またの機会にお話します。
このままでもう十分破綻が見えていますから。
本稼働
上記のようなステップを踏んでくると、QCD（Quality：品質、Cost：費用、Delivery：納期）の1つ以上が破綻しているはずです。本稼働できないです。とりあえず延期で先送りするくらいでしょうか。
皆さんご存じの失敗プロジェクトの状況です。
この記事の最初に貼った上の図は、ベンダーのためのスケジュールなんです。
ユーザ側の事情は考慮されていません。
ところがこういうスケジュールが書かれた提案書に、経営者も簡単に騙されてしまいます。
経営者にここを理解してもらうのが一番難しいです。
ではどう対処すべきか。
私は以下の図でスケジュールを考えています。
次回以降フェーズを1つ1つ見ていきます。
関連記事：
基幹システム導入 ベンダーとのフェーズ認識の違い（この記事）
基幹システム導入 ベンダーとのフェーズ認識の違い（この記事）
