saas项目开发流程图_超详解析saas项目设计

saas项目开发流程图_超详解析saas项目设计,第1张

saas项目开发流程图_超详解析saas项目设计 对于大部分SaaS公司来说,产品标准化程度决定了企业的生死。


今天,我们就站在产品经理的角度,来看看SaaS从0到1的标准化设计应该怎么做。


限于篇幅,本文对如何画流程图、如何制作原型等基础技能就不再敷述,侧重阐述实现SaaS标准化设计的要点。


为便于大家理解,本文会以一个案例为线索,一步一步演示如何从0到1设计一款SaaS产品。


01 SaaS与自用系统的差异虽然同为B端产品,SaaS与自研系统的差异却非常明显。


从根本上来说,SaaS产品需要服务于众多企业:少则几十家,多则几万家。


因此,对业务的包容性需要很强。


代价则是产品迭代速度相对缓慢。


自研系统由于只服务于一家企业,强调的是贴身服务,因此对产品包容性要求较低,但是很强调迭代的速度。


虽然SaaS和自研产品的逻辑是类似的,但是对产品经理能力的要求却有一定差异。


具体可以参考下图:内部B端产品经理更多是辅助角色。


因此比较强调深入参与和支持业务,通过协调甚至推动业务部门,达成公司目标。


SaaS产品经理就不一样了,因为负责商业化产品,是公司实现营收和盈利的核心环节,所以比较强调产品本身的架构能力和设计能力。


我个人认为,衡量SaaS产品经理的优劣,其中一个重要的标准就是:当用户数不断增加,产品功能会不会被推翻或大幅修改,即能不能多做加法,少做减法和改法。


02 标准化的意义产品标准化对SaaS公司至关重要,曾经听某知名SaaS公司大区总监说,某个百万级项目谈得非常好,约定4个月交付上线。


结果到了第3个月,客户要求推倒重来,按客户实际业务重新开发。


这位销售总监抱怨道:“前面谈得好好的,就用标准化产品。


但到项目后期,客户却说产品满足不了业务需求,真是搞不懂。


”这就是典型的产品能力支撑不了销售能力。


如果这样的项目很多,SaaS公司就很难盈利。


具体来说,SaaS标准化有以下三个重要意义:1. 降低边际成本SaaS公司最大的成本投入是研发成本, 如果每一个项目都是通过配置完成交付,这意味着随着用户数的增加,研发成本会被逐步摊薄,最终形成规模效应,因此标准化是SaaS公司盈利的关键之一。


2. 沉淀最佳实践B端客户真正希望购买的是“行业最佳实践”,即便SaaS公司具备丰富的行业经验,也了解行业标杆的业务策略和执行方案,如果SaaS产品不能体现和支撑这些“最佳实践”,那么推广和执行的成本都会很高。


所谓标准化,其实就是把领先企业的解决方案进行提炼,再固化到系统中。


这些固化的解决方案,是SaaS系统的灵魂。


3. 积累产品能力如果SaaS公司依赖运营而不是依赖产品来保障“客户成功”,那产品和产品经理的价值都会大打折扣。


标准化会不断增强产品的配置能力,使得产品越来越厚重,价值越来越高。


也只有厚重的B端产品,才能磨炼和体现产品经理的产品能力。


03 标准化策略标准化策略是SaaS产品策略的重要组成部分,可以分为三个部分,分别是:1. 产品版本标准化策略标准化最重要的策略,是确定“不满足哪些客户的需求”。


“一套产品吃遍天下”的传统软件时代,已经过去了。


即便我们要占领多个细分市场,也要谨慎判断,是否通过“一个行业版本”满足全部客户的需求。


比如,在快消品行业,经销商和生产商的管理模式差异是比较大的。


对于经销商来说,组织和权限的管理是相对简单的,也不涉及严格的外部账号管理;而品牌商则有复杂的多组织管理的需求,包括外部组织和账号的管理。


再比如,经销商的价格体系是相对简单的,不同等级的客户可能会有对应的价目表,部分客户会签订特定的价格协议;但是品牌商的价格体系则复杂很多,不同分公司、不同区域、不同商圈等级都会影响具体的价格。


这是因为“价盘”是品牌商的生命线,所以精细的控制是有必要的。


快消品经销商和品牌商需求差异当然,并不是说,我们一定不能在一个版本满足多个行业的需求。


过去SAP、Oracle的成功已经证明这一点是可以实现的。


但是,SaaS引以为傲的正是足够“高可用”的系统。


过于臃肿的产品,会大大增加客户的使用成本。


反过来说,“一个版本满足所有需求”当然是不正确的。


但是如果盲目的横向扩充版本,也会给SaaS公司带来沉重的研发负担。


比如,当我们面对“非处方药”行业的客户,是否需要划分出一个版本呢?虽然并不是快消品行业,但是“非处方药”却在学习快消品行业的分销模式。


在这种情况下,如果我们提供的是分销SaaS产品,就暂时没有必要单独为“非处方药”划分一个行业版本出来。


2. 功能层标准化策略标准化第二重要的策略,是决定“哪些功能不标准化”。


对于大部分SaaS,90%以上的功能是能够在产品层面进行标准化的,但是可能有10%的功能是很难标准化的。


分清楚哪些功能可以“在产品层面进行标准化”,也非常重要。


比如,中小企业对报表的需求相对简单,因此报表功能是相对容易标准化的;但是对于百亿级企业来说,报表是一个高度复杂且不能妥协的需求,因此对于还没有BI或者PaaS产品的SaaS企业来说,暂时进行定制也是一个可行的选择。


