168大数据

标题: 《企业大数据系统构建实战：技术、架构、实施与应用》一大数据组织架构体系 [打印本页]

---

作者: 168主编    时间: 2018-12-16 09:22
标题: 《企业大数据系统构建实战：技术、架构、实施与应用》一大数据组织架构体系

本节书摘来自华章计算机《企业大数据系统构建实战：技术、架构、实施与应用》一书中的第2章，第2.1节，作者 吕兆星 郑传峰 宋天龙 杨晓鹏，更多章节内容可以访问“华章计算机”公众号查看。

第2章企业大数据职能规划

第1章我们介绍了企业大数据在宏观和微观层面的定位，立足于解答企业大数据的商业模式、市场机会、延伸价值、内部功能定义等问题。当企业已经确定要实施大数据战略时，应该如何针对性地建立职能架构体系以保证企业大数据的有效实施和落地？各个职能部门的职责范畴如何定义？不同体系和部门间如何协同和流程化工作？

本章将详细讲解企业大数据职能规划体系，包括如何定义大数据部门在企业中的角色，常见的大数据职能及职责分工，不同职位的职责划分以及大数据制度和流程建设等问题。

2.1　大数据组织架构体系

要建立适合企业的大数据组织架构，首先要明确大数据部门在企业中的角色。不同的角色对应到企业内部会有不同的架构方式和职能定位。

2.1.1　大数据部门在企业中的角色

大数据部门泛指大数据中心、大数据部门、大数据组甚至是个体员工，它代表一类群体的角色扮演。按照大数据部门在企业中的不同角色和存在特征，可比喻为以下四类：路人、侍从、灯塔、先知。

1.路人

路人是指大数据部门处于企业边缘，其存在属于可有可无的境况，这是一种危险的企业处境。

目前很多企业的大数据部门都处于这类角色中，其实质是由于企业主观上对数据不敏感、不听、不信以及缺乏数据工作文化等原因，以及客观上缺乏有效的流程和制度约束、有经验的数据工作人员以及有价值的数据产出，导致大数据部门的存在与否无关紧要。

这类角色通常在企业中有以下几种行为和职能特征：

• 数据部门的职能定位不清晰，发展规划不明确，部门建设毫无方法可言；
• 缺乏有效的数据工作目标和数据价值产出；
• 数据工作从未参与企业运营落地环节，更无法渗透到企业核心业务流程；
• 数据部门缺乏“大领导”，无法直接跟企业C-Level的领导层进行汇报；
• 数据部门通常都是由个人或少数员工从事，甚至由运营人员兼任。
  

对于大数据部门是否处于这种状态，通常只需回答一个问题：“如果没有大数据部门，企业会损失什么？”如果无法准确回答或含糊其辞，那么这个答案就是肯定的。

2.侍从

侍从，即随从侍奉，这体现了大数据部门角色定位于企业辅助层面。侍从的角色相对于路人有明显的提升，该角色已经处于有明确工作需求的状态；但与此同时，大数据部门的这种状态也存在明显的问题：缺乏独立和自主性，侍从从来都不会自己决定去做什么，而是等待被分配工作和任务。同样，在企业中的大数据部门也无法决定企业在业务层面应该做什么、怎么做等问题。这种角色通常提供的职能包括如下几个方面：

（1）数据管理

数据管理工作包括：数据配置管理、数据权限管理、用户权限管理、数据导入管理、数据导出管理。

• 数据配置管理：主要进行数据存储、安全、排除设置、并发控制、进程控制、结构控制等管理工作。
• 数据权限管理：主要进行数据保存、新增、删除、更新、备份、合并、拆分、导出、打印等管理工作。
• 用户权限管理：主要进行用户新增、删除、重置、过期设置、共享、安全等管理工作。
• 数据导入管理：主要进行数据导入格式、时间、条件、规则、异常处理、记录数、来源等管理工作。
• 数据导出管理：主要进行数据导出格式、时间、条件、规则、记录数、加密、位置等管理工作。
  

