ソリューションアーキテクトのプロセス

SA プロセスの概要

SA プロセスは、ソリューションアーキテクトが実施を求められるアクティビティであり、明確に定義されたステップとシステム接点を持っています。これは SA プラクティス（SA が伸ばすことを推奨されるスキル）や SA エンゲージメントプレイブック（特定の販売やエンゲージメントモーション向けのエンドツーエンドガイド）とは区別されます。

SA Opportunity ハイジーン

ハンドブックのこのセクションでは、ソリューションアーキテクトが責任を負う、または関与するすべてのプロセスを説明します。そのいくつかは GitLab のアカウントおよび Opportunity の記録媒体である Salesforce での更新と追跡を必要とします。

SA の効率を高めるため、すべての SA Opportunity 更新内容のチェックリストを作成しており、SA が週次で Opportunity に対する責任事項を追跡できるよう支援しています。

SA プロセスマップ

SA 組織は、構造化された継続的改善のためのフレームワークとしてプロセスマッピングを利用しています。SA の実行ワークフローと詳細は LucidChart に文書化されています。つまり、私たちが何を、どのように行うかをビジュアルなプロセスマップとして文書化しています。これにより、再利用可能な成果物、イネーブルメント、ツールを 1 か所にまとめて見つけられるようになっています。

SA プロセスマッピングのゴールは以下を含みます。

• SA アクティビティに対して指示的かつ意図的に取り組み、効率と効果を継続的に高める
• SA のオンボーディングを高速化する
• 私たちが行うことの多くを測定可能にする
• 互いに責任を持ち合う
• 行ったことについて協働しイテレーションしやすくする
• すべての SA がお客様と協働するための再現可能なプロセスを作る

SA プロセスマッピングは、創造性、実験、改善を制限するためのものではありません。SA ラーニング組織の一員として、SA は私たちの思考モデルに挑戦し、チームとして問題解決に集中することを推奨されています。何かをより良く行えるならぜひ試してみて、その学びを共有してください。プロセスマップやそれを支えるハンドブックページに貢献しましょう。

以下のプロセスマップはフルスクリーンで閲覧することを推奨します。多くのマップノードがクリック可能で、別のマップ、ハンドブックページ、その他の関連成果物につながっていることに注目してください。

SA アクティビティキャプチャ

ソリューションアーキテクトは、透明性とコラボレーションを促進するために、すべての顧客および見込み顧客とのアクティビティを記録します。お客様向けのアクティビティを一貫してキャプチャすることで、GitLab のビジネスにおいて効率的な意思決定を確立するための分析やレポーティングに活用できます。このプロセスの詳細については、SA アクティビティキャプチャページを参照してください。

私たちは Troops でのアクティビティキャプチャに対応するようにフォーマットされた標準のミーティングノートドキュメントを用意しており、各お客様とのエンゲージメントで活用すべきものとなっています。

カスタマーサクセスプラン

カスタマーサクセスプランは、GitLab の活用を通じて価値を実現するためにお客様向けに提示し、相互合意したロードマップです。これは GitLab Solution Architecture とお客様のコラボレーションの成果物であり、お客様が成功することを確実にするのが第一の目的です。このプロセスは、製品スコープの会話（特定の機能や機能群に焦点を当て、特定の DevSecOps ステージのサブセットに限定される）から、ソリューション（特定の課題に対処する）または戦略（最重要戦略イニシアチブに紐づく、組織横断的なプロセスイノベーションと変革を通じてビジネス成果を形作る）スコープへとシフトすることをサポートするように設計されています。このサクセスプランはプリセールスプロセスで開始され、ポストセールスのサクセスプランへと引き継がれることを意図しています。

注: カスタマーサクセス組織にもポストセールス向けのカスタマーサクセスプランがあり、お客様向けドキュメントとして用いられ、ポストセールスのイニシアチブやマイルストーンを更新できる目的で運用されますが、ソリューションアーキテクトのカスタマーサクセスプランプロセスは、必要なすべてのコンテキストを提供し、プリセールス中にお客様と協働しながらお客様の声・要件・成果をキャプチャし、カスタマーサクセスへのスムーズな移行を確実にすることを目的としています。

カスタマーサクセスプランニングのコアゴールは、以下を特定し明確化することです。

