RU2748741C2 - Asset master data management system - Google Patents

Abstract

FIELD: data management.SUBSTANCE: invention relates to a system and method for managing asset master data. The system contains the core of the system that supports the creation, modification and storage in memory of a model of master data on assets: a model of master data on assets, which necessarily includes: at least three hierarchically organized views corresponding to some representations of the available landscape of assets, each of which is matched by at least one unique generic classifier of the asset master data included in the model; generic classifiers, each of which is a hierarchical system of classes built on the basis of the principles of inheritance and encapsulation, while the class of each object of the master data on assets in the classifier completely defines all the attributes of the corresponding object of this class and all types of its connections with objects of other views; sets of links of each object of any of the views with objects of other views for transition between different representations of the same asset; for each hierarchically organized view: a set of non-hierarchical (network) relationships between assets belonging to the same view, displaying view-specific relationships between assets; a set of structural models of asset master data describing the internal relationships and component composition of specific types of assets; a set of functional models of the master data on assets, built on the basis of algorithms and based on mathematical models, using the attribute values of individual instances of the master data on assets and the attributes of related instances of the master data on assets in order to check the completeness of the asset data entry or identify the type of asset depending on the values of the attributes; at least three interface modules that are associated with the system core, each of which provides interaction of the system core with one application or with one functional module of the ERP system, each interface module is designed to be unloaded upon requests from external applications and/or ERP modules, the requested piece of master data about assets related to the specific view of the master data with which the requesting module or application works; at least one algorithmic module associated with the core of the system and configured to process the entire asset master data model and/or individual views of the master data on assets model, providing operations from the following list: checking the correctness and completeness of the system of inter-view links between objects in the model, and this check is performed according to an algorithm, in the process of which: to check the completeness and correctness of inter-view links of each node, all rings of one grid of inter-view links existing in external memory are traversed node, when executed, to avoid multiple traversal of the same rings of links, markup of links in external memory is performed, at the same time, in the process of performing the traversal, the presence of not expected links or broken links is revealed by using a set of inter-view links from the master data model, and after the completion of the traversal, in the case of returning to the original node, it is determined that the chain of links of this node is correct, if there are unmarked links in the set of inter-view links, the presence of missing links is determined; checking the correctness of classifiers; search for objects by classifiers; formation of new views of the master data based on the data of other views available in the system or on the basis of external data; formation of reports on the data model and on the adjustments made in it; a module of the dialog interface, connected with the core of the system and providing the creation and correction of the master data by the administrator of the master data in the dialog mode.EFFECT: increasing the efficiency of checking the correctness and completeness of the system of inter-view connections between objects in the model.16 cl, 20 dwg

Description

[0001] The claimed technical solution relates to the field of computer technologies used to create and maintain a single consistent presentation of the master data on assets, which eliminates duplication of master data on assets in various modules of the corporate system and individual applications. Eliminating duplication eliminates the inevitable inconsistencies that arise when multiple different views of asset master data are used concurrently. In addition to improving data quality, this can reduce the cost of keeping master asset data up to date.

[0002] In this case, master data refers to consistent data describing the main entities involved in the business processes of the enterprise. Master data is available and used by several applications across the enterprise. The main salient features of master data are [1.2]:

• high importance for the company;

• less volatility compared to transactional data;

• availability of standard capabilities, creation, reading, correction, destruction and search;

• reusability;

• use as reference objects in transactional data.

LEVEL OF TECHNOLOGY

[0003] In existing corporate management systems in several modules or subsystems, as a rule, master data on production assets (assets) are maintained independently, reflecting different characteristics of the same objects. Even when different applications are modules of a single ERP system, the same approach is still used [3,4]. An exemplary structure of asset master data in existing large company management systems is shown in FIG. fifteen].

[0004] The understanding of the term "asset" itself is not unambiguous. The term is interpreted differently by different companies. Almost always, the concept of assets includes tangible assets (buildings, structures, equipment, land, facilities under construction, etc.) and their components. Somewhat less often, the concept of assets includes intangible assets - software systems, databases, patents, trademarks, etc. Even less often in Russian practice [6] and more often in Western practice, financial assets are also included in a single concept of assets - stocks, bonds, loans, shares in joint projects, promissory notes, etc.

[0005] The total number of assets in the purchased companies, such as OJSC Russian Railways, NK Rosneft, can reach several tens of millions of units. The bulk of such a large park (over 90%) is usually tangible assets.

[0006] Master data management systems (MDM systems) are used to keep the master data up-to-date and to organize the work with the master data of various applications. The purpose of using MDM systems is to form and support a consistent, functionally complete and up-to-date presentation of basic data, reflecting all the nuances of the structure and activities of the enterprise. Having and maintaining such a single meaningful view of the master data is critical to achieving the business goals of the enterprise. MDM systems are a toolkit to support enterprise-wide master data management processes based on accepted guidelines, policies and standards [7-9]. From the point of view of the belonging of software products to application or platform software, MDM systems are part of the platform and are an integral part of the complex of enterprise information management systems (Enterprise Information Management) [10].

[0007] The world's leading analytical company Gartner traditionally issued two independent analytical reviews on different classes of MDM systems annually - on MDM systems with data on subjects, which included master data management systems for assets, and MDM systems with data on people, organizations and teams. In 2017, the company changed this tradition and released a single review [11]. According to this overview, each of the business applications (for example, within ERP, CRM or PLM) or their complexes (suites) can store their data and offer their own data management capabilities. The MDM system acts as an intermediate hub that mediates, manages, exchanges and regulates master data common to all applications. For many years, organizations have tried to achieve a “single view” of master data using ERP or other functional systems that were not designed to support MDM, so these attempts failed or they were too expensive to maintain. This created the preconditions for the emergence of MDM systems. Market penetration of MDM systems is now less than 10%, and there is a steady, albeit slow, growth. The market for MDM systems is growing faster than the software market as a whole [11].

[0008] Historically, MDM systems began to evolve as single-domain systems designed to work with master data of one category (subject area). The most common data domains are:

• Customers / consumers / patients / residents

• Suppliers / manufacturers

• Distribution channels / partners

• Products / headings

• Purchased parts

• Assets

• Locations

• General ledger accounts

