增强分析（Augmented Analytics）——增强工作流

你已经了解了很多关于员工赋能和成功实施增强分析（AA）所需的组织环境的基础知识。没有高层管理的支持、组织各个部门的分析翻译者提出的创意、推动变革的卓越中心（CoE）以及将创意转化为用例的有效基础设施，就无法增强业务用户的流程和工作流程。

整个变革是一个迭代的方法，AA现已成为最终阶段的关键驱动力。这是一个双向关系，如图5-1所示：如果没有适当的分析转型成熟度，就不可能实现AA，而没有AA，就无法达到最终的卓越。

现在，最后阶段必须专注于让大多数员工，即分析用户，通过将分析技术集成到他们的工作流程中，能够有效地参与并享受分析带来的好处。我们将在本章中更详细地解释这一点。

工作流程增强的类型

如图5-2所示，新工作流程需要遵循一个通常被称为TRICUS的标准：它们应该是及时的、相关的、有洞察力的、可信的、不干扰的和具体的。

每种类型的工作流程增强都有不同的目的，适用于不同类型的任务和决策过程。它们展示了AA工具在各种业务背景和工作流程中的多功能性和适应性。

知识工作者的不同AA工作流程增强类型可以集成到多个业务流程中，以支持各种需求和要求。最明显的是固定规则和洞察增强。

固定规则，高置信度增强

在固定规则增强中，系统在满足某些预定标准时会自动做出决策或采取行动，无需人工干预。这种类型的增强被称为高置信度，因为可靠的数据质量和经过验证的、明确的AI模型使组织能够以高置信度运行。这在流程自动化中很常见，通常用于优化运营成本和确保交付标准的一致性。它在处理常规、定义明确的任务时非常可靠，但在处理复杂、细微的情况时灵活性较差。

固定规则、高置信度增强的典型用例包括将客户细分集成到客户关系管理（CRM）系统中，路由保险理赔到处理人员，导航或预填库存系统中的条目。

创意和洞察增强

创意和洞察增强是通过额外的数据驱动描述性和预测性洞察以及可视化来增强人类决策过程，以丰富用户的理解和决策。人类在循环中并做出决策。这可能包括突出趋势，预测未来情景，或提供数据的可视化表示以发现隐藏的模式。这在战略规划中特别有用，作为“副驾驶”，提供建议并呈现先前未发现的洞察。

增强不一定（也往往不能）提供明确的建议，但它提供的信息有助于分析用户选择综合解决方案。增强的一个例子是在销售提案的早期阶段基准比较类似的过去案例。商业保险中的另一个例子是，增强可以帮助核保人通过基准比较新风险，评估客户行业细分的盈利能力，或比较以前类似风险分配的再保险结构。

对话式增强

对话式增强使用生成性AI和大语言模型（LLM）以对话方式与用户交互。这通常以AI助手的形式出现，可以回答问题，提出建议，校对草稿，生成创意，提供解释，甚至建议改进。这种类型的增强高度互动且用户友好，足够让那些技术知识有限的人访问。

这种增强的最显著例子来自IT：例如，GitHub Copilot等编码辅助工具，帮助开发人员编写代码、创建文档和设计界面。麦肯锡估计，这些工具可以显著提高开发人员的编码工作流程的生产力。更普遍地，另一项麦肯锡研究发现，自动化可以提高高等教育知识工作者的工作流程生产力25%，因为他们处理的大多是非结构化数据（以文本和文档形式）。

一个例子是招聘。通过将对话引擎集成到HR系统中，招聘人员可以使用AI直接与职位空缺进行对比，挑战他们对工作的看法。当前的LLM，如GPT模型，可以比较职位描述，增强招聘人员的决策和工作流程。商业保险中的另一个例子是处理大型文本，如合同、索赔报告和现场风险调查分析。用户可以让模型总结这些文档，然后与其讨论结果以获得更好的理解。通过有效的培训和熟练的预提示，你确实可以使用生成性AI来利用洞察进行增强。

上下文增强

上下文增强，也称为自适应增强，虽然较少见但很有价值。这指的是AI系统根据用户的上下文进行调整，从他们的交互和偏好中学习，提供更个性化和相关的信息。系统根据用户的角色、专业知识或当前任务调整其交互方式和呈现的数据的详细程度和类型。

上下文增强在消费者推荐系统和个性化社交媒体推送中很常见。在商业环境中，这种工具可以根据用户的语言和语气生成预定义的电子邮件回复。

协作增强

协作增强较少见，是通过提供共享仪表板、实时数据更新、知识库等工具来增强团队成员之间的团队合作和跨职能协作，以帮助人们在分析和解释数据时进行协作。

一个典型的用户可能是一个使用协作知识库来获取用例进展和模型结果洞察的分析翻译者。另一个例子是将Azure聊天机器人代理添加到Microsoft Teams中，根据坚实的知识库（如内部工作指示或合规文件）为每个团队的对话提供支持和建议。

每种类型的工作流程扩展都有不同的目的，适用于不同类型的任务和决策过程。这些工作流程扩展定义了AA如何集成到业务工作流程中。你可以看到这些工具在各种业务背景中的多功能性和适应性。

分析用例方法：找到需要增强的工作流程

在你的组织中，可能有数百、数千甚至数十万个现有工作流程和业务流程，你如何实际找到那些需要增强的流程？从哪里开始？又如何将一个想法变为有效的执行？这就是分析用例方法能帮助你的地方。实际上，这是一种操作框架，将未开发的潜力（以想法的形式）转化为强大的分析产品，确保可持续的业务卓越并促进创新思维。

用例方法帮助你开发和维护一个用例管道，使你能够非常迅速地响应分析业务需求，并将用例从想法转化为最终产品，包括提供适当的基础设施、资源和能力。这种一步步的方法提供了从概念到运营化的明确、结构化的路径。它使创新过程风险更低，因为每个阶段都作为检查点，以验证你的假设、细化你的目标并增强你的业务重点。

对于那些分析成熟的公司，这种方法不仅仅是程序上的优势，更是运营卓越的战略推动者。其验证和迭代精炼的过程帮助你确保组织的分析投资既谨慎又有针对性。它还增强了灵活性，帮助企业以迭代步骤快速适应新的机会和挑战，挑战与业务目标和市场动态紧密相关的想法。实际上，它是一个操作框架，将未开发的潜力（以想法的形式）转化为强大的分析产品，确保可持续的业务卓越并促进创新思维。

图5-3展示了用例方法随时间的变化。以下部分将深入探讨其六个阶段。

阶段1. 想法：初始火花

就像许多旅程一样，一个用例的旅程始于一个想法。一个想法可以被定义为识别出一个机会或问题的概念性火花，这个机会或问题有可能通过数据分析来解决。

一个想法的萌芽是认识到组织内的一个挑战或机会，这个挑战或机会可以通过改进的数据分析及其应用来解决。这个想法形成了一个假设（或提出的解释），即如何使用数据分析来解决问题、改进流程或利用机会。它还通过提出一种新的方式来使用数据分析以实现业务目标，代表了创新的种子。它假设这个挑战有一个尚未完全开发或验证的分析解决方案。

交付成果

这个阶段的最终交付成果通常是在业务范围内产生的，包含对业务环境中问题的简洁描述和为其增值的解决方案草案。

风险和投资回报率

将“用例”留在此时的风险非常高，因为此时它并不是真正的用例，而是某人脑海中的一个粗略想法，最多只是在最好的情况下被写下来传达给观众。想法很快就会出现，但也可能很快被舍弃。然而，它是一个潜在的转型用例的开始。

这里的投资回报率（ROI）基本上为零，因为还没有真正的工作投入到这个用例中。只有想法的形成可以被描述为一种投资，但在这个阶段我们通常会忽略这一点。

项目成熟度

项目成熟度也接近于零，因为唯一存在的只是一个用例、工作流程或流程改进的想法。根据我们的经验，许多想法生成者都有一个非常明确的想法，指向一个清晰的方向。从这个角度来看，可以说这是一个非常成熟的想法，但将这个想法付诸实施的整个过程处于最低水平。

阶段2. 概念：结构化想法

好想法的问题在于，如果你不将它们表达、结构化和传达，它们会一直停留在想法阶段。

概念阶段是指在公司战略方向、技术基础设施和可用数据的基本框架内审查一个新想法。这主要是关于识别挑战、评估克服挑战的好处，并提出解决方案。这是一个探索和头脑风暴的阶段，在这个阶段，想法仍然是可塑的，项目的方向尚未确定。

