ドキュメントの検索
karat

+

K

APIリファレンス ↗

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

ユースケースの実現

Foundry を使って組織に価値をもたらすためには、プラットフォーム全体でツールを構築し、運用上の意思決定プロセスをサポートする必要があります。ユースケースは、特定の意思決定プロセスをサポートするために専用チームが行う時間制約のある取り組みです。ユースケースは、プラットフォーム上で新しい機能を一連のユーザーに提供する上で中心的な役割を果たしています。

ユースケースの例

Foundry のユースケースは、さまざまな活動やワークフローを含むことができます。例えば:

  • 重要な運用プロセスに関連するアラートの生成、調査、解決。
  • ネットワーク内の施設間で在庫を最適化し、レジリエンスを向上させ、サプライチェーンの不確実性を軽減する。
  • サービス提供エリアに営業担当者を最適に割り当てる方法についての意思決定を支援する。

ユースケースには、Foundry とともに構築するための構造化されたアプローチと、新しいアイデアや用語の理解が求められます。ソリューション設計方法論や事例、リファレンスアーキテクチャを ユースケースライフサイクル セクションで詳しく説明しています。

データ駆動型のマインドセット

データサイエンティスト、品質アナリスト、組立ライン作業者、エグゼクティブがデータを日常的なコミュニケーション言語として使う世界を想像してみてください。Foundry は以下の方法でデータをコミュニケーション言語に変えます。

  • データフローと帰属を維持して、人々が発見や学習を信頼できるようにする。
  • ユーザーの技術能力や経験に関係なく、誰もがデータを日常業務に取り入れることができるようにする。

この共同作業のビジョンが、Foundry の原動力となっています。

Foundry は、組織全体でデータ駆動型ループを作成することを目的として構築されました。同僚や共同作業者と連携して、データを使って意思決定を行い、どのような決定が行われたかを記録し、その決定が時間の経過とともにどのような影響を与えるかをデータを使って評価します。メールで送られたスプレッドシートや静的な分析に頼るのではなく、リアルタイムでデータ上で直接共同作業を行うことができます。

Foundry プラットフォームでのプロジェクト成功には、創造性と思慮深さが求められます。解析的な質問や組織的なワークフロー、運用上のニーズに対して、複数の解決策が存在することがよくあります。適切な道筋を選ぶためには、目的の結果、利用可能なデータ、プラットフォーム上のツールのバランスを取る必要があります。

結果

プロジェクトを分解する際には、そこに辿り着く方法よりも結果について考えることが重要です。たとえば、セールスダッシュボードの構築ニーズから始めるのではなく、作業がどのような意思決定や結果を可能にするかを理解しましょう。例えば、結果は、営業エリアへの時間やリソースの割り当てに関する意思決定、または別のことに関連していますか?

このレベルの理解は、プロジェクトの開始時に特に他の人が使用するツール、レポート、分析を構築する場合に、より多くの作業が必要になるかもしれません。現実的な目標に向かって進むために、結果志向のフレーミングを検討してください。

柔軟性と適応力は、Foundry プロジェクトを成功させるために役立ちます。明確で結果志向の目標を特定することで、プロジェクトを小さな論理的なステップに分解することが容易になります。この問題の分解は、プロジェクトが多くの場合、複数のデータソースといくつかのプラットフォームツールが連携して動作することが求められるため、重要なスキルです。

データ

プロジェクトをバックアップする適切なデータを見つけ出すことは、やや難しい課題であることがあります。ただし、結果志向のフレーミングがあり、プロジェクトをより小さなステップに分解している場合は、その結果から逆算して必要なデータを特定する作業が容易になります。

組織が Foundry をしばらく使用している場合は、必要なデータがすでにプラットフォームに存在している可能性があります。Data Catalog でキュレーションされたデータセットや、Object Explorer のオブジェクトやリンクを調べてみてください。結果の例から、営業担当者、営業エリア、製品、個々の営業などのデータが必要であると特定することができます。これらのオブジェクトは、オントロジーで主要な表現を持つべきです。

必要なデータタイプごとに主要なデータセットを特定できない場合は、プラットフォーム管理者に連絡してください。場合によっては、新しい組織オブジェクトをオントロジーに追加したり、既存のオブジェクトに新しいプロパティを追加したりする必要があります。後ほど説明しますが、データ統合レイヤーのツールを使用して外部データソースに接続し、新しいデータを Foundry に取り込むことができます。

ツール

各アプリケーションは、プラットフォーム全体の一部として動作するように設計されています。プラットフォーム内のさまざまな機能と、どのツールが特定の仕事に適しているかを理解するには時間がかかります。

プロジェクトの成果物と必要なデータを理解したら、各ステップを特定のツールにマッピングするのが容易になります。例えば、プロジェクトの中で、各地域の新しい営業指標を生成するサブプロジェクトがあることがわかりました。このサブプロジェクトでは、いくつかの追加ステップが作成されます。

  • 関連する主要指標の特定
  • データの入手
  • データ変換ロジックの開発
  • データを指標に集約するロジックの開発
  • 営業チームが消費できるようにデータを表示する

これらのステップは、Foundry の異なるツールにマッピングされます。プロジェクトが成熟するにつれて、適切なツールが変わることがあります。たとえば、最初に、Contour で変換や指標のプロトタイプを作成してみることができます。Contour は、データの形状を理解し、グラフや指標を生成するのに便利なアプリケーションです。これらの指標をダッシュボードに追加し、営業チームからフィードバックを得るためのクイックプロトタイプを作成できます。これが、このプロジェクトの素晴らしい終点になるかもしれません。営業リソース割り当てプロセスの意思決定を促進する新たなインサイトを提供する、いくつかのうまく作られたダッシュボードです。

大規模なプロジェクトや、本番環境での使用を重視したプロジェクトでは、ロジックをCode Repositories のパイプラインに変換できます。そこでは、他の技術的なユーザーと共同作業を行い、データが定期的に更新されるようにスケジュールを設定するための堅牢なプラットフォームツールを利用できます。営業チームがダッシュボードでデータを表示するだけでなく、システムに意思決定を記録する機能を提供する、よりカスタマイズされたユーザー体験を作成するために、Object Views を設定したり、WorkshopSlate でカスタムアプリケーションを構築することができます。

Foundry の多くのプロジェクトでは、このような複雑さは必要ありませんが、プロジェクトのフレームワークを作成して分解することが、成功に必要なデータとツールを特定するのに役立つ方法であることを理解しておくとよいでしょう。

次のステップ

最後に、役割別の次のステップを参照して、Foundry でどこから始めるべきかを学んでください。