企业架构 ｜ 乱七八糟的系统建设是怎样形成的、该怎么治

我经常听到大企业CIO的抱怨，在他们企业内部，每搞一个新业务，用IT技术来支撑业务是必须的，就要搞一个新系统；每个部门为了有一个自己使用、自己能控制的系统，就一定要专门为自己部门建一套系统。因而，系统建设需求层出不穷，IT部门疲于应付业务部门需求，各种系统乱搭乱建，相应的系统间集成、后续运维也非常复杂。现在时髦讲数据治理，我认为企业系统建设混乱也是数据质量低下的主要原因之一。

以我在CRM领域里的一些观察为例：例如某金融集团的某个集团总部管理部门为了促进集团内各成员单位的商机转介绍以及销售协同，提升集团整合对外的交叉销售，花了很大功夫新建一个“交叉销售管理系统”。

又例如，某银行的对公业务提出了做深行业客户、赋能客户经理，对客户提供具有行业性特色的服务的业务战略，由于各个行业的客户的销售流程、金融产品服务各有不同，这家企业对不同行业的客户开发了不同的营销管理平台，例如面向制造业、房地产行业、物流行业等客户的数字化系统都各不相同。

再例如某大型金融服务机构发起了大客户营销战略，过去，该司不同的业务线和不同区域对全国性大客户缺乏整合的营销和交付体系，为此，该司在总部成立了专门的组织，来统一协调大客户销售，由于是新的组织、流程和绩效体系，因而要专门开发一套“大客户销售管理系统”。

又例如某大型企业在销售的合同处理流程中，风控、合规、法务、审计、定价审核等等都是不同的部门在管，每个部门都一定要搞个自己部门可控的IT系统，抓着IT部门非要不可，所以这家企业在处理一个客户合同时，需要在不同的信息系统中批来审去。

我认为以上这几个例子，单独建设新的信息系统可能都存在着对企业架构认识的误区——这些业务实际上都是企业级销售管理体系的一部分，应该是对现有CRM系统的实施改造，或者/并且基于现有CRM系统的前端外挂系统开发：其一，交叉销售是典型的CRM内部流程，其二，现代银行CRM都应该整合客户信息分析（KYC）或者反洗钱（AML）的外挂平台，其三，大客户销售只是CRM中的一套流程体系，而不是另外再搞一个独立的CRM系统，其四，合同处理是个端到端的流程，各个管理机构应该是提供流程服务，而不是各建独立王国。

有意思的是，这类系统乱搭乱建的现象在制造业里相对来说似乎比较少，可能是由于制造业很早就形成了信息系统应用架构的共识，以ERP为企业核心系统，PLM、MES、SCM等系统各归其位，和金融机构比，制造业的企业架构模式相对来说比较标准化。

其次，因为制造业的工业化组织特点以及受ERP管理理念影响较深，与之相对，金融行业这类服务行业的外部环境变化动荡，内部管理更强调绩效结果而非流程管理，组织文化强调个体或部门业绩而非整体协作，因而，制造企业的跨部门信息集成、业务流程管理的思想理念，相对来说要强于金融企业。

这些因素造成了中国金融行业的信息化建设和制造业相比，不爱用套件，偏爱自己开发，也确实有资源搞系统开发——中国的银行、保险、证券公司的IT部门动不动就几百人、上千人。目前在中国，企业架构治理、数据治理这些课题，和其他行业相比，金融行业看起来最热，为什么？因为金融行业的企业架构从理念到实践都最混乱，因为乱才需要治理啊！除了金融行业外，消费品、零售、物流等服务性行业也是企业架构管理的重灾区。

总之，很多企业内部乱七八糟的系统建设状况，不是IT部门不努力，是业务部门“太要”、“太作”，而IT和业务之间又缺乏企业架构管理的协调和仲裁。（参见《数字化转型乱象 ｜ 数字化越努力，管理水平越低》）

不仅是企业管理者，不少很有经验的咨询顾问、技术工程师都容易犯这个错误——咨询顾问是客户要什么，我就顺着客户把故事编圆了；技术工程师是客户要什么，我就帮客户用技术来实现。他们这些因为工作性质而带来的工作习惯，都是因为缺乏架构思维；一个真正能交付客户价值的数字化转型项目，应该是咨询顾问、架构师和工程师协同工作，充分发挥个体特长，把握正确的项目方向。

我认为要从根本上改变企业乱搭乱建信息系统的现象，企业管理者、业务管理者、IT管理者、咨询公司顾问们，从理念上要改变三大意识：

一、缺乏“系统实施”的意识，老想重复造轮子：

信息系统开发的基础是对数据和业务逻辑的建模，在业务流程和信息展现层，都是对这些模型的应用。每个信息系统背后都有一套业务模型，系统越强大，模型越完善；然而每造一个新系统，都需要定义一套业务模型，系统数量越多，就会造成模型重复定义、模型之间口径打架的问题。（参见《中台建设记》）

很多企业缺乏“系统实施”意识，即利用一个信息系统套件（COTS），通常商品化套件因为经过多个企业使用，具备较为规范、完善、跨企业的业务建模。根据系统蕴含的内在逻辑，在现有业务和系统逻辑之间找到折衷的目标运作模式，即所谓的“业务蓝图”，并按照业务蓝图来改变现有业务以适应系统使用。即便是开发新系统，要充分利用现有IT系统的数据模型和服务，尽可能减少新增模型的复杂度。 

2、缺乏“整体架构”的全局意识：

复杂的大型企业信息系统，是从组织、流程等不同的角度、多个组织层级对企业进行数据、信息的建模，大型企业信息系统不是解决企业内单一业务、单一组织问题的，而恰恰是在单一的一个系统里，同时支持多组织、多种业务模式的信息处理和数据整合，这就是大型企业系统和小型系统、自开发系统最大的区别。

SAP ERP系统可以说是企业架构的巅峰之作，而这在三十年前就已经形成了——企业架构并不是一个新东西。前段时间我和一个同事聊起某全球性大企业在不同国家、有不同业务线和业务模式的IT规划，同事说，这得有多少套IT系统啊！我说这就是SAP ERP最擅长的领域，也是SAP ERP区别于其他所有信息系统的独特之处——SAP ERP的架构就是在一个系统里支持复杂的全球性企业，无论是多维的管理控制主体、会计核算主体、多种会计准则、公司间交易，还是物料管理的全球采购组织、库存业财一体化，销售管理的销售渠道和销售组织设计，制造管理的计划参数、产品核算等，都支持集团化企业的不同维度、不同模式的各种交叉组合。

业务信息系统建设要基于完整的顶层设计，方能实现信息整合。

SAP管理控制（CO）的组织建模

SAP销售和分销的组织建模

SAP物料管理（MM）的组织建模

 SAP生产管理（PP）的组织和数据模型

3、在企业管理信息系统建设中谨慎引入敏捷方式：

在数字化转型时代，“敏捷”成为一种时髦的数字化理念，我观察到国内甚至有些银行、证券公司在某些咨询公司推动下实现了全盘敏捷化组织——分拆IT部门，鼓吹全面解耦、分拆稳态的企业级后台系统，

对于建设面向复杂环境的数字化前端，敏捷方法是有意义和价值的，但是，对企业后台管理系统不能乱搞敏捷，要充分利用现有的后台系统的业务模型。缺乏企业架构治理约束的敏捷，容易带来系统和数据的混乱。

旧文：