人们常常基于一个理想的解决方案提出想法，但在仔细观察后发现，他们并没有充分研究潜在的问题。至少，在设计解决方案时，早期研究数据的来源是很重要的。我们的经验表明，如果跳过这一阶段，你会冒出荒诞、不现实的想法。研究相关数据源还有助于人们更好地区分分析用例和操作化（或纯技术）用例。

概念阶段的起点是一个问题陈述。例如： 我们需要能够模拟和分析某些保险组合的发展，因为条件变化或外部触发因素，如战略改变、新的市场机会或必要的调整，以衡量潜在影响并最终引导组合朝某个方向发展。

最后一步是定义潜在的解决方案。这不是详细的需求清单，而是关于挑战期望并让想法提供者思考集成和互操作性。

评估用例的维度

你可以使用四个基本维度来帮助阐明概念：问题、涉及的价值、数据环境和解决方案。关于每个维度的一些示例问题包括：

问题维度

• 我们目前正在解决组织面临的什么挑战？
• 这个问题如何阻碍我们的运营效率或盈利能力？
• 这个挑战与哪个关键业务目标相关？
• 我们希望通过解决这个用例实现什么目标？
• 谁受到了这个挑战的影响，以及如何受影响？

价值维度

• 我们预期的价值创造是什么类型的？
• 解决这个问题能带来哪些好处？
• 解决这个问题将如何使利益相关者受益？
• 这对业务、员工和/或客户来说会带来什么样的回报或优势？
• 解决这个问题是否可以创造竞争优势？
• 解决这个问题是否会带来创新或显著的流程改进？

数据环境维度

• 我们应该考虑哪些相关数据？
• 我们是否可以访问所有必要的数据？
• 我们可以探索哪些新的数据源以获得更好的见解？
• 这个用例是否需要实时数据分析？
• 我们应该如何集成外部数据源？
• 我们如何评估和提高数据质量？

解决方案维度

• 提议的解决方案包括什么？
• 哪些具体目标或绩效指标将标志着这个项目的成功？
• 我们应该考虑哪些分析技术或流程？
• 我们如何利用新兴技术来解决这个问题？
• 在提出的解决方案中是否存在自动化的机会？
• 我们如何确保解决方案在时间上的可持续性？

可以在研讨会上提出这些问题，以启动讨论并开始产生想法。

交付成果

这一阶段最重要的结果是一个用例画布，如图5-4所示。这个画布既要全面又要简洁，捕捉到项目目标的本质。

风险和投资回报率

在这个阶段放弃项目的风险比在想法阶段略高。仔细研究后，你可能会发现这个用例不是一个分析用例，也可能根本不是一个真实的问题。但是，如果问题是有效的，你可以创建用例画布并进入下一阶段。 当然，这一阶段的项目风险仍然很高。想法尚未经过测试，数据可用性尚未确保，概念必须仍然与业务目标保持一致。反过来，投资回报率是推测性的：完全关于潜力和预测，没有实际的回报可见。

项目成熟度

在这个阶段成熟度才刚刚开始显现。这是一个探索和头脑风暴的阶段，在这个阶段，想法仍然是可塑的，项目的方向尚未确定。

阶段3. 概念验证：测试水域

概念验证阶段旨在测试想法的分析可行性和评估其业务价值。这个概念可以实现吗？如果可以，如何实现？

评估业务价值

为了证明一个用例，有两个重要的考虑因素：

• 这个用例对公司有什么价值？
• 实现它的可行性如何？

在业务价值方面（绝对是最具挑战性的），你需要知道这个用例对你的业务有什么价值。这可能是改善流程、增加收入、更有利可图的组合，或者改善客户感知或满意度。这种提议的解决方案是短期还是长期实现这种价值的方式？这个用例是否是由合规性或监管问题驱动的必需品，还是根本上是为了促进创新？它是否与您的商业战略相关联？

如果你有适当的关键绩效指标（KPI），可以将它们作为基准，比较不同用例在组合规模或受影响的任务、客户或员工数量等指标上的表现。这将帮助你比较案例，识别“容易实现的目标”或简单的胜利，并优先执行用例。 为了指导讨论，可以问以下问题：

• 存在哪些机会可以简化工作流程并实现成本效率？
• 这个项目如何与我们的总体业务目标、愿景和战略保持一致？
• 我们何时能期望看到这个项目的经济收益，以及预测是什么？它是长期还是短期内实现价值？
• 这将如何提升客户的感知和满意度水平？
• 这将如何改善客户参与和忠诚度？
• 这个项目将如何有助于竞争差异化和市场领导力？
• 什么驱动我们的业务价值：改进流程、增加收入、更有利可图的组合、提高客户满意度？还有什么？
• 这个项目是必需的，由合规性或监管问题驱动，还是根本上是为了促进创新？

我们认为最好的方法是建立一个由业务专家组成的客观监督委员会，听取用例提案。CoE（卓越中心）应该协助完成这个任务，但最终的决定应该由业务专业人士做出。这让他们参与到塑造分析转型中，是传播想法并让那些提出想法的人得到关注的绝佳论坛。

如果你有适当的KPI，也可以将它们作为基准，比较不同的用例，基于组合规模或受影响的任务、客户或员工数量等指标。我们知道，为所有用例设置统一的评估标准是最困难的部分。由于用例的多样性，需要不同的KPI。一个用例可能是关于改善公司的人手配置，例如，通过节省工作日。另一个用例可能是增加公司的收入或实现显著的节省，这需要财务KPI。

此外，在许多情况下，这些都是假设的、假定的值，因为通常尚不清楚用例是否会成功。因此，在期望的改进方面要现实和谦虚。还要强调单个用例可以带来的价值。试点新方法和技术通常不会带来直接的好处，但为未来的用例奠定了基础。我们建议与其他IT和创新项目就如何使用KPI衡量价值达成一致，哪些规则适用，使用哪些维度。这将帮助其他人理解你的测量，并在公司内创建一定程度的统一性。

评估可行性

如何定义可行性也取决于你的业务模式、生态系统和行业。评估可行性不比业务价值容易，但框架要好得多。要考虑的维度包括：

• 数据的可用性和质量：是否有足够的数据用于建模？其质量是否高？
• 建模和数据工程的复杂性：在数据科学和工程方面，这个挑战有多复杂？数据集是否特别大？
• 集成工作流程的复杂性：将提议的解决方案集成到工作流程中有多难？我们需要触及哪些系统？
• IT基础设施和建模平台：我们应该使用哪些建模和操作平台？
• 依赖关系：是否有需要考虑的外部依赖或法律考虑因素？是否有业务限制，例如其他大型项目？
• 转型和采用：业务端的最终用户是否支持采用此解决方案？推出它需要多少努力？

在大多数情况下，分析专业人员应该评估可行性，理想情况下有分析翻译的支持。举办一次“可行性检查”会议，召集数据工程师、分析师、数据科学家、主题专家和具有不同技能的分析翻译来讨论任务。此外，数据专业人员可以并行进行初步原型设计和技术编码，以获得更准确的见解。

交付成果

业务价值和可行性检查的结果应包括：

• 可行性研究
• 初步的分析测试以展示用例的价值
• 一个帮助将每个用例定位在二维价值矩阵中的评估KPI

这将帮助你比较用例，识别“容易实现的目标”或简单的用例，并决定执行用例的优先级。如前所述，这只是可能的评估类型之一；取决于你的个性化需求以考虑更多的度量。

风险和投资回报率

这个阶段的风险仍然很高，因为你正在测试概念在现实世界中的可行性。概念验证作为现实检查，可以增强对项目的信心或揭示不可逾越的挑战。当然，这也增加了用例被停止的可能性。此阶段的投资回报率尚不可见，但成功的概念验证可以促进利益相关者的买入并可能解锁进一步投资。

项目成熟度

项目还不成熟。这个想法不再只是纸上的概念，而是正在经历其第一个实际测试，离实现更近了一步。

阶段4. 原型设计：塑造概念

如果概念验证结果积极，下一步是创建一个原型。目标是将分析概念实施在一个操作原型中，测试其技术和方法可行性，并提高分析成熟度。原型可以是，例如，关系数据库中的第一次数据探索，不同数据源的复杂数据准备，第一个工作流程的初步分析管道，或初步模型测试，以查看数据是否包含所需的信息增益以及初步假设是否可能得到支持。

