JP2005537595A - Collaborative master data management - Google Patents

Abstract

A method and apparatus including a computer program for sharing data. The technique involves receiving data in the central system from one or more client systems and matching on objects of data in the central system to determine whether similar objects exist in the central system. Performing a process; mapping similar object identifications to each other if similar objects exist in the central system; and providing the object mapping information to the process.

Description

  The present invention relates to a data processing and data management system.

  An information technology ("IT") environment can consist of many different systems that perform processing, such as business processes, on common master data. This different system may be part of a different entity, such as a vendor or contractor, or may be part of the same entity. The master data used for the above processing is stored in many different locations, systems, and / or incompatible formats. Company branch offices can operate very independently, and adopted companies can introduce new software solutions into a group of partners and consolidate systems from different vendors. it can. Different master data models make it difficult to integrate business processes into these scenarios.

  Master data can be trapped and stored in different systems. Master data that is not coordinated across the IT environment results in data overload and meaningless or incorrect information. For example, if two regional branches of an international company each have the same local branch of a second international company as a business partner, each international business partner will be able to determine what between two “business partner” master data objects. There is no correlation, and it is held twice. This leads to high costs for the maintenance of a large number of redundant contents. In addition, business analytics implemented with redundant or stale information results in poor business decisions. In the above example, the company-wide analytic process fails to detect the interrelationship between the “two” partners, and the international transaction with the two regional offices. The business value available from approving these business partners will be lost.

The present invention provides a method and apparatus including a computer program product for sharing data.
In general, in one aspect, the invention features a method and apparatus that includes a computer program product for sharing data. The present technology performs a step of receiving data in a central system from one or more client systems and a matching process for data objects in the central system to determine whether similar objects exist in the central system. , Determining if similar objects exist in the central system, mapping object identifications of similar objects to each other, and providing the object mapping information to the process.

  The present invention can be implemented to include one or more of the following advantageous features. A matching process can be performed on data objects in the central system to determine whether the same object exists in the central system, and if the same object exists in the central system, Object identifications of the same object can be mapped to each other.

  The data can be cleansed to standardize the content of the data. Providing the object mapping information for processing may include providing the object mapping information to a data warehouse for system-wide reporting. An analysis can be performed based on the mapping information. A determination can be made as to whether the same object is a duplicate object from the same client system, and the duplicate object is removed from at least one of the client system and the central system from which the duplicate object was received. Can be done.

  Performing the matching process may include identifying the attributes of the object in the central system and comparing the attributes of the object to determine whether the objects are identical. Object information can be stored in the central system, and the object can be distributed to the one or more client systems along with object mapping information. Here, the object information includes object mapping information for each object and an overall attribute of the object. The object information may be based on data created or received at the central system. The matching process can be performed continuously on object information stored in the central system. The object information stored in the central system may be continuously updated based on data received from the one or more client systems.

  The step of continuously updating the object information may include a step of updating mapping information for each object. An object can be created in the central system and provided with global attributes for the object. Distributing the object can include distributing the global attribute for each object, the method comprising: object information for at least one object in the one or more client systems. The method may further include a step of completing

The data object can be mapped according to industry specific standards.
A framework can be distributed to configure client system software for receiving data objects from the central system.

  In general, in one aspect, the invention features a system for sharing data. The system receives one or more client systems storing master data for use in processing performed in the client system, and master data from the one or more client systems in the central system, In the central system, a matching process for the master data object is performed to determine whether the same or similar object exists in the central system. If the same object exists in the central module, the object identification of the same object If similar objects exist in the central module, the object identifications of similar objects are mapped to each other and the object mapping information is processed. And a said central module that is configured to provide.

  The invention can be implemented with one or more of the following advantageous features. The central module is further configured to remove duplicate objects from the one or more client systems and / or provide the object mapping information to a data warehouse for use in the processing. Can do. The system may further include a data warehouse configured to receive the object mapping information and use it in the processing.

  The present invention can be implemented to realize one or more of the following advantages. A coordinated master data management system for master data enables centralized management of master data. Mapping between the same and similar objects allows for improved cross-group reporting. Duplicate identification allows avoidance of data redundancy. The cooperative master data management system enables consistent business processing through the distribution of mapping information and master data to all clients. Also, cross-company reporting is possible, resources related to data maintenance can be reduced, and master data can be coordinated with system scale and company scale.

