从“来现场POC”到“去线下店体验”：我的数据治理产品选型经历

       本人所在的企业为亚洲领先的保险集团公司，公司业务遍布亚太地区多个国家，覆盖寿险、财险、健康险等多个险种。立足于创新、多元化的互联网保险产品与服务发展目标，作为公司数据部门的元老，我先后参与建设了公司的SMART 投保系统、UW/NB核保系统、LA个险核心系统等多个业务系统，同大部分保险企业一样，我们的软件开发能力有限，以及环境、投入等因素，我们各系统均为不同开发商基于自己对业务的理解进行规则设计与开发。对于集成这些系统的我们而言，保障系统间数据一致并能有效联动成为现今工作的至关难关：在测试环境下，数据在单个系统内看起来毫无差错，基于业务流交互于各个系统之间时却往往发现数据不一致甚至相互矛盾。我们不断的投入人力、时间去全面了解各系统的规则、测试系统设计是否符合业务需求，投入了很多依然发现代理人的佣金计算不对、投保数据与核保数据不对、保费保额计算总是差那么几分钱、公司各部门各系统都说自己的数据是准确的，但为什么最后的结果就是不准甚至相矛盾……诸如此类问题一直困扰着我们数据管理部门及项目团队，最终公司决定启动数据治理咨询服务。

       历时一年，我们与全球知名的一个咨询公司完成了企业数据战略规划咨询服务后，正式开启了企业数据治理建设落地工作。首先启动的就是数据质量治理产品的选型调研----简单说就是核验检测工具对投保、核保、个险等几个系统样本数据进行数据质量分析，并对系统间数据一致性问题进行深度梳理，本次预备核验重点为各系统的保单号，代理人 编码，保单机构险种费额相关信息。做了各种比对，选择了3家数据质量产品进行体验。

A产品，国际性公司产品，公司为全球领先的数据管理软件提供商，数据质量工具在Gartner魔力象限位于领导者地位，在传统数据或大数据中均有使用案例；

B产品，国内产品，公司为专业的智能数据产品与服务提供商，深耕商务智能和大数据领域16年，案例集中在政府数据应用难题解决；

C 产品，代理的国外产品，同时在多年代理中研发了数据质量服务的周边产品，其数据质量工具在Gartner魔力象限也位于领导者地位，在工业大数据、金融保险行业均有案例。

Ａ产品体验经历：

A产品的体验过程可以归纳为12个字：文档多、会议多、确认多、思考多。

1、与厂商确定需求场景

通过远程会议、上门拜访、文档整理等诸多形式，与厂商明确了整个项目的需求场景。本次需求涉及的系统主要有S、U、L、G、D系统，涉及的主要的字段包括代理人编码、保单机构编码、首期保费、首期保额、险种编码、险种首期保费、险种保额。客户在POC流程方面有丰富经验，在需求整理时覆盖到了业务对象的相关要素：表单内容、流程明细、权限明细、统计图表要求等，以及确定参与POC的人员履历信息。

2、签署PoC服务告知书

厂商起草了一份《ＸＸ客户售前验证服务告知书》以确保POC的有效投入。告知书包含此次POC面向对象、需求要点、整体计划、验证周期，特别标注了“志愿提供不收费的售前验证服务”交予我们确认并签署。

我认为告知书增强了我们双方对此次POC的重视，也更好地明确POC的整体计划和内容，确保项目能够得到有效推进，防止长期低效的POC。

3、按计划执行POC

POC计划达成一致后，与厂商安排的人员直接按计划执行POC。伴随着POC的展开，我们与厂商频繁的进行会议沟通，无论是电话会议、视频会议还是现场会议，会议纪要数十份，相互协作，进一步明确会议中存在的争议点、确定的解决方案以及双方理解是否真实且一致，确保了PoC的有序推进。这个过程中个人觉得比较好的是厂商提供的PoC阶段问题记录文档记录POC过程中，我们的需求变更、体验优化、需求增加等问题。但是厂商与我们的业务人员、技术人员的不间断、不定时的交互过程逐渐影响了团队多人的正常工作。

4、撰写项目POC报告

当整个POC按照核验功能推进到尾声时，时间已超过约定的６个工作日，不管POC的过程是顺利还是曲折，厂商依然撰写了一份客观且诚恳的POC报告。这份报告对投入该项目POC的资源进行阶段性总结和分析。由于POC的结果距离预期略有差距，但最终的结论让我们进行数据管理系统建设有了更全面的评估。

整体感受：