（2）数据查询

很多企业的数据都在IT中心进行统一管理，而大数据部门也属于IT眼中的“业务部门”。由于大数据部门天生具有接触数据和处理数据的需求，因此很多时候也会被开放某些附属库、从属库或复制库的权限。某些情况下，大数据部门也会承担类似“取数”的功能，这类需求在某些情况下会频繁发生，例如：

• 大型活动之后，没有数据权限的业务部门可能会发出“看结果”的需求；
• 当出现意外运营情况时，业务部门也会想要“先看看数据”；
• 做年度、季度、月度和周度等计划性的总结及规划时，业务部门也会想“参考下数据”；
• 规律性导出的日报、周报、季报、半年报、年报的详细和结果数据。
  

限制业务部门的“取数”权限从企业宏观来讲利于数据安全把控，这是实现数据安全的途径之一。但从整体来看，如何平衡安全和工作效率，并释放人力和时间资源到更好的工作或项目机会上，需要进行权衡。毕竟，数据安全不只有权限控制这一种方法，而且只有这一种方法也无法完全保证数据安全。

（3）数据校验

这里的数据校验是指用一定的方法保证多数据源之间的完整性、一致性、准确性、及时性和有效性。

数据校验通常存在于大型企业中，这类企业往往存在多平台、多系统、多生产环境和多测试环境，此时如何保证多个系统对于同一业务主体的测量满足上述条件就要通过数据校验工作来实现。

数据校验（某些公司也称为数据治理）是保证和提升数据质量的重要步骤之一，如果该过程缺乏有效执行，将很有可能导致“Rubbish in，Rubbish out”的局面，后续所有数据工作的价值将无从谈起。

（4）数据统计

大多数日常报表需要通过技术开发形成产品报表体系，以提供日常业务支持。当有突发性事件或活动时，需要人工整理和汇总报表。日常报表完成后，通过自动发送邮件或短信、在线访问、离线客户端访问等接入。

根据数据日常报表提供频率和周期不同，日常报表可分为日报、周报、月报、季报、半年报和年报。报告内容因公司需求而异，但基本框架是统计周期内企业整体、各运营环节KPI陈列、对比和简单分析，目的是通过周期性数据进行业务诊断，发现业务效果趋势和异常点，为业务优化执行提供基本支持。

根据数据日常报表支持对象在企业内部分工不同，日常报表可分为针对决策层的报表和针对执行层的报表。针对决策层的报表侧重于宏观的、整体的效果汇总和结果分析，借助对比、趋势和主要维度下钻等方式进行初步分析并定位结论和问题点；针对执行层的报表侧重于微观的、个体的效果分析，各业务执行层只针对各自业务维度进行分析，并提供实际可行的操作型建议。
对于数据指标的设定，既要包括公司核心结果指标如利润，又要包括各个业务节点的过程类或间接辅助类指标，以更全面地评估和定性整体及各业务线的工作结果。

3.灯塔

灯塔意味着企业的工作方向或职能开展需要大数据部门进行指导，此时大数据部门承担着以下三类角色和功能：

• 剖析过去。对过去所发生事件的原因进行剖析，找到影响全局或特殊事件的关键因素并加以提炼以形成优化或改良机制；找到数据中的频繁规则并提炼出可供现在或未来使用的业务方法；从海量数据中发现数据知识，并能通过知识来引导业务行动或进行业务优化规则的启发。
• 监控现在。对数据实时的监控和反馈通常是大数据部门的必备职能之一，数据反馈的实时性通常对于在线活动影响极大，无论是基于预测的、异常波动区间的还是数据分布模型的监控方法，只要能快速、有效并且准确地告知业务主体当前发生的问题，并配合业务一起剖析问题，尽快解决类似于流量作弊、黄牛订单、恶意注册、虚假投资、骗保等问题，能为企业节省大量时间、资源和项目等成本支出项。很多时候，时间就是机会，而时间也是最大的成本。
• 预测未来。基于历史情况对未来的事件预测意味着业务在开展行动之前需要有明确的目标导向，基于目标可以制定明确的KPI、匹配为实现目标所需要的资源、预估行动成本和收益、平衡不同项目的机会成本和对企业整体战略布局的影响。
  