[0009] Along with the currently dominant single-domain MDM systems designed to work with data from one subject area, segments of multi-domain and multi-vector MDM systems are still not widely spread, but segments of multi-domain and multi-vector MDM systems are rapidly expanding. Multi-domain systems are designed to work with data from several subject areas. They must be able to support all of the master data domains that the organization needs.

[0010] According to a survey of several thousand customers conducted by analysts at Gartner, during the five calendar quarters ending with the fourth quarter of 2015, the percentage of those who had any requirement for multi-domain when purchasing an MDM system increased by more than four times, from 3.0% to 13.0% [11]. In this group, the percentage of those who formally tested these features rose from 0.5% to 3.1% (a sixfold increase) in the third quarter of 2015, and then declined to 0.8% in the next quarter. At the same time, the percentage of those who demanded these features, but did not test them, more than quadrupled by the end of 2015, from 3.0% to 12.0%. During 2016, the percentage of those who expressed some level of requirements for working in multiple master data domains peaked at 14.6% in the second quarter and declined to 13.5% by the end of the third quarter. The percentage of those who formally tested these features peaked at 1.8% in the third quarter. At the same time, the percentage of those who demanded, but did not check them, reached 13.7% in the second quarter and decreased by the end of the third quarter to 11.0% [11].

[0011] The concept of multi-vector MDM systems expands the concept of multi-domain MDM systems. These systems provide an integrated set of tools for ensuring consistency, accuracy, strategic management, semantic consistency, and accounting for the official shared assets of enterprise master data. The functionality of a multi-vector MDM system includes comprehensive tools for data modeling, data quality support, data management, data organization, data service, and data integration into workflow and transactional use cases. Multi-vector MDM systems also offer higher levels of scalability, availability, manageability, and security. In addition to working with different subject areas, multi-vector MDM systems should be able to work in different industries and different government agencies. authorities, for different scenarios of use (for the design of data structures, as an operational or analytical MDM system), for different organizational structures (centralized, federated, localized) and for different scenarios for the implementation of an MDM system (register, consolidation, coexistence and centralized) [11].

[0012] Among the set of functional capabilities inherent in modern MDM systems according to [11], from the point of view of the proposed invention, it is necessary to highlight and consider in more detail the following two - management of hierarchies and internal integration of a set of products.

[0013] Hierarchy management is the ability of an MDM system to model and store multiple hierarchies both within individual master data domains and across the covered domains in order to comprehensively classify all master data entities for various business requirements as well as broad functions such as search and reporting. This capability should include support for multiple related or autonomous hierarchies belonging to the same domain or a combination of master data from multiple data domains. Also, for hierarchical data, the possibility of bitemporal modeling should be supported, when the same data is displayed in two hierarchies: "as it should be according to documents" and "as is in fact". For example, it can be used to form an architectural representation hierarchy and a real estate commercial use hierarchy as part of the real estate master data. An MDM system must provide support for balanced, unbalanced, and recursive hierarchies, visualization capability to facilitate the maintenance and presentation of hierarchical data, and the ability to version hierarchies so that audit trail can be used and data can be recovered as hierarchies are created and maintained.

[0014] Internal integration of a set of products is the ability of an MDM system to provide, as a default, integration between master data presented inside domains, regardless of whether they are stored together or separately in terms of, for example, data storage objects, as well as the ability to visualize and generate this integration. This can be achieved with a single product or multiple products as part of a suite or portfolio of products, or through the use of customer-generated or pre-packaged data models (or both modeling styles at the same time). However, if this capability is to be realized, it must also support both different MDM deployment styles for each individual master data domain over time and across multiple data domains, as well as pre-envisioned opportunities to migrate domain deployment styles between deployment styles.

[0015] Another analyst company besides Gartner that regularly publishes reviews on MDM systems is Forester. In the first quarter of 2016, the company released a survey [12], in which it identified four classes of MDM systems and analyzed the products of twelve companies. Were highlighted:

• MDM systems that provide data integration and solve standard problems;

• multi-domain MDM systems and MDM systems that support multiple views of master data;

• contextual MDM systems that support the semantic representation of business data;

• analytical MDM-systems, integrated inside analytical platforms.

[0016] Of the four classes of MDM systems presented in [12], from the point of view of the present invention, the group of multi-domain MDM systems and MDM systems that support multiple representations of master data is of greatest interest. SAS, SAP and IBM are the leaders of this group. These companies do not currently have MDM systems capable of providing the master asset management capabilities that are implemented in this invention.

[0017] The main reasons why existing systems for managing asset master data do not provide full support for the subject area, unlike MDM systems for other domains [5]:

• Different asset management application areas have different asset allocation principles. For example, for accounting purposes, several adjacent pieces of equipment with the same depreciation rules can be combined into one fixed asset. For the purposes of repair and maintenance, objects are allocated with a different procedure for repair and maintenance. For the purposes of property accounting, objects are allocated that can be independently sold or leased, for example, one fiber in a bundle of optical fibers or fiber-optic cable.

• Different applications working with the same asset park use different hierarchies of nesting of objects, with different objects of grouping levels and objects of the lower levels of such detailing hierarchies.

• When operating complex management systems, users very often need to see adjacent views of the same asset. For example, from the technological view, it is necessary to see the objects of maintenance and repair. From the objects of maintenance and repair, it is necessary to see the fixed assets to which the costs will be written off. From fixed assets it is necessary to see the corresponding objects of property, etc. Almost always, users need to see objects from several different views. The lack of one-to-one correspondence between the objects of the lower level of different applications leads to the appearance of many-to-many relationships between objects of different representations describing the same asset. As it was shown earlier, many objects of technical accounting can correspond to one fixed asset. But the opposite is also true: one object of technical accounting, for example, an asphalt road, can correspond to many fixed assets if its separate sections, which are not units of technical accounting, were built (bought) at different prices or at different times.

SUMMARY OF THE INVENTION

[0018] The proposed system architecture consists of a system core, a set of interface modules and a set of high-level algorithmic modules.

[0019] The core of the system supports the creation / modification and storage in memory of a master data model about assets, built as a set of hierarchically organized views (subject areas) of assets.

[0020] The interface modules provide the unloading from the model and loading into the data model of a particular view of the master data about assets at the request of some application working with this view of the master data.

[0021] The dialog interface module provides dialog support when creating and updating master data by a master data administrator.

