一文了解主数据建设的挑战与发展

2021-02-08 09:26

一、企业主数据建设挑战

首先介绍一下很多企业在做主数据建设中都会遇到的一些痛点和挑战。可能很多企业有的没有建主数据;有的建了分域的主数据,比如说人事域、财务域、生产域、制造域;有的是建了集团级的统一的主数据;有的还建了分级的主数据。

我今天介绍中其实不仅局限于主数据的起步阶段,可能还有非常多我们很多的客户所遇到的挑战,甚至于让我们自身都感觉到非常棘手的一些主数据的挑战,这是我认为应该得到大家重视或者给大家一个参考,在未来我们的主数据建设过程中,大家会遇到其中一个或多个问题。

难以根除的数据问题

1、数据不一致,这个问题或多或少大家都遇到。首先像我今天列举的这些,比如在ERP中有重复的物料,同物料但是不一样的编码,之前我跟很多的这样的业主方聊的时候,大家比较开玩笑,用了十几年的ERP,谁没有几个重复的物料,都会遇到的。你单一的数据来源中可能会遇到重复的数据,你多数据来源中也可能遇到重复的数据,甚至于数据的冲突,比如现在很多的企业,我们在零售端流通端会To B、To C,你在To B、To C的过程中,你的客户他的很多的属性会遇到比如不一致的情况等等,这些都是数据不一致冲突的问题。

2、数据关联,获取到一个数据是想获取到数据关联的全部内容,而不仅仅局限于这个数据本身的属性,就需要主数据具备与把整个数据全部关联所包含进来的这样一个能力。

3、数据获取的困难,有的企业具备统一的主数据,可以由统一的通道来获取,有的企业是分域建的,可能物料主数据在ERP里,人事的数据在HR里,这样的分域主数据互相的一个连接也成为一个困难。

4、数据的混淆,主数据本身就是要来解决数据不一致的问题,解决数据标准问题,但是标准如何去落地?如何去执行?如何与流程结合?让每一个参与的数据人员,业务人员都能够达成一致,还是一个很难解决的问题

复杂的模型间关联,示例:组织与人员架构

从数据管理到组织机构变革,其实现在不仅是业务方需要的组织机构的变革,还有数据上的驱动组织变革,我们经历过非常多的行业,都在为了业务而进行组织机构的每次的一轮又一轮的调整,这里会遇到很多的问题。

如图,可能未来的企业中会把组织划分为多元的,比如说多维度的职能的组织,招采的组织,财务核算的组织,成本中心、利润中心等不同维度上的组织,这些我是把它作为一个组织树的分类,还是把它作为一个组织的属性,而且在我不同的组织之间还可能会有种种的关联,还有像组织与人员,很多企业有内部的人员,有外包的人员,每个人有自己所属的职能部门,当然外包人员有合作或者劳务公司,每个人你可能在不同的业务场景下,会与很多的部门发生关系。

比如你在薪酬收入的时候,你的工资是一个部门发放的,你的补贴绩效可能用另一个部门发放,在很多成本核算的时候还核算到另一个部门。当然这里更多的时候,第一还是取决于企业对于财税方面的一个规划,很多企业在规划业务的时候会进行一些拆解,你在核算的时候可能会有一个核算组织的选取,还有一部分更复杂的,我的工作关系,我本职的工作,我兼岗的工作,我借调的工作,我虚拟组织的工作,我还有外包等情况的工作,等等的这一些就构成了主数据的模型未来会变得越来越复杂。

组织人员还是主数据中最核心的一个最基础的域,到设计、生产、制造、零售、售后等域中模型的关联会越来越复杂,如何去在主数据中去反映这些复杂的模型解决问题,是我们值得思考的一件事情。

需求迫切的主数据延展模型,示例:客户模型

还有像刚才提到的,即使对单一模型,未来的需求也越来越多,比如像客户,如何更好的向客户去营销,如何更好的去在各个领域中把客户的数据复用起来。这里其实还涉及到一部分与数仓的边界,但是很多意义上讲,企业进行主数据建设的时候,如客户模型这样主数据模型要有一定的扩展性,会把一些很多人相关的内容去统一的建设,统一的复用,这是传统主数据所不具备的。

现在我们发现主数据的建设过程中,主数据的内容会越来越多,为什么?因为主数据是解决共享复用的问题,很多的数据会由原本的单一使用到多方使用,就涉及到一个主数据模型的延展设计问题。

