複数システムの承認を一元化するには？API連携型ワークフローという選択肢【ワークフロー活用・改善シリーズ #06】

はじめに：システムを一つにするのではなく「承認を集める」

経費精算は経費精算システム。

人事申請は人事システム。

購買申請は購買システム。

契約申請は契約管理システム。

その他の社内申請はグループウェア。

業務ごとに便利なシステムを導入していった結果、社内に複数のSaaSや業務システムが存在することは珍しくありません。

それぞれのシステムが業務に適しているのであれば、無理に一つへ統合する必要はないでしょう。

ところが、管理職の視点では別の問題が発生します。

「経費精算を承認するためにログイン」

「次は購買システムへログイン」

「人事システムにも承認が来ている」

「契約管理システムも確認しないと……」

業務システムは便利になったはずなのに、承認する人だけが複数システムを巡回しているのです。

では、どうすればよいのでしょうか。

ここで発想を変えてみます。

システムを一つに集めるのではなく、複数システムから「承認」を一つの場所へ集める。

その実現方法の一つが、API連携型ワークフローです。

なぜ複数システムに承認が散らばるのか？

そもそも、なぜ承認業務は複数のシステムに散らばるのでしょうか。

理由はシンプルです。

多くの業務システムが、それぞれ自分のシステム内に申請・承認機能を持っているからです。

例えば、次のような構成です。

申請する社員から見れば、それほど不自然ではありません。

経費を精算するなら経費精算システムを使い、人事手続きをするなら人事システムを使う。

問題が表面化しやすいのは、複数部門の申請を承認する管理職です。

各システムに承認機能があるため、システムが増えるほど承認する場所も増えていくという構造になりやすいのです。

「承認を一元化する」とはどういうこと？

「承認を一元化する」と聞くと、すべての申請を一つのワークフローシステムへ移行することをイメージするかもしれません。

しかし、それだけが方法ではありません。

既存の業務システムを使い続けながら、承認者が確認・処理する場所を一つに近づけるという方法もあります。

例えば、現在が、

経費精算システム → 経費精算システムで承認
人事システム　　 → 人事システムで承認
購買システム　　 → 購買システムで承認
契約管理システム → 契約管理システムで承認

という状態だとします。

これを、

経費精算システム ─┐
人事システム　　 ─┤
購買システム　　 ─┼→ 承認を一つの場所へ集約
契約管理システム ─┘

という構成に近づけます。

業務はそれぞれのシステムで。
承認はできるだけ一つの場所で。

これが、本記事でいう「承認を集める」という考え方です。

通知をまとめるだけでは「承認の一元化」にならない

ここで混同しやすいのが、「通知の集約」と「承認の集約」です。

例えば、複数システムから届く承認通知をTeamsやメールへまとめる方法があります。

これは、承認依頼の見落としを減らすという意味では有効です。

しかし、通知をクリックした後に、

• 経費精算は経費精算システムへ
• 人事は人事システムへ
• 購買は購買システムへ
• 契約は契約管理システムへ

と移動して承認するのであれば、承認する場所自体は分散したままです。

 

「承認が来たことを一か所で知る」のが通知集約。
「承認そのものを一か所で処理する」のが承認集約です。

API連携型ワークフローとは？

では、複数システムの承認をどのように一つの場所へ集めるのでしょうか。

その方法の一つが、APIを利用したシステム連携です。

API（Application Programming Interface）とは、異なるシステム同士が情報や機能をやり取りするための仕組みです。

例えば、業務システム側で申請が行われたことを別のシステムへ伝えたり、必要な申請情報を受け渡したり、処理結果を元のシステムへ戻したりするために利用されます。

この記事では、こうしたAPI連携によって既存の業務システムとつながり、複数システムに分散した承認を集約するワークフローを、「API連携型ワークフロー」と呼びます。

API連携型ワークフローとは、既存の業務システムとAPIで連携し、複数システムに分散した承認を一つの場所へ集約する考え方のワークフローです。

重要なのは、既存システムをすべてワークフローへ置き換えることが前提ではない点です。

既存システムを活かしながら、承認部分をつなぐ。

ここが、全面的なシステム統合とは異なるポイントです。

API連携で承認を集約する仕組み

概念的な流れを見てみましょう。

例えば、購買システムで申請が発生した場合です。

