The topic will be how to “Drive Customer Loyalty with Effective Master Data Management”.

It costs a lot less money to hold onto existing customers than to attract new ones.  But now that your customers have more choices than ever before, you need to give them compelling reasons to stay. Unfortunately, for many organizations, poor data quality leads to an inaccurate view of the customer – decreasing service levels and damaging customer loyalty.

Oracle Master Data Management consolidates, maintains, governs and distributes complete, accurate master data across all enterprise systems. And Oracle’s Siebel Loyalty Management provides the customer insight to help you design loyalty campaigns that maximize the value of all your customer relationships. Seamlessly integrated, Oracle’s solutions offer a powerful combination of high data quality and effective loyalty management.

Register to join the live Webcast on Wednesday, August 17 at 11:00 am Pacific (2:00 pm Eastern) to hear myself (Dan Power from Hub Designs) and David Butler (Senior Director, MDM Marketing at Oracle) discuss how the combination of Oracle MDM and Siebel Loyalty Management can help you:

• Gain an accurate view of every customer with high-quality data and advanced analytics
• Improve service levels with a single, unified view of the customer across every channel
• Boost revenue by maximizing the return from upsell and cross-sell opportunities
• Reduce service costs with increased call center efficiency and productivity
• Accelerate the return on loyalty campaigns with dramatically improved targeting

Oracle has some exciting things to say about Enterprise Data Quality and Master Data Management, and I’m pleased to be doing this webinar (and the Product MDM Webinar on August 11th) with them. Register now!

The topic will be how to “Ensure World Class Data For World Class Supply Chain Management”.

When you don’t have world class data, your company suffers from inefficient processes, misjudged decisions, compromised compliance, excessive spend, and supplier exceptions. But if you have a robust Product Data Quality and MDM strategy and deliver it well, your product information rapidly becomes one of your organization’s greatest assets.

Oracle’s Product Information Management solutions offer the most comprehensive and powerful suite of applications and tools for managing product data at every stage of the extended supply chain. By eliminating common data management problems, Oracle’s market-leading solutions allow you to improve efficiency, enhance data quality, make better informed decisions and manage a world class supply chain.

Register to join the live Webcast on Thursday, August 11 at 9:30 am Pacific (12:30 pm Eastern) to hear myself (Dan Power from Hub Designs) and David Butler (Senior Director, MDM Marketing at Oracle) discuss how Oracle’s Product Information Management solutions can help you:

• Consolidate all product information with Oracle Product Hub
• Improve data accuracy, accessibility and security with Oracle Enterprise Product Data Quality
• Drive efficiency across the supply chain with world-class Product Information Management

Don’t miss this chance to learn how you could transform supply chain data quality with Oracle Product Master Data Management. Register now!

Is my organization ready for Master Data Management (MDM)?

Assuming you’re confident that you can answer the question “What is MDM?” and can successfully debate “what MDM is not” with an unseasoned Data Architect, the title question is next in your readiness assessment progression.

While the question itself seems simplistic, the answer requires examination of many aspects of business operations as well as data management and IT maturity.

MDM projects focused on creating “IT solutions” to “IT problems” fail to provide true end-to-end life-cycle management, which is the key to maximizing business value. Below are questions to consider when evaluating your business readiness for MDM success. Consider the Core Subject Item to be the business object that you are considering mastering, such as Product, Customer, Raw Materials, Party, etc.

