单一的SaaS产品很难支撑起一家独角兽公司

我常说，未来的SaaS产品经理一定要有很强的架构能力。 主要原因有以下三个：

1）SaaS产品需要强大的“承受”能力

能够规模化的SaaS产品必须覆盖足够多的企业。 企业内外部环境的差异决定了企业越多，SaaS产品面临的差异化需求就越多。 满足这些差异化需求的能力就是所谓的“宽容”能力。

为了实现这一目标，SaaS 产品必须具有高度可配置性，同时确保高可用性和简单性。 这对SaaS产品经理的架构能力提出了很高的要求。

2）SaaS大​​势必是大企业

大企业生命周期更长，支付能力更强，最领先的SaaS产品必将打开大企业市场。

大型企业的需求比小型企业复杂得多，很难妥协，这对SaaS产品的架构厚度提出了更高的要求。

3）SaaS必然走向多产品线协同

单一的SaaS产品很难支撑一家独角兽公司。 拓展产品线是SaaS公司实现规模化的必然途径。

要实现多产品线之间的低耦合、高协作，SaaS产品经理必须具备强大的产品架构能力。 比如，如何设计统一的数据权限？ 模块之间如何协作？

如果SaaS产品经理不具备深厚的SaaS产品架构能力，随着产品线的扩展，产品可能会变得过于复杂和臃肿。

那么，如何具体理解产品架构能力呢？ 今天我们就通过一个OMS（销售管理系统）案例，来看看强大的SaaS产品如何满足不同企业的差异化需求。

01 OMS产品核心架构

考虑到篇幅，本文不打算详细阐述完整的OMS产品架构。 而是以“销售管理”业务为主，以销售订单相关模块为主。 承保范围如下：

详情如下所示：

1）组织架构及权限管理

主要包括OMS产品涉及的组织架构的设计，以及相关角色、员工账户功能和数据权限的设计。

2）产品管理

重点阐述产品的相关属性，包括信息属性和业务控制属性。

3）价格管理

价格管理可分为三个核心要素，即：

为谁（which）定价：一般来说，定价是根据特定产品来定价的，但有些公司是根据产品类别来定价的。 例如，归类为“A型圆珠笔”的产品就有统一的价格。 谁可以享受这个价格（谁）：所有顾客都享受同样的价格吗？ 还是不同的顾客享受不同的价格？ 价格如何调整（如何）：折扣和促销如何处理？ 运费等额外费用如何处理？

在设计产品时，需要考虑针对不同类型的客户匹配不同的价格。 并且在不同的条件下，不同的顾客可以享受不同的折扣。

4）客户管理

具体来说，包括客户分类，还包括基于客户分类的“信用管控”。 它还会涉及到集团架构下多个业务线之间共享客户信息的问题。

5）销售管理

涉及多种销售履行模式。 本文涵盖的模式包括：

6）发货管理

不同规模、不同类型的企业，交付模式可能存在较大差异。

例如，小企业会更喜欢最简单的一步发货方式：系统先发货，打印出货单，然后根据仓库的提货链接去仓库提货。货物订单。 大型企业的交付模式会相对复杂。

除了业务规模外，业务类型也会影响运输模式。 例如，外贸发货的流程与内贸发货的流程有很大不同。

02 批发部OMS产品结构

让我们从一个小型批发部门开始。

批发部的典型特点是在较小的区域内从事商业批发工作。 他们的年销售额往往在几百万到几千万之间，利润却相当微薄。 因此，在销售管理中，除了尽可能扩大销售量外，剩下的重点就是如何提高经营效率。

在批发部OMS系统的设计中，应高度重视功能可用性和高运营效率。 详情如下：

1、组织架构及权限管理

批发部门往往只有一个销售部门，因此在数据安全方面没有太多要求。 只需根据功能分配功能权限即可。 例如：销售人员分配销售订单和收款职能，仓库管理员分配发货职能，财务人员分配会计职能，只要保证他们不会越权操作即可。

因此，权限设计非常简单：将相关功能分配给相应的角色即可。 例如，销售订单功能分配给销售员角色； 然后将销售人员角色分配给相关用户。 示意图如下：

2、产品管理

批发部的商品管理主要用于信息记录和查询。 例如记录产品规格和图片，方便销售人员查找和确认。

