アウトカムベースのオペレーティングモデル
あなたがシェアードサービス部門の財務チームを率いていると想像してください。長年にわたり、チームの評価は、アナリスト一人あたりの処理請求書数、チケット平均処理時間、そしてチームメンバーのスケジュール充足率によって行われてきました。これらの指標は、業務のほぼすべてが人間によって行われていた時代には、いずれも妥当なものでした。
現在、あなたのチームは、決算整理業務のオーケストレーション、照合作業の準備、例外請求書のトリアージをエージェントに任せ始めています。すると、管理業務の大部分が突如として消え去ります。もし古い指標を使い続ければ、目に映るのは「人間の活動量の低下」だけです。しかし、それはチームのパフォーマンスが悪化したことを意味するのでしょうか？
より適切な問いは、むしろ次の通りです。請求書はより正確に処理されているか？例外はより迅速に解決されているか？バックログは減少しているか？初回解決率は向上しているか？人間のチームは、真に判断力を要する案件に注力できるようになったか？
ここに、多くの企業がエージェントをワークフローに導入し始めた際に直面する核心的な問題があります。労働時間、工数、プロセスあたりの人員数といった尺度は、ますます実態を反映しなくなっています。重要なのは、どれだけの活動が行われたかではなく、どのようなアウトカムが実際に達成されたかなのです。
従来の手法が揺らぎ始める理由
エージェントが、コンテキストの読み取り、ケースのルーティング、アクションの準備、ツールの呼び出し、さらには特定のトランザクションの完了といった業務を引き継ぎ始めると、仕事の構造は根本的に変化します。財務部門では、エージェントは決算整理のオーケストレーションを支援できます。調達部門では、エージェントはインテークの分類やポリシーのチェックを行えます。IT運用部門では、エージェントはインシデントのトリアージを実行できます。カスタマーオペレーション部門では、エージェントは人間の介入なしに単純なケースを解決できます。
もし経営陣が引き続き活動量に注目し続ければ、組織はその価値を誤って評価することになります。活動は、目的そのものではなく、中間変数へと変わります。より重要なのは、ビジネスに真のインパクトをもたらすアウトカムです。
アウトカムベースのオペレーティングモデルは、このようなニーズから生まれました。すなわち、主として活動量や労働力のキャパシティに基づくのではなく、サービスの成果とビジネスへの影響に基づいて企業を管理するという考え方です。これは単なるKPIの変更ではありません。サービスを設計し、説明責任を割り当て、社内外の契約を構築し、どのユースケースを拡大すべきかを判断する方法そのものを変えるものです。
アウトカムはビジネス価値により近い
アウトカムベースとは、具体的に何を意味するのでしょうか。各機能は、真に重要な結果を定義する必要があります。財務部門であれば、アウトカムは、より迅速で管理された決算、正確に処理された請求書、または照合例外の減少などです。調達部門であれば、リクエストが最初から正しいルートに誘導されること、調達サイクルタイムの改善、ポリシー遵守率の向上などです。カスタマーオペレーション部門であれば、初回問い合わせでの解決、リピートコンタクトの減少、顧客満足度の向上などです。IT運用部門であれば、インシデントのより迅速な復旧、誤ったエスカレーションの減少、リリース前の変更準備の向上などです。
このようなアウトカムは、単に自動化されたタスクの数を数えるよりもはるかに有用です。さらに重要なことは、アウトカムベースの思考は、企業に「このタスクは本当に必要か？」と問いかけさせることです。
多くのエンタープライズプロセスは、過去の遺産とも言える活動であふれています。データが改善されれば実際には排除できる重複チェック、過去の組織構造にのみ起因するハンドオフ、リスクに見合わなくなった承認、実際の意思決定に使われていない手動レポートなどです。もし企業が活動の自動化だけを追求すれば、ムダを加速させることになります。エージェンティックAIは、テクノロジーがより多くのことを自動化できるようになったため、このリスクをさらに拡大させます。アウトカムという規律がなければ、組織は誤ったプロセスを極めて効率的に実行することになりかねません。
したがって、エージェントを構築する前に最初に問うべきことは、「どのタスクを自動化できるか？」ではなく、「どのアウトカムを改善したいのか、そしてそのアウトカムに真に貢献する活動はどれか？」であるべきです。
FTEからサービスアウトカムへ
次の変化は、企業が社内外のサービスを見る方法において発生します。多くのシェアードサービス、GCC、テックサービスの部門は、依然として工数ベースのロジックで管理されています。すなわち、何人配置されているか、何時間の労働が使われたか、何件のチケットが処理されたか、またはチームにどれだけのキャパシティが必要か、といった基準です。
このモデルが完全に消え去るわけではありませんが、デジタルレイバー（デジタル労働力）がサービス提供の一部となるにつれて、その妥当性はますます低下しています。エージェンティックモデルでは、スループットは人員数の線形的な増加なしに向上する可能性があります。コスト構造も変化します。プラットフォームコスト、モデルと推論のコスト、統合コスト、オブザーバビリティとガバナンスのコストは発生しますが、特定のボリュームに対する手作業の工数は減少します。
その結果、FTEや労働時間に基づくプライシングは、その関連性を失い始めています。もし一つのサービスが、エージェント、ワークフローエンジン、人間のスーパーバイザーの組み合わせによって完結するのであれば、人間の工数だけに基づいて課金したりコストを配分したりすることは、誤解を招くものとなります。
具体的な例を挙げましょう。かつてはビジネスユニットごとのサポートスタッフ数に基づいてチャージバックを行っていた調達のシェアードサービスは、現在では、解決されたリクエスト数、サイクルタイム、コンプライアンス率などのアウトカムで測定する方がはるかに理にかなっています。かつてはレベル1で処理されたチケット数で計算されていたITサービスは、目標内に解決されたインシデント数、サービス復旧時間、変更の準備完了率などの指標へと移行しつつあります。かつては取引量あたりのFTE比率で正当化されていた財務オペレーションは、適切に処理された請求書あたりのコスト、または解決された例外あたりのコストで見る必要が出てきています。
この変化は、ベンダーとの契約にも及びます。エージェンティックサービスにおいて、企業は実際には「ツール」や「追加の人員」を購入しているのではなく、ますます頻繁にサービスのアウトカムを購入するようになっています。マネージドサービスやアウトソーシングの契約は、インプットベースのプライシング、タイムアンドマテリアル、あるいは単なる人員数活用度から、品質の高いスループット、解決アウトカム、コンプライアンスアウトカム、特定のビジネスKPIなどに近いモデルへと移行する必要があります。
もちろん、これは常に容易なことではありません。すべてのサービスが純粋にアウトカムベースで契約できるわけではありません。プロセスが外部要因に大きく影響されたり、クライアント自身のデータの質が低かったりする場合、ベンダーが全リスクを負うことは難しいでしょう。しかし、変化の方向性は明らかです。エージェンティックなサービス提供が成熟するにつれて、工数だけに基づくプライシングのロジックは弱まります。アウトカムを明確に定義できない、品質のベースラインが存在しない、外部要因が支配的すぎる、データとプロセスに対する管理が分散している、といった状況では、企業はハイブリッドモデルから始めることができます。すなわち、一部はキャパシティベースの固定費、一部は合意されたアウトカムベースの変動費とする方法です。
意思決定と責任の主体
アウトカムベースのオペレーティングモデルは魅力的に聞こえますが、より高度な組織の規律を要求します。焦点が結果に移ると、企業は誰が何を決定する権限を持ち、アウトカムの達成に失敗した場合に誰が責任を負うのかについて、極めて明確にしなければなりません。
エージェンティックエンタープライズにおいては、少なくとも3つの役割を区別する必要があります。
第一に、ビジネスオーナーです。彼らはサービスまたはプロセスのアウトカムに対して責任を負います。ビジネス目標、ユースケースの優先順位、成功の定義、許容可能な運用上のトレードオフを決定します。例としては、決算アウトカムに対するCFOまたはコントローラーシップリーダー、インテークから発注までのアウトカムに対するCPOまたは調達オペレーションリーダー、ケース解決アウトカムに対するカスタマーオペレーション担当COO、インシデント復旧アウトカムに対するCIOまたはオペレーション部門長などが挙げられます。
第二に、エージェントオーナーです。彼らはワークフロー内でのエージェントの設計とパフォーマンスに責任を負います。すなわち、エージェントの動作方法、呼び出すツール、使用する評価基準、適用するしきい値、変更のリリース方法などです。この役割は、多くの場合、プロダクトオーナー、プラットフォームオーナー、またはドメインスクワッドリーダーが担います。
第三に、リスクオーナーです。彼らは、制限付きの自律性がガードレール内に留まることを確実にします。すなわち、適用されるポリシー、必須の承認、アクセス可能なデータ、およびユースケースを保留または制限すべきタイミングなどです。特定のドメインでは、リスクオーナーはコンプライアンス、内部統制、セキュリティ、法務、または運用リスク機能から選ばれる可能性があります。
アウトカムベースモデルの真の試練の一つは、結果が期待通りでない場合です。例えば、請求書の誤処理、インシデントの誤ったルーティング、フォーキャスト例外の未対応、顧客ケースの早期クローズ（問題が未解決のまま）などです。このような状況では、組織は問題の根本原因が、データの誤りや不完全さ、ポリシーの曖昧さや未更新、ツールや統合の障害、モデルやエージェントの動作不良、あるいはプロセス設計自体の誤りにあるのかを区別できなければなりません。この区別がなければ、すべての失敗は「AIエラー」という一つのカテゴリーにまとめられてしまい、実際には異なる是正措置が必要であるにもかかわらず、適切な対応が取れなくなります。
決して曖昧にしてはならない原則が一つあります。それは、エージェントは説明責任を負わないということです。エージェントはアクションを実行し、推奨事項を提供し、ワークフローをオーケストレーションすることはできますが、責任は依然として人間と組織構造にあります。ガバナンスの観点から、企業は責任をシステムに転嫁することはできません。財務で重大なエラーが発生した場合、調達でポリシー違反があった場合、またはITでセキュリティインシデントが発生した場合、説明責任を問われるのは、プロセスオーナーと組織です。運用の観点からは、説明責任の明確化は混乱を防ぎます。誰もが「エージェントが悪い」と考えれば、誰もデータ、ポリシー、プロセス設計を真に改善しようとはしなくなります。
イニシアチブをアウトカムポートフォリオとして管理する
企業が多くのエージェンティックイニシアチブを持つようになると、課題は単にユースケースを構築することではなく、アウトカムのポートフォリオを管理することになります。すべてのユースケースが継続する価値があるわけではなく、すべてのクイックウィンが拡大する価値があるわけでもありません。
実務的には、エージェンティックポートフォリオは通常、4つのカテゴリーのバランスを取る必要があります。クイックウィン：価値が明確で、リスクが管理可能であり、データが十分に準備されているユースケースです。例えば、インテーク分類、請求書トリアージ、標準的なケースに対するサービスデスク解決などです。戦略的賭け：オペレーティングモデルをより大きく変革する可能性があるが、より複雑なユースケースです。例えば、エンティティ横断的な決算整理オーケストレーション、サプライチェーン例外調整、マルチエージェントITデリバリーワークフローなどです。プラットフォーム投資：単一のプロセスでは直接的に価値が見えにくいが、スケールのために重要なイニシアチブです。例えば、アイデンティティ、オブザーバビリティ、ポリシーエンジン、統合レイヤー、評価ハーネスなどです。リスク低減イニシアチブ：データ、コントロール、監査可能性、ガバナンスの改善であり、他のユースケースが安全に実行されることを可能にします。
もし企業がクイックウィンのみを追求すれば、多くのパイロットは生まれるものの、変革はほとんど起こりません。もし戦略的賭けのみを追求すれば、速度が遅すぎて勢いを失うリスクがあります。健全なポートフォリオにはバランスが必要です。
アウトカムベースモデルは、価値のないイニシアチブを停止する規律も要求します。各ユースケースには、明確なステージゲートを設けるべきです。ビジネス上の問題は現実のものか、ベースラインは利用可能か、データとポリシーは十分に準備されているか、パイロットはアウトカムの改善を示しているか、修正率とリスクプロファイルは許容範囲内か、経済性は健全か。もしこれらの問いに対する答えが「いいえ」であれば、ユースケースは停止、縮小、または再設計されるべきです。これは、エージェンティックAIが楽観バイアスを生み出しやすいため、重要です。優れたデモは、組織が特定のユースケースが実際には十分な価値がない、または現時点ではリスクが高すぎることを認めるのを難しくすることがよくあります。
ポートフォリオレビューは、単なるテクノロジーのフォーラムであってはなりません。ビジネスオーナー、CIOまたはCTOまたはプラットフォームリーダー、財務部門、リスクまたはコンプライアンスまたはセキュリティ部門、そして必要に応じてCHROまたは変革オフィスを巻き込む必要があります。スケールの決定は、単にエージェントが動作するかどうかではなく、ビジネスアウトカムが現実のものか、ガバナンスが適切か、組織が変化を受け入れる準備ができているかどうかが問われます。
次の実践的なステップ
アウトカムベースモデルがなぜ重要かを理解したところで、今すぐ取るべきいくつかの決定があります。第一に、優先ワークフローごとに主要なアウトカムを決定します。自動化可能なタスクのリストから始めてはいけません。改善したい結果、すなわち解決時間、正確性、コンプライアンス、サービスレベル、意思決定の質から始めましょう。
第二に、チャージバックモデル、プライシング、ビジネスケースを見直します。もしサービスが主にFTEと工数で測定されているなら、シェアードサービス、GCC、テックサービス、またはベンダーマネージドサービスに対して、どのアウトカム指標を使い始めるかを決定します。
第三に、意思決定権限を明示的に定めます。ビジネスオーナー、エージェントオーナー、リスクオーナーを区別します。誰がアウトカムを保持し、誰がエージェントのパフォーマンスを管理し、誰がガードレールを設定するのかを明確にします。
第四に、エージェンティックポートフォリオのためのステージゲートを構築します。各ユースケースには、継続、再設計、または停止の基準を設けます。すべてのパイロットが決定なしに長期間存続することを許してはいけません。
第五に、レビューフォーラムを活動からアウトカムへと変更します。ステアリングコミッティやオペレーションレビューでは、自動化の数や節約された労働時間への焦点を減らし、品質、解決率、信頼性、リスク、アウトカムあたりの経済性への焦点を増やします。
いくつかの警告サインに注意する必要があります。AIプログラムが主に人員削減や労働時間削減によって正当化されている。ユースケースがビジネスアウトカムの重要性ではなく、デモのしやすさで選ばれている。アウトカム、エージェントパフォーマンス、リスクに対して明確なオーナーがいない。エージェントの失敗が、根本原因分析なしに一般的に議論されている。ベンダーや内部チームが、サービスの成果ではなく、ほぼ完全に工数で評価されている。ポートフォリオはパイロットで溢れているが、スケール、再設計、または停止についての断固たる決定がほとんどない。ガバナンスボードは、アウトカムの質やコントロールではなく、テクノロジーの導入のみを見ている。組織は、いくつかの活動は自動化されるべきではなく、排除されるべきであるという考えを受け入れる準備ができていない。
もし明日、あなたの機能における日常的な活動の大部分がエージェントに取って代わられたら、あなたの管理モデルはまだ意味をなすでしょうか？ それとも、あなたは依然として、実際に生み出されているサービスのアウトカムではなく、人員数と労働時間に基づいて会社を管理しているでしょうか？
これこそが、アウトカムベースのオペレーティングモデルの核心的な問いです。エージェンティックエンタープライズにおいて、勝つのは活動を最も速く自動化する企業ではなく、結果を管理する上で最も規律ある企業なのです。