株式会社セールスフォース・ドットコム

カスタマーサクセス本部 エンタープライズサクセス部

カスタマーサクセスマネージャー

杉本 新也

大規模･グローバル展開のためのSalesforce運用方法とは?＜ ガバナンスフレームワークのご紹介 >

Salesforce World Tour Tokyo 2016

Forward-Looking Statements

Statement under the Private Securities Litigation Reform Act of 1995:

This presentation may contain forward-looking statements that involve risks, uncertainties, and assumptions. If any such uncertainties materialize or if any of the assumptions proves incorrect, the results of salesforce.com, inc. could differ materially from the results expressed or implied by the forward-looking statements we make. All statements other than statements of historical fact could be deemed forward-looking, including any projections of product or service availability, subscriber growth, earnings, revenues, or other financial items and any statements regarding strategies or plans of management for future operations, statements of belief, any statements concerning new, planned, or upgraded services or technology developments and customer contracts or use of our services.

The risks and uncertainties referred to above include – but are not limited to – risks associated with developing and delivering new functionality for our service, new products and services, our new business model, our past operating losses, possible fluctuations in our operating results and rate of growth, interruptions or delays in our Web hosting, breach of our security measures, the outcome of any litigation, risks associated with completed and any possible mergers and acquisitions, the immature market in which we operate, our relatively limited operating history, our ability to expand, retain, and motivate our employees and manage our growth, new releases of our service and successful customer deployment, our limited history reselling non-salesforce.com products, and utilization and selling to larger enterprise customers. Further information on potential factors that could affect the financial results of salesforce.com, inc. is included in our annual report on Form 10-K for the most recent fiscal year and in our quarterly report on Form 10-Q for the most recent fiscal quarter. These documents and others containing important disclosures are available on the SEC Filings section of the Investor Information section of our Web site.

Any unreleased services or features referenced in this or other presentations, press releases or public statements are not currently available and may not be delivered on time or at all. Customers who purchase our services should make the purchase decisions based upon features that are currently available. Salesforce.com, inc. assumes no obligation and does not intend to update these forward-looking statements.

Salesforceの定着化･活用支援体制ご利用開始後も、定着化や更なる活用促進に役立つ様々なサービス･リソースをご提供し、お客様のビジネス変革･成功をご支援

営業(アカウントエグゼクティブ)お客様への提案活動･契約全般に対する窓口

ソリューションエンジニア(SE)提案･事前検討段階での技術ご相談窓口

コンサルタント *有償契約

プロジェクトにおける技術的な対応、システム要件および課題の明確化と優先順位の設定のご支援、リスクが適切に管理された導入プランの策定、支援

カスタマーサクセスマネージャー(活用支援担当)

利用定着化･適用範囲拡大の継続的な促進を支援

サポート製品仕様や稼働状況等の各種お問い合わせに対応

定着化･活用のための各種リソース

【トレーニング】・オンライントレーニング/Trailhead・ハンズオントレーニング（有償）・プライベートトレーニング（有償）

【ノウハウ、相談】・サクセスコミュニティ・ウェブセミナー・オンライン相談会・サクセスナレッジ

【ユーザグループ】・グループChatter・製品別/地域別勉強会

お客様

本セッションのアジェンダ大規模・グローバル展開を進めるお客様において、いかにプロジェクトの推進・定着化･活用促進を進めるか？ 多くのお客様事例に基づいた弊社のベストプラクティスを、事例を交えご紹介致します。

アジェンダ：

1. ガバナンスフレームワーク

2. Center of Excellence(COE)

3. Salesforce組織戦略

4. 変更要求管理

5. 技術標準化

ガバナンスフレームワーク

Salesforceの導入･定着化/活用を推進ビジネス価値を生み出す枠組み

Salesforceは何が違うのかクラウドを活用する事で、お客様のリソースを転換しビジネスの革新に集中

ビジネスアナリスト

