よくある質問

1つのプラントは必ず1つの会社コードに属し、OX18で割り当てます。1つの会社コードには複数のプラントを持てます。会社コードは会計単位（貸借対照表・損益計算書）、プラントは在庫評価と物流の単位という役割の違いがあります。
出典：プラントの定義方法：OX10の手順と保管場所（OX09）の作り方を図解

「現場で在庫を分けて数えたい単位」ごとに作ります。原料倉・完成品倉・検品エリア・廃棄置き場のように、棚卸や在庫レポートで区別したい置き場所が目安です。金額評価には影響せず、会計設定を変えずに追加できるため、プラントよりは柔軟に増やせます。
出典：プラントの定義方法：OX10の手順と保管場所（OX09）の作り方を図解

設定側ではOX10→OX18（会社コード）→OX17（購買組織）→OX09（保管場所）の順に整えます。マスタ側では在庫・発注対象の品目にプラントビューを展開し、仕入先と購買情報レコードを整備します。さらに評価クラス・在庫勘定の自動転記、権限ロール、棚卸計画の確認が必要です。
出典：プラントの定義方法：OX10の手順と保管場所（OX09）の作り方を図解

在庫金額（評価額）はプラントで決まります。数量はプラント＋保管場所で管理されます。そのため保管場所を細かく分けても会計上の在庫金額は変わらず、「評価方法を変えたい場合はプラントを分ける」という原則になります。
出典：プラントの定義方法：OX10の手順と保管場所（OX09）の作り方を図解

会社コードは必須ですが、会社（Company）は任意です。単一法人で連結決算をSAP上で行わない場合は、会社を定義しなくてもMM・FIの運用は可能です。ただし、複数会社コードの財務諸表をまとめて見たい場合やグループ決算を行う場合は、会社を定義して束ねます。
出典：会社・会社コードの定義方法：OX15・OX02の設定手順を解説

通貨は転記（会計伝票）が発生した後は原則変更できません。言語や国も、既存マスタ・帳票・テキストとの整合性の面で変更は大きな影響を伴います。「後から直せる」と思わず、導入設計の段階で法人ごとに確定させてください。多通貨対応が必要なら並行通貨（Parallel Currencies）の導入を検討します。
出典：会社・会社コードの定義方法：OX15・OX02の設定手順を解説

OX02は会社コードの「定義」、OX01は購買組織を会社コードに「割り当てる」設定、OX18はプラントを会社コードに割り当てる設定です。SAPの組織設定は「定義（Define）→割当（Assign）」の順で進むため、OX02で定義してからOX01・OX18で紐づけます。
出典：会社・会社コードの定義方法：OX15・OX02の設定手順を解説

会社コードは4桁以内の英数字（先頭に0は不可）で設定します。実務では「日本法人＝1000、中国法人＝2000、米国法人＝3000」のように、法人単位で10の倍数を割り振る例が多いです。番号は伝票やマスタに残るため、将来の増設（買収・新会社）を見越した体系を最初に決めましょう。
出典：会社・会社コードの定義方法：OX15・OX02の設定手順を解説

SPROは設定メニュー（IMG）を開くためのTコードの名前です。現場では「SPRO＝カスタマイズ作業」を指す言葉としても使われます。「IMG＝設定画面の総称」「SPRO＝その画面を開くコマンド」と覚えると混乱しません。Tコード「SPRO」を実行すれば、プロジェクトの選択画面（SAP Reference IMGを含む）が開きます。
出典：IMG（SPRO）入門：SAP MMの設定画面への行き方とメニューパス

学習・調査・単発の確認はSAP Reference IMG、実際の導入作業はプロジェクトIMGがおすすめです。両者のツリー構造は同じですが、プロジェクトIMGは自社プロジェクトで変更する活動だけを絞って表示し、担当者やトランスポート要求（TR）との紐づけができます。本番稼働後の変更管理（誰が・いつ・何を変えたか）を残すうえでも、実装中はプロジェクトIMGを使うのが定石です。
出典：IMG（SPRO）入門：SAP MMの設定画面への行き方とメニューパス

大半は次の3つのどれかです。①別クライアントで業務画面を開いている（設定はクライアント単位で有効）、②トランスポート要求（TR）をリリースしていないため他クライアントへ未移送、③設定自体は正しいが、マスタデータや既存データとの組み合わせで期待どおりに見えない。まず「どのクライアントで設定したか」と「TRの状態」を確認してください。
出典：IMG（SPRO）入門：SAP MMの設定画面への行き方とメニューパス

