Central master data management

Methods and apparatus, including computer program products, for sharing data. The technique includes creating at least one data object in a central system, the data object including a complete object definition, and dependencies to other objects, mapping at least one data object to other data objects in the central system, and distributing data objects from the central system to one or more client systems, where the one or more client systems.

BACKGROUND

The present invention relates to data processing and to data management systems.

Information technology (“IT”) environments can consist of many different systems performing processes, such as business processes, on common master data. The different systems can be part of the same entity or can be part of different entities, such as vendors or contractors. The master data used for the processes can be stored in a number of different locations, systems, and/or incompatible formats. Branch offices of a company can work largely independently, adopted companies can introduce new software solutions to a group of affiliated companies, systems from different vendors can be linked. Different master data models can make it difficult to integrate business processes in these scenarios.

Master data can become trapped and siloed in different systems. Master data that is not aligned across an IT environment can lead to data redundancies and irrelevant or incorrect information. For example, if two local branches of the an international company each have the same local branch of a second international company as a business partner, each international business partner can be maintained twice, with no correlation between the two “business partner” master data objects. This can result in high costs for redundant multiple content maintenance. Further, business analytics performed with redundant or obsolete information can result in poor business decisions. In the above example, a company-wide analytic process can fail to detect the correlation between the “two” partners, and business value that could be leveraged out of recognizing these business partners as international business partners with two local branches would be lost.

SUMMARY OF THE INVENTION

The present invention provides methods and apparatus, including computer program products, for sharing data.

In general, in one aspect, the invention features methods and apparatus, including computer program products, for sharing data. The technique includes creating at least one data object in a central system, the data object including a complete object definition, and dependencies to other objects, mapping at least one data object to other data objects in the central system, and distributing data objects from the central system to one or more client systems, where the one or more client systems receive all data objects of an object type used by the client system from the central system.

The invention can be implemented to include one or more of the following advantageous features. A request can be received from a client system to create the data object. A matching process can be performed on the request to determine if a duplicate data object or similar data object exists in the central system, and the created data object can be mapped to similar data objects if similar data objects exist in the central system. The requesting client system can be notified if a duplicate data object exists in the central system. Performing a matching process can include comparing attributes of the request to attributes of data objects stored in the central system.

Analysis can be performed based on the data objects in the central system using the mapping information. At least one data object can be received from a client system, and the at least one data object can be staged. The received data object can further be mapped.

The data objects can be mapped according to industry specific standards. A framework can be distributed to configure client system software to receive data objects from the central system. The dependencies to other objects can be defined for the data object. Defining the dependencies to other objects can include defining a packet of objects. Defining a packet can include defining a product structure. Distributing data from the central system to one or more client systems can include distributing data in packets. Defining the dependencies to other objects can include defining a view including parts of objects.

The data object can be updated with information received from a client system. Updating the data object can include periodically updating the data object and/or updating the data object in response to an indication that the data object was changed in a client system. Distributing data from the central system to one or more client systems can include distributing data from the central system to one or more client systems in response to an updating the data object. Updating the data object can further include updating dependencies to other objects.

In general, in one aspect, the invention features a system for sharing data. The system includes one or more client systems, and a central module of an entity including a central data store to store all attributes of data objects for an entity. The data objects can be for use by the one or more client systems and can include complete object definitions, mapping information mapping the data object to other objects and dependencies to other objects. The central data module can be configured to distribute data objects from the central data store to the one or more client systems.

The invention can be implemented to include one or more of the following advantageous features. The central data store can include complex analytics based on master data for an entity, where the complex analytics includes a data warehouse.

The invention can be implemented to realize one or more of the following advantages. A central master data management system allows all master data to be maintained centrally. Central maintenance of master data allows avoidance of data redundancies and improved cross-group reporting. Since master data objects are stored only in a central system, updated master data is not trapped in a client system. Thus, all master data used by systems is up to date. The central master data management system enables consistent business processes through distribution of master data and mapping information to all clients. Also, cross company reporting is enabled, the resources related to maintenance of data can be reduced, and master data can be aligned across systems and companies.

