SaaS製品を購入する際の注意事項


最近、チームの同僚がローカルプロダクトのSaaS移行評価を行っており、評価すべき内容を整理してくれていますが、なかなか良い内容だと思いますので、自身の経験を踏まえて加筆・削除をさせていただきました。ここでメモを書きます。ここでの内容は、新しい SaaS サービスを購入する場合のチェックリストにも当てはまります。

主に、サービスの可用性、SaaS とローカル展開の機能比較、パフォーマンス、セキュリティ、運用保守、データ移行、他社アプリケーションとの統合に分かれています。

サービスの可用性

サービスの可用性は、SLA とサービス サポートの 2 つの小さな側面に分けられます。

SLA

SLAとは、1年間にサービスが正常に利用できる時間の割合を指し、一般に商用SaaS製品のSLAは99.5%~99.9%となります。
この指標を検討する際には、2 つの要素を考慮する必要があります。1 つは、この製品を使用している社内の他のチームのニーズであり、この状況についてチームとコミュニケーションをとる必要があることです。もう 1 つは、この SaaS 製品のダウンタイムが発生する可能性があるため、特に注意してください。また、当社独自の商用製品が利用できなくなるため、顧客に対する当社の SLA に影響が生じ、SLA が基準を満たしていない場合、当社は損失を被ることになります。

サービスサポート

サービスサポートとは、問題が発生した場合に他社のサポートチームからサポートを受ける方法を指します。
一般的に、相手のサポートを得るにはいくつかの方法があります。

  1. 専用のサポート ページでケースを送信する
  2. 郵便
  3. WeChat、DingTalk、Slack などの特殊なコミュニケーション ソフトウェア
  4. 電話
  5. ビデオ会議

方法によって利便性は異なりますが、この点を評価する際には、上記の相手がどのようなサポートを提供してくれるかに加えて、次の2つの点にも注意する必要があります。1: ダウンタイムやその他の重要な事故に対して非常に重要な応答時間、2: さまざまな応答方法が別途請求されるかどうか、一部の企業 (特に外資系企業) はリアルタイム応答に対して別途請求するため、これに注意してください。

機能比較

同じ製品でもSaaS版とセルフデプロイ版では一部機能が異なる場合がありますので、新規購入でもローカル移行でも注意が必要ですので、相手のSaaSと相談するのがベストです。プリセールスとセルフデプロイメント プリセールス チャットすると、異なるメッセージが届く場合があります。

パフォーマンス

ここで説明するパフォーマンスは主にネットワークのパフォーマンスを指します。
企業のオフィス所在地の分散によれば、オフィス所在地が 1 か所しかない場合と、全国または世界中の複数の都市にオフィス所在地がある場合の 2 つの状況に分類できます。

オフィスの場所は 1 つだけ

この場合、企業が独自のコンピューター室を構築するかパブリック クラウドを使用するかに関係なく、製品を展開する際、サービスはユーザーに比較的近く、また企業の他のアプリケーションにも非常に近いものになります (ローカルのコンピュータ室、同じコンピュータ室の場合もあります)ので、一般的に言えば、ネットワークのパフォーマンスにはそれほど問題はありません。

ただし、SaaS サービスを購入する場合は、特にネットワークのパフォーマンスをテストし、一般ユーザーと統合システムを同時にテストする必要があります。
SaaS 企業は、投資を考慮して国内 (全世界) のすべての都市にサーバーを展開する可能性は低いため、使用場所が SaaS サーバーの場所から遠く離れている可能性があり、必然的にネットワーク パフォーマンスに影響を及ぼします。

複数のオフィス拠点がある

会社に複数の拠点がある場合、状況はさらに複雑になります。
オフィスの所在地が 1 か所のみの場合に考慮すべき上記の事項に加えて、一般に次の状況を考慮する必要があります。

  1. CDN
    に 3 つ以上のオフィス拠点があり、距離が遠い場合は、CDN への対応を検討することになりますが、そうでない場合は、サーバーの地理的位置をどのように選択しても、各オフィスのパフォーマンス要件のバランスをとることが困難になります。位置。

  2. 異なる場所間のデータ転送は、
    データのスター転送ではなくメッシュをサポートすることが好ましい。いわゆるメッシュは、任意の 2 点間でデータを直接送信できることを意味し、スター型は、すべての通信がサーバーを介してメッセージを中継することによってのみ通信できることを意味します。
    ただし、この点も実際のニーズに応じて決定されるため、すべてのシナリオでこの機能が必要になるわけではありません。

