整天说大数据，多大算大？
这么大的数据，怎么管？
语塞，心塞，喝酒吃饭...
后来想了一项，这看似门外的问法其实涉及到了一个严肃的技术讨论问题，那就是DataGovernance，又叫做数据治理。第一次我在接触这个词的时候努力试图把它与DataManagement数据管理分开，以宏观(政府)和微观(企业)想映射。
数据就是二十一世纪的石油，所以“DataLake数据湖”产生了。对于企业来说，掌握数据就掌握了更多的可能。联络中心则是日以继夜地生产大量数据的后方根据地，以一个100坐席规模的多媒体联络中心，每天产生的数据量也是惊人的：如通话数据、录音数据、坐席数据、工单数据、日志数据、网页数据等，如果是一个外呼的营销型联络中心或者工单派发型的服务联络中心，再配合CRM所产生的业务数据，日积月累，存储空间会以T比特级别直线上升。
经常业务部门要一个数据ETL做匹配筛选，或者来一份CDR详单对一下明细，数据库管理员DBA的内心深处其实是奔溃的，就好比:
hmm，来点干货吧：
联络中心本质上是一种综合的信息处理系统，包括了多方的参与者，因此数据的生成可以从多个维度来进行剖析。从宏观来说可以从业务流、知识流、信息流、数据流这四个层次去观察。
- 业务流根据不同企业对联络中心的任务定义通过不同分工完成，各个岗位和组织之间的协作构成业务流，典型的就是一个电话订单受理的流程，客户来电下单，CSR在线受理后，提交工单，流转到财务、审核、生产、物流形成一个线性的流程。站在这个维度，联络中心可以将触角延伸到后台处理，以一个“流程360度视图”数据的方式来综合提高运营效率。
- 知识流则是在不同的岗位和组织之间进行业务活动时候，知识也在不断的迁移。比如新产品的对应的营销话术，投诉工单的聚类和归集输出等等。
- 信息流的直接表现形式就是ERP/BPM或者CRM软件，让各种知识流在不同的IT信息系统中传递。
- 信息流最终具象成数据，要么短暂使用，要么持久化在数据库中，形成数据湖，等待后期数据挖掘。
如果只有数据一直在存而不做数据挖掘分析，那就会形成数据“沼泽”，因此数据治理的第一步就应该是顶层设计，也就是数据分层。抽象地理解，联络中心的数据大致可以分为：
- 元数据：描述数据的数据MetaData
- 参考数据：如知识库等包含通用不变的数据（网点、利率、等常见知识)
- 组织结构数据：坐席、岗位和后台流程部门等
- 业务结构数据：用户信息、理财产品、工单表格等
- 业务活动数据：交互记录、活动数据、合同信息等
- 业务审计数据：操作记录、审批记录、质检记录等
从联络中心层面来说，多种媒体渠道（语音、聊天、APP），各种工具软件（知识库、录音）和应用程序（机器人）越来越复杂，相互依存度逐年增加，相应的追踪整个客户链条各组件之间数据流动、了解数据元素含义和上下文的需求越来越强烈。比如一个客户在APP上通过聊天机器人对话转到人工，坐席后又主动致电客户，后续质检人员在追踪此条对话需要对应地抽取聊天记录和通话录音两种数据，甚至还有后续客户短信满足度回放的结果。
从总量上来看，联络中心的元数据越来越多，光现有的数据模型中就包含了成千上万的表，同时还有更多的模型等着上线，同时随着大数据时代的来临，企业需要处理的数据类型越来越多，需要明确元数据管理策略和元数据集成体系结构，依托成熟的方法论和工具实现元数据管理，并有步骤的提升其元数据管理成熟度。
为了实现大数据治理，构建智慧的分析洞察Insight，仅仅是分析联络中心自身的数据，很难建立完整且一致的元数据管理策略，联络中心需要实现贯穿整个企业的元数据集成。该策略不仅仅针对某个数据仓库项目、业务分析项目、某个大数据项目或某个应用单独制定一个管理策略，而是针对整个企业构建完整的管理策略。
通俗的话说，就是联络中心在自身的元数据整理好、数仓建设好后，以ETL标准件方式主动融入业务部门的大数据分析系统，形成更有力的数据治理。
其实后来想得清楚一些了，这就是道与术的区别，抖音一个机灵：《黄帝内经》之素问·四气调神大论中提出到：“是故圣人不治已病治未病，不治已乱治未乱，此之谓也。呃～大概也就是这个意思。
