3.4　什么样的分析团队组织架构设计最好

管理咨询巨头普华永道在其2014年发表的“战略+商业”调查中发现，42%的企业高管认为他们的组织架构与其战略目标不一致，有些部门不理解自己企业的组织架构，甚至加以抵制。在题为“组织设计的10个指导原则”（Neilson，2015）的文章中，普华永道概述了组织设计中应考虑的八大基本要素，总结在表3-1中。

正如前文所说，对一个组织来说，并没有一个唯一正确的或者一成不变的组织架构设计方案，今天合适的组织架构可能会随着时间的推移而发生变化，因为技术、客户体验和角色都一直在发生着转变。在工作中，我发现有三种常见的组织设计占据主导地位。对于任何希望承诺具备分析能力的组织来说，我建议了一个能力清单。你将注意到，在任何分析团队组织所需要具备的能力中，分析的客户体验以及对分析产品或结果的管理，都处于核心位置。

表3-1　普华永道关于组织架构设计应考虑的八大要素

3.4.1　集中式架构

当需要集中管理企业范围的数据和分析需求时，我们会选择集中式的分析组织架构模式，这既有助于衡量ROI，也可以根据所有员工的技能更合理地分配项目。

图3-7是一种典型的集中式分析组织架构示意图。一些总监或AVP（Associate Vice President）向管理层中的某人汇报，比如可能是首席分析官（Chief Analytics Officer），或者双向汇报到公司不同的高级领导（CXO级别）。

分析部门统一接收大量的分析请求，并按照所需的服务条线进行分类。通过这种方式，可以向特定的业务部门以及面向整个公司层面的需求提供服务。

这样的分析组织架构模式可确保与数据治理职能的健康关系。虽然这里没有一个正式的数据治理部门，但这种集中式分析组织架构至少可以共享汇报关系。

图3-7　数据分析团队的集中式组织架构

3.4.1.1　集中式架构的优点

集中管理与配置所有分析人员，使得他们可以相互学习，并消除孤岛和彼此之间的隔离。这将对分析团队员工的参与意识产生很大的派生影响，同时也让管理层能够确保分析团队的工作与企业战略目标紧密关联。

支持该架构的人已经注意到，它有助于防止分析团队开展重复的或者非常类似的工作。花在数据管理方面的时间大大缩短，因为分析师团队共享所有的业务定义，数据在分析工作开始之前就已经协调一致并准备就绪。整体流程非常清晰规范，服务水平协议会以书面的形式写进文档，以确保所有部门都了解他们与分析团队的工作关系，以及可以期望分析团队做哪些工作。

集中管理使公司领导能够在分析师的工具、培训和职业发展等方面进行一致性的整体规划。据报道，这会对员工士气产生有利影响。

最后，集中管理的另一个优势是：如果你面临大量新领域的数据（例如物联网、边缘分析、移动通信等），组织可以就如何处理这些新的数据资源，在数据管理和分析方面进行统一的战略规划。

3.4.1.2　集中式架构的缺点

虽然集中方式对某些组织来说效果很好，但并不适合所有企业。最大的挑战之一可能是一个组织的文化和历史。将几乎所有分析师抽调出来集中管理，可能被视为剥夺部门或下属机构的控制与自治权。从整个组织的视角来看，这常常是一项不可能完成的任务。

与此同时，分析师必须与各部门保持深入联系，以便充分了解他们的需求，特别是当分析任务与部门战略目标紧密相关的时候。

因此，这是一个关于沟通的问题，像卡罗来纳州健康系统这样的组织，就明确要求它的分析师花大约20%的时间直接与业务部门在一起工作。

我认为最大的经验教训是，在创建现在这个新的集中架构之前，整个组织中的分析师一直以一种相互隔离的方式工作，但现在我们已经致力于在整个企业范围内整合分析资源，更加有效地开展工作。以整体的视角来看待分析项目并聚焦于努力的成果是非常关键的。

——Carolinas HealthCare System高级分析部门副总裁

另一个潜在的问题是，由于高层领导可以直接获得分析师资源，他们的分析需求可能会压制部门的分析需求。高层领导下达“立即做这种分析”这样的指令，对分析团队的正常工作常常是一种干扰，达不到最佳效果，我在过去服务过的组织中就看到过这种情况。

集中管理分析团队常常被打上压制创新的烙印，因为人们不能总是事先计划探索所需要的各种资源。有些部门拥有资源丰富且实力强大的研究团队，对这些部门来说，进行分析项目集中管理尤其是一项艰巨的挑战。如果这类部门已经习惯于与业务部门内的分析师建立牢固的关系，并且这也确实有助于部门的研究工作，那么把分析团队进行集中化管理的计划，就会面临政治和习惯势力的阻力。

