GitLab 調達チーム

調達とは何か？

調達チームは、ベンダーを戦略的に審査・選定するプロセス、商業条件の交渉、物品・サービスの購入、および更新またはベンダーのオフボーディングプロセスを通じて、GitLab のサプライヤーライフサイクルを管理します。

調達チームの配置

年間 25,000 ドルを超える支出の部門別担当：

• マーケティング - Ashley Abbate
• セールス - Ashley Abbate
• プロダクト - Adrienne Ruhaak
• エンジニアリング - Adrienne Ruhaak
• People - Adrienne Ruhaak
• ファイナンス - Adrienne Ruhaak
• 法務 - Adrienne Ruhaak
• 年間 25,000 ドル未満の全部門支出 - Dasha Yarmusik
• 個人ソフトウェア購入 - Anam Shaikh

共通の目標

調達は GitLab を公開企業として支援するクロスファンクショナルなチームです。以下の方法で監視される4つの主要な目標があります：

1. ビジネスステークホルダーとの戦略的パートナーシップ - 新規または更新中のサードパーティ支出とサプライヤー管理の機会を確認するために四半期ごとに会議を実施する
   • 指標：サプライヤーセグメンテーション層
2. 年次コスト回避（ソフト）節約と前年比（ハード）節約の達成
   • 指標：ソフト節約（コスト回避）は提案されたコスト増加の緩和または新規購入の交渉です。ハード節約（前年比）は前年からのコスト削減であり、更新にのみ有効です。これにはユニットコストの引き下げ、ユーザーの削減、またはサービスと範囲の縮小が含まれる場合があります
3. サードパーティリスク管理と GitLab にとって最小限のリスクで最良の商業条件を取得することの確保
   • 指標：各四半期のアクティブおよび新規ベンダーの数、内部および外部監査を通じて報告・監視
4. 責任ある調達/購入とサプライヤーの多様性 - Zip と Coupa のオンボーディングおよび購入プロセスを通じて管理
   • 指標：Zip SLA と多様なサプライヤー

ベンダーライフサイクル管理

調達チームは、初期選定・契約から定期レビューおよび更新、そしてキャンセルに至る GitLab とのビジネス関係全体を通じて、サプライヤーが管理されるプロセスを確保する責任があります。

1. RFP とベンダー選定

すべての新規支出、既存サービスのベンダー変更、および既存契約の3年ごとの市場レビューは、GitLab に最良の商業条件で最善のパートナーを確保するため、調達カテゴリーマネージャーによる承認がない限り、RFP とベンダー選定プロセスに従う必要があります。これは、新規または既存ベンダーとの口頭での条件合意や契約締結前に完了する必要があります。

• 内部ハンドブックに記載されている RFP プロセスに従ってください。クイックビッドから5社以上のベンダーが参加する調達主導の本格的な RFP まで、あらゆるレベルの RFP イベントのリソースとテンプレートが用意されています。RFP の実施を調達カテゴリーマネージャーに必ず通知してください——プロセスのサポートやご質問への対応が可能です。
  • このプロセスの一環として、RFP インテークテンプレートで Issue を作成し、カテゴリーマネージャーをタグ付けしてください。

GitLab のビジネスニーズに関する詳細や機密情報を共有する前に、潜在的なベンダーから相互非開示契約を取得してください。署名権限については署名権限マトリックスをご参照ください。

すべてのベンダーはGitLab パートナー行動規範に従う必要があります。私たちとのビジネスを希望する場合、すべてのベンダーがこれに契約上従うことは必須です。（これらはイベント関連の契約では、ベンダーがサービスを提供している場合を除き、通常必要ありません）

2. 交渉、プライバシー、セキュリティ、コンプライアンスレビュー

支出額に応じて、調達が契約の価格と商業条件の交渉を支援または主導します。

ベンダーと共有されるデータの種類に応じて、プライバシーとセキュリティがベンダーのレビューを完了する必要があります。ベンダーのサービスの性質や推奨を受けているかどうかに応じて、倫理・コンプライアンスチームが腐敗防止/贈収賄防止レビューを完了し、そのリスクを軽減するための追加措置を推奨する必要がある場合があります。

これらの要件と手順の詳細については、レビュー手順、スケジュール、考慮事項のセクションをご参照ください。