インフラ管理

ガバナンス・変更管理/開発

ビジネスアナリスト

ITリソース

ビジネス革新

インフラ管理

ガバナンス・変更管理/開発

従来 Salesforce

ビジネスを常に指向し、変化への機敏で継続的な対応と確実に成功を導く定着化･活性化を推進する活動に注力

ガバナンスの必要性ビジネスの革新を目指した大規模･複雑なSalesforce展開では、プロジェクトのリスクやコストを低減し、かつ機敏さを確保するためのガバナンスが特に重要

プロジェクトリスク低減

アジリティ(俊敏さ)

向上

統制強化･標準化推進

コスト低減･利益拡大

プロジェクト成功･

ビジネス目標達成

ガバナンス 体制･プロセス

ガバナンスフレームワーク大規模･グローバル企業において、導入･展開を成功させ、更にビジネス変化へ継続的に対応するための ４つのガバナンス要素

Center of

Excellence (CoE)ガバナンスを推進する中

核的な体制/プロセス

Salesforce組織戦略

(Organization Strategy)

Salesforceアプリが独立

して稼働する区画:

組織(Org)の設計戦略

変更要求管理(Change Management)

ビジネス要件収集からアプ

リ実装･展開までを俊敏に

行う、アプリケーションラ

イフサイクル管理

技術標準化

(Technology Governance)

アプリ構築･システム連携･

大量データ処理等、標準作

成や共通基盤の構築

Center of Excellence(CoE)

ガバナンスを推進する中核的な体制･プロセス

Center of Excellence(CoE) 変更要求管理

組織(Org)戦略 技術標準化

CoEの必要性CoEは、人･プロセス･ナレッジ･テクノロジーを最適に活用し、Salesforce導入によるビジネス目標の達成を推進

実現

イノベーション

コンプライアンス

スピード

削減

リスクCenter of Excellence

(CoE)

People

Technology

ProcessKnowledge

Base

コスト

関係者の役割･責任範囲を明確化 ビジネス目標を踏まえた取組みの優先度付け 各イニシアチブ/プロジェクト間の調整 ステークホルダーへのコミュニケーション

エンドユーザの活用・定着化をサポート 業務･IT面のベストプラクティス共有 プロジェクトの実行スピードを加速 コンプライアンス/セキュリティ対策

標準的なCoEの組織

エグゼクティブ・スポンサー＆プログラム・マネジメント

リリース･運用

ビジネス分析

開発 アーキテクト定着化･

トレーニングサポート/

ヘルプデスク

[参考] サポート体制モデル階層化されたサポート体制を構築し、日々のエンドユーザ業務を支援。ヘルプデスクやシステム管理者のみならず、現場で活躍するチャンピオン育成も重要。

お客様内のサポート体制(必要に応じて上位TIERへエスカレーション)

Salesforceによるサポート

日々業務で利用するユーザからの質問対応･支援• 機能使用方法• アカウント管理• データ管理• レポート/ダッシュボー

ド作成

マニュアル･ガイドによる技術的な問題対応

パスワードリセット等、通常の運用サポート

コード修正、連携エラー対応、複雑な設定変更、カスタムレポートタイプ作成、データロードの問題への対応 等

Salesforceサポートへのケース起票窓口

Salesforceサポート(Basic/Premier/Mission Critical Support) によるケースの受付･対応

代表的な3つのCoEモデル

統合型 連携型集約型• 公式･独立• 強い指揮･

命令権限• 集中管理

• 非公式• ノウハウ共有･

アドバイス• 分散管理

集約型モデル

– 最も強力で正式な命令・管理のアプローチ

– ベストプラクティスを活用して、 複数のビジネスユニットへ、グローバル定義の標準プロセスを適用

– コアアプリを構築し、ビジネスユニットが地域や部門ごとにカスタマイズするアプローチも可能

– 地域のビジネスユニット、子会社、部署の、すべての要件を満たせない場合もある