[0022] High-level algorithmic modules provide checking the correctness of the completeness of the system of connections between objects in the model, checking the correctness of classifiers, searching for objects by classifiers, generating new views of master data based on data from other angles in the system or based on external data, generating reporting on the model data and adjustments made in it, as well as other similar operations.

[0023] Various subject areas are represented by their specific object hierarchies. Each subject area has its own system of object classes. Object classes are based on the principles of polymorphism and inheritance and define the properties (set of attributes) of an object.

[0024] Objects present in different hierarchies are united by link grids to move from one object representation to another.

[0025] Within the hierarchies between objects, there are also non-hierarchical relationships reflecting the specific relationships between objects inherent in this subject area. For example, they can reflect the functional interaction of assets in the production process, the logistic exchange of goods between assets, neighboring territorial location, etc. These relationships can have their own classification system and sets of attributes.

[0026] Structural and functional asset models are used to identify assets represented in the system. Each structural asset model describes the internal relationships and component composition of specific asset classes. Functional models allow you to check the completeness of the asset data entry or identify the asset type depending on the attribute values.

[0027] The entire set of relationships between assets within each view and relationships between objects related to one asset, in different views, forms a complex graph of a specific structure. Incorrect or incomplete connections in such a column will disrupt the operation of the control system. The proposed algorithms provide verification of the correctness and completeness of the entire set of inter-view connections in such a graph.

[0028] In order for a data structure to be correct, all links must be correct in it. That is, when navigating through relationships between different views of the same asset, if one-to-many or many-to-many relationships are not used, the user should see different views of the same object. If one-to-many or many-to-many relationships are used, the user should be able to return to the original asset.

[0029] The linkage structure will be complete if there are all necessary links to navigate between different representations of the same asset.

[0030] Checking the correctness of all links has a very simple meaning: from each object to go through the ring of links in one direction, and then in the opposite direction. If for all objects, when passing in both directions, we return to the original object, then all connections in the selected ring are correct. To check the correctness of all links of one object, it is necessary to bypass all the existing link rings in this way.

[0031] Checking the completeness of links is based on the same technique of traversing the rings of links. For each class of objects in each of the representations it is predetermined what connections with objects of other representations should exist for objects of this class. If, when trying to traverse all rings, one of the links is absent, then the existing set of links is incomplete.

BRIEF DESCRIPTION OF DRAWINGS

[0032] FIG. 1 illustrates an example of the structure of asset master data in existing management systems of large companies.

[0033] FIG. 2 illustrates the architecture of a master asset data management system.

[0034] FIG. 3 illustrates an example of a hierarchical view of objects.

[0035] FIG. 4 illustrates an example of a lattice of links connecting the same asset from different angles.

[0036] FIG. 5 illustrates an example of non-hierarchical relationships between objects of the same view.

[0037] FIG. 6 illustrates an algorithm for checking the completeness and correctness of inter-view links in the master asset data model.

[0038] FIG. 6.1 illustrates the continuation of the algorithm for checking the completeness and correctness of inter-view links in the master asset data model.

[0039] FIG. 6.2 illustrates the continuation of the algorithm for checking the completeness and correctness of inter-view links in the master asset data model.

[0040] FIG. 7 illustrates the use of a stack to traverse objects of the same view.

[0041] FIG. 8 illustrates the use of a stack to traverse all rings of a single lattice.

[0042] FIG. 9 illustrates an example of the lattice previously shown in FIG. 3, in which instead of the semantic names of the hierarchies, their internal numbers are used, assigned to them at the time of their appearance in the data model.

[0043] FIG. 10 illustrates an example of renumbering lattice objects. The object having in the lattice in FIG. 9, the internal hierarchy number 15, received the number 1, and the numbers of all other hierarchies were shifted.

[0044] FIG. 11 contains examples of two well-formed bond rings in a lattice.

[0045] FIG. 12 contains examples of two incorrectly constructed bond rings in a lattice.

[0046] FIG. 13 illustrates an algorithm for checking the correctness of inter-view links in the master asset data model.

[0047] FIG. 13.1 illustrates the continuation of the algorithm for checking the correctness of inter-view links in the master asset data model.

[0048] FIG. 14 illustrates an algorithm for checking the completeness of inter-view links in the master asset data model.

[0049] FIG. 14.1 illustrates the continuation of the algorithm for checking the completeness of inter-view links in the master asset data model.

[0050] FIG. 14.2 illustrates the continuation of the algorithm for checking the completeness of inter-view links in the master asset data model.

[0051] FIG. 15 illustrates a general diagram of a device that implements the claimed method.

CARRYING OUT THE INVENTION

[0052] The system architecture, including all of these components, is shown in FIG. 2.and contains:

• the core of the system, which supports the creation, modification and storage in the memory of the model of master data about assets;

• at least three interface modules, each of which provides interaction of the system core with one application or with one functional module of the ERP system;

• at least one algorithmic module that implements some algorithm for processing the entire master asset data model and / or individual views of the asset master data model;

• module of the dialog interface, providing the creation and correction of master data by the administrator in the dialog mode.

[0053] the Asset master data model includes at least three views corresponding to some view of the existing asset pool. Examples of such angles include:

• fixed assets (objects of accounting and tax accounting);

• real estate objects;

• objects of equipment maintenance and repair;

• objects of property (legal aspect);

• objects of various monitoring subsystems (fire safety, video surveillance, etc.);

• objects of subsystems for operational control of operating modes of equipment for continuous production, transport and communications, utilities;

• objects of various MES and technological production control systems,

• objects of geographic information systems (visualized on maps);

• objects of generation, transmission and consumption of electricity in the subsystems of management of production and consumption of electricity;

• facilities for the production, transportation and supply of oil, oil products and gas in the subsystems for managing the production, transportation and marketing of hydrocarbons;

• processing centers and transport mechanisms in the systems of technological preparation of production (CAM-systems);

• warehouses, distribution centers and retail outlets in retail chain management systems;

and other views of assets from an application-specific perspective.

[0054] Each view is organized in a unique hierarchy that reflects the ownership of the master asset data (the entry of objects into higher-level objects). For example, the view of equipment maintenance and repair (MRO) objects is organized in the form of a hierarchy, the top level of which is the "MRO Objects" node. At the next level, there are as many nodes as there are in the company of factories. The next lower level is represented by nodes, each of which corresponds to a separate production and technological complex located at a specific plant. An even lower level corresponds to the places of equipment installation within the framework of specific production and technological complexes. The lowest level of the hierarchy corresponds to pieces of equipment that are mounted at specific locations. The described example of a hierarchy of maintenance and repair objects is shown in FIG. 3. The given example of a hierarchically constructed view is extremely simplified. The complexity of the organizational structure of large companies and the technical complexity of modern equipment are such that real hierarchical structures for representing the master data on the assets of a particular company can contain any finite number of hierarchy levels.