大多数企业中的大数据部门都有类似于数据挖掘、数据分析、专项分析类的职责，这类工作的核心价值通常不是产生多少模型、几种算法、多少报告等，而是直接对于企业整体销售和利润的提升，或在保持相同销售和利润水平下对成本的控制和缩减。当然，某些企业内部会由于各种原因，比较注重知识产权、专利申请、科学研究、学术报告和期刊等的影响力，这些视具体情况而定。

这类角色通常通过一定的模型、算法、流程和机制对数据进行解析，大多数的工作都是通过专项数据挖掘或分析的形式开展。

数据专项挖掘分析是指针对某一特定课题或需求，采用专项分析或长期课题分析的形式对数据进行深入挖掘和分析，以提炼出相应结果或方法论供业务参考或使用。数据专项挖掘分析是数据发挥价值的重要手段，更是数据辅助支持作用的关键，大多数公司的数据工作意义都来源于此。

为了提高数据工作的针对性，数据专项挖掘通常按业务模块划分，常见的数据专项挖掘分析模块包括市场分析、营销分析、运营分析、会员分析、用户体验分析、销售分析、移动分析、O2O分析、库存分析、供应链分析等。不同分析模块课题依业务需求而定。

4.先知

在上述三类角色中，我们讨论的知识前提都是数据依托于业务主体开展工作。但无论开展的工作是预测性的、剖析性的还是知识挖掘性的，可以说没有业务就没有数据发挥作用的土壤，更无法落地应用和实施。因此，从某种程度上看，数据是一定要依托于业务主体而存在。那么数据真的只能处于依托作用或依托于业务而存在吗？

在大数据时代的当下，身边所有介质所产生的任何属性、行为、结果等都可以通过一定的形式进行记录。现在除了传统的结构化数据外，还包括半结构化和非结构化的数据形式或类别，例如日志、文本、视频、语音、图片、文档、XML、HTML等。这些数据形式或状态可以被人类识别并加以有效分析、整合和利用，既然人类可以做到，那么理论上在一定条件下计算机也有机会这样开展工作。

人类开展工作的前提是从出生开始便不断接收外界各种信息源的刺激和学习，相对的，计算机所能接收到的信息相对于人类接收到的数据和信号而言，都是碎片化并且微乎其微的。基于计算机视觉、模式识别、自然语言处理、机器学习、深度学习等领域的人工智能正在被人们进行广泛的研究。假如通过一定途径将人类接收到的所有信息都能传递给计算机，那么计算机便可识别、加工、分析、应用和预测这些信号。因此，解决了这些问题之后，计算机智能便可脱离业务主体而存在，甚至在一定程度上，它可以创造业务、思考业务和优化业务并找到最优化方法进行求解。

目前，这类角色在企业和社会中还没有大规模的综合性应用案例，但在很多垂直领域中已经有所突破，例如机器翻译、语音识别、图片识别、自动规划、智能无人汽车、智能博弈等；而在学术和知识研究领域也有各自阵地，包括深度学习、神经网络、机器学习等。未来，数据的价值将借助于传感器、海量数据、数据推演的模型和算法、自动程序设计、自动控制以及硬件集成等方式独立开展行动。

2.1.2　常见的大数据职能及职责

常见的大数据组织架构分为四种类型，根据不同公司的性质可分为分散型架构、集中型架构、复合型架构和矩阵型架构。

1.分散型架构

在分散型数据架构中，数据作为单独的部门位于各个业务中心之下，职责是提供本中心的数据支持。如图2-1所示，营销中心、运营中心、会员中心和IT中心都有自己的数据部门，各个部门相互独立。

