时间: 2021-08-03 08:26:26 人气: 14 评论: 0
编辑导语：中后台产品业务分析和结构化是产品经理需要掌握的一部分内容，前一篇文章中，对组织和角色、系统数据及对象构架有了一定的了解，作者在本文中总结了客户周期及业务权限相关内容，我们一起来看下吧。
前一篇文章中，我们分享了业务构架分析的方法（组织和角色，系统数据及对象构架），同时深入了解了这句话的二个部分：
本文我们进入：“在什么时候“部分， 这部分在CRM的范畴中可以概括为客户生命周期的分析及业务对象的生命周期分析。
做过CRM项目，这个名称你一定不陌生，但是，你真的理解客户生命周期的意义和构架方法吗？
百度一下，客户生命周期的解释，图**比比皆是。笼统的说，就是客户在你的业务中经历哪些阶段？这些阶段客户交互的特点，销售的目的？客户服务的特点，这点综合起来，就是客户生命周期。
仅仅这样分析还不够透彻，首先要对客户主体的类型做个和业务模式的对应。这样你**得到一个答案，CRM体系对应的是一条或几条客户生命周期。
如果一个业务并不单一的CRM方案，乙方小伙伴给我一条大而化之的生命周期，那可能是他/她仅仅拿了个CRM生命周期的模板来套用。
最常见的客户主体不同而带来客户生命周期不同是个人用户和企业用户，在兼而有两种客户主体的业务中，这两条周期的客户状态变迁，客户痛点，销售模式均**不同。
需要注意的是，不要混淆客户主体类别，客户分类，客户细分的概念。如常有业务中有大客户和一般客户的划分，这是种客户分类。
但是否上升到客户主体的不同，还要看这两类客户在销售模式，客户诉求，客户痛点上是否有比较的的不同，当两类客户在这三个方面大同小异，那么一个生命周期即可覆盖。
还是回到本质看，客户生命周期就是解析清楚客户这个业务对象和其他业务对象的关系。
在上篇文章中，我们明确了业务对象的含义和业务对象的对应关系图。在CRM的体系范畴中，最常见的业务对象有：线索，商机，活动，日志，月报，消息，通知，产品，订单，合同，收款，客户权益，工单，call in/out， 联系人，合作伙伴……
不要想着客户生命周期有多么高大上，在业务调研中，认真的了解各个业务对象都有哪些状态，那么这些对象状态的对应关系其实就形成了客户生命周期。
先要理解，不仅仅是客户有生命周期，所有的业务对象的状态变迁就形成了自己的生命周期。
经常在面试产品经理和业务架构师中听候选者提及我去梳理流程，分析需求。
也常常听人介绍系统时，开口即是：
听这样的介绍后，作为听者，我的感受是：做过CRM系统相关工作，懂一些，但不足以做0-1的系统创建工作，不足以构架，规划一个完整的系统。
流程没错，而我们先要站在更高的角度去审视构建你的系统。都有哪些角度呢？ 我想如下图所示，业务模式，客户主体，销售模式，销售阶段，业务流程，信息字段等。
从介绍你的业务来讲，一下子扎入处在第四层的流程……可见一斑。
这里，小珠教你个更好的方法：先介绍公司业务（即业务模式），再介绍系统定位（什么样的客户的什么样的业务，服务公司什么样的职能的什么业务段？），最后是功能大模块，再加上系统的大数据（覆盖用户数，设计客户数，设计业务规模，对象业务数量等）。
市面上一谈客户生命周期，谁都说点什么，一百度也一堆图**，但看上去都对，好像看了也不能指导工作方向，更谈不上如何具体工作了。如下面的图。
如果你是乙方实施人员，给甲方老板这么一张图，请问业务方不清楚吗？如果你是甲方的CRM设计人员，这张图没有错，是客户生命周期业务逻辑，企业运营体系规划的基石，但对你的项目有何用？
我们这里不详谈在客户不同阶段销售导向销售方案的不同，单从CRM类产品业务分析的角度，如果你做的销售模式咨询的项目对应上面的范畴，而你做的是CRM构架和实施的范畴，请看小珠CRM的分析。
生命周期不是客户这个对象独有的，但在CRM的范畴中，客户的生命周期是时长最长，覆盖串联了其他对象的生命周期。
同时CRM统领的范畴也是围绕发现客户，开发客户，维护客户，经营客户进行的。所以，客户生命周期的绘制是CRM业务构架的核心。
首先找到客户生命周期和各个其他主要周期的关系。
我们举个栗子：
先将客户生命周期中客户这个主对象经历的状态按照业务推进列示，你**发现各种业务对象相继粉墨登场，如图：下单后的收款开始后，图例启动了客户权益对象的生命周期。
这样先形成客户生命周期中主要业务对象的时域对应关系。
接下来更细致的工作是，做各个生命周期详细的状态对应关系，每个业务对象的生命周期都有各自的业务状态，这些不同业务状态的对应关系要逐一列示，分析透彻。这样下来，你的业务构架完成大半。
如下图：分析了客户和机**，订单，客户权益对象关系。
文章过长，语言无趣，难免忘记，总结如下：
上面三部分中，我们分享了业务构架分析的方法（组织和角色，系统数据及对象构架，客户生命周期及业务对象生命周期）。
同时深入了解了这句话的前三个部分：
接下来我们进入：“有什么样的权限“部分， 我们先从业务的角度理解下权限的本质。
我们很多做技术的同事，朋友对这个问题非常在行，我这里是从业务理解的角度出发，权限就是谁可以对什么样的数据做什么。我们最熟悉的添加信息，删除，修改，搜索，查找，导出，审批，上传等等。
10年前我从一个乙方合作的项目经理中受教，这些本质都是对数据的增，删，改，查。
从业务的角度想理解的话不难，比如对某个申请的审批就是对在审批的状态字的修改。作为业务及产品人员，不用非往4种数据的基础操作层面理解，我们理解到操作即可。
设计好权限其实就是解决好个空间和时间的问题。
（1）空间
我们常说的空间是3维度的，而权限先解决的是，角色，数据对象及操作的问题，对应空间概念。通过某“角色”，对何种“数据”，可以做什么“操作”，形成了权限的空间。而这一空间在时间上是唯一的对应某场景的。
（2）时间
三维度形成的立体形态，随着场景的变化呈现不同的内容和形式，这里的时间对应业务场景。
举个栗子：
我们拿场景1下新客户开发的销售对客户有增删改的权利，而沿着客户生命周期的时间轴变到了老客户的场景，可能对有的销售模式讲归另一拨销售负责了，老客户维护团队对其有增删改查的权利。
我的CRM生涯中，做的多是桥的工作，业务和产品的桥，需求和技术的桥。针对于不同思维语言的转化，作为非技术出身的我，愿意使用各种类比来描述事物的本质。
架子：我曾经遇到过技术同事和我说无法实现某组织机构下，有些组织缺位的情况，比如某公司大部分销售的组织结构有5层，如销售，销售城市经理，销售区域经理，销售大区总监。
而有些相对小的区域可能存在层级的缺位，甚至在不同的销售团队里，不同层级的职位名称并不相同。
解决这个问题就要“搭架子”，如果不同销售组织中本质的权限关系，数据上串，下**关系并无差别，只是职位名称和层级技术不完全对应。
先找到最多层级的组织，搭好该层数的架子，无论叫什么职位，后台对应的层级是唯一的，而且遇到缺项的时候，不影响层级的完整性。就好像架子在那里，无论放不放东西在里面，层级不**变。
书本：不同与“搭架子”，摞书本在遇到缺位时就不能显示同样的高度，但是方便统计实际层级。
业务导向去梳理构建你的角色权限落地方案时可以理解好“搭架子”和“摞书本”的区别让你的需求和构架更加明确。
空间和时间的逻辑明确了角色的权限类型，而业务范围的架子搭好明确了数据范围，大致为非技术职能解决了常见的权限角色，组织层级如何开展业务构架的问题。
本文由 @小珠CRM 原创发布于人人都是产品经理。未经许可，禁止转载
题图来自Unsplash，基于CC0协议
