JinJin48
JinJin48
SAP Consultant | BTP · S/4HANA · US Global Rollout
· 10 min read

カバー: SAPサービスとは? — S/4HANAサービスモジュール概要

TL;DR
  • SAP S/4HANA Serviceは、CS(カスタマーサービス)の進化版ではなく、完全に再設計されたモジュールであり、独自のビジネスオブジェクト(サービス契約、サービスオーダー、社内修理、保証請求)と新しいサービス組織構造を備えています。
  • 請求処理はSDおよび収益認識(RAR/IFRS 15)とネイティブに統合され、原価配賦はCOを経由してFIに流れ、スペアパーツの調達はMMが担当します。要件定義を開始する前に、これらの統合範囲を理解することが不可欠です。
  • FSM(フィールドサービス管理)は、S/4HANA Serviceに現場派遣とモバイル実行機能を追加するものですが、オプションです。FSMを含めるかどうかは、現場作業員の規模とリアルタイムスケジューリング要件に依存する重要な設計上の判断です。

1) SAP サービスがカバーするもの

SAP S/4HANA サービスの6つの中核機能領域

SAP S/4HANA Serviceは、S/4HANAスイートにおける戦略的なサービス管理モジュールです。初期のサービス契約から実行、確認、請求に至るまで、外部顧客へのサービス提供のライフサイクル全体を管理します。プラントメンテナンス(PM)と同じオブジェクトモデル上に構築された従来のCS(カスタマーサービス)とは異なり、S/4HANA Serviceは独立したビジネスオブジェクトと専用のFioriネイティブユーザーインターフェースを導入しています。

このモジュールは、6つのコア機能領域を対象としています。

サービス契約と定期サービス

サービス契約が定期サービスオーダー生成を促進するフロー

サービス契約とは、サービスプロバイダーと顧客との間で結ばれる長期契約です。対象となるサービスの範囲、保証対象として登録された製品、応答時間やSLAのコミットメント、価格条件、請求計画を定義します。サービス契約は、サービス業務の商業的な基盤として機能し、顧客が何をどのようなコストで受ける権利があるのかを決定します。

契約に関連付けられているのは定期サービス(予防サービスとも呼ばれます)です。契約に定期的なメンテナンス(例:四半期ごとの点検や年次校正)が必要な場合、システムは定義された間隔でサービスオーダーを自動生成します。この間隔は、時間ベース(30日ごと)またはカウンターベース(500運転時間ごと)に設定できます。定期サービスオーダーは契約から作成され、関連する対象オブジェクトと価格設定を継承します。これにより、手動によるスケジューリングが不要になり、定期的な義務に対するSLA準拠が保証されます。

サービスオーダーと是正保全

サービスオーダー(是正保守)フロー:依頼から請求伝票まで

サービスオーダーは、是正(リアクティブ)サービスの主要な実行ドキュメントです。顧客が故障や不具合を報告した際に、サービス作業を計画・記録するために作成されます。サービスオーダーには以下が含まれます:

  • サービス項目: 労務(作業)、資材(スペアパーツ)、費用(出張、外注)
  • サービス契約の参照: 契約が存在する場合、オーダーは適用範囲を確認し、契約価格を適用します
  • サービス確認: 実行後、技術者が実際の作業時間と消費した資材を確認します。これにより請求伝票が作成されます

サービスリクエストから請求までのフローは以下の通りです:

サービス依頼 → サービス注文 → サービス確認 → 請求依頼 → 請求伝票

サービスオーダーは、CO内部指図を介して原価を収集します。実績原価は、確認および請求時に該当するCOオブジェクトに決済され、収益はFIに転記されます。

社内修理

社内修理プロセス:修理オーダーから請求までの6つのステップ

In-House Repair(IHR)は、顧客が故障した機器を修理のためにサービスセンターに返却するシナリオを対象としています。これはフィールドサービスとは異なるビジネスプロセスであり、専用の修理オーダーオブジェクトを使用します。