[0055] For each master data view, there is one or more generic asset classifiers that provide a classification of all objects in a given view. A generic classifier is a hierarchical system of classes based on the principles of inheritance and encapsulation. The initial objects of class hierarchies are the main classes of the generic model, which at the next levels of the hierarchy are detailed into groups of asset types according to their functionality, design features, methods of use, etc. For example: computer → personal computer → laptop → gaming laptop → gaming laptop with high performance → gaming laptop, model MSI GT72S 6QE Dominator Pro G → gaming laptop, model MSI GT72S 6QE Dominator Pro G, version us.

[0056] The number of levels of the class hierarchy in the classifier is not limited. Each major and minor asset class, an asset class, defines a set of attributes (characteristics) of assets of that class. Attributes have names and meanings. Attribute values can have a wide range of types: integer, real number, logical sign, text, reference value, array, set, dependency, graph, table, diagram, drawing, image, document, etc. Examples of attributes for the asset class "laptop "Will be: processor type, processor frequency, screen size, RAM size, hard drive capacity, etc.

[0057] The number of attributes for each class is not limited. If there is a large number of attributes belonging to any of the classes, for convenience, they can be structured by functional groups, while the same attribute can be included in different functional groups. Using the principles of inheritance and encapsulation when building classifiers provides the following rules for transferring attributes between classes in the hierarchy:

• Attributes of a higher hierarchy class are inherited in all subordinate classes of the hierarchy.

• Attributes of lower classes of a hierarchy are not visible in higher classes.

[0058] Attributes with the same name may be used to describe the same asset from different angles. However, the values of these attributes may not be the same.

[0059] In the definitions of attributes having numerical values, and their aggregates (set, array), an additional reference to the unit of measure from the classifier of units of measure is used. For functions, tables, dependencies, graphs, two or more such links can be used. Attribute definitions whose values are a graph, diagram, drawing, image, or document use an additional reference to the file type from the file type classifier.

[0060] Each class has three required attributes:

• Class name

• Class code (internal class name);

• A set of codes of classes of other views, which represent the same asset, and with which the asset of this class must be linked by inter-view links.

[0061] When operating complex management systems, users very often need to see adjacent views of the same asset. For example, from the technological view, it is necessary to see the objects of maintenance and repair. From the objects of maintenance and repair, it is necessary to see the fixed assets to which the costs will be written off. From fixed assets it is necessary to see the corresponding objects of property, etc. Therefore, in the asset master data model, each asset from any of the views has a set of links with objects from other views to navigate between different representations of the same assets.

[0062] The lack of one-to-one correspondence between low-level objects of different applications results in one-to-many, many-to-one, and many-to-many relationships between objects of different representations describing the same asset. For example, a plurality of technical accounting objects can correspond to one fixed asset. But the opposite is also true: one object of technical accounting, in particular, an asphalt road, can correspond to many fixed assets if its separate sections, which are not units of technical accounting, were built (bought) at different prices or at different times. An example of a set of links uniting the presentation of the same object from different angles is shown in FIG. 4. In this example, all inter-view links are one-to-one and bidirectional. In what follows, we will use the term lattice for such a set of inter-view connections.

[0063] The lattices are not necessarily complete (ie, they do not necessarily have all the relationships of each object to each). The presence of links between different objects depends on the semantics - it is necessary to establish relationships between the objects of these angles at a given level or not.

[0064] At one level of the hierarchy of any of the views, there are many objects, each of which is associated with its own lattice of adjacent objects. Grilles of the same level can partially overlap with each other. This occurs due to the fact that in separate views, one object can correspond to several objects of another view, located at the same level of the hierarchy (for example, one fixed asset can combine several pieces of equipment), and, then, the lattices of adjacent objects of the same level can be partially connected in separate angles.

[0065] If we consider the 3D model of the master data graph, then the lattices at different levels will not necessarily be absolutely parallel. In separate views, one object can correspond to several objects of another view, located at different levels of the hierarchy, and, then, the lattices of adjacent levels can be connected in separate views.

[0066] In each view, the master asset data model may contain a set of non-hierarchical (network) relationships between assets belonging to that view. These relationships represent view-specific relationships between assets, such as participation in production chains or transport relationships. An example of non-hierarchical relationships between assets belonging to the same view is shown in FIG. 5. Such relationships, for example, may reflect:

• availability of transport routes between production and technological complexes that extract raw materials, process them and distribute finished products;

• the presence of intersections between transport arteries (motorways, metro lines, etc.);

• linking of production equipment to technological lines within one workshop;

etc.

[0067] A set of non-hierarchical relationships between assets belonging to the same view is characterized by the fact that for such relationships there may be a classifier related to this view, which is a hierarchical class system based on the principles of polymorphism and encapsulation. Just like in asset classifiers, classes in a relationship classifier have attributes that have names and values. Attribute values can have a wide range of types: integer, real number, logical sign, text, reference value, array, set, dependency, graph, table, diagram, drawing, image, document, etc. Examples of attributes for the class of links "transport route "will be: the maximum volume of cargo transported by one vehicle, the throughput of the transport route, the cost of transporting a consignment of goods by one vehicle, the time of transportation of one consignment, etc. The number of attributes for each class of links is not limited.

[0068] Using the principles of inheritance and encapsulation in building link classifiers provides the following rules for transferring attributes between hierarchy classes:

• Attributes of a higher hierarchy class are inherited in all subordinate classes of the hierarchy.

• Attributes of lower classes of a hierarchy are not visible in higher classes.

[0069] In the definitions of the attributes of non-hierarchical links having numerical values, and their aggregates (set, array), an additional reference to the unit of measure from the classifier of units of measure is used. For functions, tables, dependencies, graphs, two or more such links can be used. Attribute definitions whose values are a graph, diagram, drawing, image, or document use an additional reference to the file type from the file type classifier. Each relationship class has two required attributes:

• Class name

• Class code (internal class name);

