Dynamic Process Modeling

Abstract

A network system that facilitates the creation of a hierarchical arrangement of process elements within a process model application. The hierarchical arrangement organizes process flows into an enterprise hierarchy. The system automatically transforms dynamic events created within the tool into output containing process implementation specifications using the hierarchical arrangement of process elements. The process model application enables users to arrange, interact, refine, and evolve the events created within the structure.

Description

[Technical Field]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This application claims priority to U.S. Provisional Application No. 63 / 435,634, filed December 28, 2022, entitled "Dynamic Work Models and Process Flows," U.S. Provisional Application No. 63 / 458,306, filed April 10, 2023, entitled "Dynamic Work Implementation Specification," and U.S. Non-Provisional Application No. 18 / 392,554, filed December 21, 2023, entitled "Dynamic Process Modeling," all of which are incorporated herein by reference in their entireties.

[0002] The present technology relates generally to the field of process flow modeling, and more particularly to methods and systems for translating dynamic, hierarchical process models and process flows into implementation specifications, providing users with actionable insights, and enabling teams to experiment with the organization and relationships between process elements. [Background technology]

[0003] In traditional systems, process flows typically present static events, actors, and deadlines that are edited by users when elements need to be modified, without revealing inconsistencies, inaccuracies, inter-process flow connections, and inherent opportunities. One example of a process flow is a work flow (e.g., a software design flow or a data transfer flow), but any other type of process may also be considered. As used herein, "process flow" may refer to both the continuous flow of component process parts and the relationships between various process flows and the various component parts of those flows. The layout of traditional process flow applications is typically linear, sequential, and static. Traditional applications are not multidimensional, collaborative, and interconnected as presented herein. Traditional systems typically provide a continuous view of the process flow and do not offer opportunities for data-driven and dynamic features that allow individuals to capture, visualize, and measure the interdependent aspects of the process flow and provide assessments of its quality, feasibility, and other benefits. [Brief explanation of the drawings]

[0004] [Figure 1] FIG. 1 is a block diagram illustrating a system for capturing, visualizing, and measuring interdependent aspects of a process through the creation of dynamic process models and process flows. [Figure 2a] FIG. 1 illustrates an example hierarchical enterprise structure of a process model application. [Figure 2b] FIG. 1 illustrates an example hierarchical enterprise structure of a process model application with functions tagged with events and activities. [Figure 3a] FIG. 1 illustrates an example hierarchical enterprise structure of a process model application with traceable catalog elements. [Figure 3b] FIG. 1 is a diagram of a catalog of catalog elements. [Figure 3c]FIG. 1 is a diagram of a hierarchical enterprise structure with horizontal parent-child relationships. [Figure 3d] FIG. 10 is a diagram of a side panel view of event details. [Figure 3e] FIG. 1 shows an expanded view of an event or activity. [Figure 4a] FIG. 10 illustrates an exemplary user interface for contextualizing activity within an event. [Figure 4b] FIG. 10 illustrates an exemplary user interface for contextualizing activity within an event. [Figure 5] FIG. 10 is a diagram of the dynamic construction of an activity description in the context of an event. [Figure 6] A diagram of the structure of operational parameters such as characteristics, trends, and attributes of an event. [Figure 7a] FIG. 1 is a diagram of activity data and material movement contextualization and storage. [Figure 7b] FIG. 1 is a diagram of activity data and material movement contextualization and storage. [Figure 8] A diagram of the dynamic construction of draft user stories during an event. [Figure 9a] FIG. 1 is a diagram of the dynamic construction of draft functional requirements in an event. [Figure 9b] FIG. 10 is a diagram of the dynamic construction of draft functional requirements in the event of alternative outcomes. [Figure 9c] FIG. 10 is a diagram of the dynamic construction of input / output specific draft functional requirements in the event of alternative outcomes. [Figure 10] A diagram of customizable policy-driven logic that controls how activities are designed and how catalog elements are employed. [Figure 11] FIG. 11 is a diagram translating variant events into insights detailing deltas / similarities between multiple models. [Figure 12] A diagram of interjections as forms of reaction to events and elements. [Figure 13] 1 illustrates a computing machine and modules. DETAILED DESCRIPTION OF THE INVENTION

[0005] Exemplary System Architecture Figure 1 is a block diagram illustrating a system for capturing, visualizing, and measuring interdependent aspects of work processes through the creation of dynamic process models and process flows. As shown in Figure 1, architecture 100 includes a process model system 110, enterprise system devices 120, and employee computing devices 130, which are connected by a communication network 99.

[0006] Each network (e.g., communication network 99) includes wired or wireless long-distance communication mechanisms and / or protocols by which the components shown in FIG. 1 can exchange data. For example, each network 99 can include a local area network ("LAN"), a wide area network ("WAN"), an intranet, the Internet, a cellular network, a storage area network (SAN), a personal area network (PAN), a metropolitan area network (MAN), a wireless local area network (WLAN), a virtual private network (VPN), a cellular or other mobile communication network, Bluetooth, NFC, Wi-Fi, or any combination thereof, or any other suitable architecture or system that facilitates communication of signals or data. Throughout the discussion of exemplary embodiments, the terms "data" and "information" are used interchangeably herein to refer to text, images, audio, video, or any other form of information that may be present in a computer-based environment. The communication technologies utilized by the components shown in FIG. 1 may be similar to or alternative to the network technologies used by network 99.

[0007] Each of the components shown in FIG. 1 comprises a computing device having a communications application capable of sending and receiving data over network 99 or a similar network. For example, each may include a server, a desktop computer, a laptop computer, a tablet computer, a television with one or more processors embedded and / or coupled thereto, a smartphone, a handheld or wearable computer, a personal digital assistant (“PDA”), other wearable devices such as a smartwatch or smart glasses, a wireless system access point, or any other processor-driven device.

[0008] In the exemplary embodiment shown in FIG. 1 , process model system 110 is operated by a network operator, network designer, or other user who may use process model system 110 to operate the system or communicate with other devices and access services or data. Enterprise system devices 120 may be operated by users, operators, or other persons or systems that access or use process model application 112 to review, observe, edit, create, or evaluate process models. Employee computing devices 130 may be operated by users, employees, operators, or other persons or systems that perform tasks assigned to the enterprise system. Each server, system, and device shown in the architecture is represented by one instance of the server, system, or device, although multiple instances of each may also be used.

[0009] As shown in FIG. 1 , the process model system 110 includes one or more process model servers 111. The process model servers 111 may be one or more devices, servers, software applications, cloud computing devices, hardware, or any other type of device, function, or module that is part of the process model system 110 used to perform a task, store data, provide a service, communicate with users, communicate with third-party devices, or perform any other suitable action. The process model servers 111 may have applications, modules, or other functions that operate as process model applications 112. The process model applications 112 may be applications that implement methods described herein to create, host, edit, analyze, monitor, or otherwise service process models. The process model applications 112 may be accessed or edited by enterprise system devices 120. The process model applications 112 may monitor the activity of employee computing devices 130. The process model applications 112 may utilize a catalog 113. The catalog 113 may represent any database or other collection of data that can be used to populate a process model, such as a database of people, equipment, and other enterprise assets, data, materials, instructions, attributes, characteristics, or other aspects of events or characteristics.

[0010] Enterprise system devices 120 may represent computing devices used by enterprise operators to build, edit, monitor, analyze, or otherwise use process models. Enterprise system devices 120 may utilize process model applications 112 to perform any of these suitable tasks. Process model applications 112 may be versions or reproductions of process model applications 112 hosted or run on process model servers 111. That is, users may access process models hosted on process model applications 112 and participate in process models created from process model servers 111. Enterprise system devices 120 may be any type of device (e.g., laptops, smartphones, workstations, servers, or other devices described herein).

[0011] An employee computing device 130 may represent a computing device used by an employee or other user to perform assigned tasks for the enterprise. For example, an employee computing device 130 may be a laptop assigned to an employee or contractor to perform tasks (e.g., accounting tasks, programming tasks, human resources tasks, research tasks, or other tasks that accomplish assigned enterprise goals).

[0012] In an exemplary embodiment, the network computing devices and any other computing machines associated with the technology presented herein may be any type of computing machine (e.g., without limitation, those discussed in more detail with respect to FIG. 13). Additionally, any function, application, or component associated with any of these computing machines, such as those described herein or any other associated with the technology presented herein (e.g., script, web content, software, firmware, hardware, or module), may be any of the components discussed in more detail with respect to FIG. 13. The computing machines discussed herein may communicate with each other, as well as with other computing machines or communication systems, over one or more networks (e.g., network 99). Network 99 may include any type of data or communication network, including any of the network technologies discussed with respect to FIG. 13.

[0013] Illustrative Embodiments Reference will now be made in detail to embodiments of the present invention, one or more examples of which are illustrated in the accompanying drawings. Each example is provided by way of explanation of the invention, and not as a limitation of the invention. Those skilled in the art will recognize that various modifications and variations can be made in the present invention without departing from the scope or spirit of the invention. For instance, features illustrated or described as part of one embodiment can be used with another embodiment to yield yet a further embodiment. Accordingly, the present technology is intended to cover such modifications and variations that are within the scope of the present invention.

[0014] Techniques for embodiments of the present invention may employ methods and systems for transforming dynamic, hierarchical process models and process flows into work implementation specifications to provide users with user stories, functional requirements, and other documents that describe the process.

[0015] Examples for embodiments of the present invention may employ computer hardware and software, including, without limitation, one or more processors coupled to memory and non-transitory computer-readable storage media having stored thereon one or more executable computer application programs that instruct the processors to perform such methods.

[0016] The exemplary methods illustrated in FIGS. 2-9 are described below with respect to components of the exemplary communication and processing architecture 100.

[0017] 2a is a diagram illustrating an example user interface displaying a hierarchical enterprise structure 200 of the process model application 112. The structure 200 represents various levels of summary data driven by granular data from various levels of the enterprise.

[0018] In this example, events in the process model application 112 are organized into enterprise hierarchy structures (e.g., structure 200). Each structure is designed to accommodate events specific to an organization or part of that organization. Some particular organizations may not have multiple enterprises. Each enterprise is an organizational structure designed to contain the information necessary to document the operations of a single organization. An enterprise hierarchy is an organizational structure based on hierarchical relationships between functions, events, and activities within an organization. Exemplary functions, events, and activities are described herein.

[0019] Within an enterprise, users can create and view different events. Each event is composed of activities or other events that have either an ordered or unordered relationship. In addition, any of these events can be nested in a hierarchical relationship within another event at the next higher level in the hierarchy of structure 200. In some specific examples, events and activities can be connected in a sequential or concurrent sequence. In other examples, events and activities can be related to each other but are not part of a sequence.

[0020] In this example, an activity is an object within the system that maintains data describing a discrete action that may occur within an enterprise, such as performing a task, obtaining materials, sorting data, or other suitable activity. An activity may consist of information such as the activity owner, budget, duration, and sequence ID. Examples of activities may include transferring data, copying a database, making headcount adjustments, or deleting unnecessary data.

[0021] In this example, an event is an object in the system that maintains multiple activities and additional information about the relationships between the activities it contains. An event consists of the following information: 1) the ordering relationships between activities (sequence lines), 2) the logic that dictates which set of activities to perform in different situations (sequence lines > decision logic), 3) the data related to any functions tagged to that event (functions), the flow of data / material catalog elements between activities (data and material elements, material and data flows), and 4) summary information (aggregation and distribution) about the activities contained within the event, such as an exemplary total time. Examples of events might include creating a mobile application, submitting a data request, or completing an anti-money laundering check.

[0022] An event may include multiple events or activities in a sequential order. An example of a process, procedure, method, or other sequence of activities that may be represented by an event is the process of creating a performance forecast. An exemplary event may be structured as a first activity or event for synthesizing data used to create the forecast, a second activity or event for performing analysis, a third activity or event for reviewing the forecast, and a fourth activity or event for submitting the forecast. A sequence of activities or events forms an event. Each activity is a component part of the event that describes a separate step in the process.

[0023] Additionally, a single event that is a child of another event may represent a nested event at a lower level in the hierarchical enterprise structure 200. That is, the event is itself an event that is made up of a series of activities or events. In this example, the first activity was to consolidate the data used to create a forecast. This activity may include a first activity that obtains data from a database, a second activity that extracts data related to the forecast, and an event that fills a spreadsheet with data.

[0024] When an event has nested events or activities, some attributes of the parent event may be driven by the child events or activities or may be set by a user, process designer, software application, or other party. In this example, the event for creating a performance forecast includes parameters related to the activities of the sub-events (e.g., parameters related to a database and a spreadsheet).

[0025] In another example, an event is created that represents the process of generating and reviewing a report. Within that event, there are five different activities or events, one of which is directed to exporting the report. The export report event then serves as an event for the activities or events at the next lower level in the hierarchy that together make up the export report event. That event may then have its own set of child activities or events.

[0026] The usefulness of the relationship between a parent event and its children can be similar whether the children are activities or events. As used throughout, some specific tasks that may be associated with activities or events may be described in examples using only one of events or activities. However, some specific tasks described herein may apply to either events or activities. That is, a child of a parent event may be described as an activity, but if that child acts as a parent to other children, that child may instead be an event in other examples. Furthermore, an activity may later become an event if it is added as a child at a lower level.

[0027] The exemplary hierarchical enterprise structure 200 of the process model application 112 illustrates an example process with four enterprise levels. At enterprise level 1, there are multiple events and one activity (Event 1, Event 2, Event 3, and Activity 4). All of these events and activities comprise the complete business of enterprise level 1. As shown, Event 1 is also an event that has a child that appears at enterprise level 2.

[0028] Each event is indicated by a vertical line directly below the event icon. Two of the event lines are shown as event lines 202. Activity 4 is indicated by a dashed icon and has no event line. Event line 202 indicates that further events and activities are children of that event. Activity 4 has no event lines because it has no child events or activities.

