交易履约类后台产品的产品价值和验证方式

1 评论 7010 浏览 10 收藏 25 分钟

编辑导语:交易履约的后台产品,可以理解为通过进行一系列履约业务流程,实现一笔交易从发生到完成的整个过程。本文作者就结合了个人经验,为我们深度分析了履约类后台产品的价值所在和结果验证方式,一起来了解一下吧。

后台产品,我把它分为3个类型,面向客户的SaaS,服务于公司管理事务的后台产品比如OA、财务系统,和服务于公司交易履约业务的后台产品。

交易履约的后台产品,可以理解为通过进行一系列履约业务流程,实现一笔交易从发生到完成的整个过程。

比如一个电商或者O2O的公司,通过运营或者销售完成客户转化,通过用户下单来形成交易,然后采购、物流配送业务来将商品送到用户手上,或派单、实时配送来完成交易,这里面的订单、供应链、CRM等系统,就是我们常见的后台系统。

我做这一块的后台产品这些年,最开始只会是按业务需求做,到后面我发现,大家都需要产品经理来证明你做的产品有什么价值,而后台产品要衡量产品和项目的效果比较困难,不一定能找到真能表现产品价值的数据指标。

比如说我要做一个供应链的采购、物流流程,涉及到一大堆单据流、状态机,但它的价值似乎只能描述为,我不做业务就没法线上运行。

再比如一个CRM系统,做了若干需求希望提升销售的成交转化率,实际上影响转化率的因素太多了,客户线索的质量,销售个人能力,外部环境,甚至销售今天的心情,都会对转化率这一结果有影响,导致即使转化率提升了,也不知道是哪个因素提升的。

但是即使后台产品的收益和效果难以量化,我们还是得知道产品为什么目标而做,并想办法去分析、验证,不然产品说不清价值,那产品经理不就没了价值,或者单纯的沦为给业务方打杂的。

本文主要结合我做过的几个案例,来写履约类后台产品的价值所在,和结果验证方式。SaaS类产品,和OA之类管理领域的产品,不在本文讨论范围内。

当然不同公司业务不一样,具体的产品设计思路也会有区别,本文适合小公司的或者入门级别的后台产品经理看看,也欢迎大公司的产品经理来批评指正。

一、为什么要做交易履约类后台产品

一个做在线交易的公司一定会有交易履约类后台产品,不然业务无法在线运转起来。这个点每个产品经理应该都知道,因为这是后台产品最基础的一个价值,即支持业务在线运转的基建价值。

除此之外,后台产品还有哪几方面的价值,我们可以从产品服务的对象去做分析。

不同于C端产品服务于用户、SaaS产品服务于某领域内的企业客户,交易产品首先面对的是一套运转中的业务,在业务中除了固有的业务流程,还会有一线的执行人员和管理人员的参与。

于此对应的,后台产品可以分出业务价值、用户价值和管理价值这三个层面的价值。以下针对这几个层面,阐述下具体的价值所在和验证方式。

二、基建项目

基建是每个后台产品的基础,没有基建就无法撑起一个后台。

一个公司的后台系统一定会包含很多基建的部分,比如做电商的公司要实现用户在线下单,就需要有管理商品的商品系统,实现订单流程的订单系统,支持使用优惠券的营销系统,再到用户体系、权限系统,这些都是基建的部分。

具体工作中,往往存在大量的基建项目。

一类是大型基建项目,从0到1做一个新业务模块,或者系统重构。

做这类大型基建项目的背景,通常是公司有了一块新业务,或者说老系统已经很难支持业务的不断发展,需要进行一轮重构以便更好的支持后续的需求。做一个大型基建项目的出发点通常不是业务,而是系统本身架构层面的一些问题,所以要衡量项目成果时,没法直接从业务数据上获得结果。

因此针对大型基建项目,不需要非得找某个指标去验证价值,想找也找不到,最多考核一下项目的上线时间即可。

还有一类是优化型的基建项目,比如修改一个业务规则,业务流程中增加一个环节,提供一个业务报表等等。

很多优化型的基建项目不是单独存在的,通常是业务上出现了需求,需要对应的做下基建来满足这个诉求。这类项目如果本身有其他维度的目标,那么可以直接用这个目标进行结果的验证,比如说上线一个业务报表能提升线下业务人员操作的效率,或者业务流程改一个环节能够让某个数据实时生成,等等。

