报表平台运营模式

浏览: 2848

贾岩:

各位朋友大家好,很高兴能参与今天的直播,今天主要给大家介绍报表平台结构,企业级数据仓库设计,数据挖掘应用,用户画像等内容,我们根据个人的项目经历以及个人经验,总结一些这方面的内容,跟大家进行知识的分享与讨论,在直播期间大家有什么好的建议或者想法,也可以与我们互相沟通与交流,那么现在开始我们今天的直播内容:

其实所谓运营模式,这个话题理解起来可能有点大,我就把我做过的项目的整体建设情况以及过程,整理了一下,虽然用的软件不同,虽然每个项目也会有不同,但是很多结构都是很类似的,我们可以加以变化,但是大同小异,变化都不会很大,这种集团性的数据平台体架构,基本是比较大比较完整的结构了。每个项目开始前,尤其是大型项目,基本都会成立一个这样的人员体系结构,如下图所示:

Clipboard Image.png

项目中有着明确的分工,尤其是大型国有企业,当然有些小的企业不会分的这么细致,这里不再做细致介绍,另外就是项目的整个过程 :

Clipboard Image.png

我们在制定一个项目计划的时候,会比这个更细致一些,这个是一个项目大概的过程。下面详细介绍每个阶段要做的工作:

需求分析阶段:

用户访谈、发放调研表、收集样本数据、编制需求报告

设计阶段:

架构设计、数据模型设计、功能设计、接口设计。并且完成相应设计文档。

例如:《系统设计报告》、《公共数据模型建模报告》、《BI应用功能设计》、《ETL设计报告》、《物理数据库设计报告》等。

环境搭建阶段:

确定硬件需求、编写技术规范书,招标采购,并编制《实施方案》、《应用软件配置方案》、《ETL部署配置方案》、《中间件配置方案》、《数据仓库部署配置方案》等。

系统开发阶段:

开始根据需求进行程序的开发与部署。

系统测试阶段:

根据项目的不同,测试的内容也不同,需要明确了测试工作内容,通常包含开发测试和现场测试2个层面;测试内容包括单元测试、出厂测试、上线功能测试、性能测试等等测试内容。并且需要编制完成《测试用例》、《测试报告》等文档。

系统试运行阶段:

进行整体运行的测试工作,包括接口、数据、系统集成等。

每个阶段都会都会产生相关的项目文档,这些文档是作为项目下一步执行的依据。

当项目结束之后,也会有一个相应的团队来进行维护。这个结构可以根据项目的大小,以及结构的复杂度而定,如果是长期项目,那么一期结束之后这个团队就会成立,在项目的二期建设中,同时也要保证一期项目的稳定运行,这里面我只是列举了一些大概的运维情况,以及运维的内容,只作为大家的参考。

l  服务支持队伍

服务支持队伍可以包括这样一些工作:服务台,事件/问题,变更,版本和配置管理,以及场地和一些非IT设施的管理。

l  技术支持队伍

技术支持队伍包括这样一些工作:
    Ø  存储服务支持

存储管理员负责数据平台尤其是数据仓库存储(备份、归档)的计划,配制,管理及故障排除等工作,并协调数据平台所有其他业务应用系统中有关信息存储的任务, 包括数据备份和恢复,数据归档及恢复。具体体现在存储区域网络,本地数据复制应用,远程数据复制,容灾,业务连续性,存储容量的分配,性能监控等任务。

Ø  数据仓库服务支持

监控ODS、数据仓库、数据集市的运行状态、日志文件及空间使用情况,并对系统资源的使用情况进行检查,发现并解决问题。监控数据库对象的空间扩展情况,并就数据库做健康检查,寻找数据库性能调整的机会,进行数据库性能调整,并以此提出下一步空间管理计划。

Ø  网络应用支持

实现对整个网络的设备配置、监控、动态运行分析、安全、问题诊断、流量控制以及虚拟网划分和管理等工作。使网络的运行更能符合企业实际应用的需要,达到网络高速有效的传输和安全可靠的使用。

