大批发制
大批发是厂家把货卖给批发商,由批发商再进行二次分销。大批发模式虽然是比较粗放的分销方式,但是当厂家管理能力不足时,采用大批发模式可以实现快速铺货,因此仍然是常见的一种分销模式。
直销制
快消品行业有40%左右的销量,都是通过以大超市为代表的现代通路完成的。这些大超市往往是区域连锁甚至全国连锁,可以树立品牌形象,但是进入门槛高、谈判过程复杂,因此,往往是由快消品厂家直接进行合作。
深度分销
深度分销是快消品分销的重要方向。实行深度分销的企业,往往已经具备一定的规模和管理能力。他们将区域进行划分,指定经销商专营,强调终端门店的铺货率、陈列、新品普及率等。
对于企业来说,深度分销可以最大化挖掘终端门店的潜力,提高新品和高毛利商品的销售量,并有效的阻击竞争对手。因此,这种模式一直是伊利、康师傅、可口可乐等大型快消品企业的重点分销模式。
3)梳理业务难点相对于传统软件,SaaS是后来者
根据产品替换公式:新产品价值>旧产品价值+替换成本,只有SaaS提供了更大的价值,客户才会考虑购买。退一步说,即便没有竞争的传统软件,SaaS也必须解决“以前无法解决的问题”,才能在激烈的竞争中站稳脚跟。
因此,梳理清楚业务难点,明白“客户为什么选择我们”,是非常重要的工作,可以让我们把资源集中在最关键的功能上。而不是分散资源,做那些客户虽然愿意使用,但是不构成“差异化竞争力”的功能。
案例:
经过和客户沟通,小李了解到,其实客户之前已经耗费上百万实施了某国际知名品牌的CRM系统,但是移动端的用户体验非常糟糕。除了使用上不够高可用,需要反复培训才能上手;低下的操作效率和缓慢的响应速度,更是使得系统的推广困难重重。
客户为什么选择由A公司来开发分销系统,就是在体验了A公司的移动端产品后,认为产品的用户体验非常优秀,可以解决当前系统推广的最大难题。了解到客户的诉求后,小李意识到:这个针对快消品厂家的SaaS系统,设计的重心要放在移动端。
快消品行业普遍存在销售人员学历低、管理难的问题,如果通过移动端大大提高员工效率、降低员工使用难度,那么该SaaS产品将对快消品品牌商产生巨大吸引力。
2. 业务层梳理
业务层梳理,最有效的做法就是画业务流程图。流程图的重点在于,产品经理要帮助客户梳理清楚业务和需求,避免错乱和遗漏。而做到这一点的关键,是产品经理要有一定的架构能力,即知道典范的流程应该如何流转。
如果是针对大客户的SaaS,那么建议到客户现场呆一段时间。大客户的要求比较细致,现场沟通可以提高沟通的效率;如果是针对小客户的SaaS,那么建议你先找到几个种子用户,通过流程图,确保1.0版本是他们能够接受的MVP(最小可行产品)。
流程图绘制细节是基本功,这里就不再敷述。下面放一张我曾经绘制的流程图供大家参考:
案例:
一开始,该快消品企业认为自己的需求很简单,主要是业务人员在定位器端录入销售订单,再通过接口实时传送到已有的ERP系统即可,如下图:
小李并没有急于下结论,而是在黑板上画出了典范的分销管理流程,然后按照流程环节逐个进行梳理,如下图:
经过梳理,小李很快发现,该厂家对于区域连锁卖场等大客户,采取的是厂家业务员拜访、工厂直接发货的直营销售策略;对于非连锁便利店等小客户,采取的是厂家业务员拜访、经销商发货的深度分销策略。因此,客户实际上有两种不同的销售管理流程,如下图:
流程梳理清楚,设计思路也就清晰了。同时,小李专业的需求梳理方法也得到了客户认可,客户领导当场表达了合作的意向。
3. 多组织架构设计
企业业务的开展,是基于多个部门的相互协同和相互监督的。当用户在使用SaaS系统时,流程流转、数据安全性都必须符合企业协同与管控的要求。这就需要我们设计好组织、角色和权限功能。而这里面最有难度的,就是多组织架构设计。
比如,某饮料公司为扩大销售规模,分别在A市和B市建立了分公司,各负责一个大区的生产和销售。为便于管理和激励分公司团队,公司决定两个分公司独立核算利润,并根据实现的利润进行分红。
为支持两个分公司的独立核算,并防止数据泄露,该饮料公司IT团队决定分别给两个分公司建立一个“利润中心组织”。
在“利润中心组织”下面建立了相应的“角色”,并分配了相应的“功能”比如销售订单、发货功能等等。最后,将相应的“角色”分别分配给了两个分公司的员工。
这样,A公司员工建立的销售订单,所产生的收入和利润数据,均会统计到A公司。且销售订单、收入和利润等数据,只能由A公司的员工查看。B公司亦如此。
多组织架构实际上体现了企业责权利的划分,决定了组织间协同与风险管控策略。由于企业越大,组织架构就越复杂,管控要求也越高。因此,越是针对大型企业的SaaS,越需要重视多组织架构的设计。
当然,如果是针对小企业的SaaS,多组织架构就相对简单了,大家把角色和权限管理设计好即可。
案例:
小李梳理发现,客户下设2个独立核算的营业部,每个营业部下面都有若干经销商。
对于直营的KA门店,只能由对应营业部管理数据和处理业务;对于经销商管理的便利店,只能由对应经销商管理数据和处理业务。同时,经销商所属的营业部,也具有这些便利店相关数据的管理权。
小李设计了“利润中心”组织类型,并创建了两个利润中心组织:江东营业部和江南营业部。
经销商A、经销商B、KA门店C都属于客户(具有不同的客户类型),在客户信息上加上“所属组织”字段,通过该字段,将这3个“***”都分配江东营业部。这样,就只有江东营业部的人员可以看到他们的资料以及业务数据。
对于便利店a、b、c、d,则通过类似的方式,关联到对应的经销商,确保经销商之间业务信息的隔离。
4. 产品功能设计
作为SaaS设计的主体,产品功能设计又可以分为应用架构设计和详细功能设计。
1)应用架构设计
所谓应用架构设计,即各系统应用的整体结构图。
相对于自研产品,SaaS的应用架构设计更为关键。合理的应用架构可以减少功能重复、避免数据混乱和降低系统拓展的难度。而一旦在不合理的应用架构上搭建起功能模块,并且拥有一定数量的企业客户后,修改的成本就非常高了。
相对来说,自研产品的纠错成本就低得多。毕竟只有一家企业在用,只要和业务部门协商好,推翻重建也不是不可以。
对于产品经理来说,应用架构设计的重点要做到低耦合、高复用。所谓低耦合,是将功能按照业务相关性,分为多个系统应用。系统应用之间通过API进行交互。
这样,单个应用的升级,对其他应用的影响就小很多,从而提高了系统的敏捷性。比如,销售订单管理、仓库管理和CRM就可以独立为多个应用,并且在必要的时候分配给不同的团队负责。
所谓高复用,即将各个模块所共用的功能抽离出来,单独形成一个系统应用。
这样,一方面确保了信息来源的一致性,另一方面简化了系统,避免了重复开发。比如,客户信息在销售订单管理、CRM、TMS(运输管理)等系统应用中都会用到,是有必要独立成一个应用的。
应用架构设计虽然没有标准答案,但实际上不管是传统的Oracle ERP系统,还是新兴的各大电商、SaaS系统,都有非常成熟的应用架构设计。多研究竞品,再结合实际情况进行适当的调整是应用架构设计的好方法。
案例:
考虑到A公司已经有独立的客户信息系统,也有成熟的商品管理系统,小李决定直接复用这些系统。为了满足品牌商的需求,小李增加了一些新的功能,比如商圈管理、价格策略管理等。
其实,复用客户信息管理和商品管理模块,小李还有长期的考虑,即未来品牌商版本和经销商版本可能会打通,形成交易型的SaaS产品。如果两个版本共用一套基础数据功能,会有利于将来的数据集成和流程整合。
2)详细功能设计
SaaS详细功能设计很考验产品经理的系统经验,从设计流程上来说,SaaS功能设计也遵循通用B端产品设计流程,如下图:
但是,SaaS系统面对的是多个企业的具体需求,而这些具体需求看起来总是千差万别的;更困难的在于,产品经理并不能确定未来会面对什么样的企业,也就无法预知所有的需求。
在这种情况下,产品经理可能就会面临各种尴尬局面,比如:
功能升级需要大幅修改原有功能,开发抱怨;功能升级改变原有体验,客户抱怨;功能上线后,没有人使用,团队抱怨;功能上线后,客户说需求变更了,各种人抱怨。
所以SaaS详细功能设计很考验产品经理的规划和深度思考能力,具体来说,SaaS产品经理需要做好以下几点:
长远规划,谨慎设计
从0到1的SaaS,往往是从一小群客户的需求起步。当客户数量较少,功能也不多的时候,产品的设计缺乏约束,很容易野蛮的生长。
比如,买赠是消费品行业常用的促销手段。在某些情况下,赠品需要关联到主品,比如买5瓶大可乐送1瓶小可乐。产品经理为了设计和操作方便,可能选择直接在订单行上新增字段,体现赠品名称和数量。
这样的设计在面对简单需求的时候,可能不会出现问题。但是一旦遇到比较复杂的情况,比如:
需要管理赠品发货;买5增2,买5瓶大可乐送2种赠品;需要和ERP系统集成等情况时,就会出现问题。
正确的做法是,主品和赠品都放在独立的订单行,拥有相同的字段,并且通过“赠品”字段来标识该订单行是否赠品(打勾即为赠品)。因此,作为SaaS产品经理,不能够只盯着眼前的需求,而应该放眼长远,尽可能考虑全面。
另外,SaaS产品经理必须承认:即便通晓所有需求,我们仍无法确定全部需求的优先级。因此,一般情况下,产品经理只能挑选那些最有价值的需求优先进行满足。而且,每一次的设计都应该是MVP,从而避免暂时不需要的功能被提前开发。
这就是SaaS谨慎设计的原则。
深度思考,究竟精神
SaaS设计的纠错成本,远高于自研产品。但是,SaaS产品经理离客户往往比较远,不容易深入参与客户的日常经营。
相对而言,传统软件时代的项目制,需求设计师可以在一个客户现场驻点数月进行需求调研和系统开发;而自研产品的产品经理,则几乎天天和业务方在一起沟通。
SaaS公司的研发团队庞大,不可能都派驻到客户现场,因此产品经理往往需要两头兼顾,既要把客户的需求搞透彻,也要做好设计,让研发能够顺利工作。
在这种情况下,SaaS产品经理就必须具备“究竟精神”:对客户的每一个需求刨根问底,究其本质。我一直坚守一个原则:永远相信客户有一个痛点,但是永远不要相信客户有一个正确答案,也把这个原则送给大家。
便览竞品,死磕细节
SaaS为什么能够抢占传统软件的市场?最重要的原因并不是SaaS更便宜,而是SaaS的出生就带有移动化、社交化的属性。但是,移动端设计的难度是PC端设计的好几倍。原因除了定位器屏幕更小,同时也是因为移动端操作是在户外,场景更复杂,对体验和效率的要求也更高。
比如:快消品车销业务员为了完成一天的拜访任务,拜访一个客户的时间平均不能超过5分钟。为了节约时间,业务员需要一边卸货一边拿着定位器下订单。因此,“录入销售订单”这个页面必须足够简单和高效。
比如:在输入商品数量时,就可以直接录入多单位数量(不需要选择单位),如“1箱/3瓶”。并且允许通过加减号来增减数量。
这样,当业务员搬下车1箱3瓶酸奶(假设1箱酸奶有9瓶),他就不需要再计算出“1箱3瓶等于12瓶”才能录入系统,这就可以大大提高业务员的操作效率。
要做好SaaS交互设计,除了和UE同学充分沟通和探讨,更重要的是多研究和学习竞品。所谓三人行必有我师焉,何况我们是从0到1的设计SaaS呢?
案例:
在进行报表设计时,客户有几张已经使用了5年的核心统计报表,客户领导希望新的报表仍然沿用以前的统计逻辑。但是,小李仔细分析后,发现以前的逻辑并不是最优的。
因为客户的部门和人员每年都会调整,而原报表是根据“订单-人员-部门”的对应关系,来计算销售业绩。这就导致进行同期对比时,历史年份和最新年份的业绩基础并不公平。
比如,去年的A部门,有10个人员,管辖***区;今年的A部门,有20个人员,管辖b片区。如果简单的把去年A部门业绩和今年A部门业绩做对比,实际上是有失公允的。
小李和客户的项目负责人进行了沟通,由于这个客户是快消品行业最顶尖的企业之一,项目负责人也属于比较自信的领导,因此一开始小李的建议并没有得到重视。
但是小李坚持与客户进行沟通,指出“在分销模式下,只有便利店和对应的区域是相对稳定的。因此应该用A部门所负责c区域的今年业绩,和c区域去年业绩做对比,这样才是真正公平的”。
最终,客户领导被小李说服了,他当着众人的面夸奖了小李。而有了客户领导的配合,项目的推进也非常顺利,最终成功上线。小李也借助这个项目完成了SaaS的从0到1。不久,他又将这个SaaS产品销售给了其他的大客户,帮助公司成功完成在大客户市场的突破。
总结
SaaS产品的设计,很强调产品经理的架构能力。如果用一句话对本***个总结,那就是:画好棋盘,放好棋子。
本文来自一九九几的她投稿,不代表舒华文档立场,如若转载,请注明出处:https://www.chinashuhua.cn/24/609549.html