The details of one or more implementations of the invention are set forth in the accompanying drawings and the description below. Other features and advantages of the invention will become apparent from the description, the drawings, and the claims.

DETAILED DESCRIPTION

As shown inFIG. 1A, a collaborative master data management (“cMDM”) system includes a central module100and one or more client modules110a-d, collectively referred to as client modules110. Each client module110a-dis linked directly to the central module100.

The central module100can include a central system representing a centralized control of data management for an entity, such as a business or an organization. The client modules110can include systems or groups performing processes on master data. For example, the client modules110can include systems and/or groups involved in a product creation process. In this example, the client modules10can include a legacy module, an e-procurement module, an e-sales module, a sourcing module, a collaborative engineering module, a manufacturing module and enterprise resource planning (“ERP”) modules.

The master data can be stored in the client module (e.g. client module110a), in the central module100or in both, depending on the implementation. The central module100allows the master data used by each client110a-dto include master data that is shared by all clients110. Traditionally, client modules110would communicate directly with each other in a point to point architecture. For example, a manufacturing module might need to share master data with an e-procurement module, an e-sales module and a collaborative engineering module, among others. In traditional systems, the manufacturing module would receive data from or transmit data to the appropriate module, which could lead to inconsistency in data or the use of obsolete data, if data is not updated in the module transmitting the data for sharing. In the system described with reference toFIGS. 1A and 1B, data is managed through the central module100. The central module100ensures consistent master data, and the distribution of the master data.

As shown inFIG. 1B, the cMDM system can be implemented to be used across a plurality of entities120,130a-b. The central module100can be part of a base entity120. The client systems110can be part of the base entity120or part of an external entity (e.g., external entity130a). For example, the base entity120can include an enterprise including client modules110for ERP, legacy, e-procurement and e-sales. The base entity can be divided into units140a-c, where each unit can include one or more clients110a-d. The external entities130can include a contractor including a client (e.g., client110a) for manufacturing and a supplier including clients110for collaborative engineering and sourcing.

In another example, the base entity120can include a customer service entity while an external entity130can include an enterprise. Customer information that may normally be dispersed over multiple client modules110can be consolidated through central system100.

The centrally managed master data can be used for processes such as cross-group reporting, data integration for mergers and acquisitions, reducing the diversity of parts, supporting product maintenance, simplification of customer management, and supporting catalogs such as through merging catalog contents and bundling of purchasing activities into a smaller number of vendors. The cMDM system can also support versioning and change management. As versions are created or changes made, the data for the versions or changed data can be managed through central module100, as described below.

A setup of a cMDM system can be performed before data is exchanged between the cMDM system and client modules110. Identification attributes are specified for master data objects and rules for matching are established. The setup of attributes and rules for matching can be performed with regard to the entity using the cMDM system, or with regard to the object needs in general. A matching process performed on master data objects received from client modules can be used to manage the master data objects.

Specifying attributes can include matching different objects from different client applications or different client modules10. Specifying attributes can also include linking elements of the matched structures together so that master data objects received from different client systems can be compared.

The specified attributes can also be ranked during setup. The ranking of attributes can be used during a matching process to determine whether two master data objects are identical. Thus, if an attribute that is ranked higher doesn't match between two objects, it is more likely that they are not identical or similar than if an attribute ranked lower on the list does not match.

The cMDM system can be implemented in at least three different scenarios, as described with reference toFIGS. 2-7. The scenarios can be implemented separately or introduced in an evolutionary manner, by starting with a content consolidation scenario and moving to a master data harmonization scenario or moving from a master data harmonization scenario to a central master data management scenario. The different scenarios can also be used together. For example, central master data management can be used for some object types while master data harmonization is used for the rest. The mixing of the scenarios will be discussed in more detail below.

Content Consolidation

