Launching MDM as Part of Larger Initiatives

Let me walk through a situation that may be common in many organizations. You as an IT visionary recognize the need for MDM initiative but are having difficulty appropriating funding due to cost concerns or simply as a result of organizational inertia. You decide to ride the coat tail of another major initiative that is somewhat related to the successful implementation of the MDM. Is it a good idea? I would suggest yes, but be careful about setting expectations and having the right level of buy in or your successful execution of MDM initiative may be perceived as not so successful. This may happen due to personalities involved or not having MDM implementation risks included in your schedule or cost estimates. You can be sure that you are going to run into data issues, and amount of data you wil have to deal with will always be more than you think. All these issues may impact the larger intiative and will reflect badly on the MDM effort.

Make sure all stakeholders understand that while MDM is expected to support the larger initiative, it has its own benefits and its goals are much larger in scope. Also, include additional time and cost to mitigate the risks.


Ashok

Best Practices: Master Data Management

Following are some of the best practices for adopting (note - not implementing) Master Data Management solutions within an Enterprise.

Understand the Business Context (semantics) prior to picking a solution

As per my earlier blog on EA, BPM, SOA and MDM it is very important to understand the business context, including the semantics of what each of business units, departments and entities mean when they refer to MDM entities such as Customers or Products. For example marketing deals with leads, sales with opportunities/accounts and services with paid customers. Should all the entity be referred to as customers throughout the business process? or should the master entity be referred to as Organization? Common vocabulary goes hand-in-hand with master data.For example what does this sign on a building mean? Is the building fully occupied and available for purchase? or does it mean that the entire building is unoccupied and available for rent? The business context needs to be clearly defined in terms of business units, departments and business processes.

Develop a comprehensive entity model.

Not only should one define the common attributes for the master data, one should map the entire set of attributes and where it is used. For example, in customer services the customer is used as a reference whereas in order management it is transactional data.
A set of models and documents that can be used both by Business and IT.

Establish data governance process right up front.

It is important to establish data governance process right upfront, especially as this may required dedicated resources from all the business units as well as from IT to manage the master data. The approach that worked for us is as follows:

• Executive Leadership Team Data Leadership Team that meets on a periodic basis (once a month) to establish data policies, standards, establish priorities for the data quality team
• Data Stewardship (Quality) Team are the business operations people who manage the data quality on a day to day basis. The business team enforces and ensures data quality across the enterprise.
• Enterprise Data Program team is responsible for developing and managing the programs and business rules in the various technology tools.

Integrate with 3rd party data providers

It is important for enterprises to consider bringing in 3rd party data providers such as D&B and Factiva for better understanding of the market. For example on a typical morning between 9:00am and 11:00am

• 706 businesses will move
• 578 businesses will change their phone numbers
• 60 businesses will change their name
• 49 businesses will shut down
• 10 businesses will file bankruptcy
• 1 business with change ownership

Source: Dun & Bradstreet (2004)

3rd party data from D&B could be used for leveraging legal name as the name of the organization, providing knowledge management systems that also provide news feeds as well as market statistics by industry, geography and demography and also mapping it to existing sales.Picking the right data standardization and matching engine:

This is a key technology that will either make or break the quality of your data. I agree that developing the business rules and configuring the matching tool is more important - however from a technology point of view - I would dedicate substantial amount of time evaluating and testing the tools with existing data before picking a technology. My preference would be to use one of the following matching engines:

Trillium, First Logic (now SAP), IBM or SAS.

In cases where a MDM product is packed with a different matching engine, I would be tempted to externalize the data quality to one of the above mentioned data matching engines. Just my preference - maybe the other quality engines may have got better. Do you own evaluation.

Expose all MDM functionality as services
Expose all functionality such as data (address) standardization, data matching, update master and propagate master key.

As usual please do feel free to drop me line with your comments and/or feedback.

- Yogish

Enterprise Architecture, BPM, SOA and Master Data Management (MDM)

One of the best practices for Enterprise Architecture teams to redo the enterprise road map on a periodic basis. It is typically reviewed and updated during the yearly budgeting cycle and my preference is to perform this activity every 18 months. The best practices (and the traditional approach) is to first document the as-is, next develop the target or future state (architecture) and finally develop a short term (6 months), mid term (12 months) and long term (18 months) road map. Preferable an actionable road map that ties back to the business initiatives.

It is good to document the the as-is (or current reality) from all the domains such as Business Context, Applications, Technology, organization and Funding. Typically the business context is best understood by identifying and mapping the key business processes at a high-level.


