大央企的“中央厨房”，泰裤辣！

本篇文章来源：特大号 作者：特大妹 

最近两年，大央企大国企在数字化转型中，特热衷成立“中央厨房”。

有的中央厨房，单独挂牌为“数科公司”，有的中央厨房，升级为集团数字化转型的一级部门。

把之前各部门独立自运营的“食堂”（IT 部门），合并；把之前各部门独立自循环的“菜品”（IT 系统），合并；

组成一个规模更大、支撑力更强的“中央厨房”，服务集团，辐射行业，由此加速大国企数字化/智能化转型步伐。

这些大甲方在打造中央厨房时，几乎都会参考一个“底座式”的 PaaS 平台来建设，这个“底座”，叫做「企业数智化平台」。

有人会问，啥是企业数智化平台呀？都是由什么构成的啊？

我们先以「用友 iuap」举例，帮大家快速理解一下↓

用友 iuap 包含了 6 大组件，它们分别是：

1 技术平台

技术平台好比一体化灶台，云原生技术打造，承上启下。

为上层不同的菜肴（应用），提供不同的灶头（多云适配）、炊具（容器）和调料（微服务）。

如果遇到讲究一点的要求，可以开个小灶（专属云私有云部署）。

整个后厨是 DevOps 流水线模式，出菜效率奇高。

2 数据中台

好比把原材料都收集上来，进行一系列的清洗、治理、加工、分析，形成各种“净菜”。

最终达到数据可用状态，随时可以流入业务。

3 智能中台

让企业的应用更加智能化，之前人肉“背的锅”，现在可以让 AI 来“背”了。

4 业务中台，也叫应用中台

业务中台能提供标品自助餐，能根据上层客户五花八门的需求和场景，能快速出锅各种可口佳肴。

每个业务部门，各取所需↓

5 低代码开发平台

业务中台已经提供了半成品菜，数据中台也积累不少数据，如今，低代码平台又提供的是“烹饪速成手册”。

有了这套烹饪“傻瓜书”，不用大厨（研发）上手，一般人（前端业务人员）也能快速简单地炒菜了，一两个紧贴自己刚需的“新应用”信手拈来

6 连接集成平台

把之前不同的老锅老灶（应用系统）连接起来，让数据流通，实现业务融合。

以上这六大部分，就可以构成中央厨房的“企业数智化底座”。

这两年，有条件的大国企，基本上都完成了底座初步构建工作，实现了从无到有、从 0 到 1。

大甲方自己踩坑摸索建设的这些底座，或多或少具备了“类似于”用友 iuap 的一些组件和功能，并逐渐开始支撑“中央厨房”的运转。

但是，在数智化转型的“烹饪”过程中，这类原始散装底座不断遇到“做菜”和“吃菜”新难题↓

大甲方们逐渐意识到，在中央厨房的架构下，原有的“散装底座“都有一定局限性，需要对标用友 iuap 的相关能力，强化 PaaS 层，完成对底座的全新升级。

接下来我们一起康康：用友如何帮助大甲方升级这个“底座”，解决数智化转型新痛点↓

新痛点之一：家里有“矿”，但是开采难度大，建了数据中台，也很难用好

这个矿，就是数据，大量数据集中在央企和国企手中，但是数据无法发挥价值。

开采难度大的原因还是老生常谈：内部数据孤岛，依然打不通。

即便建起了数据中台，也很难达到“数据驱动业务”的目标。数据中台不懂上层业务，是原罪。

市面上很多数据中台不做主数据处理，因为主数据要求对业务理解能力很高。

比如物科主数据、客商主数据，内部财务科目的主数据，如果对业务不了解，就做不出来。

借助用友 iuap 的全栈 PaaS 能力，大甲方的数据中台可以焕发新生，解决数据打通和数据驱动业务的痛点：

1、让数据中台更懂企业业务

2、不瞎挖数据，不是为了挖而挖，开始挖的时候，就会认真思考“如何让数据更懂业务”

用友 iua p 提供了“数据工厂”能力，强调数据从各端汇聚，流向各种场景。

3、AI 技术和业务场景深度捆绑

在技术层面，用友构建了一个超先进的“AI 厨房”，叫作 AI 工作坊。

在工坊里，通过 7 步烹饪，即可实现 AI 研发，“理场景->定方案->标样本->调资源->训模型->管模型->用模型”。

在业务层面，用友更是花费了大量的精力和心血，去打磨各种应用场景。

聚焦供应链、销售、财务、人力、资产等细分领域，提供「数智应用全场景」方案。