– 適用対象が多く対応が遅い部門に合わせる必要もあり、俊敏性は低下しがち

特徴

課題

集約型例)

各ビジネス部門から独立した一つの全社プロジェクト組織

エグゼクティブ直下

各ビジネス部門のスポンサー・システム管理者と連携

連携型モデル

– 各ビジネスユニット / 地域がそれぞれのSalesforce組織(Org)で独立機能する 非公式な命令・管理体制

– 各ビジネスユニット / 地域のスピードと要件で対応

– 小規模CoEチームを軸に、ベストプラクティスや反省点を共有

– グローバル / 地域や部門単位で類似のビジネスプロセス・機能を開発し兼ねない

– 重複した役割のスタッフがそれぞれに必要

– 共有したベストプラクティスが適用されない可能性

– 会社の技術標準･基準が順守されない可能性

特徴

課題

連携型例)

CoE概念を導入し始めたばかりの企業で多く採用

小規模なCoEチームと、各業務部門にシステム管理者配置

CoEチームと各部門に正式な報告関係無し･型式ばらない

統合型モデル

– 集約型と連携型と比較し、中程度の命令・管理体制

– 独立型と本社依存型のビジネスユニット･部門が混成

– 全体CoE が標準プロセスを提供するが、一部はビジネスユニット / 地域CoEが独自要件に合わせてカスタマイズを可能とする、柔軟性を持たせる

– 全体のCoEとビジネスユニット / 地域CoEとのコミュニケーション戦略が重要

– 十分でない場合は、連携型と同様の課題が生じる可能性がある

特徴

課題

統合型例)

集約型･連携型双方の特性を持ち、多数のビジネス部門がある大企業で採用

各部門内での管理型CoE

全社的なCoEリーダシップの下、ビジネス部門と連携

(再掲) 代表的な3つのCoEモデル

企業文化･商習慣やプロジェクト進展状況等により、適切なモデルは異なる初めから複雑にせず、小さく始めて大きく育てる段階アプローチも有効

統合型 連携型集約型• 公式･独立• 強い指揮･

命令権限• 集中管理

• 非公式• ノウハウ共有･

アドバイス• 分散管理

Salesforce組織戦略

シングル組織かマルチ組織か

Center of Excellence(CoE) 変更要求管理

組織(Org)戦略 技術標準化

Salesforce組織(Organization)とは

Salesforce組織(Org)は、データとメタデータ(定義情報)を含む、お客様のアプリケーションを実行する単位

それぞれの組織は、Salesforceのマルチテナントプラットフォーム(インスタンス)上で稼働

それぞれのSalesforce組織は独立。データは他の組織からセキュアに確保

全ての組織は、同一バージョンで、Salesforceによりバージョアップ

ユーザ管理・ストレージ容量・ガバナ制限などは組織単位で管理

組織 1(OrgId:XXX)

業務部門A

組織 2(OrgId:YYY)

業務部門B

組織 3(OrgId:ZZZ)

業務部門C

データ & カスタム

メタデータ

データ & カスタム

メタデータ

データ & カスタム

メタデータ

プラットフォーム(マルチテナントアーキテクチャ)

Salesforce組織(Org)の利用方法シングル組織とするか、マルチ組織とするか?

本社用アプリ

業務部門A用アプリ

業務部門B用アプリ

業務部門C用アプリ

Org 1業務部門B用

Org 4業務部門C用

Org 3本社用

Org 2業務部門B用

シングル組織1つの組織を全社で利用

マルチ組織複数の組織に分けて利用

(業務部門単位 / 地域単位など)

Org

シングル組織のアプローチ

部門間のコラボレーション向上

共通のビジネスプロセスゆえに、ベストプラクティス・解決方法が共有され効率性向上

部門を超えたデータ共有/コラボが可能

統一されたレポート作成(部門横串など)

組織への１回のログイン(IDは単一)

