SaaS从0到1，案例实操讲解

SaaS从0到1系列，全景图

在上一篇《SaaS从0到1，案例实操系列（一）》中，我们讲到SaaS产品经理小张接到客户的需求，经过分析，他意识到这是公司实现“第二次增长”的好机会。于是他赶紧让销售负责人和客户约定了拜访时间。

01 需求梳理-策略层

小张知道，第一次拜访客户，最要紧的并不是搞清楚所有需求细节。而是明确客户需求的范围，以及客户的业务策略，从而确认产品研发的范围，以及 “标准化交付”的难度。

在需求筛选阶段，小张已经明确了快消品行业的主要分销模式（业务策略），并判断公司有能力通过标准化产品进行满足。因此，小张的策略是将客户的分销模式与行业分销模式进行匹配，从而将调研重心放在客户的个性化需求上。

客户的一位渠道经理接待了小张。他认为自己的需求很简单：业务人员在手机端录入销售订单，再传送到ERP系统安排发货即可。因此，小张公司只需要提供一个手机录入端口，再打通客户已有的ERP系统。如下图：

客户的需求

一直以来，小张的需求调研原则都是：永远要相信客户“存在一个需求”，但是永远不要相信客户“搞清楚了自己的需求”。

于是，他在黑板上画出了分销管理概要流程，然后按照流程环节逐个与客户进行梳理，如下图：

概要流程

梳理的主线，是销售订单流程：从拜访客户到订单交付。

通过主线流程，再牵引出支线流程。

比如：要管理“业务员拜访门店”，就必须进行门店（客户）管理和业务员管理；要支持“录入订单”，就必须管理“商品”和“价格”。

小张之所以先画“概要流程”，是因为调研的第一要务，是首先确保不遗漏重要流程和板块。

小张很快发现，该厂家对于区域连锁卖场等大客户，采取的是厂家业务员拜访、工厂直接发货的KA直销模式：

对于非连锁便利店等小客户，采取的是厂家业务员拜访、经销商发货的深度分销模式：

因此，客户实际上有两种不同的销售流程，如下图：

而且，客户是希望把两种销售流程都管理起来。因此，要满足客户需求，远非“支持录入订单并传送ERP”就可以的，而是必须对商品、门店、经销商、价目表等基础数据，以及库存现有量、发货、收货、收款与对账等业务流程和数据进行全面管理。

另外，在“深度分销”场景下，由于发货和收款都由经销商负责，并不需要对接厂商ERP，而且收款与对账流程也和“KA直销”场景不同。因此，两个场景需要分别设计产品功能。

明确了业务范围、业务策略和主要流程，小张更有信心了。经过第一次会面，客户也对小张的专业能力很认可，并当场表达了尽快合作的意愿。

02 需求梳理-业务层

上一次与客户见面为商务谈判打下了很好的基础。不久，小张就收到了区域销售负责人的好消息：已经和客户签订了合同，可以进场调研了。

在传统软件时代，研发团队都是驻扎在客户现场，用户还可能脱产专职投入项目，这就使得需求调研的难度大大降低。

但小张公司并非项目制公司，研发团队都在总部办公，因此小张需要在客户现场把问题都搞清楚，然后再回来转达给研发团队。这就对小张提出了更高的要求。

为了提高调研效率，小张首先梳理了调研提纲：

接下来，就是按照提纲完成调研工作。

1、明确业务重难点和用户期望

小张明白，SaaS产品也符合2/8原则：20%的功能，将决定客户80%的口碑。

从产品设计角度来说，基本需求的实现只能防止客户“不满意”。但如果要让客户“满意”甚至“超出预期的满意”，就必须解决业务重难点问题。

随着数字化时代的到来，一线用户的意见，对企业软件采购决策的影响越来越大。因此，小张也需要收集一线用户的期望。

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

其实，该客户为什么选择小张所在的公司，就是在体验了他们的移动端产品后，认为产品的用户体验非常好，可以解决当前系统推广的最大难题。

