ERP知識シリーズ The・MoSCoW 第四部：BPRとMoSCoW【その8】ビジネスデータ・リエンジニアリング③設計の順序と判断軸
前回までの【問題編】【解決編】では、ビジネスデータ・リエンジニアリングがなぜ必要なのか、そして何を解消しようとしているのかを整理しました。本稿では視点をより実践に近づけ、「実際のプロジェクトでは、どのような順序で進めるべきか」という“進め方”に焦点を当てます。
よくある“間違った進め方” データ項目から入ってしまう
ビジネスデータ・リエンジニアリングを進める際、最もよく見られる誤ったアプローチがあります。それは、現行システムのテーブル構造や項目一覧を出発点にし、そのままTo-Beシステムへマッピングしようとする進め方です。
もちろん、「To-Beに合わせるために現行との差分を把握する」という目的で一覧を参照すること自体は問題ありません。問題になるのは、To-Beの項目や意味を十分に理解しない段階で、現行の項目を「業務で使っているから」という理由だけで、項目レベルで1対1のマッピングを始めてしまうことです。
To-Beプロセスを検証していない段階では、プロセスのインプットとアウトプットが定まらず、その結果として、どのデータを持つべきかを判断できません。その状態でデータ項目だけを先に揃えようとすると、現行で使っている項目を基準に考えざるを得なくなります。
その結果、現行で使っている項目をすべて移行対象に含めようとして項目定義が膨れ上がり、場合によってはこの段階でユーザー定義フィールドを使い切ってしまいます。しかし、後からTo-Beプロセスが具体化すると、それらの多くが不要であることが明らかになり、マッピングや移行設計を見直す必要が生じます。
さらに、To-Beプロセスを前提にしていないため、プロセス変更によって新たに必要となる副資材、値引き理由、取引条件といった項目が初期設計から漏れます。その結果、KPI算出に必要なデータが揃わず、後追いで入力ルールを追加することになり、業務設計と運用の間にズレが生じます。
プロセスモデルとデータモデルを同時に再構築する
ビジネスデータ・リエンジニアリングは、BPRによってプロセスモデルをTo-Beへ再構築していく過程で、そのプロセスを成立させるためのデータモデルも併せて見直していく取り組みです。To-Beプロセスを検討する際には、プロセスフローだけでなく、その前提となるデータ構造についても、一定の粒度で仮定しながら検証を進めていきます。
代表的な前提となるデータモデルには、次のようなものがあります。
- 在庫階層（どの粒度で在庫を持ち、どこで計画立案や在庫引当するのか）
- 取引タイプ（オーダータイプ）
- 品目やBOMといった技術情報の構造
これらは、プロセスそのものを左右する前提条件です。Fit to StandardでTo-Beプロセスを検証するためには、SaaS ERPが前提とするTo-Beデータモデルに業務をマッピングし、その枠組みの中で業務が成立するかを確かめていく必要があります。
一方で、こうしたビジネスデータをリエンジニアリングすること自体が、プロジェクトにとって大きな課題になります。
在庫階層を見直すと、「どの単位で在庫を把握し、どこで引当や補充を判断するのか」が変わります。例えば、倉庫単位でしか在庫を持っていなかった状態から、ロケーション単位で在庫を管理するようになれば、引当はより細かな単位で行われ、これまで処理する必要のなかった在庫移動が必要になります。品目やBOMの定義を見直せば、原価計算や在庫評価の前提も変わります。
このように、プロセスを変えようとすると、その前提となるデータモデルにも手が入るのは必然なのです。
プロセスとデータを階層で捉える ― MoSCoWの使いどころ
ビジネスデータ・リエンジニアリングを適切に進める際に役に立つのが、MoSCoWです。MoSCoWはTo-Beプロセスを検証するための判断軸であり、データはその検証を支える前提条件として位置づけられます。以下では、MoSCoWの例を用いて掘り下げていきます。
Must have：顧客の要望に応じて在庫を自動で引き当てる
一見するとTo-Beを表した要求に見えますが、このままでは業務設計が前に進みません。自動引当を成立させるためには、システムが何を基準に判断するのかを定める必要があり、その基準はデータ属性として定義されます。顧客要望が納期なのか品質なのか、どの条件で出荷可否を判定するのかといった判断材料が属性として揃って初めて、自動引当は成立します。
この整理を進めやすくするために、MoSCoWの内容を見直します。属性が在庫引当だけでなく顧客分析などにも利用される場合には、上位にプロセス要求のMoSCoWを置き、その下に、プロセスを成立させるためのデータ要求のMoSCoWを配置します。一つのMoSCoWで表現できれば理想的ですが、この例では用途が広いため、役割ごとに切り分けて整理します。
プロセス要求の優先度が上がれば、そのプロセスを成立させるために必要なデータ要求も、同じ水準で優先度を揃える必要があります。例えば、「顧客要望に応じて在庫を自動で引き当てる」というプロセスがMustであれば、引当判断に用いる在庫属性（賞味期限、品質区分、保管場所など）や、その属性を正しく管理するためのデータ構造もMustとして扱われます。
プロセスとデータ設計を具体的に進める段階では、KPIが判断の拠り所になります。KPIはプロジェクトの目的に属する指標としてTo-Beで定義され、その実現に必要なインプット条件が定まります。
データモデルに関するMoSCoWの目的は、To-Beプロセスで何を判断し、どこまで意思決定するのかを明確にし、その成立条件としてデータモデルを揃えることにあります。この関係が整理できると、プロセスとデータは整合し、ビジネスデータ・リエンジニアリングはBPRの実現と歩調を合わせて進んでいきます。
ビジネスデータ・リエンジニアリングとデータ移行
BPRを実現するためにデータモデルを再設計した後は、データ移行に移ります。そして、データモデルの現行との差が大きいほど、データ移行の課題も重みを増していきます。
品目定義を見直せば、在庫管理や他システムで使っている品目定義も合わせて見直す必要が出てきます。BOMを見直して構成ルールや階層を整理すれば、原材料の引当方法や製造実績の持ち方が変わり、それに伴って原価計算や在庫評価の算定ロジックも影響を受けます。また、顧客や仕入先の区分を再定義すれば、過去データをどの区分に紐づけ直すのか、あるいは切り離して扱うのかといった判断も必要になります。
これらはすべて、データ移行設計の複雑さとして跳ね返ってきます。
以上を踏まえると、ビジネスデータ・リエンジニアリングは、「移行を楽にするための工夫」ではなく、BPRを成立させるために、あえてデータ移行を難しくする選択でもあります。
まとめ
ビジネスデータ・リエンジニアリングは、BPRで描いたTo-Beプロセスを、ERP上で本当に動かすために、データモデルを作り替える設計行為です。
その過程では、現行データとの乖離が広がり、移行設計は確実に難しくなります。それでもデータモデルを変えなければ、プロセスはシステム上で成立せず、BPRは実装されません。
どこまで作り替えるかを判断するにあたっては、To-Beプロセスを設計の軸に置き、MoSCoWやKPIを判断のよりどころとして用います。プロセスとデータを切り離さず、To-Beを成立させる前提としてデータモデルまで設計対象に含めることが重要です。そこが、BPRを単なる構想で終わらせず、実運用として成立させるための分かれ目になります。
