首先，我们有一个大的假设前提，集团报表平台是服务于大型公司，比如有很多分公司，子公司，多部门等，并且有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一直是企业创新的先行者，因此也是最开始由他们主导，但各种原因，开始用但效果一般。但毕竟已经开始尝试了。
第三阶段：Level3，Focused聚焦阶段
1）Funding by Business Unit on project-by-project basis：各个分舵的老大发现BI的重要性了，然后出钱，按项目by项目的模式做BI系统
2）Specific set of business users realizing business values：并且对于一些特殊群体的Business User也意识到BI系统的商业价值
3）Successful focus on business needs：于是开始真正成功的聚焦于商业需求，这也是这个阶段的典型特点，真正的用户需求纷至沓来
4）BI Competency Center in place：BI团队从此可以挺起腰板，叫能力中心了，是的，不组建一定规模的BI团队已经搞不定纷至沓来的用户需求了。具体BI Competency Center什么建制，下文会说
小结：各个分舵的老大们意识到BI的业务价值，因此开始舍得投入，并且用户开始真的参与进来，注意: 还不是企业级的。同时IT部门从前的仅仅几个搞BI的兼职小弟已经不够了，需要成建制的正规军。进入业务用户于BI团队的热恋期
第四阶段：Level4，Strategic战略阶段
1）Establish balanced portfolio of standards ：有个单词我很喜欢Harmony，就是这个感觉，就是要建立能够尽可能适合各路需求的标准
2）Business objectives drive BI and performance management strategies：企业战略级别开始注意到BI的价值（更准确的说是数据的价值），并将数据作为一种特有的资产于企业战略目标以及绩效管理能结合起来去驱动BI以及BPM（Business Performance Management）的实施
3）Deploy and enterprise metrics framework：构建企业级的KPI架构
4）Governance policies and defined and enforced：从高层视角制定政策以及强制执行
小结：大BOSS终于重视BI了，哦，应该是Data，BI是其中重要的部分。并且以Data作为一种特有的资产，进行战略层的应用。要结合企业的特点，梳理KPI架构，（先体系化），再辅以BI等系统贯彻之（在计算机化），并且制定政策以及强制执行（先僵化，再固化，再优化（任正非说的））
第五阶段：Level5，Pervasive无处不BI，我称之为...浑然天成
1）Information is trusted across the enterprise: 数据充分可信赖，在整个企业范围内，自然而然的信任数据，这个非常难得（发现一些单一ERP统一平台管理的企业这方面天然做的就很好）
2）Use of BI is extended to affiliates, patients and business partners：BI的使用者范围已经扩大到附属机构，最终消费者，以及业务合作伙伴（真正意义上的全民BI，不限于企业内部）
3）Analytics are inserted into and around the business processes：分析系统自然而然的嵌入在各个业务处理流程之中，浑然天成
小结：太难perfect，让我们一步一个脚印
总结：Gartner的Framework还是不错的，但请不要拘泥于此，只是一个借鉴和参考。
-----插播结束------
因此，要解决以上的问题，就要从企业级的视角去管理BI，并且需要组织/技术/流程等等综合在一起的复杂的过程。
并且，我们今天的关键词是 集团报表“平台”，需要去搭建这样一个平台，去充分发挥BI的价值。并且，只有做成平台模式，才能实现下面的需求。
2. 全民BI，未来数据应用的潮流
BI的最基本需求：所有决策均依赖于信息
决策有大小，小决策也同样需要信息的支持。
因此，其实BI绝对不仅仅是高层和中层的需求，而是全员的需求。而当前很多BI系统没有得到充分的利用，很大一部分原因就是在于数据访问仅仅限于部分管理人员，尤其是集团管治下的模式，通常集团公司有充分的权限，需求设计也是根据他们的需求而来，而不是从底层一线人员之处获取，一线人员只能获取少的可怜的信息。而provide right information to right people at right time by right way是Bi的使命。因此，未来的模式就是全民BI，每个人都他具有权限看的信息都应该有访问权，当下对于大型企业而言，如果能下达到一线经理，主管其实就已经很难能可贵了。
而众所周知，一旦BI访问权下放一级，就会带来大量并发访问压力，因此集团报表的架构一定是可扩展能力很强的架构。并且，全民BI意味着更加复杂的权限管理机制。这些，就是我们今天讨论这个主题的主要原因，因为这些问题都是需要平台去解决的问题。
此外，除了企业内部人员，还可以开放部分权限给合作伙伴访问，这个也是非常常见的平台级别应用。
3. 运营的模式建议
结合我经历过的项目，给出如下建议。
总结了一下集团报表的运营模式，三个重要的组成部分：
1） Organization：BICC（Business Intelligence Competency Center: BICC），逐步建立起对整个公司的业务的理解，对BI平台技能掌握精深，逐渐对业务需求熟知，对系统、数据的理解. 制定各项规范的核心人员。对照上面Gartner的BI成熟度模型中的BI Competency Center
在很多世界500强企业均有这种组织，而且成功已经实践多年。BI Competency的使命是：
a. 在企业内部建立长期，稳定的核心团队
b. 具备这样的配置：
Lead Team: 总控所有，开发，运维，支持，咨询，培训，项目管理等等，这个是管理团队当然也有大BOSS
Infrastructure Team: 搭建整个平台的能力，以及基础软件方面的升级、运维，优化，支持
Engagement Consultant: 最前期阶段需求初探以及初期规划，与客户前期的交互，为客户提供解决方案
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 -> 了解基本需求->评估->然后根据实际情况报价->合同->然后调研设计开发之类，按项目实际情况而来。
一些观点: 仅供参考
1. 人永远是应用的核心，没有强有力的核心团队，其他一切都是空谈。
2. 不要妄图自上而下梳理出全部需求，too ideal to be true
3. 因此，集团的核心就是出正确的数据，唯一版本的主数据／参照数据，以及建立数据标准，至于下面部门以及分公司具体怎么玩，适度关注即可，不要太过操心，把数据权限下放给他们就好。
４.不要打包似的把整个服务交个某个乙方，也见过某大集团公司定制方略大部分给了一家大型咨询企业....然后会给你滥竽充数一帮烂人，BI全拼怎么写都不知道来做PM（真事儿，他一直以为Business Information呢）...不说了，毕竟友商。
5. 要有健全的知识管理体系