A Methodology for Sustainable Success with MDM Initiatives

Transcription

1 A Methodology for Sustainable Success with MDM Initiatives IBM has embraced the opportunity to break new ground to bring powerful Master Data solutions to the marketplace. Combine this commitment to innovation with our longstanding dedication to open standards, flexibility and Service Oriented Architecture (SOA) and you get a company that understands the business value of Master Data Management (MDM) and how you can use an MDM strategy to help you drive accurate, trusted and actionable information over time across the enterprise, to provide a real-time single version of the truth about customers, products and other entities. Today, forward-thinking systems integrators like Tata Consultancy Services (TCS), an important member of our thriving ecosystem of IBM Business Partners, have embraced MDM and are teaming with IBM to offer robust, leading-edge solutions to help their clients drive strategic and financial value from managing complex, voluminous data in an integrated manner. This white paper demonstrates the value of adopting an MDM methodology and strategy. Organizations cannot deliver on key strategic initiatives because master data on customers & products (and other domains) is fragmented across applications. Companies need to build an accurate and complete understanding of key master data entities across the enterprise, while delivering on short-term tactical projects (Customer Data Integration or Product Information Management) with demonstrated business value. Customers want to gain control of their data and manage a master version of the truth that is complete and accurate. Together, IBM and TCS can help customers increase revenue, lower marketing and sales costs, increase customer satisfaction, and reduce data errors.

2 About the Author Kalyan Viswanathan Kalyan Viswanathan is the Global Practice Head for Master Data Management at Tata Consultancy Services. He has an extensive career experience spanning across many aspects of Enterprise Architecture, Data Warehousing, Meta Data Management and other related areas. He started TCS' Master Data Management group in September 2003, and has helped TCS establish a strong expertise in this emerging area. Kalyan is located in Dallas, Texas. 1

3 Table of Contents 1. Master Data Management An Emerging Need 3 2. Master Data Management and Service Oriented Architectures 3 3. Business Drivers for Master Data Management 4 4. MDM is Application Neutral Infrastructure 5 5. Master Data Initiatives Require a Strategic Vision 5 6. Master Data Management Initiatives Require Tactical Alignment 8 7. Balancing Between Strategic Vision and Tactical Alignment 9 2

4 Master Data Management An Emerging Need If you can think back to the state of the IT world in the late 1980 s and early 1990 s, it was a time, when there was no such thing as a Data Warehouse. Business Intelligence was an unheard of phenomenon. There was only operational reporting, and most of it was being done from Operational and Transactional Systems. Then came a revolutionary idea that Data for analytics and business intelligence must be separated from Operational and Transactional systems, and the concept of the Data Warehouse was born. Today, some 15 years later BI is an established discipline, with many products and vendors, numerous design patterns such as ETL technologies, Data Marts and Dimensional Databases and Data mining and reporting technologies. Today, there is a similar methodology being created around Master Data Management (MDM), which is a critical, emerging high growth market today. MDM encapsulates a radical idea that Master Data must be fundamentally decoupled from Operational, Transactional as well as Analytical Systems. The way transactional systems interact with master data must be orchestrated through well defined Master Data Services that inter-operate in a typically heterogeneous environment, through a Service Bus in a Services Oriented Architecture (SOA). This conceptualization of MDM goes well beyond merely consolidating master data into a centralized hub, and providing some form of governance. It goes further beyond, providing some form of bi-directional synchronization between this Master Data Hub and all other applications, as well as providing the ability to do new things with crossenterprise data such as maintaining privacy preferences. The ideas of SOA and MDM, therefore, represent nothing short of an Architectural revolution in the way systems are constructed and assembled. At the leading edge of this emerging MDM market, is the customer domain. This is more commonly known as Customer Data Integration (CDI), a capability that bridges the operational and analytical realms of Enterprise Customer Information (CRM, Data Warehouse, ERP, etc.), and will be a key component of the MDM adoption cycle of most enterprises. This market is moving out of its early infancy stages, with most leading edge enterprises exploring what it is, what it means to their IT environment, and how to get started on this journey of architectural transformation. There are now many examples of companies who are rapidly progressing past their phase I implementations of customer data integration. Master Data Management and Service Oriented Architectures At first sight, it might appear that Service oriented Architectures (SOA) and Master Data Management (MDM) have little in common. After all, SOA deals with de-composing monolithic applications of the past into a collection of reusable services, while MDM deals with better management of Master Data. SOA is the most critical IT trend today. Most large enterprises today are dealing with the question of how to transform their IT systems into a Service Oriented Architecture. On this journey, they go through the early stages of organizational education, exploration and evaluation of available technologies. Then they actually invest in some kind of limited SOA Pilot. These Pilots are typically low to medium risk initiatives, and help them validate their chosen technology sets. Then their journey meets a critical cross road How do they scale from low cost, low risk pilots into a larger business unit wide or even an enterprise wide SOA initiative? At this cross road, it becomes apparent that as long as their highly shared Master Data assets are scattered, amongst numerous applications, it is in-sufficient to wrap existing legacy applications with a services layer, and call this resultant architecture SOA compliant. For example a simple Re-usable service such as Create new Customer or Update Product Information must now synchronize those master data changes with multiple operational and transactional systems (sometimes 100 s of applications). It makes little sense to end up with 100 s of different instances of Create new Customer services, with each one operating within a restricted application domain. There 3