这个过程是关于探索分析挑战和测试其可行性，但还不涉及技术集成或软件工程。当最初的分析工作流程或探索的程序化技能尚不可用时，尝试使用低代码或无代码引擎。它们可以帮助你快速进行描述性分析，并在怀疑情况下粗略测试初步的机器学习实验。一个非常易用的工具是Orange。虽然它只使用本地计算机系统的处理能力（这是一个严重的限制），但它可以帮助你快速了解数据结构和初步算法方法。图5-5展示了Orange中的一个示例探索。

在原型阶段，目的是了解数据、其结构和系统性，以便你可以快速可靠地决定算法是否合适，以及你的假设是否可以得到支持（至少目前为止）。低代码工具可以帮助快速原型设计，但不是必须的。我们的建议始终是走向编程方向，因为这种技能无法通过这些工具弥补，并且在下一阶段至少是强制性的。但如果低代码工具有助于加快第一次分析见解的获得，那就使用它们。这可以看作是一种早期的AA，旨在支持数据专业人士。

交付成果

如果原型工作，结果是一个功能性最初的技术实现。这可能是一个在有限程度上工作的代码，甚至只是一个数据子集，以展示用例的潜力。

风险和投资回报率

随着原型使理论概念变得具体，放弃的风险开始减少。可能会出现技术实现和集成挑战，但这些通常比概念不确定性更易于管理。然而，这是退出风险最高的地方，因为只有在这里才会清楚地知道是否可以实现预期的价值。

此阶段的投资回报率尚未实现，但成功展示一个原型可以促进利益相关者的买入并可能解锁进一步投资。实际上，从这一点起，投资回报率开始变为负数，因为更多的努力和成本进入了用例的探索。

项目成熟度

在原型设计阶段，成熟度显著提高，因为用例开始成形并准备好进行实际部署。

阶段5. 试点：测试运行

进入试点阶段意味着在真实操作条件下测试原型。目标是双重的：利用原型实现其初始潜力，并通过直接反馈改进其在日常操作中的可行性。这是你真正确定其可行性的地方。

想象一下你的团队已经开发了一个用于客户细分的分类模型，具有非常好的预测结果。你已经将这个模型连接到网站的后端，以定制用户体验并提供特定的优惠。不幸的是，分类过程花费的时间过长——超过了适合实时分析的时间。如果这个问题不能解决，用例可能无法实现预期的价值，你可能不得不放弃它。在这种情况下，肯定有优化的空间，但必须明确的是，该用例尚未进入安全港。

交付成果

主要的交付成果是改进版本的代码。这伴随着试点阶段的全面文档，包括操作日志、监控程序、评估结果、用户培训和反馈调查。

风险和投资回报率

随着项目在受控的真实世界环境中证明其可行性，风险进一步降低。原型越成功，反馈越积极，风险越低。退出风险在此时急剧减少，但仍然存在。在生产类似环境中的失败测试仍可能导致用例失败。

此阶段的投资回报率最低，退出项目的成本最高，因为业务尚未实际实现价值。

项目成熟度

在试点阶段，成熟度达到一个关键点。项目不再是内部原型，而是一个操作工具，正在进行严格的测试和优化。

阶段6. 产品化：全面部署

在成功的试点后，用例准备好成熟为完整的产品。这个阶段的目标是使解决方案在各种工作流程中投入生产。

交付成果

交付成果包括：

• 一个稳健的推出计划
• 一个广泛使用并集成到工作流程中的操作计划
• 复杂的治理结构
• 版本管理流程
• 全面的代码文档
• 定义的服务水平协议（SLAs）

风险和投资回报率

此阶段的风险最低，因为产品已经经过了广泛的测试并准备投入使用。现在的关注点转移到了操作风险和维护服务质量上，以及一致采用新解决方案。你的转型管理和变更管理技能在这里发挥作用，以确保解决方案的成功使用。

投资回报率预期达到顶峰，因为产品现在开始提供承诺的好处并开始产生超过初始投资的回报。

项目成熟度

项目在此时达到顶峰成熟度。一个打磨好的产品准备好为组织提供价值并推动变革。

决策：自制还是外购

也许用例方法对你来说听起来有些复杂。你怎么能同时处理多个这样的项目呢？好消息是：你不必独自完成所有工作。实际上，许多用例不应该由你来完成，而是应该外包给外部供应商或合作伙伴。

为了更好地理解这一方法，让我们快速探索一下构建用例的选项。

这不是一个二元选择

决定是否自制或购买增强工作流解决方案并不是简单的黑白选择。相反，将其视为一个连续体，一端是“完全内部开发”，另一端是“完全购买的解决方案”，如图5-6所示。在这两个端点之间，有着广泛的选项。

图5-6. 决定是否自制或购买增强工作流解决方案的因素

以下是一些带有聊天功能增强的工作流示例：

• 完全内部开发的解决方案：从头开始构建一个自定义聊天机器人，以便员工可以使用Microsoft SharePoint进行聊天。
• 主要内部开发的解决方案：将一个通用的“与我的文档聊天”聊天机器人平台集成到SharePoint中。
• 主要购买的解决方案：使用一个完全托管的聊天机器人平台，例如Microsoft Copilot Studio，并进行一些定制。
• 完全购买的解决方案：购买Microsoft Copilot许可证，使员工可以使用SharePoint进行聊天。

在大多数情况下，你可能会混合使用供应商的预构建组件或模型，并在内部开发应用程序的特定部分。这种混合方法允许更多的灵活性和控制。当然，这需要内部人才，如果你处于Data Active或Data Progressive阶段，这些人才应该是充足的。

确定正确的平衡点，考虑以下关键因素

用例阶段

如前所述，概念验证和原型阶段是快速测试可行性和潜在影响的阶段。目标是快速学习并快速失败。原型通常不会与IT环境集成，这使得这个阶段非常适合使用现成的或供应商的解决方案。

相反，试点和生产用例通常紧密集成到你的系统环境中。在这里，你需要更多的控制、治理和可靠性。此时，重新评估现成解决方案是否仍然有意义至关重要。有时，在用例通过概念验证和原型阶段后，量身定制的集成会更好。

战略价值

战略价值是指解决方案对你的总体业务目标的重要性和影响力。

以特斯拉为例，自动驾驶的用例对其公司生存至关重要，因此具有极高的战略价值。另一方面，对于保险公司来说，文档文本提取的用例可能很有价值，但业务仍然可以在没有它的情况下生存。

用例的重要性可能会随时间变化。某些最初被视为非常重要的项目，随着市场变化可能变得不再那么重要；而其他最初看起来很小的项目，随着聊天机器人从简单的客户服务工具演变为客户体验的重要组成部分，可能变得非常有价值。

外部解决方案的性能

没有现成的解决方案会完美契合。但它离满足你的需求有多近？请记住，“足够好”的门槛是可变的。

例如，一个增强的工作流可以以75%的准确率分类客户支持票。这一开始可能看起来不那么令人印象深刻。然而，如果你的手动过程之前的准确率只有60%，那么增强解决方案就代表了显著的改进。对于某些应用程序来说，即使是小幅的准确性提升也能带来显著的运营效益或提高客户满意度。

内部资源

内部资源是指组织内可用的技术资源，例如数据、基础设施和熟练的团队。不仅仅是你是否拥有所需的资源，还包括你能多有效和高效地使用它们来构建你想要的解决方案。（即使你有一屋子的开发人员，如果他们都在做其他项目，那也帮不上忙。）

决策场景

虽然我们刚讨论的因素是决定自制或购买的最关键因素，但对于大型企业来说，还有许多其他因素需要考虑。因素如组织准备情况、文化适应性、合规性和伦理道德都可能在采用和实施增强工作流中起到重要作用。但现在，让我们集中讨论我们的小子集，学习在不同场景中如何决定“自制或购买”。图5-7的流程图帮助你直观地理解这个过程。

图5-7. 用例自制或购买的流程图

场景1：具有低战略价值的用例原型

这里，决策很简单：选择现成的解决方案。即使你有可用的内部资源，它们也更适合用于具有高战略价值的用例。记住，你在原型阶段的主要目标是快速测试和验证想法，而不是重新发明轮子。

推荐：购买

场景2：具有高战略价值的用例原型

对于具有高战略价值的原型，首先检查现成解决方案是否满足你的需求。如果是，用它快速测试可行性和用户反馈。

推荐：购买

但如果没有供应商解决方案足够好？检查你是否有资源在内部构建混合解决方案。例如，你可以在内部构建主要的机器学习模型，并使用第三方组件完成其余部分，或者反之亦然。

