SaaS ERPの導入をFit to Standard に導くビジネスデータモデル構築とは【前編】
これまで、SaaSタイプのERPを「Fit to Standard」で導入するうえで、To-Beビジネスプロセスをしっかりと検証することの大切さをお伝えしてきました。本稿では、そのプロセスを流れるビジネスデータに焦点を当て、どのようにデータモデルを構築すれば良いのかを解説します。
さらに後編では、ERPのデータモデル構築に密接に関係するPLM（Product Lifecycle Management）などの設計システムにおけるE-BOM（設計BOM）からM-BOM（製造BOM）への橋渡しや、試作段階の購買や原価管理への影響など、より踏み込んだトピックを扱います。まずは前編でビジネスデータモデル構築の基本的な考え方を押さえていただき、後編へと進んでください。
現場視察とTo-Beビジネスデータモデル
先ず、ビジネスデータモデルの構築に取りかかる前に、現場視察を通じてモノの流れや在庫管理の実態を把握しておきます。例えば、BOM（部品構成表）を設計する際、以下のようなポイントを現場で確認します。
- 設備の特性：
バッチ単位やチップマウンターの多面取りや両面取り、釜熱処理の多製品製造、プレスでの（ドア部品などの）左右取り、塗装前後、計量前後、解凍前後など - 人の作業形態の特性：
多能工・多台持ち - 在庫の扱い：
ストック在庫かフロー在庫か、どの工程で材料を投入するのか - 複数工場の連携：
工場を跨いだ生産能力や外注先との関係、それらが技術的に必要なのか、単に商流・契約形態によるものか
こうした現場視察で得た生な情報をもとに、実態に即したTo-BeのBOMを構築していきます。
To-Beデータモデル構築の注意点
現行システムのマスターメンテナンス画面などを事前に詳細に調べることはお勧めしません。先に確認してしまうと、ユーザーから「現行システムの項目を踏襲したい」という要望が出た際に、それを受け入れやすくなってしまうからです。さらに、この作業にかけた工数がサンクコストバイアスとなり、後の判断を縛る可能性があります。例えば、現場視察で違和感を覚えても、「ここまで話し合ったし…」とTo-Beモデルへの切り替えをためらってしまうことが考えられます。
理想的な進め方は、「現場視察 → To-Beデータモデルの構築 → 必要に応じて現行要素を検討」 というステップを踏むことです。
データモデル構築における制約条件と改善点の分類
現場で得た情報を整理する際、以下の２つに分けて考えると、To-Beモデルの骨格が明確になります。
- 制約条件（システム・設備・材料など）
例：釜やミキサーのバッチサイズ、熟成や解凍／冷却などの時間制約、開封後の消費期限、検査のタイミングなど - 改善すべき事項（現行の煩雑さ・非効率など）
不要に細かい品目コード、現場作業に適さない品目名称、まとめ生産によるストック在庫
、階層が深すぎるBOM（例：製造スケジューラーと連携していて品目番号を工程ごとに採番している）、製造工程とミスマッチなフラット型BOM
これらの情報を踏まえ、SaaS ERPのビジネスデータモデルのコンセプトに合わせて、主要マスター（品目、BOM、工程など）を再編します。
BOM再編の一例
- フロー在庫は品目番号を取らず、ストックになる工程で初めて品目番号を付与する
- 一つの工程から複数製品が出る場合は、メイン品目をトップにして連産品として扱う
このように再編することで、現行システムの“後付けのルール”にとらわれず、最適な構造を描けるようになります。
トリガーイベントアプローチで見極めるトランザクションデータ
次に、主要マスター（顧客、仕入先など）とトランザクション（受注、購買、製造指示など）をTo-Beデータモデルをベースに再編します。
受注や購買などのトランザクションデータの用途決定には、トリガーイベントアプローチが有効です。例えば販売オーダーの場合、以下のイベント起点（CRUDのCreate/Read/Update/Delete）を想定しながら必要項目を洗い出していきます。
- 外部イベント：顧客が注文を出すタイミング（Create）
顧客が新規注文を出すタイミングで何が必要か?→顧客固有フィールドの特定 - 納期確認（Read）
顧客からの納期問い合わせのキーは？→問い合わせの検索キー（顧客注番など）の確認 - 納期変更リクエスト（Update）
いつまで変更可能か？ 出荷指示後は不可か？→ステータスの制御や納期変更履歴の必要性 - 分納や数量変更（Update）
「2ケースだけ翌週納品」のように部分的な変更がある場合、どう扱うか？→分納ラインの必要性 - 受注キャンセル（Delete）
どのステータスまでキャンセルを受け付けるか？→顧客返品との区分けやキャンセル日およびその理由区分の確認
トリガーイベントにおけるCRUDを整理しておくことで、実機検証の際に「どのシナリオで何のフィールドが使われるのか」を把握しやすくなり、より実践的な運用検証を可能にします。
トランザクションデータのステータスとBPR
トランザクションデータが決まれば、自ずとその進度を表すステータスが決まります。このステータスはビジネスプロセスを表すので、To-Beのビジネスプロセスモデルが仮決めできるようになります。
例えば、輸入品の購買オーダーであれば、輸出元工場の出荷、荷積、納期回答、輸入国の船下ろし、乙仲倉庫入庫、入荷検査、納品、請求受領、支払、といったステータスの遷移で業務が進みます。これを実業務の進度管理と照らし合わせれば、どのステータスで実績を報告できるか（あるいはしなければならないか）によって、業務改善（BPR）すべきポイントを洗い出せます。
取引パターンの網羅性とマスターの照合
トリガーイベントで変更パターンを洗い出せたら、次に業務ヒアリングでまとめた取引パターンの網羅性を検討します。例えば、
- 通常はデポから顧客の部品倉庫へ納品する
- 場合によっては顧客の生産ラインへ直接納品する
このような例外パターンを含め、From→Toの組み合わせをすべて列挙し、顧客マスターや仕入先マスターに関連するオーダータイプ（詳しくは：ERP知識シリーズ オーダーステータスの理解参照）と照合します。この作業によって、現行システムの項目に左右されないTo-Beベースのマスターデータ設計を行うのです。
外部システムとの連携におけるデータモデルの留意点
ERP導入では、PLM、生産スケジューラー、MES、WMS、CRMなどの外部システムとの連携を考慮する必要が出てきます。データモデルを検討する上では、主に以下の点に着目します。
- コード体系やマッピングルールの整合：
PLMが独自の設計コードや改訂番号、WMSが別管理している品目番号など、どのように相互変換するかを明確にする。 - トリガーイベントの共有：
外部システムが在庫引当や製造指示を行うトリガーをERPへ即時に連携するのか、バッチ処理なのか。リアルタイム化が可能ならば、イベントを外部システムと統一する。 - データ形式や更新サイクル：
どのデータ形式を用いるのか、どの程度の頻度で連携を行うのかを事前に検討する。必要に応じて、定期的なバッチ処理やリアルタイム連携など、さまざまな方式を組み合わせることが考えられる。 - 制約条件の優先順位：
外部システムにも独自の制約（PLM側の改訂ポリシーや、MESの能力計画など）がある。事前に両者の制約条件を整理してからTo-Beモデルに反映する。 - 試作段階のコード管理：
PLMとERPが別々のコードスキームで試作部品を扱う場合、それが量産フェーズへ移行するタイミングをどう切り替えるのか（または統合管理するのか）を決めておく。
このように、ERPと外部システムがデータ連携する際にも、トリガーイベントアプローチや取引パターンの網羅、そして制約条件の整理が活用できます。設計システム（PLM）からの改訂情報をERPに反映する際は、E-BOMからM-BOMへの変換時点でイベントを起こす、といったフロー設計をあらかじめ検討しておく必要があります。
実機検証前のヒアリング段階でほぼ構築可能
ここまで紹介してきたように、品目マスター・BOM・受注データ・顧客マスターなど主要なビジネスデータのモデリングは、現場視察やトリガーイベント＋取引パターンの洗い出しによって、実機検証に入る前のヒアリング段階でもかなりのところまで固めることができます。
実データを用いた実機検証
To-Beデータモデルが確定したら、次に実データを用いた実機検証を行い、To-Beビジネスプロセスを確認します。実データを使うことで、これまで整理した取引パターンに抜け漏れがないかを検証し、検証結果を通じて不足箇所を明確にします。こうして、網羅性を確保しながら検証を進めます。
ここでも言えることは、To-Beデータモデルを構築する前に実データの調査を始めないことです。先に現場視察や取引パターンの調査を行い、それに基づいてTo-Beデータモデルをコンフィグレーションする方が、実データの調査に時間をかけるよりもはるかに効率的です。
まとめ
SaaS ERPをFit to Standard で導入する際に、ビジネスデータモデルを正しく構築するうえで重要なステップは以下の通りです。
- 現場視察でリアルを把握する
- To-Beのモデルコンセプトを先行させる
- トリガーイベントアプローチと取引パターン網羅で抜け漏れをなくす
- 外部システムとの連携を踏まえて、ビジネスデータモデルを構築する
次回予告：PLMとの連携や試作段階の原価管理へ
ここまで、SaaS ERP導入時のビジネスデータモデル構築の基本を中心に解説しました。後編では、以下のような内容をさらに深掘りしていきます。
- PLM（Product Lifecycle Management）との連携：E-BOMとM-BOMの橋渡し
- 試作段階の購買オーダーや見積原価の扱い
- 外部システムとのデータ連携で気をつけるポイント
- 実機検証前の段階でビジネスモデルを固める方法
「設計システムとERPをどうスムーズに結合し、試作から量産までのデータを一元管理するか？」が後編のテーマです。ぜひ続けてお読みください。
