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

ERP導入の要件定義

ERPの導入では「業務をパッケージに合わせる」というアプローチがよくいわれていますが、無理があるかどうかは疑問が残ります。また「できるだけ カスタマイズしない」という理想論もいわれることが多いのですが、販売管理や生産管理などの複雑な業務においても本当に実現できるのでしょうか。第2回は そのような建前と本音をテーマとして取り上げてみます。

パッケージインテグレーションの要件定義の方法

最初からシステムを構築する受託開発（テーラーメイド開発）とERPを使ったシステム構築作業（パッケージインテグレーション）では要件定義の方法 が若干違うといわれています。受託開発では業務要件を聞き出してそれに合ったシステムをデザインしていき、それ対して後者はERPをベースとして業務をそ れに合わせるアプローチとなります。

しかしこれを鵜呑みにして、どのような場合でも「パッケージに合わせてください」というだけのスタイルでシステム開発を推し進めると、後々で仕様の漏れが生じやすくなります。

確かに会計や債権や債務／人事や給与など、企業による業務の差が少ない業務ではパッケージベースでも問題なくシステム開発が進められます。また企業 規模が小さく、企業が容易にパッケージに業務を合わせられる場合も問題はありません。しかし販売管理や調達管理、そして生産管理など企業により業務形態が 大きく異なる分野においては、業務にパッケージを合わせるという考えを持つことも肝要なのです。

業務とパッケージ、どちらに合わせればよいのか

ところで、要件定義のアプローチにおいて「業務をパッケージに合わす」のと「業務にパッケージを合わす」のとでは、具体的にどのような作業の違いが あるかおわかりでしょうか。「業務をパッケージに合わせる」場合には、まずパッケージをインストールして、実務で使っている業務データをシステムに入力し ます。そしてパッケージの機能をベースにして、新しい業務フローを策定していくことになるのです。

一方、「業務にパッケージを合わす」場合は業務フローを作成することが先決となります。パッケージを業務にあてはめながら、新しい業務フローを作成する作業を行い、パッケージがフィットしないカスタマイズ項目を洗い出していくのです。

2つの要求定義のアプローチについて説明しましたが、実はどちらのアプローチでも結果は同じになります。図1に示すように、新システムで実現すべき 「新業務フロー」とパッケージに追加・修正すべき「カスタマイズ項目一覧」がアウトプットとして作成されます。また実際には、「業務フロー作成」と「パッ ケージのデータ検証」は並行的に行われるのです。
 

図1：パッケージインテグレーション要件定義の作業方法

パッケージの機能を確認しながら新しい業務フローを描き出し、パッケージに標準で含まれない部分をカスタマイズ項目として抜き出す必要があります。つまり、「業務」と「パッケージ」はどちらを優先させるのかではなく、同時並行的に合わせあうものなのです。

大切なことはパッケージを早い段階でインストールして、実業務データを入れてユーザに見て触ってもらうことなのです。時々テーラーメイド開発のよう に、いつまでもヒアリングと設計資料だけで作業を進めている例を見ることがあります。しかしパッケージインテグレーションの場合は、早い段階でユーザに パッケージを触らせることを重視して進めた方が効果的です。