I would go a little further however, and I might offer up: “ERP applications should be designed and implemented to support the needs of the Enterprise – and that basically means that the ERP of the last 15 or so years comes up short in this regard”.

I have blogged a number of times on the issue that “ERP” does not mean the same thing for every user (let along reader).  But, putting that aside for now, ERP is not (for the vast majority of users) an solution to provide business process or application support for the entire enterprise.  Despite the millions we have all spent on “ERP” it is any or all of the following:

a)    A big sucking sound that takes up 5 or more years of my life

b)    A bus ticket for consultants to get their children through college

c)    Sold as a single application tool for my business, but never was

d)    Just a pretty important, but not the only, business application with its own humongous data model (among other data models in my business).

In reality ERP was not a bad thing – it just get’s called many bad names because it is just such a fluid concept and as such, it gets all the flack.  If it really was one single application stack with one single data model, that did support every major business process that drives the organizations, it would not attract all the headlines.  Also we would be on the moon since there would not be any oxygen left due to the sucking sound.

Seriously, I think that ERP was really only ever a means to “single version of the financial transactions”.  And I think ERP has proven that it can do this – hands down.  It can also do other things, such as help with HCM, and indirect material procurement.  But when it comes to business processes spanning CRM, SCM, PLM, Procurement (direct materials/goods for resale) ERP started to shows its weaknesses and variability.  ERP became a meal, not just a single flavor.

And Don’s article nicely highlights how the complexities we get with ERP lead to complexities in business intelligence.  And things like MDM, itself a governance program for some information assets such as master data, will (over time) help to get the data cleaned up at source.

My favorite peeve concerns how EVER business application should do a better job of managing its own data.  Some of the data in applications is shared with other applications – and some of this is master data (such as product, customer, etc).  However, these same applications use/publish/consume other data – that is specific to it.  This is NOT master data; though some may call it “application master data” or as I would prefer to call it, “application specific data”.  I am sure some of you fall into either (or other) camps.  The problem is, if we call it “master data” it becomes very confusing: what does MDM concern itself with – managing for re-use “customer” across all applications, or managing all data in all applications?  The former seems to be something we can do; the latter sounds like something we tried to do many times before and can never do well.  Maybe the latter follows from the former.  Anyway, I hope the note is popular.  It is certainly a popular question. 

On the political front, I seem to have struck a chord.  On December 9^th I commented on how Angela Merkel was saying things that were unhelpful with respect to long term safety of the Euro.  It turns out that some Germans in her own parliament are saying the same things.  Maybe with the right pressure Merkel will get a new vision.  If not, I fear that the Euro will suffer, and as a result Europe’s economic situation will worsen.  The article in the US print edition of the Financial Times today highlighted how the European Central Bank will, if things continue, become Europe’s (largest) “bad bank”.  A “bad bank” is a concept that separates the high risk (even near worthless) assets (in this case bonds) from those that have a future.  To think that a central bank could absorb “bad assets” to such a degree is hard to imagine – but it is good that some folks are talking about this risk.  If any of us had more spine, we would actually say that some European countries are actually bankrupt!  Already economists are looking at the value of debt that has to be covered in 2011.  And it’s not a pretty picture.

For most “ERP” users, this data (describing products, customers, vendors, materials, assets etc) get’s copied over and over even as part of an ERP implementation!  Only a few organizations can run their entire business on one application suite; most organizations end up with several, or many.  As such, in the early ERP days, the notion of “mastering” such data was nonsense.  The problem, though factually it existed, had not become nuclear.  As ERP began to take off, and it became an important part, if not the most important part, of an enterprise application strategy, the lack of such “single version” did start to cause more chronic business pain.  In some cases, it became acute – and finally MDM as a discipline was made explicit – and with it, the notion of “master data”.

So the article made perfect sense to me.  Implementing ERP, consolidating EPR, coping with ERP, does not make master data appear automatically.  In fact, for many organizations, the addition of “ERP” in the stack makes things a whole lot more complicated.

