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


(相关资料图)

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

把之前各部门独立自运营的“食堂”(IT部门),合并;把之前各部门独立自循环的“菜品”(IT系统),合并;

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

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

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

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

用友iuap包含了6大组件,它们分别是:

技术平台

1

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

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

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

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

数据中台

2

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

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

智能中台

3

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

业务中台,也叫应用中台

4

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

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

低代码开发平台

5

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

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

连接集成平台

6

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

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

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

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

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

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

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

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

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

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

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

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

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

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

❶ 让数据中台更懂企业业务

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

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

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

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

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

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

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

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

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

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

新痛点之三:紧扣“靶心”造大炮(新应用),老板要求有点高。

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

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

比如,降本增效?提高库存周转率?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

❷ 用友全技术栈的适配,兼容互认证

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

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

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

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

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

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

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

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

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

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

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

最后给大家划个重点

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

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

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

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

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

媒体点评

升级企业数智化底座

推荐内容