这也正好印证了小张之前的判断：公司的核心资源和能力，较好的匹配了新领域的需求。这次新产品的开拓，很可能会成就公司的第二增长曲线。（具体内容请参考本系列第一篇文章）

2、了解组织架构

如果把企业比喻成一个人，组织架构就是人的骨骼，业务流程就是人的血肉。骨骼不复，血肉焉存？

组织架构从根本上决定了业务流程，也决定了业务数据的安全性策略。

比如，如果公司按照产品线划分销售事业部，那么销售事业部往往会具有较为自主的权力。与此同时，事业部和事业部之间的业务数据也是相互屏蔽的，避免不必要的信息泄露以及过度内部竞争。

因此，在调研业务流程之前，小张必须首先搞清楚客户的组织架构，并绘制出组织架构图。

组织架构示意图

在查看相关资料并确认后，小张绘制出以上组织架构图。为了方便理解，小张去掉了和本次项目范围关系不大的职能部门，比如总部HR部门等。并对需要重点关注的部门，标注了星号。

1）总部-销售管理部

总部销售管理部门是本次项目的主导部门，也是各分公司销售管理的规则制定部门。

销售管理部的职责，主要是探索分销管理最佳实践，并通过管理制度、SOP和管理软件等手段，将最佳实践推广到各分公司。

为了保证执行到位，销售管理部还被赋予了考核分公司总经理的权力。

2）总部-IT部

总部IT部门是本次项目的协助部门，也是客户ERP系统的管理部门。

IT部的职责，主要是负责运维和升级ERP系统，小张公司研发的SaaS系统要打通客户ERP系统，就必须得到IT部的支持。

3）分公司-销售部

分公司销售部是本次项目的执行部门，也是负责客户具体销售业务和销售人员管理的部门。

销售部的职责，主要是负责销售人员的招募和管理，并通过拜访门店和管理经销商，最终达成公司的业绩目标。

销售部也是本次项目成败的关键——他们对系统的使用情况，决定了项目能否成功落地。

4）分公司-物流部

分公司物流部是本次项目的执行部门，也是负责仓库管理、物流配送的部门。

物流部的职责，主要是根据销售人员传回的订单，按时按量进行货物的配送。

3、梳理业务流程

由于小张已经和客户确认了整体业务流程（详见本系列第一篇），因此只需要补充详细业务流程。要了解详细业务流程，小张必须进行更为细致的调研。

具体又分为办公室调研和一线调研。

1)办公室调研

办公室调研主要目的是梳理业务逻辑，需要明确以下几项内容：

* 重点业务说明

主要是流程图无法清晰表述的业务规则等内容。

小张调研了价格管理规则，他了解到，客户的价格管理主要是由基本价目表和促销活动两个部分组成。

由于不同地区的竞争程度不同，价目表需要按地区进行配置，即不同地区（对经销商和零售店）的售价可能是不同的。

而促销则是在价目表的基础上，鼓励经销商和零售店进货的策略性手段。比如，“买3送1（杯子）”的促销活动，就是鼓励一次性采购3箱或以上——每3箱将免费送1个杯子。这对于利润微薄的经销商和零售店来说，具有很强的吸引力。同时也不会造成低价商品，从而扰乱平常价格秩序。

* 流程图

流程图是调研文档的核心组成部分。通过“什么岗位”和“负责什么操作”这两个维度，流程图可以直观反映业务处理过程，避免梳理出现错漏。

虽然只是调研阶段的流程图，但是小张仍然很重视，他针对所有细分流程绘制了流程图，并对每个步骤做了说明，示例如下：

* 重难点

虽然业务层调研的第一步已经明确了业务重难点和用户期望。但是在梳理具体流程时，用户可能会提出更多细节问题。

这些问题应该仔细记录下来，并在方案设计时妥善处理。否则，在系统上线后，小问题可能会演变成大问题，最终需要耗费更多资源去解决。

在调研时，客户提出，虽然大部分业务员都能够遵守规则，但是有极少数业务员会存在弄虚作假的行为。