3.4.2　分散式架构

现在我们来讨论分散式分析团队架构（见图3-8），以及适合使用这种架构的组织。

图3-8　数据分析团队的分散式组织架构

这个分析师团队组织架构示意图，是从那些我亲自参与过的采用分散式架构的组织中抽象出来的。这些组织的相通之处在于，每个业务部门都有自己的分析团队，他们从一个共享的、部门之外的资源库来获取分析所需要的数据。如前所述，这个外部的资源库可能是一个数据仓库或者数据湖。由于从各源系统加载进来的数据量过大，可能没有足够的时间按照范式的企业级数据模型进行加工和存储。

IT部门会把数据进行适当的转换以适应分析师的需要，这项工作一般都会在数据治理的规范下完成。当然，会采取一种轻量级的数据治理标准，以确保各业务部门仍能保留使用他们自己业务定义的能力。

分析结果将根据每个业务群组的授权分发。换言之，有些分析结果可以在整个组织内共享，在研究案例与报告中发布，有些则只能在内部业务部门中使用。

这种架构的优势在于，分析职能与业务部门紧密联系在一起，各部门对自己的业务定义和分析风格具有一定的自主权。因此，许多具有强大研究力量的大型组织都选择了这种架构。通常，对那些在分析领域具有悠久和丰富历史的企业，集中式架构不仅在政策上行不通，也不是大家所期待的。

3.4.2.1　分散式架构的优点

分散式架构的好处之一是具有最大的灵活性，非常适合那些复杂的大型组织。分析师的工作与业务部门深度融合，他们对业务和流程非常了解，这些知识对问题的设计和分析结果的解释都非常有帮助。

另一个好处是，每个部门或分支机构都可以自由选择他们想要用来分析数据的任何工具，而不受公司政策的束缚。类似地，这些业务部门还可以定义自己的分析方法。有些部门可能有完全不同的分析理念和分析逻辑，这取决于他们所处领域的行业标准。

分散式架构的一个显著特点是，以鼓励大量创新而广为人知。事实上，有几个大型企业（比如在医疗保健行业的企业），已经发展出独立的数据分析衍生机构，其业务是以数据治理、分析、咨询服务等方式，把它们的分析模型或分析方法论销售给其他企业的分析部门。

3.4.2.2　分散式架构的缺点

分散式架构模式并非没有缺点和挑战，它并不是适合所有组织的最佳分析团队组织架构。它最适合那些在企业级数据仓库建立之前，就已经具有很长的数据收集和数据分析历史的组织。

在分散式架构模式下，归属于不同业务部门的分析师，不会像他们在集中管理架构那样频繁地相互沟通。这可能会导致一些在业务领域发展出来的知识，形成部门自己的知识部落，而这并不涵盖在企业整体范围的知识管理战略中。

因此，在分散式架构模式下的变更管理可能会成为一个巨大的障碍。也就是说，如果上游数据中的某些基本内容发生变化，如何顺畅地与所有分析小组沟通这种变化？这会变得非常困难。在分散式架构中，总有可能存在少数分析师没有察觉到或者意识到这种变化。

没有自上而下的管理，可能会遇到这样一些问题，即分散的分析师们在不同的孤岛中进行非常类似的分析工作。这不仅造成资源的重复和浪费，还会由于不同的数据假设前提，造成分析报告的不一致。这些不一致的分析报告以不同途径传递到管理层后，只会增加决策和管理上的混乱。

没有分析团队的集中管理，针对分析团队的培训、工具使用和分析流程等，可能会各自为政，无法统一。有些分析师可能会有合理、清晰的职业规划，有些则没有。

在分散式架构模式下，你也可能会遇到工具膨胀（tool bloat）问题，即企业在采购分析工具的时候没有统一规划，没有基于企业已有的分析工具来考虑更好的工具采购方案。

如果领导层一开始就能意识到分散式分析团队架构存在的这些问题，那么风险还是可控的。但是，在那些急需数据和更多分析人员的企业环境下，如果选择采取分散式架构，所有上述问题极有可能发生。

3.4.3　卓越中心式架构

最后介绍一下组建分析团队的卓越中心架构（Center Of Excellence，COE）模式，它是前述两种架构的混合（见图3-9）。许多组织正在转向这种分析团队架构，因为他们意识到，随着有分析需求的业务用户数量不断增多，需要在数据管理、分析工具和流程中保持更多的一致性。