FIG. 2is a block diagram illustrating a content consolidation scenario for a cMDM system. Central module100can include a load module210, a staging module220, a match module230and an ID mapping module240. The consolidated content resulting from the processes performed in central module100can be used in processes250such as business analysis, (e.g., global spending analysis) or creation of central catalogs (e.g., a supplier product catalog).

At load module210, master data objects are received into the central module100. Master data objects are uploaded into central module100in the form in which they were maintained in their local applications (client modules110). At staging module220, a user at the central module100can determine if the master data objects are loaded correctly. For example, the user can check the content of the master data object loaded in load module210to make sure that the content of the master data object is correct. The master data objects can be cleansed in the staging module220to standardize the content of the master data objects. For example, if the standard format for abbreviating New York is “NY,” and one of an input master data object has the abbreviation as “N.Y.,” the content of the input master data object can be changed to “NY” by removing the periods in between the “N” and the “Y.” Data cleansing can also include removing mistakes and inconsistencies to make data more accurate.

The staging module220can also be used as an intermediate storage for received master data objects for a master data client. The intermediate storage can be used while processing matching and mapping routines described below with respect to match module230and mapping module240, respectively. The intermediate storage can also be used during individual user interaction before upload of master data objects.

Matching processes can also be completed in the staging module220. The master data objects are forwarded to a match module230. If the match module230does not automatically match the master data objects based on the identified attributes, the master data objects can be returned to the staging module for manually deciding whether the master data objects match.

At match module230, a matching process can be performed on the uploaded master data to identify identical or similar data objects. Identical data objects are master data objects that are semantically identical, and which are received from different client modules110. Identical data objects can have two different object IDS. Duplicate data objects are semantically identical master data objects within the same system, such as a client module110a. Possible duplicates are recognized automatically and reported. One or more of the duplicate data objects can be removed from the client system.

The matching process includes recognizing similarity between master data objects. The matching process can include identifying attributes of the data objects and comparing the attributes. The attributes that are compared can include attributes that are valid entity-wide for master data object types, so that identical and similar data objects can be recognized, although the content of the attributes can differ from system to system. Thus, different data formats and structures can be retained in different systems.

If the amount of match between two master data object is within a certain range, the results of the matching process may be considered to be unresolved. For example, if two master data objects match 50-80%, the results of the matching process can be considered unresolved. For example, if a master data object to be matched is a business partner, and four of five attributes match another business partner master data object, the amount of match would be 80%. Thus, the issue of whether the two objects match can be considered to be unresolved. The master data object can be returned to the staging module for an user to manually determine if the master data object matches another master data object.

The mapping module240receives the results of the matching process from the match module230. At mapping module240, the similar or identical objects can be mapped to each other. For example, an object identification (“ID”) of one object can be mapped to an object ID of a similar or identical object. The mapping information can be updated each time a change is made to a data object. The mapping can be performed automatically based on rules established during set up of the master data management system. The mapping can be stored in a mapping table. The mapping information can change based on changes made to a master data object. For example, if “N.Y.” in master data object A is changed to “NY,” master data objects that were not mapped to master data object A can now be considered identical to master data object A and master data objects that were mapped to master data object A will need to be changed. Thus, changes can be managed through mapping information and updates to mapping information by making the mapping information available to client modules110. Similarly, when a new version consisting of a group of data objects is defined, mapping information and updates to the mapping information can be used to manage the version.

The mapping information can be provided to process module250. Process module250can include complex analytics, including a data warehouse, such as a business information warehouse, for system-wide reporting. The processes performed in process module250can include creation of a central catalog or company-wide analysis and reporting, such as global spend analysis or mergers and acquisitions.

FIG. 3is a flow diagram illustrating a method for consolidating data. Data is received into central module100from one or more client modules110. (Step310) If the received data content is not aligned with content of a central system in central module100, the received data can be cleansed.

