Salesforceの組織戦略（Org Strategy）について考える～第二回目～

前回は、Salesforce組織を一つもしくは複数で運用する場合のメリット/デメリットとユースケースを2つほど挙げてみました。今回は実際に考えられる事例も考慮し、組織戦略を検討する上でキーとなるクライテリアについて考えてみたいと思います。

余程大規模や会社組織全体に関わるSalesforce導入で無い限り、最初から単一組織が良いか複数組織が良いかまでを検討する必要は無いかもしれませんが、将来もSalesforceを多岐にわたり活用を拡げていきたいと考えられている方やそのようなユーザの導入を支援する立場の方には、導入計画時に幾つかのクライテリアにつき是非考えておいて頂ければと思います。

そもそも導入する地域や国が異なる場合には単一組織でまとめる理由があるのかというポイントです。利用言語も異なる、利用する会社組織も異なる、縦横の繋がりやコミュニケーション上の共有も不要な場合は、Salesforce組織を一つにして管理上まとめたり、統制を効かせたりする必要も無いかもしれません。システム管理者や設定・開発担当者が1ヵ所にしかおらず言語、タイムゾーンの問題も起きない場合は、システムサイドの理由から一つの組織でロール、プロファイル、アプリケーション、オブジェクト等を内部的に切り分けて運用することはあるかと思います。
但し、地域や国を跨って数字を管理する必要がある場合、業務をこなす上で情報共有・連携が必要な場合は、レポート、ダッシュボード、プロセス/タスク割当て、Chatter等の領域において1組織で運用した方がメリットを出せるはずです。
その代わりトレードオフとしてアクセス対象となるデータ、オブジェクトが集中管理のためLarge Data Volume (LDV)となる可能性も比較的高くなりますので、データ検索、レポーティング・分析時の考慮もしておく必要があります。

地域/国は同じでも利用するユーザ層が全く異なる場合、上記と同様の考え方が適用できると思います。これは会社内のユーザという観点と社外のパートナーや顧客がユーザでパートナー・コミュニティやカスタマー・コミュニティを利用する場合も同様かと思います。共通の業務アプリケーションや業務プロセスの連続性があるアプリケーションを利用している場合は組織が分かれない方が利用者的にもそれを管理する管理者側にもメリットが出やすいということもあります。
また、数に言及したのは、とはいえSalesforceで過去経験の無いようなユーザ数で利用する場合（そういったケースはほぼ無いでしょうが）には、そもそも単一組織で処理するにあたり問題が無いか、気にした方が良いでしょうということです。

salesforce.comがEnterprise EditionやUnlimited Editionのライセンス体系を用意しており、多数のアプリケーション、オブジェクトをサポートしていることから、1組織に相当数のアプリケーション、オブジェクトを作成しても問題無く稼働することは事実です。但し、そこで扱うアプリケーションの開発ライフサイクルがアプリケーション毎に全く異なったり、ストアするデータボリュームが極端に大容量であったりする場合に、アプリケーションとデータを更新/メンテナンスする際にSalesforce組織を分けておいた方が工数や手間が少なく済む場合もあるかもしれません。SandBoxリフレッシュのタイミング/運用や本番リリースの観点を含めるとリソース計画/管理/調整すべきことが増えることも考えられます。SandBoxの追加購入の意思決定にも影響するかもしれません。

システム連携の観点から単一か複数かの判断に影響する可能性もあります。例えば連携先のシステムが複数のSalesforce組織と連携する場合に連携対象データの数に加えて（共通データがある場合は掛けて）接続ポイントを用意する必要が出てきます。その手間を軽減するためにSalesforce組織へ直ではなく連携サーバー（ETL/EAI）側で吸収するということがありますが、共通の連携先や開発アプリケーションがある程度事前に想定できる場合は、組織戦略上、検討しておいた方がよい項目です。連携方式とデータ量については、双方の観点でメリット/デメリットが考えられます。共通の連携方式で処理する場合や同じデータソース/ターゲットが対象の場合はSalesforceも一つにまとめた方が効率的と捉えられる観点と連携処理数自体が多い場合やデータボリュームが大きい場合に1組織24時間以内に適用されるAPIやApexのガバナ制限、処理の順次性・並列対応の可否から夜間処理、バッチ処理ウィンドウ内に収まるかどうかの観点で複数組織化を検討すべきケースもあるかもしれません。もちろん連携処理だけを理由に複数組織化するのではなく、他の幾つかのクライテリアと合わせた結果の解として導き出されるものであると思います。

よく聞く話としてSalesforceはクラウドサービスなので不要になった場合は、止めることも簡単にできますよ、ということもメリットに挙げられます。もちろんライセンス契約上の最低限の縛りというものがあるのでそれに抵触しない限りにはなりますが、ハードウェア、ソフトウェアを購入している訳では無いので、サービス・サブスクリプションを解約するだけですのでやはり簡単には違いありません。その特性故、企業が実施する一時的なキャンペーン対応のため、期間限定の製品/サービスのビジネスのため、災害時の緊急対応のためなど、1アプリケーションやサブシステムとして既存利用のSalesforce組織上に構築するよりも、別の組織として立ち上げた方が使用後の削除処理や修正対応が容易なケースもあります。もちろん、他のアプリケーションやデータとの連携や後々再利用するために組織を共通化しておいた方が良い場合もあると思いますのでケースバイケースで考慮する必要はあると思います。

既に各クライテリアにおける説明でも言及しましたが、共通/共有点、関連性、類似性は重要なキーワードです。例えばある企業でSalesforce上に構築したいアプリケーションが少し極端ですが50あったとしましょう。その場合、皆さんであればどうされますでしょうか。仮にSalesforceのことをよくご存知無い方でも、このブログ記事をここまで読まれた方であれば一考頂けるはずです。クライテリアとして挙げさせて頂いた項目につき一旦立ち止まり考えて頂ければ幸いです。特に各アプリケーションにおけるユーザ層の共通性（組織間における重複ユーザの有無等）、アプリケーションの類似性（アプリケーションそのものに加えて連携先のシステム、デバイスの共通性含め）、共通/共有オブジェクトあるいはデータベースの有無（同じマスターを参照する、データ項目が共通している等）を分析、検討してみることにより、後々の余分な作業や苦労を回避、軽減できる可能性があります。

今回、幾つかクライテリアを考えてみました。これ以外にも検討すべき点ももちろんあるかとは思いますが、代表的な事項として捉えて頂ければ幸いです。次回は、単一組織もしくは複数組織で運用する場合それぞれで特に考慮すべき項目とそれに対するソリューション例につき考えてみたいと思います。