分散型数据架构常见于企业创建数据体系的初期，初衷是先将数据置于某个中心之下，待数据工作正常开展并卓有成效之后，再在其他部门成立数据部门并辅助业务工作。

分散型数据架构下，各大数据部门的职责是高度相似的，包括：

• 运营业务数据统计；
• 用户体验、SEO、用户研究等通用方向的分析；
• 各自业务中心业务活动效果分析；
• 关键业务项目的数据挖掘和分析；
• 数据报表和数据产品开发（主要是IT中心的大数据部门）；
• 机器学习算法实现和集成（主要是IT中心的大数据部门）。
  

这种数据架构的优势非常明显：前期投入较小，只需人员成本和极少的系统成本便可开展工作；数据从业人员由于处于业务工作体系内，对业务熟悉度较高，数据落地价值更大；另外，相同体系下的各个部门协同工作效率更高，利于业务方数据理解和执行。当然，这种架构的缺点也是显而易见的：

• 数据质量难以保证。各部门数据来源分散且不完整，数据质量难以保证，基于未知质量上的数据结论可能无法立足。
• 数据共享困难。不同数据部门之间的数据孤立还会导致数据孤岛的出现，不同的思维方法、工作机制，甚至定义方法不同导致数据源和数据结果无法流通、共享和综合应用。比如，对于转化率的定义方法，可能有订单/UV、订单/访问、订单客户/UV甚至件数/PV。数据共享困难一方面可造成数据价值难以最大化传播，另一方面在同一个数据项目的处理上也造成重复的人力、时间和物力投入并导致资源浪费。
• 数据结果混乱。由于数据来源不一致或同一来源下定义口径的不同，各个业务部门汇报结果可能存在数据出入。这会影响决策层对业务结果的判断，同时影响数据的可信度。
• 难以形成合力。各部门基于自身需求搭建支持体系，不同部门间难以形成合力共同搭建对全公司服务的数据支撑点。
  

2.集中型架构

集中型数据架构与分散型数据架构相反，它是把所有的数据工作汇总到一个中心集中统筹规则，通常该中心是信息技术中心或IT中心。图2-2为典型的集中型数据架构图。

该架构下由于所有的数据都集中到IT中心，因此大数据部门工作职能高度集中，主要包括：

• 异构数据和主从数据的校验；
• 数据统一管理和权限管理；
• 数据报表开发和产品开发；
• 根据业务需求的数据抽取；
• 机器学习算法实现和集成；
• 针对各业务线的数据分析。
  

这种数据架构体系有效地解决了数据源不一致和数据口径定义的问题。由于所有数据从生产到应用都由该中心统一负责，数据质量度较高。这种数据架构的主要问题是业务理解与支持较弱：

• 业务工作流程复杂。所有业务中心的数据需求都需要经过该中心处理，需求沟通、确认、实施、反馈的流程较为复杂，影响业务对数据需求的积极性与主动性。
• 业务理解度不够。在该中心统筹下的数据体系，附带了技术的思维方式和工作方式，对业务的理解程度低，使得数据难以落地应用。
• 技术响应及时性差。该中心的部门都有各自的工作计划和排期，业务方多而杂的临时需求影响其正常工作，大量需求可能被积压甚至无限延期。
  

为了解决集中型数据架构带来的业务应用问题，行之有效的一种方法是派驻数据分析师入驻到各个业务中心。这能在很大程度上缓解技术类中心“不懂业务”的被动局面，但对数据分析师个人素质和能力有较高要求：

• 扎实的基本数据素质。分析师需要具有扎实的基本数据素质，能及时、有效、准确地解答业务数据问题。
• 良好的个人时间把控能力。由于身处业务中间，分析师会面临很多临时需求，包括咨询、取数、分析、报告等，这就要求分析师具有良好的个人时间管理素质。
• 完善的工作流程和机制。流程和机制可以使各项工作有据可依，过滤无效需求的同时保证数据安全性、有效性、及时性和落地应用价值。
  