• ビジネス成果
• 主要なビジネスステークホルダー
• インパクトの大きい戦略要件
• お客様のテクノロジエコシステムの現状（必要となる連携）
• 現在の能力と必要となる能力
• 戦略目標との運用面での整合性
• 現在の能力における認識されたギャップや不備
• 必要な能力を実装するためのプランと、GitLab がどのように貢献できるか

プロフェッショナルサービスのポジショニング

ソリューションアーキテクトは、長期的なお客様の成功と成長を実現するため、適格なお客様 Opportunity ごとにプロフェッショナルサービスを売り込むべきです。このデッキとルーブリックを活用して、こちらに掲載されているカタログに慣れてください。 ご自身の Opportunity でポジショニングを行ったあとは、SA アクティビティタイプとして「Positioned PS」を追加してください。

プロフェッショナルサービスへのエンゲージ

Working with Professional Services ハンドブックページに記載されているプロセスに従ってください。

簡略化したプロセス説明:

• SAE / AE によって PS Opportunity が SFDC ですでに作成されていることを確認します。
• フルカタログから提供される標準（カスタマイズなし）のサービスである場合
  • SAE / AE は SFDC 内の Zuora から直接 PS を発注します。
• 標準サービスがお客様のニーズを満たさない場合
  • Services Calculator を使って Issue とドラフト見積もりを生成します。
  • その Issue について PS および SAE / AE とイテレーションを行います。

カスタマーセキュリティアシュアランス

GitLab’s Customer Assurance Activities ハンドブックページに記載されているプロセスに従ってください。

カスタマーアシュアランスチームに依頼する際の 任意の 検討事項:

• 場合によっては Security - GitLab Trust Center から始めることができます。
• お客様には Self-service Information Gathering の利用とレビューを推奨してください。
• 時間が許せば、SA がすべてのセキュリティアンケートに対して 1 度パスを試みることができます
  • ぜひ実施してください。楽しく、教育的です！
  • GitLab’s Trust Center も活用できます
• 追加のリクエストは #sec-fieldsecurity Slack チャンネルで行えます。
• セキュリティアンケートに時間を費やすときは、最初に費やした時間を SA アクティビティキャプチャシステム（troops）でキャプチャしてください。

SA イニシアチブと OKR

ソリューションアーキテクトは、自身の OKR（Objectives and Key Results）とイニシアチブを SA Initiatives GitLab プロジェクトに記録・追跡します。 OKR は会計年度ごとの SA 重点領域および会社の OKR と直接関連します。イニシアチブは重点領域や OKR から独立しています。 すべてのソリューションアーキテクトは新しいイニシアチブと OKR を開始したり、既存のものに貢献したりできます。 理想的にはどちらも、各アクションアイテムに対して DRI（Direct Responsible Individual）を持ち、測定可能な成果物（Key Results）を伴う四半期で達成可能な単位に分割されます。 ドキュメント化と追跡には、プロジェクトで提供される OKR とイニシアチブのテンプレートを使用し、対応するラベルを付与してください。 四半期の終わりには、各イニシアチブと OKR は正常にクローズされる、達成される、もしくは必要であれば次の四半期に移されるべきです。新しいプランニングは新しい四半期の開始時に始まります。

クロスファンクショナル営業チームのプロセス

ワーキングアグリーメント

エンタープライズソリューションアーキテクトは通常、Sales Development Representative、Strategic Account Leader、Customer Success Manager で構成される営業チームを支援します。High Velocity Sales のソリューションアーキテクトはプール型のモデルで Mid-Market Account Executive と SMB Customer Advocate を支援します。営業チームに加わる際、お客様および GitLab チームに最適なサービスを提供するために、ワーキングアグリーメントを定めることが極めて重要です。会話を促進し、これらのアグリーメントを定めるためのテンプレート例を以下に示します。