以上,是我对于企业级数据平台的整个建设,以及后期收尾后进行维护的一个大概过程的理解。因为时间关系,暂时介绍到这里。下面请另外两位嘉宾发表一下自己看法:

BAO胖子

BI发展历史:最常见的传统模式之一自下而上

首先我们今天的话题是:集团公司级别报表平台运营,关键词有俩:一个是集团,也就是说是企业级的,俯瞰整个企业的视角;二是 平台,是一个能够容纳各种BI应用,并且能行之有效的运行起来的一种机制。我们有一个大的假设前提,集团报表平台是服务于大型公司,比如有很多分公司,子公司,多部门等,并且有BI需求的访问人群超过1000以上的公司。这里稍微讲点历史,先看最常见的传统模式: 

最典型的各个分公司或者部门,有一定的IT经费,然后各自为战,会雇佣一定的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. 麻雀虽小五脏俱全,充分锻炼和培养了人的综合能力,不过绝大部分都是乙方的人。是的,我们很多人就是这么成长起来的。

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

BI发展历史:最常见的传统模式之一自上而下

再后来,一些信息化建设基础比较好的企业,就开始做省级(或者全国级,当然也有全球级别)的集中,这个时候通常的大前提是,业务系统已经在集团公司集中了,比如ERP,CRM,SCM这类系统的集团化使用。这种情况下势必带来BI系统的升级换代,这个时候的需求是自上而下的。

这部分我强调一下,我极力反对ETL是整个企业BI系统建设的核心,最重要的还是直指value的BI应用,我提及的这种场景下的项目,眼下其实很多,经常是大国企

这里存在多种有趣的现象和问题,列出一些但不限于此:

需求问题:

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

这个我有必要说明一下,是这样的,我曾经遇到过一些项目,项目的规模很大,但其实出资人不是企业的cio办公室,而是某个具体的部门,比如移动的话,可能是就相当于移动的业务部门,他的财务、hr不会参与其中的,从建的规模来看好像是企业级的,但其实很多business units很多都没有纳入进来。

 而在这种情况下建设的bi平台实际上只是解决了他企业当前这一个部门的业务问题,没有想到去解决其他部门的业务问题,为什么我要提平台的概念,就是应该是从CIO的角度来讲,我去建一个更大规模的平台,能够纳入其他各个部门的需求。

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

这个问题也非常常见,集团公司定需求,往往忽略下级的需求,而下级有需求,但没有渠道做做,自己希望立项去做相关项目,又没有数据资源,因为都在集团手里,所以需求就湮没了。

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

 这部分我有必要强调一下,就是说有这种情况,企业没有专门的bi团队配置,按项目走以后,项目一旦结束,中间去增加一些中等规模小规模的需求就很吃力,一定要等到下个项目来了以后才能解决这种问题,而bi这种应用实际上来讲是长期的应用,是随需而变的,当我市场来一个需求,我要很快看到这个信息,但时间一旦错过,要等一个项目启动,这个周期很长,她就把这个需求错过了,可能就会错过市场的商机。

那这种模式又会造成什么问题呢?

资源浪费问题:

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

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

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

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

架构问题:

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

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

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

管理问题:

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

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

3. 用户看报表发现错误,不知道向谁反映 -> 维护支持管理问题。 
林林总总,可能还有很多,各位看看是不是自己公司也有类似的问题。这里需要上一张BI的成熟度阶段图,可以看看处于什么位置。

Clipboard Image.png

BI发展到现在,我们该如何做?

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

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

1) Organization:BI核心团队,逐步建立起对整个公司的业务的理解,对BI平台技能掌握精深,逐渐对业务需求熟知,对系统、数据非常了解,并能制定各项规范的核心人员团队。
2) Technology:集团统一化BI平台
      a. 基础功能统一化管理,比如数据安全访问控制,访问审计,授权等等。
      b. 选择可扩展,可信赖,成熟BI产品工具。对于不同需求,可以采购不同的BI产品,但部署于同一平台。
      c. 最优化利用硬件,软件资源。
      d. 统一化管理
 3) Process&policy:流程、方法论、最佳实践、知识管理
     a.部署模式

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

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