会社コード・プラント・購買組織などの組織は「Enterprise Structure → Definition／Assignment」、品目タイプ・番号範囲などは「Logistics - General → Material Master」、購買・在庫・請求書照合などの業務設定は「Materials Management」配下です（図2のパス表が早見表になります）。まずは開発クライアントでSPROを開き、Enterprise Structureを展開して眺めるだけでも、導入プロジェクトの流れがつかめます。
出典：IMG（SPRO）入門：SAP MMの設定画面への行き方とメニューパス

会社コードは会計上の単位（自前のBS・PLを持つ）、プラントは操業・在庫評価の単位です。プラントは必ず1つの会社コードに帰属し、1つの会社コードに複数のプラントを持てます。在庫金額はプラント（評価領域）で管理されます。
出典：SAP MMのエンタープライズ構造とは？6つの組織レベル（会社コード・プラント・購買組織）の役割を図解

プラントは在庫金額の評価単位、保管場所はその中で在庫を物理的に区別する単位です。同じプラント内に複数の保管場所（原料倉・完成品倉など）を持てます。保管場所の増設は会計設定に影響しないため比較的柔軟です。
出典：SAP MMのエンタープライズ構造とは？6つの組織レベル（会社コード・プラント・購買組織）の役割を図解

「同じものを大量に買う」共通部品・間接材は集中購買（1つの購買組織）で量を集約し、価格交渉力と標準化を高めます。工場ごとに仕入先や仕様が異なる現場依存品は、会社固有・プラント固有の購買組織で機動的に調達するのが一般的です。
出典：SAP MMのエンタープライズ構造とは？6つの組織レベル（会社コード・プラント・購買組織）の役割を図解

購買組織は仕入先との価格交渉・契約を担う組織単位で、外部の購買取引に法的な責任を持ちます。購買グループはその内部で日々の発注業務を担当するバイヤーのグループです。1つの購買グループを複数の購買組織に割り当てることもできます。
出典：SAP MMのエンタープライズ構造とは？6つの組織レベル（会社コード・プラント・購買組織）の役割を図解

預託在庫は自社敷地内にあっても所有権は仕入先にあります。消費（払出・移動タイプ411）した時点で支払義務が発生し、在庫評価の対象になります。通常在庫は購入時点で所有権が自社に移り、在庫金額に計上されます。
出典：特殊調達・特殊在庫とは？預託・外注・パイプライン・在庫転送の仕組み

通常発注は完成品を購入するだけですが、外注は自社の部品を仕入先に支給して加工してもらい、完成品を受け取ります。発注書（アイテムカテゴリL）に支給部品のリストを含めるのが特徴です。
出典：特殊調達・特殊在庫とは？預託・外注・パイプライン・在庫転送の仕組み

同一企業内で、受入プラントが供給プラントに対して発注する特殊な発注書（タイプU）です。社内取引として在庫転送され、外部の仕入先は登場しません。プラント間の在庫移動を一元管理できます。
出典：特殊調達・特殊在庫とは？預託・外注・パイプライン・在庫転送の仕組み

水道・電力・ガスなど、パイプライン経由で継続供給される品目です。在庫を持たず使用量を定期精算するため、保管コストがかからず棚卸も不要です。
出典：特殊調達・特殊在庫とは？預託・外注・パイプライン・在庫転送の仕組み

顧客・仕入先の番号範囲設定はそのまま引き継げますが、BP関連の設定（BUC2・BUCFでのBP番号範囲、ロール、フィールド属性、アカウントグループ関連付け）はすべて実行し直す必要があります。BPを顧客と同じ番号で作成したい場合は、「BPから顧客／仕入先への番号割当」で同番号を設定します（資料のFAQ・設定パス参照）。
出典：SAP S4HANA BP后台配置及前台操作详解 共61页 2020年编著 PDF版

トランザクションFLBPC1／FLBPD1で顧客・仕入先からBPを作成できます。大量件数はMDS_LOAD_COCKPIT（マスタデータ同期ロードコックピット）で一括変換するのが効率的です。変換前に番号範囲の3者一致・外部採番を済ませておくことが成功の前提です。
出典：SAP S4HANA BP后台配置及前台操作详解 共61页 2020年编著 PDF版

使えません。S/4HANAでは顧客・仕入先マスタの作成・変更・表示はすべてトランザクションコードBPで行います（資料では非対応Tコードとして10種類以上のグループが列挙されています）。運用マニュアルと教育をBP操作に切り替えましょう。
出典：SAP S4HANA BP后台配置及前台操作详解 共61页 2020年编著 PDF版