標準プロセスの適用度が低い場合には、部門要件が多くなり、俊敏性を阻害しかねない

組織利用制限(ガバナ制限)に抵触する可能性

メリット

課題点

本社用アプリ

業務部門A用アプリ

業務部門B用アプリ

業務部門C用アプリ

Org

(アプリ構成の単位は例示)

シングル組織が採用される主な理由

360˚ ビュー & レポーティング

お客様360˚ビュー

全てのお客様に対する一貫した

情報共有･レポート作成

グローバルでデータの共有

グローバルでのプロセスと

データの共有

コラボレーション

企業内コラボレーションの改

善と活性化

標準化プロセス

部門や地域を跨り、整合性のあるビジネスプロ

セス

サポート

一括のサポート体制が提供でき

効率的(規模の経済性)

マルチ組織のアプローチ

各業務部門の独立性を確保し、Orgの設定を柔軟に管理することができる。

組織の制限に抵触する可能性は低い

利用開始までの時間短縮と自律性、早い対応

個別セキュリティ要件への対応

組織単位にシステム管理者が必要

組織間で設定やコードの再利用が難しい

グローバルでの標準プロセス展開が困難

部門間のコラボレーションが低下(Chatter等)

部門間を跨いだレポーティングが難しい

ID管理/シングル・サインオンが煩雑

メリット

課題点

Org 1業務部門B用

Org 4業務部門C用

Org 3本社用

Org 2業務部門B用

マルチ組織が採用される主な理由

遺産

企業買収による多様な事業･システム

地域/言語

異なる地域の自立性重視

法令対応

税法/法令遵守

組織の制限

ガバナ制限などの組織単位の制約を回避

独立事業部門

事業部門がお互いに独立性

