「数据架构」MDM实现失败的主要原因

本文涉及的产品
数据管理 DMS,安全协同 3个实例 3个月
推荐场景:
学生管理系统数据库
简介: 「数据架构」MDM实现失败的主要原因

组织的MDM程序,当他们在一个失败的项目之后向InfoTrellis请求帮助进行清理,或者开始尝试X,以实现对某些人来说非常困难的目标时。主数据管理实现失败的原因有很多,但是没有一个是由于在这些场景中使用的责备游戏的原因。大多数的失败来自于人们没有准备好的常见问题。

让我们来看看MDM实现失败的几个主要原因。最后,他们可能不会让你感到惊讶,但如果你还没有经历过,你会更好地准备好面对他们。

低估了工作

我从这个开始,因为它引出了许多其他的,并且是一个复杂的主题。评估工作量似乎很简单,但是MDM项目有很多不明显的方面,它们会严重影响时间安排和您的成功。

“这只是一个普通的项目”

首先,MDM不是一个项目,而是一段旅程,或者至少是一个程序。

大多数考虑实现MDM的组织都是大型跨国公司。即使是那些刚起步时规模较小、后来经历了增长的中型企业,也面临着与全球规模的码头相同的问题。尽管一家全球性公司的混乱规模可能看起来要大得多,但与规模较小的公司相比,它们也有多得多的资源来解决问题。

如果我们坚持将MDM party域作为参考点(大多数组织都是从MDM开始的),那么与party信息相关的源或接触点的数量可能是惊人的。你可能有这样的系统:

  1. -管理产品或服务的销售
  2. -管理与你打交道或签订合同的供应商
  3. -提取数据到数据仓库,用于客户分析和供应商绩效
  4. -人力资源系统,以管理员工,也可能是客户
  5. -自助服务客户入口
  6. -营销活动管理制度
  7. -客户通知系统

许多其他的

许多大型组织将拥有所有这些系统,每个系统都有多个应用程序,并且常常有多个系统负责相同的业务功能。所以现在你可能会说,是的,我知道这个,然后呢?您的MDM“项目”需要位于所有这些中间,在很多情况下,由于许多系统是基于遗留大型机的系统,所以您需要保持透明,因为这些系统不允许更改。

MDM可以用于组织正在进行的许多转换计划,以替换陈旧的遗留系统,并迁移到基于现代分布式面向服务体系结构的解决方案。

大爆炸永远不会成功

现在我们已经看到了MDM问题的潜在大小,让我提醒您不能一次完成所有工作。当然,你可以计划你的大规模转型计划并执行它——但如果你曾经真正做过其中的一个,你就会知道它比看起来要困难得多,结果通常也不像你预期的那样令人满意。你最终会偷工减料,搞砸预算,错过时间线,只为了交付工作而取消工作范围。

在MDM转换项目中出现这种情况的典型原因是什么?

你不知道你不知道什么

您将与所有这些系统进行集成,在很多情况下,您需要保持透明,因为这些系统可能不知道它们将与新的MDM解决方案进行交互。你需要知道的事情如下:

  • 他们使用什么数据?多长时间?多少钱?什么时候?
  • 他们会更新数据吗?多长时间?如何?什么?
  • 他们需要知道其他人所做的改变吗?更改通知需要多久发出一次?他们需要知道它改变了吗,或者改变是什么?

这类信息似乎很直接。我没有告诉你任何你可能不知道的事情,但是,当你问这些问题时,你很可能得到的答案是:

“我不知道.”

好吧,文档不是很新(我是出于好意),但是你要去寻找答案。这就引出了下一个问题。

没有足够的资源

这是一个很容易解决的问题。我将雇佣更多的业务分析师,让更多的开发人员来查看代码,让更多的项目经理来保持他们在正轨上。看起来像是一个计划,表面上看起来像是一个显而易见的答案,(忽略了现在找到可用的it人员有多么困难),但是这些并不是问题所在。