上述方式可以有效保证数据质量和业务应用效果，但同时我们需要考虑数据之外的问题：如何管理分散到各个业务中心的分散人员？如何协同各部门工作？如何避免交叉管理问题？

在集中型数据架构下，分散到各业务中心的分析师的组织架构仍然属于技术中心。

3.复合型架构

复合型数据架构是建立在分散和集中基础上的复合组织架构。数据端集中到统一中心之下管理，该中心通常是IT或数据中心；业务端分散到各业务中心之下设立数据支持部门，如图2-3所示。

复合型数据架构既能保证数据的质量标准化，又能保证各个业务节点的数据落地应用，同时还可以结合各业务共同需求以及公司战略发展需求开发全局应用的智能产品。不同中心间的分工如下：

（1）IT/数据中心

• IT/数据中心的数据职能是对接全公司所有业务高级需求，统筹整体并进行相关数据产品开发：
• 统一口径。数据源的定义、数据出口和抽取逻辑的统一、数据指标和应用场景的规范等。
• 搭建平台。经过整合和清洗的干净的数据源甚至数据平台、报表可视化等。
• 智能数据产品开发。自动化数据挖掘模型封装和开发、BI、个性化推荐等。
• 对接业务中心高级需求。深度数据源抽取和应用、数据建模和挖掘技术支持等。
• 数据技能培训。提高业务数据应用能力和素养，包括知识、技能、素质、最佳实践场景推广等，涵盖数据知识、数据应用和工具使用知识。
  

（2）各业务中心

各业务中心除对接各自中心的需求以外，还需要与IT/数据中心协同工作：

• 根据数据中心的统一规范，制订适合本中心的数据应用场景、指标和分析体系等；
• 收集各自中心的零散需求并反馈到IT/数据中心，参与IT/数据中心公司级数据产品开发和应用，参与环节包括底层收集、数据ETL、数据建模、数据可视化、数据智能应用等——该项工作是数据协同工作的重要产出。
  

4.矩阵型架构

矩阵型数据结构常见于第三方服务或外部服务公司，属于项目管理类企业的常见架构，对于这种企业而言，项目制的工作方式是企业业务运作的基本模式，如图2-4所示。

这种模式或职能结构具有以下特点：

• 所有大数据项目都有直接项目负责人，该角色可能是项目经理也可能是项目总监，具体视项目重要性而定。
• 不同项目间通常相互独立，可独立核算成本和利润，这使得所有项目可衡量、可优化和可改进。
• 业务动作以项目为导向，除了企业管理类部门外，其他所有的职能部门都是为项目提供服务，支持项目工作的有效开展。
• 公共资源池的有效利用：项目间的资源利用可以从公司整体统一调度，通常以设立资源池作为调用出口，所有项目资源（人力、设备、技术、产品等）使用完成之后可快速回收并调配到其他资源中。
• 项目间的资源流通性提升：不同项目间虽然独立运营并参与核算，但资源也可以互通使用，这会利于保证有效资源的有效调节和最大化使用。
• 大数据项目管理中心统一协调：作为所有项目管理的枢纽，该角色承担的项目工作包括项目获取、组建、管理、运营、重组、回收、调节等，整体把控性更强。
  

这种整体与局部的有效统一使得所有的大数据工作环境都相对可控，利于企业利益最大化，但同时也存在一些不可避免的问题：

