ERP知識シリーズ マスメン 第一部：マスターメンテナンスをシナリオで検証していますか
ERP導入では、本稼働までに多くの業務シナリオを作成し、検証を繰り返します。
通常の受注や発注、仕入先から顧客への直送、週次での生産計画、返品、在庫移動、月次締め。プロジェクトによっては、シナリオの数が200から300に及ぶこともあります。
それぞれのシナリオで、誰が何を判断し、ERPへ何を登録し、その結果が次の業務へどうつながるのかを確認していきます。
では、品目、BOM、仕入先、顧客などのマスターメンテナンスについては、どこまでシナリオとして確認しているでしょうか。
今回のシリーズでは、マスターメンテナンス、通称「マスメン」について考えていきます。
CRPで見えにくいマスターメンテナンス
例えばCRPで、受注から出荷、売上までの業務を確認するとします。
シナリオには、「顧客Aから商品Xを100個受注する」と書かれています。このシナリオを実行するために、顧客Aや商品XをERPへ登録します。必要な価格や配送条件なども設定します。
生産シナリオであれば、商品Xと必要なBOMを登録し、生産計画、所要量計算、製造、完成報告までを確認します。
CRPでは、To-BeプロセスやERPの使い方を確認するため、シナリオに必要な数件のマスターを用意すれば検証できます。この進め方自体は自然です。ただし、マスターをシナリオ実行の前提として準備すると、その登録や変更の業務はシナリオの外側に置かれることになります。
顧客Aや商品Xそのものを、実際の業務としてどのように登録するのか。この点は、別途シナリオとして取り上げなければ確認できないのです。
役割を決めることと、実際に流して確認すること
ERP導入では、To-Beプロセスを設計する中で、マスターをどの部門が管理し、誰が何を担当するのかも決めていきます。
例えば新しい顧客との取引を開始する場合、営業が起点となり、経理が取引条件を確認し、物流が配送条件を決める。価格に関する情報も整え、必要なマスターを登録した後、受注できるようにする。
こうした役割分担は、本稼働までに決めます。しかし、役割分担表の上でつながっていることと、実際の業務として最後まで流れることは同じではありません。
例えば、新規顧客登録のシナリオを実際に行うとします。
新しい顧客との取引が決まり、営業担当者が登録に必要な情報を集め始めます。会社名や住所、担当者に加えて、請求先、納入先、取引条件、希望する納期など、後続の業務で必要になる情報を確認しなければなりません。
営業担当者は、情報が揃ったところで経理へ確認を依頼します。経理は取引条件や請求に関する内容を確認しますが、もし支払条件が決まっていなければ、営業へ差し戻すことになります。営業が顧客へ確認し、再び経理へ戻す。そのやり取りを、どのように記録し、どの時点で確認済みとするのかも決めておく必要があります。
経理の確認が終わると、今度は物流が配送条件を確認します。納入先はどこか、配送ルートは既存のものを使えるのか、特殊な梱包や時間指定が必要なのか。営業が把握していなかった条件が、ここで初めて明らかになることもあります。
配送条件が確定した後、価格条件を設定します。価格を決めるために、営業の承認が必要なのか、経理の確認が必要なのか。価格を登録する前に、顧客マスターや品目マスターのどの項目が完成していなければならないのか。登録の順序によっては、価格だけ先に設定できない場合もあります。
すべての情報が揃い、各部門の確認が終わったところで、担当者がERPへ登録します。登録後、営業が受注画面を開き、顧客と商品を指定してみます。そこで初めて、顧客が受注可能な状態になっているか、価格が正しく表示されるか、配送条件が後続処理へ引き継がれるかを確認できます。
実際に動かしてみるとわかること
この一連の流れを実際に動かしてみると、役割分担表だけでは見えなかった問題が現れます。
営業は、どの情報を揃えれば次の部門へ渡せるのか。経理の確認が終わったことを、物流や登録担当者はどのように知るのか。物流は、どの情報を確認すれば配送条件を確定できるのか。複数の部門が登録する場合、どの作業を先に完了させる必要があるのか。登録が完了した後、誰が受注可能な状態になったことを確認するのか。
こうした点は、担当部門を決めただけでは分かりません。実際の顧客を想定し、情報を集め、部門間で受け渡し、ERPへ登録し、最後に受注まで行ってみることで、初めて確認できます。
ERP導入によって、旧システムから部門の役割が変わることもあります。これまで情報システム部門がまとめて登録していたマスターを、ERP導入後は業務部門が直接管理する。あるいは、一つの部門で完結していた業務を、複数部門がそれぞれ責任を持って登録する。
担当部門を決めるだけでは、この新しい役割分担が実務として成立するかまでは分かりません。ここはERP導入におけるチェンジマネジメントの重要な確認対象になります。
システム統合テストでは、移行した全件データを使う
システム統合テストでは、システム全体を本番に近い状態で確認します。そのため、品目、顧客、仕入先、BOMなど、既存の全件データを用意する必要があります。
データ移行では、まずTo-BeプロセスモデルやTo-Beデータモデルを踏まえて現行システムのデータをクレンジングし、Extractする対象を確定していきます。同じ意味を持つデータを統合する。コードや分類を統一する。不整合を修正する。新しいERPへ持ち込む必要のないデータは移行対象から外す。
このように現行データを整えながら対象を確定し、必要なデータを抽出します。その後、新しいERPに合わせてTransformし、Loadし、結果をCheckします。
ここで確認しているのは、既存のマスターを新しいERPへ正しく移行し、そのデータを使ってシステム全体が正しくつながることです。
一方、本稼働後には、移行データに存在しないマスターの登録や、既存マスターの変更が発生します。
新しい顧客との取引が始まる。
新商品が発売される。
新しい仕入先を採用する。
原材料が変更される。
BOMが変更される。
商品が終売になる。
その都度、決められた部門が必要な情報を判断し、登録や変更を行います。
データ移行とマスメンは、どちらもマスターを扱いますが、確認している業務は異なります。データ移行は既存データを新しいERPへ正しく載せ替える活動です。マスメンは、本稼働後に発生する変化に応じて、マスターを登録・変更し、後続業務で使える状態にする活動です。
マスメンを独立したシナリオとして確認する
CRPでは、マスターはトランザクションを実行するための前提として用意されます。システム統合テストでは、データ移行によって既存の全件データが用意されます。
このため、どちらの工程でも、本稼働後に新しいマスターを登録したり、既存のマスターを変更したりする業務は、意識して取り上げなければ見えにくくなります。
「設計した役割分担で、マスターの登録や変更が本当に最後まで流れるのか」
これを確認するには、マスメンそのものを一つの業務シナリオとして扱う必要があります。
例えば新しい顧客との取引開始であれば、取引開始が決まったところから受注可能になるまでを、一つのシナリオとして確認します。
営業が顧客情報を集め、経理が取引条件を確認し、物流が配送条件を確定する。必要な価格を設定し、各部門の確認結果を受けてERPへ登録する。そして最後に、実際の受注処理を行い、登録したマスターが後続業務で正しく使えることを確認します。
この流れを追うことで、ERPの操作だけでなく、部門間の役割、判断、情報の受け渡し、承認、登録順序、有効日の考え方まで検証できます。
200から300ものトランザクションシナリオを作るのであれば、その前提となるマスターについても、登録や変更を一つの業務として確認する必要があります。
では、マスメンのシナリオは、何を起点として作ればよいのでしょうか。
新規登録、参照、変更、利用停止。
これらが発生する背景には、会社の中で起きる何らかの変化があります。
次回は、これまでビジネスプロセスを考える際にも使ってきた「トリガーイベント」の視点から、マスメンの始点を考えます。その上で、CRUDや4Mを使いながら、新規顧客との取引開始、新商品の発売、仕入先や原材料の変更といった業務上の出来事が、どのマスターの登録・変更・利用停止につながるのかを整理していきます。