5 is also the possibility that you can end up with rather large application centric services that are too large and complex to satisfy every consumer of the service. The problem of data replication, and resultant data conflicts remains unresolved. For services to be truly Re-usable enterprise class services, they must deal with the problem of widespread replication of their Master Data. This recognition leads naturally to a bottom up approach to SOA i.e. organizations must invest in de-coupling and consolidating their critical Master Data assets from participating applications, by instantiating the concept of a Master Data Hub. Master Data Management Solutions then become critical milestones in the journey towards enterprise wide deployment of SOA. Business Drivers for Master Data Management Although it is intuitively obvious that MDM initiative are strategic and may impact a number of business areas and applications in an enterprise, in practice there are often no clear and easily identified Business Drivers for an MDM initiative. A Business Unit or Process owner is not going to ask the CIO, that he or she would like to invest in an MDM initiative, this year, or even the next. However, there are a number of business drivers, or pain points within most large enterprises, that are addressed better through MDM Solutions. Some examples, frequently heard are I need a consistent, single view of my Customer or My profitability reports don t match up or It takes too long to introduce a new product in this environment and so on. The picture shown below captures this idea. The Business need to better manage Master Data may arise in many different contexts within an enterprise. These range from ERP consolidation initiatives, or ERP implementation initiatives, Supply Chain optimization, Customer Relationship Management initiatives, Business intelligence, Compliance reporting, Customer privacy management, New Product introduction processes, Legacy Modernization, Service oriented Architecture adoption and so on. While the Solution to each of these problems could be uniquely constructed for that particular problem space, it is when these problems are taken together as a set, that the need to better manage the shared Master Data Assets, becomes apparent as a common shared concern. ERP Implementation and Consolidation Service Oriented Architecture for Business Agility Business Agility - New Product or Customer Introduction Master Data Management Information Reliability for BI, Decision Making and Compliance Supply Chain Optimization Single Version of the Truth 360 Degree Views 4

