与C端的产品不同，B端的业务调研复杂得多，而且是更重业务。如果是个普通水平的产品，怎么做好B端的业务调研呢？
业务调研或需求调研在产品经理工作中是较为核心的一环，并且能够在整个产品的工作流中起到承上启下的作用，B端产品由于与C端产品有有着本质的区别。
你如果是个普通水平的产品，那你或许更适合去做一些B端方面业务的产品经理，因为C端对产品经理能力上要求地更加高阶与抽象。
C端产品经理不仅能够抽象总结归纳出海量用户中核心关键的需求，找出当前产品业务中所遇到的各类问题，并且还要求你对需求和业务有足够的敏感度，能够靠自己的天赋或者能力发现业务或需求解决的核心点。
且由于不像B端那样有专业人士给你提供业务细节和专业认知或者标准化的业务工作作业流程，那在实际工作中就要求C端产品经理能够自己靠自己的经验和积累去设计商业模式，产品模式，能够有靠自己去决策业务和设计出一套针对当前阶段最优的业务解决方案的业务抽象建模能力。
另外说个题外话，C端产品在能力方面也比B端产品要求更加全面，包括数据导向能力、精细化运营能力、各类营销模式的设计即trick的设计能力，这要求你能够有自己的一套数据分析的底层能力，包括掌握数据埋点的方法、各类数据模型能力、利用方法和模型解决问题的能力以及建立合理的数据指标体系指导牵引业务团队更好工作的能力，精细化运营包括用户画像、用户分群、用户触达、用户转化和全生命周期运营用户的能力，防流失、提留存。trick包括砍价、拼团以及当下垂直电商产品中的众筹、鉴定、拍卖、寄卖、求购、回收等等。
B端在业务调研中以业务为导向，这就对产品经理的需求分析能力的要求有所降低，因为我可能不像C端产品经理那样既要懂商业，能够去架构自身产品一整套的商业模型与业务模式，并且还能够通过行业分析、竞品分析以及数据分析各个维度对自己产品进行准确定位。
作为B端的产品经理，只要能够更好的理解业务，掌握正确的调研业务的方法，结合业务方对自己的业务的专业认知，分析总结出核心关键的业务提升点，比如更智能化自动化的一体化解决方案，业务流程的标准化，员工工作作业流程的标准化，业务效率的提升点、风险控制的关键解决方案就能够足以做好B端产品的业务调研。
但是由于产品经理不独立自主地抽象和总结业务，不去设计商业模式与业务模式，常常会导致产品经理即使在某个B端产品的行业领域内深耕许多年，仍然只是做着跟以前一样的工作，这就导致B端产品更容易沦为工具人，即变成分析业务产出方案的工具，思考问题的维度与高度都有所欠缺，并且B端不注重商业模式和数据，一般的B端产品经理也很难在公司为公司产生多么大的业绩，导致B端领域没有什么出名的产品经理，这也佐证了普通人适合做B端这个观念，它并不要求你有C端产品那样的需求敏感度，商业的敏锐洞察以及独立抽象业务搭建业务架构的能力，但它也没办法让你能够在产品经理领域做到一个天花板级别的程度。
既然已经知道B端产品基于自身的业务特性，以业务驱动而非产品需求驱动，我们怎么去跟专业的业务团队去协作，知道和了解业务并设计出满足专业团队的业务方案呢，首先就是要了解整个业务大的宏观方面，从全链路业务流程着手去认知到自身业务布局板块、业务特性、业务关键路径。
在B端业务调研之前，产品经理必须自身对相关业务有一定的基础认知能力。由于每个行业下的业务和产品差异是巨大的导致在拿到新的业务调研工作前，产品经理并不一定有比较完备的准备，有可能在你刚加入公司就被赶鸭子上架去跟客户沟通需求了，但是实际工作中即使没有完全的前期准备，我们也是要把跟客户的每一次沟通都当做是业务调研的过程，不断积累业务知识直至成为业务领域的专家，我们不需要实际做业务，但一定要对业务方传达自己是懂业务的，证明自身在业务方面的专业度。
以宏观了解B端产品的业务初步情况为起点，以最终产出调研报告为终点，我们可以以结果为导向去做B端业务调研。为了能够总结和输出一个结构化的调研报告，用于向领导层汇报，验证自己的业务认知和指导自己做业务落地及产品决策，并将业务需求拆解成指导开发团队开发实施系统的业务需求清单，我们可以将业务调研氛围以下几个步骤：
在业务调研前产品经理要做好提前的准备工作以明确调研的主要方向，规避调研可能遇到的误区或防止踩坑。
大多数情况下，业务方的工作产品经理是没有干过的，那么在准备阶段我们可以利用自身的分析能力以及相应材料建立初步的业务认知。
比如通过行业报告了解B端业务的宏观背景、业务结构、涉及上下游产业等、通过公司财报了解业务的商业模式和业务宏观数据，通过过往的一些资料文档了解业务的主要流程和业务涉及的具体内容等，这样可以提帮助我们建立系统化、体系化、结构化的认知。
但这样做的不足之处是由于没有实际进行调研的实操，导致自身认知不够全面，具体的业务细节不能做到很好的衔接，相应细节点难免有遗漏之处。
前期调研要明确的核心点包括业务角色确定、业务现状了解、业务场景认知。
业务角色是从宏观方面划分业务方的层级、一般有高管层、经营层（管理层）、决策层、他们在公司里分别做着不同的工作，相应岗位下的角色对业务的目标、关注点、业务产品能够达到的预期也有所不同。
业务现状，通过了解业务现状，能够让产品经理与业务人员做到同频，不仅能够让业务人员对产品经理的专业度上有认可，知道你产品经理是懂业务的，还能让你有前期初步的规划，能够在调研时直奔主题明确重点，提高调研的效率和效果。
业务场景，产品经理通过对业务场景有一个大概的认知之后，就能够对业务全局的规划有一个宏观的把控，知道业务目前遇到的问题关键点在什么地方，能够了解客户群体和画像、了解产品或业务的渠道、知道当前业务的模式和当前业务系统对业务方工作是否有提升，能够分析出当前业务需要解决的问题一个大致方向以及要优化整个业务价值链的哪些环节。
明确调研目标是在拿到业务需求之后首先要确定的事情，不能直接上手去做，要对整个调研的目的进行聚焦，花更少的时间解决更重要的问题。这样才能保证不浪费自己的精力、节省业务方的时间、更有效的完成业务调研。
然后通过了解业务方的核心痛点分析问题背后的原因，因为在实际工作中我们并不是总能解决问题，而是更多地去解决问题出现的原因，这样就釜底抽薪从根本上杜绝了问题的产生，达到业务方的预期，通过更优的解决方案实现其业务目标。
调研对象就是调研信息来源方，掌握不同信息来源于不同的角色，就能因地制宜地将业务拆分和架构。通常公司的岗位职级就决定了业务调研的不同层级。在公司里业务方分为战略层、管理层、执行层
针对各个层级最好选取2个典型用户，选取的时候既要选优秀的，也要有普通的，这样才能既有代表性，相应结论能够代表公司绝大部分现状，也具有一定的普适性，不会造成重复调研和时间的浪费。
调研提纲依据选取的调研对象的不同，我们可以粗略根据高管、中层管理和执行者分别给出3份不同的提纲。那么针对提纲的内容，涵盖“问事实”、“问期望”、“问影响”、“问原因”四个方面
访谈的规划可以高到低进行调研，这样从顶层和全局到不断向下拆解，能够一个全局和完整的思路，也能避免陷入细节无法解决核心矛盾，排除掉业务方可能提供的一些干扰信息。
需要注意的是在调研规划阶段阶段先要产出调研的提纲提升调研访谈的效果和效率。提前进行访谈时间的安排尤其是针对公司高层的访谈，由于其时间安排比较满工作忙碌，在进行调研前的邀约阶段一定要多次确认访谈时间。
调研实施阶段，就是按照前期的调研计划去进行分角色的调研。需要注意访谈中的一些注意事项。
1）重点围绕访谈大纲
2）及时针对业务关键问题进行补充和追问
3）注意积累过重访谈技巧
4）及时将关键内容总结落在文字上
5）保持与访谈对象的联络
6）及时备份录音、并将内容整理到调研报告中
业务调研目标的明确
针对前期对业务现状的理解总结出业务背景的概况，抽象总结出业务问题可以通过搭建什么系统或改进业务/工作方式来解决业务问题。完成业务方需求的总结和整理
业务调研方式选择
针对不同层级调研的对象的深度访谈，明确当前业务发展的方向、现状、痛点、收集与归纳总结成核心业务需求。
业务调研报告落地
明确核心客户定位，思考产品给客户提供的独特价值，产品服务的需求归纳，协调资源与构建能力来搭建产品，付费模式以及业务标准化或者业务拓新方面的考虑。
了解了B端业务调研的意义和具体的操作的流程。我们通过一个权限体系方案的搭建来实战性地分析一个B端的业务需求的调研如何拆解与落地。
公司业务现状了解：公司原有CRM系统由于涉及的业务量较少并没有针对各个部门搭建一整套的权限设计方案。随着使用系统的部门和客户数量的激增，导致现有的权限不再能满足各类用户的使用需求。
先通过调研确定权限分配的核心问题，提供更加完善的权限体系解决权限隔离、权限互斥、权限配置和等级划分的问题。发现权限设置背后的各类问题并解决其产生的原因。针对核心业务问题分析整理出业务需求清单，提供产品侧权限体系优化的解决方案。
选择掌握信息的调研对象。选择公司战略层即公司高管人员来调研，由于部门组织架构比较复杂且涉及部门较多，所以针对战略层典型用户的选取，仅选取公司高管中对组织架构非常了解的运营VP来对公司各个部门涉及的权限进行总结，提高业务调研访谈的效率，节省调研不同部门人员的时间。
针对中层管理侧的调研，选取权限问题频发且业务在整个公司中较为关键的销售部与SCRM部门来进行专项调研，能够代表公司绝大多数部门的权限使用现状，选取两名管理层人员，1名为销售经理、1名为运营经理，得出比较普适性的调研结论。
考虑到执行层即一线员工的业务调研情况，社群运营选2人，分别选取业绩比较优异的一名社群运营和业绩做的一般的一名社群运营。基层销售员选2人，分别选取业绩比较优异的一名销售和业绩做的较差的一名社销售人员。
选择调研对象之后，分别为公司高层、中层管理、执行层的的人员提供3份业务调研提纲。提纲包括内容分别为：面向对象、调研目的、调研问题、问题类型。
先从公司高层运营VP进行战略侧的调研，抓主要矛盾解决核心问题。再自上而下调研销售经理与运营经理，看高层与中层业务目标认知是否一致，如果不一致，深挖其中的原因并给出相应的问题解决的思路，再针对销售和运营人员进行调研，从中梳理出具体的权限操作的需求清单，指导后续权限体系方案的产品设计，优化解决当前权限存在的核心问题。
确定访谈时间，制定业务调研的问题提纲，提前将提纲发送给业务调研方各个人员。
调研访谈的邀约，针对高管运营VP进行多次时间确认，确保其有时间来进行参与调研，高管访谈主要为宏观和方向性的方面，压缩其调研时间。
围绕访谈大纲对各个角色进行访谈调研，对关键问题及时补充与追问，将涉及到的关键问题记录并将访谈的内容录音，访谈之后整理记录到调研报告之中。
通过业务调研，总结出权限体系目前有以下问题：
1）定位核心用户
公司内部各部门的同事，包括查看公司业绩和做关键业务审批的公司高层，管理员工工作流程的各部分管理层，通过系统完成各类操作的执行层人员。
2）业务优化点确定
权限按部门进行合理细分并隔离，各司其职提高工作效率。
权限互斥方面优化，防止权限滥用。
针对审批、审核以及公司机密数据方面建立完善的申请与多级审批体系。
权限分级设置，管理员角色可针对本部门、下属进行权限复用继承和进行权限组分级设计。
提供权限操作的详细使用手册。
采用统一模型RBAC3对权限进行设计。
提供角色分层，角色分级与继承关系，避免出现下级比上级权限大的情况。提供互斥约束，包括各种限制定义角色间的互斥关系，一个员工不会同时操作互斥的功能。
设计成竖形结构。为方便展示将组织架构、部门和员工放在同一页面，各业务线按照自身所负责的业务分配不同的页面进行权限操作。
从模块、页面、菜单（一二三级菜单）、按钮（多个按钮）四个层级，建立一整套的给系统权限体系用于勾选（支持多选与取消勾选），设置不同的角色，给角色赋予权限，将用户与角色关联，用户所关联的角色就能拥有该角色下所有的权限。
拥有功能权限下的页面权限的前提下才具备该页面下数据权限。数据权限除了超级管理员和分部（区域）管理员拥有默认其对应的所有数据权限之外，支持按照组织架构数分配数据权限。
系统组织结构分为：总公司、分部（区域）、县市、部门四级架构。
数据权限生效范围分为：本人、本人以及下属，本部门，本部门以及其下属，全部数据权限支持共享（快速配置账号并复用）：支持账号、部门、角色间复用共享
1）管理员角色：设置超级管理员角色、分部（区域）管理员角色。
超管默认拥有系统所有模块、页面、功能按钮以及数据增删改查的所有权限。
分部管理员默认拥有系统某一分部（区域）所有模块、页面、功能按钮以及数据增删改查的所有权限。
2）权限初始化：默认角色。
系统所有用户在新建时均默认分配一个通用的“默认角色”，该角色由管理员配置基本的员工权限功能，主要为仪表盘（系统首页）和我的工作台两个部分。
3）权限操作日志
不同用户在不同时间进行了数据修改和删除、导出等相应敏感操作，针对功能权限和数据权限两个方面操作日志记录，该模块与系统操作日志打通。
4）权限管理：
包括组织结构设置和各业务线权限的个性化分配管理，对应的管理员角色对权限进行创建和对不同角色分配权限，权限设置包括功能权限与数据权限两个方面。
组织架构：
权限管理：
模块权限：
数据权限：
本文由 @关山大道产品企划师 原创发布于人人都是产品经理。未经作者许可，禁止转载。
题图来自Unsplash，基于CC0协议。
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。