How To Understand The Benefits Of Anmdm

Transcription

1 Ap Why MDM Projects Fail? By: Ashraf Mohammed May 2012

2 Why MDM Projects fail? In my first whitepaper Demystifying MDM, I introduced the concept of Master data.we talked about why Enterprises needed to be serious about managing their master data and we also saw the different types of data and the role of master data in the total data landscape. Why MDM implementations fail In this section, I discuss the top reasons why MDM implementations fail. Let us look at some reasons why MDM is delayed in implementation and/or does not offer the functionality that the enterprise expected from MDM. 1. Adopting the one size fits all business model Typically, MDM products impose upon every customer, a rigid, one size fits all master data business model. This generic business model is forced upon every customer, irrespective of their unique business processes, compliance/regulatory requirements, unique way of doing business, industry vertical, geography, market they operate in and so forth. Many MDM customers unfortunately fall into this trap, without realizing that while a vendor s canned business model may have worked for a different market or a different customer, their own business agility could be seriously compromised. Canned MDM business models typically deviate from how the customer actually does business and when customers adopt such boxed business models, it s like trying to fit a square peg in a round hole. This is the most common cause for the failure of MDM projects. When there is a variance in the very foundational business model, it results in dissatisfaction and rejection from business users. Ideally, limitations in technology and an MDM vendor s preset models should not be the drivers on how customers need to model their business. For a business user to truly appreciate the value of MDM, the business model needs to be made-to-order, tailored and customized to accommodate the unique needs of each enterprise. 2. Ignoring Process & Organizational Change Management post MDM MDM causes a shift in Organizational structure and affects existing Processes that uses Master data. For this reason, business needs to be adequately informed and should be engaged in the MDM process right from the beginning. This ensures that when MDM is in place, business users are not caught unaware by the consequent changes in master data access, delivery or structure. Majority of the enterprise business Processes are directly related to Master data. Therefore a change in master data directly impacts the way the business conducts its day to day operations. To avoid any unwelcome surprises, a thorough study on MDM s impact on business process, and gap analysis need to be conducted.business users need to be made aware of upcoming changes, engage in and take ownership of MDM process right from the beginning. Business, not IT are the true owners of MDM. 1

3 MDM also affects organizational structure, in terms of business and IT resources. The personnel requirement for MDM needs to be clearly analyzed and the appropriate staff needs to be hired and/or adequately trained, in order to align to and support the new business processes. When this organizational impact of MDM is not properly provisioned for, it results in failure of the MDM project. 3. Poor& outdated Technology stack Most of the MDM solutions available today are built on outdated technology that was developed in the 1980 s-1990 s. These MDM solutions are obsolete in today s information age of mobile computing, social networking, the internet, intuitive/interactive solutions and cloud applications. Trying to solve today s data challenges using MDM solutions built on outdated technology, is like a goods train running on coal versus a superfast bullet train. When customers attempt to achieve simple MDM functionality such as enabling work flows, calling restful services or modifying the UI, they are met with the daunting task of altering humungous lines of code. Some MDM products on the market are so outdated that they simply do not support such customization! This ultimately translates into a very high Cost of ownership. The worst scenario is when the vendor MDM application is a complete black box. In these cases, writing code is not even an option. As a result expensive MDM implementation teams wait idly, while waiting for hot fixes. Several MDM products have complicated the very essence of MDM by creating complex data structures that buckle under their own weight. These convoluted data frameworks are nothing short of a customization nightmare. They are expensive to configure, have lengthy implementation timelines, are very limited in scalability and are difficult to maintain. 2

4 This can be avoided by performing a due diligent GAP Analysis from resources that do not have any affiliation to any particular vendor. 4. Lack of proper GAP analysis in finding the right MDM product Most prospective MDM customers choose an MDM solution offered by a vendor simply because it was named in a Gartner report, without conducting an in-depth product analysis of their own, to check the suitability of the said product for their business. MDM customers often make the mistake of choosing a particular vendor s MDM app, based on the vendor s reputation in ERP or CRM. Many MDM solutions on the market were acquired by IT big names through Mergers and Acquisitions. Although they are sold under the same big brand name, they are built on a completely different IT frame work. So while MDM customers think that xyz MDM is specifically designed to integrate with xyz CRM or xyz ERP, they realize too late that these applications although sold under the same brand are not specifically designed to seamlessly integrate with each other. This is a very common pitfall in MDM projects. To mitigate this risk, customer s need to focus on conducting a thorough gap analysis by engaging MDM experts who have firsthand expertise using multiple MDM products. The analysis needs to be performed based on a customer s data pain-points, requirements, the customers segments, market, vision and objective. Once these are mapped, a proper score card should be drawn, to rank the different MDM vendor offerings and select the right vendor. Again, while it is easier to make a choice based on what another company within the market segment has already purchased, in order to gain an edge over others, the MDM solution needs to be tailor-made per a business unique needs and not constrained by the vendor s product capability. 5. Complexity of MDM The following is a very useful analogy helpful in explaining the complexity of MDM to business executives, analysts and the IT development team. Imagine a custom application that performs only one function, you can easily predict its interactions, results and behavior. So, one can easily enhance or refine the processes. On the other hand, with MDM, processes are impacted by multiple applications. Data from these multiple applications need to live in harmony, coexist and synchronize in source, transit and destination points. The complexity only increases exponentially with each new additional data source. Unless uniform Architectural Principles, Framework and a pattern of reference is adopted, the MDM implementation team tends to reinvent the wheel, resulting in expensive delays and very high implementation costs. This is another common cause of MDM failure. Even a simple process such as - Updating Customer Attribute, needs to be designed in such a way that it not only impacts a particular record but also cascades to the subscribing applications. A holistic view of the impacts and design need to be evaluated and designed such that the record does not adversely affect business processes across the enterprise or other connected data integrations, migrations and reporting applications. Without the involvement of an MDM Information Architect this tends to fall 3