A matching process is performed on objects of data in the central system to determine if there are identical or similar objects in the central system. (Step320) The matching process can include comparing identifying attributes of the objects. The matching process can also include identifying duplicates. If two or more objects are found to be duplicate objects, one or more of the duplicate objects can be avoided from being entered into the central module. The duplicate master data objects can be transferred to the staging module220, where one of the duplicate master data objects is removed from the central module100. The cMDM can also support removal of one or more of the duplicate master data objects from the system from which the duplicate objects were received.

If identical or similar objects are found, the central module can perform a mapping process. (Step330) Object IDs of identical objects can be mapped to each other, and object IDs of similar objects can be mapped to each other. The object mapping information can be provided to a process. (Step340) As discussed above, providing the mapping information to a process can include providing the mapping information to a data warehouse, such as a business information warehouse, for use in system-wide analysis and reporting. The mapping information can also be provided to the client modules110.

Master Data Harmonization

FIG. 4is a block diagram illustrating a second scenario for cMDM. The second scenario includes a master data harmonization implementation. This scenario can be implemented by adding master data storage to a content consolidation implementation. This scenario can be used to enable the maintenance and consistent distribution of global attributes of the master data. The harmonized content resulting from the processes performed in central module100can be distributed to client modules110and process module240to be used in applications such as, for example, business partner administration, central provision of sales articles, definition and administration of non-variable parts.

The master data objects can be created in the central module100, in central creation module410, or in client modules110. Master data objects created in client modules110are received in staging module420. Portions of the master data objects and the mappings between master data objects can be stored in the central module100. The portions of the master data objects stored can include global attributes of the master data objects.

Master data objects created in central creation module410can be created to include only global attributes of the master data object. Global attributes can include the identifying attributes. Which attribute is to be maintained for each object type can be dependent on information requirements and the system landscape. A framework can be added to the cMDM to enlarge an object model without doing any modification of the software used to create the master data object in the local system. The framework can deal with new issues and new fields. For example, the object description (data model for an object) can be tailored to a central instance. For example, fields may exist in data models in one system that do not exist in data models for another system. The framework can also support updating user interfaces for client systems receiving master data objects having different attribute fields. After distribution of the objects, as discussed below, the distributed objects can be provided with additional attribute values in the client modules110.

Locally created master data objects can be created using the local application of the client (e.g., client110a). Client modules110can distribute the global attributes of the locally created master data objects into staging module420. A cross system search can be made for the master data object before it is created in the client module (e.g., client module110a). The master data object is created if no similar master data object exists. If a similar master data object does exist, central module100makes the similar master data objects available to the user at the client module (e.g., client module110a). For example, the central module100can make similar master data objects available to the user at a client module (e.g., client module110a) through a server. Thus, the similar master data object can be transferred to a server in the central module100and then transmitted to a client system at a client module (e.g., client module110a).

The user can subscribe to the similar master data object, and mapping information can be updated to include the new local system. If no similar object is found, after creation of the master data object, the created master data object can be transmitted to other target systems.

Continuous matching processes can be performed in matching and mapping module430. For example, mapping can be performed in response to a request to create a master data object in central creation module410. The continuous matching processes can be used to identify identical and similar data objects. The identical and similar data objects can be mapped to each other, as described above.

Duplicate objects identified by the matching process can be avoided from being created in local systems. For example, if a local system requests a master data object for a new business partner, a user at the central module100can check to see if the business partner master data object already exists in the central module100. If the business partner master data object does exist in the central module, the master data object can be distributed to the client system requesting the new master data object. If the user recognizes that the existing business partner master data object already exists in the target system, creation of a duplicate master data object is avoided. Mapping information can be provided to process module240for processes such as business-wide analysis.

The global attributes of the master data objects, including mapping information, can be distributed to the various client modules110through distribution module440. Thus, all systems are supplied with the same global attributes after distribution, and business processes can be processed securely. Objects that logically belong together can be changed and distributed together. For example, when the master data include master data for a product, the objects that belong to the product, such as product structures and documents, can be collected together in a packet and then, distributed in one context to a recipient client module (e.g., client module110a). A packet can include a group of individual objects that are linked through relationships including dependencies, such as objects in a product structure. A packet can be collected according to information requirements of the recipient client module (e.g., client module110a), and can be transferred in a certain sequence.

