プロフェッショナルサービスオペレーション

GitLab Professional Services のオペレーションプロセスとワークフローについて学びます。

GitLab Professional Services Operations へようこそ

Professional Services Operations は、Professional Services チームをサポートするために、コンサルティング、トレーニング、スケジューリング、レポーティング、バックエンドプロセスを協業させたものです。


連絡方法

私たちの チーム Slack チャンネル

Project Coordinator にはグループ @ps-scheduling をタグ付けして連絡できます


メンバー

内部ページ


プロジェクトコーディネーション - コンサルティング

コンサルティングプロジェクトのスケジューリング

Professional Services エンゲージメントのリードタイム

PS オポチュニティがクローズしました、次は何?

オポチュニティの予約前にプロジェクト作業を開始する必要がある場合、Work At Risk Process に従って承認を得る必要があります。

顧客コンサルティングプロジェクトのスケジューリング

コンサルティングオペレーションチームには、コンサルティングプロジェクトのスケジューリング進捗を追跡する ボード があります。Kantata プロジェクトのセットアップ、プロジェクトチームのアサイン、パートナーペーパーワークの進捗を追跡するために使用される チェックリスト があります。スケジューリングプロセスに関連する情報をリクエストする Project Scheduling Intake Issue もあります。

コンサルティングプロジェクトのスケジューリングリクエスト

SF Stage 5 より前にプロジェクトを計画する状況があることは理解していますが、PS Operations に連絡する前にほとんどの情報を満たしておきたいと考えています。

ActionDRI
SF オポチュニティが少なくとも Stage 5オポチュニティ オーナー
Forecast カテゴリが Commitオポチュニティ オーナー
顧客が SOW に同意したオポチュニティ オーナー
PS Quote がオポチュニティに作成されたオポチュニティ オーナー
MSA/PSA が締結済みオポチュニティ オーナー
顧客と合意したクローズ計画オポチュニティ オーナー
Customer Epic にスキルがプッシュされたアサインされた Engagement Manager
Project Scheduling Intake Issue に必要な詳細が記入されたアサインされた Engagement Manager

スタッフィング要件や質問については、Project Scheduling Intake Issue に詳細を追加し、アサインされた Project Coordinator にタグ付けしてください。Project Coordinator がアサインされていない場合は、Operations Manager にタグ付けして支援を求めると、その時点でアサインが完了します。今後、Project Scheduling Intake Issue にスケジューリングに関するすべての情報と議論が格納されます。PC Checklist は Project Coordinator が内部用に使用するだけです。

内部プロジェクトのスケジューリング

チームメンバーが、非顧客プロジェクト関連の項目、認定、ランプアップに時間を確保したい場合、コメントを介してリクエストを送信し、内部プロジェクトのいずれかの PC にタグ付けする必要があります:

  • PS Time Tracking Non-Creditable

コメントは以下を含むようアクティビティページに追加してください:

  • タスク
  • 必要な時間
  • 優先度

PC は対応可否を確認し、Master Planning にアロケーションでスケジュールします。

コンサルティングプロジェクトのアサイン

PC と PM がプロジェクトチームを揃えたら、PC は Kantata プロジェクトアクティビティで Consulting Project Assignment を送信し、これによりチームは誰がプロジェクトに関わるかを把握できます。

コンサルティングプロジェクトの請求ガイドライン

プロジェクトの請求は、各顧客の SOW または Order Form に概説されています。Professional Services が現在従っている請求条件は以下のとおりです:

  • SOW 締結時に請求
  • Order Form 締結時
  • Time and Materials
  • プロジェクトマイルストーン
  • 半額前払い、半額プロジェクト完了時
  • 完了時に請求

5 日間の Passive Acceptance(暗黙の受諾)は、顧客が異なる条件を交渉し Director of Professional Services が承認しない限り、SOW に含まれます。

コンサルティングプロジェクトの収益予測ガイドライン