[0029] Event 1 is shown highlighted as the selected event. In this example, the user may have clicked or otherwise selected Event 1. Once selected, the hierarchy below Event 1 expands to show the events. Non-selected events (e.g., Event 2 and Event 3) are indicated by their event lines 202 ending, disappearing, or fading.

[0030] Event 1 has four events that must occur for Event 1 to complete. Event 1's three child events are Event 1.1, Event 1.2, and Event 1.4. Events at this enterprise level are indicated by event lines (e.g., event line 202 below Event 1.4). One activity is shown as a child of Event 1, Activity 1.3. Activity 1.3 does not have an event line 202 because it does not have any children at lower hierarchical levels.

[0031] Additionally, as shown, Event 1.2 is shown selected. Thus, Event 1.2's lower hierarchical level is displayed with three child events and one activity at Enterprise Level 3. Event 1.2.3 is an event with three child activities at Enterprise Level 4. Because the activities at Enterprise Level 4 have no further child events or activities, Enterprise Level 4 is the lowest level for Event 1's hierarchical structure.

[0032] The four enterprise levels 1, 2, 3, and 4 represent a hierarchy of events and activities: enterprise level 1 can be considered the parent level, enterprise level 2 can be considered the child level, enterprise level 3 can be considered the grandchild level, and enterprise level 4 can be considered the great-grandchild level.

[0033] The diagram in Figure 2a includes a legend 201a that lists the elements of the diagram along with a description of the elements. Legend 201 lists events, selected events, activities, and parent-child sequences.

[0034] As explained in legend 201a, a darkened event is a selected event. For example, if a user clicks on an element (e.g., an event or function), the element is represented by a darkened circle in the icon. Each child and grandchild event or activity that makes up the selected element is displayed. While FIG. 2 shows selected events as darkened, any other suitable depiction may be utilized (e.g., changing color, brightness, shape, or any other suitable depiction that helps highlight the selected element).

[0035] When selected, details about the element may be displayed, for example, in a pop-up window, a split-screen window, or any other type of display. The details may be any suitable details about the element (e.g., a catalog element) as described herein. For example, when Event 1 is selected, one or more child and grandchild events and sub-activities may be highlighted or displayed.

[0036] Once a user, the machine learning capabilities of the process model application 112, or another device or system builds the hierarchical structure, the process model application 112 aggregates and distributes information related to events and functions. For example, if a user builds three events consisting of ten activities each, and the user wants to create an event that encompasses these three events at a higher level, the process model application 112 aggregates the information from the three activities into a higher-level enterprise-level event consisting of three events. The process model application 112 fills the structure 200 with the data of the three events. Each of the three events has a structure 200 filled with the data of the ten events at the lower enterprise level for each of the three events. The process model application 112 has knowledge and summaries of all the events, activities, or functions necessary to complete the parent enterprise level.

[0037] For example, if a user determines that events 1.1, 1.2, 1.4, and activity 1.3 together perform a task that the user wants to capture in an event, the process model application 112 aggregates information from the three events and activities into a higher enterprise level 1 and populates a new event 1 with the data from that hierarchical structure. The hierarchical structure can be displayed on the hierarchical enterprise structure 200 (e.g., on the user interface functionality of the process model server 111).

[0038] The system may employ other examples of aggregation and distribution of information related to events and functions. For example, attributes (e.g., catalog elements) may be aggregated from all child events to a parent event. These may be aggregated in the form of individual catalog elements, but may be summarized using higher-level catalog elements. For example, if many individuals on the same team are aggregated to a parent, the system may suggest that the team be referenced in the parent event. Additionally, any quantitative attributes (e.g., duration) may be summarized at the parent level as the sum of the durations of the child events.

[0039] Some specific catalog elements can be distributed from parent events to child events. For example, if a rule applies to a parent, the child events must also follow that rule. Additionally, quantitative attributes can be distributed from parent to child as total limit values. For example, if a parent event must occur within a certain duration, the sum of the durations of the child events cannot exceed that total duration value. If the design violates the information distributed from the parent, a warning / notification / smart signal is presented to the user.

[0040] One or more of the events in the system may have variants. A variant is a replica of the original event that can be modified to test different event configurations. For example, an event may represent a process that transforms a dataset. A user may create variants of the original event to clarify what that process might look like using different tools and methods. One variant is identified as the root variant, which is the event that is referenced in the enterprise hierarchy. Depending on the event's instructions, other variants may be swapped in to replace the root variant. For example, if the input to a dataset changes and a different type of data transformation technique works more efficiently, a variant event that uses that different technique can be inserted into the hierarchy to replace the root variant.

[0041] In the example, variants inherit information in the same way as the root variant (aggregation and distribution), but in some specific examples, only the root variant distributes its attributes to its children.

[0042] The process model application 112 may store alternative hierarchical enterprise structures 200 with variant events along with the main hierarchical enterprise structure 200. A user may explore how the alternative hierarchical enterprise structures 200 and the main hierarchical enterprise structure 200 are affected by changing conditions or changing inputs. The process model application 112 may run simulations for each of the hierarchical enterprise structures 200 to determine how the variants affect the system. If a variant event is determined to be a preferred event, the variant event may be substituted as the main event in the hierarchical enterprise structure 200.

[0043] FIG. 2b illustrates an example hierarchical enterprise structure 200 of a process model application 112 with functions tagged with events and activities.

[0044] A feature is a user-defined classification of events within an enterprise, allowing parts of the enterprise to be grouped by common characteristics. A feature may include a hierarchical list of tags that may be applied to events. For example, if a user intended to create a feature type that represents a geographic point, the feature name may be defined as "Geographic Point." This feature may have tags including: North America, United States, Mexico, Canada, South America, Brazil, Europe, United Kingdom, Asia, China, Japan, Africa, Ghana, or South Africa.

[0045] Another exemplary function type may be labeled a “functional area.” Elements with these functions may have tags including research and development, database management, medical devices, human resources, planning, or accounting.

[0046] Another exemplary function type may be labeled “product type.” Elements with these functions may have tags that include configuration software, data processing, machine parts, direct-to-consumer products, food, cosmetics, or personal care products.

[0047] When a function is tagged to a parent event, child events are classified under the same function unless otherwise specified. When a function is applied to a parent event, it does not limit the functions that apply to its children. For example, a user or software process may model a process at the parent level and specify its function as "Geographical Location: North America." Then, a user may specify a child event's function as "Geographical Location: China." In this example, the function may represent an event where work is performed in both North America and China, with the parent event owned by the North American division of an enterprise and the child event owned by the Chinese division of the enterprise.

[0048] In some particular examples, only one function of a particular type of function may be applied to each event. For example, only one type of location function may be applied to an event, or other types of functions may be applied to an event. For example, an individual may choose to apply "Geographic Location: China" and "Cost Center: ASPAC" to an event to record that the work the event represents is performed in a geographic location in China and the associated costs are reported under cost center ASPAC. In other examples, more than one function of a particular type may be applied to an event. For example, an event may produce two product types as outputs. The applied functions may include "Product Type: Machine Parts" and "Product Type: Recycled Materials."

[0049] Once features are applied to events, users can filter the enterprise by those features to isolate models that represent specific portions of the enterprise. Users can perform search or sort functions on events within the enterprise to identify, group, or sort events and activities based on the applied features. For example, a user can query the enterprise by "geographic point: North America" ​​to return all events with the "geographic point: North America" ​​feature. The system can additionally return all events with tags under "geographic point: North America" ​​(e.g., events with the features "geographic point: United States," "geographic point: Mexico," and "geographic point: Canada").

[0050] In the diagram of FIG. 2b, events and activities are represented by functions (e.g., function 203). Each function may be associated with an event or activity in any suitable manner. For example, a user may click an option to add a tag to an event. A function may belong to an event because a parent or child event is associated with that function. Functions may be assigned to all events or activities in a group, or performed in a particular area, or performed by a particular set of operators, or grouped into categories to which characteristics may be assigned in any other manner.

[0051] Event 1 and event 1.4 are represented by function 203. Feature 203 is labeled Feature 1. Feature 1 may be any suitable feature, for example, "geographic location: Mexico" or "product type: mobile application." Feature 203 is shown as a tag placed under event 1, although any other suitable representation of feature 203 may be used. In some particular examples, multiple features 203 (e.g., feature 1, feature 2, and feature 3) may be displayed. Activity 4 is also represented by feature 2.

[0052] In addition to the features in legend 201a, legend 201b includes an image of a feature tag with the label of the feature.

[0053] The "functional area" functional type may have tags including: Research and Development 〇Consumer products Pharmaceuticals Medical devices ·human resources 〇Salary 〇Advantages 〇Recruiting Financial status 〇Planning 〇Purchasing Accounting

[0054] 3a illustrates an exemplary hierarchical enterprise structure 300 of a process model application 112 with traceable catalog elements. The process model application 112 provides a catalog 113 that contains individual elements that facilitate and support the processes performed in an event, activity, or function.

[0055] A catalog element is an object in the system that represents a resource that enables the performance of a process event or activity. A catalog element may represent a dataset, a database, a data element, a role, a team, an individual, a location, a tool, a material, a rule / regulation, a goal / objective, or any other suitable element. The attributes of a catalog element may include any information relevant to its application within an activity, and these attributes may vary depending on what the catalog element represents.

[0056] For example, an individual catalog element directed to an individual performing a task may contain information about how much the individual is paid or what skills the individual possesses. For example, a catalog element might include {Name: John Doe, Salary: $80,000, Skills [Microsoft Office, Data Analysis, Leadership]}. Or, a catalog element directed to a rule may include a specification of the regulation that must be followed, i.e., {Name: [Maximum Application Processing Time], Specification: [[Activity Duration] < 24 hours]}. The data that populates the various catalog elements may be entered manually within the tool or imported from other enterprise systems (e.g., Workday or SAP).

[0057] In Figure 3a, a hierarchical enterprise structure 300 is shown with a structure similar to hierarchical enterprise structures 200a and 200b. Hierarchical enterprise structure 300 includes catalog elements tagged with events and activities.

[0058] Event 1 is represented by catalog element 302. Catalog element 302 is labeled Material 1 (x18). This catalog element 302 indicates that 18 units of the material recorded as Material 1 are required to perform Event 1. For example, Event 1, which creates a chemical solution, requires 18 liters of raw chemical to make the solution. Event 1.4 is represented by catalog element 303 labeled Material 1 (x3). 3 units of Material 1 are required to complete Event 1.4.

[0059] Any suitable catalog element may be displayed on hierarchical enterprise structure 300. In some particular examples, multiple catalog elements may be displayed.

[0060] The diagram in Figure 3a includes a legend 301 that lists the elements of the diagram along with a description of the elements. Legend 301 lists events, activities, selected events, catalog elements, and parent-child arrays.

[0061] Once catalog elements are applied to events, users can filter the enterprise by those catalog elements to isolate models with similar catalog elements (e.g., multiple processes using a common raw material). Users can perform search or sort functions on events within the enterprise to identify, group, or sort events and activities based on the applied catalog elements. For example, a user can query the enterprise by "operational worker" to return all of the events that require an operational worker to perform.

[0062] Each catalog element is associated with an event or activity in any suitable manner. For example, a user may click an option to add a tag to an event. A catalog element may belong to an event because a parent or child event is associated with it. Catalog elements may be assigned to all events or activities in a group, performed in a particular area, performed by a particular set of operators, or grouped into categories to which characteristics may be assigned in any other way.

[0063] 3b is a diagram of a catalog 113 of catalog elements 302. A user interface displays the catalog 113 of catalog elements 302 and allows a user to select a catalog element 302 to apply to an event or activity.

[0064] In one example, the catalog 113 is displayed when a user selects an option or interface object on the hierarchical enterprise structure 300 to add a catalog element to an event or activity or to review the repository of catalog elements associated with the enterprise. The process model application 112 instructs the user interface to display the catalog 113.

[0065] The catalog 113 is a repository of various catalog elements stored within the system. Depending on the nature of the catalog elements, they may be stored in a flat or hierarchical structure. In one example, a hierarchical structure may represent a group or team, which may be made up of smaller teams and / or roles. Alternatively, roles or individuals may not be divided into smaller components and may be captured in a flat list. Locations may also be described hierarchically to indicate points with varying degrees of specificity. For example, a parent catalog element 302 may represent an office building, children may represent floors, and grandchildren may represent conference rooms or offices.

[0066] The catalog 113 may be stored within the process model application 112 , on a third-party device, on the process model server 111 , or at any suitable point logically or communicatively linked to the process model application 112 .

[0067] A catalog element 302 may be applied to an activity or event to record that a specific person or tool is required to complete the activity. For example, an individual may define an activity as "Analyst processes new customer application." Within this activity, catalog elements representing "Analyst" and "New Customer Application" may be applied. When applied to an activity, the data contained within the catalog element object may affect the attributes of the activity.

[0068] For example, in the specification of an "analyst," an average salary for that role might be specified. When applied to an activity, the system utilizes the duration attribute as well as the salary attribute of the "analyst" catalog element to calculate the cost of an individual in that role performing the activity to the business. Additionally, any application of a catalog element may also be reflected in the catalog element object itself. In the previous example, the "analyst" catalog element may include information describing its application within that activity, as well as information describing any other activities to which it may be applied. Any changes made to the catalog element object may affect the activity to which it is applied.

[0069] The catalog 113 is displayed with a first column representing the name of the catalog element (e.g., Application Risk Form or Application and Money Laundering Form). These are the catalog elements 302 that can be selected to apply to an activity or event. Catalog elements 302 can be selected by clicking, dragging, or otherwise indicating that they are selected.

[0070] The second column is a description of the catalog element 302. This column includes a brief summary describing the catalog element 302 and its purpose. Additional columns allow for further description or specification of the catalog element 302. Each column may have a pull-down menu or other interface for entering details about the catalog element 302. For example, for a catalog element 302 in a database entry form, the catalog element 302 may allow for entry of the owner, the size of data entry allowed, the type of database, or any other characteristic of the database entry form.

[0071] When a user selects a catalog element 302 and enters or selects an option for further description or specification, the catalog element 302 becomes associated with an event or activity. The catalog element 302 may appear on the hierarchical enterprise structure 300 attached to or near the event or activity with which the catalog element 302 is associated.

