ドキュメントの検索
karat

+

K

APIリファレンス ↗

注: 以下の翻訳の正確性は検証されていません。AIPを利用して英語版の原文から機械的に翻訳されたものです。

ガバナンスプロセス

Foundryプログラムチームを構築・拡大するにあたり、以下で説明する戦略的計画とガバナンスチェックポイントに従うことをお勧めします。これらの計画、レビュー、開発の各段階は、ユーザーの組織内で Foundry プラットフォームの維持、使用、展開に必要なさまざまな責任と活動に対処するために、ユーザーのチームが準備ができていることを確認するために重要です。

Foundryプログラム計画

SteerCo会議:ビジョン設定

  • フェーズ: 1+
  • 頻度: 四半期ごと
  • オーナー: プログラム責任者
  • 出席者/関係者: プログラムマネージャー、エグゼクティブ/シニアステークホルダー、ドメインリード

ステアリング・コミッティ(SteerCo)会議は、Foundryプログラムの高次元的な方向性を決定するための定期的な会議です。SteerCo会議の主な目的は、Foundryプラットフォーム全体の戦略的方向性、範囲、コストを評価することです。SteerCoで特定の高優先度プロジェクトが議論されることは一般的ですが、会議の焦点はそれだけではありません。

SteerCo会議のサンプルアジェンダは以下の通りです。

  • ライブ、開発中、見込みのユースケースのレビュー、関連するコスト、開発進捗、組織への価値。
  • ユーザーベースの変更の概要(例:ユーザー数やグループ/ユースケース別使用状況の増減)。
  • 組織全体のITランドスケープと目標のコンテキストでの Foundry プラットフォームのレビュー/議論。

開発とロードマップのレビュー

  • フェーズ: 1+
  • 頻度: 月次
  • オーナー: プログラムマネージャー
  • 出席者/関係者: プログラム責任者、ドメインリード

開発とロードマップのレビューは、過去1ヶ月間の進捗を検討し、今後1ヶ月間および長期的なロードマップでの成果物について合意することを目的としています。このセッションは、進行中の開発イニシアチブの進捗をレビューし、既存のユースケースに対する拡張機能の機会を議論し、新しいユースケースに対する機会を特定し、優先順位を決定するためのフォーラムです。

各セッションのサンプルアジェンダは以下の通りです。

  • 進行中の開発の進捗状況の更新。
  • ビジネスケースの評価を行い、ユースケースの価値を確認。
  • プロジェクト計画の変更を評価し、承認する。
  • 成果物/開発の優先順位に基づいて決定を行う。
  • ユースケース開発戦略のレビューおよび承認。
  • プロジェクト成功に重要な問題に対する解決策のレビューおよび提案。

アクティブなユースケース開発

スタンドアップ

  • フェーズ: 1+
  • 頻度: 毎日
  • オーナー: データリード
  • 出席者/関係者: オントロジーリード、ユースケースリード、データガバナンス管理者(必要に応じて)

スタンドアップは、ユースケースチームの各メンバーが進捗状況を報告する短い(30分未満)毎日のコールです。

スタンドアップの更新は通常、以下に限定されます。

  • 前日に取り組んだ内容。
  • 当日に取り組む内容。
  • 進捗を妨げるブロッカーのレビュー。

スプリント計画

  • フェーズ: 1+
  • 頻度: 2週間ごと
  • オーナー: データリード
  • 出席者/関係者: オントロジーリード、ユースケースリード、データガバナンス管理者(必要に応じて)

スプリント計画会議では、出席者が前回のスプリントで完了したものと完了しなかったものをレビューし、次のスプリントで取り組む内容を決定します。

例のアジェンダは以下の通りです。

  • チームの成果物/目標のレビュー。
  • 現在のブロッカーや開発優先順位の変更に関する議論。
  • 次のスプリントにおけるチームのキャパシティの確認。
  • 成果物の要件を確認し、適切な更新を行う。
  • サイズ見積もりを割り当て、スプリントの内容を決定し、作業を割り当てる。