プロジェクト収益のリリースは、プロジェクトの請求タイプに応じて行われます:

  • SOW 締結時に請求条件
    • SOW にはアクティビティを含むマイルストーンが含まれ、各マイルストーンが受諾されるか、Passive Acceptance に達した時点で収益をリリースできます
  • Order Form 締結時に請求条件
    • SOW にはアクティビティを含むマイルストーンが含まれ、各マイルストーンが受諾されるか、Passive Acceptance に達した時点で収益をリリースできます
  • Time and Materials 請求条件
    • 各月末に承認されたタイムシートの時間がレポートされる
  • プロジェクトマイルストーン SOW 請求条件
    • SOW にはアクティビティを含むマイルストーンが含まれ、各マイルストーンが受諾されるか、Passive Acceptance に達した時点で収益をリリースできます
  • 半額前払い、半額プロジェクト完了時の SOW 請求条件
    • SOW にはアクティビティを含むマイルストーンが含まれ、各マイルストーンが受諾されるか、Passive Acceptance に達した時点で収益をリリースできます
  • 完了時に請求条件
    • SOW にはアクティビティを含むマイルストーンが含まれ、各マイルストーンが受諾されるか、Passive Acceptance に達した時点で収益をリリースできます

コンサルティングプロジェクトの収益予測方法

T&M プロジェクト

T&M プロジェクトの収益は、Kantata の Master Planning でスケジュールされたソフトまたはハードアロケーションによって予測されます。スケジュールされた時間にプロジェクトのレートカードを掛け算します。

固定価格プロジェクト

固定価格プロジェクトは、Kantata プロジェクトのプロジェクトマイルストーンによって予測されます。各マイルストーンには Sign Off タスクがあり、そのタスクはマイルストーン内のアクティビティの正しい Sign Off 日付で更新されます。ベストプラクティスは、顧客がレビューして受諾を得るための時間を確保するように Sign Off タスクを更新することです。 アクティビティが完了して顧客が Sign Off するという確信がない場合は、Sign Off タスクを次の四半期に移動すべきです。

収益の Sign Off

T&M プロジェクトの収益リリース

T&M プロジェクトでは、収益は各月末にリリースされます。プロジェクト時間は Kantata のタイムシート機能を介して毎週提出されます。PSE または PM がプロジェクトに対して時間を提出し、Project PM または Lead が毎週承認します。各月末に、PC が承認されたすべてのタイムシートのレポートを取得し、統合レポートを Finance に提供してレビューと収益リリースを行います。

FP プロジェクトの収益リリース

FP プロジェクトでは、プロジェクト SOW の文言に従って、顧客の受諾が受領された時点、または Passive Acceptance を経過した時点で収益がリリースされます。 PM は顧客に受諾リクエストを送信し、Kantata の Billing/Revenue Milestone を更新します。受諾メールを送信する際、PM は Operations Manager とアサインされた Project Coordinator を CC に入れるべきです。Passive Acceptance の日数を数える際、Day 1 は通知が送信された日付で、その日付から営業日が Passive Acceptance のために計算されます。

PM は Kantata のプロジェクトマイルストーンについて以下を更新する責任があります:

  • Sign Off Sent カスタムフィールドを、メールリクエスト送信時に更新
  • Sign Off received カスタムフィールドを、受諾受領時または Passive Acceptance 到達時に更新し、受諾の PDF メールをマイルストーンに追加
  • Passive Acceptance Utilized for Sign Off カスタムフィールドを、Passive Acceptance を利用する場合に更新
  • 受諾を受領した場合は、受諾のメール (PDF) または署名済みの マイルストーンドキュメント をマイルストーンに添付
  • Passive Acceptance に達した場合は、メール (PDF) と マイルストーンドキュメント をマイルストーンに添付

トップレベル のマイルストーンフィールドのみ更新すべきであることに注意してください。マイルストーン内のサブアクティビティは更新 しない でください。

fprevenuerelease

プロジェクトコーディネーション - トレーニング

Train

GitLab Education Services のインストラクター主導コースを提供する PSE または Technical Instructor は、以下のワークフローを使用して顧客との円滑なやりとりを確保できます。さらに、PSE と Technical Instructor は、提供する予定の各コースについて GitLab Certified Trainer のステップを完了すべきです。