1、厂商派遣的POC人员对核心需求理解比较明确，整体的核验85％满足了我们之前的预期；很好的完成了S、U、L中的保单信息与D中信息的一致性;G、D中保单机构、代理人、保费、保额一致性；L、G中的保单保费推送到V中，L、G和V的保单保费、开票金额准确性、有效性；S、U、L、G、C中的收付金额与P中的一致测验；但是在C的保单信息，与L、G中的保单保费、保单状态，U中待回访的保单，和C系统中的待回访保单定时增量核对、定时全量核对比对时存有遗漏。

2、安排的POC执行人员在流程控制上有严格的要求，严谨但略有拖沓；

3、双方在POC的约定不够清晰，在核验初期过程中由于未考虑数据记录的FLAG值，多所有记录进行了分析，另无效数据也存在问题数值记录中，让最终分析结果发生偏差，最终不得不重新沟通，在过滤了无效属性后进行了第二轮的分析。这个操作使得POC整体过程出现了延期。

4、POC过程书面记录很完整。厂商在文书记录方面值得一个大写的“服”字，从最初的沟通到中途业务了解、需求细则到处理方案，每次会议都有详细的记录。再次翻看这些资料，不仅能帮助我们回顾了整体的操作，其中探讨到的许多问题，特定条件下提出的处理方法都值得让我们再次去思考，整体的POC更像是我们双方的学习探讨之旅。

Ｂ产品体验经历

Ｂ产品的体验过程也可以归纳为12个字：环境多、操作多、结果多、解释多。

B产品的POC流程与A产品流程很接近，前期也是需求的沟通到告知书的签订。只是在对需求的处理过程中与A不太相同。

B产品测试过程中涉及了他们数据集成、数据交换、实时计算存储、元数据管理、数据标准管理、数据质量管理等模块。以SMART、UW、LA、GROUPLIFE、DMS各系统中字段元数据为数据检核对象，通过向导化、可视化等操作，将质量评估、质量检核、质量整改建议与质量报告等工作环节进行流程整合，形成数据一致性核验的闭环。整个过程中，多个工具的安装比较耗时，另外就是检测前需要对所有检查项进行规则配置，虽然厂商自带了他们积累的内置规则，诸如《GS1-2013  企业信用分类监管数据规范》等，但根据我们的业务情况，在配置规则前任然需要业务人员配合厂商工程师按照字段去梳理多条业务规则，而梳理出的规则准确性如何也依然待我们的验证。好在规则配置整个过程无需技术人员编写SQL或程序代码，只是通过图形化界面进行配置即可，不过鉴于每个字段存在多条规则，配置的过程还是略长。

B产品在实施过程中还针对不同的业务模块或数据转换环节建立了多个质量检查模型，并将上述中的规则配置在不同的业务模块中，从而达到复用，这点坚决了产品A在增量核对、定时全量核对比对时存有遗漏的问题。通过对重要阶段设置数据检查监控点，并能实现跨监控点、数据源的比较分析，这种方式可实现ETL前后的数据一致性比对。而对于发现的问题可通过图形化编辑器定义整改流程，实现将指向问题分发给数据责任人。数据责任人完成整改后，还可推动流程到审批环节，经质量管理员审批通过后结束流程，让数据整改有个规范的管理。

体验过程中，因为规则的设置差异，使得产生的结果存在多样性，有时甚至出现同一条规则，在不同的系统中同一类字段执行出不同的结果，因此也产生很多种解读。

C产品体验经历

C产品的体验过程依然可以归纳为12个字：体验新、认知新、速度快、可期待。

C产品的体验过程与A、B产品的POC过程完全不同。我们的POC从来现场变成了去体验店。

1、需求沟通只有1个电话，1张信息表

我们在联系了C产品厂商，表达意愿后，C产品客服表示公司拥有线下体验店，我们的需求为保险金融行业常见业务场景，体验店已备有相关场景数据及完整的体验方案，当然为了更直接、更真实的感受他们的数据质量探查分析能力，我们也可以带自己的数据去进行测试。在确认我们愿意去体验后，让我们填写了一份《XX数据治理体验店_用户技术基础调查表》，主要包含工作职责、是否在数据治理方面有经验、了解或参与的数据治理项目有哪些、是否有数据库使用经验等。

2、没有厂商操作的功能检测

体验店在西直门，环境很好，与老牌的数据分析培训机构合开的体验店。简单的招呼后，我们开始了１天的体验。

首先，观看了体验店数据治理概述和体验操作流程的视频，大致介绍了体验店三类体验科目包括技术、业务、管理及集成体验流程。鉴于我们本次的需求时探查各系统数据一致性、有效性、准确性的核验需求，我们选择了《数据探查与诊断》项目，主要是体验数据的自动快速分层扫描检测，对数据字段、记录、表、表间关联、健值进行分析，全面了解数据现状，如何对异常数据快速定位分析，如何基于数据探查的结果来审核数据的质量，发现数据可能存在的异常和问题，为根本原因分析、所需数据纠错和预防错误的合适改进提供基础信息。

