编辑导语：中台在近几年又火了起来，不光只有大企业创建中台，一些小厂也想在中台上有所作为；那么什么是中台呢？中台能解决什么问题？如何去搭建适合公司的中台系统？本文作者关于“政务中台”有几点思考，我们一起来看一下。

最近中台的概念随着几篇文章的传播，又开始火了起来；除了BAT几家大厂在争夺中台话语权以外，各体系下的TO G小厂也纷纷拉起战线，跃跃欲试，想在“中台战略”下有所作为。

关于“政务中台”，有一些思考分享给大家。

一、中台不是平台，中台只有一个

很多客户现在仍然在实践数据中心+多个应用平台的建设模式，由多个不同的企业分别规划建设。

这种模式很可能仅仅是一个过渡方案，只是把之前的几百个已有的小烟囱，整合成十几个大烟囱，或者新建一个大烟囱；并不真正在理念、技术、产品和组织上进行改变。

而中台不是平台，中台只有一个。

未来的大中台理念会继续把这些“大烟囱”们进行整合，我们之前强调过场景化解决方案和数据深度对于TOG企业的重要性。

在中台时代，产品规划更是要考虑到一体化政务服务平台的“协同、集约、创新、共享”的建设理念，思考和业务中台以及数据中台融合的可行性。

在中台概念下如果不是核心的中台主导者，也应该努力让自己变成一个中台建设的参与者。

更进一步来说，需要拿出平台化向中台化过渡的解决方案，成为中台建设解决方案的市场参与者；否则，很可能最终被淘汰。

二、没有具体应用“政务中台”只是空中楼阁

“政务中台”的建设模式很像近几年各地纷纷建设的“政务云”，做相关业务的公司一茬又一茬，都说自己能建。

发展到后来，就是在卖存储或者上云服务，但这些能力的可替代性太高了；在服务模式下，一家只做云服务的厂商很难做长久。

“政务中台”在这里也是一样，没有几个、十几个中台之上的拿得出手的解决方案产品，这种公司也就是一家SQL company吧（帮业主统统业务数据，画画大屏罢了）。

一个完整的、有血有肉的“中台”才能发挥最大功效，帮客户解决问题，得到客户的信任，业务才能深耕。

三、谁来补齐“政务中台”的肌肉和皮肤

阿里云在近期倡导的“1+2+2+N”的技术架构很清楚的说明了这一点：在这里“1”指的是政务云；第一个“2”指的是中台中的重要的两部分，包括业务中台和数据中台；第二个“2”指的是业务的两端，包括以钉钉为代表的政务G端，和以支付宝为代表的服务C端；而其他厂商需要在大厂的技术架构下，提供N种有效的、有价值的、有智慧的生态应用。

所以厂商的应用首先需要上云，上云是生态企业比较重要的一步；其次需要配合接入业务和数据中台，成为数据治理体系的一部分；第三就是挖掘移动应用的潜能，包括移动微信、企业微信、小程序、或者独立APP等等都是需要研究的服务承载方式；最后是厂商本身的产品设计。

未来的中台架构之下，生态应用的独立存在的可能性很低，无论是业务的需求还是客观的部署情况，都需要生态应用能够满足以上要求。

四、不相信“中台”，凭什么去碰“中台”业务

有的公司做中台业务做的很惨，到处宣传中台的力量——能够驱动业务的持续化增长，能够打破数据烟囱，重组组织关系，让数据多跑路，让群众少跑腿。

讲了大半天，你问他，你们公司有没有给自己做个业务中台？他就开始闪烁其词，不知所言。

一家自己都不相信中台理念，从来没有进行过中台实践的公司，你如何去信任他帮你统筹建设业务和数据中台？

建议所有想把“中台”作为今后一段时间公司发展的重点的公司，首先在自己的公司里把所有的人事物、产研运、各产品线统一归置到中台之上，看看自己是否真的有能力正常运行。

如果在自家公司内部这样，没什么业务隔离、数据壁垒的环境下建设中台都很吃力，就更不要说政务中台需要治理上百家业务系统和差异巨大的数据烟囱了。

等服务好一家客户，已经是5年以后的事情了，怎么可能复制粘贴经验到别的项目里？

五、不懂业务的“中台”，不是个好“中台”

有一些公司自己的产品还没在这个垂直行业落地几个，就想去动手改造别人的业务逻辑。

但实际上每个“政务中台”都是独一无二的——要充分了解客户的业务流程是怎样的，充分调动客户的参与感；让需求和数据去定义服务，融合现有产品能力，才好落地“政务中台”业务。

在现有的实践里，都需要业主方成立专班，梳理所有的业务和数据逻辑、重塑业务流程，然后再预见性的补充发展观点，最后协同乙方共同进行业务实现。

中台建设中恰恰是那些拥有多年业务系统建设经验，同时努力拥抱智慧化建设的资深行业专家型的公司，可以建设和服务好业主方。

所以我们说，“政务中台”建设的难点不在于技术层面，而在于业务逻辑的优化，包括业务逻辑的流程再造和智慧化改造。

六、跨部门业务和数据治理的显性需求

中台业务建设里面有一个非常引人注意的生态建设需求，就是业务的“跨部门业务和数据治理的显性需求”。

这个需求的政策来源是类似于“最多跑一次”、“一网通办”的政策；除此之外来源于以前各部门独立规划业务，出现部分业务重复建设的客观问题，以及随着现在逐渐兴起的业务上政务云的趋势，把这种需求和问题进一步放大。

而中台建设要求的数据和业务的统一、业务端统一和服务端统一的要求，是解决以上问题的重要推动力；跨部门治理可能是各局委办之间的，也可能是各事业单位之间的，也可能是政企之间的（如银行等）。

所以在生态应用的角度上，未来的趋势是大部门之间的业务流转，这使得厂商业务设计能力的门槛更高，mini生态公司会比较难有机会参与到中台生态建设中。

七、“政务中台”不是一年就能建成的

中台的建设不是一年一个项目就能完成的，也不是建好以后就一成不变的，中台服务需要业务的滋养，客户的业务在不断变化和发展，流程也会重组和修正。

除此之外，中台业务需要特别的运维和运营思路，可以试着建立独立的业务运维小组，包括产品、架构和研发运维小组的最小可行性业务小组，让整个流程在任何一个发展节点，都能让中台发挥作用，成为一个“流动的业务中心”。

八、总结

我们最近经常讨论“疫情改变了什么”，其实在TOG行业，精细化的城市管理、更有效的经济运行方式是对于TOG行业改变最深刻的方面。

我们也看到了中台这个概念进一步推广和落地的可能性。

我们甚至已经给“政务中台”想好了一句推广语：中台助你，“码”上办理。

#专栏作家#

稀奇先生，公众号：稀奇星球，人人都是产品经理专栏作家。拥有十余种标准化产品规划经验，7年TO G业务老兵、智能化解决方案产品专家。

本文原创发布于人人都是产品经理，未经作者许可，禁止转载。

题图来自Unsplash，基于CC0协议。