编辑导读：数字化是许多企业未来的发展趋势，但是如何实现数字化，这是产品经理需要解决的问题。本文作者根据自己主导的一个实体企业全链路数字化开发项目，总结了方案设计、团队、项目管理三部分的经验，与你分享。
今年年中，笔者主导一个实体企业全链路数字化开发项目。项目功能涵盖了9大模块，+功能项，需求文档将近4万字，共页。作为整个项目的负责人，针对项目中业务需求沟通，产品设计方案，团队配合和整体项目管理，总结了些许实战实践经验，分享给大家。
如果你是B端产品经理或项目经理，欢迎一起讨论交流；如果你是传统行业CIO或老板，有计划或者也在做数字化升级项目，多了解数字化项目，或许对您也是有帮助的。
项目背景：
我们为国内知名家居品牌提供用户全链路业务数字化业务定制开发。目的是将用户的所有触点，从接触，销售跟进，踢单成交以及交付后全部的服务和业务流程实现数字化，以此提升用户体验，提升全链路业务效率。
一、关于方案设计
1.穷尽拆解低耦合：复杂逻辑的处理原则
对于复杂的产品项目，从业务流程梳理-抽象设计方案-逻辑流程梳理-交互细节设计-部分底层框架的设计，对产品经理来说是非常考验大脑的思考力，(当然逻辑能力是基础)。
尤其是链路较长，涉及条件较多的逻辑，在梳理方案时候，需要做到”持续思考力“（虽然这听上去像是一句废话）。但是我相信有很多产品经理都会遇到有方案瓶颈但是中断的情况。
中断思考等于前面做的思考全部作废，还需要再重新梳理逻辑，低效率且低效果。如何减少这种情况呢？可以试试穷尽拆解法（有点类似金字塔模型的MECY分析法）。
在做复杂逻辑梳理+需要做设计方案决策时，有时候困住你的可能是设计决策，或者是逻辑本身。可能你想直接找到答案，但是此时效率最高的方案是将所有的情况全部可视化梳理出来，将所有有关联的维度因素梳理出来，交叉确定每个逻辑，或许解决方案会自然出现。
举个例子，我们有一个业务流程有9个关键业务节点；每个节点有多个条件判断并且有正负逻辑的流转；同时这9个业务节点有三种不同类型的业务主体。
在处理这种方案时，如果不独立拆解到最小颗粒度，很容易遗漏逻辑或设计出耦合的方案。对方案的灵活性带来很大的影响。高内聚低耦合，是系统设计的基本原则。
我们的方案是，把全部的逻辑（哪怕有重复的流程）用流程图的形式全部可视化展示出来，整个逻辑一下明朗起来。
2.设计工具：服务蓝图
服务蓝图是服务设计师常用的工具，在数字化项目，涉及到多端交互且有关联的流程时，非常适合确定主业务的服务流程；确定服务流程后，再深入到交互，逻辑，以及架构设计。
用户旅程地图是用户体验设计经常用到的设计工具，服务蓝图是服务设计领域常用的设计工具。我将二者做了简单的合并，以用户和一线人员的交互为主线，找到服务流程中的设计关键的点，针对关键触点，围绕”用户体验和”销售效率提供解决方案。
3.设计陷阱：客户提供解决方案还是需求？
警惕方案设计陷阱：用户调研获取需求过程中，始终理性分辨：客户提供的到底是解决方案还是需求？（很多客户都喜欢给解决方案）同时设计师要警惕大脑中的“第一自然方案”，而是通过用户的表达了解他的需求场景是什么？他的核心诉求是什么？如何能满足？不断深入分析寻求最合适的方案。
B端产品经理和c端产品的工作流和能力要求有些差别，但是对业务调研和需求了解的过程中，我认为都是一致的。充分的了解客户的最终诉求，用专业的解决方案满足。
我们的整个项目围绕销售数字化，用户体验数字化，用户服务数字化“来进行。在销售数字化过程中，我们为销售提供了一个专门服务客户的小程序。当时在探讨提升销售效率的方案时，销售提到了一个场景，希望我们做一个微商城小程序，这样每个商品都可以直接购买。
这个客户的用户购买模型属于购买客单价较高（平均2万元），购买决策周期较久（大概在2周-3个月不等），在和销售人员沟通的过程中，他们提到，前过用户的产品购买路径可视化的功能很好，但是希望在最后踢单和成交阶段也可以在小程序内完成，所以希望可以把这个小程序做成一个微商城小程序。
其实这个方案和我的第一直觉方案很契合，在考虑解决方案的时候，也自然的顺着这个思路在深入设计方案。但是在深入设计场景时，隐隐感觉哪里不对。
首先我意识到，如果我按照客户的建议做成一个简单粗暴的微商城小程序，那么针对购买需要做很多完整的链路功能才能形成闭环，因为社区零售等行业的购买模型和运营模型与他们完全不同；另外我突然意识到，用户提出的并不是需求，而是解决方案，我们需要继续深挖，了解用户本后的需求本质到底是什么。
方案卡壳，可以进行用户访谈，寻找购买的关键决策因素；与一线使用人员进行访谈，寻找业务流程痛点；
此时可以通过调研后，梳理出服务蓝图，用户服务蓝图，以用户为中心，将服务业务全链路可视化展示，有助于设计方案。（关于用户服务体验蓝图有多好用以及如何使用，后面会专门找一篇文章来写。）
通过用户服务旅程图+服务蓝图工具，和销售人员一起，将用户接触后的流程梳理出来，解决方案豁然开朗。
因为客户成交的特殊性，用户的购买决策影响因素有两个，一个是花色（客户是家居产品），另一个是价格。而在家居行业，一般踢单的形式有两种，一种的膨胀优惠券，一种是膨胀定金。
在导购的销售流程中，如何和用户发起沟通，如何推动抓到了这两个关键点，我们一起确定了功能简单，闭环链路短，以及灵活满足需求的功能。
我们并没有简单做一个连锁微商城的小程序，而是为销售在智能导购功能的基础上，提供了收订金，以及一对一推送优惠券的功能。并且提供了商品卡片，可以灵活的配置商品卡片，以及用户的操作路径可视化，并实时给销售发通知，收取的订金还能直接转化为后续订单中的预售款。收取订金的金额由销售主导，并且支持设置付款后实际抵扣的金额。
用这种形式，最大自由度的满足了销售踢单和锁客的最后一步。而这种解决方案也非常满意。
整个方案的开发成本很低，满足的场景足够灵活。而如果一开始根据销售的建议，或者根据直觉方案做一个商城小程序，需要做很多额外的功能才能满足自由灵活的销售流程。
4.利其器：好用的工具和表格
我们提供给技术人员的文档是PRD+交互图，PRD文档中很好用的工具有几种：
关于角色权限表格针对特定身份的人拥有不同的操作权限。用表格的形式，开发同学在实现时候，可以很清晰记录技术方案；列表状态-操作表格后台系统列表的管理页面非常多；对于复杂的列表，状态对应操作最好的表述方式也是以表格的形式展示。针对每一个操作需要再逐一说明流程；业务流程图业务流程图是帮助开发同学整体了解工作流，处理好判断条件和对应条件的处理方式，可以更好的理解项目业务，提高开发效率。
5.细节至上：需求管理中需要注意的TIPS
1）冗余还是关联？
B端产品设计时，很多数据库字段是技术同学设计数据库时非常关心的部分。多个数据库表存在时，有时候技术会直接利用关联表进行数据查询。但是对一些记录型的功能页面内。数据需要冗余记录，不能实时连表查询。这个细节需要标清楚。
常见的冗余数据，例如订单信息，用户改了手机号，或者商品后续改了名称，订单内的信息不会实时更新；结算信息，不会因为商品改了价格而实时更改结算数据等。
关联数据例如用户的头像，如果用户更换了头像我们在会员的
转载请注明：http://www.0431gb208.com/sjszlff/5151.html