[0072] Like a data dictionary, the catalog 113 defines the people, places, data, materials, tools, objectives, rules, and other resources that the enterprise has available, has implemented, plans to make available, or plans to implement. Attributes specific to a category of the catalog 113 (e.g., a people or place category) are associated with each element to add context to that element. These attributes represent the static, stable characteristics and properties of the people, places, objects, and objectives established in the catalog 113.

[0073] Catalog elements 302 are customizable structures that contain information related to specific items that facilitate work modeled in the process model application 112. Each catalog element 302 can be referenced in an event when selected by a user, or can be specified to be automatically populated with data in an event. When a catalog element 302 is referenced in an event, an application for that catalog element is created to collect data specific to the catalog element in the context of the event. Catalog element applications are automatically created when a catalog element 302 is referenced in an event. Catalog element applications can be used to collect additional data related to the deployment of that catalog element in an event. Data collected from catalog element applications is stored under the catalog element.

[0074] Catalog elements 302 may be associated with one or more categories. The categories for each catalog element may be stored in a database or other memory. The categories may be specified by a user for each catalog element or may be associated in other ways. The categories may relate to any feature, parameter, user, system, or other type of category associated with the catalog element.

[0075] For example, one category of catalog elements 302 may relate to a human-centric view of work activities. This people category may describe the type of person associated with an event or function. For example, a particular activity may typically be performed by a contractor rather than an employee, and thus contractor is a subcategory of the people catalog element. In another example, a particular event may typically be performed by an employee with a required level of training, and thus the people category may be associated with that required level.

[0076] In another example, a team category may be associated with a group of roles that may collaborate within an event. Teams may be nested within one another. For example, HR may be a department with nested departments that include people who specialize in specific aspects of HR (e.g., payroll, training, onboarding, interviewing, and other HR functions).

[0077] In another example, a role category represents a function performed by a specific individual within an enterprise. For example, a senior data analyst may be a role associated with an employee who performs a particular set of tasks or functions for an organization. The capabilities, expectations, costs, and other attributes of a senior data analyst may be associated with that category.

[0078] In another example, the individual category represents an individual within an enterprise. An individual has at least one role within the enterprise. The role may be based on any suitable convention. For example, one organization may identify contractors as employees, while another organization may not. Employee visibility may be controlled by an administrator or HR to protect employee personal information.

[0079] In another example, the location category represents a setting where an activity takes place. Locations can be in digital or physical form. Locations can be nested within one another to describe points of interest with varying degrees of specificity. For example, a location might represent a factory, and a nested location might be a specific floor within that factory, or a location might represent a digital meeting.

[0080] In another example, the tools category represents tools utilized within an event. Tools may be in digital or physical form. Examples of tools may include some specific software applications, some specific computing devices, injection molding machines, moving trucks, or forklifts.

[0081] In another example, a category of data may represent an individual data point or a set of data that can be transferred between activities and modified within an event. For example, a data catalog element could be first quarter expenses, total sales for the year, new subscriptions from a campaign, survey responses, or any other type of data.

[0082] In another example, the materials category represents physical materials that can be utilized, combined, or destroyed within an event. Assembly and waste may be two subcategories of materials intended to capture materials created as a result of activities within an event. In one example, raw materials used to create a polymer may be tagged as a material for an event that manufactures a plastic part. In another example, welding gases are consumed in making the part; welding gases may be a material even though they do not become part of the product.

[0083] In another example, an assembly category represents multiple materials that are combined together to form a new catalog element. The data structure for an assembly may include references to its component parts. For example, if an organization intends to manufacture bicycles, the bicycle may be represented as an assembly of gears, chains, tires, steel, paint, and other components. The assembly category associates each of the components with a category element. Each of the components may also be a category element.

[0084] In another example, a waste category represents material that may be lost within an activity. For example, if an event represents cutting a 5' piece of material into two 2' segments, each processed material generates approximately 1' of waste during the event's activity.

[0085] In another example, an Objectives category represents a category of a catalog meant to contain content intended to guide the design of operations within a tool. For example, an event to assemble a mechanical device that changes frequently may require a set of objectives for each event instance. The event has an Objectives category instance created for each event.

[0086] In another example, the rule category represents specific rules (e.g., policies, regulations, and service level agreements) developed by an enterprise or business entity to control the actions of the enterprise. When an instance of a rule is applied to an activity, the rule may limit other catalog elements that can be referenced or the maximum amount of time the activity must occur.

[0087] In another example, the principles category represents organizational statements that describe what is important to the organization and what it wants to accomplish. Principles may include a vision statement, a mission statement, a purpose statement, values, and goals.

[0088] For each event, metrics are quantifiable measures (e.g., key performance indicators) used to track and evaluate the status of the activity. A catalog exists at the enterprise level, making the catalog a single source of truth for all events within the enterprise hierarchy.

[0089] Within the catalog 113, the relationships that elements of the catalog 113 have with other catalog elements 302 are typically captured in parent-child relationships (child data contains parent data) and tags. Information is then aggregated and distributed based on many parent-child relationships and tags.

[0090] Other relationships between catalog elements can be established using customizable additional fields in the attributes of the catalog elements. For example, a reporting structure can be captured by adding a "reports to" field in a person or role catalog element and filling that field with a reference to another catalog element. The data structure of an exemplary catalog element with additional relationships can be thought of as follows: {Name: [John Doe], Reports to: [Darlene Johnson]}

[0091] As described herein with respect to FIG. 2, when an event is created as a subitem within a larger event, the process model application 112 determines that it is a child event. Upon creating this parent-child relationship, the process model application 112 generates and provides a reference to the associated details. Additionally, when a catalog element is attributed to an activity, the catalog element stores a reference to its own application (its point in the hierarchy and any additional data points associated with that application), and the catalog element's attributes are automatically provided as references. A tagged catalog element then has a reference to the event it was tagged with, which is employed for construction and analysis purposes. When the same activity is added to a different event, the catalog element tagged with the activity may also be added to the new event.

[0092] As shown in FIG. 3a, each higher enterprise level includes all of the catalog elements of the lower enterprise levels for each child event. While the example includes only a single catalog element, any number of catalog elements may be used. For example, Event 1 in hierarchical enterprise structure 300 may have required 18 units of Material 1, but Event 1.2.3 may also require a trained technician, all events in the structure may require a dye room location, Events 1.2.1 and 1.3 may require a dye injector, and Event 1.2.1 may require dye injector instructions. All of the tagged catalog elements associated with any child event are also tagged in that child event's parent event. The top enterprise level is tagged with all of the catalog items necessary to achieve the goal of Event 1.

[0093] As a manager reviews the hierarchical enterprise structure 300, the manager can observe all parts, materials, personnel, instructions, rules, locations, techniques, or other catalog items required to carry out a desired event.

[0094] When catalog elements are rolled up from child activities to parent activities, the hierarchical structure of the catalog may be used to simplify the list of catalog elements included in the parent activity. For example, "Team A" in the catalog may be defined as including "Role A," "Role B," and "Role C." If all three roles are tagged as children of the parent activity, the parent activity may be described as being worked on by "Team A."

[0095] FIG. 3c is a diagram of a hierarchical enterprise structure 300 with horizontal parent-child relationships.

[0096] In the hierarchical enterprise structure 300, a parent event is shown in column L1 as Retail Bank 1. Other parent events on column L1 include Commercial Bank 2 and Investment Bank 3. Each of these is shown as an event, with a dotted line under the event's name and the number of children (e.g., +4). The +4 or other designation after the event indicates that this number of events are children of the parent event. In one example, if the entry in L1 were an activity rather than an event, the dotted line and +4 would not be shown because the activity would not have any child events or activities.

[0097] In the hierarchical enterprise structure 300, Retail Bank 1 is shown highlighted or selected. For example, a user clicks on the icon for Retail Bank 1. When selected, Retail Bank 1 is illustrated in a bolder font, in a different color, not grayed out, or highlighted in any other way. When selected, the children of Retail Bank 1 are illustrated.

[0098] In this example, the four events in L2 are child events of Retail Bank 1. These events are also represented by dotted lines and the number of child events or activities displayed. In this example, Onboarding 1.2 appears highlighted or selected. The five events in L3 are child events of the Onboarding 1.2 event. At the bottom of the L3 column is the option to add a new event. The user may click the + sign and type a name for the new event.

[0099] When a new event is added, a user may enter features or catalog items into the new event to display on the hierarchical enterprise structure 300. If the new event has child events or activities, a new column in L4 may contain the new events or activities that are children of the new event.

[0100] 3d is an illustration of an event details user interface 300d. In some particular examples, a details window of user interface 300d may be displayed on the user interface when an event or activity is selected or otherwise highlighted in hierarchical enterprise structure 300. User interface 300d may be displayed on the right panel of hierarchical enterprise structure 300 or at any other suitable point.

[0101] Event 320 is at level 5-2 and is titled "Onboarding." User interface 300d shows smart description 321, which is a longer, semi-automated description of the action or decision represented by the activity. Other details about event 320 (e.g., a brief description and the tools needed to perform event 320) may also be included.

[0102] User interface 300d may include event type 322, state 323, owner 324, duration 325, parent 326, and event children 327. Any other suitable data may also be displayed within user interface 300d.

[0103] FIG. 3e shows a close-up view of an event 310 or activity.

[0104] A user may wish to see more details associated with an event from hierarchical enterprise structure 300. For example, the user may have identified an event from Figure 3c, and the user may wish to see the features or catalog elements associated with that event displayed. The user may click on the icon for the identified event or otherwise select the event to view.

[0105] Selecting an event presents an expanded view of the event 310. For example, the hierarchical enterprise structure 300 expands on the selected event 310. In another example, a new screen is displayed with the selected event 310. In another example, a pop-up window or other overlay window of the event 310 is displayed.

[0106] A close-up view of the event 310 may display further details about the event, as shown in FIG. 3e. For example, inside the icon for the event 310, the name of the event and a list of catalog elements associated with the event (e.g., teams associated with the event) are displayed. The catalog elements may be displayed as links, icons, or other representations of the catalog elements. The event is displayed with the catalog elements inside a circle representing the event. Alternatively, the event 310 may be displayed with any other data (e.g., name, child events, child activities, functions, or any other suitable data) or combination of data inside the circle.

[0107] A line 311 emanating from the right portion of the circle indicates that icon 312 to the right of L6-4 is a child event of event 310. Other child events are shown below the screen along a line 313 emanating from the bottom of Figure 3e.

[0108] In the right portion of the display is a window 314 that shows details about event 310. Event 310 is at level 6-3 and is titled "Evaluate and save new customer application." Window 314 may be similar to user interface 300d shown in FIG. 3d.

[0109] 4a and 4b illustrate an exemplary user interface that contextualizes activity within an event.

[0110] User interface 400 shows a process model with activities such as event L6-2 and event L6-3. The events indicate the flow of the process model, and each activity may include catalog elements and other elements (e.g., "Evaluate and save new customer application"). Each represented event or activity may also be an event in another process model. User interface 400a includes a panel that displays user interface 300d, as described in FIG. 3d.

[0111] 4b illustrates an alternative user interface 400b that may be used in combination with or in place of user interface 300d. Elements or options in user interface 400b may be similar to elements or options in user interface 300d.

[0112] User interface 400b shows the user a display describing the attributes of that event (e.g., activity 1.2.3-7). Activity 1.1.2.3-7 is a child of activity 1.2.3 Review. Process model application 112 can fill in one or more of the inputs on user interface 400b with data based on a structure (e.g., the structure of FIG. 4a). In another example, a user can input data into user interface 400b.

[0113] User interface 400b shows a short description within user interface 300d, which is a system-generated short description for the action or decision represented by the activity. The illustrated short description is Evaluate and save new customer application. The process model application 112 may derive the short description from the specification of the activity within the structure designed for the process model. Alternatively, the user may generate the short description.

[0114] User interface 400b shows smart description 403, which is a longer, semi-automatic description of the action or decision represented by the activity. User interface 400b shows type tag 404, which is a tag that identifies whether the activity represents an action or a decision.

[0115] The user interface 400b lists the activity's parent 405 and one or more of the activity's children 406. In another example, the user interface 400b shows an entry point for the activity's parent 405 and one or more of the activity's children 406.

[0116] User interface 400b shows one or more inputs to identify catalog elements of data or materials that inform or are inputs for that particular activity. User interface 400b shows one or more outputs to identify data or materials that result in or are outputs for that particular activity. Input / output associations identify materials that result in or are outputs for that particular activity.

[0117] The user interface 400 shows one or more catalog elements 407 that may be tagged with an activity. As described herein, catalog element tags are used to identify the catalog elements involved in or associated with that particular activity. In this example, two people tags, one material tag, and one instruction tag are displayed.

[0118] The user interface 400 shows any associated custom attributes 409. Attributes may be based on an organization's unique needs or any specific characteristics of an activity. Attributes may alternatively or additionally be referred to as operational parameters. Attributes may be attributes of catalog elements, catalog element applications / tags, activities, events, or functions displayed within the structure. Attributes may consist of trends, characteristics, factors, or other types of attributes. The purpose of attributes is to collect and analyze qualitative information about the nature of the events represented within the structure.

[0119] One category of attributes is represented by tendencies 408, which are user-input binary data points used to calculate characteristics, as described herein. The tendencies available for elements within each structure in the process model application 112 are driven by the structure's attributes. For example, the following tendencies: reflective, proactive, reactive, or iterative may be selected to describe the mindset of employees conducting an event. In a further example, the following tendencies: precision / accuracy, speed, cost, efficiency, innovativeness, quality, socialization, or risk aversion may also be selected to describe the employer's priorities related to the event.

[0120] Table 1 provides examples of trends and trend attributes. [Table 1-1] [Table 1-2]

[0121] One category of attributes is represented by a characteristic, a universal metric calculated based on selected tendencies within a structure. The same characteristic can be shared across catalog elements, catalog element instances, activities, events, and functions. For example, the system might look at all of the tendencies selected in the cognitive / problem-solving category and determine that the event is primarily oriented toward requiring abstract thinking and occurs in a constrained environment.

