Build Process Automation: アーキテクチャと用途

JinJin48

SAP Consultant | BTP · S/4HANA · US Global Rollout

May 10, 2026 · 17 min read

本記事の位置づけ#

参考資料#

1) Build Process Automation 機能ランドスケープ#

SBPAは1つの製品ですが、6つの機能を備えています。これらを区別のない単一の「自動化ツール」として扱うことは、エンゲージメントの価格設定を誤る最も早い方法です。

これらは代替品ではありません。

2) S/4HANA への接続方法#

[S/4HANA Cloud]──events──┐
[S/4HANA on-prem]──REST──┤
[Non-SAP SaaS]──webhook──┤
                         ▼
              [SAP Integration Suite]
              [Advanced Event Mesh]
                         │
                         ▼
        ┌────────────────────────────────────┐
        │   SBPA tenant on BTP Cloud Foundry │
        │  ┌──────────┐  ┌──────────┐        │
        │  │ Process  │  │ Decision │        │
        │  │ engine   │  │ engine   │        │
        │  └──────────┘  └──────────┘        │
        │  ┌──────────┐  ┌──────────┐        │
        │  │ Forms    │  │ Visibil. │        │
        │  │ runtime  │  │ engine   │        │
        │  └──────────┘  └──────────┘        │
        └────────────────────┬───────────────┘
                             │ (UI tasks)
                             ▼
              [Desktop Agent on Windows]
              SAP GUI / web / Excel / mainframe
                             │
                             ▼
       [Approver UI: Build Work Zone / My Inbox / Task Center]

S/4HANA の接続はイベント駆動型であり、実行時の密結合ではありません。SBPA はリッスンを行い、SBPA が存在するからといって S/4HANA が変更されることはありません。Cloud Connector と BTP 宛先の組み合わせが、オンプレミスコールバックの標準パターンです。

重要なポイント: SBPAはS/4HANAの周辺で作業を調整します。S/4HANAデータベースを拡張することも、S/4HANAスタック内で実行することもありません。

3) 成熟度マップ#

4) 要件チェックリスト#

§4を引用する前に十分な深さまで構築せよ。回答が具体的でなければ、プロジェクトは準備が整っていない。

テナントおよびサブスクリプションの前提条件#

ワークフロー設計の前提条件#

RPA / 自動化の前提条件#

意思決定とフォームの前提条件#

可視性とモニタリングの前提条件#

5) 意思決定基準#

ツールを選択する前に、3つの質問に答えてください。

Q1. どのような測定可能な非効率性を対象としていますか？

顧客が月間時間数、エラー率、サイクルタイムといった数値を提示できない場合、SBPAも測定可能な結果を生み出せません。「承認プロセスをデジタル化する」は目標ではありません。「1,200人の従業員に対し、休暇承認の平均サイクルを3.2日から1日未満に短縮する」こそが目標です。

Q2. データはどこに保存され、誰が閲覧を許可されているのか？

SBPAはクラウド上で実行されます。すべてのプロセスは、少なくとも1つの接続されたシステムに影響を及ぼします。どのフィールドがソースシステムから送信可能か、SBPAがそれらをどこに保存してよいか、そして保存期間を文書で確認してください。この確認は、早期に行えば短いやり取りで済みますが、後回しにすると非常に長引くことになります。

Q3. 予算権限を持ち、プロセスを自ら推進する意思のある社内スポンサーはいますか？

プロセス自動化により、プロセスのオーナーシップが可視化されます。顧客内部で公開されたプロセスを誰も所有したがらない場合は、それを出荷してはいけません。SBPAの「無料トライアル」や「PoC」の段階が容易なのは、まさにまだ誰もそれらを所有していないからです。

プロジェクトコンテキストによるドメイン選択#

ライセンスとコスト#

automation-unattended プランは従量課金制であり、稼働後にコストが予想外に増加する最も一般的な原因です。ライセンスに関する協議には、必ず月間実行回数の見積もりを含めてください。

6) よくある障害#

障害 1: デプロイ時にアテンデッドとアンテンデッドを混同する

アテンドモードで設計・テストされたボット（開発者が自身のマシン上で起動するもの）は、デプロイされたプロセスがそれらを呼び出そうとすると、警告なく失敗します。この問題を修正するには、アンテンドモードのエージェントとそれに対応するサービスプランの両方が必要ですが、これらの判断はデプロイ後ではなく、要件定義段階で行うべきものです。

障害 2: ワークフロー管理の移行をインプレース移行として扱う

SAP Intelligent RPA向けのインプレース移行ツールは一方向かつ不可逆的なもののみ存在します。SAP Workflow Managementのプロジェクトは、通常SBPAで手動で再構築する必要があります。既存のワークフローを確認せずに「ワークフローを移行します」と引用すると、大規模な手戻りが発生します。

障害 3: イベントソースがないプロセス可視性ダッシュボード

よくあるパターン：顧客はダッシュボードを求め、チームは可視化シナリオを構築するが、本番稼働時にイベントが届かない。なぜなら、ソースシステムが接続されていなかったからだ。可視性はイベントモデリングの下流にあるものであり、その逆ではない。

障害4: デスクトップエージェントエンドポイントの衛生管理の過小評価