The details of one or more embodiments of the invention are set forth in the accompanying drawings and the description below. Other features and advantages of the invention will be apparent from the description, drawings, and claims.
Like reference numbers and designations in the various drawings indicate like elements.

  As shown in FIG. 1A, a collaborative master data management (“cMDM”) system includes a central module 100 and one or more client modules 110. Each client module 110 is directly linked to the central module 110.

  Central module 110 comprises a central system that represents a centralized control of data management for entities such as bisiness or organization. The client module 110 may include a group or system that performs processing related to master data. For example, the client module 110 can comprise groups and / or systems that are included in a product creation process. In this example, the client module 110 includes a legacy module, an e-procurement module, an e-sale module, a sourcing module, and a collaborative engineering module. ), Manufacturing modules, and enterprise business planning (EPR) modules.

  Master data can be stored in the client module 110, in the central module 100, or both, depending on the implementation. The central module 100 allows the master data used by each client 110 to include master data shared by all clients 110. Conventionally, client modules 110 communicate directly with each other in a point-to-point architecture. For example, a production module may need to share master data with, among other things, an electronic procurement module, an electronic sales module, and a collaborative engineering module. In conventional systems, the production module sends and receives data to the appropriate module, which means that if this data is not updated in the module that sends the data for sharing, the use of stale data or Inconsistency in the data is introduced. In the system described with reference to FIGS. 1A and 1B, data is managed through the central module 100. The central module 100 guarantees consistent master data and distribution of this master data.

  As shown in FIG. 1B, the cMDM system can be implemented to be used across multiple entities 120,130. The central module 100 can be part of a base entity 120. Client system 110 may be part of base entity 120 or part of external entity 130. For example, the base entity 120 may include an enterprise with a client module 110 for ERP, legacy, electronic procurement, and electronic sales. The base entity can be divided into units 140, where each unit can comprise one or more clients 110. The external entity 130 may include a contractor that includes a client 110 for production, and a supplier that includes a client 110 for collaborative engineering and sourcing. .

  In another example, base entity 120 can include a customer service entity, while external entity 130 can include a company. Customer information that is typically distributed across multiple client modules 110 can be consolidated through the central system 100.

  Centrally managed master data reduces cross-group reports, data integration for mergers and acquisitions, and diversity of parts Process, such as product maintenance assistance, customer management simplification, and merging inventory content and bundling purchasing activity to fewer retailers It can be used for cataloging support like through. Also, the cMDM system can support versioning and change management. When a version is created or changed, the version data or changed data can be managed through the central module 100 as described below.

  The cMDM setup can be performed before data is exchanged between the cMDM system and the client module 110. An identification attribute is identified for the master data object, and rules for matching are established. Rules for setting up and matching attributes can generally be implemented with respect to object demand or with entities using a cMDM system. The matching process performed on the master data object received from the client module can be used to manage the master data object.

  The identification of attributes can include matching different objects from different client applications or different client modules 110. Also, identifying the attributes can include combining the elements of the matched structure with each other so that master data objects received from different client systems can be compared.

  The identified attributes can also be ranked during setup. Attribute ranking can be used during the matching process to determine whether two master data objects are identical. Thus, if a highly ranked attribute does not match between two objects, they are not the same or similar than if a low ranked attribute on the list does not match.

  The cMDM system can be implemented in at least three different scenarios, as described with reference to FIGS. 2-7. This scenario starts with a content consolidation scenario and moves to a master data harmonization scenario or by moving from a master data harmonization scenario to a central master data management scenario. Can be implemented separately or introduced in a novel manner. Different scenarios can also be used together. For example, central master data management can be used for several object types, while master data harmony is used for the rest. The mixing of the above scenarios will be described in more detail below.

