【技術動向】見えてきた、アドオン開発を抑えERPを早期導入する新技術

高コストで長期間のERP導入はもう許されない――多くの企業がこう考えている。ではコストを掛けずに短期導入するにはどうすればいいか。関連技術の動向をお伝えする。

公開 2012年08月31日 08時02分

更新 2012年09月04日 12時14分

著者

岡部志保

[ビーブレイクシステムズ]

印刷する

安く、早くで普及してきたERPパッケージ

　1990年代半ばから国内での利用が広がってきたERPパッケージ製品は、標準機能がオールインワンで提供されるため、スクラッチ開発と比べ開発期間が短く低コストで導入できるのが特徴。また全体最適という視点（ベストプラクティス構想）で業務改善が行えるというメリットから、日本企業に広く受け入れられてきた。2000年問題対応を機にスクラッチ開発の基幹システムをERPパッケージに置き換える動きが顕著となり、1990年代後半には大企業を中心にERPパッケージの導入が一気に進んだ。

ERPパッケージの基本についての記事

　ERPの基本思想の1つは、業界標準の最適な業務フローがシステムに実装されていて、その業務フローに自社の業務フローを合わせれば、業務が標準化され効率化するということだ。しかし、実際は企業の現行の効率的な業務を、ERPパッケージの業務フローに合わせて変更した結果、不要な業務が発生して非効率に陥るというケースがあった。多くのERPパッケージが海外製で日本の業務フローに合わなかったり、企業が中途半端に自社の業務フローを変更したため、非効率なフローが残ってしまったのだ。

　企業はERPパッケージの業務フローと、現場の業務フローとの間に大きな乖離がある場合、無理にERPパッケージに合わせようとせず、必要に応じてアドオン開発を行ってきた。だが、そのアドオン開発に時間とコストが掛かってしまうと、安く、早く導入できるERPのメリットを企業が得られなくなってしまう（参考記事：会員調査で分かった中堅・中小企業が「ERPを導入してこなかった理由」）。

ERPパッケージの導入方法による違い

　ERPパッケージの最大のメリットは、上記のとおり安く、早く導入できることと、必要なタイミングでERPバージョンアップを行えることだ。上図はERPパッケージをノンカスタマイズで導入した場合と、アドオン開発を行って導入した場合の開発工数（時間）と導入コストについて簡単にまとめたものだ。

※ベンダーによって定義は異なるが、以下に単語の定義付けをした。
アドオン開発：ERP標準機能にない機能をユーザー仕様に合わせてシステムを作り、追加すること
ノンカスタマイズ：パラメータ設定だけで導入し、ソースコード修正や機能追加は行わないこと

アドオン開発が帳消しにするパッケージのメリット

　ERPパッケージは部門ごとの業務システムと異なり全社統合システムであるため、例えば受注・販売業務で個別処理を入力した時点で、即時に業務データが統合データベースに反映される。これによってその業務データが他の業務でも活用できるようになる。一方、あるシステムの一部をアドオン開発するだけで、他の業務に影響が及ぶリスクがある。そのため機能不足だからといって安易にアドオン開発をすると予想外の開発工数と膨大な開発コストが掛かってしまう。場合によってはスクラッチ開発で基幹業務システムを構築する場合と同じ程度のコストになることもあり、ERPパッケージを選択した意味がなくなる。

　バージョンアップについても同様で、アドオン開発を行っていると複数システムに跨る影響分析や検証、改修に膨大なコストが発生する。結果としてバージョンアップが遅れてしまい、システムが陳腐化する危険がある。ERPパッケージ利用のメリットを最大限享受するには、アドオン開発を必要最小限に抑えてERPを導入することが望ましい。またこれによって導入時のリスクを最小化することができる。

ERPバージョンアップについての記事

アドオン開発を最小限にする手段とは