d. 流程

Engagement, 了解基本需求,评估,然后设计开发之类。

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

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

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

 内容总结:

上面讲了那么多,大家一时也不一定消化得了,我这边再总结一下,强调一下我讲的内容:

全民bi,如果大家经常访问天善的网站,就会发现我们经常会提到全民BI这个概念,全民bi,实际上指的是信息的民主化,就是说每个人其实他都有权利去访问他可以访问的数据。我们平时做的bi系统,他就会有这个问题,你会发现只有个别人能访问bi系统,平时很多人他想看都看不了数据。这个不是他没有需求,而是说通过集团式控制的手段,当他需求没办法释放出来,但如果需求一旦释放出来,就要求你的系统架构足够稳定,支持多并发,以及去能够应付复杂的授权,以及数据安全管理这种需求,你才能把这种数据下发下去。所以说这部分分为三块来看,一个平台怎么把它运营起来,首先就是有人,有核心的人,包括consultant顾问,包括前面贾岩说的,团队要有做support,做开发的,团队配置要全。

 此外,要建立一套平台,后面老头子和贾岩有更详细的描述这个平台怎么搭建,就是有一个技术性搭建的环境,能够支撑你这个应用,包括安全性,多扩展,种种能力,提供服务给相关的使用人员。

 最后还有一块是流程以及相关的知识管理相关的一些东西,这个话题非常大,可能要讨论很久的时间,如果有人感兴趣,我们后续可以再开课题详细讲,就是说我有人有物了,我可以把平台理解为物,我也有客户了,我怎么通过一种手段,让这个大规模的机器有效的运转起来,这就需要流程来规范,我要跟客户去谈你的需求是什么,我来帮你解决,你需要我提供什么样的服务,有可能我有需求做报表,但我没有足够的人,你可以提供senior的人去做需求做开发做设计,有可能我有报表我有人,但我没有平台来发布,我可能要你的平台来发布。另外一个问题,我还有support,我support怎么来做,就是说我发布上去之后,我怎么能保证每天正常运行,当出问题的时候我该找什么样的人来解决,这个需要一套行之有效的流程以及人员责任管理制度完善起来。这个话题很大,今天的介绍就到这里,如果还有另外的需求,咱们可以稍后再谈。

老头子:

两位大师说的都很全面了,我就简单说下我的理解: 

一般来说业务提出需求后,IT侧BA与业务人员会议交接,IT侧提出业务解决方案,并与业务人员串讲需求,确认无误后,输出需求文档,由业务人员评审和签字。

IT业务BA传递实施需求,IT侧进行模型设计、架构审核等,输出需求设计文档,将业务需求转换成IT需求(这一步一般来说是各个企业信息部门的痛点,很大部分需求就是在这里变形的)。

然后IT技术人员进行:开发、测试巴拉巴拉巴拉,开发完成后,业务测参与UAT测试验收,验收通过后进行签字确认并上线部署。

这也是我们经常说的一个大体的开发流程。

版本上线后开始试运行、系统监控等维护工作。系统、数据稳定后根据业务需求规划进行新一轮的调研、研发。

以上是一个理想的良性循环流程,期间的进度把控、风险预警、版本质量、需求控制等需要管理人员进行把控、接口。一个好的管理者可以平衡业务与IT期望、保持良好的合作关系。其他的再讲是重复了,我就说这么多吧。

推荐 0
本文由 天善智能 创作,采用 知识共享署名-相同方式共享 3.0 中国大陆许可协议 进行许可。
转载、引用前需联系作者,并署名作者且注明文章出处。
本站文章版权归原作者及原出处所有 。内容为作者个人观点, 并不代表本站赞同其观点和对其真实性负责。本站是一个个人学习交流的平台,并不用于任何商业目的,如果有任何问题,请及时联系我们,我们将根据著作权人的要求,立即更正或者删除有关内容。本站拥有对此声明的最终解释权。

0 个评论

要回复文章请先登录注册