同前面一样，这是一个抽象出来的架构示意图。分析团队的卓越中心式架构，在组织内为分析团队构建了一个集中的职能，而大多数分析师仍保留在各业务部门。卓越中心通常由一位资深领导来管理，他拥有深入的行业知识、强大的IT理解能力和全局视角看问题的能力。COE架构在数据治理，以及对数据仓库和企业级商业智能团队的共同监控和管理等方面发挥着至关重要的作用。COE通常是一个小规模的企业级分析团队。

COE的主要工作之一，是对培训、工具使用和知识管理等流程制定明确的规范。COE明确定义整个组织内所有分析师应遵循的最佳实践。BI和分析的COE同事，可以制定规则来对分析报告的外观和感觉进行标准化管理，甚至可以作为顾问，有选择性地参与到业务部门内分析人员的项目中一起工作。

图3-9　数据分析团队的卓越中心式组织架构

3.4.3.1　COE架构的优点

这种架构的优点在于创建了一个分析社区，即使分析人员散落在不同的地理位置，它也可以通过分析社区在组织内为所有分析师建立一个集中的“家”。

这种架构还允许各部门的分析团队保持一定的自主权，同时他们能实现资源的融合、最佳实践的交流、培训和工具使用的一致和统一，但各部门的预算仍是彼此独立的。

成功建立COE的那些组织，都拥有出色的知识管理体系和方法论，使得各种分析团队提供的有关业务的数据和分析成果在组织内可供所有人使用。

采用COE架构的组织应该通过内部的协同和努力，建立一组指导计划，并确保分析师参加这些计划是个人所期望的工作成果之一。通过这些努力，虽然分析师在地理上散布各处，但分析师社群会不断发展壮大。

3.4.3.2　COE架构的缺点

与前面讨论的其他架构一样，COE并非没有缺点和挑战。

在COE架构下，当企业级分析与部门内分析发生冲突时，可能会出现角色的混淆，特别是当涉及使用共享资源时（如需要使用同样的分析师资源）。如何对项目进行优先级排序或安排执行计划，可能会存在分歧。这种情况下，借助与部门事先约定的服务水平协议会对解决问题有所帮助。当然，这也意味着必须通过领导的参与和努力来协商、起草并定期更新这些协议。

COE架构并没有解决分散式架构下出现的分析工具膨胀问题。换言之，当每个部门都选择购买自己的分析工具时，整个组织可能会失去批量采购工具时的优势。

COE架构相对较新，可能会出现许多的内部相互角力，这取决于企业文化，因为一定程度的集中化管理是很有必要的。COE架构要求必须建立强有力的领导力，以确保最佳实践不仅仅是规范，而是能够落地执行。

3.4.4　分析的组织方式

正如你将在本书中看到的那样，我的一些个人偏见，在一定程度上影响了我对分析成功真正所需要东西的看法。具体而言，我认为客户体验应该在我们如何设计分析组织架构以及提供分析产品和服务所需能力方面占据重要位置。

如果我们围绕（分析）客户的发展旅程来设计分析组织架构，你会注意到这会改变人们对我们所做分析工作的看法，包括分析的目的和任务，这是事关战略的关键组成部分。不幸的是，我们过去一直是根据我们如何看待数据和系统来使我们的分析活动和整个组织的要求保持协调和一致，而不是根据客户如何思考他们面临的问题来设计分析任务。举例来说，尽管CIO可以围绕数据管理、商业智能、数据治理和安全等技术进行组织的设计，但由于彼此分离的职能通常不了解潜在的问题到底是什么，客户体验可能会受到损害。有时，一件被看作“数据问题”的事情，实际上可能与安全、客户端工具或技术、数据治理体系或一般系统性故障相关。

把一个问题交给你的BI团队去解决，他们提供的解决方案可能只是一份分析报告。在我看来，最好能够围绕客户旅程进行分析组织设计，并使得分析组织架构（团队、部门、分部、项目组等）将重点聚焦于客户进行设计，同时，设置一个“统筹管理人（hub person）”负责各分析团队的协调一致。在现代医疗体系中，采用类似的方法来跨越不同科室的分隔，从而促进病人关怀，确保以患者为中心的体验。在分析领域，所谓的“分析管家（analytics concierge）”承担类似的角色，由他先对问题进行理解、勾画并排定优先级，然后与相关领域专家协商可能的解决办法。这种方式可以很好地归入到本书介绍的最佳实践领域中去。

分析管家远不只是传统的业务分析人员，而是需要对业务、运营策略、可视化方法、问题解决技巧、内部业务系统和相关数据，以及分析可能性具有非常广泛了解的那个人。

分析团队还可以根据需要引入分析、技术或其他资源，帮助客户了解其遇到的挑战，对问题进行分类，并一直跟进到最终结果。这种模式如图3-10和图3-11所示。

图3-10　分析管家模型

图3-11　分析管家模型中的人员配置