针对 驾驶舱场景，梳理其每个指标，对指标进行安全级别定义，哪些是可以内部共享，哪些是不可以内部进行共享的，就这两个级别，当然这些都是需要和业务达成一致的，当然如果业务决定不了，确定不了，就以信息化的结论为主，最终形成一版驾驶舱的指标安全定级，提交公司高层领导进行审批，审批通过后在企业门户进行发布，让大家知道哪些资产可以跨部门申请，哪些不可以。3、当然所有的数据必须要控制范围，数据的订阅只允许每个部门的数据管家进行申请，并对申请到的数据的安全负责。通过以上措施，极大的促进了数据在企业内部的流通。

行业务里面有一句话特别的对，“一切不能给业务赋能，创造价值的数字化转型都是扯淡”，信息化部门在很多企业中的定位还是服务部门，就是为业务服务赋能，如果信息化对于做报表乐此不疲，而不真正的评估是否做的每一个报表，每一个看板是否有价值，沦为业务报表工具的生成者，那就彻底的完蛋了，那么信息化就一定会面临被拆解的危险。经过上面的评估，如果确实值得去做，那就要不遗余力的去实现，团结一切可以团结的力量，协调一切可以协调的资源，把这个工作达成，同时上线后要做好使用监控和运维支撑。

一般来说，技术规则都会在源头系统进行了落地，而且问题不会太大，但是笔者也见到过很多技术规则落地不好的，比如字段应该为整型的但弄成了字符型，这种最直接的影响是数据应用分析，本业应该是度量字段，但由于此字段不是整型而且里面乱填写了各种特殊字符，所以导致无法进行度量设置。2、技术规则：基于技术架构、系统能力、数据安全、数据库要求，明确“技术层面如何实现业务需求”的技术约束或规范，是技术落地的“施工图”，确保系统、数据的稳定性、安全性与兼容性。数据质量规则是判断数据是否符合数据质量要求的逻辑约束。

因为很多业务部门会通常说，当时做项目的时候我们只是为了配合工作根本没有关注是否可以使用，这种情况下要告诉业务，我们允许进行优化升级，但只给一次机会，并且要慎重考虑，并且要求对方进行虚拟账单支付，这些都会算在部门的成本上的，第一次时是免费的，你现在要升级，可以做，但要花钱，这样业务再做时就特别的慎重，不敢再乱提了，一定是深思熟虑后才做的。企业进行BI项目建设，最头疼的事情就是做完驾驶舱，业务根本就不用，项目完成后，驾驶舱成了真正的摆设，信息部门问业务，这些都是你们设计的指标，你们为什么不用啊？

数据治理平台对于企业开展BI项目建高特别的重要，一般企业会建设数据中台和数据应用平台，数据中台完成数据入湖、加工，数据仓库分层设计，而数据应用平台则侧重于进行分析展现，而且一般会把数据应用平台提供给业务使用，数据中台在一段时间内还是由信息化部门在使用，特别是在一些制造企业，信息化部门在很长一段时间内还承担着数据开发的工作，一般的工作套路还是业务提需求，信息化部门负责实现。需要支持对各种数据，结构化数据、非结构化数据，流式数据的数据入湖，既支持离线批处理，又支持实时数据，必须要覆盖所有的场景。

2）对于简单的可心拿到SQL实现的，而且是依赖用户每次提交请求获取结果的，建议将SQL中的源表进行数据入湖，同时把报表的实现在数据仓库中为其构造。1）如果这种报表完全和ERP绑定，是依赖ERP系统的内置函数实现的，这种估计无法拿到其具体的逻辑SQL实现，这种报表结果要做入湖，当然前提是ERP后台有存这个的表。4）逻辑实体：一般和数据库中的表保持一致，但又在表的上层，属于设计层，比如企业里面有多个MES，可能在逻辑实体这层只对应多个MES中的同一个逻辑实体。比如研发域、生产域、供应链域，营销域，服务域等。

很多企业的数字化转型工作都是从做BI项目开始的，很多企业认为，BI就是做指标大屏，所以做了很多的驾驶舱，也做了很多指标，有从系统取的，有手工填报的，甚至手工填报的比例占到了70%，最终BI沦为了填报系统，业务认为BI就是把从线下的微信沟通转到了线上录入展示，并没有给业务代来任何提升，久而久之，BI大屏就没人关心，公司高层也认为数据都是填报的，都经过了加工处理，这种数据不可信，不能反映业务开展的实际。其实在BI系统建设之前，我们首先要做的就是要梳理企业的指标，到底我们要展示哪些指标？

其实很多企业，特别是中国的传统制造企业其业务流程开展的过程和这些标准的业务一点都不一样，很多情况根本无法按这些标准的业务流程开展，所以必须要按企业实际的业务流程开展情况进行梳理。企业里面除了上面的指标外，但对于很多部门来说，他们的驾驶舱里面希望放的都是一些部门需要的管理指标和执行指标，如何梳理这些指标是十分的重要 ，笔者根据自己的经验，建议从业务流程梳理入手，至少梳理四级业务流程，即：业务域--流程分组--流程--活动，其实到活动级就可以了，任务级是不需要的，因为任务级对应了信息系统的操作。