準備ステップ

  1. Professional Services Operations は「Welcome to Education Services Email」で顧客に連絡し、トレーニングのスケジューリングを開始します。トレーニングの日付と時刻が確認された後、Professional Services Operations はトレーニングセッションの計画ミーティングをスケジュールします。このミーティングへのトレーナーの参加が推奨されます。出席を確保するためにミーティングを再スケジュールする必要がある場合は、アサインされた Professional Services Operations のチームメンバーに知らせてください。

  2. Professional Services Operations は、これらの メールコミュニケーションテンプレート を使用して、顧客とトレーニング参加者に主要な詳細をコミュニケーションします。

  3. トレーニング計画ミーティング中、Training Event Plan Template に列挙されているすべてのイベントロジスティクスを議論しドキュメント化することを確認してください。Professional Services Operations はミーティング前に Training Event Plan のドラフトを作成し、トレーニング計画ミーティング中にドキュメントを更新します。

    • トレーニング計画ミーティング中、以下のコースアウトラインとシステム要件のページが、トレーニングのロジスティクス、トピック、テレカンファレンス、システム要件のレビューに役立ちます。
  4. Professional Services Operations は、これらのセットアップ手順 を使用して、各セッションの Zoom Meeting または Webinar セッションをセットアップし、登録リンクを Issue に追加します。Zoom Meeting または Webinar セッションに参加するためのユニークなリンクを含むメールメッセージを受け取ります。メールメッセージ内で Zoom 情報を見つけ、Zoom 機能に慣れることを確認してください。Webinar の出席者とパネリストの管理について役立つ Zoom の記事は こちら です。Zoom のセットアップによっては、https://zoom.us にログインし、Join a Meeting に行き、Meeting ID/Webinar ID を入力して Zoom セッションを開始することもできます。

  5. トレーニングセッションの少なくとも 2 週間前に、Professional Services Operations はセッション登録リンクを顧客にメールで送信し、セッションに参加してほしい従業員それぞれにリンクを送るように依頼します。各人が登録すると、Zoom Meeting または Webinar の参加リンク(各人ごとにユニーク)と、セッションをカレンダーに追加するためのリンクを含む自動確認メールを受け取ります。

  6. Professional Services Operations は、トレーニングに別のテレカンファレンスシステムが使用されている場合、それを通知し、テレカンファレンスミーティングへのアクセスのための追加詳細を提供します。

  7. GitLab Education Services チームに連絡し、コーススライドおよびその他の資料の最新バージョンを持っていることを確認します。

  8. 提供するコースの train-the-trainer (T3) 動画をレビューします。

  9. デリバリーの準備が適切に整っていることを確認するため、Instructor Pre-Training Checklist をレビューして従ってください。

  10. これらの PS Remote Training Tips and Tricks をレビュー、練習、使用してください。

  11. 以下の GitLab Training Lab セットアップステップを完了します。クラスの初日前に、ラボの演習をレビューし、ラボが正しく動作していることを確認してください。

  12. プレゼンターとしてテレカンファレンスに参加する時間が来たら、提供された情報を使ってセッションに参加します。

トレーニングラボのコース前のインストラクターワークフロー

PS は、ハンズオンのコースラボアクティビティとハンズオンの認定アセスメントの標準環境として、GitLab Lab Environment を使用します。コース受講者にラボアクセスを設定するには、以下のステップに従います。

1. GitLab ラボ環境招待コード

  1. Professional Services Operations は、Kantata プロジェクト内のインストラクター向けリマインダー投稿の一部として、クラスの開始日のおよそ 1 週間前に、クラスの招待コードを生成し、招待コード情報を提供します。
  2. GitLab Lab Environment Invitation Code Redemption ハンドブックページ の指示に従って、招待コードを引き換え、ラボ環境にアクセスします。
  3. 編集/延長など、またはカスタムの引き換えルール(標準とは異なる期間)については、GitLab Professional Services Operations チームに連絡して支援を求めてください。

2. 招待コードとアクセス手順を出席者と共有:

  1. クラスの初日に、招待コードを共有し、出席者とログインプロセスをレビューします。また、有効期限(ログインを生成した日から 30 日間)も知らせます。

トレーニングのクローズアウト

  1. トレーニングクラスをクローズアウトするためのすべてのステップに従ったことを確認するため、Instructor Post-Training Checklist をレビューします。
  2. Professional Services Operations は出席レポートをダウンロードし、メールコミュニケーションテンプレート にあるメールテンプレートを使用してクローズアウトメールを顧客に送信します。

トレーニング計画とスケジューリング