比如，整理货架以后，企业希望业务员能对整理后的货架进行拍照，并上传到公司服务器。这样，公司督导人员就可以通过查看照片，判断业务员的工作质量，并对操作不规范的业务员进行督导和培训。

但在实际工作中，极少数业务员并没有对货架进行规范整理，而是通过调取手机图片、甚至对着图片拍照的方式，企图蒙混过关。

企业为了杜绝这种作弊行为，不得不组织人手对图片进行检查，不但工作量很大，而且也存在错漏的风险。

小张一边详细记录下这些重难点，一边思考解决方案。

2) 一线调研

在传统软件时代，大部分系统操作都在PC端，企业对用户体验也不够关注，因此，需求调研主要都在办公室进行。

在SaaS时代，移动端操作的比重越来越高，企业对用户体验也越来越关注，因此，除了办公室调研，往往还需要在一线现场调研。

考虑到一线调研的时间成本相对较高，因此小张按角色安排了调研计划，如下：

* 业务员：门店拜访场景

* 经销商：采购、发货与收款场景

* 门店：收货与付款场景

考虑到业务员是SaaS产品的主要用户——人员数量多、操作频次高、体验要求高，小张特意安排了一天时间，跟随一位业务员完成一天作业。具体安排示例如下：

在调研过程中，为了不影响业务员的工作，小张尽量作为观察者，观察和记录业务员的行为，以及他所面临的问题。

在午休时，小张主动请业务员吃了个便饭，一来拉近了关系，二来也顺便询问了很多现场作业的细节。

当然，只进行一次调研未必足够。因为这种“静默式调研”主要是了解“现状”，但并不能明确客户的“期望”。

比如，客户希望业务员在拜访门店时，对门店库存进行盘点。但是在实际工作中，业务员未必会按规范操作。

因此，有必要拉上业务员的主管人员或者优秀业务员，到现场进行“讲解式调研”。即由主管人员告诉我们，规范的操作应该是怎样的。理论上，我们应该按照可落地的、规范的操作进行产品设计。

当我们按计划完成了所有办公室调研和一线调研，并形成调研文档，还需要和客户进行确认。切记，任何问题在调研阶段被发现，纠正的成本都是最低的。因此，我们应该尽可能多调研、多和客户沟通。

另外，值得一提的是，在业务调研时，我们也要注意核对调研的范围是否完整。

比如，由于客户采用了KA直销和深度分销两种模式，因此小张在制定调研计划时，就针对两种模式分别制定了调研计划。

3、管理报表

管理报表是企业管理软件的核心组成部分，同时，考虑到大部分关键业务数据最终都会以报表的形式呈现，因此，尽早进行管理报表调研，也可以反向验证我们是否遗漏了重要流程和业务逻辑。

在业务流程调研的同时，小张找客户要了相关报表的样表，并逐一进行了分析和沟通。

其中有一张销售业绩报表引起了小张的注意。

示例（字段和数据均属虚构）

报表本身很普通，但客户提出，存在以下情况：

1）销售人员会在部门间调动。

比如张三去年在B组，今年调动到A组。

2）A、B组所负责的销售区域，每年都可能调整。

比如2020年A组负责abc三个区域，2021年可能负责abef四个区域。区域覆盖的商圈范围可能也会调整。

因此，当需要比较A组2020年与2021年的业绩时，由于A组的组织架构、负责区域和销售人员都在变动，2020年的“A组”和2021年“A组”，就失去了可比性。

但是，为了考核“A组”的绩效，与去年业绩进行同期对比是必要的。权衡之下，客户认为，相对于区域，人员在部门间的调动影响较小。因此，决定按“A组所包含的人员”进行往年同期对比。

比如，A组有张三、李四、王五三位销售人员，就将这三位销售人员2020年的销售业绩之和，作为A组2020年的销售业绩，并与A组2021年的销售业绩进行对比。

这样的对比毫无疑问存在偏差。