不同业务规模的公司,对基建这个事情的方式、做法也不一样。对于处于业务初创期和发展期的小公司而言,基建是一个比较难把控的事情,因为第一小公司没有那么多的资源来给你做基建,第二早期一定是业务先行,初创期的业务随时有变更的可能,基建做的太重一旦因为变更被推翻,非常浪费开发成本,所以我不建议在业务还没定型的时候就做大规模的基建。

当业务相对稳定,进入发展期之后,可以抽时间做基建,如果基建做的太晚不完善只能在老系统不断打补丁,越到后面越不好用。但这个时候业务需求会越来越多,需要平衡做基建和支持业务需求的时间。

大公司的基建项目,通常是我们常说的中台建设。中台产品通过将可复用的模块抽象成中台服务,给到更多的系统使用,目标在于避免重复造轮子,造成资源的浪费。

中台产品服务于各个不同的业务终端,因此可以通过接入的系统数量,来验证中台产品落地的效果。本人没深入接触过大厂的中台,针对中台就不赘述了。

1. 面向管理,业务流和数据的在线、实时、精准

面向业务管理的价值,通常会将业务操作和业务数据,做到在线、实时、精准这3个要求。

对管理角度价值的理解,一个是流程管理上的价值,比如一个原本线下的业务作业,通过线上流程进行在线化、规范化,这样能够方便公司管理角色的人员进行业务的管控,并解决一些透明、合规、风控角度的诉求。

另一点是数据管理的价值,比如公司的库存、资产数据在线,便于追溯、核算成本,并作为发挥数据价值的基础。

在线、实时、精准,是衡量后台产品是否达到管理要求的3个标准,依次递进。在线,指的是某个业务流和数据需要在线上体现,不能只在线下运作;实时,是实现了业务在线之后,线上操作需要跟随业务实时进行,不能滞后去补录;精准,指的是数据在线后,计算、关联追溯逻辑需要准确,而且是系统的准确,并非人工填写的准确。

举个例子,某个电商公司的采购业务,需要向外部供应商进行采购。原先业务的模式是线下完成采购之后,在公司自己的系统中手动录一个数据。现在从管理和合规的角度,整个采购系统需要做到线下采购业务的在线实时和精准。

在线,通过供应商端将供应商的业务作业在线进行,解决原先供应商完全在线下的情况;实时,采购业务报价、采购、送货、结算的整个流程,由采购员和供应商实时线上操作,不能全部做完之后再补录,造成采购数据滞后影响后续履约数据一并跟着滞后;准确,商品采购价格和后续每个环节的加价规则准确,因为采购价格是商品成本的来源,采购价格不准直接影响成本核算。

管理角度的后台产品项目,衡量标准通常会有点偏定性,因为还没有对业务本身做到提升,所以会用类似于某某业务是否在线,数据是否精准,作为定性的验证方式。

一种相对比较完善的做法,比如衡量一个业务流中的环节是否在线,可以先将业务流的每个环节通过流程图的方式抽象出来,然后一一数有多少个环节,几个环节不在线,产品上线后做到了几个环节的在线。比如上面这个采购案例,业务流中有报价、采购、送货、结算这4个环节需要供应商在线参与,那么验证方式就是这4个环节,有几个做到了供应商在线。

针对数据,比如衡量是否准确,也是同样的道理,比如上个案例中有商品报价、采购价格、商品批次成本等,验证方式就是看这几项数据,有哪几项做到了准确。

数据的在线实时精准,除了管理目的之外,还起到了通过积累数据,发挥数据价值的作用,这一点在后面会写到。另外有人会把这一点视为基建的一部分,这个看每个人的理解了。

虽然说流程数据的在线这个事情,实现形式就是基建,但这块需求是能说得出项目价值的,跟虚无缥缈的系统重构还是有一些差别的。

2. 面向用户,用户操作的提效,人效的释放

面向用户的价值,通过提升用户使用产品的效率和体验的方式,提升公司的人效。

对用户的价值比较理解,后台产品的用户体验,需要让用户能高效的处理业务,并且能满足多方数据协同、特殊化场景、大批量操作等情况。

提升用户效率是实际可以给业务带来可见的帮助的一个点,除了用户使用的爽之外,给用户提效就是帮公司提升了人效,节省了人力,尤其是针对一线的业务人员。