[0122] Factors allow employees to submit their feedback / experiences directly to the event, including but not limited to, in the form of trend input, allowing designers to use this data to inform future design decisions. For example, if a designer designs an event to have democratic decision-making, and factors returned from employees indicate that the decision-making process is considered absolute, the designer may infer that the mix of people running the event may not be optimal.

[0123] Where appropriate, the process model application 112 system assists in contextualization by extracting relevant information from parent activities (e.g., the parent activity object, owner, inputs (material or data type catalog elements that provide information for the event), outputs (material or data type catalog elements that are the product of the activity), and references to catalog element tags that are not treated as inputs or outputs). The process model application 112 can also automatically obtain quantifiable and partial data from parent activities and adjust child work activities to ensure that the child activities comply with the requirements of the parent activity.

[0124] In one example, a parent work event at a higher enterprise level includes a rule that the event must not take more than 60 minutes to perform. The time requirement information is automatically distributed to child work activities at lower enterprise levels so that the sum of the times for any linear activities at one or more lower enterprise levels cannot exceed 60 minutes. That is, the process model application 112 extracts any time requirements (e.g., in the rules of the child activities), determines the sum of the total time to complete each of the child activities, and compares that sum to the time requirement of the event.

[0125] If the sum is greater than the time requirement of the event, the process model application 112 may flag the event as having an error or conflict and display this to the user in the form of a smart traffic light. The process model application 112 monitors the activity and, if the requirement is violated, alerts the user to make corrections at a higher level. The user or other operator may modify the rules of the event or child activity to remove the conflict from the rule.

[0126] In addition to automatically aggregating and distributing information upon detecting parent-child relationships, the process model application 112 employs system logic to control which attributes are distributed up and down the hierarchy of the catalog. Additionally, a user can manually adjust any qualitative attributes distributed up or down based on parent-child relationships. For example, if an event requires a location in an HR office to protect employee privacy, a user may enter a requirement that any child activities of the event must also occur within the HR office.

[0127] 5 illustrates the dynamic construction of activity explanations in the context of an event 500. Dynamically constructed explanations are also referred to herein as smart explanations.

[0128] Each activity in the process model application 112 has a smart description field where a user can add a longer description of the action or decision represented by the work event. This smart description may then be used to populate the short description field. For example, the process model application 112 may extract the first verb-noun combination in the smart description and insert that combination into the short description field.

[0129] Smart descriptions of activities are constructed within the process model application 112 workspace used to build the structure. The process model application 112 allows users to create smart descriptions through an easy-to-use, semi-automated fill-in-the-blank procedure as activities or events are added to the process model. This process allows individuals to populate smart descriptions with data by directly drawing elements from the enterprise's catalog of elements 113 or by creating new elements. By allowing users to directly pull elements from the catalog 113 and tag these elements within the text of the description, a centralized source of data points that are easily referenced throughout the enterprise is further established. Catalog elements tagged within the description can also be populated with data as catalog element tags for that activity.

[0130] Figure 5 illustrates the dynamic creation of a smart explanation. In step 1, the user begins adding a smart explanation. As illustrated, activity 1.234 is explained. The cursor is presented at the top of the window in step 1. The suggested beginning for the sentence is the word "The." The process model application 112 suggests determining a noun and a verb for the explanation.

[0131] The smart explanations are structured into two types of sentences: informational sentences and detailed sentences. The process model application 112 dynamically determines what type of sentence an individual is constructing based on syntax and makes suggestions about the type of language to use to complete the sentence. In this example, the process model application 112 suggests syntax based on the format of the informational sentence.

[0132] In step 2, the user added a portion of the smart description. The process model application 112 continues to suggest syntax based on the format of the information sentence. The user enters "analyst reviews," and the process model application 112 suggests "[noun]" as the next input. The process model application 112 has determined that the information sentence has been entered using a noun that performs a verb on an object.

[0133] In step 3, the process model application 112 recognizes that the user is adding a noun as the object of the sentence and presents the user with a drop-down list of related catalog elements to select from. The display of related catalog elements may be presented in any other suitable format (e.g., a pop-up window or a split screen). The related catalog items may be based on any logical decision of the process model application 112. For example, suggestions may be based on input by the user relative to previous smart descriptions, input by other users, catalog items typically associated with some particular type of activity, or any other relevant data.

[0134] Once a sentence is constructed in the smart description field, the process model application 112 displays catalog items applicable to the activity and, if relevant, fills the smart description with data from these items. This interaction can be accomplished by auto-population, drag-and-drop, or any prompting from the user. If the relevant element is not in the catalog 113, the process model application 112 allows the catalog item to be added directly from the smart description. The new catalog item is stored in the catalog 113 and can be presented to fill subsequent smart descriptions with data.

[0135] Catalog elements may be suggested in the display based on their association with an activity (e.g., activity 1.234). A catalog item may be relevant because it was previously associated with a similar activity or is a frequent catalog item for the user. In another example, a catalog element may be determined to be relevant from its association with a parent, sibling, or child activity of the described activity. For example, if a parent event has a catalog element of a specific time period (e.g., "Weekly"), the described activity may be populated or auto-populated with data from the same catalog element in a drop-down menu. In another example, if a sibling event has a catalog element of a specific point (e.g., "File Room"), the described activity may be populated or auto-populated with data from the same catalog item in a drop-down menu.

[0136] A catalog element may be tagged to an activity at the same time that the catalog element is selected for a smart description. That is, if a user selects the "Trained Technician" catalog element from a drop-down menu or other selection menu and adds it to a smart description, the "Trained Technician" catalog item may also be tagged to the activity and displayed at other points or presentations of the activity (e.g., on the structure).

[0137] The process model application 112 may employ predictive text (to predict catalog elements based on typed characters and predict the next verb based on typed characters) and smart tags (to allow individuals to tag existing catalog elements) when a user enters a smart description.

[0138] Smart description of activities As described, the process model application 112 utilizes smart descriptions of activities that may describe actions that occur within a tool. Similar to the process described for the structure of smart descriptions associated with regular activities, smart descriptions of activities may be composed of two types of sentences: information sentences and detailed sentences.

[0139] Information statements are designed to provide context and may be similar to writing conditions in programming. Information statements are typically constructed through condition clauses (to provide context for the rest of the smart description of the high-level automated activity) and action clauses.

[0140] Informational text format (by clause type) The following sentence structures are examples of informative sentences:

number

[0141] In the examples throughout this section and subsequent sections, italicized clauses or words do not need to be included in the sentence. Italicized clauses are optional. In this and other examples, [X...Y] indicates that between X and Y words or clauses may be used at this point. X and Y may represent any number of minimum or maximum words or clauses, respectively. For example, different examples may use [1...4], [0...5], or any other suitable example. [1...4] indicates one to four words or clauses, while [0...5] indicates zero to five words or clauses.

[0142] Conditional clause format (by part of speech and catalog element) Conditionals are generally constructed using the following syntax: (Conjunction (If, While) or Preposition (On, For, Before, etc.)) + [1...5] ((Noun or Catalog Element) + (Verb or Adjective) + (Adjective or Noun))

[0143] Below are three examples using this format. Note that the examples are clauses, not complete sentences. Example 1: If data field 2 equals true, then data field 3 equals false Example 2: On Wednesday Example 3: At 10 p.m.

[0144] Action clause format (by part of speech and catalog element) Action clauses are generally constructed using the following syntax:

number

[0145] Below are three examples using this format: Example 1: BUF / RFP adjusts headcount by salary grade Example 2: BUF / RFP adjusts headcount by salary grade for individual cost centers Example 3: John takes out the trash for the day

[0146] Conditional clauses and action clauses may be combined to form sentences. Multiple combined conditional clauses and action clauses can be combined as needed. When conditional clauses and action clauses are combined, the format conforms to the following syntax:

[0147] Informational text format (by clause type)

number

[0148] Format of informational text (by part of speech and catalog element)

number

[0149] Below are four examples using this format: Example 1: On Tuesday, BUF / RFP adjusts headcount by salary grade. Example 2: When reviewed quarterly, the BUF / RFP adjusts headcount by salary grade for individual cost centers Example 3: At 10 PM on Tuesday, John takes out the trash for the day.

[0150] A specification statement is designed to provide further details that complement an information statement. A specification statement may reference a catalog element of a tool, data, or material that is listed in the actions section of the associated information statement.

[0151] For example, if the information statement is "At 8:00 AM, industrial machine B produces material D from material A," the detailed statement may refer to the following: Industrial Machinery B Material D Material A

[0152] The full specification may be as follows: Industrial Machine B produces Material D within 10 minutes.

[0153] Detailed text format (by clause type) The specification sentence itself consists of an action clause, as shown below. Action clause + *Conjunction (And, Or)* + *[0..3] Action clause*

[0154] The action clause can be constructed based on the syntax adopted for action clauses in informational sentences. When the conditional clause and the action clause are combined, the format conforms to the following syntax:

number

[0155] Detailed text formatting (by part of speech and catalog element)

number

[0156] Below are four examples using this format: Example 1: Headcount adjustments must be stored in a management database and can be retrieved at any time. Example 2: Garbage is thrown out every day

[0157] In step 5, the process model application 112 receives input from the user who completed the second sentence and begins constructing the third sentence. The process model application 112 suggests syntax based on the format of the detailed sentence.

[0158] In step 6, the process model application 112 receives input from the smart explanation input field instead of completing the third sentence. In this example, the user did not want a third sentence for the smart explanation.

[0159] In step 7, the process model application 112 automatically generates a short description based on the verb-noun combination, i.e., the verb and the verb object in the smart description. In this example, the initial was "review" and the short description of the review was "headcount adjustment." The short description field may be the title of the element (e.g., element 1.234). When this event, activity, function, or other element is referenced, the short description field may appear as the identifier of activity 1.234.

[0160] 6 illustrates the structure of work parameters such as characteristics, trends, and attributes in events. To contextualize and compare activities, events, and catalog elements including events with categories of people, places, data, tools, materials, instructions, and other categories in the enterprise (e.g., catalog elements as described herein) within the process model application 112, the process model application 112 provides a set of activity and catalog element parameters. The process model application 112 categorizes the parameters as attributes, trends, and characteristics.

[0161] One set of attributes that are not trends or characteristics of an activity or catalog element includes owner. For example, attributes of an activity may include owner, duration (how long it takes to complete the activity), cost associated with the activity, or other suitable attributes. For catalog elements, attributes may include owner, training requirements (training available for a specific tool), motivation (a description of what motivates a specific role / employee), or other suitable attributes. In some particular examples, attributes are added by individuals as they contextualize activities and catalog elements. In other examples, the process model application 112 may extract attributes from other data (e.g., from a database or from previous instances of the event).

[0162] A set of tendencies represents a set of descriptors selected based on attributes assigned to a catalog element or attributes assigned to an activity and catalog element. The tendencies specify the nature of the activity and catalog element (e.g., that the activity occurs in a highly safe work environment or that the activity has a high degree of feedback). Similar to attributes, users can select or deselect relevant tendencies when contextualizing the activity and catalog element through a set of prompts.

[0163] Finally, the set of characteristics provides a consistent, metrics-based set of descriptors for comparing both activities and catalog elements in the context of the process model application 112. Characteristics represent different dimensions that an activity or catalog element may have and act as a spectrum. For example, a spectrum may indicate that an activity relies on structural rather than abstract thinking. When viewed as a set, characteristics can be applied to both lower-level activities and the entire enterprise. Unlike attributes and tendencies, characteristics are automatically generated based on a set of algorithmic relationships that directly reference the tendencies.

[0164] FIG. 6 illustrates a user interface 600 for allowing a user to specify attributes and trends to characterize activities and catalog elements through a work parameter structure. The user interface 600 presents the user with a list of activity attributes 601 for selection. The user may choose not to address / interact with the attribute. For example, the user may enter input for number, owner, and estimated cost. Activity trends 602 are generated based on the structure's selected attributes. Activity trends 602 may vary from structure to structure. Example activity trends may include trends such as high pressure, transactional, employee growth prioritized, or repetitive.

[0165] The process model application 112 receives the activity trend selection and generates activity characteristics as output. The activity characteristics 603 list is an optional display of the characteristics generated to further contextualize the activity. This display can be a series of slider bars, as shown below activity characteristics 603. The display lists the generated characteristics, with the slider bar indicating a magnitude for each characteristic. The magnitude can relate to the amount of that characteristic associated with the activity. For example, a generated characteristic can be "collaborative." That is, the characteristic describes how collaborative an activity may be based on how many employees must work together to perform the activity. The slider bar can move from left to right based on how closely employees must work together. Any other suitable display, graph, list, or chart (e.g., a bar graph or simply a list of characteristics with a magnitude description) can be used to display the characteristics.

[0166] In the user interface 600, a list of catalog element attributes 604 is presented to the user. Based on the enumerated catalog element attributes, the system generates a list of possible trends that can be used to further describe the catalog element. Catalog element trends 605 are generated based on the catalog element attributes. The catalog element trends 605 can vary from structure to structure. For example, a user may select trends 5, 7, 8, and 11 to further describe the catalog element.

[0167] The process model application 112 receives the selection of the catalog element trend and generates the catalog element characteristics as output. The list of catalog element characteristics 606 is an optional display of the characteristics generated to further contextualize the activity. This display can be a series of slider bars, as shown under activity characteristics 606. This display lists the generated characteristics, and the slider bar indicates where the activity falls within each characteristic's width / range / dimension. The magnitude can relate to the amount of that characteristic associated with the catalog element. Any other suitable display, graph, list, or chart (e.g., a bar graph or simply a list of characteristics with a magnitude description) may be used to display the characteristics. This display may show the range of the characteristics on a spectrum as absolute values ​​or on any other suitable scale.

[0168] The process model application 112 provides the algorithmic relationships and application of operational parameters (traits, trends, and factors).

