Prescriptive analytics就是自动化您的业务。当我们在指南中探讨规范分析的复杂性时，这是一线希望。虽然很多复杂性是业务线和专家数据科学家必须处理的事情，但IT也不是不合时宜的。

规范分析很难，并且没有银弹可以让你在没有经历进化分析链的情况下实现目标。您必须正确地获取数据收集和存储基础架构，正确的数据建模以及状态分类和预测权限。

这是规范性分析的底线，IT必须确保数据收集和存储基础架构部件适用于业务和数据科学部门。成功使用规范分析所需的数据清理和组织可以从两个方面考虑：将用于提供分析的数据的数量和质量。

数据量

首先，IT需要确保所有与组织相关的数据都被考虑和访问。这确实是任何分析工作的必要条件，但它可能比听起来更复杂。

考虑组织可能正在使用的所有应用程序：定制，现成，现场，云，遗留。每个都可能有自己的格式，存储和API。IT需要确保它们都可访问，而不会中断应用程序的运行。甲数据湖的方法可以是在这方面是有用的。

它变得更糟。数据也可以超越应用程序。例如，考虑所有内部文档和电子邮件。通常，大量数据以非结构化格式和未记录的来源存在。许多应用程序也没有文档记录，无法访问，缺少导出数据的API。对于那些人，你必须要么足智多谋，要么快速失败。

然而，即使你成功了，这也不是一次性的练习。应用程序不断发展，并与他们一起发展他们的数据。API更改，模式更改，添加新数据。新的应用程序会被混合使用，旧的应用程序会被弃用。掌握数据收集需要不断努力，这是您在开始规范分析之旅时需要考虑的成本。向数据湖添加语义可能会有所帮助。

说到成本：当然，通常的IT供应话语也适用于此。您是否提前计划，将此项目作为具有预先确定的基础设施和人员成本预算的项目，并通过组织预算审批流程实现?或者你采取更灵活，按需付费的方式?

前者在理论上更安全，更符合组织流程。问题在于：除非您的数据来源相对有限且易于理解，并且您在跟踪和配置它们方面非常彻底，否则这种方法在实践中可能是不可能的。

后者更灵活，但也可能导致预算超支和影子IT问题。如果没有某种疯狂的方法，你最终可能无法控制，并且将数据存储在各处。虽然这不是100%严格的规则，但预算编制方法在使用本地存储时更有意义，而云存储和开发非常 适合按需付费方式。

最后，数据新鲜度是需要考虑的另一个考虑因素。如果您希望您的分析能够实时反映现实世界，那么提供它的数据也应该是实时的。这意味着您应该考虑流式数据基础架构。虽然采用流媒体有好处，但它是一种新的范例，伴随着自己的学习曲线和软件/硬件/人员投资。

数据