In talking to companies that use SAP, a common theme has emerged: They want to use their SAP application investment to address the key business issues that their organizations face. These issues usually include master data. Think of master data as parties (e.g., people and organizations), places (e.g., locations), and things (e.g., products and G/L Accounts). Consider the ways in which companies use master data in business processes and transactional events.
An ERP investment highlights the need for master data. In implementing SAP ERP, customers want to select one platform to handle all SAP and non-SAP data integration demands, maximizing the return on their IT assets. Even companies that consider themselves SAP shops usually manage a heterogeneous IT environment, with applications and databases from multiple vendors. Data integration becomes a technical imperative in response to a strategic business imperative. The most prevalent are general ERP deployments, consolidations and migrations, and service-oriented business transformations.
General ERP deployments typically have large amounts of data, in many legacy systems, which companies must handle when populating an ERP deployment. Think of this as master data consolidation that sets the stage for reuse and distribution.
Data integration is also important to ERP-instance consolidations and application migrations. Some large enterprises have instances of ERP that they want to centralize to keep maintenance costs down, streamline and better manage their business processes, and make adding new users to the system easier. Other organizations strive to migrate from competing enterprise applications or disparate applications that serve similar purposes as a new SAP ERP Central Component (SAP ECC) deployment does. In this scenario, companies require master data centralization, which provides one source for inter- and intra-enterprise data needs.
For service-oriented business transformations, companies must update any master data changes in one application with a consistent view from the central repository (e.g., matching, merging, and ID-mapping of the data). For example, both SAP Customer Relationship Management (SAP CRM) and SAP Sales & Distribution (SD) can take orders, yet the master-data requirements are different. You can also use the customer master data simultaneously in legacy and SAP NetWeaver Business Intelligence (SAP NetWeaver BI) systems. This requires master data harmonization.
SAP NetWeaver Master Data Management (SAP NetWeaver MDM) is garnering more interest among SAP NetWeaver adopters as a silver bullet that addresses the data issues arising from these scenarios. As more companies operate with distributed systems, they need SAP NetWeaver MDM to support the synchronization of master data across the enterprise. Think of SAP NetWeaver MDM as the sum of all acti- vities, processes, and technical mechanisms required to achieve effective master data management.
This definition might create confusion with SAP NetWeaver BI. Where does SAP NetWeaver BI fit in? Can’t it address these challenges? The issues with heterogeneous data and SAP NetWeaver MDM are similar to those with SAP NetWeaver BI. How do you implement an MDM application that controls “product” as a business object when many non-SAP operational systems define the “product” differently? Understanding, harmonizing, and transforming this data, so that companies can manage it is a complex problem in heterogeneous IT landscapes. The total solution for data management leverages MDM and BI.
MDM and BI
The two toolsets of MDM and BI have similarities. To an organization, the values of MDM and BI are the same. They just capture different data. The dissimilarities, however, are great; one toolset cannot replace the other. When a company implements both, the value is greater than the sum of the parts.
As you evaluate your data needs, first consider the unique values of both MDM and BI and the challen- ges of each. From a BI perspective, you can capture some of the value of MDM with more sophisticated BI installations. For example, many Operational Data Stores (ODSs) duplicate the data in the ERP and other systems and can be used to validate master data.
But don’t let BI replace the underlying need for MDM. The major difference that enterprise executives need to understand is that MDM is a transaction-oriented system and BI is an analytical-based system. BI data models are designed to support queries rather than transactions. The entire infrastructure for BI — hardware, database, storage systems, and client tools — is designed to support analytical activity rather than services-based transactions. Also, BI systems need to provide a stable picture of the business. As an example, an analyst who runs a query on customer count, reruns the same query one minute later, and obtains a different answer will have a difficult time preparing forecasts.
MDM’s primary value comes from less redundancy and an easier implementation of new online applications. Think of an MDM system as a hub to optimize and support transactional systems, such as call centers, inventory systems, and ERP systems. These systems need portions of the same master data. An MDM system understands how to create customer data and when to update a product name. BI doesn’t capture the business process; it simply attains the result of the process. BI doesn’t capture how to create a new account, but it does hold the accounts and is able to assign transactions to those accounts. An MDM system enhances the business objects that it holds, such as customers and products.
Because it draws from different sources and retains the business rules of how to operate on those items, the MDM system can create a more comprehensive view of a business process. For example, a few minutes after a CRM system creates a new customer, a Web application adds that customer’s email address. MDM then sends that email address back to the CRM system, updating it. When the information is needed from two or more applications, the calling application must make multiple calls. With MDM, however, a single Web-service call can return all the information needed, including a current address and previous address, as well as all the account numbers associated with these addresses.
Process innovation needs master data convergence. Both MDM and BI supply the means for more event and customer-driven interactions that require the system to write back data, which has more transactional characteristics. These new business processes impel the need for more transaction-oriented data structures and convergence of operational systems. Organizations requiring a single view of the customer or product-based initiative need to plan how they will complement analytical capabilities and support the evolution of new business practices. MDM and BI provide the way.
MDM Becoming the Foundation of Enterprise SOA
IT landscapes today are quickly moving toward dynamic environments and service-oriented architectures (SOAs) where specific master data strategies play an important role. Business processes work successfully within the context of dynamic services only if they are founded on reliable information — that is, consistent master data. In my opinion, using MDM is inevitable.
The challenge is to position master data so that any business processes that cross application boundaries can translate and interpret the data when needed. When you examine the MDM requirements in any scenario, you see the need for a portal (e.g., user interface), messaging (e.g., middleware), reporting (e.g., BI), and workflow and process modeling (e.g., modeling tools) — all the components of a modern enterprise SOA stack. Remember to look closely at the end state because this combined solution set must be highly scalable and capable to perform in near or real time, and many combinations of MDM and BI do not.
|Adolf Allesch is the global SAP NetWeaver lead partner at IBM Global Business Services. A pioneer with the Web, he is now the SAP Net-Weaver evangelist for IBM. He specializes in technology-enabled business transformation using SAP and is a frequent presenter at SAP events worldwide. You can reach him at firstname.lastname@example.org.