ここでは、ERPパッケージを選ぶ際の一般的な手順と、陥りやすい罠、その対策について記述します。
自社の基幹業務プロセスが特殊で、競争上の差別化要因になっている場合はERPではなくスクラッチ開発が妥当ですが、それでも、ERPの利用を前提に検討するほうが賢明でしょう。現場の担当者の多くは、自社の業務が特殊であると信じているため、ERPが合わな ければスクラッチ開発という方針では、ERP導入への抵抗が大きくなります。しかし、スクラッチ開発を前提に開発コストを見積ると、見積額が膨大になりがちです。ERPとは異なり、現場からの要件はすべて作ることが期待されるためです。スクラッチ開発費用が高くなりすぎるため、方針転換してERPを導入する企業もあります。
パッケージ選定にあたって比較する項目のうち、判断が難しいか、必要以上に労力をかけてしまいがちな項目について、とりわけ意思決定者に知っておいてほしい点を記載します。
① 導入対象業務に関するパッケージの適応度
ERPパッケージが自社の業務をどの程度カバーしているか、 概要レベルでFit&Gap分析を行うことが一般的です。しかし、この段 階でFit&Gap 分析を行っても、選択の決め手にはなりません。概要レベルですから、パッケージ・ベンダ/導入ペンダのいずれが分析を行うにせよ、基本的にはFitするとしても、アドオンの発生を抑えられるかどうかは、要件定義フェーズに入らないと確約できな いのが一般的です。また、自社の業種・業務に適合しそうなテンプ レートがあれば、この段階でテンプレートを評価しておくとよいでしょう。標準機能では対応が難しい業界・業種に特有の業務機能や日本独特の商慣習に対応した機能が、テンプレートとして導入べ ンダによって提供され、ERP 標準機能を補完することができます。また、テンプレートに準じた業務フローが用意されていると的確な評価が行えます。何よりユーザの理解を助けます。さらに、バッ ケージが標準で備えている複数の機能を、パッケージが想定してい ない順序では実行できずアドオン開発を必要とする場合もあるからです。
②導入実績
ERPパッケージおよび導入ペンダの導入実績を検討します。 自社 と業務が似ていると考えられる企業での導入事例は参考として価値 があります。 導入した企業から直接情報が取れるようなら一層望ま しいと言えます。このとき、導入企業の数そのものよりも、開発べ ンダが撤退したり他社に買収されたりして、戦略が大きく変更する リスクを重く考えるべきではないでしょうか? 一時的にブームに なったパッケージでも、開発ベンダが買収され、バージョンアップ 頻度が下がったり、機能拡充が滞ったりする例は少なくありません。
③ プロジェクト体制
プロジェクトの成功という観点では、導入ペンダの企業としての実績よりも、プロジェクトに参画するメンバとりわけプロジェクト・マネージャの実績を注意深く吟味することが大切です。ERPコン サルタントを数多く抱える企業でも、他プロジェクトに要員を取ら れていれば意味がありません。グローバル展開する企業のコンサルタントの多くは海外拠点に所属する、日本の業務に知識が乏しい外国人であるかもしれません。プロジェクト体制に関する留意点として、提案書を受け取ってからプロジェクト開始までの期間が長くなると、 提案書に記載されていたメンバとは異なる体制が組まれることになる場合が多いことを付け加えておきます。
④拡張性
ERPの中には、標準機能では業務要件を満たせないとき、 ソースコードが公開されておらず、パッケージを開発したベンダにしか機能追加変更を依頼できない場合があります。 導入ペンダなら製品の理解に不安はないのですが、逆に業界に特化した業務知識は期待 できないでしょう。さらに、競争原理が働かないため、どうしても開発コストがかさんでしまいます。ライセンス費用が安い国産 ERPの中には、画面イメージが日本人ユーザに馴染みやすいため パッケージ選定で高評価を得るものの、導入プロジェクトが進んだ とき当初の目論見が外れて機能追加・変更が必要になると、途端にプロジェクト費用がかさむ場合があり得ます。その可能性がないか、事前の調査が重要です。
⑤ グローバル対応
多くのERPは多言語 多通貨対応を謳っており、どれをとっても差はないように思われがちですが、パッケージによって差を生じる場合があります。パッケージソフトによっては、 英語と現地語との辞書機能を備えており、新しい画面・機能で追加した用語であっても、辞書に翻訳を登録すればシステム内すべてに反映されます。しかし、この機能を備えておらず、画面機能ごとに逐一翻訳を施すことを求めるパッケージもあります。また、国の法制度や商習慣に合わせ たローカル機能の充実度も押さえておきたいところです。 導入する 国によっては、ローカル機能とバッケージの両方に精通したコンサルタント/エンジニアが確保できない、ベンダの保守サポートがその国の言語では受けられない、といった状況が発生し、グローバル 展開に支障をきたすパッケージもありますので、考慮すべきでしょう。
⑥ ライセンス料金体系
パッケージにより料金体系が異なります。 ログインIDを付与する ユーザの数に応じて料金が決まるタイプと同時アクセス数に応じて 決まるタイプが代表的です。 利用の仕方によってもライセンス金額が異なります。 すべての機能を自由に使えるライセンスのほか、利用形態が制限されているものの料金が安いライセンスが用意されている場合があります。 また、ERP導入の過程で、より少ない人数で運用できる方法を工夫することもありますし、 同時アクセス数を ユーザ数の何%としてよいか運用してみないとはっきりしないかもしれません。 異なるパッケージについてライセンス料金を比較する場合、これらの点を考慮して実運用でどれだけのライセンスが必要か明らかにしておく必要があります。
⑦導入見積
きちんとしたRFPを提示していない場合、 複数ペンダの概算見積を横並びにしても、それだけではあまり意味がありません。 正式見積が概算を超えないように考慮した、いわゆる“堅い”見積なのか、 先ずはセレクションに残ることを優先して、“基本的には標準機能 でできるはず?”という希望的観測にもとづいた見積なのか見抜かないと、後で“こんなはずではなかった”という事態に陥りかねません。提案内容をやり切ることができるベンダなのか見極めておくことは言うまでもありません。 見積の妥当性を評価するためには、 ベンダやパッケージによって標準機能の適用度が異なるような要件を抽出して、 どういった根拠で見積を見解が詳しく尋ねるとよいでしょう。 掘り下げていくと、導入ペンダがどういった考え方に立って見積を行ったか見えてくるはずです。これらは、RFPを提示した場合でも考慮しておく必要があります。RFPの解釈が導入ペン ダによって異なっていないか、RFPに記載していない点について 前提条件をおいた見積になっていないか、見極めたうえで見積額を評価するようにしたいものです。また、程度の差こそあれ、これら この考え方は概算見積、正式見積のどちらでも適用できるものです。
最後は経営者の決断
パッケージ選定では、パッケージの特性にもとづいて候補をいくつ が選んで、詳細情報を取ってパッケージをひとつに絞り込んだうえで 複数ペンダの提案を受けるか、 候補となった複数のパッケージについて各1社または2社の導入ペンダから提案を受ける例が一般的です。どちらの進め方であっても、途中で考え方がぶれて迷走しなければ問題ありません。
パッケージ選定では、パッケージの特性にもとづいて候補をいくつ が選んで、詳細情報を取ってパッケージをひとつに絞り込んだうえで 複数ペンダの提案を受けるか、 候補となった複数のパッケージについて各1社または2社の導入ペンダから提案を受ける例が一般的です。どちらの進め方であっても、途中で考え方がぶれて迷走しなければ問題ありません。
ERPでも同じですが、概して高価格の製品はそれに応じた素晴らしさを備えています。価格が安ければそれなりです。何のためにERPを導入するのか、それを踏まえ現場のニーズをどれだけ満たすのか、そして最終的にいくら投資するのか、といった自社の方針をはっきりさせないと決定できません。
製品特性を比較すれば、早い段階で候補となるパッケージは2、3 に絞れますし、導入ペンダ候補も5社くらいには収まります。 同じ価格帯の製品を比べる場合でも、本質は変わりません。 特に、自社の現 行業務とパッケージの機能を比べるFit& Gap分析行ってもなかなか 結論には至りません。 ERP上で実現する機能は、必ずしも現行シス テムの機能とは一致しませんし、パッケージ選定の段階で機能の詳細 を調査することには限界があるからです。
パッケージ選定に時間をかけすぎるのは、担当部門の選定作業工数 をコストと見なさない企業の傾向とも言えます。どのパッケージを選 んでも一長一短がありますし、どのパッケージでも成功例も失敗例もあります。それよりも、プロジェクトの成功とその後の導入効果は、ユーザ企業と導入ペンダの力量次第と考えるほうが適切でしょう。
コメント