3. 开发层标准化策略对于无法“在功能层进行标准化”的功能,我们要想办法在开发层进行标准化,即通常我们所说的PaaS,现在流行的叫法是“低代码”。


低代码是一个很“古老”的事物。


我还在Oracle公司的时候,就很频繁的使用Oracle的低代码能力了——我们又叫personalization。


通过它,我们可以改变字段的属性,也可以嵌入SQL甚至package。


也就是说,即便是能够灵活二次开发的传统软件,也非常依赖低代码。


更不用说二次开发相对困难的SaaS公司了。


因此,如果一家SaaS决意要做大,PaaS能力就不是可选题,而是必选题。


但是,自研PaaS平台确实是一个费钱的工作,并不是所有SaaS创业公司,都能够轻易负担得起的。


好消息是,中国SaaS正在进入平台时代,钉钉、企业微信逐步增强的低代码能力,有望帮助SaaS公司低成本的拥有“PaaS自由”。


04 标准化设计难点和自研系统相比,SaaS产品的设计更依赖长远规划。


这是SaaS设计的核心,也是SaaS设计的难点。


重视长远规划,主要是由于两个原因:1. 控制开发成本由于标准化强调配置能力,因此同样一个功能,所需要的开发量可能是自研系统的数倍。


一旦开发了拙劣的功能,就可能对开发资源造成惊人的浪费。


2. 便于持续迭代更重要的是,作为“公用产品”,SaaS必须保持简洁性:如果系统充斥着一堆鸡肋的功能,且有少数企业坚持在使用,那么会对系统迭代造成阻碍。


读者可以思考一下,当规划的新功能与这些鸡肋功能产生冲突,产品经理应该如何处理?因此,好的SaaS设计就是尽量做“加法”,避免做“减法”和“改法”。


当然,标准化设计对产品经理本身也是有要求的。


我常常比喻,所谓的标准化设计,就像在棋盘上放棋子:棋盘就是产品经理所拥有的架构能力,棋子就是具体的需求。


没有棋盘,就不可能正确落子。


05 标准化设计步骤从设计过程来说,标准化设计可以遵循以下四个步骤:1. 策略层梳理所谓策略层梳理,是站在相对宏观的层面梳理业务,具体又包括以下步骤:1)明确业务范围企业的业务可以分为前中后台业务,前台业务包括商城APP等,中台业务包括CRM、订单管理、物流管理等,后台业务则包括HR、财务等。


我们首先需要明确,第一版SaaS产品版本主要是满足哪一块业务需求。


划定好了边界,才能匹配公司的战略和资源。


案例:一家知名快消品厂家找到某SaaS公司(简称A公司),希望开发一款管理销售人员的移动APP。


经过沟通,SaaS产品经理小李意识到,客户的需求实际上是分销管理,包括销售订单管理、销售人员管理和门店管理等。


虽然A公司有服务于快消品‘经销商’的分销管理系统,但是一直苦于无法切入利润更丰厚、收入更稳定的快消品‘品牌商’市场,这正是一个非常好的机会。


2)梳理经营策略所谓经营策略,其实就是企业的打法比如:在线下分销业务中,用户企业是采用深度分销?还是兼有直销?搞清楚客户的经营策略,才能理清产品研发的思路。


此外,我们必须明白,SaaS是给一个行业的众多客户使用的。


因此,我们还需要对企业所在行业的经营策略进行梳理。


这样,一方面可以将客户的经营策略匹配到行业的经营策略,便于我们抓住本质,确保产品的通用性;另一方面,也可以通盘考虑未来的拓展方向,提前打好架构基础。


比如,快消品线下分销常见的策略包括大批发制、多级分销、深度分销、直销、车销等,而深度分销又分为厂家覆盖模式和经销商覆盖模式。


作为产品经理,有必要全面梳理这些模式,才能在产品设计时胸有成竹。


案例:小李和客户沟通后,发现该快消品厂家主要采用了大批发制、直销和深度分销三种经营策略,属于行业比较经典的打法,可以先开发这三种分销模式,同时兼顾到未来向多级分销和车销的拓展。


大批发制大批发是厂家把货卖给批发商,由批发商再进行二次分销。


大批发模式虽然是比较粗放的分销方式,但是当厂家管理能力不足时,采用大批发模式可以实现快速铺货,因此仍然是常见的一种分销模式。


直销制快消品行业有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片区;今年的A部门,有20个人员,管辖b片区。


如果简单的把去年A部门业绩和今年A部门业绩做对比,实际上是有失公允的。


小李和客户的项目负责人进行了沟通,由于这个客户是快消品行业最顶尖的企业之一,项目负责人也属于比较自信的领导,因此一开始小李的建议并没有得到重视。


但是小李坚持与客户进行沟通,指出“在分销模式下,只有便利店和对应的区域是相对稳定的。


因此应该用A部门所负责c区域的今年业绩,和c区域去年业绩做对比,这样才是真正公平的”。


最终,客户领导被小李说服了,他当着众人的面夸奖了小李。


而有了客户领导的配合,项目的推进也非常顺利,最终成功上线。


小李也借助这个项目完成了SaaS的从0到1。


不久,他又将这个SaaS产品销售给了其他的大客户,帮助公司成功完成在大客户市场的突破。


总结SaaS产品的设计,很强调产品经理的架构能力。


如果用一句话对本文做个总结,那就是:画好棋盘,放好棋子。


欢迎分享,转载请注明来源:内存溢出

原文地址: http://outofmemory.cn/tougao/639981.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2022-04-17
下一篇 2022-04-17

发表评论

登录后才能评论

评论列表(0条)

保存