[0169] Operating parameters throughout the process model application 112 may have algorithmic relationships with other parameters. For example, a user may have a set of tendencies to review and select / deselect, which have direct relationships with characteristics specific to activities and catalog elements, as described in FIG. 6. As an individual selects available tendencies, the process model application 112 translates the effect of the selected / deselected tendencies on the activity's characteristics. For example, if trend 1 and trend 2 are selected, characteristic B will move to one end of the spectrum based on the trend selection. As the user reviews different tendencies, the user sees the activity's characteristics based on the tendencies selected / deselected.

[0170] In one example, a characteristic of an activity may be the level at which the activity is implicit or implicit. As the characteristic becomes more implicit or more implicit, the characteristic moves on a spectrum between the two. In an example where the activity is more implicit, the user may determine that the activity requires someone with a lot of experience to perform it well. In an example where the activity is more implicit, the user may determine that someone with any amount of experience can perform the activity well.

[0171] Tendencies below a trait may be more immediate and familiar than higher-level traits. For example, a tendency toward an activity may indicate that creativity is required but collaboration is not. The activity would then be judged as more implicit but not as implicit. Without collaboration, employees would have fewer opportunities to discuss the work required. The more creativity implied, the more difficult it is to measure performance. These tendencies support the trait that the activity is more implicit.

[0172] Figures 7a and 7b illustrate the contextualization and storage of activity data and material movement. This process allows users to provide information about different activities through inputs, outputs, and input / output associations, and to identify the materials (both physical and digital) that are the product of the activities.

[0173] A user of the process model application 112 can tag any existing data and material catalog elements, or data catalog elements from a catalog, as inputs or outputs specific to an activity. Tagging catalog elements associates inputs and outputs between two or more activities by using input / output tools in the process model application 112. A user can associate inputs and outputs when creating an activity or after it has been created. Once the association is made, the user has the opportunity to add appropriate attributes (e.g., type of association / transfer method, association / transfer time, or other attributes). By adding this information, the process model application 112 can more accurately identify the amount of time an event will take, the path the data or material will take, the steps that specific people must take, or any other suitable process flow requirements.

[0174] In the example of FIG. 7a, user interface 700 shows activity 1.2-1 tagged with material 1. Material 1 moves to activity 1.2-2 and then to activity 1.2-4. The material can be an input or output of activity 1.2-1. A line emanating from material 1 can indicate the flow of material 1, continuing to activity 1.2-2 and then to activity 1.2-4. Similarly, data catalog elements can be tagged and tracked through the process flow in a similar manner. For example, if a database needs to perform multiple activities, user interface 700 can follow a line from one activity to another, with the same database tagged in both activities. In alternative examples, other types of catalog elements (including, but not limited to, people, employees, information, materials, or any other resource) can be tagged and tracked through the process flow as well.

[0175] Within an event, users can highlight specific catalog elements and input / output associations, bringing the specific elements to the foreground while irrelevant and overlapping input / output associations recede into the background. As shown in Figure 7a, the flow for Material 1 is displayed in a dark color, while the flow for Material 2 is grayed out.

[0176] Additionally, lines between activity catalog elements indicate the amount of time required for the flow between activities. In this example, Material 1 takes 12 minutes to progress from Activity 1.2-1 to Activity 1.2.2. Material 1 takes 30 seconds to progress from Activity 1.2.2 to Activity 1.2-4. Time requirements may be based on past usage time, imposed rules, guidelines, or any other criteria. If an activity (e.g., Activity 1.2.1) takes a longer amount of time than required, a tag may notify the user that the subsequent activity is unlikely to meet the time requirement.

[0177] In the example of FIG. 7b, user interface 700 shows activity 1.2-1 tagged with person 1, activity 1.2-2 tagged with person 2, activity 1.2-3 tagged with person 2, and activity 1.2-4 tagged with person 1. In this example, no lines are drawn between one or more people, but tagged people may be highlighted based on other indicators. In FIG. 7b, person 2, associated with activity 1.2-2 and activity 1.2-3, is highlighted. Person 2 is highlighted by appearing in bold, while the other tagged items are grayed out. Highlighting person 2 may visually notify the user that the two activities require the same person.

[0178] Creating automated process flows / process model-driven work implementation specifications (user stories, functional requirements, etc.) The process model application 112 is a tool that automatically transforms the dynamic events created within the process model application 112 into several outputs for users, including ultimately a work implementation specification. This specification allows various users to transform dynamic, hierarchical process models and process flows into a work implementation specification, providing users with user stories, functional requirements, and other documents that describe the process.

[0179] The activities described above have primarily been associated with actions or decisions driven by humans (e.g., to create a product, perform a task, or make a decision). However, activities may also reflect steps in a process that are driven by tools, equipment, or other automated actors. Such activities may be described as automated activities.

[0180] An automated activity represents a step in a process that occurs without human intervention, for example, within a tool or by a piece of equipment. In one example, a user submits a report into an enterprise system, which automatically saves the file and distributes the file to various different file locations. The portion of the activity associated with saving the file and distributing the file is an automated activity because the system performed the task automatically without user direction.

[0181] Some of the same attributes identified for typical activities (e.g., owner or task duration) are also identified for automated activities. In addition, other types of attributes (e.g., logic / calculation, error, error resolution, preceding format, and subsequent format attributes) may also be identified. This identification may be done through instances and states of data and material catalog elements.

[0182] Like typical activities, automated activities can be composed of other activities (e.g., other automated activities). If the process model application 112 recognizes that a non-automated activity (that is a child of an automated activity) is beyond human perception, e.g., requires an action that requires a significant amount of human interaction, the process model application 112 pushes the user to convert the non-automated activity into an automated activity.

[0183] Similar to the human-related activities described herein, each automated activity (e.g., a step in a business process driven by a tool or equipment) in the process model application 112 may have a smart description field in which a user may add a longer description of the automated action or decision represented by the work activity.

[0184] Like other smart explanations described herein, smart explanations for automated activities are constructed through semi-automated predictive / guiding text in the process model application 112. This procedure allows individuals to pull elements directly from the enterprise's catalog or to create new elements. Allowing users to pull elements directly from the catalog and tag those elements within the text of the explanation further establishes a centralized source of data points that are easily referenced throughout the enterprise. Any catalog elements tagged within the explanation are also populated with data as catalog element tags for that activity.

[0185] As more smart explanations are added to the system, they enable the process model application 112 system to detect patterns that indicate which types of activities specific catalog elements are involved in and which types of actions occur within certain types of processes. As the number of smart explanations increases and are associated with activities, these insights can be integrated into the process model application 112 and automatically populated by the system into events or activities through pre-generated smart explanations and activities. The system will be able to recognize the types of activities that belong to certain types of processes and employ that knowledge through pre-generated activities. With the input of additional data, the process model application 112 improves its ability to interpret the syntax, process, and format of individuals creating the first draft of a smart explanation. The process model application 112 may allow for more flexible structure based on the breadth of input.

[0186] Like the human-related activities described herein, automated activities can be composed of one or more other activities. Smart descriptions for these automated activities can be distinguished based on whether the activity is a higher-level automated activity composed of other automated activities, or a lower-level automated activity.

[0187] The smart explanation of a lower-level automated activity operates at the lowest level of detail. In one example, the process model application 112 recognizes that there are two automated activities (e.g., one activity is a child of the other) that employ the smart explanation of a lower-level automated activity. The process model application 112 generates a smart signal that informs the user that the smart explanation of the lower-level automated activity should only be employed at the lowest level of detail.

[0188] Additionally, when the process model application 112 recognizes that the user has employed a smart description of a higher-level automated activity having multiple action clauses, as described herein, the process model application 112 determines whether the automated activity has any child automated activities. If not, the process model application 112 suggests, and (if the user chooses to create) automatically creates, child automated activities for the user to complete based on actions in the higher-level automated activity's smart description. The user is notified via a smart signal that a child automated activity has been created.

[0189] Smart explanations of high-level automated activities A high-level,smart description of an automated activity may describe the actions,that occur within a tool.,Similar to the process described for the structure of,smart descriptions associated with regular activities, smart descriptions,of automated activities may be composed of two types of,sentences: informational sentences and elaboration sentences.

[0190] Information statements are designed to provide context and may be similar to writing conditions in programming. Information statements are typically constructed through condition clauses (to provide context for the rest of the smart description of the high-level automated activity) and action clauses.

[0191] Informational text format (by clause type) The following sentence structures are examples of informative sentences:

number

[0192] In the examples throughout this section and subsequent sections, italicized clauses or words do not need to be included in the sentence. Italicized clauses are optional. In this and other examples, [X...Y] indicates that X through Y words or clauses may be used at this point. X and Y may represent any number of minimum or maximum words or clauses, respectively. For example, different examples may use [1...4], [0...5], or any other suitable example. [1...4] indicates 1 through 4 words or clauses, while [0...5] indicates 0 through 5 words or clauses.

[0193] Conditional clause format (by part of speech and catalog element) Conditionals are generally constructed using the following syntax: (Conjunction (If, While) or Preposition (On, For, Before, etc.)) + [1...5] ((Noun or Catalog Element) + (Verb or Adjective) + (Adjective or Noun))

[0194] Below are three examples using this format. Note that the examples are clauses, not complete sentences. Example 1: Data field 2 equals true and data field 3 equals false Example 2: On Wednesday Example 3: At 10 p.m.

[0195] Action clause format (by part of speech and catalog element) Action clauses are generally constructed using the following syntax:

number

[0196] Below are three examples using this format: Example 1: Database A performs multiple system checks Example 2: Tool C turns a piece of wood into two pieces Example 3: Industrial machine B produces material D from material A

[0197] Conditional clauses and action clauses may be combined to form sentences. Multiple combined conditional clauses and action clauses can be combined as needed. When conditional clauses and action clauses are combined, the format conforms to the following syntax:

[0198] Informational text format (by clause type)

number

[0199] Format of informational text (by part of speech and catalog element)

number

[0200] Below are four examples using this format: Example 1: On Tuesday, Database A runs multiple system checks Example 2: When data field 2 is equal to true, data field 3 is equal to false, and the time is 10:00 PM, industrial machine B produces material D from material A. Example 3: If data field 2 equals true, then database 2 is isolated from data table 5 and database 3 is isolated from data table 7 Example 4: If data field 2 equals true, then database 2 is separated from data table 5, else database 3 is separated from data table 7

[0201] A specification statement is designed to provide additional details that complement an information statement. A specification statement may reference a catalog element of a tool, data, or material that is listed in the actions section of the associated information statement.

[0202] For example, if the information statement is "At 8:00 AM, industrial machine B produces material D from material A," the detailed statement may refer to: Industrial Machinery B Material D Material A

[0203] The full specification could be: Industrial Machine B produces Material D within 10 minutes.

[0204] Detailed text format (by clause type) The specification sentence itself consists of an action clause, as shown below. Action clause + *Conjunction (And, Or)* + *[0..3] Action clause*

[0205] The action clause can be constructed based on the syntax adopted for action clauses in informational sentences. When the conditional clause and the action clause are combined, the format conforms to the following syntax:

number

[0206] Detailed text formatting (by part of speech and catalog element)

number

[0207] Below are four examples using this format: Example 1: Industrial machine B uses sub-machine 3 and sub-machine 4 Example 2: Material D is formatted onto a 16-inch disk Example 3: Industrial Machine B completes this in 10 minutes Example 4: Industrial Machine B completes this in 10 minutes and Industrial Machine B employs 30 joules of energy.

[0208] Smart explanation of low-level automated activities Unlike the smart description of a higher-level automated activity, the smart description of a lower-level automated activity is not separated into two types of sentences and may refer to tagged elements in the smart description of the higher-level automated activity. The smart description of a lower-level automated activity is constructed with a similar but simplified syntax compared to the smart description of a higher-level automated activity. In one example, this simplified syntax may consist of one conditional clause and one action clause that depends on the conditional clause.

[0209] The smart description of a lower-level automated activity operates at the lowest level of detail because it has no further child activities. If the system recognizes that of two automated activities employing a smart description of a lower-level automated activity, one activity is a child of the other, the system generates a smart signal that informs the user that the smart description of the lower-level automated activity should only be employed at the lowest level of detail.

[0210] If the system recognizes that a higher-level smart explanation is being utilized in the lowest-level model, the system notifies the user via a smart signal that the activity can be further decomposed at the lower level so that the activity can be explained by the smart explanation of the lower-level automated activity.

[0211] Smart explanation of low-level automated activities (by clause type)

number

[0212] Conditionals are generally constructed using the following syntax:

number

[0213] Below are three examples using this format: Example 1: Data field 2 equals true and data field 3 equals false Example 2: On Wednesday Example 3: At 10 p.m.

[0214] Action clauses are generally constructed using the following syntax: Action clause format (by part of speech and catalog element)

number

[0215] Below are three examples using this format: Example 1: Database A performs multiple system checks Example 2: Tool C turns a piece of wood into two pieces Example 3: Industrial machine B produces material D from material A

[0216] Conditional clauses and action clauses may be combined to form sentences. Unlike smart descriptions of higher-level automated activities, smart descriptions of lower-level automated activities can only contain one action clause. When conditional clauses and action clauses are combined, the format conforms to the following syntax:

[0217] Smart explanation of low-level automated activities (by clause type)

number

[0218] Smart explanations of low-level automated activities (by part of speech and catalog element)

number

[0219] Below are two examples using this format: Example 1: Every Monday, a computer program transforms data field 1 into data field 2 Example 2: When data field 2 is equal to true and data field 3 is equal to false, the industrial machine separates material A into material B and material C.

[0220] FIG. 8 is a diagram 800 of the dynamic construction of draft user stories in an event, according to some specific examples.

[0221] The process model application 112 can generate draft user stories specific to work occurring during different activities and events. Within the process model application 112, users can view and edit the user stories automatically generated by the process model application 112 and, if appropriate, export those user stories from the process model application 112.

[0222] A user story is a standard documentation method that describes a goal for a specific person and how future work (e.g., software development) might achieve that goal. User stories are often used in software development to break down a work process into smaller tasks that developers can work on and produce. Developers can then test the software to verify that it achieves the set goals.

