ERP知識シリーズ マスメン 第七部：その情報はどこで生まれ、どこで確定するのか
マスターメンテナンスのシナリオを具体化すると、登録項目や変更手順に加えて、もう一つ確認したいことがあります。
その情報は、どの業務から発生したのか。誰が内容を確定するのか。確定した情報をどこで正として管理し、どのシステムで利用するのか。
ここまで整理して、マスターの変更経路が一つの業務としてつながります。
例えば仕入先に関する情報でも、購買条件は仕入先との交渉から生まれ、品質条件は品質評価によって決まり、支払に関する情報は契約や経理上の確認を経て確定します。ERPでは一つの仕入先にひも付く情報として管理されていても、その発生源と確定する部門は項目ごとに異なります。
この違いを曖昧にしたまま運用を始めると、変更が発生するたびに「どの情報を正とするのか」「誰が更新するのか」という確認が発生します。
情報の発生源からたどる
最初に確認するのは、その情報が何をきっかけに生まれるのかです。
購買価格であれば価格交渉、品質条件であれば品質評価、設計情報であれば設計変更と承認が起点になります。業務上の出来事があり、その結果として新しい情報が生まれます。
次に、その内容を誰が確定するのかを確認します。
入力者と決定者が分かれる業務もあります。購買条件をERPへ登録する担当者がいても、価格そのものは仕入先との交渉と社内承認によって確定します。品質条件も、登録の前に品質評価と判断があります。
この順番でたどると、マスターの項目が業務上の判断結果としてどのように生まれたのかを確認できます。
複数システムを前提に考える
ERPが企業の基幹業務を広く担うようになった時代には、販売、購買、生産、在庫、会計の情報をERPへ集約する考え方が中心でした。
現在は、設計ではPLM、営業ではCRM、製造ではMES、全社共通のマスターではMDMなど、業務に応じて複数のシステムを組み合わせる構成が一般的になっています。
その結果、同じ情報が複数のシステムで利用されます。
設計情報はPLMで確定し、ERPへ連携して生産や購買で利用する。顧客情報の一部はCRMで管理し、受注や請求に必要な情報をERPへ連携する。こうした構成では、情報の保存場所だけを確認しても変更の起点は決まりません。
必要になるのは、確定した情報をどこで正として管理するのかという整理です。
確定した情報をどこで正として管理するのか
情報の発生源と決定者を整理した次に、その確定結果をどこで正として管理するかを決めます。
例えば、品質部門が確定した検査条件を品質管理システムで管理し、ERPへ連携する構成があります。購買価格はERPで確定し、その値を発注や原価計算で利用することもあります。
このとき定めているのがSoT、Source of Truthです。
SoTは、ある情報について、業務上の判断を経て確定した値をどこで正として管理するのかを定める考え方です。
情報の発生源とSoTが別になることもあります。仕入先から届いた銀行口座変更の連絡は外部から発生します。社内で内容を確認・承認し、その結果をERPで正として管理するのであれば、ERPがその情報のSoTになります。
ここで大切なのは、更新日時の新しさよりも、業務上の判断と承認を経て正式に確定した値を基準にすることです。
SoTは情報の単位で考える
「仕入先マスターはERP」「製品マスターはPLM」と大きな単位で決めると、実際の変更経路を十分に表せないことがあります。
一つの仕入先に関する情報でも、法人情報、購買条件、品質条件、支払条件では発生源と確定する業務が異なります。製品に関する情報でも、設計仕様、生産条件、購買価格、在庫条件では役割が分かれます。
そこでSoTは、情報のまとまりや重要な項目ごとに確認します。
誰がその情報を決めるのか。その決定結果をどこで正として確定するのか。確定した情報をどのシステムへ連携し、どの業務で利用するのか。
この単位まで整理すると、変更が発生したときの入口も決まります。
設計情報をPLMで確定するなら、設計変更はPLMから始まります。品質条件を品質管理システムで確定するなら、品質条件の変更はそこで確定し、必要なシステムへ連携します。
さらに、SoTが決まると、利用側のシステムで同じ値をどう扱うかも決めやすくなります。PLMからERPへ連携された設計情報を変更するときは、PLMで変更を確定し、その結果をERPへ伝えます。ERP側で個別に修正する運用を残すと、次回の連携で値が戻ったり、システム間で内容がずれたりする原因になります。
マスメンのシナリオに変更経路を組み込む
第4部では、マスメンのシナリオを、トリガーイベントから情報確認、判断・決定、マスターへの反映、後続業務へつなげました。
第7部では、その「マスターへの反映」をさらに具体化します。
業務上の出来事によって情報が発生し、担当部門が内容を確定する。その結果をSoTへ反映し、必要なシステムへ連携する。各システムでは、その情報を適用日や対象範囲に従って利用します。
ここまでを一つのシナリオにすることで、値の正しさと変更経路を同時に確認できます。
第5部で扱った切替点も、この流れの中に入ります。11月20日に変更を確定し、12月1日から適用するのであれば、SoTをいつ更新し、いつERPへ連携し、どのトランザクションから新しい情報を使うのかまで確認します。
マスメンでは、正しい値を登録することに加えて、その値がどこから生まれ、どこで確定し、どの経路で利用先へ届くのかを設計します。
この一連の整理を進めることで、SoTはマスターメンテナンスの責任と変更経路を決める実務上の仕組みになります。
次回は、この変更経路を前提に、確認、承認、登録、連携のどこまでを仕組み化できるのかを考えます。
第八部では、ワークフロー、API、イベント連携、MDM、AIなどを使い、これからのマスターメンテナンスをどのように設計するのかを取り上げます。