[0070] In addition to having a classifier and attributes, non-hierarchical links have another important property: they can be parametric, i.e. they can exist between objects in a shaded state and only appear when the values of one or more of the object's attributes meet certain conditions.

[0071] In each view, the master data model may contain a set of structural asset models specific to that view. Each structural asset model describes the internal relationships and component composition of a particular asset class. For example, the structural model of an asset that belongs to the class "Boiler room" includes the required components: a building, a boiler installed in it, and a chimney. Structural models allow you to check the completeness of the asset data entry or identify the type of asset depending on its structure. Returning to the already considered example, if the newly entered by the user object has the class "Boiler room", but does not contain all three required components, the user is shown an error message. Not only the component composition can be checked, but also the presence of certain types of links between the components, as well as their topology, if the links are defined in the structural model. For example, when checking an asset of the class "Ring Road", the individual sections of this road must be so connected by ties to each other that a closed ring is formed. If the sections are open somewhere, then the asset does not correspond to the class "Ring road".

[0072] In each view, the master data model can contain a specific for this view a set of functional models of the master data about assets, using in the course of their execution the values of the attributes of individual assets and / or attributes of the links of this asset and the attributes of assets associated with the data. Functional models allow you to check the completeness of the asset data entry or identify the asset type depending on the attribute values. Functional models can be built both on the basis of relatively simple algorithms and on the basis of complex mathematical models. As an example of a simple algorithm, we will give an example of a functional model that checks the correctness of the input of an asset of the class "Kindergarten Building". If for such a building the number of storeys has a value of more than two, then either the data on the asset was entered incorrectly, or the asset is incorrectly classified. As an example of a complex functional model of an asset, we present a model that calculates the population of animals in the future by years in a certain natural area, depending on the number of animals living in this area at the moment. If simulations show that after a certain minimum number of individuals are shot, the animal population is likely to begin to decline, then this area cannot be assigned the asset class “Hunting Grounds”.

[0073] Each interface module within the system unloads, upon requests from an external application or ERP module, the requested piece of master asset data related to a particular view of the master data that the requesting external application is working with. The uploaded data formats must fully correspond to the data formats that can be uploaded by a specific ERP module or application. Examples of modules and applications with which integration should be provided by individual interface modules are:

• RM - a module for managing technical repair and maintenance of equipment as part of SAP ERP;

• FI-AA - fixed assets accounting module as part of SAP ERP;

• RE-FX - a flexible property management module as part of SAP ERP;

• SAP ARO - supply chain optimization system;

• SAP ME is a production management system at the workshop level.

[0074] For modules from another ERP system or other applications that perform similar functions, separate interface modules will be required because the formats and data structures will be different.

[0075] Each of the system interface modules can upload to an external application (ERP system module) not only master data about specific assets, but also hierarchies, classifiers, non-hierarchical relationships, structural and functional models related to the objects of this angles, as well as existing connections with objects of other angles when it is possible to use this data by external applications (modules of the ERP system) and the receipt of appropriate requests from them.

[0076] Each interface module included in the system can not only upload master data about assets (data about specific assets, hierarchies, classifiers, non-hierarchical links, structural and functional models related to objects of this view, as well as existing links with objects of other angles) into an external application (ERP system module), but also at the command of the administrator received through the dialog interface module, load these objects into a specially designated memory area from an external application (ERP system module) with which this module provides an interface ...

[0077] The dialog interface module enables the administrator to create and update master data about assets in a dialog mode, providing the ability to create, modify and delete hierarchies, classifiers, inter-view links, non-hierarchical links, classifiers of non-hierarchical links, structural and functional models in the system, create, change and delete attributes, assign and change their values, modify the classifier of units of measurement and classifier of file types.

[0078] The dialog interface module, in addition to creating, correcting and deleting master data in the dialog mode, can work with the master data loaded by the interface modules from the outside, correct this data, and make additional connections. After reviewing this data and making the necessary adjustments using the dialog interface module, the master data administrator can issue a command to transfer this data to the main asset data model, replacing the data that was previously in the data model.

[0079] Algorithmic modules included in the system provide checking the correctness and completeness of the system of connections between objects in the model, checking the correctness of classifiers, searching for objects by classifiers, generating new views of master data based on data from other views available in the system or based on external data, reporting on the data model and adjustments made in it, as well as other similar operations. To perform these functions, algorithmic modules have access to the elements of individual views of the model or master data about assets as a whole, necessary for their implementation. The initiation of the work of algorithmic modules is carried out by the administrator of the master data through the module of the dialog interface. Examples of more detailed functions performed by algorithmic modules:

• Search for a type of equipment that can be used to replace another known type of equipment that is discontinued or not available for purchase. The search is carried out by the equipment classifier related to the maintenance and repair view based on the hierarchy and attributes of the equipment classes.

• Generation of a preliminary version of the asset master data view based on the asset master data view and the maintenance and repair master data view.

[0080] As part of a set of algorithmic modules, an algorithmic module must be present that checks the correctness and completeness of the entire set of inter-view links between assets available in the data model. The operation algorithm of this module, shown in Fig. 6-6.2 is one of the claimed methods (100).

[0081] The algorithm module, at the first step of its execution (101), deletes (clears) all data about the markup of links formed in the external memory during the previous execution of the algorithm.

[0082] After that, the algorithmic module in the process of work traverses (102), (136) all hierarchical views presented in the asset structure. The crawl process uses the following in RAM:

• stacks Stack1 and Stack2;

• pointers to objects Pointer1 and Pointer2;

• a set of inter-view links, each of which has a sign, where you can put a mark about its passage.

[0083] When analyzing the next view, a traversal of all the assets contained in it is organized using the Stack1 stack and the Pointer1 pointer located in RAM, as shown in FIG. 7. To do this, when hitting the next view, the stack is cleared Stack1 and the Pointer1 value is set to the top node of the analyzed hierarchy (103). Then, using the cycle (105), (134) and operations (106), (135), all nodes of the hierarchy are traversed from top to bottom and sequentially along the branches of each subtree. In the process, Stack1 increases and shrinks, since the entire chain of tree nodes through which the next node became available is stored in Stack1.

[0084] When hitting the next node of the tree when traversing the tree, the following operations are performed:

• Clearing the in-memory stack Stack2 and loading the node at Pointer1 as the first element of Stack2 (107).