プラットフォームガバナンス

プロジェクト作成レビュー

  • フェーズ: 1+
  • 頻度: 月次
  • オーナー: プログラム責任者(フェーズ1)、データガバナンス責任者(フェーズ2以降)
  • 出席者/関係者: プログラムマネージャー

新しいプロジェクトは、組織全体のユーザーからプロジェクト作成リクエストポータルを通じて作成リクエストを提出することで提案されます。これらのリクエストは、プロジェクト承認インボックスからレビューされ、承認または否認されます。

リクエストが承認されると、リクエストの詳細に従ってロールの割り当てとグループアクセスを制御してプロジェクトが作成されます。Foundryの各名前空間に対するプロジェクト作成権限は、中央のプラットフォームガバナンスチームに制限されるべきであり、開発の各段階でプラットフォームガバナンスが具体化するにつれて、このチームを構成する役割が進化します。

プロジェクトアクセスレビュー

  • フェーズ: 1+
  • 頻度: 随時
  • オーナー: プログラム責任者(フェーズ1)、データガバナンス責任者(フェーズ2以降)
  • 出席者/関係者: プログラムマネージャー

プロジェクトの役割は、特定のグループがプロジェクトで特定の役割を持つように制御されるべきです。組織の IDプロバイダ(IdP)グループに直接関連付けられたグループを確立することをお勧めします。

アクセスリクエストは、プロジェクト承認インボックスからレビューされ、承認または否認されます。 リクエストが承認されると、リクエスト者のアカウントがプロジェクトで適切な役割を持つグループに追加されます。

グループがどこで管理されているかによって、IdPグループにリクエスト者のネットワークアカウントを追加するか、Foundry固有のグループにFoundryアカウントを追加するかが必要になります。個々のユーザーがプロジェクトで直接役割を持たないようにすることをお勧めします。

データ権限管理レビュー

  • フェーズ: 1+
  • 頻度: 随時
  • オーナー: プログラム責任者(フェーズ1)、データガバナンス責任者(フェーズ2以降)
  • 出席者/関係者: ユースケースリード

Foundryのデータ権限管理は、データセットやパイプライン全体への一括アクセス制御から、データセット内のレコードの可視性制御に至るまで、いくつかの形式を取ります。

特定のユースケースに対するデータ権限管理の要件は、プロジェクト作成レビュープロセスの一部としてスコープ化されるべきです。適切なデータ権限を文書化し、適用する作業は、プロジェクト開発中に行われます。

ユーザーの活用

サポートチームの開発

  • フェーズ: 1+
  • 頻度: 随時
  • オーナー: データリード、プログラムマネージャー
  • 出席者/関係者: ドメインリード、データガバナンス管理者、ユースケースリード

ユーザーの問題のトリアージ、調査、解決を支援するための内部サポート構造の構築をお勧めします。この構造は、組織内での自主性を維持し、Palantirへの関与が必要な問題には、エスカレーション前に必要な詳細が提供されることを確実にするために、大きな影響を与えることができます。

フェーズ1/2: サポートはFoundryプログラムチームが対応することができます フェーズ2+: 専用の内部Foundryサポートチームを設立することをお勧めします

トレーニング開発

  • フェーズ: 2+
  • 頻度: 随時
  • オーナー: 教育&トレーニング専門家
  • 出席者/関係者: ドメインリード、ユースケースリード

Palantirは集中的なトレーニングリソースを提供していますが、Foundryプログラムチームは、組織のユースケースごとに特化した内部トレーニングカリキュラムを開発することをお勧めします。

これには、各ユースケースのデータフローとオントロジー要素のドキュメントの開発と維持、およびユーザーがコアアプリケーションを利用する方法のチュートリアルが含まれます。トレーニングの媒体は、プラットフォーム内および外部のドキュメント(例:インターフェースのチュートリアルやドキュメント)、録画や対面でのトレーニング/チュートリアルが含まれます。