笔者从B端产品和C端产品在产品设计上的差异性出发，结合案例，对B端产品如何进行需求分析和设计进行了探讨。

随着云计算、AI、教育、智能制造和产业互联网的兴起，这些新技术、新方案首先从B端企业开始渗透，因此市场上对B端产品经理的岗位需求大增。

但目前行业内对产品需求的方法论，大部分是针对C端产品的，所以本篇文章的主题来谈谈如何对B端产品进行需求分析和设计。

既然要谈“B端产品”的需求分析，那么首先我们要搞清楚一个问题：B端产品和C端产品在产品设计的本质差异性在哪里？

C端产品设计的逻辑在于“轻流程、重体验”，以抖音这种短视频工具为例，只有2个简单的流程：发布视频和观看视频。

并且把观看视频的流程简化到了极致—没有流程，在强大的推荐算法机制下，用户无需思考要观看什么，只需要向下滑屏，就可以实现不中断的沉浸式观看体验。

所以C端产品侧重的是用户的感受和体验，在产品设计时，精心对页面和交互进行打磨，大到优化版面结构，小到改变一个按钮的大小、颜色及位置，都可能会极大影响用户的行为，对产品的运营数据产生深刻的影响。

而B端产品呢？ 其产品设计的逻辑是“重流程规则、轻体验”，一个母婴电商公司的老板，购买一套电商ERP系统的目的是什么呢？

是让员工操作的体验更舒服、更放松？一定不是！

他在意的是怎么把手忙脚乱、错误百出的客服从20个人降到2个人，从而降低紧张的资金压力；他在意的是怎么把拣货流流程由人拿着单子满仓库跑，改为流水线式自动化作业，从而降低出错率；他在意的是把财务从每个月末抱着一堆单据通宵做账解脱出来，改为系统自动对账，从而让企业的财务数据清晰、透明，为经营决策提供准确、可信的依据。

所以，B端产品最终的目的是通过互联网IT技术对企业业务流程进行重构、优化、从而降低成本、提高效率。

从上面可以看出，C端产品经理像是一个感性的匠人，在产品设计时，带入同理心、想象力、简化用户心智，在产品设计时精心打磨用户感受和体验。

而B端产品经理更像是一个理性而严谨的“业务专家”，他们具备强大的系统性逻辑思维，富有理性的对企业业务进行全面梳理和诊断，并给出合理有效的解决方案。

由于B端产品业务流程复杂、功能庞大、用户角色众多，所以对B端产品经理的需求分析能力，提出了很高的要求。

但我在实际工作中发现，目前互联网公司对复杂B端产品具有完整驾驭能力的并不多见，甚至包括工作5年10年以上的产品经理，输出的产品规划文档，常常给人以“只见树木，不见森林”的印象。

真正具有复杂B端产品需求分析能力的是资深的程序员、架构师、但他们写出来的东西、技术术语过多、复杂、晦涩难懂。

既然B端产品业务流程复杂、功能庞大、用户角色众多，那么它一定是一个“系统性的工作”，必然得有一套“系统性的方法论”来去支撑B端产品的业务需求分析。

以肯尼迪发起的“阿波罗”登月工程为例，耗资数百亿美金，历时11年，动员了整个的国家力量。

这种“系统性的工程”，你不能上来就讨论登月舱结构，火箭推力设计的细节问题。你得有“工程性思想”去支撑，把问题分解3大步骤:“双子座计划”、绕月、登月，再层层分解，逐步细化，论证，才有可能完成这种系统性任务。

那么B端产品需求分析和设计，有哪些“系统性思想”来支撑呢？

一、确保理解背景

这是很多新手产品会犯的一个致命错误。例如和客户交流完后，客户需要一个ERP产品，结果发现，客户需要的只是一个订单打印小工具。

所以客户眼中的”ERP”，一定不是你眼中的”ERP”。