システム上は「同じにするのが推奨・強制ではない」とされています。ただし実務では3者を一致させて運用するのが標準で、一致させるには番号範囲の3者一致＋外部採番＋「同番号」設定が必要です。一致していないとBPからマスタを作成するたびに番号を手入力する運用になり、ミスの温床になります。
出典：SAP S4HANA BP后台配置及前台操作详解 共61页 2020年编著 PDF版

入荷（Goods Receipt）と請求（Invoice Receipt）のタイミングのズレを一時的に調整する勘定科目です。品物が先に届いた時点では在庫を増やしてGR/IR勘定を立て、請求書が届いた時点でGR/IR勘定を消して買掛金を計上します。
出典：SAP MMのGR/IR勘定とは？発注・入荷・請求の「ズレ」を解消する仕組みを図解アニメーションで解説

GRは入荷・入庫（Goods Receipt）、IRは請求書受領（Invoice Receipt）です。GRで在庫とGR/IR勘定が発生し、IRでGR/IR勘定の消込と買掛金の計上が発生します。この2つを別々に記録するのが、SAPの設計上の特徴です。
出典：SAP MMのGR/IR勘定とは？発注・入荷・請求の「ズレ」を解消する仕組みを図解アニメーションで解説

3ウェイマッチ（発注数量・入庫数量・請求数量と単価の突き合わせ）で、どの明細が食い違っているかを特定します。数量差異・単価差異に分類し、受入超過は承認を得て請求書を修正するなど、会社の業務ルールに沿って対応します。
出典：SAP MMのGR/IR勘定とは？発注・入荷・請求の「ズレ」を解消する仕組みを図解アニメーションで解説

GR/IR勘定に残った残高は「未着品（IR待ち）」「未請求（GR待ち）」のサインです。滞留を放置すると在庫・原価・買掛金のいずれかに不整合が残るため、MB5SやMRBRで定期的に確認し、原因（納品書未処理・請求遅延など）をプロセス側で解消します。
出典：SAP MMのGR/IR勘定とは？発注・入荷・請求の「ズレ」を解消する仕組みを図解アニメーションで解説

ME53Nは購買依頼（PR）を照会・確認するトランザクション、ME9Fは発注書（PO）の出力メッセージを一覧処理して印刷・送信するトランザクションです。PRをまとめて出力したい場合はME9Aを使います。
出典：SAPの購買依頼・発注書の印刷をME53NとME9Fで解決：出力メッセージ・スプール・再出力まで解説

出力メッセージ未送信のみにチェックが入っている場合は、対象がすべて送信済みの可能性があります。チェックを外すか、出力タイプ・発注日の条件を広げて再実行してください。
出典：SAPの購買依頼・発注書の印刷をME53NとME9Fで解決：出力メッセージ・スプール・再出力まで解説

ME9Fで出力したスプール要求をSP01で開き、プレビューからPDFとして保存するか、プリンタ定義にPDFプリンタ（例：PDF出力用デバイス）を設定して出力します。
出典：SAPの購買依頼・発注書の印刷をME53NとME9Fで解決：出力メッセージ・スプール・再出力まで解説

SP01で該当スプールを選んで再印刷するのが基本です。スプールが残っていない場合は、ME9Fの一覧で該当行を選択し［再出力］で出力メッセージを再生成します。
出典：SAPの購買依頼・発注書の印刷をME53NとME9Fで解決：出力メッセージ・スプール・再出力まで解説

まずME53Nで購買依頼の照会に慣れ、次にME9Fで「出力メッセージ未送信のみ」の条件で実行してみるのがおすすめです。変式（バリアント）を保存すると毎日の運用が格段に楽になります。
出典：SAPの購買依頼・発注書の印刷をME53NとME9Fで解決：出力メッセージ・スプール・再出力まで解説

MMは社外から「買う」調達・在庫管理を、SDは社外へ「売る」受注・出荷・請求を担当します。同じ在庫マスタ・在庫数量を参照し合うため、在庫引当や払出のタイミングで両モジュールが連携します。
出典：SAP MMとは？購買から入庫・支払までのProcure-to-Payプロセスを解説

仕入価格が変動しやすい原材料は移動平均価格、生産計画の原価管理を重視する完成品や半製品は標準価格を使う企業が多いです。どちらも品目マスタの会計ビューで設定します。
出典：SAP MMとは？購買から入庫・支払までのProcure-to-Payプロセスを解説