6 MDM is Application Neutral Infrastructure It is readily apparent from the discussion above that MDM initiatives are highly Strategic, Enterprise level Infrastructure initiatives. An MDM initiative is quite different from an Application implementation. MDM initiatives also embody a paradigm shift in the way Master Data is managed within the enterprise. Where previously, the focus had always been on building point solutions or localized applications, and Master Data simply existed as a necessary pre-requisite within any given application domain, now, there are at least a handful of people within the enterprise who are recognizing that the Master Data deserves some attention in its own right. Where previously, the way Applications acquired and managed their master data, was simply by building an interface (or even a set of interfaces) to some other application(s), from where they could acquire the Master Data, now, there is an emerging concern for the Architecture of the way Master Data is shared across application boundaries. Where previously there was little concern for Data ownership and governance, now, there is a growing interest in establishing some principles and practices, around Data ownership and governance. Where previously, Data ownership rested within specific Application domains, now there is a growing recognition, that the Enterprise s Master Data assets, flows through many business processes, ranging from Order management, to Customer Relationship management, to Procurement, to Business intelligence. Therefore the ownership and governance of Master Data cannot rest with the owners of any one process or its corresponding application. Thus, there is an entirely new set of concerns around data governance, data quality, data model and the data life cycle that is de-coupled from the domain of the individual applications, and placed in a shared space. This leaves the enterprise with a dilemma called Who owns Master Data Management Initiatives? There is a whole set of attendant questions, such as Who owns the Master Data itself? Who is going to get these initiatives funded and started? Further, when Master Data is de-coupled from the applications that use and consume it, Application design itself undergoes a radical transformation. Instead of making Master data part of the Application itself, it must allow for the possibility that Master data may be available to the application through externally provided services. Off the shelf products acquired from Vendors must also allow for externally provided Master Data Services. Managing Referential Integrity will be much more complex in this situation. All of these concerns represent a disruptive paradigm shift in the organization. Master Data Initiatives Require a Strategic Vision Master Data Management Initiatives must therefore be constituted as Enterprise transformational programs. They will impact most applications in the organization, including many concurrent in flight projects. This implies that an Enterprise level Vision and Road Map must be established for MDM initiatives. The governance of MDM initiatives must be coordinated at the Enterprise level. Executive level governance structures must provide the right steering signals to align numerous concurrent projects and programs with an Enterprise MDM initiative. Further, Master Data Management must address all subject areas that are relevant to the business. Examples of subject areas, or domains, include Customer, Product, Account, Location, Geography, Supplier, Employee, and so on. Some subject areas may be more obvious and critical than others. Nevertheless, an Enterprise level MDM Program will have many tracks, each dedicated to a subject area. Each track may have a different Business sponsor, and even different Solution patterns. The customer domain (and CDI) then is only one of the tracks in an Enterprise MDM Program, although it frequently provides businesses with a starting point from which to focus on MDM. The CDI Market has gained momentum simply due the fact that in almost every business vertical, getting to know the customer is a critical business imperative. Customer data is also widely shared across numerous operational and analytical applications. 5

7 Enterprise wide MDM initiatives can gain benefit and momentum from early success with Customer Data Integration. When CDI initiatives get initiated, without an appropriate Enterprise level vision, they fail to yield any reusable design patterns, and may not yield the full business value of MDM. In the first horizon of Master Data Management initiatives, enterprises begin by consolidating master data from many different disparate environments. Since Master Data is widely scattered, Data consolidation is the first milestone. Without Data consolidation, the ubiquitous single version of the truth will remain elusive. Semantic dissonance and discrepancies in definitions will remain. Enterprise Information Integration (EII) oriented approaches that allow for real time integration of data will not resolve the pervasive issues of data quality. However they can provide a short or medium term work around. This Data consolidation naturally leads to the construction of persistent Reference Data Stores (also called Data Hubs). This Reference Master Data Store will be a critical Application neutral infrastructural component. In the initial stages of MDM initiatives these data hubs will co-exist with other legacy data stores, which may include older versions of Master Data stores as well as Application specific Master data stores. Data consolidation into the Reference Data Hub, will have to address all forms of data quality issues and data conflicts. Such a Data Consolidation exercise requires the creation of Enterprise Master Data models. Establishing an Enterprise level Master Data Model, allows an enterprise to address issues of data definition conflicts and semantic dissonance, in a centralized manner. Data concepts such as Party or Customer acquire different meanings and interpretations in different business contexts especially over time. MDM initiatives thus become occasions to fundamentally address the business terms and definitions in use and establish clear business context and concepts, which can be shared across departmental boundaries. Such a Data Modeling exercise must have a business context that transcends specific application contexts. The tendency to avoid data modeling altogether, because the MDM solution is based on a vendor s package (which has a packaged data model), must be avoided. While specific Application Vendors may provide adequate Starter Models, these must be carefully evaluated and customized. Since MDM infrastructures by their very nature are application-neutral, Application specific data models must be avoided. In the second horizon of Master Data management initiatives, the data in the Master Data Hubs must be synchronized with all surrounding applications and master data stores that use some portions of this master data. Since Master Data changes may originate in many different application environments, this Synchronization must be bi-directional. Synchronization design patterns such as real time, batch or near real time, must be established for each subject area, some times at the attribute level. Issues of Data ownership and conflict resolution become critical in this horizon. Data ownership requires that there is a single identified owner for each business attribute, in each subject area in the enterprise. Historically data ownership has always rested with specific application owners by default. Enterprise wide data ownership is not a well understood concept yet, in most enterprises. For example, it is somewhat intuitive that the SVP of Sales and Marketing, could be a Data owner for Customer Master Data. However he has to own and govern customer Master data on behalf of the entire enterprise, not just on behalf of the Sales and Marketing function. This represents a paradigm shift in data ownership and governance that is not well understood and assimilated. New kinds of Enterprise wide roles and responsibilities and attendant organization structures, now become important in the wake of Master Data Management initiatives. This dynamic also underscores the importance of why it is critically important to have an enterprise-wide governance body overseeing, creating dialog and providing guidance around these issues. 6