• Clearing the set of inter-view links formed in the RAM (108).

• Adding to the set of inter-view links located in the main memory of all the obligatory links of the class node of the first element from Stack2 from the attributes contained in the classifier according to clause 4 (109).

• Checking the completeness and correctness of the inter-view links of this node.

[0085] To check the completeness and correctness of inter-view links of each node, all rings of one lattice of inter-view links existing in external memory are traversed, starting from this node. For this, Stack2 is used, shown in FIG. 8. Traversing each of the rings with the help of the stack, we must return to the original object. In this case, the chain of links participating in the ring will be correct. Since the enumeration of all links of each object is performed, the correctness check of both unidirectional and bidirectional links will be automatically implemented.

[0086] The process of traversing all the rings of one lattice is implemented in such a way that internal view numbers (hierarchies) of the data model are used. An example of the lattice previously shown in FIG. 3, in which instead of the semantic names of the hierarchies, their internal numbers are used, assigned to them at the time of their appearance in the data model, is shown in FIG. 9. When checking the links in a particular lattice, the internal numbers of the hierarchies are substituted so that the node at the top of the Stack and its hierarchy get number 1, and the numbers of all other hierarchies are shifted in any direction along the ring, preserving the order. FIG. 10 shows an example when the object having in the lattice in FIG. 9, the internal hierarchy number 15, received the number 1, and the numbers of all other hierarchies were shifted. Formulas can also be used to change numbers:

Where:

Nnew - new hierarchy number,

Nold is the standard internal number of the hierarchy,

Nold1 is the standard internal number of the hierarchy, which should receive a new number equal to 1,

M is the number of hierarchies in the model.

[0087] The process of traversing all the rings of one lattice is implemented in such a way that the rings from the node with the number 1 must be built in such a way that each next node in the ring has a number greater than the previous one or number 1. Examples of two well-formed rings are shown in Fig. eleven:

1 - 2 - 3 - 4 - 9 - 10 - 1

1 -13 - 15 - 1

Examples of invalid rings are shown in FIG. 12.

Using the described principle makes it possible to exclude the creation of rings of arbitrary length. The maximum ring length will be M. Interview connections in the lattice, which will not be checked with the proposed method for constructing rings, will be checked when traversing rings from objects of other angles, when other elements of the same lattice are numbered 1.

[0088] Directly, the process of traversing all the rings of one lattice using the stack Stack2 is performed using the loop (110), (131) and operations (113), (114), (127), (128). All rings are traversed sequentially along the inter-view links of each object. In the process of this, Stack2 increases and contracts, since the entire chain of nodes of the ring, through which the next node became available, is stored in Stack2.

[0089] The process of traversing all rings of one lattice is implemented in such a way as to exclude multiple traversing of the same bond rings, starting from different objects. For this, during the execution of the algorithm (100), the markup of links is used, which is fixed in the external memory (which was previously cleared at step (101)). If, when traversing the rings, we pass along some connection, and for the next transition there are no unmarked connections or we get to the beginning of the ring, then we put a mark on the passed connection. With further verification, you will no longer need to go through this connection. As a result, after traversing all rings, starting with an object of one view, for objects of other views, only those links that have not yet been checked will be checked. Checking the relationships of these objects will not require any repeated traversal of the rings, which were already checked earlier. To establish the markup, checks (111) and (126), operations (112), (121), (125), (130) are used.

[0090] For the first element added to Stack2 when traversing all the rings of one lattice, the following actions are performed:

• A check is made whether there is a link between the class of the node by Pointer2 and the class of the node at the top of Stack2 in the set of inter-view links (116). If not, then a message is generated about an unexpected connection between the node at Pointer2 and the node in Stack2 (117).

• A check is made whether the link between the class of the node by Pointer2 and the class of the node at the top of Stack2 in the set of inter-view links (118) is marked. If not, then a mark is put on the link between the class of the node by Pointer2 and the class of the node in Stack2 in the set of inter-view links (119).

[0091] Then, for the next element of the ring, when traversing all the rings of one lattice, the following actions are performed related to checking the correctness of inter-view connections:

• A check is made to see if the node at Pointer2 matches the node at Pointer1 (120), which means that the ring has returned to the original node. If yes, then a mark is put on the current link in the markup in external memory so that no more traversal through it is made (121).

• A check is made whether the total number of members in Stack2 is equal to the number of hierarchies (views) in the master data model (122). If yes, then a message about a link failure is generated with an indication of all elements of the stack Stack2 (122), a mark is placed on the current link in the markup in external memory so as not to go through it anymore (125), the top element is excluded from the Stack (128).

• A check is made whether there are inter-view links originating from this node (ie, is there, in principle, the possibility to move from the node) (124). If not, then a communication failure message is generated indicating all elements of the stack Stack2 (129). And if so, then a check is made whether at the next hop there are connections without markup in external memory (126). If they are present, the node by Pointer2 is added to Stack2, and if they are absent, a mark is put on the current link in the markup in external memory, so that it does not go through it anymore (130).

[0092] After passing through all the rings of one lattice, a check is made whether unmarked links remain in the set of inter-view links located in the main memory (132). If yes, then a message is generated about the incompleteness of links with an indication of all objects corresponding to the classes of lattice nodes and unmarked lattice links (133).

[0093] After the end of traversing all hierarchies at the last step (137) as part of method (100), on the basis of all generated messages, a report is generated about broken, missing and unpredicted links or that there are no violations of inter-view links.

[0094] Based on the algorithmic module (100), two algorithmic modules are implemented that perform more specific operations:

• an algorithmic module for checking the correctness of inter-view links, the algorithm of which is shown in Fig. 13;

• an algorithmic module for checking the completeness of inter-view links, the algorithm of which is shown in Fig. fourteen.

[0095] Both modules each contain its own specific part of the operations of the algorithm (100). There are no operations in them that are not represented in algorithm (100). The algorithmic module for checking the completeness of inter-view links can reveal all missing links in full only in cases where all links in the data model are correct. This is achieved by executing the algorithmic module for checking the correctness of inter-view links and then correcting the identified errors in the links.

[0096] Algorithmic modules, inter-view link validation and inter-view link completeness checks shown in FIG. 13-13.1 and Fig. 14-14.2 allow you to organize a dialogue process:

• first, perform several stages of checking the correctness of links with correcting some of the errors after each run,

