システム稼働するも、安定運用できずに失敗：ERP導入プロジェクト失敗の法則（5）（1/2 ページ）

ERPは業務に密接に結び付いたものなので、システム開発のカットオーバーをもって導入完了とはならず、稼働後でも“失敗”のリスクがある。よくあるケースと対策とは？

[鍋野敬一郎，＠IT]

ERPシステム稼働後に訪れる危機

　ERPシステムの構築に成功し、新システムが稼働するとERP導入プロジェクトは8割がた完了したといってよいでしょう。

　新システムの本番稼働は、プロジェクト関係者にとって感慨深いものだと思います。しかし、油断は禁物です。気が緩んだこのタイミングで最後の危機が訪れる可能性があるのです。

　一般にERPシステムの検収は、システムの稼働後1カ月後の月末締め処理が完了してユーザー検収とする場合が多いようです。

　どれだけエンドユーザートレーニングや移行テストを行っても、システム稼働後3カ月程度は、慣れない新システムに対するユーザーからの問い合わせや不具合の修正に追われます。逆に3カ月を超えると、次第にこうした状況も改善され安定稼働を迎えることとなります。

　導入業者のERPコンサルタントとスタッフは、システム稼働後1カ月程度で逐次メンバーが撤退していくことになります。そして大抵の場合、システム稼働後3カ月で保守要員を残して完全撤退となります。

図1　システムが稼働したのに“失敗”？

危機その1：エンドユーザーの理解不足

　さて、ERPシステムは稼働しましたが、それだけでは本当の意味でERP導入に成功したとはまだいえません。ERPシステムの稼働直後に訪れる危機は、稼働初期のユーザートラブルを収束できないことによるものです。先に述べたとおり、通常の場合にはシステム稼働後3カ月程度で安定稼働に至り、ヘルプデスクに対する問い合わせも減少していくものです。しかし、ときどき収束しないケースがあるのです。

　収束できない理由は大きく分けて2つあります。

　1つは、エンドユーザーに起因する問題です。これはエンドユーザートレーニングを軽く見て、十分な育成をしなかった（できなかった）というものです。つまり新システムの利用者の大半が、新システムを十分に理解できないまま、運用フェイズに入ってしまうことにより生じます。

　具体的な例として、これまでは伝票入力を経理部門や管理部門で一括入力していたところを、BPRと合理化の結果として現場入力へとルール変更したようなケースが挙げられます。この場合、全エンドユーザーに対する複数回（最低でも2回以上）の研修を実施する必要があるのですが、これを軽く見てアシスタントや一部エンドユーザーだけに限定した研修で済ませてしまうと、大量の誤入力が発生します。

　ご存じのとおり、ERPシステムは取り消しという処理ができません。一度間違って入力確定してしまった伝票は、赤伝を切る（逆の伝票入力処理、マイナス処理）必要があります。これは、管理部門や情報システム部門に莫大な負荷を掛けることになります。当然エンドユーザーからの不満が続出し、本来新システムで管理部門の負荷を低減するはずが、まったく逆の状況を招くこととなります。営業系の受注入力や物流系の出荷入力など、日常業務に支障がある場合には、その影響は計り知れません。

危機その2：パフォーマンス不足

　もう1つの問題は、導入業者に起因するものです。

　ERP導入失敗例には、システムは完成したが実用には耐えないと判断されて廃棄された（お蔵入りとなった）ケースが結構多くあります。機能が不足していた、導入業者とユーザー企業で機能の認識にズレがあったということもありますが、これらは導入業者のレベルが低いのが要因ですから今回は論外とします。

　意外に思われるかもしれませんが、ERPパッケージが要求に対して十分な機能をそろえていたとしても、パフォーマンスや運用性能という点について導入業者やパッケージベンダとの連携が甘い場合に、実用に耐えないシステムが出来上がってしまうことがあるのです。

　具体的な例としては、受注や購買入力における処理や、他システムとの連携による大量データの一括バッチ入力処理の量を甘く見て、パフォーマンス不足になるなどがこれに当たります。

　受注や購買入力については、機能検証時は数百点程度の部品発注処理で行い機能とパフォーマンスを試算してハードウェアスペックなどを決めるわけですが、実際に本番稼働で数千から数万点に及ぶ処理を行うとパフォーマンスが足りず、1日の処理を行うのに1日以上かかるという信じられない結果が出たりします。また、他システムからの大量データを一括入力処理しようとした場合も同様にパフォーマンス不足を招くことがあります。ERPは1つの処理で複数（時には数百）もの派生するトランザクション（データベースの更新処理）が生じるため、この負荷がシステムの上限を超えシステムダウンを招くのです。

　いずれにしても、ERPの特性である1つのイベント（処理）がドミノ倒しのような複数トランザクションを生じることによる負荷を軽く見ることに起因するものです。導入業者のコンサルタントが機能を重視し過ぎてパフォーマンスへの影響を安易に判断した場合や、大量処理を行うシステムを実装した経験がない場合によく見られます。

　エンドユーザーに起因する場合も導入業者に起因する場合も、ERPシステムが稼働するという点では問題なく見えるのですが、安定稼働という面から見て失敗だといえるでしょう。