WO2018156043A1

WO2018156043A1 - System for managing asset master data

Info

Publication number: WO2018156043A1
Application number: PCT/RU2017/000096
Authority: WO
Inventors: Андрей Валентинович СУХОБОКОВ; Артем Андреевич СУХОБОКОВ; Андрей Львович МИХАЙЛОВ; Виктория Игоревна СТРОГОНОВА
Original assignee: Общество С Ограниченной Ответственностью "Оптимальное Управление"
Priority date: 2017-02-27
Filing date: 2017-02-27
Publication date: 2018-08-30
Also published as: RU2748741C2; RU2018130478A3; RU2018130478A

Abstract

The proposed system architecture consists of a system kernel, a set of interface modules and a set of high-level algorithmic modules. The system kernel supports the creation/modification and storage in a memory of an asset master data model built in the form of a set of hierarchically organized views (subject areas) of assets. The interface modules allow an individual view of the master asset data to be downloaded from or uploaded to the data model in response to a query from any application working with said view of the master data. A dialogue interface module provides support for a dialogue during the creation and correction of master data by a master data administrator. The high-level algorithmic modules make it possible to: verify the correctness and completeness of the system of relations between objects in the model; verify the correctness of classifiers; search for objects according to classifiers; form new master data views based on existing data from other views in the system or based on external data; perform accounting based on the data model and corrections made thereto; and also carry out other similar operations. For the proposed system architecture, the application describes in detail a data model which can be used for presenting asset master data, and also algorithmic modules for verifying the completeness and correctness of the relations between views in said model.

Description

ASSET MASTER DATA MANAGEMENT SYSTEM

DESCRIPTION

FIELD OF TECHNOLOGY

[0001] The claimed technical solution relates to the field of computer technology used to create and support a single consistent representation of asset master data, which eliminates duplication of asset master data in various modules of the corporate system and individual applications. Elimination of duplication eliminates the inevitable contradictions arising from the simultaneous use of several different representations of the asset master data. In addition to improving the quality of data, this reduces the cost of maintaining the current state of asset master data.

