RU2671048C2 - System and method for identifying relevant information for enterprise - Google Patents

Abstract

FIELD: computing; counting.SUBSTANCE: invention relates to means of finding information. Portable device is configured to access and display information relating to an enterprise, wherein the device has a communication means, a display and an energy source, wherein said device communicates with a computing device having a machine-readable medium with executable instructions encoded on a storage medium, and also stores an enterprise model, wherein processes associated with the model include process nodes, a machine-readable description of relevance between different process nodes and the relevance between content and data and said different process nodes, said plurality of process nodes are interconnected in a causal grid, wherein each link is encoded by executable instructions.EFFECT: technical result is aimed at widening the range of tools for the same purpose.38 cl, 22 dwg

Description

FIELD OF TECHNOLOGY

[0001] The disclosure of the present invention relates to enterprise software and, more specifically, to a software tool for finding information that is relevant to problems, opportunities and / or unexpected or interesting events that affect the processes carried out by the enterprise.

BACKGROUND

[0002] An enterprise (which can be any organization engaged in activities to achieve a goal) usually has goals and processes that are capable of achieving these goals. Problems in the enterprise usually affect the success of one or more processes; these problems must be identified in a special and effective way. Individuals in the enterprise (users of the enterprise system) should be warned about problems that could be dangerous for the processes for which they are responsible. A user who needs to solve a problem will want to have at his disposal information that is relevant to the problem, in particular, information about current and past experience in the enterprise that is relevant to the problem. The user will also want to collaborate with other users to solve the problem.

[0003] Thus, it is desirable to implement a system that identifies and retrieves information that is relevant to a problem associated with a process, and sends this information to users who are most concerned with the problem.

SUMMARY OF THE INVENTION

[0004] According to the disclosure of the present invention, there is provided a system and method for locating and retrieving information within an enterprise that is relevant to enterprise problems, enterprise capabilities, and unexpected or interesting events. As the system searches for information about the enterprise, it indexes current elements (eg, transmitted emails) and past elements (eg, archived notifications) to improve knowledge of the system related to a problem, opportunity, or event.

[0005] According to a first aspect of the disclosure of the present invention, a system for finding information relevant to a process performed by an enterprise, or to a voltage point of an enterprise of said process, includes a computing device configured to view content related to the process carried out by the enterprise, a process includes one or more process steps; identification of problems, opportunities or events (stress points of the enterprise) associated with the process step; indexing the viewed content relative to the stress point of the enterprise; determining whether the content viewed is information relevant to the problem, opportunity or event; and providing relevant information to the user. Relevant information includes a description or discussion of the prior experience of the enterprise (or related enterprises) regarding a problem, opportunity or event. The content viewed may include an e-mail message within the enterprise, to the enterprise, or from the enterprise; documents created by the enterprise; Application data associated with the process, including business objects and / or web content available to the enterprise. An enterprise stress point is a problem, opportunity, or an unexpected or interesting event, and it is associated with other stress points that further describe a hazard, cause, effect, or remedy.

[0006] Determining whether the information is relevant to the problem, opportunity or event, may further include determining the effect of the completion of a process step on the achievement of a goal associated with a process including this process step; it expresses closeness to the goal of the process step. Proximity to the goal of a process step can also be used to identify a hazard, which is an important criterion for relevance.

[0007] The definition of proximity to a goal can also be used to find similar processes that, due to the similarity of their generalized aspects and the similarity of proximity to a goal, are considered similar; the experience options associated with these similar processes are returned by the system for user attention.

[0008] The determination of relevance can be provided by identifying processes that are characterized in the system by their generalized components of processes, so that a conclusion about the similarity or relevance between processes can be made due to their generalized aspects. Additionally, the characteristic problems or capabilities embedded in the processes may establish additional similarity or relevance between the processes.

[0009] The system may include a viewer for viewing content related to the process carried out by the enterprise; language parser for identifying concepts within the content viewed; and an indexing machine for indexing the viewed content relative to the process node (wherein the process node is associated with this problem, opportunity or event), and to determine whether the viewed content is information relevant to the problem, opportunity or event. The language parser and indexing machine together designate the relevance of stress points to concepts within the viewed content, whereby a stress point index is generated for elements of the viewed content.

[00010] The system may further include a user interface using a stress point index to alert the user of a problem associated with a corresponding set of processes; enable collaboration between users regarding a problem or opportunity associated with a process by limiting the information returned to current and historical information related to processes for which collaborating users are participants, and by providing the ability to return information related to subordinate processes if that information probably poses a danger to processes for which collaborating parties are involved; or extracting information that includes a description or discussion of prior experience related to a problem associated with a process. In one embodiment, the indexing machine is a middleware service.

[00011] According to another aspect of the disclosure of the present invention, a user can control a cognitive structure that extracts past and current experiences that can be used for many of the uses described here.

[00012] It should be noted that, according to the disclosure of the present invention, when solving enterprise problems, using the capabilities of the enterprise, or explaining interesting or unexpected events occurring within the scope of the enterprise, the relevance of the content item or data to the enterprise can be fully determined by establishing a connection of this content or data with relevant enterprise stress points (process nodes) and with cognitive structure elements that are most closely associated with these Lamy process; similarities between processes can be fully determined by reference to the identification of processes and their generalized components of processes, proximity to the goal of the respective processes with respect to their dependent processes, and characteristic problems, capabilities or events associated with the processes; and, when it is determined that a process node within a stage constitutes a hazard, the significance of this hazard can be fully determined by reference to (i) the proximity of this stage to its direct purpose, (ii) the proximity to the purpose of this stage and its effect on additional dependent goals , (iii) the estimated cost of failing to achieve goals and corrective action, and (iv) the likelihood that the site in question will fail.

[00013] The foregoing description has briefly outlined, rather broadly, preferred features of the disclosure of the present invention, so that those skilled in the art can better understand the detailed description of the disclosure of the present invention, which follows. Further, further features of the disclosure of the present invention, which form the subject of the claims according to the present disclosure of the present invention, will be described. Those skilled in the art should understand that they can easily use the disclosed idea of the invention and the specific embodiment as a basis for designing or modifying other structures for the same purposes as the objectives of the disclosure of the present invention, and that such other structures are not beyond the nature and scope of the disclosure of the present invention in its broadest form.

BRIEF DESCRIPTION OF THE DRAWINGS

[00014] FIG. 1 schematically shows an enterprise having goals and processes, with software for finding relevant information related to the enterprise, according to one embodiment of the disclosure of the present invention.

[00015] FIG. 2 schematically shows aspects of a process node for an enterprise process.

[00016] FIG. Figure 3 schematically shows the abstraction of the activities underlying the definition of a process node.

[00017] FIG. 4 shows the goals and associated processes for the enterprise.

[00018] FIG. 5 shows some details of the two processes and the problems associated with these processes.

[00019] FIG. 6A shows proximity to a target for various process steps.

[00020] FIG. 6B shows the interaction between agents in the enterprise and this process step.

[00021] FIG. 7A schematically shows generalized processes and more specific processes.

[00022] FIG. 7B schematically shows processes including process nodes or stress points of an enterprise.

[00023] FIG. 8 schematically shows the process nodes representing the hazards, causes, consequences and means for a variety of processes.

[00024] FIG. 9 is a flowchart showing a procedure by which an expert user can assign node attributes at various context-specific levels of abstraction.

[00025] FIG. 10 is a flowchart showing a procedure for identifying generalized processes and processes similar to a given source process, according to one embodiment of the disclosure of the present invention.

[00026] FIG. 11 is a flowchart showing a procedure by which an expert user can populate the system with cases or told stories, according to one embodiment of the disclosure of the present invention.

[00027] FIG. 12 is a flowchart showing a method in which software creates and uses an enterprise voltage point infrastructure, according to one embodiment of the disclosure of the present invention.

[00028] FIG. 13A and 13B are connected flowcharts showing steps performed by a user of a disclosure system to solve a problem or take advantage of an opportunity.

[00029] FIG. 14 schematically shows a system for collecting information and indexing information regarding voltage points of an enterprise, according to one embodiment of the disclosure of the present invention.

[00030] FIG. 15 schematically shows a convergence of objectives, according to one embodiment of the disclosure of the present invention.

[00031] FIG. 16 schematically shows a system for use with multiple users, some of which have access to display devices (displays) with limited viewing access.

[00032] FIG. 17 schematically shows an emergency management system known in the art.

[00033] FIG. 18 schematically shows an emergency management system according to one embodiment of the disclosure of the present invention.

[00034] FIG. 19 is an enlarged view of a portion of the emergency control system of FIG. 18 showing a display of selected nodes.

DETAILED DESCRIPTION

[00035] Software embodying the present disclosure is referred to herein as “Overlay”. Overlay is an aid to finding information within an enterprise; sources of this information are therefore, typically, internal content and enterprise data, including messages transmitted within the enterprise, and messages transmitted between the enterprise and external parties. Another source of information is external information related to the enterprise, to which the enterprise wishes to access regularly. One aspect of Overlay is that it functions as a relevance machine, as opposed to a search engine; Overlay extracts only information that is considered relevant to the problems, opportunities and unexpected or interesting events of the enterprise.

[00036] Overlay software utilizes relevance between enterprise processes and relevance between enterprise stress points in such processes (namely, focal points in a business that represent risks, failure to predict, conflicts, dangers, common causes and related areas of attention and knowledge) , to present to the user only the relevant return data from the underlying data and content in order to do the following:

[00037] Provide the Overlay user with an overview of the underlying changes to any enterprise software / emails that may form an enterprise stress point for which the user is responsible. In a large organization, senior staff cannot manually manage and thus control all applications, and cannot hard-code workflows for every possible issue that could potentially create a problem. Because enterprise stress points are often caused by a combination of multiple events, Overlay helps identify these enterprise stress points and avoids overly detailed notifications when this is undesirable;

[00038] Provide the Overlay user with the ability to access enterprise content and / or data systems (including email systems) from remote locations using a portable device, and to play a filtered view of events that affect enterprise voltage points;

[00039] Provide the Overlay user with the ability to handle events and coordinate alerts, as well as improve content related to metadata knowledge; and

[00040] Provide the Overlay user with the ability to manage unwanted events with relevant legacy content.

[00041] Glossary

[00042] Cause: An event or potential event that is considered the cause of the investigation.

[00043] Main reason: an event or potential event that is considered to be the cause of the cause.

[00044] Consequence: an event or potential event that is considered to be the result of a process or a planned goal or conditional goal.

[00045] Danger: potential consequence. It can be both positive when it corresponds to the possibility, and negative when it corresponds to the problem.

[00046] Diagnosis: finding the cause of problems and explaining interesting events or causes of opportunity.

[00047] Organize: be an abstraction of something, generalize, group.

[00048] Proximity / proximity: The percentage effect of a process step on the process goal to which this step relates.

[00049] Goals or conditional goals: goals and conditional goals for which the enterprise process was designed.

[00050] Cognitive structure: a structure that indexes information in a manner that complies with known cognitive principles.

[00051] The primary means for a better understanding of a problem or opportunity: the means by which the most appropriate relevance related to the problem or opportunity is determined.

[00052] Cases / discussions / descriptions / variants of experience: these are cases of variants of experience that can describe all or part of the cause, effect, danger, and means. They can include general explanations and models to describe how objects behave in the processes in which they are assigned.

[00053] Models: generalized cases explaining cause and effect.

[00054] Explanations: explanations of problems or opportunities or unexpected events.

[00055] Attributes: characteristics of the subjects mentioned in the disclosure of the present invention. Node attributes are used to determine the similarity of nodes. Namely, the characteristics of the nodes that determine the similarity. Node attributes are represented in the state model. Namely, the characteristics of the nodes are presented in the state model.

[00056] Responsible: a situation in which the attributes of agents significantly affect the outcome of a process or process step.

[00057] Problems / Failures: In the disclosure of the present invention, problems and failures are considered to be nodes in processes where experienced practitioners reasonably expect problems and / or failures or unexplained phenomena or phenomena of unexplained causes and effects.

[00058] Opportunities / Successes: In the disclosure of the present invention, opportunities and successes are considered nodes in processes where experienced practitioners reasonably expect opportunities and / or successes.

[00059] Event / unexpected event / interesting event: in the disclosure of the present invention, an event is an event that an experienced practitioner with good reason considers important for the enterprise and its goals.

[00060] Process nodes: parts of processes where experienced practitioners expect problems or opportunities.

[00061] Experienced practitioners: people who have participated or have been responsible for a process in which they are considered highly experienced due to most of their career achievements, and know the specific process and its main characteristics, and also know processes that are dependent on and subordinate to the process, in which they are considered highly experienced.

[00062] Enterprise: any organization or set of organizations engaged in activities for one or more well-known purposes; usually characterized by predictability of goals at any given time, predictability of plans and processes to achieve these goals, and agents with essentially known significance, qualifications, knowledge, information, stamina, and emotions regarding goals.

[00063] Business structure: infrastructure of relevant relevance criteria that are recognized by practitioners in most subject areas.

[00064] Type of activity of the enterprise: the types of activity are recognized by practitioners in each subject area or in more than one subject area.

[00065] External process: external processes that take place outside the enterprise on which some enterprise processes depend: for example, design, construction, or training, and training activities that may be part of any stage of the process; processes that are found to occur in an environment that are not designed to achieve known goals, but that affect the goals and processes of an enterprise, for example, discretionary human behavior: or processes that are not directly related to human behavior, such as environmental phenomena.

[00066] Practitioners: people who have average experience in the enterprise.

[00067] Overlay: a system and / or method according to the disclosure of the present invention.

[00068] Typical problems / opportunities / nodes: problems, opportunities, or unexpected / potential / random events, at various levels of abstraction, which experienced practitioners consider to be repeated in many related processes. Characteristic problems / opportunities are associated with goals, as problems and opportunities cannot be identified without first setting goals.

[00069] Object: an object in a subject area that is part of a process.

[00070] Context: the environment in the subject area within which the process takes place.

[00071] Abstract object: an object that can be abstracted and thus can be applied to more than one subject area.

[00072] Abstract context: a context that can be abstracted and thus can be applied to more than one subject area.

[00073] Subject area: industry, branch of a company, or any structure of an enterprise where the process steps and terminology are specific, and practitioners understand them.