在设计产品管理时，除了代码、名称、规格等标准的产品属性外，还需要考虑不同批发部门业务的特殊性。

例如，对于食品业务，您可能需要添加“口味”属性，对于服装业务，您可能需要添加“尺码”属性，等等。 因此，有必要设计“自定义属性”字段功能，让客户决定应该添加哪些产品属性。 如下所示：

3、价格管理

对于大多数批发部门来说，通常只有一种价格。 对于其中一些贸易公司来说，他们可能会允许业务人员自行修改价格——只要在公司的限制范围内。

价格管理逻辑如下：

但对于其他贸易公司来说，由于其批发业务规模较大，已经形成了分销层次，因此需要根据不同类型的客户来制定价格。

例如，一级经销商和二级经销商因采购规模不同，需要匹配不同的价格。 对于此类贸易公司来说，其管理往往比较规范，价格规则也比较严格，不允许业务人员随意调整价格。

价格管理逻辑如图：

因此，批发部门OMS系统设计时，需要同时支持标准价格和分类价格。 考虑到不同企业的调价策略不同，可以添加一个企业级配置项：是否允许销售调价。 如图所示：

4. 客户管理

与产品信息一样，批发部门的客户信息主要用于记录和查找。 但对于具有一定规模的贸易公司来说，有必要对客户进行分类。

一方面，客户分类本身就是重要的客户信息。 例如，我们可能需要知道有多少中型超市客户，有多少便利店客户，以便我们评估市场拓展潜力。

另一方面，我们还需要根据客户分类实施不同的业务策略。 例如，不同的销售价格（分类价格）可能适用于不同级别的分销客户。

因此，在设计贸易公司的OMS系统时，我们需要设计一个相对简单的客户信息页面，并与客户分类定义等基础配置页面相匹配。

5. 销售管理

典型的批发部门经常从事“低买高卖”的业务。 而且由于它们的重要功能之一是帮助制造商分担库存和资金压力，因此它们往往会批量进货，然后分批出售。 这就是最典型的销售管理模式：按库存销售。

“按库存销售”模式的销售订单设计比较简单。 首先有一个订单管理页面，然后需要管理销售订单的状态：一旦销售订单被确认有效，其状态会自动更新为“待发货”。

对于“待发货”的销售订单，需要将销售订单信息同步到“发货管理”模块，以便行政人员或仓库人员进行后续的发货操作。

6. 发货管理

对于小型贸易公司来说，他们非常注重效率，相对不太注重流程的标准化（事实上，公司老板和老板娘可能会亲自处理具体业务）。 因此，系统的运输操作往往非常简单。

典型的操作流程是：行政人员确认订单可以发货后，直接对OMS系统中的货物进行“出库操作”，抵消系统中现有的库存，并打印“出库单”。 将一份出库单副本交给送货人员，然后送货人员前往仓库提取实物货物。

虽然这种操作方式会因为“系统先出库，实物后出”而导致“账实不符”，但由于业务比较简单，只涉及很少的环节和人员，但这种差异是经常可以忍受。 交付流程如图所示：

因此，对于小型贸易公司使用的发货管理，往往只需根据有效销售订单的“未发货”明细数据，在发货管理页面生成“待发货”数据，以方便管理人员执行“出库作业”并生成出库单。 如图所示：

细心的朋友可能会注意到，“发货操作”是在单独的“发货管理”页面上进行的，而不是直接在“销售订单”页面上进行的。 这样的设计主要是考虑到系统的可扩展性。 如果您直接在“销售订单”页面进行发货操作，您可能会遇到以下问题：

缺乏架构能力的产品经理可能会在这个细节上犯错误，导致后续出现更复杂的业务时必须重构整个逻辑和交互。 这对于已经熟悉原有逻辑和交互的老客户来说是难以接受的。

批发部门OMS系统整体架构如下：

03 全国贸易公司OMS产品架构

与区域性批发部门不同，较大的贸易公司会进行跨区域、多品牌、多模式的经营。 例如，可以代理多个省份、多个品牌的经销，甚至可以拓展“寄售业务”：与库存销售不同，只有收到客户的正式订单后才会向供应商采购。

国贸企业仍然十分注重业务效率，但由于组织机构和业务更加复杂，必须进行更加规范化、精细化的管理。