• then check the completeness of the links, after which the necessary missing links will be added,

• then again check the correctness of the links in order to correct the introduced errors

etc…

[0097] The sequential execution of the algorithmic module for checking the correctness of inter-view links and the algorithmic module for checking the completeness of inter-view links will require almost twice as long as the execution of one algorithmic module for checking the completeness and correctness of inter-view links, since all hierarchies and all rings of inter-view lattices will be traversed twice. links of each object.

[0098] FIG. 15 shows an example of a system (200) that is used to support the patented master data model, as well as to perform the functions of the asset master data management system, including the operation of interface modules, a dialog module, and algorithmic modules of the system.

[0099] System (200) includes the following components:

• Random access memory (RAM) (202), intended for operative storage of instructions executed by one or more processors (201) and operative temporary storage of working data.

• The storage medium (203) in external memory can be a hard disk drive (HDD), solid state drive (SSD), flash memory (NAND-flash, EEPROM, Secure Digital, etc.), an optical disk (CD, DVD , Blue Ray), mini disc or their combination.

• I / O interfaces (I / O) (205) are standard ports and means of connecting devices and data transfer, selected based on the required system execution configuration (200), in particular: USB (2.0, 3.0, USB-C, micro , mini), Ethernet, PCI, AGP, COM, LPT, PS / 2, SATA, FireWire, Lightning, etc.

• I / O tools (206) are also selected from a known range of different devices, for example, keyboard, touchpad, touch display, monitor, projector, mouse, joystick, trackball, light pen, stylus, audio output devices (speakers, headphones, built-in speakers, buzzer), etc.

• Data transmission means (207) are selected from devices designed to implement the process of communication between various devices via wired and / or wireless communication, in particular, such devices can be: GSM modem, Wi-Fi transceiver, Bluetooth or BLE module, GPS module , Glonass module, NFC, Ethernet module, etc.

• The system components (200) are interconnected via a common data bus (204).

[0100] Collectively, system (200) is a server platform that provides the necessary computations when implementing a master asset data management system. In the preferred embodiment, this server platform should be equipped with tools that have the following capabilities:

• The toolkit must have the capabilities of a graph database [13]. This will provide significant advantages when working with graphs by increasing the speed of development and reducing the amount of code when traversing chains of links, compared to traditional SQL, and will also require less resources for the prototype.

• The toolkit should have the capabilities of graph engines [14], which perform complex algorithms on a large graph as a whole, even if its fragments are stored on different servers included in the server cluster.

Information sources:

1. Wolter R., Haselden K. The What, Why, and How of Master Data Management. Microsoft Corporation, November 2006, URL: https://msdn.microsoft.com/en-us/library/bb190163.aspx?f=255&MSPPError=-2147217396

2. Otto B., Schmidt A. Enterprise Master Data Architecture: Design Decisions and Options. Institute of Information Management, University of St. Gallen, 13 p. URL: http://mitiq.mit.edu/ICIQ/Documents/IQ%20Conference%202010/Papers/2B1_EnterpriseMasterDataArchitecture.pdf

3. Equipment as Units of Tangible Assets. SAP Help Portal. URL: http://help.sap.com/saphelp_ppm400/helpdata/en/01/d545f84ab311d189740000e8322d00/frameset.htm

4. Creating an Architectural Object. SAP Help Portal. Url:

http://help.sap.com/saphelp_erp60_sp/helpdata/en/fb/5ad0531d8b4208e10000000a174cb4/frameset.htm

5. Management system for master data on assets. LLC "Optimal Management". URL: http://optimalmngmnt.com/page34ru.htm

6. RAO "UES OF RUSSIA". ANNUAL REPORT 2006. URL: http://www.fsk-ees.ru/media/File/stockholders/otchet/decisions/VOSA_otchet/RAO/03_RAO_GO_2006.pdf

7. Master data management. Wikipedia. URL: https://en.wikipedia.org/wiki/Master_data_management

8. What is Master Data. TechTarget. SearchDataManagement. URL: http://searchdatamanagement.techtarget.com/definition/master-data-management

9. Wolter R. Master Data Management (MDM) Hub Architecture. Microsoft Corporation, April 2007, URL: https://msdn.microsoft.com/en-us/library/bb410798.aspx?f=255&MSPPError=-2147217396

10. Barrenechea M.J., Jenkins T. Enterprise Information Management: The Next Generation of Enterprise Software / Open Text Corporation, Waterloo (Canada), 2013, 288 p.

11. Magic Quadrant for Master Data Management Solutions. Gartner / Analysts: O'Kane B., Palanca T., Moran M. P., 19 January 2017, ID: G00305598. URL: https://www.gartner.com/doc/reprints?id=1-3RH2O6C&ct=170120&st=sb

12. The Forrester Wave ™: Master Data Management, Q1 2016 // Forrester / Goetz M., March 16, 2016, 17 p.

13. Robinson I., Webber J., Eifrem E. Graph Databases. O'Reilly Media, 2nd ed., 2015, 238 p.

14. Processing large volumes of graph data: a guide to modern technologies. IBM / Sacr S., URL: http://www.ibm.com/developerworks/ru/library/os-giraph/index.html

Claims (50)

