B端业务分析方法（以家装行业为例）
整体先于部分而存在，有目的然后才有目的的实现；没有整体，我们就不能理解部分。
都说B端产品是强业务型的，要对业务有充分的理解。那么如何了解业务呢？本篇文章就来分享下我自己在产品设计过程中的一些工作经验（以家装行业为例）。
一、了解完整的业务，画流程图
这是我4年前开始的习惯，接手一个项目时，先跟业务方唠嗑，尽可能完整的了解当下的业务流程是怎样的，然后用流程图描绘出来。
沟通过程中，业务方对系统的期望可以记录，但是不展开沟通。
画业务流程图时，我给自己定的两个要求：
- 流程图要有一个『主轴』
- 只关注业务，不关注角色
以家装业务为例：
什么是家装？就是：把家装成能住的样子。复杂的说装修又分自装、半包、套餐、半包+主材、局改、全案等等等等
但是家装业务有一个基本业务流程（主轴），获客 → 转化 → 交付，如下图：
当然，我不可能一上来就画的出这个玩意，这都是大量的沟通和记录之后，梳理出来的。这个主轴是我自己的习惯，并不是规范，可以根据自己的喜好来。
解释下这个流程图，首先我定义了三个节点状态：『意向客户』、『签约合同』、『竣工』，用他们封闭出三个阶段。用这样的方式：
- 快速简单地做了业务边界划分
- 更清晰的描述业务，方便沟通和理解
到这一步，其实对我来说就不是做一个系统，而是做三个有关联的系统。系统跟系统之间只要约束要数据生成的触发机制和字段要求即可。甚至根据资源优先级或业务优先级，可以考虑先做某一部分。
单单一个主轴，并不能完整的描述业务，所以我们要进一步完善流程图，这里的完善就是把『阶段』给描述出来，到底这个阶段是怎么流转的，有哪些事。回顾下注意事项：只关注业务，不关注角色。
1. 营销阶段
这里会发现：营销分为线上、线下两种方式，每种方式下由分为不同的渠道。
2. 设计跟进阶段
这里的流转顺序是『意向』→ 『面谈、定金、量贩』→ 设计方案 → 预算 → 签约。之所以这么描述是因为：
- 因为公司的不同，收不收定金、先收定金还是先量房各有规则
- 跟单过程中的事就那么几样：见面、量房、定金、设计方案、预算报价，（还有设计费这里没考虑）
这个阶段流程补充完，可能接要开始考虑一个事：工作流引擎。让各个公司配置自己的业务顺序。
3. 施工阶段
交付是家装业务中最繁杂的一环，这块展开描述太多，就不赘述了。
上述流程其实就是将我收集到的信息，进行结构化的呈现，这样可以很清晰的展示业务之间的关系，既然指导我做产品设计，也能帮助我给协同方讲解业务。
4. 小结
大型系统一般都有好几个产品经理，各自负责一个模块，但是强业务的系统，模块跟模块之间耦合无法避免，且共用很多基础内容。
所以即使我只负责某一个模块的情况下，也会要求自己去了解业务的全貌，了解整个系统如何使用。以此来避免一些错误、重复的设计。
二、组织架构是系统的核心
业务系统中组织架构的坑，往往通过其他业务体现。
这里的组织架构不仅仅是『部门』之间的关系，更是企业经营逻辑、数据关系和业务边界的具象体现。
家装公司的管理各种各样，管理思路也百花齐放：
以上只是其中几种，这里还涉及到一些概念如：
- 门店间的数据是隔离的、业绩也是隔离的
- 一个客户可能是A门店的来源，但是在B门店进行履约合作
- 线上来源的订单，基于渠道进行划分管理，但是可以指派给任意门店
- 多个门店可能在同一个主体报税，也可能独立报税
- ……
不过，不是所有问题都是由系统来解决的，有的时候我们需要推送公司进行调整。但是这所有的前提都是:充分了解当下的组织架构以及规划好未来的系统的组织、数据管理方案，才能跟业务方进行讨论。
关于组织架构的设计，我没办法给到通用的『方法』，只能强烈的建议一定要了解行业的『组织架构』，我主导过两次线上系统的大重构：一个是关键业务模块的重构，一个是组织架构的重构。其中组织架构的重构是我最痛苦的一次，因为基本所有上游模块都跟组织架构有所关联。
重构的方案设计，不仅要考虑你要做成什么样，还要协同开发一起找到所有可能影响的数据点，输出调整方案、全流程测试、数据清洗等等。
三、总结
数字化这两年热火朝天，未来也势必延续很多时间，但是很多系统做的，还不如用Excel。
产品难受于：客户怎么那么多问题，客户怎么不会用；
客户难受于：这个系统不好用，这个功能不完善，这个设计不符合预期。
问题其实一直出在产品经理身上，因为我们除了要提升产品设计能力以外，我们还要额外的学习更多的行业知识，要学习分散在几个、几十、上百个人身上的知识。过程是痛苦的，但是这是我们的职责所在，希望以上建议能对你们有所帮助。
本文作者 @koci 。
版权声明
本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！
