TechTargetジャパン
ERP
ERP
事例
中堅・中小企業の安易なSaaS移行はトラブルを招く

SMBのためのSaaS利用術【第1回】

中堅・中小企業の安易なSaaS移行はトラブルを招く

「SaaSは中堅・中小に適している」とよくいわれる。サービスは多岐にわたり、選択肢も多い。だが、コスト削減効果のみに着目して安易に導入すると、本来の業務効率を低下させてしまうことにもなりかねない。

公開 2009年05月26日 08時00分

更新 2012年09月04日 18時05分

著者

岩上由高

[ノークリサーチ]

印刷する Googleで優先するソースとして追加

　SaaS（Software as a Service）は業務システムの導入・運用コストを削減し、迅速で柔軟なシステム活用を実現する手段である。しかし、既存システムを単にSaaS化するだけでは十分なメリットは得られず、かえってコスト高になったり、業務効率を低下させることもある。そこで本連載では、4つの業務カテゴリを中心に中堅・中小企業にとって最適なSaaS活用ポイントを解説していくことにする。今回はまず総論として、SaaSに適した業務システム／適さない業務システムを正しく判断する手法について述べたい。

SaaSに適した業務システムとは何か？

　初期投資を抑え、迅速にシステムを展開できる――。これは、SaaSの大きなメリットだといわれている。ユーザーはサーバやアプリケーションを自前で用意する必要がなく、契約すればすぐに利用を開始できる。SaaSが変化の激しい時代にマッチしたIT活用形態の1つであることは確かだ。SaaSのメリットをユーザーに尋ねた調査結果でも、コスト削減効果を期待する声が最も多い。だが実際には、ハードウェアやソフトウェアといった「目に見えるコスト」だけではなく、既存業務システムとの連携といった「目に見えない／見えにくいコスト」にも目を向ける必要がある。

　例えば、グループウェアやメールといった情報系システムはSaaSの利用に適するとされている。しかし情報系システムであっても、現状把握を怠って安易にSaaSを導入すれば、そこには思わぬ落とし穴が潜んでいるのである。以下にそうした失敗事例を挙げてみよう。社内であれば比較的容易に実現できた連携も、社外と社内をまたぐ場合は種々の配慮が必要となる。また、自社のIT活用スキルとのバランスについても十分考慮しなければならない。

失敗事例1：製造業A社

グループウェアをSaaSへ移行したことでシングルサインオンができなくなった例

　A社では自社内でグループウェアパッケージを利用していたが、バージョンアップコスト削減を目的に、ホスティング業者が提供する同じパッケージ製品のSaaS版へと移行することになった。同じグループウェアパッケージということもあり、SaaS版への移行は何ら問題ないと判断された。ところがいざ運用を開始すると、自社で独自開発した業務システムとのシングルサインオンができない。業務システムを利用できない社員が続出し、業務効率の大幅な低下を招いてしまった。

　A社ではグループウェアと業務システムのシングルサインオンを「ドメインCookie」（※）によって実現していた。ドメインCookieを利用したシングルサインオンでは、対象となるシステムが同じドメインに属している必要がある。SaaS版へ移行したことによりグループウェアのドメインが変わってしまったことで、シングルサインオンが機能しなくなったのである。

　同じパッケージ製品での移行であったことで油断が生じ、SaaS版に移行しても変わる要素が何もないと安易に判断してしまったことが失敗の要因だといえる。

※ドメインCookie：Webアプリケーションがログイン済みのユーザーを特定するためには、通常Cookieという仕組みを用いる。このCookieはサーバ単位で発行されるため、異なる複数の業務システムで同じCookieを共有することができず、シングルサインオンを実現することができない。そこで、同じドメインに属するサーバ間で共有することができるようにしたものがドメインCookieである。

失敗事例2：小売業B社

SaaSメールサービスへ移行したことで受注処理システムに支障を来した例

　B社では自社内でメールサーバを運用していたが、運用管理人員削減に伴ってSaaSによるメールサービスへと切り替えた。ところが、切り替え直後から顧客からの注文メールが届かなくなってしまったのだ。

