はじめに：なぜ承認はワークフローに乗せるべきか
「購買依頼の承認はメールで回しています」「経費精算はExcelで上長判子を押してもらっています」――今でもこういった運用は珍しくありません。しかしこの方式は、承認の遅延・履歴の散逸・差戻しの混乱・監査証跡の欠落といった問題を必ず生みます。さらに問題なのは「誰の承認待ちか」が組織の中で見えなくなり、ボトルネックを特定できなくなることです。
なぜそれが致命的か（why so）。承認プロセスは業務スピードと内部統制の両方に直結します。遅延は業績に影響し、証跡欠落は監査指摘につながります。Excelとメールでは、組織変更・代理承認・並行承認・条件分岐といった現実の業務要件を吸収しきれません。
ではどうすべきか（so what）。承認プロセスをシステム上に明示的にモデル化し、ステップ・承認者・条件・履歴を統合管理する仕組みに乗せるのが答えです。SAPはこの目的のためにワークフロー機能を長年提供してきており、現在は従来型のSAP Business WorkflowとFlexible Workflowの2世代が共存しています。本記事では両者の違いと使い分けを整理します。
ワークフローが解決する4つの問題
| 問題 | ワークフローによる解決 |
|---|---|
| 誰が承認待ちか分からない | UWLや承認受信箱で一元表示 |
| 代理・組織変更で承認者が変わる | 役職ベース／組織ベースで自動再ルーティング |
| 履歴が残らない | すべてのステップ・コメント・所要時間を自動記録 |
| 例外処理が属人化する | エスカレーション・タイムアウト・差戻しを標準化 |
なぜワークフローが業務改善ツールになるか。承認プロセスを可視化すると、どこで詰まっているかが分かり、改善対象を定量的に特定できるからです。これはSAP Signavioのプロセスマイニングと組み合わせると、さらに強力な業務改善基盤になります。
SAP Business Workflow（従来型）
SAP Business Workflowは1990年代から提供されてきた、ABAPベースのワークフローエンジンです。Tコード「SWDD」でグラフィカルに設計し、「SWWL」で実行モニタリングします。
構成要素
| 要素 | 説明 |
|---|---|
| Workflow Template（WS） | ワークフローテンプレート、設計の単位 |
| Task（TS） | 1ステップで実行するアクション |
| Business Object（BOR） | ワークフロー対象オブジェクト（購買依頼、休暇申請など） |
| Rule | 承認者決定ルール |
| Container | ステップ間でデータを引き渡すコンテナ |
特徴
- ABAPに深く統合されており、業務オブジェクトのイベントをトリガに自動起動
- 承認者決定ルールを役職・組織・カスタムロジックで自由に組める
- エスカレーション・タイムアウト・並行承認などの業務要件に対応
- SWDDでGUI設計、ABAPのスキルがあれば自由度は非常に高い
- 学習コストが高い、初学者には敷居がある
なぜ従来型は今も使われているか。S/4HANAでも標準業務オブジェクト（購買依頼、休暇申請など）には従来型ワークフローのテンプレートが多数用意されており、「すでにあるテンプレートをコピーして手直しする」だけで動くケースが多いからです。
Flexible Workflow（S/4HANA時代の新方式）
Flexible WorkflowはS/4HANAで導入された、Fiori上で設定するノーコード/ローコード型ワークフローです。Tコードでなく、Fioriアプリ「Manage Workflow」で設定します。
特徴
- Fiori UIでステップ・条件・承認者を設定、ABAP不要
- 業務オブジェクトに事前定義された「シナリオ」をベースに使う
- 条件分岐は「金額>100万円なら部長承認」のようなルールを画面で定義
- 標準で利用可能なシナリオが拡充中（購買依頼承認・販売注文承認・請求書承認など）
- バージョン管理・有効日管理が組み込まれている
- 通知はメール・Fiori通知センター・Microsoft Teams等に飛ばせる
設計思想
flowchart LR A[業務イベント
購買依頼登録] --> B[シナリオ選択
標準テンプレート] B --> C[条件評価
金額・組織] C --> D[ステップ1
課長承認] D --> E[ステップ2
部長承認] E --> F((業務完了))
ポイントは「シナリオ」という概念です。SAPがあらかじめ業務オブジェクト別にワークフローの骨格を用意しており、ユーザーは条件と承認者を画面で設定するだけで動かせます。なぜこの設計か：従来型では「テンプレートをコピーしてABAPで微調整」が必要でしたが、シナリオベースなら業務担当者がコードに触れずに変更できます。
従来型 vs Flexible Workflow 比較
| 観点 | SAP Business Workflow | Flexible Workflow |
|---|---|---|
| 対象 | 全業務オブジェクト | SAPがシナリオを提供している業務 |
| 設計ツール | SWDD（GUI設計） | Fiori「Manage Workflow」 |
| スキル | ABAP・BOR知識必須 | 業務担当者でも設定可能 |
| 自由度 | 非常に高い | シナリオの範囲内 |
| 承認者決定 | ルール（PFCG連携・カスタム） | 役職・組織・条件 |
| エスカレーション | 標準サポート | 標準サポート |
| 通知連携 | UWL中心 | Fiori通知・メール・Teams等 |
| Clean Coreとの相性 | △（カスタム実装が増えがち） | ○（標準シナリオを使うため） |
なぜ両方が共存しているか。S/4HANAでもすべての業務シナリオがFlexible Workflowに移植されているわけではないからです。「標準シナリオがあるならFlexible Workflow、なければ従来型」というのが現代の選び方です。新規プロジェクトではFlexible Workflowを優先し、それで実現できない複雑な要件だけを従来型で組むのが定石です。
どちらを選ぶべきか：判断フロー
flowchart LR
A[要件分析] --> B{Flexible
シナリオあり?}
B -->|Yes| C{条件範囲内?}
B -->|No| D[従来型
SWDD]
C -->|Yes| E[Flexible
採用]
C -->|No| F{拡張で対応
可能?}
F -->|Yes| E
F -->|No| D判断のポイントは「業務担当者が将来自分でメンテナンスできる形にする」ことです。従来型はABAP開発者の手を離れにくく、業務変更のたびに開発依頼が発生します。Flexible Workflowは設定変更で対応できる範囲が広いため、長期的な運用コストが低くなります。
SAP標準でカバーできない範囲とアドオン事例
1. Microsoft Teams／Slack等への深い連携
Flexible Workflowは標準でTeams連携できますが、独自の承認カードやアクションを組みたい場合はBTPで独自アプリを作る必要があります。Power Automateと組み合わせるパターンも増えています。
2. 複雑な多階層承認ロジック
「金額により3段階、特定品目は別ルート」のような複雑な要件は、Flexible Workflowの条件式では表現しきれず、BAdIで承認者決定ロジックを書くケースがあります。
3. 承認SLAの可視化
承認所要時間を測定し、遅延を上長にアラートするレポートは標準では弱く、CDSビュー＋Fioriダッシュボードで作るアドオンが定番です。
4. 外部システムとの承認連動
社外の取引先に承認をもらう必要がある業務（共同プロジェクトの承認など）では、Integration SuiteやWebフォームと組み合わせて外部連携を実装します（SAP Integration Suite入門参照）。
5. 承認データのAI分析
過去の承認履歴から「却下されやすい申請パターン」を学習し、起票時に警告するAIアドオン。Joule活用と組み合わせるケースも増えています。
なぜここでも標準優先か。ワークフローは業務統制と直結しており、改造ミスが承認漏れ・統制違反につながるからです。「Flexible Workflowで実現できる範囲か」を最初に確認し、それで足りない部分だけアドオン化するのが鉄則です。
ワークフロー設計の実務ポイント
- 承認ステップは最小化する。「念のため」で増やすと現場の不満になり形骸化する
- 代理承認・休暇時のリルートを最初に設計する
- タイムアウト時の動作（自動承認／自動エスカレーション）を業務責任者と合意する
- 承認コメントを必須化するかオプションかを最初に決める
- 承認履歴の保存期間と監査要件を経理・内部統制部門と合意する
- 通知方法は「メール／Fiori通知／Teams」のどれをデフォルトにするかを統一する
よくある疑問（FAQ）
Q. 従来型ワークフローは廃止されますか？ A. 廃止予定はありません。S/4HANAでも標準テンプレートが多数残っており、Flexible Workflowでカバーされない領域では現役です。
Q. Flexible WorkflowはS/4HANA Cloud Public Editionでも使えますか？ A. 使えます。むしろPublic EditionではABAPアクセスが制限されるため、Flexible Workflowが事実上の標準になります。詳しくはPublic vs Private比較も参照してください。
Q. ワークフローのトリガは何ですか？ A. 業務オブジェクトのイベント（伝票作成・変更・ステータス変更など）です。Flexible Workflowではシナリオ側で事前定義されています。
Q. Fioriの通知センターと承認受信箱は何が違いますか？ A. 通知センターは全社の通知を集約する場所、承認受信箱（My Inbox）は承認待ちタスクに特化したFioriアプリです。
Q. Microsoft TeamsへAdaptive Cardで承認を出せますか？ A. 出せます。Flexible Workflowの通知設定でTeams連携を有効化し、Adaptive Cardのテンプレートを設計します。
まとめ
- ワークフローは承認プロセスを可視化・標準化・自動化するSAPの基幹機能
- SAP Business Workflow（従来型）はABAPベースで自由度が高く、SWDDで設計
- Flexible Workflow（S/4HANA）はFioriベースで業務担当者でも設定可能、Clean Coreと相性が良い
- 新規プロジェクトはFlexible Workflowを優先し、不足分だけ従来型または拡張で補う
- 標準シナリオの有無が選定の最大ポイント、判断フローを最初に固める
- 承認ステップは最小化、代理・タイムアウト・通知方法を初期設計時に決める
- 統制と直結する領域なので、改造より設定での実現を最優先する
ワークフローは「承認を減らす技術」ではなく「承認を見える化する技術」です。可視化されて初めて、本当に必要な承認とそうでない承認を判別でき、業務改善の議論ができるようになります。SAPを使っている企業ほど、ワークフローを正しく組むことが業務スピードと統制の両立を支える土台になります。
ワークフローの拡張はBTP上のBuild Process Automationとの連携で真価を発揮します。BTPの基礎から実践まで体系的に学べるハンズオン講座を紹介します。