多级单位主数据管理问题

这里现在很多企业都是这种分子公司很多,2级3级,像我们做过最多的还有9级的这样的分子公司,独立法人的,这里集团关注哪些主数据,二级公司三级公司关注哪些主数据?集团更多的是关注组织、人员、科目、项目,二级公司更多的是关注自身的基础和生产经营类的主数据。集团更关注于统计分析和经营管理的这些指标的需求,分子公司二级公司更多的是关注于财务经营等领域的数据,所以这就导致了一个集团级和二级公司级所关注于主数据的侧重点不一样,甚至于未来的主数据会涉及到一个多级的协同的分级部署多租户管理,这也是我们最近几年遇到的大型集团非常明确且清晰的一个问题。

多业态下主数据共享与驱动业务创新

其实现在主数据也越来越把它的整个作用价值往业务上延展,很多的集团已经从传统的单一业务转变成多业务,可能会有诸多的这样不同的业务,不同的板块,板块之间甚至有很大的一个差异。有零售的,有地产运营的、有金融的、教育的,对于一个多业态集团,现在非常多的一个迫切的问题,第一是集团级的一个主数据的管控,还有第二就是不同板块之间的一个业务赋能。

这里肯定是要在安全可控的条件下进行一个业务赋能。比如说很多大型集团都有金融板块,金融板块里有很多高价值的业务客户,那是否能把这个客户提供给比如其他如地产板块,当然这是不可能的。

相关的监管条例不允许,我们要保护客户的隐私,保护数据安全。但是更多的企业开始开拓思路,可以反向的把很多其他板块的一些产品进行一些包装与个性化推荐,纳入到金融的板块,实现一个多板块协同的赋能。在这个场景下,主数据就真的去触达到了很多的业务的创新,并且驱动它进行创新。当然也需要进行对客户的画像要更深刻,对产品的包装要更丰富,类似这样的场景还有很多,这都是我们近些年发现的在多业态主数据建设过程中的一些重点的挑战问题。

二、主数据管理发展趋势

第二部分也结合在多领域多客户的一些经验的总结,我们开始思考在主数据建设中的一个发展的趋势。

在信息化项目发展趋势:逐渐以数据应用为主

这里首先讲主数据之前我们看一下最近些年的信息化项目的一个发展趋势,可能会看到我们有很多信息化项目类型,我这边简单的做了一些分类,比如基础类的,例如开发平台,服务总线、数据库,比如说办公类的,例如OA、HR、财务,还有更多的是业务类的ERP 、MES、PDM、 SCADA、LIMS,这些系统组成了很多企业的信息化建设,也支撑了业务的开展。

最近几年我们会发现整个的信息化项目的发展趋势进行了一个很大层级的提升。基础类的逐渐向微服务,容器,大数据平台去演进,办公类开始逐渐的向移动办公、财务共享、流程机器人等方向去演进,那么业务类的系统情况,其实传统系统已经做得够好了,现在我们发现很多的业务系统的发展趋势是什么?有两个方向,一个是一体化,一个是共享,财务共享平台,人力资源共享平台,还有产销一体化平台,很多都是一些综合性的应用,还有主动营销、精准营销、综合运营、能效、环保排放、产销差等

你会发现未来的信息化项目的发展逐渐以数据应用为主,为什么?因为它与传统的这些信息化系统,ERP 、MES有本质区别,它并不是自产自销式的,也就是它的很多的数据并不是自己来维护,它需要上游给它提供数据,它经过一些数据的加工,经过一些业务的流转,最终为业务上创造价值。
所以这里会看到一个很重要的趋势,未来整个信息化的趋势都逐渐会以数据应用为主。

需要主数据提供更丰富的内容支撑

因为传统这些业务应用,其实大家已经做得很成熟了,在这个需求之下就需要主数据提供更丰富的内容支撑。传统的我们分域的主数据,离散的主数据,产品是产品,物料是物料, BOM是BOM,客户是客户,这里未来会把这些主要内容连接起来,他们是以什么样的形态存在?它们之间的连接是以什么样的主数据的相关的关联的内容,从而才能够去支撑于我们未来的创新的应用需求,一体化平台的需求,数据的分析的需求,数据的共享需求。

主数据内涵更加动态化