Some early travels have excited me again and forced my attention back to MDM and ERP.  More precisely, the issue with how to organizations decide what is “mastered” in ERP and what is mastered elsewhere.  It seems that there are so many different definitions of “ERP”;  sometimes it is a s suite of applications that share a common data store (think Epicor, Soft Solution) and yet sometimes it is a heterogeneous set of application suites (think SAP).  Yet, “ERP” is the term in the question so users think that there must be one answer to the question.

What makes this even more complex is that “one systems master data is another systems reference data”.  Or, if you like, “data might treat one system as a system of record and another as a system of reference”.  Any business application could author master data; and another may need a copy for its own purposes.  Are both versions of the data “master data”?  Technically yes – but one has to be the “mastered” data (i.e. authored) and the other has to be a subscription to the mastered data; or a copy of it.  So sometimes ERP is the place where such data is authored; but increasingly with the rise of MDM, ERP is not.  But this does not mean that ERP does not need a copy of this data.  But this copy is what is causing the confusions.

Please, users, if you have a legitimate MDM goal or strategy (achieve “single version of the truth across your organizations), assume MDM spans your ERP applications, and do not make the mistake of saying, “ERP masters master data” until and if you figure out that you don’t need or have a separate master data hub.  Just for the record I will say this: the majority of so-called “ERP” users will need a separate master data store of some kind.

Here’s a blog on a favorite topic of mine that comes up a lot – especially in ERP land but is applicable to many, if not all, MDM users.

Should MDM applications be extended/developed with business application logic (as a single application)?

• Yes: Given MDM is fast becoming a much better place where good, clean master data is governed, why not be efficient and build business application on it?  Surely this is efficient and effective, and means that over time users can sunset legacy applications that are remote from the (master) data.
• No: This is history repeating itself and is the reason why MDM came about in the first place!  No single system or application will be capable of supporting the needs of the entire business.  Just look at ERP!  Before you know it another data store will be created “in the interests of speed” or flexibility or some other reason, and we will be back to where we started: larger and larger application stacks with their own copy of the (master) data.  Separate the (master) data, once and for all, from the application from whence it came.

MDM results in the separation of (master) data (governance) from the application that originally (for the last 30 years) created it.  It is because we deployed each application with its own copy of the (master) data that we got into this mess in the first place.  This notion of separating business application from master data is however an ideal; it is not where we start from but it is the place organizations are headed toward, slowly.  In some places (think BI, Finance, Procurement) there are places where this separation has not yet taken place.  In CRM, e-Commerce, ERP, SCM, PLM, it is underway to varying degrees of completeness.

Where master data is not yet separated from Applications

There is a follow on question that becomes CRITICAL to MDM’s long term success and adoption.  The question focuses on analytics, and how analytics support all manner of business processes/decisions, as well as those specific to supporting MDM. 

The business analysis needed to support (master) data governance is DIFFERENT to the analysis a business user makes that uses master data!  In finance, a user might play with various “what if” scenarios for evaluating re-reporting annual sales using different reporting schemes.  This is what Hyperion DRM does; even though Hyperion DRM also supports hierarchy management.

This situation – adding business application support/logic to MDM capabilities has been observed in one part of MDM already, that of MDM of product data, or Product Information Management (PIM).  Old PIM vendors (before we talked about MDM) were adding all manner of business application logic onto their systems, such as the screens needed to support the launch of a new product, or product catalog views for use by merchants selling to customers through different channels. 

For governance to work well in a sustainable manner, architecturally it needs to be separated from the business application domain.   IT will have to resist the pressure and only add critical capabilities (such as search) that could be called as a service be remote applications.  If not, we (users) run the risk of duplicating their governance capabilities and the data along with it, and hence we will be back where we were when MDM emerged.

1. Should I “do” MDM before, during, or after, I “do” ERP?
2. How do I “do” MDM with an ERP migration/implementation/rationalization?