8 In the third horizon of Master Data Management initiatives, Applications surrounding the Master Data Hub, may get re-engineered, to access the Master data from the Hub, and get de-coupled fundamentally from any master data stored locally to the application. This is a critical and radical transition. This transition may happen one application at a time, or may not happen at all in some instances. Through these transitions, additional enhancements to the Data Hub data model may be required. As customers consider their approach to this third horizon, they need to make sure they are considering flexible MDM products and solutions that will help them evolve over time. For example, a client may determine that they want to start off with a thin layer of customer data in the CDI Hub, and then gradually increase the amount of data that is maintained in the Hub. Additionally, accessing and managing that information in real time may become more critical. Clients need a flexible, but scalable, product that can meet their current, as well as future, needs. CUSTOMER DATA INTEGRATION - A JOURNEY HORIZON 1 Creation of unique global customer ID and cross reference with source systems Ensuring Data Quality - Standardization, Accuracy, Reliability Matching and Merging duplicate customer records Customer data in the hub synchronized with the source systems HORIZON 2 Expansion of the customer data model Sourcing new data elements from data sources both internal and external such as D&B User interfaces for specific customer data management roles Real time connectivity to the Hub HORIZON 3 Business process re-design of customer processes Information ownership - who owns which pieces of customer data Composite processes, workflows that include the hub, and other application in a SOA Transaction concurrency, stability, and reliability Management Commitment and Alignment It is clear from the above discussion that Master Data Management initiatives represent a transformational journey for most organizations. They are not just another project. Therefore the need to establish the MDM programs firmly in an overarching Architectural Vision, is critical for sustainable success with MDM initiatives. 7

9 Master Data Management Initiatives Require Tactical Alignment It is clear that Master Data Management results in improved data quality, semantic consistency and can impact many business areas. For example, a typical CDI initiative can impact a variety of areas related to the Customer. The real business value of MDM initiatives is the aggregate of the business benefits in each impacted area. Building a comprehensive business case for MDM requires understanding its potential business value across these varied business areas. No one Business Executive is going to have MDM on the top of his or her agenda. Selling the concept of MDM to the business requires constant evangelism and advocacy across a broad range of business executives. The creation of a Centralized Master Data Hub cannot be an end in itself. It has to be leveraged appropriately to deliver measurable business value. The business value of an MDM initiative must be forecasted before the initiative begins, and assessed after it ends. When business value is clearly demonstrated, subsequent iterations of the MDM Road map can be funded more easily. The business value must be articulated clearly through a well developed business case. The business case must be built on the basis of critical business measures that will be impacted by the MDM initiative. MDM initiatives only deliver the foundational infrastructure for potential business value. For example, the fact that we now have a single customer view in the customer data hub, does not guarantee that the Cross Sell ratio will go up. The single view of the customer has to be leveraged through intelligent cross sell business strategies. Business executives must be educated on the fact that MDM initiatives deliver critical infrastructure, which must be accompanied by business strategies and solutions. As an enabling infrastructure, it is difficult to directly attribute business value to an MDM initiative. Selling the concept of MDM and acquiring funding for an enterprise wide MDM initiative is going to be a difficult task. It will always be easier to sell an enterprise on the concept of a focused and tactical MDM initiative, with limited scope and budget, and to develop similarly focused follow-on phases from that starting point. Pressing needs may exist within the enterprise that demands a solution to specific business problems. Some examples are Sales (Cross Sell efficiencies), Marketing (Marketing productivity), Compliance (Basel 2) or Servicing (Service Excellence). The initial language of the problem, will almost never imply that the business is looking for an MDM based solution. At first evaluation, each pain area may not look like they have anything to do with an MDM Solution. In fact, it may even be possible to address the business requirement, or pain area, without an MDM infrastructure. However, every significant business initiative can be tied back to MDM in some way, since all business problems will involve the need for Master Data. The concept of MDM must be creatively positioned within the domain of the specific business pain area. Often there are in-flight, funded projects that are currently being addressed through custom development, or off the shelf products. These efforts may not have considered an MDM based approach at all. If an MDM Architectural vision is not aligned tactically with ongoing funded initiatives, it may never get off the ground. By aligning an MDM Road map with tactical initiatives, the enterprise can begin the MDM journey. Some central agency must own the MDM architectural vision and arbitrate it across numerous in flight and upcoming initiatives. Tactical business projects must be assessed for convergence with the MDM architectural vision. The delivery of business value to a specific business area or function could be constituted as a specific MDM iteration. For example, delivery of integrated Customer Master data to the Sales function, and the attendant benefits could be a single iteration in the MDM Road Map. The delivery of business value to a specific business area is easier to manage in a shorter time frame. Shorter time to value builds confidence in the initiative. 8

