履约产品系统分解
履约是指交易双方在确认交易（达成约定）后，服务提供方按约定为用户提供服务的过程；也就是说从用户确认订单后，到服务完成的整个过程就是履约。
在《俞军产品方法论》中提到，产品经理找到有利可图的用户价值，固化成产品的形式，实现了企业和用户价值的交换。而履约过程的本质，就是这个交换过程的外化。
基于交易的多样性，履约过程也有多种不同的表现形式：为乘客提供一次打车服务（送达目的地）；一次外卖配送是一次履约；甚至于用于打开王者荣耀玩一把游戏，游戏中为用户刺激的体验、游戏奖励等都可以被称之为履约。
履约产品的分层
我将履约产品的搭建划分成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你会怎么设计呢？如果你的回答是围绕交互页面、怎么做提款、存款，那么说明你的设计还只停留在业务层（建议大家可以去听下，这里就不展开了）。
以上均基于笔者个人的工作经验和对产品的理解，主旨在于分享设计思路，没有深入的针对某类产品进行具体的设计分解。可能还存在不到位或不妥帖之处，如果大家有想要沟通交流或指正之处欢迎后台留言，共同交流进度。
感谢阅读。
#作者#
麋鹿产品，公众号：麋鹿产品手册。专注供应链挖掘提升，热爱生活，热爱产品。
版权声明
本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！