推荐：混合

如果没有内部资源，构建原型是一个艰难的决定。如果用例具有非常高的战略价值，你可能需要考虑在基础设施或数据上进行投资或雇佣（临时）员工。然而，这些事情很复杂。在做出这种承诺之前，仔细评估潜在的投资回报率。

推荐：三思而行

场景3：将具有低战略价值的用例推向生产

如果你已经成功地使用供应商解决方案完成了一个“快速赢”的用例原型，并且它满足你的需求，那么在生产中继续使用它或基于它构建是明智的。例如，如果你使用现成软件创建了一个用于自动化手动数据输入的人工智能原型，并且它能满足你的需求并顺利添加到当前系统中，那么在生产中继续使用供应商解决方案可能会更便宜和更快。你以后可以随时切换到内部构建。

请记住，每个人工智能服务都需要持续的维护和支持。即使你需要定制，你仍然可以只重建工作流的部分并根据需要进行调整。例如，如果你使用美国供应商的聊天机器人服务进行原型设计，但希望在生产中切换到欧洲供应商，你可以检查是否可以在欧洲托管核心组件（人工智能模型）作为服务，然后在你自己的基础设施上构建其余应用程序，使用开源或无代码工具。

推荐：混合或购买

场景4：将具有高战略价值的用例推向生产

首先，如果你已经成功地将一个具有高战略价值的用例从原型阶段推进到生产阶段，祝贺你！你已经跨越了一个重大障碍。如果用例对你的业务确实至关重要，那么几乎总是值得分配一些专门资源来内部构建它。毕竟，这将使你与竞争对手区分开来，并为你的业务带来显著的长期价值。

推荐：自制

从我们的场景来看，显然“自制”通常不是最好的选择。你最初的努力可能只会产生一些对竞争力至关重要的强大用例。在内部用一个专门的团队构建这些用例是可以的。但对于大多数用例，不要过于纠结细节。处于数据流利阶段的公司不会只在生产中有少数几个分析用例，而是有成千上万个。它们中的大多数是小而低影响的，但它们的价值加起来很大。

特别是如果你的组织处于分析成熟度的早期阶段，或者是一个非技术性的中小型企业，大多数增强用例都可以通过现成的或混合解决方案来处理。这使你能够专注于业务的核心方面。最好从小处着手，并在开始时寻求专家帮助。你尝试得越多，学到的东西就越多。

成功的关键因素

有几个关键因素在成功实施用例中起着重要作用。它们包括：

透明度

通过使用交互式用例库（在本章后面详述的“用例库”）来实现透明度。高级管理层的支持至关重要，同样也需要一个明确的收费模型来清楚地划分资金责任。

标准化监控

定期监控以衡量用例相对于预定义指标的成功有助于保持项目的轨道和生产力。定义操作标准并定期评估用例，以避免沉没成本谬误也很重要。

敏捷方法

敏捷方法已被证明对开发和操作数据驱动的用例非常有效。从一开始就融入DevOps和MLOps概念可以简化从概念到产品的路径。培育一个数据分析社区，特别是涉及分析翻译的社区，可以推动创新和协作。

我们描述的方法强调了从概念到可部署产品的结构化但灵活的过渡。这条路径需要仔细规划、持续关注交付成果，并灵活响应反馈和变化的条件。这种战略概览和战术灵活性的结合是成功分析转型的基石。

除了遵循这些结构化阶段和策略，还要注意不断变化的数据景观和技术进步。即使你专注于组织当前的数据状态和分析能力，也要关注可能影响用例的新的趋势。整合新技术、适应监管变化以及随着业务增长扩展用例都是影响分析转型长期成功和可持续性的关键考虑因素。

平衡自动化与集成

许多增强工作流之所以失败，是因为在一开始过于依赖自动化和集成。要明确的是，高度集成和高度自动化的增强工作流对你的业务具有最高的杠杆作用（因为它们为用户完成了大部分繁重的工作），但它们也是最难构建的。在大多数情况下，最好设计用例以相对较低的自动化和集成程度来增强工作流。一旦你积累了更多经验，就可以逐步扩展它们。

这是如何工作的呢？看看图5-8中的简单矩阵，我们称之为集成-自动化框架。

图5-8. 集成-自动化框架

这个框架基于一个简单的原则。它根据两个标准对用例进行分类：集成程度和自动化程度。集成是指用例嵌入到现有系统环境中的深度。自动化是指用例在最小的人为干预下完成多少工作。

思考一下这一点。大多数人会认为集成推动了自动化，反之亦然。但这并不一定是事实。例如，你可以创建一个包含一些自动化但未完全集成到系统环境中的用例。为了帮助你理解区别，这里有四种类型的用例及其在矩阵中的位置：

助手

最低级别的用例是我们称之为助手的类型。通常，员工使用一个外部应用程序，需手动处理输入和输出（如复制和粘贴文本或上传和下载文件）。集成程度低，自动化程度也低。ChatGPT就是一个经典的例子。不要误会，这些应用程序可以非常强大。截至本文撰写时，ChatGPT可能是你会遇到的最有能力的外部AI助手。其他例子包括Poe、Google的Gemini、微软的AI驱动的必应搜索，以及任何需要手动上传和下载文件的AI工具（如标准版Midjourney）。

副驾

类似于助手，副驾需要用户进行繁重的工作（即自动化程度低），但它们深度集成到你的系统环境或业务工作流中。这是目前AI中最有前途的领域之一：每个主要软件公司都在评估是否在其产品中包含这些“副驾”功能。GitHub Copilot、Microsoft Copilot、Tableau中的Einstein Copilot、Google Workspace中的Duet AI以及Slack和Notion中的AI功能都是例子。

副驾非常棒，因为它们知道你当前在做什么。例如，如果你使用Outlook Copilot回复邮件，它会已经知道之前的对话历史。无需复制粘贴。然而——这是与下一种用例类型的最大区别——使用副驾，AI生成的建议不能在没有批准的情况下实施。因此，员工可以（并且必须）根据需要审查和纠正AI的输出。这种用例类型很受欢迎，因为即使AI模型并不完美，它也提供了很大的价值。

自动驾驶

自动驾驶具有高度的自动化但集成程度低。想象一下，你训练了一个AI驱动的聊天机器人，基于你的网站和内部文档来回答一级客户支持查询。一旦部署，这个聊天机器人就会完全自动运行，24-7回答客户问题，无需手动干预。

然而，这个聊天机器人并没有真正集成。它的集成通常只是将一个小的HTML或JavaScript代码片段放在网站上。（我们最近在我们为这本书建立的网站上实施了一个！）如果你告诉那个聊天机器人，“我想买这本书”，它会返回一个亚马逊链接。然而，它不能接受你的订单并将其放入预订系统。如果你想这样做（在技术上是可行的），你需要提高集成程度（见下一类型，代理）。

其他自动驾驶用例的例子可能包括：

• 一个社交媒体工具，进行自动内容审核
• 一个自动监控系统，发送电子邮件通知
• 你家里的一个机器人吸尘器，按计划进行清洁

代理

代理是AI和增强工作流的圣杯。每个人都想要它们。想象一个内部聊天机器人，能够回答常见问题并执行诸如重置密码、退款和接受书籍订单等任务。明确地说，这些用例确实存在，但它们是最难破解的坚果。它们需要一个强大且经过战斗测试的基础设施（我们将在第六章介绍）。在这个阶段，你不仅要处理AI固有的挑战（如不准确、幻觉和性能问题），还要处理涉及集成大量遗留应用程序的老式IT问题。代理用例的进一步例子包括：

• 自动处理和转发传入文档
• 在你的网站上提供个性化推荐
• 标记生产线中的质量问题

我们是这些用例的大粉丝，我们的目标是尽快帮助你实现它们。但它们不是最好的起点。

当你开始用增强的AI功能来增强工作流时，有两种方式进行。你可以从左到右（低自动化到高自动化）并通过增加自动化来增加用例的复杂性。或者你可以从下到上（低集成到高集成），主要挑战是将现有的功能进一步集成到你的系统或工作流中。通常同时进行这两者——即对集成和自动化水平同时增加——不是个好主意。不要直接从助手跳到代理。

我们在多个领域的不同AI项目中的经验教会我们，最好的方法通常是按照我们刚刚介绍的顺序来处理用例： 助手 → 副驾 → 自动驾驶 → 代理