IHRプロセスは以下のステップに従います:

  1. 顧客が不良品を発送し、サービスセンターが修理オーダーを作成します。
  2. 入庫 (MM):不良品が指定された保管場所に受け入れられます。
  3. 修理実行:技術者が不良品を診断・修理し、作業と部品が確定されます。
  4. 保証チェック:システムが不良が保証対象かどうかを検証します。
  5. 出庫 (MM):修理された品目が顧客に返送されます。
  6. 請求:保証対象外の場合、確定された作業と部品に基づいて請求伝票が作成されます。

IHRは、在庫移動においてMMと、また原価および収益転記においてFI/COと緊密に統合されています。保証対象の修理については、顧客に請求するのではなく、コストは内部で決済されます。

保証請求管理

保証請求プロセス:提出、検証、判定、決済

保証請求管理は、ディーラーやエンドカスタマーから、製品またはサービスの保証範囲内であると主張される欠陥に関する請求を処理します。このプロセスには以下が含まれます:

  • クレーム申請:ディーラーまたは顧客が、不良品および該当する保証を参照して保証クレームを申請します。
  • 保証検証:システムが、保証マスタデータ(有効期間、対象コンポーネント、クレーム限度額)に対してクレームをチェックします。
  • 判定:サービスプロバイダーがクレームを承認、一部承認、または却下します。一部承認は、申請された品目の一部のみが対象となるケースを処理します。
  • 決済:承認されたクレームは、SDクレジットメモ(ディーラーへの払い戻し)または直接のFI転記を通じて財務的に決済されます。却下されたクレームは監査用に文書化されます。

S/4HANA Serviceの保証マスタデータには、保証オブジェクト(マスタ保証)と保証カウンター(時間ベースまたは使用量ベースの制限)が含まれます。登録済み製品には保証割り当てが設定されています。

請求と収益認識

2つの課金モデル:時間・材料ベース vs IFRS 15 RARを適用した固定価格

S/4HANA Serviceは、請求エンジンとしてSD請求を使用し、サービス確認や請求計画からサービス固有の請求伝票が生成されます。以下の2つの主要な請求モデルが適用されます。

  • 時間・材料ベースの請求: 実際の作業時間と消費された材料が確定され、請求依頼が作成され、SD請求伝票(請求書)が顧客に発行されます
  • 固定価格およびマイルストーン請求: 定額月額料金やプロジェクトベースのマイルストーンを伴うサービス契約で一般的です。実際のサービス確定数量とは関係なく、契約の請求計画に基づいて請求が実行されます

IFRS 15 の対象となる企業向けに、S/4HANA Service は Revenue Accounting and Reporting(RAR) と統合されます。RAR は、商業上の請求ビュー(請求書発行時)と収益認識ビュー(履行義務の充足時)を分離します。これは、収益を請求時ではなく契約期間にわたって認識する必要がある複数年にわたるサービス契約において特に重要です。


2) 組織構造

SAP S/4HANA サービスの組織階層:会社コード、サービス組織、サービスチーム

SAP S/4HANA Serviceでは、従来のCSモジュールには存在しなかった新しい組織単位としてサービス組織が導入されています。サービス組織は:

  • 正確に1つの会社コードに割り当てられます(財務転記用)
  • 1つ以上のプラントにリンクされます(在庫からのスペアパーツ調達用)
  • 1つの販売組織にリンクされます(請求および顧客向け価格設定用)

サービス組織内では、サービスチームが技術者やリソースをグループ化します。チームはワークロードの割り当てやスケジューリングに使用され、サービスオーダーやサービスリクエストをチームに割り当て、その後チームが個々のリソースを割り当てます。

**ビジネスパートナー(BP)**は、サービスコンテキストにおける従来の得意先マスタを置き換えます。S/4HANAのセントラル・ビジネスパートナー・アプローチに準拠し、サービスにおけるすべての得意先関係(販売先、請求先、出荷先)は、個別の得意先マスタレコードではなく、BPロールとして表現されます。

登録製品(「個別オブジェクト」とも呼ばれる)は、S/4HANA Service内で管理される技術オブジェクトです。これらは、顧客が所有または運用し、サービス対象として登録された特定の設備インスタンスを表します。登録製品はPM設備とは異なります。PM設備は社内資産を管理するのに対し、登録製品はサービス範囲内にある顧客所有の資産を管理します。