Professional Services Operations のプロセスについての詳細は、この 内部ページ を参照してください。


トレーニングプロジェクトの請求ガイドライン

トレーニングの請求は、各顧客の SOW または Order Form に概説されています。Professional Services が現在従っている請求条件は以下のとおりです:

  • SOW 締結時に請求
  • Order Form 締結時

5 日間の Passive Acceptance は、顧客が異なる条件を交渉し Director of Professional Services が承認しない限り、SOW に含まれます。

トレーニングプロジェクトの収益予測ガイドライン

トレーニング収益のリリースは、トレーニングの請求タイプに応じて行われます:

  • SOW 締結時に請求
    • 各トレーニングクラスが完了し、ロスターが受領された時点
  • Order Form 締結時の請求条件
    • 各トレーニングクラスが完了し、ロスターが受領された時点

トレーニングプロジェクトの収益予測方法

トレーニングプロジェクトは通常、固定価格プロジェクトとみなされ、Kantata プロジェクトのプロジェクトマイルストーンによって予測されます。各マイルストーンには、トレーニング準備/計画/クローズアウトとデリバリー時間を捕捉するための各トレーニングコースのタスクが含まれます。各タスクはマイルストーン内のアクティビティの正しい期日で更新されます。ベストプラクティスは、予測の目的で、トレーニング完了日を正確に反映するようタスクの期日が更新されていることを確認することです。 アクティビティが完了するという確信がない場合は、タスクの期日を次の四半期に移動すべきです。

トレーニングプロジェクトの収益リリース

トレーニングプロジェクトでは、プロジェクト SOW の文言に応じて、トレーニングが完了したとき、および/または受諾が受領されたときに収益がリリースされます。 プロジェクト SOW で必須の場合、Professional Services Operations は受諾リクエストを顧客に送信し、Kantata の Billing/Revenue Milestone を更新します

  • Sign Off Sent を、トレーニングが完了したとき、またはメールリクエストが送信されたときに更新
  • Sign Off received を、トレーニングが完了したとき、受諾が受領されたとき、または Passive Acceptance に達したときに更新し、クラスのロスターまたは受諾の PDF メールをマイルストーンに追加
  • Sign Off に Passive Acceptance が利用された場合に更新

trainingrelease


オペレーション

新規入社者

PS チームに新しいチームメンバーが加わったとき。レビュー対象のトレーニングとプロセスへのリンクがあります:

新規入社者レビュー

Kantata アクセス

内部 GitLab チームメンバーに Kantata アクセスを提供するには、以下の方法でアクセスを提供します:

  • Kantata Access
    • Settings
    • Members
    • Invite Account Members
  • Okta-Kantata- Users Google Group
    • Gmail
    • Gmail Apps
    • Groups
    • Okta-Kantata- users
    • Members
    • Add Members

GitLab パートナーに Kantata アクセスを提供するには、以下の方法でアクセスを提供します:

  • Kantata Access
    • Settings
    • Members
    • Invite Account Members
  • GitLab Access Request を処理
    • Okta をリクエスト
    • Kantata を Okta に追加するようリクエスト

時間追跡

正確な時間追跡記録は、Statement of Work(「SOW」)に概説されているプロジェクトスコープの完了率に基づいて収益を認識できることを確保するために必須であり、このデータは粗利益の計算にも使用されます。時間追跡の主要ポイントは以下のとおりです:

  • ベストプラクティスは、各日の終わりに時間を記録することです。これにより、稼働時間とそのタイミングの最も正確な記録が得られます

  • 各 PSE は自分の時間を追跡することが求められ、責任を負います。週ごとに金曜日 EOD までに提出します

  • 週末に作業する場合でも、タイムシートは金曜日 EOD までに提出すべきで、週末作業時間用のタイムシートに新しい行を作成します

  • 請求可能時間は、特定の SOW に紐づいているとスタッフメンバーが報告する稼働時間を表します。各チームメンバーの日次時間追跡フォーマットは以下のとおりで、週ごとに PS Operations と Manager がレビューします

  • PTO、祝日、Family and Friends day の時間は、もはや週次タイムシートで提出する必要はありません

  • チームメンバーがその週に割り当てられた時間を働いていない場合、Kantata の PTO 機能に時間が追加されます

  • PS Time Tracking - Non Creditable プロジェクトにはノートは不要です

  • 顧客プロジェクトにはノートが必要な場合があります。時間提出前に Project/Program Manager に確認してください

    • PTO は Kantata の time off 機能で提出し、企業ガイドライン time off process にも従うべきです
    • 祝日と Family and Friends day は Kantata カレンダーでスケジュールされます
  • 時間は最も近い 15 分単位に丸める必要があります、例:

    • 15m は .25
    • 30m は .5
    • 45m は .75

