【】中台实战（7）：绕不开的企业架构

中台实际上就是一个餐厅中配菜的小工，职责就是负责向前台的各位大厨配菜，，但在梳理中台需求的时候，我们必须要清楚的知道前台到底有多少位厨师？各个厨师的偏好是什么样子的？我们怎么样的工作才能配合上每位厨师的炒菜节奏？也就是完成一次新的企业架构定义。

本文插图
谈到设计中台绕不过去的一个概念就是企业架构！
【【】中台实战（7）：绕不开的企业架构】为什么这么说呢？
是因为设计中台就不能像以往设计传统的单一产品线的产品那样，仅仅是面向特定的人群进行思考，而是需要站在公司的视角，面向于整个公司业务对象与公司内部生产关系进行设计。实现对内提升企业运作效率，对外提升产品交付效率。
记得在本系列的第一篇文章里我已经给大家阐明了中台实际上就是一个餐厅中配菜的小工，职责就是负责向前台的各位大厨配菜，但是在梳理中台需求的时候，我们必须要清楚的知道前台到底有多少位厨师？各个厨师的偏好是什么样子的？我们怎么样的工作才能配合上每位厨师的炒菜节奏？也就是完成一次新的企业架构定义。
再用更白的话说一下就是，我们搭个工棚可能不需要设计，拿着砖就干了，但是如果我们要建个迪拜塔就必须要好好设计了，整个建筑的上下水，电怎么接等都需要思考，而这就是企业架构的活。
一、我们先来看看企业架构到底是个什么东西？
企业架构(Enterprise Architecture)这一概念最早是由IBM的咨询顾问John Zachman ，于1987年提出的。
也就是在随着企业管理精细化，企业内部引入了多套不同领域的管理软件之后，绝大多数企业出现了相类似的信息化企业病，我称之为“人肉接口”与“为系统工作”的两种病症。
具体来说这两者的根本症结就是存在当公司内部采购了多个软件后，由于各个软件之间数据无法互相传递，事件状态无法相互推进，导致不得不由员工将上一个系统产生的结果手动输入到另一个系统进行下一步流转。
此外由于系统间天然的隔离性，导致在上一个系统做过的审批以及操作，在下一个系统中很有可能还需要进行。
举个例子来看，某公司的信息系统体系如下：

HRM：类似italent等系统
OA：企业某信+邮件
邮箱：内部搭建
产品研发管理：JIRA
财务系统：财务
销售管理：某CRM

以员工离职这个场景来看，当我们要为某员工做个退工操作时：

第一步：需要进入HRM系统进行退工封档；
第二步：需要进入OA系统里关闭权限；
第三步：关闭邮箱权限；
第四步：关闭JIRA项目权限；
……

这正是由于数据无法互通，导致我们不得不在多个系统之间进行操作，尤其注意的是这其中任何一个系统的权限遗漏都有可能会造成不可挽回的损失。
可以说上述的场景在现在的很多企业中都是非常常见的，那么现在企业中是怎么解决这个问题的呢？
由于无法实现系统间的互联，因此往往是由公司人事部门整理了一份离职list ，在每个人员离职的时候，按照list进行逐个手动关闭系统权限。
大家回想下自己离职的时候，是不是也会收到这样一份list要你按照上面的流程去找不同的人关闭权限并签字确认。可以说这大大加大企业内部的风险与对应人员工作流被打断次数。
其实这个问题并不是这几年才暴露出来的，早在1987年这位咨询师就已经发现了这样的问题，并给出了自己的解决方案这就是企业架构：他认为在企业信息化建设之初就应该考虑到多个部门之间的协作，并且在系统上体现出来，也就是A部门的协作结果很有可能成为B部门的信息来源，所以在系统之间必须有。对应的数据接口进行数据传递，此外还必须要为系统的后续迭代保留可拓展的部分。