ERP知識シリーズ The・MoSCoW 第四部：BPRとMoSCoW【その8】ビジネスデータ・リエンジニアリング①データ問題構造編
ERP導入プロジェクトでは、BPRと並行して、既存データの統廃合や定義の統一といった「ビジネスデータ・リエンジニアリング」に取り組むことになります。
データの粒度やコード体系、名称ルールを整理しておくことで、データは人にとってもAIにとっても扱いやすい状態に近づきます。こうして整えられたデータは、「見る→診断する→意思決定する」という分析サイクルを通じて、データドリブンな経営判断を効率化し、次の一手につながる示唆も得られるようになります。
既存データをそのまま移行することで生じる構造的な問題
こうした「扱いやすいデータ」を目指す理由は、既存データがそのままTo-Beに適合することはほとんどなく、多くの場合で見直しが必要になるためです。既存データは、ビジネス環境の変化に合わせて項目やルールが少しずつ追加されながら運用されてきました。この傾向は現行システムに登録されているデータだけでなく、Excelや独自の管理表など、システム外で扱われてきた情報にも共通しています。日常業務では自然に使われているこれらの入力や管理の方法が、ERP導入の段階になるとTo-Beプロセスと噛み合わず、思わぬ制約として現れます。
現場で頻発する“あるある問題”
- 似て非なる品目属性コードの乱立：
本来は全社共通で使うはずの品目属性コードが、部門ごとに微妙に違う基準で作られ、似て非なるコードが複数存在するケースがあります。製造・購買・販売がそれぞれ独自の考え方で分類を作った結果、同じ品目であっても、部門によって“分類の意味”や“位置づけ”が揃わず、共通の基準で議論できない状況が生まれます。 - 値引きが単価に埋没する販売価格：
受注時の単価に値引きがそのまま含められ、標準価格と値引き額がデータ上で区別できないケースがあります。値引き理由も残らず、粗利の変動を後から追えなくなる典型例です。 - BOMに管理されていない副資材の独自管理：
フィルムやラベル、梱包材といった、本来は在庫や原価に関わる副資材が、システムではなくExcelやメモで別管理されているケースもよくあります。その結果、実態とシステム上の数値にズレが生じていきます。 - コードの桁に意味を持たせすぎて、業務判断がコード依存になる：
品目コードの桁に「カテゴリー」や「事業部」などの意味を持たせて運用するケースがあります。コードを見るだけで判断できて便利ですが、分類や組織の見直しがあるとコード体系そのものを作り替える必要が生じます。本来は属性として管理すべき情報がコード内部に埋め込まれているため、分析時には分解処理が欠かせず、柔軟な活用を妨げてしまいます。 - 備考欄（フリーテキスト）が情報のブラックボックス化：
備考欄が“万能メモ欄”として使われ、本来は項目や区分として管理すべき情報が自由記述の中に埋もれてしまうケースは非常に多くあります。担当者ごとに書き方が異なるため、分類も検索も難しく、分析に活かせないデータになってしまいます。
こうした現場起点の“あるある”は、どの企業でも探せばいくらでも見つかります。いずれも日常の業務運営の中では無理のない対応であり、普段は大きな問題として意識されることはありません。しかし、Fit to StandardタイプのERPへ置き換える段階になると、これらの運用が構造的な問題として影響し始めます。
では、それらの背後にはどのような問題が潜んでいるのでしょうか。
背後に潜む“本質的な問題”
ここまで見てきた「あるある問題」の背後には共通した構造的な問題があります。整理すると、本質的な問題は次の四つに分けて考えることができます。
- ビジネスプロセス（To-Be）とデータ構造が噛み合っていない
- 単一の基準とルールが維持できず、統制が効いていない
- データの意味や使い方が属人化し、説明と継承ができない
- 分析や意思決定に十分に使える形になっていない
これらはそれぞれ独立した問題というよりも、(1)のズレを起点として、(2)の統制不全が生まれ、(3)の属人性を助長し、その結果として(4)の「活用できないデータ」に行き着く、という連鎖関係にあります。以下では、一つずつ詳しく見ていきます。
- ビジネスプロセス（To-Be）とデータ構造が噛み合っていない
- 最も根本的な問題は、BPRで描いたTo-Beプロセスと、そこで扱うべきデータの構造が一致していないことです。業務の流れ自体はTo-Beとして再設計されていても、その前提となるデータは依然として既存の構造のままであり、両者の間にズレが生まれています。
- このズレは、To-Beプロセスを成立させるために必要となる意味や粒度が、既存データでは十分に表現されていないことで表面化します。
- 例えば製造領域では、本来は工程ごとに作業時間や段取り時間を把握したいにもかかわらず、実績が一括で登録されてしまい、工程別の実態が見えなくなるといった状況が見られます。
- 購買でも、仕入先から多めに納品された際の差異や理由がデータとして残らず、どこで在庫数にズレが発生したのかを後から判断できないことがあります。発注数量と入荷数量の差には本来、確認・承認・処理といったプロセスが紐づくはずですが、それがデータ上では表現されていません。
- 受注領域では、オリジナルの顧客希望納期が社内で調整した回答納期に上書きされ、区別できなくなる場面が少なくありません。この状態では、納期遵守率を正しく捉えることが難しく、改善の着眼点がぼやけてしまいます。
- このように、To-Beプロセスで求められる切り口や管理単位が既存データの構造では十分に表現されていない場合、業務だけをTo-Beに再設計しても、そこを流れるデータが追随できず、BPRで描いた「理想の運用」が実現しにくくなります。
- 単一の基準とルールが維持できず、統制が効いていない
- 次に問題となるのが、単一の基準（Single Source of Truth）が保てず、統制が効かなくなっていることです。
- 同じような意味を持つコードや分類がいくつも併存し、どれが正式な基準なのかを組織として説明できない。部門ごとにローカルルールでコードや区分を追加してきた結果、似て非なる品目属性コードや管理区分が増えていく。新旧のルールが混在し、「これは昔のルール」「これは最近の登録」など、その場しのぎの説明で処理されてしまう状況も見受けられます。
- こうした状況では、新たな登録を行うたびに「どの基準に合わせるべきか」をその都度判断する必要が生じ、マスタ維持そのものが難易度の高い作業になっていきます。
- データの意味や使い方が属人化し、説明と継承ができない
- 統制が効いていない状況が続くと、データの意味や使い方は必然的に属人化していきます。
- どのコードを使うべきか、どの分類が正しいかは、過去の事情を知っている特定の担当者だけが理解している。「このコードは触らないほうがいい」「この区分は帳票の都合だけで存在している」といった非公式ルールが、口伝えで引き継がれていきます。新しい担当者は、意味が分からないまま“前と同じように”登録するか、怖くて変更に手を出せない、という状況に陥りがちです。
- このように、マスタの意味やルールが文書や設計としてではなく、人の頭の中にだけ存在するようになると、組織としてデータの整合性を維持することが難しくなり、品質も徐々に揺らいでいきます。
- 分析や意思決定に十分に使える形になっていない
- 最後に表面化するのが、数値自体は取得できているのに、意思決定に活かせるデータとして機能していないという問題です。
- 部門間の不統一を補正するために、裏側でコード変換やマッピングが必要となり、ExcelやBIツールに個別ロジックが埋め込まれていきます。レポートの見た目は整っていても、「この数字がどのコードをどう束ねて算出されているのか」「誰のロジックに依存しているのか」が分からず、データの説明可能性と再現性は失われていきます。
- さらに“意味ありコード”を業務判断に利用している場合、分類や管理軸を変えたいときにコードの分解が前提となり、柔軟な分析が難しくなるという問題が生じます。本来は項目として管理すべき情報をコード内部に埋め込んでいるため、To-BeプロセスやKPIで必要となる切り口と整合させにくく、分析の自由度も限定されてしまいます。
- このような状況では、データを使って議論しているように見えても、実際には「変換済みの数字」に後から解釈を乗せているだけに近くなり、本来の意味でのデータドリブンな意思決定からはむしろ遠ざかってしまいます。
こうした連鎖が続く限り、レポートを作り替えても、画面を整えても、根本的な解決にはつながりません。既存データにERPを寄せてしまうと、BPRで描いたTo-Beの業務も、プロジェクトの目的に沿って設定したKPIも、本来の役割を果たせなくなります。
前回の記事で述べた「測定しないものは改善できない」という原則は、まさにこのことを指しています。測定に必要なデータが整わなければ、改善のサイクルそのものが成立しません。ERPを既存データに合わせるという判断は、改善という目的そのものを手放すことと同義です。
今回取り上げた四つの本質的な問題は、その背景や構造を理解するためのものです。
次の投稿では、これらの本質的な問題をどのように解きほぐし、To-Beプロセスと整合した形でデータを再構築していくのか、すなわち「ビジネスデータ・リエンジニアリング」そのものの進め方について整理していきます。