3. 契約締結

ベンダーとのすべての作業には完了した契約が必要であり、契約が締結されるまで作業を開始することはできません。契約にはNDA、マスターサービス契約、作業指示書が含まれます。法務チームがこの手順を支援します。詳細については法務レビュープロセスをご参照ください。

また、GitLab を代表して契約に署名できるチームメンバーは限られています——詳細については権限マトリックスをご参照ください。

4. ベンダーのオンボーディング

ベンダーへの支払いが行えるよう、システムへのオンボーディングを完了する必要があります。詳細については新規ベンダーオンボーディングセクションをご参照ください。

5. 定期ベンダーレビューと管理

調達チームは四半期ごとの調達・ビジネスハイライトを通じて、今後の更新とキャンセル、新規支出プロジェクトの確認、およびベンダーのセグメンテーション層（戦略的、ニッチ、汎用、取引的）の特定についてサポートします。

サプライヤーが属するセグメンテーション層を特定することで、適切なベンダー管理アプローチ（契約更新、RFP、定期的なビジネスレビュー、継続的改善計画など）を決定するのに役立ちます。

ベンダーとビジネスレビューを行う場合は、以下のトピックについて話し合うべきです：

• 契約の成功基準
• うまくいっていること
• 改善できること
• 問題のレビューと期待される改善策
• 契約とその利用状況の概要

ベンダー更新

四半期ごとに、調達チームは各部門のビジネスステークホルダーと会議を開き、今後2四半期に焦点を当てた12か月間の更新リストをレビューします。このリストは Zip と Coupa から取得されます。リストはビジネスオーナーとともにレビューし、優先順位を決定する必要があります。更新プロセスは更新日の少なくとも90日前に開始し、条件を確認して決定するのに十分な時間を確保する必要があります：

• ベンダーに対してセキュリティ要件の追加はあるか？
• 制裁スクリーニングツール Risk Rate は、ベンダーが元々オンボーディングされてから潜在的な一致を検出したか？
• 腐敗防止リスクプロファイルは変化したか？
• 過去3年間でベンダーの価格に関する RFP が実施されたか？
• 契約に従って積極的に通知する必要がある解約または支出の削減を希望するか？
• 契約条件を変更したいか？

6. キャンセル

キャンセル（解約または非更新を含む）を記録するために以下の方法が使用されます：

1. 自動通知： 購入品目の DRI が今後の更新の通知を受け取る
2. 調達主導： 調達チームが四半期ごとの「カテゴリースポットライト」会議中に今後の更新とアクティブな購入をレビューする
3. DRI 主導： DRI とその他のステークホルダーが製品、イベント、またはサービスが不要になったと判断する

上記のいずれかにおいてキャンセルが希望される場合（解約または非更新を含む）は、以下の「キャンセルプロセス」に従ってください：

1. Zip でインテークフォームに記入し、キャンセルする既存の契約のコピーを提供することで解約/非更新リクエストを提出する。
2. Zip を通じて、調達と法務がリクエスト者に対して、ベンダーへの通知の方法、タイミング、担当者の指示を提供する。ほとんどの非更新通知については、ビジネスオーナーが法務のガイダンスに従ってベンダーに通知します。
   • データがベンダーと共有されている場合、データの返却または削除の要件を確認するために、セキュリティとプライバシーが認識と確認のために追加される場合もあります。
3. ソフトウェアのオフボーディングなどの特定のキャンセルリクエストについては、必要なデプロビジョニングとシステムオフボーディングの手順を決定・完了するために IT が Zip ワークフローに含まれる場合があります。これには HelpLab の Tech Stack Update プロセスを通じてシステム削除リクエストを提出することが含まれます。
4. 必要に応じて、リクエスト者またはビジネスオーナーはキャンセルを影響を受けるすべてのまたは特定のチームメンバーに通知するコミュニケーション計画を作成・実施する必要があります。

今後の解約/非更新については、調達がカテゴリーリード/予算オーナーとともに実施する四半期カテゴリースポットライト会議で議論されるべきです。これらの会議で今後のキャンセルが把握された場合、調達は四半期ごとに既知のキャンセルを法務とともにレビューして、通知要件が満たされているか確認します。その後、調達と法務がビジネスオーナーと協力して上記のプロセスを完了します。キャンセルがこの四半期ごとのサイクル外に決定された場合は、できるだけ早く調達カテゴリーマネージャーに通知し、上記のプロセスを完了してください。

