互联网产品，本质是一种高效的满足用户对数据进行增、删、改、查等需求的方式和载体。
SaaS，适应云时代而生的一种产品形态。只需要一个浏览器或者客户端即可以完成所需的数据流转。
企业级SaaS，适用于大规模协同，实现多角色多组织之间共同对数据进行增、删、改、查的产品。
随着参与角色的增多，发生事件的增多，企业级SaaS除了在满足业务需求的前提下，更要注重满足管理需求。企业级SaaS中的数据中心，即是满足业务需求，也是满足管理需求。
以下六步可以大致的帮助产品经理来搞定数据中心的规划与设计（为了将方法论更具象的表述，我会以智能客服SaaS来进行业务场景的举例）。
（一）明确需求
B端产品需求获取的办法有很多，我总结了大概有四种，包括观察法（看业务方的实际工作场景）、访谈法（询问业务方实际工作中的需求点）、角色扮演法（有条件的去实际操作几次业务流）、经验萃取法（通过思考把感性的经验量化）。
这四种需求获取的方式在深度上依次递进，看、问、体验、思考。想做好B端产品，就很难将产品范畴的工作与业务范畴的工作割裂开，如果说C端产品讲究用户思维，那么做B端产品一定要有业务思维。
管理中常常提到HR要懂业务，其实产品经理也是一样，要能听到炮火声才能知道仗怎么打。
然而很多时候产品经理获取需求的办法是——看看竞品有没有。
这并不是最可怕的情况，因为追赶竞品也是一种不容易犯错的办法。
最可怕的是一不懂业务，二不看市场，凭既有经验去臆想需求。
企业级SaaS的业务方一般有一线人员与管理人员两种角色，经过对这两种角色分别进行几次需求调研之后，可以提炼出这些需求：
1、管理侧需要实时查看正在产生的数据，用来进行调度或者决策；
2、管理侧需要客观数据进行统计和分析，用来进行流程优化或者产品改进；
3、管理侧需要检查历史数据进行问题排查和质量管理；
4、管理侧可以查看数据报表或者导出数据进行向上汇报；
5、业务侧需要查看工作时间内的相关业务数据，用来调整工作节奏；
。。。。。。。
（二）搭建架构：
数据中心由数据构成，数据二字要分开来解释，一类是日志（据），一类是指标（数）。前者是原材料，后者是衍生品。
按照时间维度数据又可以分为存量数据和增量数据，一定时间段内的数据变化，就是实时监控的范畴。
根据需求场景，数据中心应由实时监控、统计分析、系统日志三个模块组成。并且要针对不同用户组进行鉴权。
比如有系统管理员权限的客服经理可以看到整个系统的运转情况，以及每个客服的工作完成情况。但是只有客服权限的一线客服只能看到整个系统的排队情况，以及自己完成的工作情况用来掌握自己休息的节奏。
（三）构建系统日志：
数据指标的统计源，是系统日志。
系统日志是数据统计的依据。
我们首先要搞清楚有哪些数据流，产生了哪些系统日志，才能从这些系统日志里萃取出数据指标。
怎样搞清数据流？
业务流的背后就是数据流，一套完整的数据流，包括角色节点、流转规则、表单数据。系统中的用户角色有哪些，他们之间的数据交互是怎样的，有哪些表单数据产生了，搞清楚这些，数据流就搞清了。
一般企业级SaaS都有多个角色，包括visitor 、user、vip、admin等。我们要搞清楚系统业务侧的服务对象是谁，管理侧的管理对象是谁。数据中心的本质是记录业务侧的生产数据，为管理侧提供决策服务。
哪些系统日志需要被记录下来？
不是所有的系统日志都需要在数据中心里体现，只有跟业务相关的数据才有价值。
比如，用户与客服的对话记录、用户排队时间、客服响应时间等等是需要业务侧和管理侧关注的，但是每条query的传输时长，控件的触发时长，系统的qps等这些后台日志，与业务关联度低，所以不用出现在数据中心。
这里要解释一下我对前台和后台的界定范畴。
拿客服SaaS举例，用户与客服对话的界面相对于客服侧属于前台，客服工作的界面相对于用户侧属于后台，相对于管理侧属于前台。
整个客服系统相对于产品经理来讲又都是前台，支撑客服系统的底层架构才是后台。这里指的后台日志，是指底架构的后台日志，而不是客服系统的后台日志。
系统日志是数据统计与分析的基础，数据统计的指标项取决于系统日志里是否包含这些字段。比如要查看用户咨询量的趋势，但用户进入时就没有加时间戳，那显然就只能呵呵了。
产品经理要根据业务场景把所需要的字段梳理出来给工程师进行开发，对于工程师来讲，他们专注的是工程质量，而不是业务场景。这里并没有什么约定俗称的事情，文档里没有的，就默认为没有。
产品经理要把每个字段的含义与取用规则写理清楚，写明白。具体的实现由工程师来完成。
以客服SaaS为例，核心的数据流是用户与客服的对话，那么根据业务场景每一组对话应该有如下字段应该被记录下来：
对话ID/对话内容/来源渠道/用户ID/问题类别/客服ID/对话状态/开始时间/结束时间/用户评价/等待时长/是否被转发
工程师会把这些字段组成一个表单，字段不同，表单也不一样。
再比如，应用人工智能技术的客服系统，会有机器人客服的角色，人机对话的场景就会有区别。这些字段就需要被记录下来：
queryID/来源渠道/用户ID/时间戳/query/机器人回复/匹配度
这些表单就组成了系统日志部分。每一个字段都可以作为筛选项，也可以通过一定条件对表单进行排序。一般会取时间戳作为排序条件，ID类字段作为查询条件，其他字段作为筛选条件。这些条件构成了系统日志所需的查看方式。
（四）数据指标项的设置与分析：
系统日志搞完了，原材料就有了，那么数据指标应该怎样设置呢？
指标项可以根据统计方式不同分为，计数项、运算项、时间项。
计数项：每个字段其实都可以作为计数项，是一种绝对值计数。例如对话数。
运算项：一种情况是两个或两个以上计数项进行交叉运算得出的值，比如求和，求差，求百分比，求平均值。例如用户对客服的满意度。
另一种情况是这个字段本身的属性就是一个值，而不是文本。
这种情况常见于财务系统，例如基本工资这个字段。那么基本工资这个字段就可以作为序列项进行运算，比如拿月份作为分类项，年度基本工资总数，月度基本工资涨幅，单月基本工资占全年基本工资的半分比就是运算项。
时间项：一般指时长，利用相应的时间戳算出来的。可以是正计时，也可以是倒计时，还可以是累计时长。例如用户等待时长。
这些指标项又该怎样去分析呢？
根据业务场景选择相应的字段作为筛选项，看这个字段涵盖数据的计数项或者运算项，就是分析的范畴。
例如选择问题这个维度，看不同问题分类所属对话的分布，就可以看出哪一类问题是热点问题。
应付复杂的业务场景，不仅要支持分维度，还要支持分类别。还是拿智能客服系统举例子，统计分析可以分为对话维度、问题维度、渠道维度、又可以归类为系统，客服，机器人三个类别。
具体的指标项设置和分析，是行业方法论的范畴。产品经理想要做好一个行业的SaaS，成为这个行业的业务专家是必要的。这些数据项按照时间维度构成的表单，就是统计分析部分。这部分的交互要支持灵活的筛选。
（五）可视化设计：
满屏堆表单，不是一个好产品。我们要进行合理的可视化呈现。
数据可视化的方式有很多，网上有关于这方面比较成熟的方法论。图表类型的选择，我就不在这里过多叙述。我要补充的是产品经理如何写一份可视化需求的文档交付给设计师和工程师。
其实很简单，每个图表的背后都是一个表单。
文档里要包含以下几点要素：
1、图表类型，例如趋势图、饼图、雷达图等。
2、分类项（X轴）的定义，例如取用哪个表单里的哪一个字段数据，或者直接用年月日时分秒。
3、序列项（Y轴/Z轴）的定义，例如取用哪个数据序列的值，值的格式（分数/百分比/小数点），刻度的单位（百/千/万）。
4、图表标题、图例、数据标签。
5、最后规定出你要强调的数值区间或者数据项即可。
（六）考虑一些业务功能：
1、实时监控
将一定时间范围内的增量数据（包括日志和指标）单独作为一个模块展示，就是实时监控模块。
这里可以用dashboard的设计，关键字段突出展示与可视化图表相结合。
重点是要与工程师确认好刷新机制，在实时性和成本之间有个取舍。
数据项的计数一般取得是那个刷新节点的数据，类似快照的概念。
2、权限管理
不同级别的用户组在数据中心的查看和操作权限是要有过滤的。
一般一线业务人员是没有查看整个系统数据的权限，但是有些场景业务人员也要关注整个系统的数据流转情况。
比如客服中心，客服也要掌握整个客服平台的用户排队情况，来判断自己的工作节奏。
这里的处理办法是实时监控界面要有支持全屏的设计，每个工区都可以放置电视大屏用来进行实施监控的展示。
3、增加功能控件
数据中心除了支持查数据，也可以根据业务需求增加操作功能。
例如客服SaaS的实时监控模块，可以通过查看，每个客服的状态，负荷度，正在处理的问题进度，管理员可以根据需要进行问题的转发，实现人员调度的需求。在每条数据的后面加个转发问题的控件即可。
4、支持报表制作与数据导出
方便管理侧进行报表制作与数据导出。
走完以上六步，数据中心就基本完成了规划与设计。
总结
讲透一个具体的点简单，讲透一条连贯的线很难，讲透一个通用的面难上加难。
这是一篇我个人从业以来在数据中心的规划与设计上的梳理和总结，我已是尽可能的以一个通用的面的形式去阐述。这也仅代表我个人的水平和观点，不具备权威参考性。
为了使整篇文章更加有偏重和结构，我适当的把握了描述的颗粒度，有些细节并没有完整的交代，在实际的产品设计中，还需要产品经理进行深度的思考和补遗。
高阶产品经理应该关注的点在于业务逻辑和数据逻辑，所以我就没有进行原型和交互示例，有这方面需要的产品经理可以私信我。
感谢pmcaff社区提供的这次交流机会（其实是给我挖了个大坑，我通宵码了以上文字来填坑）。
欢迎关注我的个人公众号：醒茶（PM-xingcha）
