HUD's CIO Understands Importance of Data

Loraine Lawson
Slide Show

10 Critical Myths and Realities of Master Data Management

Prevalent myths surrounding MDM alongside an explanation of the realities.

Integration and BI consultant Joyce Norris-Montanari owes me a bottle of ibuprofen. Thanks to her recent post, I was compelled to bang my head against my desk and now I have a major headache.

 

Why on earth would I even mention such a post? Because it's one of those stories so ridiculously stupid, you have to share it with everyone.

 

She writes that a friend recently finished installing master data management at his company. What pressing business problem prompted this project? How many long hours did they spend preparing for MDM, which we all know is a discipline and not a tech solution you buy?


Clear a spot on your desk, because that's the crazy part. Here's why, according to Norris-Montanari's post:

Upper management told his group to keep the software installed and working. So they did! They don't have any data for the software to use yet, but the software is installed. Now the hard part begins, which is to find those groups in the enterprise that want integrated master data.


Seriously? Do they just have money to burn or something? Because, hey, share some of that waste over here, buddy!

 

Norris-Montanari manages not to mock them at all, which makes her a better person than me because that is one of the dumbest things I've heard this week, and that's saying something, because I read the newspaper's letters to the editor.

 

Let me break it down for business and IT alike: If that's your MDM implementation plan, you're doing it wrong.

 

This is not my opinion. It is fact. (Okay, it is my opinion, as well as the opinion of almost everybody else in the industry, but I believe it could be proven as factual if someone had the opportunity to do it.)

 

Alas, that's not the only silliness that crossed my inbox this week. I also noticed Department of Defense auditors predicting the Army's new ERP project - which would become one of the world's largest public sector ERPs - "is at high risk of running even more over schedule and budget," according to a recent FierceGovernmentIT article. Now, ERP of any ilk running over schedule and over budget is not surprising - it's practically part of ERP's definition - but what really chaffed my chaps is why:

In a report dated June 15, the DoD OIG (Office of Inspector General) finds that the financial management system known as the General Fund Enterprise Business System continues to lack a detailed data conversion plan and supported cost estimates. ... In response to auditors' 2008 report, the Army comptroller said it would prepare a detailed plan--but the document presented to auditors for this audit did not address data conversion for at least 49 non-Army systems that process Army data, and did not mention the problem of historical transaction data--other than to say that historical data won't be converted.

And the Army's not alone: The entire armed forces is struggling with ERP integration and data migration issues, it seems.

 

Okay, it's not as obvious as the MDM fail I mentioned first, but it's not exactly an unexpected problem, either. Way back in 2007, Bloor Research found that data migration is a major cause of ERP projects running over budget and over schedule when it studied data migration projects at Global 2000 companies in the "context of wider enterprise application projects." Among its findings at the time: Data migration costs overrun averages in excess of 30 percent of the total project budget and - huge gasp of surprise, everyone - more than half say it happened in part due to "a failure to properly scope the project in advance."

 

At least the military's not alone in making this blunder. Despite the fact that experts have known about this issue since at least 2007, the Enterprise Resources Technology Group recently wrote that data migration/conversion costs are one of the five most-often overlooked costs of ERP.

 

Why share these failures? To my way of thinking, there are two ways to learn about mistakes: You can learn for yourself or you can learn from someone else's mistakes. Personally, I prefer the latter. It's cheaper, quicker and causes fewer headaches.



More from Our Network
Add Comment      Leave a comment on this blog post

Post a comment

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Subscribe to our Newsletters

Sign up now and get the best business technology insights direct to your inbox.


 
Resource centers

Business Intelligence

Business performance information for strategic and operational decision-making

SOA

SOA uses interoperable services grouped around business processes to ease data integration

Data Warehousing

Data warehousing helps companies make sense of their operational data


Thanks for your registration, follow us on our social networks to keep up-to-date