アンバランスな業務とERPの関係

業種別ERP構想の理想と現実

先日、ソウルで開催された「アジアERPフォーラム」に参加しました。これは日中韓3国のERPやERP関連ツールベンダが集まり、「お互いの製品 紹介などの交流を通してアジアのERPを高めていこう」という趣旨で行われているものです。今回が2回目で、第1回は北京で開催されました。そして第3回 は来年10月に和歌山で開かれる予定です。

あるセッションで、中国のERPベンダが631X戦略というものを発表していました。これはERPの基本部分が6割、業種別機能部分が3割、コンサ ルテーションが1割、それにサードパーティー製のソフトウェアXを付加して顧客のニーズに対応していく構想モデルだと伺いました。このベンダはERP基本 部の上に12種類の業種別機能をサポートしており、これから業種別テンプレートを増やしていくと語っていました。

日本のERPベンダの中でも、基本部の汎用性はある程度にとどめて業種別テンプレートを増やして行くという方針を採っているところがあります。確か にこれだけERP製品が巷にあふれて基本機能の差が少なくなってくると、いかにその業種にぴったり合うかという専門性で勝負するのも当然だと思います。

業種特有の特殊機能をカスタマイズで実現する代わりにテンプレートが用意されているのは、ユーザにとっても大きな魅力となるでしょう。しかし方向性が正しいものの現在のところこういった業種別テンプレート戦略はそれほどインパクトを得ていなようです。

なかなか効果をあげられない業種別テンプレート

その主な原因は2つあります。1つは、このような業種別テンプレートの完成度が低いことがあげられます。大抵はどこかのパイロットユーザで試したも のをテンプレート化したものが多く、汎用性に欠けていて他社では使いにくくなっています。また実績が少ない分だけに、現場での利用にこなれていないという 面もあるでしょう。

もう1つの原因として、ベンダにとってERPのメンテナンスが大変ということがあげられます。基本機能をバージョンアップする度に、業種別テンプ レートの数だけ修正を加えなければなりません。このため、基本部分の上にきちんと業種別機能が乗っかっており、基本機能のみの修正で済む構造にできればよ いという人もいます。

しかしそれはあくまで理想論であり、現実には言葉でいうほど簡単にはいきません。例えば基本機能のプロジェクトコードの桁数を増やした場合、全テン プレート上のプロジェクトコードに修正が必要になってしまいます。またJ-SOX法対応ということで基本機能のトレーサビリティを強化した場合、全テンプ レートも同様の考えで強化する必要が生じます。このように開発上での制約が大きいので、現段階では基本機能部分で様々な業種に対応できるような汎用性を追 及している製品が多いのです。

カスタマイズしないことへの理想と現実

ERPベンダのセミナーなどに出席すると、「ERPはカスタマイズしない方がよい、業務をパッケージに合わせるべきだ」などというもっともらしい話 をしていることが多いです。確かに導入コストの低減やバージョンアップ適用の容易性を考えても、カスタマイズは行わないに越したことはありません。

しかし、それはあくまでもそのERPが必要とされる業務を効率よくこなせる機能を実現している場合に限っていえることです。実際には必要な機能が不 十分、もしくは一応パラメータ設定によりカバーしているものの非常に使いにくいなど、そのまま利用するのには困難な場合が多いのです。

どこの企業でも大きく変わらない会計や給与まわりの業務ならば、ERPをカスタマイズせずに利用してもおおむね大丈夫でしょう。しかし販売管理や生 産管理などでは、あらゆる業種にカスタマイズなしで適用できるほど柔軟なERPというのは存在しません。それなのにERPに合わせるべきと断定する場合と いうのは、現場を知らないもしくはユーザ業務を侮っているのではないでしょうか。

実際、その言葉を信じてカスタマイズレスを前提にERP導入を進めるとどういうことになるのでしょうか。「途中でこのままじゃ使えないことが判明し て、暗礁に乗り上げる」「追加のアドオン開発が膨れ上がり、パッケージを使ったメリットがなくなる」「カットオーバーをしたが、ユーザビリティが悪くて利 用する現場が泣いている」などの失敗を引き起こす恐れがあります。

カスタマイズしない場合にユーザを待ち受ける悲劇

もちろん、ERPを利用したソリューションは業務をパッケージに合わせることが基本です。筆者が導入コンサルテーションを行う場合でも、できるだけ パッケージに合わせてもらうように指導しています。しかし、場合によってはカスタマイズを選択する柔軟さも必要です。導入は一時的なものですが、ユーザは ずっとそれを使い続ける運命にあります。ユーザの使い勝手の悪さは、長期間での大きな負担を企業と社員にもたらします。

カスタマイズの問題点は、パッケージがバージョンアップした場合にそれを適用するのが困難になることです。仮に保守契約していたとしても、ベンダは 基本部分しかサポート対象としないので、カスタマイズ部分への適用作業は別費用になってしまいます。確かにこれは悩ましい問題であり、カスタマイズによる 業務効率アップとトレードオフになるでしょう。

この点について二兎を追うことができないのと同じく、割り切るべきと筆者自身は考えています。カスタマイズをすると決めたからには、ベンダによるバージョンアップの適用はあきらめて、初期導入以降は自社で改良していく方針もあり得ると思います。

会計や給与などは、カスタマイズを避ける、もしくはアドオン的機能追加によりコア部分を変更しないことが可能です。しかし、 もっと複雑で自社独自の機能（それが企業の強みにもなっている）があるような業務に関しては、カスタマイズを避けられない場合があります。そんな時は、 テーラーメイド開発と同じと割り切れるのです。