提起中台和SaaS你会不会想问这些问题？
目录：
中台理念最早由阿里巴巴提出，更准确说是马云认为面对未来快速变化的商业社会，具备市场竞争力的一种组织模式，是通过组建灵活小巧的前台团队，频繁并低成本试错，进行商业创新，为了能支撑这样前台团队，需要组建中台团队，负责建设复用业务能力的软件平台。
很多时候我们聊起中台有很多争议和困惑，主要原因是搞错了中台所服务的前台，并不是我们通常理解的前台，我们通常会把APP、UI、应用层、应用软件、客户端等称为前台，但在中台服务理念里，中台所服务前台更多指代一个具有自主性和灵活性的前台业务团队。
这个被阿里称为“大中台小前台”战略，从业务和组织视角看，小前台首先是团队人员数量少，只需要少量市场和运营轻巧资源，无需加入产品甚至研发这种沉重资源；其次团队容易组建和调整，甚至可以是临时组建，人力组织成本低；最后面对市场的变化，响应更快速，业务流程更直接和敏捷，能频繁进行低成本业务试错。
从产品和技术视角看，是一个用以支撑多个灵活小巧的前台团队的系统平台，前台团队是纯业务团队，中台团队提供全套产品和技术支撑，提供可复用产品能力外，还要能快速响应业务团队的市场需求，低成本敏捷迭代产品，支持业务快速试错。
假设某外卖APP开通两个城市服务，深圳地区外卖和上海地区外卖，组建深圳运营团队和上海运营团队。
这两个团队在本地化运营过程中可能会存在一些市场需求的差异，例如深圳和上海运营团队在招聘骑手、运力管理、商家入驻运营、用户奖励活动等日常运营工作上不会完全一样，因为所处业务环境、地区、市场竞争会存在一定差异的。
同样的，当外卖APP开始扩展新品类，例如从餐饮外卖到鲜花、超市、药品外卖时，组建的新运营团队在产品功能需求上的差异，可能更多集中在服务品类上，例如商品管理、商家资质、配送时效、类目属性等。
这些差异属于因不同业务环境，存在一定的业务灵活性和自主性，抛开这些，我们会发现外卖业务主逻辑（消费者下单，商家履约，骑手配送）是不会因地区和品类差异而变化。
通过外卖APP例子，我们可以认为“小前台”指代的是这些因业务需要组建的前台业务团队，这些团队在同一个行业环境下（外卖行业），所使用的业务系统中，业务的主逻辑相似甚至相同（消费者下单，商家履约，骑手配送）。
因此前台业务团队要求能高效重用已有系统以满足业务快速扩展需求（例如开通新地区、新品类），同时又需要针对业务环境进行高度的灵活性和自主性（例如商家招募、运力管理、市场营销、骑手奖励、团队KPI），以满足各自的业务需求。“大中台”就是能够满足前台团队对于复用业务能力和自主需求的系统。
还是以外卖APP为例，从消费者旅程视角看，外卖APP核心业务流程是消费者选购下单，商家接单履约订单，骑手取货即时配送到家。
消费者、商家、骑手是实现业务闭环的角色，外卖APP作为平台负责为实现业务闭环提供业务能力。
同样的，商家招募、菜品管理、订单管理、骑手招募、运力管理、派送管理、时效管理都是为了实现商家订单履约业务流程和骑手即时配送业务流程所设计的产品功能模块。
从整个外卖APP视角看，业务能力就是由三个流程组成的业务闭环，这个业务能力是经过多年外卖业务实践并沉淀形成的，是具备提供面向外卖行业解决方案的能力，是可被复用的业务能力。
可以说，一家公司的业务能力是对所处的行业提供行业解决方案的能力，提供的行业解决方案高度依赖公司所拥有的资源和能力，公司所处在市场竞争环境，内部组织环境，技术积累，人力结构等，这些都会影响其方案最终效果。
顺便说下，讨论一家公司的中台价值，需要先去理解这家公司的所处行业，业务能力，建设中台起点和目标，还有技术积累，组织能力，人力结构等等，否则是毫无意义的。
一个行业从形成一定市场规模到实践出行业解决方案，至少经过探索期、成长期、成熟期，其中探索期会出现大量创新的行业解决方案，这些方案存在很大的市场不确定性，频繁变动的业务流程很难被复用，探索期更关心跑通商业模式和产品PMF。
进入成长期后行业解决方案经过优胜劣汰，留下来都是经过市场检验的，沉淀下来业务能力，具备复用的可能，同时成长期更关心业务的规模化扩张，这同中台理念相呼应。
这时候的业务能力其本质是面向特定场景下的行业解决方案，可以抽象分为业务型和领域型。
业务型行业解决方案面对的市场，更加的复杂和多变，行业竞争更加激烈，需要解决和满足市场需求和用户需求外，还要解决商业模式可持续的问题，简单来说解决如何多赚钱少亏钱，用户、企业都开心的问题，业务容易被市场和政策变化所影响，好在行业特性和边界较为清晰，存在很多业务垂直细分行业。
常见业务型行业解决方案：
领域型行业解决方案更多集中在组织管理、办公协同、行政、人事、财税、法务、发票、工具等，需要解决都是企业行政和职能方面问题，简单来说解决公司人与人协同协作效率的问题，面对是成熟的市场环境和商业环境，较少会被市场和政策变化所影响。
常见领域型行业解决方案：
常用的行业分析方法论：
当两个行业在行业特性和业务流程上存在相似的时候，可否共用一套业务流程，来提高公司开展新业务效率和节省产品研发资源？
既然存在相似功能模块，那电商交易场景和外卖交易场景能否共用一套中台系统？这样即可减少重复建设问题，通过共享和复用还能提高产品建设效率。遇到差异流程和功能，进行抽象处理，来兼容两个交易场景需求。
答案是不能，这想法从一开始违背了中台的初衷和理念，中台服务的是灵活小巧的前台业务团队，复用的是行业解决方案，不同行业之间存在特性和边界，这个很难通过产品或者技术手段进行抽象复用，在中台架构设计上没必要为了抽象而抽象，何况电商交易的团队和外卖交易团队在部门权责和组织架构上存在很多差异，强行统一使用一套中台服务必然出现很多职责和边界问题，容易引起组织和业务矛盾。
那有没有其他办法解决这个问题，既不会违背中台理念，不跨行业共用一套中台，不出现重复建设等问题？
我们假设当完成外卖APP产品建设，外卖前台团队扩张更多新地区和新品类，业务蒸蒸日上，实现外卖行业的中台和业务能力复用，现在准备扩张新赛道进入b2c电商行业，肯定会考虑哪些外卖业务能力和产品模块具备可复用到电商行业的机会。
从行业特性视角分析，外卖行业基于lbs技术提供o2o需求和服务，用户通过地理定位选购附近的实体店商家（目前消费需求让实体店商家概念进行细分，包含前置仓、社区商超、便利店等），通过骑手即时配送到家，配送时效50分钟左右。
电商行业中用户可以选购任意地区商家、超市、工厂、经销商等，可选商品数量理论上∞（无限），通过快递跨省跨市配送到家，配送时效1-3天左右。
行业特性决定了商品选购、商家资质和配送业务流程差异较大，电商交易场景和外卖交易场景属于两个不同的行业，不是大行业和子行业的关系，无法直接共用一个业务流程和业务中台。
互联网企业最喜欢的以事业部为单位的业务组织架构，特别是业务发展为主导的企业中，产品和研发部门也可以进行职能共享，支持整个公司所有业务团队。
这时候产品规划不能局限在某一个业务线上，而是面向整个公司业务进行，否则产品和研发部门会因事业部的业务发展压力，无节制的扩张人力资源，导致组织过于冗余和臃肿，缺乏整体规划影响产品质量。
产品和研发资源倾斜在业务迭代上，产品模块设计只能满足当下业务需求，甚至重复建设，缺少对业务未来的发展思考，最终导致产品维护成本上升，无力维护形成“烟囱式”系统。
参考阿里、腾讯等大型互联网企业的中台建设，可以得出一个有意思的结论，多业务线的公司，当面对多行业，跨行业时，会有多个中台系统，满足公司不同的业务线使用，同时还会将具备可共享的能力建设成SaaS产品，开放服务给市场使用。
除了阿里集团开放能力建设生态平台外，具有多条业务线的企业，也可以从研发资源和业务效率上考虑，对适合的产品模块进行SaaS产品化，减少重复建设和烟囱式、孤岛式系统，特别是跨事业部和跨部门，能有效提高研发资源和业务能力的利用率，产品架构健康边界清晰。
中台具有复用能力是为提高业务发展效率，在中台基础上，进行SaaS产品封装，开放服务给市场使用，提供服务属于业务中功能边界清晰，适用场景广泛，复用场景多的垂直业务类型。
SaaS可以说是中台的下一站，如果说中台服务前台团队，服务的是企业的前台业务团队，那么SaaS产品是开放服务整个行业。
顺便说下，中台一定是行业内中台，特别是业务型公司建设的中台和公司业务高度依赖，是行业解决方案，所以不存在跨行业中台，这是中台理念和架构风格决定的。
当行业规模足够大时，会因市场和用户需求发展，细分出很多专注在垂直领域的行业，这些细分行业相互之间存在一定的业务关联和相似。
据国家统计，2020年国内零售电商交易金额接近10万亿人民币，其中90%交易金额由B2C、C2C、B2B三种电商细分行业产生。
从行业特性视角看，前台业务上有差异，同时存在相似的业务流程，具有可复用或共享的机会。
电商行业特性举例：
B2C和C2C交易对象都是个人买家角色，消费端的商品选购、搜索推荐、订单履约、客户关系管理、物流售后等产品模块存在相似业务流程，具备复用价值。
B2C和B2B货品出售方都是商家角色，商家经营端的商品管理、类目管理、商家资质、保证金、货品要求、合规要求等产品模块存在相似业务流程，具备复用价值。
寻找前台业务上的差异部分和相似的业务流程部分，直到整个业务完成闭环，然后复用相似业务流程和产品模块，甚至对部分产品进行SaaS设计，这样能有效减少重复建设，节约产品研发资源，同时提高整个电商产品线系统效能。
理解行业和行业特性，根据特性识别行业的特性差异以及复用相似业务流程和功能，是能够带来更高效的业务效率，同时还能避免重复建设对前台团队独立性和自主性的影响，通过将业务能力的复用转化为特定场景下的行业解决方案，提高整个系统的效能，同时促进企业内部业务创新。
复用业务能力不单单把业务逻辑和模块进行抽象，提供给多个需求方或团队使用，而是能准确的理解公司业务的核心逻辑和流程，公司所处行业情况，市场环境，竞争态势等，提炼核心业务流程闭环，然后沉淀业务能力，最终实现公司业务的复用能力，支撑快速响应以用户为中心的需求。
可以被复用的业务能力，首要前提是业务的稳定性高，如果业务因市场或其他原因改变频率太高，那就缺少复用的价值。
以外卖行业为例，经过多年发展行业已经进入成熟期，美团外卖加上饿了么占据市场90%以上的市场份额，美团外卖和饿了么APP的用户旅程体验成为国内外卖行业业务流程标准。
从行业的成长期开始，核心业务流程平均变化频率在5-10年左右，流程功能（领域模块）平均变化频率在1-3年左右，前台团队的自主需求平均变化频率半年左右。
到行业成熟期，业务趋于稳定，核心业务流程和领域模块固化不变，前台团队需求有一定概率会因为市场增速放缓进入日常维护阶段，根据行业发展趋势和平均变化频率，可以识别和提前规划复用能力平台。
建设一套中台系统应该采用那种理论知识？
常用的架构方法论：
云计算深刻影响信息技术和互联网的发展，奠定现代互联网基础，至少在可见的未来10-20年内，云计算还会继续支撑互联网的发展。
一套中台架构至少要满足未来3-5年企业战略规划，要做到支撑业务发展上限，直接照搬或模仿大厂中台架构往往容易建设失败，主要原因是中台架构需要考虑公司的愿景，战略目标，组织能力和资源投入，行业环境，市场竞争等等，就好比你照抄全套淘宝产品功能，也无法重建一个淘宝一样，因为能被抄袭和模仿，是看得见的产品形态，看不到的还有业务知识，组织能力，资源投入，企业愿景战略等等。
中台理念从诞生到落地实践，已经发展数十年，行业内出现各种各样的中台，例如业务中台、技术中台、移动中台、数据中台、管理中台、组织中台等等，每个中台都是公司对业务理解和业务需求的产物，这里我们不去讨论那种中台更好更适合。
还是那句话，毕竟脱离一家公司业务能力和资源，建设中台起点和目标，还有市场竞争环境，内部组织环境，技术积累，人力结构等这些环境因素，去讨论中台建设是否有效，或是建设那种中台是毫无意义的。
中台其本质是支撑多个灵活小巧的前台团队的系统平台，是满足前台团队对于复用业务和自主需求的系统，是面向特定场景下行业解决方案，是为了实现业务目标的业务系统。
只要是业务系统，那就需要落地实现，从实现业务系统技术视角看，溯本追源，业务系统是由业务流程、模块功能、业务数据以及使用业务系统的角色组成。
业务流程以及产品模块功能规划到业务中台，业务数据规划到数据中台，业务中台和数据中台的技术实现中应用到的技术需求规划到技术中台。
中台部门是由产品和技术研发组成，部门核心职能建立和维护公司的能力复用平台（中台平台），并满足前台团队快速响应市场变化的需求，其部门和岗位职责、职能、职级应该根据公司愿景、战略目标、组织架构和能力、人力构成等多方面因素考虑，尽可能达到权责利的平衡。
三套中台系统里：
中台与SaaS最大的区别在其服务理念上，建设中台的主要目标首先是沉淀业务能力，复用业务能力，消除重复建设，消除“烟囱式”“孤岛式”业务系统，提高业务系统和组织的内部效能；其次是快速响应前台业务团队需求，提供频繁的低成本业务试错能力，促进业务团队创新。
中台能在国内高速发展，其主要原因是国内具有容量巨大的单一市场和高互联网渗透率，使得赢家通吃成为可能，国内的巨头企业会利用自身流量和资本进军更多行业和市场，这样的市场竞争和业务扩张策略催生了中台需求，可以说中台是国内特有的商业环境和生态环境塑造的，其目的是为了寻找效率更高，成本更低的业务架构和组织架构，用来支持业务的快速扩张和高速发展。
2009年NIST（美国国家标准与技术研究院）为云计算定义三种服务模式，同时诞生订阅收费商业模式，服务模式之所以这样划分，主要的目的是开放服务，降低it使用成本，通过低成本和高效率应用最佳实践，构建生态促进繁荣和创新。
国外的SaaS产品当红炸子鸡shopify提供电商服务平台，主打开放服务是通过简单操作即可创建一套功能丰富的独立电商网站。
假设没有shopify这样的SaaS厂商，需要建设一套功能丰富，操作简单的独立电商网站需要进行哪些投入？
首先是组建产品和技术团队，然后进行研发和测试，最终购买服务器进行部署上线，电商网站服务期间还需要技术团队进行维护和bug修复，对于只需要卖货的品牌经销商来说，整个投入成本太高，建设周期太长，回报太小。
或者购买外包团队的产品，又会涉及到产品要求、产品质量、产品售后等等问题，机会成本太高，风险太大。
IaaS、PaaS、SaaS三种服务模式提供开放服务的能力，订阅收费模式做到按需付费，降低机会成本和使用成本，为市场带来的低成本和高效率使用最佳实践的方案，三种服务相互补充和完善最终构建健康生态。
其实天猫、淘宝、京东等这类电商平台从云计算服务模式视角看，属于SaaS应用范畴，同样是开放服务，采用订阅收费，为客户降低使用成本，提供电商领域的最佳实践方案，不同的是因国内市场环境这些服务和电商平台是相互绑定和依赖的，这也是国内外生态建设上最大的区别。
中台和SaaS在具体的软件应用层面主要区别在于对开放服务的支持力度上，中台服务的是前台业务团队，是为解决企业业务模式下的需求，从产品和技术实现视角看，中台的开放服务是封装的企业的业务能力，满足的是前台业务团队需求，为企业愿景和战略目标负责。
云计算的三种服务模式强调的开放服务是面向整个行业，是整个生态中所有的客户需求，封装的是行业解决方案，在通过规模化弹性能力，订阅收费商业模式，镜像和容器等技术能力，最终实现为行业提供低成本和高效率的行业解决方案。
中台产品要不要建设SaaS产品，取决于公司建设中台产品最终目标，有没有扩张业务的愿景和野心，是只做现有业务，服务前台业务团队，还是想扩张更多的业务进军更多市场，然后提供开放服务建设生态，满足整个市场和行业需求。
SaaS产品要不要建设中台，取决于市场竞争激烈程度和行业成熟度，如果市场变化快，需要频繁低成本试错，进行业务创新，那就需要中台的复用能力支撑，毕竟行业的标准化产品服务和最佳实践都是在频繁低成本试错后业务总结沉淀出来的。
除了web3.0等新的技术革命，其他行业的发展几乎都在成熟期，人口和资本的红利期进入尾声，企业客户大多开始应用标准化的产品服务和成熟的行业解决方案，定制化的需求空间不大。
从菲利普·科特勒（PhilipKotler）提出市场营销理论开始，围绕营销管理理念开发的传统应用软件不计其数，进入互联网时代开启移动化和数字化浪潮后，以云计算为主的新的技术范式带来更低成本和更高效率的优势，为企业扩张了业务带来更高的收入，同时也改变了业务运营方式，改变了支撑业务的技术架构和组织架构。
数字化营销产品非常适合用SaaS服务模式加中台理念进行产品架构：
市场上数字化营销SaaS产品涉及涵盖快消、耐消、教育、金融、医疗、电商、服务等众多领域，以产品服务标准程度可以归纳为四种类型：
采用SaaS服务模式和中台理念设计的数字化营销SaaS组织架构示例
通过配置规格、能力选项、服务质量三个维度灵活调整经营策略，可以满足市场上大部分客户对产品质量的要求，免费版本满足个人和小微客户，收费版本是利润大头，满足高价值客户。
非常推荐SaaS产品厂商都提供免费版，不设置任何门槛和要求，开放免费版系统运营成本其实很低，云计算提供的弹性技术能力，使用IaaS和PaaS的低配置，组建一套独立产品系统环境，通过镜像和容器技术独立部署，不会影响其他收费版本，自助式服务，零维护成本。
免费版是为满足除高价值客户外的剩余客户，这些客户大部分是小微企业或者个人，很难被培育和转化成高价值客户，其中部分客户会抱有极大热情愿意参与产品设计中，SaaS厂商应该利用好这点让免费版本用户成为产品持续改进的源头，毕竟在收费版做做产品创新风险高，做ABTest会被人骂。
使用应用的频率有高频和低频，关键功能有核心和非核心。开发迭代效率上也有高频紧急和低频非紧急，业务支撑上有需要频繁试错创新，也有有成熟稳定，这些差别造就应用在使用和开发上的成本不同，合理的应用边界可以隔离不必要的耦合和影响，合理的边界还能设置财务更优的订阅选项商业模式。
从组织视角看，应用之间的边界对应是组织部门权责边界和角色边界，应用之间也存在依赖和上下游关系，在架构设计中既要考虑业务和数据问题，还需要考虑组织权责和成本效率问题。
以下图为例，这是简化版本的TOC数字化营销SaaS产品应用关系和边界图，图中实线链接是业务和应用之间的上下游关系表示的业务流程。虚线链接表示的是业务数据流转。
企业建设中台的初衷是为了寻找效率更高，成本更低的业务架构和组织架构，用来支持业务的快速扩张和高速发展。
中台是支撑多个灵活小巧的前台团队的系统平台，是满足前台团队对于复用业务和自主需求的系统，是面向特定场景下行业解决方案，是为了实现业务目标的业务系统，封装了企业的业务能力，为企业愿景和战略目标负责。
中台的建设目标：
SaaS的价值是面向市场开放服务，提供标准化、低成本、高效率行业解决方案和产品服务，共建生态促进繁荣和创新。
SaaS的核心能力：
新的技术范式带来更低的成本和更高的效率，带来了商业上的成功同时也开始催生下一次技术革命，云计算是如此，web3.0也是如此。
注1:本文所涉及到的产品架构因商业敏感原因经过部分简化，可参考，不建议直接用作产品架构。