調達プロセス

サービス/物品のサプライヤーグループを評価している場合、または GitLab に代わって個人経費には該当せず例外リストの条件も満たさない購入を行う場合は、購入または作業を開始する前に調達への関与が必要です。以下の場合に調達プロセスを開始してください：

1. 会話またはメールでサプライヤーと事業、法的、価格条件に合意する前
2. 新規または定期ビジネスのための契約または見積もりを受け取ったとき
   • サプライヤーから契約を受け取った場合は、調達チームにレビューを依頼するとサプライヤーに伝えてください
3. サプライヤーグループを評価しているとき、または RFP プロセスを開始するとき
4. 開始する場所や時期がわからない場合は、#procurement Slack チャンネルで @procurement_team にタグを付けてサポートを求めてください。また、調達カテゴリーマネージャーに直接連絡することもできます。

調達プロセスの開始方法

調達プロセスの大部分は Zip という調達システム内にあります。Zip にはOkta のホームページからアクセスできます。Zip アクセスが必要な場合は、こちらからアクセスリクエストを提出してください。

Zip のトレーニング資料については、Zip エンドユーザーガイドおよび Zip リクエスト提出のヒントページをご参照ください。

購入のいくつかの要因に応じて、調達への関与方法と調達プロセスの開始方法は異なります：

1. 以下の場合は Zip リクエストを提出する
   1. 既存ベンダーのサービス更新の購入リクエスト
   2. 25,000 ドル未満の新規支出の購入リクエスト
   3. 既存 PO への変更リクエスト
   4. デモやトライアルを含む $0 の契約レビュー
   5. パートナー収益支払い
   6. 個人使用ソフトウェア
   7. 解約または非更新の通知
2. 新規支出、既存サービスのベンダー変更、またはサービスを3年間更新した後は、RFP プロセスに従う
   1. 250,000 ドル超：調達主導の RFP、通常5社以上のベンダー入札
   2. 100,000 ドル〜250,000 ドル：ビジネス主導の RFP、2〜3社のベンダー入札が必要
   3. 25,000 ドル〜100,000 ドル：ビジネス主導のクイックビッド、2社のベンダー入札が必要
   4. 25,000 ドル未満：入札不要

派遣社員の採用？

派遣社員を採用する場合は、GitLab の派遣社員ポリシーをお読みください。このポリシーでは、さまざまな種類の派遣社員の関与に関する包括的なガイドラインを提供しています。ポリシーでは3つの主要なカテゴリーを概説しています：スタッフ補強ワーカー（エージェンシーが提供する一時リソース）、コンサルティングサービス（サードパーティのプロフェッショナルサービス）、独立コントラクター（例外的にのみ使用）。各ワーカータイプの特性、期間制限、国別採用ガイドライン、コントラクター延長プロセス、バックグラウンドスクリーニング要件の詳細情報が記載されています。このポリシーは、チームメンバーが分類リスクを軽減しながら適切に派遣社員を関与させる時期と方法を理解するのに役立つよう設計されています。

注：プロフェッショナルサービスチームの下請業者については、収益パートナー支払いのプロセスを使用してください。

レビュー手順、スケジュール、考慮事項

リクエストは、購入リクエストのレビュー時間に影響を与えるいくつかの要因によって、5日から3週間以上かかる場合があります。これらには以下が含まれますが、これらに限定されません：

1. 新規または既存のベンダー
2. 交渉が必要かどうか
3. ベンダーと共有されるデータの種類とセキュリティおよびプライバシーのレビューが必要かどうか
4. 契約の複雑さと GitLab のベンダー利用規約との整合性
5. ベンダーの対応時間と交渉の意欲

各レビューの目標承認時間は以下に示されていますが、前述のように、これはリクエスト者が提供した情報の精度と完全性を含む多くの要因に依存します。リクエストが以下に概説された追加承認基準のいずれかを満たす場合は、各クロスファンクショナルチームがレビューを完了するのに十分な時間を確保して Zip リクエストを提出してください。以下のスケジュールを満たすことができず、ビジネスへの具体的かつ定量化可能な影響がある緊急リクエストの手順に従ってください。

