ERP知識シリーズ マスメン 第八部：これからのマスターメンテナンスを考える
ここまでのシリーズでは、マスターメンテナンスを、トリガーイベント、判断、Create・Read・Update・Delete、適用日、切替点、取引関係、情報の発生源と確定する場所までたどってきました。
第七部までで変更経路を設計できたら、次に考えたいのは、その経路を現在の技術でどこまで仕組みにできるかです。
いま、企業のデータ基盤は大きく変わっています。ERPやPLMなど複数の業務システムに蓄積された、購買、生産、品質、販売などのデータを統合データ基盤へ集め、鮮度、件数、分布、整合性などを継続的に監視する仕組みが実用化されています。
さらに、データの変化を検知して処理を開始したり、蓄積・整備したデータを業務アプリケーションへ届けて活用したりする仕組みも広がっています。その一つが、データアクティベーションです。
これらを組み合わせると、第七部までで整理した変更経路を、より自動的に実行できるようになります。
マスターを実績から問い直す
例えば、ERPに登録している仕入先の標準リードタイムが5日だとします。
実際の納品実績を統合データ基盤で継続して確認すると、特定の仕入先・品目・拠点では、直近3か月の実績が7日前後で安定している。この状態が続けば、現在の標準リードタイムが実態に合っているかを確認する理由になります。
ここで重要なのは、マスターとトランザクションを一緒に見ることです。
マスターには、会社が業務を動かすために決めた前提が入っています。トランザクションには、その前提を使って実際に業務を行った結果が蓄積されます。
標準リードタイムと納品実績、発注単位と実際の発注数量、品質条件と検査結果。両者を継続して比較することで、マスターの見直しが必要な兆候をデータから見つけることができます。
長期間利用されていないコード、複数システムで一致していない属性、適用日を過ぎても利用側へ届いていない情報なども監視対象になります。
第二部で考えたトリガーイベントに、データから発見するトリガーが加わるという考え方です。
検知した後の調査を自動で進める
兆候を検知したら、次にその差が生じた理由を確認します。ここでは、AIが大きな役割を担えます。
リードタイムの例であれば、過去の納品実績を仕入先・品目・拠点ごとに確認し、いつから傾向が変わったのかを調べる。季節要因なのか、配送条件の変更なのか、特定期間だけの遅延なのかを整理する。さらに、発注残、在庫、生産計画への影響をまとめる。
その結果を基に、「標準リードタイム5日を7日へ見直すことを検討」といった変更候補を作り、担当者への確認依頼まで作成することも考えられます。
ただし、ここで前提になるのがデータそのものの品質です。
GIGO（Garbage In, Garbage Out）という言葉があります。入力するデータが正しくなければ、AIがどれだけ高度になっても、そこから得られる判断や処理の品質は上がりません。
マスターの重複、古い値、不整合を抱えたままでは、異常検知や変更候補の精度にもその影響が表れます。
AIエージェントを組み合わせれば、関連するデータを集め、過去の変更履歴を確認し、判断材料と変更候補をまとめ、次のワークフローへ渡すところまで一連の処理として設計することもできます。
人は、そろえられた情報を基に取引への影響や例外条件を判断します。
判断の重さによって自動化の範囲を変える
どこまで自動化するかは、変更内容によって変わります。
頻度が高く、判断条件が明確で、影響範囲が限定され、元の値へ戻しやすい変更であれば、自動更新まで進めることが考えられます。
金額や品質への影響が大きい変更、複数部門へ影響する変更、例外条件が多い変更では、監視、調査、変更候補の作成までを仕組みが担当し、人が判断・承認する形が考えられます。
見るべきなのは、頻度、判断条件の明確さ、影響範囲、誤った場合の損失、復旧のしやすさです。
この基準を持つことで、AI、システム、人の役割をマスター変更の単位で具体的に分けられます。
マスターを企業の外とも共有する
もう一つ、これからのマスメンで考えておきたいのが、データシェアリングです。
例えば、仕入先自身が確定する法人情報や認証情報などを考えてみます。変更のたびに顧客へ通知し、それぞれの顧客企業が自社のマスターへ転記すると、同じ情報を多くの企業がそれぞれ保守することになります。
現在のデータシェアリングには、データを相手へコピーし、別々に保有する方法に加えて、提供側が管理するデータを、権限を持つ利用者が直接参照する仕組みもあります。提供側で情報が更新されれば、利用側も更新されたデータを参照できます。
この考え方をマスメンへ広げると、情報を確定する企業がデータを管理し、その情報を必要とする取引先が共有して利用するという形も考えられます。
仕入先が確定する情報の一部は仕入先から共有し、顧客ごとに異なる購買価格や仕入先評価、発注方針などは顧客側で管理する。第七部で整理した「その情報はどこで生まれ、どこで確定するのか」という考え方を、企業間まで広げることになります。
企業ごとに同じ情報を保守するという現在のマスメンの前提そのものを、データシェアリングによって見直せる可能性があります。
確定したデータを業務で使える状態にする
変更が確定したら、APIや統合・自動化基盤を使って、正として管理するシステムのマスターを更新します。
その確定したデータを、必要な業務アプリケーションへ届けて利用するところでは、データアクティベーションという考え方を活用できます。
統合データ基盤に蓄積・整備したデータを必要な業務アプリケーションへ同期し、実際のアクションにつなげます。Reverse ETLは、その代表的な実現方法の一つです。
さらに、iPaaSに代表される統合・自動化基盤やイベント駆動の仕組みを組み合わせれば、「承認完了」「設計変更確定」「品質評価完了」といった出来事を起点に、APIを通じて後続処理を開始できます。
第七部までで整理した変更経路が、ここで自動化の設計図になります。
更新した結果をもう一度データで確かめる
更新後には、その変更が意図した結果につながったかを確認します。
リードタイムを5日から7日へ変更したのであれば、その後の納品実績との乖離が縮まったかを見る。品質条件を変更したのであれば、検査結果がどのように変化したかを確認する。購買条件を変更したのであれば、その条件が実際の発注で使われているかを確認します。
結果が想定と異なれば、再び見直し候補を出します。
監視
→ 兆候の検知
→ 原因と影響の分析
→ 変更候補の作成
→ 判断・承認
→ 更新・連携
→ データアクティベーション
→ 結果確認
→ 再び監視
現在のデータ品質監視、異常検知、イベント駆動、統合・自動化基盤、AI、データアクティベーションを組み合わせれば、このような循環を構成することも考えられます。
自動化の範囲が広がれば、変更履歴を確認し、必要に応じて過去時点のデータを参照・復元できる仕組みも重要になります。
マスメンは継続的に適応する仕組みへ
第七部までで整理してきたマスメンの考え方に、現在のデータ基盤、AI、統合・自動化技術を組み合わせると、データの変化そのものをマスター見直しのきっかけにできます。
統合データ基盤が変化を捉え、AIが原因や影響を整理し、人が必要な判断を行う。確定した変更を必要なシステムへ届け、その結果を再びデータで確かめる。
マスターは業務を動かす前提です。その前提を実際の業務データから継続的に確かめ、必要な変化を次の業務へ反映していく。
これが、これからのマスターメンテナンスを考える上で、一つの有力な方向ではないでしょうか。
