最近中台的概念随着几篇文章的传播，又开始火了起来。除了BAT几家大厂在争夺中台话语权以外，各体系下的TO G小厂也纷纷拉起战线，跃跃欲试，想在“中台战略”下有所作为。关于“政务中台”，有一些思考分享给大家。
01、中台不是平台，中台只有一个
很多客户现在仍然在实践数据中心+多个应用平台的建设模式，由多个不同的企业分别规划建设。这种模式很可能仅仅是一个过渡方案，只是把之前的几百个已有的小烟囱，整合成十几个大烟囱而已，或者新建一个大烟囱，并不真正在理念、技术、产品和组织上进行改变。
而中台不是平台，中台只有一个。未来的大中台理念会继续把这些“大烟囱”们进行整合，我们之前强调过场景化解决方案和数据深度对于TOG企业的重要性。在中台时代，产品规划更是要考虑到一体化政务服务平台的“协同、集约、创新、共享”的建设理念，思考和业务中台以及数据中台融合的可行性。
在中台概念下如果不是核心的中台主导者，也应该努力让自己变成一个中台建设的参与者。更进一步来说，需要拿出平台化向中台化过渡的解决方案，成为中台建设解决方案的市场参与者。否则，很可能最终被淘汰。
02、没有具体应用“政务中台”只是空中楼阁
“政务中台”的建设模式很像近几年各地纷纷建设的“政务云”，做相关业务的公司一茬又一茬，都说自己能建。发展到后来，就是在卖存储或者上云服务，但这些能力的可替代性太高了。在服务模式下，一家只做云服务的厂商很难做长久。
“政务中台”在这里也是一样，没有几个、十几个中台之上的拿得出手的解决方案产品，这种公司也就是一家SQL company吧。帮业主统统业务数据，画画大屏罢了。
一个完整的、有血有肉的“中台”才能发挥最大功效，帮客户解决问题，得到客户的信任，业务才能深耕。
03、谁来补齐“政务中台”的肌肉和皮肤
阿里云在近期倡导的“1+2+2+N”的技术架构很清楚的说明了这一点，在这里“1”指的是政务云，第一个“2”指的是中台中的重要的两部分，包括业务中台和数据中台，第二个“2”指的是业务的两端，包括以钉钉为代表的政务G端，和以支付宝为代表的服务C端。而其他厂商需要在大厂的技术架构下，提供N种有效的、有价值的、有智慧的生态应用。
所以厂商的应用首先需要上云，上云是生态企业比较重要的一步；其次需要配合接入业务和数据中台，成为数据治理体系的一部分；第三就是挖掘移动应用的潜能，包括移动微信、企业微信、小程序、或者独立APP等等都是需要研究的服务承载方式；最后是厂商本身的产品设计。
未来的中台架构之下，生态应用的独立存在的可能性很低，无论是业务的需求还是客观的部署情况，都需要生态应用能够满足以上要求。
04、不相信“中台”，凭什么去碰“中台”业务
有的公司做中台业务做的很惨，到处宣传中台的力量：能够驱动业务的持续化增长，能够打破数据烟囱，重组组织关系，让数据多跑路，让群众少跑腿。讲了大半天，你问他，你们公司有没有给自己做个业务中台？他就开始闪烁其词，不知所言。
一家自己都不相信中台理念，从来没有进行过中台实践的公司，你如何去信任他帮你统筹建设业务和数据中台？
建议所有想把“中台”作为今后一段时间公司发展的重点的公司，首先在自己的公司里把所有的人事物、产研运、各产品线统一归置到中台之上，看看自己是否真的有能力正常运行。如果在自家公司内部这样，没什么业务隔离、数据壁垒的环境下建设中台都很吃力，就更不要说政务中台需要治理上百家业务系统和差异巨大的数据烟囱了。
等服务好一家客户，已经是5年以后的事情了，怎么可能复制粘贴经验到别的项目里？
05、不懂业务的“中台”，不是个好“中台”
有一些公司自己的产品还没在这个垂直行业落地几个，就想去动手改造别人的业务逻辑。但实际上每个“政务中台”都是独一无二的，要充分了解客户的业务流程是怎样的，充分调动客户的参与感，让需求和数据去定义服务，融合现有产品能力，才好落地“政务中台”业务。
在现有的实践里，都需要业主方成立专班，梳理所有的业务和数据逻辑，重塑业务流程，然后再预见性的补充发展观点，最后协同乙方共同进行业务实现。
中台建设中恰恰是那些拥有多年业务系统建设经验，同时努力拥抱智慧化建设的资深行业专家型的公司，可以建设和服务好业主方。
所以我们说，“政务中台”建设的难点不在于技术层面，而在于业务逻辑的优化，包括业务逻辑的流程再造和智慧化改造。
06、跨部门业务和数据治理的显性需求
中台业务建设里面有一个非常引人注意的生态建设需求，就是业务的“跨部门业务和数据治理的显性需求”。
这个需求的政策来源是类似于“最多跑一次”、“一网通办”的政策，除此之外来源于以前各部门独立规划业务，出现部分业务重复建设的客观问题，以及随着现在逐渐兴起的业务上政务云的趋势，把这种需求和问题进一步放大。
而中台建设要求的数据和业务的统一、业务端统一和服务端统一的要求，是解决以上问题的重要推动力。跨部门治理可能是各局委办之间的，也可能是各事业单位之间的，也可能是政企之间的（如银行等）。
所以在生态应用的角度上，未来的趋势是大部门之间的业务流转，这使得厂商业务设计能力的门槛更高，mini生态公司会比较难有机会参与到中台生态建设中。
07、“政务中台”不是一年就能建成的
中台的建设不是一年一个项目就能完成的，也不是建好以后就一成不变的，中台服务需要业务的滋养，客户的业务在不断变化和发展，流程也会重组和修正。
除此之外，中台业务需要特别的运维和运营思路，可以试着建立独立的业务运维小组，包括产品、架构和研发运维小组的最小可行性业务小组，让整个流程在任何一个发展节点，都能让中台发挥作用，成为一个“流动的业务中心”。
08、总结
我们最近经常讨论“疫情改变了什么”，其实在TOG行业，精细化的城市管理、更有效的经济运行方式是对于TOG行业改变最深刻的方面。我们也看到了中台这个概念进一步推广和落地的可能性。
我们甚至已经给“政务中台”想好了一句推广语：中台助你，“码”上办理。
免责声明：本文版权归原作者所有，文章系作者个人观点不代表蜗牛派立场，如若转载请联系原作者；本站仅提供信息存储空间服务，内容仅为传递更多信息之目的，如涉及作品内容、版权等其它问题都请联系kefu@woniupai.net反馈！
]]>中台建设对于大企业来说是一件必不可少的事情，什么是中台呢？中台是指为企业前端业务应用提供共享服务的平台，该平台可以快速的响应企业业务需求，支撑企业业务的运营和创利。本文作者通过自身经验通过全面分析，中台建设中我们如何做好需求调研。
一、调研背景
公司明确希望推动中台建设，但因为之前“既没做过，也没见过”，不同人对中台的预期完全不同且十分模糊。为了了解各部门及同事对中台的理解，经过领导授权，产品经理需要在一周之内完成相关的需求调研工作。
二、干系人分析
1.选择分析
由以上识别获取需求干系人的一般方法可知：初始需求是由公司大Boss提出的。但由于职级不对等，平时跟大Boss沟通机会较少，所以还需要寻找其他业务干系人（可深度沟通且业务高度相关的人），从中可以学习到相关的业务知识，更好地探索业务需求。
2.选择策略
由于公司人员较少，部门层级较为扁平化，平时与各部门或人员的沟通机会比较多，对对方的工作内容也都大概了解，所以在寻找相关干系人时较为容易。因为该调研任务是为了了解公司对中台的理解，故只需找到各部门负责人及业务负责人即可。
3.利益相关度
中台化作为公司的战略方向，主要目标就是为了降本和增效。而公司的各个部门都会涉及这两部分，故中台化的实施建设对各个部门的相关负责人也都会产生相应的影响。作为公司的核心部门，如技术研发部、产品运营部和市场销售部，其部门相关负责人对中台化的顺利实施相对于其他部门来说影响也会更大。
附：公司组织架构示意图
三、访谈策略
1.从【问题】出发的访谈策略
2.从【机会】出发的访谈策略
四、访谈方案
1.鉴于公司人员较少，部门层级也比较扁平化，所以在做具体干系人访谈时，只需根据事先拟好的访谈提纲及考察重点进行45-60分钟时长的访谈即可。另外，我选择的部门干系人一般为两个人（部门负责人+业务负责人）。
2.访谈干系人会涉及公司各个部门，所以我会优先访谈对中台化建设影响比较大的部门，如市场销售部、产品运营部；因为业务负责人职级相对低一些但业务相关度较高，所以我会优先访谈各部门的具体业务负责人再重点关注访谈部门负责人。
3.完成各部门及相关干系人的访谈任务后，我会把具体访谈内容加以整理汇总，合并同类项，从中提炼抽取出各部门的业务目标及业务需求，并进行综合评估。
4.自我访谈
4.1怎么样才能建设好中台？
- 从各产研小组抽调出单兵能力较强的成员，快速组建中台团队；
- 建立相关的管理机制和规范，如OKR考核、前台对接流程等；
- 明确中台建设目标及领域，深入调研各业务模块流程细节及潜在问题，梳理价值链；
- 敏捷开发，小步快跑，快速优化迭代。
4.2中台化建设不好推进怎么办？
- 动之以理：中台化建设是公司级的重要战略，关乎公司未来几年的发展，责任重大，意义深远；
- 晓之以情：中台化的建设，对各业务部门的业务发展会给予更有力地支撑，也会更容易达成对部门或个人的KPI考核指标。
五、评估需求
六、业务目标
通过对相关部门干系人的访谈和需求评估，可确定如下业务目标：
1.提升产品服务满足度和品牌知名度；
2.提高产品市场占有率和利润空间；
3.降低各种成本，提高公司盈利水平。
七、最终结论
综上所述，为了能降低人力、资金和时间等成本，提高公司各项业务的盈利水平，我司应该尽快推进中台产品建设。但在推进中台产品建设之前，我们最先要解决的问题是如何保证在不影响目前业务进行的基础上完成中台产品建设。
建议如下：在目前各业务系统功能稳定运行的前提下，单独成立中台研发团队，专门负责中台产品的相关规划和建设。中台产品正式投产后，再将各业务功能逐步对接迁移至中台。
免责声明：本文版权归原作者所有，文章系作者个人观点不代表蜗牛派立场，如若转载请联系原作者；本站仅提供信息存储空间服务，内容仅为传递更多信息之目的，如涉及作品内容、版权等其它问题都请联系kefu@woniupai.net反馈！
]]>最近几年“中台”被行业大厂炒得如火如荼，甚是火爆，业务中台、数据中台、技术中台、风险中台、管理中台等等概念层出不穷，生怕错过中台这一“大风口”，但并不是每个公司都适合追这一风口，甚至举整个公司之力来搭建中台体系。
什么时机建设中台，不取决于公司大小，而是取决于公司是否需要快速扩张。但在公司是否决定建设中台之前，作为产品经理，需要为领导提供一份可行性调研报告，以此说明公司中台建设的时机是否成熟，而为了建设中台，公司又需要做哪些努力和调整。
一、什么是中台
所谓中台，结合公司现有业务通俗来讲，是将预付卡支付、互联网支付、跨境支付及企业钱包等各业务线的共性需求加以提炼并抽离，比如商户中心、账户中心、计费中心、支付中心、清算中心、风控中心、数据中心等，将其打造成为一种具有平台化、标准化、组件化的系统服务能力，然后以接口或服务的形式提供给前台各业务单元使用。使前台的各支付产品在更新迭代、创新拓展的过程中研发更灵活、业务更敏捷，最大限度地减少“重复造轮子，烟囱式架构’的KPI项目、组织架构或设计思维。
二、为什么要建中台
结合我司目前的业务现状，各条业务线“各自为政”，自己建设自己的业务模块，完全业务闭环。导致一些系统功能重复建设且无法在其他业务线进行复用。由于各业务线的系统架构设计不统一，一旦涉及到多条业务线的协作配合，就会出现系统功能扩展性较弱，业务处理流程繁琐，对接周期长等问题，严重影响了前端商户的使用体验，同时也浪费了公司的各种资源。
三、中台建设方案
1.建设目标
基于目前各支付业务的发展状况，避免各支付业务线的系统功能重复建设，节约公司成本；将各支付业务线的共性需求提炼抽离出来形成一套标准化、组件化、松耦合的各业务线可以共享的系统能力，支持前台各支付产品的快速迭代，灵活创新；不断沉淀并增强系统的服务能力，在不大量增加人力的情况下，支撑公司3-5年内前台各支付业务线得以更好地建设和发展。
2.建设领域
3.涉及业务单元
4.中台建设图
四、可能遇到的困难
1.因为各支付业务线各自独立运营，进行中台建设，需要清晰梳理各支付业务线的业务需求及系统逻辑，投入的成本巨大；
2.各支付业务线已各自正常运营多年，一旦进行中台建设，会对现有业务的开展产生冲击，影响到相关市场销售的利益；
3.各支付业务部门领导早已习惯目前系统的运营状况，说服他们配合推进中台建设，难度较大。
五、最后小结
中台建设的目标大概可以分为三种：去重、复用和做强。去重，即避免重复建设，规避重复造轮子、烟囱式架构，节约公司成本；复用，即系统重复使用，标准化、组件化、松耦合，支持前台业务快速迭代，灵活创新；做强，即能力不断沉淀，服务可被不断滋养，体验可统一把控。
作为产品经理，对于公司是否需要建设中台这一问题，需要做很多的前置性思考和规划。首先需要明确公司背景，比如从长期来看公司会关注什么事情？目前现状如何？目前的问题可能是什么？通过这步把公司的情况思考清楚，我们现在有什么项目，未来可能会开展什么项目？然后梳理价值，公司哪部分业务或系统适合作为中台？中台在其中的价值是什么？是开源、节流还是提效？因为你要立项，就必须先取得上级的认可，作为高层最关注的就是你做的事情到底有什么价值。明确项目价值之后，才会去关注你想怎么干。最后就是初步的方案构想。在阐述清楚中台价值后，就可以阐述初步方案。
对于初步方案，简单看就是梳理清楚：方案的影响面（会涉及哪些部门）、大概的方向（我们大概会怎么做）、以及可能遇到的困难。
免责声明：本文版权归原作者所有，文章系作者个人观点不代表蜗牛派立场，如若转载请联系原作者；本站仅提供信息存储空间服务，内容仅为传递更多信息之目的，如涉及作品内容、版权等其它问题都请联系kefu@woniupai.net反馈！
]]>不知道大家有没有注意到，现在我们一谈起中台，经常会伴随着中台会听到这两个词：微服务，SaaS；但是这两个东西到底有什么区别？这三个产品是否相等呢？
现在几乎是在很多的文章里都有人提出过这样都说法：
那么到底中台与他们有什么关系呢？
今天我为大家带来了我个人的理解：中台既不等于SaaS也不等于微服务，我认为这三者是一个完全不同的东西。
1、SaaS与中台
SaaS在我看来其实是一个服务于需求方的一个成熟的软件的产品，通常SaaS会为用户提供了一个运算逻辑服务以及加一个操作终端，事实上就是为外部用户提供了一个标准的解决方案。
但是这里第一个对于中台来说不同的点是，实际上很多时候中台是我们在企业内部的一套管理调度工具，相当于中台是在管理企业内部的一个生产资源，我们可以抽象理解为各个产线上的一些生产机器的一个资源管理，所以它的重心在于管理与调度内部的资源，并不一定会拥有一个可视化终端。
第二个点中台更多时候是为前台业务线提供半成品服务，而非像SaaS提供完整的解决方案。
但是这不意味着两者没有关系了，其实还是有一定关系的：我认为SaaS其实是中台发展的下一阶段演化产物。
现阶段绝大多数这些做SaaS的企业，通常都是直接根据市场的需求去定义了一款SaaS的软件。
那么事实上我觉得企业有了中台之后，其实每个企业到最后，在他自己内部把他自己的业务模式跑通了之后，并且将核心服务提取归属到了中台后，在经过一段时间的打磨后把中台理顺了，那么再往下发展，其实这个中台就可以抽象出一款SaaS，去服务于整个行业和与自己类似的小企业。
例如在一家电商公司中，在一开始的时候可能这家公司只是专注于某个业务，比如说是专注于化妆品垂直销售的电商平台，一开始他的系统与业务流程都是只服务于化妆品业务销售。
而当企业业务进行发展并多了之后，企业开始进行业务多元化，然后企业内部就有了不同的业务线，比如说开始涉及ToB的业务，此时企业内部就开始发现似乎有很多东西可以复用，那这个时候便开始慢慢去搭建一个中台，然后在中台基础上我去把很多的东西去抽象出来，抽象出来的开始交由中台去和各业务线对接，将这种模式完成跑通。
当然此时中台需要采用标准的：Summary-Details分离设计。
再往后公司开始发现有一些行业的通用问题，而我们内部产出的解决方案，或者抽象出这个东西，不仅仅是我们企业内部能用，其实行业中很多小企业都可以用这个方案，特别是比我们弱的这些产业中的长尾企业，他们都可以用我们这一套抽象出这个东西。
因此我们就完全可以在中台基础上再去进行一个抽象，然后变成一个SaaS对外输出这个能力。于是中台摇身一变就从企业内部的一个工具变为了SaaS，因此未来很有可能每个企业都可以将自己的中台再做一个拓展，变成可以对外输出的一个SaaS化产品。
抽象逻辑由小到大是这样的三个阶段：
3、微服务与中台
刚才我们谈完了SaaS与中台的关系，接下来我们来谈另一个高频词汇——微服务。
事实上微服务它并不是完整的一个产品，也不可以拿来独立使用，它相当于只是一种技术实现手段，例如我们在代码里头听过很多的架构设计模式。
无论设计模式还是设计框架，那么微服务都属于是一种我们实现技术实践的一种方式，和我们的产品设计是不一样。
也就是说中台事实上是一个系统级的设计方案，或者说是一个新的产品方案，而微服务相当于只是我们的一个实现它的方法。
再举个通俗的例子，比如说我把这个大楼的图纸画好了，这就是我们的中台，但是实现上我可以是使用砖混结构去盖楼，也可以使用别的方式搭建，那砖混结构盖楼方法就是微服务，就是我们的一种实现方式。
而中台由于为了将一个个服务抽离出来作为独立的服务，因此我们就必须使用微服务的实现方式。
在了解清楚了这个概念之后，很多事情我们就能看明白了，比如说为什么在双11的时候，我们去一些电商能看到虽然此时购物车卡顿了无法加购，但是商品都还可以去浏览，原因其实就是因为他用微服务去进行的实现，在这种大并发情况下就充分发挥了微服务最大的优势，虽然说我的架构服务以及后面订单服务挂掉了，但是我的商品中心这些服务都还正常，因为这几者之间没有强耦合，所以我还可以去进行浏览商品，没有任何问题。
我们可以看一个基于微服务架构的设计：目的有效的拆分应用，实现敏捷开发和部署
3、总结观点
所以总结一下这三者关系：
- 中台：面向企业内部提供服务，提供半成品生产能力，同时提供配套服务；
- SaaS：是一个服务需求方的完整解决方案产品产品，如它为顾客提供了完整的端到端解决方案，如计算后台到客户操作终端；
- 微服务：产品微服务只是中台的实现手段之一但不是中台，微服务是中台实现的技术手段。
免责声明：本文版权归原作者所有，文章系作者个人观点不代表蜗牛派立场，如若转载请联系原作者；本站仅提供信息存储空间服务，内容仅为传递更多信息之目的，如涉及作品内容、版权等其它问题都请联系kefu@woniupai.net反馈！
]]>