Patent Application
20200349479
This invention relates to methods and systems for monitoring and analyzing business processes. More particularly, this invention relates to software and methods for allowing a user to build, customize, and revise business process definitions, or “templates,” define process counters, timers, checkpoints, exceptions, and other process monitoring and measurement parameters, to monitor and/or analyze actual instances of the business process using the defined parameters and data collected from a SCADA system and enterprise applications, and to revise and customize the process measurement parameters thus improving the analysis, all in order to understand and improve the business process.
As used herein, the term business process is used to refer to any business process or activity of a business that is reasonably susceptible to standardization and for which there is a need or desire to monitor, measure and/or analyze some aspect or another. For example, a manufacturing process is a business process. As another example, the service or repair of a piece of equipment is a business process. Examples of equipment in this context may be manufacturing equipment, transportation equipment (trucks, forklifts, etc) or facility infrastructure equipment (computers, HVAC equipment, elevators, escalators, etc.). Other examples of business processes include employee hiring processes, employee training processes, employee review processes, employee grievance processes, various manufacturing process, billing and accounting processes, and complaint management/processing. As a company grows, management becomes more and more concerned with the efficiencies and inefficiencies in these various processes and looks for ways to monitor, analyze and improve the efficiencies of these process in order to improve the overall efficiency and performance of the company. Companies have therefore collected and analyzed information concerning these processes, but it is a cumbersome undertaking. This process analysis has made use of data collected by systems and software that are used or are impacted as the process instance is carried out, but most business processes require the use of or interaction with multiple enterprise applications and equipment or building systems. Accordingly, data concerning instances of a business process is captured by various different applications in multiple locations and must then be exported, consolidated offline, and formatted/normalized before it can be processed using standard analytical tools. The only exception to this paradigm is custom-built and installed manufacturing systems in which the process analysis tools are built into the process automation. In these cases, modifications of the prior art process analysis tools requires re-writing of the system software, which is time-consuming and difficult to accommodate and implement.
Due to these limitations, many opportunities are missed to change and/or improve the analysis parameters to better analyze the process under consideration and hence to identify and correct mistakes or inefficiences in the process in a timely manner. More importantly, it is very hard using prior art process analysis methods to receive a feedback for a process modification (a change in the actual practice in doing something) because prior art systems do not allow for changes in business process, process definitions, process measurements after initial setup.
The present invention provides a computer-implemented system and method by which an end user can easily monitor and manage multiple business processes with a single interface using data collected and stored in SCADA (supervisory control and data acquisition) systems and enterprise applications, and in which the user can easily customize and revise the process definitions/templates, the process measurements, and the analysis parameters for multiple business processes, and review analyses of data collected automatically from various related and unrelated systems and enterprises.
This invention is complementary to, and may be configured to work in conjunction with or as part of, the system and application integrating command and interface software module described in U.S. application Ser. No. 12/952,675, filed Dec. 23, 2010, the entirety of which is incorporated herein by reference.
Accordingly, the present invention provides a drop-in process management layer, in the form of a software module, which, from a software architecture perspective, sits on top of the metadata layer where data and information from various systems, devices and control applications are represented and stored according to prior art supervisory and control and data acquisition systems. The present invention allows the user to access a business process definition, set measurement parameters, and collectively analyze multiple actual instances of the business process using data collected from diverse systems as the actual business process instances are carried out. Moreover, as business processes are revised, as new business processes are devised, and as new systems and applications are installed, the present invention can easily accommodate the changes without reconfiguring the entire control system. In short, the present invention, in conjunction with the invention described in U.S. application Ser. No. 12/952,675, allows a user to define measurement parameters for various business processes, and to view various analyses of the accumulated instances of the process over time using the defined measurement parameters and data collected from various systems and applications. The systems and enterprise applications that can be used to collect and present data for analysis by the invention include, but are not limited to, HVAC, fire control, access control, video monitoring, public address, exterior lighting and signage, interior public and private space lighting, escalator and elevator systems, telephone systems, room scheduling/reservation systems, resource management systems, data and information technology systems, document management systems, e-mail servers, fax servers, SMS servers, building tenant/visitor database systems, and customer relationship/management systems. Accordingly, business processes that interact with any or all of these systems, and others, can be analyzed according to the invention.
While the system of the invention may be used with the business process definitions that are established according to the process automation described in U.S. application Ser. No. 12/952,675, the process monitoring and analysis aspect of the invention may also be used to monitor and analyze business process that are automated using other systems, or business process that are partially automated, or business process that are not automated at all. According to this embodiment, the meta data later of the invention is configured to gather information that reflects the progress of the process by interfacing with the system that automates the process or, in the case of processes that are not automated, by interfacing directly with systems (such as reservation applications, customer complaint applications, and scheduling or calendar applications) that reflect the progress of the process. Once the meta data layer is populated with representations of the devices and data that reflect the aspects of the process, a business process definition can be established as described in U.S. application Ser. No. 12/952,675. In this case, however, the business process definition will not initiate the actual instances of the business process, but instead will be used to monitor and analyze accumulated instances of the actual process.
According to another aspect of the invention, the process definitions, and the number, location and character of process measurements are fully editable by the end user. For example, according to the invention, a user may have designed a smoke detection response process according to invention described in U.S. application Ser. No. 12/952,675 in which the system queries various systems to collect information and then command various systems based on the information collected. The system can be programmed to wait for end user intervention before an alarm is sounded, for example, if based on the queries, the threat level fails to meet a particular threshold. According to the present invention, the user can set various measurements for any one or all of the steps in the process definition and analyze accumulated instances of the process based on data collected in the SCADA system over time. In addition, the user can revise the measurement parameters, measurement locations, process locations and other measurement and process parameters at any time and re-run the analysis to see how changes in various variables affect the efficiencies of the business process. Significantly, process measurements can be defined for a process that is already running. Additionally, new process measurements can be applied to all process instances in the past and future. Therefore, the present invention alleviates the need for a user to anticipate all iterations and measurement variations and possibilities when the operational and analytical software is first written/implemented.
A more detailed description of features of the invention is set forth below in the detailed description of the invention, with reference to the figures. While this invention is described with respect to a work order as an exemplary business process, this invention can be used for any business process, including, but not limited to, manufacturing processes, service processes, repair processes, hiring processes, training processes, employee review processes, grievance processes, sales processes, billing processes, accounting processes, collection processes, and complaint management/processing. The following detailed description of the invention is not intended to limit or exclude these embodiments from the invention.
In particular, the present invention also includes a process analyzer module which allows a user to access a configured process, to define process measurements at various locations in the process diagram, and to view various analyses of collective instances of the process based on the defined measurements using data collected from devices, systems and applications and saved, for example, in a SCADA system.
System access and process configuration by an end user, as well as process launch and execution upon a status or event trigger is explained in U.S. application Ser. No. 12/952,6745, the entirety of which is incorporated herein by reference.
User access of a previously configured process definition, setting of process measurement definitions, and viewing and modification of various process analyses can be explained by way of example.
Practice of the process analyzer aspect of the invention begins with launching of the process analyzer module. The user then selects the “open” icon to obtain a list of available processes for analysis.
At the left hand side of
In the prior art, process measurements had to be defined during process configuration, and process configuration was not editable. According to this invention, process measurements can be defined after the process has been deployed and data collected. Moreover, since the process definition is editable, multiple versions of processes may exist, and each version may be configured for measurement and included in any analysis, if desired. In short, it is possible the current version of the process template may have been modified one or more times in the past. In this case, process instances in the history tables might belong to more than one versions of the process template. Thus, when the process template is downloaded and opened, the process measurement editor also shows available different versions of the process template in the history tables.
The next step according to the invention is to define one or more process parameters for analysis. There are three types of parameters used for analyzing process data: process variables, checkpoints and measurements.
Process variables are defined at the time of configuring the process template. Process variables cannot be added after a process is deployed to run except as a new version of the template. The primary role of process variables in process analysis is to allow classification of process instances into various groups. For example, in work order process, we may save “technician” as a process variable, which will allow analysis of time-to-complete by each technician.
Checkpoints arc points in the process that arc critical to track to understand the progress of each process instance. In process analysis, checkpoints can be used to classify the process instances when defining the sample space. For example, analyzing of “time to complete a WO where spare parts were not found in stock” requires a checkpoint to determine whether parts are found in stock or not. Checkpoints can be defined after a process is deployed to run and can be applied to both past and future process instances.
Measurements are analogue values, and they are two kinds: “loop count” and “duration” between two stages in the process. Similar to checkpoints, measurements can also be defined after a process is deployed to run.
According to this example, the measurement will be overall completion time for the process. To do this, the user selects “define a new measurement” under the “Measurement” section displayed on the screen shown in
When a process template is opened, the Process Measurement Editor will show the list of measurements and checkpoints defined for the selected business process in the “Measurement” box. For system to work correctly, these measurements must be attached, or “tabbed,” to the process definition at appropriate stages. If any of the versions have unassigned measurement tabs, the process measurement editor will bring it to user's attention.
When a new checkpoint or a measurement is added, corresponding tabs should be attached to all versions of the process template. In an event where newly placed measurement is not applicable to old versions of the process template, it can be marked as “not applicable” to avoid editor highlighting it as an error.
If the measurement location tabs for a selected measurement have not been set for a version of the process, the system will present an exclamation point next to the version of the process for which the location tabs have not been set, see, e.g.,
Once the completion time measurement configuration has been completed, the user saves the measurement configuration to the system by selecting the “save” tab (
According to a preferred embodiment of the invention, when the process analysis screen (
The user may also filter the sample space by selecting a process variable matching or not matching a specified value, by selecting one or more checkpoints (discussed below) and/or other analysis conditions. The user can also define a specific process location for analysis. Since every process has one or more associated locations (actual devices or space locations, e.g., “lobby,” “cafeteria,” etc.), the user can limit the process analysis to specific locations, if desired.
Once the user has set the sample space for analysis, the user may be presented with a selection with analysis tools. The system can be configured to offer the user any of a variety of data analyses and graphical presentations. Representative available analyses include a control chart, a histogram, and a scatter plot. For any particular analysis, further settings may necessary. Whatever analysis is selected by the user, the user may have the option to switch between different analyses without having to redefine the sample space.
The objective of a control chart is to see whether process instances are staying within acceptable levels. For this analysis, a process measurement should be selected, which will appear in y-axis. X-axis is time, showing the full span of selected range. The user can also define CL, LCL & UCL to (visually) see whether the data falls within acceptable limits.
The objective of a histogram is to compare the frequency of process instances falling into various ranges (of a selected process measurement). For this analysis, a process measurement should be selected, which appears in the x-axis. The user will be able to modify the number of groups in x-axis for better visibility of the curve. The Y-axis is the count of number of process instances. The histogram chart can be set to a default according to which the x-axis scale reflects the six-sigma range, which can be modified to get a better view of the distribution curve.
Returning to the process definition for Simple WorkOrder (
Once the exception for the postponed loop has been set, the user can select the report” tab again to return to the analysis page. To exclude the postponed loop from the completion time analysis, the user may use a pull down menu in the Checkpoint field to select “does not contain exception,” as shown in
The analyses available according to the present invention may be used for Six Sigma analysis because, unlike prior art systems, it allows the user to exclude non-random data from the analysis. Prior art systems do not have this capability because process automation is accomplished through hard-coded binding between different applications, rather than the flexible and user-editable process automation between different systems and applications of the present invention, and because, in the prior art, process automation and process monitoring and/or analysis arc conducted in separate and independent applications. In the present invention, however, both process automation and process monitoring, even between multiple systems and applications, are fully configurable and editable by the end user, and they are fully integrated with one-another.
Accordingly, to conduct Sigma-Six analysis of completion time using the present invention for example, the process definition can be examined to determine if the events leading to completion time are randomly distributed. Returning to the process definition for Simple WorkOrder, it can be seen that the process includes provisions for handling anomalous instances of the process. For example, there are timeouts when the assignment is not made within a specified time period and the supervisor is notified. When the process includes such instances, the process is no longer random. In order to remove these non-random instances from the data analysis, the user may return to the Process Measurement Editor. Selecting the Simple WorkOrder process, the user may insert additional exception tabs for the two timeout loops in the Simple WorkOrder process definition as shown in
Once these additional exceptions are added, the reports may be run again, excluding the exceptions. As shown in
Review of the process definition for the Simple WorkOrder process reveals two key delays: assignment delay, and wait-for-completion delay. To measure the actual delay resulting from these steps, the user may define new measurements in the Process Measurement Editor, as shown in
Likewise, the user may define a “work time” measurement, as shown in
Returning to the Reports tab, the user can set the “Condition” to the “Completion Time” measurement from the pull down menu (
To determine whether the completion time has a relation, for example, to assignment delay, the scatter plot x and y values can be set to compare completion time to assignment delay as shown in
The Reports portion of the process analysis tool of the invention can be used to look at many other relationships. For example, a user can analyze set of records by day of week to see if there is any pattern that relates to the days of the week. Again, looking only at process instances over 500 minutes,
The user can also analyze process instances by discipline (e.g., mechanical, electrical, plumbing, etc.), as shown in
The process analysis tool can also be used to analyze work time by day of week, as shown in
A user might ask why the work time is higher on the weekend. It might simply be a scheduling or manpower issue. But the analysis described above also shows that there is some relation to discipline. The system may be used to conduct additional analyses to look further into the issue.
The process definition of the Simple WorkOrder includes several loops (see
Examining repeat count instead by discipline,
Each process instance includes a record of its corresponding process definition along with additional data specific to that instance—such as last executed step, and the data came along with the event. The steps of the process instance arc executed by the “process engine,” an executable that periodically looks at process instances that require execution.
Process instances can be monitored visually with respect to the process definition.
In the case where the process to be monitored and/or analyzed is not already represented by a business process template, a business process template may be established as disclosed in U.S. application Ser. No. 12/952,675. The business process template may be a process automation template which initiates and drives a business process upon a particular event or status trigger, or it may be a process monitoring template, which does not automate, initiate or drive any business process or process step but merely monitors existing business processes. Alternatively, the business process template may both automate and monitor a business process.
In the case where process automation is carried out by an independent business system, or where the process is not automated, the present invention may optionally be used solely for process monitoring. According to this embodiment, the meta data layer of the present invention would be configured to gather details relating to the process steps by interfacing with various applications that are used by a user to carry out various steps of the process. Then, a process monitoring template would be defined in the system of the invention, as described in U.S. application Ser. No. 12/952,675, to represent the process to be monitored. This process monitory template would then be annotated with process measurements as described herein in order to monitor and analyze accumulated instances of the process. According to this embodiment then, the present invention does not drive the process, but merely “follows” a process that is driven by another system, or by a human driver, collecting statistics from the systems and applications that are used as the process is carried out. As process instances and related data is accrued, the process may be analyzed as described herein.
| Number | Date | Country | Kind |
|---|---|---|---|
| SG201103180-4 | May 2011 | SG | national |
| Number | Date | Country | |
|---|---|---|---|
| Parent | 13463248 | May 2012 | US |
| Child | 16735337 | US |
