履约产品系统分解

0 评论 1437 浏览 5 收藏 12 分钟

编辑导读:本文作者从业务层、运营层和战略层这三个产品层级出发,梳理总结了履约产品系统的架构和核心功能,并对搭建过程中需要注意的几点问题进行了系统分析,希望通过此文能够加深你对履约系统的认识。

履约是指交易双方在确认交易(达成约定)后,服务提供方按约定为用户提供服务的过程;也就是说从用户确认订单后,到服务完成的整个过程就是履约。

在《俞军产品方法论》中提到,产品经理找到有利可图的用户价值,固化成产品的形式,实现了企业和用户价值的交换。而履约过程的本质,就是这个交换过程的外化。

基于交易的多样性,履约过程也有多种不同的表现形式:为乘客提供一次打车服务(送达目的地);一次外卖配送是一次履约;甚至于用于打开王者荣耀玩一把游戏,游戏中为用户刺激的体验、游戏奖励等都可以被称之为履约。

履约产品的分层

我将履约产品的搭建划分成3个层级,分别是:业务层,运营层,战略层。

  • 战略层:企业战略目标(或者说产品目标)决定了用户群体、决定了企业要交换的用户价值,从而决定了履约的外化形式(业务层)和运营规范。
  • 运营层:是基于战略的拆解,实现对业务层的管理、监控、异常处理,基于运营层可以对业务层进行优化。
  • 业务层:与用户对接,直接面向用户和企业,承载履约流程的执行,业务层是履约系统的基层。

履约产品整体的设计是自上而下的,而实现则是自下而上的。

因此好的履约产品经理在微观上需要深入流程,宏观上需要了解战略。本文主要从产品层面分解业务层和运营层的内容。

一、业务层

业务层,或者可以称之为应用层,的核心在于实现履约流程(基础要求)。以当下比较热门的社群团购为例,下图是一个简化的抽象流程:

业务层的搭建过程中需要注意以下几点:

1. 一切基于实操

基于上面的抽象流程,我们可以对这个业务有个大致的了解。但是在实际系统设计时,需要和执行层的同学进行详细的细节沟通,包括每一个操作的细节处理。

不要用固有的经验去设计一个看似相同的系统(以下面的经验教训为证)。

2. 场景的复用

这一点恰恰与上面相反,要在不同里面找相同,考验产品经理的抽象思维。将流程抽象为系统能力,哪些能力是当前已有的可以复用的,通过搭积木的方式来搭建流程。

在功能下细分拓展点(配置点)来区分流程,将流程设计得更加灵活。

一个比较形象的例子就是iphone,其实组装的流程都是一样的,所以可以共用一条流水线,其区别只在于厂家可以支持不同的配置以满足不同型号的产出。

3. 注意异常和逆向流程

业务描述流程一般是”第一步、第二步、第三步”。

而我们要切入的点是,如果第X步没有顺利发生怎么办,从这个点开始,我们就会聚焦于什么情况下第X步会有问题及怎么解决这个问题。(之前笔者在汽车行业的时候,称这种做法为FMEA, Failure Mode and Effects Analysis,失效模式与影响分析)。

抓住可能的异常点,提前评估对正向流程的影响,将“致命点”提前杀死在摇篮中。

经验教训:笔者之前所在的公司是做平台电商的,后来开始尝试社群团购。

对于电商来说,正常情况下是不允许拆卖的(除了有计划性的预售),所以最初系统设置的订单下发逻辑时会校验下游库存是否充足,如果库存不足,则会拦截订单并告警。

后来开始做社群团购后,因为采用的采购模式是以销定采,且前期无法保证供应商100%及时到货,所以会有部分商品缺货的情况,而当时做的合单策略是按照团长合单,所以导致一个团长下有100个子单,但是合单后,由于某个订单缺几件商品,无法下发团长订单到仓库(越大的订单越容易出现这个问题)。

