Preparations this week focused on getting our last presentations into our editing machine such that they can be formatted, made consistent, and cleaned up for public consumption.  Once the presentations are completed we then begin the slow process if distilling from the key messages, and creating a body of work that is to be published over the next couple of quarters.  Our Summits force us to put on paper all the good, new ideas and content that we have explored with users recently that has not hitherto been published.  These Summits, though a lot of work, are a great way to keep forcing our brains to dump content onto paper, thus freeing up more space for the next set of client interactions.

I had some interesting inquiries this week.  Here is a smattering of the more notable:

On Monday I had a real interesting call with a large industrial end user client that wanted to explore options for – wait for it – “cloud based MDM”!  Well, I knew I was in for an exciting conversation already since that is an odd topic.  I have blogged on this before(SaaS moves the process boundary, does not necessarily change the process, and can make integration of master data more complex); there are not real cloud based MDM offerings today, and really only a very small handful of end users have asked about this – more for interest than anything else.  Only one serious vendor has talked to me about this opportunity – and a credible vendor at that.  But, as I have said before, this is a complex topic.  On the one hand it makes sense that aspects, even all of MDM, should/could go outside the firewall, but the costs to move to that state increase for each and every object.  Those costs relate to integration, synchronization, management and so on.  Application infrastructure gets more complex as a result – until and if enough master data exists outside the firewall at which point the costs, and complexity, fall.  But there must be a tipping point at which this takes place.  Question is – which industry, which business processes, and which master data, are close to that tipping point?  

On Tuesday I had a real good call with an energy user.  This was a large organization with a strong IT shop; I spoke with several senior architecture folks were trying to invigorate their overall information management (IM) strategy.  They knew that MDM played a role in overall IM but they were not totally clear what the relationship was; and they also had an issue with “getting started” – how could they get interest from the business to help them with their IM strategy?  We explored MDM and its connections to IM, as well as to Business Intelligence and Business Applications, and very quickly the client realize that MDM is a great place to start their IM invigoration efforts!  I suspect that I will be talking with them a few times in the next few months to help guide them through their MDM launch.

On Wednesday I presented on MDM vendors to our MDM Special Interest Group (SIG) that is part of our EXP program’s Best Practice Council.  I highlighted the lenses through which we look at the MDM landscape (data domain, use cases, industries) and then talked about how the vendors align both in terms of capability, versus direction.  Many vendors are “good” at one thing/area, and have plans to be “good” at many others.

On Thursday I had a call with an end user firm that I know very well.  In a previous life I worked for an organization that had a business relationship with this client, so I knew something about their business.  They are in consumer goods/fine chemical industry segment, and they are struggling with one aspect of MDM – that being the link between MDM and product design/development, clinical trials, and operations/manufacturing.  The client has a lot of experience with operational MDM for traditional objects, such as customer and product, but this aspect of MDM was more focused on multi-enterprise considerations of sharing complex and confidential information that drive product design, development and acceptance.  

On Friday I joined one of our more interesting virtual research communities (B2B) that span several other formal communities, to explore how business to business is evolving.  My interests, including Supply Chain Management (SCM), concerned both the drivers for why business processes are moving outside the firewall, and with Master Data Management (MDM), what are the barriers and inhibitors to that movement. By exploring one specific phenomenon, related to e-Invoicing, we concluded that we need to identify scenarios by which users can evaluate a longer term B2B strategy.  You might not see the connection – between e-Invoicing and long term B2B strategy – but it is there.  More on this later…

So it was a great week – brimming with client interaction, and research production.  Time for a rest, and a cold one.  Have a good weekend.

I was talking with a sales person today who wanted help to initiate a dialog with a client that we knew had an MDM “issue”.  We explored several ways we could help the client with respect to MDM, and as a result of the conversation, the sales person came to a mighty conclusion: why is there not a simple, standardized, blue print for the client to explain to how to get started, and what the next 2, 3, and 4 steps should be?

This is a good question – but I had to explain to the rep what, to me, was obvious.  Each enterprise might end up with a vision and strategy for MDM that seems to look and smell like the next guy, but that is not really important.  What is important, and now clear, is that each and every enterprise starts their journey toward MDM, from a completely different place!  As such, there is no single blue print, but several, even many.  I explained that there were large patterns emerging, but these are today not detailed enough to provide individual blue print for each firm.

There are some typical places from where large clusters of firms have begun their MDM journey; here are some of them:

• Departmental Madness: Specific business leaders, perhaps VP sales and marketing, report that business performance is poor; initiatives to improve customers service, up-sell and cross-sell, are not delivering on their promise despite significant business and IT investment in new application and business intelligence software.  Root cause analysis shows that IT costs are higher than expected in support of increased data cleansing and integration routines; and the business says it takes too long to get the data to make the right decision.  This “departmental” cluster is complicated in that any number of departments might make the leap between the symptom (poor business performance) and cause (master data quality).  So this cluster is actually many different sub-clusters,
• The Unintelligent Business, or, ‘BI gone wild’.  This cluster has the common characteristic that each business meeting, that includes leaders from different parts of the business, spend more time arguing over the data, the source of the data, or the accuracy of the reports they each use, that business decisions are often left unmade, made with poor data, or elevated to senior management who have even less idea what to do about the decision.  Generally each stake-holder has developed, over some period of time, their own data source and this source is independent, and likely not integrated to any formalized information architecture in the business.  This emerged very often when senior executives encourage internal competition for resources and management attention, between departments, or business units.
• The Sunny ERP Uplands: A mid-size firm, in the specialty chemicals industry, is trying to wrestle with a migration from many legacy and custom made business applications to a single instance ERP strategy.  This is a “me too” strategy since the firms’ competitors seem to have done this already, and the firm believe that this is a necessary step in order to remain “in the game’.  There has been little thought to how ERP supports the firms secret sauce, business competitiveness, process automation, or process innovation.  IT has no idea where the master data is; who really uses it, or why.  There seems to be lots of data everywhere, locked up in applications that do not play well with others, will be ‘sunsetted’ over the next couple of years anyway, and bottom line – business and IT do not have a good working relationship.  IT is distrustful of the business – they do not think that the business really knows what it needs.
• The Kaleidoscope: A large, global financial services firm is trying to migrate hundreds of legacy and ERP applications across several regions. around the glob, over the next 5 or more years.  There are regulatory issues to cope with as there is an additional global BI strategy that supports financial reporting.  The final selection of two large ERP alternative vendor is about to be made; the business seems to be ignorant of the fact that compromises in each case will lead to different parts fo the business being serviced with innovative or best in class capabilities. 
• The Engineer: A large, European automotive parts supplier is being hit with two major issues: the need to reduce substantially its time to market for new parts; and increasingly demand and more complex requests from customers and partners for product related data.  The firm has invested in Product Lifecycle Management and this was thought to be the silver bullet to their product development needs; this did not prove to be the case.  While engineering received some good functionality to meet their design needs, the firm seems to be have been over-sold by the PLM vendor that implied that PLM supports the end-to-end lifecycle of the product.  The firm is now wrestling with how to manage information across the business, across PLM, ERP, SCM, CRM, Procurement, and other systems – including trading partners.

You might see aspects of each of these clusters in your business – and that just proves the point.  Every firm will understand and agree that there is value in having consistent master data (we can even agree that need the principles of MDM in the home – every tried trying to change channel without a good, clean program guide?), but the place from which every firm starts the journey is different, and infinitely complex. 

MDM was very prominent in the vision.  In fact, several of my favorite topics were central to the strategy: MDM, and multienterprise, and B2B.  Inovis is historically what many would call an EDI-VAN but today the vendor has moved “up” a stack of technology (we ultimately call this a multienterprise business process platform) in order to provide value add to its customers.  Such value add includes analytics, order/supply chain visibility, business process improvement/design, and ultimately, full blown multienterprise business applications for B2B collaboration.  It is not easy to assemble this stack; not is it easy to make money from selling the stack – not least because prospects are not really aware of the solution that best fits their problem’.  

One part of MDM emerged from the B2B space.  Some years ago a number of firms “doing” B2B figured out that the data they shared with each other in the EDI and XML transactions were out of sync; that is, the data being pushed and pulled was never always in alignment with either the sender or recipients (or both) internal systems.  It either took to long to keep the systems in sync; or the timing was OK but the quality of the data was not fit for purpose.  

This business impact of this desynchronizing of commonly used data are legion: out of stocks are higher than they should be since recipients are not able to process good received that were not expected (according to the ‘system’); users were not able to develop effective business plans since they were never looking at the right data; customers would create confusion and loss of good will when arguing with suppliers over charge backs that were a result of out of data systems.  The list is endless.  The justification to do something about it was obvious.  So Global Data Synchronization (GDS) was born.  

However, as GDS got going, it was obvious to a few more firms that the basic data inside the firm was so messed up that sending it on to clients was hopeless – until and if the data inside the business was cleaned up.  So achieving a “single view” of product, location, and customer become important.  

So MDM has many drivers, and can offer many benefits to the business, but it is also a pre-requisite to many B2B initiatives.  That is why Inovis is working hard in this area, and some of their earlier acquisitions are beginning to add a lot of good IP to the vendor.  QRS was acquired in 2004 and that vendor had an MDM like engine that was cleaning up, reconciling, and managing apparel information for large swathes of the US apparel industry, in a SaaS based manner.  Between Markets was acquired in 2007 and that vendor was focused on a multienterprise data model centric set of B2B applications.  The current CTO, Erik Huddleston, comes from Between Markets.  These two building blocks, and the rest of the Inovis stack, and existing customer hubs, provide an interesting runway for Inovis in 2009. 

My colleague, and collaborator, Benoit Lheureux, also covers Inovis but more from the enterprise and multienterprise integration perspective.  See Q&A: Hot Questions for Multienterprise (B2B) Integration.

a)     where is the master data mastered?  Has this location moved?

b)     Is the business process different, or is SaaS simply being used to move the boundary of application interchange across the firewall?

So far, all SaaS offerings I have seen really only move the boundary of the processes, and as such, the “what” moves across the firewall changes.  The business process itself is virtually unchanged. 

Secondly, where the master data is mastered has also not changed.  For most firms, though not all, master data is viewed as sacrosanct and is mastered – and protected – behind their firewall.  Only subsets of master data are exposed in any B2B fashion (think of what content goes into an EDI transaction) and there are strict controls over what is hosted or managed outside the firewall.

If the user is not willing to accept the change in costs, both in terms of organization and technology, associated with the movement of master data mastering, and if the processes remain pretty much the same and the boundaries are just moving around, the SaaS offering itself is pretty much a waste of time.  And this last point was the most interesting for me: I represent business users who talk about business process and execution of same; and the knowledge of MDM exposes to me some major issues and challenges with SaaS; yet technologists that are into architecture, SaaS and cloud computing hype, would argue that such (new) applications are “awesome” and “new” and “innovative”.  They may by – but I challenge vendors to explain to business users what is the material benefit to the business in deploying SaaS offerings.

By the way, Happy New Year to you!