注: 以下の翻訳の正確性は検証されていません。AIPを利用して英語版の原文から機械的に翻訳されたものです。
現代のビジネスとオペレーティングシステムは相互に連携した風景の一部であり、例えば、一国での政治的不安定さが他の国の株式市場に大きな影響を及ぼしたり、一つの業界での材料不足が他の需要の高い製品の価格や入手可能性に影響を及ぼすことがあります。
さらに、組織が完全に孤立して存在し、運営している場合、失われたリソースと収益、革新と発見への遅い道筋、効率の低下、既に他者が犯したミスを繰り返すリスクというコストを負うことになります。組織の効果性は、組織内外での手作業によるアドホックなデータ共有を必要とする非統合システムによって阻害されることがあり、これによりセキュリティとデータガバナンスにおいて重大なリスクが生じることがあります。
組織は、必要なデータのリクエスト、集約、正規化に多くの時間を費やすあまり、データを理解し、より良い意思決定を行うために行動を起こすことができません。
ここで、組織や業界全体がエコシステムの一部となることで利益を得ることができます。
エコシステムでは、組織は互いにデータとアプリケーションを安全に共有することができます。効率的なサプライチェーン、新薬の発見、品質管理などは、情報共有から利益を得るプロセスの例です。
例えば、上流のサプライチェーンの混乱を早期に検出し、それに適応することができる小売業者は、作業資本を抑えつつ、更なる収入を生み出すことができるかもしれません。この仮想的なシナリオでは、同じエコシステム内の製造業者やベンダーは、小売業者の在庫が少ないことに対する洞察を得ることができ、これにより製造スケジュールを最適化して利益性と在庫保有を改善することができます。組織間のデータとアプリケーションの共有は、関与する全ての当事者に利益をもたらすことができます。
Palantir Foundryは、複数の組織が標準化されたデータ形式とアプリケーションインターフェースでデータを安全に共有できるような、組織間のエコシステムを可能にします。Foundryは、航空、自動車、金融、製薬業界を跨るエコシステムを動かすために必要なセキュリティ、データ管理、アプリケーション要件について、実績のあるレコードを持っています。これにより、相互に有益な共同作業とデータ共有が可能になります。
一般的に、エコシステムのステークホルダーには、企業、ベンダー、アプリ開発者、業界の他の参加者などが含まれます。各当事者は自分たちのスペースとデータガバナンスを完全に所有し、誰と何を共有し、何をプライベートに保つかについての厳密なコントロールを維持します。
Foundryは、データアクセス、調和、共同作業の主要な課題に対処し、任意の数のカスタムシステムから一つの集中化された形式に共有を自動化し、標準化します。データが中心的な管理ポイントを必要とする歴史的なモデルを超えて、Foundryは許可を分割することができるようになり、各当事者が自分たちのスペースとデータガバナンスをコントロールし、誰と何を共有し、各組織にとって何がプライベートであるかについて完全なコントロールを持つことができます。
Foundryは、エコシステムが成長するにつれてしばしば組み合わされる、いくつかの異なるスタイルの組織間エコシステムモデルをサポートしています。以下にいくつかの一般的な例を示します。
マーケットエコシステムモデルでは、一つの組織が同じマーケットの他の組織が参加するためのエコシステムを導入し、相互に有益なイノベーションの伝道師として機能します。
例えば、先進的な製薬クライアントは、(1)より堅牢な結果のために研究データをプールし、(2)新薬を開発するためのパートナーシップの機会を特定するために、マーケットエコシステムを作成することができるでしょう。
マーケットエコシステム図
Foundryは、プライベートと共有のspacesの設定を通じてマーケットエコシステムモデルを可能にします。組織は、プライベートスペース内のプロジェクトでプライベートなパイプラインとアプリケーションを構築することができ、どのデータが共有されるかを定義することができます。また、手動のエクスポートや自動化されたデータパイプラインを通じて共有可能なデータセットを作成することもできます。これらのデータセットは、共有スペース内の共同プロジェクトで複数の当事者によって使用することができます。組織マーキングなどの必須コントロールは、データセットへのアクセスを粒度レベルで監査し、コントロールすることを容易にします。データオーナーは、どの組織とその中のユーザーがデータセットにアクセスしているかを確認することができます。
共同作業による分析は、ContourやCode Workbookなどのアプリケーションを通じて共有スペースで行うことができます。参加者が共通のオントロジーを選択する場合、Object Explorer、Quiver、Vertexなどのアプリケーションを共有データアセットの上に活用することができます。
クライアントエコシステムは、組織がいくつかの方法でより良い製品とサービスを提供することを可能にします。このコンテキストでは、ホスト組織はクライアントとベンダーのエコシステムモデルの両方を採用することを選択するかもしれません。クライアントとベンダーのエコシステムの利点と構成は似ています。
クライアントとベンダーは、他のエコシステムメンバーが過去にアクセスできなかったかもしれない彼らのサービスや製品についてのデータを共有することができます。このデータ共有は、すべての当事者が製品の運用についてより多くのことを学び、時間とともにそれを改善するだけでなく、問題を予測する能力やトラブルシューティングを加速するなどのアフターセールスサービスにもつながることがあります。例えば、航空機製造業者(ベンダー)は、そのクライアント(航空会社)に航空機部品の保証請求に関する判断を下すためのアプリを提供するかもしれません。
二つ目に、組織は、クライアントやベンダーのデータに基づいたアプリなどのデジタルオファリングを既存の製品やサービスに補完することができます。この場合、航空機製造業者(ベンダー)は、そのクライアント(航空会社)に飛行スケジュールの改善に関する判断を下すためのアプリを提供するかもしれません。
ベンダーとクライアントエコシステム図
第三者エコシステムモデルとは、アプリ開発者、データプロバイダ、またはサービスプロバイダがプラットフォームに貢献し、既存のエコシステム参加者が使用するリソースを提供するように招待されるものです。開発者は、彼らがプラットフォームに持ってきたアプリやデータを開発、販売、デプロイすることができます。なぜなら、すべての参加者が共通のオントロジーを使用しているからです(以下のキーエレメントを参照)。エコシステムのホストは、それらの開発者、彼らのデータ、および彼らのアプリを認定することを選択することができるか、またはエコシステム内の開発者と潜在的なクライアントとの間で接続を促進することにより、より非公式なアプローチを促進することができます。
このモデルは、既にエコシステム内に異なる組織の確立されたネットワークが存在する場合に最も価値がある傾向があります。したがって、第三者エコシステムモデルは時間とともに進化する傾向があります。
3rd Party Ecosystem model
ホスト組織は通常、Foundryのエンロールメント(つまり、ライセンスと請求に関するPalantirとの契約的な枠組み)の所有者であり、ファシリテーターとして位置づけられます。このエンロールメントを通じて、ホスト組織は他の組織をオンボードすることができます。それらがクライアントであれ、他の市場参加者であれ、第三者であれ、ベンダーであれ、すべてがエコシステムのパートナーと見なされます。Foundryは、ホスト組織がWorkshopモジュールのようなFoundryアプリケーションを共有でき、メンバーが自分たちのデータを提供し、選択したデータをホスト組織と共有できる共有スペースを提供することで、エコシステムモデルをサポートします。
共通のオントロジーを定義することにより、ホスト組織は、メンバーが提供されたアプリケーションを利用できることを確認できます。これは、各個別のメンバーがどのソースシステムとデータフォーマットを使用しているかに関係なくです。メンバーは、自分たちのプライベートスペース内で、自分たちの独自のデータを共通のデータモデルに変換するパイプラインを構築することができます。共通のデータ変換パイプラインは、ホスト組織によってテンプレート化され、迅速なオンボーディングを可能にすることができます。
組織は、一度に複数のクライアント、第三者アプリプロバイダ、ベンダーと仕事をすることがよくあります。例えば、ベンダーは、ホスト組織やメンバー、またはプラットフォーム上にいない他の人々に最良の製品を提供するために、しばしば競争相手となります。データセキュリティとガバナンスは、このエコシステムモデルにとって非常に重要です。メンバーは、自分たちのデータを確実に保護し、管理し、制御することができることを確信する必要があります。Foundry内のデータは、必須のコントロールを通じてセキュリティとアクセス制御されており、共有すべきデータは意図した組織にアクセスでき、共有すべきでないデータは所有組織の外部のユーザーからはアクセスできないように保証しています。
以下に、すべてのエコシステムモデルに共通の要素をリストアップし、下の図では航空業界を例にしています。
接続されたネットワークの力を十分に活用するためには、エコシステムのすべての組織が、実世界のエンティティとその関係を表現するための同じスキーマ - Foundryではこれをオントロジーと呼びます - を使用する必要があります。エコシステムの参加者は、業界標準を使用するか、自分たちのオントロジーを定義することができます。オントロジーはFoundryでバージョン管理されており、単一のエコシステム参加者からの改善や入力がすべての参加者に利益をもたらすように、インクリメンタルな開発(例えば、需要に基づいて一つのエンティティを一度に)が可能です。同じスキーマを使用することは、参加者が同じソースシステムや生データフォーマットを使用することを必要としないことに注意してください。
Foundryは、Data ConnectionやCode Repositoriesなどのdata integrationツールのスイートを提供しており、これにより、さまざまなソースシステムとフォーマットからのデータを共通のデータモデルに変換するパイプラインの構築と変換が可能になります。これにより、エコシステムの参加者は同じソースシステムを使用する必要はなく、共通のデータモデルを使用することができます。入力データのフォーマットや入力システムに共通性がある場合、エコシステムのホストは一度それらを統合するためのロジックを定義し、Foundry内でそれを参加者と共有することができます。SalesforceやSAPなどの一般的なソースシステムの場合、ホストやユーザーはHyperAutoを活用して、入力データを共通のオントロジー・スキーマに変換する作業を加速することができます。
アプリケーションは、Foundryのネイティブツールの組み合わせを使用して、エコシステムの参加者全体でユースケースに対応する独自の方法を作成する方法です。共通のオントロジーを持つことで、エコシステムのホストは2つのタイプのアプリを提供できます:
複数の組織が単一のプラットフォーム上に存在するため、エコシステムはすべての参加者にとって最高レベルのプラットフォームとデータセキュリティを必要とします。このセキュリティを考慮に入れて設計されたFoundryは、すべてのエコシステム参加者がアクセスできる共同作業スペースと、一つまたは一部の組織のみがアクセス可能で共同作業が可能なプライベートスペースの両方を保護するためのツールの配列を持っています。これらのセキュリティツールには、エンロールメント、スペース、組織マーキングやセキュリティマーキングなどの必須コントロールが含まれています。
このユースケースパターンについて詳しく知りたいですか?同様のことを実装したいですか? Palantir で始めましょう。 ↗