調査とコホーティング

組織は、ツールを用いて探すことができれば、大きな収益増加やコスト削減の機会を通常は持っています。例えば、電力網のリスクを特定する場合、潜在的な不正を調査する場合、材料の利益を改善する機会を特定する場合、あるいは次に最適な販売行動を見つける場合などです。調査とコホーティングのワークフローは、ユーザーが組織の共通の運用画像を作成し、専門知識とデータ分析を組み合わせて機会を明らかにし、現実の世界での解決策を実装することを可能にします。

解決策

調査とコホーティングのワークフローは、データに表現される収益または節約の機会を表す実際の問題または異常を理解し、グループ化することを目的として設計されています。また、問題への掘り下げを容易にし、修正を容易にします。これらは、探索的なアプローチに従い、問題を積極的に特定したり、関係を理解したりするために使用されます。この中で、コホーティングのロジックは、アナリストからの専門知識を導き、異常を明らかにするために使用されます。データの量が増え続ける中で、複雑な統計アプリケーションを扱うための技術的なスキルがないという問題が、アナリストの入門障壁となったり、組織がデータの複雑さを大幅に減らすことを強いたりすることがよくあります。

これらのワークフローでは、大規模で、しばしば孤立したデータ資産の迅速な分析と探索を可能にするツールセットがほぼ常に必要とされます。結果は保存され、再利用される必要があり、通常は再現可能である必要があります。

Foundryでは、これらのワークフローは、異なるスキルセットを持つユーザー向けの異なるツールを組み合わせていますが、すべては同じデータ資産、すなわちオントロジーに依存しています。オントロジーは、関連する組織のオブジェクトとそれらの間の関係をモデル化します。自動化されたビジネスロジックや/またはMLのコホーティングが適用され、調査の出発点となり、Foundryのさまざまな分析ツールが問題への掘り下げに使用されます。最後に、オントロジーの書き戻しが使用されて、オントロジーと外部ソースシステムが更新され、問題の修正やアクションが行われます。

主要な要素

ユーザーインターフェース

探索的分析

データを調査し、仮説を検証するために、アナリストはよく探索的分析に依存します。彼らはトップダウンのアプローチから始め、大規模なデータセットを高レベルで見てから、それを変換したり、フィルター処理したり、集約したりして、仮説を検証します。例えば、Material Yield Applicationでは、アナリストは週ごとに最もパフォーマンスの悪い材料をレビューし、Contourを通じて節約の機会を特定します。

過去には、この方法は大規模なデータセットを扱い、結果を比較するツールを使用するスキルを持つ高度に技術的なアナリストのためのものでした。これはしばしばプロセスが少数のユーザーにボトルネックになり、反復速度が遅くなることを意味していました。

Foundryでは、ユーザーはコードとノーコードのツールセットに依存して、任意のデータセットを秒単位で分析します。これはデータを視覚的に探索するためのツールセットを提供するだけでなく、オントロジーを活用することで、ユーザーに多くの運用コンテキストも提供します。

関連製品:

• Contour
• Quiver
• Vertex

ケース調査

調査は、アラートワークフローパターンの結果（例えば、電力網のトレンドや停電）、優先されたコホート（例えば、最もパフォーマンスの低い製造プロセス）、またはユーザーが機会を探している（例えば、営業担当者が次の行動を特定する）といったことから始まることがあります。

彼らは単一のオブジェクトか、小さなオブジェクトのサブセットから始めます。調査はめったにオープンエンドではなく、ほとんどの場合、定義された目標があります（例えば、顧客のクレームの源泉を理解すること）そして、それはアナリストのタスクである、トリガーからその根本原因までのイベントを遡ることです。

関連製品:

• Object Explorer

インパクトトラッカー

調査が終わり、仮説が確認され、または分析が終了したら、現実の世界のイベント（例えば、リスキーな資産の修正を行うチームをトリガーする）を引き起こす運用上の決定が下されます。

理想的には、これらの現実の世界のイベントは、同じ状況に再度遭遇するリスクを減らすことも可能にします。これが起こると、決定と行動が自体が重要なデータ資産となります。いつ、どこで、なぜ決定が下されたかを知ることは、今後の調査や分析で利用でき、アナリストが時間をかけて異なる状況を比較し、一貫性を高めることができます。

関連製品:

• Workshop
• Quiver

(オプション) 自動クラスタリング

手動ルール作成

理想的には、調査は積極的にトリガーされます。専門家は、ある時点でエラーや異常が発生する可能性があると推測でき、特にこれらをデータでモニタリングしたいと思うかもしれません。そのテータは非常に具体的であるかもしれません（その場合、アラートパターンに頼ることになります。Asset Failure Operationsのユースケースなど）、またはあいまいであるかもしれません（その場合、データの中で注意を払うべきKPIやビジネスロジックを定義します。Material Yield Applicationなど）。最も単純なロジックでは、アナリストがそれぞれの調査や分析の初めに手動で行う手順を追っています。

（少なくとも部分的に）自動化されたアプローチはまた、規制当局によって必要とされるか、一貫性を確保し、リスクの発生可能性を減らすために貴重であるかもしれない、決定論的な動作を確保するために使用することもできます。

アラートパターンと同様に、ユーザーはFoundryのアラート自動化に頼ることができます。または、調査と探索と同じツールを使用することができます。

関連製品:

• Foundry Rules
• Actions
• Workshop

Foundry ML

場合によっては、調査やデータの異常を検出するために、専門知識をケースバイケースで適用する必要はありません。堅牢で一貫したデータ資産が存在する場合、統計的なアプローチが問題に対してより適しているかもしれません。大量のデータの中に複雑なパターンを見つけることは、特にパターンが常に変化しているとき、人間にとっては困難です。Foundry MLを使用すると、大規模なデータセットの上にモデルを訓練し、実装することができます。結果（クラスターまたは予測）は、プラットフォームの他の任意のデータポイントと同様に使用することができ、つまり、それをオントロジーの一部とすることができ、探索的分析や調査で取り上げることができます。

関連製品:

• Foundry ML
• Code Workbook

オントロジー

オントロジーは、異なる資産がどのように関連しているかの情報を保存します（例えば、出荷、顧客、注文がどのように接続されているかなど）、ユーザーが自然に質問をしたり、回答を得ることができます。

オブジェクト:

• コホート
• Rules
• 主題別のコンテキストオブジェクト

関連製品:

• オントロジー
• Object Explorer
• Foundry Actions

要件

使用するパターンにかかわらず、基礎となるデータ基盤はパイプラインと外部ソースシステムへの同期から構築されます。

データ統合パイプライン

データ統合パイプラインは、SQL、Python、Javaなどのさまざまな言語で書かれており、データソースを主題別のオントロジーに統合するために使用されます。

Data Connectors

FoundryはFTP、JDBC、REST API、S3など、幅広いソースからデータを同期することができます。さまざまなソースからデータを同期し、可能な限り最も完全な真実の源をコンパイルすることは、最高の価値の決定を可能にするための鍵となります。

このパターンを実装するユースケース

• 標準化されたKPIレポーティングを通じた生産利益の改善
• インテリジェントな再価格設定を通じて保持と回収のパフォーマンスを改善
• 統合キャンペーン管理を通じてクライアントのエンゲージメントを増加
• アラートと調査のサポートを通じてトランスフォーマーの故障を防止

このユースケースパターンについての詳細情報が必要ですか？同様のものを実装しようとしていますか？Palantirで始めましょう。