完整进行中后台产品业务分析和结构化的方法（上）

编辑导语：第一次接到对于中后台产品业务，不知道如何下手？作者分享了一些自己做完整地进行中后台业务分析和结构化方法，或许对你有所帮助。

一、“组织和角色”

从需求调研到业务调研，从业务分析到业务构架。继而完成系统的整体构架，最后升华到业务优化的推动，甚至对行业及公司战略的影响。

这个LOOP的升迁也是我心中CRM类系统相关工作的“段位”升迁路径。从需求调研，功能细节设计的脚踏实地，到战略参与的仰望星空。这并不断层，而是个有机的连续的体系和升迁路径。

小珠CRM分享至今，这部分是我这几工作心得的核心，愿意分享，讨论，学习，共同进步。

无论你是甲方自己的产品及运营人员还是业务分析人员，或者是乙方的需求分析，咨询人员都涉及到本文。

1. 第一次分享

10多年前，进入一家外企工作，现在看来做的是产品运营，或者系统产品的需求管理，运营及运维。那时候没有系统，部门在进行多个销售过程优化，客户智能分析等相关的业务优化和体系建立项目。

当时外企的客户智能部门成立很早，其实这个部门梳理建立的体系，流程是CRM类系统成功的前提，直至今日我任然建议您公司上CRM系统不能由IT部门牵头管理，应该在业务运营部门。对应一个时髦的职能，自己系统成功的”客户成功职能“。

客户管理制度优化好了，销售流程有了，数据分析方法有了，就缺数据了。我就被委派和外包开发团队合作，建立了公司第一个CRM系统。现在回想有非常多的缺陷，我们在不知道CRM为何物时，就建立了相对庞大的CRM系统。

一年后，系统就运行平稳了，当时市场部有一个同事，该部门也想做个系统，管理市场活动，信息收集，活动效果等。就找到我，让我介绍下作为甲方，如何从0-1建立系统。

我和她聊了聊，觉得她没太听懂。我认真思考了几天，把我这一年第一个系统的工作方法总结了下。最后她们还是放弃了。但我的方法和思考留了下来。 当时我入坑不深（CRM大坑），也要考虑如何给非IT人士（我也非IT人士）讲清楚，所以一句话来构建系统，我想想明白这句话，系统大体轮廓就出来了。

一句话!

“什么样的人，在什么时候，对什么样的数据，有什么样的权利。”

2. “什么样的人”之组织职能分析

你构建的系统是给什么样的人用的？

不要告诉我张三，李四，张总，王总。是给公司什么样的部门用的？

对于公司管理还不太完善的公司，或者部门命名五花八门的情况下，可能你要自己重新定义部门职能定位，一般公司的职能有销售职能，产品职能，运营职能，市场职能，支持体系（HR, 财务，行政，IT等）。

每个职能部门要研究其组织形式，这也是为何做好业务系统其实要对企业管理与基本的知识和理解。

和CRM结合最紧密的职能之一，销售职能。有多少部门组成？如何分工？组织结构的本质形态是什么？

如常见的分类，第一级别先根据渠道来分：直销，代理商等等。在此之下的可能是矩阵式，如常见的是业务线和城市两个维度形成矩阵式。

还有一种是第一层用城市划分，下面在区分渠道类型。当然还与业务线。

总结下来，常见的销售组织维度一般有下面几个维度来形成。

绝大多数公司用这几个维度在不同层级构成了销售职能的组织结构体系。

例子1：A公司的销售体系先根据客户生命周期分为新客户开发的销售团队，老客户维护的销售团队，然后在根据地理区域从大区到城市到小组。这样的组织机构就包含生命周期阶段及区域两大维度。

例子2：B公司的销售体系第一层为渠道类型，然后是地理大区如华东，东北，华北，华中，西南，每个区域有有分为中心城市集合到小城市集合。

同时每个中心城市集合又区分为不同的业务线小组。这样的销售职能就涉及到渠道类型，区域，及业务线。

需要说明的是这样的维度未必是全集对全集，比如再大的城市，可能涵盖所有业务线，而小的城市只有部分业务线。

3. “什么样的人”之组织角色分析

在业务分析和系统构架中，要先形成3类角色个概念，如果一个IT规划和业务规划成熟的公司，这三类角色统一形成规范，整体的认识，会解决整个IT体系及业务口径不断发展的过程中，数据及角色架构统一可以对应的问题。

（1）HR职务角色

公司在人员招聘，组织规划时会建立自己的HR职务及职级体系，如销售角色，市场专员，管理角色等，在我们的HR人员管理系统及OA类系统中的基本角色规划和设计即来源于HR职务角色。

（2）业务运营角色

我们在理解梳理业务时（也就是小珠CRM谈到的第一化中：CRM类系统产品经理职业要求的思考！) , 涉及的最主要的角色类别就是业务运营角色，也就是在各个业务场景下，都什么样的角色承担的什么样的工作。

