集团报表的微信在线直播 - BAO胖子部分 之 集团公司报表平台运营（最终版）

一、集团公司级别报表平台运营

首先，我们有一个大的假设前提，集团报表平台是服务于大型公司，比如有很多分公司，子公司，多部门等，并且有BI需求的访问人群超过1000以上的公司。

这样，我们的关键词是：集团 平台 运营

集团：意味着，需要站在企业视角而不仅仅是项目视角审视

平台：意味着，海纳百川般的接受各类需求，在一定规则下平稳运行

运营：意味着，如何持续化、可发展的健康运转下去，这需要一套体系

1. 模式的演化以及面临的问题

1. 1 自下而上

稍微讲点历史，先看最常见的传统模式： 自下而上

最 典型的各个分公司，或者部门，有一定的IT经费，然后各自为战。会雇佣一定的IT的管理员，当有规模的需求时，组织项目进行系统设计开发。通常都会立项 ->招标->采购（硬件+软件+服务）->需求调研->设计->开发->部署上线->运维管理。

本世纪初开始，这种情况最为明显，很多省级公司的报表都是需要市级、县级、区级逐层上报汇总，数据中参杂各种水分。这个阶段，都是多如牛毛般的小项目，然后相关数据设计千差百别，集成很多时候是根本无法高质量完成的。

这 个阶段地市一级的BI需求很多都是夹杂在MIS系统里面一起实现的，通常都是固定报表，一般很少有为BI单独立项的项目，在2003年以前，会做一些独立 于MIS以外的决策支持系统，规模通常都很小。而经理一层的在这方面的需求实际上是很强烈的，很多小系统使用率非常高，偶尔会采购BI工具，很多时候就是 自行开发实现，用户规模也小，通常只有十几个人。

BI有关的稍微大一点规模项目往往是由集团管理层发起的，因为看不到及时的数据，无法做有效的决策，这个阶段出现各种二级数据集市的模式，地市一级用一套系统，出数据，然后上传到省公司, 集团公司等再做数据汇总。

这个阶段的特点是：

1. 部门或者分公司发起  

2. 小规模DSS系统，需求自下而上

3. 项目by项目，做一个是一个

4. 基本上找个管理员维护了事，很少升级

5. 自行定制开发很多

6. 集团拿不到原始数据，都是汇总加工过的。或者拿到原始数据除了查查基本信息，也做不了分析。

缺点：

1. 管理分散化，这样势必造成各个分公司、部门之间的不一致，建立企业级统一化的数据平台战略更是无从谈起。

2. BI都是循序渐进的，是长期的过程，这个基本是一锤子买卖，做完了等升级换代就不知道何年何月了。

3. 统统交给乙方，甲方完全没有核心团队，造成后面难以为继

4. 下次有类似一定规模的需求，如果换了乙方，基本上就是重做。

5. 集团级别拿的数据水分十足，并且很难及时，各个分公司口径不一致，没有统一试图

也别光说缺点，还是有优点的：

1. 一线的需求都是真需求，接地气

2. 低成本，灵活，规模小，启动快，容易见成效

3. 麻雀虽小五脏俱全，充分锻炼和培养了人的综合能力，不过绝大部分都是乙方的人。是的，我们很多人就是这么成长起来的。

为什么讲这些老掉牙的东西呢？因为即使到了今天也有很多信息化建设水平低下的企业（行业）还存在同样的问题。

1. 2 自上而下

再后来，一些信息化建设基础比较好的企业，就开始做省级（或者全国级，当然也有全球级别）的集中，即步入自上而下的模式

这个时候通常的大前提是，业务系统已经在集团公司集中了，比如ERP，CRM，SCM这类系统的集团化使用。势必带来BI系统的升级换代，这个时候的需求是自上而下的。所以开始大规模建立数据仓库，这个时代建BI系统的特点是，轰轰烈烈！都是大投入，大项目。