<Content consolidation>
FIG. 2 is a block diagram illustrating a content concatenation scenario for a cMDM system. The central module 100 may include a load module 210, a staging module 220, a match module 230, and an ID mapping module 240. The consolidated content obtained by the processing performed in the central module 100 is a process such as creation of a comprehensive inventory (eg, supplier product inventory) or business analysis (eg, overall expenditure analysis). 250 can be used.

  In the load module 210, the master data object is received by the central module 100. Master data objects are uploaded to the central module 100 in the form they were held in their local application (client module 110). In the staging module 220, the user of the central module 100 can determine whether the master data object is loaded correctly. For example, the user can check the contents of the master data object loaded into the load module 210 to verify that the master data object is correct. The master data object may be cleanseed in the staging module 220 to standardize the content of the master data object. For example, if the standard format for shortening New York is "NY" and one of the contents of the input master data object has a shortened form such as "NY" The content of the master data object can be changed to “NY” by deleting the period between “N” and “Y.”. Data cleansing can also make data more accurate by eliminating mistakes and inconsistencies.

  The staging module 220 can also be used as an intermediate storage for received master data objects for a master data client. The intermediate storage may be used during the matching and mapping process described below with respect to match module 230 and mapping module 240, respectively. The intermediate storage can also be used during individual user interaction prior to uploading the master data object.

  Also, the matching process can be completed in the staging module 220. The master data object is transferred to the match module 230. If the match module 230 does not automatically match the master data object based on the identified attributes, the master data object is staged to manually determine whether the master data object matches. Can be returned to the module.

  In the match module 230, a matching process can be performed on the uploaded master data to identify the same or similar data objects. The same data object is master data that is semantically identical and is received from different client modules 110. The same data object can have two different object IDs. A duplicate data object is a semantically identical master data object in the same system, such as the client module 110. Possible duplicates are automatically recognized and reported. One or more replicated data objects can be removed from the client system.

  The matching process includes a step of recognizing similarity between master data objects. The matching process can include identifying an attribute of the data object and comparing the attribute. Compared attributes are valid entity-wide for the master data object type so that the same or similar data objects can be recognized even if the contents of the attributes vary from system to system. It can contain certain attributes. Thus, different data formats and structures can be maintained in different systems.

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

  The mapping module 240 receives the result of the matching process from the match module 230. In the mapping module 240, similar or identical objects can be mapped to each other. For example, the object identification (“ID”) of one object can be mapped to the object ID of a similar or identical object. The mapping information can be updated each time a change is made to the data object. The mapping can be performed automatically based on rules established during the setup 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 the master data object. For example, if “NY” in the master data object A is changed to “NY”, the master data object that has not been mapped to the master data object A can be considered the same as the master data object A. And the master data object mapped to master data object A will need to be changed. Accordingly, by creating mapping information that can be used by the client module 110, changes can be managed through updating the mapping information and mapping information. Similarly, a new version consisting of a group of data objects is defined, and the mapping information update and mapping information can be used to manage the version.

  The mapping information can be supplied to the processing module 250. The processing module 250 includes a data warehouse, such as a business information warehouse, for system-wide reporting, and complex analytics. Can be included. The processing performed by the processing module 250 can include enterprise-wide analysis and reporting or creation of a central catalog, such as overall spend analysis or mergers and acquisitions.

  FIG. 3 is a flow diagram illustrating a method for concatenating data. Data is received by the central module 100 from one or more client modules 110. (Step 310) If the received content data does not match the content of the central system in the central module 100, the received data can be cleansed.

  In order to determine whether identical or similar objects exist in the central system, a matching process is performed on the objects of data in the central system. (Step 320) The matching process may include comparing and identifying object attributes. The matching process can also include identifying a duplicate. If two or more objects are found to be duplicate objects, one or more duplicate objects can be avoided from being placed in the central module. The duplicate master data object is transferred to the staging module 220, where one of the duplicate master data objects is removed from the central module 100. The cMDM can also assist in the removal of one or more replication master data from the system from which the replication object was received.

  If the same or similar object is found, the central module can perform the mapping process. (Step 330) Object IDs of the same object can be mapped to each other, and object IDs of similar objects can be mapped to each other. Object mapping information can be supplied to the process. (Step 340) As described above, the step of supplying mapping information to processing comprises the step of supplying mapping information to a data warehouse, such as an enterprise information warehouse, for use in system-wide analysis and reporting. Can be included. Also, the mapping information can be supplied to the client module 110.

