現代システムホームへ

★導入失敗例-その2-

戻る

引き渡し間近にキャンセル。

1998年11月5日作成
2000年10月18日修正

引き渡し間近になって契約をキャンセルされた例がありました。原因の分析と、関係の修復を依頼されて知りました。結果的には、受注金額一千数百万円のパソコンLANシステムで、販売側がキャンセルを受け入れて、納入した機械を引き上げた例です。

給与、経理のパッケージはすでに数ヶ月前から使用が始まっていました。問題となった販売管理システムは2ヶ月の並行作業が終わり、本番移行して2ヶ月が経過しようと言う時期の事です。

1)キャンセルの理由 2)システム構成 3)導入の経過 
4)導入企業側の状況 5)問題点の整理 6)全体の感想


1)キャンセルの理由

導入側の最終的な理由は、以前のオフコンシステムの方がいいから、そちらへ戻したい、と言うものです。

最も大きな理由は、その会社が全く属性の違う2系統の製品を製造販売していたにもかかわらず、販売管理システムはその2系統を単なる商品の違いとして考えていたことにあります。

旧システムとの並行期間を2ヶ月とって、本番移行して2ヶ月経っても、システムの不備が完全に修復出来ていないと言うものでした。
納期的には、当初の本番開始予定から4ヶ月遅れたこともありました。
そして、販売管理と財務管理の連動処理が未納で、財務の手入力が増えたことがあげられました。
また、販売の全帳票が、ロータス123へ直接取り込めないことも理由にあげられました。


2)システム構成

納入したシステムは、給与が市販パッケージです。
経理は、同じメーカーの市販パッケージを購入しましたが、販売管理とのデータ連動の関係で別のメーカーのパッケージに変更しています。
販売管理は、プログラムの修正が出来ると言うパッケージで、データベース言語を使ったものです。

機械の構成は、サーバー1台、端末4台です。LANのOSはネットウエア、端末はウインドウズ3.1です。
実績は少ないが、クライアント・サーバー(パソコンLAN)がいいと騒がれていた時期の構成です。


3)導入の経過

2ヶ月間の営業活動後、パソコンLANの契約成立。

販売管理は、契約後5ヶ月目から開始予定。
この時点で、システム構築の一式を外注のソフト会社に任せる。

1ヶ月目:給与、経理、打合せ。

2ヶ月目:給与開始。担当SE、パッケージ言語の講習参加。

3ヶ月目:販売仕様打合せ。経理開始。

4ヶ月目:販売システム確認書提出。明確な確認なし。販売側の営業担当退社、交代。

5ヶ月目:LAN構築するもトラブル続出。販売マスタデータ登録開始。

6ヶ月目:LANの再構築。販売マスタデータ登録完了。販売プログラム全体納入。
      販売管理の担当課長入院。

7ヶ月目:旧オフコンと新システムの並行作業開始。
      プログラム改造で大混乱。導入側の内容チェック無し。

8ヶ月目:並行作業続行中。属性の違う2系統の製品システムの違い判明。

9ヶ月目:本番開始。前月分の月次帳票チェックで未検収帳票多数残る。
      2系統の製品区分をコードで分けるように対応する。
      販売管理の担当課長退職。経理担当の女性退職。

10ヶ月目:残作業のチェック。経理連動打合せ。連動プログラム作成開始。

この月末にキャンセルの意向を伝えられる。


4)導入企業側の状況

契約前の社長からの申し出は、前のオフコンシステムは無視して、パソコンで新しいシステムを構築したい、とのことだったそうです。

この会社ではオフコンシステムが長く使われており、経理、給与、販売、原価管理と会社全般に渡る処理をすでにしていました。しかも、販売管理のデータを経理に連動したり、製品の原価管理まで含んでいる訳ですから、業務のレベルは高いほうに属したと考えられます。

しかし、そのレベルを作り上げた経営陣は、すでにほとんどがいなくなっていました。また、運用する課長や担当者も、契約時点ではすでに辞めていたり、残っていた人も次々に辞めてしまう状況でした。任された担当の課長は契約時点で入社5ヶ月目、係長は入社8ヶ月目と言う経歴でした。

導入側の企業形態は従来のままでも、導入の責任者、担当者、運用者が過去の経過や業務内容を完全に把握していない状況にあったと言えます。


5)問題点の整理

営業のいい加減さ 慣れないパッケージの採用 上級SEの不在 販売側の管理体制 ユーザー側の問題


営業のいい加減さ

一番の問題は、販売側にあります。
現状システムを無視してくれと言う相手の要求を鵜呑みにして、単純なパッケージをはめ込もうとした事です。当然に金額も安くなりますから、相手も喜ぶし、いい事のように見えます。

この例は、契約した社長自らが自社の特異性を把握していなかった事もありますが、契約前の打合せで営業が感じ取るべきことです。全く形状も販売経路も違う製品を製造し販売し、原価管理までやっている。この事だけで、通常の販売管理が使えないと考えなければならないのですが、こういう例はよくあります。

製造業に卸業の販売管理システムを導入してしまい、その不具合から、次のリプレース注文をもらえないケースは多いものです。


慣れないパッケージの採用

次に、販売側が、今までに使った事のない言語で作られたパッケージを採用し、その修正を試みた事です。講習を受けたのが、契約の翌月で、残り2ヶ月でパッケージを修正して納入しなければならない訳です。どんなに優秀なシステムエンジニア(SE)でも、全く初めての言語で販売管理一式を2ヶ月で構築出来るなんて、考えられない事です。このために開発現場は苦戦したことでしょう。実際に並行作業に入れたのが、2ヶ月遅れています。そして、その時点でも相当な混乱を来したようです。


