4. テンプレートを過信する

　パッケージの導入費用を低減させるために、テンプレートが前提となっているベンダーの提案にも注意が必要である。極論を言えば、テンプレートは、テンプレートに含まれている部分しか構築しないことで費用を低減するものと考えれば間違いない。テンプレートは確かに、どこの企業でも同じように求められるパラメータやアドオンが含まれており、そのパッケージを導入するに当たり必要となる手順をマニュアル化している。しかし、テンプレートを過信すると痛い目に遭う場合もある。

　テンプレートは、典型的な構築パターンを基に作成されたものであり、構築期間が短縮できるということは、本来パッケージが提供するソリューションの幅の広さや深さを削り取ったものともいえる。つまり、テンプレートにも使いこなしが求められるということだ。中には、数社の導入をこなしただけで「テンプレート」を標ぼうしているベンダーもあるため、事前に入念な評価が必要である。

5. アドオンをしない

　ERPパッケージの選定にかかわっていて、アドオンを知らない人は恐らくいないだろう。アドオンはパッケージを否定的に見るときの一番の問題点、諸悪の根源のようにいわれ、とにかくそれを減らすことがERPパッケージ導入の最重要成功要因だとされている。しかし、ERPパッケージはあくまで標準的な機能を提供するにすぎず、業務の見直しや改善といった検討を経ても自社にとって必要な機能は何らかの追加開発で対応せざるを得ないのが通例である。従って、アドオンだけを問題視し、アドオンがなければ導入プロジェクトが成功するといったとらえ方からの脱却が必要だ。

　本当に問題なのは、明確な方針や対処方法を検討することなく、やみくもに作るままの状況に流されてしまう「丸投げされたアドオン」である。どのように作るべきか、何をしてはいけないのか、何を順守すべきなのか、逆にどの範囲なら自由に作ってもいいのか。つまり、アドオンの標準化を徹底した開発標準をベンダーに順守させる、「管理されたアドオン」にすることが重要なのだ。

　ある企業の例では、ERPパッケージ導入が“アドオン厳禁”にとらわれて大きな痛手を負った。問題となったのは、この企業がシステムを導入する際の前提条件としていた機能であり、ベンダーもプロジェクトの開始時点では提供を約束していた。しかしその後、ベンダーの説明が「要求された機能を実現するためにはアドオンだけでなくパッケージのモディファイも必要となるため提供できない」「このパッケージはそういうものであり、他社でも我慢してパッケージに合わせている」といった言い分へと変わっていった。

　単なる使い勝手の問題であれば我慢もできただろうが、企業の要求する機能はパッケージを導入する際の前提条件に近いものであったため、ユーザーの不信感は大きく膨れ上がった。結論からいうと、このケースのモディファイは軽微で済み、バージョンアップなどでも問題はないと判断できるものだった。むしろパッケージも、拡張的な機能が必要になる場合にはモディファイを伴うアドオンを想定しているかのような設計になっていたのである。

6. データ構造を確認しない

　一般的に、パッケージのデータ階層は非常に浅い。これは、汎用的なパッケージ製品が持つ宿命であり、逆に優れている点でもある。なぜなら手組みの場合は、ユーザーの要件や実組織をそのままシステム化しがちであり、それがシステムの固有性を高める一方で標準性をそいでしまうからだ。組織の構造が変わればシステムも変更を余儀なくされる。手組みのシステムでは、組織構造の異なるほかの事業に展開したり、組織階層の浅い中小規模のグループ企業などにシステムを展開することが難しくなるのだ。

　パッケージのデータ構造の例を以下の表に示す。このほかにも多種多様なデータや組織構造があるが、基幹系業務における木の幹に当たる構造を抜き出している。製品によって名称や細かな特徴は異なるものの、ERPパッケージと分類される製品であれば、あまり大きな差異はなく似通っていることが多い。

　汎用化されたデータ構造を持つのはパッケージの優れた点であると先述したが、初めてのパッケージ導入では大きな問題にもなり得る。在庫、販売、会計（主に財務会計）のデータ階層は浅いことが多く、既存システムや実組織の階層がそのまま反映できることは、ほぼあり得ない。よほどシンプルな組織運営をしている中小規模の企業でもない限りは考慮しなければならない問題である。

　では、グローバル企業や大企業はこの問題をどう解決し、パッケージの導入を進めてきたのだろうか。結論としては、基本的には販売や在庫に深いデータ階層を持たせずにフラットに並べることを前提として、パッケージの基本機能を生かすような導入を行う以外に手だてはない。よくアドオンが問題視されるが、この部分でのギャップが大きい場合には、アドオンしても導入するかパッケージの利用をあきらめるしかないのである。

　初期のころに比べれば、パッケージベンダーもデータ構造を深くするための選択肢を提供してきているが、基本的にはパラメータ設定などの範囲で対応できるものではない。モディフィケーションは厳禁といわれるが、機能不足でプログラムを修正することなどは、データ構造に変更を加えることに比べれば軽微だろう。

7. マスターデータを確認しない

　マスターデータでは、コードのけた数や項目が要件を満たしているかどうかを確認する必要があることは言うまでもない。しかし、意外に思われるかもしれないが、データの一元管理を売り物としているにもかかわらず、マスターデータの完全世代管理ができないといった問題は見落とされがちである。