[00074] Bone: the characteristics of the subject in the model of activities of the enterprise, which changes, but is considered constant, as practitioners expect this characteristic to be fairly constant and predictable.

[00075] Relevance criteria: any entity that helps to create a structure or model of the types of activity of an enterprise.

[00076] Circumstances: context, object time, etc.

[00077] Process: a sequence of actions that serve to achieve a variety of goals and conditional goals. They can vary from bone processes, to established processes, to newly established processes, to plans that are processes that are yet to be put into practice.

[00078] Scenario: A process that is performed consciously and unconsciously as it has become bone.

[00079] Plan: a plan is not a very well defined process, where the steps in the process are ordered in a manner appropriate to current circumstances. The hierarchy of plan goals often differs from the underlying processes that they unite.

[00080] Inanimate process: a process that does not include human intervention (such as a chemical process) and thus may not have goals other than the goals of the process of which it was designed by people. For example, corrosion is an inanimate process that is predictable and well-known, but nonetheless cannot be considered to be a goal-based process.

[00081] Non-goal-based inanimate processes: processes that people carry out, but which are not explicitly goal-based, such as evaluating some type of music or preference for some color. A common definition for this is discretionary.

[00082] Condition: as defined in English and in AI.

[00083] Goals and processes of the enterprise

[00084] As schematically shown in FIG. 1, enterprise 1 generally has goals 11 and processes 12 designed to achieve these goals. Enterprises and enterprise branches, in general, have the following attributes with respect to goals: collective values, collective qualifications, collective knowledge, collective information, collective stamina, and collective emotions. One or more enterprises may relate to a subject area defined in the form of an industry, branch of a company, or any structure of an enterprise, where the process steps and terminology are specific, and at the same time, practitioners understand them. Thus, practitioners in this subject area can be said to have shared, specific knowledge.

[00085] Goals 11 may include the goals of the enterprise (often expressed at a high level so that specific processes are not related to them), the main goals (the achievement of which directly affects one or more goals of the enterprise), and conditional goals ( namely, goals that are not the main reason for designing the process, but failure to achieve them may impede the achievement of the main goal or, otherwise, may provide an opportunity to achieve the main goal, but make this achievement undesirable). Processes can be goal-based (in general, performed by agents in the enterprise to achieve the goal), non-goal-based, but prescribed and usually not projected by people, or non-goal-based, and non-prescribed and non-projected people. Processes include the function of machinery or any process designed by humans for human purposes, but not necessarily prescribed by humans. When performing various processes in an enterprise, dangers unexpectedly occur; problems and opportunities arise; these problems have causes, consequences, danger or potential consequences, and means.

[00086] Those parts of 13 processes where experience has shown that dangers, problems and / or opportunities may occur on their own, or unexpected or interesting events may occur, are called “enterprise stress points” or “process nodes”. Process nodes are often identified by experienced agents 15 within the enterprise. Overlay software 16, which in one embodiment is available to the enterprise as a service through the network 100, searches for the enterprise’s internal content and data 14, and, in some cases, also external data, yielding information that is indexed relative to the identified voltage points. Then, for the indexed information, the relevance of the stress points is assigned. Overlay searches are natural language searches based on process nodes in an enterprise and the language used to describe them. Overlay also searches for structured data that is known to be associated with each process node.

[00087] In general, a process can be either internal or external, or some combination thereof; moreover, the internal process is prescribed in the enterprise, and the external process takes place outside the enterprise; for example, designing, constructing, or training, and training activities that can be part of any process step, processes that are found to occur in an environment that are not designed to achieve known goals, but that affect the goals and processes of the enterprise, for example, discretionary human behavior, or processes not directly related to human behavior, such as environmental phenomena.

[00088] Process nodes

[00089] As schematically shown in FIG. 2, the process node 21 is characterized by one or more problems, capabilities, and / or unexpected / interesting events in the process or step of the process. The wording 22 describing the process node is used in the natural language search 23 of enterprise data and internal content 24 (and other information sources).

[00090] Process nodes for an enterprise are components of a cognitive structure (discussed further below). Process nodes, as part of the cognitive structure, contain discussion or descriptions of problems and / or opportunities and / or events that practitioners consider relevant for the goals and / or processes in the enterprise, or, sometimes, outside the direct activities of the enterprise. Such activities beyond the direct activities of the enterprise may be, but are not limited to, other enterprises; business world; political environment; social environment; physical environment; biological environment; or any environment that significantly affects the enterprise process.

[00091] Process nodes may also include variances for discussion and / or descriptions of potential problems or opportunities or events, as follows:

(a) A discussion and / or description or evidence of a problem or an opportunity or unexpected event to achieve one or more goals or conditional goals in a process that

(1) at the point in time of the discussion or description, or at a later point in time, was considered an ongoing process;

(2) forms a dependent process for the ongoing process;

(3) contains a problem or opportunity that may become active if the subordinate process fails;

(4) contains a problem or opportunity, and / or a potential problem or opportunity, in a subordinate process for the ongoing process.

(b) Discussion and / or description or data regarding:

(1) An explanation of the problem, possibility, or unexpected event;

(2) An analysis of the causes of the problem or opportunity or unexpected event;

(3) An analysis of the root cause (cause of cause) of the problem or possibility or unexpected event;

(4) A plan that is considered an action to eliminate a problem or seize an opportunity;

(5) A procedure that describes how to prevent a problem or how to seize an opportunity.

[00092] The discussions or descriptions associated with the process node may be in the text or in the figures, or may be any combination that forms the generally accepted indication used in enterprise software or content. This may include, but is not limited to, spreadsheets, emails, documents, metadata, data in databases, electronic messaging, voice communications, etc.

[00093] The cognitive structure discussed here is a structure having information indexed in a manner that complies with known cognitive principles, the cognitive principles being structured in such a way that they are related to each other in a manner that allows the relevance of the information to be determined.

[00094] As schematically shown in FIG. 3, the cognitive structure 33 is an abstraction of daily activities and related objects; these are activities and objects that are known to the average practitioner outside the domain of the enterprise, since they are used in daily activities in most subject areas. Such enterprise activities and facilities 32 include, but are not limited to: users, user roles, tasks, context options in which tasks and processes take place, enterprise objects, processes, goals, qualifications, relevance, agents in the process, or any generalization of this. This process node represents the components of the cognitive structure. All nodes and subjects in the cognitive structure may have abstractions and / or be abstractions of other subjects.

[00095] Thus, the cognitive structure 33 may include:

goals

goals and related processes, and corresponding characteristic nodes (described below);

enterprises, enterprise branches, and associated roles, agents, and attributes (e.g., qualifications, significance, etc.);

generalized process nodes;

specific nodes of the process;

lower level goals and related process steps;

the tasks and agents or roles that are assigned to them;

contexts and related processes or tasks that they affect;

the objects and related processes or tasks that they affect;

workflows; and

users.

[00096] Overlay software is also a means of finding information relevant to any process node or any element of cognitive structure. The information retrieval methods used by the Overlay software are applicable to this relevant information. These extraction methods also apply to most elements of the cognitive structure.

[00097] The term “relevant” includes, but is not limited to: related as a process endangered, as an additional process endangered, a causal process, an abstracted causal process, additional causal processes, corrective action processes, relevant as a similar process for any other process associated with a common context or object or their abstraction, associated with a common node or abstraction, associated with a common goal or condition purpose, or a combination thereof.

[00098] Information is irrelevant, for the purposes of Overlay, unless it is the primary means to provide a greater understanding of the problem, possibility or unexpected / interesting event.

[00099] The relevance of a content item or data for an enterprise can be fully determined by reference to enterprise stress points (process nodes), as explained in more detail below.

[000100] Process Analysis; process similarity

[000101] FIG. 4 is a schematic illustration of some of the goals and processes for an enterprise. In this illustration, a set of goals 41 for the entire enterprise has numerous processes designed to achieve these goals; one process 42 has steps 43. The shown enterprise is involved in the transportation of goods, including, but not limited to, transportation of goods by sea; thus, there is another set of goals 44 in the enterprise subject area related to “navigation”. In this example, the process 45 for navigating from one point to another has the following steps 46: seeing (for example, finding navigation aids), moving (for example, controlling the engine), and plotting to the desired location. As shown in more detail in FIG. 5, the process step for “seeing” includes the need for glasses; loss of points constitutes a problem for this stage of the process.

[000102] An enterprise in another subject area (for example, military training) with other purposes 47 (for example, firing a field gun) may, however, have some process steps similar to those of the navigation process 45. Goal group 47 includes the main goals (“shoot from the gun”, “hit the target”) and conditional goals (“dodge other objects”, “avoid the explosion”); the conditional goal “to avoid an explosion” must be achieved in such a way that the goal “to shoot from the gun” can be achieved in the necessary way. The process 48 for achieving the “shoot from the gun” goal includes a step 49 for “seeing the target." The type of activity “vision” can be considered as a generalized type of activity relevant for both processes. Additionally, the process 48 includes a step 50 for “adjusting the implement”. The process step for “tool setup” includes the need for a wrench; losing a wrench creates a problem for this process step. Loss of points and the loss of a wrench can be considered as examples of a generalized problem (namely, a generalized node), namely, “loss of tools”.

[000103] Some nodes and processes are indicated in FIG. 5 as context-specific or generalized. You can see that the processes in different subject areas, however, are connected by generalized processes and generalized nodes. In general, after identifying context-specific nodes, these context-specific nodes define more generalized nodes. These more generalized nodes, in turn, define the generalized components of context-specific / subject-specific processes for a given subject area. These generalized components of processes and their generalized nodes will exist in another subject area at the same level of generality and, thus, will point to specific nodes in this other context / subject area.

[000104] One process node may be similar to another process node; this is determined by the similarity of processes or process steps, which is explained in more detail here. As shown in FIG. 5, the process steps of different processes often have commonality. When a process step is common to two processes, the two processes are considered similar if the process step is similarly able to influence the main goal of the process to which it relates. The influence that the process step has on achieving the goal to which it relates is called “proximity to the goal” of this process step.

[000105] Overlay software finds cases similar to the problems and / or capabilities of a given process node by finding similar process nodes, and then indicating similar cases where the process and process node and proximity to the target are similar. In this regard, it should be noted that Overlay is not based on a very large array of process conditions for similar cases. Overlay evaluates the similarity of processes based on proximity to the goal and on the basis of the similarity of nodes and abstracted nodes or characteristic nodes. (Abstracted nodes or characteristic nodes provide an alternative way to define abstracted processes, because processes are designed to consider highly abstracted characteristic nodes at the most abstracted level). In this process, process conditions are contained within this process; finding such a process will thus determine comparable conditions. This is so because noticeable conditions are, in fact, embedded in the process nodes (problems and opportunities within the process). Then it follows that if the process nodes determine the criteria of the process, then they are also sufficient to determine the conditions within this process.

[000106] It should be noted that Overlay searches for similarities both in the processes and in the nodes contained therein. In general, processes are designed so that you can avoid problem nodes and use feature nodes. This process can have more than one node. Then it follows that the similarity of nodes is included in the similarity of processes.

[000107] Additionally, the hierarchy of goals in the process affects the determination of similarity. The hierarchy of goals and conditional goals in the process determines the profile of the goals of the process; this is considered an additional defining characteristic of process similarity. Processes that have a similar hierarchy of goals are likely to be similar. Thus, the similarity of processes depends not only on the general stages of the process or the general generalization of these stages of the process.

[000108] Proximity to the goal; probability of success

[000109] In general, not every process step is equally critical to successfully achieving the process goal. As noted above, the term "proximity to the goal" refers to the influence that a process step has on achieving the main goal of the process to which this step relates. The proximity to the goal of the process step can be quantified with respect to how close the process step is to success or failure in achieving the process goal (s) or conditional goals. For example, as shown in FIG. 6A, the achievement of the “shoot the gun” goal, as estimated, is 50% dependent on the completion of the “set up the gun” process step. Achievement of the “hit target” goal, as estimated, 70% depends on the completion of the “see target” stage of the process. These relationships are shown schematically at 61 and 62 in FIG. 6A. Then it follows that problems at the stages of the process with high proximity to the goal have an increased impact on the success of this process. Proximity to the goal provides an additional criterion for the similarity of processes; processes with similar attention to the goals of dependent processes, and processes that also have common generalized or specific characteristics (for example, common nodes) are considered similar, even if they occur in different subject areas.

[000110] An abundance of resources (or lack thereof) in a process is considered an attribute of the process steps within the process. Thus, the redundancy of resources affects the proximity to the goal of the process. In addition, the problem or opportunity at the process stage affects the proximity of the process stage to the goal according to the abundance of resources or redundancy of processes.

[000111] Agents (individuals performing the process or otherwise participating in it) also influence the success of the process. As schematically shown in FIG. 6B, agents primarily influence the process steps for which they are responsible. Agents, in general, have the following attributes: significance, qualifications, knowledge, information, stamina, and emotions. Depending on the steps in the process, other attributes of the agents may be considered relevant. Attributes, in turn, affect the likelihood of expected problems or opportunities related to the process step, and thus affect the purpose of the process. In the example shown in FIG. 6B, the agents 63 responsible for the “see the target” step have the qualifications, relevance and knowledge 64 that they use in relation to both the object (s) 65 involved in the process step and the context 66 in which the step is performed. If the object used in the “see target” stage is a surveillance device, and the context is fog, then qualifying agents to use a fog monitoring device to see the target will have a significant impact on success. From this example, we can see that the process steps themselves also have goals (“find a target using a surveillance device”), and the attributes of the agents influence these goals. In general, the process steps that agents perform, or which they significantly influence, have goals and conditional goals, and it is the goals and conditional goals of these stages, or their components, that are affected by the attributes of agents.

[000112] Generalized processes and nodes

[000113] Processes can be abstracted into generalized process groups; processes can belong to generalized groups, or processes can have generalized stages of processes. For example, navigating a ship may relate to the general process of “driving a vehicle or a ship”, and it may have generalized components such as vision, steering, planning, etc. Generalized processes are processes that are not specific to one subject area, and which practitioners with average knowledge in another subject area can recognize. In general, processes have generalized components or belong to large generalized processes.

[000114] Generalized processes are less context-specific processes in a given subject area. When they reach a higher level of abstraction, they contain less specific and more generalized nodes. The least context-specific processes can be so general that they will not have any specific steps, and thus, it may be difficult to identify them differently than through characteristic nodes (discussed in more detail below).