This approach not only helps have a common vocabulary between business and IT by identifying the key business processes, it also helps identify the key enterprise data objects (entities) such as Customers, Contacts, Products and orders. Based on the priorities of the each of the business process, the next steps would be to drill down into one or all the business processes as illustrated below.
Once again, it is not necessary to use a Business Process Modeling tool (however, using one would be helpful later), the objectives is to clearly identify and document the next level of details. The next steps are to perform the gap analysis on each of the activities as illustrated below.

This approach enables both business and IT clearly visualize the existing gaps, impact areas and cost estimates which helps in developing the priorities and the investment plan. In addition, it is also important to identify and illustrate the list of applications/solutions that support a given business process as well as it perception within Business and IT as illustrated below.
As we develop the actionable road map to the future state, one this is obvious, no matter what we implement or adopt, whether it is a packaged applications, BPM or SOA key enterprise data crosses the silos both from an organization and the applications. It is for this reason, there is a critical need for adoption Master Data Management across the enterprises.

It is very important to spend sometime understanding and mapping these enterprise data objects in the context of the business process. It would also be very helpful to also develop a high-level data model and transaction (CRUD) matrix associated with the business process before initiating the activity of selecting/implementing an MDM solution.

I have seen a lot examples where companies have embarked on an MDM project without developing the architecture (see my blog on Blueprinting Information Architecture for more details) and not meeting the desired business outcome. The two other primary reasons of MDM failures are:

• Lack of developing the data governance model up front that involves all the impacted business units
  
• Assuming that a packaged applications could be modified to be the master data for enterprise.
  

To keep this blog short, I plan to blog more about my thought on BPM & SOA later and please do feel free to review my CDI-MDM Summit presentation on my experience with MDM/CDI.

As usual please do feel free to drop me line with your comments and/or feedback.

- Yogish

Vendor need to adopt "Common Sense" Strategy

A lot of vendors are jumping on the band wagon about the latest jargon such as SOA, Web 2.0 (or Enterprise 2.o), BPM and now WOA(?). It does make sense from a marketing point of view, however they also need to adopt a "common sense" approach.

Following are a few of suggestions to the large ISVs (Independent Software Vendors).

The Platform is the application:
This is true and that a majority of IT organizations are demanding, starting right from the CIO down. This is true not only for enterprise solution but also for consumer solution, resulting in all major Internet (what do we call these companies now? ) companies such as Google, Yahoo!, Facebook, eBay and Amazon.com are taking this approach. For this discussion I shall limit it to the large Enterprise ISVs.

All the major ISVs have announced and invested heavily in developing their next generation application based on a unified middle ware. The message I am hearing from these vendors is that they will support the current version for quite a while (so if you have PeopleSoft 8.x you may be fine until Oracle decides to pull the plug) but they do expect you to upgrade (migrate - and yes! this cost you a bundle!!!!) to the next generation.

This approach really puts the IT organization (customers) in a spot, more so from people skills point of view. First, it will take time for the current staff (or SI partners) to come-up to speed with the new tools sets and second, the early adopter may pay the price to finding major bugs in the field, especially for their mission critical applications such as Finance, Order Management, Supply change, etc. Don't want to have major problems there. I would like to once again repeat that vendors need to incorporate SOA infrastructure in legacy application. If this does not work for them, they why not support the existing (legacy) applications from the next generation development ?

Lets take the case of an IT organization using PeopleSoft 8.x. Why not provide the PeopleSoft developer to developer to develop/modify existing work flow/application logic using their SOA Platform development tool? Agreed Oracle will have to invest in making this backward compatible for deploying the solution to PeopleSoft 8.x. However, this approach will get the existing support engineers up to speed on the latest tool resulting in faster adoption of the next generation platform.

End-to-End Life cycle Management:
Most ISVs, especially the large ones, do not provide an end-to-end life cycle management for their product stack(s). Of course, they will definitely claim that they do - but not really. How many software companies provide the capability for CIO and the IT leadership team keep track of all their major investments? also, how many of them provide the capability to get realistic feedback of the solutions deployed? None - as far as I know. Most of the Strategic IT organizations have been able to put this in place by procuring multiple solutions (IT Governance tools, EA tools, BPM, Enterprise Monitoring and Management Solutions, BI, etc.) and a lot of $$$ to stitch them together. Wouldn't it be great if the ISVs put something together that could be plugged in? Even if it just only for their solutions?

Provide Complete Solutions:
ISVs must provide complete solutions - not just point solutions that requires a lot of time and resources to customerise the solution. Lets take the case of Master Data Management (MDM) - all major vendors provide this solution (and one of them has 4 MDM products, including UCM) but is only a point solution. Why don't the ISVs integrate their MDM solutions with at least all their major (if not all) applications such as CRM, Order Management, Finance, Supply chain and Customer Support? Also, why not also provide the customer with a list of best practices and governance models (for free)?