The answer to both questions actually depends, in part, on what is meant by “ERP”.  Some users use the term “ERP” to describe the intention of “source all solutions from a primary/preferred vendor”.  Some users use the term to describe “a single data/process model”; yet more assume ERP means “a single business application suite on which to run an entire business”.  These are three different things, and this explains why the MDM question is not simple.

However I can generalize the following observations:

Most, if not all, “ERP” vendors do not call MDM out as a separate work-stream in their ERP road mapping or blue printing.  This makes sense; MDM evolved after ERP did.  However many tasks and activities in ERP overlap with MDM.

• Most, if not all ESPs that help you implement MDM do not call MDM out separately from the ERP design either, for the same reason as for ERP software vendors.
• ERP, when either a vendor strategy or an application suite strategy, is most likely nothing other than one of many blobs of application and data.  Unless ERP means “a single, enterprise wide data and process model” then ERP is just another blob; albeit a pretty large one in many cases. As such the discipline of MDM is needed whatever the status of the ERP roll-out.

So the recommendation is most likely this: If you have time and money, look to carve an MDM work-stream out of any ERP road map, in order to create/govern master data across but independent of ERP.  It maybe that your MDM program starts and ends with ERP (data) in the short term, but MDM is broader than ERP.   The ideal state is to plan an explicit MDM work-stream offset by 2 months, ahead of the ERP program.  The MDM work will service the needs of the ERP users more holistically and in fact make the ERP implementation, migration, or consolidation, easier.

I have taken many inquiries that explore this topic, and I don’t think we have written a short, specific note that says what I say above.  I need to write the note, and fill in the details and options.  But my colleague Bill Swanton get’s pretty close with a note, “MDM for ERP Requires a Different Mind Set”.

Bottom line: If you “do” ERP first, and think you can “do” MDM afterward, you will re-work a lot of ERP and it will cost you a lot more.  Worse, you probably won’t “do” MDM for a long time since the ERP thing will have to be used a lot in order get the return you wanted from its large investment.  The motivation to architect your information properly will be low down the list…

I had a great day today with end users.  In fact days like this make it great fun to be an analyst.  The bad news is you get to learn a lot of stuff in a very short period of time; and such data points have to be reconciled to recent and more historical experience, data, and analysis.  I spotted a couple of interesting stories I wanted to share with you.

One user explained their terrible and current experiences with outsourcing aspects of IT and “cloud” offerings.  This user’s organization is in the middle of a major IT infrastructure outsourcing program with a large, reputable vendor.  The user had been maintaining 15+ or so data centers around the world supporting large global ERP installations and other business applications.  With one contract, and one SLA (over simplified, I know), the user had “handed over the keys of the data centers” to the vendor.  All well and good, you might think.

Problem: Some time later the business wishes to make changes to its business processes.  This means application architecture and information architecture have to change.  This results in a change in the configuration of the applications.   This is a pain because the IT, no longer in control of this stuff, has to go cap-in-hand to the 3^rd party provider and schedule all manner of meetings to design requirements and get the vendor to re-configure the systems.  This is not a quick process and in fact, in this case, results in wholesale changes in the basic agreement between user and outsourcer, since original SLAs are not sufficient for this “new” requirement.  As if a business’s processes never changes!

Now IT, still in the throes of paying and standing up a huge decision, is realizing that major hindrances have been established.  Business is not happy with IT (again) and long term, unless resolved, IT’s ability to enable business performance will be hampered.

The Woe of IT – Got to Start Running, Now

Another user explained how really successful his roll-out of cloud based email.  This user’s organization has many thousands of users now live, on a global email solution, managed in the cloud.  IT is no longer bound and hamstrung managing what is basically a low tech, relatively simple, near commoditized service.  IT looks like a hero; business is happy since the service is run efficiently, and everyone is happy.  Well, almost.  Two issues stand out – one good, one bad.

