CMDB数据审计经常在企业推行不下去，考核往往形同虚设应该怎么处理？

以往我们谈到CMDB数据治理的主要印象是：配置流程规范+数据审计。从原理上，这是一种事后+上层控制的思路，策略上属于下策：
第一，事后控制不如事前、事中控制。流程上看，末端来纠错的成本肯定大于前期纠错成本。
第二，上层集中控制成本很高。可以想象，审计出来的问题数据怎么处理呢？真的考核到个人头上，华为或者一些外企这类组织执行力强的公司可以长期实施，但在绝大部分公司政治环境生态中，领导们还不至于为了CMDB大动干戈，可能把审计出来的问题数据进行公示也无关痛痒。CMDB在很多情况下还无法达到像运维安全那样形成公司上下共识，在强有力的管理要求下开展考核。要知道任何严密的组织结构都是需要一定能量来维持的，领导的权利支持、被管理者的抵制，需要的能量都是成本，而收益又是多少？

成本收益是有机体生存的底层策略之一。因此CMDB数据审计的思路应该是：通过流程设计想办法调整流程约束的时间结构，让数据检查动作提前，提高用户犯错成本，同时转移治理中的监督成本。举个例子，某个流程要求设备到货时某人某时刻录入CMDB，但执行人可能偷懒或者真的遗忘了，事后审计虽然形成闭环但效率低。更优的流程设计是把设备初验场景整合进流程里，如果没有录入CMDB则无法初验，流程在执行中就有人会跳出来拉响警报。请注意以往逻辑是业务先变更，再到CMDB登记，业务是因，CMDB是果。正确的思路把CMDB设计为某个业务活动的因，这样数据质量可以得到极大改善。
传统的数据审计模式还得有，但主要用来做存量数据基线盘点。考核责任人建议以产品为单位。考核手段尽量借力外部或现有的能量资源，譬如外部审计要求、安全要求、公司现有的奖励评选等等。让错误数据找得到责任人，同时让责任人自己感到鸭梨山大。