• 员工缺乏归属感：大多数参与项目工作的员工，通常需要驻扎在客户阵地前线，这使得项目完成之后员工需要根据下一项目需求调度到其他项目中重新投入工作。很多情况下可能会到全国各地做项目，导致员工很难产生归属感，容易造成员工流失。
• 企业人员有效管理问题：对于大多数项目工作制的劳动方式而言，大多数时候都在“甲方”工作，这使得员工的“工作过程”很难把控，因此大多数项目员工会以项目交付成果作为考核依据；除此之外关于员工的费用、社保、培训、晋升、汇报、福利、知识等所有问题由于缺乏有效的基于地理位置的管控，只能通过在线系统开展并需要依靠公司制度约束，这些都会对员工管理造成困扰，员工越多管理难度越大。
• 员工成长问题：处于项目工作中的员工，在不同项目中扮演的角色是类似的，应用的技能也基本类似。技能的成长通常只能由生到熟而遇到技能瓶颈，职业通道和发展路径上又受到项目的限制而缺乏其他管理类经验，因此“天花板”问题比较突出。
• 企业文化培养问题：由于员工长期处于“甲方”工作状态，企业内部工作文化很难进行有效落实，并且项目内员工的问题也很难通过正常渠道反馈到企业工作流程和机制中，通常项目经理或项目总监就是一个企业的“小老板”。
  

对于矩阵型的大数据工作架构，不同部门间的职能分配如下：

（1）大数据项目管理中心

核心职能：

• 资源管理：根据公司项目开展需要，建立和健全项目资源管理制度，实现公司所有资源在项目内的总体协调与调度最优化，以保证资源效率最优、利润率最大。
• 项目管理：组织和策划公司项目招标、计划实施与协调，确保各项目的有效推进和落地。
• 质量管理：制定施工方案、质量工作标准和验收标准，组织质量管理培训、逐步推进项目活动全过程的质量管理工作。
• 费用管理：组织实施工程项目管理的项目经理责任制和项目成本核算管理。
• 监察管理：对各项目中可能存在的影响公司整体利益的外包项目分派、内部资源的外部利用、项目违规操作、个人边缘利益以及其他违反公司规章和制度的监督和管理措施。
  

非核心职能：

• 知识管理：针对项目实施过程中遇到和应用的场景、行业、案例、模型等知识物料进行统一汇总和管理，形成可供企业所有项目参考的知识库，最终根据企业市场形态建立针对性的解决方案。
• 培训管理：项目招投标、实施、验收等过程中所需的各种技能和职业素养要求的培训，重点在于满足项目工作需求，是对普通职业技能的拓展。
• 人员管理：项目工作中所需人员的管理，包括组织规划、人员选聘和项目核心骨干建设等一系列工作。
• 档案管理：建立和完善项目信息、档案信息制度，组织和指导建档工作并及时汇总和更新档案信息。
  

大数据项目管理中心和各项目中心的职能中，除资源管理和项目管理外，其他职能可能会根据公司实际运营情况有所差异，某些公司甚至会采用各项目组独立核算成本的方式。

（2）各项目中心

• 范围管理：为实现项目预期目标，对项目的工作范围进行管理的过程，包括范围的界定、规划、调整等具体工作。
• 时间管理：为确保项目交付时间而进行的一系列管理过程，包括具体项目实施的规划，实施过程界定，项目细分内容优先级评估、时间估计，项目进度控制，周期性监察，进度报告等各项管理工作。
• 成本管理：在保障项目交付的前提下对实际需要的各种成本、费用的管理过程，包括软硬件资源的配置、调整，弹性解决方案应用，项目内费用审批及控制等各项工作。
• 质量管理：为达到项目交付约定的质量要求所实施的一系列管理过程，包括质量规划、质量控制、质量验收和质量保证等。
• 人力资源管理：项目内的人力资源管理通常是对于项目内部人员的工作职责、范围的调整，以及为最大化人力资源产出而实施的工作时间、效率和结果的一系列管理措施。
• 风险管理：对项目工作过程中涉及的可能会影响项目交付时间、交付质量、交付数量等交付成果的各种不确定因素的识别、量化、规避和控制等管理措施。
  

很多公司为了避免项目的失控并保证公司利益最大化，都会设置项目内的双管理（两个项目负责人）检查的制度，这样不但可以保证各利益方相互监督，同时又能最大限度地避免利益主体抱团。

---

欢迎光临 168大数据 (http://www.bi168.cn/)

Powered by Discuz! X3.2