2021年4月份我主持的项目集团数据仓库、BI平台正式结项，在整个项目的建立程中有问题也有很多感触，今天和大家分享下整个项目的过程和后续收尾作的一些经验。一、项目立项阶段在项目立项阶段首先要确认自己企业所处的阶段，可以根据所处数据准备阶段匹配项目选型，包含系统成熟度、数据规范程度、主数据建设情况、数据储备量、指标规则与逻辑梳理程度、业务部门分析需求程度。1.1系统成熟度这里不是指的itil3里面的系统成熟度，是指企业中各项业务的系统使用情况及各系统之间的数据贯通性，企业中各项业务信息化的程度直接决定了后面所有条件的好坏，一个成熟的业务软件环境代表着业务逻辑已经梳理清晰且稳定，业务软件环境运行的各项成果较好，能够将工作过程与结果变为规范化的数据存储起来，这些数据就是数据仓库与数据分析的基石。例如餐饮行业如果从原材料入库到出品到销售全过程都数据化，那么数据仓库中指标一定更细、更多，而BI可分析的一定更多。但是如果只是销售使用了系统，那么BI中的分析主题只能是销售指标。1.2数据规范程度数据规范程度与系统有着很大的关系（手工提报则是和实际操作人有很大关系），当一个系统与业务的贴合度越高，那么他的数据逻辑和数据规范程度一定越高，因为业务系统在使用的过程中，系统是固定的而业务是随着环境等变化的，哪怕一开始是根据业务实际贴身制作的系统，随着业务的不断变化，系统中一定会逐渐废弃一些操作步骤，那么整个业务链条就会产生废数据，这些废数据会随着原来的系统逻辑产生更多的废数据，就造成系统中的数据质量越来越差。例如一个培训系统，一开始的业务逻辑是开班-选择学员-给学员配课-结课/讲师评分-毕业，但是随着使用的过程业务逻辑将学员配课那个步骤变更了，那么后续的结课讲师评分与结课毕业等后续步骤一定会产生废数据，而这些废弃数据在数据分析的过程中一定产生很多噪声。1.3主数据建设情况在很多的时候说起主数据建设的情况，甚至是信息化人员都不容易说出主数据到底有什么用，但是一旦你使用BI分析的时候特别是在做复杂的企业全链路分析的时候，你就会意识到没有主数据，你所作出的数据分析得出的结果是混乱的，没有一点用处的，因为企业全链路数据是根据业务贯穿起来的，但是各部门的系统如果未进行主数据管理，那么每个部门对不同指标的名称、定义、逻辑等都不同的时候，问题就非常严重了。例如财务部认为利润总额应该是去税的，但是相关部门却在计算的时候将税加上了，或者是车间的良品率指标在生产部定了三个指标决定，而在车间则是直接通过两个指标定义，那么结果就是混乱。1.4数据储备量这个其实非常好理解，统计学里面的大数理论（大数定理简单来说，指得是某个随机事件在单次试验中可能发生也可能不发生，但在大量重复实验中往往呈现出明显的规律性，即该随机事件发生的频率会向某个常数值收敛，该常数值即为该事件发生的概率），当你有3000条数据的时候，你分析的餐厅菜品受欢迎程度排行榜和你使用3000000调数据分析出来的一定不一样。（注意时间维度，时间维度的长短也是一种指标）。这也是为什么做快消品分析的分析师都偏爱敏捷BI，因为在使用的时候除了有很多实用的工具、函数之外，最重要的是敏捷BI在大数据量的时候表现（上百万、千万条数据）。1.5指标规则与逻辑梳理在所有的分析建立之前，只有数据没有指标就像让你拿着购物清单直接去仓库里面买东西一样，你会无从下手。只有根据业务将各项业务指标梳理清晰，然后将指标之间的关系逻辑梳理清楚，这时候你才能在数据中，通过数据化的指标在不同逻辑层面进行分析，从而得到你需要的结果。在梳理业务指标与逻辑进行数据化的时候一定要注意两点： 1.5.1业务指标指定要是可变的不能写死，将指标拆分到最底层数据分类，一旦将指标写死后续的业务变动就会造成分析体系重新拆分修复。将所有指标拆分到最小分类，然后不断汇总到指标。这样不管业务如何变化只需要调整类别或者分类就可以应对变化。 1.5.2业务指标逻辑通过系统或者模块控制，不能把逻辑写死，原理同上。1.6业务部门的分析需求所有的系统都是被需求才会出现的，不管是管理层需求还是业务部门需求。在BI建立之前一定要确认现有各业务部门对业务分析需求的程度然后进行排序，这样你在推广的过程中就可以由重到轻的去推广，让重需求部门逐渐带领或者引领轻需求部门。通过以上六个方面（个人经验会有不全，欢迎指正），可以判断企业所属数据需求阶段是数据展现还是数据分析阶段，然后通过不同阶段选择不同的环境，如果所处的是数据展现阶段，那么通过集团数据仓库+报表平台先将数据整体梳理好，然后展现。如果是数据分析需求阶段，那么通过集团数据仓库+敏捷型BI快速实现业务人员主导数据分析。二、数据仓库与BI实施阶段在项目实施阶段分为技术选型，技术体系（指标数据化体系）两个方面比较重要。2.1技术选型技术选型阶段首先要根据现有数据量与未来3年左右的数据量预估，通过这些确认数据仓库所使用软件的技术选型，中型数据库与大型数据库（大型数据库可考虑通过建立date lake替代）在选型很清晰。而技术在3年的时候一般会有较大的革新。根据企业的数据量级可以选择直接建立企业数据仓库或者是建立集团大数据湖上面在架构集团数据仓库。在数据仓库方面在实施的过程中要注意分层，标准数据仓库是分五层，但是在实施的时候除了非常规范的企业，一般是分两层或者三层。在分层的时候在贴源层（ODS）建设的时候要注意一点是，一定不要忽略无系统数据的导入，哪怕尽量使用系统流程提交也不能导入，不管导入的规范有多标准一定容易出问题，而除了系统直接抽取数据之外会有一些导入数据（成熟度较低），这些导入数据最好通过流程进行规范。保证数据规范及准确性。在建立汇总层的时候看历史数据的数量级，建议在建立DW层的时候一定要一次性导入历史数据后，在汇算规则上建立好限制历史数据不计算。在DM层也尽量将历史数据与实时汇算数据分开，即使不分开也一定要做好汇算规则隔离，避免出现历史数据混乱。BI系统在选型的时候现在基本上以敏捷性BI为主，对业务人员比较友好，现在市面上的敏捷BI只要是大厂基本没什么问题，但是切记一点，BI对实施团队要求非常高。特别是在分析指标数据化方面，技术团队的经验可以让你避免很多坑。2.2技术体系在项目中由于工期较紧且乙方团队有变动，在此次项目中我作为项目经理却没有过多时间进行项目管理，而是耗费较大精力进行技术支持。在项目中只是将BI系统的驾驶舱页面逻辑技术参数进行了确认，而数据仓库和BI驾驶舱的参数体系只是在后期进行了规划，未能在前期进行整体进行技术体系确认，这也造成在后期出现了些问题。2.2.1数据仓库的技术参数这里指的不是你去参与数据仓库的技术开发，而是你要在建立之前，确认整个数据仓库的分层架构（根据业务复杂度），整个数据仓库的汇算逻辑、整个ETL数据清洗过程的整体架构。保证数据仓库在清洗汇算及展示层的正确运算关系。特别注意汇算过程的全刷和递增，ODS层的变化是否保存等。2.2BI驾驶舱页面参数体系与页面逻辑在BI驾驶舱建立的过程中，项目初期过多的关注页面逻辑，为了保证页面分析逻辑块与页面之间的跳转关系及填报关系等，忽视了比较重要的页面参数体系，直到项目前台开发完一个驾驶舱之后才发现整个页面的参数混乱、参数名称不一，与前台技术人员沟通后进行参数名称统一的修改，结果驾驶舱崩溃，当时也在工期和规范性上犹豫了，但是庆幸当时坚持了原则，宁可返工3天也要重新规范。如果整个驾驶舱体系参数混乱，在后期维护及下一期开发的过程中会出现很多不必要的问题。三项目收尾所有的项目在结项的时候，对所有的技术文档、开发文档、问题清单等都会进行严格审查，这些我就不说了。在这里分别就数据仓库及BI在验收的时候应该注意的一些事情进行分享。3.1数据仓库在验收的时候一定要进行全量备份，然后分别从全量ETL、单ETL流程、ETL片段三个方面讲所有ETL流程跑一遍，同时要把ETL的容错性进行测试，例如缺失年份、月份后流程的安全性，看看是否会影响历史数据。同时要注意数据仓库的DW层所有数据的完整性和规范性。3.2BI分析平台在最后结项前一定要找个心细的人把所有页面看一遍，最好是业务人员。然后让我方技术与BI前台技术人员确认每个页面的数据筛选方式。这直接关联着维护工作量。同时要在合同签订中所有的模块进行确认。在BI这个项目中与我以前所有的项目都不同，以前的项目作为项目经理只需要确认业务需求，将需求从技术角度与乙方沟通然后与业务人员确认即可，但是在BI的项目中却要在技术体系层面多关注，因为这直接关系整个项目的后期可扩展与维护量级。在这个项目让我学到了很多也有一些失误，在此和大家进行分享，希望能够帮助大家避坑。在最后还有一句比较重要的话是，在选型的时候分清你企业所处的数据准备阶段，这对项目的影响很大。
