注意:以下翻译的准确性尚未经过验证。这是使用 AIP ↗ 从原始英文文本进行的机器翻译。
任何组织的运营流程,无论是确保发票得到正确处理、管理电力关闭以避免火灾风险,还是高效安全地管理和利用研发数据,都需要用户与各种源系统接口,解决其中的任何冲突,使用专业化的应用程序,做出运营决策,并记录这些决策以改进流程并向下游提供信息。
Foundry的数据连接和Ontology允许组织在几天内而非几个月内实施这种模式,并继续安全高效地实施、定制和维护这些流程。
考虑任何关键业务流程,无论是确保发票得到正确处理、管理电力关闭以避免火灾风险,还是高效安全地管理和利用研发数据。这些不同的流程都共享相同的模式:它们需要许多不同的用户和用户类型与各种源系统和其他用户进行交互,以做出对组织至关重要的运营决策。此外,这些流程会随着时间的推移而演变,所使用的工具也需要随着它们的发展而演变,同时保持安全和可维护。
然而,在实践中,这些流程通常被实现为定制软件,该软件是为与特定数据源集交互而专门构建的,难以管理或更新,与其他此类软件隔离,并遵循其自身的安全模型。或者,流程通过电子表格和电子邮件进行管理,这存在技术限制,易出错且不安全,难以管理和协作。
在Foundry中,组织改为实施以下模式,将所有相关数据源集成到一个ontology中,从中使用Workshop应用程序构建自定义应用程序,这些应用程序回写到ontology和外部系统。所有这些都通过Foundry的平台安全模型安全管理(通常跨多个组织,如供应商),并且可以通过Foundry的版本控制系统轻松维护和改进。
操作收件箱
在Workshop中的操作收件箱,允许不同用户被指派任务,查看和探索Ontology的关键方面,并采取措施做出现实世界的决策。
例如,在进行发票争议解决的过程中,发票被指派给正确部门的用户,他们在其中查看采取的客户服务措施,查看潜在的损害原因,并提交发票的清晰解释,这些解释会在应用程序下游共享给客户。
相关产品:
运营流程Ontology
操作收件箱的底层是一个**Ontology,它将运营流程建模为具有属性和关系的Object**。例如:
用户在Workshop中自动可用,无需在ontology中建模,但如果将它们与附加属性(如部门或位置)关联有帮助,则可以进行建模。
相关产品:
主题Ontology
除了操作收件箱的功能ontology外,还有一个主题的数字孪生,作为用户参考做决策的单一真实来源。Object、属性和关系会根据应用案例的不同而有所不同,但通常在许多应用案例中共享,并在Object Explorer视图(以Object为中心)、Quiver(图表和仪表盘)或Vertex(网络分析)中可视化。
例如,对于公共安全断电(PSPS)范围界定,对象将包括变压器和电路等资产、天气阈值突破和电网配置。
相关产品:
决策数据输出
在操作收件箱中采取的操作会触发对流程ontology的数据输出(例如创建、更新或重新指派任务),但更重要的是对主题ontology进行数据输出,在那里它会更新数字孪生,然后写回外部来源。
例如,对于公共安全断电(PSPS)范围界定,在收件箱中做出的决策将标记客户(Foundry中的Object)为未成功联系,以便稍后重新联系,并将推送通知发送到外部自动消息广播系统。
相关产品:
业务逻辑和自动化
驱动操作收件箱的逻辑通常在管道中实现,例如确定将哪些操作映射到哪些用户或优先考虑先执行哪些操作。这些通常利用在Foundry机器学习中创建和管理的模型。
例如,发票争议解决使用上游逻辑来确定哪个部门最适合处理给定的询问。
相关产品:
无论使用哪种模式,底层数据基础都是从管道构建并同步到外部源系统的。
数据集成管道
数据集成管道使用包括SQL、Python和Java在内的多种语言编写,用于将数据源集成到主题ontology中。
Foundry可以从广泛的来源同步数据,包括FTP、JDBC、REST API和S3。从各种来源同步数据并编译尽可能完整的真实来源是实现最高价值决策的关键。
(非必填)SAP和Salesforce连接器
许多组织流程依赖于SAP和Salesforce数据,Foundry提供现成的连接器和集成管道,只需点击几下即可摄取并创建ontology。例如,发票争议解决使用这两种来源。
想要了解更多关于此应用案例模式的信息吗?想要实施类似的东西吗?开始使用Palantir。↗