6000字长文:SaaS从0到1,案例实操系列(二)

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

SaaS从0到1系列,全景图

01 需求梳理-策略层

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

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

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

客户的需求

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

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

概要流程

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

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

比如:要管理“业务员拜访门店”,就必须进行门店(客户)管理和业务员管理;要支持“录入订单”,就必须管理“商品”和“价格”。

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

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

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产品,从而服务千千万万的客户。

本篇完。下一篇,我们接着讲SaaS产品的整体方案如何编制。

#作者#

王戴明,微信公众号:To B老人家,多年互联网产品与信息化管理经验。

本文

版权声明

本文来自互联网用户投稿,文章观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符,请点击 举报 进行投诉反馈!

相关文章

立即
投稿

微信公众账号

微信扫一扫加关注

返回
顶部