一个500人天的BI项目实施记录

导语 

这是一个来自拥有百年历史金融企业的BI项目。十年前,该企业已经全面上线BI,并在过去十年中为企业的经营管理与决策提供了强有力的支撑,但是随着十年来数据的积累及技术的迭代,企业原有BI产品及系统支持新的需求已经越来越吃力,在此背景下,该企业全球招标,寻找更优的产品及解决方案进而使其数据可以最大化发挥优势。

历经一年的产品选型及实施商选择,最终该企业选定MSTR作为更新升级的BI产品,并邀请多家实施商竞标,德昂作为拥有十年BI实施经验的专业数据服务商最终胜出,于是德昂入场,一个500人天的项目开工了。

 

了解项目相关方,并从其获得项目目标

相关方的满意是项目成功的终极目标。

 

 

我们优先分析客户方的需求和期望。作为企业高层,期望从原本在邮件及web上查看数据的方式,转由在手机端等移动端查看,能更灵活更及时地获得数据。作为IT数据中心,期望速度提升,目前BI系统因为数据量增大及十年业务逻辑的增加,一个典型的问题是报表越来越多,速度越来越慢。作为业务分析人员,期望模型能更易用,更方便自主分析及探索数据。作为终端用户,期望不要变更原有的使用习惯。这是第一个层面的需求分析。经过进一步的分析与访谈及焦点小组会议,最终还明确项目的潜在需求,新产品替换必须在半年内完成测试验证并实现无缝替换,作为一期项目,成本需控制在500人天,而验收方式为两套系统并行测试,数据必须完全一致。相关方的需求收集完成后,一个项目的可量化的目标就成型了,范围进度成本质量目标也清晰起来。

范围计划

项目规划阶段优先约束的是范围计划。

 

在实际了解后发现,当前原系统中已经存在超3000张报表,而在时间和成本的约束条件下,很难全部在第一期中全部移植。经过数轮会议沟通,对所有报表进行分级和分类,最终锁定关键报表300张,这300张报表已经变成缺一不可的内容,而再进一步分析,发现通过数据仓库模型重构,可对其数量大幅压缩,约100个数据集可完全覆盖这些报表内容。范围确定后,就开始准备进度计划。进度计划的输入主要为工作包与人力资源。德昂的项目策略一直是小步快跑迭代式开发,因此我们将分析的内容进行主题和模块划分,拆分为多个主题模块。而人力规划方面,德昂多年实践拥有着被内部戏称为“特种部队”的组织形态——项目现场保留“特种兵”,而后方“五角大楼”给予近乎秒级的响应支持,让“特种兵”可以最快最精准地完成交付,这个独特的模式是多年实践磨合的成果,具体运作协同机制无缝。在交付包的依赖关系分析完成,并依实际现场工程师特性排好后,结合此项目为BI升级移植项目的特点,团队特别在启动的第一天开始加入技术验证环节,因为项目有个潜在需求,就是原有的功能特性及用户使用体验不能少,若有体验上的差异,这个技术风险需要给项目留足时间来应对。

项目分析识别与应对

按照德昂项目的实践指导建议,项目分别从人、机、料、法、环五个方面对项目风险进行识别并给出对应的应对计划与方案。
 


 风险分析之“人”
 

经过内部团队人力及客户人力分析,德昂针对此项目分别从两岸三地组成最适宜的团队,并与客户磨合出更佳的沟通模式,并形成项目沟通计划。

 


风险分析之“机”

 

十年的积累让德昂对MSTR的应用和实施已经游刃有余,但是此项目涉及了之前的另外一个原BI产品,要想把原产品更好的替代,德昂利用业余时间对此产品进行了充电学习,充分了解其特性后,创新性地设计了导出并通过XLST转换脚本,让原来的庞大仓库模型可读性大大加强,实际业务需求就在这里开始破冰;但是在实际测试和验证过程中,仍然发现两个产品的特性差异,为了不影响用户使用体验,德昂综合利用服务器特性,并结合自主开发的程序来补充,最终设计出整体解决方案,不单能实现主动条件触发(原产品一个特性),还实现被动触发机制。
 

 风险分析之“料”
 

对于BI项目来说既关注原始数据,也关注最终交付的成果数据;数据质量问题一直是BI项目成败的一个关键风险因素,因为低质量的数据直接导致最终指导决策数据的可信度,因此项目从开始就引入数据质量检查机制。而在交付成果上,这个项目因为原仓库已经运行十年,十年来数据仓库不断发展,存在大量的冗余结构及ad-hot表结构,业务逻辑分散在五层结构中,很难从上向下地分析业务逻辑。德昂人的技术功底与拼搏精神在这个风险应对上充分体现,面对动辄上千行的最终机器生成SQL代码,屏住呼吸一个个攻克下来,确保了对业务逻辑理解的一致性,因为人可能逻辑出错,但是机器不会撒谎。
 风险分析之“法”

