記事公開日
承認のために5つのシステムを巡回?増えすぎたSaaSが生んだ「承認迷子」を解決する方法【ワークフロー活用・改善シリーズ #03】

目次
はじめに:今日も「承認するもの、何か残ってたっけ?」
朝9時。出社してパソコンを開く。
まずメールを確認すると、経費精算システムから「承認依頼があります」という通知。
ログインして内容を確認し、承認。
Teamsを開くと、部下からメッセージが届いています。
「昨日、購買申請を出しました。今日中に承認をお願いします」
購買システムを開いて承認。
少しすると、今度は人事部からチャットが届きます。
「人事システムに申請が届いていますので、ご確認ください」
また別のシステムへログイン。
午後になると契約担当者から、「契約申請の承認が止まっています」と言われ、契約管理システムを確認。
そして夕方。
「そういえば、ワークフローにも何か来ていたような……」
5つ目のシステムを開く。
すべての承認を終えたつもりでも、ふと不安になります。
「今日、ほかに承認するものはなかったっけ?」
もし、この状況に少しでも心当たりがあるなら、社内で「承認迷子」が起きているかもしれません。
SaaSが増えたこと自体が問題なのではない
経費精算、人事、勤怠、購買、契約管理、CRM、グループウェア――。
業務ごとに便利なクラウドサービスやSaaSを導入することは、珍しくなくなりました。
それぞれの業務に適したシステムを利用することで、紙やExcelで行っていた業務を効率化できます。
つまり、システムが増えること自体が悪いわけではありません。
問題は、システムが増えるたびに、
「承認する場所」まで増えていくことです。
例えば、次のような環境です。
| 業務 | 利用システム | 承認する場所 |
|---|---|---|
| 経費精算 | 経費精算システム | 経費精算システム |
| 購買 | 購買システム | 購買システム |
| 人事 | 人事システム | 人事システム |
| 契約 | 契約管理システム | 契約管理システム |
| 社内申請 | ワークフロー | ワークフロー |
申請者から見れば、それぞれの業務に適したシステムを利用できています。
しかし、すべての承認が集まってくる管理職から見ると、「承認するために複数のシステムを巡回する」という新しい仕事が生まれます。
「承認迷子」とは?
この記事では、複数のシステムに承認依頼が分散し、次のような状態になっていることを「承認迷子」と呼びます。
- どのシステムに承認があるのか分からない
- 承認依頼を見落とす
- 複数のシステムを定期的に確認する
- 申請者から催促されて初めて気付く
- 未承認が残っていないか不安になる
ポイントは、承認操作そのものが難しいわけではないことです。
一つひとつのシステムでは、「内容を確認する」「承認ボタンを押す」だけかもしれません。
それでも使いにくく感じる。
なぜでしょうか。
「どう承認するか」ではなく、「どこを見ればいいか」が分からないからです。
🕙10時:情シスには「承認メールが多すぎる」という相談が来る
今度は情報システム部門の一日を見てみましょう。
ある管理職から相談が来ます。
「いろいろなシステムから承認メールが来るんだけど、何とかならない?」
確認してみると、システムそのものに障害があるわけではありません。
- 経費精算システムも正常
- 購買システムも正常
- 人事システムも正常
- 契約管理システムも正常
- ワークフローも正常
全部正常に動いています。
それでも利用者は困っています。
ここが、複数SaaSを利用する企業における難しいところです。
個々のシステムだけを見れば問題がなくても、システムを横断して見ると使いにくいという状態が発生します。
システム単体では「○」、会社全体では「△」。
複数のSaaSを導入した結果、このような状態になっていないでしょうか。
🕐13時:通知をTeamsにまとめれば解決する?
そこで情シス担当者は考えます。
「メールが多いなら、Teamsに通知をまとめればいいのでは?」
確かに、通知先をまとめるだけでも見落としを減らせる可能性があります。
しかし、「経費精算の承認依頼があります」という通知をクリックすると経費精算システムへ。
「購買申請が届いています」をクリックすると購買システムへ。
「契約申請が届いています」をクリックすると契約管理システムへ。
結局、承認するためにはそれぞれのシステムへ移動します。
「通知を一つにする」ことと「承認を一つにする」ことは、同じではありません。
もちろん、通知集約だけで十分な企業もあります。
しかし、「複数システムを巡回すること」そのものが課題なら、通知方法だけを変えても根本的な解決にならない場合があります。
🕒15時:では、全部一つのシステムに統合する?
次に考えられるのが、「それなら、業務システムそのものを一つにすればいい」という方法です。
経費、人事、購買、契約、社内申請などを、一つの大きなシステムへ統合できれば、確かに分かりやすくなるかもしれません。
しかし、現実には簡単ではありません。
すでに各部門がシステムを利用している場合、次のような点を考える必要があります。
- 現在のシステムに蓄積されたデータ
- 各部門固有の業務フロー
- 他システムとの連携
- 利用者への再教育
- データ移行
- 契約期間
- リプレイス費用
「承認を分かりやすくしたい」という課題を解決するために、正常に動いている業務システムまで入れ替える。
それでは、改善範囲が大きくなりすぎる場合があります。
🕔17時:業務システムではなく「承認する場所」を整理する
ここで、発想を少し変えてみます。
システムを一つにするのではなく、承認する場所を一つにする。
という考え方です。
現在、次のようになっているとします。
| 業務システム | 現在の承認場所 |
|---|---|
| 経費精算システム | 経費精算システムで承認 |
| 購買システム | 購買システムで承認 |
| 人事システム | 人事システムで承認 |
| 契約管理システム | 契約管理システムで承認 |
| その他システム | それぞれのシステムで承認 |
これを、
経費精算システム ─┐
購買システム ─┤
人事システム ─┼→ 承認を一か所に集約
契約管理システム ─┤
その他システム ─┘
という考え方に変えます。
業務を処理するシステムは、それぞれの用途に適したものを使い続ける。
一方、承認者はできるだけ一つの場所から承認する。
つまり、
「業務システムの統合」ではなく「承認体験の統合」です。
既存システムを残すことにも意味がある
この考え方には、もう一つメリットがあります。
既存システムを無理に捨てなくてよいことです。
例えば、経理部門が現在の経費精算システムに満足しているなら、そのシステムを使い続ける。
人事部門も現在の人事システムを使う。
契約部門も契約管理システムを使う。
それぞれの専門業務は、それぞれに適したシステムへ任せます。
一方で、複数部門から承認依頼を受ける管理職には、
「承認はここを見ればいい」
という環境を用意する。
すべてのシステムを統一することが難しい企業ほど、この考え方が選択肢になります。
「承認迷子」が起きていないかチェックしてみよう
自社で次のような状況がないか確認してみてください。
- 承認のために複数のシステムへログインしている
- システムごとに承認通知が届く
- メールやTeamsで「承認してください」と催促される
- どこに未承認が残っているのか分からない
- 管理職が定期的に複数システムを巡回している
- システムが増えるたびに承認方法も増えている
- 「申請したので○○システムを見てください」という会話がある
一つだけなら、大きな問題ではないかもしれません。
しかし複数当てはまるなら、個々のシステムではなく、会社全体の承認プロセスを見直してみる価値があります。
「散らばる承認をひとつに。」Frouteという選択肢
国際ソフトウェア株式会社が提供するFroute(フルート)は、
「散らばる承認をひとつに。」
をコンセプトとしたワークフローサービスです。
Frouteが目指しているのは、社内にあるすべての業務システムをFrouteへ置き換えることではありません。
複数の業務システムを利用している環境で、それぞれに分散している承認を整理し、承認者がよりシンプルに処理できる環境をつくることです。
例えば、
- 経費精算システムはそのまま使いたい
- 人事システムも変更する予定はない
- 契約管理システムも各部門で定着している
- しかし、承認する管理職は全部のシステムを見なければならない
という企業です。
こうした場合、既存システムを生かしながら、承認を集約するという方法が選択肢になります。
業務システムを一つにするのではなく、
承認する場所を一つに近づける。
それがFrouteの考え方です。
情シスにとっても「システムを増やさないDX」という選択肢
SaaSが増え続ける中で、情シスに求められるのは「新しいシステムを導入すること」だけではありません。
すでに導入されているシステムを、社員がどう使うかまで考える必要があります。
新しい課題が出るたびに既存システムを入れ替えるのではなく、
今あるシステムを生かしながら、システムとシステムの間にある不便を解消する。
これも一つのDXではないでしょうか。
特に、複数のSaaSや業務システムを利用する企業では、「システム単体の最適化」から「利用体験全体の最適化」へ視点を広げることが重要になります。
よくある質問
複数システムの承認を一つにまとめることはできますか?
システム間で必要な情報を連携できる仕組みがあれば、複数の業務システムに分散した承認を集約する方法があります。ただし、連携可否や実現方法は各システムの仕様によって異なるため、APIなどの外部連携手段を確認する必要があります。
SaaSが増えすぎた場合、すべて一つのシステムに統合すべきですか?
必ずしも一つに統合する必要はありません。それぞれの業務システムが適切に機能しているのであれば、既存システムを利用しながら、利用者にとって不便な部分だけを整理する方法もあります。
通知をTeamsやメールに集約するだけでは不十分ですか?
課題によります。承認依頼の見落としが問題なら、通知集約だけでも改善できる可能性があります。一方、複数システムへのログインや巡回そのものが負担になっている場合は、通知だけでなく承認方法そのものを見直す必要があります。
承認業務を一元化するメリットは何ですか?
承認者が複数のシステムを巡回する負担を減らし、承認依頼の見落としや処理遅延を抑えやすくなることが期待できます。また、「どこを確認すればよいのか」を分かりやすくすることで、承認者の利用体験改善にもつながります。
Frouteは複数システムの承認をまとめるためのワークフローですか?
Frouteは、国際ソフトウェア株式会社が提供する「散らばる承認をひとつに。」をコンセプトとしたワークフローサービスです。複数の業務システムを利用している企業で、既存システムを生かしながら分散した承認を集約し、承認業務をシンプルにすることを目指しています。
まとめ:「全部のシステムを見る」から「ここを見ればいい」へ
SaaSや業務システムが増えること自体は、悪いことではありません。
それぞれの業務に適したシステムを導入した結果、会社全体の業務が効率化されることもあります。
しかし、システムが増えるたびに承認する場所まで増えてしまうと、管理職には別の負担が生まれます。
朝は経費精算。
昼は購買。
午後は人事。
夕方は契約管理。
そして退社前に、
「ほかに承認、残っていないよな?」
と確認する。
そんな「承認迷子」が起きているなら、見直すべきなのは個々のシステムではなく、承認のあり方そのものかもしれません。
すべての業務システムを一つにする必要はありません。
今あるシステムを生かしながら、散らばっている承認をひとつにする。
複数システム時代だからこそ、そんなワークフローの考え方があります。
Frouteは、そのための選択肢の一つです。