<Master Data Harmonization>
FIG. 4 is a block diagram illustrating a second scenario for cMDM. This second scenario involves a master data harmonization implementation. This scenario can be implemented by adding master data storage to the content consolidation implementation. This scenario can be used to enable consistent distribution and maintenance of global attributions of master data. The coordinated content resulting from the processing performed in the central module 100 can be distributed to the client module 110 and the processing module 240, which can be, for example, business partner administration. Used for applications such as central provision of sales articles, management and definition of non-variable parts.

  Master data objects can be created in the central module 100, the central creation module 410, or the client module 110. The master data object created by the client module 110 is received by the staging module 420. Some master data objects and mappings between master data objects can be stored in the central module 100. A portion of the stored master data object can include the global attributes of this master data object.

  A master data object created in the central creation module 410 can be created to include only the overall attributes of the master data object. The global attribute can include an identifying attribute. Which attributes are to be retained for each object type depends on the information requirements and the system landscape. A framework can be added to the cMDM to extend the object model without any modification of the software used to create the master data object in the local system. The framework handles new issues and new fields. For example, an object description (data model for an object) can be tailored to a central instance. For example, a field may exist in a model in one system that does not exist in a data model for other systems. The framework can also assist in updating the user interface for client systems that receive master data objects having different attribute fields. As will be described below, after distribution of the object, the distributed object may comprise an attribute value in the client module 110.

  A locally created master data object can be created using a local application of the client 110. Client module 110 can distribute global attributes of locally created master data objects to staging module 420. A cross system search can be done for the master data object before it is created in the client module 110. A master data object is created if no similar master data object exists. If a similar master data object exists, the central module 100 makes the similar master data object available to the user of the client module 110. For example, the central module 100 can make similar master data objects available to users of the client module 110 through a server. Thus, similar master data objects can be transferred to the server in the central module 100 and sent to the client system in the client module 110.

  The user can reserve similar master data objects and the mapping information can be updated to include the new local system. If a similar object is not found, after the master data object is created, the created master data object can be sent to another target system.

  A continuous matching process can be performed in the matching and mapping module 430. For example, the mapping can be performed in response to a request to create a master data object in the central creation module 410. A continuous matching process can be used to identify identical and similar data objects. This same and similar data objects can be mapped to each other as described above.

  Duplicate objects identified by the matching process are avoided from being created in the local system. For example, if the local system requests a master data object for a new business partner, the user of the central module 100 can check whether the business partner master data object already exists in the central module 100. If a business partner master data object exists in the central module, the master data object can be distributed to client systems that request a new master data object. If the user recognizes that an existing customer master data object already exists in the target system, creation of a duplicate master data object is avoided. The mapping information can be provided to the processing module 240 for processing such as business scale analysis.

  The overall attributes of the master data object, including mapping information, can be distributed to the various client modules 110 through the distribution module 440. Thus, all systems are supplied with the same overall attributes after delivery and business processing can be handled safely. Logically grouped objects can be distributed and modified together. For example, if the master data comprises master data for a product, objects belonging to that product, such as product structures and documents, are collected together in a packet and received in one context To the client module 110. A packet contains a group of individual objects that are combined through relationships that include dependencies, such as objects in a product structure. The packets can be collected according to the information requirements of the recipient's client module 110 and can be transferred in a sequence.

  For example, if the BOM changes or is delivered to the target system, the rules associated with the mapping for some specific systems will allow the specific system to recognize the product ID for the materials As can be done, it can be shown that the product master for the material must be sent to the particular system prior to BOM. Thus, sequencing of the objects to be delivered can be made to meet the requirements and semantics of the target system.

  The client module 110 can complete the master data information for the received master data object in a local environment. In addition, changes to master data can be mainly managed in the central module 100. This change is received, approved, and distributed to the client module 110.

  The master data created by the central module 100 can be created in response to a request from the client module 110. For example, a business user at a client module 110 using a client system can fill out a request form for a new product master and send the form to a user at the central system at the central module 100. The form can be checked to ensure that this form has been completed correctly. For example, the form can be checked semantically, or the unit of measurement can be checked to ensure that the correct unit is used. Central system users can view and accept requests. Users in the central system can then check for replication, complete the information given, and create and distribute new product masters.

  5A and 5B are flow diagrams illustrating a method for master data harmonization. Referring to FIGS. 1A, 1B, and 5A, master data reconciliation can include the creation of master data objects in the central module 100 as well as the client module 110. (Step 510)

  Master data objects can be created in three ways in master data harmonization. A new master data object can be created directly in the central module 100, or a new master data object can be created in the central module 100 in response to a request from the client module 110. The master data object can also be created locally at the client module 110 and transferred to the staging module 420. Master data created locally in the client module 110 can be uploaded to the central module 100.

  The created object can be stored in the central module 100. A master data object stored in the central module 100 can include the overall attributes of the master data object.

  A continuous matching process can be performed on the stored master data objects. (Step 520) The continuous matching process can be used to identify duplicate, identical and similar data objects. The found duplicate objects can be removed and the object IDs of the same and similar objects can be mapped.

  Master data object information, including overall attributes and mapping information of the master data object, can be delivered to the client module 110. (Step 530) Master data information for the master data object received at the client system may be completed at the client module 110. (Step 540)

  FIG. 5B illustrates a master data harmonization method in which master data is created locally as described above. Master data objects are created locally. (Step 550). This locally created master data object is staged. (Step 560).

