,

SaaSタイプのERPをFit to Standard で進めるためのToBeヒアリングとは② システムヒアリングの進め方

前回は、業務ヒアリングを中心に、「なぜヒアリングが重要なのか」を主題として解説しました。今回の第ニ弾では、業務ヒアリングの結果を踏まえつつ、現行システムとの連携や主要マスターの属性などを確認する「システムヒアリング」について扱います。業務を理解した上でシステムの課題を見極め、次フェーズCRP（実機検証）に必要な要件を具体的に整理していきます。

システムヒアリングと他のヒアリングとの関係

システムヒアリングは、基本的に「現場視察 → 業務ヒアリング」の後に行います。この順番を守らないと、業務ヒアリングの結果を踏まえた追加のシステムヒアリングが必要となり、二度手間になるケースが多いからです。

システムヒアリングの目的

システムヒアリングの主な目的は次の通りです。

  1. 現行システムの利用目的や役割の把握
  2. マスターデータおよび管理コード体系の確認
  3. システム間の連携状況・課題の把握
  4. システムにおける制約条件の整理
  5. システム・データ移行方針の策定

事前準備

システムヒアリングを円滑に進めるには、以下の情報をあらかじめ用意してもらうとよいでしょう。

  • 現行システムの用途や概要
  • 現行インターフェース一覧
  • 現行の品目やBOMなど主要マスターのファイル定義書および桁数や属性などのコード定義
  • 受注や発注などのおおよその件数

これらを事前に揃えておけば、実際のヒアリング中に要点を深掘りしやすくなります。

システムヒアリングの順序

業務ヒアリングを終えて、システムヒアリングの準備が終わったら以下の順序で開始します。

  1. 現行システムの業務領域と主要マスターの関係を把握
  2. 主要マスターの属性整理
  3. インターフェース連携：UMLシーケンス図作成
  4. インターフェース一覧表作成

現行システムの業務領域と主要マスターの関係を把握

まずは、対象となるシステムの業務領域と主要マスターを再度確認します。ERP導入プロジェクト開始時点で概要は把握している前提ですが、業務ヒアリングを踏まえ、改めて現行システムが担う業務領域や利用部門、稼働状況、マスターの発生源を確認します。

稼働状況を確認するのは、ERP導入期間中に保守切れを迎えるシステムがあるか、あるいはPLMなど他のシステムが稼働する予定があるかを把握し、システム移行方法やプロジェクトへの影響を見極めるためです。加えて、ERP稼働後に残るシステムと移行対象となるシステムを分け、事業と業務の組み合わせで「To-Beのシステムではどのシステムがどこを担うのか」を明確にしていきます。

なお、一つのシステムに対するヒアリング時間は、目安として1～2時間程度を想定します。

注意点：画面や帳票の細部には立ち入らない

システムヒアリングとはいえ、現行システムの画面レイアウトや帳票を細部まで調べる必要はありません。そうした調査は数ヶ月にも及ぶ膨大な作業になる上、To-Beに向けた価値を得られないことがほとんどだからです。それよりも、「どのデータがどこにあり、どのような流れで更新・参照されるのか」や「システム間で二重に管理しているマスター」を把握することが最優先事項となります。

主要マスターの属性整理