1. 制裁スクリーニング（倫理・コンプライアンス）：30分〜3日以上（必要な場合）

• ベンダーの完全な名称を Zip リクエストに使用してください。これが制裁スクリーニングツール Risk Rate での自動スクリーニングの基礎になります。不完全な名称（例：「EY Germany」ではなく「Ernst and Young GmbH」）は誤検知を引き起こし、不要な遅延につながる可能性があります。
• Risk Rate がベンダーと適用される制裁リストの間に一致がなく、ベンダーが高リスク国に所在していない場合、ベンダーは自動承認されます。Risk Rate が潜在的な一致を検出した場合、またはベンダーが高リスク国にある場合、GitLab の貿易コンプライアンス顧問へのエスカレーションと手動レビューが必要になる場合があります。
• 顧問がより迅速に一致を評価できるよう、関連する Zip フィールドにベンダーのウェブサイトまたは LinkedIn ページを事前に含めてください。

2.A. バイヤーレビュー（調達）：2日

• リクエストを提出する際に適切な契約書類がアップロードされていることを確認してください
• 要求の金額が契約金額と一致し、正しい請求コードが選択されていること

2.B. 新規サプライヤーオンボーディング：2〜3日以上（必要な場合）

• これは完全にサプライヤーの対応時間に依存します。
• サプライヤー情報が Zip に提出され、調達チームが Coupa でベンダーを設定したら、サプライヤーは支払いを円滑化するための銀行口座と税務情報を要求する Coupa からのメールを受け取ります。
• 私たちがこの情報を知らないため、調達チームはサプライヤーに代わってこれを完了することはできません。行った場合、SOX コンプライアンスガイドラインに違反することになります。
• サプライヤーが2日後にオンボーディングされていない場合は、これが完了するまで契約のレビューも承認もできないため、サプライヤーに直接連絡してできるだけ早く行うよう求めてください。[email protected] をカーボンコピーしてください

3.A. FP&A レビュー：2日

• FP&A は、要求された支出が予算内であり、Zip に入力された請求コードが正しいことを確認するための初期レビュアーとして含まれています。最終承認の準備ができたら Coupa に転送できます。

3.B. IT レビュー：2日（新規ソフトウェアの購入またはコントラクターの場合）

• リクエスト者はベンダーに IT 新規ソフトウェアアンケートを記入してもらい、購入リクエストと一緒に提出して IT がレビューを完了できるようにする必要があります

4.A. 法務レビュー：3〜21日

レビューと締結までの時間は、以下の詳細に基づいています。これらの SLA をガイドラインとして使用してください。各契約レビューは固有であることに注意してください。追加の条件、要件、または要件が確認された場合は、スケジュールが延長される場合があります。GitLab がアグリーメント交渉を効率的に進める能力は、ベンダーとその顧問が GitLab の修正や コメントに迅速に対応することに依存します。サプライヤーからの遅延は承認を遅らせます。

ベンダーの種類とレビュー時間

• 既存ベンダーの更新またはアップセル：3〜5日

  • 既存ベンダーは既存の条件が整備されているため、通常は大幅に少ない時間で済みます。ただし、GitLab が新しい製品またはサービスを追加する場合、既存の合意を修正するために追加のサイクルが必要になる場合があります。
  • ⚠️ 完全な契約条件（添付書類と修正を含む）をアップロードするか、既存の合意への直接リンクを提供する必要があります。現在のリクエストをカバーするセクションを示してください。例えば、「ベンダー XYZ との既存マスターサービス契約（Zip req #67890）、修正#3 が要求している新しいソフトウェアモジュールをカバーしています」。「ベンダーとの既存の合意でカバーされています」のような一般的な参照を提供したり、法務が指示なしに条件を見つけられると思わないでください。