<Central master data management>
FIG. 6 is a block diagram illustrating an embodiment of central master data management of a cMDM system. In the central master data management scenario, the master data is completely controlled in the central module. In this embodiment, all master data information is mainly present in the central module 100. This embodiment can be used for applications such as a central product data pool that supplies product data to multiple locations for manufacturing, assembly, sales and distribution.

  In the central creation module 610, master data objects can be created. This created master data object can include complete object information, including complete object definitions, object mapping information, and object dependencies. A master data object can be created in response to a request from the client module 110. A matching process is performed in response to this request, and the mapping information can be included in the data object information stored in the central module 100. If the same object exists in the central module 100, the requesting client module 110 has the same object and a new master data object is not created or mapped to an existing object. Can be notified. The mapping information can be updated.

  In the distribution module 620, master data information mainly held can be distributed as individual objects as defined in the client module 110. This object can be delivered in packets. Grouped objects can be modified and distributed together. If the master data includes a product model, grouping objects such as BOM (bills of material) and document products are collected together in a consistent packet and delivered together. The objects can be collected according to the information requirements of the recipient client module 110. For example, an object can be collected with reference to a special view of the product. A view can include product relevant attributes such as a purchasing date. Thus, groups of objects can be combined depending on usage or location. For example, the sales view can include the contents or attributes of objects used by or related to the sales department.

  As described above, scenarios can be used together. For example, central master data management can be used for business partner master data objects, where all business partner master data object information is held in the central module 100. The central module 100 can store only global attributes for the remaining data objects, such as product master data objects.

  FIG. 7 is 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 to FIGS. 1A, 1B and 6, at least one data object is created in the central module 100 (step 710). The central module 100 can comprise a central system for the cMDM system. The central module 100 can store complete data object information that can be distributed to the client module 110. Thus, the created data object can include complete object information, including complete object definitions, mapping information that maps data objects to other objects, and dependencies on other objects.

  A data object can be created in response to receiving a request from the client module 110 to create the data object. A matching process can be performed on the request to determine whether similar or identical data objects exist in the central system. If a similar or identical data object is found, this same data object will be delivered to the requesting system and this delivered object will be automatically mapped.

  Data objects from the central system can be distributed to one or more client modules 110. (Step 720) Distributing the data object includes distributing the data object to the client module 110. Data objects can be delivered in packets. This packet can be defined in the central module 100 based on requirement information received from the recipient client module 110.

  Also, the method of central master data management can include updating data objects stored in the central module 100 and making changes to the data objects. The updated data object can be distributed to the client module 110.