等到仓库到货入库了,大订单下来了,仓库作业往往就来不及了(当时承诺用户是晚上9点前下单,次日10点送达)。

4. 分清优先级,辨别核心流程

资源不足大概是产品经理最常听到的话之一了。因此也要求我们必须要识别关键需求的能力。因此在流程梳理过程中,也需要和业务方确认清楚每个功能点的价值和优先级。

特别是对于从0到1的项目,如果考虑全链路流程的支持,等万事俱备再开始推广,很可能已经差别人几个身位了。

以上面社区团购为例,在前期发展体量小的时候,资源应该先优先保证面向用户的功能,仓内和排线是可以先由人工和纸质单据来代替的。

二、运营层

业务层面实现的是能力,而运营层实现的则是通过对业务层的管控,反哺业务层达成优质履约。优质是基于对战略指标的达成来说。比如说服饰市场中的快销品和高奢定制,快销品的履约注重迭代快、价格低,对品质的要求没有那么高。而高奢则恰恰相反。因为两者从战略层面来说本身就是不同的。

所以运营层的搭建是立足于业务,承接于战略的分解。这个模块主要需要包含这几个层面的能力:

1. 指标管理

拆解流程中和战略相关的指标,将其固化为运营指标,比如以公司[毛利率]这个指标为例,它本身是一个综合的指标,很难直接从一个点或者某几个点去进行达成。下图是这个指标在仓库管理链路上的拆解:

后续则可以通过对运营层指标(如坪效、人效等)的管理,间接的实现战略目标的达成。这一部分内容通常最后会被外化为数据看板。

2. 异常监控

对于指标的监控大家应该都比较熟悉,所以这个段落我想说下对于系统行为的监控。

其实每个用户(包含内部用户和外部用户)行为在系统上的使用都会留下足迹,而每个行为其实都可以被定性为正常操作和异常操作。

很典型的就是淘宝的防刷单机制中对于异常订单的监控。

再比如之前在知乎上有看到,关于如何薅红包单车羊毛的贴子:骑行用户扫码打开红包车后,通过虚拟定位进行还车(这个行为非常不推荐哦)。这其实就是属于系统应监管的异常行为。

3. 系统建议

运营层除了监控和现状的外露外,还应该具有指导性。在告诉用户现状的同时,指导用户如何提升以达到目的或者如何处理异常。

以仓内流程为例,用户都知道为了完成时效目标,应该把“好钢用在刀刃上”,那么哪里是刀刃(瓶颈)呢?光看当前的时效可能无法解决问题。但系统可以通过不同订单结构在不同工序所需的工时不同(比如单品单件的订单瓶颈通常在打包工位,多品多件订单的瓶颈通常在拣货工位),提前预测瓶颈工序,提示管理人员及时进行人员调动。

综上,运营层的整体回答了:我要管控什么行为,我要达到什么目标(现在做的怎么样了),我应该怎么达到这个目标。

总结

我之所以将其分解为三个层面,是希望在产品的输出过程中,不要只专注于表面的功能,而是可以更深入的理解业务,让产品真正成为一个产品。三个层次的设计并不是指需要设计三个层次相互隔离的功能,而是在同一个功能/流程设计中考虑到三个层次。

梁宁老师关于ATM设计的讲解不知道大家之前有没有听过,如果让你设计ATM你会怎么设计呢?如果你的回答是围绕交互页面、怎么做提款、存款,那么说明你的设计还只停留在业务层(建议大家可以去听下,这里就不展开了)。

以上均基于笔者个人的工作经验和对产品的理解,主旨在于分享设计思路,没有深入的针对某类产品进行具体的设计分解。可能还存在不到位或不妥帖之处,如果大家有想要沟通交流或指正之处欢迎后台留言,共同交流进度。

感谢阅读。

#专栏作家#

麋鹿产品,公众号:麋鹿产品手册,人人都是产品经理专栏作家。专注供应链挖掘提升,热爱生活,热爱产品。

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

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

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