详解客商主数据的输入及相关管理

客商主数据（客户、供应商、既是客户也是供应商）是企业最常用的主数据类型之一，因在主数据管理层面客户和供应商思路基本一样，所以本文以供应商为例介绍。

先说供应商数据，供应商主数据除了真正在供应商关系管理系统SRM、采购系统、电商等系统或者模块中管理的典型供应商数据外，在财务管理中，只要是我方需要向其支付款项的都是供应商，那么部分业务场景下企业需要向个人支付时，这类个人也是供应商的角色（以下简称“个人供应商”），也需要按主数据管理。此外，在一般情况下，主数据是业务实体数据的子集，比如在SRM系统中对供应商做全方位管理时会包括大量的字段，而属于主数据范畴的字段可能只是其中二十几个。

进行主数据管理时常规希望是单一数据源，即主数据直接在主数据管理（MDM）系统输入或者来自于一个前端应用系统（比如供应商数据来自SRM系统），如果是多源则会较大的增加主数据管理和MDM系统应用（包括集成）的复杂度。以下将先介绍在MDM系统中输入供应商主数据的场景，之后介绍在类似SRM等第三方系统中输入供应商主数据并与MDM系统集成的场景。在MDM系统中输入供应商主数据

一般情况下，新增供应商时建议用户先在MDM中查询主数据是否已存在，因为很多时候其他用户此前已输入过，但现实中用户往往还是会习惯性的直接输入。无论用户是否会先查询，在用户输入时MDM系统应首先在数据库中查询该供应商主数据是否已存在，如存在则提示用户主数据已存在是否需要修改等。

此前输入供应商主数据时，供应商名称、统一社会信用代码等内容的准确性检查一直是件头疼的事，严谨的企业会要求上传供应商的工商营业执照等扫描件，在审核时人工比对，在数据量比较大的情况下，主数据管理人员的工作负荷比较大，人工比对也会难免出现较多失误，此前见过的一些案例，大型集团企业在处理全集团的主数据时有些情况下需要第二天才能审核通过。于是后来应用了OCR，影像识别后将扫描件上的企业名称等结构化，之后与用户手工输入的名称进行主动比对，只有比对发现异常时才提示管理人员干预，处理效率和准确性大大提高。

以下的案例来自于我几年前看过的《国家电网公司主数据管理系统功能优化研究》一文。当用户对供应商主数据提出申请后，将通过省（市）公司运维和总部主数据运维两级审批，审批通过后将创建或更新主数据。经统计，仅2014年通过主数据管理平台申请创建和更新的供应商主数据就有82000条，其中公司类数据占到90%以上，而该类数据需上传的信息包括组织机构代码证、税务登记证、营业执照三类电子扫描图片，两级审批人员都需对这三项信息进行人工对比审核，效率低且需大量的人力支持。总部运维情况如表1所示。

在供应商主数据审批功能优化中，利用两种技术对一副图片的识别审批速度都在1秒左右，对应于供应商的公司类数据三份必须资料，利用两项技术独立串行审批需6秒左右，并行审批只需3秒左右。对于这三份必须资料，两次自动审批都通过的比率大概占到60%左右，而转人工审批的资料文件中，存在关键字段字体重叠、印刷位置错误等现象而无法自动审批的文件占50%左右。即机器总的审批数能占到80%左右。机器辅助审批工作量统计见表4，效率提升统计见表5。

上边是一个例子，接着介绍，当近些年企业征信服务出现后，基于上述对主数据准确性、风控及自动化等更多现实需要，主数据管理领域也出现了与企业征信服务集成应用的方案，典型的征信服务商包括企查查、启信宝、天眼查等（多家大型银行也有，但服务内容侧重和价格不一样）。企业的MDM系统通过与征信服务的集成，在用户输入时自动调用征信服务接口，用户只需要输入一部分数据即可自动从征信服务平台获取到准确的多个内容，一是大大减少了输入的内容，同时自动获得的还是准确的数据，比如输入供应商的18位信用代码，MDM通过接口自动从征信平台获取企业名称、企业所属地等数据。原则上，企业档案类的数据以征信平台的为准，于是相关字段在MDM的录入界面上是只读的，即只能从征信平台获得，不允许用户编辑。