顧客はボットが「そのまま動作する」ことを期待しています。本番環境の安定性には、バージョン管理、アンチウイルス除外設定、専用サービスアカウント、無人セッションのロック/ロック解除ポリシーが必要です。これらはそれぞれ小さなタスクですが、まとめると無視できないエンドポイント管理のワークストリームとなり、SOWに含める必要があります。

障害5：プロセス内への承認者や接続情報のハードコーディング

“John Smith” という名前や特定のURLをハードコードするプロセスは、デモでは機能しても本番環境では失敗します。承認者は意思決定テーブルや組織サービスに属し、接続詳細はBTP宛先に属します。これは実装の洗練ではなく、要件段階の規律です。

障害 6: ライセンスに関する会話の範囲を狭くしすぎている

デフォルトのミスは、advanced-user と standard-user のみを引用することです。デプロイされたボット向けの automation-unattended や、ドキュメント処理が多いプロセス向けの DOX Premium を忘れると、最悪のタイミングで調達の再開が発生します。スコープ設定時にすべての機能ボックスを確認し、ライセンスについて「スコープ内」または「スコープ外」を明示的にマークしてください。

障害 7: データ保存場所および保持契約の省略

プロセスインスタンスデータ、添付文書、および監査ログはSBPAテナントに保存されます。規制産業の顧客は、この制約をスコープ設定時ではなくセキュリティレビュー時に発見します。要件段階で顧客のプライバシーまたはコンプライアンス責任者と30分間話し合うことで、後々の数か月にわたる遅延を防ぐことができます。

FAQ#

Q: SBPAはオンプレミスのS/4HANAでも動作しますか、それともS/4HANA Cloudのみですか？

両方です。オンプレミス統合では、同期呼び出しにCloud Connector + BTP宛先を使用し、イベントにはAdvanced Event MeshまたはRESTプッシュのいずれかを使用します。アーキテクチャの形状は同一ですが、設定はより複雑になります。

Q: SBPAのライセンスはどのように付与され、最もよくある価格設定の驚きは何ですか？

プラン別：standard アプリケーションに加え、ユーザー単位のプラン（advanced-user、standard-user）およびボット実行単位のプラン（automation-attended、automation-unattended、またはバンドル版のdigital-workforce）があります。最もよくある誤解は、ボットを呼び出すデプロイ済みプロセスにはautomation-unattendedの消費が必要であり、アテンデッド専用の顧客はスケジュールされたボットを実行できない点です。

Q: プロジェクトからRPAをスコープ外とするのはどのような場合ですか？

対象システムに適切なAPIやイベントチャネルが存在する場合、RPAは最後の手段です。なぜなら、RPAは自動化をベンダーが予告なく変更可能なUIに依存させるからです。顧客の「RPAが必要」という要望が実際には「統合（インテグレーション）が必要」であるなら、まずはAPIを優先するよう促してください。

Q: 要件を引き継ぎに耐えられるようにするには、どのように文書化すべきですか？

各自動化プロセスについて、以下を取得すること：トリガーソース（イベント/API/フォーム）、終了条件、承認者決定方法、SLA、エスカレーションパス、影響を受けるデータフィールド（データ保存場所に関する注記を含む）、および使用されるライセンス機能。要件ドキュメントでこれらのいずれかが空白の場合、実装時に推測値が補完される。

Q: ビジネスユーザーは本当にIT部門なしで意思決定を維持できるのか？

はい、決定テーブルについてです。Excelのラウンドトリップは実際に使用可能です。ただし、2つの注意点があります。所有権はスコーピング時に合意する必要があり、暗黙的に決めるべきではありません。また、Excelで変更を行った後も、誰かがSBPAでルールバージョンをリリースする必要があります。そのステップはスプレッドシートに委任されません。

Q: Joule 生成は SBPA アーティファクトに対して本番環境で使用可能ですか？

プロセス、フォーム、意思決定、スクリプトの初稿作成における生産性向上ツールとしてご利用ください。Jouleの出力は、命名規則、エラーハンドリング、認可モデルについて専門家によるレビューが依然として必要であり、これらは出力が不十分になりがちです。

Q: 本番環境では可観測性はどのように扱われますか？

Process Visibility はビジネスビューを提供します。運用ビュー（失敗したインスタンス、エージェントの健全性、キュー深度）については、SBPA Monitoring アプリと BTP Alert Notification を使用してください。これらは別々のツールであり、両方を接続する必要があります。

概要#

SAP Build Process Automationは、BTP上で統合されたローコード自動化製品であり、SAP Workflow ManagementとSAP Intelligent RPAが廃止された現在、唯一の将来性のあるパスです。その強みは幅広さにあります。1つのスタジオで6つの機能を提供しますが、障害モードはその境界部分に集中しています。すなわち、有人/無人ライセンス、Desktop Agentエンドポイントの衛生管理、可視性のためのイベントソースの欠如、ワークフロー移行に関する軽率な想定です。コンサルタントとしてのあなたの価値は要件定義段階に集中しています。最初のプロセスが描かれる前に、ライセンス機能、イベントソース、および所有権に関する質問を確定させてください。

次に読むべきもの#