作为项目经理如何开展BI项目

先说一下背景：BI项目采用商务采购方式，由乙方公司搭建，我作为项目经理，作为供应商和业务中间的沟通桥梁，协助乙方与业务人员、各大系统管理员之间的需求、技术交流。

1、指标初步沟通的流程

大致对接流程是：

1）、邀请各个业务板块的主要干系人，和供应商开项目启动会，加强存在感，BI是属于后知后觉的项目，存在感不像业务系统那么强，但BI的重要性和建设成本不亚于业务系统，特别是对于我们这种没有像样的BI系统的公司。

2）、供应商根据行业经验，整理出可能需要用到的指标，分模块，邀请相关业务人员沟通指标，大体定下需要实现的指标范围，这段工作断断续续大概用了一个多月。

3）、按照第二步的沟通，结合调研到的系统的数据情况，供应商、甲方项目经理、业务三方再进行反复沟通，进一步确定初步指标需求范围。

2、与数据来源系统对接

     和底层数据打交道是比较困难的部分，这个需要项目经理熟悉上游业务系统的功能以及数据，并且能够把业务人员说的需求，投射到对应系统功能上，找到对应的底层数据表及其关联逻辑。如果直接拿着指标和业务系统的人沟通，需要业务系统的人员花费一定精力去理解指标，通常会很困难，特别是在业务系统本身有一定任务的情况下，他们的配合度不会高，沟通起来会十分痛苦，一个字段通常需要等上一两天。

质量高的供应商团队会主动去熟悉源系统，理解源系统的业务逻辑，协助BI开发人员获取表关联，保证项目进度。如果业务系统和BI系统刚好是同一个团队或同一个公司，会相对好解决。但正常情况下都是一直催着业务系统，给出表等关联关系，而且信息往往同步不到位鸡同鸭讲，最后互相不理解。BI认为业务系统不配合工作影响了BI上线，业务系统认为BI占用时间，影响项目进度，吃力不讨好，进而导致矛盾。

这项工作一般都需要靠甲方人员去推动，并且要核对好数据的准确性，业务系统给逻辑关系会比较随意，经常导致BI返工，特别是在业务人员参与度低的情况下，甲方的项目经理等人员要多进行数据校验。

3、确认指标、确认原型

   这个阶段需要做好需求说明书确认工作，最好让业务人员及其领导签字，其中指标的业务逻辑定义一定要清晰，不仅要让业务人员能看懂，开发人员也能通过业务逻辑定义判断如何取数，同时也避免后续扯皮。报表的取数链路都比较复杂，很难让说清弯弯绕绕，业务人员理解其中的问题核心，一份清晰的指标说明和原型说明可以很好的避免大部分问题。如果有公司有审计部门的情况下，做好对应的流程文档，可以避免后期各种被质疑。

1. 做好项目管理工作

   项目进度安排，包含需求调研计划、开发计划，项目关键结算要每周开一次项目进度会议，及时记录、沟通、发现问题，同时做好问题跟进。项目按照计划上线是项目经理的头等大事，也是评估一个项目经理能力的重要指标。同时，项目上杂事很多，很多人做着做着就忘记之前需要跟进的事情了，所以要做个备忘录文档，避免跟丢事情。

1. 经验总结及后感

    对于BI这个项目，我对整体业务的情况有了比较详细的了解，后面也会知道组织这类项目项目经理需要完成，整理积累的文档（如指标）作为自己的知识沉淀，温故知新。总体来讲，项目管理是隐性知识占比比较大的工种。

经过这一个项目，成功涨了不少姿势，之前没有接触过甲乙方这种工作模式，不知道项目的立项、招投标、合同、验收这些流程，现在都大概知道基本流程。项目上需要谁配合，怎么才能让他配合的各种招数也略有领悟。

    我在的这个公司很多业务都不太对数据报表这块上心，各种需求确认也是糊糊涂涂的，给自己加了不少工作量。可能也是因为很多业务流程、系统都还在建立，没办法输出数据明确的需求。同时当时公司内也没有比较成熟的数据系统可以参考，所以这个项目完全是0到1开始做的。准确来说，那时其实没到能够做一个成熟报表系统的时机就开始在做了，这个为后期赶工、频繁改报表、口径埋了伏笔。

--未完待续

我从其他学习资料里也找到了我一直困惑但又讲不出来的地方，今天看到博文怎么建设中台。业务中台和数据中台的组织、支撑技术和方法论

里提到的”指标管理系统”需要让中台或IT人员统一规范好技术和业务的口径规范管理体系，到这里我才意识到，这个是导致本项目底层数据逻辑沟通障碍高的主因。进而我接触到了领域驱动设计的概念（Eric Evans著），深有启发，如果是刚踏入项目管理，像我这种人，这本书推荐读。