[0223] The process model application 112 adds value to standard user stories by indicating the exact moment in a work event when goals must be achieved, automatically establishing relationships between user stories / functional requirements, and turning manual, difficult tasks in the software development lifecycle into automated activities.

[0224] Many draft user stories may be generated in the background based on the activity's smart description 803, short description 805, and catalog elements 804 tagged to the specific activity. Diagram 800 shows the smart description 803 for activity 1.234. Activity 1.234 is a headcount reconciliation review. The smart description 803 and short description 805 may be created at least as described with respect to FIG. 5. Some aspects of the draft user story are not automatically generated. For example, this includes value statements (which may include references to trends and characteristics) or user-generated value statements (such as statements entered via a ly text field).

[0225] Individuals can sort and filter draft user stories based on the activity and catalog element (e.g., tool catalog element) with which the user story is associated. Typically, user stories follow the following format 801 to ensure consistency and understanding across the organization:

[0226] As a _[role / employee catalog element]_, I want to _[brief description of activity]_ so that I can _[list of related instructions, catalog elements, trends, characteristics, other activities, and user-generated value statements]_.

[0227] In some specific examples, user stories are generated only at the role and employee level. Draft user stories are generated at this level so that they are actionable and not so large that they are impractical. A draft user story can be populated with only one role / employee catalog element. This catalog element fills the first blank in the draft user story template. If an activity contains more than one role / employee catalog element, multiple user stories are generated for each of those catalog elements. For example, if an activity tags three roles, the activity will result in three draft user stories, one for each role. Users may have a preference for either generating individual user stories for each user with the same action or generating a user story that can be applied to multiple users.

[0228] In this example, there are two employee catalog elements: "Analyst" and "Project Manager 2." Since each role / employee catalog element is associated with a single user story, the element "Analyst" is inserted into draft user story 802 in the first blank for this user story. "Project Manager 2" is associated with the second user story.

[0229] To fill in the second blank in the draft user story template 801, the activity's short description 805 is directly copied. For example, if an activity has a short description about "Headcount review" and the analyst role catalog element is tagged to the activity, the corresponding draft user story 802 should say, "As an analyst, I would like to review headcount..."

[0230] Additionally, the draft user story includes a list of short "so that" statements. These statements fill in the third blank in the draft user story template. These "so that" statements can relate to associated instructions, catalog elements, trends, characteristics, other activities, and value associated with user-generated value statements.

[0231] For example, a "so that..." statement may correspond to the creation of a data catalog element. This creation may occur when the data catalog element is tagged to an activity and recorded as an output of that activity. In diagram 800, the "so that..." statement is derived from Goal 2 in catalog element 804. The completed (fill-in-the-blank) draft user story 802 states, "As an analyst, I would like to review headcount adjustments to achieve Goal 2."

[0232] Another example output may be "generate a total purchase data point." In one example, the draft user story then reads, "As an analyst, I would like to review the headcount adjustments so that I can generate a total headcount data point."

[0233] An additional "to be able to" statement can be added. For example, "As an analyst, I would like to perform headcount reviews to generate total headcount data points and experience a collaborative environment." This additional statement can be added if the activity is recorded as having a collaborative tendency.

[0234] Other example "so that" statements might include "so that I can follow organizational rule 2.34," "so that I can grow professionally," "so that I can achieve my sales goals," or "so that I can complete activity 4.53."

[0235] When a user defines an instruction catalog element, the user enters whether the instruction "seeks to follow," "strictly follows," "achieves," or any other suitable modifier. Thus, the section immediately following "so that ____" may be driven by what was previously defined in the instruction catalog element.

[0236] Other exemplary "to be able to" statements include the following: Instruction-based, automatically generated "to be able to..." statements so that you can aim to follow instruction catalog elements To be able to strictly follow instruction catalog elements To be able to achieve the instruction catalog element So that you can aim to achieve the instruction catalog element Human-based, user-generated "to be able to..." statements To be able to work with human catalog elements Data- or material-based, automatically generated "to be able to" statements To be able to generate data or material catalog elements Location-based user-generated "to be able to" statements Location catalog elements available Tendency and trait-based user-generated "to be able to" statements _tendencies or characteristics_ to experience the workplace Other activity-based auto-generated "so that" statements (when other "so that" statements cannot be auto-generated) To be able to complete a brief description of the subsequent activity

[0237] Optionally, an individual can add a user-generated value description via a free text field to complete the "be able to" description. For example, the process model application 112 may provide a user interface object that receives text input from a user on the employee computing device 130. In another example, the process model application 112 may provide a series of drop-down menus or auto-fill suggestions to receive selections from the user. A user may enter text input to specify a "be able to" result that is not available from the smart description or short description. For example, a user may have a non-intuitive reason for performing a task that is not available through the process model application 112.

[0238] Individuals may have limited functionality with regard to editing draft user stories. This functionality includes the ability to update the "so that" statement to reflect the most accurate representation of the user story, add additional user stories that cannot be generated automatically (e.g., user stories that include trend- and property-based "so that" statements or user-generated value statements), or delete draft user stories. For example, the process model application 112 may create a user story that no longer reflects the reason for performing a task. The user may edit or delete the user story as needed.

[0239] If a tool is mentioned in the activity where a user story is generated, the system also links that user story to the mentioned tool. This link allows traceability between the user story and the associated functional requirements if the user chooses to generate both.

[0240] Individuals have the opportunity to export draft user stories from the process model application 112 to other tools designed specifically to support the development process, such as Jira.

[0241] FIG. 9a is a diagram 900a of the dynamic construction of draft functional requirements in an event, according to some specific examples.

[0242] The process model application 112 can generate draft functional requirements specific to processes occurring in different activities across various tools. Within the process model application 112, users can view and edit the functional requirements automatically generated by the process model application 112 and, if appropriate, export those functional requirements from the process model application 112.

[0243] Functional requirements are statements that describe the functions or behaviors that tools, data, or material elements must be able to perform in order for individuals and teams to successfully complete an activity or event.

[0244] The process model application 112 adds value to standard functional requirements by indicating the exact moment in a work event when some specific behavior is required, automatically establishes relationships between user stories / functional requirements, and turns manual and difficult tasks in the software development lifecycle (or other work lifecycle) into activities automated by the process model application 112.

[0245] Draft functional requirements can be generated in the background based on the activity's smart description 903, short description 905, tagged catalog elements 904, inputs / outputs, and other attributes for that particular activity.

[0246] Draft functional requirements can be generated at the lowest possible level of activity and input / output associations. Because draft functional requirements are generated at this level, the user stories are actionable and not so large that they are impractical.

[0247] Users have limited functionality when it comes to editing draft functional requirements. This functionality includes the ability to delete draft functional requirements. At the same time, users can sort and filter draft functional requirements based on associated activities and catalog elements.

[0248] Users also have the opportunity to export draft functional requirements from the process model application 112 to other tools designed specifically to support development processes, such as Jira.

[0249] Diagram 900a of Figure 9a shows a smart description 903 for activity 1.234 and a smart description 906 for activity 1.123. Diagram 900a of Figure 9a shows a short description 905 for activity 1.234 and a short description 907 for activity 1.123. Diagram 900a of Figure 9a shows a catalog element 904 for activity 1.234 and a catalog element 908 for activity 1.123. The smart descriptions and short descriptions may be created at least as described with respect to Figure 5.

[0250] Functional requirements typically follow the following format 901 to ensure consistency and understanding across the organization:

[0251] Draft feature requirements for automated activities The draft functional requirements for an automated activity focus on the actions to be performed by the tool within a particular activity.

[0252] Functional requirements format for automated draft activities If it is a _[Trigger]_, the _[Tool Catalog Element]_ will perform the following action: _[System Action]_

[0253] To fill the first blank (_Trigger_) of an automated activity's functional requirement 902, the process model application 112 first identifies the activity's smart description 903 and, if the smart description 903 is the smart description of a higher-level automated activity, derives the condition clause of the information statement. For example, if the activity's smart description 903 is "On Tuesday, Database A performs multiple system checks," the process model application 112 identifies "On Tuesday" as the trigger for the functional requirement.

[0254] If the smart description 903 is that of a lower-level automated activity, the process model application 112 may also derive a conditional clause. For example, if the smart description 903 of the activity is, "When data field 2 equals true and data field 3 equals false, the industrial machine separates material A into material B and material C," the process model application 112 identifies "When data field 2 equals true and data field 3 equals false" as a trigger for the functional requirement 901.

[0255] The second blank (_Tool Catalog Element_) of the automated activity's functional requirement 902 is filled with data from one tool catalog element. If the automated activity includes more than one tool catalog element, multiple functional requirements 901 may be generated, each with one of those catalog elements. For example, if an activity tags three tools, the activity will result in three draft functional requirements 901, one for each tool.

[0256] The third blank (_System Action_) of the automated activity's functional requirement 902 is filled with data based on the main clause of the automated activity's smart description 903. For example, if the smart description 903 says "Every Monday, the computer program transforms data field 1 into data field 2," the system action blank would read "Transform data field 1 into data field 2."

[0257] In the example from diagram 900, the (filled in the blank) draft functional requirement 902 states, based on data extracted from smart description 903 and short description 905, "If data field 2 equals true and data field 3 equals false, the industrial machine performs the following action: Separate material A into material B and material C."

[0258] Draft Functional Requirements Format for Automated Determination Activities The draft functional requirement for the automated decision activity 912 exhibits behavior somewhat similar to that of the draft functional requirement for the automated action activity 901, but focuses on possible alternative paths / decisions within the activity.

[0259] Draft Functional Requirements Format for Automated Determination Activities If it is a trigger, the tool catalog element determines whether to perform the result of [1...4] based on the following logic: [1...6] If _[data point]_ is _[condition]_ or _[condition]_, then _[result]_.

[0260] FIG. 9b is a diagram 900b of the dynamic construction of draft functional requirements in the event of alternative outcomes, according to some specific examples.

[0261] Similar to the draft functional requirement for an automated activity, the first blank (_Trigger_) in the draft functional requirement 959 for an automated decision activity is drawn from the resulting activity's smart description 950 (specifically, from the condition clause of the informational statement if the smart description 950 is a higher-level automated activity's smart description 950). For example, if the activity's smart description 950 is "On Tuesdays, Database A runs multiple system checks," the system identifies "On Tuesdays" as the trigger for the functional requirement.

[0262] If the smart description 950 is that of a lower-level automated decision activity, the process model application 112 also derives a condition clause. For example, if the smart description 950 of an activity is "When data field 2 equals true and data field 3 equals false, the industrial machine separates material A into material B and material C," the process model application 112 identifies "When data field 2 equals true and data field 3 equals false" as a trigger for the functional requirement.

[0263] If the process model application 112 does not find a condition statement with the activity's smart description 950, the process model application 112 extracts the action clause from the smart description of the previous activity. For example, if the activity preceding the automated action activity has the smart description "BUF / RFP adjusts headcount by salary grade," the trigger blank would read "When BUF / RFP adjusts headcount."

[0264] The second blank (_Tool Catalog Element_) of the draft functional requirement 959 is filled with data from one tool catalog element 952. If an automated activity includes more than one tool catalog element 952, multiple functional requirements are generated for each of those catalog elements 952. For example, if an activity tags three tools, the activity will result in three draft functional requirements, one for each tool.

[0265] The third set of blanks (_Results_) in the draft functional requirements 959 are filled with data based on the brief descriptions 954 and 957 of the activities that follow the adjudication activity. The number of these blanks is determined by the number of activities that follow the associated automated adjudication activity.

[0266] The set of if statements is filled in based on the sequence mark descriptions 961 and 962 coming out of the automated decision activity of interest, and from the brief descriptions of subsequent activities (activities connected to the automated decision activity of interest through sequence marks). The process model application 112 does this by deriving action clauses from those information statements. The sequence mark descriptions fill in the blanks for data points and conditions, while the action clauses fill in the blanks for results.

[0267] Diagram 900b in Figure 9b shows a smart description 950 for activity 1.123 and a short description 951 for activity 1. Diagram 900b in Figure 9 shows a catalog element 952 for activity 1.123. The smart description and short description may be created at least as described with respect to Figure 5.

[0268] In one example, an automated decision activity has a smart description of "On Tuesday, Database A runs multiple system checks," and two subsequent activities have simple descriptions of "Review reports" and "Make adjustments," along with their own respective sequence-mark descriptions. The generated functional requirements might be written as follows: On Tuesday, Database A determines whether to make an adjustment or review the report based on the following logic: -Make adjustments if the report is rejected -Review the report if it is approved

[0269] Input / Output Associations - Input-Specific Draft Functional Requirements FIG. 9c is a diagram of the dynamic construction of input / output specific draft functional requirements in the event that they have alternative outcomes.

[0270] Diagram 900c in Figure 9c shows a smart description 906 for activity 1.123 and a short description 907 for activity 1. Diagram 900c in Figure 9c shows a catalog element 908 for activity 1.123. The smart description and short description may be created at least as described with respect to Figure 5.

[0271] Input-specific functional requirements focus on the inputs associated with a particular activity.

[0272] Input / Output Associations - Input-Specific Draft Functional Requirements Format The [Tool 1 Catalog Element] sends the following elements to the [Tool 2 Catalog Element] via the [Transfer Method] upon the [Trigger]: -_[Data Catalog Clement]_ -_[Data Catalog Clement]_

[0273] To fill the first two blanks (_tool catalog elements_) of the input-specific draft functional requirements with data, the process model application 112 reviews the input / output associations associated with the activity and determines the parent tool or parent data / material catalog element 908 of the data or material catalog element involved in the input and output associations. The parent catalog element 908 associated with the activity from which the data or material catalog element originates fills the first blank, while the tool catalog element 911 associated with the activity to which the data or material catalog element 908 is transferred fills the second blank.

[0274] The third blank (_Transfer Method_) is filled with the data of the Input / Output Association Method tag 914 associated with the relevant Input / Output association.