<Master data management system>
FIG. 8 is a block diagram illustrating a simplified configuration of the central module 100. The central module 100 can include an exchange infrastructure (“XI”) 810, a content integrator (“CI”) 820, and a master data server (“MDS”) 830. The XI 810 can be used for communication between the client module 110 and the central module 100.

  Master data to be delivered is received at XI 810. Distribution can be implemented in three different ways, including reservation-based distribution, historic distribution, and content-based distribution. A routing model (not shown) stores information about which systems are interested in the master data. Master data is then transmitted from XI 810 to the associated system. Queuing can be used to ensure consistent messaging across XI 810. Messages can be transmitted between systems in XML (Extensible Markup Language) format.

  CI 820 can associate master data from different systems by defining identifying attributes for each object. This identification attribute is provided to the CI 820 from different systems in the client module 110 and is scanned for analogness according to predetermined rules. The CI 820 saves the object ID for the object in the system landscape, regardless of which system it belongs to or under what data model. The master data object stored in the client module 110 holds the identity defined in each client system that stores the master data object. CI 820 understands that each instantiation is associated with some other object in the system (using a mapping function). Accordingly, the CI 820 performs the resulting ID preparation and matching process.

  In one example, the mapping can be done using an industry specific standard. Different industries, such as chemicals, consumer products (“CP”) / retail, etc., define standards for how objects should be described for their requirements. In some industries, for example, in CP it is sufficient to describe the product name, description and class (eg 'SWEETS'), but in chemicals only the class is sufficient. Thus, attributes and their values are used to fully describe chemicals. Thus, an attribute can be like a language for industry. Therefore, mapping of MDM standard xml format to industry specific standards is supported. Industry specific standards include, for example, CIDEX, Pidx, RosettaNet, Pricat.

  CI 820 uses a mapping for double check processing to create an object. CI 820 checks for requests for the same object. If it finds that there is no match, the central module creates a new object. The CI 820 then performs a check on the new object. If it finds no match, the central module stores a new master data object. Thus, even if the initial check is incomplete based on the description provided by the client module 110, a match will be found when the object is fully created.

  A merge strategy can be used to combine two or more objects that have been found to be similar or identical. For example, if a master data object for a pump is created in a purchasing system, a sales system, and a production system, one object will have three master data It can be created in the central module 100 by merging objects. For example, a new object can be created, where different systems have authorization for different parts of the object. Thus, the purchasing system can maintain purchasing information for the master data object. Although the purchasing system can view sales and manufacturing information, the purchasing system can only be authorized to maintain the purchasing information.

  The MDS 830 can comprise a central data store for storing data objects. The MDS 830 can perform object creation and modification processing. The MDS 830 may also provide services for change management and status management, such as unified versioning. Also, the grouping of objects that have been changed into packets for distribution can be implemented in MDS 830.

  The invention can be implemented in digital electronic circuitry, or in computer hardware, firmware, software, or a combination thereof. The invention is clearly embodied in an information carrier for controlling or executing a data processor, for example a programmable processor, a computer, or a multiple computer, for example in a machine-readable storage device or in a propagated signal. Can be implemented as a computer program. A computer program can be written in any form of programming language, including a compiled or interpreted language, which is a stand-alone program, or module, component, It can be deployed in any form including subroutines or other units suitable for use in a computing environment. A computer program can be deployed to run on one or more computers at one site, can be distributed across multiple sites, and can be interconnected by a communications network. it can.

  The method steps of the present invention may be implemented by one or more programmable processors executing a computer program for performing the functions of the present invention by operating on input data and generating output. Also, the apparatus of the present invention can be implemented as a special purpose logic circuit, for example, an FPGA (Field Programmable Gate Array) or an ASIC (Application-Specific Integrated Circuit), and thereby method steps can be implemented. .

  Processors suitable for executing computer programs include, by way of example, both general purpose or special purpose microprocessors and any one or more processors of any type of digital computer. Generally, a processor receives instructions and data from a ROM (Read-Only Memory), a RAM (Random Access Memory), or both. The essential elements of a computer are a processor for executing instructions and one or more memories for storing instructions and data. Also, in general, a computer includes one or more mass storage devices for storing data, such as a magnetic, magneto-optical disk, or optical disk, or is operatively coupled to transmit and receive data. Or both. Information carriers suitable for embodying computer program instructions and data include, by way of example, semiconductor memory, eg, all types of non-volatile memory including EPROM, EEPROM, and flash memory devices, magnetic disks such as internal hard disks and removable disks , Magneto-optical disks, and CD-ROM and DVD-ROM disks. The processor and the memory can be incorporated into or supplemented by a special purpose logic circuit.

  To provide user interaction, the present invention provides a display device such as a CRT (cathode ray tube) or LCD (Liquid Crystal Display) monitor for displaying information to the user, a keyboard and a user. Can be implemented on a computer with a pointing device such as a mouse or trackball that can provide input to the computer. Similarly, other types of devices can be used to provide user interaction. For example, the feedback provided to the user can be any form of perceptual feedback such as visual feedback, audio feedback, tactile feedback, and the input form from the user is acoustic, audio Or any form including tactile input.

  The present invention is a graphical with a back-end component such as a data server, or a middleware component such as an application server, or a front-end component such as a user that can interact with an embodiment of the present invention. It can be implemented in a client computer having a user interface or web browser, or a computing system with any combination of such backend, middleware, or frontend components. The components of the system can be interconnected by a digital data communication medium, such as a communication network or any form. Examples of communication networks include a local area network (“LAN”), a wide area network (“WAN”), and the Internet.