画外音：而数据仓库鼓 吹ETL是整个工作量的核心（一种声音表示，ETL占到整个工作量的70%，很多书上也是这么说的），到今天这种声音仍然不绝于耳。或许是真的吧，但如果 前端应用的比例太低，就意味着，你种庄稼光生根发芽不结果，那花这么多钱有什么意义？ETL是企业信息的极为重要的基础，但不可偏废！

这个阶段的特点是：

1. 集团公司发起，往往是IT总部使用公司划拨经费发起，各地方部门公司配合

2. 需求自上而下

3. 仍然是项目，但规模大，周期长，往往多期

4. 会大规模从找乙方的人来实施

5. 会选用成熟的BI工具

6. 集团公司把控所有数据

优点：

1. 统一化管理，降低管理成本

2. 统一化技术平台

3. 一定程度上开始标准化

但也有缺点：

1. 管理集中化，造成需求实际上基本只是从集团公司的需求，一定程度上削弱了地方公司或者部门的需求，甚至很多是上层的臆断

2. BI规模过于庞大，期待一次大而全

3. 甲方会有核心团队，但主要工作还是帮助联络，配合，斡旋。甲方或许会有BI的团队，但一般没几个人。核心仍在乙方手中，并且，乙方其实也不真的关心后续的工作，主要还是完成当下的需求。后续仍成问题，尤其是换乙方，更甚至是换乙方的核心人员系统就有问题

4. 很多小范围的需求被优先级置后，从不问津。

1.3 总结及案例

综合如上两种情况，总结了一些问题，列出一些但不限于此：

需求问题：

1. 虽然规模大，但有趣是有很多时候仍然不是企业级别的项目，而是最有钱或者最有实力（有话语权)的Business Unit (比如销售）出资，这样就只做自己的部分，其他的我可没钱去关心。然后公司就出现一种奇怪的现象，其他小部门呢？无人关心。他们也有需求啊！ -->小部门需求没人满足

2. 集中化了，需求自上而下，集团公司爽了，下面忽然看不到想要的数据了。而下面的需求其实和上面有很大区别，即使是同样的Business Unit。 -> 信息专制，而又没有渠道让下级公司满足需求

3. 对于企业没有专门BI团队配置的，还是按项目走，项目一旦结束，增加点中等规模或者小规模的需求很是吃力。  -> 更新，升级，增加小需求困难

资源浪费问题：

1. A部门有钱，B部门也有钱，OK，各自为战，你买Cognos做平台，我买BO，各玩各的。

    A部门有高级分析需求，用Tableau，殊不知B部门也有类似需求，但买了Qlikiew。  -> 软件License浪费

2. 硬件买多了浪费，买少了不够用；我就是月末用，平时都闲着；全球性企业，白天用晚上闲着，全世界多套系统均如此。 ->硬件资源需要优化

3. 信息安全（登录、授权）之类的通用型需求，重复建设。 ->基础建设管理成本增加

4. 集团公司把权限全收走了，可分公司还有BI的人马呢，他们最通业务也懂技术，怎么办？ －＞人力资源浪费

架构问题：

1.随着时间推移，用的人越来越多，并发太多，根本无法使用。 ->架构不可扩展

2.选择过于小众的产品，虽然满足了一小部分需求，但community不成熟，产品功能不完备，造成后续新功能无法添加，人员难以配备，出现技术问题没有成熟方案和社区获得支持。  ->产品选型问题

3. 若应用规模较大，可以更有效的获得产品厂家的技术支持，甚至为了当下迫切的需求，临时打补丁。从企业战略层面，和厂家深度合作也能获得更有利的折扣和其他优惠。    -> 产品Support方面

管理问题：

1. 没有BI建制的公司，乙方核心顾问闪了，自己的人没培养起来，回头还是做不出高质量的BI应用 -> 核心竞争力培养问题

2. 有BI建制的公司，BI人员苦逼了，都是企业内部需求，谁都可以让你做事，你都不知道听谁的，然后做了也白做，你自己都说不清楚你做了多少。优先级就是谁的声音大听谁的。   -->管理混乱

3. 用户看报表发现错误，不知道向谁反映 -> 维护支持管理问题

林林总总，可能还有很多，各位看看是不是自己公司也有类似的问题。

1.4 插播BI成熟度模型，请自行比对

这里插播一段内容，上一张BI的成熟度阶段图，大家可以看看自己所在的企业目前处于什么位置。

鉴于上面都是鸟语，我尝试一条一条解释一下，如果觉得这种东西没劲，请自行略过。

这图是Gartner在2008年提出的BI和BPM的成熟度模型，尽管过去7年了，看起来仍觉得他们说的到今天也不过时。

第一个阶段：Level1，Unware，无意识的，我可以称为叫一穷二白阶段，特点如下：

1）Total lack of awareness: 对的，就是啥啥也不知道，啥是BI？啥是BPM？统统不知道

2）Spreadsheets, Access databases, and information anarchy: 虽然啥啥都不知道，但需求是挡不住的，一般都是从excel， access这类东西汇总分析啥的，然后完全自由的查看信息，一般就是email带个附件传来传去

3) one-off reports: 就是也会出Report，但都是来个单个的Report需求，用Excel搞一搞了事