1. メールやミーティングフォローアップに対するお客様への応答時間 特記事項がない限り、私はお客様からのお問い合わせやフォローアップに対し、可能な限り当日対応するよう努めます。お客様にトップクラスのサービスを提供したいと考えていますが、割り込みがその目標を妨げる場合があります。出張時には不在通知を使用するため、お客様はその間応答が遅れることを想定できます。1 日の終わりが近づき、私がお客様の依頼に対応していないことに気づいた場合は、いつでもご連絡ください。Slack はほとんどの場合、私と最も簡単に連絡を取れる方法です。
2. デリバリーエクセレンス 私の応答が、お客様向けによりよく、より高品質な文脈に整える必要があるトップクラスのサービスを必要とする場合、私は GitLab 営業チームと協力し、完了までの妥当なスケジュールを設定します。例としては、ドキュメント（単なる URL ではなく）に基づいて技術的ガイダンスをお客様向けにカスタマイズしてまとめたサマリ、推奨されるリファレンスソリューションアーキテクチャ、GitLab とサードパーティテクノロジーとの統合などが挙げられます。
3. カレンダー 必要に応じて、勤務時間中に私のカレンダーに直接スケジュールを入れてください。私はカレンダーを最新に保つよう努めます。ただし、その日に空きスロットが 1 つしかない場合や、別の予定と背中合わせになっているように見える場合は、お客様と日時を確定する前に必ず私に確認してください。最高のパフォーマンスを発揮するためには、準備とフォローアップの時間が必要です。背中合わせでスケジュールを入れると、前のミーティングで遅刻したり、コンテキストの切り替えで慌てたり、既知の質問への答えが用意できなかったり、前回のコールで変更されたデモ環境の準備が間に合わなかったりすることがよくあります。
4. 定期的なコミュニケーション SA、SAE、SDR、CSM での週次の戦略コール（1 時間）が望ましいです。より頻繁な同期コミュニケーションが望まれる、または必要な場合は、実現可能なケイデンス、必要な参加者、都合の良い時間、コールの議題をチームとして特定するために協力すべきです。これらの定期コミュニケーションのいずれの方法においても、議論ポイントと合意事項を文書化することは不可欠です。
5. エレベーテッドな会話 私たちが価値に集中し、非常に深い技術や問題のトラブルシューティングの会話から離れるほど、目標とする売上を達成するために私はあなたの役に立てます。同期を保つために、ビジネスプランと戦略をレビューし貢献することを喜んで行います。
6. プロフェッショナルサービス より速い導入を促進するためにお客様のニーズを慎重に評価したうえで、見込み顧客やお客様に必要なサービスを提案・推奨することを喜んで行います。私は最初の SOW を書き、Professional Services チームから承認を得ます。
7. 出張 戦略的なエンタープライズセールスには出張が絶対に必要ですが、出張する日が増えるほど、週の他の日における作業量やコール量も増える可能性があります。私のお客様との対話には、特定のお客様向けのソリューションを調査・モデリングするために多大な時間が必要となるためです。私は地域内で少なくとも 2 つの営業チームを支援していることを考慮し、オンサイトを検討するときは戦略的にプランニングしてください。さらに、オンサイト（または対面）訪問の手配時には、1 週間前の通知でお客様と調整するようにしてください。これにより、出席のコミットメントを確保し、必要に応じて家族やその他の事項について別の手配を行うことができます。
8. ノート 別途指示がない限り、お客様との外部コールのノートは Salesforce から Google Docs にリンクされ、Gdocs の「GitLab Sales」ディレクトリに保存されます。お客様とのメール通信も Salesforce に BCC されます。ノートやアクションを別の方法で記録したい場合は、その協働方法を教えてください。SA アクティビティプロセスにリンクします。
9. 継続的学習 GitLab のことは非常に速く動いていて、私もキャッチアップする時間が必要です。リリースに合わせて最新の GitLab 機能セットを取り込むため、カレンダーに数時間ブロックします。しかし、新しい技術や競合製品も定期的に登場します。お客様を十分に支援するために、それらについて学習する追加の時間を定期的に割り当てる必要があることをご理解ください。

クロスファンクショナルチームでのツール活用

1. Salesforce [To-do] セールスサイクル中に使用するビューやレポートに関する情報を追加。また、Opportunity やアカウント上での SA のリスティングに関するガイダンス（現在のハンドブックには情報がない）。
2. Slack クロスファンクショナルチーム用の社内向けパブリックチームの Slack チャンネルを作成しましょう。これにより、DM を送信せずに簡単にコラボレーションできます。
3. Google Drive 共有の GitLab Sales フォルダがあります。お客様に関する継続的なノートやその他のドキュメントは、適切な頭文字とお客様名のサブフォルダ配下にある Customers and Prospects サブフォルダ に保存してください。
4. GitLab Account Management Project は、ポストセールスでお客様との PoV や CSM コラボレーションに使用される場合があります。
5. Chorus.ai はミーティングを記録するために使用されます。アカウントがセットアップされると、GitLab Notetaker は GitLab 外部の人とのミーティングに自動的に参加します。

