ワークフローは全部入れ替えなくていい。既存システムを活かして承認だけをまとめる方法【ワークフロー活用・改善シリーズ #04】

はじめに：ワークフロー刷新、本当に「全部入れ替え」が必要ですか？

「今のワークフローが使いにくくなってきた」

「システムが増えて、承認する場所がバラバラになっている」

「そろそろワークフローをリプレイスした方がいいかもしれない」

そんな話が社内で出たとします。

すると、次に考えるのは新しいワークフローシステムへの入れ替えです。

現在の申請を洗い出し、新しい製品を比較して、データを移行して、承認ルートを再構築して、社員へ操作方法を説明する。

さらに経費精算、人事、購買、契約管理など、それぞれの業務システムにも申請・承認機能がある。

「これも新しいワークフローへ移した方がいいのだろうか？」

「せっかく刷新するなら、全部まとめた方がいいのでは？」

こうして検討範囲がどんどん広がっていきます。

しかし、ここで一度考えてみましょう。

ワークフローを刷新するために、本当にすべてのシステムを入れ替える必要があるのでしょうか？

実は、現在利用しているシステムをそのまま活かしながら、「承認する部分だけ」を整理するという考え方もあります。

「リプレイス＝全面刷新」と考えると、話が大きくなる

システムのリプレイスという言葉から、「古いシステムを廃止して、新しいシステムへ置き換える」ことをイメージする方も多いでしょう。

もちろん、既存システムそのものに問題がある場合は、それが必要です。

しかし、ワークフローの課題を整理してみると、必ずしもすべての機能に問題があるとは限りません。

例えば、こんな会社を考えてみます。

• 経費精算システムは経理部門に定着している
• 人事システムも特に問題なく利用できている
• 購買システムも業務に合っている
• 契約管理システムも継続して利用したい

それでも管理職からは、こんな声が出ています。

「承認するシステムが多すぎる」

「どこに承認依頼が来ているのか分からない」

「全部のシステムを確認するのが面倒」

この場合、問題なのは経費精算や人事、購買、契約管理の機能ではありません。

問題なのは、それぞれのシステムに「承認」が分散していることです。

それなのに「ワークフローを刷新するなら全部入れ替えよう」と考えると、解決したい課題よりもプロジェクトが大きくなってしまいます。

問題がないシステムまで入れ替える必要はない

長年利用してきた業務システムには、すでに多くのものが蓄積されています。

• 過去のデータ
• 自社に合わせた設定
• 他システムとの連携
• 社員の操作経験
• 部門ごとの運用ルール

これらも企業にとっては資産です。

例えば経費精算システムを入れ替えるとなれば、単純に新しい製品を契約するだけでは済みません。

データ移行、設定、テスト、社員教育、マニュアル変更、問い合わせ対応などが必要になる可能性があります。

新しいシステムが他のシステムと連携しているなら、その影響も確認しなければなりません。

もちろん、現在のシステムに大きな問題があるのであれば、こうした負担をかけても刷新する価値があります。

しかし、現在の業務システムそのものには大きな問題がなく、困っているのが「承認の分散」だけなのであればどうでしょうか。

「問題のない部分は残す。問題のある部分だけ変える。」
そんなリプレイスの考え方もあります。

見直すべきは「システム」ではなく「承認する場所」かもしれない

ここで、現在のシステム構成を「業務」と「承認」に分けて考えてみます。

例えば、社内で次のようなシステムを利用しているとします。

こうして整理すると、入れ替えるべき対象が見えてきます。

業務システムそのものではなく、

「承認する場所が分散している」という部分だけを改善すればよい可能性があります。

リプレイスを検討するときに重要なのは、「何を新しくするか」を先に決めることではありません。

「現在のどこに問題があるのか」を切り分けることです。

既存システムを活かして「承認だけ」をまとめる

そこで考えられるのが、既存の業務システムを残しながら、承認を集約する方法です。

現在は、

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

となっている。

これを、

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

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

経費精算は、これまで通り経費精算システム。

人事業務も、これまで通り人事システム。

購買も契約管理も、それぞれの専門システムを利用します。

変えるのは、承認者の体験です。

業務システムはそのまま。
承認する場所だけを一つに近づける。

これなら、「承認を改善するために、正常に動いているシステムまで入れ替える」という大掛かりなプロジェクトを避けられる可能性があります。

全面刷新と「承認だけ集約」は何が違う？

全面リプレイスと、既存システムを活かした承認集約の違いを整理してみます。

どちらが優れている、という話ではありません。

重要なのは、自社の課題に対して、どこまで変更する必要があるのかです。

既存システムそのものが老朽化しているのであれば、全面刷新が適していることもあります。

一方、既存システムには満足していて、承認だけが不便なのであれば、変更範囲を絞った方が合理的な場合があります。

既存システムと共存する方法が向いている企業

では、既存システムを活かしながら承認を集約する方法は、どのような企業に向いているのでしょうか。

例えば、次のようなケースです。

• 複数のSaaS・業務システムを利用している
• 各部門で利用しているシステムが異なる
• 既存システム自体には大きな不満がない
• 承認者だけが複数システムを巡回している
• 「申請したので○○システムを見てください」という連絡が多い
• 既存システムを一斉にリプレイスするのは難しい
• 段階的に業務を改善したい

特に、各部門がそれぞれ最適なSaaSを導入してきた企業では、すべてを一つに統一することが難しい場合があります。