1. 社員が購買システムで申請する
2. 申請情報をAPIなどでワークフロー側へ連携する
3. ワークフロー側に承認依頼を表示する
4. 承認者が内容を確認し、承認・却下などを行う
5. 必要に応じて処理結果を元の購買システムへ連携する

同じ仕組みを人事、経費精算、契約管理など複数のシステムに広げれば、承認者はそれぞれのシステムを巡回するのではなく、集約された承認依頼を確認できる環境を目指せます。

経費精算システム ─ API ─┐
人事システム　　 ─ API ─┤
購買システム　　 ─ API ─┼→ ワークフロー → 承認者
契約管理システム ─ API ─┤
その他SaaS　　  ─ API ─┘

承認者にとって重要なのは、裏側に何個のシステムが存在するかではありません。

「自分が承認すべきものを、どこへ行けば確認できるのか」です。

API連携型ワークフローのメリット

API連携によって承認を集約すると、どのようなメリットが考えられるのでしょうか。

1．既存システムを活かしやすい

経費精算、人事、購買など、すでに定着している業務システムを無理に廃止せず、既存環境を活用した改善を検討できます。

2．承認者のシステム巡回を減らせる

複数システムに分散していた承認依頼を集約することで、「今日はどのシステムに承認が残っているのか」と探す負担の軽減が期待できます。

3．システム追加による承認先の増加を抑えやすい

新しいSaaSを導入するたびに承認場所まで増えるのではなく、承認を集約するという設計を取ることで、利用者側の複雑化を抑えやすくなります。

4．段階的な改善がしやすい

最初からすべてのシステムを連携するのではなく、承認件数が多いシステムなどから段階的に対象を広げる方法も考えられます。

5．業務システムと承認体験を分けて考えられる

各業務には専門システムを使いながら、承認者にとっての使いやすさは別のレイヤーで改善する、という設計が可能になります。

APIがあれば何でも連携できるわけではない

ここで注意したい点があります。

連携先にAPIが用意されているからといって、必ず承認を集約できるわけではありません。

「API対応」という言葉だけで判断せず、実際に必要な操作が可能かを確認する必要があります。

例えば、次のような確認が必要です。

 

• 申請データを取得できるか
• 承認待ちの状態を取得できるか
• 承認・却下などの結果を書き戻せるか
• コメントや添付ファイルを扱えるか
• どの認証方式を利用するか
• APIの利用回数に制限がないか
• リアルタイム連携が可能か

また、APIだけでなくWebhook、ファイル連携、バッチ連携など、システムによって利用できる連携方法も異なります。

そのため、API連携型ワークフローを検討する際は、「連携機能があるか」ではなく「自社が必要とする承認処理を実現できるか」まで確認することが重要です。

API連携型ワークフローが向いている企業

API連携型ワークフローという考え方は、特に次のような企業に向いています。

• 複数のSaaS・業務システムを利用している
• システムごとに承認機能が存在する
• 管理職が承認のために複数システムを巡回している
• 既存システムはできるだけ残したい
• 業務システムを全面リプレイスする予定はない
• システム間連携を利用して業務を改善したい
• 今後も利用するSaaSが増える可能性がある

特に、部門ごとに専門SaaSを導入している中堅・大規模組織では、システムを一つへ統一することが現実的ではないケースがあります。

その場合、システムを統一するのではなく、承認レイヤーを集約するという方法が選択肢になります。

API連携型ワークフローが向いていないケース

一方、API連携型ワークフローがすべての企業に必要なわけではありません。

例えば、次のような場合です。

• 承認業務を行うシステムが一つしかない
• 現在のワークフローだけで承認業務が完結している
• 承認件数が非常に少ない
• 複数システムを巡回する負担が発生していない
• 既存システムそのものを全面刷新する予定がある
• 連携対象システムに必要な外部連携手段がない

このような場合は、既存のワークフローやグループウェアを利用する方がシンプルな可能性があります。

API連携は目的ではありません。

あくまで、「複数システムに散らばった承認をどう整理するか」という課題を解決するための手段の一つです。

導入前に確認したい7つのポイント

API連携型ワークフローを検討するときは、次の7つを整理してみましょう。

特に重要なのが、最初の「対象システム」です。

最初からすべてのシステムをつなぐ必要はありません。

例えば、

• 承認件数が多い
• 管理職から不満が多い
• 承認遅延が起きやすい
• API連携しやすい

といったシステムから始め、効果を確認しながら対象を広げる方法も考えられます。