It may may help if we all collectively push back on the large ISV and also have their Products Managers from ISVs spend 3 months in an IT Organization. Just a thought.

Vendors need to focus on providing practical (real) advice

Since the end of last year - I have had the opportunity to talk to a number of CIOs, Chief Architects and business executives for large enterprises and one of the constant frustration I have heard from the end-user community (IT organizations) is the lack of practical (real) advice from the vendor community.

Following is an example of a simple Business scenarios:

• In order to increase it's revenue Business Operations would like to learn more about the customer - to identify opportunities for cross-sell/up-sell.
• They approach their partners - typically their preferred SI and/or their preferred software vendors.
• Depending on the vendor (including SI - their resell relationship with the ISV) they would recommend a Data Warehouse, Business Intelligence, EAI and/or Master Data Management Solution. In addition, they will also be willing to guarantee, typically as a fixed bid, implementation within weeks/months (typically 3 to 6 months).
• Business buys into it - spend the money and a year later had not yet achieved the end-result they were promised.

Problem:

• Vendors focus on delivering an IT solution (generate the revenue and move on to the next project) instead of solving the business problem

Recommended Approach:

• As part of every engagement - both the SI and ISVs need to insist on conducting a Business workshop (prior to starting the IT implementation).
  
• Provide real-practical advices - example: for a customer master the vendor typically looks for decision from the business to provide them with direction on where to add the customer - Lead Management, Opportunity Management or Order Management. As the vendors have done multiple implementations - shouldn't they know the best practices in the vertical and recommend the approach?
• SI typically have separate organizations that deal with business transformations and IT (CRM/ERP )implementation teams. Shouldn't every engagement have folks from both the practices at the customer site during the initial stages? Agreed the engagement cost will be a bit higher for the customer - but the value received will be substantial greater than the up-front cost. I for one - would be willing to pay. My problem was that no one approached me with such a proposal. However, I was lucky - my CIO recommended (and funded) that I have a full-time architect(s) from an SI on my team.
  

Thanks to SOA - I am starting to see changes in the SI engagement models. They seem to these days more focus on Architecture & Approach first - before bringing in their implementers. However, I am yet to see this transition happening in the ISV community.

The above example is based on my own experience and the case study is available here. As the case study indicates - I had to solve the same problem twice. First implement and learn from my mistakes and then repeat it again later. If we had real advice - we would have got it right the first time.

- Yogish

Key Learnings: Blueprinting Information Architecture is key successful adoption of SOA

Following is the high-level approach for Blueprinting the SOA Framework for the enterprise.

Understand the business process and identify the areas for improvement
„Understand overall business objectives
„Understand specific business pain points
„Understand priorities

Develop the Enterprise Information Models to identify the Information services needed to support business processes

Develop the SOA Framework foundation to identify the infrastructure needed to support the business process needs.





Currently there are a lot of content available on the topic of best practices, key learning, reference architectures, ROI, etc. on the topics of Business Processes and Infrastructure. However there does not seem to be a lot of publications around Blueprinting the Information Architecture for SOA.

Basically there are three areas of focus for Blueprinting the Enterprise Information Architecture and are as follows:

• Reference data: Examples: salutation, job title, contact type, partner type, region, state/province, country, currency, language/locale, and industry
• Master data: Examples: customers, contacts, products and orders
• Analytic data: Examples: marketing data mart, forecasting, customer Life cycle value and customer satisfaction

Categorizing the key enterprise information needs into these three areas enables IT to have an very fruitful discussion with the business. However, the first task is to get business to fund and participate in this Blueprinting effort. Following is a very high level three step approach to Blueprinting the Information Architecture.

1. Scope and Planning (Establish: Budget and timeline, Team, Deliverable)
2. Information Architecture Assessment (Current state: high-level business process, data flow, data models - reference, master and analytics)
3. Information Architecture Blueprinting (Enterprise Information Model, Data Governance, Recommendations and Actionable Road map)

Why is this necessary?

Most business processes cross business and application silos. The current best practice is to migrate/move the data across these silos which results in redundant data, systems and places a lot of burden on business operations teams to clean it manually. In addition, multiple business silos tend to implement the same business process in different applications.

Adopting SOA enables enterprises to reduce the overall cost by enabling business to implement their business processes by consolidating/reusing a single infrastructure/application. This is possible only by exposing the appropriate information services to support the business processes.

This can be achieved only by truly understanding the Enterprise Information Model. Please click here for a three slide presentation on this.