アカウントプランニング

アカウントプランニングは、SAE と SA が Opportunity 主導の会話をお客様の価値ドライバーに焦点を当てた価値ベースの会話へと格上げするのに役立ちます。これはアカウントレベルでお客様を戦略的に支援するうえで重要なステップであり、より効率的な Opportunity プランニングを促進します。

Quarterly Exchange

四半期の終わりに、SA チームは集まって、それぞれが注力していたことを共有し、学びを伝え合うか洞察を集めます。

ゴール

1. お互いのお客様アクティビティから協働・学習し、改善する
2. お互いの仕事を活用するための対話を作る
3. チームとしてより親密になる

アンチゴール

1. 完璧主義
2. ビジーワーク
3. もうひとつのミーティング

フォーマット

各 SA が振り返るか、または前を向くのに 15〜30 分。

⬅️ 振り返り

過去の四半期を振り返り、SA はうまくいったことや避けるべきことを共有できます。この振り返りと議論を促進する素晴らしい方法は、Closed Opp Key Learnings やお客様戦略プランを通じて行うことです。

前を見る ➡️

次の四半期に向けて、SA は技術的な勝利を確保するための戦略を概説する Technical Opportunity Plan を共有し、チームメンバーからフィードバックや洞察を集めることができます。

四半期ビジネスレビュー（QBR）

ソリューションアーキテクトマネージャーは、SA 専用のダッシュボード、SA や地域横断チームからのフィードバック、Quarterly Exchange を活用して QBR コンテンツを準備します。

SA は、Notable Opportunities セクションで技術的な勝利と成功基準の詳細の表現に関する事項について、プロアクティブな支援を提供すべきです。

スライドは Solutions Architects QBR フォルダ の四半期サブフォルダ内に保存されます。

営業サイクル中の SA エンゲージ

ソリューションアーキテクトは初期の qualifying meeting (IQM) に参加することも、SDR と SAE/AE が初期コールを担当し、そこから得られた情報を追加準備に活用することも可能です。チームはケースバイケースで対応できます。

command of the message discovery に従って目的と期待が確立されたら、アカウントチームとして集めた情報をレビューすることを推奨します。これにより、技術ディスカバリーをさらに進めるための適格基準が満たされたか、またはアカウントが成果に関するさらなるディスカバリーを必要としているかを判断するのに役立ちます。ソリューションアーキテクトは、特定の Opportunity に対してしばしばユニークな視点を持っており、この情報を引き出してアカウントチーム全体に共有することが、できればコマンドプランを通じて重要です。

特定の Opportunity の認識される規模は、SA がそのお客様にかけるべき労力の量を必ずしも反映しません。以下の要件は次の点を目的としています。

• お客様とのミーティング前に適切な準備が行われていることを保証することで、SA ができるだけ多くの Opportunity に対応できるようにする
• すべてのお客様に対して、SA とのミーティングを通じて感じる価値、そしてプランの妥当性を検証してもらえる自信を高める
• SA が Opportunity に関わる経験を活用し、SA に投資が最も必要だと判断する場所に適切な時間を投じる自律性を与える
• 提示されたさまざまな技術領域における情報不足や深い知識の欠如による SFDC Opportunity の混乱を減らす

Opportunity の qualification、ディスカバリー、技術評価の段階で SA に関与してもらう際は、以下の情報を提供してください。これにより SA は実行を加速し、成功を可能にし、さまざまな営業役割や採用された戦略に整合した一貫性ある質の高い Opportunity 成果を促進できます。SA は、依頼後に下記情報が欠落・未提供である場合、また適切なペルソナが関与していない場合、ミーティングを辞退する権利を保持します。下記情報が提供されない、または qualified でない場合は例外をケースバイケースでレビューします。

• アクティブな SFDC Opportunity ID をご提供ください
• 対応する完成済みのコマンドプランへのリンクをご提供ください
  • Why Now?、Identified Pain、Champion がキャプチャされていることを確認してください
• 追加の Opportunity 情報（例: 会社概要と背景、イニシアチブ、望ましい成果、ペルソナなど）
• スケジュールまたは予定されているお客様とのミーティングは、お客様とのエンゲージメント前に SA と議論されていることを確認してください
  • スケジュールされたミーティング内で何を達成しようとしているか?
  • 目的は明確で理解可能か?
  • 期待値が管理され、明確に議論されているか?