5 through the cracks, resulting in screams and roars from users in different business domains resulting in complex, painful, time consuming and expensive redesigning activities. 6. Objective of MDM is unclear Very often businesses are unclear on the ultimate objective of MDM. Time and effort needs to be invested in educating business users to understand the benefits of MDM, its impact and the corresponding adjustments that need to be implemented in order to reap the benefits of adopting an MDM strategy. An MDM strategist and Business analyst are crucial to ensure the business users understand the MDM vision, interpret it in business terms and help strategize the MDM solution. MDM is not just a technology. It s a complete strategy, which includes how it should be adopted. When MDM is treated as a pure IT approach, neglecting to involve business users, MDM projects fail. MDM is a new concept even to most IT teams. Very often, they tend to wander off on their own, and create an IT solution without involving business users. They tend to put on the application development hat, even before designing the MDM business processes. This causes simple business processes to get overly complicated and ultimately becomes an implementation nightmare. 7. Business flow is undocumented Business process flow is very often not identified or documented. Business thinks it is an IT responsibility to document the current process flows. When IT documents business processes they do so still wearing their IT hats, they capture too many technical details, while neglecting to capture business impact. End result is that often times, the deliverable becomes too complicated and unusable by business users. For successful MDM, current processes need to be clearly documented by business, and they should take ownership for the business process. When IT is designing the detailed system processes for MDM, business need to be actively involved to ensure the processes are streamlined and simplified. Having IT work on this with no or minimal input from Business results in building an overtly complicated detailed process flow, requiring so much customization that the MDM implementation fails miserably. 8. Prioritization Many MDM projects tend to lose the enthusiasm and hype created during the initial stages of the project, when each business domain disclose their long wish-list of requirements from MDM. This may be a good thing, provided the PMO and IT ensure that the scope of the MDM implementation is prioritized and phased out. Requirements of the different business domains, should be prioritized and delivered in phases, per a clear cut project plan, as opposed to trying to boil the entire ocean at once. 4

6 Once the enterprise experiences the benefit of a small, yet successfully implemented MDM piece, other business units are more enthusiastic about implementing MDM for their own division. On the other hand, if the smaller, strategic stages of the MDM implementation are not clearly defined, it can turn the entire MDM project into a mammoth effort compared to where it all began. The project could easily go out of hand when there is no uniformity in vision and MDM strategy. Different domains are at odds and IT and Business lose hope in the project. Therefore a strategic prioritization of MDM effort is a must to ensure the success of MDM. Every domain can have a vision of what they require from MDM, but they need to select the most important ones for the enterprise, implement it first, and then come back to the remaining requirements in stages. 9. Do it now or it will never be done approach Often times, with MDM projects, IT pushes for the let s get it all done now approach, which is not the ideal approach for MDM. When a multi year MDM project is architected at one time, it turns out into a very expensive effort with a very high cost of ownership for the enterprise. It calls for very complex, long term, architectural design, plus extensive development. The complex architecture would then need to go through rigorous review and approval process while the development team is waiting for the design and draining the project budget. A phased approached is absolutely critical for successful MDM. On the other hand, with MDM, there are certain foundational aspects that should not be overlooked such as reference architecture and architectural building blocks. I talk about iclassic MDM reference architecture in my white paper titled MDM architectural best practices and iclassic MDM. 10. No Methodology Successful MDM requires the enterprise to adopt and follow a methodology from the many choices and frameworks available. In fact the customer might already have a working model. Therefore a methodology adoption workshop needs to be conducted, in order to ensure the business and implementation teams are on the same page regarding the MDM approach. The MDM methodology needs to be chosen carefully. Some methods tend to be solid only during strategy and blue-printing, some others are good for high level design only. The ideal methodology is one which can successfully address every stage in the life cycle of the MDM project. A good example of a comprehensive MDM Methodology is iclassic MDM s implementation framework. It is technology agnostic, and successfully handles the strategy, blueprinting, design and development stages of MDM projects. Without a flexible and comprehensive Methodology, MDM projects can fail miserably. In this paper I talked about what causes an MDM project to fail. In my next paper, I talk about the MDM Project Lifecycle and provide tips and strategies to ensure successful MDM implementation. To leave your questions, comments or enquiries please write to me at ashraf@etsondemand.com 5

7 About the Author Ashraf Mohammed is a TOGAF and IBM Master Certified Information Architect specializing in MDM Master Data Management. Ashraf has worked at reputed IT concerns like IBM, Oracle and Siebel in delivering MDM projects across industry verticals such as agro-chemicals, finance, telecom, multi-media, publishing, e-government, retail, O&G and so forth. As an MDM specialist, he has seen firsthand, the glaring deficiencies in existing MDM solutions, faulty strategy and surprisingly common, yet, avoidable MDM pitfalls. Realizing the phenomenal benefits Master Data Management can provide to an enterprise, he believed the time was right for an MDM solution, designed specifically to solve the complex data challenges faced by enterprises, in today s age of the internet, mobile computing, social networking and cloud applications. Thus was born and iclassic MDM. In designing iclassic MDM, he has consciously eliminated many limitations seen in current MDM solutions. iclassic MDM is an agile, cloud based, flexible, highly configurable, end-to end MDM solution seamlessly built using the latest and greatest in technology and Information Architecture. See To leave your questions, comments or enquiries please write to ashraf@etsondemand.com 6