因此，在OMS系统设计中，除了注重功能可用性和高效率外，还需要支持更复杂的组织和业务管理。 具体包括：

1、组织架构及权限管理

由于全国性贸易公司同时在多个省份开展业务，为了保持一线经营的灵活性，往往赋予分支机构相对独立的权限。

例如，不同的分支机构可以授予不同产品的销售权限。 又比如，由于各省面临的竞争程度不同，需要有独立的定价权和独立制定促销政策的权力。

更重要的是，分支机构之间的数据要严格屏蔽。 这样做一方面是为了避免不必要的误操作，另一方面也是为了防止一线随意查看整个公司的运营数据，不必要地增加业务风险和管理难度。

因此，OMS系统的权限设计需要部门的概念：当员工被分配到某个部门时，他就默认拥有该部门的数据权限。

当然，这里还有一些细节设计，比如：上级部门是否应该有子部门的数据权限？ 上级主管默认有下级数据权限吗？ 一般来说，答案应该是“是”。

2、产品管理

全国贸易公司的商品管理除了最基本的信息记录和查询功能外，还必须具备一定的业务控制能力和多组织管理能力。

例如，通过在组织层面添加产品属性“是否可以销售”，可以指定某个分店是否可以销售某种产品​​。 出现这种情况可能是因为贸易公司没有在某些省份分销商品的权限，也可能是由于物流、服务等因素暂时不方便在某些地区销售。

因此，全国贸易公司OMS系统的商品管理需要更强的管控能力。 如图所示：

3、价格管理

对于国贸公司来说，由于供应能力较强，开始能够服务于大型连锁超市。

与便利店和独立超市相比，连锁超市的发货能力更强，但对贸易公司也提出了更高的要求。 比较典型的要求之一就是独家销售协议，核心条款之一就是独家销售价格。

因此，对于全国贸易公司的OMS系统来说，可能需要设计一个销售协议管理功能，并且至少需要设计一个协议价格功能，即针对单个客户的定价。

除了价格之外，由于贸易公司可能会将制定促销政策的权力下放给各分店，因此还需要支持各分店制定自己的促销计划。 而且，这些促销方案还需要遵守统一的数据权限，即分支机构之间的严格屏蔽。

OMS价格和促销管理功能如图：

4. 客户管理

全国性贸易公司面临着采购量更大、付款条件更苛刻的客户。 除了基本的客户信息管理和客户分类功能外，还需要更强大的客户管理功能。

比较典型的是信用管理：即贸易公司根据客户的实力和信用记录给予一定的信用额度。 只要客户的订单金额或发货金额不超过“可用信用额度”，就可以正常提货。

信用管理的逻辑比较简单：

可用授信额度=预分配授信额度+预收账款-应付账款-外部风险

其中，“预收账款”主要包括客户支付的预付款，在某些情况下，还可能包括客户的承兑汇票（类似于商业借条）。 除了以往的欠款之外，“应付账款”还可能包括一定期限内待发货的订单，以及已发货但未结算的订单。

“外部风险”相对复杂，主要是指某些外部事件可能对客户信用造成的损害。 例如，如果客户将预付款文件抵押给银行，则可能需要适当抵消客户的部分“可用信用额度”。

5. 销售管理

国贸公司可能仍以“以库存销售”为主，但将开始尝试“以销定制采购”类型的业务。 具体来说，可以分为两种模式：

购买并运送一件货物

所谓采购发货是指贸易公司收到客户的正式订单后，根据客户的订单生成采购订单并发送给供应商。 供应商根据采购订单准备货物并将其运送给贸易公司，然后贸易公司将其运送给客户。

为什么会有采购和运输业务？ 主要原因是该类商品销量不稳定。 如果提前采购，会占用贸易公司宝贵的资金和库存。 贸易公司收到货物后，往往会与客户需要的其他货物一起包装并发送给客户。

采购及发货流程如图所示：

一件代发的流程与采购和发货类似，但供应商收到贸易公司的订单后，会直接发货给贸易公司的客户。 与代购和运输相比，无疑减少了运输环节。 不过，这往往也反映出，贸易公司只是纯粹的“寄售角色”，供应商实际上可以直接与客户进行交易。

在微商体系中，“一件代发”业务比较常见。 毕竟，微商的核心竞争力是销售渠道，他们只需要专注于获取客户订单即可。

一件代发流程如图：