The computing system can include clients and servers. A client and server are generally remote from each other and typically interact through a communication network. The relationship between the client and the server is generated based on a computer program that operates on each computer and has a client-server relationship with each other.
The invention has been described in terms of specific embodiments. Other embodiments are within the scope of the claims. For example, the steps of the present invention can be performed in a different order and still achieve the desired result.

It is a block diagram illustrating a cooperation master data management system. It is a block diagram illustrating a cooperation master data management system. It is a block diagram illustrating the content connection example of a cooperation master data management system. FIG. 3 is a flow diagram illustrating a method for consolidating data. It is a block diagram illustrating master data harmony implementation of a cooperation master data management system. FIG. 3 is a flow diagram illustrating a method for master data harmonization. FIG. 3 is a flow diagram illustrating a method for master data harmonization. 1 is a block diagram illustrating a central master data management embodiment of a joint master data management system. FIG. FIG. 3 is a flow diagram illustrating a method for central master data management. It is a block diagram illustrating a cooperation master data management module.

Explanation of symbols

100 Central module 110 Client module

Claims (34)

A method of sharing data,
Receiving data in the central system from one or more client systems;
Performing a matching process on objects of data in the central system to determine whether similar objects exist in the central system;
Mapping similar object identifications to each other if similar objects exist in the central system;
Providing the object mapping information to a process. Performing a matching process on objects of data in the central system to determine whether the same object exists in the central system;
The method of claim 1, further comprising mapping object identifications of the same object to each other if the same object exists in the central system.   The method of claim 1, further comprising cleansing the data to standardize the content of the data.   The method of claim 1, wherein providing the object mapping information to a process comprises providing the object mapping information to a data warehouse for system-wide reporting.   The method of claim 1, wherein an analysis is performed based on the mapping information. Determining whether the same object is a duplicate object from the same client system;
The method of claim 1, further comprising: removing the duplicate object from at least one of a client system and a central system from which a duplicate object is received.   2. The step of performing a matching process includes identifying the attributes of the object in the central system and comparing the attributes of the object to determine whether the objects are identical. the method of.   Storing object information in the central system; and delivering the object to the one or more client systems with object mapping information, the object information including object mapping information for each object; The method of claim 1, wherein the object information is based on data created or received in the central system.   9. The method of claim 8, further comprising the step of continuously performing the matching process on object information stored in the central system.   9. The method of claim 8, further comprising the step of continuously updating the object information stored in the central system based on data received from the one or more client systems.   The method of claim 10, wherein updating the object information continuously includes updating mapping information for each object.   The method of claim 8, wherein an object is created in the central system and comprises global attributes for the object. Delivering the object comprises delivering the global attribute for each object;
The method is
9. The method of claim 8, further comprising completing object information for at least one object at the one or more client systems.   The method of claim 1, further comprising mapping the data object according to an industry specific standard.   The method of claim 1, further comprising distributing a framework to configure client system software for receiving data objects from the central system. A system for sharing data,
One or more client systems storing master data for use in processing performed in the client system;
Master data is received in the central system from the one or more client systems, and matching processing is performed on the master data object in the central system to determine whether the same or similar object exists in the central system. If the same object exists in the central module, the object identification of the same object is mapped to each other, and if the similar object exists in the central module, the object identification of the similar object is mapped to each other, and the object A system comprising the central module configured to provide mapping information to the process.   The system of claim 16, wherein the central module is further configured to remove duplicate objects from the one or more client systems.   The system of claim 16, wherein the central module is further configured to provide the object mapping information to a data warehouse for use in the processing.   The system of claim 16, further comprising a data warehouse configured to receive the object mapping information and use it in the processing. A computer program product clearly stored on a computer readable recording medium, wherein the programmable processor
Receive data in the central system from one or more client systems,
Causing the central system to perform a matching process on data objects to determine whether a similar object exists in the central system;
If similar objects exist in the central system, map object identifications of similar objects to each other,
A computer program product comprising instructions that can cause processing to provide the object mapping information. Programmable processor
Causing the central system to perform matching processing on data objects to determine whether the same object exists in the central system;
21. The computer program product of claim 20, further comprising instructions that, if the same object exists in the central module, can map object identifications of the same object to each other. Programmable processor
21. The computer program product of claim 20, further comprising instructions that can cleanse the data to standardize the content of the data.   The instructions that can cause a programmable processor to provide the object mapping information for processing include instructions that can cause the programmable processor to supply the object mapping information to a data warehouse for system-wide reporting. The computer program product described.   21. The computer program product of claim 20, further comprising instructions that allow a programmable processor to perform an analysis based on the mapping information. Programmable processor
Determine if the same object is a duplicate object from the same client system,
21. The computer program product of claim 20, further comprising instructions capable of causing a duplicate object to be removed from at least one of the client system or the central system from which the duplicate object was received.   Instructions that can cause the programmable processor to perform a matching process cause the programmable processor to identify the attributes of the object in the central system and compare the attributes of the object to determine whether the objects are identical 21. The computer program product of claim 20, comprising instructions that can be executed. Programmable processor
Storing object information in the central system;
Further comprising instructions for causing the object to be delivered to the one or more client systems with object mapping information;
21. The computer of claim 20, wherein the object information includes object mapping information for each object and an overall attribute of the object, wherein the object information is based on data created or received in the central system. Program product. Programmable processor
28. The computer program product according to claim 27, further comprising instructions capable of causing the matching process relating to object information stored in the central system to be performed continuously. Programmable processor
28. The computer program product of claim 27, further comprising instructions capable of continuously updating the object information stored in the central system based on data received from the one or more client systems.   30. The computer program product of claim 29, wherein the instructions that can cause a programmable processor to continuously implement the object information include instructions that can cause the programmable processor to update mapping information for each object.   28. The computer program product of claim 27, further comprising instructions that cause a programmable processor to create an object in the central system and provide global attributes for the object. The instructions that can cause a programmable processor to distribute the object include instructions that can cause a programmable processor to distribute the overall attribute for each object;
Furthermore, the method
28. The computer program product of claim 27, wherein object information for at least one object is completed in one of the one or more client systems. Programmable processor
28. The computer program product of claim 27, further comprising instructions capable of mapping the data object according to an industry specific standard. Programmable processor
28. The computer program product of claim 27, wherein the computer program product comprises client system software for distributing network frames and receiving data objects from the central system.

Images