中台： 54天搞定中国百强企业的库存中心建设
中台： 54 天搞定中国百强企业的库存中心建设，而时间还能够再缩短至少一倍
试想一下，从签合同，到对接需求，再到设计、开发、上线只有两个月不到的时间，期间还伴随着:
- 不明确的需求： 需求不清晰、稳定，时常变动
- 10 来个系统的对接： 和其内部各种系统的对接
- 短缺的技术人员：仅 3 个技术人员
- 不稳定的运行、开发环境：其运维流程长，管控严格；资源有限，其他项目组带来的脏数据干扰
- 无数的开会
- ……
有信心完成么？
在如此多干扰的情况下，最终也只花了 54 天顺利上线，这与其他项目短则半年一年相比，可谓是个小小奇迹。而这奇迹的背后，内中台建设、中台的建设、快开平台建设带来了不可磨灭的功绩。
内中台提供构建中台的能力
中台，在近年来是个被说烂了的词，是个技术公司都在说要建设中台，做中台，然后真正把中台体系建设好的恐怕也没有几个，而从中收获到成果的更少。
对于大部分企业而言，中台都是将一些公共服务剥离，提供给所有前段业务先使用，如：用户中心、商品中心、交易中心、数据服务中心、库存管理、财务中心等等，随着中台服务的不断发展、迭代，前段应用可以更轻松、快速的构建，也就所谓的：“厚平台，薄应用”。
然而有一类企业的中台建设，则与这种有非常大的区别，这类企业就是像金蝶、用友这样，帮助其他企业构建自己的中台的企业。对他们而言，他们的中台，是中台内的中台，他们构建的不是中台，而是构建中台的能力，可以称为内中台。
内中台的定义
内中台，就是能够快速构建中台服务的能力平台。如，库存管理与财务中心，两个看似毫不相干的服务，可以独立的构建成中台服务，共享给所有产品线。然而，再细想的化，除了 PAAS 层的共性之外，他们还有一层可再抽象共用的能力：余额更新能力: 库存管理更新库存余额，财务中心更新信用余额。而这，就是中台业务下的与具体业务无关的内中台引擎。
也就是说，内中台，更多的是脱离具体业务而提供的一种能力，不直接给中台用户提供服务，却又属于中台的一部分，所以称为内中台。
内中台的作用
就像中台服务能够让前段应用快速的构建一样，内中台提供能能够快速构建中台服务的能力，
在前面说的余额更新能力的帮助下，我们只需要在库存管理和财务中心服务中，设计好相关的数据表格，然后配置好余额更新的策略即可完成相关服务的构建。关键是，在这些能力帮助下，省去了繁杂的代码编写，也省去了各种可能出现的技术问题(如数据一致性)，只需要好好设计自己的数据格式即可。
内中台设计的挑战
内中台，更多的是一种模式、一种数据模型的归纳、抽象、建模。而做好内中台设计的挑战则主要来自三个方面：
- 对不同服务之间的业务有比较深刻的理解
- 同时对数据模型的归纳、抽象、建模能力要求很高
- 最后才是具体的技术实现：功能、性能、扩展能力等要求多非常高
中台构建标准产品
除了中台，还有的就是标准产品的丰富度
内中台终究是无业务属性的，作为 SAAS 产品，为了能够切实的服务客户，我们还需要建设属于我们自己的标准产品，而这更多的是像其他企业的中台服务。如库存中心、共享财务等就是标准的中台式服务了，这些都是构建在我们的内中台之上。
最终卖给用户的，用户能够看到的，则更多的是这类的标准中台产品
快开平台构建快速的二开能力
像一开始说的，企业的需求是不明确的，是不明朗的，标准产品永远不可能完全满足客户的需求，这种情况下，要么是客户改变自己来适应系统，要么是系统二次改造以适应企业需求。大部分情况下，都是属于后者。
而后者面临的情况如需求变幻莫测、开发人员短缺、时间有限等各种因素，会严重加大二开的难度。
对大部分二开场景而言，其需求都源自于两个点：
- 业务数据结构变动： 如增、减字段等
- 业务流程变动： 原来单个流程，编程多个流程等
针对这些，一个低代码，甚至零代码的二开平台，就能够很好的缓解这一个问题。在我们的开发平台上，二开人员不需要任何代码，就可以对一条产品线进行扩展数据结构，调整业务流程。原来设计一张表格或者报表，可能需要至少几天时间，而现在，也仅需几分钟就能够配置好（熟手 😂）。二开小伙伴，更多的是像搭积木。而对于特别的定制化需求，也可以通过开发具体插件来完成，只需针对这个需求进行代码开发，可以完全脱离其他业务代码。
题外话
之所以把内中台单独剥离出来，主要是因为它既不像是带有很强很强业务属性的业务中台服务，也不像 PAAS 层等技术中台的纯支撑技术领域，而更多的是由业务领域抽象出来的一种模型。
还有更多的改进空间
纵观整个过程下来，我们其实有理由也有信心相信，我们还可以做到更好，我们的时间还可以缩短至少一半以上，毕竟我们还有很多不成熟的地方。
我们抽象了很多的模型出来，有面会慢慢的针对每个模型，以及其应用的场景，逐一进行梳理。