発注（Purchase Order）・入庫（Goods Receipt）・請求書（Invoice）の3つのデータを突き合わせて、数量と金額が一致しているかを確認する仕組みです。差異があると請求書がブロックされ、支払前に確認が入ります。
出典：SAP MMとは？購買から入庫・支払までのProcure-to-Payプロセスを解説

まずはME51N（購買依頼）からME21N（発注）、MIGO（入庫）、MIRO（請求書照合）までを実際に流してみて、3点照合でどう数量・金額がチェックされるかを体感するのが近道です。次に品目マスタの評価クラス・価格決定方式を追うと理解が深まります。
出典：SAP MMとは？購買から入庫・支払までのProcure-to-Payプロセスを解説

SDは受注から出荷・請求までの「売る」プロセスを、MMは購買から入庫・在庫管理までの「買う・保管する」プロセスを担当します。出荷時の在庫引当や生産部品の払出など、両モジュールは在庫データを介して密接に連携します。
出典：SAP SDとは？受注から出荷・請求までの販売プロセスを解説

「プライシング手続き（Pricing Procedure）」に条件タイプ（基本価格・割引・税など）が順序付けて登録されており、各条件タイプは「条件テーブル」と「アクセスシーケンス」にもとづいて、得意先・品目・数量などの条件でマスタから値を取得します。
出典：SAP SDとは？受注から出荷・請求までの販売プロセスを解説

得意先ごとに設定した与信枠（信用限度額）を、未決済の受注・請求残高が超えないかをチェックする仕組みです。FD32で与信枠を設定し、超過すると受注がブロックされ、承認者の解除待ちになります。
出典：SAP SDとは？受注から出荷・請求までの販売プロセスを解説

まずはVA01（受注作成）からVL01N（出荷）、VF01（請求）までを実際にシステム上で流してみて、コピー統制でデータがどう引き継がれるかを体感するのが近道です。次にプライシング手続きと与信管理の設定を追うと、応用が利くようになります。
出典：SAP SDとは？受注から出荷・請求までの販売プロセスを解説

SAP Business Suite 7（ECC 6.0 など）の通常保守が2027年末で終了し、以降は有償の延長保守が2030年末まで提供される予定であることから、期限までの移行判断を迫られる問題を指します。期限は2段階で捉えるのが実務的です。
出典：S/4HANA 2027年問題とは？保守期限までの逆算ロードマップ

アドオンが少なく現行業務を維持したい場合はシステムコンバージョン型、業務プロセスを見直したい場合やアドオンが多い場合は新規導入型が候補になります。判断軸はアドオン量・標準適合度・変革の許容度の3点です。
出典：S/4HANA 2027年問題とは？保守期限までの逆算ロードマップ

延長保守は有償であり、単純な先延ばしはコスト増になります。移行期間を確保するための計画的利用や、段階移行の受け皿として設計する使い方が現実的です。
出典：S/4HANA 2027年問題とは？保守期限までの逆算ロードマップ

現行システムの棚卸し（アドオン・帳票・インターフェース・利用頻度）です。ここで「廃止できるもの」を確定できると、その後の移行範囲・工数・テスト計画が具体的になります。
出典：S/4HANA 2027年問題とは？保守期限までの逆算ロードマップ

記録はできますが、優先度・SLA・構成情報（CMDB）・変更承認が連動しないため、重大障害の判断や影響範囲の特定が属人的になります。運用の再現性が必要になった段階が導入の目安です。
出典：ServiceNowとは？ITSM導入で何が変わるかを図解で整理

ITSM の基本プロセス（インシデント・要求・変更・ナレッジ）を1部門で運用開始するまでに数か月、全社展開と CMDB 整備を含めると半年〜1年以上を見込みます。範囲の切り方で大きく変わります。
出典：ServiceNowとは？ITSM導入で何が変わるかを図解で整理

多くの場合、ITSM（特にインシデントとサービス要求）から始めるのが効果的です。利用者との接点が多く効果が見えやすく、CMDB や ITOM の整備はその後段階的に進められます。
出典：ServiceNowとは？ITSM導入で何が変わるかを図解で整理

カテゴリ追加・フロー修正・レポート整備を継続するため、プラットフォーム管理者とプロセスオーナーの設置を推奨します。特にプロセスオーナー（運用責任者）が不在だと、設計が現場の実態と乖離します。
出典：ServiceNowとは？ITSM導入で何が変わるかを図解で整理

ITSM は「利用者からの依頼や障害にどう対応するか」というプロセスを扱い、ITOM は「監視・検知・自動復旧」といった運用そのものを扱います。ITSM で窓口とルールを整え、ITOM で検知と自動化を強化する順序が現実的です。
出典：ServiceNowとは？ITSM導入で何が変わるかを図解で整理

