Operational process coordination(运营流程协调)¶
Operational processes at any organization, whether it’s ensuring that invoices are handled correctly, power shutoffs are managed to avoid wildfire risk, or R\&D data is managed and leveraged efficiently and safely, require users to interface with a variety of source systems, resolve any conflicts among them, interact with specialized applications, make operational decisions, and record those decisions to improve the process and feed others downstream.
Foundry’s Data Connection and Ontology allow organizations to implement this pattern in days instead of months and continue to implement, customize, and maintain them safely and efficiently.

Solution¶
Consider any critical business process, whether it’s ensuring that invoices are handled correctly, power shutoffs are managed to avoid wildfire risk, or R\&D data is managed and leveraged efficiently and safely. These disparate processes all share the same pattern: they require many different users and types of users to interact with a variety of source systems and other users in order to make operational decisions that are critical for the organization. Moreover, these processes evolve over time and the tools used need to evolve with them while remaining secure and maintainable.
Yet, in practice, these processes are often implemented as custom software that’s purpose-built to interact with a particular set of datasources, difficult to manage or update, siloed from other such software, and follows its own security model. Alternatively, the process is managed via spreadsheets and emails, which have technical limitations, are error-prone and insecure, and are difficult to manage and collaborate on.
In Foundry, organizations instead implement the pattern below to integrate all of the relevant data sources into an ontology, from which Workshop apps are used to build custom apps which write back to the ontology and external systems. All of this is governed safely using Foundry’s Platform Security Model (often across multiple organizations such as vendors), and can be easily maintained and improved on via Foundry’s version control systems.
Key elements¶
Action Inbox
An Action Inbox in Workshop which allows different users to be assigned tasks, view and explore the key aspects of the ontology, and take actions to make real-world decisions.
For example, in a process for doing Invoice Dispute Resolution, invoices are assigned to users in the correct department, where they review the customer service actions that are taken, see potential causes of injury, and submit a clear explanation for the invoice, which is shared back with the customer downstream of the application.
Related products:
Operational Process Ontology
Underlying the Action Inbox is an Ontology, which models the operational process as objects with properties and relations. For example:
- Tasks have assignees, creation and assignment times, priorities, and statuses
- Workflows contain tasks and model sequential steps in a process
Users are available in Workshop automatically and don’t need to be modeled in the ontology, but can be if it’s helpful to associate them with additional properties such as department or location.
Related products:
Subject Matter Ontology
In addition to the functional ontology for the Action Inbox, there’s a digital twin of the subject matter, which serves as the single source of truth that users reference to make their decisions. The objects, properties, and relations will differ depending on the use case, but are typically shared across many use cases and are visualized within Object Explorer views (object-centric), Quiver (charting and dashboarding), or Vertex (network analysis).
For example, for Public Safety Power Shutoff (PSPS) Scoping, objects would include assets like transformers and circuits, weather threshold breaches, and grid configurations.
Related products:
Decision writeback
Actions taken in the Action Inbox trigger writeback to the process ontology (e.g. creating, updating, or reassigning tasks), but more importantly to the subject matter ontology, where it updates the digital twin and then writes back to external sources.
For example, for Public Safety Power Shutoff (PSPS) Scoping, decisions made in the inbox mark customers (objects in Foundry) as unsuccessfully contacted to be recontacted later as well as push notifications to the external automated message broadcast system.
Related products:
Business logic and automation
Logic that drives the Action Inbox is often implemented in pipelines, e.g. determining which actions to map to which users or prioritizing which actions to implement first. These often leverage models created and managed in Foundry Machine Learning.
For example, Invoice Dispute Resolution uses upstream logic to determine which department is best suited to handle a given inquiry.
Related products:
Requirements¶
Regardless of the Pattern used, the underlying data foundation is constructed from pipelines and syncs to external source systems.
Data integration pipelines
Data integration pipelines, written in a variety of languages including SQL, Python, and Java, are used to integrate datasources into the subject matter ontology.
Foundry can sync data from a wide array of sources, including FTP, JDBC, REST API, and S3. Syncing data from a variety of sources and compiling the most complete source of truth possible is key to enabling the highest value decisions.
(Optional) SAP and Salesforce Connector
Many organizational processes rely on SAP and Salesforce data, and Foundry has out-of-the-box connectors and integration pipelines for both sources that ingest and create ontologies in just a few clicks. Invoice Dispute Resolution, for example, uses both of these sources.
Use cases implementing this pattern¶
- Driving revenue through integrated pricing
- Improving customer satisfaction and retention through intelligent task management
- Improving invoice collection through intelligent dispute resolution
- Increasing client engagement through integrated campaign management
- Optimizing production with ERP data across the supply chain
- Public safety power shutoff (PSPS) scoping
- Reduce rail disruptions through intelligent maintenance prioritization
- Reducing over- and under-payments to health care providers
Want more information on this use case pattern? Looking to implement something similar? Get started with Palantir. ↗
中文翻译¶
运营流程协调¶
任何组织中的运营流程,无论是确保发票得到正确处理、管理断电以规避野火风险,还是安全高效地管理和利用研发数据,都需要用户与各种源系统进行交互、解决系统间的冲突、使用专业应用程序、做出运营决策,并记录这些决策以改进流程并为下游环节提供支持。
Foundry 的 Data Connection(数据连接)和 Ontology(本体)使组织能够在数天内(而非数月)实现这一模式,并持续安全高效地实施、定制和维护这些流程。