如，某教育行业在现场教学的时候，会有相关的教学角色，承担现场客情维护，客户引导，销售促进的工作，这些人角色在HR职务都是销售，而根据课程现场所负责的客户参会情况被选择为某场次的教学，那么这个角色不是HR职务角色，但在场景及业务梳理时承担了不同于销售的任务，所以作为业务运营角色存在。

（3）系统角色

了解了业务运营角色后，这些角色并不是和系统设计的角色一一对应的我们那上面的例子，教学都是由销售承担，销售的角色对应的权限都没问题，只有一个场景在课程对象前2周有课程主管将参课客户在系统分类。

同时在对应的责任销售中选择一个作为助教，那么这个助教仅仅关联到现场成单的业绩上而已，并没有其他系统操作的需求和权限，我们就不必为其在系统单独分配助教角色。

业务场景角色是否需要设为系统角色，也要看其单独操作的场景是否多，是否贯穿客户生命周期相对多的环节，配置角色带来的工作量是否繁杂相对于其在系统的操作来讲。

“什么样的人”是指全面理解组织结构，部门职能，业务运行模式，多维度角色提炼等复杂的内容。

接下来的文章小珠会和你分享“对什么样的数据”，当4个部分讲完，相信你可以做出一个基本实际可用的系统业务规划。

二、“系统数据及对象构架”

上文中，我们分享了业务构架分析的方法，同时深入了解了这句话的第一个部分，关于组织结构和角色的分析方法。

本文我们进入：“什么样的数据“部分， 这里的数据是个广义的概念，不仅仅指业务数据，系统中的各种信息字段都是数据。

1. 数据分类

如果你是个甲方的同仁，使用的是实施后的CRM产品，或者对接外包开发的产品那么你从业务的角度理解各种文档的要求即可，我们暂且叫Level A。 如果你是自开发的产品职能还要加上Level B。

前者适当的了解Level B便于和乙方和技术人员沟通，而后者必须同时了解，才能做好业务规划，产品设计。

Level  A: 数据分类

从这个程度来讲，非严谨的IT技术层面，我们可以把系统里的数据分为三类：

• 业务数据：客户数据，线索，机会数据，订单，绩效等。
• 用户数据：组织结构数据，用户数据，系统权限配置数据等。
• 运行数据：各种日志（审批，账号，导出等), 任务及消息， 任务及消息日志，访问量等。

很多系统的需求是从第一类开始的，如，我们之前在线下管理的客户列表，突然觉得我们可以建立一个系统放在系统上管理，那么这个系统就是从一个简单的客户数据开始的。

慢慢从几个字段的需求，拓展为客户文档，这里需要说明下，文档其实就是一个业务对象（比如客户）的一系列信息的集合。我们对主要业务对象的需求是多维度的信息需求。

想要管理的业务对象数据，如客户文档，机会文档，订单文档，代理商文档，客户权益文档逐步丰富，明晰后。系统功能主要依照这些数据的获取，关联，优化，管理，利用来进行继而形成系统。

什么样的职能在系统内外何种场景完成了上面的获取，关联，优化， 管理，使用就是用户的数据体系。而系统运行下来，做的操作积累，关键动作的追踪，系统使用情况的检测就是运行数据体系。

2. 业务对象

Level  B: 对象抽象

通俗的讲我们在系统中管理了，运营了哪些东西，那么这些就是业务对象。如CRM里的客户，联系人，代理商，线索，机会，订单，客户权益，工单，任务，日志，月报，签到，通知，消息，任务等。

而业务对象可以根据其业务关系和数据关系形成集合。

如客户，包括负责业务的多形态客户。可能细分为个人客户，企业客户等。

当其文档结构和包含信息差别大，而且和其他业务对象的关联关系明显不同时就要单独作为两个对象。常见的客户对象族群为，个人客户，企业客户，最终用户，代理商，联系人等。

又如，机会对象，当行动都落在机会过程中被管控的话那么机会和行动常常形成集合。而订单，收款，合同常常形成一个集合。

Level  B: 对象关系图

明确出来各种业务对象，对象簇，主子关系图，就要根据业务分块形成对象关系图。

能否做业务导向的产品经理，在于这一步。我们都熟悉技术架构师的职能，而对应的产品应该是业务构架师。

在我的从业经验看来，这种人才不多，难能可贵。业务人员具有产品思维，逻辑及抽象能力强可以往这个方向发展，而产品经理偏业务导向，同时具有良好的业务理解，强大的逻辑能力，做业务架构师，也是一个不错的职业规划。

举个栗子：

下图是某CRM系统的整体对象规划图的1/4。

整个业务构架分为客户全生命周期，权益全生命周期等4大生命周期，其中主要的业务对象形成了互相的集合。

这为整个系统的梳理业务，理解需求，技术职能规划技术架构提供了基础。

 

本文由 @小珠CRM 原创发布于人人都是产品经理。未经许可，禁止转载

题图来自Unsplash，基于CC0协议