• MDM success relies on understanding the current and desired state of business operations. Identifying and involving business champions and business sponsors is the only credible method of defining information and process gaps which lead to a true business case.  Are your business sponsors fully engaged?
• Is there a Data Governance strategy in place already that can be used to manage business information or do we need to define this from scratch?
• Is the business case defined and does it directly tie to the project success criteria?
• What is the Core Subject Item of your MDM? Have you validated that business owners, Finance, Customers, Marketing, Legal, and IT all have the same perspectives, including the same granularity and the same definitions? If not, how will you resolve the differences?
• What are the target volumetrics for the Core Subject Item based on current and anticipated business needs?
• Is there a single Taxonomy for your Core Subject Item where all objects map to one and only one leaf node?
• Have you created an as-is information model?
• Have you created a to-be information model that business and IT sponsors agree on?
• Would you be able to define a conceptual data model to describe the various high-level information types targeted for the MDM system?
• In the case of product MDM, can business users define the difference between a version and a revision, if there is one? How do they manage each?
• Is there unstructured data you need to include?
• How are object related to each other? Are some products cross-sellable, up-sellable, substitutions, or versions of others? Do some contacts household with others?
• What rules and restrictions do you have to enforce in the MDM system?
• What additional information must be collected to allow other downstream information consumers to apply their business rules and restrictions?
• What is the current lifecycle process used by the business to manage its Core Subject Items? What is the proposed new process to do lifecycle management?
• What are the technical constraints your organization will be facing?

These are just a few of the points to consider when evaluating how well your business is prepared to undertake a successful MDM project. While you do not necessarily need to answer all of them before you start your project, consider making them a milestone before full budget is allocated because it makes planning much more accurate.

Lastly, keep in mind that knowledge and experience go a long way. Those who have gone through these projects before can attest to importance of laying down a solid foundation to build upon.

This free virtual seminar is focused on best practices for maximizing SAP performance. The day long virtual event features expert presentations, live panels and expert networking opportunities to help you make the most of your SAP environment, and will cover the hottest topics in SAP right now – including business intelligence, virtualization, master data management and mobile technologies. You’ll learn tips that you can put into practice immediately and you’ll get unbiased advice for long-term strategy development. At this unique online event, go beyond the hype and get insight into the latest technologies and best practices you can use to improve operational efficiency in SAP environments.

Dan Power’s session will be at 1:30 pm EDT, and will cover topics such as:

• Definitions of master data management, data governance and data quality
• The five essential elements of MDM
• Why companies are doing MDM and what this means to you
• Getting started on an MDM roadmap
• Is your organization ready?
• Creating the MDM business case
• MDM software selection
• Some important best practices

For more information, please visit http://searchsap.techtarget.com/feature/Getting-the-most-out-of-your-SAP-environment,  and to register, please click here.

Education

• Based on our popular “Best Practices in MDM and Data Governance” speaking engagements, presented at Oracle OpenWorld and the Oracle Applications Users Group COLLABORATE conference.
• Our workshops get business & IT professionals up to speed quickly
• You get access to the best MDM experts, and can bring your business people into the process early

Roadmap

• Based on Hub Designs’ MDM framework
• Defines where you are now, where you want to be, and over what time period
• Looks at master data management, data integration, data quality, and data governance over time

Readiness Assessment

• Looks at issues relating to politics & culture
• Performs skills assessment on people who may need training
• Examines process issues, outlining where business processes need improvement or redesign
• Investigates technology issues, detailing where essential components are not present or not able to support your upcoming MDM initiative
• Performs data profiling to discover data quality issues

Business Case

• Captures business requirements
• Identifies stakeholders and select metrics
• Baselines current performance
• Negotiates expected benefits
• Converts to financial results
• Develops total cost of ownership
• Calculates hard-dollar ROI

Software Selection

• Develops selection criteria
• Creates a weighted vendor scoring model
• Includes functionality, technology, viability, costs, services and vision
• Develops demo scripts for vendors to follow and sample data sets to give them
• Manages proof of concept (POC) process
• Assists in evaluating POC performance and scoring vendors

These engagements range in length from one to twelve months, with teams varying from two to ten people, depending on the size of the company, the number of domains of master data  involved, and the complexity of the politics and legacy systems in the enterprise.

If you’re interested in discussing an MDM strategy engagement like this, please contact Hub Designs at http://www.hubdesigns.com/contact_us.html. Or if you have comments on the above approaches, please let us know by commenting here.

The blueprint has now moved from being computation and platform independent to one that expresses intent through the use of more concrete platform-specific models. The solution specification is now documented (independent of the functional Business Requirements) to provide shared insight into the overall design.

Now, it’s time to bring the modeling products together and incorporate them into a MDM solution specification we can use in many ways to communicate the intent of the project.