　アドオン開発を少なくする方法の1つとしてフィット＆ギャップ分析がある。フィット＆ギャップ分析は、要件定義の段階で自社の業務とパッケージの標準機能の適合性について分析し、ERPパッケージをどう使うかを判断するために行うのが一般的だ。だが、適正なギャップ分析と正しいシステム設計を行うことでアドオン開発を最小限に留めることもできる。

　フィット＆ギャップ分析のポイントは、洗い出されたギャップに対して、やたらにアドオン開発をするのではなく、導入コストを検討した上で明らかにギャップと判断できる業務に関してだけ、アドオン開発を決定することだ。パッケージの標準業務フローに合わせられるような小さなギャップであれば、アドオン開発をするのではなく、パッケージの標準業務フローを自社の新業務フローとして設計するのが得策だ。

　しかし実際は、アドオンを最小限にすべきだという考え方は机上の理論になりがちだ。アドオン開発を最小限にするという方針があっても、現場との力関係もあり、結果的にアドオン開発を受け入れてしまう情報システム部門は多いからだ。多くの企業において、「自社固有の要件を満たすために膨大なアドオン開発が発生し最終的に導入が高コストになる」「そのため保守料金も膨らみ、利用し続けるだけでも高コストになる」「アドオン開発部分が多く、バージョンアップの際の検証コストが高コストになる」「結果としてバージョンアップができずにシステムが陳腐化する」という悪循環を生んでいる実態がある。

テンプレート活用でシステムをフィットさせる

　次に机上の空論にならない具体的なソリューションを紹介しよう。アドオン開発を少なくし、ERPパッケージの能力を最大限に生かす方法としてはテンプレート導入がある。テンプレートはERPパッケージの標準機能に追加して利用でき、業界固有の帳票や検証済みの業務プロセスなどがあらかじめ実装されている。パラメータ設定だけでより業務にフィットした標準機能を短期間で導入することができるのが特徴だ。業種、業態、目的別など、ベンダーやSIerが独自に開発したさまざまなテンプレートが存在する。ユーザー企業にとっては自社の業務に合うテンプレートを見つけることが重要になる。

ERPテンプレートについての記事

アドオン開発自体も進化

　自社業務フローの変更やテンプレートで対応できない部分については、アドオン開発を検討する。ERPパッケージにおいてアドオン開発が行われるのは主に以下の3つの部分だ。これらについても標準機能による運用が可能でないかを検討しながら、新システムの設計を進めることが重要だ。

帳票――最も追加開発が必要とされる部分であり、既存の帳票をそのまま使いたいのであれば開発が必要になる。パッケージの標準機能に搭載されている帳票を運用できないかを検討する。
インタフェース――既存システムと新システムの連携部分であり、必ずといっていいほど開発が必要となる部分。既存システムがメジャーなシステムの場合、ベンダーがインタフェースを用意していることもある。
自社固有の業務に関する機能開発――標準機能やテンプレートに搭載されていない機能を、自社の業務に合わせ新たに開発する部分。

　最近では、ユーザー企業の要望に対応できるようなアドオン開発の新しい仕組みやソリューションをベンダーが数多く提案している。例えば帳票では汎用的に利用できる帳票機能として、ユーザー自身がERPパッケージのデータベースに登録されたデータを自由に取り出すことができる仕組みや、ユーザー自身がデザインした帳票を簡単に出力できる機能などを用意している。

　また、ユーザーの要望に合わせてユーザーインタフェースを自由にカスタマイズできるERPパッケージや、自社固有の業務に関する機能を開発するために、生産性の高い開発環境を用意するERPパッケージもある。さらにバージョンアップ時の本体への影響を小さくするために、アドオン開発した機能をレイヤーごとに管理できるようにしたり（参考記事：シェア調査で浮かび上がるERP選びの「ニュースタンダード」）、メジャーバージョンアップなしに新機能を追加できるようにするなど（参考記事：SAP ERP 6.0を2020年まで使い続けられる理由）の仕組みが挙げられる。どうしても必要なアドオン開発については、このような仕組みを利用したい。