The bad news is this: If the business ever wanted to “merge” or align business processes/data (and hence business applications that represent business processes) with data managed in their email systems (some vendors like Microsoft, Oracle and SAP do this between messaging/mail and business apps like ERP) then a new level of IT complexity has emerged.  The data models and integration mechanisms, let alone governance, would have to span to business models and landscapes, which are not under the control of one organization.  This is not a show-stopper – not everyone wants to merge email with ERP; but the barrier is there nonetheless.  The barrier is fictional but exists when and if the need to integrate processes and data from in-cloud to out-cloud.

Now the good news: This user has figured out something very interesting.  The outsourcing of Email was a great success because, as the user pointed out, there was no configuration to “email”.  It is a standard process, highly commoditized.  So outsourcing of “out of the box” functionality made perfect sense.

The previous story above – the dark side of (cloud) outsourcing – highlights the complexities when non-commoditized, or applications that need revisions and configuration changes, are outsourced.  The first example highlights a fallacy: outsourcing/cloud makes perfect sense when commoditized services (email, CPU processing power) are identified.  When processes, applications and/or data have to change, and possibly frequently, a whole new level of complexity emerges.  And this complexity can be significant – even to the point of eliminating any savings that justified the outsourcing in the first place!

Lastly, the real benefit to this second user scenario is that the CIO in this instance has recognized the value IT should be providing the business.  The old days were focused on email; the future is focused on innovation.  This CIO has removed legacy work from his IT stack (and team) and has freed himself, and his team, to now sit with the business and explore new ways to help the business compete and win in its chosen market.  IT can focus on innovation with the business, not managing the trash.  IT can help lay new tracks, and not worry about keeping the train on time (as much).

The conclusion?  With the pressure on IT, in many cases with a smaller staff to a year ago, there is a race being run.  Leaders/CIO’s need to identify commodity processes and services ASAP and outsource where possible, being careful not to readily outsource complex processes and services that may need to change dynamically in support of business change.  Winners of this race will do this first, and free up brain power and money to embed themselves in the business.  Losers will be stuck governing email.  Get running.

Of course, CRM and ERP (and other application suites) are the reason WHY we are talking about MDM; these applications were designed in an era when there was no need to take account of information requirements ACROSS the enterprise.  These applications represent silos of data supporting specific applications.  It is because we “did” things like ERP and CRM that we need MDM…

Over the last few weeks I have met with many end user organizations that continue to struggle with “making MDM work well with ERP” systems.  And when say ERP systems, I mean “any business application”.  The problem is that many, if not all, business application bring with them baggage that includes data validation and other business rules that govern how data, including master data, is entered.  Sometimes this means rules that interact with a user when they sit in front of a screen adding a new product code; other times it means rules that are involved when a file is electronically received from a supplier; other times it is parsing and cleansing (and enrichment) of data as (order management) transactions hit up against a customer master file.  In all cases, rules exist in business applications.  The problem is, when an organizations decides that MDM is in their future, they soon have to wrestle with the “where do I author” and “where do I validate” master data.  And business applications just don’t get along with each other, let alone MDM solutions.

This is, of course, not new news to you.  Ever since the deployment of the second business application, back in the middle 1970’s, master data and associated rules was replicated.  The problem has been festering away for years; it has become for many organizations a chronic problem, not an acute problem.  Hence the insidious part of this is that though IT might perceive there is a need for MDM, the business may not see it as clearly.

So what will the future hold?  We came up with the idea of applications that will be “MDM aware” a few years ago.  The concept is not exactly earth-shattering, but it certainly is important.  If we think about how to create an environment, probably services based, where applications “come and go” and a common, shared infrastructure takes account of where data is, where it is needed, where it is created, and where it should be used, we can figure out what needs to change in application architecture.  As such, “MDM aware” applications are those that recognize that MDM as a distinct discipline will emerge in their environment, and to “play well with it”, they need to change.  