• 新規ベンダー：1〜3週間以上

  • 新規ベンダーは、調達される製品またはサービスの使用を管理する条件を初めて確立する必要があるため、最も多くの時間がかかります。
  • すべての契約書は英語で Word (.docx) 形式で提供する必要があります。 PDF バージョンは効率的に修正できないため、法務レビューには受け入れられません。リクエストを提出する前に Word バージョンを要求するためにベンダーに連絡してください。
  • 交渉は、執行可能な条件に達するために必要な詳細と変更の程度によって、1週間から数か月に及ぶ場合があります。
  • ベンダーがGitLab 標準条件を容易に受け入れない場合、追加の修正および交渉のラウンドが必要になり、この SLA が延長されます。
  • 可能な場合は、法務チームは割り当てから少なくとも5営業日以内にベンダーへの修正を提供することを目標としています。

契約の種類

• ソフトウェア（SaaS およびオンプレミス）： GitLab に課される権利と義務が（i）提供されるソフトウェアに対して合理的であり、（ii）GitLab の契約および業界標準と一致していることを確保するために最も厳密なレビューが必要です。
• プロフェッショナルサービス/トレーニング： 知的財産の所有権が私たちの意図と一致していること、および GitLab に課される合理的な義務を確保するための詳細なレビューが必要です。
• マーケティング/イベント： 問題のイベントとプログラムに応じて義務が標準化されているため、通常は最も少ない時間でレビューできます。イベントに関する詳細には、不可抗力、キャンセル（ペナルティを含む）に関する交渉、および条件が要求している GitLab チームメンバーの条件と一致していることの確認が含まれる場合があります。
• データ処理契約（DPA）/標準契約条項（SCC）： 個人データが GitLab に代わって供給者によって共有、アクセス、または収集される場合に必要です。DPA/SCC は通常合意に付随していますが、プライバシーの決定により（以下のプライバシーレビュープロセスを参照）、別の合意として必要になる場合があります。

交渉、セキュリティ、プライバシー、および PeopleOps レビューは、以下に説明する特定の基準を購入リクエストが満たす場合にのみ必要です。これらの活動のうち2つ以上が必要な場合、それらは互いに並行して、および法務のレビューと並行して実施されます。

4.B. 交渉：12日

• 調達チームは SaaS 契約（25,000 ドル超）および一時払い契約（100,000 ドル超）を交渉する
  • この手順が取られない場合、調達が交渉できるまで発注書は承認されません
• SLA は、大規模および/または複雑な契約に必要な交渉のレベル、およびサプライヤーが予算とベンチマーク指標を満たす意欲によって延長される場合があります。大規模な支出購入については、早期に調達と関与して、リクエストを Zip に提出する前に交渉を開始するのが有益です。
• ベンダーへの法務修正の伝達について：
  • 契約金額が 100,000 ドルを超える場合、または調達がすでに積極的に交渉またはベンダーとコミュニケーションしている場合、調達は法務修正をベンダーに送信する責任を持ちます。調達は可視性のためにベンダーへの修正送信時に要求にコメントします。それ以外の場合、ステークホルダー/リクエスト者が責任を持ちます。
  • 詳細はこちらをご参照ください

4.C. セキュリティレビュー：4〜14日

• セキュリティサードパーティリスク管理レビューは、オレンジ/レッドデータを収集、処理、または保存するベンダー、ソフトウェアプロバイダー（SaaS およびオンプレミス）、独立コントラクター/コンサルタントに対して必要です（フィールドマーケティングイベントを除く）
• この活動は、サプライヤーがセキュリティアンケートを完了し、セキュリティドキュメントを提供した後に開始できます。多くの場合、サプライヤーが対応して要求された資料を完成させるのに1〜2週間かかることがあります。セキュリティレビューの SLA はそれが完了してから始まります。この活動を開始できるまでの時間は、サプライヤーの対応時間とセキュリティプロトコルの成熟度に完全に依存します。
• ヒント： 承認速度を向上させるには、セキュリティコンプライアンスドキュメント（SOC-2 レポート、ISO27001 証明書）を ZipHQ リクエストにアップロードし、GitLab のセキュリティリスクチームからできるだけ早く完了のリクエストを受け取ることをサプライヤーの担当者に通知してください。
• 問い合わせと質問については、#procurement Slack チャンネルで @securityrisk にタグ付けしてください。

4.D. コンプライアンスレビュー：4〜14日