Kantata 内部プロジェクト

内部プロジェクトは、顧客プロジェクトに関連しない内部時間を追跡するように設定されています。以下はプロジェクトリンクとタスクおよび例です。

顧客コンサルティングプロジェクト

顧客プロジェクトに従事する場合、すべての稼働時間はプロジェクトに対して追跡すべきです。例:

  • プロジェクトタスクは SOW のアクティビティと整合し、時間はタスクに対して追跡される
  • 内部/販売引き継ぎコール
  • 内部/外部のステータスミーティング
  • プロジェクト進行中のサポートチケット提出
  • 週次/最終の顧客レポートとドキュメント
  • ステータス/クローズアウト顧客コール
  • 顧客への出張

顧客トレーニングプロジェクト

トレーニングプロジェクトに従事する場合、すべての稼働時間はプロジェクトに対して追跡すべきです。例:

  • 紹介/計画/準備/クローズアウト
    • すべての時間は、トレーニングの準備とクローズアウトのタスクに対して追跡される
  • すべてのクラスの時間は、トレーニング名を含むタスクに対して追跡される。例: GitLab Basics TRNG Hours

プロジェクト経費

オンサイト出張と経費プロセスについての詳細は、この 内部ページ を参照してください。

GitLab Travel ポリシーに関する他の質問がある場合は、Travel ハンドブックページ を参照してください。

Kantata プロジェクトステータス/カラー

Kantata Statusステータス定義
Estimate- GrayGitLab PS および GitLab Partner の内部時間を追跡しているプロジェクト
Prospect- GrayPC が Kantata プロジェクトをセットアップ中/プロジェクトが Stage 5 - スタッフィング計画のレビュー開始
In Set Up- GrayPC が Kantata プロジェクトをセットアップ中/スタッフィング/Welcome to PS Email のレビュー
Okay to Start- Light Greenプロジェクトセットアップ完了/PM がプロジェクトを計画中
Active- Dark GreenPM/PSE がプロジェクトをアクティブに進行中
Closed- Blueプロジェクト作業は完了、請求と収益の完了待ち
Completed- Blue請求と収益が完了
On Hold- Grayプロジェクトが遅延している
Backlog- Gray作業が計画されていない
Cancelled- Blueプロジェクトは作成されたが、さまざまな理由で作業されない

トレーニング専用プロジェクト には、以下の Kantata/Kantata ステータスを使用します:

Kantata/Kantata Statusステータス定義
Prospect- Grayプロジェクトはまだ予約されておらず、Stage 5
In Set Up- GraySFDC オポチュニティがクローズ/PC が Kantata プロジェクトをセットアップ中
Okay to Start- Light Greenプロジェクトセットアップ完了/Welcome to GitLab Education Services email
Active- Dark GreenPC がプロジェクトのスケジューリングをアクティブに進行中/トレーニング日程が顧客に提案されている
Closed- Blueオンサイトトレーニングプロジェクトのみ/トレーニングデリバリーは完了したが、経費レポート待ち
Completed- Blueすべてのトレーニング活動が完了/請求と収益の準備完了
On Hold- Gray部分的なトレーニング活動は完了している;顧客が残りのトレーニング活動のスケジュールを準備していない
Backlog- Gray顧客がトレーニング活動のスケジュールを準備しておらず、注文予約日から少なくとも 1 か月が経過している
Cancelled- Blueプロジェクトは作成されたが、さまざまな理由で作業されない
Kantata プロジェクトカラー
Blueトレーニング専用プロジェクト
Yellowコンサルティング専用プロジェクト
Orangeコンサルティング & トレーニングプロジェクト
Lime内部プロジェクト

コンサルティングプロジェクトのヘルスレポート