10 Thus, the MDM vision for an enterprise must encompass the notion of an MDM delivery iteration. The business case and the solution footprint of each iteration must be carefully constructed in order to build growing consensus for the initiative. This implies that there are no tactical MDM projects only MDM iterations that build upon an Architectural vision. By ensuring that each MDM delivery iteration delivers on its business case we can establish a growing consensus within the business for the MDM initiative. If the business case for an MDM iteration, is buried in a larger business initiative, MDM initiatives will never acquire their enterprise level focus and distinct identity. Each MDM delivery iteration must be anchored with a specific business sponsor, who is willing to demonstrate the business value of the specific MDM iteration. Not all MDM deployments are the same. Therefore, MDM solutions need to provide capabilities to manage multiple forms of MDM. This concept, Multiform MDM, requires support for multiple domains (subject areas) and usage types. There are broadly three distinct usage types in MDM solutions. There is Collaborative MDM design patterns that focus more on Master data as content, and is concerned with the workflows associated with content authoring. Operational MDM focuses on transactional delivery of Master data through large grained business oriented services. Finally, Analytical MDM focuses on in-line analytical data consolidation and roll ups. It may be tempting to align with an MDM vendor, who has an offering that is very strong within a specific usage type, and most applicable to the initial needs. Without an over arching MDM vision, trade offs between niche MDM (or CDI or PIM) vendors and enterprise MDM vendors cannot be appropriately evaluated. There may be multiple MDM products involved in the overall MDM strategy of an enterprise, but it is better to create a strategy that plans for an MDM product that can successfully be applied to all domains and usage types. Balancing Between Strategic Vision and Tactical Alignment Without a strategic MDM Vision, it is possible for most large enterprises to end up with multiple MDM infrastructures, which are not appropriately integrated. The design of MDM solutions will not be established to evolve through multiple MDM delivery iterations. Tactical MDM design patterns that do not scale up to a coherent MDM architecture will be predictable. A strategic MDM Vision that has the buy in with the key enterprise stakeholders, on both the Business and IT organizations is critical to success along the MDM journey. A mechanism to co-ordinate the project portfolio with the MDM initiatives is also critical to MDM success. At the same time, without tactical alignment, the MDM journey will remain a vision without a sponsor. A big bang approach without tactical short term value delivery will be difficult to get funded. The MDM Vision must be reconciled with the current funded project work. A beach head project must be identified that can become the pilot to get the MDM program started. The business value of tactical MDM iterations must be clearly demonstrated. Without an appropriate balance between strategic vision and tactical alignment, MDM initiatives can suffer for want of adequate sponsorship and visibility. Every MDM initiative during its life cycle will lean either towards the strategic vision or the tactical alignment. Maintaining this balance is a key challenge with steering MDM initiatives. This requires that Enterprises must have the appropriate ownership and governance structures to achieve this balance with MDM initiatives. Executive steering signals must drive organizational behavior to accomplish this balance. Senior executives must be sensitized to the nature of this balance. Enterprise Architecture has the broadest view of the IT portfolio in the organization. Without such a broad view of the IT portfolio, MDM initiatives can become narrowly focused. Enterprise Architecture must provide the leadership and guidance, to establish an MDM road map. 9

