摘要：电信企业的数据仓库项目组织团队常常是非常复杂的，如何构建高效的数据仓库项目组织团队，对数据仓库项目建设的成功及后期系统的运营应用有至关重要的意义。本文总结了某省级电信企业在大型数据仓库项目组织团队建设中探索的经验，为构建电信业高效的数据仓库项目组织团队提供了可供参考的解决方案。其特点是，从系统建设阶段就考虑到了后期运营的承接，并从一开始就特别重视数据仓库的应用；在运营阶段，通过摸索演进，最终找到了一种高效的、稳定的适应长期运营的数据仓库项目团队组织构建模式，使数据仓库系统价值得到更好发挥。
关健词：数据仓库项目管理项目团队组织构架 角色 职责 流程
引言
数据仓库目前在银行、证券、电信、保险等行业得到广泛的应用。由于数据仓库涉及到的技能非常庞杂，且与整个企业的各个业务系统及各部门各层面的员工都可能发生广泛而深刻的联系，这些大型企业的数据仓库项目组织团队也常常是非常复杂的。如何构建高效的数据仓库项目组织团队，对数据仓库项目建设的成功及后期系统的运营应用有至关重要的意义。
数据仓库在建设和运营的两个阶段目标不同，参与方也往往不同，对团队人员的技能要求有很大差别，项目的组织团队也会发生很大变化。如何调整组织团队适应项目生命周期进展的需要，既顺利衔接，又适应变化是许多企业在实施数据仓库项目时面临的难题。一些企业由于疏忽了这个问题的处理，虽然在数据仓库建设阶段取得了很好的成果，顺利构建起了符合最初项目目标的数据仓库系统，但在后期的运营应用中却遇到了困难，不能使花费了大量成本构建的系统很好地发挥出应有的价值。另外，有些数据仓库项目在建设期间将数据集中作为自己的主要目标，在构建项目团队时甚至将应用开发人员划入外围团队，重数据采集与平台搭建，却忽视了应用的及时切入，从而使项目不能尽快产生效益导致失败。
本文总结了某省级电信企业在大型数据仓库项目组织团队建设中探索的经验，为构建电信业高效的数据仓库项目组织团队提供了可供参考的解决方案。
1 数据仓库建设阶段项目团队组织构建
项目团队包括为完成项目而分派有角色和职责的人员。“团队à角色à人员”是我们用来描述项目组织的三个概念，不同的角色代表不同的分工即职责，同一角色可由多个人员承担，同一人员也可同时兼任多个不同角色。下面描述中团队、组属于“团队”层面概念，其它一般用“角色”来描述团队的具体组织构架，一个角色可能包含多名成员。
下面是某省级电信企业在数据仓库建设期间的项目团队组织构架，包括项目核心团队和项目外围团队。项目核心团队由数据仓库产品厂商，数据仓库集成商，数据仓库建设单位的人员混编而成。核心团队中建设单位参与人员主要是IT部门人员，建设单位项目经理也一般由IT部门派人承担。项目外围团队主要包括数据仓库最终用户（省公司级及分公司级业务部门人员）、系统维护工程师和源系统技术专家。项目核心团队成员都专职参与项目，项目外围团队一般采取虚拟团队模式，成员兼职参与。
由于示例项目所建数据仓库后续由集成商负责平台维护和应用开发，建设单位只在每个小组中派驻了项目管理人员，在系统建设期间这些人员通过深入参与项目得到很好的培养和锻炼，后期不只负责技术管理，还都成长为技术专家。项目建设期间的每个角色分工，都由数据仓库厂商和集成商的人员共同承担，使集成商得到很好的知识转移，为后续独立承担运营应用任务打下坚实基础。由于该系统的硬件平台后续采取外包维护的形式，我们将系统维护（数据硬件平台维护）角色纳入外围团队。
图1 数据仓库建设期间项目核心团队组织构架
核心团队由三个小组构成，数据模型组负责源系统的信息分析，概念模型、逻辑模型及物理模型设计，模型的解释培训，编码映射及元数据的管理，也负责模型的调整和维护。平台维护组负责数据库管理，包括数据库性能、空间、访问权限及安全管理，表及视图创建；与源系统数据文件接口的实现及维护，保证数据文件及时、完整、正确传送，并对接口机进行维护；ETL程序开发、测试、维护及调度管理；数据质量管理与数据问题跟踪处理等。应用开发维护组又下分报表多维分析开发、专题应用数据挖掘开发及即席查询开发三个小组。应用开发维护组负责应用需求分析管理，应用开发、测试、维护，应用推广培训，应用门户网站（Portal）的开发维护，应用服务器的维护等。这种组织模式，结合数据仓库各项工作不同的技能要求，分工非常明确，从系统建设阶段就考虑到了后期运营的承接，并从一开始就特别重视数据仓库的应用。
图2 数据仓库建设期间项目外围团队组织构架
外围团队不象核心团队一样是个严格按项目管理来运作的项目组，而是一个虚拟团队，团队成员的主要职责往往不是参与数据仓库建设，只是在需要的时候听从召唤，阶段性参与到相关工作中来，或将其中的某些工作纳入到已有工作职责中成为自己工作的一部分。系统维护角色主要负责数据仓库硬件平台，包括主机、磁带库等的维护及数据备份与恢复，他们常还兼任其它系统硬件平台的维护。源系统专家配合数据仓库接口文件的抽取和数据模型的信息调研等工作。分公司IT部门负责在分公司层面对数据仓库应用的承接，包括分公司业务系统与数据仓库接口的维护，与分公司业务系统相关的数据质量管理及数据问题处理，分公司数据集市维护，应用需求分析与应用开发、维护等。各类业务部门（本示例中主要是市场部）是数据仓库的最终用户，他们负责应用需求的发起与分析成果的应用，使之产生价值，并对应用效果进行评估。在实施数据仓库应用时，也常将某个应用独立成一个项目进行运作，数据仓库核心团队中应用开发人员与外围团队中业务部门的业务专家密切配合，甚至阶段性地全职参与该项应用的开发工作，并对分析成果投入应用的全程进行跟踪和管控，从而使应用能切实发挥效用，产生价值。
2 数据仓库建设团队向运营团队的演进
数据仓库项目建设验收后就转入运营阶段，这时项目团队会发生一系列显著变化。在运营阶段主要是核心团队会发生变化，而外围团队变化不大。数据仓库厂商的人员会撤离项目组，小型项目由建设单位，大型项目由集成商和建设单位承担起数据仓库平台的日常运营应用工作。工作内容也会有很大变化，模型设计、ETL开发的工作量会大为减少，相反应用由星星之火渐成燎原之势，应用需求会应接不暇；且随着应用的拓展和深化，各类数据问题也会充分暴露，接踵而至。数据仓库项目团队必须及时调整以适应这些变化。然而在找到最适合日常运营的组织团队构架之前，往往要经历一个艰苦的探索过程，并难以避免要走弯路。比如本文示例的企业，在数据仓库运营阶段最初的项目核心团队组织构架如下图3所示。
图3 数据仓库运营期间项目核心团队组织构架演进
核心团队的组织构架之所以演进成了以上模式，是由应用发展所推动的，不断涌现的应用需求及不断提升的应用要求，使整个项目团队疲于应付、顾此失彼。一个好的现象是说明数据仓库的重要性和价值正越来越得到认可，而且以上组织模式在一定阶段容易做出一些应用成果，推动数据仓库应用取得一些突破性进展。然而致命的问题是如果不能组织起高效的运营模式，随着应用的膨胀，项目团队将难以为继，而且做得越多，得到的报怨也会越多。
这种组织模式的低效还体现在：应用各自为战，缺少集中的需求管理分析和统一的应用规划，可重用性差，重复劳动多；应用开发人员分散，职责重复，管理困难，优势资源难以共享；重应用轻维护，没有专职的应用维护人员；人员承担职责较多，对人员能力要求高，如ETL运维和开发没有分离，应用开发和维护没有分离，各应用组除承担应用开发工作还需要承担所负责应用的WEB展现开发；缺乏全员的数据质量意识，数据质量问题由运维组下的数据质量管理小组来专职处理，实际上数据质量问题是整个项目组每个成员需要面对的问题，数据质量管理小组不可能去解决所有的数据质量问题，导致问题积累比较多，用户满意度差。
3 适应长期运营的数据仓库项目团队组织构建
本文示例企业通过一个阶段的摸索，并专门实施了一项内部管理咨询项目，对项目团队组织构架进行了一番调整。通过项目成员访谈、调研了解现状，并分析存在问题；通过借签国内外好的做法，吸收项目成员好的建议，参考数据仓库成熟度模型明确改进方向；通过调整和跟踪管理，落实改进措施；通过评估进行调整优化。
目标是明确人员职责分工，打造核心团队，建立起适合长期运营的高效的、稳定的团队组织架构。改进的原则是：利于效率提升，便于职责落实与核心团队构建；类似工作进行合并，避免职责交叉和重复；助于该企业省公司统一管理和集成商创造性的自主发挥；助于项目团队成员的职业发展和队伍稳定。调整方法是根据关键工作流程梳理出关键环节，根据关键环节明确关键功能点，对应设置关键角色和组织架构。梳理出了3个关键流程和7个关键岗位。三个关键流程分别是：数据流、任务流（应用需求）和问题流。
数据流保障数据的完整、及时、准确，贯穿数据ETL的整个流程：源系统àstage(数据临时区)àPDM(物理数据模型)à数据中间层集市à应用数据集市，在流程的各个环节中，模型管理、运维支撑、应用支撑、体系管理、质量管理等几个关键角色分别承担了相应职责。
图4关键流程之一：数据流
任务流保障应用需求－任务的合理产生和合格落实，使应用开发符合范围、进度、质量、优化（持续生效）的要求，任务流贯穿于应用开发的整个生命周期。在流程的各个环节中，需求管理、模型管理、应用支撑、专题支撑、运维支撑、体系管理、质量管理等几个关键角色分别承担了相应职责。
图5 关键流程之二：任务流
问题流保障问题及时、准确、全面的解决，可以是和数据仓库工作相关的任何问题，包括数据质量问题。问题流贯穿于问题由产生到解决的整个生命周期。在流程的各个环节中，质量管理、模型管理、应用支撑、专题支撑、运维支撑、体系管理等几个关键角色分别承担了相应职责。
图6 关键流程之三：问题流
根据以上关键流程抽象出的关键角色，我们形成了以下适应数据仓库长期运营的矩阵式项目核心团队组织构架。在数据仓库运营阶段，数据仓库所属企业的IT部门专门有一个分支机构负责数据仓库的运营，由以下角色构成：
|
角色 |
职责 |
|
数据仓库运营室主任 |
建设阶段任项目发起方的项目经理，负责整个机构的事务管理 |
|
业务支撑管理岗 |
需求管理，模型管理，编码及元数据管理，即席查询应用支撑管理 |
|
维护支撑管理岗 |
运维支撑管理（ETL、接口、应用维护），数据质量管理，问题管理 |
|
应用支撑管理岗 |
应用体系架构管理、报表及多维护分析类应用开发管理、门户管理 |
|
专题支撑管理岗 |
专题规划管理，专题、数据挖掘类应用开发管理 |
|
数据支撑管理岗 |
兼职，负责源系统数据质量及接口管理 |
表1 建设方数据仓库运营项目核心团队角色及职责列表
以上成员分渗透到集成商的各项工作中，对应各关键角色，发挥专家顾问和项目管理的作用。
图7 数据仓库运营项目核心团队组织构架
以上团队组织中7类关键角色的职责分工、技能要求及职业发展规划如下表所示：
|
角色 |
职责 |
技能要求 |
职业发展 |
|
体系管理 |
DBA，负责数据库的系统管理，包括性能监控与优化、数据库权限分配、数据库空间管理等；脚本及任务的监控与优化；应用服务器的体系管理与性能优化；本地网资源管理；脚本优化培训。 |
对数据仓库系统的体系架构、存储访问机制、权限控制机制等非常熟悉；能熟练使用相关工具软件；能熟练使用SQL语言；需要工作责任心强，学习能力强，对技术非常热爱。 |
团队核心成员，可向体系架构师发展。
|
|
质量管理 |
DQ，负责各类问题的受理，并进行分析、分派，跟踪问题的解决并进行评估考核。受理客户的投诉。对项目的各项执行流程进行监控和考核，包括项目管理文档的核查，对各项工作进行质量跟踪管理，协调数据质量问题的处理。 |
需要责任心强，执行能力强，沟通协调能力强。熟悉数据仓库各项工作流程，熟悉质量检查的体系架构、实现机制、工具配置；熟悉数据仓库系统及其数据模型，对数据较为敏感，有较强的数据质量问题分析判断能力；熟练使用即席查询工具。 |
团队核心成员，并可向运营经理发展。 |
|
需求管理 |
负责需求的统一受理管理与分派，参与需求分析和客户沟通，进行需求及设计方案的确认。负责需求记录整理但不负责具体需求及设计文档的编写，负责应用规划，对需求实现及应用部署进行统一考虑。对需求实现进度及质量进行跟踪考核。 |
需要熟悉业务，熟悉数据仓库各类应用及数据模型，沟通协调能力强。能根据当时的数据情况、系统性能及技术条件，把用户需求向有利于数据仓库应用和发展的方向引导，确保每个阶段开发的应用最能产生价值的、最符合业务需求。 |
团队核心成员，并可向业务架构师发展。 |
|
模型管理 |
负责模型的设计，模型的解释说明和培训，模型相关文档及元数据管理，解答和解决模型方面的问题，参与应用中间层模型的设计
，并负责设计方案的审核。对数据模型进行统一规划。负责模型调整维护，接口变动设计。 |
需要熟悉业务，非常熟悉数据仓库模型和数据仓库各类应用，有业务系统实施经验，熟悉主流业务系统，熟悉实体之间的关系，熟悉数据仓库的数据存储情况。沟通协调能力强。 |
团队核心成员，并可向业务架构师发展。 |
|
运维支撑 |
负责数据流的维护，应用持续运行的维护，数据问题及应用问题的日常监控和具体处理。包括ETL维护、编码映射维护、接口维护、应用维护（包括应用测试与发布）等角色。 |
ETL维护：熟悉ET的实现机制和任务调度机制；能够排数据流等各环节的故障；熟悉数据仓库系统及数据存储。编码映射维护：熟习业务规则及标准编码。接口维护：熟习源系统接口及数据接口实现机制。应用维护：熟悉数据模型；应用架构及数据流程；熟悉各类BI应用工具；熟悉应用测试方法。 |
组长为核心成员，可向运营经理发展。
其他成员可向组长及相关岗位发展。 |
|
应用支撑 |
报表、多维护分析、即席查询类应用设计、开发，协助ETL开发。以项目经理制受理相关应用开发需求，可完成从stage到pdm到fact集市的整个脚本开发工作，并负责应用项目的文档整理和项目管理。参与测试、应用发布和协助应用维护人员进行问题处理和应用升级。应用门户维护，WEB类应用开发。 |
非常熟悉数据仓库系统及其数据模型；熟练使用数据仓库查询软件，熟悉sql和Perl编程；熟练掌握各种BI软件的应用；有较强的业务理解和领悟能力，掌握了较多的业务知识，对数据较为敏感；具有较强的沟通交流能力；有一定项目管理能力。
负责Portal维护及WEB程序开发的，需熟悉Portal架构；
WEB程序开发，应用服务器的管理配置。
|
组长为核心成员，可向技术构架师发展。其他成员可向组长及相关岗位发展。 |
|
专题支撑 |
数据挖掘、专题分析类应用设计、开发。以项目经理制受理相关应用开发需求，完成专题开发工作，并负责应用项目的文档整理和项目管理。参与测试、应用发布和协助应用维护人员进行问题处理和应用升级。 |
非常熟悉数据仓库系统及其数据模型；熟练掌握数据技术及工具；熟练使用数据仓库查询软件，熟悉sql和Perl编程；熟练掌握各种BI软件的应用；有较强的业务理解和领悟能力，掌握了较多的业务知识，对数据较为敏感；具有较强的沟通交流能力；有一定项目管理能力。能长期出差（因一般在分公司实施项目）。 |
组长为核心成员，与咨询顾问可向咨询师发展。其他成员可向组长及相关岗位发展。 |
表2数据仓库运营技术支撑团队角色及职责列表
最终数据仓库运营组织团队的构成如下：
|
角色 |
成员数（单位：人） |
备注 |
|
数据仓库运营室主任 |
1 |
建设单位 |
|
业务支撑管理 |
1 |
建设单位 |
|
应用支撑管理 |
1 |
建设单位 |
|
维护支撑管理 |
1 |
建设单位 |
|
专题支撑管理 |
1 |
建设单位 |
|
数据支撑管理 |
|
建设单位，由主任兼 |
|
集成商运营经理 |
1 |
以下为集成商技术支撑团队 |
|
体系管理 |
1 |
核心成员 |
|
质量管理 |
2 |
核心成员1 |
|
需求管理 |
1 |
核心成员 |
|
模型管理 |
2 |
核心成员1 |
|
ETL开发 |
6 |
可兼应用维护 |
|
运维支撑 |
1 |
组长 |
|
ETL维护 |
2 |
兼接口维护 |
|
接口维护 |
|
|
|
编码映射维护 |
2 |
|
|
应用维护 |
4 |
|
|
应用支撑 |
1 |
组长，兼需求分析、项目管理 |
|
应用开发 |
8 |
可兼应用项目管理、ETL开发 |
|
即席查询支撑 |
2 |
|
|
门户维护与WEB开发 |
1 |
核心成员 |
|
专题支撑 |
1 |
组长，兼需求分析、咨询顾问 |
|
专题开发 |
4 |
可兼专题项目管理、咨询顾问 |
|
合计 |
44 |
|
|
建设单位合计 |
5 |
|
|
集成商合计 |
39 |
|
|
技术支撑团队合计 |
38 |
|
表3 数据仓库运营组织团队的构成人员列表
该企业数据仓库的容量达到83TB，由以上建设单位及集成商构成的44人团队负责日常运营和应用，其中技术支撑团队38人，核心成员8人，分别占居上述7个关键角色，支撑起整个团队稳定高效的运转。
以上项目团队组织构架在团队内明确了关键岗位角色，利于打造一支稳定称职的核心数据仓库运营支撑队伍，并通过这些关键角色保证数据仓库的关键工作流程得到高效落实。通过需求管理，加强与客户的沟通和需求的统筹把控，保证团队人力资源发挥最大价值；通过需求管理、模型管理对应用及中间层数据模型进行统一规划，提升应用开发成果的可重用性；通过质量管理，加强对问题的跟踪解决和客户申告的及时处理，提升客户满意度，并让各环节各岗位协同解决数据质量问题，全员对数据质量问题负责，更适合数据质量问题的解决特点。应用开发与ETL开发需要技能相同，应用人员可参与ETL开发，应用开发从ETL开发开始，贯通各环节，便于开发的项目管理及应用的维护管理，并可根据需要动态调节ETL开发资源。运维与开发的工作性质有很大区别，将ETL运维与开发分开，运维只需要较低的技能，ETL运维人员可同时兼接口运维护等工作，便于工作管理、提升效率、保证质量。将应用门户维护，WEB类应用开发等需要专门技能的工作纳入应用支撑组统一管理，相关资源共享，并保证了各类应用的统筹规划部署。应用及专题支撑开发采用项目经理制，各成员都有机会成为负责具体应用项目的项目经理，充分挖掘人员的潜力，且随着应用项目的拓展不会导到组织机构膨胀。通过以上调整后，数据仓库运营团队面貌焕然一新，成员的工作积极性被极大激发，潜能被充分挖掘，团队更加稳定，流程更加顺畅，工作更为高效，数据仓库价值得到更好发挥。
4 结语
本文为电信企业数据仓库建设及运营阶段项目团队的构建提供了可供参考的解决方案。其特点是，建设阶段的项目团队由项目发起方、数据仓库厂商、集成商混编而成，明确各自定位，注重知识转移，从系统建设阶段就考虑到了后期运营的承接，并从一开始就特别重视数据仓库的应用；在运营阶段，适时进行团队组织的调整，以适应形势变化，经历了应用急剧膨胀的考验，通过摸索演进，最终找到了一种高效的、稳定的适应长期运营的数据仓库项目团队组织构建模式。该模型根据关键工作流程梳理出关键环节，根据关键环节明确关键功能点，对应设置关键角色和组织架构。通过组织构架调整后，团队面貌焕然一新，工作效率极大提高，客户满意度显著提升，使数据仓库系统价值得到更好发挥。 | 
