SaaS導入で“つながらない”を防ぐにはデータ連携の構造を意識する【第5回】

　営業、人事、経理、勤怠、購買など、さまざまな業務に対し最適なSaaS（Software as a Service）を導入することで現場の効率化は進みました。しかし、その便利さの裏側では、種々のSaaSが乱立し全体の整合が取れなくなる「SaaSスプロール」が多数、発生しています。

　SaaSスプロールが発生する原因は、導入しているSaaSの数の多さではなく、つながり方を整理しないままに導入を進めることにあります。SaaSごとに更新タイミングが違ったり、SaaS同士が自動で連携する機能を有していたりするためです。結果として「この申請はどこで承認されたのか？」「最新の顧客情報はどれが正しい？」といった混乱が生まれるのです。

SaaSの導入検討では、その役割をはっきりさせる

　SaaSの導入時には一般に、まずは機能比較をしたりUX（User Experience：顧客体験）を確認したりするでしょう。それと同時に大切なのが、そのSaaSが会社全体の中で、どんな役割を担うのかの明確です。

　例えば、勤怠管理のSaaSを導入するなら、次のような情報の出入りを検討段階から整理しておく必要があります。

●社員情報（所属や雇用区分）はどこからもらうのか？
●打刻や承認情報はどこへ渡すのか？
●このSaaSで完結させる業務と、他の仕組みと連携させる部分はどこか？

　SaaSを単体で便利に使うのではなく「誰が主で、誰が補うのか」という関係性を明確にすることがポイントです。この関係性を見誤ると、SaaSが本来の業務システムを支配する形になり、結果として全体の整合性が崩れていきます。

　なかでもSaaS導入で最も慎重に考えるべき領域が、顧客や社員、商品などマスターデータの扱いです。基本方針は「マスター情報は会社全体で共通の仕組み（人事や会計、基幹システムなど）で一元管理し、そこから各SaaSに配ること」です。これにより「どこが正しい情報を持っているのか」が明確になります。

　ただ現実には、営業用のSaaSで顧客情報を修正したり、勤怠のSaaSで所属を変更したりと、現場に近いSaaSで最新情報が先に更新されることもあります。それ自体は自然なことですが、問題は、その変更が会社全体に戻らず、システムごとに異なる情報が残ってしまうことです。

　つまり現場に近いSaaSがマスターに「印」を付けたにもかかわらず、他のシステムでは情報が古いままになってしまうことで、いくつもの“正しい情報”が生まれてしまいます。従って、次のように2段構えの構造を設計しておくことが重要です（図1）。

●基本の流れは「共通の仕組みからSaaSへ配る」
●例外的な流れは「SaaSで更新された情報を全体に戻す」

図1：マスターデータの連携では、いくつもの“正しい情報”の発生を防ぐ

　最近は、この“戻す”仕組みを支える考え方として、SaaSで更新された情報を全体へ反映する仕組みである「リバースETL」にも注目が集まっています。こうした設計を前提にしておけば、SaaS側で最新情報を書き込むことがあっても全体の構造は崩れません。

　つまり（1）共通の仕組みが基点になり、SaaSはそれを利用する立場にする、（2）現場で起きた更新も、その流れの中で正しく取り込むの2つを徹底することで「どこから情報が流れ、どこで整合が取れるか」を可視化しておくことが、SaaSスプロールを回避するための前提になります。