First, the MDM blueprint specification becomes the vehicle for communicating the system’s design to interested stakeholders at each stage of its evolution. The blueprint can be used by:

• Downstream designers and implementers to provide overall policy and design guidance. This establishes inviolable constraints (and a certain amount of freedom) on downstream development activities.
• Testers and integrators to dictate the correct black-box behavior of the pieces that must fit together.
• Technical managers as the basis for forming development teams corresponding to the work assignments identified.
• Project managers as the basis for a work breakdown structure, planning, allocation of project resources, and tracking of progress by the various teams.
• Designers of other systems with which this one must interoperate to define the set of operations provided and required, and the protocols for their operation, that allows the inter-operation to take place.

Second, the MDM blueprint specification provides a basis for performing up-front analysis to validate (or uncover deficiencies in) design decisions and refine or alter those decisions where necessary. The blueprint could be used by:

• Architects and requirements engineers who represent the customer. The MDM blueprint specification becomes the forum for negotiating and making trade-offs among competing requirements.
• Architects and component designers as a vehicle for arbitrating resource contention and establishing performance and other kinds of run-time resource consumption budgets.
• Development using vendor-provided products from the commercial marketplace to establish the possibilities for commercial off-the-shelf (COTS) component integration by setting system and component boundaries and establishing requirements for the required behavior and quality properties of those components.
• Architects to evaluate the ability of the design to meet the system’s quality objectives. The MDM blueprint specification serves as the input for architectural evaluation methods such as the Software Architecture Analysis Method [and the Architecture Tradeoff Analysis Method (ATAM-SM) and Software Performance Engineering (SPE) as well as less ambitious (and less effective) activities such as unfocused design walkthroughs.
• Performance engineers as the formal model that drives analytical tools such as rate schedulers, simulations, and simulation generators.
• Development product line managers to determine whether a potential new member of a product family is in or out of scope, and if out, by how much.

Third, the MDM blueprint becomes the first artifact used to achieve system understanding for:

• Technical managers, as the basis for conformance checking, for assurance that implementations have in fact been faithful to the architectural prescriptions.
• Maintainers, as a starting point for maintenance activities, revealing the areas a prospective change will affect.
• New project members, as the first artifact for familiarization with a system’s design.
• New architects, as the artifacts that (if properly documented) preserve and capture the previous incumbent’s knowledge and rationale.
• Re-engineers, as the first artifact recovered from a program understanding activity or (in the event that the architecture is known or has already been recovered) the artifact that drives program understanding activities at the appropriate level of component granularity.

Blueprint for MDM - Where this fits within a larger program

Developing and refining the MDM blueprint is typically associated with larger programs or strategic initiatives. In this last part of the series, I'll discuss where all this typically fits within a larger program and how to organize and plan this work within context.

The following diagram (click to enlarge and use your browser to magnify the png file) puts our modeling efforts within the context of a larger program taken from a mix of actual engagements with large, global customers. The key MDM blueprint components are highlighted with numbers representing:

1. Common Information Model
2. The Canonical Model
3. The Operating Model
4. The Reference Architecture

Click to enlarge

I have also assumed a business case exists (you have this right?) and the functional requirements are known. Taken together with the MDM blueprint, we now have a powerful arsenal of robust information products we can use to prepare a high quality solution specification that is relevant and can be used to meet a wide variety of needs.

Typically, use of the MDM blueprint may include:

• Identifying all necessary components and services
• Reviewing existing progress to validate (or uncover deficiencies in) design decisions; refine or alter those decisions where necessary
• Preparation of detailed planning products (Product, Organization, and Work Breakdown structures)
• Program planning and coordination of resources
• Facilitating prioritization of key requirements – technical and business
• Development of Request for Quotation, Request for Information products (make vs. buy)
• Preparing funding estimates (Capital and Operating Expense) and program budget preparation
• Understanding a vendor’s contribution to the solution and pricing accordingly (for example, repurpose as needed in contract and licensing activities and decouple supplier proprietary lock-in from the solution where appropriate)

We are also helping to ensure the business needs drive the solution by mitigating the impact of the dreaded Vendor Driven Architecture (VDA) in the MDM solution specification.

Summary

I hope you have enjoyed this brief journey through “Modeling the MDM Blueprint” and have gained something from my experience. I’m always interested in learning from others, so please let me know what you’ve encountered yourself, and maybe we can help others avoid the pitfalls and pain in this difficult demanding work.

The difference between success and failure on an MDM journey is taking the time to model the blueprint and share this early and often with the business. This is after all a business project, not an elegant technical exercise. In an early reference, I mentioned Ward Cunningham’s Technical Debt concept. Recall this metaphor means doing things the quick and dirty way sets us up with a technical debt, which is similar to a financial debt. Like a financial debt, the technical debt incurs interest payments, which come in the form of the extra effort we have to do in future development because of the quick and dirty design choices we have made. The technical debt and resulting interest due in MDM initiative with this kind of far-reaching impact across the enterprise is, well, unthinkable.

Take the time to develop your MDM blueprint and use this product to ensure success by clearly communicating business and technical intent with your stakeholders.

The blueprint has now moved from being computation and platform independent to one that expresses intent through the use of more concrete platform-specific models. The solution specification is now documented (independent of the functional Business Requirements) to provide shared insight into the overall design.

Now, it’s time to bring the modeling products together and incorporate them into a MDM solution specification we can use in many ways to communicate the intent of the project.

First, the MDM blueprint specification becomes the vehicle for communicating the system’s design to interested stakeholders at each stage of its evolution. The blueprint can be used by:

• Downstream designers and implementers to provide overall policy and design guidance. This establishes inviolable constraints (and a certain amount of freedom) on downstream development activities.
• Testers and integrators to dictate the correct black-box behavior of the pieces that must fit together.
• Technical managers as the basis for forming development teams corresponding to the work assignments identified.
• Project managers as the basis for a work breakdown structure, planning, allocation of project resources, and tracking of progress by the various teams.
• Designers of other systems with which this one must interoperate to define the set of operations provided and required, and the protocols for their operation, that allows the inter-operation to take place.

Second, the MDM blueprint specification provides a basis for performing up-front analysis to validate (or uncover deficiencies in) design decisions and refine or alter those decisions where necessary. The blueprint could be used by:

• Architects and requirements engineers who represent the customer. The MDM blueprint specification becomes the forum for negotiating and making trade-offs among competing requirements.
• Architects and component designers as a vehicle for arbitrating resource contention and establishing performance and other kinds of run-time resource consumption budgets.
• Development using vendor-provided products from the commercial marketplace to establish the possibilities for commercial off-the-shelf (COTS) component integration by setting system and component boundaries and establishing requirements for the required behavior and quality properties of those components.
• Architects to evaluate the ability of the design to meet the system’s quality objectives. The MDM blueprint specification serves as the input for architectural evaluation methods such as the Software Architecture Analysis Method [and the Architecture Tradeoff Analysis Method (ATAM-SM) and Software Performance Engineering (SPE) as well as less ambitious (and less effective) activities such as unfocused design walkthroughs.
• Performance engineers as the formal model that drives analytical tools such as rate schedulers, simulations, and simulation generators.
• Development product line managers to determine whether a potential new member of a product family is in or out of scope, and if out, by how much.

Third, the MDM blueprint becomes the first artifact used to achieve system understanding for:

• Technical managers, as the basis for conformance checking, for assurance that implementations have in fact been faithful to the architectural prescriptions.
• Maintainers, as a starting point for maintenance activities, revealing the areas a prospective change will affect.
• New project members, as the first artifact for familiarization with a system’s design.
• New architects, as the artifacts that (if properly documented) preserve and capture the previous incumbent’s knowledge and rationale.
• Re-engineers, as the first artifact recovered from a program understanding activity or (in the event that the architecture is known or has already been recovered) the artifact that drives program understanding activities at the appropriate level of component granularity.

Blueprint for MDM - Where this fits within a larger program

Developing and refining the MDM blueprint is typically associated with larger programs or strategic initiatives. In this last part of the series, I'll discuss where all this typically fits within a larger program and how to organize and plan this work within context.

The following diagram (click to enlarge and use your browser to magnify the png file) puts our modeling efforts within the context of a larger program taken from a mix of actual engagements with large, global customers. The key MDM blueprint components are highlighted with numbers representing:

1. Common Information Model
2. The Canonical Model
3. The Operating Model
4. The Reference Architecture

Click to enlarge

I have also assumed a business case exists (you have this right?) and the functional requirements are known. Taken together with the MDM blueprint, we now have a powerful arsenal of robust information products we can use to prepare a high quality solution specification that is relevant and can be used to meet a wide variety of needs.

Typically, use of the MDM blueprint may include:

• Identifying all necessary components and services
• Reviewing existing progress to validate (or uncover deficiencies in) design decisions; refine or alter those decisions where necessary
• Preparation of detailed planning products (Product, Organization, and Work Breakdown structures)
• Program planning and coordination of resources
• Facilitating prioritization of key requirements – technical and business
• Development of Request for Quotation, Request for Information products (make vs. buy)
• Preparing funding estimates (Capital and Operating Expense) and program budget preparation
• Understanding a vendor’s contribution to the solution and pricing accordingly (for example, repurpose as needed in contract and licensing activities and decouple supplier proprietary lock-in from the solution where appropriate)

We are also helping to ensure the business needs drive the solution by mitigating the impact of the dreaded Vendor Driven Architecture (VDA) in the MDM solution specification.

Summary

I hope you have enjoyed this brief journey through “Modeling the MDM Blueprint” and have gained something from my experience. I’m always interested in learning from others, so please let me know what you’ve encountered yourself, and maybe we can help others avoid the pitfalls and pain in this difficult demanding work.

The difference between success and failure on an MDM journey is taking the time to model the blueprint and share this early and often with the business. This is after all a business project, not an elegant technical exercise. In an early reference, I mentioned Ward Cunningham’s Technical Debt concept. Recall this metaphor means doing things the quick and dirty way sets us up with a technical debt, which is similar to a financial debt. Like a financial debt, the technical debt incurs interest payments, which come in the form of the extra effort we have to do in future development because of the quick and dirty design choices we have made. The technical debt and resulting interest due in MDM initiative with this kind of far-reaching impact across the enterprise is, well, unthinkable.

Take the time to develop your MDM blueprint and use this product to ensure success by clearly communicating business and technical intent with your stakeholders.

Go back to Part 5.

I was struck recently by the difference between companies that have a formal, structured approach to data governance, versus an informal, unstructured or “ad hoc” approach.

In many cases, companies with an ad hoc approach already have the right people, in the right places, doing the right things.

But it’s not formally part of their job description. They just do it because they know it’s the right thing to do, or that the company really needs it.

So they act as unsung heroes of data stewardship, cleaning up data manually, writing scripts to make data corrections in bulk, even working together in teams to do data governance tasks, without ever formalizing it into a data governance program.

I wrote yesterday about whether data governance should be located in the business (with support from IT) or in IT (with support from the business). It’s a natural tendency of business people to think that data management, since it involves computers, should be part of IT. And it’s a natural tendency of the IT people to think that only the business knows the subject matter well enough to manage it.

But wherever you stand on this question, I think it’s better to have a structured approach to data governance. Set up a data governance committee or team, define its mission and processes, and give them the technology tools they’ll need to achieve the mission.

Relying on an ad hoc or informal approach is risky. People take new jobs, go on vacation, or get burned out. So you can’t rely forever on the unsung heroes of data stewardship.

I’ve said many times that if companies treated their physical assets (like inventory or cash) the same way they treated their information assets (particularly customer data, for some reason), then people would be going to jail.

Start thinking about how your organization can improve its data governance maturity, or start a data governance function, if you don’t already have one. You’ll find that “when the student is ready, the teacher will appear”. In other words, once you start, if you remain diligent and patient, the rest of the organization will ultimately see the value of adding data governance to “how we do things here”.

Here are some good resources for further reading:

• “So You Want to be a Data Champion?” by Tom Carlock
• Wikipedia article on Data Governance
• The Data Governance Institute’s Data Governance Framework
• The Master Data Management Institute
• Data Governance Blog

Please let us know via a comment if you have any other resources on data governance you’d like to suggest.

Building a “Single Version of the Truth” can be more expensive than you expect, and documenting and measuring its ROI requires careful thought.

Good planning is more necessary than ever in an uncertain economic climate. The result of inadequate planning can be misdirected spending, chewing up valuable time and resources and then, six or twelve months later, having to go back and “right the ship”. And the second time around, the efforts are often overstaffed (to “make up for lost time”), while the organization as a whole might still be marching down the wrong path.

Master data management and data governance initiatives can have a disruptive effect on the organization, and the budget is often millions of dollars. Now the stakes are even higher, because in times of economic uncertainty, the pressure is on to “do more with less” and to take shortcut approaches for achieving corporate data objectives.

One such shortcut is to turn the MDM initiative into a “technology-only” project, perpetuating a “silo” approach to data and selectively purchasing the latest data quality or hub tools. This approach should be used with caution, because at the end of the day, data is still data, and without process and stewardship, even the latest technologies will probably fail to meet the intended objectives.

Because of the organizational effects (new processes, roles and responsibilities) in MDM and the budget requirements, our advice is to take the time for a readiness assessment, understand where on the maturity curve you are, see if your business drivers make a sufficient case, think through cultural issues, etc.

The results of an assessment may surprise you. Even with a strong business case and senior management buy-in, don’t underestimate the amount of preparation and time that a well conceived planning process for MDM and data governance will take.

Metadata management is often overlooked, misunderstood or assumed to be taken care of automatically as part of an MDM initiative. While it’s true that databases can generate metadata reports based on a logical data model, there’s a lot more than that to metadata management in an MDM initiative.

As companies start to include multiple domains such as customers, products, suppliers, etc. in their MDM initiatives, the collaborative lifecycle management of the master data across business and IT functions will become a challenging change management undertaking.

One of the key benefits to addressing metadata management is to lower cost of ownership by documenting the entire end-to-end process for master data at the metadata level that greatly enhances change control across business and IT functions.

“Metadata is structured information that describes, explains, locates, or otherwise makes it easier to retrieve, use, or manage an information resource. Metadata is often called ‘data about data’ or ‘information about information’” (National Information Standards Organization, 2004).

Metadata within an MDM initiative includes all of the following: the source systems, MDM hub, data quality tools, business process management (BPM) and workflow tools, and enterprise application integration (EAI) tools.

The need for metadata for different semantics between the source systems and the MDM hub is the most apparent, as a source and hub may call the same thing by different names, e.g. part number versus SKU.

However the business rules, transformations and data rules in the data quality, BPM and EAI tools are often overlooked. Yet the complete data lineage from source to hub and back to source needs to be fully documented at the metadata layer.

So if managing metadata is so important, how does one go about managing it?

There are three approaches to managing metadata: a centralized approach, a distributed approach or a federated (hybrid) approach.

The centralized approach stores all metadata centrally, providing easy access to information, scalability and performance. This approach is more complex to integrate initially than the distributed approach, requires continuous synchronization and is also a single point of failure.

The distributed approach takes advantage of each participating system’s own metadata management capabilities and simply reads the information as required. In essence, this is simply a web portal that queries the relevant information from all participating systems on demand.

The federated approach is similar to the distributed approach in maintaining references to the metadata information for all participating systems. But also like the centralized approach, it can store metadata information locally, thus taking advantage of the best of the centralized and distributed approaches.

Choosing the best approach for an organization depends on a number of factors. The metadata capabilities of some of the existing systems in use by an organization may prohibit the federated or distributed approach, so a thorough assessment of your current tools is a necessary consideration.

Also if you are planning on upgrading existing tools, make sure that the selections fit into your metadata management approach.

MDM initiatives will require significant attention to be paid to semantics across the enterprise and metadata management in order to be successful.

At Hub Solution Designs, our MDM partnership strategy is pretty straightforward.

We are a management & technology consulting firm focused exclusively on Master Data Management and Data Governance.  Our strategy is to partner with all of the leading MDM vendors, because there is no “one-size fits all” solution and businesses need options here.  So our strategy is to provide unbiased solutions that best meet the needs of our clients.

Partnering with all of the MDM vendors is an ambitious strategy, but as Teddy Roosevelt said, “Far and away the best prize that life offers is the chance to work hard at work worth doing”.

And pragmatically speaking, as trusted advisors who bring a tested methodology and sound best practices to bear on every MDM engagement,  we think the question of which consulting firm or systems integrator you select is, if anything, more important than which MDM hub platform you select.

So here’s where we stand today with the three MDM “mega-vendors” (Oracle, IBM and SAP) and the three smaller MDM vendors (Siperian, Initiate Systems and Purisma/D&B).

Oracle: We joined the Oracle Partner Network as a worldwide partner in November 2007. Several of our team members have extensive experience with Oracle’s growing portfolio of MDM solutions, and have driven successful implementations of them at financial services institutions, software companies, and high tech firms. We have good relationships with Oracle’s MDM product strategy team and with Oracle sales teams around the country. We’re also involved in the independent Oracle Applications Users Group (OAUG) and, as part of its Education Committee, helped plan the MDM track of OAUG’s upcoming COLLABORATE 08 conference.

IBM: We joined IBM’s PartnerWorld program in September 2007, based on knowing several people from DWL (acquired by IBM in 2005) and other parts of IBM.  We think that IBM is going to do very well with companies in their “sweet spot” (certain industries like financial services and companies that are historically heavy users of IBM hardware or software).  So we’ll keep looking for opportunities to grow our client relationships, our team and our expertise in the area of IBM’s MDM solutions.

SAP: another slow starter, with an MDM solution that was originally very centered around the “Product” domain. But SAP’s NetWeaver MDM solution continues to evolve and develop. And SAP also has a strong “sweet spot” of companies (global manufacturers, consumer packaged goods companies and European-headquartered firms), and a large installed base of SAP applications users who are pretty loyal when it comes to considering an MDM solution from SAP. We’re just about to join the SAP partner program at the Associate Partner level to start, and have just brought on a new team member with significant experience in Master Data Management and SAP.

We also continue to be impressed by the smaller MDM software vendors.  We think we’re still in the early stages of MDM market development and there’s still room for a “best of breed” MDM strategy at this point.

The Siperian MDM Hub is a robust product, and is able to identify and manage relationships among multiple types of enterprise data, such as customers, products or accounts, across multiple applications and lines of business. The company has done very well in the financial services and pharmaceutical & life sciences industries. Siperian had a more than 300% growth rate from 2006 to 2007, and just received a $25 million round of financing in January, to support additional expansion in Europe and further development of its channels and products. The Siperian customers we’ve talked to really like the product, and the Siperian people we work with are top notch. We’ve been an approved Siperian partner since October 2007, and are planning to attend the Siperian user group and partner summit in San Francisco in early April.

Initiate Systems filed with the SEC to go public in November 2007. The company was founded in 1995 and has more than 140 customers in production, in industries such as health care, financial services, public sector, retail and technology, with marquee customers such as Microsoft, Intuit, Capital One, Countrywide, Wells Fargo, Humana, Hyatt Hotels, Barnes & Noble, CVS, and SuperValu. We signed a partnership agreement with Initiate in December 2007, after talking with some Initiate people and customers at the Fall 2007 MDM Summit conference in New York. The company’s technology has some very interesting capabilities, and we’re impressed with what we’ve seen to date of the product, the company and its people.

Purisma (a D&B company): Prior to starting Hub Solution Designs in mid-2007, I worked for Dun & Bradstreet for three years in its Global Alliance team, managing D&B’s strategic alliance with Oracle. I was part of various CDI and MDM related teams and initiatives within D&B, and was one of the few people from D&B to attend the first public CDI-MDM Summit conference in Spring 2006.  After being an internal MDM evangelist at D&B for several years, I was pleased to see the company acquire Purisma in November 2007. The acquisition was a good strategic fit for both companies, allowing D&B to become more of a player in the Customer Data Integration (CDI) and MDM marketplace, and giving Purisma the chance to extend its market reach.  We’re not formal partners with D&B/Purisma yet, but we’re working on it, and in the meantime, our network of informal relationships within both companies continues to grow.

After establishing and growing our relationships with all of these companies, we’re listening carefully to what our clients and the market as a whole are telling us about their relative strengths & weaknesses, who has the best product for which situation in which industries, and who’s growing their market share over time.  We think there will be some additional consolidation in MDM, as in every other part of the enterprise software market, and we hope to continue as thought leaders by being able to look “around the corner” at what’s coming two to five years down the road.

We’ve got our eye on other large enterprise software players, like Microsoft, salesforce.com and Google, that are not yet really playing in the MDM space in an organized way.

Our formal & informal relationships with Oracle, IBM, SAP, Siperian, Initiate Systems and Purisma/D&B will continue to develop and grow. Our clients benefit from our solid methodology, approaches and best practices, plus the processes, procedures and data governance that we help you wrap around these MDM products, regardless of which vendor you select. Please review our service offerings for Educational Workshops, Readiness Assessment, Software Selection, and Business Case Creation to get an idea of how we help clients map out and execute a winning MDM strategy.

The vendors bring great technology and we bring great people with broad domain expertise.

Today, we published two one-page documents on our Educational Workshops and Readiness Assessment service offerings on our web site.

Please let us know what you think of them …

Well, the short answer is – “it depends”! Putting aside the conventional answer for the moment, I’d say that a critical first step in achieving a pragmatic MDM strategy is that your company must agree and commit to developing a 3-5 year MDM strategy.

This is not as simple as it may sound. Successfully executing an MDM strategy with a 3-5 year vision requires a considerable cross-functional effort and substantial agreement on some vexing political, business and technology issues. More on this later.

The following situation is not uncommon. A senior executive at the company decrees that the company needs an MDM solution to remain competitive or to fix nagging data issues. The vendor selection team jumps into action, solicits requirements from business owners, puts together a vendor questionnaire and contacts vendors.

The next few months are taken up with defining selection criteria, sitting through vendor demonstrations and digesting different vendors’ current approach to MDM and their future roadmaps.

The promise of a business intelligence solution, with a Single View of Customers, across CRM and ERP systems, through a federated or persistent hub is now only months away.

The demos were impressive and installation is promised to take only 8-12 weeks. After all, the company has already implemented CRM and ERP solutions, so the next solution should be much quicker – right?

Which brings us back to “it depends” The reality is that this approach may work for certain companies. Those companies who have matured through CRM and ERP implementations, who have well defined business needs and change management projects under their belts, with well documented business processes and a Project Management Office already in place stand the best chance to succeed.

But then these are the very companies who already know that they need to develop an MDM strategy, often with the help of consultants.

And this leads us to the question of developing an MDM strategy. How comprehensive does the strategy need to be? How much time is reasonable to spend developing a strategy? Can a staged approach be taken on the strategy, for example just start with customers and worry about other domains once that is working? Can we just bring a hub up with our current customer data and go from there? These are all valid questions.

One of the biggest factors that will help answer these questions is an organizational readiness assessment.

The strategy process should develop a vision for data governance, business outcomes, business processes and technology for the company. The process will touch on situation analysis, goals and objectives, strategy development, implementation plans and change management. Involving consultants through the process can greatly speed the process for many companies.

Our recommendation is that no matter how tempting a “quick win” approach to implementing MDM may seem – make sure you take some time up front to develop your strategy with both short and long term goals. Make sure that strategy is accepted throughout the organization and that the short term goals are on the correct path to solving the longer term business objectives.

This can help you avoid having to “rip & replace” your MDM solution shortly after building it, and help prevent you from creating MDM “data silos” because your strategy didn’t take into account other critical enterprise data domains beyond the immediate situation.

MDM can be a “game changing” initiative, giving the enterprise clean, consolidated, complete data for the first time, driving increased revenue, decreased costs and improved compliance. But as Stephen Covey says, make sure you “begin with the end in mind”.