SA がタイミングや十分なコンテキストなしに関与する不適切にポジショニングされた Opportunity は、SA のバーンアウト、停滞または長引く営業サイクル、お客様のニーズとのミスアライメントにつながります。SA は、コマンドプラン（特に Why Now/Identify Pain）が文として活用されているときに関与することが極めて重要です。

ソリューションアーキテクトは、リード qualification が完了した後のテクニカルディスカバリー、およびテクニカルウィンにつながる営業プロセス中の他のアクティビティに参加すべきです。例:

• GitLab デモ
• GitLab テクニカルディープダイブ
• GitLab ハンズオンワークショップ & ラボ
• ホワイトボーディングセッション
• 見込み顧客 Q&A セッション
• RFI/RFP の完了
• PoV のプランニング、ドキュメント化、実行戦略
• セキュリティ監査
• Professional Services と SOW のスコーピング

SA は CSM と連携して既存のお客様を支援することもあります。特にアカウント内に拡張 Opportunity が存在する場合に重要です。また SA は、CSM が割り当てられていないより小規模なお客様との定期的なタッチポイントを持つこともあります。

SA/CSM エンゲージメントの重複

• 大局的な観点では、SA は見込み顧客および既存顧客向けのプリセールスアドバイザーであり、CSM は既存顧客のポストセールスのリレーションシップを管理し、GitLab の活用に責任を持ちます。

詳細は次のリンクをご覧ください: Overlap Between Solution Architects and Customer Success Managers

テクニカルディスカバリーとデモ準備

ソリューションアーキテクトは、価値を実証し、現在の問題領域に対処するための会話やデモをテーラーメイドにするために、以下の情報を理解したいと考えています。デモの前にさらなるテクニカルディスカバリー¹をリクエストする場合があります。

1. アウトカム:

• お客様にとって何のメリットがあるのか?
• なぜソフトウェア開発の新しい戦略を検討するのか?
• なぜ突然 GitLab に関心を持ったのか?

1. インフラストラクチャ:

• 現在どのようなツールが使われているか?
• 置き換えの可能性があるツールは何か?
• 変更の可能性があるプロセスやワークフローは何か?

1. 課題:

• どのような問題や障害が明らかになっているか?
• 現在どのプロセスやテクノロジーが、どのソフトウェア開発の理由で利用されているか? (つまり、開発されているアプリケーションの目的は何か? どの言語で書かれているか?)
• 現在のリリースベロシティは?
• 現在のプランニングプロセスは?
• 可視性、トレーサビリティ、または効率性の懸念は何か?
• どのようなコラボレーションやガバナンスの機会が存在するか?
• どのようなセキュリティやコンプライアンスの非効率が存在するか?

テクニカルディスカバリーが完了したら、SA はアカウントチームと協力して進むべき道を固め (お客様は購入、トライアル、PoV のいずれかに進むのか?)、評価の成功を判定する対応するメトリクスを特定します。

ソリューションアーキテクトのエンゲージメントモデル

U.S. Enterprise Account and Opportunity Engagement Model

Enterprise Strategic SA Engagement Model は、私たちおよびお客様の間でさらに大きなコラボレーションとイテレーションを促進することを目指しています。

Landed Addressable Market (LAM または LAM Dev) は常に正確とは限らず、Opportunity Net ARR がポテンシャルを必ずしも示さないことを踏まえ、このモデルは SA チームのエンゲージメントを AE 役割でセグメンテーションし、SA エンゲージメントモデルが AE チーム構造と整合するようにしています。

ソリューションアーキテクトは、自身の Opportunity に対するエンゲージメントを所有することに責任を持ちます。「エンゲージメントモデル」は一般的な推奨事項であり規則ではなく、ソリューションアーキテクトの裁量に任されます。

Major Account Executive の場合、SA はそれぞれのアカウントアクティビティで Account Executive と整合します。

Strategic Account Executive の場合、SA は進行中の Opportunity に基づいて Account Executive と整合します。

Strategic Account Executive 向けには、以下のプロセスを使って SA をリクエストできます:

• Strategic Account Executive は、適格 Opportunity を作成した後、Salesforce で「SA Request」ボタンをクリックします。
• これには、お客様のペインポイント、Why Now、SA のヘルプを得るために必要な追加情報が必要です。
• この情報はコマンドプランとクローズプランからプリフィルされます (これらが存在しない場合は、コマンドプランとクローズプランにも追加されます)。
• このリクエストは Slack チャンネル経由でトリアージされ、SA に受け入れられると Primary SA フィールドが入力されます。
• SA 割り当ての対応時間は 24 時間です。
• Enterprise SA は Opportunity のライフタイム全体にわたって専任となります。
• アカウントのライフサイクル全体にわたって複数の Opportunity に SA を継続させること、または SAE に対する専任 SA は、SA/ASM マネージャーの裁量に委ねられます。
• SA/SAE のアラインメントはレポートで確認可能です。

非同期 Slack サポート

場合によっては、初期段階または完全には qualified ではない Opportunity で SA サポートが必要となることがあります。Slack は、技術的な質問への回答、追加の顧客アウトリーチ資料の提供、またはアカウントエグゼクティブの狭くスコープされたお客様の質問への支援に使用できます。これらのリクエストは Slack 経由で非同期に対応できます:

AMER EAST: #us-amer-east-sa-support AMER WEST: #us-amer-west-sa-support

これらの Slack チャンネルは、すべてのエンタープライズ AE <-> SA コミュニケーションのための安全な場とみなされます。質問する際は、SFDC URL とサブスクリプションのタイプ (SaaS または Self-Managed) を含め、できるだけ多くのコンテキストを提供してください。Solutions Architecture はこれらのリクエストを監視し、ベストエフォートでサポートを提供します。

EMEA Account Engagement Model

EMEA エンタープライズソリューションアーキテクトは、Major Account Executive (MAE) および Strategic Account Executive (SAE) をアラインメントモデルで支援します。

SA は地域別に AE と整合し、それぞれのアカウントアクティビティで連携します。各チームは標準のワーキングアグリーメントに従って協働しますが、チームごとに調整可能です。

デフォルトのアラインメントは EMEA AE-SA Alignment ページに維持されています。

SA のキャパシティを超える作業負荷の場合、または他部門からのリクエストの場合は、#emea-customer-success Slack チャンネルでアシスタンスを依頼してください。

High Velocity Engagement Model

お客様とのやり取り、RFP、監査などに関する SA エンゲージメント (High Velocity SA に関与依頼する方法) は、Mid-Market Account Executive または他の GitLab チームメンバーによって、Salesforce Opportunity の SA Request ボタン経由でリクエストできます。エンゲージメントの考慮事項、トリアージプロセス、期待値の詳細は、専用の High Velocity Solutions Architecture Engagement Model ハンドブックページに記載されています。

APAC Account Engagement Model

APAC SA は、Strategic Account Leader、Commercial AE、Channels Manager のテリトリーに密接に整合する形で、ANZ、SEA (東南アジア)、インド、韓国、日本などの地域に整合しています。チームは標準のワーキングアグリーメントに従って協働します。

Ecosystem SA Engagement Model

Ecosystem SA (ESA) チームはグローバルです。Ecosystem SA は、チームメンバーの経験と地域のニーズに基づいて、あらゆるタイプのグローバルおよび地域パートナーとさまざまな形で整合しています。各地域の Ecosystem Sales Manager (ESM) と並んで作業し、Ecosystem SA は直接の顧客関係ではなくパートナー関係の構築に注力します。Ecosystem SA は、パートナーが営業サイクルでサポートを必要とし、パートナーのアカウントチームが GitLab 営業チームを巻き込む準備ができていない場合に、直接の顧客エンゲージメントに参加します。Ecosystem SA はすべてのお客様とのやり取りを文書化し、可能な限り早く Field SA に引き継ぎ、パートナーとお客様で Opportunity を進めます。Ecosystem SA は、パートナーアラインの Opportunity をサポートするために Field SA コミュニティのバックアップを提供できます。

ほとんどの Opportunity ベースのエンゲージメントは、ESM から始まり、関与すべき適切な Ecosystem SA を特定すべきです。すべてのアカウントの ESM は SFDC のお客様アカウントレコードに記載されています。パートナーアカウントの ESA は SFDC パートナーアカウントレコードに記載されています。ESA がリストされていない場合は、Ecosystem Sales Manager にアシスタンスを依頼してください。

Ecosystem SA に関与依頼する詳細は Ecosystem Solutions Architect Engagement Model ハンドブックページを参照してください。

Subject Matter Expert Engagement Model

