Given I focus on Master Data Management, and hence the core of an information governance strategy, I take a general interest in virtually everything SAP has to say where information is consumed, copied, used or produced.  Given the hype around “big data”, mobile, and in-memory computing, that means much of the agenda is relevant.

There is lots to analyst and lots to discuss, but the one thing that stands out for me (during day 1) is that SAP continues to incorrectly present and sell Enterprise Information Management.  I think this is a legacy that remains from the acquisition of Business Objects (yes, that long ago).  You see, as soon as Gartner coined officially the term EIM (I don’t think we invented the practice; we just gave it a fresh new perspective along with a formal term), Business Objects (then still independent) renamed their data integration tools as EIM tools.  This gave the perception that they were the market leader for what is not, in actuality, a market.

Despite this, SAP remains (in my limited view) out of kilter with strategic information management practices.  EIM is not about “serving data, cleaned, ready, for use in BI” (a phrase I heard from an SAP speaker today).  EIM is about managing the right information for re-use, for business valuel across ALL applications and all BI and all mobile and so on.  Yet SAP’s go to market remains a little confused here.  EIM (and perhaps BPM?) needs to broken out from the “Business Analytics” product line and assembled and built to “serve” all systems of record and engagement.

Even the “collaboration” message, presented as part of the glue within the Business Analytics product line, seems disjointed.  Some of the examples shared were from the legacy application domain, or system of record systems.

Byron Banks is talking now.  Maybe it’s all going to change….

I asked Byron one question: Does SAP NetWeaver move over to HANA?  The answer was that SAP is committed to solving its customers’ MDM problems, but SAP has not (yet) committed to moving SAP NetWeaver MDM over to HANA.

Is this the end of the road for NetWeaver MDM?

This was one of those flight where:

• Several folks around me kept falling asleep without one of those nice neck cushions, so their heads nod slowly, then finally fall forward, which wakes them up again.  This goes on for the whole trip – and we have all been there.  It’s not fun for the nodder.
• The guy two rows up was snoring heavily which is so annoying (until you put on your noise cancelling headphones)
• Most other folks were really quiet, not even reading
• The late setting sun was falling quickly yet spreading its orange and then red, and then purple rays through the many half closed window shades
• It was a smooth ride, no bumps, that was very comfortable

I was sitting there, in the middle seat (no upgrade), but with control of the two arm rests.  My noise cancelling headphones were on, and I had music quietly sifting through my mind.  But I was not listening.  My eyes wandered around the cabin, watching the nodding near-sleepers and other folks half-dozing, taking in the almost surreal experience. It was a most enjoyable, physically restful ride- but my mind was running at a thousand miles an hour.  As the cabin grew ever darker and the setting sun beams reddened to mauve and then near darkness, I just drifted from one thought to the next.

I had just met a lot of user organizations, across many industries, across different sizes from massive to large to medium/large, and yet everyone was focused on MDM and information governance, and also many had an ERP context, or a BI context, or a joint ERP/packaged apps and BI context.  Each call was very different – each company being at a different phase of MDM, and each company had a different set of complexities and questions.  It was a testing time for me – but it was SO exciting.

In many of the calls I ended up answering questions by drawing on a white board.  The same pictures emerged over and over again.  Yet some of these pictures have not been documented before.  Yet the logic and the leverage of ideas that brought these graphics and dialog behind them, were spot on and filled the need of the user.  Some dialogs opened up new channels of thinking that have yet to be thought about by many other users.  Some dialogs opened up wholly new questions that I had not thought of.  Yet more concreted some very hot topics, trends or issues in my mind – and made them so clear, so obvious to me now.  These ideas needed attention; I could not park then in short term memory.  It was bursting and so I was not able to sleep or turn off.  I closed my eyes but pictures kept darting across the red colors on my closed eyes.

It is now Friday, and though my physical state is replenishing and looking forward to the evening’s rest, my mind just won’t stop.  New stuff to do; old stuff to re-do; more to update.  I don’t want the day to end.  It is all so obvious:  Data stewardship and MDM are blood brothers.  You need to start EIM with MDM; and virtually no self named EIM program will achieve its aims without MDM.  MDM is for life.  MDM has to be business led else it will be just traditional data integration.  ERP and other large packaged applications do NOT do data stewardship – you are lucky if they do a good job of managing their own data.  ERP (and other large packaged applications) need our help, big time.  Registry styles only go so far in support of information governance and MDM – it may not be the best place to end up at (in every case).  And another – BI is NOT information management!  Try that one out for size… more to come (you can imagine).