因为征信平台提供的商业服务可被信任，于是按上述方式获得的数据是准确的，所以在主数据管理层面或许可以不再上传供应商资料影像件，不再需要基础性的审核。但对个人供应商和境外供应商通常还是需要人工审核的，个人供应商一是数量相对较少，二是没有常规的个人征信服务，那么在输入姓名和身份证号等信息时存在出错的可能性，而大多数的情况下也不能拿到个人供应商的身份证原件，那么对身份证影像件的OCR可以一定程度上实现自动化，但人工审核往往还是需要的；对境外供应商，目前也没有类似国内供应商的18位信用代码，而国际上虽然有邓白氏码，但很多境外供应商因为规模等原因也不一定会注册邓白氏码，那么一般情况下只能通过供应商名称作为唯一性判断条件，这就存在输入错误、外文字符等各种异常状况，一般情况下也需要人工审核。

再补充一点MDM系统查重校验的内容（MDM系统应在软件功能上最大限度的保证主数据的唯一性），对国内常规的组织机构可以通过机构名称（如企业名称）加上18位统一社会信用代码两个条件去复合查重；而对境外的组织机构，现阶段只能以名称进行查重判断；对于个人供应商，因为姓名重名的几率非常大，所以需要按身份证件的类型，以身份证件号码做查重判断，比如居民身份证编号等，综上，需要根据不同的客商主数据类型按不同的查重规则做判断。

当主数据经过一系列校验以及审核，达到规定的数据质量标准后，MDM系统按规则为主数据生成唯一性的主数据编码（这个操作以下简称为“赋码”），随后将主数据推送给所有目标系统，主数据新增完成。

征信服务不仅在主数据输入时有用，因为供应商存在企业名称等内容的信息变更，那么在主数据的日常管理工作中，可以调用征信服务接口定时对MDM库内的主数据做检查，发现库内数据与征信平台不一致时要提示管理人员做后续的处理。

顺便简单说一下主数据的日常性管理，除了上边国网案例中的日常性的主数据审核工作，还有检查MDM系统对主数据的接收和分发状态、对异常情况的处理、参考数据及各类编码表的更新，等等。对参考数据更新的工作略作展开介绍，类似于国别地区、币种等参考数据一般变化很少，日常维护工作相应也很少，而供应商有一些数据往往需要时不时的维护，这个就是输入供应商银行账号数据时的银行编码表（常规至少包括两个字段：银行名称、联行号）。在较多的场景下，对供应商做银企直连的在线付款时需要供应商收款的银行和账号（供应商的银行信息也常常被多个系统所需要，所以纳入供应商的主数据范围），需要把银行的名称和联行号发给银企直连接口才能实现在线支付，联行号是银行类似于个人身份证号的官方编号，各家银行新增营业网点时就会有新的银行及联行号需要维护到MDM系统中，此外也有银行网点更名的情况，也需要对银行编码表做更新。所以，除了维护主数据本身，相关的参考数据和编码表也是主数据管理的工作内容。

在第三方系统中输入供应商主数据

如果把第三方系统作为主数据的输入端，那么第三方系统应具备上述MDM系统输入主数据时所需的全部功能，并在此基础上开发与MDM系统集成的一系列接口和功能。首先，因为第三方系统与MDM系统是独立的两套系统，数据库也是各自的，那么就可能存在两个数据库中数据不一致的情况，特别是如果有多个供应商主数据入口（含个别直接在MDM系统输入主数据的情况），很可能出现两个数据库中数据数量不一样的情况，比如第三方系统中没有的主数据但在MDM系统中有，那么第三方系统判断主数据是否存在的功能就不能只检查自己的数据库，还需要开发一个接口去MDM系统中做查询（查重逻辑与MDM系统中的一致），如果在MDM系统中没有才认为是真的没有，如果有，则需要一个机制做数据同步。