[000115] Generic processes can be represented schematically, as shown in FIG. 7A. The high-level goal set 71 has a set of auxiliary goals 72, which, in turn, has sets of auxiliary goals 73, 74. Processes 75 and 76 are configured to achieve goals 73, 74, respectively. The solid boundaries in the image of processes 75, 76 indicate that these processes are domain-specific processes; the dashed lines represent the generalized process 77 and the sub-steps 78 of the generalized process.

[000116] Generalized processes can have nodes, context options, and objects that are generalized on the basis of many processes of subject areas, of which they are parts, as was discovered by practitioners and an unlimited number of people. They can be shifted to one or more specific subject areas when they have fewer attributes than the number of attributes when considering all subject areas. This applies to (but not limited to) context options, objects, generic nodes, etc.

[000117] Process nodes may be schematically represented as shown in FIG. 7B. A node appears in each of the three stages of the process 700, and in two stages of the process 710. Each of the nodes 701-705 may be a danger, cause, effect or remedy associated with a problem / opportunity / event that occurs in connection with this process or some other process.

[000118] In the process 700 shown in FIG. 7B, each of the process steps 711-713 has proximity to a target relative to a target G1. There is also, separately, the likelihood of a process failure if the node is dangerous. These concepts are used to analyze process hazards. Unlike other methods of hazard analysis, in the Overlay software, danger is determined by proximity to the target and, separately, by probability assessment. As described above, proximity to the goal is the percentage assigned to the extent to which the success or failure of the subordinate process influenced the goal or conditional goal in the process. Proximity to the goal for processes of an equal level of subordination or dependence is additive to a total value of 1 or 100%. Each dependent process is dependent on the next lower level of processes with equally subordinate levels. For example, the control of the ship during navigation is 100% dependent on the driving force and steering. The driving force and steering are 100% dependent on electrical energy. At the level of the ship control process, there are other stages of the processes of equal subordination, for example, watch keeping, flight planning and personnel management.

[000119] Danger is assessed in relation to proximity to a target. When it is determined that a process node within a stage is a danger, the significance of this danger can be determined completely by referring to the proximity to the goal of this stage relative to its direct goal, proximity to the goal of this stage relative to additional dependent goals, the total cost of not achieving the goal, and the total cost of corrective actions in case of failure to achieve the goal.

[000120] Proximity to the goal is useful in evaluating the cost of a process and the cost of process control software. Proximity to causality, combined with probability, and the cost of failure or the revenue from success of influenced processes plus the cost of the corrective action process are quantitative indicators of danger or opportunity. Then it follows that processes performed with the ability to manage a hazard or use an opportunity have value for the company. It also follows that selling Overlay software to manage relevant information to reduce risk and take advantage of opportunities is significant. Overlay sets the right pointers to determine the significance of processes and their nodes, and thus to determine the significance of software that helps manage these processes by reducing risk and managing opportunity.

[000121] A hazard, or a potential opportunity, can be considered to be defined more qualitatively when relevant experience options are available in processes that are likely to be affected by the problem, determined by the proximity to the goal of the dependent processes. An additional quantitative assessment of the effect, danger or possibility is achieved by multiplying the proximity to the goal by the percentage probability of failure and opportunity in subordinate processes.

[000122] United processes

[000123] It should be noted that the nodes representing hazards, causes, consequences or means serve to connect the processes to each other. A simplified example of this is shown in FIG. 8.

[000124] The possibility or unexpected event 80, described in some context or shown by some data sample, has a danger, cause, effect and means associated with it. In general, not all of this danger, causes, consequences and means will be found in one process. The process 81 associated with the set 82 goals, is different from the processes 801, 802, which are associated with a set of 83 goals and sets 811, 812 auxiliary goals. All of these processes have nodes associated with problem / opportunity / event 80. In the example shown, nodes 85 indicate process steps in process 81 that are dangerous. The node 86 at some stage in the process 801 indicates the cause of the problem / opportunity / event, while the node 87 indicates its / its consequence at some stage in the process 802. The node 88, at another stage in the process 801, represents the means.

[000125] Specific Issues and Topics

[000126] As noted above, generic processes are less context-specific domain processes; when they reach a higher level of abstraction, they contain less specific and more generalized nodes.

[000127] Generic processes can be abstracted into types; the type of generalized process can be associated with a process at the level of a subject area and can be recognized by an experienced practitioner in a similar subject area. For example, movement is a type of generalized process other than personnel management. Some problems or opportunities, at various levels of abstraction, as experienced practitioners believe, are repeated in many related processes. Such problems / opportunities are called characteristic. Characteristic problems / opportunities are associated with goals, since problems and opportunities cannot be identified without first setting goals.

[000128] The type of generalized process is determined by its set of characteristic problems / capabilities. In the field of personnel management, for example, there are many characteristic problems related to personnel and opportunities dating back to antiquity, and a whole subject area of processes has grown that deals with these problems and opportunities. In addition, generalized high-level processes are determined by their characteristic nodes. In Overlay, generalized processes that contain generalized nodes, and / or additional generalizations, are also grouped under characteristic problems or opportunities. This is done because when processes become very general, their process steps also become very general, and the whole process becomes difficult to define, with the exception of a reference to specific problems or opportunities (usually called topics). In Overlay, generalized processes are defined by a set of abstracted characteristic problems or opportunities that they embody.

[000129] In assessing the similarity of processes, an additional similarity criterion is a characteristic problem (s) found in generalized processes or process steps. Two seemingly different stages of the process with some similarity of a very high level can be recognized as similar if they have the same expected problems or opportunities of an abstracted nature.

[000130] Typical problems or opportunities (themes) of a high level serve to organize characteristic problems of a lower level, more specific to a subject area, which, in turn, serve to organize an unlimited number of levels of characteristic problems in an unlimited number of subject areas. Typical problems or opportunities (topics) also organize high-level generalized processes, which, in turn, organize an unlimited number of lower-level generalized processes that are more specific to subject areas.

[000131] The words used to describe generalized processes are often abbreviations for a number of purposes and corresponding characteristic problems that may have too long a natural language expression. Thus, groups of characteristic problems at various levels of abstraction may have names associated with generalized processes at various levels of abstraction.

[000132] Objects and context options

[000133] As described above with reference to FIG. 6B, objects and context options alter the impact of nodes on process completion and goal achievement. Nodes can more or less likely to influence the process and its goals for different context options or objects. In some cases, the nodes of the process are different when the process is very specific to the subject area and has very specific context options and objects. The context and objects, in turn, are affected by agents and their attributes (or enterprises or branches of enterprises and their attributes). Thus, different agents will generally have different effects on the same process, due to differences in objects or context options. The context or object itself may have a greater or lesser likelihood of influencing the goal (s) of the process or the goal (s) of the dependent process.

[000134] Changes to objects and context affect both processes and proximity to the goal. Proximity to the goal varies according to the processes. But processes include objects and context options that can be different in different subject areas, while processes, on the contrary, can be very similar. Thus, for ease of adapting Overlay from the subject area to the subject area, Overlay combines the relationships between the context options of objects and their processes according to the subject area, so that in the new subject area the system identifies those objects and context options that are different and may require re-evaluating the proximity to the goal of each stage of the process, especially when such stages are affected by the difference in objects or context options. For ease of adaptation from the subject area to the subject area or from enterprise to enterprise, Overlay may also include the relationship between the context and objects and agents, users, and other elements of the cognitive structure.

[000135] Objects and context options can be generalized or broken down into components, and can have relationships among themselves. Objects and contexts relevant to the enterprise have generalizations and components, as well as relationships between them, which change according to the goals and corresponding processes or plans in which they play a role.

[000136] The system requires that the extent to which all or part of the attributes should be dynamically related to each other is based on the experience and requirements of each subject area, and on the client application of the system. When not all attributes are dynamically active, the default state is to maintain a continuous dynamic relationship of the attributes with the object that they usually affect. For example, when agent attributes are considered averaged for convenience, their influence on the likelihood of problems and opportunities arising at the process stage is neutral. In another example, when the redundancy of the resource used in the process step is averaged, the proximity of this process step to achieving the goal is averaged. The influence of attributes is averaged when experts in the processes under consideration consider them averaged for this subject area.

[000137] Objects and / or context options, as well as associated with the time of the appointment of simultaneous events, are used to determine whether, in fact, two indications of such an event are the same event. This is important when the purpose of finding relevant information is to find the content and data that is simultaneous with this event.

[000138] Hierarchy of goals and conflicts of goals

[000139] A study of the hierarchy of goals and conflicts between goals in a process is necessary to determine which stage of the subordinate process is more important in any circumstance. The more coherently the process is applied, the more coherent is the hierarchy of goals, and the more attention is paid to designing the process to prevent problems due to conflict of goals. When a process changes and becomes more similar to an action plan with new process steps and a new goal structure, the goal hierarchy and goal conflicts must be reinstalled, and new process steps must be applied to mitigate the negative effects of goal conflicts and inappropriate results, resulting in an insufficiently supported goal hierarchy .

[000140] Overlay relevance model: goals, processes, and nodes

[000141] It is useful, but not essential, to have a consistent relationship between goals, processes, and nodes (referred to as the relevance agreement here). If the relationships between the goals, processes, and nodes seem to be consistent with the Overlay users, but do not follow the agreement, then the relevance results (namely, cases from experience returned by the relevancy machine) may still be highly satisfactory, as current applications usually do not group goals, processes and nodes through any agreed agreement. The relevance agreement used according to one embodiment of the disclosure of the present invention is detailed below.

[000142] Attributes of nodes

[000143] The node attributes help to identify the nodes so that these nodes can be used to obtain similarities between processes and similarities between cases from experience. This is usually done only by expert users of the system. Node attributes can be grouped as follows:

[000144] (1) Goals and Agents: Goal conflicts can exist between agents that condition nodes and processes that are capable of overcoming these conflicts. For example, a legal contract is designed as a process to agree on how conflicts can be prevented or resolved; Machinery design is a process that overcomes the conflict between profit and cost of a machine product; A taximeter is an automation process that overcomes the conflict between the taxi service business and customer-related prices.

[000145] Goal conflicts can exist between goals of different agents and / or between main goals and conditional goals. An additional type of goal conflict may exist between the goal and the obstacles that exist in the environment, while the resources available in this environment contribute to the achievement of the goal. Resources and obstacles are context-specific and are affected by a specific conflict of goals. For example, the conflict between quality and value affects the quality and effectiveness of manufactured products; Each product has specific resources and obstacles that are affected by this conflict of goals. The traditional conflict of goals between quality and value, in production processes and production machine functions embodied in a product, has nodes associated with it. The nodes most closely associated with this conflict of goals are the causal nodes of any product malfunction. Conflicts of goals, therefore, are closely related to nodes in causal processes.

[000146] (2) Resources and hurdles: resources and hurdles are context and process specific elements that are most closely associated with each node. They are elements in processes that change according to context, and are also generalized into more generalized resources and obstacles when grouped into a suitable generalization of context. With reference again to the example of manufactured products and the internal conflict of goals between quality and cost, groups of similar products with a design commonality within the same context (e.g. hydraulic fluid pumps) will have similar problems, characterized by resources and obstacles that are affected . Additionally, due to design variations depending on the products in the same contextual groups, there will also be resources and obstacles associated with problem nodes that differ depending on the products. Moreover, in this case, the context structure should further divide the products into separate products, with individual specific problems and corresponding resources and obstacles. This means that the nodes of this particular contextual grouping are not generalized to all other context options. However, everything will be grouped according to the conflict of goals of quality and value. Thus, contextual groups are defined by resources and obstacles that are active in the active nodes of problems and opportunities. Some context options include more generalized nodes and provide easier generalization; some context options remain specific to very specific context options.

[000147] The relevance of resources and obstacles to a node is determined by the context structure. Nodes are a declaration of external obstacles to resources that can cause a problem or opportunity in the process. When nodes are not the result of conflicts between agents, but instead are the result of conflicts between the goals of the process and the resources and obstacles of the context in which the process takes place, relevant resources and obstacles are resources and obstacles that are active when the problem or opportunity is active.

[000148] (3) Causal nodes and affected nodes: causal nodes accompany the affected nodes and describe why the node is active as a problem or opportunity or event. Nodes that can be active in causal processes, as well as nodes that can be active in influenced processes, are used to identify the attributes of the nodes.

[000149] (4) The relationship between goal conflicts and causal nodes: goal conflicts that belong to the same abstracted group are caused by nodes with similar abstracted attributes, while the attributes of affected nodes can change more and not so easy to group without specialized knowledge of the subject area. A causal relationship between causal nodes and affected nodes is useful in linking nodes from one context-specific domain to another context-specific domain.

[000150] Expert User Process

[000151] Overlay expert users, when filling out the cognitive structure of the system, assign node attributes at various context-specific levels of abstraction. Overlay expert users then assign node attributes to higher-level abstractions. Computerized methods can also be used to model node attributes to assist expert users.

[000152] Identification of nodes

[000153] The following procedure (shown in FIG. 9) can be performed by expert user 920 to identify nodes at various levels of abstraction, according to the disclosure of the present invention.

(1) Identify nodes: Overlay expert users identify nodes found in a context-specific process whose similarity to other processes is determined (block 921);

(2) Identify the context associated with each node at various levels of abstraction (block 922). This is achieved through a (context-specific) process model of the subject area specific to the enterprise, the process in question and the processes that depend on it are analyzed in relation to the specificity of the context;

(3) Identify the attributes of the nodes of a lower context level (block 923): Overlay user experts identify the attributes of the nodes as described above as the attributes of the nodes 930: the attributes 931 include context-specific process goals and conditional goals; conflicts of purpose; context-specific resources and barriers; and context-specific causal relationships between nodes for a process whose similarity with respect to other processes is determined;

(4) Select from a set of abstracted attributes of nodes of a lower context level (step 924): in other words, select from a pre-filled set of attributes of nodes at the stage of abstracting the context above the level in steps 1-3. Overlay system 940 shows the user a selection of attributes of higher level nodes; the expert user selects higher-level attributes 932 to match the lower-level attributes of the nodes identified in step 3; and