安全性

セキュリティはデータ セキュリティとネットワーク セキュリティに分けられます。

データセキュリティ

データをホストできないなど、特定の業界に制限を課す法律や規制がいくつかあります。そのため、SaaS サービスを購入する際には企業の法務チームと連絡を取り、将来の監査に備えて連絡の証拠を残しておくことが最善です。

法的制限がない場合でも、調達契約のデータセキュリティの部分を詳細に理解し、法務チームと慎重に調査および確認する必要があります。

サイバーセキュリティ

自己展開の場合、サービスはイントラネット上でのみアクセスできる可能性が高くなりますが、SaaS 製品はインターネットにリリースされることが多く、ネットワーク セキュリティに隠れた危険をもたらします。
次の点を考慮することをお勧めします。

  1. WAF の有無。これはパブリック ネットワークに公開されるサービスにとって重要です。
  2. 2FA、つまり二要素認証をサポートするかどうか
  3. 詳細なアクセス監査機能(誰が、どこで、いつ、何をしたか、成功したかどうか)はありますか
  4. 会社のセキュリティ チームとの共同評価 (一方で、チームは専門的な能力を利用してより完全な評価を実施でき、他方では、サポートを支援してくれる別のチームを見つけることができます)

データ セキュリティとネットワーク セキュリティに加えて、特に上場企業や多国籍企業では、法的要件がある可能性があるため、完全な監査機能が懸念されます。

運用保守管理

実際、SaaS 製品は運用保守ゼロが理想ですが、現状では運用保守ゼロにはならず、一般に運用保守には状態変化通知と監視の 2 つの側面に注意する必要があります。 。

ステータス変更通知

いわゆる状態変更通知とは、アップグレード、メンテナンス、障害時など、サービスの状態が変化したときに、効果的な方法でユーザーに事前に通知することです。

ほとんどの SaaS 製品は現在、管理者への通知の送信のみをサポートしていますが、製品のエンド ユーザーへの通知の送信はサポートしていません。管理者 (通常は自分たち) が通知を転送する必要があります。少数の管理従業員に依存しているため、この部分を自動化するのが最善です。手動で通知を中継するため、重要なノードで通知を逃すと重大な結果につながる可能性があります。

モニター

外部サービスを提供するシステムにはサポート監視が必要です。そうしないと、保守者は常に恐怖にさらされ、いつ「爆弾」が投げ込まれるかわかりません。

一部の SaaS 製品は、顧客に完全な監視および警報システムを提供し、再開発可能な API も提供しますが、これは理想的です。

ただし、監視システムを顧客に提供していない SaaS 製品もありますので、この場合でもこの製品を購入したい場合は、重要な機能やシナリオについてはブラックボックス監視を自分で行うことが最善です。本当に盲目で、どちらも知りません。

データ移行

自社サービス利用後にSaaS側に移行する場合は、データ移行を検討する必要がある 企業の情報セキュリティポリシーや法務が許せば、購入前に実際にデータ移行作業(POCなど)を行うのがベスト。「セールスの口、欺瞞の幽霊」、セールスやプリセールスの言葉を信用しないでください。本当に問題を抱え、頭を悩ませているのは私たちです。

他社アプリケーションとの統合

SaaS 製品と会社の他のアプリケーションを統合するには、機能とネットワーク アクセシビリティという 2 つの側面を考慮する必要があります。

機能が利用できるかどうか

この点は依然として上記の問題であり、同じ製品のセルフデプロイ版と SaaS 版の機能は完全に同じではない可能性があるため、実際に統合して動作するかどうかを確認する必要があります。少なくとも私の今までの経験からすると、たとえ相手が業界の一流企業であっても、書類に誤りや漏れがあるのは普通のことです。

ネットワークへのアクセシビリティ

SaaS 製品はパブリック ネットワークにリリースされることがよくありますが、同社のアプリケーションの多くはイントラネットにのみリリースされるため、ネットワークに到達できない、ネットワークのパフォーマンスが標準に達していないなど、通信中にネットワークの問題が発生する可能性があります。これを知るには実際のテストが必要です。

一般に、SaaS 製品を購入する場合、テストは非常に重要であり、落とし穴を最小限に抑えるために、関係者と可能な限りコミュニケーションを取り、より多くのテスト シナリオを検討する必要があります。

個人サイトにも同時掲載:http ://panzhixiang.cn/article/2022/10/4/54.html

おすすめ

転載: blog.csdn.net/u013117791/article/details/127251482