当供应商主数据在第三方系统中经过一系列校验成功录入后，需要由第三方系统进行如上的审核使主数据进一步符合质量要求，这个审核可能需要管理或者业务方的参与，比如财务部门。当主数据审核通过后，第三方系统需要开发一个接口把主数据推送给MDM系统，无论采用同步接口还是异步接口，都需要保障数据推送的可靠性，只有第三方系统成功的从MDM系统收到正确的反馈时才认为主数据被成功送达。为此，需要第三方系统开发有接口监控的功能，以监控向MDM系统推送和接收数据的状态，在包括网络、系统、企业服务总线等出现异常时可以掌握情况并做处置。

这个接口还需要支持实时或者定时的推送控制，常规情况下，达到标准的供应商主数据应实时推送给MDM系统，之后再由MDM系统推送给各个用户系统，有些业务场景对主数据的时效性是有要求的。并且，当推送遇到异常时，第三方系统可以批量的重新发起推送。此外，第三方系统应记录所有与MDM系统的交互日志，一旦交互异常，可以加以分析和处理。

在第三方系统作为主数据输入的情况下，主数据编码的产生也需要予以重点关注。如果第三方系统是明确唯一的主数据入口，那么原则上主数据编码可以由第三方系统赋码，如果不能确保主数据入口的唯一性，即当前第三方系统不是唯一的供应商主数据入口，那么通常就只能由MDM系统赋码了。对于后一种情况，相当于在第三方系统中产生的主数据是半成品，因为缺少最关键的主数据编码，主数据编码必须由MDM系统赋码并返回给第三方系统，于是就需要再开发一个接口用于返回主数据编码。

此时又分为两种情况，第一种是第三方系统有自己的编码体系，并且这个编码体系作用于第三方系统的业务功能，只能使用第三方系统自己的编码，只是为了需要与其他系统集成应用，与其他系统数据交换时需要采用主数据编码，于是主数据编码可被认为是第三方系统中供应商数据的一个功能性字段，当第三方系统按供应商主数据的标准把数据推送给MDM系统后产生了主数据编码后，通过接口把主数据编码反填至第三方系统的对应字段中，这个对主数据编码字段的反填接口通常是需要按非主数据编码的一个字段进行判断的（因为此时第三方系统还没有主数据编码），比如国内供应商可以按18位信用代码，此时需要第三方系统和主数据系统务必做好数据唯一性的管理。

另外一种情况是，第三方系统可以不使用自己的编码体系，完全依赖于MDM系统的赋码，此时，第三方系统刚录入的供应商主数据可以采用一个临时编码，临时编码与数据一并发给MDM系统，MDM系统成功返回主数据编码后，第三方系统根据这个临时编码去查找到对应的供应商数据并把临时编码替换为正式的主数据编码。这两种情况适用于不同的应用场景，具体按系统情况决定，但无论哪种情况，主数据编码返回到第三方系统后的更新接口需要特别的严谨和可靠，需要纳入到接口监控的范围中，以保障主数据和主数据编码的唯一性。

上述是供应商主数据新增时的一些管理内容，那么因为第三方系统是供应商主数据的入口，那不仅是新增时的管理，对主数据修改的管理也是第三方系统需要承担的工作内容，也需要第三方系统开发一系列接口用于数据的修改，主数据修改的接口可以直接使用主数据编码在第三方系统和MDM系统中定位到数据，同时仍然需要对接口做重点的监控，保障MDM系统中的主数据成功得到了修改才行。

综上所述，本文以供应商主数据为例，介绍了在MDM系统和第三方系统中输入主数据时常规的一些管理内容，在具体实践中，在不同企业、不同系统情况、不同应用场景下，会有更多的技术细节需要具体关注。

中翰软件：专注数据治理17年（http://www.jobhand.cn）

免责声明：本网站所发布的文章为本网站原创，或者是在网络搜索到的优秀文章进行的编辑整理，文章版权归原作者所有，仅供读者朋友们学习、参考。对于分享的非原创文章，有些因为无法找到真正来源，如果标错来源或者对于文章中所使用的图片、连接等所包含但不限于软件、资料等，如有侵权，请直接致电联系，说明具体的文章，后台会尽快删除。给您带来的不便，深表歉意。