编辑导语：基于我们的工作习惯，接手一个项目，需要和业务方沟通，才能决定后续的工作流程。整体先于部分存在，B端产品也是如此。b端产品更强调商业，需要对商业有清晰的认识。那么，我们如何了解商业呢？以家装行业为例，笔者分享了自己的B端业务分析方法，大家来看看吧。
整体先于部分而存在，目的实现之前有目的；没有整体，我们就无法理解局部。
都说B端产品业务性强，要对业务有充分的了解。那么你是怎么理解业务的呢？本文将分享自己在产品设计过程中的工作经验(以家装行业为例)。
00-1010这是我四年前开始养成的习惯。我接手一个项目，先和业务方聊天，尽可能完整地了解目前的业务流程，然后用流程图描述。
在沟通过程中，可以记录业务方对系统的期望，但不进行沟通。
在画业务流程图的时候，我给自己定了两个要求：
以家装业务为例：
什么是家装？那就是：让房子看起来能住人。复杂装修分为自装、半包、包、半包主材、局改、全案等。
但是家装业务有一个基本的业务流程(主轴)，即获客转化交付，如下图所示：
当然，我不能一上来就画这个东西。都是经过大量沟通和记录整理出来的。这个主轴是我自己的习惯，不是规格，可以根据自己的喜好使用。
解释这个流程图。首先，我定义了三个节点状态：意向客户、合同签订和完成，并用它们来收尾三个阶段。这样一来：
快速划分业务边界，更清晰地描述业务，便于沟通和理解。其实对我来说，不是一个系统，而是三个相关的系统。只要触发机制和数据生成的现场要求受到系统的约束。甚至按照资源优先或者业务优先，可以考虑先做某一部分。
单个主轴无法完整描述业务，需要进一步完善流程图。这里的改进是描述“阶段”，这个阶段是如何流动的，发生了什么。审查说明：只关注业务，不关注角色。
一、了解完整的业务，画流程图
在这里，你会发现营销分为线上和线下两种方式，每种方式又分为不同的渠道。
1. 营销阶段
这里的流转顺序是“意向”“面试、定金、折扣”设计方案预算签约。这种描述的原因是：
因为公司不同，跟单过程只有几件事：开会、量房、定金、设计方案、预算报价(这里不考虑设计费)。在这个阶段补充完流程之后，接下来可能需要考虑一个东西：工作流引擎。让每个公司配置自己的业务订单。
2. 设计跟进阶段
送货是家装业务中最复杂的部分。这一块的描述太多了，就不赘述了。
上面的流程其实是我收集的信息的结构化呈现，可以清晰的展现商家之间的关系。由于它指导我进行产品设计，它还可以帮助我向合作伙伴解释业务。
3. 施工阶段
/h2>大型系统一般都有好几个产品经理，各自负责一个模块，但是强业务的系统，模块跟模块之间耦合无法避免，且共用很多基础内容。
所以即使我只负责某一个模块的情况下，也会要求自己去了解业务的全貌，了解整个系统如何使用。以此来避免一些错误、重复的设计。
二、组织架构是系统的核心
业务系统中组织架构的坑，往往通过其他业务体现。
这里的组织架构不仅仅是『部门』之间的关系，更是企业经营逻辑、数据关系和业务边界的具象体现。
家装公司的管理各种各样，管理思路也百花齐放：
以上只是其中几种，这里还涉及到一些概念如：
- 门店间的数据是隔离的、业绩也是隔离的
- 一个客户可能是A门店的来源，但是在B门店进行履约合作
- 线上来源的订单，基于渠道进行划分管理，但是可以指派给任意门店
- 多个门店可能在同一个主体报税，也可能独立报税
- ……
不过，不是所有问题都是由系统来解决的，有的时候我们需要推送公司进行调整。但是这所有的前提都是:充分了解当下的组织架构以及规划好未来的系统的组织、数据管理方案，才能跟业务方进行讨论。
关于组织架构的设计，我没办法给到通用的『方法』，只能强烈的建议一定要了解行业的『组织架构』，我主导过两次线上系统的大重构：一个是关键业务模块的重构，一个是组织架构的重构。其中组织架构的重构是我最痛苦的一次，因为基本所有上游模块都跟组织架构有所关联。
重构的方案设计，不仅要考虑你要做成什么样，还要协同开发一起找到所有可能影响的数据点，输出调整方案、全流程测试、数据清洗等等。
三、总结
数字化这两年热火朝天，未来也势必延续很多时间，但是很多系统做的，还不如用Excel。
产品难受于：客户怎么那么多问题，客户怎么不会用；
客户难受于：这个系统不好用，这个功能不完善，这个设计不符合预期。
问题其实一直出在产品经理身上，因为我们除了要提升产品设计能力以外，我们还要额外的学习更多的行业知识，要学习分散在几个、几十、上百个人身上的知识。过程是痛苦的，但是这是我们的职责所在，希望以上建议能对你们有所帮助。
本文由 @koci 原创发布于人人都是产品经理。未经许可，禁止转载。
题图来自 pexels ，基于 CC0 协议