が必要(ビジネスのスピード優先）

機能性

異なるビジネスプロセス(HR/Sales)

Salesforce組織の戦略における検討ポイント現在のビジネス部門・地域のオペレーション状況だけでなく、Salesforceの定着･活用が進んだ状況も考慮すべき。定着化が進むとより多くのアプリケーション利用要望・未導入部門/地域からの利用希望増加が想定される。

ビジネス• 地域や業務部門間における

ビジネスプロセス/組織の類似性、情報共有の必要性、俊敏性など

サポート/開発体制• アプリ開発体制• エンドユーザへの

トレーニング/サポート体制 など

企業文化• 各部門/地域の自律性、コラボレーション度合、グローバル統制度合 など

テクニカル• セキュリティ基準、

Salesforce組織の制限、アーキテクチャ構成 など

Salesforce組織の戦略は、企業文化・ビジネス･テクノロジー・サポートの各領域での十分な分析･将来計画が必要

シングル組織構成の例 - Salesforce

Salesforceではお客様向け業務はシングル組織で実現・グローバルで共有、全世界の社員が利用・営業/マーケティング/サポート等の部門によらず利用

お客様(取引先･取引先責任者)の360°ビューを実現

Salesforceシングル組織インサイドセールス

SE コンサル

営業 CSM

サポートEMEA

APAC JAPAN

US

[参考] 考慮すべきポイント(1/2)

27

分類 マルチ組織 シングル組織

システム管理

- 可視性

• システム管理者は、自身が担当している組織の設定情報のみ見る

ことができる。変更管理のスコープも自身が担当している組織の

み。

• システム管理者は、自身が担当していない他BUの設定情報や

データを見ることができる。

• 誤って他業務部門(BU)の設定を変更してしまうリスクがある。

• プロファイルやページレイアウトが多くなりすぎて、管理の複

雑になる可能性がある。

システム管理

- 影響

• 多くの設定を加えたとしても、自身が担当している組織にしか影

響はない。例えばタブ名、項目名、カスタムオブジェクトなど。

• 組織単位で有効／無効を制御する機能を、各組織の判断で選択で

きる。

• 1つの設定変更により、すべてのBUの業務に影響が出る可能性

がある。

システム管理

- AppExchange

• AppExchangeのパッケージは各組織にインストールする必要が

あるため、同じパッケージを複数組織で利用する場合は手間がか

かる。

• 有償アプリの場合、組織ごとに課金される可能性がある。

• パッケージを1度インストールするだけで、プロファイル設定

に従って各ユーザが利用可能になる。

システム管理

- 変更管理

• 複数組織に対して同じ設定変更を行う可能性も考慮に入れた変更

管理手順が必要。

• システム管理者は自身が担当していない組織にはログインしない

ため、その点も考慮に入れる。

• 大企業における単一組織では、各地域のシステム管理者と協働

する為に、入念に定義された変更管理プロセスが必要となる。

メンテナンス時間

• 各地域を考慮した時間帯にメンテナンスが実施される。 • 年3回バージョンアップのメンテナンス時間を考慮する必要が

ある。例えば日本用のインスタンスで運用した場合、日本時間

の日曜深夜＝アメリカでは土曜の日中となり、その時間帯は

Salesforceにアクセスできなくなる。※実停止時間は最大5分

間程度。

[参考] 考慮すべきポイント(2/2)分類 マルチ組織 シングル組織

顧客の360°ビュー

• とある顧客を複数地域で担当している場合、顧客データが複数

組織に分散するため一元管理を行うのが難しい。

• 複数組織間でデータを同期させる運用も考えられるが、このプ

ロセスを維持するのは難しい。

• Portalを利用する場合、ポータルユーザ（顧客）をどの組織に登

録するか検討が必要。

• 他BUの顧客に関する過去のやりとりを共有できるので、スムー

ズなケース対応を実施したり、営業部門と共有してクロスセル

やアップセルにつなげることも可能。

• 他BUに共有したくない情報がある場合、データアクセスコント

ロールの設定に注意を払う必要がある。

レポート &

ダッシュボード

• データ連携を行わない場合、自身の組織に関するデータしかレ

ポーティングできない。

• Salesforce to Salesforceを利用して組織間でデータをコピーし

たり、ETLツールなどを利用し、1つの組織にグローバルのデー

タを集約してレポーティングすることは可能。

• Salesforce以外のBIツールにデータ連携をして、そちらで分析

を行うという選択肢もある。

• グローバル各拠点のデータを統合的にレポーティング可能。

• 目安として、1オブジェクトあたり100万件を超えてくるとレポ

ートの実行時間に影響が出る可能性がある。

セキュリティ• 各組織毎にデータアクセスコントロールを定義する必要がある

• ある顧客の他BUの過去のやりとりを参照するために、1人のユ

ーザが複数IDを持つ運用が考えられる。

• ある顧客を担当するグローバルのユーザが多くなりすぎた場合

、データアクセスコントロールが複雑になる可能性がある。

データ量• 各組織にデータが分散するので管理しやすい。 • 1つの組織にグローバルの全データが集約されるので、大量ボ

リュームになる可能性がある。

• ストレージは追加購入可能。

リリース• リリースや展開に関する管理が容易。

• リリースまでのスピードが速い。

• BUごとに注意を払う必要があるため、リリースや展開に関する

管理がやや複雑。

• 同様の理由により、リリースまでのスピードもやや遅くなる。

変更要求管理

ビジネス変化へ俊敏に対応する開発ライフサイクル管理

Center of Excellence(CoE) 変更要求管理

組織(Org)戦略 技術標準化

Salesforceアプリケーションの開発サイクル大規模展開ではウォーターフォール型･ビッグバンで長期開発になりがち。Salesforceのメリットを活用し、ビジネス変化への俊敏な対応が重要

Test

Ideas

Maintenance

Implement

Design

Salesforceの標準機能、ポイント&クリック開発、新機能バージョンアップのメリットを最大に活用

企画･設計･開発･テスト･メンテナンスのサイクルを素早く・次々と回し、段階的･継続的に業務/アプリケーションを改善

変更要求管理プロセスモデルSalesforceの標準機能・ポイント&クリック開発(コンフィグレーション)を活用し、アジャイル開発/段階リリースを進めるプロセスをCoEが定義

ビジネス要件管理 リリース管理設計･開発･テスト

Ideasビジネス

要件バックログ

スプリント

開発• コンフィグレー

ション• コーディング• ユニットテスト• 移行スクリプト

テスト

ユーザ受入テスト(UAT)

Production

環境管理

アジャイル開発方法論

バグフィックス

本番移行

4つのリリースタイプクイックな機能改善リリースを繰り返しビジネス要件へ迅速に対応。Salesforceメジャーリリースへの対応計画(新機能活用検討＋影響調査) も必要

マイナーリリース(機能改善)

メジャーリリース

(プロジェクトリリース)

バグフィックス(+小規模改善)

Salesforceリリース(年3回メジャー

バージョンアップ)

容易

複雑

開発規模･複雑度

月次 四半期次日次/週次

リリースタイミング

変更要求管理プロセスにおいて考慮すべきポイント

ビジネス部門

企画段階からリリースまでの開発プロセス全体を通じて参画

ビジネス要件のバックログを管理し、優先順位/判断基準を定義

ビジネス部門がユーザ受入テスト(UAT)を主導

IT部門

ロードマップ： Salesforce組織内の全ての定期リリース計画を策定

開発サイクル：すべてのプロジェクトは、予め定義された開発ライフサイクルの方法論に準拠 (Salesforceのベストプラクティスガイドを活用)

環境管理：定期リリース計画・開発ライフサイクルを確実に行うために必要となる開発/テスト･本番環境のアーキテクチャ管理を行う

技術標準化：開発チームはSalesforceのベストプラクティスに従い、コーディングでなくコンフィグレーションでの対応ができないかをまず検討

ユーザ

エンドユーザへも、プロジェクトのVison/Valueを伝え、自分たちのビジネス目標に対してどのように役立つのか、現在の業務のやり方がなぜ変化するのか・ビジネス上の理由を理解して貰う(確実な定着化繋げる)

エンドユーザからの効果的なフィードバックサイクルを作り上げる

技術標準化

標準・ガイドラインの策定･共通基盤の構築

Center of Excellence(CoE) 変更要求管理

組織(Org)戦略 技術標準化

技術標準化の取組み一般的な大規模システムと同様、エンタープライズアーキテクチャの策定・共通基盤の構築、設計･開発時に適用すべき標準･ガイドラインの策定が重要

コンフィグレーション

コーディング パフォーマンス(大量データ処理等)

開発ツール開発

Salesforceは各種の開発者ガイド・ベストプラクティスガイドを提供https://developer.salesforce.com/docs/

セキュリティインテグレーション(ｼｽﾃﾑ連携方式･基盤)

データ(ﾗｲﾌｻｲｸﾙ･品質管理等)

インフラ(ｸﾗｲｱﾝﾄ環境･NW等)

エンタープライズアーキテクチャ / 共通基盤

標準･ガイドライン (Salesforceベストプラクティス参照)

まとめ：ガバナンスフレームワーク大規模･グローバル企業において、導入･展開を成功させ、更にビジネス変化へ継続的に対応するための ４つのガバナンス要素

Center of

Excellence (CoE)ガバナンスを推進する中

核的な体制/プロセス

Salesforce組織戦略

(Organization Strategy)

Salesforceアプリが独立

して稼働する区画:

組織(Org)の設計戦略

変更要求管理(Change Management)

ビジネス要件収集からアプ

リ実装･展開までを俊敏に

行う、アプリケーションラ

イフサイクル管理

技術標準化

(Technology Governance)

アプリ構築･システム連携･

大量データ処理等、標準作

成や共通基盤の構築