影響を受けるシステム、利用者数、業務停止時間、財務影響などの数値で定義します。あわせて、宣言者・連絡先・更新頻度・収束後の振り返り実施条件まで決めておくことで、初動が属人的にならなくなります。
出典：ServiceNow運用設計：インシデント→問題→変更の流れを作る

いいえ。同一原因の再発、重大障害、ベンダー対応が必要な事象など、昇格条件を決めて該当するものだけを問題として管理します。すべてを問題化すると管理不能になります。
出典：ServiceNow運用設計：インシデント→問題→変更の流れを作る

定型度の高い作業を標準変更として事前承認し、承認フローから外すのが有効です。また承認に必要な情報（影響範囲・ロールバック手順・検証方法）をテンプレート化すると、判断が速くなります。
出典：ServiceNow運用設計：インシデント→問題→変更の流れを作る

復旧時間（MTTR）と緊急変更の比率の2つから始めることを推奨します。前者は対応力、後者は統制の効き具合を示し、どちらも改善テーマが具体的に見つかります。
出典：ServiceNow運用設計：インシデント→問題→変更の流れを作る

重大障害（影響度の高い停止）は必ず発生後 1 週間以内に行い、それ以外は月次にまとめて振り返るのが現実的です。重要なのは頻度より、振り返りで決めた改善策を変更として起票し、実施まで追跡することです。
出典：ServiceNow運用設計：インシデント→問題→変更の流れを作る

インシデントは「サービスが止まっている・品質が落ちている」状態への対応、サービス要求は「標準的な作業（アカウント追加等）の依頼」です。優先度の付け方が異なるため、カテゴリを分けて別のフローで処理します。
出典：ServiceNow運用設計：インシデント→問題→変更の流れを作る

影響の大きい基幹系（SAP、認証基盤、ネットワーク）と、その上の業務サービスから始めることを推奨します。全資産を一括で登録する進め方は、更新が追いつかず形骸化しがちです。
出典：ServiceNow CMDBとSAP連携：構成管理を起点にした運用高度化

自動検出（Discovery 等）を「正」とし、人手管理は業務サービス定義と例外に限定します。あわせて重複・未更新・孤立 CI の件数を月次で確認する運用を入れると維持できます。
出典：ServiceNow CMDBとSAP連携：構成管理を起点にした運用高度化

障害や変更の影響を「業務の言葉」で説明できるようになります。たとえば「このサーバ停止で受注登録が止まる」と即座に判断でき、連絡先・影響範囲・過去の類似障害を同じ画面で確認できます。
出典：ServiceNow CMDBとSAP連携：構成管理を起点にした運用高度化

機能自体は早期に使えますが、効果はデータ品質に依存します。まずインシデント要約やナレッジ候補提示から始め、カテゴリ・CMDB・解決記録が整ってから判断の自動化へ進む段階設計を推奨します。
出典：ServiceNow CMDBとSAP連携：構成管理を起点にした運用高度化

作業の指示が明確で時間管理が必要な案件は派遣、業務の進め方ごと委ねる案件は準委任（SES）、明確な成果物を求める場合は請負が適します。単価ではなく、業務の性質と責任の所在で選んでください。
出典：SESと派遣の違い：契約形態・指揮命令・向く案件を整理

準委任では指揮命令権は受託元にあります。発注者は業務の目的・要件を示し、進め方の判断は受託元が行う形にします。実態として直接指示が常態化すると偽装請負と判断される可能性があります。
出典：SESと派遣の違い：契約形態・指揮命令・向く案件を整理

契約が準委任・請負でも、発注者が受託元のエンジニアへ直接業務指示を行い、勤怠や配置を管理し、受託元に業務遂行としての実体（指揮・検収・責任）がない場合です。指示系統と管理体制の両面で判断されます。
出典：SESと派遣の違い：契約形態・指揮命令・向く案件を整理

派遣は労働時間に対する精算として精算幅を設定することが一般的です。準委任では業務遂行の対価として月額・精算幅を定める運用が多く、請負では成果単位の対価となるため精算幅という考え方は用いません。
出典：SESと派遣の違い：契約形態・指揮命令・向く案件を整理

案件の性質によります。作業範囲を特定して指示する定型業務は派遣、設計や進め方ごと任せる開発・運用案件は準委任（SES）が選ばれる傾向があります。単価ではなく業務の性質で判断するのが基本です。
出典：SESと派遣の違い：契約形態・指揮命令・向く案件を整理