第09期：B端产品经理怎么拆解复杂业务
1 b端产品经理怎么拆解复杂业务？
1.1 明确定义：拆解复杂业务需要明确哪些关键定义？
（1 ）定义关键角色
拆解业务首先要弄清楚哪些人会参与解决问题。解决一个问题往往需要完成多个任务，每一个任务都会由一个或多个人参与。找到那些执行相同任务的人，把他们定义为一个角色。比如餐厅点餐，顾客负责点餐，服务员负责确认菜单，勤杂工负责准备食材，厨师负责做菜。这些角色各自的任务都不相同。有一点需要特别说明，一个任务的参与人也可能是“系统”。比如服务员确认菜单后，通知厨师和勤杂工可以由系统替代。
（2 ）识别关键业务节点
解决一个问题需要执行很多任务，但并非所有的任务都是关键业务节点。关键任务节点有两个特征：一是能够推进业务往下进行，二是推动业务在不同角色间流转。比如厨师在做菜时会执行很多个操作。配菜、炒菜、调味、摆盘……但这些步骤都是“做菜”。虽然厨师做了很多事情，但在餐厅的业务流程里只有“做菜”是关键业务节点。再比如后台系统常见的录入用户信息。昵称、性别、城市的填写都是需要执行的任务，但完成其中单个信息的填写并不能推动业务往下进行。在系统层面可以把这些任务抽象为一个关键业务节点——填写用户信息。不同角色间的流转，审批流程是很好的例子。比如在钉钉上提交一个采购工单，审批者需要对提交的金额和采购的物品进行核对，但这些不会在系统层面体现，只有“通过”或“拒绝”这类推动业务在不同角色间流转的任务才会被定义为关键业务节点。
（3）定义业务规则与业务流程
前面我们已经将业务的关键角色和关键业务节点梳理清楚，但这只是业务梳理的热身运动。接着还需要弄清楚人和人、事和事、人和事的联系。“联系”体现在两个方面：一是不同角色执行任务的顺序，二是任务执行时需要遵循的规则。业务梳理的最终产出物就是业务规则与业务流程。依旧以餐厅点餐为例，做菜时盐不能放太多、火候不能太过、分量不能太少，这些都是厨师在执行任务时需要遵循的规则。如果不遵循规则，最终的结果是业务停在做菜这个环节无法继续往下推进。同时做菜一定是在服务员确认好菜单后才会进行，这是任务执行的顺序。假设先做菜后确认菜单，就会导致之前进行的任务变得无效以及任务的重复。以上两个例子说明了梳理清楚人与事的重要性，梳理有误最终导致的结果就是业务的停滞与业务的周期变长。
1.2 流程梳理：如何做好业务流程梳理？
（1）搞清楚流程目标
先确定流程的目标是什么？从上往下一般流程分为战略性流程、运营性流程、支撑性流程，每个类型的流程肩负的使命都不一样，也就是要清楚这个流程是要完成什么或解决什么问题，才能识别流程的关键环节。不同类型流程参与的部门、岗位也不一样，流程梳理时也要紧密围绕这个目标，辨识是否为核心流程，还是支持性的流程，识别梳理的先后主次，也就是把主线先理出来。
（2）基于组织机构的流程先行
流程梳理工作往往从大往小，从粗往细，基于组织机构的流程是基础，也是非常重要费时的一步，跨部门的协调工作量非常大也很难。这个流程梳理过程主要要解决的就是企业内部各部门或企业间分工合理的问题，避免无人干活，或者权责利划分不清晰。如果你所负责的项目是企业从0-1的项目，那么这个企业的组织架构也是需要你在流程梳理完后给出建议的。机构是信息系统的主数据之一，影响系统流程、系统权限管理，是底层设计。基于组织机构的流程梳理过程中主要有以下几点要注意：
- 不要被企业已有的部门职责所左右
很多中小型甚至大型企业，部门间的职责划分本身划分的不合理或者不清晰，那么在梳理机构间流程时就会发现，不知道这个职能该给哪个部门合适。这种情况下，我们应当基于责权利去仔细分析，网上、同行的经验就可以借鉴，必要时候公司的内审部门是可以发挥较为重要的作用的，内审就是使公司各项工作合法化，合理化就得召集几个业务部门开会讨论了。甚至有的时候企业确实缺少某个必要的部门，这种情况下就只能找个尽量合法合理的部门来承担这缺失部门的职责了，如果谈不下来，就要找boss来指派。
- 职责规划要符合内审要求
内审常常强调的一点就是不能自说自话，自导自演，具体是指什么呢？就是需要跨部门协作的业务，不能自己说了就算了，比如运营部门决定要改良一个生产物料，不能自己制定了方案自己批完给老板审批就行了，必须要经过精益部门、采购部门、财务部门等审批。所以如果这种情况下流程设置不对，老板直接审批了，完了之后精益说无法落地，采购说要定制，成本翻一倍，结果要么夭折，要么强行上了之后效果适得其反。
- 内外部组织职责要合理
企业业务难免会与外部合作伙伴产生交互合作，所以流程要完整也必须包含此部分，系统可能还要为外部合作伙伴设计专门的功能，此时非常要注意双方的界限在哪，不要不是一家人非要当成一家人，业务部门往往出于本部门成本的考虑，想把更多的工作往外推，但是实际在梳理流程的过程中发现有些工作推给别人有风险的，双方合作时权责利也很不清晰，从系统设计层面来说是非常不合理的。那么此时就要坚持自己的意见，了解到业务的痛点之后，找别的办法解决，同时将弊端讲清楚。这个时候，还要注意的是你的沟通对象，业务负责人难以沟通的时候（往往是顾着自己那点小利益），就得拉上财务、内审这些相关的职能部门一起，一旦妥协，结果就是自己带着研发测试受苦不说，可能到后面还被人骂不专业。
（3）基于岗位的流程要清晰
基于机构的流程梳理完了之后，就是细化到基于岗位的流程，这里经常会遇到的问题是如何划分流程环节，如何定岗，这里分享几点主要方法：
- 先把显而易见的岗位定好
显而易见的岗位怎么定呢？参考行业其他企业的做法基于流程中关键的环节确定把专业性比较强的工作标出来这几种做法一般能把整个流程里面大部分常见的岗位和职能定好。
- 模糊地带流程岗位分析方法
基于活动产生的时间、空间和相互依赖性梳理流程环节以及确定是否需要独立的岗位来完成，不同时间或空间发生的活动，肯定要划分不同的流程环节，设立不同岗位来完成，若一个活动要依赖于另一个活动完结的结果才能进行，那么也是需要分开的。
- 一人多岗不代表一个岗位
这种问题在运营类流程中比较多，生产管理者基于成本考虑，对于部分不饱和的岗位人员就会安排多项工作，经验不足的产品经理在梳理流程的时候就会误解为这都是一个岗位。所以我常常会给小伙伴强调梳理岗位流程时不要看他现在是谁来做的，运营类流程一般不会按人定岗，因为流程标准化才利于运营效率。一般在较高层管理岗才会有因人定岗的做法。
（4）交接流程清晰
流程是一环扣一环的，一项工作需要多部门多岗位协同完成，有协同就一定会有争议，有共同利益就一定有利益分配，部门间或岗位间的交接环节往往会发生货物、资金、权利、责任的转移，所以流程上一定要明确什么情况下以什么形式由谁交接给谁，出异常如何判责，这样才不会在实际生产过程中要么出现三不管地带，要么一锅粥大家都连带责任，责任不清晰的情况就会有空子可钻。
（5）不要忘记异常流程&逆向流程
很多新入行的产品同学在梳理生产流程时，容易忽视or拒绝异常流程、和逆向流程，最终结果就会发现流程不闭环，异常无出口，如何去确定哪里会有异常or逆向流程呢？一般可以基于正常的正向流程基础上，挨个环节用类二叉树的分析法分析每个环节的输出都有哪几种可能的结果，每种结果的处理流程又是怎样的，是否能形成闭环。最重要的是，一定要在脑海中不停的告诫自己：一个完整的流程一定是包含正向、逆向、异常流程的。那句“没有做不到，只有想不到”的真理最是适合了。
（6）各环节的作业单据明确
生产过程中的作业单据就是在没有系统情况下的信息流媒介，也就可能是信息系统的单据类型，单据在作业流程中的流转就是信息流梳理的依据，作业单据的收集就比较简单了，把现场一切纸质文件收集了问清楚现场人员每份纸质文件的用途，在什么场景下使用，由哪些人确认。
（7）线下流程与线上流程区分梳理
业务流程这一步里面尽可能的还原线下流程，先不管线上的流程，待线下流程梳理完成再考虑线上如何支撑，否则就无法真实还原业务流程，因为你会受当前系统设计的影响。但是有些情况下是只有线上流程的，那么就要把这个环节做好标记，颜色或者不同的流程元素均可。
（8）业务中产生的财务流程要同步梳理
为什么财务流程也要在梳理业务流程时梳理呢，很多企业往往结算产品和业务产品分开，业务产品梳理业务流程不考虑结算流程，到最后才发现业务流程设计不合理再来改的代价很大。比如在快递业务环节里面涉及到快递员收费这样的环节，可能业务产品梳理到快递员把钱收回来即可。但是你会发现，不同的收费方式跟后面的财务处理流程是很耦合的：线上支付可能直接就到客户账户或者总部账户，但是如果是现金收费又涉及到缴费扣费一套流程，能走哪一套，不能走哪套又跟公司的财务政策有关，反过来影响业务流程。这种情况最好的方式就是在梳理业务流程时，标注好哪些财务节点，要组织财务人员、产品一起梳理确定。
（9）画流程图时尽可能不要有交叉回路
画流程图时要注意布局，尽量减少或者避免交叉回路的情况，不仅仅为了美观，更重要的是便于查看。交叉回路太多，还得花精力去找找连接线，容易找错。遇到有交叉的时候看看布局调整是否可以避免，不行就调整流程的粗细粒度，使用子流程的方式来解决。那么如何着手梳理一个流程呢，以下工作流程，我称之为“倒推法”流程：其实这个方法是紧密围绕流程的六大要素（顾客、价值、输入、输出、活动、活动间关系）来进行的一种分析方法。
1.3 拆解转化：如何将一个复杂的业务拆解转化成产品需求？
（1）理解名词
每个业务领域都有专有的业务名词，理解需求首先要搞清楚它涉及的专业术语。理解了相关术语，对这个需求相关的是一件什么样的事情，就有了一个初步的概念和认知。其中，了解的方法有两种：
- 向需求提出方询问：“XXX是什么意思？”
一般情况，业务人员会从这项业务是干嘛的来展开介绍，在这个介绍里，你可以得到的信息包括但不限于：
- 这个需求涉及的业务干系人（用户来源）；
- 这个需求的关键操作（功能拆分来源）；
- 这个需求的操作流程（流程来源）。
- 借助网络查询词语最通俗的释义
业务方的介绍可能是从他们专业的业务操作上进行的，这对一个新手来说，有可能还是过于晦涩和专业，为此你需要自己通过网络理解名词背后最通俗的含义，有可能会有多重解释，但你能辨别出哪一种解释是跟你相关的。这一节点应该输出“名词解释”列表。有了上面的理解，就大致知道了需求是干嘛的，那实际的业务中，是如何操作的呢？经过了什么样的流程节点呢？
（2）整理流程图
这个过程会经历两个阶段：
- 流程图草稿：
把理解到的都用流程图的方式表达出来，不分泳道、不纠结流程节点命名、也不用在意这个节点该不该画出来，画出最粗又是最细的流程图。粗是因为不分泳道很多节点也不合理，细是因为把听到的理解的都作为节点画出来。这时候不要画泳道图，因为对业务还模糊不清，抽象不出合理的泳道，如果一开始就设计泳道图，反而会花费较多时间和精力，但效果并不理想。
- 细化流程图：
经过对业务的不断调研，草稿图越来越完善越贴近真实业务，可以说对业务的整个流程有了宏观上全面的认识，那么就可以抽象泳道精细化节点来细化流程了。这时候输出的流程必须是泳道划分合理，流程节点粗细适宜，节点命名合乎业务的。但是这时候的流程有一点还是会有欠缺，异常流程和判断节点往往会缺失。但不要紧，后面的一步会帮助我们把这些细节都考虑清楚和全面。这一节点应该输出：
- 一是流程图草稿（只给自己最初理解业务用）；
- 二是业务流程图（用于向其他团队成员讲解和帮助他们理解业务）。
（3）整理状态迁移图
业务型产品在研发实现上很重要的一点是状态，状态控制着整个业务的流转和什么时候什么人该干什么事，不合理的状态划分使得代码的难度和体量呈指数增长（因为每多一个状态，程序在做任何一个判断的时候，都要去判断一遍它），因此状态的划分要足够合理和精细。
- 抽象对象：顾名思义，状态用于标注一个东西在不同条件下的情况，那么整理状态迁移前提是先要有对象。
在业务导向型的产品中，这个对象往往是业务操作过程中产生的各种单据。如：订单、退货单、收款单等。抽象对象的方法是：如果一件事情的完成需要不同的人在不同的节点做不同的操作才能完成，那么这个事情开始的时候就要生一条单据，后面的操作人都是对这条单据的操作。
- 抽象状态：处理对象的各个流程节点就是状态，但是在梳理流程图时，有些流程节点是辅助性的，它不影响整个业务的流转，这样的节点，不应该被抽象成状态。
比如：在小明吃饭的业务中，评价是一个很重要的流程，顾客是否有做评价也是我们会统计和关注的点，但评价状态并不属于核心业务流，顾客有没有评价跟就餐是否完成一点都不影响，因此评价的状态并不适合抽象成主状态。是否有评价给单据打个标记，能够方便查询和统计就OK了。在梳理状态迁移的时候，会发现流程里面没有考虑到各种不同的情况，从而反过来指导完善了流程图的设计。这一节点应该输出：各个对象的状态迁移图。
（4）整理场景和规则
有了流程图和状态图，就可以抽象出不同的业务场景。再根据场景逐个细化调研，从而获得业务规则，其中，业务规则细化到每个细节的长度、类型等等信息，是真正走到业务里面了。
- 抽象场景：对场景的抽象有两步，一是把流程图中的大节点抽象成一个场景，二是对大场景的不同情况进行细分，划分出小场景。
这样做的好处是：总的场景不至于那么多，理解查看和维护都方便，但又不会落下细节和特殊情况，保证产品设计的完整性。
- 细化规则：有了场景，有了场景下的不同情境，就可以针对各个情境下的业务限制规则进行梳理和调研了。
这一节点应输出：业务场景划分列表、业务细节规则列表，应该注意规则列表是对业务场景的细化和深入。
（5）需求输出
有了上面的流程、状态、场景、规则，对业务的理解已熟透到心，该着手设计原型、编写文档了。这里对文档的结构，我想应该包含这几部分：
- 名词解释：第一步已经准备了，整理下放进去
- 流程图：包括业务流程和状态图，第二、三步已经准备了，整理下放进去
- 按场景划分的章节安排：根据第四步的场景划分，每个场景作为一个章节，场景中不同情境作为小节，具体包含的内容大概有：
- 单据字段
- 单据状态
- 单据搜索
至此，一个业务就被一步步拆分和转换成了功能。不难发现：拆分过程中输出的文档，最后就是需求文档的每个组成部分，所以，拆分的过程也就是写文档的过程，拆分完了，PRD也就写完了。
1.4 复杂业务拆解工具有哪些？
（1）结构图
结构图，关键在于结构化的拆解，要通过需求方法论、场景化的需求分类，将该产品设计分解成对应的结构层次中以功能模块为类别（产品常用的脑图/思维导图，也是结构图），结构化更加清晰，也方便查漏补缺。 在产品梳理具体场景中，我们通常分为功能/信息结构图（产品结构图=功能结构图+信息结构图）
产品功能结构图：以功能模块为类别，介绍模块下其各功能组成的图表。专注在产品功能模块的逐级延展，如微信底部的微信、通讯录、发现、我 四个模块，然后逐级展开罗列子页面功能。图例如下产品信息结构图：脱离产品实际页面，将信息进行结构化梳理。专注在产品不同类型的信息，逐级延展，罗列信息字段；如当一个人写简历的时候，大致包括姓名，性别，联系方式，工作单位、时间、职位，毕业院校，毕业时间等，但是一一罗列就会十分繁杂，所有我们会将其梳理成几个分组，包括基本信息、工作经历、教育经历。。。这就是对“一个人”的结构化信息描述。而信息结构图就是将业务中的对象按上述方式进行梳理。图例如下怎么画?产品结构图并无画图规范，我认为需要想３个问题，功能放在哪个位置，涉及到多少个页面？页面中拥有什么元素或者功能点？从这三个问题来思考，把我们的理解的结构给做出来就可以了，上图我用的Xmind思维导图工具。
（2）流程图
流程图的作用是帮助我们清晰的认识过程，正确的认识相关方/组织资源，确定调查界限。并且是有通用规范的，主要规范有图形规范和逻辑规范图形基础规范和要素：画这种图形时呢，我们遵循一些图形规范，我们叫流程图元素定义，流程图是符号化的图形语言，比如开始和结束用圆角表示等如下
逻辑规范基本要素：
流程图五个要素：角色、活动、协助关系、分支、产出物。
角色：业务中相关方，通常需要用泳道来分隔不同角色，也就是涉及到的系统/角色有哪些？。活动：业务角色做的具体每件事情，也就是每一步流程，也就是业务流程需要进行哪些活动/动作？。协助关系：协作关系包括并行、顺序、异步等等，这里主要是形容不同活动之间的发生顺序，也就是系统之间是如何进行这些活动的？。分支：流程图中的分叉，通常由判断产生。产出物：通常指的是文档或者数据表等。图的画法：抛开简易主线流程图，介绍两种常用的流程图展示形式：泳道图：产品经理最常用也是最简单的流程图展现形式，常常被用于描绘完整的业务流程和简单的产品流程，日常工作中常用多泳道图来构建整个的业务流程。通过这个如下这个泳道图，可以清楚的看到在业务的过程中，四个不同角色在申请GPS的不同阶段可以做出的全部选择和应对，从而形成整体的流程闭环。时序图：需要多个系统参与的产品流程，那么多泳道图会显得不够直观。那么针对于这种情况，更推荐使用的是时序图，时序图本来就是用作专门描述产品流程的一种专门的流程图形式，能够清晰的展现出在产品中复杂的前后模块之间的关联关系，整体的数据流走向，各个模块在不同流程中所应该承担的工作以及各种判断过程，当产品经理能够准确的使用时序图来展示产品流程时候，意味着这个产品。经理的技术能力已经差不多过关了，可以和大部分的研发无障碍的battle
图的说法：
将流程图按照描述内容的维度进行切分，分为业务流程图，功能流程图，页面流程图。呈现效果根据不同画法呈现结果差不多就不放图了，（上述泳道或时序图是不同画法，这个是不同说法，且说法多于市场流传，UML中并没有这些说法概念，这种归类并不严谨，边界也并不固定，但架不住行内外都用，肯定需要懂）
任务/功能流程图——描写系统或模块内部的任务/功能流向的图表（比如登陆功能、添加购物车功能等等） 页面流程图——具体到了网站、系统、产品功能设计的时候，表现页面之间的流转关系——用户通过什么操作进了什么页面及后续的操作及页面。相比功能流程图，它把系统呈现的更体系了，到了页面的层级，通过页面流程图甚至可准确评估整个产品需要多少张页面了。 业务流程图——业务关系，作业顺序和管理信息流向的图表，大白话就是按顺序描述某一事项执行流程的图形化展示形式，描述业务流程的时候，业务流程的活动之间有严格的先后顺序限定（流程），业务流程里活动的内容、方式、责任等也都必须有明确的安排和界定（角色），除了上述的逻辑规范，还有个简单小技巧去校验流程是否考虑完整（课本学过的故事六要素：时间地点人物、起因经过结果）。
流程图绘制建议：
- 关于业务流程图的颗粒度，以所在的团队对于业务的熟悉程度为判断依据，如果都已经比较熟悉业务了，基于把事情讲清楚的目的，那么流程图的颗粒度就可以粗一些，如果是一个新业务，大家都不熟悉，那么在流程图就需要更多细节，然后尽量保持整体颗粒度一致性。
- 当业务比较复杂时，业务流程图就尽量的简洁，比如不重要的一些子流程，就可以另外画一个子流程图进行关联补充说明。
（3）架构图
企业架构分为业务架构、应用架构、技术架构。其中业务架构是战略，后两个是战术装备，归属IT，具体架构的内容后续企业架构内容会做详解，这次以讲图为主，本文均以业务架构（又叫产品架构）作为作图案例。对产品架构最直观的感受是，产品架构是一个由框框组成的架构图，类似于下图一样实际上，产品架构是产品经理用来表达自己产品设计机制的图，一种表达业务层级和关系的工具，设计的核心在于多维度的结构化分层。它将产品功能落地为信息化、模块化、层次清晰的可视化架构，并通过不同分层的交互关系、功能模块的组合、数据和信息的流转，来传递产品的业务流程、商业模式和设计思路，一般是在复杂的产品或者规划初期出现，用于呈现产品的大致规划。作用就是：将复杂的业务逻辑简单化，降低理解难度，在复杂项目开始前画产品架构，这样可以避免就不断改需求、推翻之前的计划重新规划等低效工作的情况。产品架构图规范：思考产品架构是一个体系化、流程化的思考过程，它总共区分为四个层面。第一层面：层面范围，在范围层面主要思考一个产品主要涉及哪些系统，比如支付体系作为一个产品，可以由上图四个系统组成，通过对范围的思考，从而界定产品是什么不是什么的问题，从而可以界定思考产品架构的思考范围。第二层面：在确定了组成产品架构的系统有哪些之后，我们需要进一步思考每个系统的组成。先不要思考具体功能和技术是什么，而是对系统进行分层。比如我们经常听到系统由业务层、数据层、表现层组成。对系统分层的思考实际上是系统组成部分的分类，比如技术相关的部分组合成为技术层，业务相关的部分组合成为业务层，数据部分相关部分组成数据层。分层的意义在于每一层由不同人员负责，比如业务层是由产品经理负责，技术层就由技术架构师负责。
第三层面：将系统分层之后，需要对系统进一步的研究，系统是具体由哪些功能模块组成，在这个层面需要明确每个系统模块之间如何通过不同的数据进行连接 第四层面：在思考完成框架图之后，就要对每个模块进行进一步的拆解，这个层面的拆解主要是从流程上进行深入的思考。通过对产品流程的思考来思考具体的产品是怎样使用和运行的。
如何画？步骤：
画业务架构图实际上就是对业务的一种收集、提炼、拆解、归纳、分类的一个过程，可以分为三个步骤： 1.功能穷举聚类:将业务流程图中每个节点下所有的页面、功能或处理机制以模块化的形式功能矩阵，然后通过业务的边界来归类，比如一个内容电商产品，内容运营就存在三个不同的端的业务：官网、公众号、营销触达媒介，其中官网产品，可以如下模块功能穷举 2.横向体现：将同一范围或产品功能放在一个横向层级中，在同一个层级中，有哪些独立模块，可以代表一个完整的产品或是同类型的业务聚合。如图3.纵向体现：架构层级的关系，明确不同产品或系统之间的边界逻辑，下层更抽象，上层更具体，比如下层为上层服务，或者提供能力支撑。如图通过这种方式，一份清晰的模块功能边界 功能做到标准化、互相独立，上下游产品功能边界清晰，架构分层明确合理的产品架构图就做好了，产品架构图的绘制并不复杂，关键在于实际工作中的运用,看似是一张简单的图，其实背后蕴含着巨大的复杂，这部分复杂被前置到了思考层面。 流程/结构/架构图使用总结：
- 用来表达操作流程，用流程图。
- 用来表达每个模块或页面有什么功能，用结构图。
- 用来表达底层设计和边界，表达功能之间的关系，用架构图
推荐工具：
- processon（在线-简单快速）：注册登陆即可免费，部分功能付费，是我工作来自己和同事画流程图最常用的工具了。同时支持在线协作，多人同时协作调整编辑，而且上手容易,上述的图基本也是用这个软件花的（无广）。
- Visio（老员工了，规范）：微软推出的一款流程图绘制工具，它有很多并且很强大组件库，正式的泳道图、流程图等推荐visio（不支持mac电脑）。
- Omnigraffle（规范，美观）：Mac下没有Visio很多人就用这个，支持外部插件。
- 其他非专业工具根据场景（PPT、Axure等）：说不上对比，部分特殊场景要求，或者个人习惯会用这些工具去操作画图，顺手就好。
- xmind（脑图-结构图）：拓展思维和梳理结构是绝对口碑老牌软件，不过没有网页版，不能在线制作比较遗憾。
进阶推荐书籍：《UML大战需求分析》该模块只推一本书，一部分是因为有上面的理论，通过实践练习（选一个自己喜欢的还算成功的APP或者从工作中实践）足够满足我们的使用了。产品在出这些图的时候，最基本和重要的事情讲清楚，复杂对讲清楚这件事并无好处，而产品的重点价值在于后续会讲的对企业架构的理解。还有一部分就是更为细致的规范及图标专业性，在我们对研发沟通时是有必要的，内容繁杂我们可以从这本书中去学习（如UML用例图等都是我们可以了解的概念）。参考文献：中台产品经理02：产品经理如何用一套方法搞定复杂业务拆解？ https://www.woshipm.com/pmd/5805026.html如何拆解复杂业务流程？https://www.woshipm.com/pd/4157700.html如何将一个复杂的业务，从头拆解转化成产品需求？https://www.woshipm.com/pmd/1047270.htmlB端产品如何做好业务流程梳理？https://baijiahao.baidu.com/s?id=1648731882191905212&wfr=spider&for=pcB端产品经理：如何进行业务分析？https://www.woshipm.com/pmd/3984875.html10个步骤，拆解实用的B端产品工作流 https://www.sohu.com/a/394598564_114819用好流程图，轻松化解复杂的B端业务流程梳理https://www.woshipm.com/www.woshipm.com/pd/5562452.html/comment-page-1
B端产品链路拆解法，专解复杂问题https://baijiahao.baidu.com/s?id=1743914382492667831&wfr=spider&for=pc 1.1三种图-流程/结构/架构图，搞懂产品经理的业务梳理和展示https://mp.weixin.qq.com/s/QJysyJbSNPu-aGeS2fviEA