能被称作提效的产品需求范围很大,小到排序、批量操作、导出excel这类细节功能,大到流程重构、业务操作流转的自动化等大项目,只要是提升了人效,都可以称之为提效。

通常业务方很喜欢给产品提方便他们自己提效的小需求,哪里加个字段,哪里调下排序之类的,但产品经理不能陷入到他们提的这些小细节当中,而且也要关注更多的人,坐办公室的运营人员经常会提需求,一线业务人员不一定会给产品提需求,但他们的提效需求可能更重要。

提效的起点是用户线下实际的业务操作,因此提效的衡量标准也需要回归线下业务和人。

常见的方式有两种,第一种统计时间,将用户的使用时间量化,什么业务操作,哪个角色,X个人,目前花费X分钟/天,产品预计能提升X分钟,不同的业务城市、熟练度不同的人员,这个时间是否有不同。这个量化的时间不只是用户操作产品的时间,更确切的是用户处理业务的时间。具体时间根据实际线下的业务情况进行预估。

举个例子,某电商公司的物流配送业务,从供应商送货,到排线,现场装车调度,配送,货物清点,整个流程效率过低时间太长,影响履约时效。接下来需要分析每个环节,有哪些因素影响人效,比如供应商送货慢,因为给到供应商的送货单会慢30分钟;排线每次都要人工排一遍,耗时15分钟;现场对货需要通过人工制作的excel表,多出来额外做表的20分钟,等等。

针对这些问题输出产品方案,送货单自动推送给供应商,预计能提前10-20分钟送货;在线自动排线,并自动导出现场对货的表,预计省去这35分钟。其他环节也是同样的逻辑,最终将每个环节的解决方案,提效的时间,和开发成本,综合考虑。

第二种更加宏观一些,统计人,某个范围的业务需要X个人完成,或者说一个人能处理多少范围的业务。这个数据会涉及到公司的人员数量,是一个反应结果的数据,影响的因素会比较多,不限于产品功能的提升。

举个例子,某公司的管理业务,某站点当前业务管理人员和一线业务人员的比例为1:5,公司需要提升管理的人效,以节省公司管理人员的人力成本。

针对这一点,产品通过将更多一线业务在线管理,提供报表,提供管理建议等手段,让一个管理人员能更有余力的管理更多一线业务人员,提升业务人员的数量同时不需要再增加管理人员,通过后续管理人员和一线业务人员的比例是否低于1:5,可以观察产品的效果。

这些提升用户人效的后台产品都有一个前提,就是用户有没有使用你做的产品功能。如果不好用,或者用户习惯了之前老的方案导致不想用,那么这些个对业务提效的目标都无从谈起了。

有些时候新功能上线时用户确实不习惯,尤其是一些对线上产品感知不大、又比较忙的一线业务人员,推广和适应都需要时间,不过产品上还是得保证首先好用让用户愿意用,当用户习惯之后,再去看实际的效果。

3. 面向业务,业务运转的自动化,高效、准确

面向业务的价值,指的是通过业务的计算、匹配、流转规则,对业务从人工转化为自动化的过程。

对业务的价值是后台产品最直观、有效,也是更终极的价值。诸如业务流程的自动化,对订单、采购数量的预测,订单和履约之间的智能分配,异常状况的预警等,都属于后台产品对业务的价值。这里有些已经超出后台产品,属于策略产品的部分。

业务自动化的前提条件,是数据的在线和准确,也就是前面写到的面向管理要做的部分。因为没有准确的数据,通过数据价值去进行业务的自动匹配计算就无从谈起。所以针对业务的价值,通常是业务较为后期的目标。

一个业务还未成熟的公司,一些决策和预警的业务,一般都是人工执行为主,这个阶段的重点可能更多在于流程在线准确和用户提效的价值,当公司业务逐渐扩大成熟之后,因为自动化业务的准确率、匹配度等都高于人工,再逐步由系统自动化代替人工。

针对业务的衡量方式,直接从对应的具体业务指标入手,看这个指标是否有提升即可。这块相关的指标一般是比例、时间之类的,比如业务数据的准确率,履约完成率,流程的时效,等。

