笔者从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.明确业务规则
爱盈利-运营小咖秀(www.aiyingli.com) 始终坚持研究分享移动互联网App运营推广经验、策略、全案、渠道等纯干货知识内容；是广大App运营从业者的知识启蒙、成长指导、进阶学习的集聚平台；
想了解更多移动互联网干货知识，请关注微信公众号运营小咖秀（ID: yunyingshow）
【转载说明】 若上述素材出现侵权，请及时联系我们删除及进行处理：8088013@qq.com