PCAST published a report (Report to the President Realizing the full potential of Health IT to improve healthcare for Americas: The path forward) Dec 2010 that suggested that a universal exchange language could help the exchange of health data across the healthcare system while preserving privacy.  This would support the important idea that a person’s health records follow them wherever they go: thus reducing costs overall due to fewer repeat medical tests and processes, and also better healthcare for the individual due to more accurate and complete view of their medical history.  The press release announcing this report said,

Importantly, implementation of PCAST’s recommendations would not require physicians to replace their existing electronic health records systems, virtually all of which could be made compatible through “apps” and other “middleware.” And they do not call for creation of a centralized Federal database of people’s health information or the assigning of Federal healthcare identifier numbers to individuals.

This reads like another classic case for how IT boffins throw the wonders of metadata management at a problem.  Well pardon me for being just a little skeptical, but commercial pressures – that little known thing referred to as the drive for profit and competition – has attempted the same concept and yet it remains elusive.

An article in June’s Health Data Management (Data Exchange: ONC Advisors: Implement PCAST in Pieces) suggested that the vision was great, but not practical.  Specifically,

“We [ONS] are unaware of any real-world environments (either in healthcare or other sectors) where the combinations of technologies envisioned for the end-state have been placed into operation.”

[T]he PCAST recommendations from December are difficult to reconcile without operational examples and concrete plans, and there is an absence of stakeholder consensus about the recommended approach, according to the workgroup.

Taking a leaf out of the commercial sector we can see that we have a great vision that is not clearly tied to stakeholder benefit (or reconciled stakeholder interests), no practical experience of this scale, and no business oriented examples.  Despite the challenges, the ONS does conclude (I think rightly):

The workgroup does recommend establishing a new exchange architecture with a universal exchange language and interlinked search capabilities, coupled with privacy and security safeguards.

This would start by focusing on metrics and promotion of patient portals, where patients can access their “single source of truth” for their medical data using tagged elements (not sure yet who will associate the tags meaningful to me to the actual data widespread across the network).  Additionally the ONS could use electronic health record certification criteria to identify metadata standards for use in identifying transactions in the network.

Bottom line: Great vision but no realizable strategy; needs more work.  And dependent on HER’s.  Which leads to the second article and the cover story for June’s print edition.

The second article explored the state and reason for EHR’s, and the $80 billion question: Can HER’s curtail runaway costs? The bottom line is no, and yes.  I found the article interesting due to its similarities to how we see Master Data Management being adopted in every other industry.  Several contributors smartly identified how EHR’s should be viewed as “revenue neutral” in that one cannot justify the business case for the effort based on the opportunity to “upsell” the patient once full and clear visibility to medical history is available.  This is because implementing EHR’s does not, itself, change behavior.  Like MDM, the change in how the data is created and managed (dare I say governed?) does not alone generate direct business benefit.  It is only through the evolution of line of business processes that such benefits accrue, and those changes cannot come about unless something like EHR’s (or MDM) is adopted.

It so happened that the article did include a couple of contributions from some networks that did report a cost saving from the adoption of EHR’s, and this was primarily a saving in the direct costs for maintaining the basic data.  These were not costs from “doing business” per se, but sizable administration costs as a result of moving from manual and unlinked data within a network to electronic and linked data within the same network.  Like MDM, there are cost savings to be had for IT in lower integration and data management costs (moving from spaghetti integration to hub and spoke).  But also like MDM, there is much less chance of a successful justification for things like MDM and EHR’s purely on a cost basis.  It does happen, but it’s not going to set the world on fire.

The article concluded that EHR’s are a prerequisite for many other good things that we all want to happen to our healthcare systems.  And adopted EHR’s is not easy, and in some cases, may increases costs short term.  Thus EHR’s will remain a challenge and central to how we need to reengineer our healthcare systems.  But if we don’t focus on behavior also (e.g. from productivity to quality) then we will not reap the expected benefits.

We got talking about the scale of the master data in the hub being used.  We talked about how business applications store a lot of data, some that is widely re-used by other applications, and many that are unique to those applications.  We then talked about how master data requirements change over time.  And as we talked, an old epiphany came back to me:   we need to use a maximized metadata model in our MDM program, tied to a minimalist master data model.

After I stated this last phrase the guy I was speaking about said, “exactly that Andrew, that is exactly what we are trying to maintain”.  And though it might sound obvious, and I have written about this before, I felt moved to write it again.  I really need to put this point in research note.  I believe it is obvious, but I also believe that many of us miss the obvious and we get caught up in our own ways of doing things.

In fact this guy went even further: the more business systems and applications we have, the greater the spread of attributed information in the systems (we include hierarchies and dimensions here), the greater the challenge of keeping the master data “minimalized” and the greater the value from doing so. I liked the way this guy was thinking!   I hope he gets to speak at our upcoming Gartner MDM Summit in May:

So there you have it: your MDM technology needs to support a metadata model that is expansive, that models all the master data and also the nearest data to master data, just in case it becomes master data later.  And this metadata model needs to track those additional, non master data attributes that are used in business systems and applications, so you know where they are, and which applications manage them.

The master data model is NOT an attempt at a universal data model; it should be a minimalist model that only stores the bare minimum of widely re-used data. You should resist the tendency to put more into the model; and very definitively avoid putting application specific data in the model.  That would be a bad practice!

If you can get MDM figured out, it becomes a real valuable “first step” in a broader Enterprise Information Management (EIM) strategy.

Interesting also- the writer (Greg Todd) focuses on analytics at Accenture.  Analytics, technologies to help guide and improve effective decision making (thus improving business performance), are as much dependent on data quality in general, and increasingly recognized by users, master data.

While perusing this article, I came up with another: Simplifying IT with Master Data Management and SOA.  Fascinating article, which seems to read nicely inline (mostly) with your view of SOA and MDM.  The hype around MDM remains very high, and it seems the connection between MDM and SOA continues to increase also.  This is key – for MDM as it is for SOA, though business users are still, for the most part, not this far along or even aware….  We all have much more work to do.

Company A – Two steps forward, One steps back

I met with a number of individuals that represented business and IT, across sales & marketing, operations, finance, IT, and BI.  The customer had an objective of formalizing their MDM strategy.  They reviewed several different initiatives they had underway:

• one focused on finance data consolidation (across multiple ERP systems)
• another focused on building a new “customer hub” for multiple CRM systems, including transactional, master and analytical data
• and a third focused on a data integration pilot that built data quality rules into several data integration flows to clean data up as it flows through.  

This firm also has a longer term ERP rationalization strategy underway.  Over several years they have grown through acquisition, and now represents 5 distinct businesses, in US and Europe, each with their own business systems but sharing common customers, and common suppliers.  

During the dialog the team of users realized that governance, process change, and organization change were keys to making MDM a living, breathing, sustained process.  The projects the team had described had no distinct MDM focus, even though master data was being touched over and over again, with each IT and business initiative.  But with now business sponsor, IT was not able to make MDM “stick”. 

Lastly, we explored why there had not been any MDM focus to date.  We learned that the firm, that is predominantly an information oriented company, had no Information Architect or defined information strategy!   This explained a lot.  Though the firm is profitable (the enemy of innovation), there was no single person or role looking at the overall strategy, let alone master data.  But business pressure was mounting that eventually brought enough users together to realize that MDM was going to be needed – so now the next step is first to establish a broader vision and strategy.

Company B – The Sunny Uplands

This firm is a large engineering firm that has also grown through mergers and acquisitions.  This firm also has several ERP systems, as well as large PLM components.  There are separate sales and marketing business units also.

This firm had developed a comprehensive information strategy even though they are a physical products company.  The products this company makes is very complex (ie engineered) and so a lot technical data is used to design and manufacture – and then support – the product.  This skill has led to a good understand of how to ensure data is maintained consistently, and made shareable. 

Additionally the firm also had developed a series of other master data oriented strategies, across supplier, customer, location, and also other data (called reference data) that looks and smells like master data but is not your typical objects (ie exchange rates, units of measure).

The firm had adopted Gartner’s MDM Maturity Model and compared and contrasted their maturity, across all key business units and departments, all master data domains and initiatives, and evaluated their current maturity against vision, strategy, governance, organization process, metrics, and technology.  The firm presented this information to us and was looking for feedback on the overall strategy: 

• How did the approach look?
• Would gaps in the strategy be found if they continued in this way?
• Were there any obvious gaps now?
• How does their status equate to industry norms?
• What else can they do to assure better success with next steps (execution)?

Bottom Line

These two stories were like applies and oranges – both firms have MDM aspirations, both know that MDM can help their businesses and both know that it is needed.  However, two very important take-aways came to me when I compared these initiatives:

• MDM can succeed in isolation to some larger, information management strategy (such as Enterprise Information Management) but it is real, real hard to succeed with MDM    
• Governance, process, and organization is far more important to MDM success then technology

Busy week – closing out an MDM Magic Quadrant; closing out the MDM Hype Cycle, as well as talking to some users about some complex MDM problems.  What else can an analyst ask for…

The document serves as a starting point for any client wishing to understand enterprise information management (EIM) or undertake an EIM initiative. We would recommend that it be read by information architects, information managers, CIOs, enterprise architects and anyone working on a team evaluating or implementing a portal, an enterprise content management system, a business intelligence application, a master data management system, document centric collaboration, eDiscovery, information access or collaboration software.