抽象
分析“大数据”具有产生业务价值的巨大潜力。近年来，工具和技术的不断进步创造了一个新的生态系统，为数据驱动的创新创造了一个充满机会的新生态系统。但是，随着可用数据量上升到新的高度，复杂性也随之增加。组织面临的挑战是通过塑造界面和流程，以及提出正确的问题来指导数据分析，从而创建正确的上下文。提升创新潜力需要团队合作和专注，以有效地将可用资源分配给最有前途的计划。关于创新过程，本文将集中精力为分析项目建立一个从最初的想法到实现的流程（在大多数情况下：一个正在运行的应用程序）。我们解决的问题是：关于大数据和分析的实践论述可以从创新管理中学到什么？本文中提出的见解建立在我们与各种客户合作的实践经验之上。我们将对分析项目进行分类，并讨论此过程中的常见创新障碍。
介绍
可以理解的是，人们正在花费大量精力来分析“大数据”以释放其潜在的巨大商业价值。新的数据源不断发展，用于存储和分析大型数据集的新技术正在支持许多新的应用程序，但任何一个大数据应用程序的确切业务价值通常不清楚。从实际角度来看，组织仍然难以有意义地使用数据，或者他们缺乏适当的能力。在组织环境中会出现不同类型的分析问题，这取决于起点是来自仅缺乏所需技能或能力的部门的精确请求（例如，机器学习），还是源于处理大数据的主要兴趣（例如，没有自己的基础设施，没有方法的经验）。到目前为止，经常缺少从数据中产生价值的明确策略和流程。
许多文献涉及技术和方法实施、大数据的变革力量、通过构建分析能力来提高公司绩效或其他管理问题。很少有工作涵盖从最初的想法到现成的分析应用程序或构建分析能力的转型过程。本文旨在解决这一差距。
Analytics 计划具有几个独特的功能。首先，它们需要一种探索性的方法——分析不像其他项目那样从具体要求开始，而是从一个想法或数据集开始。为了评估贡献，应用了构思技术和快速原型设计。这种探索在形成共同理解和为大数据计划提供战略方向方面发挥着关键作用。其次，分析项目处于早期阶段，必然会受到不同利益相关者利益、能力和观点之间复杂相互作用的影响。学习是这些项目不可或缺的一部分，以积累分析经验和能力。第三，分析项目与现有的信息技术 （IT） 基础设施并行运行，并提供简短的脚本或战略见解，然后将其安装在更大的 IT 项目中。由于缺少端到端目标，不仅需要提取、转换和加载数据，还需要对数据进行识别、分类和部分结构化。因此，需要建立一个价值生成的一般流程来指导分析项目并解决这些问题。
在这里，我们提出了一个确切的配置和一系列步骤来指导大数据分析项目。大数据分析项目（与传统分析项目相比）缺乏明确的要求和明确的项目目标，这使得构建分析过程变得具有挑战性。因此，线性创新过程可以作为参考和方向。正如 Braganza 及其同事 （2017） 所描述的那样，要在组织中成功集成和实施大数据，需要清晰且可重复的流程。然而，每个分析计划都是不同的，流程需要灵活。遗憾的是，文献很少将分析过程中的挑战与创新管理的概念结合起来。尽管如此，创新管理概念的整合可以指导制定数字战略、分析单元及其功能的组织锚定、设计分析组合以及基本工作原则（例如，快速原型设计、构思技术）等分析工作。
因此，在本文中，我们将集中讨论在组织中实施大数据的实践话语和分析工作可以从创新管理中学到什么。引入了分析创新流程，以指导从构思到价值生成的流程。重点放在这一过程中的挑战以及不同的切入点上。因此，我们以不同行业和领域的大量分析项目的经验和见解为基础，为成功实施分析解决方案提供建议。
我们首先从大数据和分析的定义开始。接下来，我们提出了一个结构化方法从数据中检索价值的过程。最后，我们讨论了结果并概述了未来研究的方向。
大数据和分析
在本节中，我们将讨论应该从基本角度来看待分析价值链（图 1）：数据、基础设施和分析 – 以及作为驱动因素的业务需求。根据我们的理解，价值是通过在特定上下文中分析数据而产生的，与业务需求相关的问题陈述推动了创新的需求。除了执行数据和分析项目的专业知识外，此过程还需要有效的基础设施，尤其是当要分析的数据量、速度或种类超过一定限制时。下面，我们将更详细地描述这三个技术角度。
图 1.数据、基础设施、分析和业务需求框架
数据
大数据通常由数据量（数据量）、速度（数据生成速度）和多样性来定义，因为数据类型的多样性。大数据描述了难以使用传统数据管理技术处理的规模的数据收集。虽然大数据的许多定义都集中在数量方面，指的是可用数据的规模，但大数据特别带来了异构格式和广泛的可能数据源。示例包括结构化数值数据或非结构化数据，例如文本、图像或视频。这种数据源的多样性和广泛性为生成见解提供了许多机会。此外，数据创建的速度可以快速洞察正在进行的发展。
最近的技术改进（例如，云计算、大数据架构）使数据能够被大规模分析和存储。对于许多（新）类型的数据，它们的确切商业价值目前尚不清楚，需要系统探索。可用数据通常是杂乱的，即使经过清理也可能让人不知所措，而且太复杂，即使专业数据科学家也不容易理解。当然，数据的贡献是特定于上下文的，并且因业务案例和应用程序而异。一个关键挑战是确定最符合业务需求的数据。
分析学
数据科学关注从数据中生成知识。分析或数据科学涉及使用不同定量方法对数据集的探索，这些方法的动机来自统计建模（James et al.， 2015）或机器学习（Mitchell，1997）。来自不同学科（如统计学、经济学或计算机科学）的方法可用于识别模式、影响因素或依赖关系。与商业智能相比，分析比描述性分析（基于 SQL）更广泛，并且通常具有预测组件。应用哪种方法取决于确切的商业案例。例如，分析数据受到公司内部政策以及不同国家/地区的法律限制和准则的限制。数据质量和可靠性是进一步的问题。数据理解和领域知识是分析过程中的关键先决条件（例如，Waller & Fawcett，2013），尤其是在做出模型假设时。
关于数据分析，组织主要有以下机会：
- 改进内部数据分析：一个例子是通过额外的数字来增强基于专家的规划方法的预测方法。这些方法建立在现有数据库（如商业智能系统）之上，它们为内部公司流程提供了新的或进一步的见解。
- 数据集的新组合提供了新的见解，例如，通过传感器数据和用户配置文件的组合。
- 开放新的或（到目前为止）未使用的数据源（例如，网站、开放数据），以确定产生新见解的潜力。但是，使用数据需要上下文或应用程序。一个例子是用于市场观察的社交媒体数据。
但是，分析的核心问题是找出指导性问题，并在业务需求、数据源和分析之间实现匹配，如本文后面所述。
IT 基础设施
与成功实施分析相关的是 IT 基础架构的调整，以嵌入分析解决方案并集成不同的数据源。IT 基础架构的核心层如下：
- 数据摄取层：此层涵盖从源系统到分析环境的数据传输。因此，需要定义工具集和相应的流程。传统的提取、转换、加载 （ETL） 工具和关系数据库与 Hadoop/大数据设置相结合，特别是涵盖由结构较低、高容量或流数据引起的场景。分析使用案例基于从数据仓库到完全非结构化数据的数据。这种广度对经典架构提出了挑战，需要适应性强的方案。要集成的数据源取决于特定的应用程序。
- 数据价值探查层：根据业务需求和相应的使用案例，在该层对数据进行调查、测试和采样。根据复杂性和业务问题，开发适当的分析方案。通过使用高级分析方法和集成（例如 R 或 Python 插件），对基于内存技术中的在线分析处理 （OLAP） 模型的业务和探索性分析进行了补充或扩展。
- 数据消费层：例如，在这里，结果用于可视化。最终用户可以在没有深入技术理解的情况下使用数据或服务（例如，用于自助式商业智能）。
现代方法需要能够适应和扩展不同需求和数据源的结构。必须考虑系统性能、成本效率和整体企业基础设施战略等因素。
从数据到价值：将创意转化为应用
组织仍然难以有意义地使用数据或缺乏适当的能力。分析项目中的主要挑战之一是确定业务需求和指导性问题。原则上，在组织环境中会出现不同类型的分析问题，从仅缺乏特定能力的精确请求到处理大数据的主要兴趣（例如，没有自己的基础设施、基于专家的方法）。这种方法意味着分析过程的不同起点和不同的创新途径，这两者都将在本文后面介绍。
起点是什么？
每个分析计划的起点各不相同。根据上面提到的四点，需要单独评估每个点的 “最新技术” 以估计分析成熟度：
- 业务需求：问题描述和范围的精度因案例而异。在某些情况下，指导分析阶段的主要问题和范围是非常精确地制定的，而对于其他情况，则需要在此过程中制定和完善。
- 数据：可以定义要在项目中使用的数据，或者尚不清楚适当的来源。数据的大小和质量基本上决定了进一步过程的进度。参数包括结构（即预处理工作）或数据集的大小（例如，一个 CSV 文件或一个大型数据库）。
- 分析：应用哪些方法因情况而异，必须进行测试和探索。
- 基础设施：业务部门的当前（技术）状态（例如，自己的数据仓库、报告系统）或自己的（人力）资源和能力是分类请求的另一个重要方面。
这四个角度可以根据分析请求的成熟度级别进行不同的评级。根据我们的经验，可以区分代表不同成熟度级别的三种情景（图 2）：
- 在场景 1 中，数据分析是由定义的要求驱动的，例如在新产品推出期间进行市场观察。需要确定适当的数据源。到目前为止，数据缺失意味着无法定义精确的分析，并且没有现有的基础设施。需要就哪些数据源可能是相关的以及哪些问题可以在此基础上解决来形成想法。然后，应用数据分析的不同方法来生成新的见解。
- 在场景 2 中，明确定义了数据源和基础设施，并且需要确定具体问题。一个应用程序正在评估迄今为止尚未进行专业分析的特定数据源的贡献，例如，通过机器学习。例如，该业务部门有一个内部数据库，正在考虑新方法，并希望通过添加预测组件来进一步开发商业智能系统。在这种情况下，范围比第一种情况更清晰，并且可以立即开始探索性数据分析。
- 在场景 3 中，有一个精确的分析问题需要专业化。初稿显示了有希望的结果，下一步，该解决方案可以被放大。在做出架构决策时需要指导。
分析过程
要成功进行分析，必须构建从数据到价值的流程，以便集成到现有组织中。例如，Braganza 及其同事 （2017） 研究了大数据计划中的组织资源管理。他们强调了系统化方法和流程对大数据实施的重要性。
分析过程的相关工作侧重于服务设计（Meierhofer & Meier，2017）或专注于分析数据的方法部分（例如，Cielen & Meysman，2016）。正如 Braganza 及其同事 （2017） 介绍的那样，该过程过于线性，没有解决数据分析和必要的利益相关者话语的系统复杂性。为了解决这些问题，构建分析过程可以与经典的线性创新过程联系起来。
在我们的工作中，为了指导从构思、范围界定和识别数据集到价值生成的分析过程，引入了一个包含四个阶段的流程。以经典的创新漏斗为起点，这个概念被转移到分析的上下文中。该过程分为四个部分：i） 想法的产生，ii） 进行概念验证 （PoC） 以测试这些想法，iii） 实施和测试成功的 PoC，最后，iv） 它们作为产品或服务提供。根据第一个想法或要求，初始化流程，同时减少每个阶段中的想法或项目的数量。每个阶段都有任务以及需要传递的障碍或过滤器，以便在流程链中继续。
上述三种情景的成熟度评估方式不同，如图 3 所示。情景 1 处于想法产生的早期阶段，需要解决许多悬而未决的问题。方案 2 比方案 1 更具体，解决的问题也更多。但是，在进行 PoC 之前，需要制定启动问题。方案 3 建立在正在运行的系统之上，因此它位于测试和操作化阶段（阶段 3）。
对于每个阶段，都会出现不同的挑战。虽然相关工作强调与数据相关的挑战，例如数据采集、清理或聚合，但这项工作侧重于过程挑战。
第 1 阶段：创意生成
定位分析项目从构思阶段开始。在这里，关键的挑战是收集想法并讨论相关的商业问题（也见Provost & Fawcett，2013）。在形成共识、挑战现有假设、确定大数据计划的方向以及确定可以通过分析解决的方面方面，想法生成起着关键作用。例如，设计思维被用作系统化的问题解决方法（Liedtka & Ogilvie，2011）并支持结构化的构思过程。收集业务部门的问题并将其与分析范围（例如，技术可行性、输入参数和方法要求）相匹配。构思阶段是迭代的。最初，总体项目目标指导第一轮构思，旨在了解业务部门当前面临的挑战和需求。这与确定适当的数据集是一致的。然后，必须由专家检查想法的可行性，然后选择这些想法进行原型设计。
从组织的角度来看，所有层次结构级别的决策者都必须参与。需要最高管理层解决利益冲突并营造紧迫感，需要中层管理人员将专家从日常工作中解放出来，让利益相关者进入他们的特定角色，而运营专家的专业知识是详细说明指导问题和检查可行性的关键。
绘制一个投资组合以选择在 PoC 阶段考虑的想法。创新投资组合为判断想法的可能影响提供了一个连贯的基础（Tidd & Bessant，2013）。它们将想法划分为多个区域，并指出要优先考虑哪些想法。对于图 4 所示的示例案例，根据三个类别对想法进行评级和评估：可行性（x 轴）、价值创造（y 轴）和整体相关性（节点的大小）。可行性包含数据可用性、访问数据的时间或任务的预期复杂性等方面。价值创造解决了预期的商业价值，并强调了具有高预期贡献的想法。总体相关性用于强调哪些想法预计会对手头的问题产生更大的影响。因此，例如，想法 3 的预期可行性很高，但创造的价值预期会很低。相比之下，想法 4 和想法 8 对价值创造的期望更高，因此应该在下一阶段优先考虑。
除了基于投资组合的选择过程外，在第一阶段还会过滤想法，例如，由于没有可用的数据来解决问题，必须首先提出数据（例如，实施额外的传感器），否则将拒绝访问（例如，内部政策、法律限制）。因此，需要确定适当的数据源并授予访问权限，以便对业务需求和数据适用性进行可靠而有效的评估。
作为组织障碍，需要确定合适的专家并将其从日常工作中解放出来，以便他们可以用于分析项目。在构思过程中，创造力和专注力之间的适当平衡很重要，弥合不同知识领域之间的差距以提出正确的问题也很重要。
第一阶段的结果是想法加上可以检查问题的数据源;需要对问题或想法和数据源进行映射。在第一阶段，需要强大的促进者来指导整个过程。此外，具有系统专业知识的人来检查所考虑的想法的技术可行性以及商业理解也很重要。想法和数据只是被讨论的;不进行检查。这将在下一步中完成。
在这个早期阶段需要澄清的另一个问题是数据安全和数据保护。每个国家/地区都有限制分析的单独法规。
第 2 阶段：概念验证
为了测试这些想法，构建了原型并进行了 PoC。PoC 是对数据集的第一次检查，以查看是否可以根据可用数据回答提出的问题。
图 5 描述了这个阶段：根据上一阶段定义的范围，必须授予对数据的访问权限，对数据进行探索和分析，最后传达结果。
如上所述，此阶段从项目目标或问题描述 （业务需求） 开始。传统的 IT 开发从需求开始，而分析通常以探索性方式从数据集和假设开始。在分析过程中会产生特定要求。因此，PoC 阶段只能从数据开始，或者当数据可用时开始。从现有系统获取数据或检索数据是 PoC 的第一步。在这里，需要检查法律问题或组织限制等访问障碍。因此，例如，根据数据类型（例如个人数据、机器数据、市场数据），分析应符合这些限制。
接下来，对数据进行探索以更深入地了解。在这里，数据被转换为合适的格式以供进一步分析。此步骤包括数据准备和清理，并执行第一个描述性分析。
然后在建模阶段分析数据的模式和依赖关系，以回答提出的问题。测试了不同的方法和算法，并在变量选择、模型选择、模型适应和验证的迭代过程中验证了结果。
最后，将结果传达出去。PoC 对数据中的潜力给出了第一个方向，重点是优势和劣势。可能的结果是不同的建模技术无法提供有效的结果，数据质量不允许建模，或者没有足够的数据来做出重要的陈述。这最终是规划和沟通后续步骤以及协调进一步行动的基础。
关于结果的呈现，可以使用 Tableau、QlikView 或不同的开源平台等工具应用不同的可视化技术。特别是为了加深对数据的理解，描述性数据分析很有帮助。然而，来自高级分析的许多模型和技术提供的数字无法通过直观的可视化来捕获。
PoC 的持续时间很短，可能为 6-8 周。除了访问必要的数据或从相关来源提取数据外，此阶段的主要挑战还包括数据质量、数据所有权和数据理解。进一步的障碍是将数据清理和修改为可以处理的格式，并应用正确的模型。此外，业务理解是从数据中检索有价值的见解并实现不仅合理而且与业务相关的结果的关键。另一个问题是缺乏分析经验和实施结果所需的敏捷性。
阶段3和4：运营化
然后，PoC 结果被集成到专业的 IT 基础设施中。需要为原型结果的操作化做好准备，并将其转换为应用程序。要回答的主要问题是：模型是否可扩展，迄今为止获得的结果是否可以应用于更大的数据集？必须进行调整，以便 IT 服务组织可以在没有数据科学家持续支持的情况下维护生成的应用程序。必须建立基于事件或时间的数据流，并且与最终应用程序一起，需要与合规性、安全性和数据隐私要求保持一致。需要就事件处理和应用程序更改的测试管理和服务级别协议以及产品和产品组合管理功能达成一致，以防工具或应用程序旨在承担战略性的长期角色。
障碍包括所需的预算、过于复杂的测试、标准和合规性等。总之，IT 管理中的集成和将任务分配给 IT 部门代表了另一个问题。这与从敏捷、迭代的工作模型切换到稳定的操作以及扩展分析模型并将其转换为可维护的代码有关。
一般来说，将 PoC 原型转变为专业的基础设施需要付出巨大的努力。操作过程中的其他障碍包括，例如，建立支持和服务管理功能、获得用户群的接受、开发适当的培训概念以及转移维护、测试和开发应用程序所需的知识。
讨论和结论
一般来说，组织面临的挑战在于从大量可用数据集中定义价值生成策略。在本文中，我们讨论了如何从数据中检索价值，并介绍了分析项目遵循的系统流程。首先，我们描述了价值创造的基本构建块：业务需求、数据、基础设施和分析。然后，我们描述了从构思到上市应用程序的过程。根据项目的成熟度状态，可以在不同的阶段进入流程。描述了这个过程的四个阶段，并强调了具体的障碍。该模型面向分析过程的阶段关卡模型 （Cooper， 1990），旨在构建和系统化探索性分析方法。
分析和大数据不仅是一项技术挑战，而且会影响整个组织及其流程。为了在分析方面取得成功，应该减少在构建复杂和精密模型上花费的精力，而应该将结果集成到现有的（技术）基础设施和流程中。对于正在专业化的原型，必须接受和理解结果，并且业务部门应持续参与该过程。此外，正确的人员和技能是必要的：不仅需要具有机器学习和统计建模能力的数据科学家，还需要 IT 专家和一般的业务理解。此外，只有当分析集成到技能和能力的整体框架中，并且分析计划嵌入到业务应用程序中时，数据才会产生价值。
在构建分析功能时，本文的结果可以转移到不同规模和经验水平的组织。本工作中描述的过程将指导整个分析项目，并说明与已知 IT 管理方法的差异。通过主要讨论创新对分析的意义，这项工作有助于不断发展的数字创新管理文献（Nambisan et al.， 2017）。在我们的工作中，我们概述了一种数据驱动创新的方法。
未来的工作应该检查组织分析的决策。这包括角色和职责、团队结构、领导分析团队或组织中分析单元的组织嵌入等方面。这项工作的结果应与对分析能力的广泛研究联系起来，这些研究通常根据管理、技术和人类能力的维度进行分类（Akter 等人，2016 年;Mikalef et al.， 2017）。正如本工作中介绍的那样，在整个过程中，对分析的理解变得更加清晰。因此，应该检查它对组织学习、技能发展、发展共识和构建分析能力的贡献。例如，根据 Davenport 和 Harris （2007） 的说法，这个分析学习过程大约需要 18-36 个月。从技术角度来看，特别是将分析解决方案集成到整个 IT 环境中，原型的专业化和已建立流程的更改仍然具有挑战性。