在这里我们也总结下来主数据的一些发展的趋势,首先是主数据的内涵更加动态化,其实这是一个老生常谈的问题,最传统的时候主数据一直都是静态数据,几乎不动的数据。主数据的更新是缓慢的变化,我们会把这些变化更新的版本记录下来。

现在随着主数据的一个发展,我们发现主数据的范围越来越大了,不仅仅只是缓慢变化记录,比如客户的信息,比如说我们物料的相关的规格材质,它也会把一些比如像汇率,在我们做财务共享,应付、应收、报销、总账都涉及到,比如说产品的价格,会被多元的复用,而且现在大市场环境下,非常多行业的领域的产品价格的变化是非常频繁的。

还有一些比如说项目的累计金额,库存的库存量,来料的平均的消耗量,这些内容会在生产制造以及多领域中会被复用,他是不是也会纳入主数据中呢?其实很多的也会纳入进来,这里就会产生一个主数据逐渐由静态向动态发展的过程。当然这里不可能说逐渐的把动态内容全拿进来,因为这里还涉及到数仓,因为数仓这些年也在延展,包括数据中台,那么这里如何切分是我们也在探索的一个切分点。

可能像未来比如说数学领域0．618会有一个黄金分割点,把主数据和数仓做一个完美的切割,现在大家在做边界的探索。

主数据需求更加实时化

传统的主数据需求做定时的推送,做增量接口的推送,把数据推送给需求方,每小时去推送,获取到了,你怎么用的,可能不太清楚,甚至于增量接口提供了,读取之后后续的增量的状态就取消掉了,这里会导致数据对接中间有时差,还有取不到变化的可能。

现在我们的主数据平台会更为快捷的去对接需求方,在业务流程中更实时的去获取到主数据。例如,很多的时候我们流程中比如有BPM平台,这个的时候如果你想获取到一些核心的组织人员相关的,比如说项目合同,很多传统的方式都会把数据同步下来,时效性的影响会导致我们业务的流转会缓慢。

举一个例子,我们有一个高管,高管本身就有很高的一个审批权限,比如他在今天上午10点的时候发生了离职,这个时候他的审批权限是不是要立即关掉,最合理的肯定是要立即关掉。在很多的时候,由于主数据推送的延迟,流程系统可能到第二天才会有关闭的权限,因为这里会有一些权限泄露的问题,等等类似的问题很多。所以现在更多的客户需要在整个业务流程流转中实时的去获取主数据,这样才拿到最新的数据。

主数据连接更加深度化

这是个例子,这个例子大家都会理解,是房产开发界经常会遇到的一些核心的项目主数据中面积的相关关系,比如说一个房企拿到了一个楼盘,拿到了一个地块,要盖一个楼盘,在建设规划中肯定会有地上面积和地下面积,在过程中地上面积和地下面积肯定等于总建筑面积。任何一个厂商在做系统的时候,肯定是让每个人,让业务人员录入地上面积,录入地下面积,最后得到总建筑面积,这个是没有问题的。

那么地上面积加地下面积求和等于总建筑面积,并且地上面积和地下面积是录入的数值,总建筑面积是计算的数值,但是这是我们的设计和规划系统,他的这部分数据会纳入到我的项目主数据,或者是地块主数据。

我们还会有另一个系统,它是营销系统,他是要销售房子的,这个的时候它在里面会有三个值,不可售面积,可售面积、已售面积,这三个值肯定互相有直接关系,并且这三个值一定等于总建筑面积,因为不可能说我所有的面积加起来超过总建筑面积,或者小于总建筑面积,而且这三个值之间是有相关性的,不可售面积的减少等于可售面增加,可售面积的减少等于已售面积的增加。

所以在这6个值被纳入到主数据的时候,我们会发现这6个值之间是有什么关系的,这个关系就会涉及到我下一步的校核,因为两个系统两个表单两个功能,可能存在于我两个系统中,可能有不同的乙方厂商来做的。

那么如何保证着这6个值的一致性,可能要在主数据中做相关的一个关联,解决两个问题。第一个问题是解决数据质量的问题,保证数据的一致性。第二个问题在别人使用数据的时候,他也知道相关的一个关系。

我举这个例子还比较明显,大家都能理解到相关的内容,可能在我们的生产制造过程中有比这个更复杂的一个关联性,在流水线的上下游相关的环境指标都会有非常复杂的一个关联,这都是主数据需要考虑的问题。

三、主数据管理建设策略