CSからS/4HANAサービスへの移行に関する注意事項: 従来のCSモジュール(ECC時代)では、カスタマーサービスモジュールは、プラントメンテナンス(PM)とトランザクションコード(通知用IW21、サービスオーダー用IW31)やビジネスオブジェクトタイプを共有していました。専用のサービス組織は存在せず、CSオーダーはPMプラントとビジネスエリアの下で管理されていました。S/4HANAサービスはこの依存関係を完全に解消します。サービス組織はサービスの最上位組織単位となり、すべてのサービスオブジェクトはPMの組織階層から独立して動作します。CSからS/4HANAサービスに移行するコンサルタントは、要件定義フェーズにおいて、すべての組織割り当てを再マッピングし、マスタデータ構造を再評価する必要があります。


3) ロール

SAP S/4HANA Service 実装における主要なロール

SAP S/4HANA Service の実装において、以下のロールが関連します。

ロールS/4HANAサービスの責任範囲
サービス管理者サービス契約ポートフォリオの管理、SLA準拠の監視、エスカレーションの承認
サービスコーディネーターサービスオーダーの作成と派遣、リソース/チームの割り当て、未処理オーダーの追跡
サービス技術者サービスオーダーの確認(労務・資材)、障害所見の記録、オーダーのクローズ
バックオフィス請求担当者請求依頼の処理、請求書の作成、請求プラン実行の管理
保証アナリスト保証請求の評価、補償範囲の検証、請求の承認/却下、決済の管理
サービス設定コンサルタントサービス組織、サービス製品、価格条件、請求プランテンプレートの定義

概要

CSレガシーモジュールとSAP S/4HANAサービスの比較 — 主な違い

SAP S/4HANA Serviceは、SAPエコシステムにおけるサービス管理の根本的な再設計を表しています。プラント保全オブジェクトと共有トランザクションコードに基づいて構築された従来のカスタマーサービス(CS)モジュールは、独自の組織構造(サービス組織)、独自のビジネスオブジェクト(サービス契約、サービスオーダー、社内修理オーダー、保証クレーム)、およびネイティブのFioriアプリケーションを備えた、目的特化型のサービスモジュールに置き換えられました。

6つの中核機能領域(サービス契約・定期サービス、サービスオーダー(事後保全)、社内修理、保証クレーム管理、請求・収益認識)は、時間・資材ベースのフィールドサービスから、IFRS 15に基づく収益認識を伴う複雑な複数年契約に至るまで、サービス提供シナリオの全範囲をカバーします。

S/4HANA Service導入における要件定義を進めるコンサルタントやキーユーザーにとって、重要な設計上の判断事項は以下の通りです。

  1. CS か Service か? ブラウンフィールドのS/4HANA移行では、新しいServiceモジュールを採用するか、既存のCSを維持するかの判断を早期に行う必要があります。グリーンフィールド導入では、新しいServiceモジュールをデフォルトとすべきです。
  2. サービス組織の設計: いくつのサービス組織が必要か?それらは会社コード、プラント、販売組織にどのようにマッピングされるか?
  3. FSMの範囲: 現場派遣とモバイル実行は必要か?必要な場合、FSM統合の範囲とS/4HANA Service/FSMの境界を定義する必要があります。
  4. 請求モデル: 時間&材料、固定価格、マイルストーン請求のいずれか?収益認識(RAR)は必要か?
  5. PM統合: 設備マスタデータに関してPMとの共存要件はあるか?

設定を始める前にこれらの次元を理解することが、成功する実装と高額な手戻りの違いを生み出します。

次に読むべきもの

L1) Big Picture

IDCategoryTitle
srv-001OverviewSAP Serviceとは何ですか? 📍

L2-A) Master Data

IDCategoryTitle
srv-a01OverviewSAP サービス基本データ:概要、階層、および関連性
srv-a03-01Master DataSAP サービス品目マスタ
srv-a04-01Master DataSAPスペアパーツマスタ
srv-a03-02Master DataSAP サービス価格決定条件
srv-a05-01Master DataSAP サービス機能場所
srv-a05-02Master DataSAP サービス設備
srv-a05-03Master DataSAP サービス部品表
srv-a06-01Master DataSAP サービス サービス契約テンプレート
srv-a06-02Master DataSAP サービス サービスオーダーテンプレート
srv-a07-01Master DataSAP サービス保証マスタ