(5) Select for a set of attributes of nodes of a higher or higher context level (step 925): The overlay shows a selection of attributes of nodes of an enterprise of a higher or highest context level. The expert user selects attributes of the highest level that are consistent with the attributes identified in step 3.

The above sequence of steps can be applied to the selection of nodes so that a similarity of processes can be identified, or it can be applied to a single node so that a similarity of nodes can be identified.

[000155] Processes and their relationships with nodes

[000156] The similarity of processes is identified by comparing the attributes of the nodes of a contextually specific process with the abstracted attributes of the nodes of a higher level. For example, a context-specific process, such as seeing a target in a military training exercise, has several nodes (for example, inability to see due to physical obstacles, inability to see due to poor lighting, inability to see due to a malfunction of the surveillance device, etc.). They, in turn, can be abstracted by Overlay experts in the abstraction of higher-level nodes (for example, inability to see due to obstacles, inability to see due to the atmosphere, inability to see due to loss of equipment to enhance vision). The new cluster of abstracted nodes produces a generalized process of a higher level, which is an abstraction of the specific process of target vision.

[000157] An abstraction can be performed to reconcile generalized higher-level processes with context-specific lower-level processes through node attributes, but in reverse, by using more generalized nodes and their attributes and linking them to context-specific nodes in another subject area. Thus, two processes in different subject areas or in similar subject areas, but with different context options, can be agreed upon with respect to similarity. This similarity, in turn, provides the opportunity to gain experience in one context-specific subject area to predict problems or opportunities in another context-specific subject area.

[000158] Identification of a similar process

[000159] The following procedure (shown in FIG. 10) can be performed by an expert user to identify processes in other subject areas that are similar to the original context-specific process 1070.

[000160] (1) According to this procedure, a generalized process is first identified, as follows:

A context-specific process in an enterprise is used with its context structure. The context structure is identified and consistent with the new subject area in which the process will be mapped (block 1071). This means that the selected context abstractions must be consistent across many subject areas, which are supposed to function in the same overlay system. Then, context-specific nodes are identified at the most specific level of context (block 1072). The attributes of 1082 nodes were assigned to these context-specific nodes by Overlay expert users using the specific method shown above. Nodes and node attributes are abstracted to higher contextual levels by an expert user Overlay (step 1073), to obtain a new cluster of abstracted nodes (step 1074). A new cluster of abstracted nodes generates a generalized process of a higher level (step 1075), which is an abstraction of the initial context-specific process.

[000161] A process that includes the largest number of source nodes abstracted to higher context options is a generalized process of the highest level associated with the source process. The generalized process is identified iteratively (steps 1076, 1075): a) by expert users who name this process and assign it to a set of generalized processes; b) expert users who agree on the nodes and attributes of the nodes, as described in the method described above, to verify that the process is unique and that a process with the same nodes and node attributes did not exist in the set of generalized processes; c) expert users who can break down the future generalized process into stages of the generalized process, apply the above process to the matching attributes of the nodes in these smaller component stages (with fewer nodes), and then build the process from its component stages into a larger generalized process. However, the layout of a larger generalized process from smaller processes limits the level of generality of the process, since it requires the presence of the same constituent steps. The methodology for assessing the commonality of smaller component stages is more appropriate when the stages cannot be easily changed, as in the functions of machinery and other more stringent processes. Starting with more complex processes with many component nodes is more suitable for planning where the process step has yet to be determined.

[000162] In other words, the level of detail of the process (to which the above methods are applied with respect to the attributes of nodes and their abstraction in higher-level processes) may vary according to the choice or focus of expert users. If the above methods are applied to lower-level subordinate processes (more detailed) within large processes, then similarity of processes can be used for higher-level processes by proximity to the goal and coordination of the number of subordinate processes. If the applied methods are applied to processes of a higher level (less detailed), then there may be similarities of processes obtained at higher levels, with less emphasis on the similarity of subordinate stages. Each method has different advantages. A more detailed method is better for comparing processes with similar steps and similar goals, a less detailed method is best for comparing processes with similar goals, but in different ways.

[000163] (2) Finding a similar process in many different contextually specific subject areas:

After identifying the generalized process of the highest level (step 1077), the expert user proceeds to find more context-specific processes, the abstraction of which this generalized process is. In general, a high-level process will be generalized to context-specific processes in other subject areas 1081.

[000164] To test which context-specific ones are most suitable, you need to find which context-specific processes contain the largest number of nodes that have the closest set of node attributes to the set of node attributes of the generalized process (step 1078). This is achieved by comparing the attributes of nodes at various levels of abstraction, starting from the highest.

[000165] (3) Apply proximity to the goal to compare the importance of common processes in each respective subject area (step 1079): this step is more important than the next step in examples where the influence of the process on the goals it serves is more important or more relevant to the similarity criterion. This similarity tests whether the new contextually specific process has proximity to its main goal and conditional goals, similar to proximity to the goal of the original process in a different context. This includes dependent processes that are potentially affected by nodes whose abstractions are common to contextually specific processes being compared. This happens before determining the similarity of the context, when the importance of the process should be similar for the compared processes.

[000166] (4) Apply the node attribute test (step 1080) to find the context / object cluster that is most sensitive to the selected nodes. This requires knowledge of the actions of such a context and objects in subject areas (usually in a much narrower range of subject areas) in order to establish sensitivity to selected nodes. This step is more important than the previous step, in examples where context-specific obstacles and resources are more important as the focal point of relevance, and also in cases where the similarities in the context of the nodes of a particular case are more important than the similarities of the process. In other words, the choice of nodes is narrower and does not fully correspond to the nodes of a wide process, but can group more processes and context options with a common node of interest. For example, most machinery failures have case nodes that apply to specific machines that may be sensitive to the same failure using design, manufacturing, and operational criteria. To find these other machines, the number of nodes selected in the selected generalized process should be reduced, and the expert user should coordinate the attributes of the nodes based on the knowledge of these other machines and their sensitivities.

[000167] It should be noted that in practice, finding such single nodes by context / subject areas is exactly as important as finding clusters of similar nodes. In one embodiment, this problem can be solved by identifying the first and second context options for the node. The node is specific to the first context variant, so that the node is characterized as the first context specific node. The second variant of the content is at a higher level of abstraction than the first variant of the content, so this node is not specific to the second variant of the context. Then, there will be two sets of node attributes associated with the node, according to the first and second context options, respectively. Then, at least one generalized node can be identified, and this generalized node has attributes according to the attributes of the nodes of the enterprise high context level.

[000168] Filling the system with cases

[000169] FIG. 11 schematically shows a procedure 1180 for filling the system with cases (thus, solving problems or using opportunities using Overlay, while ensuring the availability of the collective experience of the enterprise). The user fills the system by entering the process, nodes, goals and proximity of goals (step 1181). They can be introduced using the experience of industry practitioners. Cases 1186 are entered using the assistance of indexing engine 1187 to index stories 1185 told by experts and / or recorded in the enterprise. Knots are problems and opportunities declared in discussions regarding the causes, consequences, means, and explanations found in cases (narrated stories). In this exercise, context-specific processes, context options, goals, causes, effects, and proximity of goals are established.

[000170] Process abstraction: cross-contextual similarity

[000171] In the second stage of filling the system, Overlay expert users apply process summaries and node summaries (step 1182) to provide non-expert users with the ability to locate similar processes among subject areas and context options. Experts using the indexing assistance from Overlay can reconcile nodes through their attributes to obtain process commonality and process similarities (block 1183).

[000172] Overlay method steps

[000173] FIG. 12 is a flowchart showing how the Overlay system finds problems in an enterprise and provides users with relevant versions of prior experience; namely, lessons learned from previous dangers, causes, effects, and remedies (also called stories).

[000174] The method performed by Overlay focuses on creating an infrastructure of voltage points of the enterprise. The objectives of the enterprise (the objectives of the enterprise and the main goals mentioned above) are set at step 901. Various processes performed to achieve these goals are set at step 902. The result of the processes (proximity to the goal) is set at step 903. At step 904, problems are identified , process related capabilities and events. At step 905, an enterprise stress point infrastructure is created, according to: process descriptions; problems, opportunities, and events that affect processes; reasons, consequences, dangers and means; and according to how processes influence each other.

[000175] It should be noted that this infrastructure development includes the identification of such processes. As described above, this includes identifying common process steps and / or applying other criteria to different processes.

[000176] Processes are analyzed to identify generalizations of processes and, thus, to identify generalized processes (step 906). At step 907, the generic nodes and characteristic topics are identified based on the processes. The internal content of the enterprise and the data of the enterprise are viewed, and the viewed content is indexed relative to the voltage points of the enterprise using the indexing machine (step 908). The system determines the impact of this problem on this process, and sends a description of the problem to users who are most associated with the problem (steps 909-910). The system starts structuring cooperation options according to the infrastructure of stress points, focusing user cooperation options on key points affected by the problem, the causes of the problem, and means of solving the problem (step 911). From the indexed information, the system extracts relevant prior experience and returns these relevant stories to users (block 912).

[000177] Solving problems using Overlay

[000178] A method for solving a problem (alternatively, using an opportunity, making a decision, or answering a question) using the Overlay system, from the user's point of view, is shown in the connected flowcharts of the operational sequences shown in FIG. 13A and 13B.

[000179] It should be noted that the method described here is iterative, and the order of steps depends on how close the problem or opportunity is to the previous problem or opportunity, and how well it was possible to manage the problem or opportunity in a known process. If the problem or opportunity is not well known, and the process by which it can be fixed is not well established, then the order of steps and emphasis is different from the order of steps and emphasis described here.

[000180] A user dealing with a problem (or opportunity, solution or question) 1001 first draws up a preliminary plan in his or her mind regarding the problem to be solved (step 1010); a plan is developed outside the system. The corresponding action of the system is to allow the user to select several generalized processes that the plan organizes. These processes can be returned in a variety of ways by including a set of auxiliary word searches using pre-configured searches for generalized processes or goals; in other words, to provide a search for an initial concept based on cognitive structure. Usually a narrower range of process selection is needed that provides more specific processes than the range of process selection returned by the search for targets, a narrower range of process selection than the range of process selection returned by the search for generic processes, and a wider range of process selection than the range of process selection, returned by the search for specific processes.

[000181] In step 1011, the user selects a narrower set of processes, and then, the user selects goals corresponding to the processes returned by the system, and the system creates the original hierarchy of goals (step 1021). The hierarchy of goals is modified (step 1012; system action at step 1022), taking into account the agents involved in the processes, and taking into account how their goals affect the hierarchy and how the selected goals conflict with each other. The fewer processes are selected (which, in turn, depends on how well known or established the problem or opportunity is, and how well the process of corrective action is known or established), the more likely that the conflicts of goals and the hierarchy of goals will be the same as in the selected process.

[000182] At step 1013, the user retrieves the characteristic nodes within the selected processes (namely, processes selected in the intended plan). The corresponding systemic action (block 1023) is to extract characteristic problems for a set of processes. The user identifies related processes that use common problems; the system selects additional processes that are known to be associated with identified characteristic nodes (steps 1014-1024). Then, the user selects stories and experience options based on the selected processes, which are organized according to the problems / capabilities of the processes and characteristic problems / capabilities. Stories are retrieved by finding a relevant group of processes according to the commonality of nodes and proximity to the goal for related processes (steps 1015-1025).

[000183] When a user collects past experiences and recalls his or her own experiences from stories through stories (content or data related to problems, opportunities, and interesting / unexpected events), the system helps the user reconfigure his goals and goal hierarchy and highlight goal conflicts , to enable extraction of the processes that are best suited to the resulting hierarchy of goals and goal conflicts (steps 1016, 1026).

[000184] Using the returned stories, the user formulates and tests the preliminary decision (step 1017). Then, the user selects additional processes, modifies the intended plan, and tests the modified plan (steps 1018, 1019). The plan is not necessarily stored in the system, in addition to its description when discussing with colleagues a common discussion document that Overlay can handle. The plan can be saved, if preferred; for example, if experience is considered useful for future reference, especially if the plan has a hierarchy of goals, which, in some circumstances, is better than the standard process that it replaces. The extracted stories help the user develop the best possible plan using the collective experience of the participants. Overlay helps to extract past experiences through stories and helps coordinate the proper participants in the discussion.

[000185] Overlay system

[000186] A system for executing an Overlay includes an indexing structure (or indexing machine) that determines how to achieve relevance between nodes or stress points of an enterprise. The indexing structure contains word patterns and data patterns, including business objects relevant to nodes or stress points of the enterprise. The system also includes a language parser and viewers, which are used to view existing or new content and assign this content to process nodes. The indexing structure of the Overlay system helps users find information relevant to enterprise stress points more efficiently than using conventional search engines.

[000187] It should be noted that the relevance of content in an enterprise is determined solely by considering process nodes. The user defines a cognitive structure for performing indexing; critical criteria for relevance are defined within the cognitive indexing structure.

[000188] An implementation of the Overlay software tool, according to one embodiment of the disclosure of the present invention, is shown schematically in FIG. 14. Overlay includes means 1101 for viewing content for viewing enterprise content and enterprise data and related external data, as well as business objects; language parser 1120; and an indexing machine 1150. Viewers get content from multiple sources; for example, emails 1102, documents 1103, application data, including business objects 1104, and web content 1105. The language parser 1120 identifies concepts within the viewed content 1110 and interacts with the indexing machine 1150 to assign relevance to stress points for these concepts. In the case of application data, the relevance of stress points is preconfigured so that Overlay searches for specific data at specific locations within the application. The resulting stress point index 1160 supports a number of user interfaces 1170. The user interfaces use the stress point index to alert users of problems, enable collaboration between users, limit the information returned to processes for which users are participants (even if the information is directly related only with subordinate processes for which they are not participants); and extracting relevant options from prior experience. In the embodiment shown, user interfaces include a search web interface 1171, a collaboration web tool 1172, a portal interface 1173 for combining applications, a mobile device interface 1174 for alerts, collaboration, and searches relevant to the problem, and a interface 1175 for combining stress point index with one or more required office applications.

[000189] The indexing machine indexes information regarding enterprise stress points using the indexing model 1130. An indexing model is created using stories of 1106 cases (stories of how the company acted in relation to stress points in the past) and current cases of solving 1107 problems in the company. Thus, both current and past cases are used to populate the system. Analysis of current cases creates indexing for a case relative to cognitive structure. Past cases can be introduced as options for experience where a separate process is indirectly part of the solution to an enterprise problem.