解决方案¶
考虑任何关键业务流程,无论是确保发票得到正确处理、管理断电以规避野火风险,还是安全高效地管理和利用研发数据。这些不同的流程都遵循相同的模式:它们需要许多不同类型的用户与各种源系统及其他用户进行交互,以便做出对组织至关重要的运营决策。此外,这些流程会随时间演变,所使用的工具也需要随之演进,同时保持安全性和可维护性。
然而在实践中,这些流程通常以定制软件的形式实现,这些软件专为与特定数据集交互而构建,难以管理或更新,与其他类似软件相互隔离,并遵循自身的安全模型。或者,流程通过电子表格和电子邮件进行管理,这些方式存在技术限制,容易出错且不安全,难以管理和协作。
在 Foundry 中,组织转而采用以下模式,将所有相关数据源集成到一个本体(Ontology)中,然后使用 Workshop(工作坊)应用构建自定义应用,这些应用将数据写回本体和外部系统。所有这些操作都通过 Foundry 的平台安全模型(Platform Security Model)进行安全管理(通常跨越多个组织,如供应商),并且可以通过 Foundry 的版本控制系统轻松维护和改进。
关键要素¶
操作收件箱(Action Inbox)
Workshop(工作坊)中的操作收件箱(Action Inbox),允许不同的用户被分配任务、查看和探索本体的关键方面,并采取行动做出实际决策。
例如,在执行发票争议解决流程时,发票会被分配给正确部门的用户,由他们审查已采取的客户服务行动,查看潜在原因,并提交清晰的发票说明,该说明会通过应用程序与下游客户共享。
相关产品:
- Workshop(工作坊)
- Actions(操作)
- Functions on Objects(对象函数)
运营流程本体(Ontology)
操作收件箱的基础是一个本体(Ontology),它将运营流程建模为具有属性和关系的对象。例如:
- 任务具有负责人、创建和分配时间、优先级和状态
- 工作流包含任务,并对流程中的顺序步骤进行建模
用户会自动出现在 Workshop(工作坊)中,无需在本体中建模,但如果需要将用户与部门或地点等附加属性关联起来,也可以进行建模。
相关产品:
- Ontology(本体)
- Object Explorer(对象浏览器)
主题本体(Subject Matter Ontology)
除了用于操作收件箱的功能性本体外,还存在一个主题的数字孪生(digital twin),作为用户做出决策所参考的单一事实来源。对象、属性和关系将根据用例而有所不同,但通常跨多个用例共享,并在 Object Explorer(对象浏览器)视图(以对象为中心)、Quiver(图表和仪表板)或 Vertex(网络分析)中进行可视化。
例如,对于公共安全断电(PSPS)范围界定,对象将包括变压器和电路等资产、天气阈值违规以及电网配置。
相关产品:
- Ontology(本体)
- Object Explorer(对象浏览器)
决策回写(Decision writeback)
在操作收件箱中采取的操作会触发对流程本体的回写(例如创建、更新或重新分配任务),但更重要的是对主题本体的回写,它会更新数字孪生,然后回写到外部源。
例如,对于公共安全断电(PSPS)范围界定,收件箱中做出的决策会将客户(Foundry 中的对象)标记为联系失败以便稍后重新联系,同时将通知推送到外部自动消息广播系统。
相关产品:
- Ontology(本体)
业务逻辑与自动化(Business logic and automation)
驱动操作收件箱的逻辑通常通过管道(pipelines)实现,例如确定将哪些操作映射给哪些用户,或优先实施哪些操作。这些逻辑通常利用在 Foundry Machine Learning(Foundry 机器学习)中创建和管理的模型。
例如,发票争议解决使用上游逻辑来确定哪个部门最适合处理特定查询。
相关产品:
- Code Repositories(代码仓库)
- Code Workbook(代码工作簿)
要求¶
无论使用哪种模式,底层数据基础都是由管道(pipelines)和与外部源系统的同步构建而成。
数据集成管道(Data integration pipelines)
使用 SQL、Python 和 Java 等多种语言编写的数据集成管道,用于将数据源集成到主题本体中。
数据连接器(Data Connectors)
Foundry 可以从多种来源同步数据,包括 FTP、JDBC、REST API 和 S3。从各种来源同步数据并编译尽可能完整的单一事实来源,是实现最高价值决策的关键。
(可选)SAP 和 Salesforce 连接器
许多组织流程依赖于 SAP 和 Salesforce 数据,Foundry 为这两个数据源提供了开箱即用的连接器和集成管道,只需点击几下即可摄取数据并创建本体。例如,发票争议解决就使用了这两个数据源。
实施此模式的用例¶
- 通过集成定价推动收入增长
- 通过智能任务管理提升客户满意度和留存率
- 通过智能争议解决改进发票催收
- 通过集成活动管理提高客户参与度
- 利用供应链中的 ERP 数据优化生产
- 公共安全断电(PSPS)范围界定
- 通过智能维护优先级排序减少铁路中断
- 减少对医疗保健提供者的超额和不足支付
想了解有关此用例模式的更多信息?希望实施类似方案?立即开始使用 Palantir。↗