产品|履约产品系统分解分解|系统|流程|产品经理|履约

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

文章插图
履约是指交易双方在确认交易（达成约定）后，服务提供方按约定为用户提供服务的过程；也就是说从用户确认订单后，到服务完成的整个过程就是履约。
在《俞军产品方法论》中提到，产品经理找到有利可图的用户价值，固化成产品的形式，实现了企业和用户价值的交换。而履约过程的本质，就是这个交换过程的外化。
基于交易的多样性，履约过程也有多种不同的表现形式：为乘客提供一次打车服务（送达目的地）；一次外卖配送是一次履约；甚至于用于打开王者荣耀玩一把游戏，游戏中为用户刺激的体验、游戏奖励等都可以被称之为履约。
履约产品的分层我将履约产品的搭建划分成3个层级，分别是：业务层，运营层，战略层。

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

【 产品|履约产品系统分解】履约产品整体的设计是自上而下的，而实现则是自下而上的。
因此好的履约产品经理在微观上需要深入流程，宏观上需要了解战略。本文主要从产品层面分解业务层和运营层的内容。

文章插图
一、业务层业务层，或者可以称之为应用层，的核心在于实现履约流程（基础要求）。以当下比较热门的社群团购为例，下图是一个简化的抽象流程：

文章插图
业务层的搭建过程中需要注意以下几点：
1. 一切基于实操基于上面的抽象流程，我们可以对这个业务有个大致的了解。但是在实际系统设计时，需要和执行层的同学进行详细的细节沟通，包括每一个操作的细节处理。
不要用固有的经验去设计一个看似相同的系统（以下面的经验教训为证）。
2. 场景的复用这一点恰恰与上面相反，要在不同里面找相同，考验产品经理的抽象思维。将流程抽象为系统能力，哪些能力是当前已有的可以复用的，通过搭积木的方式来搭建流程。
在功能下细分拓展点（配置点）来区分流程，将流程设计得更加灵活。
一个比较形象的例子就是iphone，其实组装的流程都是一样的，所以可以共用一条流水线，其区别只在于厂家可以支持不同的配置以满足不同型号的产出。
3. 注意异常和逆向流程业务描述流程一般是”第一步、第二步、第三步”。
而我们要切入的点是，如果第X步没有顺利发生怎么办，从这个点开始，我们就会聚焦于什么情况下第X步会有问题及怎么解决这个问题。（之前笔者在汽车行业的时候，称这种做法为FMEA, Failure Mode and Effects Analysis,失效模式与影响分析)。
抓住可能的异常点，提前评估对正向流程的影响，将“致命点”提前杀死在摇篮中。
经验教训：笔者之前所在的公司是做平台电商的，后来开始尝试社群团购。
对于电商来说，正常情况下是不允许拆卖的（除了有计划性的预售），所以最初系统设置的订单下发逻辑时会校验下游库存是否充足，如果库存不足，则会拦截订单并告警。
后来开始做社群团购后，因为采用的采购模式是以销定采，且前期无法保证供应商100%及时到货，所以会有部分商品缺货的情况，而当时做的合单策略是按照团长合单，所以导致一个团长下有100个子单，但是合单后，由于某个订单缺几件商品，无法下发团长订单到仓库（越大的订单越容易出现这个问题）。
等到仓库到货入库了，大订单下来了，仓库作业往往就来不及了(当时承诺用户是晚上9点前下单，次日10点送达）。
4. 分清优先级，辨别核心流程资源不足大概是产品经理最常听到的话之一了。因此也要求我们必须要识别关键需求的能力。因此在流程梳理过程中，也需要和业务方确认清楚每个功能点的价值和优先级。
特别是对于从0到1的项目，如果考虑全链路流程的支持，等万事俱备再开始推广，很可能已经差别人几个身位了。