新痛点之二：“一人一把号，各吹各的调”，业务运转中缺少协同和支撑。

一个项目管理中，涉及财务（预付、合同分期付款）、人力（人不够，要招人）、采购（供应商）、制造（什么时候交货），就会出现这种横向的、跨部门、跨系统的业务场景横向串联。

实际场景确是如此，实际场景确是如此，属于刚需↓

新痛点之三：紧扣“靶心”造大炮（新应用），老板要求有点高。

之前，做一个应用，就是做工具，CRM 工具、财务工具...

现在新应用，是奔着一个明确的主题去的。

比如，降本增效？提高库存周转率？

所以，前端业务场景的互联互通需求，变得强烈了。

其实，这两个痛点的核心原因是：之前建设时落下的“信息孤岛”问题，散装 IT 系统，就没有支撑力！

先做系统，后做集成，导致业务横向不贯穿，数据不流通。

现在，应用系统横向贯穿才能满足部门协同支撑和核心业务意图。

部门串联的需求怎么破？老板要的硬菜级应用怎么整？

用友的思路是：在强大的平台之上，进行「主题化创新」。如基于一个主题去做业财一体化，把自己的业务链条横向先打穿。

实现跨部门的、跨系统的业务场景横向串联，数据实时，打破企业数据孤岛，实现人、财、物系统融合。

新痛点之四：“牵一发动全身”，无法适应“柔性业务”需求。

说得好听点叫“柔性业务”，说得直白一点叫“一直在变的业务”。

可是原来系统架构僵化，敏捷度低，无法适应变化多变的业务需求。

有些变化，是深层次的，牵涉到方方面面，甚至细到 UI、打印、流程表单…

怎么破？用友给出了终极答案：先抽象出各个业务特征，构造“特征体系”。

如果遇到业务新变化，可以对未知的业务事项定义「弹性域」，灵活自定义字段，让业务具备柔性化能力。

IT 支撑，随需而变，业务柔性+组织柔性，丝滑柔顺，一切顺顺顺！

新痛点之五：信创 &混合云适配能力弱

信创成了大国企和大央企，无法回避的话题。

面临混合云场景，云上云下集成效率和安全成为难题，很难满足信创要求。

怎么破？用友在为大甲方升级底座的过程中，强调“有价值”替换。

不是为了替换而替换，真替真用！数智化与信创化相结合，形成中国企业真正的价值替代。

●截至 2022 年底，用友累计完成国产化替代项目 260 个，同时实现业务场景的纵深替代。

●用友全技术栈的适配，兼容互认证

用友 BIP 从芯片、服务器、操作系统、数据库、中间件到安全等方面，全栈适配中国电子 PKS、中国电科、中科院及华为鲲鹏四大信创技术体系。

●在混合云集成上，用友通过“连接器”，把各方应用快速链接在一起。

新痛点之六：大甲方角色转变，从成本中心变成利润中心。

大国企大央企成立「数科公司」的目的，一方面服务内部集团，一方面对外深耕行业。

此时，数科公司从「雇人搬砖」变成了「自己搬砖」，既是甲方，又是甲方中的“乙方”，使命感立刻不一样了，焦虑也更多了↓

为了帮助大甲方解决这个难题，用友提出了基于用友 iuap 的【“1+3”合作模式】，即：

❶联合研发：基于用友平台和标准产品联合研发行业级应用软件，上架用友 ISV 优选/融合生态，赋能全行业

❷交付服务：以行业级专业服务生态伙伴身份加入用友生态，为本行业客户提供项目实施交付服务

❸销售合作：基于联合研发产品，针对行业内客户提供销售服务。

通过建设联合运营创新中心（虚拟/实体），充分发挥各自的“懂王”优势，基于用友 iuap 数智化底座，共建行业级产品和解决方案。

作为「长期主义者」，用友的目标是成为用户的左膀右臂，把“底座”真正运营好，与客户一起攻坚数智化转型路上的新挑战。

最后给大家划个重点

用友帮助大甲方完成的「底座升级」，是站在用户角度，围绕用户痛点，去做思考，去做革新。

支撑这种革新，离不开用友炉火纯青的“内功”和“外功”。

用友的内功，是硬核的技术积累和自主创新，这个能力让用友更有底气，也让大甲方们对底座的技术领先性充满信心。

用友的外功，是多年来深耕行业、对业务的精准理解。用友 iuap 的底气就是更懂业务、技术领先和体系完整。

企业数智化 2.0 时代已来，升级「底座」正当时！