For example, if a BOM changes or is to be distributed to a target system, rules associated with mappings for some specified systems can indicate that product masters for materials have to be transferred to a specified system before the BOM so that the specified system can recognize the product ID for the materials. Thus, sequencing of objects to distribute can be enabled to comply with semantics and requirements of target systems.

Client modules110can complete master data information for the received master data objects in the local environment. Changes to the master data can also be managed centrally in central module100. The changes can be received, approved, and then, distributed to client modules110.

Master data created in central module100can be created in response to a request from a client module (e.g., client module110a). For example, a business user at a client module (e.g., client module110a), using a client system, can fill out a request form for a new product master and transmit the form to a user at central system in a central module100. Forms can be checked to ensure that the forms are correctly filled. For example, the forms can be checked semantically or units of measurement can be checked to ensure the correct units are used. The user at the central system can view and accept the request. The user at the central system can then check for duplicates, complete the given information, and then, create and distribute the new product master.

FIGS. 5A and 5Bare flow diagrams illustrating methods for master data harmonization. Referring toFIGS. 1A,1B,4and5A, master data harmonization can include the creation of master data objects in the central module100as well as the client modules110. (Step510)

The master data objects can be created in three ways in master data harmonization. A new master data object can be created in the central module100directly or a new master data object can be created in the central module100in response to a request from a client module (e.g., client module110a). A master data object can also be created locally in a client module (e.g., client module110a) and transferred to a staging module420. Master data created locally, in client modules110can be uploaded to central module100.

The created objects can be stored in central module100. The master data objects stored in central module100can include global attributes of the master data objects.

Continuous matching processes can be performed on the stored master data objects. (Step520) The continuous matching processes can be used to identify duplicate, identical and similar data objects. Duplicate objects found can be removed, and object IDs of identical and similar objects can be mapped.

Master data object information, including global attributes of the master data objects and mapping information, can be distributed to the client modules110. (Step530) The master data information for the master data objects received in the client systems can be completed in the client modules110. (Step540)

FIG. 5Billustrates a method of master data harmonization where the master data is created locally, as discussed above. A master data object is created locally. (Step550). The locally created master data object is staged. (Step560).

Central Master Data Management

FIG. 6is a block diagram illustrating a central master data management implementation of a cMDM system. In the central master data management scenario, master data is controlled completely in the central module. In this implementation, all master data information resides centrally in central module100. This implementation can be used for applications such as a central product data pool supplying product data to multiple locations for production, assembly, sales and distribution.

At central creation module610, master data objects can be created. The created master data objects can include complete object information including complete object definition, object mapping information and object dependencies. The master data objects can be created in response to a request from a client module (e.g., client module110a). Matching processes can be performed in response to the request, and mapping information can be included in the data object information stored in the central module100. If identical objects exist in the central module100, the requesting client module (e.g., client module110a) can be notified that an identical object exists, and a new master data object is not created or mapped to an existing object. The mapping information can be updated.

At distribution module620, the centrally maintained master data information can be distributed as individual objects as they are defined in the client modules110. The objects can be distributed in packets. Objects that belong together can be changed and distributed together. If the master data includes product model master data, the objects that belong together, such as products, BOMs (bills of material), and documents, are collected together in a consistent packet and distributed together. The objects can be collected according to information requirements of the recipient client module (e.g., client module110a). For example, the objects can be collected in reference to a particular view for a product. A view can include product relevant attributes, such as purchasing dates. Thus, a group of objects can be linked according to usage or location. For example a sales view can include attributes or content of objects that are related to or used by a sales department.

As discussed above, the scenarios can be used together. For example, central master data management can be used for business partner master data objects, where all of the business partner master data object information is maintained in central module100. The central module100can store only global attributes for the rest of the data objects, such as product master data objects.

