SAP

SAP Business Workflow 基礎:ワークアイテム、承認、代理人、エスカレーションの運用

SAP Business Workflowの基本構造を、ワークフロー定義、ワークアイテム、エージェント決定、承認処理、代理人、期限監視、エラー調査の観点から実務向けに整理します。

SAP Business Workflowの実行フローイベントが担当者へのワークアイテムとなり、完了へ進む流れを示すSAP Business Workflowの実行フローイベントが担当者へのワークアイテムとなり、完了へ進む流れを示す開始評価割当処理業務イベント文書登録や業務変更が処理…ワークフロー定義ステップ、条件、タスク、…担当者決定担当ユーザーや組織単位を…ワークアイテム担当者が処理する作業を生…結果と次のステップ承認、却下、差戻し、エス…CertPas オリジナル図解
業務イベントからワークフロー定義、担当者決定、ワークアイテム処理、完了までの流れ
目次
  1. SAP Business Workflowの基本構造
  2. ワークアイテムと承認処理の流れ
  3. 担当者決定と代理人の設計
  4. 期限管理とエスカレーション
  5. ワークフロー定義の確認方法
  6. 滞留やエラーの切り分け
  7. 運用チェックリスト

SAP Business Workflowは、SAP ERPやSAP S/4HANA上で発生する業務イベントを起点に、承認や確認などの作業を担当者へ割り当て、処理結果に応じて次のステップへ進める仕組みです。購買依頼、請求書、マスターデータ変更など、担当者の判断を含む業務を一定のルールで運用できます。

この記事では、設計者だけでなく運用担当者が確認すべき単位に分けて、ワークアイテムの状態、担当者決定、期限管理、障害調査の流れを説明します。SAP Concurの承認機能とは対象システムと管理方法が異なるため、ERP内のBusiness Workflowとして整理することが重要です。

SAP Business Workflowの基本構造

ワークフローは、業務イベント、処理ステップ、担当者、分岐条件、完了条件の組み合わせで構成されます。たとえば購買依頼が登録されると開始イベントが発生し、金額や組織などの条件から承認者が決まり、承認用のワークアイテムが作成されます。

代表的な構成要素は次のとおりです。

  • イベント:業務オブジェクトの登録や変更を起点にする
  • ワークフロー定義:処理順序、分岐、待機、完了条件を定義する
  • タスク:承認、確認、通知、バックグラウンド処理など、実行する作業を表す
  • エージェント:タスクを実行できる担当者、職位、組織単位などを表す
  • ワークアイテム:実行中の具体的な処理単位を表す
  • コンテナ:伝票番号、金額、組織など、処理中に受け渡すデータを保持する

ワークフロー定義が設計図であるのに対し、ワークアイテムは実際の業務データに対して生成される実行単位です。この違いを分けて確認すると、設計上の問題と個別案件の滞留を切り分けやすくなります。

ワークアイテムのトラブルシューティング手順ワークフローが進まないときの主要な確認点を示すワークアイテムのトラブルシューティング手順ワークフローが進まないときの主要な確認点を示す最初に起動済みなら割当済みなら表示済みなら診断後ワークフローが進まない定義を変更する前に症状を…開始イベントを確認業務イベントと実行インス…担当者決定を確認入力値、ルール、組織情報…ワークアイテム表示を確認割り当てと受信箱の表示条…実行処理と通知を確認バックグラウンド処理、エ…再処理またはエスカレー…ワークアイテムIDを記録…CertPas オリジナル図解
滞留したワークフローを開始イベント、担当者、ワークアイテム表示、実行処理の順に調査し、復旧する流れ

ワークアイテムと承認処理の流れ

利用者が確認するのは、多くの場合、受信したワークアイテムです。SAP GUIではSBWPなどから自分に割り当てられた作業を確認し、対象文書を開いて承認、却下、差戻し、転送などの操作を行います。利用可能な操作はタスク定義と業務ルールによって決まります。