[000190] In addition, when populating the system, the indexing engine provides cross-contextual links; this makes it possible to fill the system with options for experience and verbal concepts related to content in new subject areas by using the generalized aspect of processes and generalized nodes from previously filled subject areas. Context-specific nodes define more generalized nodes. These more generalized nodes, in turn, define the generalized components of context-specific / problem-specific processes. These components of generalized processes and their generalized nodes will exist in a new subject area at a certain level of generality and, thus, will point to specific nodes in this other context / problem area.

[000191] The indexing machine may provide indexing services for other software products, including third party products, such as: content management systems; search solution products; ERP systems; or any other systems that might benefit from the addition of stress point relevance software.

[000192] [0209] In one embodiment, the indexing machine 1150, which is the core of Overlay, is a cross-platform software service provided through web services.

[000193] [0210] The system, according to the disclosure of the present invention, can be used for:

Identification of content relevant to sites

providing an understanding of the enterprise by establishing a connection of nodes with each other in a cognitive structure;

problem solving in the enterprise; and

finding random information in the enterprise.

[000194] Some of the benefits of using the Overlay system are as follows:

evaluate the similarity of processes between two compared processes;

Describe processes and plans relevant to the enterprise

find relevant information about problems and opportunities;

find random information (unaccepted notices) about problems and opportunities;

assess the dangers and consequences of problems and opportunities;

anticipate challenges and opportunities;

diagnose problems and opportunities;

apply corrective action plans to problems and opportunities;

create strategic plans for challenges and opportunities;

give users an idea of the causes and consequences in the industry;

allow users to be creative when dealing with problems and opportunities;

help users to explain the complex phenomena associated with the actions of the enterprise or the environment in which the company operates, and which significantly affects the company;

help experts helping companies solve problems or take into account opportunities for this company; and

find the relationship between the elements of the cognitive structure based on the types of activities of the enterprise.

[000195] For example, at the factory level, system users typically include managers, sales workers, administrative assistants, engineers and maintenance personnel who have specific functions and individual goals and a generalized goal of delivering the product to consumers. Many of these users access the enterprise model through a portable device, such as a cell phone, tablet, or other personal electronic device (PED). Often these portable devices have a user interface (viewing screen with touch screen capabilities) having a limited area. When presenting the complete structure of enterprise nodes on the viewing screen, the nodes may be too small for the user to view or to access by touching the node of interest. Thus, the system is configured to demonstrate only the nodes of interest to individual users and, optionally, several additional nodes on either side of the nodes of interest. When the goals of a particular user change, the nodes of interest shown on this user viewing screen usually change as well.

[000196] With reference to FIG. 16, system 1200 includes a module 1202 that configures a plurality of user interfaces 1204a through 1204e to reflect each user's relevant current state with respect to a real event. This means representing to each user only parts of an interconnected set of nodes 1206, filtered by the context associated with this user and the current state of that user. Each user interface 1204a through 1204e has a display device 1208a through 1208e having a limited viewing area. When all nodes 1206 are displayed in a restricted viewing area 1208a through 1208e, the nodes may be too small for the user to view or interact with. Also, the current state for the user may vary, and system 1200 may need to change the display device on which the user interface 1204 resides to provide more space for viewing information relevant to the last current state. However, since all nodes 1206 are connected using cause and effect and similarity, the user can return, if necessary, to view any nodes assigned to participate.

[000197] Module 1202 customizes the user interface to focus on nodes 1206 most relevant to the user / participant, and can change the set of nodes most relevant to the user / participant, according to situational developments relevant to the user / participant. The system can change the appearance of the user interface 1024a - 1204e to provide more space for viewing information relevant to the last state relevant to the user / participant. However, at the discretion of the user, all nodes relevant to the user may be accessible regardless of the current focus shown on the screen.

[000198] Module 1202 communicates with a number of external devices to ensure that the information contained in and accessible through nodes 1206 is up-to-date and each user's situation is up-to-date. One external device may be a keyboard 1210. The second external device may be a remote sensor 1212, such as a temperature or light detector for detecting a fire, or a humidity detector for detecting a leaking or burst pipe. Module 1202 may also remain in contact with remote sites 1214 via the Internet 1216. Such remote sites may include, without limitation, other business units, external databases (eg, a public facility to access building plans or circuit diagrams) , publicly accessible databases (e.g. search engines) and private databases (e.g. diagrams for a ship or item of equipment provided by the author / manufacturer).

[000199] Module 1202 includes a computing device 1218 having a computer-readable medium with executable instructions encoded in a non-transitory digital storage medium, wherein the non-temporary digital storage medium also stores an enterprise model, enterprise content and enterprise data, the processes associated with the model include nodes, a machine-readable description of relevance between different nodes, and a machine-readable description of relevance between content and data and different nodes.

[000200] Module 1202 is capable of communicating with each user through a transmitting device 1220. The transmitting device both sends and receives information from each user through a user interface 1204a through 1204e. Any form of communication can be used, for example, cellular network 1222, wireless local area network or the Internet 1216a. It is useful to specify nodes 1206 not only based on changes in the underlying information in the database, but also by directly entering user data into the user interface 1204a through 1204e controlled by Overlay. This will, nevertheless, be interpreted as information in a database or other computerized module to be processed by viewers, etc., but this information will be entered through a user interface controlled by Overlay. This information may be a simple selection of the node 1206 reproduced in the user interface, or a choice, from the user’s choice, of specific actions associated with the node 1206 and / or the content entered by the user. Some information, such as images or videos, may be made available by means 1202 on portable devices display devices 1208a through 1208e or via portable devices. The user-specific action can be entered by the user into the module 1202 through the transmission means 1220, 1216 and the computing device 2018.

[000201] The user interface 1204, the structure of the interconnected nodes 1206, and the data in the database 1224 exist in the form of a single middleware service. This cross-platform software service provides the ability to modify logic / code and modify the database 1224 and modify the nodes 1206 without the need for any software changes for the user interface 1204.

[000202] Overlay combines a set of interconnected nodes that are connected using cause and effect and similarity. Cause and effect can also be determined through formulas and relationships between characteristics associated with nodes. In conventional programming, changes provide for relationships and for data representing problems and opportunities. After these changes are implemented, new user interfaces must be designed to present these new relationships to users. The present embodiment bypasses the second programming exercise.

[000203] The coded relationship 1226 between nodes 1206 can be explicit, and if all nodes are connected to other nodes through code / programming logic that describes cause and effect and derived causes and effects, then changes in nodes and formulas connecting them, code / programming logic can also be provided without changing the relationship of information reproduced on user interfaces 1204 in a separate exercise. System 1200 creates a database 1224, where each data increment is associated with at least one node 1206, and the relevance of one node 1206 to another node 1206 ′ is described by code / logic that links one node to another. Nodes are connected to each other through application code / logic that describes cause and effect and derived causes and effects. Data from the database 1224 relevant to each node 1206, 1206 'can be displayed on the display device 1208 with a limited display area of the user interface 1204 in groups corresponding to nodes that are directly connected to each other. These nodes are connected with each other by cause and effect and by derivatives of cause and effect.

[000204] The user interface is a continuous environment that is not software designed for the use case in question. The prior art user interfaces are configured to select fixed predetermined use cases. For example, it could be a user interface for determining the exit route from a burning building by providing a fixed selection of navigation options. Another user interface might be needed to exit the building plus an embedded emergency, such as a broken leg. Another user interface might be needed for the coordinator, who monitors the status of the location of the evacuees. Overlay's user interface picks up all use cases, including future unforeseen use cases, because the user interface is derived from a continuous node structure that contains the system logic and accommodates future logic. In addition, since the logic of the system and the state of each attribute of the system are described through a causal relationship between nodes and these nodes, respectively, there are only two variables for description; node and communication with another node. This can be described graphically in a topographic map similar to a vector map. But the provision of this topographic description, due to the presence of only two variables, a node plus connections with another node, plus the ability to expand or retract descendant nodes under the parent nodes, while increasing and decreasing the number of nodes, can be shown on the user interface, which allows the user to combine situational awareness when reducing the image and focusing on a particular node and related information when enlarging the image. At present, there is no user interface describing any group of processes, regardless of whether these processes are sequential or not, and regardless of how they are connected to each other, and regardless of how many processes are described, which is graphic and which allows navigation based on the selection of thousands of nodes to focus on any of the lowest nodes in the subordination and any choice of nodes between these extremes, and when doing this in a continuous description.

[000205] Although a view that users may want to see in the zoom mode may become a view of the attributes of nodes and links, rather than nodes and links between the nodes themselves, these attributes are nevertheless generated dynamically by nodes and links to which focus is applied. There is no programmatic generation of attributes to view. Node attributes in the part interface are generated dynamically.

[000206] This contrasts with the prior art enterprise process describing the User Interface Software, which requires each user interface to be detailed, or otherwise defined, and then programmatically generated. One example in existing software systems that do not describe enterprise processes but are continuous is electronic cards. Electronic cards can increase or decrease focus by enlarging or decreasing the image. But there is no way to represent processes in this way, since the map view is not used to describe processes and the relationships between processes, but is used to describe positions and distances in two dimensions. In Overlay, in contrast, space is used to describe cause-effect relationships and processes. In other words, nodes describe problems and opportunities, and relationships describe the cause and effect that links nodes, and space is used to indicate subordination or dependence. A noticeable feature that provides this is the fact that processes and representative nodes converge, namely, the descendant nodes are drawn into the parent nodes and, thus, fit into each other when the image is reduced. Flowcharts and similar process diagrams are used to describe processes, from detailed processes to large enterprise systems. But flowcharts describe sequential processes and decision points that do not fit together to enable image reduction.

[000207] Process sequences are often too detailed to define all process relationships in practice. How, for example, do you determine how audit failure affects corporate reputation, in successive stages? And at the same time, is consistency important, or is cause and effect important. How does a skew ball bearing affect the structural integrity of the machine? How can the flowchart describe this? The relationship between two processes that are not connected in series can be established in the flowchart, but this relationship is no longer a description of the process flow and cannot be described as a component of a flowchart.

[000208] Other hybrid process descriptions can be created based on a two-dimensional UI format, but they do not contain explicit cause-effect relationships between nodes, which are also machine-readable nodes and process nodes, which also converge and, in a graphical description, fit into each other to provide the possibility of reducing the image, and also fully describe the relationship of one problem or process capability with another, as required by the context of the description system for which they were designed.

[000209] In other words, prior art hybrid flowcharts attempt to describe process relationships, not just a process flow, but cannot provide nodes that converge so that the part processes can converge in the parent processes with explicit and full causal relevance between nodes, which is machine-readable and thus can be processed by a computer. Thus, when describing the interconnected enterprise processes in the user interface, these hybrid flowcharts of the prior art may show processes, but not the degree of relevance between the processes, sufficient to ensure convergence. This is because nodes do not converge, and relevance is often vague, or, in some cases, statistically determined by user groups. On the contrary, in Overlay, causal relationships are described either empirically by being close to the target, or by means of an algorithm, in cases of more explicit quantitative relationships, as mentioned here. Both proximity to the goal and relevance algorithms describing cause and effect are machine readable and able to describe the importance of the relationship. Statistically described relationships are machine-readable, but they are not necessarily accurate, especially when the results aggregate causal relationships that may not be sufficiently independent, statistical samples aggregate the results for completely different reasons, thus making the cause and effect unclear, or statistical samples are insufficient for significant statistically relevant relevance.

[000210] For example, ship collisions that are statistically analyzed and assigned to human factors, such as human errors, are not significant enough, because every technical aspect of shipping, which can also be the cause of a collision, for example, a steering failure, also includes human factors, for example, in machine design, manufacturing, maintenance, operational complexity, etc. In case of vague relationships or statistically related nodes, as in the prior art, the user interface may be disordered by vague or statistically derived relationships between nodes. In an emergency, for example, this relationship can cause confusion and, as a result, make the whole computerized emergency response application meaningless, which consists in providing relevant information with minimal distraction.

[000211] In another prior art graphical two-dimensional description method used for formal hazard assessments, commonly referred to as “butterfly” diagrams, the relevance between “failure or risk modes” and processes is described in statistical probability and “significance” compounds between nodes. But, since there are “failure modes or risks” and “processes” and “goals” and the relationships between them, as well as, often, “conditions” and other variables, the elements do not converge. “Danger”, “risk”, “barrier”, “sequence”, etc., do not converge the way process nodes in Overlay converge. In an emergency, such a generally accepted description in the form of a “butterfly” will not, for example, show the whole situation. It may represent the nodes of failure and risks, but what if the user wants to see other processes that are affected by the risks described in the diagram in the form of a butterfly, or other contributing factors for the consequences in the diagram in the form of a butterfly, or other processes, to focus on them. How can they be connected? A “butterfly” chart only shows, at best, a set of influenced processes and causal risks plus logical derivatives associated with one process or risk that is in focus. There is no idea how all the processes in the enterprise are connected. Thus, in case of emergency, if the user needs to look at another process with his or her participation, or if the system helps to focus on the last event, then this may not be possible without reproducing another graphic description that is different from the previous graphic description and not continuous. Thus, the graphic description will not be continuous and cannot be used to enlarge the image and reduce the image. This, in turn, makes it impossible to describe any process in the system and any future process without first designing a user interface for each process or use case or user / system interaction point.

[000212] Thus, the prior art system cannot dynamically generate user interface descriptions for any process or group of processes emulated in the system, or for the current process or group, or for a future process or group.

[000213] The foregoing is in part used to explain the following:

[000214] Improving or replacing underlying enterprise applications using Overlay principles:

[000215] One way to improve understanding of an enterprise’s actions is to reduce the time period needed to improve and, unsystematically, replace the underlying enterprise systems with their role as information sources for hosting event triggers regarding problems and opportunities, interesting or unexpected events, or missing important control elements, as well as relevant information that improves user decision making.

[000216] The reason for improving or replacing these underlying enterprise applications is that often these systems are outdated and irrelevant, or poorly designed in terms of ergonomics, and therefore they are rarely updated on time to provide proper triggers and relevant information for effective Overlay functioning.