小结：没有意识的需求，完全没有体系化，萌芽阶段

第二阶段：Level2，我可以称为情窦初开阶段，好吧，原文翻译是 战术 阶段，特点如下：

1）No business sponsor, IT executive in charge: 嗯，搞业务的老大一般不管，IT你们自己玩吧，对照一下上面我写的例子，是不是现在还有很多这么玩的？

2）Limited User：少数人能访问，更少数人愿意访问。

     注：我讲个笑话，你们可别哭啊。真事儿！有次做项目，我就不说是电力的项目了，我问电力的IT领导，你们平时并发访问最高是多少啊？我指的是绝对并发。然后那哥们数了一下，IT一共7个兵，再加自己，嗯，8个，不会超过8个，确定一定以及肯定。

3）Data inconsistent and stoverpiped systems: 为啥没人看？有一定的原因是，数据不一致，烟筒系统

小结：IT一直是企业创新的先行者，因此也是最开始由的交互，为客户提供解决方案

第三阶段：Level 3， Focused，聚焦阶段，BI进入热恋期。

1）Funding from business unit on project-by-project basis: BU的老大们觉醒了（比如销售，比如财务），他们开始出资做BI项目了，也正式按照项目by项目的方式运作。

2) Specific set of users realizing busines values：一部分特定的用户群体，这里指的是真正有需求的业务用户，开始意识到BI蕴藏的商业价值。

3) Successful focus on a specific busines need：于是，开始成功的聚焦于某写特定的商业需求上面。

4) BI Competency Center(BICC) in place，而BICC在此时适时而生，需求太多，不组团已经没法弄了。

小结：各个部门的老大终于开始意识到BI的价值，纷纷出资，于是BICC在这种情况下出现。

第四阶段，Level4 Strategic，战略阶段。

1) Establish balanced portfolio of standards: 建立投资组合标准，也就是说将数据作为资产加以充分利用已经成为整个企业不可或缺的战略部分，每年都会有稳定的投资。

2) Business objectives drive BI and performance management strategies：企业的商业目标驱动了BI和BPM的实现战略。也就是说各个层级的人员背负的使命，也通过一定程度的量化，由BI和BPM系统化的进行辅助。

3) Deploy and enterprise metrics framework：创建企业级的KPI体系架构。

4) Governance policies are defined and enforced：创立监管策略以保证上述内容的实现。

小结：数据作为一种特殊的资产登堂入室，企业级量化绩效的模式需要BI和BPM提供强有力的支撑。

