直接上答案也是一种美德

CMDB 的建设应该以**“ 市场经济”**为主导，先让数据野蛮生长，各自管理，组织机构在中间再通过弱监管的方式对数据进行穿针引线，再逐步抽象出配置模型，再不断参考行业标准，持续推动不断完善模型标准，不仅能提升数据生产率还能提生数据生产质量。

人治强压数治

哪里有压迫哪里就有反抗，在过往的CMDB 建设过程中大多采用一个自上而下的**“ 计划经济”**建设模式，经常会出现三个现象：

01

组织上的要求，把CMDB 的建设纳入正常工作中，后续又增加一系列的流程进行管控，把原本应当成为标准数据输出型CMDB 搞成了增加工作量的数据输入型CMDB。

02

由于是统一搭建CMDB ，在建设之初必然需要调研各团队维护数据现状，然后参照行业标准抽象出来一个看起来能满足短期企业发展需求的一个标准化配置模型，然后才开始收集核验配置数据，实际上很难接地气。

03

各专业最开始迫于组织压力和对美好新事物的憧憬义无反顾献出自己手中长短不一、规格不整的EXCEL希望至少能够满足现有数据的维护，但在一次次投入产出未达预期和缺失明确数据消费场景下，渐渐又回归到维护原有EXCEL工作模式

我们在CMDB 建设过程中可以找到很多原因来阐述为何CMDB 没有能被适当的使用起来，可能有组织上的压力、现阶段需求上的差异、厂商不够专业、工具不够友好等等，但我觉得也许我们一开始就把力使错了地方。

在很多客户建设中，不难发现各专业在对自身管理范围的数据质量都存在一定的误差，更何况我们在建设CMDB 过程中需要汇聚应用、系统、主机、网络等各专业配置数据，这样就导致我们在CMDB 建设之初已经失去的数据的准确性。

数治引人治

过往CMDB 建设抛除组织压力、流程管控等维度，只从建设思路来看，也许本质就是错的，本身CMDB 的建设应该是一个数据治理的过程，一上来就拿各种条条框框来限定人的使用习惯和数据格式，是不人道的，而真正靠谱的CMDB 建设也许应该是以数据为导向，满足各专业眼前对数据管理渴望的需求，比如可以直接将手中EXCEL导入进行维护，那至少要满足以下要求：

1

至少要比EXCEL更好用

如果你都不能让各专业自给自足，凭什么让他们为社会主义建设添砖添瓦。

2

可满足各专业需求，有重叠数据也不会冲突

数据本身是多维度的，在应用、主机、资产管理各维度来看一台X86 服务器的维度完全不一样，应用看到一台X86 服务器只关注IP 、配置，而主机的就要关注厂商型号、内存磁盘空间、物理位置等信息，而资产管理则更侧重维保、合同、金额等信息，而这些数据本身也应该是分离的，但是他们却在从不同维度描述同一个对象。

3

可以提供各专业数据自定规则关联调和能力

不同维度数据间相互描述的标识可以是一个IP 、也可以是多个字段共同组合而成，而这个标识是数据调和能力衔接的纽带，通过数据间的调和从而将多维数据关联起来真正实现从业务、应用、系统、基础设施的端到端IT 架构可视。

4

各自维护的数据可以单独对接外围系统的能力

在每个专业不仅能够通过直接导入导出EXCEL对数据进行管理，还应当具备对接外部数据源的能力，让CMDB 适配现有或未来准备建设的系统。

小结

一个开放的CMDB 工具也许能给迷雾的人们点亮一盏灯塔。今天算是开个场，很多细节只有在实践过程中才能发现错误所在。