SMBがERP導入で見落とす「10のポイント」：中堅・中小企業の賢いERPパッケージ選び【第2回】
SMBがERPの導入で失敗する理由は何か。「アドオンを減らせ」「パッケージに合わせろ」といった決まり文句を聞くだけではもはや避けられない、10個の“落とし穴”を挙げる。
実は増えている導入トラブル
前回「多様化するSMB向けERPの今を読み解く」では、ERP導入の参考としてSMB向けパッケージ市場のトレンドを解説した。実際のところ、多くの導入実績があり、同業他社も利用しているというだけで安心して選んだERPパッケージの導入プロジェクトが頓挫するというケースは珍しくない。また、アドオンをしない、あるいは極力減らすことだけを優先したため逆に弊害が生じるケースも見られる。また、それまでにERPパッケージの導入経験がない企業では、選定段階では見えなかったり本質的な意味が実感できない課題を多々抱えており、これらが導入開始とともに一気に表面化し頓挫してしまうこともある。
アイ・ティ・アール（ITR）では、ERPパッケージの選定支援を数多く行ってきたが、導入時のトラブルや、導入後の運用を開始してからのトラブルについてのアドバイスを求められることも少なくない。そうしたトラブルは起きてほしくないが、パッケージの導入が進み、使いこなす文化もそれなりに進展してきているはずなのに、むしろここ数年トラブルの発生件数が増えてきているとすら感じる。
そういったトラブルの中には、ベンダーやシステムインテグレーターとの訴訟に至るような不幸なケースもある。そこで今回は、ERPパッケージの選定や導入で陥りやすいわなの典型的な例について述べたい。具体的には、このようなテーマでありがちな「パッケージに合わせる」といった精神論、業務改善やコミュニケーションの不徹底、使い勝手が悪くてアドオンが増えるといった決まり文句ではなく、できるだけシステムを導入して動かす側の視点から実践的な10カ条を選んでみた。ただし、「10のわな」は昨今の選定プロジェクトやトラブル事例などで散見されるものから優先的に選んでおり、これらだけがすべてではない点に注意していただきたい。
1. ERPの幻想にとらわれる
ERPパッケージを導入しさえすれば、基幹系の全業務システムがいっときに再構築できる、いわゆる「ガラガラポン」はもはや幻想にすぎないことを多くの企業が痛感している。会計と人事給与以外の、モノをハンドリングするシステムにパッケージを適用する際には、単純に製品の機能が業務に適合するかどうかの評価では読み切れないギャップ（実際のユーザー業務とERPの想定する業務との食い違い）も出てくる。逆説的ではあるが、ERPパッケージが万能の解決策ではないことを理解し、理想を求めなければ、パッケージの良さも客観的に評価できるだろう。
例として図1に、製造業が利用するシステムの種別を、データの集約度を縦軸、業務処理の時間軸（タイミング）を横軸にして大きなくくりで配置してみた。
縦軸と横軸が交差する点をデータの粒度とすれば、上位に配置される会計のようなシステムほど粒度が粗くデータ量も少ない。逆に下位のMES、SCADAに近づくほど粒度が細かくデータ量は膨大となる。
データの一元化やリアルタイムというコンセプトを基に、ERPパッケージで基幹系システムを統合し再構築する際には、データの粒度に着目して、会計系、物流系／生産管理系のシステムの配置モデルを注意深く検討する必要がある。一般的に、MES以下のシステムを会計システムと統合するのは不可能である。また、データの処理量やピーク時などの性能要求によっても異なるが、会計システムと物流系／生産管理系システムの統合も要注意となる。さらにバックオフィス系と現場系のシステムでは、マネジメントのサイクルやタイミングが異なっており、統合だけが正解ではない。
このようにすべてをERPパッケージで、しかも単一のインスタンスで動かすといった考えだけに陥らないようにすべきだ。あまり粒度を細かくし過ぎると、ハードウェア費用が膨大になるばかりか、データのバックアップ処理もままならないシステム、使えないシステムとなる危険性もある。
2．「できる」との回答をうのみにして「どうできる」かを精査しない
RFP（提案依頼書）では、質問表を作成してパッケージの機能評価を実施することが多い。しかし、機能評価だけにとらわれると、「できる」「できない」といった議論ばかりで空回りしてしまう。RFI（情報提供依頼書）を活用してベンダーに情報提供を依頼しても、「できない」「不可能」といった回答が積極的に示されることはない。また、「可能」という回答も、パッケージが内在するギャップの代替手段を示しているにすぎないこともある。中には、数百の質問項目のほとんどすべてに満点の自己評価をしてくるベンダーもあるので要注意である。
このことから分かるように、単に「できる」だけでなく、「どうできるか」を詳細に確認しないと、後の工程で「こんなはずではなかった」というギャップが数多く発生することにもなりかねない。そして、まだほとんど実績のない新製品を前提に「できる」とベンダーが提案してくる場合などは細心の注意が必要だ。
ただし、通常は事前にすべてのギャップを洗い出しておくことは困難だ。パッケージの評価では、機能評価よりもむしろ選定候補とするパッケージの基本構造、より具体的にはデータ構造を見極めることが重要であり、この部分が理解できていれば、本当に「できる」のかどうかを応用的に見抜くことができる。
逆に、選定条件が厳し過ぎて製品を選び切れなかったり、指定された条件をすべて満たす製品が存在しないケースもある。これには、機能要件が厳し過ぎる場合が当てはまる。あるいは、完全Web対応、シングルサインオン、ソースコードやデータ構造の公開、データの更新ログや過去データの世代管理機能、ワークフロー機能の承認階層が深いといったように、非機能要件や周辺要件に完ぺきを求め過ぎる場合もある。
パッケージを活用した新システムに理想を求め過ぎた結果、「あればいい」程度の機能や要望が一人歩きして選定メンバー全体の暗黙の合意となっていたりすると、後戻りが難しくなる。自社が必要とする機能の優先順位を的確に認識して、なるべく早い段階で軌道修正しておけば、円滑に選定を進められるケースは少なくない。
3. 事例を深堀りしない
「多くの導入実績がある」「同業他社も利用している」というだけで選んだパッケージの導入プロジェクトは頓挫してしまうケースもある。一般的に、同業他社が多く利用していれば業界固有の致命的な問題は解消されている可能性は高い。しかし、当然ながら自社にとって致命的であっても他社にとってはそうでないケースもあり得る。致命的かどうかは自ら判断すべきだろう。
また、ユーザー企業にERPパッケージの導入経験がないと、事例となった企業にヒアリングを行ったとしてもプロジェクト運営などの総論的な部分しか理解できず、パッケージの技術的な問題については分からないこともある。そのため、事例企業側が導入時に重要なポイントとなる課題を説明したところで、選定段階ではその本質的な意味が実感できないだろう。そしてこれらが製品選定後に一気に表面化し、導入が頓挫してしまうのである。
上記のような理由から、ベンダーの資料を見て事例が多いというだけで導入を判断するのは避けるべきだ。事例企業へのヒアリングを行う場合は、事前に入念に質問内容を作成しておく必要がある。ヒアリングした結果に少しでも疑問や分からない点があれば、別途調査するなどして納得がいくまで確認することを勧める。
Copyright © ITmedia, Inc. All Rights Reserved.