　B社ではWebサイトから顧客が注文すると、その内容が自社のメールサーバを経由して受注担当者に届く「受注処理システム」を構築していた。SaaSへと切り替えたことによって、発注システムから送信されたメールはSaaS側のメールサービスに届けられる経路に変更される。しかし、SaaS側メールサービスはメール転送の踏み台になることを避けるため、外部からのメール送信を受け付けないようになっていた。

　メール送信時に認証を行う、SMTP認証と呼ばれる機能を受注処理システムに追加すれば解決できるが、それにはカスタマイズ費用が発生してしまう。結局、B社では受注処理システムとの連携のために従来のメールサーバも残すことになってしまった。

　メールというとユーザーが使うものと思われがちだ。しかし、この例のように意外なところでシステム連携の手段として活用されているケースも少なくない。SaaSへ移行する前に自社内の業務プロセスを一通り点検し、移行後に問題が生じないかを綿密に確認しておくことが肝要だ。

失敗事例3：サービス業C社

SaaSのバージョンアップサイクルにユーザーが追随できなかった例

　C社では営業支援システムパッケージを自社内で運用していた。しかし、パッケージのバージョンアップに伴う作業コストが負担となっていたため、SaaS形態の営業支援システムへと切り替えることにした。

　SaaS形態のサービスへ変更したことにより、バージョンアップに伴うシステム関連の作業コストは大幅に削減することができた。しかし、同サービスを利用する営業担当部門からは戸惑いと不満の声が多く上がり、結果的に営業効率の低下を招いてしまった。

　実は、C社がITを積極的に活用するようになったのはごく最近である。そのため、営業担当者は自社内で運用していた営業支援システムの習得に半年近い期間を要していた。SaaSへと変更する際も、新しい営業支援システムに慣れるまでに多くの時間を要することは明らかだった。しかし、経営層からのコスト削減方針に従い、営業担当は再度習得に励むことにしたのである。

　ところが、SaaS形態の新しい営業支援システムにもようやく慣れてきたころ、サービスがバージョンアップし、使い勝手が変わってしまった。このサービスは年数回のバージョンアップを行うため、営業担当はそのたびに新しい画面操作を覚えなければならない。このことが営業効率を少なからず低下させる結果となってしまったのである。

　SaaSのメリットの1つとして、「最新の機能を常に利用できる」というものがある。しかし、これは裏を返せば「ユーザーはバージョンアップの内容や時期をコントロールできない」ということになる。もちろん、多くの場合は下位互換性が考慮されており、使い勝手が急激に変わってしまうことはない。だが、C社のようにIT活用に慣れていない企業の場合、少しの変化であっても現場に大きな影響を及ぼしてしまうことがある。

　「SaaS＝バージョンアップコストが掛からない」というコスト削減面だけでなく、「自社のユーザーがSaaS側のバージョンアップに追随できるスキル、リテラシーを持っているか」ということも考慮に入れることが重要だ。

業務システムの特性を理解せよ

　自社の業務システム全体をとらえず、特定業務システムのみを対象とした個別のSaaS活用を考えてしまったことが、これら失敗事例の根本原因である。まずは自社で利用している業務システム全体を分類し、ふかんしてみることが大切だ。

　以下に、業務システムを幾つかのカテゴリに分類し、各カテゴリのSaaSに関連した特性を整理することで、どのカテゴリのSaaS移行を優先して検討すべきかを考える際に役立つマトリクスを作成してみる。業務システムの分類にはさまざまな方法があるが、本稿では大まかに以下の4つのカテゴリに分類した。

顧客管理系（SFA、CRM、コールセンター業務など）
基幹系（経費精算、原価管理など）
情報系（メール、グループウェアなど）
運用管理系（セキュリティ、バックアップ、アーカイビングなど）

　また、それぞれの業務システムについて、

どのように導入、運用されているか
パッケージ利用か、あるいは独自開発か
自社内運用か、あるいは運用を社外に委託しているのか