FIG. 7is a flow diagram illustrating a method for central master data management. The central master data management process can be performed in a homogeneous environment. Referring toFIGS. 1A,1B, and6, at least one data object is created in a central module100(step710). The central module100can include a central system for a cMDM system. Central module100can store complete data object information which can be distributed to client modules110. Thus, the created data object can include complete object information including a complete object definition, mapping information mapping the data object to other objects, and dependencies to other objects.

The data object can be created in response to receiving a request from a client module (e.g., client module110a) to create the data object. A matching process can be performed on the request to determine if a similar or identical data object exists in the central system. If a similar or identical data object is found, the identical data object will be distributed to the requesting system and the distributed object will be mapped automatically.

Data objects from the central system can be distributed to one or more client modules110. (Step720) Distributing the data objects can include distributing the data objects to client modules110. The data objects can be distributed in packets. The packets can be defined in the central module100based on requirements information received from a recipient client module (e.g., client module110a).

The method of central master data management can also include performing changes to data objects and updating the data objects stored in the central module100based on the changes received. The updated data objects can be distributed to the client modules110.

Master Data Management System

FIG. 8is a block diagram illustrating a simplified structure of a central module100. Central module100can include an exchange infrastructure (“XI”)810, a content integrator (“CI”)820, and a master data server (“MDS”)830. The XI810can be used for communication between client modules110and central module100.

Master data that is to be distributed is received in XI810. Distribution can be performed in three different ways, including subscription based distribution, historic distribution and content based distribution. A routing model (not shown) stores information about which systems are interested in the master data. The master data is then sent from the XI810to the relevant systems. Queuing can be used to ensure consistent messaging across the XI810. Messages can be sent in XML (extensible markup language) format between the systems.

CI820can correlate master data from different systems by defining identifying attributes for each object. The identifying attributes are fed to CI820from different systems in client modules110and scanned for analogousness according to predefined rules. The CI820saves an object ID for objects in the system landscape, no matter to which system they belong, or to which data model they are subject. Master data objects that are stored in client modules110retain the identification defined in the respective client systems storing the master data objects. CI820understands that the respective instantiation relates to some other object in the system (using the mapping function). Thus, CI820performs the matching processes and preparation of the resulting ID mappings.

In one example, mapping can be done using industry specific standards. Different industries such as Chemicals, Consumer Products(“CP”)/Retail and so on, define standards of how an object should be described for their requirements. In one industry, for example, in CP it can be sufficient to describe a product name, description and a class (e.g. ‘SWEETS’), while in Chemicals only the class is not sufficient. Thus, attributes and their values are used to describe the chemicals sufficiently. Thus, the attributes can be like a language for an industry. Therefore, the mapping of a MDM standard-xml format to industry specific standards is supported. Industry specific standards include, for example, CIDEX, Pidx, RosettaNet, Pricat.

CI820use the mappings for a double checking process for creating objects. The central module100receives a request to create a master data object. The CI820checks the request for identical objects. If no match is found, the central module generates a new object. The CI820then performs a check for the new object. If no match is found, then the central module stores the new master data object. Thus, even if the first check is incomplete based on the description provided by the client module (e.g., client module110a), a match may be found when the object is completely created.

Merge strategies can be used to combine two or more objects that are found to be similar or identical. For example, if a master data object for a pump is produced in a purchasing system, a sales system and a production system, one object can be created in central module100by merging the three master data objects. For example, a new object can be created where different systems have authorizations for different parts of the object. Thus, a purchasing system can maintain purchasing information for the master data object. Although the purchasing system can view sales and production information, the purchasing system can be given authorization only to maintain the purchasing information.

MDS830can include a central data store for storing data objects. MDS830can perform the processes of object creation and change. MDS830can also provide services for change management, such as unified versioning, and status management. Grouping of changed objects into packets for distribution can also be performed in MDS830.

The invention has been described in terms of particular embodiments. Other embodiments are within the scope of the following claims. For example, the steps of the invention can be performed in a different order and still achieve desirable results.