接下来我们获取了每个人专属的访问地址、账号信息（此步对应A\B产品环境安装环节）及实操中用的资料：体验指南、体验数据、体验结果及报告模板；现场顾问老师简单讲解了如何使用指南、体验的数据及规定的数据问题发现的结果需要呈现的要求后就让我们自己开始实操体验。

当时我们团队感觉有点懵，前后不过30分钟，我们就要开始操作一个陌生的系统了吗？

事实证明，我们团队真的是很聪明，若不然怎么会让体验过程如此简单顺畅？

实操第一步，数据加载，包含数据分割符的选择、字符编码类型（基本囊括了全球80多种编码格式，这个功能可以在数据集成时多域数据源处理）、CR/LF、数据量的选择（很好的一个功能，支持全部加载、随机加载或从某个位置加载）。百万条记录用了不到5分钟就完成了加载，当体验店顾问告知我们，加载结束后，工具内置算法已经对所有字段自动完成了数据基本属性及初步规则的分析，并对结果进行了统计。

实操第二步，按照工具对数据本身多维度分析，通过提供的重复值、最大最小值、掩码、Mark值、类型、空值、关系、规则遵从度、健值、数据结构等四十余个维度直接获取到核验字段的数据质量情况。

 不同系统中代理人编码格式

 多表并联规则核验

体验中除了极快的产生结果外，还有两点也让我们觉得很刷新认知。其一是依据掩码、Mark值，我们可以快速的确定某个字段的标准。诸如保单编号，工具中显示存在AAA _NNNN占95.464%，AA _A_ NNNN占2.154%，AAAA_A _NNN占1.352%，A _ NNN_NNNN_AA占0.030%四种格式;我们可以以此推导保单编号遵从的格式标准为AAA _NNNN（3个字母，5个数字）格式，凡是不属于此格式的即为异常数据；通过这种方式即可验证之前制定的规则是否正确，也可通过这种直接解析出的结果推到出业务规则。这点对于业务人员非常友好，他们无需技术人员协助，便可快速发现异常数据；其二是所有发现的问题均可“下钻”，可直接定位到问题数据。即使是多个数据源，多张表，无需代码，也不需要SQL，通过点选字段建立关系后，可以直接显示匹配程度，并且遵从程度可调整设置。这点对于数据人员非常友好，他们无需撰写代码、无需SQL，便可快速定位到异常数据，这点对于我们常用SQL或者自制小插件进行查找的人来说，如同。

3、顾问老师的点评让体验变为另一种形式的学习

整个体验过程中，顾问老师不仅对操作有指导，同时也给出一些帮助，通过哪些维度可以发现数据中可能存在的问题，即便日后不适用他们的产品，我们也可凭借这些知识去发现问题。这应该就是从体验店中得到的自身数据素养的提升吧。

整体上来说，C产品的核验给我们待来很大的震撼，除了分析的速度、多样的维度、精细的准度、便捷的操作，还为我们节省出大量的沟通、环境部署时间。略微遗憾的是当天我们无法拿出自己的数据（众所周知的数据安全保密原因）来直接、真实的核验。

三家产品整体对比情况

三家产品功能核验完毕，整体对比如下（1、2、3级别表示，数值越大，排位越低）

		产品Ａ	产品Ｂ	产品C
综合实力	公司规模	1	2	3
	产品和服务品牌	1	3	2
	管理体系健全性	1	3	2
	公司财政实力	1	2	3
	长期发展能力	2	3	1
产品与技术	产品体系的完整性	1	2	1
	软件功能完善程度	2	3	1
	技术领先和前瞻性	3	2	1
	产品开发与运行平台先进性	3	2	1
	产品整体性能的稳定性	2	3	1
	系统安全性	1	2	1
	系统运行速度	2	3	1
	产品升级难易	3	1	2
	产品持续发展的能力	3	2	1
	产品集成和二次开发能力	3	1	2
行业优势	行业客户积累	1	3	2
	典型客户应用现状	1	3	2
	金融行业产品提供的针对性	3	3	3
	在金融行业投入力度	3	3	3
	有资深行业顾问	1	3	2
服务能力	行业方案针对性	2	3	1
	客户方案针对性	2	3	1
	整体方案的严密性与可行性	1	3	2
	方案服务能力	1	3	2
成本	产品价格	3	1	2
	技术服务价格	3	2	1

结合产品性能、产品功能、过往的经验、咨询能力以及产品价格来进行产品选型，我们还需要继续考虑，相信不久之后就有答案了。