ヘルスレポートは、PS Management に対して、プロジェクト全体のステータスについての週次スナップショットを提供し、エグゼクティブまでロールアップされます。レポートには Red、Yellow、Green のインジケータと、全体ステータス、スケジュール、スコープ、予算、クライアントの更新セクションが含まれます。ヘルスレポートは、Active プロジェクトステータスのプロジェクトについて、各週の木曜日 EOD までにプロジェクトリードまたはプロジェクトマネージャーが記入すべきです。

  • 全体プロジェクトステータス:
    • 全体プロジェクトステータスを 2 〜 3 行で記述、長所/短所/ブロッカーを含む
  • プロジェクトスケジュール:
    • プロジェクトは現在の Kantata スケジュールに沿って進んでいるか? Y/N、N の場合はなぜか?
  • プロジェクトスコープ:
    • プロジェクトは SOW どおりの元のスコープに沿って進んでいるか? Y/N、N の場合はなぜか?
  • プロジェクト予算:
    • プロジェクトは SOW どおりの元の予算に沿って進んでいるか? Y/N、N の場合はなぜか?
  • クライアント:
    • 顧客はプロジェクトについてどう感じているか? 満足、不満、関与、非関与
    • プロジェクトはスコープ、スケジュールなどで red のステータスでも、顧客はまだ満足している場合があります

新規サプライヤーリクエストフォーム

  • 新規パートナー/ベンダー専用
  • パートナー/ベンダーは、Professional Services Request および Purchase Request フォームを提出する前に Coupa で承認されている必要があります
  • 新規サプライヤーリクエスト方法の手順

新規 Professional Services Request フォーム

  • Coupa(GitLab のベンダー請求書管理シス)の使用方法については、Coupa ハンドブックページ を参照

  • これは新規 Purchase Request フォームを開始します

  • Requisition の作成方法

  • Professional Services Request フォームの記入方法

  • ノート:

    • その個人が雇われて何をするか
      • GitLab Customer Name- Partner Name- PSE/ PM Name
    • すでに GitLab 従業員がこのサービスを実施しているか?
      • 多くの場合、「いいえ」と回答
    • GitLab がその個人に作業完了に必要なハードウェア/デバイスを提供するか?
      • 多くの場合、「いいえ」と回答
    • これは PS Partners サービスリクエストか?
      • 多くの場合、「いいえ」と回答
    • これは延長か?
      • 多くの場合、「いいえ」と回答
    • 意図されたエンゲージメントは 6 か月以上の予定か?
      • 多くの場合、「いいえ」と回答
    • Procurement に交渉してほしいか?
      • 多くの場合、「いいえ」と回答
    • 推定支出はいくらか?
      • 多くの場合、「いいえ」と回答
    • Requisition Information
      • パートナー名を追加
      • Description/ Item
        • GitLab -Partner Name- Customer Name- PSE/ PM Name
        • Training- Training: partner name / year month day
      • Partner SOW の価格
      • 通貨は常に USD
      • Commodity は COGS consulting fees
      • Service Start Date:
        • Consulting: 顧客プロジェクト日程の見積もり
        • Training: トレーニング資金を使い始める時期の見積もり
      • Service End Date:
        • Consulting: 顧客プロジェクト日程の見積もり
        • Training: トレーニング資金を使い始める時期の見積もり
      • Need by - 提出日から 1 週間後に設定
      • 支払い構造:
        • データ入力規約 - Consulting: Hourly rate/ または Fixed Price
          • 例: $###/hour
          • 例: $### Fixed Price
        • データ入力規約 - Training:
          • Standard Course Delivery: Fixed Price
          • Pre-Configured Course Delivery: Hourly Rate
        • Custom Course Delivery: Hourly Rate
        • 例 (standard course): $### per course
        • 例 (pre-config or custom): $###/hour
      • 承認のために購入リクエストを提出
      • 必要に応じて内部承認者にフォローアップ
  • Professional Services Request フォームを提出した後、Cart に適用されます。

  • Review Cart セクションに移動し、すでに記入され Purchase Request に追加された Professional Services Request フォームの質問とともに、Purchase Request の情報を入力します。

  • ノート:

    • Consulting の場合、「on behalf of」フィールドには誰も指定しないでください。PS Project Coordinator が新しい Purchase Request を起票します。
    • Training の場合、PS Education Services Manager が新しい Purchase Request を起票し、「on behalf of」フィールドに PS Project Coordinator を指定します。
  • General Info セクション:

    • Description of Purchase- PS Partner Sub Contractor Agreement
    • Attachments に Agreements を追加
      • Partner SOW
  • Service End Date を過ぎても作業が継続し、月次で請求書が処理されている場合、PO はオープンのままになります。何らかの理由で PO がシステム的にクローズされた場合、Accounts Payable Slack チャンネル #accountspayable を介して A/P に PO を再オープンするようリクエストを送信する必要があります。