主要マスターの属性整理では、多岐にわたる項目を確認します。主なトピックとしては以下の通りです。これら各マスター属性の確認項目を縦軸に、現行システムを横軸にマトリックスでまとめることで、システムごとの必須項目やコードの再検討項目、システム間のコード相違点などを明らかにできます。

  1. 在庫属性
  2. 品目属性
  3. 顧客属性
  4. 仕入先・外注属性
  5. BOM属性
  6. 工程属性
  7. 勘定科目と管理会計セグメント
  8. 原価構成要素
  9. その他管理コード
  10. トランザクション（需要・供給）の把握
  11. システム概要とインターフェース一覧
  1. 在庫属性
    在庫属性の中でも在庫階層は、ERPシステムのデータモデルによってあらかじめ標準的な定義が設けられていることが多いです。なお、これに反する独自定義を選択してしまうと、後々大幅な設計変更や、場合によってはシステム全体の作り直しが必要になり、取り返しのつかない事態を招くリスクがあります。そのため、在庫階層は「間違いなく押さえておくべき定義」の一つです。
    例えば、マルチカンパニー対応のERPでは、以下のような在庫階層が考えられます。
    • 会社（ホールディングスなど連結単位
    • 事業（法人格）
    • ファシリティ（工場・物流センターなど）
    • 倉庫（建屋や積送在庫および支給品在庫など）ここに主要な在庫品や引当方法、在庫ステータスなどをマッピングしていきます。業務ヒアリングで得た“現場のモノの動き”と“業務上のニーズ”を踏まえて、ERPの基本コンセプトに則りながら設計するのが大切です。
    • 在庫ゾーン（ピッキング単位）
    • 在庫場所（棚番号など）
    • コンテナ（パレットなど容器単位）
  2. 品目属性
    品目属性では、採番ルールや名称・属性といった基本的な設定から見直します。特に、現場では品目コードを基準に識別しているケースが多いので、「品目コードを意味のある形にするのか」「コードに意味を持つのをやめて、品目名称を充実させるのか」を明確に区別し、目的に沿った定義ルールを設定することが重要です。現場で品目コードで判断している場合、品目コードを意味なしにすると品目名称を定義する必要が出てくるからです。それと、品目名称はカタログなどお客様へ提示するものと社内向けに違いがあるかなども確認します。品目名称は業務に則してルールに基づいた定義が求められます。例えば次のような項目を検討します。
    • 版数管理の要否
    • 同意複数コード（別コード）が必要か
    • 基本単位・変換単位
    • 品目タイプ（勘定科目との紐付け）
    • 棚卸評価方法
    • 安全在庫や供給方法
    • 品質や原産国、JAN/EANコード、顧客／仕入先の別名品番など
    • 品目に固有の備考
  3. 顧客属性
    顧客マスターは、一つの顧客に対して複数の役割が結びつく場合が多々あります。また、販売チャネルや地理的分布、配送リードタイムなどの属性をどう管理するかによって、在庫の引当や配送計画にも影響が出ます。グループ会社間で顧客マスターを共有する場合もあるため、セキュリティやデータ整合性の観点でも整理します。
    • 注文顧客（契約先）
    • 納品場所
    • 請求顧客
    • 価格決定顧客
    • 販売統計顧客
    • 帳合先 
    • 出荷倉庫との関係
    • 配送ルート／配送リードタイム
    • 顧客に固有の備考
  4. 仕入先・外注属性
    仕入先も顧客と同様に、一つの仕入先が複数の契約形態を持つことが多いです。また、外注の場合は、支給品の扱いや生産能力の管理といったポイントをシステムの観点からも確認しておきます。
    • 契約先、支払先、購買価格決定の方法
    • 購買単位、発注方法、通貨
    • 受け入れ倉庫との関係
    • 納品ルート／納品リードタイム
    • 原材料・部品以外の一般購買や設備、物流業者などの仕入先タイプ
    • 仕入先に固有の備考
  5. BOM属性
    BOMは、多くの企業で現場視察の情報が役立つパートです。たとえば製造工程や設備との紐付け、工場間での部品受け渡しなどを把握しておくと、実際のBOM階層や工程に対するイメージがつかみやすくなります。このようにイメージした理由と利点を添えることで、理解が深まります。BOM属性は次のような項目をヒアリングでチェックします。
    • 技術単位
    • 払出工程（投入時点の工程）
    • 有効期間（変更管理）
    • 補正リードタイム・不良率
    • 副産物／連産品、代替品 、ファントム品
    • 引落方法
    • BOMに固有の備考
  6. 工程属性
    工程は、「工場 → 部門 → 製造ライン → 作業場 → 設備」のように階層化して整理します。どのレベルでスケジューリングや負荷状況を判断するのかも明確にしておくと、日程計画や生産指示がスムーズになります。
  7. 勘定科目と管理会計セグメント
    財務会計や管理会計における勘定科目の紐付けと、部門や製品ライン別の収益分析・コスト配賦などをどのレベルで行うかも、システムヒアリングで重要となるトピックです。例えば、売上の計上タイミングや原価の配賦ルールなどを部門単位で管理する場合、ERP標準機能でセグメント管理ができるかを確かめたり、勘定科目とセグメントの粒度をそろえたりする必要があります。ここで整合性をとっておくことで、財務諸表と管理会計レポートのズレを極力減らせます。
    • 勘定科目の基本構造（貸借区分・費用科目との関連）
    • 変動費と固定費
    • 管理会計で使うセグメント（部門・製品ライン・地域など）の定義方法
    • どのトランザクションで勘定科目やセグメント情報が更新されるか
    • グローバル勘定科目とローカル勘定科目
  8. 原価構成要素
    原価構成要素の定義では、製品やサービスを提供する上で発生するコストを、どのように分類・集計するかを明確にします。製造業の例としては、以下のような原価要素を挙げることができます。
    • 直接材料費
      製品を作るために必要となる材料や部品の費用
    • 直接人件費（直接労務費）
      製品やサービスの生産に直接かかわる作業者の給与・手当など
    • 製造間接費
      工場設備の保守費、光熱費など、直接的に特定製品へ結びつきにくい費用
    • 販管費（販売管理費）
      営業・管理部門の人件費やオフィスの固定費など
  9. その他管理コードの確認
    その他管理コード定義では、まず既存のコード体系を洗い出しつつ、新しい業務プロセスに則した形で再設計することが重要です。現行運用をそのまま踏襲するのではなく、改善すべき点を見極めた上で、コードの意味や利用シーンを整理し、用途に合わせた定義ルールを設定します。
    例えば、取引条件や物流手段が大幅に変わる場合、コード内容や登録手順も刷新する必要がありますし、新しい業務フローにマッチしない旧コードは統合・廃止を検討しなければなりません。作業者が戸惑わないよう、新コードの適用手順やメンテナンスルールをわかりやすく示しておくことも大切です。最終的には、誰がどのタイミングでコードを参照・更新するのかが明確になり、運用フローの整合性と業務精度を高められる形で設定するのがポイントです。
  10. トランザクション（需要・供給）
    需要トランザクションと供給トランザクションでは、どの種類の取引があるのか、どこからどこへ連携されるのか、さらに発生頻度やサイクルおよびステータス管理を確認します。

    各トランザクションに付随する品質保証データや検査結果など、必須と考えられる情報（Must要件）も洗い出しておきます。例えば、納入品にはロットの品質検査結果や品質保証が必要になります。これらの添付資料はMust要件ですので情報の提供の仕方は変わったとしても無くすことはできないでしょう。これらは次フェーズのCRPで実機検証する際に非常に重要となります。
    • 需要側の例：販売予算、需要予測、顧客内示、確定注文、納入指示
    • 供給側の例：所要量、内示発注、確定発注、製造計画、検査、転送（移動）など

