ERP知識シリーズ ユーザー定義フィールドの取扱説明書① UDF乱用から始まる「失敗の始まり」を回避し、Fit to Standard を目指す
ERP選定段階でよくある話です。ユーザーから「こういった項目を持てますか？」との問いに、ITベンダーから「ユーザー定義フィールドで持つことができます」と即答される瞬間。それは、私が「ERP導入失敗の始まりだ」と感じる典型的なケースです。
ユーザー側としては、現在使っているシステムの項目を新システムへそのまま移行したいという思いから、「◯◯項目を持てること」といった機能要求が起票されます。このとき陥りがちな失敗例は、現行の項目を精査せず、安易にERPのユーザー定義フィールド（UDF）で対処してしまうことです。なぜこれが問題なのでしょう？ 二つの事例で説明します。
プロセス定義の重要性とUDF乱用の危険性
一つ目は、ビジネスプロセスフローを先に決めることの重要性です。必要とされる項目は、あくまで「現在の」業務プロセスで必要とされているものに過ぎません。新たなビジネスプロセスに移行した際、本当に同じ用途が必要なのかは、実際のERP標準機能を用いた実機検証で初めて明らかになります。
例えば、「受注入力時に在庫予約用フラグを付けて欲しい」という項目追加要求を考えてみます。多くのERPには、ATP（Available to Promise：引当可能在庫）やCTP（Capable to Promise：製造可能在庫）といった在庫確約機能が標準搭載されています。これら機能を活用すれば、受注に対してシステムが自動的に最適な在庫を割り当て、必要なら製造予定から確保します。つまり、担当者が「予約用フラグ」を手動で設定する手間は不要であり、フラグ付与を前提とした抽出処理は本来の在庫最適化から外れた対処療法なのです。
アウトプットを考えずに項目追加するリスク
二つ目は、追加項目のアウトプット（帳票や分析レポート）を想定しているかどうかです。仮に「在庫予約フラグ」をUDFで受注入力画面に追加したとして、それが後から受注請書などの印刷物や他システムとの連携に必要になると、レポートのカスタマイズやインターフェース開発が必須となります。こうした行き当たりばったりの項目追加は、後々大きな負担とコストを生み出すのです。
DOA (データ指向：Data Oriented Approach) と POA (プロセス指向：Process Oriented Approach) の観点から見る項目設計
このような問題は、ERP導入時のアプローチの違いとも深く関わっています。
- DOAはデータ項目を起点に要件定義を行い、データモデル優先でシステムを組み立てます。これは現行項目への執着を生みやすく、真の業務改革を阻害する可能性があります。
- POAはプロセスを起点に考え、標準プロセスを最大限活用した上で必要なデータ項目を洗い出すアプローチです。これにより、不要なカスタマイズやUDFの追加を最小化し、Fit to StandardなERP稼働を実現しやすくなります。
正しいステップと全社的な再考
正しいアプローチは「必要な追加フィールドは要求管理に挙げるが、初めは何もしない」ことです。そのフィールドが本当に必要か、どのようなアウトプットを想定しているかを明確化し、プロセス→ファンクション→フィールドという順序で検証することで、不要な項目が自然と淘汰され、標準機能で運用可能な状態へと近づきます。
こうしたサイクルを高速回転で回し、実運用を想定した検証を重ねると、ユーザーはERP標準機能の強みを理解し、既存項目への執着が薄れます。その結果、Fit to Standardが実現され、システム運用・保守コストの削減、業務効率化の向上が得られるのです。
本記事では、ERP導入時に陥りがちな「UDF頼み」の罠と、それを回避するための基本的な考え方（POAの重視とFit to Standard志向）を解説しました。次回の記事「ERP知識シリーズ ユーザー定義フィールドの取扱説明書② 現行踏襲からの脱却」では、これをさらに一歩進めた具体的なアプローチを紹介します。As-Is要求とTo-Be要求を適切に整理・検証し、ERP標準プロセスを最大限活用しながらアドオンを最小化する手法について、実践しているプロセス例を用いて解説します。
