注: 以下の翻訳の正確性は検証されていません。AIPを利用して英語版の原文から機械的に翻訳されたものです。
請求書が正しく処理されること、火災リスクを回避するために停電が管理されること、R&Dデータが効率的かつ安全に管理・活用されることなど、すべての組織のオペレーショナルプロセスは、さまざまなソースシステムとのインターフェースをユーザーが行い、それらの間の競合を解決し、専門的なアプリケーションとやり取りし、オペレーショナルな意思決定を行い、それらの意思決定を記録して、プロセスを改善し、下流の他の人にフィードバックを提供することが求められます。
Foundry の Data Connection と オントロジー により、組織はこのパターンを数ヶ月ではなく数日で実装し、安全かつ効率的にカスタマイズやメンテナンスを続けることができます。
請求書が正しく処理されること、火災リスクを回避するために停電が管理されること、R&Dデータが効率的かつ安全に管理・活用されることなど、重要なビジネスプロセスにおいて、これらの異なるプロセスはすべて同じパターンを共有しています。すなわち、多くの異なるユーザーとユーザータイプが、さまざまなソースシステムや他のユーザーとやり取りして、組織にとって重要なオペレーショナルな意思決定を行うことが求められます。さらに、これらのプロセスは時間の経過とともに進化し、それらを使用するツールも安全でメンテナンス可能なまま進化する必要があります。
しかし、実際には、これらのプロセスは、特定のデータソースと対話するために作られたカスタムソフトウェアとして実装されることが多く、管理や更新が困難で、他のソフトウェアとは孤立しており、独自のセキュリティモデルに従っています。あるいは、プロセスはスプレッドシートやメールで管理されており、技術的な制約があり、エラーが発生しやすく、セキュリティが低く、管理や共同作業が困難です。
Foundry では、代わりに、関連するすべてのデータソースをオントロジーに統合し、Workshop アプリを使用してカスタムアプリを構築し、オントロジーと外部システムに書き戻す以下のパターンを実装しています。すべてこれは、Foundry のプラットフォームセキュリティモデルを使用して安全に管理され(ベンダーなどの複数の組織間で)、Foundry のバージョン管理システムを介して簡単に保守および改善することができます。
アクションインボックス
Workshop の アクションインボックス では、異なるユーザー が タスクを割り当てられ、オントロジーの主要な側面を 表示および探索 し、実世界の意思決定を行うための アクションを実行 できます。
例えば、請求書紛争解決 のプロセスでは、請求書が適切な部門のユーザーに割り当てられ、顧客サービスのアクションが確認され、負傷の原因が特定され、明確な請求書の説明が提出され、アプリケーションの下流で顧客と共有されます。
関連する製品:
オペレーショナルプロセス オントロジー
アクションインボックスの基盤となるのは、オペレーショナルプロセスを オントロジー でモデル化 し、オブジェクト に プロパティ と 関連 を設定します。例えば:
ユーザーは Workshop で自動的に利用可能であり、オントロジーでモデル化する必要はありませんが、部門や場所などの追加プロパティと関連付けることが役立つ場合には、モデル化できます。
関連する製品:
主題 オントロジー
アクションインボックスの機能オントロジーに加えて、主題のデジタルツインがあり、信頼できる 1 つのデータソース としてユーザーが参照することができます。オブジェクト、プロパティ、および 関連 は、ユースケースによって異なりますが、通常は多くのユースケースで共有され、Object Explorer ビュー(オブジェクト中心)、Quiver(チャート作成やダッシュボード作成)、または Vertex(ネットワーク分析)内で可視化されます。
例えば、公共安全電源遮断(PSPS)範囲では、オブジェクトには、トランス、回路、天候の閾値の違反、グリッドの構成などの資産が含まれます。
関連する製品:
意思決定の書き戻し
アクションインボックスで行われたアクションは、プロセスオントロジーへの 書き戻し をトリガーします(例:タスクの作成、更新、再割り当て)。しかし、より重要なのは、主題のオントロジーへの書き戻しで、デジタルツインを更新し、外部ソース に書き戻します。
例えば、公共安全電源遮断(PSPS)範囲では、インボックスで行われた意思決定は、Foundry のオブジェクトとしての顧客を連絡できないとマークし、後で再連絡するために、外部の自動メッセージ配信システムに通知をプッシュします。
関連する製品:
ビジネスロジックと自動化
アクションインボックスを駆動するロジックは、パイプラインで実装されることがよくあります。例えば、どのアクションをどのユーザーにマップするか、あるいはどのアクションを最初に実装するかを決定します。これらは、Foundry Machine Learning で作成および管理されるモデルを活用しています。
例えば、請求書紛争解決 では、上流のロジックを使用して、どの部門が特定の問い合わせを処理するのに最適かを決定します。
関連する製品:
使用されるパターンに関係なく、基盤となるデータは、パイプラインと外部ソースシステムとの同期から構築されます。
データ統合パイプライン
データ統合パイプラインは、SQL、Python、Java などのさまざまな言語で記述され、主題オントロジーにデータソースを統合するために使用されます。
Foundry は FTP、JDBC、REST API、S3 など、さまざまなソースからデータを同期できます。さまざまなソースからデータを同期し、できるだけ完全な信頼できる 1 つのデータソースを構築することが、最も価値のある意思決定を可能にするための鍵となります。
(オプション) SAP および Salesforce コネクタ
多くの組織プロセスでは、SAP および Salesforce データが依存しており、Foundry には、両ソースのデータを摂取し、わずか数回のクリックでオントロジーを作成するためのコネクタおよび統合パイプラインが用意されています。請求書紛争解決 では、例えば、これらの両方のソースが使用されています。
このユースケースパターンに関する詳細情報が必要ですか?同様のものを実装したいですか?Palantir で始める。↗