你没有足够的主题专家(SME)。

BA、开发人员和其他人都需要您的主题专家的时间。主题专家已经很忙了,因为他们是主题专家。通常没有足够的系统来处理它们,如果您有很多系统要处理,那么您将面临大量的IT和中小企业。

您的中小企业带来的是知识产权。知识产权是成功实施的关键。您将需要您的sme为您的各种系统带来的知识,但是您将需要另一种类型的知识产权,并且可以与一个非常漫长的过程相关联。

通过治理进行数据管理

为了能够掌握您的信息,您需要合并来自多个来源的数据,并且需要清楚地定义这些信息的含义和用法。来自一个来源的看似相同的信息可能有不同的含义。数据治理是能够建立对主数据至关重要的企业数据定义的关键需求。即使在成熟的环境中,这也是一项具有挑战性的任务,并且会消耗大量的时间和资源。

数据治理可能看起来是一项有问题且耗时的工作,但它是一种有效的工具,可用于解决在尝试建立公共主数据集时将面临的其他主要障碍之一。

这是我的数据

许多组织被组织成筒仓。筒仓的设计是为了照顾他们自己的利益,提供资金以维持他们的业务目标,并在资源和资金方面具有竞争力。虽然任何组织的最终目标都是组织的成功,但竖井是根据其本身来衡量其成功的。

MDM实现本质上与基于竖井的组织不一致,因为主数据是对某个业务部门有价值的数据,因此跨越竖井。在许多组织中,危险在于一个特定的竖井比另一个竖井具有更大的影响力,通常与业务的收入线有关。这种权力的过度平衡很容易对主数据实现产生不适当的影响,使其成为division X的另一个项目,而不是供所有人共享的企业资源。

数据治理是帮助控制这种情况的关键因素之一。您的数据治理委员会将由所有利益相关者的代表组成,给予所有人平等的代表权。数据治理的跨组织特性也是决策可能是一个困难而漫长的过程的原因,因为它需要跨所有筒仓的共识。

除了企业数据定义之外,主数据管理的另一个重要方面是建立业务规则。

太多的规则

需要涉及业务和数据治理,以建立以下业务规则:

  1. 将数据加载到MDM应用程序的ETL过程
  2. 从多个来源更新信息
  3. 匹配规则
  4. 生存规则

规则的建立是为了解决MDM要解决的一个大问题:数据质量。组织希望同时管理负载数据质量和正在进行的数据质量。人们常犯的一个大错误就是试图马上引入太多的规则。

在早期使用过多的规则会对MDM解决方案的初始数据负载产生很大的影响。您已经准备好投入生产,并且很可能第一次尝试实时数据,结果却发现大量记录由于业务规则而被拒绝。您的数据加载现在失败了,您需要回过头来重新考虑您的规则,修改您的ETL过程,然后再试一次。

您最终获得了您的数据加载,您的消费者已经开始使用数据,您的遗留事务正在失败。为什么他们失败了?因为应用程序没有根据业务规则验证输入,也没有收集足够的信息来满足规则。

当然,有一种方法可以降低这种风险,但通常做得不够好,有时甚至根本没有做。

分析(Profiling)什么?

数据分析是一项重要的任务,它有助于理解数据的外观和需要计划的内容。由于您的参与方主数据很可能包含个人身份信息(PII),并且出于安全原因,访问将受到限制,所以常常存在许多分析障碍。您必须克服这些障碍,因为数据分析是预见将使您在未来偏离轨道的问题的唯一方法。

数据概要分析可能是一项重要的任务,因为每个源系统都需要概要分析。随着您对数据的了解越来越多,您将有更多的问题需要回答。所有这些分析都需要时间,并且很可能需要特定资源的时间,因为只有它们可以访问您需要的信息。(资源问题又出现了。)

项目管理是我的问题吗?