刚才介绍了企业主数据遇到的一些挑战问题痛点,以及主数据行业的一个发展趋势。接下来通过普元在很多领域的很多客户项目中总结出来的我们的经验和方法。来介绍一下我们如何去应对如上的这些挑战和发展。

灵活强大的模型配置与实现

现在的主数据的核心就是主数据的模型,这个模型的组合相关的设计,我们很多的时候传统的主数据大家做的时候很依赖于第一,咨询厂商它们的规划,这也是要咨询产商来参与介入的。第二,还依赖于实施团队的人员能力。如何组合的模型,如何设计相关的模型。

在建设主数据的过程中,也就是说我们万事万物的核心对象中是有几种分类的:第一种最常见的这种关联的模型,客户、合同、产品、计划,第二种是组合模型,一个产品,比如汽车制造业的整车,除了有三大件,发动机、变速箱、底盘,可能还有座椅等等这些方面。会发现有多个主数据构成了一个主数据,第三种是层级继承模型。电脑的子集就是台式机笔记本,还会有多级的继承,还会有不同层级之间的关系,等等这些其实都是需要有一个灵活强大的模型配置去实现自动生成并优化相关的数据结构。

这里第一涉及到你业务上的关联,第二还涉及到未来性能上的一个影响,怎么保证数据快速的导入,录入。甚至于我们实时的接入,以及数据的如何能够快速的获取,快速的得到。

实时与定时双通道的集成与分发

还有现在越来越多的主数据的实时性要求越来越高,从传统的这种定时批量的获取数据,到现在通过实时的事件触发的,数据来源要实时的数据给主数据平台,主数据可以通过实时的数据服务,实时的数据推送,批量的数据同步,按需的数据文件以及其他的技术对接方式,把相关的主数据提供给所有的需求方的业务系统。

多源输入下的一致化版本管理

我们会看到主数据未来的来源必然会非常多,因为想把主数据统一在一个系统中去维护管理是很难的,几乎是很难去推动,那必然会有一个离散式的。业务系统作为主数据的权威管理方,它有自己的业务流程来维护相关的主数据,比如HR系统维护人员行政组织,那么ERP系统维护物料生产计划等等,那么会涉及到多来源的数据接入,实时的接入、批量的接入、前端的维护、离线的导入,甚至于集团与二级公司,还有二级公司与集团之间还有上报和下发。

这个过程中会形成一条数据的一个全接入入版本,以时间为轴,无论是任何一个源的写入,是否有权限写入,写入哪几个字段的权限。以及是否与别人有冲突,是否有仲裁、审核,最终形成发布的版本,并且对这其中的每一个的变化,每一个时间戳下的数据管理进行一个明细的留痕。

技术与业务双统一的编码体系

编码是一个老生常谈的问题。相信很多企业都做了统一编码,甚至于不同域都有编码,主数据怎么来解决编码问题,我们认为是双统一的。首先统一的技术标识这个是必然的,否则怎么来唯一的标识数据,业务编码不能够作为唯一主键,因为很多的相关的领域的同事有相关技术背景的时候,可以了解到,业务主键是很难解决到重复的问题的,必然有一个唯一的主键标识,唯一的字段,并通过这个技术标识去映射多元的数据。实现一物一键,我们可能不叫一物一码了。因为现在这个情况下。一物一码是比较难的,甚至一物多码,我们必然要实现一物一建。并且提供数据的对接服务,这是在技术端通过技术解决唯一性的问题。

那么在业务端是很难一物一码,在实践过程中我们会有很多领域下有不同的编码,这也取决于我们在不同的业务域,不同的业务人员对一条数据的认知不一样,例如在CRM里的客户和在财务里的客户,可能会产生不同的编码。

因为相关的业务人员在使用的时候,他希望通过业务编码一眼就看出来这个数据的特性,所以这里的时候需要做到的是统一的编码规则,编码的映射,能够去解决你不同系统中不同业务场景下的数据的关联的问题,并且跟外部做对接。

类似还有很多,比如说制造业中有上下游的关联,有供应链,例如与下游的营销端贸易端,可能还会跟政府的监管部门,比如海关有相关的进出口报关业务发送,这个的时候企业自身的编码如何与政府(海关)的编码做映射,还可能与外部的合作厂商编码做映射,也是要统一的编码管理。

以数据问题为切入点,形成数据质量持续提升闭环