[0275] The fourth blank (_Trigger_) is filled with data based on the action clause of the smart description 906 associated with the activity in which the input and output association occurred.

[0276] The remaining blanks (_Data Catalog Elements_) are filled with data based on the data or material catalog elements 908 and 911 that associate functional requirements with the two activities already filled with data, and the associated input / output associations.

[0277] Input / Output Associations - Output-Specific Functional Requirements Input / Output Associations - Output-specific functional requirements focus on the outputs associated with a particular activity.

[0278] Input / Output Association - Output-Specific Functional Requirements Format _[Tool Catalog Element 1]_ receives the following elements from _[Tool Catalog Element 2]_ by _[Transfer Method]_ at _[Trigger]_: -_[Data Catalog Clement]_ -_[Data Catalog Clement]_

[0279] To fill the first two blanks (_tool catalog elements_) of an input-specific draft functional requirement with data, the system reviews the input / output associations associated with the activity and determines the parent tool or parent data / material catalog element 908 of the data or material catalog element involved in the input and output association. The parent catalog element 911 associated with the activity to which the data or material catalog element proceeds fills the first blank, while the tool catalog element 908 associated with the activity from which the data or material catalog element originated fills the second blank.

[0280] The third blank (_Transfer Method_) is filled with the data of the Input / Output Association Method tag 914 associated with the relevant Input / Output association.

[0281] The fourth blank (_Trigger_) is filled with data based on the action clause of the smart description 906 associated with the activity where the input and output association occurred.

[0282] The remaining blanks (_Data Catalog Elements_) are filled with data based on the data or material catalog elements 908 that associate the functional requirements with the two activities already filled with data and the associated input / output associations.

[0283] Connection with User Stories When user stories are created and tagged to the same tool where the functional requirements were created, the process model application 112 establishes a relationship between the functional requirements and the user story. This relationship allows developers to understand the full range of front-end and back-end requirements needed for the tools that support a specific activity and may enable them to organize development activities in a more efficient manner. These relationships are currently established manually, but the process model application 112 can automate this manual activity.

[0284] Scope Statement The scoping statement is a system-generated introduction to the table of functional requirements. The purpose of this statement is to succinctly summarize what is covered by the functional requirements (which tool the requirement is for and what human events it supports). The functional requirements can be exported to another tool for further editing or used for development purposes.

[0285] The scope specification outlines the relevant tools, relevant functions / events / activities, and relevant user types. The list of relevant tools is initially generated by the system and refined by the user to determine which tools are included in the set of functional requirements.

[0286] The list of related functions / events / activities is generated by including the functions / events / activities selected by the user to receive the draft functional requirements, as well as each nested function / event / activity at the lowest level of granularity provided in the enterprise hierarchy. The user may manually adjust which child functions / events / activities are included. For example, the user may manually add or remove items from the list.

[0287] Additionally, the process model application 112 generates a list of integrations between the in-scope tools and other tools applied to the selected part of the enterprise hierarchy that are linked through inputs and outputs. During the scope specification, the process model application 112 also extracts catalog elements in the people category that are recorded as interacting with the in-scope tools and creates a list of end users. This scope specification is intended to summarize the content of the functional requirements and allow users to quickly modify it.

[0288] Permissions and Security Matrix The process model application 112 generates a draft permission / security matrix outlining the actions that users within the scoped tool may take, with all of the human catalog elements described as performing these actions. Action headers may be drawn from the action clauses in the smart description.

[0289] A security matrix (e.g., in exemplary Table 2) is a standard software development artifact that outlines the users of a particular tool on one axis and the functions that users may perform using that tool on another axis. The matrix formed by these two axes records whether a particular user has access to perform a particular function. The purpose of this security matrix is ​​to provide the data necessary to configure system-specific user roles, permissions, and security. [Table 2]

[0290] The process model application 112 adds value to this standard business product by allowing users to manipulate the data in the security matrix using other organizational structures specific to the process model application 112 environment. For example, a user may filter / sort / edit the functional axis of the security matrix by level of the enterprise hierarchy. In another example, a user may filter / sort / edit the user axis of the security matrix by a hierarchy established in the catalog. Any other suitable arrangement of the security matrix may be created by the user or the process model application 112.

[0291] Tools and Data / Materials Access Matrix (Data / Materials Integration) The process model application 112 generates a draft matrix outlining the different data and material catalog elements that the tool needs to access / edit within its portion of the enterprise, with row and column headers representing either a tool or a data / material catalog element.

[0292] Rules and Regulations List The process model application 112 can generate a summary list of instruction catalog elements that apply to the portion of the enterprise hierarchy defined within its scope. The process model application 112 records the pervasiveness of instruction catalog elements across different functions / events / activities, allowing the user to begin defining rule sets for the design and development of new tools.

[0293] Users can filter and sort instruction catalog elements, functions, events, and activities by those that are most relevant to them.

[0294] Dynamic creation of spreadsheet-based flows The process model application 112 can generate spreadsheet-based flows specific to the work occurring in different activities. A user can view the spreadsheet-based flows automatically generated by the process model application 112 and, if appropriate, export those spreadsheet-based flows from the process model application 112.

[0295] A spreadsheet-based flow is generated in the background based on a smart description of the activity and the attributes associated with that particular activity.

[0296] In some particular examples, the spreadsheet-based flow is formatted as a table that corresponds to events or activities in the process model application 112. The rows represent different activities and the columns represent different attributes associated with each of those activities.

[0297] For example, if an event contains 10 activities, the spreadsheet-based flow for that event will contain 10 rows: one for each activity. Each of those rows will contain one or more columns that represent the attributes of each activity. In the example, columns are dedicated to one or more of the activity's type tag, catalog element of the tagged material, duration, and other attributes.

[0298] In some specific instances, users cannot directly edit spreadsheet-based flows, but instead must edit activities within the process model application 112 and generate a new spreadsheet.

[0299] The user has the opportunity to export the spreadsheet-based flow from the process model application 112 into several different formats (eg, PDF, CSV, or other suitable formats).

[0300] By providing this functionality, users and teams can address organizational requirements, where the organization requires work to be done in a specific format. Users and teams can address individual preferences, where some specific individuals prefer to consume information in a certain format.

[0301] Dynamically Creating Business Process Flows The process model application 112 generates business process flows that are specific to the work that occurs at different events and the activities that make up those events. Individuals can view the business process flows automatically generated by the process model application 112 and, if appropriate, export these business process flows from the process model application 112. These flows employ visual depictions and notations that are accepted and adopted across many industries.

[0302] A business process flow is generated in the background based on a brief description of the activities and the sequence marks associated with those specific activities. The business process flow is formatted as a Business Process Modeling Notation (BPMN) equivalent of events in the process model application 112.

[0303] For example, activities are visualized based on their type tag as either a rectangle, a diamond, or any other organization-specific document standard. In addition, a brief description of the activity is visible and associated with the rectangle or diamond. Sequence marks and contextualization of those marks also appear based on the relationships between those activities.

[0304] In one example, if a process model application 112 has an event that is composed of five activities, the event and its constituent activities are converted into a process flow diagram that employs BPMN to show the five activities. The diagram of the process model application 112 may indicate whether the event and activities are associated with actions or decisions. The diagram of the process model application 112 may indicate whether there are connections between those activities (based on the sequence marks of the events).

[0305] In some specific instances, users cannot directly edit the business process flow. Instead, users must edit the activities themselves within the process model application 112.

[0306] Individuals have the opportunity to export the business process flow from the process model application 112 into several different formats (eg, PDF, etc.).

[0307] By providing this functionality, individuals and teams can address organizational requirements (where an organization requires work to be in a specific format) and personal preferences (where certain individuals tend to consume information in a certain format).

[0308] Figure 10 is a diagram of the customizable policy-driven logic that controls how activities are designed and how catalog elements are employed.

[0309] A system administrator of the work model application 112 can enter any policy-related restrictions on work and apply them at various levels of the enterprise by employing instructions from the "Instructions" section of the catalog 113. For example, a time requirement may be based on a government or other rule. In another example, a tag may require the use of a certain person with a certain training certificate to perform one or more of the activities of an event.

[0310] If a user intends to create an event or activity that violates any of these instructions, the user is warned that the process is not compliant with company policy. Depending on the level of restrictions entered by the system administrator, designers with non-compliant events may be restricted from publishing their models.

[0311] Limits can be set by employing instructions, including the ability to limit which catalog elements can be used within the same event. For example, an organization can limit the number of people involved in an activity. If that limit is set and the activity exceeds that limit, individuals viewing the activity will receive a system-generated notification or other limit or notification (smart signal). Other limits include the ability to require certain catalog elements to be employed within an event, a requirement that certain points be tagged, a requirement for the amount of time a particular event can take, or any other suitable requirement.

[0312] In FIG. 10, user interface 1000 shows activity 1.2 with rule 1 that the activity must be completed in 24 hours. For example, that rule may exist because raw materials may experience spoilage after 24 hours. In the figure, activity 1.2-1, activity 1.2-2, activity 1.2-3, and activity 1.2-4 must occur for activity 1.2 to be completed. However, the time required to perform each of the child activities totals 26 hours. Requiring 26 hours violates rule 1. A smart signal or other notification notifies the user or system administrator, or activity 1.2 is disabled until a correction is made.

[0313] The working model application 112 transforms process flows and working models into meaningful and actionable modeling insights and suggestions, which can be expressed as smart signals.

[0314] The working model application 112 system generates smart signals when it identifies opportunities or challenges specific to how a model / flow or activity was designed and how catalog elements were deployed. Additionally, smart signals can be influenced with respect to their attributes, type / trend / quality, and characteristics. To identify flow conflicts or opportunities, the working model application 112 reviews various attributes of different enterprises, models / flows, activities, catalog elements, attributes, and reactions from individual perspectives.

[0315] When a user receives a smart signal, the smart signal specifies the date and time it was generated, a description of why the signal was generated, and a reference to the content that caused the smart signal to be generated.

[0316] Examples of smart signals are shown below in Table 2. The table includes the name of the smart signal, the context of the smart signal, a description, and possible suggestions for responding to the smart signal. [Table 2-1] [Table 2-2] [Table 2-3]

[0317] Figure 11 illustrates the translation of variant events into insights that detail the differences and similarities between multiple models. This process is useful for comparing and resolving smart signals, comparing current and future states, comparing variants of the same event in different locations (e.g., North America vs. South America), and assessing the impact of changes in a model on other attributes / activities.

[0318] When comparing two events, the system compares the data models of both variants and identifies and presents to the viewer information such as: 1) which catalog elements are utilized across both events, 2) which activities are identical, 3) where activity characteristics may differ, 4) where responses from workers may differ for the two events, 5) where variations in catalog elements result in cost / time variations, 6) overall cost and time for the two variants, and 7) any other suitable data from the two events.

[0319] This feature allows users to analyze two different possibilities for a new job or compare two similar existing events. The comparison allows users to identify why performing one activity might be better than another. By viewing work in this way, users can identify redundant or repeated activities, consider activities that can potentially be consolidated, and reduce unnecessary complexity within their jobs.

[0320] In FIG. 11 , user interface 1000 shows two variants of a sequence of events. In variant 1, Activity 1.2-1, Activity 1.2-2, Activity 1.2-3, and Activity 1.2-4 indicate that the sequence of activities requires four different people using four different tools. Each of these sequences of events involves a different person using a different tool. Variant 2 indicates that Activity 1.2-1, Activity 1.2-2, Activity 1.2-3, and Activity 1.2-4 involve a single person using a single tool to perform the sequence of activities. People 2, 3, and 4 and Tools 2, 3, and 4 are not required in variant 2. Savings in personnel time and tool usage time are realized in variant 2. When work model application 112 compares the two variants, it can identify the reduction in people and tools required. Work model application 112 reports the differences to the user via smart signals, so the user can choose which variant to use.

[0321] The work model application 112 may also use the system to allow a user to design multiple processes to implement an event or a complete work model. For example, a user may create a structure with multiple alternative work models that lead to a desired conclusion. By comparing multiple work models, the work model application 112 determines the number of resources required to implement each activity in the work model. The work model application 112 compares the required resources and identifies a work model that uses fewer of one or more of the resources. The work model application 112 may suggest to the user a preferred work model to save costs, personnel, raw materials, tool use, or other resources.

[0322] 12 illustrates interjections as a form of reacting to events and elements. Reactions are a set of interjections or interjections that a user can employ to respond to an event, activity, or catalog element in the context of an activity on the structure or other embodiment of the working model application 112. Reactions can be words or expressions that convey a spontaneous feeling or reaction.

[0323] Reactions are organized into two groups: those related to the task itself and those related to the modeling of the task. Reactions related to the actual task include, but are not limited to, Awesome!, Satisfying, Frustrating, or any other suitable reaction or response term. Reactions related to the representation of the task within the task model include, but are not limited to, Wow, That's right, No, or any other suitable reaction or response term.

[0324] When a user reacts to an event, the user is prompted to identify whether any catalog element tagged to the event influences the reaction. In addition, the individual is asked to contextualize the reaction to explain why they reacted to that event or catalog element.

[0325] In FIG. 12, a user interface 1200 is displayed with activity 1.2.3-7. Activity 1.2.3-7 displays a smart description and an object field displaying a review of the headcount adjustment. User interface 1200 displays interface object 1201 with options for providing a reaction to activity 1.2.3-7. The displayed options are Wow, Huh?, and Got It! The displayed options may be based on past reactions provided by the user, reactions by other users, reactions based on the content of the event, or any other suitable history or usage. Interface object 1201 displays an option to add a reaction by clicking a plus sign. Clicking this link or object may provide a drop-down list or pop-up menu of other reactions from which the user can select. Alternatively, interface object 1201 may provide an option to enter a new reaction word that is not on a stored list.