关键是从那些让人处于循环中的用例（助手和副驾）开始。这样，你将能够控制AI输出，确保结果质量，并随着时间的推移了解更多工作流的情况。这些用例的美妙之处在于它们通常是最不复杂的，使其成为早期原型和概念验证的绝佳候选者。

用例库

用例库是一个具有重要价值的战略资产：一个中央目录和存储库，涵盖了组织的分析努力——过去、现在和未来。理想情况下，它是一个互动的库，捕捉每个用例从想法到完全功能的分析工具的成熟过程。用例库是用例方法的重要组成部分。在构思阶段，它提供了参考点，供你考虑或尝试。在概念验证和原型阶段，它提供了可行性和比较分析的有价值数据点。当项目进入试点和成熟阶段时，该库记录了整个过程。

用例库不仅是分析项目的存储库，还是一个战略工具，捕捉组织分析能力的学习、成长和创新。它是构建分析中心文化的基石。其好处包括：

促进全组织的透明度

记录每个用例的目标、方法、进展和结果，促进决策制定并鼓励跨功能协作，因为不同领域的利益相关者可以看到整个组织正在解决哪些分析项目。

实现监控

用例库使管理层和团队能够监控每个用例的进展，评估其影响，并在需要时做出明智的调整。

孵化创新

通过详细查看当前和已完成的项目，该库可以激发团队在现有工作和想法的基础上进行改进，并开发新想法。分享知识和经验可以加速创新周期并减少重复劳动。

激励组织文化

用例库可以在尚未参与分析项目的团队和部门中创造一种错失恐惧感。这可以激励他们探索数据驱动的机会。

使利益相关者可见

该库展示了每个用例的参与者，认可他们的努力，并为专业知识和执行力建立内部基准。这种可见性可以促进个人职业发展，并帮助组织识别和培养其分析人才。

图5-9. 用例库的一个示例实现

用例库的最重要功能是提供公司各个领域收集的所有用例的概述。由于包括了创新管理或IT等其他领域的用例，你可以使用元配置将它们适应到你自己的领域。这种优势对于增强工作流至关重要，因为拥有一个广泛的用例输入通道可以提高对其他领域的可见性，并允许IT和分析团队在以后的增强工作流中更紧密地合作。因此，用例库的跨领域概述和需求管理非常有帮助。

评估用例的可行性和业务价值

评估用例的可行性和业务价值（见图5-10和5-11）对确保将资源分配给最有前途的用例至关重要。如果你专注于定期运行用例，那么拥有一个提供透明结果沟通的工具是必要的，甚至可以在工具内进行评估和评估。概念验证是用例过程的一个频繁且连续的部分。

图5-10. 用例库对业务价值和可行性的评估

图5-11. 用例库评估业务价值和可行性的概述

了解用例的详细信息，包括正在进行工作的状态，对于每个参与者获得对整个过程的全面理解非常重要。

看板板

看板板（见图5-12）对于传达各个项目的详细执行情况也非常有用。它不仅对分析专业人员有帮助，还能让利益相关者了解每个关键资源的预计执行时间、资源规划和分配。看板通常比大纲标题更详细，例如构思、概念或概念验证。它允许为每个用例定义具体的子任务并记录依赖关系。

图5-12. 不同阶段用例的看板执行

我们建议你仔细查看你的具体工作环境。在大多数情况下，公司有一个专门的资源规划解决方案用于敏捷开发。可能有数十种解决方案，甚至Microsoft Teams也提供了一种在任务板上记录活动的方法。技术资源之间的相互依赖性和所需人员的容量也许可以更轻松地记录在此处。

将看板集成到你的用例库的魅力在于，它为所有利益相关者提供了全面的透明度，包括那些未参与更广泛的敏捷开发项目的利益相关者。对于应用程序来说，这可能比可行性更重要。

用例库的另一个更重要功能是提供单个用例的详细信息：问题的详细描述、期望的收益和拟议的解决方案（见图5-13和5-14）。这可以增加人们对实施用例的理解和信心。让人们了解当前的发现、初步结果和进展，也为他们提供了参与的机会。对于全面的文档记录，我们建议包括指向其他知识来源的链接，例如知识库、产品页面和Git存储库。

图5-13. 用例库概述

图5-14. 详细的用例概述

实施增强分析的技术要求

在第三章中，我们从业务和以人为本的角度讨论了增强分析（AA）的挑战和限制。在本章的结尾，我们将讨论在你的组织环境中实施AA的技术挑战。然后，在第六章中，我们将提出一个概念，为实际实施AA解决方案奠定基础。

一个最大的挑战是AA的基本需求：将分析解决方案集成到工作流中。提供传统的数据和分析解决方案很简单：你在适当的环境中部署产品，这就是结束。当然，这并不是没有努力：你仍然必须考虑适当的运行环境、授权管理、培训和ML/DevOps等因素。但当你提供一个交付成果，如仪表板、报告或工具时，你已经完成了用例方法中的最后一步，可以开始使用解决方案。

然而，在AA中，你必须考虑不同的解决方案交付方式，相应的工作流仍需要一个采用步骤。在这里，努力可能会非常大。你必须涉及其他参与者和团队，计划活动，有时还要在已经建立的系统和工具中进行这些活动，这些工具具有完全不同的技术运行时或技术上难以扩展。虽然交付是传统过程链的终点，但在AA中，这个链条必须扩展到包括集成活动。

乍一看，这似乎复杂得多，因为现在必须进行进一步的技术实施。但请记住，AA消除了适应支持活动的需要，简化了产品阶段。由于推动新解决方案的采用和积极接受是我们迄今为止展示的方法中最大的挑战之一，因此不要高估技术集成的努力。

只有成功地将分析解决方案集成到工作流中，你的用例才能成功。当然，如何评估成功（例如通过ROI或个体退出风险）取决于具体的解决方案。例如，对于设计为独立工具的解决方案，如仪表板，你可以更早地实现高ROI，并且实现特定工作流可能是可选的。然而，我们坚信，对于大多数解决方案，只有通过成功的技术集成，你才能实现高ROI。

图5-15扩展了我们在图5-3中展示的用例方法，增加了一个进一步的集成步骤：增强。在下一节中，我们将考虑这一步骤的最重要方面，并讨论如何最好地解决这些问题。

图5-15. 包含新步骤“增强”的更新用例方法

基础设施设置挑战

虽然你可以以非常不同的方式设计AA的技术实施，但实施必须适应整体基础设施。这里最明显的分析见解提供者是微服务基础设施。我们建议依赖REST API，它们是成熟的，分析编程语言良好支持的，轻量级的，模块化的，安全的和可重用的。它们几乎可以集成到所有系统中，并创建独立于供应商解决方案的功能，这是始终推荐的。Martin Fowler的这本指南提供了微服务基础设施的良好概述。

SAP和微软提供相应的解决方案，例如将业务对象集成到SAP中或将Power BI集成到微软工具和Office中。我们在这里不触及这些解决方案，因为它们严重依赖于供应商并且不提供相同的轻量和独立性。

你的增强应是技术无关的。无论你的遗留基础设施及其运行时如何，你的分析应是自主的和独立的。云提供商，如微软Azure和亚马逊AWS，提供通过网络API提供分析的方法。Python和R提供易于使用的Web服务端点，以使分析和数据可用。此外，这两种编程语言还提供了各种连接器，用于广泛的数据源。它们应该是你实现代码分析的首选。例子5-1说明了其中一个选项：R Plumber。这是一个非常简单的示例API，提供有关特定合同ID的详细合同信息。

例子5-1. 一个R Plumber数据提供服务示例

# 文件: api.R 
library(plumber) 
library(dplyr) 

# 想象的示例数据框
contracts <- data.frame(
  id = 101:110, 
  name = c("Customer A", "Customer B", "Customer A", "Customer A", "Customer C", "Customer V", "Customer Z", "Customer G", "Customer A", "Customer Z"),
  date = as.Date(c("2023-01-01", "2023-01-05", "2023-01-10", "2023-01-15", "2023-01-20", "2023-01-25", "2023-01-30", "2023-02-04", "2023-02-09", "2023-02-14")), 
  product = c("Product 1", "Product 2", "Product 1", "Product 1", "Product 2", "Product 1", "Product 5", "Product 2", "Product 2", "Product 1"), 
  premium = c(120, 150, 180, 210, 240, 270, 300, 330, 360, 390) 
) 

#* @apiTitle Contract Filter API 
#* @apiDescription API to filter contracts by contract number 