　マスターデータが完全な世代管理に対応していないのは、ベンダーの初期の設計によるとしか言いようがないが、問題なのはマスターの構造が不均質な状態になっている場合が多いことだ。ただし、ここで言う完全な世代管理とは、開始年月日／終了年月日を持ち、またマスターを使用するすべてのプログラムが開始／終了をコントロールするロジックを持っていることを指している。

　一方、国内の手組みのシステムでは、開始年月日／終了年月日といったマスターデータの世代管理は常識化していることが通例だ。先日付でのデータ投入や過去日付でのコード名称表示が当たり前となっており、その前提でマスターデータ管理業務や業務システムの運用がルール化されている。従って、その常識をそのままパッケージ製品に期待すると、パッケージを選定した後に思わぬ落とし穴が露呈してしまうことになるため、要注意である。

8. 権限構造をチェックしない

　権限の問題は、ユーザーによって利用できる機能を制約したり、必要な機能のみをメニュー化したりといったレベルでは起こらない。トラブルになるのは、入力・更新・参照といった機能の処理権限や、利用できるデータの範囲（本社、事業、部署など組織別に限定する権限やデータの種別などで限定する権限など）である。こういったアクセス権限は、内部統制でもその重要性が再認識されているが、ERPパッケージを導入していながら、権限を非常に緩く設定している企業は意外に多い。

　それは、そもそも手組みのシステムで実現しているレベルの機能が提供できていない製品があるのが理由だが、中には権限のバリエーションが増えると設定に多大の時間と費用が掛かるような製品もある。そのような製品では、初期導入では必要な権限レベルで構築をしたものの、ユーザーが稼働後に組織変更に対応した権限の変更を行おうとしたら、ベンダーからあまりに高額な見積もりが来て見送ってしまったというケースも見られる。

　パッケージの権限構造は、初期導入時だけでなく、稼働後の変更がいかに柔軟にできるかどうかも含めて評価すべきである。

9. データの保存年限を考慮しない

　データをいつまでにERPパッケージに蓄積しておくのか、あるいはいつになったら削除するのかという問題も、選定時や導入時にはほとんど顧みられないことが多い。「1. ERPの幻想にとらわれる」でも述べたように、ERPだからといって既存システムで利用している販売系の明細データやPOSデータをそのまま投入したりすると、動かないシステムとなってしまうケースもあるが、むしろ深刻なのは、カットオーバー当初は何とか動くが、その後のデータ量が飛躍的に増大して動かなくなるといったケースだ。

　そのため、自社で必要とするデータの明細レベルで、どのくらいデータが保存でき、過年度のデータとパッケージ上で比較できるかといった、いわゆる管理会計的なニーズを満たせることを製品選定段階でも確認しておくべきだ。販売の明細がアーカイブされてもほかのテーブルにサマリーデータを残すといった代替機能を持つ製品も中にはあるが、ERPパッケージの売り文句である「ドリルダウン」や「明細レベルでの確認」などを行うには、専用のアーカイブシステムを別途導入しなければならないことにもなりかねない。

10. 性能問題を甘く見る

　ERPパッケージを導入した複数の企業から、一括処理や大量データ処理でパフォーマンスが出ない、データが年々蓄積されるに従ってパフォーマンスが著しく劣化するといった話をよく聞く。最近、ITRがある企業から受けた問い合わせに、次のようなものがあった。稼働後わずか半年で想定するデータ量の20倍のデータが発生しており、数年先を予定していたハードウェアの増強を前倒しせざるを得ないが、経営者に対して説明できないというのだ。ここまで悲痛でなくても、当所の想定より10倍増えた、ピーク時の更新が重なるとレスポンスが極めて悪化するといったケースは珍しくない。Fit＆Gap分析（※）を経て設計が終わりに差し掛かるあたりで、最上位機種のサーバでも動かせる見込み立たなくなるというトラブルもあった。

※　パッケージの導入時に自社の業務プロセスやシステム要求とパッケージの提供する機能がどの程度適合し、かつズレがあるかを分析・評価すること。

　こういったケースに共通するのは、サーバなどハードウェアのサイジングを誤っている点である。パッケージやハードウェアの専門家ではないユーザーにしてみれば、高い導入費用を払って依頼したプロであるベンダーに責任を問いただしたい気持ちはよく分かる。しかし、サーバのサイジング結果やハードウェアの見積もりにハンコを押してしまえば、それを承認したことになることを忘れてはならない。

　そして、残念ながらプロであるベンダーにも驚くべき単純な間違いはある。例えば、サイジングの根拠となるデータ件数そのものが古い資料のデータをコピーしていて気付かなかったり、一般的な計算値だけを使用して自社システムの特性をまったく考慮していない場合などである。

　そうなると、予算を超えてもハードウェアの増強しか対処の方法はない。性能の問題は、これまで述べてきた複数のチェックポイントに絡むが、パッケージの場合、ソースコードレベルでの対処が簡単ではないことから、手組みのシステムよりも解決方法が限定されることには注意しなければならない。

専門家の意見が重要に

　以上に挙げた10のポイントは、初めてパッケージの導入を検討する際には見落とされやすく、導入後に初めて認識されることが多い。事前に事例などを深く調査し、企業訪問などでユーザーの生の声を聞いてもなかなか理解できないものだろう。従ってパッケージの選定では、コンサルタントなどの公正中立な専門家から第三者としての意見を得たり、デモなどで納得のいくまで要件を確認したりすることが効果的である。

　次回は、RFPをどのように作成すればERPパッケージを効果的に選定・導入できるかについて述べたい。