連携でさらなる改革を：ビジネスプロセス管理とAPI主導の接続性

ビジネスプロセス管理（BPM）とAPI主導の接続性は、同じビジョンを共有し、互いに互いを補い合う戦略です。そのビジョンとは、新しい市場の要求や進化する顧客の期待に応じて迅速に変化し続けられる「コンポーザブルエンタープライズ」（自由な組み立てが可能な企業）を目指すということです。

BPMとAPI主導の接続性が相性がよい理由

BPMの目的は、企業のビジネスプロセスを最適化することです。この目的に従い、ビジネスプロセスはモデル化、自動化、モニタリングされます。BPMシステム（BPMS）は、ビジネスプロセスの管理とデータフローをモデル化し、実行します。また、BPMSには人的なワークフロー機能の提供に加え、さまざまなビジネスプロセスに適用されるビジネスルールロジックを取り込むことができるビジネスルールエンジンが含まれています。

オンライン小売業の事例を紹介します。図１のビジネスプロセスの例は、顧客の返品リクエストへの対処をビジネスプロセスモデリング表記法（BPMN）に従ってモデル化し、簡略化したものです。

顧客が返品を依頼するとすぐに、その顧客の注文履歴を参照します。注文履歴は、次の処理である「返品条件との適合性の検証」のために重要なデータになります。この処理を自動化するためにビジネスルールエンジンが試用されます。

返品条件と照らし合わせた結果、否定的な検証結果が出た場合は、顧客に対して有効な代替案や誠意ある解決策を人間が探し出す必要があるでしょう（人的な作業をヒューマンタスクとも言います）。返品リクエストが却下された場合、顧客は却下の通知を受け取ります。一方、返品リクエストが受諾されれば、顧客は返品承認の連絡を受け取り、顧客の注文履歴に返品承認（RMA）が記録されます。

図１に、この簡単なビシネスプロセスをモデル化し、図示しました。以下に、BPMライフサイクルの次フェーズである「ビジネスプロセスの自動化」も紹介します。企業のビジネス活動は、技術的な実装を常に検討しなければなりません。

ビジネスプロセスの自動化には、以下の3つの選択肢があります。

1. ヒューマンタスクを作成し、該当する作業項目を割り当てる
2. ビジネスルールエンジンを定義・参照することで、判断処理を自動化させる
3. BPMS外のアプリケーションを呼び出して、ビジネスロジックを適用する

図１の例では「返品条件が適合されないとき」の処理のみが、ヒューマンタスクとなります。そして、判断処理である「返品条件との適合性の検証」は、ルールエンジンを通じて処理が実行。残りの５つの処理には、バックエンドシステムとのインテグレーションが必要になります。では、API主導の接続性がどのように役立つのでしょうか？

API主導の接続性とビジネスプロセス

API主導の接続性では、類似する役割別に3つの階層（エクスペリエンスAPI、プロセスAPI、システムAPI）を定義しています。ビジネスプロセスに適合する階層はどれでしょうか？エクスペリエンスAPIは、デジタルチャネル向けに調整された情報を扱います。システムAPIの大半は、記録システム用の接続ロジックを含有しています。エクスペリエンスAPIとシステムAPIの間にプロセスAPIの階層が存在します。この階層は、デジタルチャネルや下に位置するシステム構成から分離、抽象化されており、ビジネス領域にフォーカスします。つまりプロセスAPIこそが、ビジネスプロセスとビジネスルールの両方のロジックを持たせるのに最適なのです。

ここで、ビジネス領域における既存のAPIとのインテグレーションについて検討しましょう。API主導の接続性のアーキテクチャを図２に表しました。２つのチャネルが関与しています。ひとつはショップシステムで、もうひとつはショッピング体験を補完するモバイルエクスペリエンス（顧客情報や購買履歴、トランザクションの確認など）です。

これに対応して、それぞれのチャネルに合わせた情報を提供するため、エクスペリエンス層に「Shop（ショップ）」と「Mobile（モバイル）」のAPIを用意しています。

プロセス層には4つのビジネス向けAPIがあります。「Order History（注文履歴）」APIと「Shipping（発送）」APIは、複数のAPIを呼び出して情報を充実化させます。システム層には、バックエンドシステムとの接続ロジックを含有するAPIを用意しています。

MuleSoftが提供するAPI管理の「Anypoint Exchange」には将来のプロジェクトで再利用できるように、APIが文書化され、公開されています。また、Center for Enablement（C4E）は再利用を推進し、他のチームがプラットフォームを積極的に利用することをサポートするチームとなります。すなわち、C4Eとは、BPMの戦略にとって最適な組織的基盤なのです。 

新しいビジネスプロセスを自動化する際、API主導の接続性によって、過去の投資を有効活用することができます。ビジネスプロセス内のタスクに接続するためのAPIを、新たに開発する必要はなく、同じ機能を持った既存のAPIを再利用すればよいのです。再利用では賄えない処理にのみ、新しいAPIを構築して公開するだけで済ませられます。

ビジネスプロセスを自動化するためには、個々の処理とバックエンドシステムとの接続が大きな課題になります。API主導の接続性は、迅速なデリバリと効率を向上させるソリューション。そして、BPMはAPI主導の接続性の採用によって可能となる「コンポーザビリティ」（組み立て可能なアーキテクチャ）によって、ビジネス価値を向上するための手段です。つまり、BPMとはAPI主導の接続性の採用によってビジネス価値を生み出す手段のひとつなのです。

図３は、現状のAPI主導型アーキテクチャ（図２）を見直し、ビジネスプロセスの自動化に必要な改善を施したものとなります。

新しいビジネスプロセスには、「返品リクエストへの対応」APIが追加され、文書化、公開されます。これは顧客の返品リクエストをトリガーに、エクスペリエンスAPI層内のShop APIから呼び出され、返品リクエストを承認するための情報を返します。もちろん、「返品リクエストへの対応」APIを文書化、公開することで、この返品プロセスを他の状況のために再利用することができるようになります。

BPMSはプロセスインスタンスの実行を制御します。まず、最初の「顧客の注文履歴の確認」を処理する際には「Order History（注文履歴）」APIを呼び出します。ビジネスプロセスの自動化において、この「Order History（注文履歴）」APIを再利用することで、多くの時間と労力を節約が可能となります。この処理を実行するにあたっては、既存の接続性とインテグレーションのロジックをCRMと受注管理システム（OMS）に適用します。

ルールエンジンは、プロセス内の２つ目の「返品条件との適合性の検証」の処理を実行。またBPMSは、ヒューマンタスクである「ポリシー違反への対処」を直接処理します。

「返品発送ラベルの作成」の処理も、既存の「Shipping（発送）」APIを参照するだけで実行できるため、APIを新しく構築する必要はありません。この図２のアーキテクチャでは、返品プロセス後半の処理を実行するためのAPIは存在しませんでした。そのため、「Notification（通知）」と「Commerce（取引）」という新しいAPIを開発しなければなりません。この２つの新しいAPI は、再利用可能な資産として保管され、将来のプロジェクトで誰でも利用できるようになります。

結論

API主導の接続性が、ビジネスプロセスの実装に最適な基盤であることを示してきました。ビジネスプロセスを実装するために、APIを再利用すれば時間と労力が大幅に削減できます。

BPMとAPI主導の接続性は、それぞれの独自戦略のもと単独で価値を生み出すと同時に、互いを完全に補い合う関係でもあります。API主導の接続性は、企業が「コンポーザビリティ」を実現するための投資。そして、BPMによってその投資を回収します。自動化されたビジネスプロセスがいずれも、ビジネス価値を実現する独自の構成要素となるからです。