一般的な処理の流れは次のようになります。

  1. 業務トランザクションで文書や申請が登録される
  2. 開始イベントがワークフローを起動する
  3. 条件に基づいて担当者が決定される
  4. 担当者向けのワークアイテムが作成される
  5. 担当者が処理し、結果がワークフローへ返される
  6. 次のステップ、完了、差戻し、例外処理へ進む

ワークアイテムが受信箱に表示されない場合は、最初に起動の有無、担当者決定、ユーザーへの割り当てを順番に確認します。業務文書が登録されていても、イベント連携が発生していなければワークフローは開始されません。

ワークフロー全体の進捗確認には、対象の文書番号、作成日時、開始ユーザー、ワークフロータイプ、現在のステップを揃えます。個別の実行状況を調べる際は、SWI1などのワークアイテム検索を使い、処理済み、実行中、エラー、論理削除などの状態を分けて確認します。

トランザクションの入口を整理したい場合は、SAPトランザクションコード一覧も参照できます。業務トランザクション、ワークフロー管理、運用監視の役割を分けて記録すると、調査担当者への引き継ぎが容易になります。

担当者決定と代理人の設計

担当者決定は、ワークフロー運用の安定性を左右する部分です。固定ユーザーを直接指定する方法に加え、組織単位、職位、ポジション、ルール、責任範囲などを使って担当者を求める設計があります。組織変更や異動が多い業務では、個人名を直接埋め込むより、管理対象となる組織情報とルールを連携させる方が保守しやすくなります。

担当者決定を確認するときは、次の情報を同じ時点の状態で照合します。

  • 申請または伝票に入っている会社コード、購買組織、販売組織などの値
  • 条件分岐で参照される金額、カテゴリ、承認区分
  • ルールが参照する組織、ポジション、担当者属性
  • 対象ユーザーの有効期間と割り当てられた権限
  • 代理人設定の有効期間と対象ワークアイテム

休暇や異動に備える代理人設定では、代理の対象範囲、開始日時、終了日時、承認権限の扱いを明確にします。代理人が設定されていても、すでに生成されたワークアイテムが自動的に移動するとは限らないため、既存アイテムへの適用結果を確認します。

ユーザーのロック、期限切れ、割り当て不足などがあると、担当者決定が成立しても実行者が処理できないことがあります。ユーザー管理の確認が必要な場合は、SAPユーザー管理とSU01の基本を関連資料として利用できます。承認者側の権限設計を見直す場合は、SAP権限ロール設計の基本も参照できます。

期限管理とエスカレーション

承認期限を運用する場合は、期限の起点、期限値、休日カレンダー、通知先、期限超過後のアクションを定義します。期限到来時の処理には、通知、担当者変更、上位者へのエスカレーション、別経路への分岐、例外処理などがあります。

期限監視では、次の時刻を区別します。

  • ワークフローが開始された時刻
  • ワークアイテムが担当者へ割り当てられた時刻
  • 担当者が処理を開始した時刻
  • 期限が計算された時刻
  • 期限監視が実行された時刻
  • エスカレーションが実行された時刻

期限超過は自動的に上位者へ再割当されるわけではありません。期限監視は、レポートRSWWDHEXがSWU3で設定・監視される定期バックグラウンドジョブとして実行され、期限値を評価してワークフロー定義で指定された分岐(通知のみ、エスカレーション分岐、または何もしない)を実行する仕組みです。「エスカレーション」はワークフロー定義上の分岐であり、担当者の自動的な付け替えではありません。分岐処理自体は、対象のワークアイテムを完了・キャンセル・再割当しません。ワークフロー定義側で転送・完了・キャンセルなどの後続処理を明示的にモデル化していない限り、元のワークアイテムはそのまま滞留し続けます。通知のみの設計であれば、受信者が手動で対応・転送する必要が残ります。また、次の3層を区別して確認します。タスク定義上一般的に実行を許可されている「possible agent」、その特定のワークアイテムについて実際に責任を持つと解決された「responsible agent」(複数になる場合もあります)、そして実際にそのワークアイテムを開いて処理した「actual agent」です。possible agentに通知しても、そのワークアイテムのresponsible agentに含まれていなければ状況は解決しません。ワークアイテムが期限を超えているのに通知されない場合は、期限値だけでなく、この定期ジョブが実行されているか、通知先が解決できているか、メール送信基盤が稼働しているかを確認します。定期実行処理の停止や遅延があると、ワークフロー定義が正しくてもエスカレーションは進みません。

