最近关于中台的概念，在B圈议论很多，很多公司也有这方面的尝试或者想法，但这里面有几个观点希望和大家探讨一下。
首先到底怎么理解这个中台，每个人都有不同的观点，但中台可以叫中台，也可以不叫中台，为什么这么说呢，因为他严格意义上不是一个产品，而是一些支撑用户与平台在业务层面极致交互和体验的功能模块的集合，对很多平台来说可能就是一些功能区块的排兵布阵或者重新集成、强化某方面的使命而已。但为什么又叫中台呢，这是区分前台和后台，便于运营，因为只有中台的功能区高度共享，简便高效，这样才能更好的支撑前台定制化、个性化；或者业务渠道、模式的多元化。这样才能实现B端追求效率的诉求。
所以说中台这个概念，可以叫中台，也可以不叫中台，这一点很重要，否则，就会把中台当做一个大项目在操盘，最后可能落得雷声大雨点小的窘境，很多企业往往做中台做的半途而废或者原地踏步，往往就是这一点认知造成的，另外还有就是中台最大的障碍就是ROI失衡，投入很多，收效甚微，这也是很多企业中台失败的原因，能突破这个临界值的平台少之又少，毕竟规模和多元化服务是硬核。另外，中台需要业务多元化，体量足够大，才能发挥价值，注意不是没有价值，是发挥价值，这也与ROI这个回报失衡有关。
中台的目的也不能过于寄予希望给经营带来改变，这只是服务经营的路径的重新集成，目的是为企业加强客户的转换，加强体验和用户满意度，希望追求中台做经营上的改变都要适可而止，所以说中台只是结果，一种经营模式的呈现方式，没有业务上的起势、生态上的布局、模式多元化，就想通过系统调整构建概念来带动经营模式的转变，最后都是不了了之，都属于扯淡，割一波韭菜，过两天再来一波“中后台”才是迎合趋势的言论，然后继续周而复始。
中台作为一些靠近用户的功能模块的集成，自然要跟前台后台有所区分，毕竟介于前台业务和后台管理的夹缝中，注定在定制化、规范化上要兼顾。这就要跟业务和管理适当分割，而管理规范化层面又分为驱动业务的流程管理和驱动决策的数据管理，相互之间不要搅和的太深。很多流程一边要满足业务时效，一遍要满足管理规范，自然就又臭又长，不做分割何谈高效支撑前台业务，何谈合规管理供应链。
因此，做成中台难就难在很多企业实现不了流程、权限和数据的对接，路径自然也就不存在，更别说客户层面的业务支撑，张口效率、闭口体验的绝对是说说而已。一个B端的供应链交易型平台，流程，权限、岗位、员工，自有一套流程体系已经够复杂了，如果再有一套SaaS的定制化程度较高的规则，那是难上加难。而现在几乎所有的平台又都在追求一套SaaS底层数据全部搞定，这个要求就要求底层流程体系的全部打通，这样才能实现底层数据的全部打通，因为只有底层打通了，数据化，可视化才有意义，底层打通的平台，前面说的流程、岗位、权限、人员、以及随机性的管理，都得搞得规规范范才可以考虑。如果对业务的理解不够深，产品架构的能力不够强，核心技术不过关，基本就是镜花水月。如果碰上经营或者团队的不稳定，那这个底层的打通就可能周而复始，遥遥无期。
很多B2B平台，前台都很弱化，就贸易+信息化的后台，基本前台更多做成了摆设，尤其很多产业是贸易起家的，干脆前台运营都不想要，直接系统跑自有业务流程，这时还希望通过自己所为的供应链综合服务、形同虚设的前台唱线上线下一体化的戏，又希望能将自己所谓的综合服务向采供销进行传递，措辞上渗透，延伸、击穿溢于言表，无非是希望达到一个目的，将自己的已实现的平台能力，系统能力，产品能力能够击穿上下游，实现上下游的生态化，但怎么击穿、落地就三缄其口，这就是典型的概念化综合服务平台。
如果要实现击穿和渗透，模式和产品输出，往往涉及到平台实际操盘人的经验、认知和魄力，一个模式或者产品或者服务，想要击穿上下游，最能够达到极致验证，跑通想法的是独立团队打磨，成熟后交付，但很多传统企业却仍然是部门化管理的思维，不是产品化运营的思维，所谓的部门化管理的思维就是一个业务模式或者服务产品，仍然交给对应的已有的部门去执行，例如交给地推部门去推，看似符合管理的规范，和部门岗位的设置定位，但却是因小失大，可能地推部门都没有弄清楚怎么回事不说，他们认知程度、重视程度、兴趣以及相信度都相差甚远，这就导致了周期长，内耗高、来回推磨就是难落地，这就是对应的思维决定认知，组织设计决定落地。遇事先满足规范，落地先符合条框，执行按图索骥，这就是典型的部门化管理的思维。
所以说，中台的概念涉及到认知、前中后台的协同，涉及到系统的底层流程、权限、岗位、人事、数据层面的流畅、稳定、互联互通，也涉及到业务的规模、模式的多元化、还涉及到操盘人的认知和落地执行的举措等等，要有一个操盘*权人**衡所有，适力而行，稳定大于一切。