到目前为止,还没有听说MDM实现失败的神奇原因。事实上,许多问题似乎与任何IT项目可能失败的典型原因有关:

  1. 低估了工作
  2. 没有足够的资源
  3. 尝试一次做太多事情(包括范围渐变)
  4. 发现所需时间

MDM实现的一个不太典型的方面是需要数据治理。数据治理不仅为您提供您试图掌握的信息的企业视图,而且还可以是处理竖井之间的竞争议程的有效方法。

数据治理也是实现持续成功的关键因素之一。由于MDM是一段旅程,而不是一个项目,所以成功实现的一个特征是寿命长。一旦您交付了您的基础,接下来的阶段将在基础上构建并提供更多的主数据覆盖。为了确保实现的持续成功,您将需要数据治理的支持,以确保新系统和对现有系统的升级使用主数据,而不只是创建它们自己的孤岛。

在过去,我们试图实现主数据管理今天所承诺的目标,但是由于缺乏控制和治理,我们最终使用MDM纠正数据蔓延。一旦项目结束,主数据管理的角色就不会结束。认识到必须建立流程和规则,不仅要创建主数据存储,还要维护主数据存储并将其集成到系统中,这一点很重要。主数据管理与新软件产品的安装和配置无关。产品是使工作更容易的推动者。规则、治理过程和实施的建立将为您带来成功。

每一个主数据管理实现都需要的最后一件事是强有力的执行支持,没有它,您几乎注定要失败。您的MDM实现将花费数年时间。你将需要持续的资金和支持才能踏上这段旅程,而只有高管才能提供这种程度的支持。组织成竖井的组织常常不能很好地协同工作,虽然数据治理可以在这种情况下提供帮助,但是有时可能需要一些干预来确保事情在预期的时间轴上朝着正确的方向发展。

你的主管是董事会内外的关键资源。在董事会会议室,您需要t champion这样的人,他对MDM实现将为组织带来什么有远见,并随着时间的推移不断前进。离开董事会会议室后,你将面临相互竞争的议程、数据囤积、优先事项的转移,以及试图协同工作的筒仓。这里的执行影响力可以用来确保每个人继续朝着共同的目标努力,并在合理的时间内提供实现gaols所需的资源。

