ERP知識シリーズ The・MoSCoW 第四部：BPRとMoSCoW【その8】ビジネスデータ・リエンジニアリング②解決編
前投稿で取り上げた四つの本質的な問題、
① ビジネスプロセス（To-Be）とデータ構造が噛み合っていない
② 単一の基準とルールが維持できず、統制が効いていない
③ データの意味や使い方が属人化し、説明と継承ができない
④ 分析や意思決定に十分に使える形になっていない（活用できないデータになっている）
は、いずれも既存データがAs-Isの業務運用に合わせて積み重ねられてきた結果として生じたものです。
ビジネスデータ・リエンジニアリングとは何か（本質的な問題の解決策として）
ビジネスデータ・リエンジニアリングとは、この歪みを解消し、BPRで描いたTo-BeプロセスとKPIに合わせて、データの意味と構造を再設計する取り組みです。単なるデータクレンジングや移行前の整理ではなく、To-Be業務を本当に機能させるための「データ側のBPR」と言えます。
以下では、ビジネスデータ・リエンジニアリングが、四つの本質的な問題をどのように解消するのかを整理します。
① To-Beプロセスに合わせてデータの「意味・粒度・取得タイミング」を再設計する（構造化）
To-Beプロセスでは、新しい仕事の進め方に合わせて“プロセスを流れるデータ”の意味や粒度を再定義する必要があります。以前の投稿「KPIマネジメント」で触れたように、「なくなる／変わる／減る／増える」といった業務の変化が生じるため、KPIを成立させるには、その変化を捉えられる形にデータも作り直さなければなりません。
そのイメージをつかみやすくするために、指図書を紙からタブレットへ切り替えるケースを例に考えてみます。
As-Is（紙の指図書）では、現場で次のような情報が紙の上でやりとりされています。
- 手書きの作業者名
- 開始・終了時刻の手書き記入
- 消費量のメモ書き
- 品質チェックの⚪︎×
- 製造ロットの書き込み
業務自体は成立していても、管理は紙やExcelにとどまり、システムにはあとから必要最低限の情報だけを転記する運用になっています。そのためデータの粒度は粗く、記録のタイミングも現場によってバラつきが生じ、現場の判断とデータの軸が揃わないまま運用が続いていきます。
一方、To-Be（ペーパーレス：タブレット化）では、プロセスの進行に応じてデータがその場で確定されるようになります。その結果、データ構造は次のように再設計されていきます。
まず、追加されるデータ項目として、例えば次のようなものが挙げられます。
- 作業者ID（ログインにより自動取得）
- 開始・終了のタイムスタンプ
- 作業中断理由コード
- アラートフラグ（温度異常・資材不足など）
- 使用ロット番号（スキャンで確定）
逆に、削減されるデータ項目もあります。
- 手書き署名欄
- 手書きの時間記録
- メモ書きの調整情報
紙だからこそ残っていた「非構造な情報」は電子化によって役割を終え、必要なものは構造化された項目としてデータ側に取り込まれていきます。
紙では別々に扱われていた情報が、次のような統合されたデータ項目としてひとまとまりになります。
- 作業者
- 作業時間
- ロット番号（使用ロット・製造ロットを含む）
- 品目属性（製品ライン・仕向地など）
- 品質チェック
- 機械稼働情報
これらが「1つの製造実績データ」として一体化されることで、後工程の分析やトレーサビリティにも使いやすい形になります。判断の基盤も、品番やロット番号ではなく、その品番やロット番号に紐づく属性情報へと移っていきます。
粒度が変わるデータもあります。
As-Is では、「紙1枚 = 1オーダー」が単位で、小さな段取り替えや微調整は記録されないまま流れていました。
To-Be では、「作業ステップ単位（セット → 投入 → 検査 → 仕上げ）」で記録し、原材料消費も「ロット × 数量」の粒度で残すようになります。つまり、「1オーダー = 1データ」だったものが、「1ステップ = 1データ」へと変わり、プロセスの実態に沿った粒度でデータが残るようになります。
データ登録のタイミングも大きく変わります。
As-Is：作業後に紙へ記入し、後日まとめてシステムへ転記
To-Be：作業の「発生タイミング」でデータが即時に確定
具体的には、
- 作業者がログインすると、その時点で作業者IDが登録される
- 「開始」操作で開始時刻が記録される
- 原材料をスキャンすると、ロット番号と数量が確定する
- センサーが異常を検知すると、アラートフラグが自動でONになる
- 「終了」操作で実績数量と終了時刻が確定する
このように、プロセスの節目がそのままデータ確定の節目となり、後追い入力やタイムラグが解消されます。
ペーパーレス化という一つのBPRの中だけを見ても、これだけ多くの「追加・削減・統合・粒度変更・登録タイミングの見直し」が同時に起きています。To-Beプロセスに合わせてデータの意味と構造を再設計するとは、まさにこうした変化をまとめて受け止め、KPIで測れる状態に変えていくことだと言えます。
② 単一の基準（Single Source of Truth）を再構築し、統制を取り戻す（体系化）
To-Beプロセスの視点からデータの意味を定義し直したあとは、その意味に沿ってマスタやコードの「使い方」を揃えていくことが求められます。ここで重要なのは、コード体系そのものを先にいじるのではなく、「まず意味を決め、その意味に対してコードをどう位置づけるか」を整理することです。
以前の記事「ERP知識シリーズ The品目マスター」でも触れたように、コード体系の見直しは設計の出発点ではなく、「何をどう区別するか」という意味づけを定めた結果として決まるものです。この考え方は、ビジネスデータ・リエンジニアリングでも同じです。
具体的な見直しの内容としては、次のようなものがあります。
- 似て非なる分類やコードについて、「何を区別するためのコードなのか」をTo-Beの観点で整理し直す
- 部門ごとに独自に増えてきたローカルコードの役割を再確認し、必要に応じて統合・廃止を検討する
- 過去の経緯で残っている新旧ルールを棚卸しし、「今後正式に採用する基準」を明確にする
- 品目・顧客・仕入先・組織などの階層構造を、To-Beプロセスと管理したいKPIに合わせて再設計する
品番やロット番号に意味を詰め込んで人がそれを読み解くやり方も、このステップで整理の対象になります。コードに埋め込んでいた意味を、品目属性・ロット属性・組織階層といった構造に移し替えていくことで、コード自体は「一意に識別するためのキー」としての役割に専念させることができます。
こうした整理を行うことで、同じ意味のものは同じコード・同じ属性で扱われる状態が実現し、どの部門でも同じ基準でデータを扱えるようになります。これにより、マスタ維持で迷う場面が減り、統制の再現性も高まります。
最終的にマスタは、過去の暫定運用が積み上がった“堆積物”ではなく、To-Beプロセスを支えるための安定した基準として再構築されます。部門ごとに異なっていた解釈や扱い方がそろうことで、データの前提が統一され、どの部門でも一貫したルールで登録・参照・運用できる状態が実現します。これが、このステップで取り戻すべき「統制」の姿です。
③ 属人化していた“判断と知識”を項目・ルールとして形式知化する（運用設計）
ビジネスデータ・リエンジニアリングは、現場で行われてきた属人的な判断を、データ項目とルールに置き換えていくプロセスでもあります。
- 備考欄に書かれていた重要情報を、項目として切り出す
- 「このケースはこう扱う」といった暗黙知を、属性や区分として定義する
- 特定の担当者だけが知っている分類基準を文書化し、データ構造として表現する
- 理由コードや管理区分を標準化し、選択肢として組み込む
こうした整理を通じて、人の頭の中にだけ存在していた判断基準が、誰もが再現できる運用ルールとしてデータに埋め込まれていきます。その結果、入力も分析も担当者に依存しなくなり、新任の担当者でも同じ品質で業務を回せるようになります。
従来はロット番号の並びを読み取って判断していた出荷や引当の業務も、属人化の典型例です。To-Beでは、ロットに製造日・工場・賞味期限・検査区分などの属性を持たせた上で、業務に必要な引当ルールを定義します。
例えば、
- 賞味期限が早いロットを優先する（FEFO）
- 再検査品の引当可否
- 特定工場ロットの優先／回避
- 品質グレード別の優先順位
といったルールを設定しておけば、システムが属性をもとに自動的に最適なロットを選択します。判断の源泉が「番号」から「属性 × ルールベース」に置き換わることで、属人判断は姿を消し、業務は標準化・自動化された流れに変わっていきます。
④ 分析や意思決定に耐えうる「説明可能なデータ」に変える（分析基盤）
最後に、データを分析や意思決定に耐えうる形に整えることも、リエンジニアリングの重要な役割です。
- 部門ごとの違いを補正するためのコード変換やマッピングに頼らない設計にする
- 裏側での帳尻合わせや、一部の担当者だけが知る加工ロジックを排除する
- レポートやダッシュボードの前提となる切り口・定義をデータ構造として一貫させる
- 「この数字は何をどう集計した結果なのか」を誰でも説明できる状態にする
こうして整えたデータは、意味と計算過程が明確で、再現性のあるデータになります。BIやAIは、そのような説明可能なデータを前提にしてこそ、本来の力を発揮します。
まとめ：To-Beプロセスとデータをセットで設計し直すこと
ビジネスデータ・リエンジニアリングは、BPRで描いたTo-Beプロセスを、データの側から支えるための再設計です。
- プロセスだけTo-Beにしても、流れるデータがAs-Isのままなら、運用は過去に引き戻される
- KPIを定義しても、その軸となる情報がプロセス側のインプットに存在しなければ「測れないKPI」になってしまう
- レポートだけを作り替えても、背後のデータ構造に歪みが残れば属人性から抜け出せない
こうした状況を断ち切るために、プロセスとデータを“To-Be側”で揃え直すのが、ビジネスデータ・リエンジニアリングの役割です。今回の投稿では、その必要性と本質的な位置づけを整理しました。
次の投稿では、こうした考え方を前提に、実際のプロジェクトでビジネスデータ・リエンジニアリングをどのように進めていくのかについて、MoSCoWの優先順位付けと併せて掘り下げていきます。