这里的方法有两个内容,一个是协作方式,一个是验收方式。在这个项目中,典型的就是ETL工作的协作,这样客户的工作进度与乙方的工作进度形成了硬逻辑依赖,这个风险点很容易造成项目进度延误,因此作为重点风险来监控。在实际项目执行过程中,项目组设计了模型比对脚本与数据检查脚本,每日定时自动跟踪进度,及时发现异常及调整工作内容。在验收方式方面,因为要求是与原报表完全一致,因此针对此项目,项目组设计了“双脚本核对”法,通过两个步骤编写两个脚本,经过三次核对分别对应不同的处理方案,最终确保了项目交付符合验收标准,针对每个报表,均独立编写测试报表,测试报表描述了比较基准/逻辑验证结果/数据验证结果/报表执行状况/异常问题(关联到问题库), 并对报表的其他配置情况均做详细说明,确保交付给客户时方便使用。

 

 

 风险分析之“环”
 

环境包括软硬件的客观环境及主观环境。在客观环境方面,BI项目通常都不可避免需要保护数据安全,因此通常在受控环境下实施,德昂已经积累了足够的方案来应对这种方式,内网出去,外网进不来的问题在风险库里面都有成熟解决方案。而对于主观环境,通常是客户需求的不确定性导致,一方面,客户总在见到实际成果时才知道要什么,针对这个风险,德昂的策略为,先画原型并做多套方案,便于及早确认。另一方面,有些变化是不可预知的,这个需要靠经验,将变化部分与稳定部分进行解耦,变化部分设计为可配置的,未来在变化时配合即可,最终做到在交付时免代码调整。
 

 

项目执行与监控阶段

 


在项目实施过程中,实际进度与规划进度总是会有偏差,而这个时候需要一张项目管理的全景图来帮助及时发现异常并及利及时纠偏。而这些则通过德昂项目管理流程来保障,从表现层来看,是通过项目日报,项目周报,项目各类会议来保障的,而在底层则是由十二类底层数据作为支撑。德昂在项目管理方面,充分发挥对数据加工处理,进而为项目管理层提供决策支持的优势。

 

项目管理工具之项目日报
 

在项目的执行过程中,德昂每日发布项目日报给项目相关成员,项目日报概述中说明当日的工作内容,当前尚未解决的问题及潜在风险状况。针对项目不同阶段,附上不同的项目成果及重点问题跟踪进度。
 


 项目管理工具之项目周报
 

项目团队成员可通过项目综合看板随时关注到项目执行健康状况。也可以显著看出项目的实际完工工作量与序时进度的差异,若出现偏差,也可进一步分析是否有超过管控红线,若超过第一条红线,则表示需通过赶工或快速跟进方法来进行项目调整,若超过第二条红线,则需要通过发起项目变更申请、或增加人力、或延长时间等方法来确保项目利益相关方能够得到预期结果。针对数据仓库的健康状况也能得到及时的了解。针对项目出现的问题,我们不仅关注问题的解决状况,更关注其对应的优先级及OPEN时间,以避免重要问题持续不能解决。


 项目管理之需求管理
 

项目范围来源于项目原始需求,为确保项目范围的可控与聚焦,避免范围蔓延,德昂采用需求双向管理,在需求库与交付库之间建立双向跟踪关系,同一个需求可能在实际实现中被拆分,多个需求也可能被同一个交付来覆盖。针对每个需求,我们不仅仅了解需求的内容,还要对需求的管理目标、应用场景、分析思路都进行逐一分析与了解。在实际项目执行过程中对各个原始需求的覆盖执行进度进行图形化的监控。
 


 项目管理之覆盖率分析

 

项目涉及多个部门,每个部分当前的交付情况及覆盖状况则主要通过覆盖率分析报表来分析。单某个模块整体出现停滞时,则需要召开专题会议来推进,避免出现明显短板及部分模块的相关人不满。
 


 项目管理工具之周任务看板
 

每周任务优先级排序。每周周会,项目团队会针对当前项目的各类任务进行优先级及紧急性排序,进而明确执行顺序及关注焦点,确保项目稳定向前推进。
 


 项目管理之问题管理
 

针对项目中出现的各类问题,在提交问题时,我们不仅说明问题发生的时间及具体现象,还对问题进行深入剖析,得知问题的影响分析,看问题对交付物的影响状况,针对数据类问题,还给出对应的脚本以便问题重新排查。
 

项目管理之进度监控
 

在项目交付物执行情况中。我们坚持用数据说话,针对每个交付物的当前状况进行细分,分别针对需求进度、模型进度、数据进度、开发进度、验证进度进行数据跟踪分析,这些数据最终确保项目的实际进度准确有效,给项目的整体控制提供数据支撑。
 


项目管理之交付物执行报告
 

作为一张管控交付物明细报表,在交付物执行报告中,项目团队不仅说明项目交付物的交付状况,综合采集了问题库、任务库、日志库的各类数据,统一呈现出完整的执行情况。说明交付物什么时间点提交测试、当前没有关闭的问题数、已经投入的工时数、预计仍需要投入的工时数等,完整的情况更利于项目利益相关方得到详尽的信息,进而确保项目稳步向前推进,如出现偏差,也能及时纠偏。

 

项目测试验收阶段