インターフェース連携：UMLシーケンス図の作成

現行システムと主要マスターの属性を把握できたら、UMLシーケンス図を活用して「各システムがいつ、どの順番で、どんなデータを送受信するのか」を可視化します。例えば、下記のような流れをまとめます。

  1. システムAが注文データをシステムBへ送る
  2. システムBは受注処理後、在庫を更新し、納期回答データをシステムAへ返す
  3. 必要であれば、システムBが物流システムCへ出荷指示を送信
  4. 出荷完了後、システムCからシステムBを経てシステムAへASN（事前出荷通知）として配送実績を送る

このようにシーケンス図でタイミングと順番を整理すると、システム間の「データフロー」が一目で把握でき、製造完成前に出荷指示といった設計上の抜け漏れを防ぎやすくなります。

このデータ連携タイミングによる不整合については、以前の記事「プロジェクト立て直しシリーズ　-タイムラグの解消-」をお読みいただけるとUMLシーケンスを用いたインターフェース連携の重要性を深くご理解いただけると思います。

インターフェース一覧表作成

システムヒアリングの最後に、ファイルレベルのインターフェース一覧表を作成することです。移行しないシステムとの連携は、APIによるシームレスな連携かマニュアル運用による疎結合かを仮決めし、システムごとに連携するファイルを確認します。

注意すべきことは、同じ品目コードでもシステムによって異なる場合がある点です。これは品目属性で事前に確認しておかなければなりません。インターフェースで品目コード変換が必要かどうかも合わせて検討します。

さらに、連携ファイルの作成タイミングや連携方法、更新方法（CRUD）、データ量などを把握します。もし更新方法が「洗い替え」だったり、ERPに適さないステータス更新を行う運用がある場合は、課題管理として起票します。サブシステムと緊密に連携するERPにおいて、データの洗い替えはリスクが高いため、早めに対処策を検討しておく必要があります。

これらの項目は一度にすべて把握するのは大変ですが、業務ヒアリングで得た情報を「システムヒアリングボード」などに整理しておくと進めやすくなります。重要なのは、As-IsではなくTo-Beのビジネスデータモデルを基にデータ構造を検討することです。また、データ量やマスター登録のタイミング（メンテナンスのトリガー）も合わせて確認します。、

業務ユーザーを巻き込む

システムヒアリングと聞くとIT部門だけが対象と思われがちですが、システム担当者だけでなく、業務ユーザーも巻き込みながら進めることが大切です。業務とデータのつながりを正しくマッピングするためには、業務の実態をよく知るユーザーの知見が欠かせません。

まとめ

システムヒアリングは、ERP導入における業務面とシステム面を結びつける重要なステップです。在庫や品目、顧客、仕入先などの主要マスターを整理し、それぞれの属性や連携方法を明確にすることで、実運用時のデータの一貫性と信頼性が高まります。また、勘定科目や管理会計セグメントなどの財務・管理会計項目もあわせて確認しておくと、導入後の運用負荷やシステム間で生じる不整合を事前に防ぐことができます。

さらに、インターフェース連携やトランザクション（需要・供給）のフローまでを検討することで、部門間やシステム間の協働がスムーズに進む基盤を整備できます。こうした要件定義を経てはじめて、“Fit to Standard”を意識したERP導入が実現し、標準化・リアルタイム連携を最大限に活用する環境が整うのです。

次回（第三弾）では、これらの業務・システム設計をさらに「ビジネス価値」に直結させるための分析ヒアリングの視点を解説していきます。

※次回記事：2025年2月6日公開予定