[000217] In order for Overlay to replace these enterprise applications without very much effort in creating applications, for example, to ensure that legacy code is understood or to support legacy code or to improve legacy code, there is a need to use Overlay’s main innovation to improve or replace legacy ones systems. In other words, to ensure the creation of additional enterprise information systems, if necessary.

[000218] An important goal is to ensure the completeness or possibility of creating these systems without the need to resort to traditional methods of software development, thus, experts in the subject field of business, in other words, participants and experts in the subject field, are given the opportunity to create these systems with lesser requirements than the requirements in traditional ways of creating applications. This significantly increases the likelihood that the resulting system will be effective, and also increases the speed with which systems can be created and adapted in such a way that they meet new and emerging requirements.

[000219] The behavior of Overlay-based systems is partially controlled by the node structure, and partially controlled by traditional data structures within the underlying enterprise applications. Those aspects of the system that are controlled by the structure of nodes, which, in general, relate to system navigation and the relationships between nodes, in other words, to finding information about relevance for a user in an enterprise, are very flexible. Those aspects of the system that are managed by traditional code within the underlying applications that, in general, require the creation and interaction with business objects, remain complex and expensive to change, and cannot easily use the developing business model defined by experts in the subject area. This latter situation means that Overlay systems remain vulnerable to the quality and relevance of the underlying legacy applications.

[000220] The next section discloses an embodiment of the Overlay concept, which is the elimination of the need for traditional code and, thus, a vision of the entire system behavior driven by the newly expanded node structure. At the concept level, the business model thus becomes the application code. This will provide Overlay Systems with the ability to meet the goals outlined above.

[000221] In the prior art and in legacy systems, a business object acts as an “indivisible unit” that a business model can manage — that is, move between transactional tasks, access through navigation filters, etc. . These business objects, in general, are convenient data packets — sets of related attributes that model an object or concept in the real world, such as a person or a document. It is these business objects that are currently implemented using traditional code. These business objects contain attributes and relationships with other objects derived from many use cases. This is similar to a home repair tool with accessories for many types of home repair work. However, due to the multiplicity of options for using business objects, which is many orders of magnitude greater than the multiplicity of options for using tools for home repair, and is almost as great as the multiplicity of options for using modern smartphones and computers, a description of the attributes and relationships with other business objects is too difficult and difficult for designers to imagine and manage.

[000222] For example, the placement of attributes in business objects means the fact that these attributes and their values are usually determined by complex underlying processes and are subject to rules and restrictions that extend beyond the enterprise (and indeed to other enterprises), which software engineers are usually not aware of when the system is being developed.

[000223] For example, take a simple linear element of an order for the supply of spare parts:

[000224] Part number: The part description is the result of a complex process that probably traces its roots back to the original manufacturing process.

[000225] Quantity required: it can be determined through a complex set of conditions, including the condition of the machinery for which the item is intended, upcoming maintenance, availability of time, labor, cash, and other resources.

[000226] The timing requirement is again, this may relate to resource availability, equipment availability, how and when equipment will be used.

[000227] Planned delivery date - this may relate to the availability of supplier personnel to prepare the item for delivery, which, in turn, relates to the personnel and professional requirements for the personnel in question.

[000228] In short, a simple business object of a linear element of a purchase order can traditionally capture only a part of the aforementioned - however, displaying the aforementioned in a complex causal structure of nodes is essential to provide an effective system for supporting business processes - a system which will facilitate effective decision making and will be easily extensible by expanding the structure of nodes.

[000229] The problem is especially acute when a “perfect” business process cannot be executed — that is, when handling exceptional cases. For example, if the spare part cannot be delivered on time, the actions that need to be taken may depend on very complex information, for example, on the predicted reliability of the equipment, which can allow you to assess hazards and facilitate the actions taken.

[000230] In addition to this, there is a very general scenario for the implementation of business objects that hardly meet the requirements of different enterprises, which usually, as a rule, have different interpretations and patterns of use in relation to them. Implementations of business objects effectively encapsulate business logic, which should be in the model, and should not be in the code, and are rarely designed so that this logic is exposed to the business model so that the model can control how the business object leads yourself.

[000231] Thus, the central principle is to remove the concept of a business object as a fixed concept and, instead, select an attribute as a more detailed unit of indivisibility. As a result, it provides a new and highly dynamic type of data type, based on the structure of nodes interconnected through explicitly described machine-readable cause and effect or derivatives or variable cause and effect declared in machine-readable logic, which will replace the concept of a business object, a separate transformation logic and separate user interface logic, which has become a sign of existing prior art systems.

[000232] An additional principle of this evolution of the Overlay / TA system is the explicit union of the process model, in the form of a declaration of the interconnected structure of nodes, with a data model defined as attributes. It is this combination of data with interconnected nodes connected as a cause and effect that clearly shows what the data is intended for and how it is transformed, which is central to the ability of the system to host significant machine-readable logic of transformations and significant attributes of user interfaces without special programming skills. This is in contrast to traditional data structures, such as relational databases, which do not give an explicit idea of what the data is intended for (i.e., the goals they support) and, in essence, do not have the permission necessary to obtain suitable user interface. Traditionally, this information, which is embedded and thus hidden and fixed within the code, needs to be made explicit within the model so that experts in real-world processes and computerized transactional processes can understand all computerized processes within the enterprise application and expand them when necessary.

[000233] Unlike other databases with a non-SQL node structure, Overlay’s unique concept in creating or expanding enterprise applications is that all the transformation logic is within the cause-effect relationships between nodes, and no other logic is required to influence either application transforms or user interface attributes. There may be logic outside the node structure necessary for ancillary services, but none of the enterprise business logic or the presentation of user interface attributes should be outside the node structure.

[000234] Modern information systems may, in general, look like a certain number of levels, each of which performs a specific type of function and provides services for adjacent levels, and the Overlay / TA concept is no exception. The next-generation Overlay / TA concept has three levels outlined below:

[000235] The user interface level. This level reproduces the interface for system users and is completely derived from the business model.

[000236] The level of business logic or the "middle" level. This level defines the idea of how the system should support the user and the organization in their desire to achieve their goals. It consists of a business model implemented within the implementation infrastructure, which is Overlay.

[000237] The data management layer. This level provides storage of status information and, again, is fully derived from the business model.

Business logic level

[000238] As stated above, this level consists of two main elements: a business model and an implementation infrastructure within which this business model is executed. A business model is created and managed by non-software engineers, which means that knowledge of traditional programming languages and database systems is not required. The business model, therefore, will determine everything necessary to obtain a meaningful information system, i.e., an information system that supports the organization in achieving its goals. Thus, supporting the definition of a model, which is easily understood by people who are not technical specialists, and at the same time remains unambiguous enough to handle the underlying infrastructure of implementation, nevertheless provides a predictable, meaningful, and useful end result, is a key issue. .

[000239] The heart of the Overlay business model is the node — the stress point of the enterprise where the human operator, or alternatively a sensor or other system agent, must make a decision and provide data input, ie, a change in state, or where the user must get information about anything from the system. At a high level, the set of these nodes determines the model of the organization process, which, when combined with the underlying state model, should provide sufficient information to obtain user interfaces based on it, necessary to support each point of the enterprise voltage. Elements of the process model can be mapped for abstractions of a higher-level generalized process in the main process model. We will not now describe each of the components in more detail.

Business Logic Level: Process Model

[000240] A process model is defined as an interconnected set of nodes. Each node has a set of attributes that are entered into or deduced from the node. Nodes are mainly associated with other nodes as a cause and effect, although other types of relationships also exist and are described below.

[000241] A causal relationship between nodes means that an action that is explicitly or implicitly the result of data input or existence can be initiated by a user or another agent as part of a causal node that will trigger a change in state, which, in turn, will reproduce the node under the influence as “interesting”. The "code" of the system, which is associated with an action, which, in turn, is associated with a causal relationship between nodes, thus focuses on the implementation of changes in the state as a result of the initiation of actions.

[000242] A node is associated with a set of attributes that are associated with nodes within the "node cluster" of this node. A node cluster is a collection of related nodes, usually connected by a process, as well as for other reasons, and is clearly determined by the subject matter expert creating the model. Within each node, attributes are assigned either as input (read-only) or output (read-write). A set of attributes for a node may be called a “predicative pattern” for that node.

[000243] Nodes essentially have no states, which means that they consume and produce attribute classes. In other words, there is no concept of specifying a node. Instead, nodes become interesting as a result of the state of the entered attributes for these nodes. For example, the “Estimate supply and transportation options” node becomes interesting when there is a noticeable need for a ship that needs to be met. This change in state is usually the result of initiating an action associated with the causal node.

[000244] Nodes can also be associated with other nodes belonging to the same subject area — that is, as tasks within an organizational grouping of tasks. These organizational relationships do not necessarily mean belonging to the same cluster of nodes according to direct cause and effect, but rather are used to assist the user in navigating what can become complex node structures. For example, the Purchases node, which organizes many procurement processes, has no causal connection with the processes it organizes, or with any other processes. This is because it is unclear how such an organizational node is affected by the nodes it organizes, or how it affects other nodes. Namely, if you ask the question, how do “purchases” fail, or when “purchases” are in danger, the answer will be inaccurate. A similar result will be, if we ask the question, which process will fail, if the "procurement" fail. However, more detailed units within this grouping, such as the “stock status of the ship” in relation to the spare part, can have very accurate consequences regarding the possibility of performing repairs on board. Thus, these organizational nodes, such as “purchases,” exist for navigational purposes, while the nodes organized by these nodes have normal cause and effect relationships with other nodes.

Business Logic Level: State Model

[000245] This is a place where data is stored and provide users with the ability to share information and provide the system with the ability to “remember” objects between user sessions.

[000246] When an attribute is identified as part of a process model, the state model is automatically expanded to provide storage of values for this attribute.

[000247] The values of the attributes of the state model may also contain a relationship in the model through the node, so that an additional attribute value indicates a relationship. For example, the age and name attributes may be associated with the employee identifier attribute to collectively represent the employee, and this may be represented in a cluster of nodes. At the class level, the types of relationships that exist are derived from the process model (cluster of nodes), usually as a result of the attributes being part of the same cluster serving the larger emulated process or parent node.

[000248] The key mechanism here is the context component of the Overlay interface. Attributes used for contextual filtering, namely, system navigation using key identifiers, become “key” attributes. A key attribute forms the basic navigation technique when many similar processes differ in their causes and consequences by means of a key identifier, and when many related but different stages of the process use the same key identification. For example, if the employee’s name is defined as a key attribute, then it becomes possible for the system to associate the employee’s age attributes with the name if each of these attributes forms two nodes in a larger cluster that identifies the employee. The key attribute and the use of the key attribute for system navigation help ensure, when processing employee data, that we focus on the proper employee, if there is more than one employee, while the process steps are the same for all employees.

[000249] This methodology for managing states represents an important step beyond conventional systems, in which by removing all domain-specific knowledge from the data model and the need to obtain it from the process model, we help prevent subconscious transfer of the prevailing assumptions of the information system design to a new one project, which may affect the ability of the system to accurately represent what is needed to complete the process in question.

Business Logic Level: Main Process Model

[000250] Nodes, if possible, are associated with node classes (abstracted clusters of nodes describing abstracted processes) as instantiations of these classes of nodes (abstracted cluster of nodes), which are determined by the model of the main process. Classes of nodes capture the common elements of domain-specific nodes as abstract versions of these nodes. For example, node classes can encompass concepts such as plan, check, validation, warning, etc. We can say that the abstracted classes of nodes represent concepts that can be known to a “caveman” because they are among the first abstractions that we, as humans, have come to understand.

[000251] Abstracted node classes serve two main purposes. First, they serve as a guide for business domain experts when considering how to model domain-specific issues, for example, by reminding them which issues should be addressed, and by helping individuals understand the work of experts in subject area. Secondly, they accelerate the modeling process by providing reuse and enabling the rapid identification of such processes by domain model. Reuse, however, may not be direct copying and pasting of generic code components and, more likely, involves adapting the node class (abstract cluster) to all examples / use cases. This is because an abstracted cluster or a class-level cluster is not always easy to describe in a suitable coding language, which can be converted without adapting to the level of the problem domain / use case. However, linking a cluster of a problem area with a class of nodes (an abstracted cluster) can be very explicit, so it becomes very clear where to cascade class level improvements in logic for the problem area / use case level.

User interface level

[000252] The user interface layer combines information contained within a business model with coding best practices for designing user interfaces for reproducing graphical user interfaces for a user.

[000253] Existing systems of the prior art use business objects as the main division of the concept with the UI. In other words, users create and open views of business objects to view their context options and make changes, if necessary. Overlay sees a radical change in the methodology here in that the node itself becomes the main concept of UI interaction. Users open the node UI to view the information needed to complete the process and capture information to update the state model.

[000254] The UIs of the nodes essentially represent the attributes of the input and output data of the node and surrounding nodes, that is, the cluster of nodes. Attributes identified as input are read-only attributes, while output attributes are read-write attributes. Attribute values are grouped, if necessary, and determined by the process model, as described above.

[000255] The existing number of attribute values determines the presentation format and the availability of support for navigation tools (such as sorting, filtering and searching) - if there is a lot of data, the UI will thus adapt dynamically to them. Attributes can be highlighted as key attributes for a node, which, in turn, can affect how they are presented in the node view.

[000256] For nodes with large quantities of output attributes, the system can resort to a two-stage UI model based on a list of source key attributes and an attribute set editor, but, in both cases, UIs must be generated dynamically. An example of this is a purchase order, where the first stage of the UI can provide an overview of the relevant key attributes (date, supplier name, order ID, recipient), and the second stage can be a more complex UI that can provide the full title of the Purchase Order and all linear elements.

[000257] As well as determining which attributes are relevant, cause-effect relationships between nodes also have an effect on how these attributes are represented. For example, visual emphasis can be applied to attributes that are affected by a causal relationship that are directly related to the node in question or to the type of cluster of nodes that provides a single UI that captures multiple causal relationships. This platform formulates a UI technique that is suitable for a solution or decisions or transactions to be performed.

[000258] Attributes can also be defined as relevant if deemed necessary to provide a context for attributes that the node structure considers relevant. For example, if the name of the machine component is identified as an attribute of the input, then the system may also consider that the name of the ship is relevant. These key attributes can be used to separate the view in a data structure suitable for grid display. In this example, the name of the ship will accompany the engine component as a sibling node for the identification node in the transaction called the “master data-filling system”.