第五阶段：Level 5，Pervasive。无处不BI，浑然天成

1) Information is trusted across the enterprise：整个企业的各处，信息均可信赖。

2) Use of BI is extended to affilliates, patients, and business partners：BI的使用范围被进一步推广，不仅仅企业内部，还包括客户，合作伙伴等均能看到他们需要的信息。

3) Analytics are inserted into and around the business processes: 分析已经浑然天成的融入到各个业务流程之中。

小结：好吧，too perfect to be true，不过很多思想还是可以借鉴的，这是我们终生努力的目标。

---插播结束----

2. 全民BI

现在BI还流行一种概念，全民BI，未来数据应用的潮流。BI的最基本需求：所有决策均依赖于信息，决策有大小，小决策也同样需要信息的支持。因此，其实BI绝对不仅仅是高层和中层的需求，而是全员的需求。而当前很多BI系统没有得到充分的利用，很大一部分原因就是在于数据访问仅仅限于部分管理人员，尤其是集团管治下的模式，通常集团公司有充分的权限，需求设计也是根据他们的需求而来，而不是从底层一线人员之处获取，一线人员只能获取少的可怜的信息。而provide rightinformation to right people at right time by right way是Bi的使命。因此，未来的模式就是全民BI，每个人都他具有权限看的信息都应该有访问权，当下对于大型企业而言，如果能下达到一线经理，主管其实就已经很难能可贵了。

而众所周知，一旦BI访问权下放一级，就会带来大量并发访问压力，因此集团报表的架构一定是可扩展能力很强的架构。并且，全民BI意味着更加复杂的权限管理机制。这些，就是我们今天讨论这个主题的主要原因，因为这些问题都是需要平台去解决的问题。

此外，除了企业内部人员，还可以开放部分权限给合作伙伴访问，这个也是非常常见的平台级别应用。

3. 集团公司报表平台运营建议

结合上面的BI成熟度模型，大部分公司仍然处于低于

因此，要解决以上的问题，就要从企业级的视角去管理BI，并且需要组织/技术/流程等等综合在一起的复杂的过程。

并且，我们今天的关键词是 集团报表“平台”，需要去搭建这样一个平台，去充分发挥BI的价值。并且，只有做成平台模式，才能实现下面的需求。如何做成平台模式呢？

1） Organization: 组织，按照成熟度的要求，建立BICC，那么BICC是怎么构成的呢？

       Leader Team: 把控全局，包括客户，营销，运营，平台，等等，里面的核心成员是大Boss，Chief Architect, Operation Manager, Engagement Manager.

       Engagement Consultant: 客户前期需求探查阶段，深入和客户沟通了解需求并提供high level的解决方案，可以理解成Sales以及solution 团队。

       Infrastructure Specialist: 负责整个平台搭建，升级，维护，优化，监控等等，偏重于系统基础架构。

       Application Development: 平台的一些定制化程序，比如Security Control, Access Management, Audit等等公用的平台工具，由他们来开发完成。

       Application Consultant: 对业务理解精深，在项目中前期梳理需求并为设计提供帮助。

       Specialist: 设计和开发，对平台所支持的BI产品精通。这部分人群的核心人员都是产品方面的专家，根据项目的需求要求，动态合理的分配人力资源，因此会有相当比例的人从其他协力公司而来，招之则来挥之则去，但核心设计人员不可或缺。

       Operation Team: Maintain & Support，保证系统日常的正常运行，以及当系统或应用出现问题时能够及时应对，有的公司需要结合call center。一般都用ticket模式进行日常管理。同样，也会根据公司具体情况决定是否找协力人员来做，属于相对低端的工作。也会接一些小规模修改的需求，这个分工各个公司各有不同，也有开发Team来做的。

特点：长期存在，核心人员稳定，项目支持人员会动态变化。对于大规模需求，采用Project - by - project的方式实施，对于小规模需求或者Bug修正，由Maintain Team按CQ方式解决。