企业遇到的数据质量问题,需要以数据问题为切入点,去形成质量的持续提升的一个闭环,如何去收集问题,分析问题,包括数据质量差吗?没有录入吗?数据无效吗?获取困难吗?数据缺失吗?等种种问题。

对于每一个问题做分类,质量检查技术实现简单,但取得效果是很难的。第一个是管理的维度如何去推动,第二如何去把问题的分类通过一些我们的办法去解决。这个办法第一,比如对于没有录入的如何去补充,对于找不到的如何去定一个规则,对于很多系统都没有的,什么时候做改造,明确数据的分布,数据的质量规则,清晰的方案,对于数据问题归类分析处理,最后才能形成质量的闭环管理。

所以这里数据质量是一个恒久远的问题,质量问题很难通过技术手段去完全解决,需要通过一套的方案和方法去对它进行一个优化。

实时化、自助化的主数据服务提供

我们希望未来的主数据是可以实时获取的,无论是数仓也好,还是我的业务系统也好,他在需要主数据的时候,提出需求就能够获取到数据。

所以这也与互联网的很多的 API化平台有异曲同工的思路,我们是希望未来能够通过非常细化的数据API把我的主数据实时的提供给所有的需求方,他们能获取到全量的,获取到增量的,获取到它所需要的任何的一个时间片的主数据。

自动化的主数据服务生成

这里提到一个产品要具备的能力,这也是近几年我们致力在这里面深耕的。有别于很多刚才提到互联网的API平台,很多的时候它提供的是一个开发平台,需要实施方根据相关的数据进行一个开发,我们提供的是一整套的解决方案,我可以针对于刚才提到的非常灵活的主数据的模型,模型的名称,中文的说明,属性的类型,自动的生成相关的数据服务,有入参出参,自动的生成相关的一个基本信息的在线页面或者说是文档,所有的对于主数据的需求方都可以以一种统一的视角看到主数据服务,这样例如说未来的主数据对接,不再是To A系统、To B系统、To C系统,每个需求系统一套API,而是有自己的一套标准API,每个系统每个需求方可以上来查询申请授权。

精细权限管控—服务权限与数据权限管控

既然提到了授权,就会提到企业非常关注的一点精细化的权限管控,这也是我们在做很多企业的时候遇到一个非常大的问题。因为很多企业现在越来越重视到数据的重要性。在企业内部,很多系统之间的对接还是一个弱管控的形式。这里主数据平台虽然说不能够去一揽子解决你所有数据安全的问题,但会掌握到核心数据的一个数据安全,提供一个管控的能力和手段。这里包括与提供的每一个API谁能够调用,他调用的请求是否合理。

还有一块很重要的就是对于行权限列权限的一个管控,我的控制到某一条数据,某一列的字段,就控制到某一个单元格的数据,谁能够获取,比如说我的人员主数据有10个字段,生成了1个标准的10个字段的API,那 A系统过来它可能只能获取到6个字段, B系统过来只获取到8个字段,这样其他字段即使需求方知道也无法获取数据,这就是一个非常细化的权限管控。

还有一块非常重要的就是数据脱敏,尤其是客户的主数据,这些对于企业的一个数据安全,客户的隐私,商业机密的保护要求是非常高的。那就这些高敏感的主数据,如何去保障它的安全?我们会严格的控制需求方的权限,你是真的是要字段的全部的信息吗?

如果说你要的其实只是一部分信息,比如说像我们现在做的很多的一些政务的场景,需求方做人员的老龄化分析,申请身份证号码字段,本质是需要人员的年龄,其实我可以把身份证号的一部分去脱敏,只提供其中出生年月这样年龄表示信息,类似于这样的场景下,企业的一些工艺参数也可以进行相关的脱敏。还有,现在对于很多的乙方开发厂商,在给甲方开发实施相关的系统的时候,很多时候开发人员都是能够看到具体的明细的数据的,这也会有一些隐私的安全的一个风险。

这个时候可以通过主数据的脱敏,比如说把身份证号转成一个固定的字符串类似于ABCD…这样的,但是它在不同的数据集里转换的字符串是一致的,这样开发人员拿到这个数据还是可以做关联做开发,但是他看不到真实的数据。当系统真正上线的时候,对接的才是真实的主数据的,没有经过脱敏的。当然这时候开发人员已经无法接触到了,因为已经进入企业的上线环境,进入到运维管控环境,类似如上场景下,主数据的权限管控要求越来越高。

稳定可靠的主数据分布式架构