编辑导读：对业务进行拆解能帮助产品经理更好地厘清各个模块之间的关系，分清主次需求。当一个产品经理接到一个复杂且陌生的业务时，要怎么将它从头拆解转化成产品需求？本文主要讲解该如何拆解，一起来看看~
产品的价值取决于用户需求。需求是用户当下遇到的问题，用户为了解决问题会寻求解决方案。
企业与用户的连接点就在于此。企业为用户提供解决方案，而产品则是解决方案的载体。
无论C端还是B端产品，都是为了解决问题而存在。
产品经理的工作其实是给出一个符合当下最优的解决方案，解决方案的载体就是产品。
解决方案制定的过程中会不断重复这三个步骤：发现问题，解决问题，验证问题。
梳理解决方案就是弄清楚需要哪些人做哪些事，以及人和事、人和人、事和事之间的联系。
这对应着系统的三个组成元素：角色、任务、规则。
角色对应需要哪些人，任务对应需要做哪些事，规则对应人和事、人和人、事和事之间的联系。
有了以上的认知，就可以开始拆解业务。
01定义关键角色
拆解业务首先要弄清楚哪些人会参与解决问题。
解决一个问题往往需要完成多个任务，每一个任务都会由一个或多个人参与。
找到那些执行相同任务的人，把他们定义为一个角色。
比如餐厅点餐，顾客负责点餐，服务员负责确认菜单，勤杂工负责准备食材，厨师负责做菜。这些角色各自的任务都不相同。
有一点需要特别说明，一个任务的参与人也可能是“系统”。比如服务员确认菜单后，通知厨师和勤杂工可以由系统替代。
02识别关键业务节点
解决一个问题需要执行很多任务，但并非所有的任务都是关键业务节点。
关键任务节点有两个特征：一是能够推进业务往下进行，二是推动业务在不同角色间流转。
比如厨师在做菜时会执行很多个操作。配菜、炒菜、调味、摆盘……但这些步骤都是“做菜”。虽然厨师做了很多事情，但在餐厅的业务流程里只有“做菜”是关键业务节点。
再比如后台系统常见的录入用户信息。昵称、性别、城市的填写都是需要执行的任务，但完成其中单个信息的填写并不能推动业务往下进行。在系统层面可以把这些任务抽象为一个关键业务节点——填写用户信息。
不同角色间的流转，审批流程是很好的例子。比如在钉钉上提交一个采购工单，审批者需要对提交的金额和采购的物品进行核对，但这些不会在系统层面体现，只有“通过”或“拒绝”这类推动业务在不同角色间流转的任务才会被定义为关键业务节点。
03定义业务规则与业务流程
前面我们已经将业务的关键角色和关键业务节点梳理清楚，但这只是业务梳理的热身运动。
接着还需要弄清楚人和人、事和事、人和事的联系。
“联系”体现在两个方面：一是不同角色执行任务的顺序，二是任务执行时需要遵循的规则。
业务梳理的最终产出物就是业务规则与业务流程。
依旧以餐厅点餐为例，做菜时盐不能放太多、火候不能太过、分量不能太少，这些都是厨师在执行任务时需要遵循的规则。如果不遵循规则，最终的结果是业务停在做菜这个环节无法继续往下推进。
同时做菜一定是在服务员确认好菜单后才会进行，这是任务执行的顺序。假设先做菜后确认菜单，就会导致之前进行的任务变得无效以及任务的重复。
以上两个例子说明了梳理清楚人与事的重要性，梳理有误最终导致的结果就是业务的停滞与业务的周期变长。
04如何拆解复杂业务流程？
现实世界的业务往往是极其复杂的。
业务的复杂度往往体现在以下几个维度：
多关键角色、多关键任务节点
多业务分支流程
业务流程长
业务周期长
业务规则复杂
并不是同时具备以上特征才能算作复杂业务。有时只要具备一个或其中几个就足以让业务变得复杂。
拿我正在负责的业务系统为例，系统的角色并不复杂，参与核心业务流程的角色不超过10个。但因为行业的特殊性，用户的成单周期在2~4周，服务用户的周期在2年左右。同时，虽然角色不多，但用户的分支业务流程很多。
因为过长的成单周期和服务周期，让整个业务周期被拉长，从而让业务变得复杂。同时每个角色的分支业务流程很多，进一步提升了业务的复杂度。
最后的结果是，我绘制的流程图里的节点可以造一艘航空母舰。
那么面对如此复杂的业务，我们该从何下手呢？
1.梳理单角色业务流程
业务复杂时，我们可以先梳理清楚单角色的业务流程。
比如梳理餐厅出餐业务，我们可以先梳理清楚服务员的业务流程，暂时搁置其它角色的业务流程。
如上图所示，服务员在通知厨房做菜后，不用关心厨师是如何制作菜品的，只需要弄清楚服务员后面会在哪一个节点再次介入业务。
对于服务员而言，厨师做菜是一个“黑盒”，他只关心菜品什么时候制作完成，收到菜品制作完成后他就可以进行后续的任务。
同理，其它角色也可以按照这个逻辑进行梳理。当每个角色独立的业务流程梳理完成后，再将它们串联起来就组成了完整的业务流程。
2.梳理单向业务流程
一个角色可能会进行多个分支业务流。
这个时候，我们可以先梳理清楚可能存在的业务线，然后对每一条业务线进行单独的梳理。
比如审批流里，审批的结果通常有通过和不通过。这时可以先梳理清楚通过后的业务流程，再回过头去梳理不通过的业务流程。
当两条业务线梳理清楚后再合并在一起就构成了完整的业务流程。
其背后的思维方式其实和梳理单角色业务流程一致——化繁为简。
把复杂的业务拆解为单角色、单流程的业务进行梳理，这样能够更清晰地把握业务脉络。
3.梳理异常业务流程
除了主线的业务流程外，还有很多异常的业务流程。
比如餐厅就餐的主线业务流程是用户点餐到用户买单。但不可避免的情况是——退款。
这种独立于主线业务流程外的业务称之为异常业务。
针对异常业务，我们可以单独拎出来进行梳理而不和主线业务流程产生交织。在设计业务时，要尽可能避免降低对主流程的影响。
05那些需要留意的坑1.线上业务流程抽离
完整线下业务流程梳理后，在进行产品设计时，要从线下业务流程中抽离出完整的线上业务流程。
比如点餐系统。在系统层面，会删除掉很多线下的环节。厨师做菜是线下的任务，执行时可以不必与系统进行交互，只需要完成做菜后在系统执行操作，通知到服务员取餐即可。
其次是线上业务流程会引入“系统”这一角色，很多原本在线下执行的任务都会有系统的参与。我们需要明确系统在整个业务流程中替代了哪些之前由线下角色执行的任务。
2.了解真实的业务现状
很多公司里面系统的需求方是业务负责人，而不是一线的业务人员，所以系统的设计是从管理者视角出发的。
这种情况很可能导致系统的设计并不符合真实使用者的需求。为了避免这种情况发生，产品经理在设计系统时一定要找一线业务人员进行调研。
另外一种情况是，系统上线后系统使用者可能并没有按照设计者的预期使用系统，而是按照自己的理解来使用系统。所以在系统上线后产品经理一定要去看看系统真实的使用情况。
3.系统的效率并不一定高于线下
系统的核心价值在于提升效率。如果引入系统后效率并没有提升，甚至效率降低，这个时候就值得我们深思了。
比如服务行业里往往存在总部和线下门店两个独立的业务部门。线下门店有时会遇到极其特殊的情况，而这种情况通常需要即时处理，但又无法自己做决策。
如果走系统可能会因为业务流程的停滞导致线下的问题无法即时解决。
系统只是一种解决方案，但不是唯一的解决方案。
4.业务问题、系统问题傻傻分不清楚
“你们系统设计的太烂了，根本满足不了现在的业务需求！”
“其它竞品都有XXX功能，为什么我们不能加上去？”
“这个地方经常会误操作，能不能XXX这样改进一下啊？”
诸如此类的话语，我相信大部分产品从业者都不陌生。业务方总是能从你不曾想到的角度提出问题。
不知道大家有没有去探寻过背后深层次的原因？
我思考的结论是，业务人员会对系统形成依赖性。
有的业务人员认为什么问题都可以靠系统解决，更为夸张地是觉得任何问题都是因为系统不完善导致的。
产品经理的脑子一定要清醒，不要因为业务方的强势而妥协。
比如运营部常常会说我需要一个XXX营销功能，如果没有这个功能，我们这个阶段的指标就无法完成。
这样的需求我听到过N次，但当问到他们具体的运营目标、预期的ROI是多少时？绝大多数时候运营方都无法回答出来。
这就属于典型的把业务问题甩给产品来解决。即便产品做了，后续依然会甩锅到功能做得不够好。
所以业务方提需求时，一定要先让他们意识真正的问题是什么。
写在最后
很多人问过我比较擅长什么类型的产品，其实我并不觉得一定要局限在某一类产品。
两年前我会想在某一个领域深挖，但现在思考更多的是产品背后的方法论。
产品的道是思维，产品的术是方法。不管什么类型的产品，只要掌握了道与术都应该能够做好。
那些优秀的人一直在不断突破自我的边界并实现自我的价值。