任何一个B端产品和解决方案，一定是在某个特定的阶段满足企业的某种价值，这种价值可以很小，也可以放的很大，这是一种平衡和取舍，所以产品经理一定要搞清楚这个产品需求产生的背景是什么？

你的客户目前是什么现状？组织的复杂度？使用你的产品是为了解决什么问题？是业务转型的问题，还是流程改革和优化的问题？

另外从某种程度上来讲，企业经营也是管理者个人意志的体现，boss对产品或解决方案的诉求是为了达成什么样的目的？你确保了你理解他的诉求？

对背景的理解和解读，一定是你产品文档的开篇部分。

二、搞清经营模式

在理解背景的基础上，我们需要搞清楚企业的经营模式，经营模式决定了产品分析和设计的框架。

很多产品没有把业务理解清楚的根本点在于，没有充分理解企业的经营模式，经营模式理解不清楚，会出现严重的系统设计偏差。

特别是一些复杂的平台级产品，例如钢铁B2B交易平台，涉及到行业生态上下游厂商、大大小小的贸易商、终端客户、仓储公司、物流公司、金融企业等众多的参与方，每个参与方又有不同的职能部门需要在平台作业。

很难想象没有搞清楚经营模式，产品需求分析和设计如何进行。

但搞清楚经营模式，也不是非常困难。任何再复杂的业态，一定有一条主干经营流程，这条主干流程简单的来说，就是以下几个问题？

卖什么？怎么卖？挣什么钱？

买什么：这个企业经营什么产品或服务？有多少种？差异性在哪里？

怎么卖：产品或服务的销售流程是什么样的？是通过互联网，还是通过线下渠道？如果是，这些渠道怎么管理？当前存在哪些问题……

挣什么钱：企业是如何盈利的？是靠销售产品或服务吗？还是羊毛出在猪身上,狗来买单？

一旦你把这条主线梳理清楚，就可以清晰的知道企业的经营模型，有哪些供应商、客户、合作伙伴等各种参与方，为接下来的需求分析，打下坚实的基础。

经营模式可以用一张图表来说明，它是你产品设计的蓝图。通常需要用不同的线条把信息流、物流、资金流标识清楚，来搞清楚企业是如何运作的。

下图说明了一个家电售后平台的经营模式运作图。

三、析出业务角色

到这里，才真正从商业分析部分进入到产品分析和设计部分。

如何把需求从商业概念转化为产品分析和设计概念，我目前看到最具有系统性的是UML，其设计思想，贯穿了从需求分析到系统设计的整个过程。

但UML本身是软件工程的产物，概念繁多：图、依赖、泛化等各种概念。本身太过于庞大、复杂、笨重，并且难以学习。

不过其“系统性工程”思想可以值得我们借鉴学习。

为什么，产品分析和设计的第一步是分析出业务角色？而不是画流程图（这是很多人的做法）

因为业务角色是产品需求的源头，所有的产品需求一定来自于全部业务角色需求的集合，B端产品的复杂度决定了必须从业务角色分析着手，才不会出现遗漏和偏差。

并且B端产品越复杂、业务参与方越多、你会发现这种分析越有价值。

在上一步搞清楚经营模式的基础上，会会对该经营模式涉及到的所有业务角色有了个完整的了解，接下来的工作，就是把业务角色分离出来。

下图说明了一个B2B平台的业务角色图。

四、推导出业务用例

有了业务角色后，我们可以推导出业务用例（也即业务角色需求）。

UML的业务用例图，最大的好处是用一张图可以把整个系统的需求以全局的方式，生动、完整、清晰的表达出来。

有了这种图，我们可以很方便的和业务、开发、测试方便的去沟通需求，对系统需求有个整体的认识。

推导出业务用例的过程，我们可以通过以核心业务角色为重点，交叉验证思维来快速构建整个业务用例。

