“我们这个BI怎么做成这副鸟样，他们还想要钱，我们的尾款是不可能付的。”这是我在G集团听到财务总监的抱怨。感觉类似于这种吐槽BI的话，我经常能够听到的。我正在经历第四家公司，有三家公司都上了BI分析平台，但是效果都不太理想，作为一个SAP技术顾问兼主数据治理顾问（岗位如此，但我更愿意称自己是ABAP小菜鸡），我感觉我可以从旁观者的角度来分析一下为什么这三家公司的BI都不太理想。以下内容，均为本人的一隅之见，不针对任何单位也不针对任何个人。因为M集团的情况尤为明显，所以内容以M集团中所见所闻来写的。
我想了很久，失败的原因大方向就2个，一个是系统本身的原因，一个是人员的问题。下面我将细分这两个原因。
系统问题--架构
我大体上还是参与过数据中台的调研和选型的，不过也只是作为旁听者，作为一个接触过SAP-BW的人，我还是比较抵触现有的国内一些数据中台的架构的，或者说抵触某些数据中台项目经理的想法。
国内大多数据的BI的方案，甚至数据中台结合BI的方案，最终的架构就是这样的。不论前面吹嘘得多么厉害，最终落地的人只有这点功力，抽数，计算，呈现。一套方案走天下，完全不考虑实际情况的项目经理比比皆是。接下来说说这个方案的弊端：
1.前期吹得厉害，能针对各种类型的数据进行抽数转化，最终只能做到对数据库数据的抽取和呈现。因为传统制造业的文件数据多样化，如果要对文件数据进行数据识别和录入，耗费的资源是巨大的，BI项目基本做到数据库呈现已经到头了，领导层一看就这么个玩意，基本不会再次投入资源，更别说耗费大量资源实现各类文件的和其他数据的抽取录入了。
2.“数据抽取”是一个主动捕获的动作。
不考虑实际业务对实时性的需求，统一考虑抽数，导致BI呈现的信息滞后；
不考虑数据增量的方案，统一大批量抽数，导致系统负载太多，反手就是一个升级硬件的方案和需求；
这个时候我有点想为SAP-BW打一波广告，SAP-BW对数据库类似于做了一个指针，只要数据库发生变化，数据会主动入到抽数据的中间表中。
3.不考虑数据治理和数据清洗的过程。多数传统企业没有主数据治理和数据治理的这个过程（这个点我还是想赞扬一下M集团的，至少它愿意专门成立一个这样的团队来做这件事，虽然也不理想），针对抽取后的数据一定要做数据清洗，否则因为多系统之间数据的差异，很容易导致呈现的数据与实际数据有较大出入，结果就是各种数据对不上。
4.数据统计运算过程。各种大量的SQL语句，写SQL不考虑性能，SQL只图方便，该建哪些索引，建什么样的索引，这些都影响着性能。这个时候，不论甲方还是乙方的项目经理都需要注意的点，代码审核不可或缺（至于审核的人，找个老鸟吧）。
数据中台或者BI的架构都应当根据实际业务场景和结合各软硬件需求做方案，有些项目经理完全不考虑实际情况，用一套方案走天下，方案是简单了，但是把最终用户和维护人员给坑惨了。
系统问题--建模
传统制造业把建模这件事要么想得太高深，要么想得太简单。我能在M集团听到的两种声音，第一种“时间紧，任务重，把数据库TABLE直接导入到数据中台/BI数据库，或者把传统ERP中做过的报表直接存表再提取”，这种就是把建模想得太简单了，建模的过程是至关重要的一个过程，这个过程是对传统业务的一种审核，确认传统业务过程中，哪些数据是极为重要的，哪些数据是可有可无的，是对原有业务场景模型化，需求再确认再分析的一个过程，好的模型不仅对后期性能有很大提升，更能发现传统业务欠缺的部分；第二种“我们现在都没有建模师，我们应该花个大价钱招一个算法工程师，然后帮我们对这些业务进行模型建立”，这种就是把建模想得过于复杂，反正有问题，就是缺资源，缺工程师，模型没有建立好。其实，我个人的感觉建模并不是一个特别复杂的过程，哪里需要那么多的所谓的算法工程师，更何况，传统制造业招聘一个算法模型工程师的成本是巨大的。传统制造业，所谓的建模，其实就是一个基于业务场景，建立数据库底表的过程（当然可能我的想法过于简单），在这个过程中，要根据自身的经验，对数据模型建立的颗粒度把握一个度，模型不能建立的太粗，也不能太细，太粗导致很多查询无法实现，太细导致数据量太多，影响性能。不能基于业务场景去分析，就算招一个会算法的模型师也是于事无补的。
所以，建模是一个不可缺少的过程，也是一个极其细化的过程，这个过程需要多岗位的共同努力，并不是说招一个建模师就万事大吉了的。
系统问题--性能
M集团的可怕之处“所有BI的统计代码都是实习生完成的”，想来也是可笑，并不是看不上实习生，相反，我看到在M集团实习的实习生，他们的能力比我刚毕业入职那会强太多了。只是，还未毕业的实习生在校学习的过程，更多偏向于功能实现，极少考虑整体架构的。所以，他们写出来的代码，大多数更偏向于功能实现就好，很少有实习生能关注到对性能影响这个点，而老手一般会考虑代码的优化及对性能的优化，甚至有时候反向吐槽业务的算法逻辑哪里有缺陷。
性能并不是优化出来的，也不是说升级服务器，加个内存就能解决的。性能是设计出来的，在这个过程中需要考虑怎么样的业务逻辑能够最快实现业务的需求，怎么样的业务逻辑是计算量最小的。我作为一个ABAP技术人员，信奉“业务顾问给最合理的逻辑，开发写最优化的代码，整个程序跑得才快，程序慢，性能差，并不仅仅是开发一方面的责任，逻辑给的不合理导致的性能慢，不是说开发优化优化代码就能解决所有的问题的”。
架构没做好、建模不合理、业务逻辑设计的有问题，后期性能不行了，反手就是一句“开发看一下怎么优化一下代码”，对于这样的BI项目经理，我作为一个旁观者的角度，都恨不得反手过去给一个大逼兜。可能作为开发出身的我更能感同身受地理解开发的难处吧。
人员问题--甲方选将上
M集团的中台项目，从富士康中台到阿里中台，换了2个中台，前前后后花了大几百万，项目经理换了一茬又一茬。从M集团中台的选将上，我就已然预测到这个项目不太可能成功。（1.前期挑选的甲方项目经理都是纯技术，不懂业务；2.后期挑选了个业务项目经理，还是个半吊子，也不是真正懂业务的人；3.甲方项目经理频繁更换，项目上换项目经理是大忌，前期的调研和后期的方向基本上算是都换了，而且前期不成功的经验也传达不到后来者；）
人员问题--人员矛盾
一个项目的成功源于项目上，所有的成员的团结及目标一致性。M集团的平台，是一个僧多粥少的平台，所以高层明争暗斗，中层之间相互使绊子，基层看戏。没有把大家的利益绑定到这一个项目上，让大家作为一个利益共同体，也是中台/BI项目不太成功的原因。这是M集团的高层失败之处，让一个人身处多个项目中，每个项目都做不到全力以赴，后面M集团的高层好像认知到这件事了，做了一个形式上的项目管理平台，具体成效我不太好评论。某些中层管理者会成为公司前进道路上的拦路虎，向上形式主义，向下打压，防止优秀人员进度太快，作为公司的高层，特别是初创企业的高层，一定要清楚地认识到这件事，初创团队并不需要那么多中层，初创团队需要的更多的是做事的人，并不需要那么管理者。
人员问题--项目经验缺失，导致项目失败
明明资源不够，却选择多点开花的项目实施方式。我曾建议，项目总监不要选择多点开花的方式，结果却被叼了一顿，后面就直接选择闭嘴了。不论中台还是BI项目，其实都算一个漫长的过程，这个过程中，需要资源的不断投入，所以前期一定要针对某一个业务部分出一个较好的呈现，让用户和领导层吃到一点“甜头”，这个后期才会有资源的不断投入。明明资源不够，却选择多业务共同推进，各种业务需求全面接，结果就是导致所有业务都做过半吊子，半吊子的玩意上线后，出现用得人少，甚至没有人用的情况，领导没有尝到甜头，觉得项目不行，资源不再投入，结果导致整个项目瘫痪了。当项目资源不够的时候，就需要进行单点开花，把某一个点做好做精，然后总结成功的经验，让这种经验延续到其他点，这样一方面让让领导尝到了甜头，也很好地锻炼和培养了自己的团队，资源的再次投入，拿到资源后，再以推广的形式去稳打稳扎才是正道。
人员问题--乙方项目经理和实施人员
我看到的三个公司的中台或者BI的乙方项目经理和实施人员，对比一下SAP乙方的项目经理和实施人员，不论个人能力上，还是项目管理经验上，都差太多了。这也是我觉得很多中台和BI不能成功的原因，一个好的BI项目的实施顾问，应当首先是一个好的业务顾问，能明确甲方提出需求的目的，深挖甲方的为什么会有这样的需求，这样才能做出真正满足甲方需求的看板。
至于国内很多BI和中台的项目经理，感觉项目经验真的有限，这个时候得给汉得和IBM一个大大的赞，至少我看到的汉得和IBM的项目经理，在项目管理上，把握整个项目进度，对项目中产生的问题，项目中需要的产出物都能做到很好。国内的中台和BI，如果想做到更好，不妨去看看SAP的项目是怎么实施的，一些乙方的SAP的项目经验是怎么沉淀的，把实施的项目经理培养好，把项目经验沉淀好，我觉得国内的中台和BI才能走得更远。
人员问题--数据质量问题
我看到的很多的BI呈现问题，最终都是数据质量有问题，这个问题的本质是基层人员的认知度不够，没有认知到数据质量重要性，在做单子和数据时导致大量的错误数据。当高层需要数据的分析结果对未来做决策时，基层做的数据问题源源不断，导致整个数据治理的过程耗费了大量的精气神。关于数据管理，不妨看看我写的
《【IT杂技】--数据管理》
写到最后，数据中台和BI的失败的原因我个人的理解就这些吧。有的时候，想说，作为传统制造型企业，别把自己想得太高大上，ERP还是传统企业的根本，有些企业ERP还没有用明白，就中台和BI，各种自动分析的软件，有点本末倒置了。传统制造业，做数字化转型，多想想怎么从业务流程中优化，从审批流程中优化，从数据流程中优化，多想想怎么样把数据治理好。先把流程和数据治理做好，怎么把ERP+OA+MES做好，后面再考虑考虑中台和BI吧。