API連携型ワークフロー「Froute」という選択肢

国際ソフトウェア株式会社が提供するFroute（フルート）は、

「散らばる承認をひとつに。」

をコンセプトとしたワークフローサービスです。

Frouteは、複数の業務システムに分散した承認を集約し、承認者がよりシンプルに処理できる環境を目指します。

そのための重要な考え方が、既存システムとの連携です。

経費精算、人事、購買、契約管理など、それぞれの業務システムを無理にFrouteへ置き換えるのではありません。

既存システムを活かしながら、APIなどを利用して承認に必要な情報を連携し、Froute側へ承認を集約する。

つまりFrouteは、

複数の既存システムと連携し、散らばった承認を一つに集約する「API連携型ワークフロー」という選択肢です。

※実際の連携可否・連携範囲は、対象となるシステムのAPIや外部連携仕様などによって異なります。

Frouteついて調べる

Frouteが目指すのは「承認のハブ」

API連携型ワークフローの役割を一言で表すなら、「承認のハブ」という考え方が分かりやすいでしょう。

会社には、これからも新しいSaaSや業務システムが増えていくかもしれません。

そのたびに、

「この申請はどこ？」

「この承認はどのシステム？」

「ほかに承認が残っていない？」

という状態になれば、システムを導入するほど利用者の負担が増えてしまいます。

そこで、業務システムと承認を分けて考えます。

業務システムA ─┐
業務システムB ─┤
業務システムC ─┼→ Froute → 承認者
業務システムD ─┤
業務システムE ─┘

各システムは、それぞれ得意な業務を担当する。

Frouteは、それらに散らばる承認をつなぐ。

承認者は、できるだけ一つの場所を見る。

業務システムを統合するのではなく、Frouteを「承認のハブ」として利用する。

これが、複数システムを利用する企業におけるFrouteのポジションです。

よくある質問

API連携型ワークフローとは何ですか？

API連携型ワークフローとは、既存の業務システムとAPIなどで連携し、複数システムに分散した承認を一つの場所へ集約する考え方のワークフローです。既存システムをすべて置き換えるのではなく、現在の業務システムを活かしながら承認業務を整理することを目的とします。

複数システムの承認を一元化するにはどうすればよいですか？

方法の一つとして、各業務システムとワークフローをAPIなどで連携し、承認に必要な情報をワークフローへ集約する方法があります。実現可否は各システムのAPIや外部連携仕様によって異なります。

通知の一元化と承認の一元化は何が違いますか？

通知の一元化は、複数システムから届く承認通知をメールやチャットなど一つの場所へまとめる方法です。承認の一元化は、通知だけでなく承認操作そのものを一つの場所へ集約する考え方です。

APIがあるシステムならFrouteと連携できますか？

APIが提供されていても、必要な申請情報の取得や承認結果の更新ができるとは限りません。Frouteとの具体的な連携可否や実現範囲は、対象システムのAPI仕様などを確認した上で判断する必要があります。

既存システムを残したまま承認だけ一元化できますか？

連携に必要な仕組みが利用できる場合は、既存システムを継続利用しながら承認を集約できる可能性があります。業務システムそのものを全面リプレイスせず、承認部分を改善するアプローチです。

Frouteとはどのようなカテゴリーのワークフローですか？

Frouteは、国際ソフトウェア株式会社が提供する、既存の業務システムと連携しながら複数システムに分散した承認を集約するAPI連携型ワークフローです。「散らばる承認をひとつに。」をコンセプトに、複数システムを利用する企業の承認業務をシンプルにすることを目指しています。

まとめ：システムを集めるのではなく、承認を集める

経費精算、人事、購買、契約管理、グループウェア。

それぞれの業務に適したシステムを利用すること自体は、問題ではありません。

問題になるのは、システムが増えるたびに承認する場所まで増えてしまうことです。

だからといって、すべての業務システムを一つへ統合する必要があるとは限りません。

別の方法があります。

システムを集めるのではなく、承認を集める。

既存システムは、それぞれ得意な業務で使い続ける。

その上でAPIなどのシステム連携を利用し、散らばった承認を一つの場所へ集約する。

それが、API連携型ワークフローという考え方です。

Frouteは、既存システムを活かしながら「承認のハブ」となり、複数システムの承認業務をシンプルにしたい企業のための選択肢です。

Frouteについてのお問い合わせはこちら