6. 发货管理

与批发部门相比，虽然全国贸易公司仍然非常重视效率，但业务范围的扩大也让交货流程变得更加复杂。 例如，贸易公司可能与物流公司合作，物流公司将货物运送给客户。 典型的运输流程如下：

全国贸易公司OMS系统整体架构如下：

04 集团公司OMS产品架构

如果贸易公司能够进一步向供应链延伸，建立自己的生产制造体系，那么就会进入一个新的阶段：集团化经营。

当然，说实话，贸易公司向上整合的案例并不多，制造企业向下延伸销售渠道的案例较多。 无论哪种情况，由于内部供应链的存在，企业管理都将面临新的挑战，OMS系统的架构也必须能够支持更加精细化、全面的业务管理。 具体包括：

1、组织架构及权限管理

与全国性贸易公司相比，集团公司从集团管控和协作方面有更复杂的管理需求。

例如，张先生作为集团副总裁，不仅管理集团行政工作，还兼任软件分公司负责人。 如果OMS系统在贸易公司版本中只具备“按组织屏蔽数据”的能力，那么它就会面临一个困境：我们是否应该向张先生开放销售和财务功能？

如果打开的话，张先生可以管理软件分公司的相关业务，同时他也可以看到整个集团的销售和财务数据（因为他属于集团组织，有销售和财务职能权限） ），这显然是不允许的。 公认。

“在不同组织担任不同职务”这种场景的出现，要求集团型OMS系统在数据权限方面具备更加精细化的管理能力。 即可以分离不同类型的数据权限，从而实现只将“组织的部分数据权限”分配给某个角色的能力。 如图所示：

2、产品管理

在商品管理层面，OMS系统除了信息属性和通用的业务控制属性外，还必须具备更加精细化的业务控制属性。

例如，销售公司组织中的酸奶产品应至少具有两个业务属性：可销售和可购买。 前者允许销售公司在系统内销售产品，后者允许销售公司从系统内的集团制造企业或外部供应商采购产品。 然而，在制造公司组织中，产品不应该具有“可采购”的属性，而应该具有“可生产”的属性，以允许制造公司在系统中为该产品创建生产工单。

类似的精细化管理场景还有：天津分公司和重庆分公司都会从北京制造工厂采购，但由于物理距离的巨大差异，两者的采购时间明显不同。 为了更合理地规划采购计划，避免库存短缺和积压，需要在“天津分公司”和“重庆分公司”两个组织中维护该产品不同的“采购提前期”数据。

3、价格管理

在价格管理方面，集团公司已开始充分发挥集团优势。 比如集团总部与全国大型连锁企业签订价格协议，一次性锁定巨额销售收入。

由于在全国商业OMS系统中，价格数据实际上是由机构管理的——A分公司的价格只能供A公司的客户使用，B公司的价格只能供B公司的客户使用——因此，在集团型OMS系统，需要跳出这个限制，实现“全球价格协议”功能。

只要客户与集团签订了全球价格协议，只要是该客户的销售订单，该价格协议将在任何分支机构统一报价。

事实上，类似的场景也出现在采购管理系统中。

例如，某快递公司为了控制墨水笔成本，与墨水笔厂家签订统一价格协议，由墨水笔厂家直接将货物发往各地分支机构。 依托集中采购的数量优势，不仅提高了墨水笔的质量，还降低了采购价格。 由于此类场景不属于OMS系统，本文不做详细阐述。

4. 客户管理

集团公司往往还有一个特点，那就是拥有多条业务线。 例如，某房地产公司既有新房销售业务，也有旧房物业服务业务。

多个业务线会带来一个“麻烦”，即每个业务线可能会重复创建客户档案，这样在集团层面就无法清晰描绘客户画像，无法准确统计客户数量。

那么，集团OMS系统是如何解决这个问题的呢？

一种解决方案是在“客户层”和“地址层”之间添加“账户层”。

当分行创建新客户时，系统可以通过数据验证提醒分行操作员“该客户信息已存在”。 这样，运营商只需在客户信息下方添加一条“账户层”信息即可，无需添加重复的客户。 同时，按照分支机构的权限隔离“账户级别”信息。 这不仅保证了客户信息档案不会被重复创建，也保证了分支机构之间的客户数据得到严格屏蔽。

架构如图所示：

