每到年初,信息化负责人的桌上都会多一张清单:财务一套、进销存一套、OA 一套、车间一套。业务每长一条线就多一个系统,接口一个个写。
等到老板问"这个月到底赚了多少",答案还要从四个系统里导出来拼。这时"中台"被提上会议桌,当成一剂能治百病的药。勤哲Excel服务器的思路不同:不新建一个大平台,先把数据和流程收拢到一张能共用的表上。
先把概念放下。中台要解决的,其实是三笔拖了很多年的旧账;把账看清,才谈得上选工具。
每到年初,信息化负责人的桌上都会多一张清单:财务一套、进销存一套、OA 一套、车间一套。业务每长一条线就多一个系统,接口一个个写。
等到老板问"这个月到底赚了多少",答案还要从四个系统里导出来拼。这时"中台"被提上会议桌,当成一剂能治百病的药。勤哲Excel服务器的思路不同:不新建一个大平台,先把数据和流程收拢到一张能共用的表上。
先把概念放下。中台要解决的,其实是三笔拖了很多年的旧账;把账看清,才谈得上选工具。
这三笔账,几乎每家企业都有一本。区别只在于,有的记在纸上,有的记在每次开会时的争论里。
2018 年,中国数字经济规模已占 GDP 的 34.8%。盘子越大,这三笔账越躲不开:数字化不再是"要不要做"的问题,而是"怎么把已有的东西接起来"的问题。
阿里在 2016 年提出"大中台、小前台",把中台从一个技术词变成了经营词。此后电商、零售、制造都在谈,概念也越谈越杂,最后常常变成一句"我们也要建中台"。
中台目前没有统一口径。按功能粗分,至少有三类,各自要解决的问题并不相同;混在一起谈,方案就会失焦,预算也会失控。
它针对的是数据孤岛、资产维护混乱、价值利用率低。核心不在存了多少数据,而在三件事:缩短从数据到价值的时间;把开发能力沉淀成可复用的服务;让交易在云计算、大数据、微服务的支撑下变得敏捷。
换句话说,数据中台交付的不是一张报表,而是"随时能长出报表"的能力。
业务部门调用平台上的模块,快速拼出新的业务场景。所谓"十大业务中心",本质是把重复的能力抽出来共用,避免每个项目、每个区域各写一套。
它考验的不是技术,而是抽象能力:哪些是共性,哪些必须留给一线自己定。
国内企业的组织架构、人员岗位随市场频繁调整,组织中台要解决的是"人变了,权限和流程能不能跟着变"。这一层最容易被忽略,却常常是项目落地失败的真正原因。
除此之外还有技术中台、研发中台。阿里的数据业务双中台,是谈得最多的一个样本。
再往下一层,技术中台提供的是统一的开发、集成与运维能力,让上面的业务能力不必各自重复造轮子。
两张图放在一起,会发现中台的共同点不是某个产品,而是"分层":前台贴近用户,变化快;后台管账和主数据,求稳定;中间那层负责吸收两者的差异。
这个结构对中小企业同样成立,只是规模不同。大厂有专门的团队建中台,小企业可以用一套工具先把"中间层"搭出来——只要能承接变化,形式并不重要。
反过来,如果一套系统上线后,业务提个新需求还要排期三个月,那它无论叫什么名字,都不算中台。
中台建设听起来要大量研发人力。但它的核心目标只有一个:以用户需求为中心,持续扩展、持续创新。平台化是手段,不是目的。按这个标准,勤哲Excel服务器能承担业务中台里最贴近现场的那一层。
它替代不了大厂的中台研发体系,也不该被当成万能底座。它擅长的是把"一张表上的业务"标准化、流程化、可查询——而这恰恰是多数企业最先需要的那一段。
选型时不妨问三个问题:业务人员能不能自己改一张表?改完能不能马上在手机上用?数据能不能被别的系统取走?三个都能答"能",这一层就立住了。
路线图上没有"一步到位"。先把最痛的一张表做出来,让人用起来;再把流程串上,把权限分清;最后才谈接口与集成。顺序反过来,项目多半停在方案阶段。
这也是不少中台项目搁浅的原因:一上来就画大图、建大平台,业务部门等了半年没见到能用的东西,热情就散了。小步走看起来慢,其实省掉了返工。
叫它数据中台、业务中台或组织中台,其实没那么重要。真正要回答的是:企业能不能更快地响应客户。
破除孤岛、节省人力、缩短实施周期、在前后台之间加一层适配,这些动作做到哪一步,中台就成立到哪一步。平台化只是恰好走在这条路上。
对多数企业来说,可行的路径不是复制阿里的架构,而是找到自己最痛的那一段,用能承受的成本先接上。接上了,再谈下一段——这比一次规划三年更接近"中台"的本意。