上級SEの不在

更に、契約後の打合せ時点で、2系統の製品を製造している特異性はすぐに判明したと考えられます。製品により、単価や金額の計算方法が違うし、販売時の形状や、販売先の形態が違う訳ですから、現状の帳票を見ただけで判断がつきそうに思えます。それに気がつかなかったか、もしくは契約に引きずられて問題の重大さを把握できなかったのは、システム構築をする担当SEのランクが低かったと言えます。

システムを新規に構築する時は、ユーザー側窓口担当者の力量の見極めが非常に重要になります。SEは相手の担当者を選ばなければなりません。この例では、プログラマーレベルのSEとしては上級のランクが投入されていると思いましたが、相手との折衝を含みシステム構築全体を仕切る上級SEがいなかったように思います。

そのため、相手の力量を見抜けなかった、システム内容の複雑さを見抜けなかった、並行作業を2ヶ月も続ける愚行をしてしまった、と言うことです。受注決定の時点から、上級のSEを投入すれば、ベッタリつかなくても、キャンセルまでには至らなかったと言えます。


販売側の管理体制

キャンセルに至るほどのシグナルを、何故もっと早くキャッチできなかったのか、と言う疑問が残ります。システム確認書を提出した時点、並行処理を開始した時点、本番処理に移行した時点、など、何回も大きなチェック時点があったような気がします。いい加減な相手であればあるほど、最終のリース検収が気になるものです。

これには、営業担当が4ヶ月目で退職し、別の担当へ引き継がれた事が考えられます。また、システム構築が一式外注された事も原因かもしれません。引き継いだ営業、販売側の管理SEも、キャンセルを正式に言われるまでは解らなかったと言いますから、細かいニュアンスが伝わってこなかったのかも知れません。


ユーザー側の問題

ユーザー側は契約をキャンセルしたわけで、金銭的な被害はないのですが、半年に及ぶ販売管理の導入作業はなんだったのでしょうか。また、1回導入した給与、経理の入替えなど、無駄な作業を繰り返した混乱は大きいと言えます。ユーザー側に問題はなかったのでしょうか。

ユーザー側の最大の責任は、オフコンのシステムを無視していいとした経営者にあると思います。最終的にオフコンのシステムに戻したいと言う訳ですから、そのシステムの良さを解っていなかった事になります。長年使われるシステムには、いところがあるから使われる訳で、悪いところが多かったらシステムは使われなくなるものです。

次に、新規にシステムを構築するとしながら、導入担当者に入社して1年にもならない社員を当てた事です。人材が辞めてしまって、適当な人員がいなかったと言う事であれば、新規導入を1年くらい伸ばしてもよかったのではないでしょうか。

また、担当となった課長・係長にも問題がありました。並行処理に入ってからの内容チェックを一向にしてくれなかったと言います。SEが毎晩遅くまで残業していても、ユーザーの担当者は定時で退社していたと言います。SEに完全に付き合って欲しいとは言いませんが、並行処理時の混乱の中では、2時間くらいの残業をしてでも、出てきた結果を逐一チェックして欲しいものです。

ユーザー側で新規のコンピュータ導入を何回か経験しましたが、並行処理の時期はきついものです。通常の業務はしなければならない、新規のマスタ登録はしなければならない、新規システムの結果もチェックしなければならないのです。しかし、これは誰でもが経験する事です。業務内容の解るユーザー担当が出来る限り早くチェックする事で、システムの問題点が指摘出来て、早く治す事が出来ます。


6)全体の感想

発注した社長もいい加減、受注した営業もいい加減、ユーザー側の担当者もいい加減、間に入った担当SEだけが、的確な指示ももらえず必死でやっていた、そんな感じを受けたキャンセル劇でした。

現行システムがある場合は、この内容をきっちり把握しましょう。どこが悪くて、どこがいいのか、新システムに入替えるならどこを改善すべきかを明確にするべきです。

社内でコンピュータ担当を選ぶ時は、サービス精神のある、社内でも信用のある、実務経験豊富な人を選んで下さい。コンピュータ経験にこだわる必要はありません。

相手のシステムエンジニアを選びましょう。コンピュータ関連の会社では、プログラマーもシステムエンジニアもすべて、名刺にはSEと書いてあります。優秀なプログラマーも必要ですが、業務の理解できるSEはもっと大事です。

現行システムがあるなら、マスタデータは出来るだけそれを使いましょう。金を払ってでも、新システムへ変換させるべきです。不毛な登録作業はなるべくやめましょう。

新旧システムの並行作業はなるべくやめて、必要最小限にしましょう。同じことを2回も入力するなんて、誰もやりたくありません。長引くほど、新システムのチェックがおろそかになります。

2000年10月18日

この会社はこの夏ごろ、前を通ったところなくなり更地になっていました。システムの導入に失敗してから数年が経過していますので、すでにその頃から経営的に苦しかったのではないかと思います。会社がなくなる時には、何年も前から主だった社員がポツポツと辞めて行きます。この会社の場合、担当の社員が次々に辞めていく状況でしたので、その頃すでに末期の症状を呈していたのかも知れません。

システムは更新しなければならない、経営は思わしくない、人は辞めてしまう。こんな状況で、社長は「安ければいい」と考えられたのではないでしょうか。このようなゴタゴタが、更に経営の足をひっぱたのではないか、そんな気もします。

戻る