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

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

文章插图
二、运营层业务层面实现的是能力，而运营层实现的则是通过对业务层的管控，反哺业务层达成优质履约。优质是基于对战略指标的达成来说。比如说服饰市场中的快销品和高奢定制，快销品的履约注重迭代快、价格低，对品质的要求没有那么高。而高奢则恰恰相反。因为两者从战略层面来说本身就是不同的。
所以运营层的搭建是立足于业务，承接于战略的分解。这个模块主要需要包含这几个层面的能力：
1. 指标管理拆解流程中和战略相关的指标，将其固化为运营指标，比如以公司[毛利率]这个指标为例，它本身是一个综合的指标，很难直接从一个点或者某几个点去进行达成。下图是这个指标在仓库管理链路上的拆解：

文章插图
后续则可以通过对运营层指标（如坪效、人效等）的管理，间接的实现战略目标的达成。这一部分内容通常最后会被外化为数据看板。
2. 异常监控对于指标的监控大家应该都比较熟悉，所以这个段落我想说下对于系统行为的监控。
其实每个用户（包含内部用户和外部用户）行为在系统上的使用都会留下足迹，而每个行为其实都可以被定性为正常操作和异常操作。
很典型的就是淘宝的防刷单机制中对于异常订单的监控。
再比如之前在知乎上有看到，关于如何薅红包单车羊毛的贴子：骑行用户扫码打开红包车后，通过虚拟定位进行还车（这个行为非常不推荐哦）。这其实就是属于系统应监管的异常行为。
3. 系统建议运营层除了监控和现状的外露外，还应该具有指导性。在告诉用户现状的同时，指导用户如何提升以达到目的或者如何处理异常。
以仓内流程为例，用户都知道为了完成时效目标，应该把“好钢用在刀刃上”，那么哪里是刀刃（瓶颈）呢？光看当前的时效可能无法解决问题。但系统可以通过不同订单结构在不同工序所需的工时不同（比如单品单件的订单瓶颈通常在打包工位，多品多件订单的瓶颈通常在拣货工位），提前预测瓶颈工序，提示管理人员及时进行人员调动。
综上，运营层的整体回答了：我要管控什么行为，我要达到什么目标（现在做的怎么样了），我应该怎么达到这个目标。
总结我之所以将其分解为三个层面，是希望在产品的输出过程中，不要只专注于表面的功能，而是可以更深入的理解业务，让产品真正成为一个产品。三个层次的设计并不是指需要设计三个层次相互隔离的功能，而是在同一个功能/流程设计中考虑到三个层次。
梁宁老师关于ATM设计的讲解不知道大家之前有没有听过，如果让你设计ATM你会怎么设计呢？如果你的回答是围绕交互页面、怎么做提款、存款，那么说明你的设计还只停留在业务层（建议大家可以去听下，这里就不展开了）。
以上均基于笔者个人的工作经验和对产品的理解，主旨在于分享设计思路，没有深入的针对某类产品进行具体的设计分解。可能还存在不到位或不妥帖之处，如果大家有想要沟通交流或指正之处欢迎后台留言，共同交流进度。
感谢阅读。
#专栏作家#麋鹿产品，公众号：麋鹿产品手册，人人都是产品经理专栏作家。专注供应链挖掘提升，热爱生活，热爱产品。
本文原创发布于人人都是产品经理。未经许可，禁止转载。
题图来自Unsplash，基于CCO协议。