#* Filter contracts by contract number
#* @param contract_id The contract ID to filter by
#* @get /filterContracts
function(contract_id) { 
  filtered <- contracts %>% 
    filter(id == as.numeric(contract_id)) 

  if (nrow(filtered) == 0) 
    return(list(message = "No contract found with the given number"))
  
  return(filtered)
}

plumber::plumb(file='api.R')$run()

此外，R Plumber会自动创建一个Swagger API端点来检查和访问新的Web服务。Swagger是一个开源软件框架，支持大量工具生态系统，帮助开发人员设计、构建、文档化和使用RESTful Web服务。它提供了一个基于Web的用户界面（如图5-16所示），使API的测试和交互变得简单，并提供了自动生成客户端库、服务器存根和API文档的工具。由于其简洁性和在管理整个API生命周期（从设计和文档到测试和部署）中的作用，Swagger被广泛使用，并得到R Plumber的支持。

图5-16. R数据提供服务的示例Swagger API界面

这是通过终端直接请求API所获得的结果：

curl http://127.0.0.1:6423/filterContracts?contract_id=104 

[{"id":104,"name":"Customer A","date":"2023-01-15","product":"Product 1","premium":210}] 

总体而言，提前考虑建立一个内部分析基础设施以开发和提供解决方案是很重要的。例如，算法必须构建为软件工件，以使它们作为包、分析引擎或Web服务可用。如果在早期转型迭代中还没有这样做，请在此时提升员工的分析编程语言技能。他们还可以在全栈开发中广泛使用这些技能。

除了IDE之外，你还需要为部署和执行这些语言创建合适的运行时。描述性报告引擎、无代码和低代码选项以及Excel解决方案在扩展方面不会完全足够，因此我们再次建议在早期阶段依赖Python或R。这两种语言具有广泛的功能库，可以实现全栈开发，并提供最佳的分析操作能力，如数据管道和ML或各种分析挑战的扩展。

在R中，很容易创建封装分析功能的包结构，并且可以在不同的上下文中使用这些包。包可以嵌入其他应用程序中，作为服务端点部署，或集成到用户界面前端中。

一种有益的方法是将R包实现为可执行引擎。这些包在使用上与纯功能包有所不同，功能包包含一个统一域的功能集合（如dplyr，包含各种数据整理功能）。

引擎是可执行的工件，在运行时接收环境变量并通过定义的功能端点执行。例如，一个执行客户销售汇总的引擎必须封装所有必要的数据获取、评估和计算操作。在运行时，引擎接收所有需要的环境变量（如数据路径）作为参数或环境设置。通过调用执行功能并传递相关的客户标识符来执行相应的操作。这些引擎对于建立公司范围内的标准化工作流非常理想，因为它们结合了功能和互操作性。

然而，如果你的整个设置主要基于SAP或微软，并且分析团队和IT团队在这些环境中部署和集成解决方案更容易，那么利用这些机会更好。比起没有增强，因为最初跳到独立解决方案的门槛太高，还是依赖于高度依赖的解决方案更好。

以下示例中的代码创建了一个客户引擎来分析购买情况。首先实现例子5-2中的执行函数。

例子5-2. 客户购买分析引擎

#' 执行客户购买汇总 
#' 
#' 此函数根据环境变量路径检索客户和购买数据，基于指定的客户ID筛选这些数据，
#' 并返回他们的购买历史摘要以及他们的个人信息。 
#' 
#' 该函数从RDS文件中读取客户数据和购买数据，路径由环境变量指定。
#' 然后，它根据给定的客户ID筛选这些数据，汇总购买信息（购买数量、总金额和平均金额），
#' 并将其与客户信息结合。 
#' 
#' @param customer_id 一个表示唯一客户ID的数字或字符值。 
#' 
#' @return 包含客户个人信息（customer_id，name，age，city）和购买汇总（num_purchase，sum_amount，avg_amount）
#' 的数据框。如果找不到客户，则返回一条消息，指示找不到给定ID的客户。 
#' 
#' @examples 
#' execute(1234) # 用有效的客户ID替换1234 
#' 
#' @import dplyr 
#' 
#' @note 该函数依赖两个环境变量：'CUSTOMER_DATA_PATH' 和 'PURCHASES_DATA_PATH'
#' 来定位RDS文件。确保这些变量已在R环境中设置。 
#' 
#' @export 
#' 
execute <- function(customer_id){ 

  # 使用环境变量获取文件路径 
    customer_data_path <- Sys.getenv("CUSTOMER_DATA_PATH") 
    purchases_data_path <- Sys.getenv("PURCHASES_DATA_PATH") 

  # 从环境变量指定的路径中读取数据 
  customers <- readRDS(customer_data_path) 
  purchases <- readRDS(purchases_data_path) 

  filtered_customers <- customers %>% 
    dplyr::filter(customer_id %in% !!customer_id) 

  if (nrow(filtered_customers) == 0) { 
    return(list(message = "No customer found!"), result = filtered_customers) 
  } 

  filtered_purchases <- purchases %>% 
    dplyr::filter(customer_id %in% !!customer_id) %>% 
    dplyr::group_by(customer_id) %>%
    dplyr::summarize( 
      num_purchase = n(), 
      sum_amount = sum(purchase_amount), 
      avg_amount = round(mean(purchase_amount), 2) 
    ) 

  result <- filtered_customers %>% 
  dplyr::inner_join(filtered_purchases, by = "customer_id") 

  return(list(result = result, message = "Success!")) 

}

这是相应的包描述文件：