举个例子,某O2O公司的订单履约业务,存在由于超出履约时效,导致用户不满意、履约率降低的问题。其中一个问题,在订单采购环节如果出现库存缺货,会导致订单履约时间被拉长,现在需要提升缺货订单的履约时效。

原先的方案,只是定期提采购需求的时候进行采购,新的策略中,首先优化缺货的处理策略,缺货的商品先找周边的仓库调度,如果没有就直接提采购需求,通过减少从下单到采购中间等待的时间来加快履约时效。

这一点可以通过缺货订单的到货时效来验证。同时,通过对采购需求计算逻辑进行优化,让每个站点在预估采购需求量时候能够更加准确,减少缺货情况的发生。这一点可以从缺货订单的比例进行验证。

整体上,可以看缺货订单的订单履约率是否有提升。

从以上案例能看出来,很多处理方式实际上是业务策略,业务数据的指标表现的就是业务方案的效果。业务指标的影响因素不仅限于产品上的改动,业务上自己的策略、人员、能力等因素也会影响业务指标,而且影响的更大一些,指标本身业务方也会更加关注。

这个方面产品和业务是分不开的,产品方案和业务策略提升的是同一个大的指标,具体到每个项目,需要再进一步对指标进行分拆,尽可能减少指标的影响因素。实在分拆不了的,那只能视为产品和业务共同的影响,至于是产品主导还是业务主导,得看不同公司不同业务线。

这是3个价值方向,并不是具体产品功能,这几点之间是相辅相成的,不是分隔独立的。事实上不同的目标,很有可能都是同一个方案去解决。

比如,将某块在线下进行的业务,通过线上的自动化规则代替人工操作,那么同时起到了针对用户的提效,和针对业务提升准确度的价值。再比如,数据的在线精准,一方面起到了管理价值,一方面也作为业务自动化的数据基础。

尤其是基建,很多后台产品的需求都会涉及到一部分基建,常见的比如让某业务流程线上化替代人工、让某数据在线之类的,将这些基建项目往在线管理和用户提效方向靠,通常就能找到可以衡量的价值。

三、从指标拆解后台产品对公司的价值

以上这些后台产品的价值,可以用我们常用的两个词,提效和降本来概括。产品的最终目的都是为公司的盈利而服务,不管什么方式的提效和降本,都能往盈利这个大目标上去靠。

当我们做一个后台产品,如何找到适合且有用的指标,以及这个指标会如何影响到公司整体的目标,对公司的价值到底产生在哪,这个问题可以通过指标拆解去看。不同的业务部门,会有自己的核心指标作为考核的依据,具体到每个项目,再会拆分二级三级指标,找到一个适合评估项目结果的指标。

比如一个做交易的公司的指标拆解,利润之下是收入和成本。其中收入=订单量*客单价,订单量取决于流量、转化、履约、复购这几个因素。

后台产品在其中能发挥的作用,流量方面,通常是运营和市场带来的,产品的CRM和运营支撑系统可以帮助运营和市场人员提升流量的获取、转化之类的;履约即提升交易的履约率,包括时效、距离、库存、服务等各种影响履约的因素,比如前面提到的案例,提升商品缺货订单的履约率。

成本,大致可以分为原料、营销、售后、仓配、人力这几类。

原料和仓配属于供应链业务,后台产品在其中除了做到数据在线准确之外,也能起到业务上的降本,比如通过供应商评级帮助采购选择原料成本更低的供应商,通过采购数量计算降低库存损耗等等。

人力成本方向,是后台产品发挥比较大的地方,所有提升人效相关的产品,包括降低每人次的业务操作时间、提升每人次的业务范围或管理范围,都是对人力成本的提升。

整体上而言,后台产品无论对公司业务还是对用户,都有比较明确的价值,但有些类型的产品,收益还是相对难评估的。尽管如此,作为后台产品经理,还是要尽可能的去衡量产品对业务的收益,无论是对公司还是对用户,定量还是定性,尽可能找到比较合适的指标。

#专栏作家#

潘帕斯雄鹰,人人都是产品经理专栏作家,进击、踩坑中的产品狗一枚,关注互联网,写过小说,看过哲学。简书:潘帕斯雄鹰。

本文原创发布于人人都是产品经理。未经许可,禁止转载。

题图来自 Unsplash ,基于 CC0 协议。

给作者打赏,鼓励TA抓紧创作!
更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 回复