SaaSが増えて二重入力が残るとき、業務システムをどう見直すか

顧客管理、案件管理、請求、チャット。それぞれ便利なサービスを導入したのに、最後は担当者が情報を集めてExcelへ転記している。こうした状態では、製品を追加する前に、同じ情報がどこで作られ、どこへ渡るかを確認します。

目指すのは、必要な人が正しい情報を使って仕事を進められることです。サービスを一つにまとめるか、既存のサービスを連携させるかは、その後に決められます。

まず、同じ情報を書いている場所を数える

受注から請求までを架空の例として考えます。営業が顧客管理へ受注内容を入力し、担当者が案件管理へ転記し、月末には経理が請求のために入力し直しています。

転記だけなら短時間で済んでも、金額や請求先が変更されると、すべての記録を直す必要があります。どこかが古いままだと、確認のやり取りが増えます。

業務を整理する際は、次のような表を作ります。

この表の内容はあくまで例です。自社の運用では誰が正しい情報を確定するかを記入します。担当が曖昧なまま同期すると、誤った変更まで広がるおそれがあります。

情報ごとに、正式な記録を残す場所を決める

一つのサービスをすべての情報の管理元にする必要はありません。顧客情報は顧客管理、作業の進捗は案件管理という分担もできます。

同じ項目を複数の場所で自由に書き換えると、どの値を使うべきか判断しづらくなります。変更する場所と、他の場所へ反映する方向を決めます。訂正が入ったときに、誰が判断してどの記録を直すかも決めておきます。

すぐに連携を開発しなくても、更新する場所をそろえるだけで確認が減る場合があります。まず少ない作業で改善できるところを探します。

見直し方は、設定・連携・専用アプリの順に検討する

既存製品に必要な機能があるなら、設定や使い方の変更で対応できるか確認します。機能があることを知らず、別の表で補っている場合もあります。

製品間で同じ情報を使いたいなら、CSVの受け渡しやAPI連携を検討します。APIは、ソフトウェア同士が情報をやり取りするための仕組みです。月末にまとめて渡せればよい情報なら、常時同期する仕組みが必要とは限りません。

独自の承認や計算が残るなら、その部分を専用アプリで補う案を比較します。前の例なら、受注・作業完了・請求条件を照合し、確認済みの請求データを出力する仕組みです。既存の顧客管理や会計まで作り直すかどうかは別に判断できます。

連携は、失敗したときまで設計する

データを送れるだけでは、日々の仕事には足りません。送信に失敗した場合、重複した場合、あとから取消が入った場合の扱いも必要です。

エラーの通知先、処理済みの記録の確認方法、重複を避けて再処理する手順を決めます。運用担当者が毎回開発者を呼ばないと状況を確認できない仕組みでは、転記の代わりに別の負担が増えます。

利用中の製品についても、データ出力、接続方法、必要なプラン、追加料金を確認します。連携先の仕様が変わったときの対応も、保守の範囲に含めて検討してください。

削減できる費用は、利用料と作業時間を分けて測る

使わなくなるサービスがあれば、解約可能な時期と削減できる利用料を整理します。同時に、転記、照合、修正にかかる時間を、見直しの前後で測ります。

作業が減っても、給与などの支出が同じだけ減るとは限りません。残業や外注を減らすのか、空いた時間を顧客対応に使うのか、改善の使い道を決めて評価します。

新たに発生する開発・保守・接続費用も含めた比較は、業務システム開発の費用と運用費で説明しています。

一つの業務で、最後まで情報がつながるか試す

最初は一つの部署や取引の種類に絞り、登録から仕事の完了までを試します。通常の処理に加え、訂正や取消も実行してください。

その結果を見てから、対象業務を広げます。現在の製品を使い続ける案と、専用開発などの方式を比べるときも、同じ仕事を最後まで実行できるかが判断材料になります。

業務システム化の相談では、利用中のサービス名と、その間で手作業になっている部分をお知らせください。どの情報をどこへ渡す必要があるかを整理することが、開発範囲を考える出発点です。