2） Technology：集团统一化BI平台

      a. 基础功能统一化管理，比如数据安全访问控制，访问审计，授权等等，统一的Portal, Email管理等。

      b. 选择可扩展，可信赖，成熟BI产品工具。对于不同需求，可以采购不同的BI产品，但部署于同一平台。如果普通报表，选用Cognos，高级分析选用Tableau，数据挖掘选用SPSS等，对于一些定制型的开发可以采用

      c. 最优化利用硬件，软件资源

      d. 统一化管理：Engagement管理，Project Management， Operation（Maintain & Support），Version Control，Knowledge Base，等等，这些都做统一化管理。

      e. 严格遵循公司的IT Strategy Compliance, 各位用习惯了D版的小朋友，别以为SAP，微软神马大公司不找你们麻烦，尤其是国际性企业，这种是会被狠狠打击的，告上法庭也能搞死你，只是在中国这种事见怪不怪了。

3） Process&policy：流程、方法论、最佳实践、知识管理

        提供的服务：

        a.  发布、运行

        有的客户自己有团队，也有现有的报表，但希望BICC帮助部署、维护和管理。

对于长期运行的BI应用，按运行的报表数量，使用用户的个数计算收费，提供不同级别的Support，比如将用户分为钻石，金，银等不同级别，提供不同的support。一般会用ticket的模式去管理，结合call center, email等接受信息的模式。制定Service Level Agreement，分请求的优先级等等。

       b. 咨询/开发模式

       对于客户有开发新报表的需求，可以提供顾问给出专业的建议和解决方案，并且提供开发/测试等环境，同时提出如果使用平台的规约，比如对于查询performance的要求，等等。对于特殊需求的用户，也可以单独分配硬件/软件资源，等等。

       c. 培训

       对产品的培训，平台使用的培训等等。

       d. 流程

       Engagement -> 了解基本需求->评估->然后根据实际情况报价->合同->然后调研设计开发之类，按项目实际情况而来。

BAO胖子一些观点:　仅供参考

1. 人永远是应用的核心，没有强有力的核心团队，其他一切都是空谈。

2. 不要妄图自上而下梳理出全部需求，too ideal to be true

3. 因此，集团的核心就是出正确的数据，唯一版本的主数据／参照数据，以及建立数据标准，至于下面部门以及分公司具体怎么玩，适度关注即可，不要太过操心，把数据权限下放给他们就好。

４.不要打包似的把整个服务交个某个乙方，也见过某大集团公司定制方略大部分给了一家大型咨询企业....然后会给你滥竽充数一帮烂人，BI全拼怎么写都不知道来做PM（真事儿，他一直以为Business Information呢）...不说了，毕竟友商。

5. 要有健全的知识管理体系

最后让我们回顾一下上面提到的各类问题，看看在BICC制下如何应对。

需求问题：

