0
会員になると、いいね！でマイページに保存できます。
「ERP」というと大企業向けの重厚長大なシステムというイメージが強いかもしれないが、中堅・中小企業でも基幹系システムの中核として重要な役割を果たしている。中堅・中小企業ではシステム規模は大企業と比べ小さく、求める要件は千差万別だが、年商帯や要件に応じて、「SAP ERP All-in-One」「OBIC7」「GLOVIA smart」「SMILE BS」「奉行 V ERP」など、さまざまなERPパッケージが存在している。こうしたパッケージを活用するうえで問題になるのが「ユーザー企業ごとのカスタマイズ」だ。今回はこの「ERPパッケージにおけるカスタマイズ」について、従来手法の課題とそれをカバーするべく生まれた最新手法などについて見ていこう。
利用中ERPのユーザー評価が示す意外な結果
まずは以下のグラフをご覧いただきたい。これはERPを利用中の年商500億円未満の中堅・中小企業に対し、「導入/サポートの価格は妥当か？」「機能が足りているか？」「自社の要件に合致しているか？」といった3つの観点での評価を尋ね、その結果をポイント換算したものである。
なお、本調査ではERPの利用形態を以下の3通りに分類している。
パッケージ/サービス
冒頭に例示したようなパッケージ製品を自社で運用している、またはそれらのパッケージをASP/SaaS形態のサービスとして利用している場合である。ERPのASP/SaaS形態はまだごく少数であるので、パッケージ製品の自社内運用と実質的に同等とみて良い。
独自開発システム(OSSベース)
「Compiere」「ERP5」といったオープンソースのERPをベースに、ユーザー個別のシステムを構築する場合である。サンプル数が少ないことからもわかるように、オープンソースのERP活用は中堅・中小企業ではそれほど多くない。
独自開発システム(完全なスクラッチ)
一番目の商用パッケージ、二番目のオープンソースのいずれの土台も用いず、独自にシステムを構築する場合である。SIerが自ら持つフレームワーク（Strutsを自社向けに改良したものなど）をベースにユーザー企業の要求仕様に従って開発するケースが多くを占める。
ポイント換算については、選択肢に応じて「大変不満：-5ポイント」「多少不満：-3ポイント」「どちらでもない：0ポイント」「まあまあ満足：3ポイント」「大変満足：5ポイント」と値を付け、各選択肢の回答件数に応じた加重平均値を算出している。
いずれの評価項目でも「独自開発システム(完全なスクラッチ)」が最も高く、「パッケージ/サービス」「独自開発システム(OSSベース)」の順となっている。
「独自開発システム(OSSベース)」はライセンスコスト削減の手段として選択されるものの、導入/運用のためのドキュメントが少ないなどの理由でSIer側も十分に機能を活用しきれていない場合が少なくない。そのため、全般的に評価が低くなりがちな傾向にあるようだ。
問題は「パッケージ/サービス」の評価だ。既に完成された製品を土台とすることで、豊富な機能を安価な費用で利用できる、本来はそれがパッケージのメリットであるはずだ。当然、「独自開発システム(完全なスクラッチ)」よりも「パッケージ/サービス」の方が価格、機能、要件合致性といった観点で有利になると思える。だが、ERPについてはそれが当てはまらない。それはなぜだろうか？
従来型のERPカスタマイズが抱える課題
この原因がまさに冒頭に述べた「カスタマイズ」である。中堅・中小企業においてもERPパッケージをそのままで利用するケースはむしろ少なく、何らかの形で自社の要件に合わせるための「手直し」が必要となる。カスタマイズには、以下の方法が挙げられる。
1.ERP本体部分にプログラム改変を施す方法
最も直接的な方法である。オープンソースの場合はこれが主要な手段となる。商用のパッケージの場合には「開発キット」などといった形で別途公開されたソースを入手する必要がある。
2.追加機能を持つ部品を組み込む方法
本体部分に直接プログラム的な変更を加えてしまうと、本体がバージョンアップをした際に改変部分のプログラムコードを新しいバージョンに合わせて再度適用する必要が出てくる。そのため1.の方法は「パッケージ/サービス」や「独自開発システム(OSSベース)」では維持コストが高くなりやすい。それを回避するための施策がこの「追加機能を持つ部品を組み込む方法」である。アドイン、アドオンと呼ばれるこれらの追加モジュールはERP本体に設けられた機能強化ポイント(インターフェース)に差し込む形で実装される。
だが、1.の方法と同様に本体のバージョンアップによってインターフェースそのものの仕様や追加モジュールの作成方法が変更になることもあり、1.と同様の課題が生じることも多々ある。
3.設定項目を集めた「テンプレート」を適用する方法
1.や2.はプログラム的な改変を伴う方法だったが、3.はそれとはやや異なる。ERPにはさまざまな設定項目(パラメータ)が備わっており、それを変更することで業種/業態によって異なる業務上のルールなどに対応できるようになっている。この設定項目の集まりを「テンプレート」と呼ぶ(「テンプレート」の定義はベンダによって若干異なるが、本稿の中では左記を用いる) 。
この場合、プログラム的な改変は伴わないため、バージョンアップ時の負担も1.や2.に比べると少ない。だが、本体部分に備わっていない設定項目については対応ができないため、この方法だけで自社の要件を全て満たすことは難しい。
このように「パッケージ/サービス」や「独自開発システム(OSSベース)」では自社の個別要件を満たすためのカスタマイズをしようとすると、バージョンアップ時の対応コストが発生してしまう。それを回避しようとしてテンプレートでカバーしようとすると、今度は要件をすべて満たすことができなくなる。
一方、「独自開発システム(完全なスクラッチ)の場合には最初から自社の要件を満たすように作り込むことができ、バージョンアップを強制されることもない。そのため、先に挙げたような評価差が生じるわけである。
【次ページ】バージョンアップとの「衝突」を回避した新しいカスタマイズ方法
関連タグ
