某天Boss招呼老文去他办公室，坐下来，点上一根香烟之后便开始最近工作的近况的闲聊。相信很多看官都熟悉这个画面，唯一不同的可能是你们只有故事没有烟。
聊着聊着，Boss突然话锋一转，最近我有个这样的想法，业务是这样的：现在物流供应链相对还比较落后，咱们也很有机会，如果结合金融进行辅助，那不就可以……听明白了么？你看看如何设计一下，下周我过来的时候给我一个具体的方案。
接下来，老文便会根据自己的理解重述一下Boss刚刚的想法，必要时会白板上写写画画。经过可能长达几个小时的沟通后，Boss也觉得差不多了，便说方案尽快给出来哈，还抽根烟么？云云~~然后离开办公室脑袋一片空白。
根据这个话题背景，Boss是想设计一款物流+供应链金融系统，那咱们梳理一下，一个完整的B端产品设计要经过哪些步骤？先来看看总体设计架构：
一、设计前：分解Boss的想法1.业务现状梳理
我们首先要做的就是将Boss的想法结合行业现状去梳理清晰，整理出来一个大致的流程和方案，然后匹配到公司现有的业务中，哪个事业线的负责人更有经验和权威。通过请教他来了解现有行业中的操作方式及痛点等，如果有机会的话最好是自己亲身去体验需求场景中去。
如老文公司是做公路物流的，所以经常去到物流公司或集散中心的操作现场去和一线的用户和操作员去聊天和了解业务现状。
通过以上方式将会对现有的业务现状有个初步的了解，并且能够和实际的业务场景有所结合，形成草稿式的文档，不限于采用什么形式。这个也是基于我们不是很了解行业的时候采取的方式，假设本来就深入了解业务，那就直接进行梳理即可。
目的就是为了将需求贴合实际的业务，分析出来业务问题并整理基础的解决问题的思路，而不是仅凭自己的主观经验去理解，脱离了线下的实际业务，最终设计出来的产品将会是一座空中楼阁。
2.竞品分析&调研
B端产品设计时，不管是竞品分析还是市场调研，是具备一定难度的事情，因为有时候根本就找不到竞品，即便找到竞品想要获取测试账号也是很难的一件事情，实际的用户调研有可能是在饭桌上。
如何找到B端产品竞品我的经验如下：
通过以上的方式基本上能够完成竞品分析的工作，关键点在于如何提炼对于分析有用的信息。至于如何找到同行系统的测试账号、产品介绍等，那就需要各凭本事去套路了。
关于进行B端产品市场调研我的经验如下：
市场调研主要还是以线下拜访为主，亲临业务现场比听到的任何高谈阔论都有意义。其次，如果公司有条件，能够提供实操的环境，或者能够在用户岗位提供学习的机会，那这就是最好的市场调研方法。B端产品的调研对象分为两大块，第一个为管理层，第二个为员工层。因为有可能做决定的管理层并不一定是使用用户，所以和员工层的沟通也是至关重要的一个环节。他们也是特别重要的干系人，一定程度上决定了产品能够在客户处走多远。提前准备好业务问题，最好是有一定的层次和针对性，分不同的对象去了解，不同的业务角色需求、目的、痛点不同。最后，不管调研的效果如何，一定要输出调研报告，将收集的业务问题做一个优先级，明确用户痛点，为后续的产品方案设计和实施提供决策支持。
光是市场调研这个板块都是可以独立出来写很多内容的，如调研的流程、方法、报告总结等。
咱们产品设计过程中也不能忘记这一环节，另外作为产品经理只有经历过一线才会对业务有更深刻的理解，然后做出正确的决策。每多去一次一线，就能少拍一次脑袋，每少拍一次脑袋，就能多一分成功。
3.蓝图设计：商业模式
B端产品商业模式的设计是非常复杂的设计，涉及到的方式也比较多。落实到产品层面，就是我们常说的BRD文档。但是如果咱们是刚刚接触这个行业或者产品岗位，商业模式的设计基本可以忽略，毕竟设计好产品本身的业务逻辑才是重点。
一般的情况，B端产品的商业模式的建立也不是我们来做决定，我们也相对比较少接触，这里还需要根据产品运营的形式来决定盈利方式。
既然咱们上面做了竞品分析，竞品的盈利方式当然我们也是需要分析的。所以可以结合竞品分析报告及公司的现有业务模式给出一定的建议，将产品后续的蓝图提前规划，做到这个层面基本完成要求。
二、设计中：从不缺席的那个PPT
每次产品设计时，都会先写一个思路相对整体的PPT，可以让后面产品详细设计的时候少走很多弯路。目前我们部门的表现形式为PPT，其实使用什么文档类型并不重要，Word也可以，主要是要描述清楚下面的流程即可。
此PPT的意义：
将需求方的想法和需求做一个全面的整理，并且可以用于与需求方进行沟通，使其意见达成一致。可以减少资源浪费，如果深思熟虑后发现此需求并不成立，就不必要进入产品的详细设计阶段，更不需要浪费研发资源。可以作为产品详细设计阶段的蓝本，也可以作为工作安排的依据，可以以此分解工作任务给到产品团队成员。可以作为项目组认知此产品的基础文档，对产品整体性达成共识，防止技术方案设计时，不符合产品设计要求。此PPT通过之后，架构师即可开始工作，这样产品和技术则可以同步进行工作。可以作为项目管理的尚方宝剑，因为这个就是和Boss达成一致的相对详细的文档。如果后面Boss认为产品方向偏离，则可以对照此PPT。也可以作为和技术团队的参照物。最后，这个PPT也是后面写产品介绍PPT的原型，将会为后面的工作打下基础，所以事实上它从不缺席。
我将此部分内容分为两大部分，12个分点。第一部分为总体概要设计，包括01-07点；第二部分为模块详细设计，包含08-12点。
1.产品背景
以前从0至1设计产品时，我也对这块的内容存在疑惑，感觉产品背景的描述过于虚幻，不仅是现在PPT中需要描述，咱们的后续的需求文档中也需要。有时候都不知道怎么下笔，又不能直接把Boss的那个梦进行描述。直到现在稍微有那么一些感觉了，下面给各位看官提供一下我的思路。
大致可以分为四点：
产品定位的描述就涉及到产品设计的本身业务，定位的描述可多可少，多的描述会涉及到业务支持的范围、预期目标的详细描述、简要的业务架构、产品角色业务支持等。少的描述集中于产品在公司产品中的定位以及边界定义。
产品定位和产品背景的区别在于背景更多的还是行业背景、痛点描述，定位将是描述你设计此产品的整体性描述和概要总结，并且对产品功能边界、系统or模块边界进行定义。
经验总结，目前我们部门的做法是：
首先，先会做一个产品定位图，用来表述大致的业务以及和公司其他产品的连接。其次，将产品定位图进行解释，让文档阅读者能够清晰的认识产品定位，篇幅两页PPT基本搞定。
产品定位图：
3.角色说明
产品中的角色大致可以分为两类，业务角色和系统操作角色。系统操作角色设计在系统的权限管理中，可以灵活的赋予角色不同的权限和功能。
业务角色本身就存在于实际的业务过程中，他们被赋予了不同的工作场景和使命，当然和系统操作角色一样也有同时承担多个角色的主体存在。
经验总结，业务角色定义的用处：
业务角色虽然一开始就存在于业务过程中，但是把其映射到产品中来的时候也是需要进行一定包装，并且需要结合整体的业务流程进行不断的完善和修正。
因为最后系统操作角色将会参考业务角色进行设置。简要角色说明参考：
4.核心业务流程
相信在前面分析铺垫的基础上，梳理起来核心业务流程将不会是一件特别让人头疼的事情了。我们有了角色说明之后，根据实际的业务流程将他们通过一定的业务操作串联起来。这些业务操作一定是系统非常具有代表性的操作，并且角色相互之间是需要沟通和交流的（两次握手）。
经验总结，建议：
核心业务流程一定需要使用流程图来进行描述，纯文字性描述起来相对不会那么清晰，流程图辅以部分文字说明是相对比较好的实现方式。实现方式建议使用具有一定代表意义的图标，包括序号、箭头、颜色等进行区分，这样整个图不会显得很死板，因为这里还没有到详细流程图的设计。
业务流程图：
5.核心资金（支付）流程
这部分的内容，并不是所有的B端产品都是必须的，比如常见的OA系统、客服系统等并不具备这些功能，因为类似这样的产品只是为了解决企业内部的某些效率问题。并且里面的角色并不参与业务交易。
但是，作为一款商业型的B端产品，大部分都会涉及到资金流程，但是不一定会涉及支付流程。这里咱们要区分开的是，资金流程可以理解为一个记账的过程，比如财务模块、应收应付管理等功能，这些功能不一定会触发真实的资金支付流程。
支付流程又是另外一个独立的流程和体系上的内容，支付流程的设计也关系到公司是否已经存在支付系统，还有产品支付渠道的选择等，B端产品的支付和C端的支付差别相当大，因为涉及资金的限制也不同。比如老文的公司使用了很多银企直连接口，这些渠道也将会影响产品后续的设计，所以一开始最好是有所准备。
发票流程的设计紧跟资金流程设计，整体原则就是谁收钱谁开票。所以，发票的内容基本上都是和资金流程同步出现的。
但是发票流程的设计并非如此简单，特别是遇到复杂的业务流程的时候。还有关于发票模块和流程的设计，往往容易被忽略，因为大多数情况发票都是一个线下的动作，实际上，对于一个商业型的B端产品，并且产品中拥有多个企业主体，又涉及到资金结算等业务，那必然会出现发票流程。
设计阶段尽早让财务部的同事参与进来，可以少走很多弯路，特别是很多对公司本身的财务规则不熟悉的小萌新。尽早确定系统的运营公司主体，因为不同的公司主体营业范围不一样，可开的发票也不一样。如果没有对应的公司主体，则需要提前去准备，防止出现系统上线后无运营主体的情况。发票流程的设计需要符合公司财务部的习惯和要求，这里具备一定的专业性，不能一味的只考虑产品交互层面的实现。7.系统应用架构：功能模块
之前老文也说过，B端的产品经理如果具备技术背景将会是优势之一，如果是有技术知识的话，这块的内容写起来将会更加得心应手。这个也叫做业务架构图，也是产品功能模块的雏形，将核心的功能模块进行定位。这个和产品定位不同的是站的角度和层面不一样。
业务架构更多的是考虑产品内部功能模块之间的定义和关系，以及与公司其他系统的关联关系和布局。刚刚开始可能会觉得用处不大，但是这里还是蕴含着一系列的设计思考，这也会受到公司本身的技术架构影响，比如我们常说的SaaS、中台思想等。
如果经验不够，架构图画起来比较别扭，那就提前请教做的好的同事或者技术同事，不然换种方式实现。提前和CTO或者架构师进行沟通，不同的实现方式，所需的资源不一样，达到的效果也不一样，比如小程序和APP。好的系统应用架构应该得到技术团队的认可，也可以使产品能够达到预期的使用期限，所以不能为了实现而实现。这一步我认为是非必要步骤，也可以在后续的功能模块分解时做简要描述，将两者结合起来去实现。
业务架构图：
本文由@老文原创发布于人人都是产品经理，未经作者许可，禁止转载。