Package: customer.engine 
Type: Package
Title: Customer Data Analysis and Purchase Summary Engine 
Version: 0.1.0 
Author: [Your Name or Your Team's Name] 
Maintainer: The package maintainer <yourself@somewhere.net> 
Description: This package provides tools for analyzing customer data and summarizing their purchase history. It includes functions for reading customer and purchase data from RDS files, filtering based on customer ID, and calculating key statistics such as total and average purchase amounts. Designed for use in retail and e-commerce data analysis, it offers a streamlined approach for customer data handling and insights generation. 
License: [Specify License, e.g., GPL-3] 
Encoding: UTF-8 
LazyData: true 
RoxygenNote: 7.2.3

这是封装购买功能的最终执行：

Sys.setenv(CUSTOMER_DATA_PATH = "data/customer.rds")
Sys.setenv(PURCHASES_DATA_PATH = "data/purchases.rds") 

customer.engine::execute(c(1500, 9552))

最终输出：

  customer_id   name  age      city  num_purchase   sum_amount   avg_amount 
1        1500  Alice   40   Phoenix           107     49353.34       461.25 
2        9552  David   26   Houston            89     38878.83       436.84

SQL接口也是一种增强解决方案吗？是，也不是。

当然，最明显的解决方案是使用经典的SQL接口将数据传输到你自己的系统。集成通常不太复杂：每个开发人员至少具有基本的SQL知识，并且每种编程语言都有连接器和驱动程序。然而，就有效增强而言，缺点超过了优点。

SQL需要数据库上的访问管理。当然，数据库访问是常见标准，但在有效增强现有工作流时，它带来了更多挑战而不是好处。访问通常是表和视图，因此你必须了解每个表的含义、关系和约束。此外，数据库是直接连接的，这可能对公司的访问基础设施产生严重影响——尤其是如果不同的数据库运行在不同的云实例甚至通过不同的提供商。

数据库也可能难以替换或移动到不同的运行时。访问数据库的系统越多，从Oracle迁移到Postgres等数据库就越复杂。所有这些依赖项都必须解决，这意味着大量的组织工作。

最后，需要记住的是，无法保证通过常见数据提供获得的见解的治理。直接访问数据可能导致不同的实施和解释，因为每个消费系统在一定程度上必须这样做。然后见解的实施在各自的系统中以某种方式进行治理，不管各自的运行时是否适合这样的处理。我们见过无数的实现将像Java或C#这样的语言的能力推到极限，以在内部处理大量数据。

除了API DIY方法和SQL接口外，许多购买和开源解决方案在数据库之上，甚至在文件访问或其他数据存储之上提供抽象层（也称为数据访问层或DAL）。然而，它们总是创建对解决方案的依赖，并且通常不能解决见解治理问题。一个始终适用的指导原则是，今天的供应商解决方案是明天的遗留技术。

我们的建议是使用分析编程语言将分析作为Web API提供，使用API中心组织访问，如图5-17所示。像Kong这样的开源框架可以支持你。最有效的分析将是为业务量身定制的，并且需要个性化实现，因此尽早采用分析编程并在必要时培训员工的技能。

图5-17. 分析解决方案的API访问

除了结构化数据和分析的常规基础设施外，越来越重要的是拥有相应的非结构化数据基础设施。这将提供基础，以便基于上下文相关文档进行增强。与传统基础设施中的集成一样，你应该创建并提供编程访问作为API。

特别是生成AI和LLM的能力提供了全新的增强可能性，使得考虑适当的文档管理变得至关重要。想象一下，你在个别合同的库存系统中，选择了一个合同。一项服务返回有关该合同具体条件的摘要。

其基础设施比你想象的要简单得多。服务访问合同文件。它向LLM发送一系列复杂的提示以总结文档的细节。特别是如果需要分析数十份文件，这可能会变得非常复杂。然后，需要为文档管理提供索引和嵌入服务或向量数据库。我们不想深入细节：重要的是，如果增强要有针对性地支持业务，编程实现是必不可少的。Python特别适合在此实现这些功能，并提供这些服务，如例子5-3所示，使用开源库如LlamaIndex和LangChain。

例子5-3. LangChain工作流示例

# 导入必要的库
import os
from langchain.llms import OpenAI
from langchain.chains import LLMChain

# 从合同中提取排除条款的函数
def extract_exclusion_clauses(api_key, contract_file):
    # 使用GPT-4初始化语言模型
    llm = OpenAI(api_key=api_key, model="gpt-4")

    # 加载合同文档
    with open(contract_file, "r") as file:
        contract_text = file.read()

    # 定义提取的提示
    prompt = "Extract all clauses related to exclusions from the following contract:"

    # 使用LLM和自定义提示初始化一个LangChain链
    extraction_chain = LLMChain(llm=llm, prompt=prompt)

    # 处理文档并提取条款
    extracted_clauses = extraction_chain.run(input_text=contract_text)

    # 返回提取的条款
    return extracted_clauses

# 加载API密钥
api_key = os.getenv('YOUR_API_KEY_ENV_VARIABLE')
contract_file = "contract.txt"  # 替换为合同文件的路径

# 提取并打印排除条款
exclusion_clauses = extract_exclusion_clauses(api_key, contract_file)
print(exclusion_clauses)

IT系统集成挑战

将AA集成到公司的IT基础设施中是一个多方面的挑战，不仅仅是设置必要的基础设施。成功将AA集成到现有的IT环境中对于实现其全部潜力至关重要。这种集成必须无缝地融入用户的工作流中，从一方面适应遗留系统到另一方面嵌入到新开发的系统中。AA对组织有深远影响，并影响IT部门的持续项目和计划。本节将讨论这些集成挑战，考察出现的障碍和机会，并提供有效导航这一复杂领域的见解。

处理遗留系统

许多公司使用不易与现代AA工具兼容的旧IT系统。因此，某些前提条件是必不可少的：例如，技术堆栈必须支持API或Web API。你无法充分增强任何仍在运行不允许连接到常规Web API基础设施的环境的应用程序。变更通常需要对这些系统进行改装或升级，这可能很复杂且昂贵。

公平地说，这种情况不太可能出现；很难想象一家公司提供现代AA交付结构，但仍在运行无法使用它们的基础设施。

更可能的情况是，遗留技术“卡住了”：它基于适当的基础设施，但实现已经很旧（或未以可理解的方式实现，或由不再在公司的人员实现），公司通常决定继续运行它们，直到必要为止，但不再扩展它们的使用。这使得集成变得更加困难。仔细考虑是否值得扩展这样的系统。一旦你到达只进行维护的阶段，你就不远于退役系统并用新解决方案替代它。

最好的方法是在更新这些系统时考虑如何集成分析。当然，这一决定并不仅仅是由增强功能推动的；为了提供额外的分析解决方案而提前进行的努力不会得到充分的回报，因为没有人会使用它们。这就是为什么最好同时进行这两件事。

今天，没有任何运行环境无法使用Web API，因此我们的建议始终是依赖编程工具而非生成工具。

项目依赖关系

无论是将分析集成到新系统还是现有系统中，规划都很重要。集成会消耗资源和时间，因此你的可行性检查和用例规划必须考虑到这一点。重要的是在与利益相关者和客户的外部沟通中透明地展示这一点。

与IT协调进行分析规划。IT项目通常有自己的路线图和目标，因此其首要任务很少是由AA集成增加的第三方影响。与IT制定联合路线图，以协调目标并确保有效的资源规划。联合目标和关键结果（OKR）或计划增量规划（PIP）可以帮助你找到共识。

如果不适当推广，增强可能很快被降级，因此提高意识很重要。IT项目往往不是因为想提供新的、更好的用户体验而驱动，而是因为想遵守雄心勃勃的退役路线图。分析领导者可以利用这些机会，通过合适的增强直接改进系统的更新。他们的角色使他们在IT项目中有发言权，并能引导意图和优先级。只需确保仔细权衡什么更重要：快速启动还是包含增强工作流的整体方法。我们的经验表明，后续集成工作良好，但精心规划的整体实施最终需要更少的努力。

除了分析领导者，其他角色现在必须参与进来。

IT决策者负责组织的技术方向，并面临将AA集成到现有IT基础设施中的复杂任务。他们的责任不仅仅是实施；他们必须积极规划一个未来，在这个未来中，分析解决方案不仅共存，而且与现有系统协同工作，以确保无缝功能、体验和系统可扩展性。挑战不仅仅是技术上的；还包括将分析转型的文化转变从业务领域转移到IT。IT决策者拥有并塑造IT路线图。早期让他们参与进来，并帮助他们理解分析的价值及其对业务用户的相关性，以便他们能将其纳入规划中。

此外，你还需要业务分析师。他们是塑造工作流的过程架构师，所以提前准备他们思考增强。他们承担着类似分析翻译的角色，将业务和IT世界联系起来，并将AA见解转化为可行的策略。他们对AA潜力的认识将改变各部门对分析的看法和使用方式，因为他们定义了核心系统工作流。

在数据进取阶段的结束时，将分析翻译和业务分析师联合起来进行联合项目。他们的互动将在最终阶段中变得重要：一个定义解决方案，而另一个确保其有效集成到工作流中。

治理挑战

AA解决方案需要坚实的技术基础，特别是在运行时和可扩展性方面，但也在安全性、合规性和维护方面。可扩展性至关重要：无论消费的类型如何，应用程序必须高度可用和稳定。然而，它们在AA中以不同的方式运行。

虽然许多人习惯于通过工具和仪表板直接使用分析，但AA应用程序在后台运行。作为整体处理链的一部分，它们对最终用户来说通常是不可见的。实际上，最终用户甚至可能不知道他们目前正在使用一个复杂的、完全组合的工作流。

系统和组件必须正确协调，因为单个组件的错误可能导致整个工作流崩溃。这并不罕见，但问题在于工作流的组件可能高度分散，并由不同的责任方（数据或分析所有者）提供。确保这里的高可靠性以保证所有组件的互动。个别组件的系统集成测试是必不可少的。我们还强烈建议你为测试覆盖率、运行时和可用性建立最低标准。

此外，集成到工作流中意味着完全不同的实现个别分析服务的方式，它们必须能够处理更高的使用频率和无状态事务。不是专用工具的一部分的算法将需要智能策略来处理会话和高效的数据访问。交易将更短但更频繁。

当整个组合工作流的某些部分处理敏感数据时，必须澄清每个人的责任。乍一看，似乎显而易见的是将这项责任交给提供细粒度功能的人。但是当他们怀疑时，如何确保适当使用？

考虑以下示例：公司引入了一个增强其CRM系统的功能，直接向销售经理显示客户的购买历史、退货率和信用评分，所有这些信息都由不同的分析服务提供。这给他们提供了一个360度的客户视图。其中一些信息非常敏感，特别是信用评分。系统应该拒绝客户服务员工访问客户信息的敏感部分。控制这一点的责任几乎无法由信用评分信息的分析组件所有者来完成。尽管所有者尽可能遵守所有合规要求，但他们对消费工作流如何使用信息以及是否保密几乎没有影响。因此，实现的工作流本身必须确保访问控制和必要的多客户端能力。

我们与一个广泛的建议保持一致：为增强工作流的个别功能用户引入合同。这一概念已经在数据产品中建立，称为数据合同。在她的书《数据网》中，Zhamak Dehghani描述了如何为数据产品建立分布式责任并确保标准级别的合规性。在额外的文章“如何从单一数据湖迁移到分布式数据网”中，Dehghani定义了六个范式来提供数据作为产品：可发现、可寻址、可信且真实（具有定义和监控的服务级目标）、自描述、互操作（受开放标准治理）、安全且受治理。

我们在这些范式的基础上进行扩展。分析产品应： 可发现

分析产品必须易于查找。你可以通过提供一个集中平台或目录来提高可发现性，其中包含关于每个分析产品的详细信息，例如支持的分析类型、可以回答的问题和用户指南。

可寻址

每个分析产品都应具有唯一标识符或地址，以便于查找和引用。对于提供分析服务的API尤为重要。地址应直观且在组织内一致，以便于访问和集成其他工具和平台。

可信

分析产品必须提供基于高质量、干净数据的可信见解和预测。这包括数据来源、分析方法及任何假设或限制的透明文档。需要定期验证和更新以确保产品的完整性。

自描述

分析产品应用户友好且自解释。这意味着它们应具有清晰的文档、易于理解的界面，甚至可能有引导用户解释结果的交互元素。这增加了增强工作流开发者对分析产品的使用。为了减少对IT或数据科学团队的依赖，结果的语义（含义和解释）和语法（数据的结构和查询方法）应对用户清晰。

互操作

分析产品应符合已建立的行业标准，并能够与不同的运行时环境互动，以便集成到业务工作流中。

安全

确保对分析产品的安全访问至关重要。这包括实施严格的访问控制以保护敏感数据和分析见解，例如基于角色的访问控制、认证协议和加密。这些措施应与组织的更广泛IT安全策略以及全球数据安全、隐私和伦理标准保持一致。

我们增加了一个范式，定义了分析产品的使用更狭窄： 负责任地使用

应定义分析产品适当、合法和伦理使用的界限和指南。概述产品设计的具体用例；突出不支持或明确禁止的应用的限制。这应包括遵守数据治理政策、相关的数据保护法律和数据处理和分析的伦理标准。

这一范式强调了用户责任，强调了避免偏见、误解和滥用的重要性。它规定了如何传播信息以及如何保持机密性。它还规定了信息应如何使用，以避免误解，并要求提供每个产品的局限性的信息。关键是确保分析产品负责任、合法和有意义的使用，保护所有相关方的利益。

以下是根据这些范式定义的分析合同的可能元素： 产品描述和用途

概述分析产品、其功能和预期用途

它提供什么类型的分析、报告和数据可视化？

可以实现的增强类型（例如固定规则、高置信度增强）？

可发现性

用户如何找到和访问产品

产品列在中央目录或平台的位置

可寻址性

产品的唯一标识符

元数据，包括版本、发布日期和功能摘要

访问产品的说明，包括任何API端点、仪表板URL等

集成笔记：与其他系统或平台的兼容性

可信和真实

数据质量和准确性标准声明

数据来源和使用方法的描述

透明关于限制、假设和在何种情况下产品表现最佳

自描述语义和语法

详细的使用产品的文档，包括用户指南、常见问题解答和样本分析

术语和指标定义

数据结构、格式和查询方法的解释

互操作性和全球标准

数据集成和标准化指南

遵循的公司范围内的维度和标识符的标准

安全和访问控制

保护数据和见解的安全措施

访问控制机制描述，例如基于角色的访问

支持和维护

用户的支持渠道和资源信息

定期更新和维护计划

报告问题和请求改进的程序

联系渠道

支持请求和问题解决的响应时间

性能和SLA

预期的性能指标和服务可用性

用户责任

用户在伦理使用、数据处理和遵守法律标准方面的责任

违反许可使用条件的后果

建议的见解使用（增强、代理、副驾驶或助手）

披露和共享的限制

生成数据、报告或分析产品见解的共享规则

未经事先授权不得与第三方共享产品或其功能的限制

例子5-4. 一个虚构的客户流失预测器的分析产品合同示例

product_description_and_purpose:
  name: "Predictive Analytics Tool for Customer Churn"
  overview:
      "A predictive analytics tool designed to analyze customer data and predict 
      potential churn.
      Features include churn likelihood scoring, customer segmentation, 
      and churn drivers analysis."	
  features: 
    - "Customer churn prediction"
    - "Predictive modeling"
    - "Customer behavior analysis"
    - "Trend identification"
  intended_use: "To predict potential customer churn and assist in retention 
      strategies"
  augmentation_type: "High-confidence augmentation based on predictive analytics"

findability:
    catalog_location: "http://company-analytics-catalog.com/churn-predictor"
    product_listing_page: "http://intranet.company.com/analytics-tools/
      churn-predictor"

addressability:
  unique_identifier: "churn-predictor-001"
  metadata: 
    version: "1.2.3"
    release_date: "2023-08-01"
    feature_summary: "Advanced churn prediction using AI algorithms"

  access_instructions: 
    api_endpoints: 
      - "http://api.company.com/churn-predictor/v1/predict"
      - "http://api.company.com/churn-predictor/v1/report"
    dashboard_url: "https://analytics.company.com/churn-dashboard"
  integration_notes: "Compatible with CRM and ERP systems via API"

trustworthiness_and_truthfulness:
  data_quality_standard: "ISO 9001:2015 Certified"
  data_sources: 
    - "Customer Relationship Management System"
    - "Customer interaction logs"
    - "Transaction history"
    - "Support tickets"
  method_description: "Uses supervised machine learning algorithms to analyze 
  patterns in customer behavior"
  model_performance_kpis:
     accuracy: "93%"
     precision: "90%"
     recall: "88%"
  performance_constraints: 
    - "Optimal performance in datasets with at least 10,000 customer records"
    - "Requires at least 2 years of historical data for accurate predictions"

semantics_and_syntax:
  documentation: 
    api_interface: "http://docs.company.com/churn-predictor"
    user_guide: "https://docs.company.com/churn-predictor/user-guide"
    faq: "https://docs.company.com/churn-predictor/faq"
    sample_analyses: "https://docs.company.com/churn-predictor/samples"
  terms_and_metrics: 
    - "Churn Probability: Likelihood of a customer leaving within the next month"
    - "Retention Factors: Key factors influencing customer loyalty"
  data_structure_explanation: "Data is by default structured in JSON format with 
  fields for customer ID, transaction details, and interaction metrics"
    data_formats: 
      - "json"
      - "csv"

interoperability:
  data_integration_guidelines: "http://docs.company.com/churn-predictor/integration"
  standards: 
    - "Follows GDPR for data privacy"
    - "Adheres to OpenAPI Specification for API standards"

security_and_access_control:
  security_measures: "Data encryption in transit and at rest"
  access_control: "Role-Based Access Control (RBAC) with SSO Integration"

support_and_maintenance:
  support_channels: 
    email: "support@company.com"
    phone: "+1234567890"
  update_schedule: "Quarterly updates and maintenance"
  issue_reporting_procedure: "http://support.company.com/report-issue/churn-predictor"
  response_time: "Initial response within 24 hours"

performance_and_sla:
  uptime_sla: "99.9% Service Uptime"
  performance_metrics: 
    - response_time: "Under 2 seconds for API requests"

user_responsibilities:
  ethical_use_policy: "Use in accordance with company ethics guidelines"
  data_handling_compliance: "Adhere to GDPR and CCPA standards"
  violation_consequences: "Access revocation and potential legal action"
  limitation: "not allowed for automated processing in agents"
  
restrictions_on_disclosure_and_sharing:
  sharing_rules: "Data and insights generated are for internal use only"
  third_party_sharing_restriction: "No sharing of the product functionalities with 
  external parties without prior authorization"

这只是分析产品合同的一个可能结构示例；最终，这一合同必须适应你自己公司的具体情况和要求。

结论

将增强分析（AA）引入组织核心系统的技术挑战不容小觑。需要深入思考并做好计划。总结我们的三条关键建议：

1. 参与IT决策者的工作以与IT的路线图保持一致。这在处理遗留技术时尤为重要。业务分析师应学会以自动化的思维方式考虑未来工作流程中的功能。
2. 依赖API作为集成增强功能的终端。建立程序化的分析解决方案，以确保组织的未来独立性和供应商的独立性。
3. 通过引入通用规则和承诺来规范工作流程中分析解决方案的使用。

最终，AA更多地涉及软件工程而非分析：建立将分析用例与核心流程结合的基础设施和技术，以有效增强相应的工作流程。分析和业务能力的互动现在扩展到包括IT能力。在这一阶段，软件开发人员和分析工程师的重要性超过了分析师和数据科学家。