相关实践学习
MySQL基础-学生管理系统数据库设计
本场景介绍如何使用DMS工具连接RDS,并使用DMS图形化工具创建数据库表。
相关文章
|
3月前
|
机器学习/深度学习 数据采集 人工智能
揭秘!47页文档拆解苹果智能,从架构、数据到训练和优化
【8月更文挑战第23天】苹果公司发布了一份47页的研究文档,深入解析了其在智能基础语言模型领域的探索与突破。文档揭示了苹果在此领域的雄厚实力,并分享了其独特的混合架构设计,该设计融合了Transformer与RNN的优势,显著提高了模型处理序列数据的效能与表现力。然而,这种架构也带来了诸如权重平衡与资源消耗等挑战。苹果利用海量、多样的高质量数据集训练模型,但确保数据质量及处理噪声仍需克服。此外,苹果采取了自监督与无监督学习相结合的高效训练策略,以增强模型的泛化与稳健性,但仍需解决预训练任务选择及超参数调优等问题。
146 66
|
1月前
|
存储 大数据 数据处理
洞察未来:数据治理中的数据架构新思维
数据治理中的数据架构新思维对于应对未来挑战、提高数据处理效率、加强数据安全与隐私保护以及促进数据驱动的业务创新具有重要意义。企业需要紧跟时代步伐,不断探索和实践新型数据架构,以洞察未来发展趋势,为企业的长远发展奠定坚实基础。
|
2月前
|
存储 搜索推荐 数据库
MarkLogic在微服务架构中的应用:提供服务间通信和数据共享的机制
随着微服务架构的发展,服务间通信和数据共享成为关键挑战。本文介绍MarkLogic数据库在微服务架构中的应用,阐述其多模型支持、索引搜索、事务处理及高可用性等优势,以及如何利用MarkLogic实现数据共享、服务间通信、事件驱动架构和数据分析,提升系统的可伸缩性和可靠性。
40 5
|
3月前
|
安全 网络安全 数据安全/隐私保护
云原生技术探索:容器化与微服务架构的实践之路网络安全与信息安全:保护数据的关键策略
【8月更文挑战第28天】本文将深入探讨云原生技术的核心概念,包括容器化和微服务架构。我们将通过实际案例和代码示例,展示如何在云平台上实现高效的应用部署和管理。文章不仅提供理论知识,还包含实操指南,帮助开发者理解并应用这些前沿技术。 【8月更文挑战第28天】在数字化时代,网络安全和信息安全是保护个人和企业数据的前线防御。本文将探讨网络安全漏洞的成因、加密技术的应用以及提升安全意识的重要性。文章旨在通过分析网络安全的薄弱环节,介绍如何利用加密技术和提高用户警觉性来构建更为坚固的数据保护屏障。
|
3月前
|
存储 监控 安全
大数据架构设计原则:构建高效、可扩展与安全的数据生态系统
【8月更文挑战第23天】大数据架构设计是一个复杂而系统的工程,需要综合考虑业务需求、技术选型、安全合规等多个方面。遵循上述设计原则,可以帮助企业构建出既高效又安全的大数据生态系统,为业务创新和决策支持提供强有力的支撑。随着技术的不断发展和业务需求的不断变化,持续优化和调整大数据架构也将成为一项持续的工作。
|
3月前
|
机器学习/深度学习 自然语言处理 数据处理
|
3月前
|
Java 数据库连接 微服务
揭秘微服务架构下的数据魔方:Hibernate如何玩转分布式持久化,实现秒级响应的秘密武器?
【8月更文挑战第31天】微服务架构通过将系统拆分成独立服务,提升了可维护性和扩展性,但也带来了数据一致性和事务管理等挑战。Hibernate 作为强大的 ORM 工具,在微服务中发挥关键作用,通过二级缓存和分布式事务支持,简化了对象关系映射,并提供了有效的持久化策略。其二级缓存机制减少数据库访问,提升性能;支持 JTA 保证跨服务事务一致性;乐观锁机制解决并发数据冲突。合理配置 Hibernate 可助力构建高效稳定的分布式系统。
64 0
|
3月前
|
存储 缓存 Java
Android项目架构设计问题之优化业务接口数据的加载效率如何解决
Android项目架构设计问题之优化业务接口数据的加载效率如何解决
44 0
|
3月前
|
存储 安全 关系型数据库
"揭秘!如何设计数据库架构,让信息系统心脏强健无比?一场关于数据效率、安全与可扩展性的深度探索"
【8月更文挑战第19天】数据库架构是信息系统的核心,关乎数据存储效率与安全及应用性能和扩展性。优秀设计需综合考量业务需求、数据模型选择、查询优化、事务处理、安全性和扩展性。首先,深刻理解业务需求,如电商系统需高效处理并增长商品、订单等数据。其次,基于需求选择合适的数据模型,如关系型或非关系型数据库。再者,优化查询性能与索引策略以平衡读写负载。同时,考虑事务处理和并发控制以保证数据一致性和完整性。最后,加强安全性措施和备份恢复策略以防数据风险。通过这些步骤,可以构建稳健高效的数据库架构,支持系统的稳定运行。
36 0
|
3月前
|
消息中间件 缓存 Kafka
图解Kafka:架构设计、消息可靠、数据持久、高性能背后的底层原理
【8月更文挑战第15天】在构建高吞吐量和高可靠性的消息系统时,Apache Kafka 成为了众多开发者和企业的首选。其独特的架构设计、消息可靠传输机制、数据持久化策略以及高性能实现方式,使得 Kafka 能够在分布式系统中大放异彩。本文将通过图解的方式,深入解析 Kafka 的这些核心特性,帮助读者更好地理解和应用这一强大的消息中间件。
132 0