• Zip リクエストの最初のページには腐敗防止のゲート質問が含まれています（例：ベンダーは私たちに代わって政府機関と交流するか、このベンダーは政府関係者によって推薦されたか、など）。これらの質問のいずれかへの回答が「はい」の場合、倫理・コンプライアンスチームはベンダーが受け入れがたい高いコンプライアンスリスクを示しているかどうかを検討する必要があります。
• このために、倫理・コンプライアンスチームは追加のデューデリジェンスを実施します。これには、ベンダーに直接アンケートを送信することが含まれます。このアンケートは、リスクをより深く理解するためにベンダーの所有権と関連規制機関との歴史について尋ね、ベンダーが腐敗防止プログラムを実施しているかどうかを確認します。ターンアラウンド時間はベンダーの対応の速さに大きく依存します。
• リスクが存在する場合、倫理・コンプライアンスチームはそのリスクを軽減するために何かできることがあるか検討します。リスク軽減策としては、例えばベンダー契約に追加条項を設けることが挙げられます。

4.E. PeopleOps レビュー：1〜4日

• PeopleOps はバックグラウンドスクリーニングが必要かどうかを判断するために、すべてのプロフェッショナルサービス購入リクエストのレビュアーとして機能します。
• GitLab のPeople ポリシーに従い、コントラクターはバックグラウンドスクリーニングを完了する対象です。GitLab はコントラクターの雇用主が完了したバックグラウンドスクリーニングを受け入れます。ただし、バックグラウンドスクリーニングが実施されたことがない場合、GitLab は自らが実施するか、完了するよう求めます。
• バックグラウンドスクリーニングは、background_check_request テンプレートを使用してライフサイクル管理プロジェクトで Issue を作成することで依頼できます。
• 承認は、完了したまたは開始されたバックグラウンドスクリーニングの証明が共有された後、またはコントラクターが処理のためにバックグラウンドスクリーニングを提出した後に行われます。
• シニアバックグラウンドチェックスペシャリストは、バックグラウンドスクリーニングで懸念のある結果が返ってきた場合にのみフォローアップします。
• Zip のプロフェッショナルサービス購入リクエストのバックグラウンドスクリーニングに関する質問や証明は、[email protected] に送信できます。

4.F. プライバシーレビュー：4〜14日

• プライバシーレビューは、すべての SaaS 購入および、サプライヤーが GitLab からまたは GitLab に代わって赤/オレンジデータを受け取る他の購入タイプに対して必要です。既存ベンダーの場合、ベンダーが以前の調達サイクルで完全かつ満足のいくプライバシーレビューを完了していれば、24か月ごとに完全なプライバシーレビューが必要です
• この活動は、サプライヤーがプライバシーおよびトレードコンプライアンス評価フォームと移転影響評価フォーム（EUから米国への個人データの移転がある場合）を完了した後に開始されます。多くの場合、サプライヤーが対応して必要なフォームを完成させるのに1週間かかることがあります。SLA はそれが完了してから始まります。
• この活動を開始できるまでの時間は、サプライヤーの対応時間と DPA/SCC が必要かどうかに完全に依存します。
• DPA/SCC は通常サプライヤーとの合意の一部として作成されます。通常、プライバシーは私たちの DPA/SCC の使用を好みますが、サプライヤーが主要合意の別紙として DPA/SCC を提供する場合、法務とプライバシーはサプライヤーのバージョンを使用して最終的な合意バージョンに到達することがあります。調達は最終バイヤーレビューの段階で DPA/SCC の署名済みバージョンを取得します。
• ヒント： 承認速度を向上させるには、サプライヤーのプライバシー通知へのリンクを追加し、サプライヤーの移転影響評価ガイドをアップロードし、サプライヤーが自社のバージョンの使用を要求する場合は DPA/SCC の Word バージョンをアップロードしてください。

5. 最終バイヤーレビューと Coupa 購入リクエスト作成：2日

• 調達は、すべての情報が正確で合意がスタンプされていることを最終チェックしてから、最終承認のために Coupa に購入リクエストを作成します。

6. Coupa の承認と契約執行：4日