などといった現状を把握しておくことが重要だ。この現状把握を行う際にチェックすべきポイントを、ここでは「業務システム特性」と呼ぶことにする。SaaSを検討する際に特に重要となる業務システム特性は以下の通りである。

初期導入コスト

　業務システム構築に際してのパッケージ購入費用や導入費用の高さを示す指標である。一般にパッケージライセンス費用が高い基幹系やハードウェア投資を必要とする運用管理系で高くなる傾向がある。

自社運用負担度

　自社で運用を行うことがどれだけ負担となるかの指標である。例えば、データバックアップを行おうとするとストレージ投資が必要となる。従って、運用管理系業務において大量のデータをバックアップしている場合には自社運用負担度は高いということになる。

カスタマイズ度

　自社業務に適合させるためにパッケージなどの既製品にどれだけ手を加える必要があるかの指標である。一般的に基幹系は独自開発やカスタマイズが多いため、カスタマイズ度は高いということになる。

データ連携度

　その業務の遂行において、他業務システムとのデータ連携が必要とされる度合いを示す指標である。顧客管理系では基幹系の販売管理や在庫管理と連携が必要になるケースもある。従って、顧客管理系はデータ連携度が比較的高いといえる。

データ秘匿度

　その業務で扱うデータが社外に漏えいすることのリスクを示す指標である。いずれの業務においても漏えいリスクは存在するが、一般的に基幹系業務のデータは特に漏えいリスクが高いといえる。

　以上をまとめると以下の表のようになる。

業務システム特性別レベル
	顧客管理系	基幹系	情報系	運用管理系
初期導入コスト	中	高	低	中
自社運用負担度	中	中	低	高
カスタマイズ度	高	高	低	低
データ連携度	高	高	低	低
データ秘匿度	高	高	中	低
出典：ノークリサーチ（2009年5月）

業務システム特性から見たSaaSのメリット／デメリット

　次にSaaSのメリットを上記の業務システム特性と照らし合わせてみると、以下のような結論を導き出せる。

業務システムの運用を他社に預けることで自社の運用負担を軽減できる

→自社運用負担度の高い業務システムに対して効果的

自社業務に合わせたきめ細かな設定変更が可能である

→UI（ユーザーインタフェース）変更などカスタマイズ度が中程度の業務システムに対して効果的

マッシュアップやWebサービスAPIを活用したデータ連携が可能である

→インターネット上のデータ連携度の高い業務システムに対して効果的

ハードウェア投資が不要なため、初期導入コストを抑えられる

→初期導入コストの高い業務システムに対して効果的

　一方、SaaSのデメリットと業務システム特性を照らし合わせた結果は以下の通りである。

データを社外に預けることになるため、対象となるデータに関するユーザー側のセキュリティポリシーがそれを許容している必要がある

→データ秘匿度の高い業務システムは不向きである

　以上を踏まえると、SaaSに適している業務システム特性は以下となる。

自社運用負担度：高

カスタマイズ度：中

データ秘匿度　：低

データ連携度　：高（ただしインターネット上の連携）

初期導入コスト：高

　上記に完全に当てはまる業務システム特性を持ったカテゴリは残念ながら現時点では存在しない。しかし、現在の業務システムをこのような形で整理、ふかんすることで、自社業務システムのどの部分でSaaSを活用すればいいのかを検討できるはずである。

　さて、次回以降では、業務システムの特性とSaaSがもたらすメリット／デメリットとの兼ね合いを「顧客管理系」「基幹系」「情報系」「運用管理系」の各カテゴリごとに詳しく見ていく予定だ。

＜筆者紹介＞

岩上由高

ノークリサーチシニアアナリスト

ソフトウェアベンダー数社でソフトウェア製品の企画、設計、開発、コンサルティング、トレーニングなどに携わった後、ノークリサーチに入社。シニアアナリストとしてITのさまざまな領域の調査・分析に従事し、その成果を記事執筆やコンサルティング活動を通じて積極的に発信している。

印刷する

この記事の著者

岩上由高

中堅・中小企業の安易なSaaS移行はトラブルを招く