Subject Matter Expert を Opportunity に招待または依頼する前に、Opportunity が完全に qualified であることを確認してください。SME は主担当のソリューションアーキテクトによってリクエストされるべきです。これにより、リソースを効率的かつ効果的に使用できます。

SME Triage Project でテンプレートを使って Issue を作成してください。現在のエンゲージメントはボードで確認できます。

Secondary SA

特定の Opportunity が、1 人の SA だけでテクニカルウィンを十分に確保するには複雑すぎる、価値が大きすぎる、リスクが高すぎると判断されることがあります。

アドホックサポート

GitLab の CREDIT 価値の一環として、SA はより良い結果を提供するためにお客様のアクティビティで互いに協働することが推奨されます。そのため、SA はしばしば自分でアシスタンスを求めて連絡を取ります。例として、Slack チャンネルや Stackoverflow での質問、ブレインストーミングやイネーブルメントミーティングのスケジューリング、互いのデモンストレーションやワークショップのサポートなどが挙げられます。

長期

ビジネスをよりよく支援し、SA が互いに協働・学習する機会を作るため、SA リーダーは Opportunity に対して長期的にペアを組ませる Secondary SA を割り当てる場合があります。

長期的な Secondary SA を伴わずアドホックサポートのみが必要な場合、SA は引き続き互いに頼り合い、協働する必要があります。

Opportunity 上の Secondary SA エンゲージメントの追跡

アドホックおよび長期 Secondary SA は、お客様とのやり取りに対する印象をキャプチャし、アカウントを支援する Primary SA であるかのようにアクティビティをログ記録すべきです。Salesforce の Primary Solutions Architect フィールドは Primary SA を指定するために使用され、Opportunity に関与する他の SA はログ記録されたアクティビティから派生します。

Secondary SA が Subject Matter Expert としても関与している場合、アクティビティをログ記録するときに SA Assistance - Subject Matter SA Activity Type を使用すべきです。

Issue 作成の詳細

1. ご自身の地域の正しいボードに移動します。注意: すべてのトリアージボードは、SA Triage Boards グループ内の地域またはエンゲージメントモデルごとに分けられたプロジェクトに配置されています。
2. 新しい Issue を作成します。
3. 次のいずれかの利用可能なテンプレートを使用します:

• 新しいアクティビティ: 適切なデータが収集・利用可能であることを保証するために「SA Activity」テンプレートを使用
• フォローアップアクティビティ: 「Follow Up」テンプレートを使用
• セキュリティ監査: 「Vendor Security Assessment」テンプレートを使用

1. SA グループがクライアントの成功を確実にするため、SA エンゲージメント前に以下の情報が利用可能になっているべきです

• お客様情報: お客様名、SFDC Opportunity リンク
• 希望日のオプション: お客様がコールを希望する日時 (タイムゾーン情報を含む)
• 対象ホスティング環境: Self-Managed、クラウド、または GitLab.com?
• 課題/ペインポイント: お客様のペイン/問題は何か?
• 必要な機能: お客様は何を必要としているか?
• 現在のツール/競合: 現在のツールセットは何か? それらのうち譲れないものはあるか?
• SA への依頼内容: SA に何を求めるか (デモ、テクニカル Q&A、SOW など)

1. 必要に応じて以下のラベルを 1 つ以上追加します (ラベル一覧は下記)。

ボードラベルの説明

• Open/no label: 新規に提出された Issue
• SA Triaged: SA によって Issue 所有権が主張された
• SA Demo Ready: お客様とのインタラクションのための準備が完了し、さらなるスケジューリングや会話が可能
• Security Audit: このリクエストにはセキュリティチームの関与が必要 (通常はお客様のセキュリティアンケートを受け取った時点)
• Services Request: この Opportunity がサービスにフォーカスしている場合、このラベルを使って示す
• SA Doing: SA が Issue にアクティブに取り組んでいることを示すと、Issue は「Doing」に移動。Issue は SA、お客様、営業チームが完了に同意するまでこのステータスのまま
• SA Followup: この特定のリクエストに対して SA によるフォローアップ作業が必要 (例: コール終了後にリサーチが必要な質問)
• SA Waiting: このラベルは、SA がこの Issue を進めるために依頼者からのさらなる情報を待っていることを示す
• SA POV: PoV がリクエストされている、またはサポートが必要

Issue のトリアージ