[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 enterprise-wide applications. The main characteristic features of master data are [1, 2.

• high importance for the company;

• less volatility compared to transactional data; · The availability of standard capabilities, the creation, reading, adjustment, destruction and search;

• reusability;

• Use as reference objects in transactional data. BACKGROUND

[0003] In existing corporate management systems in several modules or subsystems, as a rule, master data on production assets (assets) is independently maintained, reflecting various 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] Understanding the term “asset” is not unambiguous. The term is interpreted by different companies in different ways. Almost always, the concept of assets includes tangible assets (buildings, structures, equipment, land, buildings 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 the western, financial assets — stocks, bonds, loans, shares in joint projects, bills, etc., are included in a single concept of assets.

[0005] The total number of assets in purchasing companies, such as Russian Railways OJSC, Rosneft Oil Company, can reach several tens of millions of units. The bulk of such a large fleet (over 90%), as a rule, is comprised of tangible assets.

[0006] To maintain the current state of the master data and organize work with the master data of various applications, master data management systems (MDM systems) are used. The purpose of the use of MDM systems is the formation and support of a consistent, functionally complete and relevant presentation of the main data, reflecting all the nuances of the structure and activities of the enterprise. The presence and support of such a single meaningful presentation of master data is a critical factor for achieving the business goals of the enterprise. MDM systems are tools for supporting enterprise-wide master data management processes based on accepted guidance documents, policies, and standards [7–9]. From the point of view of software products belonging 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, has traditionally annually issued two independent analytical reviews on different classes of MDM systems - on MDM systems with item data, which included asset management data management systems and MDM systems with data on people, organizations and teams. In 2017, the company changed this tradition and issued a single review [11]. According to this review, each of the business applications (for example, within the framework of ERP, CRM or PLM) or their complexes (suites) can store its data and offer its own data management capabilities. The MDM system acts as an intermediate hub, which performs intermediary functions, manages, exchanges and regulates master data common to all applications. For many years, organizations have tried to achieve a “unified presentation” of master data using ERP or other functional systems that were not designed to support DM, so these attempts failed, or they proved too costly for continuous operation. This created the prerequisites for the emergence of MDM-systems. The penetration of MDM systems on the market now is less than 10%, there is a constant, 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 develop as single-domain systems designed to work with master data of a single category (subject area). The most common data domains are:

• Clients / consumers / patients / residents

• Suppliers I Manufacturers

• Distribution channels / partners

• Products / commodity items

· Purchased parts

• Assets

• Location

• 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 multivector MDM systems are still expanding very quickly. Multi-domain systems are designed to work with data from several subject areas. They must be able to support all the master data domains that the organization needs.

[0010] According to a survey of several thousand customers conducted by Gartner analysts, over five calendar quarters ending in the fourth quarter of 2015, the percentage of those who presented at least some multidomain requirements when purchasing an MDM system increased by more than four times, from 3.0% to 13.0% [11]. In this the group, the percentage of those who formally tested these opportunities increased from 0.5% to 3.1% (six-fold increase) in the third quarter of 2015, and then fell to 0.8% in the next quarter. At the same time, the percentage of those who required these features, but did not test them, had more than quadrupled by the end of 2015 from 3.0% to 12.0%. During 2016, the percentage of those who expressed a certain level of requirements for working in several master data domains reached a maximum of 14.6% in the second quarter and decreased by the end of the third quarter to the level of 13.5%. The percentage of those who formally tested these opportunities 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 extends the concept of multi-domain MDM systems. These systems provide an integrated set of tools for ensuring unity, accuracy, strategic management, semantic consistency and accounting for the official total assets of the enterprise master data. The multi-vector MDM system features include comprehensive tools for data modeling, data quality support, data management, data organization, data transfer service and integration of data into the workflow and transactional usage scenarios. Multivector MDM systems also offer higher levels of scalability, availability, manageability and security. In addition to working with different subject areas, multivector MDM systems must be able to work in different industries and different state. authorities, for different use cases (for designing data structures, as an operating or analytical MDM system), for different organizational structures (centralized, federated, localized) and for different scenarios for implementing an MDM system (register, consolidation, in coexistence mode and centralized) [1 1].

[0012] Among the set of functional capabilities inherent in modern MDM systems according to [1 1], from the point of view of the present invention, it is necessary to distinguish and consider in more detail the following two - hierarchy management and internal integration of a product complex.

[0013] Hierarchy management is the ability of an MDM system to model and store multiple hierarchies as inside separate domains master data, as well as traversing covered domains, in order to comprehensively classify all the master data entities for various business requirements, as well as for wide functions such as search and reporting. This ability 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 bit-temporal modeling should be supported when the same data is displayed in two hierarchies: “as it should be according to documents” and “as it is in fact”. For example, this can be used to form a hierarchy of architectural representation and a hierarchy of commercial use of real estate as part of real estate master data. The MDM system must provide support for balanced, unbalanced and recursive hierarchies, the ability to visualize to facilitate support and presentation of hierarchical data, and the ability to manage hierarchy versions so that you can use the audit log and restore data in the process of creating and maintaining hierarchies.

[0014] Internal integration of a product complex is the ability of an MDM system to provide, by default, integration between master data presented inside domains, regardless of whether they are stored together or separately from the point of view of, for example, data storage objects, as well as the ability to visualize and spawn this integration. This can be achieved using one product or several products as part of a complex or portfolio of products, as well as through the use of data created by customers or pre-packaged data models (or both modeling styles at the same time). However, if this ability is realized, then support must be provided for both different styles of implementation of the MDM system for each individual master data domain in time and simultaneously for multiple data domains, as well as pre-planned options for migrating domain implementation methods between implementation styles.

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

• MDM-systems that provide data integration and solve common problems;

· Multi-domain MDM systems and MDM systems that support many representations of master data;

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

• analytical MDM systems integrated into 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 a variety of master data representations is of the greatest interest. The leaders of this group are SAS, SAP and IBM. These companies currently do not have MDM systems that can provide the ability to manage master data about the assets that are implemented in this invention.

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

• In different application areas where work with assets is carried out, various principles of asset allocation are applied. For example, for accounting purposes, several adjacent units of equipment that have the same depreciation calculation rules can be combined into one fixed asset. For the purposes of repair and maintenance, objects are allocated that have a different order of repair and maintenance. For the purposes of property accounting, objects are distinguished that can be independently sold or leased, for example, one fiber in a bundle of optical fibers or fiber optic cable.

· In different applications working with the same asset fleet, different hierarchies of nesting of objects are used, and both objects of grouping levels and objects of lower levels of such detailed hierarchies are distinguished. • When operating complex management systems, users very often need to see related representations of the same asset. For example, from a technological view, it is necessary to see objects of maintenance and repair. From objects of maintenance and repair it is necessary to see fixed assets for which costs will be written off. From fixed assets it is necessary to see the corresponding property objects, etc. Almost always, users need to see objects from several different views. The lack of a one-to-one correspondence between the objects of the lower level of various applications leads to the emergence of many-to-many relationships between objects of different representations that describe the same asset. As previously shown, many fixed assets can correspond to one fixed asset. But the reverse is also true: many fixed assets can correspond to one object of technical accounting, for example, asphalt road, if its separate sections, which are not technical accounting units, 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 kernel of the system supports the creation / modification and storage in memory of a master asset data model constructed in the form of a set of hierarchically organized views (subject areas) of assets.

[0020] Interface modules provide unloading from the model and loading into the data model of a separate view the asset master data at the request of some application working with this view of master data.

[0021] The dialog interface module provides dialogue support for creating and updating master data by the master data administrator.

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

[0023] The various subject areas are represented by their specific hierarchies of objects. Each subject area has its own system of classes of objects. Classes of objects are built on the principles of polymorphism and inheritance and determine the properties (set of attributes) of an object.

[0024] The objects present in different hierarchies are combined by linking grids to transition from one representation of the object to another.

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

[0026] Structural and functional asset models are used to identify the 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 input of asset data or to identify the type of asset depending on the values of the attributes.

[0027] The whole set of relationships between assets within each view and relationships between objects belonging to the same asset, in different representations forms a complex graph of a specific structure. Incorrect or incomplete communications 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 totality of inter-aspect relationships in such a graph.

[0028] In order for the data structure to be correct, it is necessary that all relationships in it are correct. That is, going through the relationships between different representations of the same asset, if one-to-many or many-to-many relationships are not used, the user should see different representations 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 link structure will be complete if there are all the necessary links for the transition between different representations of the same asset. [0030] The validation of all links has a very simple meaning: from each object, 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 the links in the selected ring are correct. In order to check the correctness of all relations of one object, it is necessary to bypass all available connection rings in this way.

[0031] The check for completeness of bonds is based on the same technique of bypassing rings of bonds. For each class of objects in each of the representations, it is preliminarily determined what relations with objects of other representations should exist for objects of this class. If, while trying to bypass all the rings, some of the links is missing, then the existing set of links is incomplete.

BRIEF DESCRIPTION OF THE DRAWINGS

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

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

[0034] FIG. 3 illustrates an example of hierarchical construction of an object view.

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

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

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

[0038] FIG. 7 illustrates the use of the stack to traverse objects of the same angle.

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

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

[0041] FIG. 10 illustrates an example of the renumbering of lattice objects. An object that had a lattice in FIG. 9 internal number of the hierarchy 15, received the number 1, and the numbers of all other hierarchies have shifted. [0042] FIG. 11 contains examples of two correctly constructed lattice rings.

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

[0044] FIG. 13 illustrates an algorithm for verifying the correctness of inter-aspect relationships in an asset master data model.

[0045] FIG. 14 illustrates an algorithm for checking the completeness of inter-aspect relationships in an asset master data model.

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

DETAILED DESCRIPTION OF THE INVENTION

[0047] A system architecture including all of the listed components is shown in FIG. 2. and contains:

• the core of the system that supports the creation, modification and storage in the model memory of asset master data;

• at least three interface modules, each of which ensures the 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 asset master data model and / or individual views of the asset master data model;

• a dialog interface module that provides the creation and adjustment of master data by the administrator in a dialogue mode.

[0048] The asset master data model includes at least three views corresponding to some view of an existing asset park. Examples of such perspectives include:

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

• real estate objects;

· Objects of maintenance and repair of equipment;

• property objects (legal aspect);

• objects of various monitoring subsystems (fire safety, video surveillance, etc.); • objects of subsystems of operational control of operating modes of equipment of continuous production, transport and communications, utilities;

• objects of various MES and technological systems for managing 5 production,

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

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

y · facilities for the production, transportation and supply of oil, oil products and gas in the subsystems for the management of production, transportation and marketing of hydrocarbons;

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

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

and other representations of assets in terms of specific applications.

[0049] Each view is organized as a unique hierarchy that displays the ownership of the asset master data (objects in

20 objects of a higher level). For example, the view of objects for maintenance and repair of equipment (MRO) is organized in the form of a hierarchy, the top level of which is the MRO objects. 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

25 to a separate production and technological complex located at a particular plant. An even lower level corresponds to the places of installation of equipment in the framework of specific production and technological complexes. The lowest level of the hierarchy corresponds to units of equipment mounted at specific equipment installation locations. An example of a hierarchy of objects of maintenance and repair described in FIG. 3. The given example of a hierarchically constructed perspective 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 presenting master data on assets a particular company can contain any finite number of hierarchy levels.

[0050] For each view of the master data, there is one or more generic asset classifiers that classify all objects in that view. The generic classifier is a hierarchical system of classes built on the basis of the principles of inheritance and encapsulation. The initial objects of class hierarchies are the main classes of the generic model, which at the next hierarchy levels are detailed into groups of types of assets 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, us version.

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

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

· Attributes of a higher hierarchy class are inherited in all hierarchy classes subordinate to it.

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

[0053] Attributes with the same name can be used to describe the same asset, presented from different angles. However the values these attributes may not match.

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

[0055] Each class has three required attributes:

"Class name

• Class code (internal class name);

• Many class codes of other angles that represent the same asset, and with which an asset of this class must necessarily be connected by inter-angle relationships.

[0056] In the operation of integrated management systems, users very often need to see adjacent representations of the same asset. For example, from a technological view, it is necessary to see objects of maintenance and repair. From objects of maintenance and repair it is necessary to see fixed assets for which costs will be written off. From fixed assets it is necessary to see the corresponding property objects, etc. Therefore, in the asset master data model, for each asset of any angle, there is a set of relationships with objects of other angles for switching between different representations of the same assets.

[0057] The lack of a one-to-one correspondence between lower-level objects of various applications leads to the emergence of one-to-many, many-to-one, and many-to-many relationships between objects of different representations that describe the same asset. For example, many fixed assets may correspond to one fixed asset. But the opposite is also true: many fixed assets can correspond to one object of technical accounting, in particular, an asphalt road, if its separate sections, which are not technical accounting units, were built (bought) at different prices or at different times. An example of a set of relations uniting the representation of one and the same object from different angles is shown in FIG. 4. In this example, all cross-sectional communications are one-to-one and bi-directional. Further, for such a set of inter-angle relationships, we will use the term lattice.

[0058] Lattices are not necessarily complete (that is, they do not necessarily contain all the relationships of each object with each). The presence of connections between 5 different objects depends on the semantics - it is necessary to establish relations between objects of these angles at a given level or not.

[0059] At one level in the hierarchy of any of the views, there are many objects, each of which is associated with its own grid of adjacent objects. Lattices of one level can partially be combined with each other. This arises because in separate views one object can correspond to several objects of another view located at the same hierarchy level (for example, one fixed asset can combine several pieces of equipment), and, then, the lattices of adjacent objects of the same level can partially Connect in separate angles.

15 [0060] If we consider the Ze-model of the master data graph, then the gratings 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.

20 [0061] In each view, the asset master data model may contain a set of non-hierarchical (network) relationships between assets belonging to this view. These relationships display perspective-specific relationships between assets, such as participation in production chains or transport relationships. An example of non-hierarchical connections between

25 assets belonging to one perspective are shown in FIG. 5. Such relationships, for example, may reflect:

• the availability of transport routes between production and technological complexes engaged in the extraction of raw materials, their processing and distribution of finished products;

zo · intersections between highways

(by roads, metro lines, etc.);

• linking production equipment to production lines within the same workshop;

etc.

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

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

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

[0064] In the definitions of attributes of non-hierarchical relationships 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. In the definitions of attributes whose values are a graph, diagram, drawing, image or document, an additional reference to the file type from the file type classifier is used.

Each link class has two required attributes:

• class name

· Class code (internal class name);

[0065] In addition to having a classifier and attributes, non-hierarchical relationships have another important property: they can be parametric, that is, they can exist between objects in a shaded state and appear only when the values of one or more attributes of the object correspond to certain conditions. [0066] 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, a structural model of an asset that belongs to the Boiler Room class includes the required components: a building, a boiler installed in it, and a chimney. Structural models make it possible to verify the completeness of data entry about an asset or to identify the type of asset depending on its structure. Returning to the example already considered, if the object newly entered by the user has the Boiler class, but does not contain all three required components, an error message is displayed to the user. It can be checked not only the component composition, but also the presence of relations of certain types between components, as well as their topology, if the connections are defined in the structural model. For example, when checking an asset of the “Ring Highway” class, certain sections of this road should be so connected by links 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 Highway”.

[0067] In each view, the master data model may contain a set of functional models of asset master data specific to this view, which use the values of the attributes of individual assets and / or the attributes of the relationships of this asset and the attributes of the assets that are associated with the data during their execution. Functional models allow you to check the completeness of the input of asset data or to identify the type of asset depending on the values of the attributes. 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 give an example of a functional model that verifies the correctness of the input of an asset of the class "Kindergarten Building". If a building's attribute has a value of more than two for such a building, then either the asset data is entered incorrectly or the asset is incorrectly classified. As an example of a complex functional model of an asset, let us give a model that calculates the population of animals in the future by years in a certain natural territory depending on the number of animals living in this territory at the moment. If the simulation shows that after shooting a certain minimum number of individuals, the animal population is likely to start If this area is to be reduced, then the territory cannot be assigned the class of assets “Hunting lands”.

[0068] Each interface component of the system unloads, upon requests from an external application or 5 ERP modules, the requested fragment of master data about assets related to a particular view of master data with which the requesting external application works. The formats of the uploaded data must fully comply with the data formats that can be downloaded by a specific ERP module or application. Examples of modules and applications with which integration with individual interface modules should be ensured include:

• 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;

15 · RE-FX - flexible property management module in SAP

ERP

• SAP ARC - supply chain optimization system;

• SAP ME - workshop-wide production management system.

[0069] For modules of another ERP system or other applications,

20 performing similar functions, separate interface modules will be required, since the formats and data structures will be different.

[0070] Each interface module that can be part of the system can upload not only master data on specific assets to the external application (ERP system module), but also hierarchies, classifiers,

25 non-hierarchical relationships, structural and functional models related to objects of this angle, as well as relationships with objects of other angles when it is possible to use this data with external applications (modules of the ERP system) and the corresponding requests from them.

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

[0072] The dialog interface module enables the administrator to create and adjust master data on assets in the dialogue mode, providing the ability to create, modify and delete hierarchies, classifiers, cross-relationship relationships, non-hierarchical relationships, non-hierarchical relationship classifiers, structural and functional models, create, change and delete attributes, assign and change their values, modify the classifier of units of measure and the classifier of file types.

[0073] The dialog interface module, in addition to creating, adjusting, and deleting master data in the dialog mode, can work with master data loaded from the interface modules from outside, make corrections to these data, and make additional connections. After viewing this data and making the necessary adjustments using the dialog interface module, the master data administrator can give the command to transfer this data to the main asset data model with the replacement of the data previously available in the model.

[0074] The algorithmic modules included in the system provide verification of the correctness and completeness of the system of relationships between objects in the model, validation of classifiers, search for objects by classifiers, the formation of new views of the master data based on other angles available in the system or based on external data, reporting on the data model and on the adjustments made in it, as well as other similar operations. To perform these functions, the algorithmic modules have access to the elements necessary for their performance from individual views of the model or master data on assets as a whole. The operation of the algorithmic modules is initiated by the master data manager through the dialog interface module. Examples of more detailed functions performed by algorithmic modules:

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

• Formation of a preliminary version of the property master data view based on the master data view of the main

5 tools and a view of master data on objects of maintenance and repair.

[0075] As part of the set of algorithmic modules, there is always an algorithmic module that checks the correctness and completeness of the totality of the inter-aspect relationships between assets available in the data model. The operation algorithm of this module shown in FIG. 6, is one of the claimed methods (100).

[0076] the Algorithmic module at the first step of its implementation (101) carries out the destruction (cleaning) of all data about the markup links

15 formed in external memory during the previous execution of the algorithm.

[0077] After that, the algorithmic module in the process bypasses (102), (136) all hierarchical views presented in the asset structure. In the process of crawling, the following are used:

20 · stacks Stack1 and Stack2;

• pointers to objects Pointers and Pointer2

• a set of inter-angle relationships, each of which has a sign where you can put a mark on its passage

[0078] When analyzing the next perspective, a bypass of all 25 assets contained in it is organized using the stack Stack1 and the Pointers pointer located in the RAM, as shown in FIG. 7. To do this, when it enters the next view, the Stack1 stack is cleared and the Pointers 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 scanned from top to bottom and sequentially along the branches of each subtree. In the process, Stack1 grows and shrinks, since the entire chain of tree nodes through which the next node became available is stored in Stack1.

[0079] When it enters the next tree node while traversing tree 35, the following operations are performed: • Clearing the Stack2 stack located in the RAM and loading as the first element of the Stack2 node according to Index 1 (107).

• Cleaning of the set of inter-angle connections formed in the RAM (108).

• Adding to the in-memory set of inter-aspect relationships all the required relationships of the class node of the first element from Stack2 from the attributes contained in the classifier according to claim 4 (109).

· Checking the completeness and correctness of the inter-aspect relations of this node.

[0080] To check the completeness and correctness of the inter-angle connections of each node, all the rings of the same lattice of the inter-angle connections existing in the external memory starting from this node are bypassed. For this, Stack2 shown in FIG. 8. By going through the stack of each of the rings, we must return to the original object. In this case, the chain of links involved in the ring will be correct. Since all connections of each object are enumerated, the correctness check of both unidirectional and bidirectional connections will be automatically implemented.

[0081] The process of traversing all the rings of one lattice is implemented in such a way that the internal numbers of the views (hierarchies) of the data model are used. An example of the grid 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 moment they appear in the data model, shown in FIG. 9. When checking the links in a particular lattice, the internal numbers of hierarchies are changed so that the node at the top of the Stack and its hierarchy get the number 1, and the numbers of all other hierarchies are shifted in any direction along the ring, keeping order. In FIG. 10 shows an example when an object having a lattice in FIG. 9 internal number of the hierarchy 15, received the number 1, and the numbers of all other hierarchies have shifted. To change the numbers can also be used formulas:

Nnew = Nold - Nold + 1 provided: Nold> = Nold,

Nnew = Nold + M - Noldl + 1 provided: Nold <Noldl,

Where:

Nnew is the new hierarchy number, Nold - standard internal hierarchy number,

Noldl - 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.

[0082] The process of traversing all the rings of one lattice is implemented in such a way that the rings from the node with number 1 should be constructed so that each subsequent node in the ring has a number greater than the previous one or number 1. Examples of two correctly constructed 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 eliminates the creation of rings of arbitrary length. The maximum length of the ring will be M. Inter-angle connections in the lattice, which will not be checked with the proposed method of constructing rings, will be checked when traversing rings from objects of other angles, when other elements of the same lattice get number 1.

[0083] Directly the process of traversing all the rings of one lattice using the Stack2 stack is performed using the cycle (110), (131) and operations (113), (1 14), (127), (128). All rings are sequentially traversed by the inter-aspect relationships of each object. In the process, Stack2 grows and shrinks, since the entire chain of ring nodes through which the next node has become available is stored in Stack2.

[0084] The process of traversing all the rings of one lattice is implemented in such a way as to exclude multiple traversal of the same rings of bonds, starting from different objects. For this, during the execution of algorithm (100), markup of links is used, which is fixed in external memory (which was previously cleared in step (101)). If, when going around the rings, we go through some kind of connection, and for the next transition there are no unmarked links or we get to the beginning of the ring, then we put a mark on the passed connection. Upon further verification, it will not be necessary to go through this connection anymore. As a result, after traversing all the rings, starting with an object of one angle, only those relationships that have not yet been checked will be checked for objects of other angles. Checking the relationships of these objects does not require any re-traversal of the rings that were previously checked. To set up the markup, checks (1 11) and (126), operations (112), (121), (125), (130) are used. [0085] For the first element introduced on Stack2 bypassing all the rings of the same lattice, the following actions are performed:

• A check is made to see if there is a connection between the node class by Pointer2 and the node class at the top of Stack2 in the set of inter-aspect relations (116). If not, a message is generated about the unforeseen connection between the node on Pointer2 and the node in Stack2 (117).

• A check is made to see if the connection between the node class by Pointer2 and the node class at vertex Stack2 in the set of inter-aspect relations is marked (118). If not, then a mark is placed on the connection between the node class according to Pointer2 and the node class on Stack2 in the set of inter-aspect relations (119).

[0086] Then, for the next element of the ring, bypassing all the rings of the same lattice, the following actions are performed related to checking the correctness of inter-angle relationships:

• A check is made to see if the node according to Pointer2 coincides with the node according to Pointers (120), which means that the ring has returned to the original node. If so, then mark the current connection in the markup in the external memory so that it no longer passes through it (121).

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

• A check is made to see if there are inter-aspect communications originating from this node (that is, whether there is, in principle, the ability to go from the node) (124). If not, then a message is generated about the failure of links indicating all the elements of the stack Stack2 (129). And if so, then a check is made to see if there is a connection without markup in the external memory at the next transition (126). If there is one, the node by Pointer2 is added to Stack2, and if not, a mark is placed on the current link in the markup in the external memory so that it does not go through it anymore (30). [0087] After passing through all the rings of one lattice, a check is made to see if there are any unmarked links in the set of inter-angle links located in the main memory (132). If yes, then a message is generated about the incompleteness of the links indicating all the objects corresponding to the classes of lattice nodes and unmarked lattice links (133).

[0088] After completing the traversal of all hierarchies in the last step (137), a report is generated on the basis of all generated messages based on all generated messages that indicates broken, missing or unintended connections, or that there are no inter-angle communication violations.

[0089] Based on the algorithm module (100), two algorithm modules are implemented that perform more private operations:

• an algorithmic module for checking the correctness of inter-aspect relationships, the operation algorithm of which is presented in FIG. 13;

• an algorithmic module for checking the completeness of inter-aspect relationships, the operation algorithm of which is presented in FIG. fourteen.

[0090] Both modules each contain their own specific part of the operations of algorithm (100). They have no operations not represented in algorithm (100). The algorithmic module for checking the completeness of inter-aspect relationships can identify all missing relationships in full only when all the relationships in the data model are correct. This is achieved by the implementation of the algorithmic module for checking the correctness of inter-aspect relationships and the subsequent correction of identified errors in the relationships.

[0091] Algorithmic modules, correctness checks of inter-aspect communications, and checks of the completeness of inter-aspect relationships, shown in FIG. 13 and FIG. 14 allow you to organize a dialogue process:

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

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

· Then again check the correctness of the links to correct the errors made

and so on...

[0092] Successive sequential execution of the algorithmic module for checking the correctness of inter-aspect communications and the algorithmic module for checking the completeness of inter-aspect communications will require almost twice as much time than the execution of one algorithmic module for checking the completeness and correctness of inter-aspect relations, since all hierarchies and all rings of the inter-angle relationships lattices of each object will be double-scanned.

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

[0094] The system (200) includes the following components:

· Random access memory (RAM) (202), designed for online storage of instructions executed by one or more processors (201) and operational temporary storage of working data.

• The storage medium (203) in the external memory may be a hard disk drive (HDD), solid state drive

(SSD), flash memory (NAN D-f lash, EEPROM, Secure Digital, etc.), an optical disk (CD, DVD, Blue Ray), a mini disk, or a combination thereof.

• Input / output (I / O) interfaces (205) are standard ports and devices for pairing devices and transmitting data, selected based on the required configuration of the system (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 facilities (206) are also selected from a well-known range of various devices, for example, a keyboard, touchpad, touch display, monitor, projector, mouse, joystick, trackball, light pen, stylus, sound output devices (speakers, headphones, built-in speakers, buzzer), etc.

· Data transmission tools (207) are selected from devices designed to implement the communication process between different 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. • System components (200) are interfaced via a common data bus (204).

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

• 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 to work.

• The toolkit must have the capabilities of graph engines [14] that perform complex algorithms on a large graph as a whole, even if its fragments are stored on different servers that are part of 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_Enterpris eMasterDataArchitecture.pdf

3. Equipment as Units of Tangible Assets. SAP Help Portal. URL:

http://help.sap.com/saphelp_ppm400/helpdata/en/01/d545f84ab31 1d189740000e8322d 00 / f rameset.htm

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

http://help.sap.com/saphelp_erp60_sp/helpdata/en/fb/5ad0531d8b4208e10000000a174 cb4 / f rameset.htm

5. Asset master data management system. Optimal Management LLC. URL: http://optimalmngmnt.com/page34en.htm

6. RAO "UES of RUSSIA". 2006 ANNUAL REPORT. URL: http: //www.fsk-ees.ru/media/File/stockholders/otchet/decisionsA OSA_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. Search DataManagement. 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

0. 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 -3RH206C & ct = 170 20 & 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, 2-nd ed., 2015, 238 p.

14. Processing large volumes of graph data: a guide to modern technology. IBM / Sacr. S., URL:

http://vvww.ibm.com/developen/vorks/ruM

Claims

FORMULA ASSETS MASTER DATA MANAGEMENT SYSTEM

1. An asset master data management system comprising:

• the core of the system that supports the creation, modification and storage in the model memory of asset master data,

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

• at least one algorithm module configured to process the entire asset master data model and / or individual views of the asset master data model,

2. The system according to claim 1, characterized in that the asset master data model includes at least three hierarchically organized views corresponding to some representations of the existing asset park, with each hierarchically organized view showing the ownership of the assets (their occurrence to assets of a higher level).

3. The system according to claim 1, characterized in that each aspect of the master data model for assets is associated with at least one unique classifier of master data on assets that is part of the model, which is a hierarchical system of classes built on based on the principles of inheritance and encapsulation, and the class of each asset master data object fully defines all the attributes of this object.

4. The system according to claim 1, characterized in that the asset master data model includes, for each object of any angle, a set of relationships with objects of other angles for transition between different representations of the same asset.

5. The system according to claim 1, characterized in that the master data model for assets in each perspective may include a set of network relationships between assets belonging to the same perspective. Such network communications can be of various types and can be characterized by sets of attributes.

6. The system according to claim 1, characterized in that for network connections characteristic of any of the views, if these connections are of different types, then for them the master data model for assets necessarily contains a classifier related to this view, which is a hierarchical class system based on the principles of polymorphism and encapsulation. This classifier, if necessary, can determine all the attributes of each type of network connections of this angle.

7. The system according to claim 1, characterized in that the asset master data model in each perspective can include a set of structural master asset data models describing the internal relationships and component composition of specific asset types.

8. The system according to claim 1, characterized in that the asset master data model in each perspective may include a set of functional master asset data models using the attribute values of individual instances of asset master data and attributes of related instances asset master data.

9. The system according to claim 1, characterized in that each interface module is configured to download, upon requests from external applications and / or ERP modules, the requested fragment of the master data on assets related to a particular view of the master data with which the requesting module is running.

10. The system according to claim 1, characterized in that, if necessary, the interface modules can have the ability to unload hierarchies, classifiers, network connections, structural and functional models related to the objects of a particular perspective, with which this interface module works, as well as existing connections with objects from other angles.

1 1. The system according to claim 1, characterized in that, if necessary, the interface modules may have the ability to download model data, but this data cannot be used until it is confirmed by the master data administrator.

12. The system according to claim 1, characterized in that the dialog interface module provides the creation and adjustment of master data by the master data administrator in the dialogue mode, as well as, if necessary, the adjustment of master data on assets received from the interface modules, confirmation of the correctness of these wizards -data and its transfer to the main master model asset data.

13. The system according to claim 1, characterized in that the algorithmic modules included in the system verify the correctness and completeness of the system of connections between objects in the model, verify the correctness of classifiers, search for objects by classifiers, generate new views of the master data based on available in the system data from other angles or based on external data, generating reports on the data model and on the adjustments made in it, as well as other similar operations necessary to work with the master data of a particular user rka assets.

14. The system according to claim 1, characterized in that:

• at least one algorithmic module will implement a method for checking the correctness and completeness of inter-angle relationships between assets in the system;

• and / or in the system there can be two different algorithmic modules, one of which checks the correctness of the inter-angle relationships between assets in the system, and the second - checks the completeness of the inter-angle relationships between assets.

15. The system of claim 14, characterized in that if it implements two algorithmic modules, one of which checks the correctness of inter-angle relationships between assets in the system, and the second - checks the completeness of the system of inter-angle relationships between assets, then each of these modules implements a data processing method in which only part of the operations of the algorithmic module for checking the correctness and completeness of inter-aspect relationships between assets is performed.

16. A method for verifying the correctness and completeness of inter-aspect relations between assets, in which it is performed:

• clearing all data about the markup of links formed in the external memory during the previous execution of the algorithm;

• traversal in a cycle of all hierarchical views presented in the asset structure;

• traversal of all nodes of each hierarchy from top to bottom and sequentially along the branches of each subtree using the stack and pointer located in the main memory:

• upon falling into the next node of the hierarchy:

o cleaning up the second in RAM stack and loading the current node of the hierarchy as the first element of the second stack;

o cleaning the set of inter-angle links formed in the RAM and adding 5 inter-angle links of all the required links of the class node of the first element of the second stack to the set of attributes contained in the classifier;

o verification of the correctness and completeness of inter-aspect relations of this node;

y · reporting on broken, missing and unintended communications, or that there are no violations of inter-angle communications.

17. The method according to p. 16, characterized in that when checking the correctness and completeness of inter-aspect communications of a particular node, all

15 rings of the existing lattice of inter-aspect relations existing in external memory starting from this node.

18. The method according to p. 16, characterized in that when checking the correctness and completeness of inter-aspect relationships of a particular node, the internal numbers of the views of the data model are used and when checking the relationships in a specific lattice

20 substitution of internal hierarchy numbers so that the node at the top of the second stack and its hierarchy get number 1, and the numbers of all other hierarchies are shifted in any direction along the ring, keeping order.

19. The method according to p. 16, characterized in that when checking the correctness and completeness of inter-aspect relations of a particular node, all the rings are bypassed

25 lattices in such a way that the rings from the node with number 1 are built so that each subsequent node in the ring has a number greater than the previous one or number 1.

20. The method according to p. 16, characterized in that when bypassing all the rings of the lattice, the rings are sequentially traversed by the inter-aspect relationships of each object, and the entire chain of ring nodes through which the next node has become available is saved on the second stack.

21. The method according to p. 16, characterized in that when bypassing all the rings of the lattice, in order not to pass each ring repeatedly, marking of links is fixed in the external memory. If, when going around the rings, a transition is made through some kind of connection, and there is no transition for the next transition

35 unmarked links or there is a hit at the beginning of the ring, then on the passed connection is marked. For the marked links, the transition is not performed.

22. The method according to p. 16, characterized in that when bypassing all the rings of the lattice, to select a new element of the current ring is used

5 second pointer.

23. The method according to p. 16, characterized in that for the first element pushed onto the stack when bypassing all the rings of the same lattice, checks are performed:

• is there a relationship between the node class at the second pointer and the node class at the top of the second stack in the cross-view set

10 links. If not, an error message is logged;

• whether the link between the node class at the second pointer and the node class at the top of the second stack in the set of inter-aspect relations is marked. If not, then it is marked.

24. The method according to p. 16, characterized in that for the next element of the ring 15 when bypassing all the rings of the same lattice checks are performed:

• whether the node in the first pointer matches the node in the second pointer. If so, then a mark is placed on the connection between the nodes so that they do not go through it anymore;

• whether the total number of elements of the second stack is equal to the number of hierarchies in the 20 asset master data model. If so, an error message is logged;

• whether there are inter-aspect communications originating from the node by the second pointer. If not, an error message is logged. If yes, then a check is made to see if there is a connection at the next transition

25 without markup in external memory. If there is one, the node at the second pointer is added to the second stack, and if not, a mark is placed on the connection between the node in the second stack and the node at the second pointer so that it does not go through it anymore.

25. The method according to p. 16, characterized in that at the end of the traversal of all the rings of the given lattice, a check is made to see if there are any unmarked links in the set of inter-angle links located in the main memory. If so, an error message is generated.

26. The system according to claim 1, using at least one processor and at least one memory containing machine-readable instructions that when they are executed by at least one processor, they support the master data model according to items 2–8, as well as the functions of the system interface modules according to items 9–11, the functions of the dialog module according to items 12–8, and also the algorithmic functions system modules according to claims 13 to 25.