单一的SaaS产品很难支撑起一家独角兽公司，扩展产品线是SaaS公司实现规模化的必然之路。而要实现多条产品线之间的低耦合和高协同，便需要具备很强的产品架构能力。本文作者用一个OMS（销售管理系统）的案例，带我们深入认识SaaS产品架构，一起来看一下吧。
我常说，未来的SaaS产品经理必须具备很强的架构能力。原因主要有三点：
1）SaaS产品需要较强的“容差”能力
能够规模化的SaaS产品必然需要覆盖足够多的企业。而企业 内外部环境的不同，又决定了企业越多，SaaS产品面临的差异化需求就越多。而满足这些差异化需求的能力，就是所谓的“容差”能力。
要做到这一点， SaaS产品就必须在保证高可用、简洁性的前提下，具备很强的可配置性。这就对SaaS产品经理的架构能力提出了很高的要求。
2）SaaS的大趋势必然是大企业
大企业具有更长的生命周期和更强的付费能力，大部分领先SaaS产品一定会开拓大企业市场。
大企业的需求要比小企业复杂得多，而且很难妥协，这就对SaaS产品的架构厚度提出了更高的要求。
3）SaaS必然走向多产品线协同
单一的SaaS产品很难支撑起一家独角兽公司，扩展产品线是SaaS公司实现规模化的必然之路。
而要实现多条产品线之间的低耦合和高协同，SaaS产品经理就必须具备很强的产品架构能力。比如，统一的数据权限如何设计？模块与模块之间如何配合？
如果SaaS产品经理没有深厚的SaaS产品架构能力，就可能在产品线扩展的同时，导致产品过于复杂和臃肿。
那么，如何具象地理解产品架构能力呢？今天，我们就用一个OMS（销售管理系统）的案例，来看一下一个强大的SaaS产品，是如何满足不同企业的差异化需求的。
考虑到篇幅有限，本文无意就一个完整的OMS产品架构进行阐述，而是围绕“销售管理”业务，对销售订单相关模块进行重点阐述，涉及范围如下图：
具体阐述如下：
1）组织架构与权限管理
主要包括OMS产品涉及到的组织架构设计，以及相关角色、员工账号的功能和数据权限设计。
2）商品管理
重点阐述商品的相关属性，具体包括信息类属性、业务控制类属性。
3）价格管理
价格管理可以分解为三个核心要素，分别是：
在产品设计时，需要考虑不同类型客户匹配不同价格。以及不同条件下，不同客户可以享受到不同的折扣。
4）客户管理
具体包括客户分类，也包括以客户分类为基础的“信用管控”。还会涉及在集团架构下，多业务线共用客户信息的问题。
5）销售管理
涉及多种销售履行模式。本文涉及的模式包括：
6）发货管理
不同规模、不同类型的企业在发货模式上可能存在较大差异。
比如，小企业会倾向于最简单的一步式发货：系统先出库，打印出库单，然后根据出库单提货联去仓库提货。而大企业的发货模式则会相对复杂。
除了企业规模，业务类型也会影响发货模式。比如，外贸发货的流程和内贸发货就存在很大差异。
我们首先从一个小规模的批发部说起。
批发部的典型特点，就是在一个较小的区域从事商贸批发工作。他们的年销售额往往介于几百万到几千万之间，利润也颇为微薄。因此在销售管理上，除了尽可能扩大销售额，剩下的重心就放在如何提升业务效率上。
在批发部OMS系统的设计上，要非常注重功能的可用性，以及操作的高效率。具体如下：
批发部往往只有一个销售部门，因此在数据安全性上，并没有太多要求。只需要按照职能分配好功能权限。比如：销售人员分配销售订单和收款功能，仓库管理人员分配发货功能，财务人员分配记账功能，确保他们不会越权操作即可。
因此，权限设计非常简单：将相关功能分配给相应角色即可。比如销售订单功能分配给销售人员角色；再将销售人员角色分配给相关用户即可。示意图如下：
批发部的商品管理，主要用于信息记录和查找。比如，记录商品的规格和图片，以便于销售人员查找和确认。
在设计商品管理时，除了标准的商品属性比如编码、名称、规格等等，还需要考虑不同批发部业务的特殊性。
比如，对于食品类业务，可能需要增加“口味”属性，对于衣服类业务，可能需要增加“尺码”属性等，不一而足。因此，需要设计“自定义属性”字段功能，让客户自行决定应该增加哪些商品属性。如下图所示：
对于大部分批发部来说，往往只有单一价格。而对于其中部分商贸公司，他们可能允许业务人员自行修改价格——只要在公司限制的范围内即可。
价格管理逻辑如下图：
但是对于另一部分商贸公司来说，由于他们的批发业务做得很大，以至于发展了分销层级，就需要按照不同类型的客户分别定价。
比如一级分销商和二级分销商由于采购规模不同，就需要匹配不同的价格。对于此类商贸公司，他们管理往往比较规范，有较为严格的价格规则，不允许业务人员随意调整价格。
价格管理逻辑如图所示：
因此，在设计批发部OMS系统时，既需要支持标准价格，也需要支持分类价格。考虑到不同企业有不同的价格调整策略，因此可以增加一个企业级配置项：是否允许调整销售价格。如图所示：
和商品信息一样，批发部的客户信息也主要用于记录和查找。但是，对于具备一定规模的商贸公司来说，对客户进行分类是很有必要的。
一方面，客户分类本身是重要的客户信息，比如我们可能需要知道中型超市类客户有多少家、便利店类客户有多少家，以便于我们评估市场拓展潜力。
另一方面，我们也需要根据客户分类执行不同的业务策略。比如，不同级别的分销客户，可能适用不同的销售价格（分类价格）。
因此，在设计商贸公司OMS系统时，我们需要设计相对简单的客户信息页面，并且搭配客户分类定义等基础配置页面。
典型的批发部往往从事“低买高卖”业务。而且由于他们的一个重要职能就是帮厂商分担库存和资金压力，因此他们往往会批量购入商品，再零散进行销售。这就是销售管理模式中最典型的一种：按库存销售。
“按库存销售”模式的销售订单设计相对简单，首先要有订单管理页面，然后需要管理销售订单的状态：一旦销售订单确认生效，即自动更新其状态为“待发货”。
对于“待发货”的销售订单，需要将销售订单信息同步到“发货管理”模块，以便行政人员或者仓库人员进行后续的发货操作。
对于小型商贸公司，非常注重效率，对流程的规范性相对不太关注（实际上，公司老板和老板娘可能亲自处理具体业务）。因此，系统的发货操作往往非常简单。
典型的操作流程是：行政人员确认订单可以发货后，直接在OMS系统对货物进行“出库操作”，冲减系统库存现有量，并打印“出库单”。出库单的其中一联，交给提货人员，再到仓库去领取实物。
虽然这种操作方式因为“系统先出库，实物后出库”，会导致事实上的“账实不符”，但是由于业务相对简单，仅涉及很少的环节和人员，因此这种差异往往是可以容忍的。发货流程如图所示：
因此，对于小型商贸公司使用的发货管理，往往只需要根据有效销售订单的“未发货”明细数据，生成发货管理页面的“待发货”数据，方便行政人员进行“出库操作”并生成出库单。如图所示：
细心的朋友可能注意到：“发货操作”是在单独的“发货管理”页面进行操作，而没有直接在“销售订单”页面进行操作。这么设计主要是考虑到系统的延展性。如果直接在“销售订单”页面进行发货操作，可能会面临以下问题：
缺乏架构能力的产品经理，有可能在这个细节犯错，导致后续出现更复杂的业务时，整个逻辑和交互不得不重构。这对于已经熟悉原有逻辑和交互的老客户来说，是不可接受的。
针对批发部的OMS系统整体架构如下：
不同于区域性批发部，规模更大的商贸公司会进行跨区域、多品牌、多模式的经营。比如代理多个省份、多个品牌的分销工作，甚至会拓展“代销业务”：不同于按库存销售，只有当接到客户的正式订单后，才向供应商发起采购。
全国性商贸公司仍然非常强调业务效率，但是由于组织和业务都更为复杂，他们不得不进行更为规范化、也更为精细化的管理。
因此，在OMS系统设计上，除了注重功能的可用性和高效率以外，还需要支持更为复杂的组织和业务管理。具体包括：
全国性商贸公司由于在多个省份同时开展业务，为保持一线操作的灵活性，往往会授予分公司相对独立的权限。
比如，不同分公司可能会授予不同商品的销售权限。再比如，由于各个省份面临的竞争程度有差异，因此他们需要有独立的定价权，以及独立制定促销政策的权力。
更重要的是，各分公司之间的数据应该是严格屏蔽的。一方面是为了避免无谓的误操作，另一方面也是防止一线随意查看整个公司的经营数据，这会无谓的增加业务风险和管理难度。
因此，OMS系统的权限设计需要具备部门的概念：当员工被分配给某个部门以后，他就默认拥有了这个部门的数据权限。
当然，这里还有一些细节的设计，比如：父部门是否应该拥有子部门的数据权限？上级主管是否默认拥有下属的数据权限？一般情况下，答案都应该为“是”。
全国性商贸公司的商品管理，除了最基本的信息记录和查找作用，还必须具备一定业务控制能力和多组织管理能力。
比如，通过在组织层增加“是否可销售”的商品属性，就可以指定某个分公司是否可以销售某商品。这种场景的出现，既可能是由于商贸公司没有在某些省份分销商品的许可，也可能是由于物流、服务等因素，暂时不便于在某些地区销售。
因此，全国性商贸公司OMS系统的商品管理，需要具备更强的管控能力。如图所示：
对于全国性商贸公司来说，由于供货能力更强，开始有能力服务于大型连锁超市。
和便利店以及单体超市相比，连锁超市拥有更强的出货能力，但相应的也对商贸公司提出了更高的要求。比较典型的一点要求就是独家销售协议，而其中核心条款之一就是独家销售价格。
因此，对于全国性商贸公司OMS系统，可能需要设计销售协议管理功能，至少也要有协议价格功能，即针对单一客户的定价。
除了价格，由于商贸公司可能放权给各分公司制定促销政策，因此，还需要支持各分公司自行制定促销方案。而且，这些促销方案也需要遵循统一的数据权限，即各分公司之间严格屏蔽。
OMS价格与促销管理功能如图所示：
全国性商贸公司面对采购量更大、付款条件更为苛刻的客户，除了基本的客户信息管理、客户分类功能外，还需要更为强大的客户管理功能。
比较典型的就是信用管理：即商贸公司根据客户的实力和信用记录，给予一定的赊销额度。只要客户的本次订单金额或发货金额没有超过“可用的赊销额度”，就可以正常提货。
信用管理的逻辑比较简单：
可用的赊销额度=预分配的赊销额度+预收账款-应付账款-外部风险
其中，“预收账款”主要包括客户支付的预收款，在某些情况下，也可能包括客户的承兑汇票（类似于商业白条）。“应付账款”除了之前的欠款，也可能包括一定期间内的待发货订单，以及已发货未结算订单。
“外部风险”相对复杂，主要是一些外部事件可能导致的客户信用受损。比如客户将预付款单据抵押给了银行，那么可能就需要适当冲减客户的部分“可用赊销额度”。
全国性商贸公司可能仍然以“按库存销售”为主，但是会开始尝试“以销定采”类业务。具体又可以分为两种模式：
所谓采购发运，是指在收到客户的正式订单以后，商贸公司根据客户订单生成采购订单，并下达给供应商。供应商根据采购订单备货，发货给商贸公司，商贸公司再发货给客户。
为什么会有采购发运的业务呢？主要是这一类商品销售量不稳定，如果提前购入，会占用商贸公司宝贵的资金和库存。商贸公司收到货以后，往往会连同客户需要的其他商品，一并打包后发给客户。
采购发运流程如图所示：
一件代发和采购发运流程比较相似，但是供应商在收到商贸公司的订单后，会直接发货给商贸公司的客户。和采购发运相比，一件代发无疑减少了发货环节，不过，这往往也反映出，商贸公司只是一个纯粹的“代销角色”，供应商实际上可以直接和客户发生交易。
在微商体系中，“一件代发”业务比较常见，毕竟微商的核心竞争力是销售渠道，他们只需要专注于获取客户订单即可。
一件代发流程如图所示：
和批发部相比，虽然全国性商贸公司仍然非常注重效率，但是业务范围的拓展也让发货流程变得更加复杂。比如，商贸公司可能与物流公司展开合作，由物流公司将货物运送给客户。典型的发货流程如下：
针对全国性商贸公司的OMS系统整体架构如下：
商贸公司如果能进一步向供应链延伸，建立自己的生产制造体系，那么此时它将来到一个全新的阶段：集团化经营。
当然，实事求是的说，商贸公司向上整合的案例并不多见，更多的是制造型企业向下延伸销售渠道。不管哪一种情况，由于内部供应链的存在，企业管理将会面临新的挑战，OMS系统的架构也必须能够支撑更加精细和全面的业务管理。具体包括：
与全国性商贸公司相比，集团型公司更为复杂的管理需求来自集团管控与协作。
比如，张总作为集团副总，他在管理集团行政工作的同时，兼任了软件分公司的负责人。如果OMS系统只有商贸公司版“按组织屏蔽数据”的能力，那么就会面临一个两难：到底要不要给张总开放销售和财务功能呢？
如果开放，张总就可以管理软件分公司的相关业务，但是他也因此能看到整个集团的销售和财务数据（因为他属于集团组织，又拥有销售和财务功能权限），这显然是不可以接受的。
这种“在不同组织担任不同职位”的场景出现，就使得集团型OMS系统在数据权限方面需要具备更精细的管理能力。即可以把不同类型的数据权限分开，从而实现只分配给某个角色“一个组织部分数据权限”的能力。如图所示：
在商品管理层面，除了信息属性和一般的业务控制属性，OMS系统还必须具备更精细化的业务控制属性。
比如，某酸奶商品在某销售公司组织至少应该具有两种业务属性：可销售与可采购。前者允许该销售公司在系统内销售该商品，后者允许该销售公司在系统内向集团制造企业或外部供应商采购该商品。但是，在制造公司组织，该商品就不应该具有“可采购”的属性，而应该具有“可生产”的属性，以允许制造企业在系统内为该商品建立生产工单。
类似的精细化管理场景还包括：天津分公司和重庆分公司都会向北京制造厂进行采购，但是由于物理距离的巨大差异，两者的采购时长是明显不同的。为了更加合理的规划采购计划，避免库存缺失和积压，需要为该商品在“天津分公司”和“重庆分公司”这两个组织维护不同的“采购提前期”数据。
在价格管理方面，集团型公司开始发挥集团优势。比如，由集团本部和全国大型连锁签署价格协议，从而一次性锁定巨额销售收入。
由于在全国性商贸OMS系统中，价格数据实际上是分组织进行管理的——A分公司的价格只能用于A公司的客户，B公司的价格只能用于B公司的客户——因此，在集团型OMS系统中，需要跳出这个限制，实现“全局价格协议”功能。
只要某客户与集团签订过了全局价格协议，那么在任何分公司，只要是针对该客户的销售订单，都会统一引用该价格协议。
实际上，类似的场景也出现在采购管理系统。
比如某快递公司为了控制墨水笔成本，由集团与墨水笔厂商统一签订价格协议，墨水笔厂商则直接把货发给各地分公司。凭借着集中采购的数量优势，不但提高了墨水笔的质量，也因此降低了采购价格。由于此类场景不属于OMS系统，本文就不再详细阐述。
集团型公司往往还有一个特点，那就是拥有多条业务线。比如，某房地产公司既有新楼盘销售业务，也有老楼盘物业服务。
多业务线会带来一个“烦恼”，那就是各业务线可能会重复建立客户档案，以至于在集团层面，无法清晰的描绘客户画像，也无法准确的统计客户数量。
那么，集团型OMS系统如何解决这个问题呢？
解决方案之一，是在“客户层”和“地址层”之间，加一个“账户层”。
当某一个分公司新建客户时，系统通过数据校验，可以提醒分公司操作人员“已经存在该客户信息”。这样，操作人员就只需要在该客户信息下方，添加一个“账户层”信息，而不用再添加一个重复的客户。同时，“账户层”信息是根据分公司权限隔离的，这样既保证了不会重复建立客户信息档案，也保证了分公司之间的客户数据严格屏蔽。
架构如图所示：
值得一提的是，这种“合理分层”的能力，是B端产品架构能力的重要体现。
比如，有经验的HR产品经理，就会把人员信息分为“人员层”和“分配层”两个层次。人员基本信息比如员工号、年龄等在“人员层”统一管理，但是职位信息则在“分配层”进行管理。
这样，一方面可以处理“一个员工多个岗位”的需求，另一方面也可以实现更精细化的数据权限：这位员工的多位上级，只能看到自己所管理的那个“分配”（即职位）的相关信息。
如果集团型企业进行了“垂直一体化”：既包含销售型公司，又包含生产型公司。这就带来了一个新的管理需求：内部交易。
你可能会认为：既然是一家公司，何必采用“交易”这么复杂的业务形式？简单做一个库存调拨不就好了吗？
关键在于，集团型公司为了严格区分各分公司的责权利，从而适当的考核和激励各分公司管理层，这些分公司往往都是独立核算的——因此即便是集团内部公司的采购，仍然要“亲兄弟、明算账”。
和“正常”的采购、交易业务不同，由于内部交易流程的双方使用的是同一套系统，因此采购和销售流程，以及财务核算流程，都可以更顺畅的进行协作。
比如，当作为采购方的分公司发起内部申请后，作为销售方的分公司就会自动生成对应的内部销售订单；而当内部销售订单发货以后，内部采购申请就会自动进入“可接收”状态。相关的财务数据和单据，也都可以自动化的生成。
流程如图所示：
Oracle系统内部交易流程示例
对于集团型企业来说，已经可以接受更为复杂的订单。
客户可能定制一批商品，并且要求按特定的时间点分批发货。这就对集团型公司的供应链能力提出了更高的要求。
比如，某位海外客户定制了300辆特种车，并要求分别于1月1号、1月11号和1月21号各交付100辆。交货方式是FOB，即企业只需要把货物在指定的装运港装船，并完成相关单据交付，即可视为交货。
对于负责发货的销售公司来说，往往需要安排专人跟踪订单，以完成整个复杂的发货流程。流程（示例）如下：
至此，一次发货操作完成。
针对集团型公司的OMS系统整体架构如下（仅列示差异化部分）：
回顾本文，什么是好的产品架构？其中一个最核心的标准，就是能够满足不同企业在不同发展阶段的个性化需求。
实际上，如果不做标准化产品，就并不需要太强的产品架构能力。因为只需要模仿客户的现有流程，进行简单的线上化就好了。但是由此带来的问题就是：投入巨大成本研发的系统，仅仅只是一个“一次性用品”。
纷享销客PaaS平台总负责人健鹏曾经做客SaaS星球直播分享，他说道：SaaS公司很容易受到大项目的诱惑。这些大项目不但金额高，还有示范效应。但是SaaS公司必须认识到：这样的项目需要占用大量的研发资源，而且由于无法复用，最后很可能还要面临亏损。
另一个中国细分赛道头部SaaS公司的客户成功副总裁也给我说过：一个千万级的大项目，最后一核算，发现研发和交付成本超过三千万。所以做定制化项目，真的要考虑清楚。
就以本文的发货流程为例，批发部、全国性商贸公司和集团型公司的发货流程存在较大差异，但在实际场景中，一个公司可能同时出现其中2种，甚至3种发货流程。或者在早期是比较简单的发货流程，到后期发展为比较复杂的发货流程。
因此，好的SaaS产品，一定会兼顾系统的简洁性和灵活性，即通过标准化功能加上一定的配置项，满足各种差异化的发货管理需求——不仅仅是满足更多企业的需求，也是能够和客户一起成长，不至于当客户发展壮大、业务变得更复杂以后，我们反而面临被抛弃的命运。
实际上，很多单纯强调轻薄、易用的SaaS应用——比如部分无代码SaaS——就会面临这种窘境。
那么，如何突破这种窘境？
一方面我们要深入业务应用，把产品做厚，形成粘性和护城河；更重要的是，我们要一开始就注重产品架构，这样才能越走越轻松，跟上客户的成长步伐。
而如何提升产品经理的产品架构能力？我很认同纷享销客PaaS平台总负责人健鹏的观点，那就是要多研究国外顶级B端产品，比如：SAP、Oracle、Salesforce。少研究国内BAT偏C端的产品，因为他们过于轻薄。
专栏作家#
王戴明，微信公众号：To B老人家，人人都是产品经理专栏作家，多年互联网产品与信息化管理经验。
本文原创发布于人人都是产品经理，未经许可，禁止转载。
题图来自 Unsplash，基于 CC0 协议。
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。