我经常参与一个组织的MDM程序,当他们在一个失败的项目之后向InfoTrellis请求帮助进行清理,或者开始尝试X,以实现对某些人来说非常困难的目标时。主数据管理实现失败的原因有很多,但是没有一个是由于在这些场景中使用的责备游戏的原因。大多数的失败来自于人们没有准备好的常见问题。
让我们来看看MDM实现失败的几个主要原因。最后,他们可能不会让你感到惊讶,但如果你还没有经历过,你会更好地准备好面对他们。
低估了工作
我从这个开始,因为它引出了许多其他的,并且是一个复杂的主题。评估工作量似乎很简单,但是MDM项目有很多不明显的方面,它们会严重影响时间安排和您的成功。
“这只是一个普通的项目”
首先,MDM不是一个项目,而是一段旅程,或者至少是一个程序。
大多数考虑实现MDM的组织都是大型跨国公司。即使是那些刚起步时规模较小、后来经历了增长的中型企业,也面临着与全球规模的码头相同的问题。尽管一家全球性公司的混乱规模可能看起来要大得多,但与规模较小的公司相比,它们也有多得多的资源来解决问题。
如果我们坚持将MDM party域作为参考点(大多数组织都是从MDM开始的),那么与party信息相关的源或接触点的数量可能是惊人的。你可能有这样的系统:
-管理产品或服务的销售
-管理与你打交道或签订合同的供应商
-提取数据到数据仓库,用于客户分析和供应商绩效
-人力资源系统,以管理员工,也可能是客户
-自助服务客户入口
-营销活动管理制度
-客户通知系统
许多其他的
许多大型组织将拥有所有这些系统,每个系统都有多个应用程序,并且常常有多个系统负责相同的业务功能。所以现在你可能会说,是的,我知道这个,然后呢?您的MDM“项目”需要位于所有这些中间,在很多情况下,由于许多系统是基于遗留大型机的系统,所以您需要保持透明,因为这些系统不允许更改。
MDM可以用于组织正在进行的许多转换计划,以替换陈旧的遗留系统,并迁移到基于现代分布式面向服务体系结构的解决方案。
大爆炸永远不会成功
现在我们已经看到了MDM问题的潜在大小,让我提醒您不能一次完成所有工作。当然,你可以计划你的大规模转型计划并执行它——但如果你曾经真正做过其中的一个,你就会知道它比看起来要困难得多,结果通常也不像你预期的那样令人满意。你最终会偷工减料,搞砸预算,错过时间线,只为了交付工作而取消工作范围。
在MDM转换项目中出现这种情况的典型原因是什么?
你不知道你不知道什么
您将与所有这些系统进行集成,在很多情况下,您需要保持透明,因为这些系统可能不知道它们将与新的MDM解决方案进行交互。你需要知道的事情如下:
他们使用什么数据?多长时间?多少钱?什么时候?
他们会更新数据吗?多长时间?如何?什么?
他们需要知道其他人所做的改变吗?更改通知需要多久发出一次?他们需要知道它改变了吗,或者改变是什么?
这类信息似乎很直接。我没有告诉你任何你可能不知道的事情,但是,当你问这些问题时,你很可能得到的答案是:
“我不知道.”
好吧,文档不是很新(我是出于好意),但是你要去寻找答案。这就引出了下一个问题。
没有足够的资源
这是一个很容易解决的问题。我将雇佣更多的业务分析师,让更多的开发人员来查看代码,让更多的项目经理来保持他们在正轨上。看起来像是一个计划,表面上看起来像是一个显而易见的答案,(忽略了现在找到可用的it人员有多么困难),但是这些并不是问题所在。
你没有足够的主题专家(SME)。
BA、开发人员和其他人都需要您的主题专家的时间。主题专家已经很忙了,因为他们是主题专家。通常没有足够的系统来处理它们,如果您有很多系统要处理,那么您将面临大量的IT和中小企业。
您的中小企业带来的是知识产权。知识产权是成功实施的关键。您将需要您的sme为您的各种系统带来的知识,但是您将需要另一种类型的知识产权,并且可以与一个非常漫长的过程相关联。
通过治理进行数据管理
为了能够掌握您的信息,您需要合并来自多个来源的数据,并且需要清楚地定义这些信息的含义和用法。来自一个来源的看似相同的信息可能有不同的含义。数据治理是能够建立对主数据至关重要的企业数据定义的关键需求。即使在成熟的环境中,这也是一项具有挑战性的任务,并且会消耗大量的时间和资源。
数据治理可能看起来是一项有问题且耗时的工作,但它是一种有效的工具,可用于解决在尝试建立公共主数据集时将面临的其他主要障碍之一。
这是我的数据
许多组织被组织成筒仓。筒仓的设计是为了照顾他们自己的利益,提供资金以维持他们的业务目标,并在资源和资金方面具有竞争力。虽然任何组织的最终目标都是组织的成功,但竖井是根据其本身来衡量其成功的。
MDM实现本质上与基于竖井的组织不一致,因为主数据是对某个业务部门有价值的数据,因此跨越竖井。在许多组织中,危险在于一个特定的竖井比另一个竖井具有更大的影响力,通常与业务的收入线有关。这种权力的过度平衡很容易对主数据实现产生不适当的影响,使其成为division X的另一个项目,而不是供所有人共享的企业资源。
数据治理是帮助控制这种情况的关键因素之一。您的数据治理委员会将由所有利益相关者的代表组成,给予所有人平等的代表权。数据治理的跨组织特性也是决策可能是一个困难而漫长的过程的原因,因为它需要跨所有筒仓的共识。
除了企业数据定义之外,主数据管理的另一个重要方面是建立业务规则。
太多的规则
需要涉及业务和数据治理,以建立以下业务规则:
将数据加载到MDM应用程序的ETL过程
从多个来源更新信息
匹配规则
生存规则
规则的建立是为了解决MDM要解决的一个大问题:数据质量。组织希望同时管理负载数据质量和正在进行的数据质量。人们常犯的一个大错误就是试图马上引入太多的规则。
在早期使用过多的规则会对MDM解决方案的初始数据负载产生很大的影响。您已经准备好投入生产,并且很可能第一次尝试实时数据,结果却发现大量记录由于业务规则而被拒绝。您的数据加载现在失败了,您需要回过头来重新考虑您的规则,修改您的ETL过程,然后再试一次。
您最终获得了您的数据加载,您的消费者已经开始使用数据,您的遗留事务正在失败。为什么他们失败了?因为应用程序没有根据业务规则验证输入,也没有收集足够的信息来满足规则。
当然,有一种方法可以降低这种风险,但通常做得不够好,有时甚至根本没有做。
分析(Profiling)什么?
数据分析是一项重要的任务,它有助于理解数据的外观和需要计划的内容。由于您的参与方主数据很可能包含个人身份信息(PII),并且出于安全原因,访问将受到限制,所以常常存在许多分析障碍。您必须克服这些障碍,因为数据分析是预见将使您在未来偏离轨道的问题的唯一方法。
数据概要分析可能是一项重要的任务,因为每个源系统都需要概要分析。随着您对数据的了解越来越多,您将有更多的问题需要回答。所有这些分析都需要时间,并且很可能需要特定资源的时间,因为只有它们可以访问您需要的信息。(资源问题又出现了。)
项目管理是我的问题吗?
到目前为止,还没有听说MDM实现失败的神奇原因。事实上,许多问题似乎与任何IT项目可能失败的典型原因有关:
低估了工作
没有足够的资源
尝试一次做太多事情(包括范围渐变)
发现所需时间
MDM实现的一个不太典型的方面是需要数据治理。数据治理不仅为您提供您试图掌握的信息的企业视图,而且还可以是处理竖井之间的竞争议程的有效方法。
数据治理也是实现持续成功的关键因素之一。由于MDM是一段旅程,而不是一个项目,所以成功实现的一个特征是寿命长。一旦您交付了您的基础,接下来的阶段将在基础上构建并提供更多的主数据覆盖。为了确保实现的持续成功,您将需要数据治理的支持,以确保新系统和对现有系统的升级使用主数据,而不只是创建它们自己的孤岛。
在过去,我们试图实现主数据管理今天所承诺的目标,但是由于缺乏控制和治理,我们最终使用MDM纠正数据蔓延。一旦项目结束,主数据管理的角色就不会结束。认识到必须建立流程和规则,不仅要创建主数据存储,还要维护主数据存储并将其集成到系统中,这一点很重要。主数据管理与新软件产品的安装和配置无关。产品是使工作更容易的推动者。规则、治理过程和实施的建立将为您带来成功。
每一个主数据管理实现都需要的最后一件事是强有力的执行支持,没有它,您几乎注定要失败。您的MDM实现将花费数年时间。你将需要持续的资金和支持才能踏上这段旅程,而只有高管才能提供这种程度的支持。组织成竖井的组织常常不能很好地协同工作,虽然数据治理可以在这种情况下提供帮助,但是有时可能需要一些干预来确保事情在预期的时间轴上朝着正确的方向发展。
你的主管是董事会内外的关键资源。在董事会会议室,您需要t champion这样的人,他对MDM实现将为组织带来什么有远见,并随着时间的推移不断前进。离开董事会会议室后,你将面临相互竞争的议程、数据囤积、优先事项的转移,以及试图协同工作的筒仓。这里的执行影响力可以用来确保每个人继续朝着共同的目标努力,并在合理的时间内提供实现gaols所需的资源。
本文 :https://architect.pub/data-architecture-data-governance-proactive-approach | ||
讨论:知识星球【首席架构师圈】或者加微信小号【ca_cto】或者加QQ群【792862318】 | ||
公众号 | 【jiagoushipro】 【超级架构师】 精彩图文详解架构方法论,架构实践,技术原理,技术趋势。 我们在等你,赶快扫描关注吧。 | |
微信小号 | 【ca_cea】 50000人社区,讨论:企业架构,云计算,大数据,数据科学,物联网,人工智能,安全,全栈开发,DevOps,数字化. | |
QQ群 | 【285069459】深度交流企业架构,业务架构,应用架构,数据架构,技术架构,集成架构,安全架构。以及大数据,云计算,物联网,人工智能等各种新兴技术。 加QQ群,有珍贵的报告和干货资料分享。 | |
视频号 | 【超级架构师】 1分钟快速了解架构相关的基本概念,模型,方法,经验。 每天1分钟,架构心中熟。 | |
知识星球 | 【首席架构师圈】向大咖提问,近距离接触,或者获得私密资料分享。 | |
喜马拉雅 | 【超级架构师】路上或者车上了解最新黑科技资讯,架构心得。 | 【智能时刻,架构君和你聊黑科技】 |
知识星球 | 认识更多朋友,职场和技术闲聊。 | 知识星球【职场和技术】 |
领英 | Harry | https://www.linkedin.com/in/architect-harry/ |
领英群组 | 领英架构群组 | https://www.linkedin.com/groups/14209750/ |
微博 | 【超级架构师】 | 智能时刻 |
哔哩哔哩 | 【超级架构师】 | |
抖音 | 【cea_cio】超级架构师 | |
快手 | 【cea_cio_cto】超级架构师 | |
小红书 | 【cea_csa_cto】超级架构师 | |
网站 | CIO(首席信息官) | https://cio.ceo |
网站 | CIO,CTO和CDO | https://cioctocdo.com |
网站 | 架构师实战分享 | https://architect.pub |
网站 | 程序员云开发分享 | https://pgmr.cloud |
网站 | 首席架构师社区 | https://jiagoushi.pro |
网站 | 应用开发和开发平台 | https://apaas.dev |
网站 | 开发信息网 | https://xinxi.dev |
网站 | 超级架构师 | https://jiagou.dev |
网站 | 企业技术培训 | https://peixun.dev |
网站 | 程序员宝典 | https://pgmr.pub |
网站 | 开发者闲谈 | https://blog.developer.chat |
网站 | CPO宝典 | https://cpo.work |
网站 | 首席安全官 | https://cso.pub |
网站 | CIO酷 | https://cio.cool |
网站 | CDO信息 | https://cdo.fyi |
网站 | CXO信息 | https://cxo.pub |
谢谢大家关注,转发,点赞和点在看。