1. 虽然规模大，但有趣是有很多时候仍然不是企业级别的项目，而是最有钱或者最有实力（有话语权)的Business Unit (比如销售）出资，这样就只做自己的部分，其他的我可没钱去关心。然后公司就出现一种奇怪的现象，其他小部门呢？无人关心。他们也有需求啊！ -->小部门需求没人满足

A：由于BICC是长期存在的Team，并且Team中的一些人员会与协力公司有合作，因此只要有需求，无论大小，均可满足。并且，由于平台的完善，造成小部门的上BI系统的初始成本非常低廉，哪怕只有一张报表，也可以上线。

2. 集中化了，需求自上而下，集团公司爽了，下面忽然看不到想要的数据了。而下面的需求其实和上面有很大区别，即使是同样的Business Unit。 -> 信息专制，而又没有渠道让下级公司满足需求

A：前面提到的信息民主，而且BICC是完全开放的组织，不同于中央统一划拨经费的模式，他的计费模式是“报表运营费用”+“客户支持费用”+“设计开发费用”，只要下级公司有需求，并且有足够的funding, BICC会照单全收，因为也是BICC的业绩，不可能拒主顾于千里之外。

3. 对于企业没有专门BI团队配置的，还是按项目走，项目一旦结束，增加点中等规模或者小规模的需求很是吃力。  -> 更新，升级，增加小需求困难

A：前面提到过BICC是长期存在的Team。而且知识的传承是这种组织的核心竞争力之一，客户的报表也正在平台上run，所以这种更新，升级，如果是小规模的，完全可以在维护层解决。

资源浪费问题：

1. A部门有钱，B部门也有钱，OK，各自为战，你买Cognos做平台，我买BO，各玩各的。

    A部门有高级分析需求，用Tableau，殊不知B部门也有类似需求，但买了Qlikiew。  -> 软件License浪费

A：统一平台，目的之一就是为了软件资源的充分利用。

2. 硬件买多了浪费，买少了不够用；我就是月末用，平时都闲着；全球性企业，白天用晚上闲着，全世界多套系统均如此。 ->硬件资源需要优化

A：统一平台，目的之二就是硬件资源的最大化应用。

3. 信息安全（登录、授权）之类的通用型需求，重复建设。 ->基础建设管理成本增加

A：重要的事情说三遍，统一平台，目的之三就是减少重复建设。

4. 集团公司把权限全收走了，可分公司还有BI的人马呢，他们最通业务也懂技术，怎么办？ －＞人力资源浪费

A：BICC是开放的组织，完全可以分公司BI团队继续做报表，然后报表发布到BICC的平台上，由BICC做维护和管理。

架构问题：

1.随着时间推移，用的人越来越多，并发太多，根本无法使用。 ->架构不可扩展

A：所以说产品选型就非常重要，一定要选择经过实践考验的，市场成熟的BI产品。这种情况也要预估未来的变化，然后选择合适的ＢＩ产品，大部分知名的BI产品在可扩展性方面做的都不错。

2.选择过于小众的产品，虽然满足了一小部分需求，但community不成熟，产品功能不完备，造成后续新功能无法添加，人员难以配备，出现技术问题没有成熟方案和社区获得支持。  ->产品选型问题

A：所以说产品选型就非常重要，一定要选择经过实践考验的，市场成熟的BI产品的ｃｏｍｍｕｎｉｔｙ都成熟。

3. 若应用规模较大，可以更有效的获得产品厂家的技术支持，甚至为了当下迫切的需求，临时打补丁。从企业战略层面，和厂家深度合作也能获得更有利的折扣和其他优惠。    -> 产品Support方面

A：重要的事情说三遍，所以说产品选型就非常重要，一定要选择经过实践考验的，成熟的产品Support都成熟。

管理问题：

1. 没有BI建制的公司，乙方核心顾问闪了，自己的人没培养起来，回头还是做不出高质量的BI应用 -> 核心竞争力培养问题

A：BICC是核心，乙方不是。

2. 有BI建制的公司，BI人员苦逼了，都是企业内部需求，谁都可以让你做事，你都不知道听谁的，然后做了也白做，你自己都说不清楚你做了多少。优先级就是谁的声音大听谁的。   -->管理混乱

A：收费的模式按照SLA(Service Level Agreement)，将用户分为钻石、金、银、铜不同等级，根据客户的需求提供不同级别的支持。因此，管理优先级的问题就此能够得以很好的解决。

3. 用户看报表发现错误，不知道向谁反映 -> 维护支持管理问题

A：BICC有成熟的Support机制。最终用户可以通过call center, functional mail box，ticket system等不同的方式提交支持请求，Support的Leve1， Level2，Level3层人员，会按照Ticket的优先级进行处理。以确保用户有正确的渠道解决实际的问题。

对BAO胖子原创文章感兴趣的朋友，请关注我的公众号。