比如张三去年实际是在B组，他去年的销售业绩，根本不应该归属于A组。但是客户认为这种误差是相对可控的，因此5年来，一直采用这个逻辑。

小张知道，这个逻辑涉及到部门业绩的核算，虽然误差“可能”不大，但由此可能导致的一线部门抱怨甚至纠纷，将给企业管理带来很大隐患。

同时，万一客户后期又发现更好的方案，就意味着报表的底层逻辑要大改，那么无疑将会造成巨大的研发浪费。

考虑到这些，虽然客户一再强调“按照原有逻辑处理就好”，小张仍然决定从底层重新思考报表的逻辑。

小张认为，深度分销的基本逻辑，是将客户划片（比如按商圈划片），再将商圈组成区域，分配给销售小组进行覆盖。而这个逻辑的基础，则是客户（夫妻老婆店）是相对稳定的。虽然也会存在客户从a商圈搬迁到b商圈，但是这种情况发生的概率极其低。

因此，小张认为，相对于部门和销售人员，客户才是最稳定的。如果将客户所属的商圈，作为对比的依据，就可以更多准确的判断“A部门”在今年的销售业绩，究竟比去年更好还是更差。

比如，A部门今年负责了10个商圈，我们只需要找到这10个商圈在去年的销售数据，就可以判断A部门今年的表现情况了。

这种逻辑，在A部门组织架构、负责区域和销售人员都存在较大变动的情况下，应该是最合适，也最符合深度分销逻辑的。

心里有底了，小张决定和总部销售管理部的负责人，也是本次项目的负责人，好好谈一谈。小张知道，要说服客户并不容易，因为他们是快消品行业最顶尖的企业，一直都是他们指导供应商，从来没有供应商“指导”过他们的。

4、系统集成

大企业往往存在多套“现有系统”，而它们也可能影响到新的SaaS系统的设计和部署。比如：

1）现有系统将被新SaaS系统替代

2）现有系统将与新SaaS系统集成

小张详细询问了用户对现有分销管理系统的评价，他发现，用户对现有系统的反应迟缓、操作复杂怨气很大。毫无疑问，用户体验将是这次设计的重点，因为用户一定会将新SaaS系统与现有系统进行对比。

小张也详细了解了需要与新SaaS系统集成的系统，其中最重要的是Oracle ERP系统。小张明白，了解集成系统的业务流程和表结构非常重要，否则在集成的时候，流程或者数据接口就会出现问题。

在小张公司原有的SaaS系统中，允许一个订单行的商品存在多个单位（比如3箱8瓶）。系统按照“录入单位”进行数据存储：比如销售3箱8瓶A商品，虽然6瓶等于1箱，但是仍然按照3箱和8瓶存储在一个订单行，而不会进行换算，也不会拆分为两行。

这样处理主要是便于经销商核对实物，即：8瓶和1箱2瓶在实物上是不同的。自动换算或者拆行，都可能影响用户体验。

但是，在客户的Oracle ERP系统中，一个订单行就只有1个单位。而且，不管订单行录入什么单位，最终都要换算成“基本单位”进行存储（也会保留录入的单位）。比如录入了60瓶，系统也会换算为10箱（6瓶等于1箱），并根据10箱进行后续的供应链和核算处理。

小张意识到，新的SaaS系统也有必要引入“基本单位”的概念，并对订单行进行单位换算和存储，否则和Oracle ERP的集成将会遇到麻烦。

5、后记

经过一周的调研，小张认为已经对客户的相关业务和系统有了较为全面、深入的认识。于是，他提前约了客户的项目负责人，将梳理的调研文档与客户进行了逐一沟通，并对其中的一些细节问题进行了补充和纠正。

和传统软件项目不同，小张并没有要求客户对文档进行签字确认。小张知道，在SaaS项目中，产品经理需要承担起更多的责任——因为这个项目最重要的意义，并不在于服务好某一个特定的客户。而是在于打造一个真正优秀的SaaS产品，从而服务千千万万的客户。