值得一提的是，这种“合理分层”能力是B端产品架构能力的重要体现。

例如，经验丰富的HR产品经理会将人事信息分为两个层次：“人事层”和“分配层”。 员工人数、年龄等人事基本信息在“人事层级”统一管理，但职位信息在“职务层级”管理。

这样，一方面可以处理“一人多职”的需求，另一方面可以实现更精细的数据权限：员工的多个上级只能看到自己管理的“任务” （即职位）相关信息。

5. 销售管理

如果集团企业进行“纵向一体化”：既包括销售公司，也包括生产公司。 这就带来了新的管理需求：内部交易。

你可能会想：既然是公司，为什么要采用“交易”这么复杂的业务形式呢？ 简单地进行库存转移不是很好吗？

关键是，为了严格区分各分公司的责任和权利，从而正确考核和激励各分公司的管理层，这些分公司往往是独立核算的——所以即使是集团内公司的采购仍然要求“兄弟们，咱们算清楚吧”。

与“正常”的采购和贸易操作不同，由于内部交易流程双方使用相同的系统，因此采购和销售流程以及财务会计流程可以更加顺畅地协作。

例如，当采购方分支机构发起内部申请时，卖方分支机构会自动生成对应的内部销售订单； 当内部销售订单发货时，内部采购申请会自动进入“可接受”状态。 相关财务数据和文件也可以自动生成。

流程如图：

系统内交易流程示例

6. 发货管理

对于集团企业来说，他们已经可以接受更复杂的订单。

客户可以订购一批货物，并要求在特定时间分批发货。 这对集团公司的供应链能力提出了更高的要求。

例如，海外客户定制了300辆专用车，要求分别在1月1日、1月11日、1月21日交付100辆。 交货方式为FOB，即企业只需在指定的起运港装货并完成相关单证的交付，即可视为交货。

对于负责发货的销售公司来说，往往需要安排专人跟踪订单，完成整个复杂的发货流程。 流程（示例）如下：

至此，一次运输操作就完成了。

集团公司OMS系统整体架构如下（仅列出差异化部分）：

05 总结

回头看这篇文章，什么是好的产品架构？ 核心标准之一就是能够满足不同企业不同发展阶段的个性化需求。

其实，如果不做标准化产品，就不需要很强的产品架构能力。 因为你只需要模仿客户现有的流程，简单地做成线上就可以了。 但由此带来的问题是，投入巨大成本研发的系统只是“一次性产品”。

芬芳下客PaaS平台总经理建鹏曾客串SaaS星球直播。 他说：SaaS公司很容易受到大项目的诱惑。 这些大项目不仅资金量高，而且具有示范效应。 但SaaS公司必须认识到，此类项目需要大量的研发资源，而且由于无法复用，最终很可能面临损失。

在中国细分市场中，另一家领先的SaaS公司客户成功副总裁也告诉我：对于价值数千万的大型项目，最终的计算表明，研发和交付成本超过3000万。 因此，在进行定制项目时，您确实需要仔细考虑。

以本文的送货过程为例。 批发部门，国家贸易公司和集团公司的交付过程之间存在很大差异。 但是，在实际情况下，公司可能同时拥有2个甚至3个。 过程。 或者这可能是早期阶段相对简单的交付过程，但在后期发展为更复杂的交付过程。

因此，优秀的SaaS产品必须考虑系统的简单性和灵活性，即通过标准化功能以及某些配置项目，它可以满足各种差异化的交付管理需求 - 不仅满足更多企业的需求，我们也可以满足我们的需求可以与我们的客户一起成长，这样当我们的客户增长且业务变得更加复杂时，我们将不会面对被抛弃的命运。

实际上，许多简单地强调稀薄和易用性的SaaS应用（例如一些无代码SaaS）都会面临这一困境。

那么，如何突破这个难题？

一方面，我们需要深入研究业务应用程序，并使我们的产品更浓密以形成粘性和护城河。 更重要的是，我们需要从一开始就专注于产品体系结构，以便我们可以更轻松地前进并跟上客户的成长。

以及如何提高产品经理的产品架构功能？ 我非常同意 PaaS平台总经理Jian Peng的观点，即我们应该研究更多外国顶级B-End产品，例如：SAP，。 不要研究国内蝙蝠的C-End产品，因为它们太薄又轻。

专栏作家＃