对于大部分 SaaS 公司来说，产品标准化程度决定了企业的生死。今天，我们就站在产品经理的角度，来看看

  限于篇幅，本文对如何画流程图、怎么来制作原型等基础技能就不再敷述，侧重阐述实现 SaaS 标准化设计的要点。

  为便于大家理解，本文会以一个案例为线索，一步一步演示如何从 0 到 1 设计一款 SaaS 产品。

  从根本上来说，SaaS 产品需要服务于众多企业：少则几十家，多则几万家。因此，对业务的包容性需要很强。代价则是产品迭代速度相对缓慢。

  自研系统由于只服务于一家公司，强调的是贴身服务，因此对产品包容性要求较低，但是很强调迭代的速度。

  虽然 SaaS 和自研产品的逻辑是类似的，但是对产品经理能力的要求却有一定差异。

  内部 B 端产品经理更多是辅助角色。因此比较强调深入参与和支持业务，通过协调甚至推动业务部门，达成公司目标。

  SaaS 产品经理就不一样了。因为负责商业化产品，是公司实现盈利收入和盈利的核心环节，所以比较强调产品本身的架构能力和设计能力。

  衡量 SaaS 产品经理的优劣，其中一个重要的标准就是：当用户数持续不断的增加，产品功能会不会被推翻或大幅修改，即能不能多做加法，少做减法和改法。

  曾经听某知名 SaaS 公司大区总监说，某个百万级项目谈得非常好，约定 4 个月交付上线 个月，客户真正的需求推倒重来，按客户实际业务重新开发。这位销售总监抱怨道：“前面谈得好好的，就用标准化产品。但到项目后期，客户却说产品满足不了业务需求。真是搞不懂。”

  这就是典型的产品能力支撑不了销售能力。如果这样的项目很多，SaaS 公司就很难盈利。

  SaaS 公司最大的成本投入是研发成本， 如果每一个项目都是通过配置完成交付，这在某种程度上预示着随着用户数的增加，研发成本会被逐步摊薄，最终形成规模效应。因此标准化是SaaS公司盈利的关键之一。

  即便 SaaS 公司具备丰富的行业经验，也了解行业标杆的业务策略和执行方案，如果 SaaS 产品不能体现和支撑这些“最佳实践”，那么推广和执行的成本都会很高。

  所谓标准化，实际上的意思就是把领先企业的解决方案进行提炼，再固化到系统中。这些固化的解决方案，是 SaaS 系统的灵魂。

  如果 SaaS 公司依赖运营而不是依赖产品来保障“客户成功”，那产品和产品经理的价值都会大打折扣。

  标准化会慢慢地加强产品的配置能力，使得产品越来越厚重，价值慢慢的升高。也只有厚重的 B 端产品，才能磨炼和体现产品经理的产品能力。

  “一套产品吃遍天下”的传统软件时代，已逝去了。即便要占领多个细分市场，也要谨慎判断，是否通过“一个行业版本”满足全部客户的需求。

  比如，在快消品行业，经销商和生产商的管理模式差异是比较大的。对于经销商来说，组织和权限的管理是相对简单的，也不涉及严格的外部账号管理；而品牌商则有复杂的多组织管理的需求，包括外部组织和账号的管理。

  再比如，经销商的价格体系是相对简单的，不一样的等级的客户可能会出现对应的价目表，部分客户会签订特定的价格协议；但是品牌商的价格体系则复杂很多，不同分公司、不一样的区域、不同商圈等级都会影响具体的价格。这是因为“价盘”是品牌商的生命线，所以精细的控制是有必要的。

  当然，并不是说，我们肯定不能在一个版本满足多个行业的需求。过去 SAP、Oracle 的成功已经证明这一点是能轻松实现的。

  但是，SaaS 引以为傲的正是足够“高可用”的系统。过于臃肿的产品，会大幅度提升客户的使用成本。

  反过来说，“一个版本满足所有需求”当然是不正确的。但是如果盲目地横向扩充版本，也会给 SaaS 公司带来沉重的研发负担。

  比如，当我们面对“非处方药”行业的客户，要不要划分出一个版本呢？虽然并不是快消品行业，但是“非处方药”却在学习快消品行业的分销模式。在这种情况下，如果咱们提供的是分销 SaaS 产品，就暂时没有必要单独为“非处方药”划分一个行业版本出来。

  对于大部分 SaaS，90% 以上的功能是能够在产品层面进行标准化的，但是可能有 10% 的功能是很难标准化的。分清楚哪些功能能“在产品层面进行标准化”，也非常重要。

  比如，中小企业对报表的需求相对简单，因此报表功能是相对容易标准化的；但是对于百亿级企业来说，报表是一个高度复杂且不能妥协的需求，因此对于还没有 BI 或者 PaaS 产品的 SaaS 企业来说，暂时进行定制也是一个可行的选择。

  对于无法“在功能层进行标准化”的功能，我们要想办法在开发层进行标准化，即通常所说的 PaaS，现在流行的叫法是“低代码”。

  低代码是一个很“古老”的事物。我还在 Oracle 公司的时候，就很频繁地使用 Oracle 的低代码能力了——我们又叫 personalization。通过它，我们大家可以改变字段的属性，也 可以嵌入 SQL，甚至 package。

  也就是说，即便是能够灵活二次开发的传统软件，也非常依赖低代码。更加不用说二次开发相对困难的 SaaS 公司了。

  但是，自研 PaaS 平台确实是一个费钱的工作，并不是所有 SaaS 勇于探索商业模式的公司，都能够轻易负担得起的。好消息是，中国 SaaS 正在进入平台时代，钉钉、企业微信逐步增强的低代码能力，有望帮助SaaS公司低成本的拥有“PaaS 自由”。

  和自研系统相比，SaaS 产品的设计更依赖长远规划。这是 SaaS 设计的核心，也是 SaaS 设计的难点。

  由于标准化强调配置能力，因此同样一个功能，所需要的开发量可能是自研系统的数倍。一旦开发了拙劣的功能，就可能对开发资源造成惊人的浪费。

  更重要的是，作为“公用产品”，SaaS一定要保持简洁性：如果系统充斥着一堆鸡肋的功能，且有少数企业坚持在使用，那么会对系统迭代造成阻碍。读者可以思考一下，当规划的新功能与这些鸡肋功能产生冲突，产品经理该怎么样处理？

  因此，好的 SaaS 产品设计就是尽量做“加法”，避免做“减法”和“改法”。

  当然，标准化设计对产品经理本身也是有要求的。我常常比喻，所谓的标准化设计，就像在棋盘上放棋子：棋盘就是产品经理所拥有的架构能力，棋子就是具体的需求。没有棋盘，就不可能正确落子。

  企业的业务可大致分为前中后台业务，前台业务包括商城 APP 等，中台业务包括 CRM、订单管理、物流管理等，后台业务则包括 HR、财务等。

  我们第一步是要明确，第一版 SaaS 产品版本主要是满足哪一块业务需求。划定好了边界，才能匹配公司的战略和资源。

  一家知名快消品厂家找到某 SaaS 公司（简称 A 公司），希望开发一款管理销售人员的移动 APP。经过沟通，SaaS 产品经理小李意识到，客户的需求其实就是分销管理，包括销售订单管理、销售人员管理和门店管理等。

  虽然 A 公司有服务于快消品‘经销商’的分销管理系统，但是一直苦于无法切入利润更丰厚、收入更稳定的快消品‘品牌商’市场，这正是一个非常好的机会。

  所谓经营策略，其实就是企业的打法。比如，在线下分销业务中，用户企业是采用深度分销？还是兼有直销？搞清楚客户的经营策略，才能理清产品研发的思路。

  此外，我们一定要明白，SaaS 是给一个行业的众多客户使用的。因此，我们还需要对企业所在行业的经营策略进行梳理。这样，一方面能够将客户的经营策略匹配到行业的经营策略，便于我们抓住本质，确定保证产品的通用性；另一方面，也可以通盘考虑未来的拓展方向，提前打好架构基础。

  比如，快消品线下分销常见的策略包括大批发制、多级分销、深度分销、直销、车销等，而深度分销又分为厂家覆盖模式和经销商覆盖模式。作为产品经理，有必要全面梳理这些模式，才能在产品设计时胸有成竹。

  小李和客户沟通后，发现该快消品厂家主要是采用了大批发制、直销和深度分销三种经营策略，属于行业比较经典的打法，可以先开发这三种分销模式，同时兼顾到未来向多级分销和车销的拓展。

  大批发是厂家把货卖给批发商，由批发商再进行二次分销。大批发模式虽然是比较粗放的分销方式，但是当厂家管理能力不够时，采用大批发模式能轻松实现快速铺货，因此仍然是常见的一种分销模式。

  快消品行业有 40% 左右的销量，都是通过以大超市为代表的现代通路完成的。这些大超市往往是区域连锁甚至全国连锁，可以树立品牌形象，但是进入门槛高、谈判过程复杂，因此，往往是由快消品厂家直接进行合作。

  深度分销是快消品分销的重要方向。实行深度分销的企业，往往已经具备一定的规模和管理能力。他们将区域进行划分，指定经销商专营，强调终端门店的铺货率、陈列、新品普及率等。

  对于企业来说，深度分销可以最大化挖掘终端门店的潜力，提高新品和高毛利商品的销售量，并有效的阻击竞争对手。因此，这种模式一直是伊利、康师傅、可口可乐等大型快消品企业的重点分销模式。

  根据产品替换公式：新产品价值旧产品价值+替换成本，只有 SaaS 提供了更大的价值，客户才会考虑购买。退一步说，即便没有竞争的传统软件，SaaS 也一定要解决“以前没有办法解决的问题”，才能在激烈的竞争中站稳脚跟。

  因此，梳理清楚业务难点，明白“客户为什么选择我们”，是很重要的工作，可以让我们把资源集中在最关键的功能上。而不是分散资源，做那些客户虽然愿意使用，但是不构成“差异化竞争力”的功能。

  经过和客户沟通，小李了解到，其实客户之前已经耗费上百万实施了某国际知名品牌的 CRM 系统，但是移动端的使用者真实的体验很糟糕。除了使用上不够高可用，需要反复培训才能上手；低下的操作效率和缓慢的响应速度，更是使得系统的推广困难重重。

  客户为什么选择由 A 公司来开发分销系统，就是在体验了 A 公司的移动端产品后，认为产品的使用者真实的体验很优秀，能解决当前系统推广的最大难题。

  了解到客户的诉求后，小李意识到：这个针对快消品厂家的SaaS系统，设计的重心要放在移动端。

  快消品行业都会存在销售人员学历低、管理难的问题，如果通过移动端大幅度的提升员工效率、降低员工使用难度，那么该SaaS产品将对快消品品牌商产生巨大吸引力。

  流程图的重点在于，产品经理要帮助客户梳理清楚业务和需求，避免错乱和遗漏。而做到这一点的关键，是产品经理要有一定的架构能力，即知道典范的流程该怎么样流转。

  如果是针对大客户的 SaaS，那么建议到客户现场呆一段时间。大客户的要求比较细致，现场沟通能大大的提升沟通的效率。

  如果是针对小客户的 SaaS，那么建议你先找到几个种子用户，通过流程图，确保 1.0 版本是他们可以接受的 MVP（最小可行产品）。

  流程图绘制细节是基本功，这里就不再敷述。下面放一张我曾经绘制的流程图供大家参考。

  一开始，该快消品企业觉得自身的需求很简单，主要是业务人员在手机端录入销售订单，再通过接口实时传送到已有的ERP系统即可，如下图：

  小李并没有急于下结论，而是在黑板上画出了典范的分销管理流程，然后按照流程环节逐个进行梳理，如下图：

  经过梳理，小李很快发现，该厂家对于区域连锁卖场等大客户，采取的是厂家业务员拜访、工厂直接发货的直营销售策略；对于非连锁便利店等小客户，采取的是厂家业务员拜访、经销商发货的深度分销策略。因此，客户实际上有两种不同的销售管理流程，如下图：

  流程梳理清楚，设计思路也就清晰了。同时，小李专业的需求梳理方法也得到了客户认可，客户领导当场表达了合作的意向。

  企业业务的开展，是基于多个部门的相互协同和相互监督的。当用户在使用 SaaS 系统时，流程流转、数据安全性都一定要符合企业协同与管控的要求。这就要求我们设计好组织、角色和权限功能。而这里面最有难度的，就是多组织架构设计。

  比如，某饮料公司为扩大销售规模，分别在 A 市和 B 市建立了分公司，各负责一个大区的生产和销售。为便于管理和激励分公司团队，企业决定两个分公司独立核算利润，并根据实现的利润进行分红。

  为支持两个分公司的独立核算，并防止数据泄露，该饮料公司IT团队决定分别给两个分公司建立一个“利润中心组织”。在“利润中心组织”下面建立了相应的“角色”，并分配了相应的“功能”比如销售订单、发货功能等等。最后，将相应的“角色”分别分配给了两个分公司的员工。

  这样，A 公司员工建立的销售订单，所产生的收入和利润数据，均会统计到 A 公司。且销售订单、收入和利润等数据，只能由A公司的员工查看。B 公司亦如此。

  多组织架构实际上体现了企业责权利的划分，决定了组织间协同与风险管控策略。由于企业越大，组织架构就越复杂，管控要求也越高。因此，越是针对大规模的公司的 SaaS，越需要重视多组织架构的设计。

  当然，如果是针对小企业的 SaaS，多组织架构就相对简单了，大家把角色和权限管理设计好即可。

  小李梳理发现，客户下设 2 个独立核算的营业部，每个营业部下面都有若干经销商。 对于直营的 KA 门店，只能由对应营业部管理数据和处理业务； 对于经销商管理的便利店，只能由对应经销商管理数据和处理业务。 同时，经销商所属的营业部，也具有这些便利店有关数据的管理权。

  小李设计了“利润中心”组织类型，并创建了两个利润中心组织：江东营业部和江南营业部。经销商 A、经销商 B、KA 门店 C 都属于客户（具有不一样的客户类型），在客户信息上加上“所属组织”字段，通过该字段，将这 3 个“客户资料”都分配江东营业部。这样，就只有江东营业部的人能看到他们的资料以及业务数据。

  对于便利店 a、b、c、d，则通过类似的方式，关联到对应的经销商，确保经销商之间业务信息的隔离。

  作为 SaaS 设计的主体，产品功能设计又可大致分为应用架构设计和详细功能设计。

  而一旦在不合理的应用架构上搭建起功能模块，并且拥有少数的企业客户后，修改的成本就非常高了。相对来说，自研产品的纠错成本就低得多。毕竟只有一家公司在用，只要和业务部门协商好，推翻重建也不是不可以。

  所谓低耦合，是将功能按照业务相关性，分为多个系统应用。系统应用之间通过 API 进行交互。这样，单个应用的升级，对其他应用的影响就小很多，来提升了系统的敏捷性。比如，销售订单管理、仓库管理和 CRM 就可以独立为多个应用，并且在必要的时候分配给不同的团队负责。

  所谓高复用，即将各个模块所共用的功能抽离出来，单独形成一个系统应用。这样，一方面确保了信息源自的一致性，另一方面简化了系统，避免了重复开发。比如，客户信息在销售订单管理、CRM、TMS（运输管理）等系统应用中都会用到，是有必要独立成一个应用的。

  应用架构设计虽然没有标准答案，但实际上不管是传统的 Oracle ERP 系统，还是新兴的各大电商、SaaS 系统，都有非常成熟的应用架构设计。多研究竞品，再结合真实的情况进行适当的调整是应用架构设计的好方法。

  考虑到 A 公司已有独立的客户信息系统，也有成熟的商品管理系统，小李决定直接复用这些系统。为满足品牌商的需求，小李增加了一些新的功能，比如商圈管理、价格策略管理等。

  其实，复用客户信息管理和商品管理模块，小李还有长期的考虑，即未来品牌商版本和经销商版本可能会打通，形成交易型的 SaaS 产品。如果两个版本共用一套基础数据功能，会有利于将来的数据集成和流程整合。

  从设计流程上来说，SaaS 功能设计也遵循通用 B 端产品设计流程，如下图：

  但是，SaaS 系统面对的是多个企业的具体需求，而这些具体需求看起来总是千差万别的；更困难的在于，产品经理并不能确定未来会面对什么样的企业，也就无法预知所有的需求。

  当客户数量较少，功能也不多的时候，产品的设计缺乏约束，很容易野蛮的生长。

  比如，买赠是消费品行业常用的促销手段。在某些情况下，赠品需要关联到主品，比如买 5 瓶大可乐送 1 瓶小可乐。产品经理为了设计和操作方便，可能选择直接在订单行上新增字段，体现赠品名称和数量。

  这样的设计在面对简单需求的时候，可能不可能会出现问题。但是一旦遇到比较复杂的情况，比如 1）需要管理赠品发货；2）买 5 增 2，买 5 瓶大可乐送 2 种赠品；3）需要和 ERP 系统集成等情况时，就会出现一些明显的异常问题。

  正确的做法是，主品和赠品都放在独立的订单行，拥有相同的字段，并且通过“赠品”字段来标识该订单行是否赠品（打勾即为赠品）。

  因此，作为 SaaS 产品经理，不能够只盯着眼前的需求，而应该放眼长远，尽可能考虑全面。

  另外， SaaS 产品经理必须承认：即便通晓所有需求，我们仍无法确定全部需求的优先级。

  因此，正常的情况下，产品经理只能挑选那些最有价值的需求优先进行满足。而且，每一次的设计都应该是 MVP，从而避免暂时不需要的功能被提前开发。

  但是，SaaS 产品经理离客户往往比较远，不容易深入参与客户的日常经营。

  相对而言，传统软件时代的项目制，需求设计师可以在一个客户现场驻点数月进行需求调研和系统开发；而自研产品的产品经理，则几乎天天和业务方在一起沟通。

  SaaS 公司的开发团队庞大，不可能都派驻到客户现场，因此产品经理往往需要两头兼顾，既要把客户的需求搞透彻，也要做好设计，让研发能够顺利工作。

  在这种情况下， SaaS 产品经理一定要具有“究竟精神”：对客户的每一个需求刨根问底，究其本质。

  SaaS 为什么能够抢占传统软件的市场？最重要的原因并不是 SaaS 更便宜，而是 SaaS 的出生就带有移动化、社交化的属性。

  但是，移动端设计的难度是 PC 端设计的好几倍。原因除了电子设备屏幕更小，同时也是因移动端操作是在户外，场景更复杂，对体验和效率的要求也更高。

  比如，快消品车销业务员为完成一天的拜访任务，拜访一个客户的时间平均不能超过 5 分钟。为了节约时间，业务员需要一边卸货一边拿着手机下订单。因此，“录入销售订单”这个页面必须充足简单和高效。

  比如，在输入商品数量时，就可以直接录入多单位数量（不要选择单位），如“1 箱 / 3 瓶”。并且允许通过加减号来增减数量。

  这样，当业务员搬下车 1 箱 3 瓶酸奶（假设 1 箱酸奶有 9 瓶），他就不需要再计算出“1 箱 3 瓶等于 12 瓶”才能录入系统。这就可以大幅度提高业务员的操作效率。

  要做好 SaaS 交互设计，除了和 UE 同学充分沟通和探讨，更重要的是多研究和学习竞品。

  在进行报表设计时，客户有几张已经使用了 5 年的核心统计报表，客户领导希望新的报表仍然沿用以前的统计逻辑。

  因为客户的部门和人员年年都会调整，而原报表是根据“订单-人员-部门”的对应关系，来计算销售业绩。这就导致进行同期对比时，历史年份和最新年份的业绩基础并不公平。

  比如，去年的 A 部门，有 10 个人员，管辖 a 片区；今年的 A 部门，有 20 个人员，管辖 b 片区。如果简单的把去年 A 部门业绩和今年 A 部门业绩做对比，其实就是有失公允的。

  小李和客户的项目负责人进行了沟通。由于这个客户是快消品行业最顶尖的企业之一，项目负责人也属于比较自信的领导，因此一开始小李的建议并没有正真获得重视。

  但是小李坚持与客户做沟通，指出“在分销模式下，只有便利店和对应的区域是相对来说比较稳定的。因此应该用 A 部门所负责 c 区域的今年业绩，和 c 区域去年业绩做对比，这样才是真正公平的”。

  最终，客户领导被小李说服了，他当着众人的面夸奖了小李。而有了客户领导的配合，项目的推进也非常顺利，最终成功上线。小李也借助这一个项目完成了 SaaS 的从 0 到 1。不久，他又将这个 SaaS 产品销售给了其他的大客户，帮助公司成功完成在大客户市场的突破。