1. A master asset data management system containing: • the core of the system, which supports the creation, modification and storage of the master asset data model in memory: • model of master data on assets, necessarily including: - at least three hierarchically organized views corresponding to some representations of the available asset park, each of which is associated with at least one unique generic classifier of asset master data included in the model; - generic classifiers, each of which is a hierarchical system of classes built on the basis of the principles of inheritance and encapsulation, while the class of each object of the master data on assets in the classifier completely defines all the attributes of the corresponding object of this class and all types of its connections with objects of other angles ; - sets of links of each object of any of the angles with objects of other angles for transition between different representations of the same asset; for each hierarchically organized view: - a set of non-hierarchical (network) links between assets belonging to the same view, displaying view-specific relationships between assets; - a set of structural models of asset master data describing the internal relationships and component composition of specific types of assets; - a set of functional models of the master asset data, built on the basis of algorithms and based on mathematical models using the values of the attributes of individual instances of the master asset data and the attributes of the related instances of the master asset data in order to check the completeness of the data entry on asset or identify the type of asset depending on the values of the attributes; • at least three interface modules that are associated with the system core, each of which provides interaction of the system core with one application or with one functional module of the ERP system, each interface module is designed to be unloaded upon requests from external applications and / or ERP modules, a requested piece of master data about assets related to a particular view of the master data with which the requesting module or application is working; • at least one algorithmic module associated with the system core and configured to process the entire asset master data model and / or individual views of the asset master data model, providing operations from the following list: - checking the correctness and completeness of the system of inter-view links between objects in the model, and this check is performed according to an algorithm, in the process of which: to check the completeness and correctness of inter-view links of each node, all rings of one lattice of inter-view links existing in external memory are traversed, starting with of a given node, when executing which, to exclude multiple traversal of the same rings of links, markup of links in external memory is performed, while in the process of performing the traversal, the presence of unpredicted links or broken links is revealed by using a set of inter-view links from the master data model, moreover, after the completion of the traversal, in the case of returning to the original node, it is determined that the chain of links of this node is correct, if there are unmarked links in the set of inter-view links, the presence of missing links is determined; - checking the correctness of classifiers; - search for objects by classifiers; - formation of new views of the master data based on the data of other views available in the system or on the basis of external data; - formation of reports on the data model and on the adjustments made in it; • a module of the dialog interface, connected with the core of the system and providing the creation and correction of the master data by the administrator of the master data in the dialog mode. 2. The system according to claim 1, characterized in that each hierarchically organized view of the model reflects the ownership of assets (the entry of objects into higher-level objects). 3. The system according to claim 1, characterized in that if non-hierarchical (network) links between assets of the same view are of different types, then for them the master data model of assets necessarily contains a link classifier related to this view, which is a hierarchical system of classes, built on the principles of polymorphism and encapsulation, which, if necessary, can determine all the attributes of each type of network links of a given view. 4. The system according to claim 1, characterized in that the interface modules may have: • the ability to unload hierarchies, classifiers, network links, structural and functional models related to objects of a specific view, with which this interface module works, as well as existing links with objects of other views; • the ability to load model data into the master data management system, but this data cannot be used until confirmed by the master data administrator. 5. The system according to claim 1, characterized in that the dialog interface module can correct the master asset data obtained from the interface modules, confirm the correctness of this master data and transfer it to the main asset master data model. 6. The system according to claim 1, characterized in that: • the system has at least one algorithmic module that checks the correctness and completeness of the system of inter-view connections between objects in the model; • or the system can have two algorithmic modules, one of which checks the correctness of the inter-view links between assets in the system, and the second checks the completeness of the system of inter-view links between assets. 7. The method for checking the correctness and completeness of inter-view links between assets, implemented by the system according to claim 1, includes the following operations: • clearing all data on the markup of links formed in the external memory during the previous execution of the algorithm; • by means of stacks and pointers located in the main memory: traversal in a cycle of all hierarchical views presented in the structure of assets and traversal of all nodes of each hierarchy from top to bottom and sequentially along the branches of each subtree; • when hitting the next node of the hierarchy: clearing the second stack in memory and loading the current hierarchy node as the first member of the second stack; clearing the set of inter-view links formed in RAM and adding to this set of inter-view links all the obligatory links of the class node of the first element of the second stack from the attributes contained in the classifier; checking the correctness and completeness of the inter-view links of this node; • formation of a report on broken, absent and not supposed connections or that there are no violations of inter-perspective connections, and • to exclude multiple traversal of the same rings of links, markup of links in external memory is performed, while in the process of traversal, the presence of unpredicted links or broken links is revealed by using a set of inter-view links from the master data model, and after the traversal is completed, in the case of return to the original node, determine that the chain of links of this node is correct, if there are unmarked links in the set of inter-view links, determine the presence of missing links. 8. The method according to claim 7, characterized in that when checking the correctness and completeness of inter-view links of a particular node, all rings of the existing lattice of inter-view links existing in external memory are traversed from this node. 9. The method according to claim 8, characterized in that when checking the correctness and completeness of inter-view links of a particular node, the internal numbers of the views of the data model are used, and when checking the links in a particular lattice, the internal numbers of the hierarchies are substituted so that the node at the top of the second stack and its the hierarchy received the number 1, and the numbers of all other hierarchies are shifted in any direction along the ring, maintaining the order. 10. The method according to claim 9, characterized in that when checking the correctness and completeness of inter-view connections of a particular node, all the rings of the lattice are traversed in such a way that the rings from the node with number 1 are constructed so that each next node in the ring has a number greater than the previous one or number 1. 11. The method according to claim 10, characterized in that when traversing all the rings, the lattices of the rings are traversed sequentially along the inter-view connections of each object, and the entire chain of ring nodes through which the next node became available is stored in the second stack. 12. The method according to claim 10, characterized in that when traversing all the rings of the lattice, in order not to traverse each ring repeatedly, the markup of connections is used, which is fixed in external memory, if when traversing the rings, a transition is made along some connection, and for the next transition there are no unmarked links or the beginning of the ring occurs, then a mark is placed on the passed link, the transition is not made along the marked links. 13. The method according to claim 10, characterized in that when traversing all the rings of the lattice, a second pointer is used to select a new element of the current ring. 14. The method according to claim 10, characterized in that for the upper element introduced into the second stack when traversing all the rings of one lattice, the following checks are performed: • is there a link between the class of the node by the second pointer and the class of the node at the top of the second stack in the set of inter-view links, if not, then an error message is logged; • whether the link between the class of the node according to the second pointer and the class of the node at the top of the second stack in the set of inter-view links is marked, if not, then a mark is put on it. 15. The method according to claim 10, characterized in that for the next element of the ring, when traversing all the rings of one lattice, the following checks are performed: • whether the node by the first pointer coincides with the node by the second pointer, if yes, then a mark is put on the link between the nodes so that you do not go through it anymore; • is the total number of members of the second stack equal to the number of hierarchies in the master asset data model, if so, an error message is logged; • whether there are inter-view links outgoing from the node by the second pointer, if not, then an error message is recorded, if yes, then a check is made whether there are links at the next hop without marking in external memory, if there are any, the node by the second pointer is added to the second stack, and if it is absent, a mark is put on the link between the node in the second stack and the node at the second pointer, so as not to go through it anymore. 16. The method according to claim 10, characterized in that after the traversal of all the rings of this lattice is completed, a check is made whether unmarked links remain in the set of inter-view links located in the RAM, if so, an error message is generated.

Images