11 This requires that there must be a strong Enterprise Architecture team, in the first place. The Enterprise Architecture must educate and evangelize the concept of MDM and the nature of the MDM journey with the senior IT and Business executives. Enterprise Architecture must guide individual projects, product selection exercises, and technology choices to align them with the MDM vision. A enterprise level program management function must align projects with the MDM initiatives. Without a program management function governing and overseeing the current in flight projects, there is a risk of individual projects making decisions that are not in alignment with the over all MDM vision. Individual project design and architecture decisions made without the overall MDM vision in mind can be counter productive and cause inefficiencies. It is not uncommon to have multiple MDM like initiatives sprout up, each with a narrow focus and little convergence. The enterprise program management function, must work closely with Enterprise Architecture to provide Architectural convergence across the portfolio of projects currently in flight. Clear mechanisms for Architectural reviews, compliance assurance and exception management must be established. Sustainable success in the MDM journey is dependant on this balance between strategic vision and tactical alignment. Enterprise Architecture and Enterprise Program Management are two governance functions that are critical for enabling this balance. Tactically oriented MDM projects must be brought under the fold of an Enterprise governance function. The Enterprise Architecture and Enterprise Program Management Office roles must be strengthened and enabled to operate as a team, in order to steer MDM initiatives for success. TCS is a 35-year global veteran and visionary pioneer in the IT industry, currently serving seven of the Top Ten Fortune corporations in the U.S. alone. We believe organizations gain a competitive edge by partnering with our business and domain experts. Some of the key advantages that your organization will experience working with our MDM Practice include: Extensive experience, credentials and expertise in the areas of ERP, BI, CRM, and SCM technology space. Alliances with major MDM/CDI vendors like i2 Technologies, IBM, Initiate Systems, Kalido, Oracle, SAP, Siebel, Siperian, which we leverage to provide appropriate product independent and best-in-class solutions for our clients. A dedicated product group focusing as a team on your Data Profiling and Cleansing requirements. A Data Quality Improvement Methodology derived from extensive Six Sigma Process Consulting engagements designed to optimize data quality investments; maximize the impact of the data cleansing and process improvement effort; and to accelerate Value Delivery. 10

12 About TCS MDM Consulting Through our MDM practice, TCS delivers end-to-end Master Data Management (MDM) consulting and implementation services that are innovative and visionary, yet practical. In the MDM Practice, we view our affiliation with our customers as a journey, not as a project. MDM, CDI and PIM Solutions assists in redefining your approach to data management across both the Operational and Analytical environments. We strive to deliver a cost-effective, high-quality solution in a fluid but timely manner that avoids unnecessary business disruptions. Our goal is to understand our customers challenges and business objectives, and then design a solution, based on market leading solution packages or one that is tailormade just for your organization. TCS has offerings that span the entire spectrum of the MDM adoption cycle. TCS' services include Envisioning the MDM Program, Establishing the MDM Strategy, Architecting the MDM Solution, Delivering the MDM Solution About Tata Consultancy Services (TCS) Tata Consultancy Services Limited is an IT services, business solutions and outsourcing organization that delivers real results to global businesses, ensuring a level of certainty no other firm can match. TCS offers a consulting-led, integrated portfolio of IT and ITenabled services delivered through its unique Global Network TM Delivery Model, recognized as the benchmark of excellence in software development. A part of the Tata Group, India's largest industrial conglomerate, TCS has over 94,000 of the world's best trained IT consultants in 47 countries. The company generated consolidated revenues of US $4.3 billion for fiscal year ended 31 March 2007 and is listed on the National Stock Exchange and Bombay Stock Exchange in India. For more information, visit us at global.consulting@tcs.com All content / information present here is the exclusive property of Tata Consultancy Services Limited (TCS). The content / information contained here is correct at the time of publishing. No material from here may be copied, modified, reproduced, republished, uploaded, transmitted, posted or distributed in any form without prior written permission from TCS. Unauthorized use of the content / information appearing here may violate copyright, trademark and other applicable laws, and could result in criminal or civil penalties. Copyright 2007 Tata Consultancy Services Limited