例如下图的B2B交易平台，我们只需要以该平台最重要的业务角色采购商为切入点，再来交叉验证：采购商需要采购下单，必然需要供应商发布商品、供应商发布商品必然需要平台监管人员去审核和管理……这样基本可以搞清楚各种业务角色80%的需求。

五、细化出业务流程

再接下来，我们需要把重要的业务需求，细化为业务流程。

业务流程可以用UML的活动图来展示，在to B复杂的业务场景中，我们往往使用的是跨泳道流程图，例如一个取消订单的业务流程，涉及到ERP、客服、财务不同的业务角色。

这样在构建业务流程的过程中，我们对系统设计如何实现，也有了一个完整的概念。

另外，业务流程图的最最要的一个原则是线条不能交叉，无论流程如何复杂，保证线条不要交叉，很多新手犯的错误，就是把流程图画的纵横交织像一个蜘蛛网，非常难以看懂。

六、绘制可视化页面原型

至此，我们通过对业务角色分析、不同角色的业务需求分析，核心业务需求的业务流程确认，我们实现了从商业概念到业务概念的建立。

接下来，我们需要把上述业务需求转化为产品系统的设计，这是一个更加细致的工作，我们最熟悉的Axure工具就正式上场了。

当然从“抽象的业务需求”到“具象的系统需求”，也存在一个巨大的鸿沟，这个需要参考同类产品的设计思想，从中吸取精华，并结合互联网设计，做一定程度的创新。

例如，采购商反馈说，通过购物车下单太麻烦了，需要一个“批量下单”功能，你单凭想象是难理解这个需求的。

最好的办法是到用户的工作现场，观察和感受下他平时工作是如何处理订单的。

等你到了现场，你会发现和2C用户的下单场景截然不同：用户的桌面是堆积如山的文档、忙碌的电话接入，长达几页的订单要等待录入……

你会发现B端产品设计的首要目的是快速、准确、无误的帮助用户提高工作效率，节约用户的时间，其他都是耍流氓。

所以你需要去大量观摩和学习一些B端成熟软件的设计逻辑，再结合一些移动端的特性，例如GPS定位、拍照识别、语音，去构思一些创新的设计，可以帮助用户大大提高工作效率。

七、其他补充

产品设计过程中，非常重要的一点是，明确业务规则。

在一个项目团队中，由于背景、工作经验、领悟能力各不相同，如果业务规则不明确，同一个概念，每个人的理解不同，会造成鸡同鸭讲，争执不下，浪费大量时间。

所以一些核心、重点、复杂的业务规则，产品经理需要举出详实的例子来，把各种情况一一枚举出来，并进行阐述。

例如在互联网交易平台，涉及到商品、SPU、SKU这3个概念，产品经理可能对这些概念很熟，但业务方、开发人员不一定对这些概念很清楚。

如果在页面上只是简单的描述为“点击此按钮，将此SKU加入购物车”，会引发大量的困惑和争议，我看到过一个产品经理的需求会，为此争执和讨论了半个小时。

理想的做法，把这些重要的概念和规则，用数据实例呈现出来，并指出他们之间的结构关系，这样在讲解业务时，确保所有人的理解是一致的。

再例如互联网交易平台的交易流程，包括各种正向流程、逆向退换货流程所有的单据状态，这些单据状态互相交叉，互相影响。他们是系统设计的骨架和脉络，如果不定义清楚他们之间的互动关系，会造成严重的混乱和缺陷。

总结

整体上来说，分为三个过程，商业分析—业务分析—系统设计。

商业分析：1.确保理解背景 2.搞清经营模式

业务分析：3.析出业务角色 4.推导出业务用例 5.细化业务流程

系统设计：6.绘制页面原型 7.明确业务规则

#专栏作家#

陈文中，微信公众号：秀肌肉的码蚁，人人都是产品经理专栏作家。

本文原创发布于人人都是产品经理。未经许可，禁止转载。

题图来自Unsplash，基于CC0协议