[0326] After receiving the response, user interface 1200 may provide an option for the user to associate the response with a specific catalog element for activity 1.2.3-7. Interface object 1202 may display one or more catalog elements that are already associated with activity 1.2.3-7 or that may be associated with activity 1.2.3-7. The response may be specific to only one catalog element, rather than the entire activity. For example, the user may respond with "Got it!" in response to the fact that a catalog element related to a particular raw material is associated with activity 1.2.3-7. The user may respond because the raw material is new to the activity and the new raw material corrects a previous shortcoming in the activity. The user is responding to the assignment of a new raw material to an existing activity 1.2.3-7.

[0327] The user interface 1200 may subsequently provide additional interface objects that allow the user to type a reason for their response. For example, a pop-up window may provide the user with a text entry option to type the reason for their response. In the previous example, the user may enter text to clarify that the Got It! was provided because, "I'm very excited about using the new ingredient. This ingredient solves a long-standing problem with this event."

[0328] Exemplary System 13 illustrates a computing machine 2000 and a module 2050 according to some specific examples. The computing machine 2000 may correspond to any of the various computers, servers, mobile devices, embedded systems, or computing systems presented herein. The module 2050 may include one or more hardware or software elements configured to facilitate the computing machine 2000 performing the various methods and processing functions presented herein. The computing machine 2000 may include various internal or associated components, such as a processor 2010, a system bus 2020, a system memory 2030, a storage medium 2040, an input / output interface 2060, and a network interface 2070 for communicating with a network 2080.

[0329] The computing machine 2000 may be implemented as a conventional computer system, an embedded controller, a laptop, a server, a mobile device, a smartphone, a set-top box, a kiosk, an in-vehicle information system, one or more processors associated with a television, a customized machine, any other hardware platform, or any combination or hybrid thereof. The computing machine 2000 may be a distributed system configured to function using multiple computing machines interconnected via a data network or bus system.

[0330] The processor 2010 may be configured to execute code or instructions to perform the operations and functions described herein, manage request flow and address mapping, perform calculations, and generate commands. The processor 2010 may be configured to monitor and control the operation of components within the computing machine 2000. The processor 2010 may be a general-purpose processor, a processor core, a multiprocessor, a reconfigurable processor, a microcontroller, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a graphics processing unit (GPU), a field-programmable gate array (FPGA), a programmable logic device (PLD), a controller, a state machine, gate logic, a discrete hardware component, any other processing unit, or any combination or hybrid thereof. The processor 2010 may be a single processing unit, multiple processing units, a single processing core, multiple processing cores, an application-specific processing core, a coprocessor, or any combination thereof. According to some particular examples, the processor 2010, along with other components of the computing machine 2000, may be a virtualized computing machine running within one or more other computing machines.

[0331] The system memory 2030 may include non-volatile memory, such as read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), flash memory, or any other device capable of storing program instructions or data with or without applied power. The system memory 2030 may also include volatile memory, such as random access memory (RAM), static random access memory (SRAM), dynamic random access memory (DRAM), and synchronous dynamic random access memory (SDRAM). Other types of RAM may be used to implement the system memory 2030. The system memory 2030 may be implemented using a single memory module or multiple memory modules. While the system memory 2030 is shown as part of the computing machine 2000, those skilled in the art will recognize that the system memory 2030 may be separate from the computing machine 2000 without departing from the scope of the subject technology. It should also be understood that the system memory 2030 may include or operate in conjunction with a non-volatile storage device (e.g., storage medium 2040).

[0332] The storage medium 2040 may include a hard disk, a floppy disk, a compact disk read-only memory (CD-ROM), a digital versatile disk (DVD), a Blu-ray disk, a magnetic tape, a flash memory, other non-volatile memory devices, a solid-state drive (SSD), any magnetic storage device, any optical storage device, any electrical storage device, any semiconductor storage device, any physically-based storage device, any other data storage device, or any combination or hybrid thereof. The storage medium 2040 may store one or more operating systems, application programs and program modules, e.g., module 2050, data, or any other information. The storage medium 2040 may be part of or connected to the computing machine 2000. The storage medium 2040 may also be part of one or more other computing machines in communication with the computing machine 2000, e.g., a server, a database server, cloud storage, network-attached storage, etc.

[0333] The module 2050 may include one or more hardware or software elements configured to facilitate the computing machine 2000 performing the various methods and processing functions presented herein. The module 2050 may include one or more instruction sequences stored as software or firmware associated with the system memory 2030, the storage medium 2040, or both. The storage medium 2040 may thus represent an example of a machine or computer-readable medium on which instructions or code may be stored for execution by the processor 2010. A machine or computer-readable medium may generally refer to any medium(s) used to provide instructions to the processor 2010. Such machine or computer-readable medium associated with the module 2050 may include a computer software product. It should be understood that the computer software product comprising the module 2050 may also be associated with one or more processes or methods for distributing the module 2050 to the computing machine 2000 via the network 2080, any signal-bearing medium, or any other communication or distribution technique. Module 2050 may also include hardware circuitry or information for configuring hardware circuitry (eg, microcode or configuration information for an FPGA or other PLD).

[0334] The input / output (I / O) interface 2060 may be configured to couple to, receive data from, and send data to one or more external devices. Such external devices, along with various internal devices, may also be known as peripheral devices. The I / O interface 2060 may include both electrical and physical connections for operably coupling various peripheral devices to the computing machine 2000 or processor 2010. The I / O interface 2060 may be configured to communicate data, address, and control signals between the peripheral devices, the computing machine 2000, or the processor 2010. The I / O interface 2060 may be configured to implement any standard interface, such as Small Computer System Interface (SCSI), Serial Attached SCSI (SAS), Fibre Channel, Peripheral Component Interconnect (PCI), PCI Express (PCIe), serial bus, parallel bus, Advanced Technology Attached (ATA), Serial ATA (SATA), Universal Serial Bus (USB), Thunderbolt, Firewire, various video buses, etc. The I / O interface 2060 may be configured to implement only one interface or bus technology. Alternatively, the I / O interface 2060 may be configured to implement multiple interface or bus technologies. The I / O interface 2060 may be configured to operate as part of, in whole of, or in conjunction with the system bus 2020. The I / O interface 2060 may include one or more buffers for buffering transmissions between one or more external devices, internal devices, computing machine 2000, or processor 2010.

[0335] The I / O interface 2060 may couple the computing machine 2000 to a variety of input devices, including a mouse, touch screen, scanner, electronic digitizer, sensor, receiver, touchpad, trackball, camera, microphone, keyboard, any other pointing device, or any combination thereof. The I / O interface 2060 may couple the computing machine 2000 to a variety of output devices, including a video display, speakers, printer, projector, haptic feedback devices, automation controls, robotic components, actuators, motors, fans, solenoids, valves, pumps, transmitters, signal emitters, lights, etc.

[0336] The computing machine 2000 may operate in a networked environment using logical connections through a network interface 2070 to one or more other systems or computing machines via a network 2080. The network 2080 may include a wide area network (WAN), a local area network (LAN), an intranet, the Internet, a wireless access network, a wired network, a mobile network, a telephone network, an optical network, or a combination thereof. The network 2080 may be packet-switched, circuit-switched, of any topology, and may use any communication protocol. The communication links within the network 2080 may involve various digital or analog communication media (e.g., fiber optic cables, free space optics, waveguides, electrical conductors, wireless links, antennas, radio frequency communications, etc.).

[0337] The processor 2010 may be connected to other elements of the computing machine 2000 or the various peripherals discussed herein through a system bus 2020. It should be understood that the system bus 2020 may be internal to the processor 2010, external to the processor 2010, or both. According to some particular examples, the processor 2010, other elements of the computing machine 2000, or any of the various peripherals discussed herein may be integrated into a single device (e.g., a system-on-chip (SOC), system-on-package (SOP), or ASIC device).

[0338] Examples may include computer programs embodying the functionality described and illustrated herein. The computer programs are implemented in a computer system having instructions stored in a machine-readable medium and a processor that executes the instructions. However, it is clear that there may be many different ways of implementing examples in computer programming, and the examples should not be construed as limited to any one set of computer program instructions. Moreover, a skilled programmer could write such a computer program to implement one example of the disclosed examples based on the accompanying flowcharts and the associated description in the body of this application. Thus, disclosure of a specific set of program code instructions is not considered necessary to properly understand how to make and use the examples. Furthermore, as will be appreciated by those skilled in the art, one or more aspects of the examples described herein may be implemented by hardware, software, or a combination thereof, such that they may be embodied in one or more computing systems. Additionally, any reference to an act being performed by a computer should not be construed as being performed by a single computer, as more than one computer may perform the act.

[0339] The examples described herein can be used with computer hardware and software that implements the aforementioned methods and processing functions. The systems, methods, and procedures described herein can be embodied in a programmable computer, computer-executable software, or digital circuitry. The software can be stored on a computer-readable medium. For example, the computer-readable medium can include a floppy disk, RAM, ROM, hard disk, removable media, flash memory, memory stick, optical medium, magneto-optical medium, CD-ROM, etc. The digital circuitry can include an integrated circuit, a gate array, building block logic, a field-programmable gate array (FPGA), etc.

[0340] The example systems, methods, and acts described in the examples presented above are exemplary, and in alternative examples, some specific acts may be performed in a different order, in parallel with one another, omitted entirely, and / or combined between different examples, and / or some specific additional acts may be performed, without departing from the scope and spirit of the various examples. Accordingly, such alternatives are intended to be included within the scope of the following claims, which are to be accorded the broadest interpretation so as to encompass such alternatives.

[0341] While specific examples have been detailed above, this description is for illustrative purposes only, and thus it should be understood that many of the above aspects are not intended as required or essential elements unless expressly stated otherwise.

[0342] Those skilled in the art having the benefit of this disclosure, in addition to those described above, may also make modifications of the disclosed aspects of the examples, and corresponding equivalent components or acts, without departing from the spirit and scope of the examples as defined in the following claims, which are to be accorded the broadest interpretation so as to encompass such modifications and equivalent structures.

Claims

1. 1. A system for providing dynamic digital construction of hierarchical process flows, comprising: a processor communicatively coupled to a storage device, the processor executing application code instructions stored in the storage device to provide the system with: receiving process element inputs required to perform the process; determining a hierarchical arrangement of the process elements, the hierarchical arrangement including parent events arranged as parents to child events and activities; displaying one or more of the parent events in the hierarchical arrangement on a user interface of a computing device; receiving a selection of a particular parent event on the user interface; and in response to receiving the selection, displaying one or more child events or activities of the parent event on the user interface.

2. The system of claim 1 , further comprising instructions for displaying a feature associated with a particular one of the parent events.

3. further comprising instructions for displaying catalog elements associated with a particular one of the parent events; The system of claim 1 , wherein each catalog element associated with each parent event is a factor in the determination of the hierarchical arrangement of the process elements.

4. adding a subsequent child event or activity to a particular activity in the hierarchical arrangement that has no child events or activities; The system of claim 1 , further comprising instructions for: changing the designation of the particular activity to an event when adding the child event or activity.

5. The system of claim 3 , wherein the catalog element is selected from a catalog of catalog elements and associated with an event or activity on the user interface.

6. The system of claim 1 , wherein the hierarchical arrangement on the user interface is a vertical tree diagram with child events or activities under parent events.

7. The system of claim 1 , wherein the hierarchical arrangement on the user interface is a horizontal tree diagram with child events or activities branching to the right of a parent event.

8. The system of claim 3 , wherein the catalog element includes one or more resources required to complete a task associated with an event or activity.

9. The system of claim 2 , wherein the features include categories associated with events or activities.

10. The system of claim 3 , wherein catalog elements for each of the one or more child events or activities of the parent event are aggregated, and the aggregated catalog elements are associated with the parent event.

11. providing a user interface input for a variant event, the variant event being a duplicate event of the parent event; receiving input of a modification to the parent event to be associated with the variant event; simulating the hierarchical arrangement on the user interface with the variant events; The system of claim 1 , further comprising instructions for: receiving a selection to replace the parent event in the hierarchical arrangement on the user interface with the variant event.

12. 1. A computer program product comprising: a non-transitory computer-readable storage device having computer-executable program instructions embodied thereon that, when executed by a computer, cause the computer to provide a hidden data set, the computer-executable program instructions comprising: receiving process element inputs required to perform the process; determining a hierarchical arrangement of the process elements, the hierarchical arrangement including parent events arranged as parents to child events and activities; displaying one or more of the parent events in the hierarchical arrangement on a user interface of a computing device; receiving a selection of a particular parent event on the user interface; and in response to receiving the selection, displaying one or more child events or activities of the parent event on the user interface.

13. The computer program product of claim 12 , further comprising computer-executable program instructions for displaying a feature associated with a particular one of the parent events.

14. The computer program product of claim 12 , further comprising computer-executable program instructions for displaying catalog elements associated with a particular one of the parent events.

15. adding a subsequent child event or activity to a particular activity in said hierarchical arrangement that has no child events or activities; 13. The computer program product of claim 12, further comprising computer-executable program instructions for: changing the designation of the particular activity to an event when adding the child event or activity.

16. The computer program product of claim 14 , wherein the catalog element is selected from a catalog of catalog elements and associated with an event or activity on the user interface.

17. The computer program product of claim 11 , wherein the hierarchical arrangement on the user interface is a vertical tree diagram with child events or activities under parent events.

18. 1. A method for providing a hidden data set, comprising: by one or more computing devices, receiving process element inputs required to perform the process; determining a hierarchical arrangement of the process elements, the hierarchical arrangement including parent events arranged as parents to child events and activities; displaying one or more of the parent events in the hierarchical arrangement on a user interface of a computing device; receiving a selection of a particular parent event on the user interface; and in response to receiving the selection, displaying one or more child events or activities of the parent event on the user interface.

19. providing a user interface input for a variant event, the variant event being a duplicate event of the parent event; receiving input of a modification to the parent event to be associated with the variant event; simulating the hierarchical arrangement on the user interface with the variant events; 18. The method of claim 17, further comprising: receiving a selection to replace the parent event in the hierarchical arrangement on the user interface with the variant event.

20. The method of claim 18 , wherein the hierarchical arrangement on the user interface is a horizontal tree diagram with child events or activities branching to the right of a parent event.

Images