そのような企業では、システムを統一するのではなく、システムを横断する「承認」を整理するという発想が有効です。

逆に、全面リプレイスを検討した方がよいケース

一方で、既存システムを残すことが常に正解というわけではありません。

例えば、次のような場合はシステムそのものの刷新を検討する必要があります。

• 既存システムのサポート終了が近い
• セキュリティ面で問題がある
• 現在の業務に必要な機能が不足している
• 操作性に大きな問題がある
• システム維持・改修の負担が大きい
• 特定の担当者しか運用できない
• 他システムとの連携が難しい

この場合、「承認だけ」を改善しても根本的な課題は残ります。

大切なのは、

「全部残す」か「全部捨てる」かの二択にしないことです。

残した方がよいシステムは残す。

変える必要があるシステムは変える。

承認だけ改善できるなら、承認だけ変える。

このように対象を切り分けることで、現実的なリプレイス計画を立てやすくなります。

既存システムと連携するときに確認したいポイント

既存システムを活かして承認を集約するには、それぞれのシステムと連携できるかを確認する必要があります。

特に確認したいのは次のような点です。

• APIなど外部システムとの連携手段が用意されているか
• どの情報を外部へ受け渡せるか
• 承認・却下などの結果を元システムへ戻せるか
• ユーザーや組織情報をどのように管理するか
• 認証・権限をどのように扱うか
• エラーが発生した場合にどのように検知するか

ここは重要なポイントです。

「APIがある＝簡単に連携できる」とは限りません。

必要なデータを取得できるのか、承認結果を書き戻せるのか、認証方式に対応できるのかなど、連携対象となるシステムごとの確認が必要です。

そのため、既存システムと共存するワークフローを検討するときは、製品機能だけでなく、システム連携について相談できる提供会社かどうかも確認するとよいでしょう。

既存システムと共存するFrouteという選択肢

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

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

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

Frouteが目指しているのは、現在利用しているすべての業務システムをFrouteへ置き換えることではありません。

既存システムを活かしながら、複数のシステムに散らばった承認をまとめる。

という考え方です。

例えば、経費精算は現在の経費精算システム。

人事は現在の人事システム。

購買や契約管理も、それぞれ現在利用しているシステム。

それらを無理に廃止するのではなく、システム連携によって承認業務をFrouteへ集約することで、承認者にとって分かりやすい環境を目指します。

つまりFrouteは、

「既存システムか、Frouteか」

という二者択一ではなく、

「既存システムとFrouteを組み合わせる」

という選択肢です。

「今使っているシステムは変えたくない。でも承認業務はもっとシンプルにしたい」

そんな企業にとって、既存システムと共存するワークフローという考え方があります。

Frouteについて調べる

「システムを減らす」だけがDXではない

システムが増えると、「できるだけ一つに統合した方がよい」と考えたくなります。

確かに、重複したシステムを整理することは重要です。

しかし、業務ごとに必要な機能は異なります。

経費精算には経費精算に適したシステム。

人事には人事に適したシステム。

契約管理には契約管理に適したシステム。

それぞれの専門システムを活かした方がよい場合もあります。

そこで必要になるのが、システム同士をどうつなぎ、社員にとって使いやすい環境をつくるかという視点です。

システムを一つにすることが目的ではありません。
業務をシンプルにすることが目的です。

既存システムを活かしながら、システム間にある不便を解消する。

これもDXの一つの進め方です。

よくある質問

ワークフローを刷新するとき、既存システムもすべて入れ替える必要がありますか？

必ずしもすべてを入れ替える必要はありません。既存システム自体に問題がなく、承認の分散だけが課題であれば、現在のシステムを活かしながら承認部分を集約する方法もあります。

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

既存システムにAPIなどの外部連携手段があり、必要な情報を連携できる場合は、既存システムを利用しながら承認を集約できる可能性があります。実現方法は連携対象となるシステムの仕様によって異なります。

全面リプレイスと承認だけを集約する方法は、どちらがよいですか？

既存システムそのものに課題がある場合は全面リプレイス、既存システムには問題がなく承認の分散が課題である場合は承認集約が選択肢になります。どちらかを先に決めるのではなく、現在の課題を切り分けて判断することが重要です。

既存システムとの連携では何を確認すればよいですか？

APIなどの連携手段、取得できるデータ、承認結果の書き戻し可否、認証方式、ユーザー・組織情報の管理方法などを確認します。「APIがある」というだけではなく、実際に必要な承認フローを実現できるかを確認することが重要です。

Frouteは既存システムと共存できるワークフローですか？

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

まとめ：「全部変える」から「必要なところだけ変える」へ

ワークフローのリプレイスを検討すると、つい「新しいシステムへ全部移行する」という発想になりがちです。

しかし、現在利用しているシステムすべてに問題があるとは限りません。

経費精算は問題ない。

人事システムも問題ない。

購買システムも問題ない。

契約管理システムも問題ない。

でも、承認する管理職だけが困っている。

それなら、見直すべきなのはシステム全体ではなく、「承認する場所」かもしれません。

リプレイス＝全部捨てる、ではありません。
今あるものを活かしながら、必要なところだけ変えるという選択肢があります。

既存システムを残しながら、散らばった承認をひとつにする。

Frouteは、既存システムと共存しながら承認業務をシンプルにしたい企業のための選択肢です。

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