• この時点で、購入リクエストは最終的な FP&A、機能、エグゼクティブの承認（必要な場合）のために Coupa で作成されました。
• これらの承認が受理されると、調達は GitLab とベンダーの署名のために契約を回付し、回付時に Coupa 購入リクエストにコメントします。両当事者が合意に署名した後、調達は執行済み合意のコピーを Coupa に添付し、購入リクエストを承認して PO をリリースします。
  • 注：GitLab チームメンバーの中で契約に署名できるのは特定の人物のみです。権限マトリックスをご参照ください
• Coupa で承認ステータスを確認する方法については、Zip エンドユーザーガイドをご参照ください。
  • 注：この手順の完了は、必要な承認者が Coupa でどれだけ迅速に承認し、契約が署名されるかに依存します

7. リクエスト詳細の確定

• 購入リクエストが承認されました！サプライヤーは PO のコピーと、以下の2つの方法のいずれかで請求書を提出する方法に関する Coupa からの通知を受け取ります：
  • Coupa ポータルで直接（推奨）
  • 請求書に PO 番号を記載して [email protected] に送信する
  • これらの指示に従わないと支払いが遅延し、GitLab チームメンバーが Coupa にアップロードした請求書は支払いのために処理されません。
• この承認手順の中で、調達は署名有効日に基づく最終契約期間日など、リクエストの詳細を確定し、必要に応じて Zip の更新アラートを設定しています。
• 契約が署名され PO がリリースされた時点で、サプライヤーとの作業または サービスの取得を開始できます。

緊急リクエストがある場合は？

計画が立てられず、購入リクエストをエスカレーションする正当な理由がある場合は、以下のプロセスに従ってください。

• 以下の情報を含むエスカレーションリクエストを #procurement Slack チャンネルに投稿する：
  • Zip リクエストへのリンク
  • 必要日程
  • 日程が守られない場合のビジネスへの具体的かつ定量化可能な影響
    • 「サプライヤーが今日署名を望んでいる」はエスカレーションの理由として認められず、これらのリクエストは拒否されます。
    • 「金曜日までに署名しないと 45,000 ドルの価格上昇が生じる」または「PR の締め切りを逃すことでの実質的なブランドへの悪影響が生じる」は、レビューされる具体的で実質的なビジネスへの影響です。
• 本当に緊急でビジネスクリティカルなリクエストは評価されますが、これらは私たちのワークフローと、時間通りに提出されたリクエストの SLA を満たす能力を妨げることに注意してください。
• リスクと利用可能な帯域幅に基づいて、緊急リクエストに対応できる場合とできない場合があります。
• 締め切りのある重要なリクエストがわかっている場合は、エスカレーションを避けるために標準的な承認時間の1〜2週間前にリクエストを Zip に入力してください。契約が確定していなくてもプロセスを迅速化するために行ってください。

PO ポリシーの例外は何か？

PO ポリシーの例外は以下のとおりです：

1. 5,000 ドル未満の一時払い購入（または年間 5,000 ドル未満）
2. 慈善寄付（寄贈）
3. 面接候補者の経費精算
4. 機密の顧問法律費用
5. 機密の採用業務
6. 法定税費用
7. PEO プロバイダー
8. AR/顧客返金
9. 取締役会メンバーへの支払い
10. ファイナンス、バンキング、投資（利息、負債、外貨、手数料を含む）
11. コーポレートクレジットカード
12. 上記リストに含まれない緊急支払い（VP、コーポレートコントローラー、または PAO からの承認が必要）

サードパーティリスク管理

調達チームはコンプライアンスとリスクの観点から、以下のリスクを軽減するためにサードパーティリスクを処理するプロセスを策定しています：

• 以下のようなサードパーティの行動によって引き起こされる財務上の不正行為またはリスク：
  • データ漏洩
  • セキュリティ侵害
  • ビジネスの継続性
  • その他
• 供給に影響を与えるサードパーティの財務的実行可能性の失敗
• サードパーティの行動から生じる評判損害
• サードパーティの行動による規制または法律の違反
• サードパーティによる顧客サービスの中断

財務的実行可能性チェックが必要な場合

以下のいずれかが当てはまる場合：

1. ベンダーが私会社、LLC、または自営業者
2. 提供されるサービスが継続的な運営に必要
3. クラウドホスティングサービス
4. 稼働率要件のある顧客へのサービスに直接関係
5. ベンダーが廃業した場合に回復不能なデータの保管
6. 交換または入れ替えに1週間以上かかるソフトウェアまたはサービス