Data management layer

[000259] The data management layer transforms the state model within the business model into the implementation infrastructure provided by the existing database management system. The need for scalability and the absence of a need for a formal structure of relational databases, since the underlying schema will, if necessary, be a meta-model to support operational extensibility, which means that this data is likely to be stored as key-value pairs. In turn, this naturally allows the use of non-SQL database systems such as CASSANDRA (The Apache Software Foundation, Los Angeles, CA). This technique reduces the likelihood that the underlying data management scheme will become an obstacle to ensuring system efficiency.

[000260] There are many other types of computational logic that go into information systems, in addition to logic that simply represents data and captures input data. Now, we begin to briefly examine how some additional types of computation can be covered:

Create and delete attributes.

[000261] As discussed in the state model, the actions that lead to the creation of a new attribute will trigger the execution of constructor functions that can create and populate attributes and other related attributes. Attribute removal should be supported by a special hard-coded action type that uses the attribute as a parameter from the node UI. You can also define destructor functions that contain logic that validates the deletion.

Event handling

[000262] As well as constructor and destructor events, you can define an action code for system and custom events. For example, when a node view is opened, viewed, edited, etc. Custom events associated with an action code are triggered when a change in state occurs. This may look like a database trigger, but appears in the node structure as a reusable abstracted process, albeit at a very detailed level, associated with transactional type processes.

Access Control and Access Security

[000263] Access control is essentially provided as part of the role-node-user-context structure. There is no need to override this structure with an additional layer of access control.

Machine-readable cause and effect of computed attributes

[000264] This is a central concept for providing computing support for users. The fields that are calculated are defined as the product of the script, which may include, but is not limited to, program constructs such as mathematical operators, logical operators, conditions / choices, loops, etc. The calculated fields are usually updated as a result of actions that trigger the transition from causal nodes to consequence nodes.

System integration

[000265] The concept of node structure at the heart of the Overlay model provides a useful infrastructure regarding the issue of combining disparate information systems - both in terms of combining processes (or users) and in terms of combining simpler data. We can consider these cases in turn.

[000266] A process union may look like a transition of information between processes that are not emulated by the same system, but where the effective execution of a process requires that they be combined. The problems associated with this type of consolidation become more acute when both systems to be combined discover conflicting representations of the same underlying object - in other words, both systems provide implementations for the same business object, none of which is not a suitable representation for all scenarios in which the attributes of these objects are relevant. Dividing business objects into their underlying attributes and assigning them to nodes and applying logic to the relationships between nodes will provide the ability to match attributes, since attributes will be assigned to nodes that describe the same business logic in both systems suitable for associations.

[000267] The methodology for combining processes may look somewhat similar to the following methodology, which is also the way in which generally accepted code using business objects can be converted to code that is hosted within the structure of the Overlay node model:

Display the state model in accordance with the state models of the two systems to be combined.

Abstract the problems and solutions proposed by each application to be merged.

Create a cluster of abstracted nodes that overlap the processes to be merged.

Connect abstract nodes with attributes in each application to be merged.

When executed correctly, the two sets of attributes (i.e., the abstracted set and the set of applications) will be the same. In other words, create predictive patterns for each node in each subject area and locate the data in the tables mentioned above and connect to the abstracted nodes.

In the end, the data in these predictive patterns will be equivalent, even though the tabular relationships and groupings are different in the two applications that are combined. Any goal-based relationships implemented by applications are thus replaced by a node structure.

Predictive patterns extract exactly consistent data from each database, because the nodes describe exactly the same data, and provide relationships that are different in the respective databases.

[000268] In relation to the easier task of combining data, we can start by considering external systems as agents that “execute” nodes. As a result of this, we can determine the data transformations necessary for passing data to the output and receiving data (and processing them), as part of the structure of nodes. In other words, we can look at external systems that want to receive data in some way, just like people do. Of course, systems tend to have less tolerance when it comes to their ability to accept inputs that do not follow exact rules, but there is a reason why this cannot be provided. It will be necessary, however, to create some platform elements to support different types of services, platforms, etc., to ensure compliance with security considerations, but this can be done in a fully generalized form.

[000269] The above can be shown with reference to FIG. 15. In case of an emergency requiring evacuation and locking of the school, the general goal of 1500 is 100% of the number of students evacuated, and 100% of the number of locked doors. Essentially, the two processes to be combined are the state of the doors and the number of students in the school. The two state models to be displayed are “door state” (open or closed) and “number of students present” (number of students passing through the open door, +1 for incoming and -1 for leaving). Problems and solutions can then be abstracted to monitor the state of the door and to count how many students go through the door when it is open.

[000270] Node A 1502, node B 1504, node C 1506 and node D 1508, then, are a cluster of nodes that overlap the processes to be combined. Then, the abstracted nodes 1502-1508 are connected to the door state attribute and the presence attribute. Each node has a causal relationship with an intermediate goal. For example, Interim Goal E 1510 is the result of counting how many doors are closed, and Interim Goal F 1512 is the number of students at the gathering place. These goals, then, converge on a common goal that determines the percentage of students at the venue and the percentage of closed doors. When both percentages are 100%, a common goal of 1500 will be achieved.

[000271] When an attribute is identified as part of a process model, the state model is automatically expanded to provide storage of values for this attribute. In other words, when an attribute is redefined as part of the process model, which is represented by a predictive sample of the node, the state model is automatically expanded to provide storage of values for the attribute, without any software extension of the auxiliary state model. In the example of FIG. 15, another attribute may be a turn-off of lighting devices, and a state model may be extended to include the state of the lighting devices (“on” or “off”).

[000272] Planning and allocation of resources. There are two examples of common software tasks that are likely to arise when trying to create systems on this platform. Imagine that a set of services can be created that provide computational support based on established best practices. In other words, the platform can provide generic resource planning and allocation machines that can be used in many situations.

[000273] Advanced data visualization. The platform can provide a set of services that can use the data set and reproduce it in the form of a chart, graph, or other visualization. The output and corresponding playback options follow the output nodes. Input data inserted into the aforementioned improved data reproduction options, in other words, interactively, on top of this visualization, is again provided by basing all the reproduction options on an interconnected node structure. The node structure foresaw the need for user interaction. Thus, any reproduction option is a declaration of either the generally accepted reproduction of the output data, which is the result of processing by the information system, or an input dialog to adapt to user reactions to the output data of the reproduction options.

[000274] Emergency response. Sometimes situations arise in which the priority of the goals of the participants and, thus, the input data and output data of the relevance connections between nodes change suddenly. In the event of an emergency, for example, if the fire spreads across the floor of the factory, then the hierarchy of targets changes, and a new network of Overlay nodes is used for the emergency. All the relationships between the processes to be followed and the options for participation change as the goal of the highest level changes to minimize damage and provide staff with the opportunity to safely evacuate, compared to a situation before an emergency, which focuses on the normal goals of the enterprise. In one example, the function of an administrative assistant can change from providing data input to ensuring that data contained in a company database is stored. In the second example, the function of the service worker can change from maintaining the equipment in good working condition to disconnecting the power supply from the equipment. In the third example, the function of a sales employee can change from making contacts with potential customers by phone to notifying authorities of an emergency and then ensuring control over the safe evacuation of the enterprise.

[000275] It should also be understood that during an emergency, the functions of physical objects and environments can change. For example, an evacuation route may be blocked, and an alternative route must be identified or identified, emergency services may be busy on another call, and an alternative service must be identified and contacted.

[000276] Emergency response requires that non-enterprise participants, who are new users, enter information regarding the state, from their point of view, of the emergency response process. It is also necessary for a casual user who will work as an employee of the enterprise responsible for dealing with the emergency.

[000277] Emergencies require coordinated management. With reference to FIG. 17, the centrally coordinated emergency management of the prior art did not use the information of participants from the enterprise, but processed it through people who received incoming calls. A member of the organization 1230, who is preferably a security expert, but may not be one due to the volume and time of the emergency, establishes communication with one or more participants not from the side of the enterprise, for example, employees of the fire department 1232, police department 1234, medical staff 1236 and the agency 1238 environmental protection. Then, member 1230 is instructed to pass this information on to other members of the organization 1240a - 1240e.

[000278] The prior art model has many drawbacks. In the event of an emergency, most enterprises do not have a backup call processing center for receiving calls, or do not have experienced people who are ready to interpret information and transmit it to users of the enterprise who use it to take actions or make decisions. The participant 1230 receives a lot of information from the many participants 1232, 1234, 1236, 1238 not from the side of the enterprise, which may not have connections with each other, and which may give conflicting advice. This participant is required to disseminate the correct information to multiple participants 1240a - 1240e of the enterprise, each of which may have different affairs during an emergency, and each of which may be in changing circumstances, as a function of time. Additionally, enterprise participants 1240d, 1240e may exchange data 1242 with each other, resulting in loss of attention to instructions from participant 1230. In addition, participant 1230 may need to disconnect due to an emergency or due to lack of cell phone power. Obviously, the prior art system is not suitable in the event of a serious emergency in a large enterprise, and a system is needed to receive information and interpret it, and transmit it to decision makers and participants who need this information.

[000279] With reference to FIG. 18, the appearance of portable telephones with the possibility for observers or personnel 1232, 1234, 1236, 1238 not from the enterprise side, as well as for respondents 1204a, 1204b, 1204c, 1204d, 1204e of the enterprise, to use portable devices to access the Internet 1216 through local telecommunications networks or local wireless networks 1222, provides new users or casual users the opportunity to participate in emergency response. They can enter information based on an expected set of choices so that the computer processor can decide how to automatically distribute the information to interested parties. Emergencies are usually situations requiring a narrow set of corrective actions, so a very large set of choices are not needed at any given time.

[000280] Each participant from the side or from the side of the enterprise in case of emergency has a narrow set of options for experience and actions, which should be transferred to other participants. Consequently, ignorant users have few options for choosing actions through systems, so that an easy choice of system actions is provided. A portable device, combined with an inexperienced user, cannot be effective if it offers the user a wide range of information or reactions. To offer a narrow set of choices, the system should have some degree of situational awareness.

[000281] When designing a system with limited choices, there is a need to emulate the exact situation in question. For example, common emergency actions are evacuation, locking, with various risks associated with this, such as fire, storm, intruders, and various types of physical environments. For each facility, more than one of the above elements is covered in most emergency response plans.

[000282] To create emergency response applications for portable devices, the following features are required:

Central application management module.

The central control module must designate the type of emergency.

Enterprise users should be provided with a suitable interface for the emergency in question. Because enterprise users perform different activities in any emergency, they must have access to a different set of application interfaces for each specialization in each emergency. When an emergency develops or branches out or, otherwise, changes, they should be provided with even more different, but focused application interfaces. When enterprise users are replaced due to lack or disability or a change in situation, other enterprise users must inherit their tasks and a suitable user interface.

Non-enterprise users should also be provided with a suitable user interface according to their situation and, usually, their location.

When non-enterprise users or enterprise users must resort to a text message response, they should be centrally parsed and distributed to the appropriate participants to make a decision or take an action. The system should be able to assign SMS messages to emergency voltage points.

[000283] To achieve the above, the application must anticipate all actions and decisions of the participants in the emergency scenario, as well as their combinations and their variants. Preferably, a system suitable for responding to emergencies can be configured appropriately regardless of the type or nature of the emergency, the type of information, or the type of decision made based on this information.

[000284] There is a need for user profiling of the user interface so that each user receives a suitable user interface in an emergency.

[000285] Situation variables that change user interfaces should be able to make changes during an emergency as soon as the situation forks or users change. Changes in the situation may be automated or initiated by designated users.

[000286] With reference to FIG. 19, part of tool 1202 is shown. Node 1206 is a stress point for an emergency and is associated with nodes identifying different types of emergency situations, such as fire 1252, flood 1254, and intruder 1256. These different types of emergency situations have nodes, in general, as the location of problem 1258, the number of people who reached a safe location 1260, the number of people 1262 missing, local emergency equipment 1264 and the location of exits 1266. Some nodes may have subnodes, for example, the number of people Those who have reached a safe location 1260 may have a subassembly of each person’s medical condition, node 1268, and a corresponding sub-attribute in the state model corresponding to each person’s medical condition.

[000287] Non-enterprise personnel display screen 1208, such as personnel of the fire department 1230 and medical personnel 1236, displays various information useful to this personnel. For example, fire department personnel can view the type of emergency (fire 1252) and attributes, such as location 1258 and the number of 1262 missing persons. Other information is not displayed to provide information relevant to the fire department, the ability to be large enough to ensure its good visibility on a small screen. The display device can be scrolled so that other information, such as the location of the outputs 1266, is centered on the display device 1208. A limited number of nodes 1270 user input, such as "do you need special equipment?" Is also displayed. With reference to FIG. 18 and 19. If the answer to the user input request is “yes”, then the designation that the fire is chemical in nature can be sent to a system that can then access the database inside the enterprise to determine which the chemical burns, and to the remote database 1214 to receive instructions on how to extinguish the fire, and quickly transfer this information back to the personnel 1232 of the fire department.

[000288] Medical personnel 1236 can also see that the emergency is a fire 1252, but location 1258 may be less relevant than the number of people in a safe location 1260 and the medical condition of these people 1268. Medical personnel can also scroll to other nodes and attributes for example, knowing the number of 1262 missing persons may help in responding to a 1270 'query about whether additional medical equipment is needed on site.

[000289] Emergencies introduce user attention and possibly limited functionality.

[000290] The screen size is very small, alphanumeric physical keyboards and touch screen keyboards are very small.

[000291] In case of emergency, there is a need for systems to exchange data with users, and for users there is a need to exchange data with the system and with each other, to meet the situation-specific needs for transmitting information and receiving information. The information to be received or to be transmitted is situation-specific and / or user-specific perceived needs.

[000292] The situation-specific nodes are related to user-perceived emergency needs. The relationship is provided through cause and effect, and sequential processes. Cause and effect concentrate related nodes. Clarification of the situation by other participants or sensors provides the opportunity to direct users' attention to new warnings in an unfolding situation. Serial nodes provide the ability to perform transactions, in other words, user inputs of data in accordance with sequences, if necessary. Nontransactional sequences may also be necessary, for example, reporting successive status indications. For example, student enumeration or, in another example, the controller fulfilling the sequence of confirmation of the declaration of escalation or de-escalation of the situation.