発注書プロセス

  • すべての承認者が購入リクエストを承認した後、関連する Coupa PO が作成されます。
  • パートナー/ベンダーの請求書が PO に対して提出されます。
  • コメントセクション: パートナー請求 A/R PoC を @ メンションして請求書提出のリマインダーを送信
  • Project Coordinator は Partner Folder に Customer Folder をセットアップし、以下を含めます:

請求書処理と追跡

COUPA を介した現在のプロセス:

  • Project Coordinator は、Coupa からパートナー提出の請求書をレビューする通知を受け取ります。
    • 注 - 承認キューは、Consulting Project Coordinator が最初、Training Project Coordinator が 2 番目です。
  • Project Coordinator は、承認された時間とレートの正確性を確保するため、請求書と Kantata のタイムシートをレビューします。
  • 請求書とタイムシートが整合している場合、請求書は承認されます。
  • 請求書とタイムシートが整合しない場合、請求書は Accounts Payable に返却され、Project Coordinator がパートナーにフォローアップします。
  • Project Coordinator は、パートナー請求書資金追跡シートを更新して請求書番号、日付、金額を含め、請求書のコピーを Partner Folder に保存します。

パートナーへの請求書リマインダー送信 - 各月末

  • Kantata 内で Insights > Time & Expense Admin- Partners に移動し、その後 Time Approvals by Project レポートに移動します。
  • 日付範囲を入力し、表示したいパートナーで GitLab User Type フィールドをフィルタします。
  • レポートを実行し、ページの右上の歯車アイコンをクリックし Export to XLSX を選択して、Excel フォーマットでレポートをエクスポートします。
  • 該当するパートナーのタイムシート Google sheet に情報をコピー&ペーストします。新しいシートを作成する必要がある場合は テンプレート が提供されています。
  • パートナーのタイムシート情報の PDF バージョンを作成します。
  • テンプレート を使用して、パートナーの A/R ポイントオブコンタクトにメールを送信します。

エンゲージメント Epic と Issue をパートナーアクセス可能にする

背景
ノート
  • Epic は現在移動できないため、代わりに新しい場所で epic を再作成し、従属する Issue を新しい場所に移動し、元の epic をクローズします。詳細は以下の 手順 で説明します。
  • 元の epic と新しい epic は、Issue 移動の監査エントリを介してリンクされます。
  • 手順では、このエピック検索の Issue のため bulk edit を使用しません。
手順
  • 再作成する epic をブラウザタブで開きます
  • もう 1 つのブラウザタブで destination epics list UI を開きます
    • New Epic
      • Title - Customer Name Customer Project Epic
      • Description - 元の epic(現在もう 1 つのブラウザタブにある)から description の markdown をコピー&ペースト
      • Create epic
    • 新しい epic の URL をコピー&ペーストバッファに入れて以下で使用します
  • 再作成する epic 内の各 Issue について:
    • Issue を参照
      • Issue を新しい epic に移動するために /epic <url> スラッシュコマンド を使用
        • 例: /epic https://gitlab.com/groups/gitlab-com/customer-success/professional-services-group/ww-consulting/-/epics/2
        • スラッシュコマンドを使用するには、コメントインターフェースにコマンドのテキストを入力し、Comment ボタンで適用します

Kantata プロセス

Kantata は私たちの現在の Professional Services Automation (PSA) システムです。プロセスステップを表示するには以下のリンクに従ってください。

Kantata プロセスへのリンク

Kantata レポート

Professional Services チームは、プロジェクトとチームのメトリクスを追跡するために Kantata レポートを使用します

Kantata レポートリスト


Mavenlink プロセス
GitLab プロフェッショナルサービスの運用プロセスとワークフローについて学びます。