期限設計では、承認者が不在のときの経路も決めておきます。代理人、上位組織、業務管理者のどこへ送るかを明文化し、通常処理と例外処理の両方をテストします。

ワークフロー定義の確認方法

ワークフロー定義を確認するときは、最初に対象のワークフロータイプとバージョンを特定します。SWDDでは、開始イベント、ステップ、分岐、タスク、コンテナ、終了条件を確認できます。変更を加える前に、現在本番で使用されている定義、関連するタスク、移送対象を記録します。

実行中のワークフローに対して定義を変更すると、すでに生成されたワークアイテムの挙動と、変更後に新規起動されるワークフローの挙動が分かれることがあります。テストでは、新規起動、承認、却下、差戻し、担当者不在、期限超過、例外終了を一通り確認します。

定義確認のチェック項目は次のとおりです。

  • 開始イベントが想定する業務オブジェクトとキー
  • イベントとワークフロー定義の連携状態
  • 条件分岐で使用するコンテナ値
  • 各タスクの実行者決定方法
  • 承認結果を次のステップへ渡すマッピング
  • エラー時の終了処理と通知先
  • バックグラウンド処理を実行するユーザーの権限

設計変更は、開発環境での単体テスト、検証環境での業務シナリオテスト、移送後の本番確認という順序で管理します。特に承認経路の変更では、既存の申請がどの定義を使っているかを確認してから切り替えます。

滞留やエラーの切り分け

ワークフローが進まないときは、症状を「起動されない」「担当者が決まらない」「受信箱に出ない」「処理後に次へ進まない」「期限処理が動かない」に分類します。分類せずに定義を修正すると、別の層にある原因を見落としやすくなります。

実務では次の順番で調査します。

  1. 対象文書の登録が正常終了しているか確認する
  2. 開始イベントが発生しているか確認する
  3. ワークフロー実行インスタンスが生成されているか確認する
  4. 現在のワークアイテム状態とエラーメッセージを確認する
  5. 担当者決定の入力値と結果を確認する
  6. 対象ユーザーの有効性と権限を確認する
  7. 定期処理、通知処理、RFCなどの連携を確認する
  8. 再実行または管理者による処置を実施する

開始されない場合はイベント連携、開始条件、対象文書のコミット処理を重点的に調べます。担当者未決定の場合は、条件値、組織情報、ルール、代理人を確認します。受信箱に表示されない場合は、割り当て先、ユーザー状態、表示対象のフィルタを確認します。

処理後に停止する場合は、次のタスクの入力値、結果分岐、バックグラウンド処理のエラーを確認します。エラー処理では、メッセージ本文だけでなく、ワークアイテムID、対象文書キー、発生時刻、実行ユーザー、直前のステップを記録すると再現性が高まります。

運用チェックリスト

日次または業務日ごとの確認では、未処理ワークアイテム、期限超過、エラー終了、担当者未決定の件数を確認します。件数の増加だけでなく、特定の組織、承認者、文書種別に偏っていないかも見ます。

月次または変更後には、代理人の有効期限、退職者や異動者の割り当て、期限監視、通知先、エラー再処理の記録を点検します。監視結果は、ワークフロー管理者、業務管理者、権限管理者が同じ形式で確認できるようにします。

運用台帳には、ワークフロータイプ、対象業務、開始イベント、担当組織、承認段階、期限、エスカレーション先、障害時の連絡先、最終テスト日を記載します。これにより、担当者が変わっても承認経路と復旧手順を追跡できます。

SAP Business Workflowを安定させるには、定義の正しさだけでなく、組織情報、ユーザー、定期処理、通知、権限を一体として管理します。まずワークアイテムの状態を正確に把握し、次に担当者決定と期限処理を確認する順番が、現場で再利用しやすい調査方法です。

ブログ一覧へ戻る