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

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

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

很多系统的需求是从第一类开始的，如，我们之前在线下管理的客户列表，突然觉得我们可以建立一个系统放在系统上管理，那么这个系统就是从一个简单的客户数据开始的。
慢慢从几个字段的需求，拓展为客户文档，这里需要说明下，文档其实就是一个业务对象（比如客户）的一系列信息的集合。我们对主要业务对象的需求是多维度的信息需求。
想要管理的业务对象数据，如客户文档，机会文档，订单文档，代理商文档，客户权益文档逐步丰富，明晰后。系统功能主要依照这些数据的获取，关联，优化，管理，利用来进行继而形成系统。
什么样的职能在系统内外何种场景完成了上面的获取，关联，优化，管理，使用就是用户的数据体系。而系统运行下来，做的操作积累，关键动作的追踪，系统使用情况的检测就是运行数据体系。
2. 业务对象Level B: 对象抽象
通俗的讲我们在系统中管理了，运营了哪些东西，那么这些就是业务对象。如CRM里的客户，联系人，代理商，线索，机会，订单，客户权益，工单，任务，日志，月报，签到，通知，消息，任务等。
而业务对象可以根据其业务关系和数据关系形成集合。
如客户，包括负责业务的多形态客户。可能细分为个人客户，企业客户等。
当其文档结构和包含信息差别大，而且和其他业务对象的关联关系明显不同时就要单独作为两个对象。常见的客户对象族群为，个人客户，企业客户，最终用户，代理商，联系人等。
又如，机会对象，当行动都落在机会过程中被管控的话那么机会和行动常常形成集合。而订单，收款，合同常常形成一个集合。
Level B: 对象关系图
明确出来各种业务对象，对象簇，主子关系图，就要根据业务分块形成对象关系图。
能否做业务导向的产品经理，在于这一步。我们都熟悉技术架构师的职能，而对应的产品应该是业务构架师。
在我的从业经验看来，这种人才不多，难能可贵。业务人员具有产品思维，逻辑及抽象能力强可以往这个方向发展，而产品经理偏业务导向，同时具有良好的业务理解，强大的逻辑能力，做业务架构师，也是一个不错的职业规划。
举个栗子：
下图是某CRM系统的整体对象规划图的1/4。
整个业务构架分为客户全生命周期，权益全生命周期等4大生命周期，其中主要的业务对象形成了互相的集合。
这为整个系统的梳理业务，理解需求，技术职能规划技术架构提供了基础。

本文由 @小珠CRM 原创发布于人人都是产品经理。未经许可，禁止转载
题图来自Unsplash，基于CC0协议