针对不同的项目,德昂团队拟定不同的项目测试执行计划。多轮测试的测试重点各不相同,最大效率地执行。
针对此项目,项目规划了四轮测试。第一轮测试开始与BI系统部署移植到生产环境后,此时后台数据仓库接测试数据仓库,设计原理在于将数据问题与BI开发问题隔离解耦分析,BI报表逻辑与数据逻辑单独验证。第二轮开始,BI平台与数据仓库全部切换到生产环境。第三轮的特点在于优化与删除冗余。第四轮处于待命观察中,任意问题均可在较短时间范围内排查并修正。

进入项目验收阶段后,项目组针对每个提交的交付物,都明确了对应的验收标准及验收人。验收执行报告除标书静态信息(发布时间,最后修改时间)外,还发送验收阶段的执行情况,执行情况包括报表的最后一次执行情况(执行时间、耗时、访问数据表数量,范围记录数量),为方便比对参考,同时汇总测试阶段累计执行情况(平均耗时、最大耗时、最小耗时),在统计耗时的过程中,抛出了缓存命中等各类干扰信息。

 

 

经过500人天的努力,一期项目最终交付给客户并取得客户的认同。一期的成功上线促使了二期的快速立项,目前此客户的二期已经在立项准备中。

总结来看,项目的成功推进,德昂的三个特色发挥了重要作用。

第一个是“特种部队”的组织形态,让前方“特种兵”可以在各种约束条件下交付。

第二个是完备的风险库,多年的项目实施经验使德昂的风险管理库不断完善及充实,更好地确保项目的成功执行,在这个风险库的保驾护航下,项目都如期到达预期的目标地点。

第三个是项目管理的工具库,十年上百个项目的实施,已经磨合出一套实用的适用BI项目的组织过程资产。

 

内容:马哥

图片:马哥、蕾蕾

编辑:刘京

审校:青色山脉

  • 3
    点赞
  • 14
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
目录 2 一、 前言 5 1. 定义 5 2. 用途 5 二、 BI项目二期建设目标 5 1. 系统的功能体系结构概述 5 2. 总体功能体系结构说明 6 1) 日常业务报表 8  定制脱机报表 8  联机报表查询 8 2) 业务探索式分析(OLAP) 8 3) KPI指标分析报告 9 3. 系统流程 10 1) 系统总体流程 10 2) 日常业务报表处理流程 11 3) 业务探索式分析(OLAP)处理流程 12 4. 数据说明 12 1) 总体数据说明 12 2) 系统数据来源详细说明 14 3) 日常业务报表分析处理数据说明 14 4) 业务探索式分析OLAP处理数据说明 14 5. 系统界面基本形式 15 三、 某零售集团BI系统运行环境 15 1. 软件环境 15 1) 软件环境配置图 15 2) 软件环境配置说明 16  客户端软件 16  BI应用 16  中间件 16  数据库管理系统 17  操作系统 17 2. 网络与服务器环境 17 1) 网络与服务器配置图 17 2) 网络与服务器配置说明 18  某零售集团信息仓库ODS服务器配置 19  某零售集团信息仓库OLAP服务器配置 20  某零售集团信息仓库Web应用服务器配置 21 四、 某零售集团BI项目需求分析的任务概述 21 1. 对一期需求业务的重新整理、归类、筛选和补充 22 2. 跨业态商流、物流分析 22 3. 决策支持系统 22 4. 数据交换平台 22 五、 某零售集团BI项目需求分析的对象 23 1. 区域/业态 23 1) 中等超市业态子公司主题分析 23  运营分析 23  商品分析 24  合同 24  订货 24  销售 24  旬报 24  供应商 24  品类KPI指标 24  品类组KPI监控 24  品类组业绩监控 24  供应商分析 24  供应商基本查询 24  供应商供应结构分析 24  供应商供货能力分析 24  供应商销售分析 24  供应商库存分析 24  供应商贡献度分析(KPI) 24 2) 加盟店分析 24  进货分析 25  销售分析 25  库存分析 25  要货分析 25 3) 大卖场业态子公司主题分析(将来纳入) 25 4) 便利店业态子公司便利主题分析(将来纳入) 25 5) 江苏分公司主题分析(将来纳入) 25 6) 浙江分公司主题分析(将来纳入) 25 2. 跨业态商品分析 25 1) 定牌商品主题 25  销售主题 25  库存主题 25  定牌商品结构分析 25  定牌商品供货能力分析 25  定牌商品贡献度分析(KPI) 25 2) 联合采购商品主题 25  供应商主题 25  库存主题 25  销售主题 25  联合采购效果评估(KPI) 25 3) 生鲜商品主题 25  销售统计报表 25  销售跟踪报表 25 3. 中仓分析 26 1) 中仓库存分析 26 2) 中仓进发货分析 26 3) 门店向中仓要货统计 26 4. 决策分析 26 六、 日常业务报表分析的详细内容 26 七、 多个业务因素、多角度、随机式探索式分析OLAP 26 1. 探索式分析功能概述 27 2. 探索式分析的形式 27 3. 探索式分析所提供信息内容 28 4. 探索式分析的基本操作 28 八、 决策支持系统 29
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值