GitLab（およびベンダー）の権利と責任を確立するための条件をどのように確保するか？

GitLab が物品またはサービスの調達のためにサードパーティと契約を結ぶ際は、GitLab 法務調達チームが条件をレビューします。このチームの目的は GitLab が締結する契約をレビューし、以下を確保することです：

1. 調達される製品またはサービスの種類に対して公正かつ合理的な条件；および
2. GitLab のベンダーに対する適切な義務の確保：
   • GitLab の行動規範および他の会社ポリシーへの準拠
   • 適用される法律、規則、規制（個人データの保護を含む）
   • 物品またはサービスの提供、サポート、供給

GitLab 法務調達チームは、条件の確保に加えて、契約がチームのニーズと一致していることを確保するために調達およびビジネスステークホルダーと頻繁にコラボレーションします。GitLab 法務調達チームは、複雑な技術的アプリケーションやプラットフォームサービスから、GitLab イベントのニーズを満たすためのイベント契約の作成や起草まで、幅広いニーズに対応します。

顧客サービスの中断をどのように防ぐか？

GitLab が自社の顧客に対して行うのと同様に、サードパーティとの合意には、ベンダーが GitLab に対して負う義務が含まれます。これには以下が含まれますが、これに限定されません：

1. 稼働時間/ダウンタイムのコミットメント（SaaS プロバイダーの場合）
2. SLA（サポートの場合）
3. 解約権
4. 中断の場合に GitLab が救済を求めることができるその他の商業契約条項

大規模社内イベントプロセス

SKO、プレジデントクラブ、Commit など、総コストが 100 万ドルを超える大規模な社内イベントについては、契約が執行されるまたは作業が実施される前に以下を完了する必要があります。

この規模のイベントの計画段階は、実際のイベントの少なくとも18〜24か月前に完了する必要があります。これにより、必要な社内承認を取得し、必要な RFP を実施し、大規模なホテルブロックや買い取りを予約するのに十分な時間が確保されます。

1. 調達カテゴリーマネージャーと FP&A ビジネスパートナーと連携して、イベントの運営に必要なさまざまなベンダーとイベント総予算のライン項目詳細を決定する。これには宿泊施設、食事と飲み物、イベント企画、現地サポート、レクリエーション、交通費などが含まれます。
2. 調達担当者と協力して、これらのベンダーの選定方法と必要な RFP を実施するスケジュールを決定する。RFP はイベント日の少なくとも20か月前に実施する必要があります。
3. RFP の完了後、上位2〜3か所の候補地とその合計価格を E Group DRI（CRO/CMO）と VP of Finance に提示して、希望する候補地と対応する予算を決定する。すべての情報は、これらの承認が記録できる Issue にまとめる必要があります。
4. 希望する候補地と予算が仮決定されたら、この情報を CFO の承認のために提示し、その後取締役会の四半期会議での承認または必要に応じてメールで提示する。取締役会の承認には数週間かかる場合があることに注意してください。CFO と取締役会の承認はイベント日の少なくとも18か月前に取得する必要があります。
5. すべてのエグゼクティブ承認が受理されたら、公式承認を文書化し、契約の署名を取得して PO をリリースするために Zip リクエストを作成する。

役立つドキュメントとテンプレート

契約テンプレート

• GitLab ベンダー利用規約
• ロゴ使用許可テンプレート
• データ処理付録（編集可能）
• EU 標準契約条項
• 米国コントラクター契約書
• SOW テンプレート
• 変更リクエストテンプレート

ドキュメント

• 非開示契約（NDA）プロセス
• 保険証明書リクエストプロセス
• ContractWorks へのサードパーティ契約アップロード
• 会社情報 - 会社の各法人に関する一般情報
• 商標 - GitLab の商標使用に関する情報
• 権限マトリックス - 支出と会社拘束に関する権限マトリックスおよび法的書類への署名プロセス

その他のサービス

• ホームオフィスと備品
• 個人使用ソフトウェア
• RFP とベンダー選定プロセス
• ベンダー利用規約
• 非開示契約（NDA）
• 慈善寄付
• 非コスト関連契約（トライアル/デモを含む）

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