各地域に関連する SA チームは、トリアージボードまたは関連 Slack チャンネルを監視して受信作業を確認し、必要なスキル、スケジュール、可用性に応じて、Slack、メール、または電話で適切な Customer Success チームメンバーに連絡します。アクティビティの SLA は 48 時間ですが、Issue が「Expedite」ラベルでマークされている場合は除きます。

イベントを支援する SA を依頼する

ソリューションアーキテクトは、その専門知識を必要とするイベントの支援によく必要とされます。イベントサポートのリクエストには、世界中の SA 割り当て、依頼者・SA リーダーシップ・個々の SA の協働が必要です。効率的かつ透明性のあるリクエスト/トリアージプロセスがなければ、必要以上の費用が発生し、収益機会の SA エンゲージメントが妨げられ、ダイバーシティ&インクルージョンが最適でなくなるリスクがあります。

イベント支援を SA に依頼するには、以下が必要です:

1. SA_Request テンプレートを使用してリクエストを作成します。
2. 必要なすべての情報を提供します。

SA リーダーは SA リクエストトリアージボード を活用してすべてのリクエストを追跡し、各イベントに最適な SA を割り当てます。以下の基準が考慮されます:

• 必要なコンピテンシー
• SA の可用性
• SA の所在地
• ダイバーシティ & インクルージョン

このリクエストとトリアージプロセスに従うことで、イベントサポートに伴う費用を最小化し、収益を生む Opportunity への影響を回避し、イベントでダイバーシティ & インクルージョンを表現することを確実にします。

SA の参加を確保するための SLA は 5 日間です。

プロダクトからのソリューションサポートを依頼する

見込み顧客またはお客様が、私たちの製品提供に直接マッピングされない機能を必要としている場合、ソリューションアーキテクトの最初のステップは、現在のツールセットでその要件を満たすソリューションや回避策を探ることです。 SA が見込み顧客に適したアプローチを判断できない場合、次の最善のアクションはプロダクトマネージャーに連絡することです。どのプロダクトマネージャーが適切かを判断するには、Product Categories ハンドブックページをレビューしてください。

可能な限り効率的に進めるため、推奨されるアプローチは以下のとおりです:

1. 収集: お客様のジャーニーを文書化し、明確化する
   1. まずアカウントマネジメントプロジェクトで Issue を作成することから始めます。お客様のビジネス目標、既存のアプローチ、見込み顧客とのコミュニケーション (コール録画、メールなど) を含めます。
   2. Customers & Prospects フォルダの running log を参照します
2. 検討: 該当する場合、お客様と検討したソリューションや回避策、それが不十分だった理由を文書化します
3. エンゲージ: プロダクトマネージャーに連絡します
   1. アカウントマネジメント Issue へのリンクを含めて、SA/SAE/PM などと新しい Slack チャンネルを作成します
   2. 思いやりを持ち、最低 48〜96 時間のリードタイムを贈りましょう。適切に行えば、PM は少なくとも 1 週間前の通知を受け取るべきです
   3. アカウントマネジメント Issue、履歴、進行中ドキュメント、共有資料を使って協働します
   4. [任意] 資料と次のステップを調整するための内部チームコールを提案します
4. コミュニケーション: 見込み顧客またはお客様とのコールをセットアップし、次の最善ステップを決定します。

Demo Architect からコンテンツをリクエストする

Demo Architect の支援が必要となる主な理由は 2 つあります。1 つは特定のイベント向けのコンテンツ/インフラのセットアップを支援してもらうこと、もう 1 つはすでに存在するかもしれない、または存在しないかもしれないデモのリクエストです。プロセスは以下に分けられます。

ハンズオンワークショップ/ラボ

これを行うベストな方法は、こちらの Issue に記入することです。Issue に追加する前にすべての列の答えを知っている必要はありませんが、情報を追加することで Demo Architect が初期のプランニング/コンテンツハンドオフミーティングをセットアップしてくれます。一般的な依頼として、イベントの少なくとも 1 週間前に通知することを意識してください。

特定のデモ

まず CS Shared Demo Space を確認し、お探しのデモがすでに存在しないかを確認してください。コンテンツを閲覧するためにアクセスをリクエストする必要があるかもしれません。それでも探しているコンテンツが見つからない、またはデモのいずれかにアップデートが必要だと考える場合は、こちらの README に従って Issue をオープンしてください。

ページのソースコードを見る - ページの編集 - please contribute.