[000293] Thus, the system should show A) the specific nodes of the new situation relevant to the user through cause and effect, and B) the last user selected nodes and their associated consecutive nodes, as well as related nodes, through the cause and effect communication, C) nodes representing the greatest danger and significance for the participant.

[000294] In a limited screen, where each role is associated with a fairly large number of nodes. It may not be possible to show all nodes on one screen without playing the nodes too small to be clearly visible and navigable, especially in an emergency. Thus, the choice of three focal points can be provided: A) with the current node associated with the last situation, and B) with the node that the user is currently influencing, or to which he may want to return, C) with the nodes representing the largest danger and significance for the participant.

[000295] A user can navigate further beyond other nodes according to a user perceived need.

[000296] If you draw a parallel with the aircraft control panel, the control panel will show the last potential emergency for the role / user and all the nodes that are connected as the cause and effect with the last node of the potential emergency, the last user / role attention node, node of greatest danger and significance to the participant.

[000297] A similar paradigm for a portable device is talking during an emergency with complex acoustics. The listener will not be involved in the conversation during an emergency panic if the conversation is not related to the current emergency or to a new conversation about a new danger related to the emergency or about the most significant aspect of the emergency and its relevance to specific participants .

[000298] Such a system, in order to be flexible, requires the use of the elements described above:

enterprise stress points;

the relationship between stress points of the enterprise;

participants stress points of the enterprise;

input data from users;

Browse enterprise systems to find information relevant to sites

language syntactic analysis of enterprise systems to find information relevant to nodes; and

context options that provide the ability to filter user choices for the context of their difficulties in case of emergency.

[000299] Without the relationship between the stress points of the enterprise, the system will have to have pre-assigned relationships associated with the role and task, and pre-assigned task trees. To jump to the branch of the current scenario, the central management tool should provide an excellent task tree for each profiled user.

[000300] Alternatively, the orientation of the objects is the remaining option with corresponding navigation tasks.

[000301] Without the relationship between tasks, there will be many task trees / user interfaces that are profiled for the user. Adding and subtracting tasks can be the only way to ensure that their number becomes smaller. But if there is no relationship between them, then the tasks are difficult to choose and apply to user interfaces during an emergency.

[000302] Using Overlay relationships between process stress points, the number of user interfaces is reduced to one large continuous user interface with the ability to focus on any particular stress point. Thus, users see the nodes near the specified stress points, and they are filtered by the context applied to them. In other words, the system reduces each display for the user to an interface according to the state and context and profiling of the member user. The state refinement can be selected by the designated users, or, automatically, by the system.

[000303] In order to select information for an action field and distribute it to appropriate users for performing actions and making decisions, the system must anticipate the information and have a pre-planned way of presenting it to the user. This is possible using prior art software and hardware.

[000304] An obstacle to design is the provision of an appropriate user interface for each user and circumstance. The following paragraphs describe some alternatives in the prior art.

[000305] Orientation to Physical Objects to obtain input data. Orientation to physical objects is, for example, navigating the system by, first, selecting an option to select a physical location or an option to select people to be evacuated. Orientation to physical objects in the navigation tool of the User Interface is possible when there are very few options for choosing a physical object, and the physical object is a key indicator of relevant information. But complex navigation, nevertheless, will be necessary if there are many objects to choose from, for each user. For example, if during the evacuation of a school there are five buildings and different locations in them. Building-based evacuation information as an orientation of objects is possible because evacuation is associated with locations and thus with objects. And also, there are other objects relevant for an emergency, for example, students at school. But there are many different students in each class, depending on the time of day. Navigating through the system to find student-based or building-based information will be difficult because most of the information, such as types of damage, and situation-related information, such as weather or respiratory problems, are not easily associated with these two physical objects.

[000306] Orientation to Business Objects for viewing relevant objects. Orientation of navigation at business objects can be carried out, for example, by means of security instruction documents. Displaying a description of a business object, for example, a relevant user instruction document, is a problem because there will be too many choices for each user, due to the multiple steps of the process. Instructions in case of panic, in case of damage, personal medical records, alternative exit routes based on location, etc. Thus, targeting business objects is complex. Concretization of the current process, plus some filtering of objects, is necessary to provide the proper object for the user's attention. This requires establishing a connection between processes and objects. Implementing this without a model is very resource intensive in developing and maintaining software, and also controversial. Each object must have a code written for it so that it appears at the right time for the proper user. In addition, periodic enhancements to emergency response applications will require new software versions, while they will also increase the complexity of the system and its navigation.

[000307] Replacing a user-defined set of nodes and context options. It is likely that during an emergency, available personnel may not meet the default system assessment, as is the case with users of a normal enterprise software system. Thus, changes in user access may be required both at the beginning and during an emergency. The operational implementation of this, when the situation unfolds, is possible only using the Overlay model disclosed here, or multiple pre-programmed designed interfaces. Pre-programmed interfaces should be quickly assigned for proper use and situation, as many of them will have some extensions. This will require very intensive work during an emergency, as well as the very large resources required at the design and implementation stage of a task-oriented model for an emergency response application. And also, without pre-programmed designed interfaces for the situation in question, plus concretization according to development options in an emergency, navigation for the proper object will be very unfriendly to portable devices.

[000308] SMS messages used to coordinate an emergency. If SMS messages are sent from the action field, then they must be interpreted, and a central system will be required to assign words to nodes. Interpreting SMS messages requires the Overlay model to designate a linguistically appropriate predictive pattern for nodes. An alternative is to have a team of people coordinating the distribution of SMS message channels from the source to decision points regarding needs.

[000309] Thus, for an emergency response application, it is desirable to use the continuous Overlay user interface provided by the enterprise model declared in the nodes connected as cause and effect, and the possibility of specifying a part of the user interface for new alerts and allowing users to return to previous focus nodes or new focus areas relevant to the user / participant.

[000310] While the disclosure of the present invention has been described with respect to specific embodiments, in view of the above description, it should be understood that multiple alternatives, modifications, and variations will be apparent to those skilled in the art. Thus, the disclosure of the present invention is intended to cover all such alternatives, modifications, and variations that fall within the spirit and scope of the present invention as defined by the following claims.

Claims (58)

1. A portable device configured to access and display information related to the enterprise, while the portable device has communication means, a display and an energy source, the portable device being characterized in that: said portable device communicates with a computer-readable medium with executable instructions encoded in a non-temporary digital storage medium, wherein the non-temporary digital storage medium also stores an enterprise model, enterprise content and enterprise data, the processes associated with the model including process nodes , a machine-readable description of relevance between different process nodes and a machine-readable description of relevance between content and data and these different evils process; the aforementioned set of process nodes are interconnected by links in a causal grid, with each link being encoded by executable instructions; and the display has a limited area, as a result of which not all process nodes are visible at the first specified time, and the module communicating with the computing device identifies the interconnected process nodes that should be displayed at the first specified time. 2. A system for locating and retrieving information within an enterprise, comprising: a computing device having a computer-readable medium with executable instructions encoded in a non-temporary digital storage medium, the non-temporary digital storage medium also storing the enterprise model, enterprise content and enterprise data, the processes associated with the model include process nodes, a machine-readable description of the relevance between different process nodes and a machine-readable description of the relevance between content and data and these different process nodes; and many portable devices according to claim 1, communicating with a computing device. 3. The system of claim 2, wherein the computing device transmits and receives a different information packet from each portable device, and each respective information packet depends on the process nodes assigned to an individual user, and this respective transmitted packet depends on the designed reactions on interactions provoked by this user, and state changes of any process nodes in the system detected by a computing device, which, through continuously-effect ratio change process state node assigned to the user. 4. The system of claim 3, wherein the state of the interconnected process nodes is determined in computer code encoded in a non-temporal digital storage medium, and the relationship between the interconnected process nodes is dynamic. 5. The system of claim 4, wherein the state of the interconnected process nodes changes based on a message between said computing device and said plurality of portable devices. 6. The system of claim 4, wherein the state of the interconnected process nodes changes based on the role of the individual user and the effect of the most recent warning on the interconnected process nodes displayed at the first predetermined point in time. 7. The system of claim 2, wherein each portable device includes a corresponding display that is integrated with and communicates with this portable device. 8. The system of claim 7, wherein those process nodes that are visible at a first predetermined point in time are interconnected process nodes providing the user with access to relevant information. 9. The system of claim 8, wherein the computing device communicates with said portable device to identify interconnected process nodes displayed at a first predetermined point in time. 10. The system according to claim 9, in which the computing device has access to the state of the situation of the event and changes the set of interconnected process nodes depending on the time and state of the situation. 11. The system of claim 9, wherein each portable device is adapted to display process nodes sequentially preceding and / or following interconnected process nodes identified by said module. 12. The system of claim 11, wherein the user interface allows the user to change the number of interconnected process nodes visible on the display at any given point in time by one or more of (i) collapsing the descendant nodes into parent nodes, (ii) showing descendant nodes under the parent nodes and (iii) scaling up and down. 13. The system of claim 12, wherein the user interface provides the user with the ability to increase the number of interconnected process nodes visible on the display at any given point in time. 14. The system of claim 12, wherein the user interface provides the user with the ability to reduce the number of interconnected process nodes visible on the display at any given point in time. 15. The system according to p. 12, in which up to all process nodes can be visible on the display at any given point in time. 16. A system for locating and transforming information relevant to a process related to an enterprise, the system comprising: a computing device having a computer-readable medium with executable instructions encoded in a non-temporary digital storage medium, wherein the non-temporary digital storage medium also stores an enterprise model, enterprise content and enterprise data; wherein the processes associated with the model include process nodes, a machine-readable description of relevance between different process nodes and a machine-readable description of relevance between content and data and these different process nodes, the aforementioned set of process nodes are interconnected by links in a causal grid, with each link being encoded by executable instructions; a device communicating with the computing device and configured to both receive data relevant to the voltage point of the enterprise, and enter this data; and a user interface associated with a portable device for presenting to the user content and data adapted to assist the user in at least one of a solution to a problem, use the opportunity and understand the event, the user interface having a display through which the first cluster of interconnected process nodes is visible in first set point in time. 17. The system of claim 16, wherein the display is integrated with and communicates with the portable device, and the display has a limited area, so that not all process nodes are visible at the first predetermined point in time. 18. The system of claim 17, wherein those process nodes that are visible at the first predetermined point in time are interconnected process nodes providing the user with access to relevant information. 19. The system of claim 18, wherein the computing device communicates with the portable device to identify the interconnected process nodes displayed at the first predetermined point in time. 20. The system according to claim 19, in which the computing device has access to the state of the situation of the event and changes the set of interconnected process nodes depending on the time and state of the situation. 21. The system of claim 19, wherein the portable device also displays process units successively preceding and / or following interconnected process units identified by said module. 22. The system of claim 20, wherein the user interface allows the user to change the number of interconnected process nodes visible on the display at any given point in time by one or more of (i) collapsing the descendant nodes into parent nodes, (ii) showing descendant nodes under the parent nodes and (iii) scaling up and down. 23. The system of claim 22, wherein the user interface provides the user with the ability to increase the number of interconnected process nodes visible on the display at any given point in time. 24. The system of claim 20, wherein the portable device displays those process nodes that pose the greatest risk to the enterprise. 25. The system according to p. 22, in which up to all process nodes can be visible on the display at any given point in time. 26. The system of claim 16, wherein the relevance between adjacent process nodes is a machine-readable causal relationship. 27. The system of claim 26, wherein the transition to a value in the state model associated with the process node does not require a transition to a machine-readable description of the relevance of the content and data between this process node and adjacent process nodes. 28. The system of claim 26, wherein the process node is assigned a value and, based on this value, the converted value is assigned by program code to one or more adjacent process nodes, the program code defining a machine-readable causal relationship connecting this process node to adjacent process nodes. 29. A method for emulating real-world processes in an overlay system, comprising stages in which: identify many system steps of the process and assign attributes that are attributes of the state of the underlying processes in the real world; compose the system stages of the process into many clusters of process nodes: establish machine-readable causal relationships between process nodes, wherein said plurality of process nodes are interconnected by links in a cause-and-effect grid, with each link being encoded by executable instructions; using transactional process nodes to identify the underlying state values of real-world processes and their unique locations in the state model; place attributes relevant to each process node in the corresponding state model; and use machine-readable cause-effect relationships between process nodes to determine the relationship between state elements of underlying processes in the real world. 30. The method of claim 29, wherein each process node is characterized by attributes in a state model. 31. The method of claim 30, wherein when a new process node or new attribute is identified, the state model is automatically expanded to provide storage of values for that process node or attribute. 32. The method of claim 30, wherein when a new process node or a new attribute is identified, it is added to the cluster of process nodes and the user interface is automatically expanded to accommodate the new process node and its attributes. 33. The method of claim 30, wherein when an existing process node or an existing attribute is deactivated, it is removed from the cluster of process nodes and the user interface is automatically reduced to delete this process node and its attributes. 34. A method of combining at least two processes in two different systems or processes that are optionally designed together to achieve a common goal, comprising stages in which: identify one cluster of nodes from the set of clusters of process nodes, which is abstract enough to be reliable both in the first process and in the second process, with each process node in the cluster of process nodes describes an enterprise stress point having an intermediate goal, and each process node contains data and / or content related to this stress point of the enterprise; wherein each process node in the cluster of process nodes has a causal relationship with other process nodes in the cluster of nodes, and this causal relationship can be expressed as a machine-readable mathematical algorithm, the aforementioned set of process nodes are interconnected by links in a causal grid, each link being encoded by executable instructions, and said intermediate goals converge on said common goal. 35. The method of claim 34, wherein each process node is characterized by attributes in a state model. 36. The method of claim 35, wherein when a new process node or new attribute is identified, the state model is automatically expanded to provide storage of values for that process node or attribute. 37. The method of claim 35, wherein when a new process node or new attribute is identified, it is added to the cluster of process nodes and the user interface is automatically expanded to accommodate this new process node and its attributes. 38. The method of claim 35, wherein when an existing process node or an existing attribute is deactivated, it is removed from the cluster of process nodes and the user interface is automatically reduced to delete this process node and its attributes.

Images