• That part of the data model that represents master data, and applications specific master data, needs to be separated, and externalized, so that 3^rd party metadata management, MDM, and newly emerging governance applications to identity, reconcile and manage data design.
• Data reconciliation and harmonization tasks, centralized in MDM solutions (for master data) need to have external applications publish and subscribe to the MDM hub.  This may need some mature service bus; but at least the idea that, at attribute level, publishers and subscribers need to be explicitly modeled and supported in MDM, is clear.
• Governance applications, such as those evolving in the MDM market, need to model more than just master data for which they are directly responsible for. Governance needs to be aware of application specific data; even if stewardship is concerns with management of day to master data.  As master data definitions change, as the business change, so governance tools need to support the dynamic needs of managing master data.

This might seem pie-in-the-sky stuff, and we need to realize that this is not another attempt at wall to wall data modeling, or universal data modeling.  This is focused; this is specific.  It starts with master data, and needs to be aware of the immediate surroundings, in order to sustain application needs, and to interact with the future changing environment.

It will take a long time for “MDM aware” applications to emerge, but emerge they will.  We know of a few that are capable of such distinction, even if the MDM tools they integrate too are not yet mature enough to manage the data within them.  But if business is to achieve and sustain “single view” across a complex, heterogeneous landscape, this has to happen.  Maybe it will start in earnest with “vendor compliance” programs; or large dominant industry leaders requiring it in their architectural blue prints.  But it will happen.

Will we all be a lot greyer and older?  What do you think?

• Kristian Steenstrup published a note, The Value of Asset Intelligence for Utilities, where Kristian explores “single view” of asset data.  IT systems can provide the support utilities needed to improve the approach to asset management from inception, construction or acquisition, through to performance and investment decisions. This research provides a full explanation of the emerging components of a complete asset management view.  This “360 degree” view of asset aligns nicely with our idea of a master data lifecycle.  Master data (of all kinds) experiences a life cycle that is unique; this is not the same as Information Lifecycle Management, which looks at the physical storage requirements for all data as it moves through a usage pattern.  Asset master lifecycle is unique in that is spans design, construction (two MDM use cases), as well as operations, and analytics (the other two MDM use cases). Utilities are well versed in this lifecycle concept so are in a position to lever MDM quickly.
• Jeff Woods published a note, How to Evaluate Your Vendor’s ERP Strategy, where Jeff provides a comprehensive framework to help you evaluate your vendor’s ERP strategy.  Most enterprises will be tied to their ERP vendors for more than 10 years. Therefore, it pays to make a fully informed decision about those vendors, beyond just functional fit, before you implement or engage in an expansion of your ERP project. This is particularly complex since what is meant by “ERP” has changed over the years.  The original concept was a specific application sported a  “single data model/single process model”.  Over time as those vendors grew in size, and acquired applications and application suites, “ERP vendors” now offer more of a heterogeneous landscape.  SAP and Oracle, the two largest “ERP vendors”, still offer an ERP option from old, but that is far less useful to the majority of users, that now focus on an “ERP strategy” which is “source as much stuff from one vendor”.  Whatever your ERP strategy, this research is great for scoping out the ERP footprint.
• Lastly, Mark Beyer and I wrote a note, The Emerging Vision for Data Services: Master Data and Content Management for SOA.  This is a very important note, because we have not written that much on the relationship between MDM (and Content Management, for that matter) and SOA and this is changing.  This note represents a core piece of research that explains why MDM needs SOA.  There is more to come on why SOA needs MDM.  This note explores the increasing first hand experience users are reporting when they try to create integration between MDM hubs and application oriented data that also stores master data.  Mark and I will be exploring this in more detail at our upcoming MDM summit (see below).

I hope you find the research helpful.  Let us know if you don’t, and why.

Submit a customer case study to win the Gartner MDM Excellence Award 2009!  Go here: http://www.gartner.com/it/page.jsp?id=851612&tab=special&params=pg,zzz.html