Systems and Related Apparatus for Improving Process Data Integrity and Timeliness

Abstract

Systems, apparatus, and methods for improving the monitoring of processes. These systems comprise processors co-located with the (physical) processes and which accept certain metrics regarding the processes. These systems also include processors which are located remotely from the processes, but, which are in communication with the co-located processors. The remote processors receive the metrics from the co-located processors and transform these metrics to corresponding probability metrics. Based on the probability metrics, the remote processors determine whether the processes are predictable. They also output the predictability determinations regarding the processes. The processes can be associated with petrochemical wells, food/beverage processes, etc. Additionally, or in the alternative, some systems further comprise memories which store flowchart representations of the processes. In various embodiments, the remote processors associate the metrics with the operations represented in the flowcharts.

Description

CROSS REFERENCE TO RELATED APPLICATIONS

This application claims priority to U.S. patent application No. 62/196,040, filed on Jul. 23, 2015, entitled Enterprise Performance Reporting Systems, by Forrest Breyfogle, the entirety of which is incorporated herein as if set forth in full.

BACKGROUND

In large industrial processes, things go wrong. And sometimes they go wrong catastrophically. For instance, the Apr. 20, 2010, Deepwater Horizon Explosion (and subsequent fire and oil spill) killed 11 people. It also spewed approximately 5 million barrels of oil into the Gulf of Mexico. To make matters worse, British Petroleum (the owner of then Deepwater Horizon rig) had a history of major accidents and lagged other oil companies when it came to safety, according to federal officials and industry analysts. See Jad Mouawadmay, the New York Times, May 8, 2010. Perhaps not as dramatic, but also serious, the 2015 Blue Bell listeria incident was both complex and unusual in that the ten illnesses over four states spanned the period from 2010 to 2015. All involved hospitalizations and three died. See Dan Flynn, Food Safety News, Mar. 27, 2016.

And of course, almost every American old enough to remember the Space Shuttle Challenger disaster will remember Jan. 28, 1986 as one of the most tragic days in recent American history. For, in addition to the 6 Astronauts on board, the accident killed Christa McAuliffe, who was to have been America's first “Teacher in Space.” This catastrophe shut the Space Shuttle program down for 3 years, put America's manned space program on hold, and resulted in $350 million of re-design work. Se the Washington Post, Mar. 12, 1986.

Yet all of these incidents could have been prevented had management and/or oversight personnel had timely, up-to-date information from the “field” that had not been manipulated and/or obscured by those responsible for allowing the incidents to occur. Unfortunately, for all involved, these organizations lacked a physical system to ensure the integrity and timeliness of safety-related data flowing to management.

SUMMARY

The following presents a simplified summary in order to provide a basic understanding of some aspects of the disclosed subject matter. This summary is not an extensive overview of the disclosed subject matter, and is not intended to identify key/critical elements or to delineate the scope of such subject matter. A purpose of the summary is to present some concepts in a simplified form as a prelude to the more detailed disclosure that is presented herein. The current disclosure provides systems, apparatus, methods, etc. for monitoring processes and, more particularly, for improving the integrity and timeliness of information related to those processes.

Some embodiments provide systems for monitoring physical processes. These systems comprise processors co-located with the physical processes and which accept safety-related metrics regarding the physical processes. These systems also include processors which are located remotely from the physical processes, but, which are in communication with the co-located processors.

The remote processors receive the safety-related metrics regard from the co-located processors and transform the safety-related metrics to corresponding probability metrics. Based on the probability metrics, the remote processors determine whether the physical processes are predictable. They also output the predictability determinations regarding the physical processes.

In some embodiments, the physical processes are associated with petrochemical wells, food/beverage processes, etc. Additionally, or in the alternative, some systems further comprise memories which store flowcharts representations of the physical processes and the remote processors associate the probability metrics with operations of the physical processes. In various embodiments, the remote processors associate the safety-related metrics with the representation of the physical processes.

Systems of embodiments comprise processors co-located with certain processes and which accept metrics regarding the processes. These systems also include processors which are located remotely from the processes, but, which are in communication with the co-located processors. The remote processors of the current embodiment receive the metrics regard from the co-located processors and transform the metrics to corresponding probability metrics. Based on the probability metrics, the remote processors determine whether the processes are predictable. They also output the predictability determinations regarding the processes.

To the accomplishment of the foregoing and related ends, certain illustrative aspects are described herein in connection with the annexed figures. These aspects are indicative of various non-limiting ways in which the disclosed subject matter may be practiced, all of which are intended to be within the scope of the disclosed subject matter. Other advantages and novel features will become apparent from the following detailed disclosure when considered in conjunction with the figures and are also within the scope of the disclosure.

BRIEF DESCRIPTION OF THE FIGURES

The detailed description is described with reference to the accompanying figures. In the figures, the left-most digit(s) of a reference number usually identifies the figure in which the reference number first appears. The use of the same reference numbers in different figures indicates similar or identical items.

FIG. 1 illustrates a system for monitoring a process.

FIG. 2 illustrates a drilling rig.

FIG. 3 illustrates a value chain supporting a physical process.

FIG. 4 illustrates a control chart related to the physical process.

FIG. 5 illustrates an incident chart regarding the operations of a physical system.

FIG. 6 illustrates a probability chart regarding the operations of that physical system.

FIG. 7 illustrates another incident chart regarding the operations of a physical system.

FIG. 8 illustrates another probability chart regarding the operations of that physical system

FIG. 9 illustrates a flowchart of a method for improving, inter alia, the integrity and/or timeliness of data regarding a physical processes.

FIG. 10 illustrates a graphical user interface for monitoring a process.

FIG. 11 illustrates a component of a graphical user interface for monitoring a process.

FIG. 12 illustrates another component of a graphical user interface for monitoring a process.

FIG. 13 illustrates yet another component of a graphical user interface for monitoring a process.

FIG. 14 illustrates another component of a graphical user interface for monitoring a process.

FIG. 15 illustrates a taxonomy of a system for monitoring a process.

FIG. 16 illustrates a process goal setting worksheet for several scenarios.

FIG. 17 illustrates a stoplight scorecard for one scenario in FIG. 16.

FIG. 18 illustrates an “individuals” I-chart and a probability chart for a scenario.

FIG. 19 illustrates another individuals I-chart and another probability chart for a scenario.

FIG. 20 illustrates yet another stoplight scorecard for a scenario.

FIG. 21 illustrates an individuals I-chart and a probability chart for a scenario.

FIG. 22 illustrates another I-chart and another probability chart for a scenario.

FIG. 23 illustrates yet another I-chart and yet another probability chart for a scenario.

FIG. 24 illustrates another stoplight scorecard for a scenario.

FIG. 25 illustrates yet another I-chart for a scenario.

FIG. 26 illustrates still another I-chart for a scenario.

FIG. 27 illustrates a stoplight scorecard for a scenario.

FIG. 28 illustrates an I-chart for a scenario.

FIG. 29 illustrates a stoplight scorecard.

FIG. 30 illustrates an I-chart.

FIG. 31 illustrates a stoplight scorecard.

FIG. 32 illustrates an I-chart.

FIG. 33 illustrates data regarding a process.

FIG. 34 illustrates more data regarding a process.

DETAILED DESCRIPTION

This document discloses systems, apparatus, methods, etc. for monitoring processes and, more particularly, for improving the integrity and timeliness of information related to those processes inter alia. Embodiments provide centralized tools for monitoring, reporting on, controlling, and improving processes.

Take, for instance, the many processes that occur in a company producing petrochemicals. These processes occur within a context such as that shown by FIGS. 1 and 2. And at this juncture, it might be helpful to briefly discuss FIGS. 1 and 2 to facilitate the current disclosure. FIG. 1 illustrates a system for monitoring a process. More particularly, FIG. 1 illustrates system 100, companies 102, affiliates 104, fields 106, drilling rigs 108, wells 110, wellbores 112, numeric drilling data 114, descriptive drilling data 116, reams of data 118, event 120, user 122, data repository 126140, and a “remote” computer 140 among other aspects of system 100. As is disclosed herein, system 100 generates and processes drilling data (for instance numeric drilling data 114 and/or descriptive drilling data 116 as well as other types of data) to provide information (perhaps including raw or processed drilling data 114 and 116) to user 122. Meanwhile, FIG. 2 illustrates a drilling rig. As shown, the drilling rig 108 includes mast or derrick 200, drill string 202, hook 204, rotary table 206, connection 208, drill bit 212, and mud motor 214 among many other potential components. In addition, FIG. 2 illustrates that the drilling rig 108 can include a computer or data system 216 (co-located with the processes on the rig 108 and) networked with a web server 218 which further comprises network interface 220, processor 222, memory 224, and user interface 226. FIG. 2 illustrates that either, or both of, the data system 216 of the drilling rig 108 and the web server 218 can be in communication with a data repository 227. Note that these computer related pieces of equipment and/or data can all be networked with remote computers 140 located elsewhere in the system 100. This particular drilling rig 108 also includes (or uses) an instrument package 228, a log 230, and a pseudolog 232.

Turning to the rig first, some of the processes on the rig include:

• • Drilling wells and or well bores
  • Finishing the wells
  • Producing oil, gas, water, etc.
  • Maintaining/repairing the rig etc.

Of course, other processes occur on the rig. For instance, some of these other processes include:

• • Treating sick/injured crew members
  • Creating/maintaining production records
  • Auditing safety related conditions
  • Investigating safety-related issues
  • Reviewing crew member performance and rewarding/punishing the same
  • Tracking crew members' working hours.

And, of course, data and/or information is sent to the company 102 headquarters, affiliates 104, vendors, regulators, other governmental organizations, etc. via the network 233. Elsewhere in the company 102 illustrated by FIG. 1, many other processes occur.

• • For instance, customer inputs are sought on the products/service of the company.
  • Developing products
  • Marketing those products
  • Selling those products
  • Producing/manufacturing those products
  • Delivering those products
  • Invoicing/collecting payments
  • Reporting financials and other information

But many of these processes depend on the data, information, etc. flowing from the rig 108 or other locations. As a result, users 122 co-located with the data sources have the opportunity to manipulate that data. Many motivations might exist for them to do so: some benign, some not. For instance, some users 122 might be unaware of problems with a process and therefore might not be disciplined in collecting data regarding that issue. Other users 122 might be aware of the problem, but might be unable/unwilling to acknowledge it. Still other users 122 might think that hiding or obscuring the problem might be desirable by themselves or others. Other users 122 might even be willing to deliberately hide data that might reveal a problem to management (at headquarters or elsewhere) and/or others. Of course, such behaviors make it more difficult for these remote (for instance at the company 102 headquarters, a governmental office, etc.) users 122 to find and correct problems.

Now with reference to FIGS. 3-32, systems for improving the integrity and timeliness of data and/or information reaching remote users 122 such as management are disclosed herein. More specifically, FIG. 3 illustrates a value chain 300 supporting a physical process 301 and related metrics 304, support processes 306, and other processes such as: obtaining customer input 310, developing a product 312, marketing the product 314, selling the product 316, invoicing 320, and reporting 322. Often, the value chain 300 describes everything that a particular company 102 does although they can be centered about a particular physical process 301. For instance, the physical process 301 could be operating a drilling rig 108 or other industrial activity, operating an aerospace system such as a launch vehicle, producing a food/beverage such as ice cream, etc. Note that in this instance of a value chain 300, the processes represented by rectangles and interconnected by lines without arrowheads tend to be support functions such as safety, information technology, enterprise process management, etc. The metrics 304 represented by oblong or rounded rectangles are top-level metrics for the company 102/value chain 300 and can correspond to the various processes 302 whether they be physical, support, or otherwise.

Indeed, a remote processor 140 can associate various metrics 304 with their corresponding processes 302. Moreover, graphic user interfaces (GUIs) running on the remote computer 140 or processor can display the value chain 300 and/or select portions thereof and allow users to select processes 301, 310, 312, 314, 316, 318, and/or 320. Responsive thereto, the remote computer 140 can display the metric(s) 304 associated with the selected process 302. A user could, for instance, select a GUI representation of physical process 301 and view one or more metrics 304 such as lead time-related, defect rate, work in progress (WIP), delivery time performance, throughput, etc. metrics 304. Moreover, as is disclosed elsewhere herein, various other metrics 304 such as safety-related metrics 304 can also be available for viewing via the remote computer 140.

FIG. 4 illustrates a control chart related to the physical process 301. The control chart 400 illustrates data gathered regarding a metric 304 related to the particular process 301 (or perhaps group of processes). In this instance, the control chart plots the number of (safety-related) incidents occurring in a time interval (in this case the number of incidents in a month). The raw data underlying the control chart 400 is found in Table 1 (FIG. 33). While the control chart 400 provides a convenient, visual method to portray the underlying data, it provides little (if any) stable/predictable statement, etc. Typical usage of a control chart is to determine if a process is ln control and react to points that indicate out of control conditions. With 30000 foot level the system of embodiments also displays a probability plot for continuous data so that it can make a prediction statement. For attribute data we do not necessarily need a probability plot. But, the system still makes a prediction assessment, which again is not done with heretofore available systems/

Table 2 (FIG. 34) and FIG. 6, on the other hand do provide information insight to the user as to how the physical process 301 is behaving, since FIG. 5 indicates predictability of the physical process 301 as noted below. In addition to the number of safety-related incidents occurring in any given month, Table 2 shows the calculated days-since-last incident associated with the data in Table 1. And FIG. 5 illustrates an incident chart regarding the operations of a physical system and reflecting the days-since-last-incident information from Table 2. More specifically, FIG. 5 illustrates an incident chart regarding the operations of a physical system, which assesses process stability. But, while FIG. 5 provides a convenient way to view the data of Table 2 and provides insight into whether the underlying physical system is stable/predictable or not. In this scenario, the process is stable since there are no trends or excursions relative to the statistically calculated upper control limit (UCL) or lower control limit (LCL).

FIG. 6 illustrates a probability chart regarding the operations of that physical system, which provides information for a process-prediction statement at the bottom of the FIGS. 5 and 6 chart pair, since FIG. 5 indicates that the process is stable. More specifically, FIG. 6 replots the days-since-last-incident data in a probability chart. From FIG. 6 therefore, it is seen that for the 20 time-between-failures data points presented, the estimated median days-between incidents is 84 with 80% of incidents occurring between 50 and 117 days. If this frequency of incident-occurrences is unsatisfactory, it might be desirable to do something to improve the process. Thus, taken together, the I-chart (FIG. 5) and probability chart (FIG. 6) allows the system to mathematically determine whether the process is under control and to output a prediction statement to that effect. More particularly, the system can do so by calculating the standard deviation, AD value, p-value, and/or other paramaters associated with the process and comparing them to user input limits. These capabilities of the system of the current embodiment are particularly useful when large numbers of data points and/or when the data points are generated rapidly. An indication that an improvement was made to the frequency between events is that the individuals chart (I-chart) transitions to an enhanced level of performance.

As a result, users 122 associated with the physical process 301 might decide to improve the performance of the physical process 301. For instance, they could add safety features to the equipment associated with the physical process 301; they could institute better training based on simulations or otherwise; etc. But, in this scenario, they make changes associated with the physical process 301 and collect more data related to the physical process 301 and its associated metric 304. The data collected following improvements to the physical process 301 are presented in Table 2 as the last 6 data points. FIGS. 7 and 8 illustrate the results in another incident chart and a probability chart respectively. In FIG. 7 (the incident chart), the 6 new data points are added in a separate section of the chart (and are re-scaled) while in FIG. 8, the post-improvement data points are presented standing alone.

FIG. 7 illustrates another incident chart regarding the operations of a physical system, which assesses process stability, noting that a change occurred in the system. And FIG. 8 illustrates another probability chart regarding the operations of that physical system, which provides information for a process-prediction statement at the bottom of the FIGS. 7 and 8 chart pair, since process indicates stability since process shift noted in FIG. 7.

The incident chart (FIG. 7) provides insight as to whether the underlying physical process is stable and/or changed over time. If an individuals chart has a recent region of stability, one can say that the process is predictable. The probability chart (FIG. 8) provide insight into what one might predict, if the individuals chart indicates current process stability. More particularly, FIG. 8 shows that the median for the days-since-last-incident has risen to 113.3 with now an 80% frequency of occurrence between 106 and 121 days; i.e., the time between failures for 4 out of 5 incidents is between 106 and 121 days. Thus, the post-improvement probability chart (FIG. 8) when compared to the pre-improvement probability chart (FIG. 6) provides an estimate of the benefits of the change.

Thus, embodiments provide improvements in creating honest, transparent, performance metrics (from a process point of view). And indeed, systems which do so can be obtained from Smarter Solutions, Inc. of Austin, Tex. under their Integrated Enterprise Excellence® (IEE) and/or Enterprise Performance Reporting Systems (EPRSs) lines of products/services. And, it is noted that, by having such honest, transparency in the reporting of performance measurements with various physical process, companies and/or other organizations can avoid potentially disastrous results. One need look no further than the Blue Bell listeria, Deepwater Horizon, and Space Shuttle Challenger incidents to appreciate the savings/cost-avoidance in terms of capital as well as the safeguarding of physical structures and life and limb provided by embodiments. In contrast, with systems heretofore available typical organizational reporting can lead to ineffective if not destructive behaviors such as that which occurred during these incidents. Leading up to and during these incidents it was as if, colloquially, there was an “elephant in the room” that few involved were willing to acknowledge and/or address.

Embodiments automatically update predictive, top-level performance metrics and therefore provide transparency in the reporting of the same. Some embodiments also (or in the alternative) integrate the predictive metrics with the processes via GUI links for convenient selection and viewing. Moreover, leaders in the organization (using remote processors and/or systems disclosed herein) decide which top-level metrics 304 are to be automatically updated thereby providing those with access privileges to these metrics 304 information in a timely manner (from a process point of view). Moreover, systems of embodiments allow “real-time clickable” access to such process-reported metrics during periodic (for instance, monthly) meetings and/or at times selected by such users.

Thus, embodiments help prevent field and/or co-located users 122 from creating “filtered” reports regarding unfavorable situations pertaining to physical processes 302, other processes 302, and/or other situations in organizations which have implemented such systems. Systems of embodiments therefore help prevent co-located users 122 from shielding remote users 122 (for instance, management) from learning of true field conditions which might/might not be adverse to the corresponding organizations (and/or the reputations of the co-located users 122).

In systems of various embodiments, the corresponding value chains 300 can include metrics 304 for the safety function. These metrics can include those related to safety incidents and/or frequency of safety audits and other corrective and/or prophylactic activities. Organizations that are not trying to hide “bad news” should be receptive to such systems. And sub-groups attempting to hide “bad news” will likely find it much harder to do so if the over-arching organization has implemented a system in accordance with embodiments. Moreover, embodiments provide improvements over heretofore available systems which, at best, provide rough performance measures such as red-yellow-green scorecards. Even well-intentioned organizations that rely upon these rough measurements often do so to their detriment. Instead, systems of embodiments provide improved metrics 304 consistent with process thinking/reporting, structured process improvements, and better common-cause variability. And, when the sought after, process improvements are not satisfactory, embodiments provide metrics 304 which indicate the same and allow users 122 to track progress as they implement further process improvements.

Now with reference to FIG. 9, various embodiments provide reporting systems as disclosed herein. More specifically, FIG. 9 illustrates a flowchart of a method for improving, inter alia, the integrity and/or timeliness of data regarding physical processes. Embodiments provide Integrated Enterprise Excellence® (IEE) and/or EPRS Lean Six Sigma® (registered by Motorola) systems which can be obtained from Smarter Solutions, Inc. of Austin, Tex. Such systems can be created by programming computers, web servers, web browsers, etc. to implement the same. Such specially programmed systems (as opposed to generic computers and the like) can provide comprehensive enterprise monitoring which is reported to organization managers (and/or other authorized users) via interactive enterprise performance dashboards and/or other GUIs.

Some systems provide a number of features including, but not limited to:

• • Automated data acquisition from enterprise resource planning (ERP) systems and other data resources.
  • Manual data acquisition for other data resources if desired.
  • Creation of organization performance metrics 304 using available data.
  • Automated updates of enterprise performance metrics 304.
  • Online tools for development of flowcharts and value chains 300 that illustrate enterprise processes.
  • Linking of flowcharts and value chains 300 to related metrics 304, files and other resources.
  • Providing high-level project status tools.
  • Administration tools for software configuration and user access control.
  • Provision for organizations to load their logo or other branding images.
  • Linkage to websites, articles, standard operating procedures and other information that may be relevant to an organization's value chain

Users who might benefit from such systems include, but are not limited to:

• • Medium and large organizations with a culture or strong desire for excellence (and even other organizations can benefit).
  • Organizations of any size applying the principles of IEE® or Lean Six Sigma®.
  • Leaders of these organization who seek tools for themselves and their staff to easily assess process performance.
  • Leaders of these organization who seek “enterprise performance dashboards” and similar tools for themselves and their staff.
  • Lean Six Sigma® Practitioners who seek a centralized tool to control, report and monitor their projects.
  • IEE® Lean Six Sigma® Practitioners who seek a centralized tool to control, report and monitor their projects
  • Organizations that desire to implement and an operational excellence system

Organizations typically strive to achieve the “3 Rs” of business; i.e., everyone doing the right things, doing them right, and doing them at the right time. To move toward achievement of these objectives in an ever changing complex, competitive climate, businesses could use a framework for orchestration of activities and business improvement efforts. IEE systems of the current embodiment provide such frameworks as disclosed herein.

Governance methods such as those illustrated by FIG. 9 provide roadmaps for systematically addressing management challenges head on if desired. Methods are provided that can facilitate process improvement efforts and that can positively impact the enterprise as a whole. Method 900 (see FIG. 9) includes various activities such as describing a vision and/or mission for the organization, a physical process 301, a physical system, and/or some other process 302. See reference 902. Method 900 also includes, as shown at reference 904, describing a value chain 300 including top level metrics 304 (, “satellite level” Metrics® and/or “30,000 foot level Metrics® as registered by Smarter Solutions, Inc. of Austin, Tex.). Moreover, reference 906 illustrates that (in accordance with the current embodiment) method 900 also comprises analyzing the process 302 or other object of interest (hereinafter “process”).

FIG. 9 also illustrates that method 900 comprises establishing “SMART” (specific, measurable, action oriented, reasonable, and timely) top-level, metric-related goals for the process. See reference 908. As reference 910 illustrates, method 900 further comprises create strategies for achieving the vision and/or mission chosen for the process 302. Moreover, reference 912 indicates that areas of high potential for improvement can be identified and that SMART top level metrics for those areas can be established. Reference 914, meanwhile, shows that method 900 comprises identifying and executing process improvement projects for those areas of potential. In addition, FIG. 9 illustrates that method 900 comprises assessing the impact of those projects (using the metrics established during method 900 or otherwise) during their implementation and/or after their completion. See reference 916. Method 900, moreover, illustrates that those improvements can be maintained (again with reference to pertinent metrics 304,) See reference 918. Method 900 also includes a feedback loop by which method 900 can be repeated/continued in whole or in part as might be desired. See reference 920.

Indeed, in accordance with embodiments, that feedback loop can return to reference 906 (analyzing the process) rather than returning to reference 902 (although that too is in accordance with embodiments). One implication of this type of feedback is that a long-lasting front-end management system is provided, which can remain structurally constant over time even through leadership, organizational, strategy, and/or other process-related changes occur.

EPRS systems provided herein can transform heretofore available process dashboards/scorecards to predictive performance metrics 304 that can be automatically updated. Such systems can also allow users to tailor reports so that everyone in the pertinent organization(s) can view up-to-date information on how processes of interest are performing and can view graphic representation of the processes that are leading to these results shown by those metrics 304. Furthermore, EPRS systems in accordance with the current embodiment can links those process representations (and documentation related thereto) with the pertinent metrics 304 from these efforts in a timely manner. Such features allow users 122 working to develop the metrics 304 while other users 122 (working remotely from the other users) develop the process documentation and/or process improvements. EPRS systems can bring these efforts together so that there is a timely flow of information regarding the processes and the related metrics.

EPRS systems of embodiments allow organizations associated with the process(es) to transition from “firefighting” (in which common-cause (normal) variability of the process 302 is reacted to as though it were a special cause) to “fire-prevention” (in which long term process improvements cause benefits at the top-levels as well as perhaps other levels associated with the process 302). Such EPRS systems also facilitate implementing Demings' philosophy, achieving Malcolm Baldrige Awards, and/or certifying the processes as ISO-9000 compliant.

Moreover, organizations can use the systems and methods described herein to move toward achieving the 3 Rs of business (described elsewhere herein). They can also become more efficient and/or effective as these systems make it more difficult for users 122 to “play games” with the metrics in attempts to hide, obscure, or otherwise avoid reporting bad news regarding various processes. As a result, systems and/or methods in accordance with embodiments help prevent conditions which lead to results like the Deepwater Horizon, Blue Bell, and/or Space Shuttle Challenger incidents. In all of these cases, issues had been known by at least some users. But the organizations avoided dealing with the issues because of a lack of honest, timely, pertinent, and/or predictive process metrics 304. Thus, risks were run—and ultimately materialized. Systems and methods provided herein help organizations avoid those risks and their results. EPRS systems and methods can also allow organizations to evaluate performance metrics 304 from a process point of view (in a timely and systematic fashion) so that enhancement efforts are undertaken that will likely benefit the big picture.

With reference now to FIGS. 10-15, it might now be useful to discuss GUIs programmed in accordance with embodiments. For instance, FIG. 10 illustrates an EPRS dashboard. The dashboard 1000 is an entry point for the various users of the EPRS system of the current embodiment. General access users 122 may use this screen to review the current status of their process(es). The screen includes options to easily search for information via a search field in the header or using various selection features. Additionally, this screen is a portal to other features to access information and/or lists of available metrics 304 and value chains 300. Furthermore, editors and administrators can use this screen to enter the backend of the software that allows their users to management the information available on the EPRS dashboard and/or to administer the EPRS system and/or underlying software. FIG. 10 also illustrates the IEE scorecard 1002 which is a section of the EPRS dashboard 1000 and that can provide a quick summary of metrics 1004 identified to be of some user selected level of importance to the organization (for instance, top-level). Selecting one or more of these metrics 304 prompts the system to provide a popup with more detailed information about the selected metric.

Meanwhile the value chain section 1008 of the EPRS dashboard allows users 122 to select value chains 300 using the value chain information feature 1010. They can also (or in the alternative) view processes 1030 and/or sub-processes 1032 (or rather graphical representations of the same such as flowcharts), related metrics 304 and other related links to process-related documentation, websites, files and/or other resources. Indeed, if a user selects one or more of the processes 1030 or sub-processes 1032, the dashboard 1000 (or GUI) can be configured such that the metric 304 (and/or other information pertinent to the selected item) pops up or is otherwise displayed.

The related metrics section 1012 of the EPRS dashboard provides that, when a particular value chain(s) is selected by the user 122, the metrics 304 associated with (i.e., linked to) the pertinent flowchart (for the selected value chain) are displayed in this section of the EPRS dashboard 1000. Moreover, the dashboard 1000 also includes an IEE projects section 1014. This section of the dashboard 1000 provides users 122 the ability to profile high level project status to users 122. In this section, moreover, project owners may edit the information and status of the projects they are responsible for and in a timely fashion.

With reference to FIG. 11, the customer logo setup option 1100 of the dashboard 1000 allows users 122 to upload a logo or other graphic for identifying the organization associated with the process(es) associated with the dashboard 1000 and/or for customizing the dashboard 1000. In accordance with the current embodiment, the dashboard 1000 also provides links/controls to list all metrics 304 published in the system, to list all flowcharts published in the system, and/or to publish the flowcharts of various value chains 300 (and/or related metadata).

In the meantime, FIG. 12 illustrates a metric editor 1200 of an EPRS system of embodiments. Using it, users 122 with metric-editing permission can manage and publish metrics. These metrics 304 are typically created using commercially available statistical products such as Minitab. Although, in accordance with embodiments, the metrics 304 can be created by other means.

FIG. 13 illustrates a flowchart designer feature 1300. Using it, users with process editing permission can create flowcharts using various flowcharting tools. Once published, updates to the flowchart (representing various processes) are automatically viewable via associated value chains 300 which are selectable via the EPRS dashboard 1000 and/or its various features.

FIG. 14 illustrates a project editor. Using the project editor 1400, users with project editing permissions can manage project summaries and status information displayed on the EPRS dashboard 1000. FIG. 15 illustrates a taxonomy of an EPRS system. The taxonomy 1500 shows the types of information, GUIs, etc. present in EPRS systems of embodiments.

Non-Limiting Illustrative Scenarios

At this juncture it might be useful to disclose aspects of some embodiment and how they can relate to Lean Six Sigma process improvement efforts. more specifically, an “individuals” control chart (XmR chart, I-chart) can be used for time-series tracking of a process to determine if the process is in statistical control and whether it can be considered stable. When a process is considered stable, in accordance with embodiments, it experiences only common-cause variability. When a process is not in control, special-cause conditions can be causing non-stability.

In considering a process, it might be desirable to understand and resolve, when appropriate, special-cause conditions. A process that only experiences common-cause conditions does not imply that the process does not have any issues. A process can be stable but be unable to provide a consistent level of quality or performance. Assessments for process stability and capability can be provided through 30,000-foot-level reports with predictive measurements as further disclosed herein.

A moving range chart can be included with an individuals control chart report-out, producing a pair of charts (i.e., XmR control chart or ImR control chart). However, since the primary purpose of the MR chart is only to identify larger than normal short-term swings in the data, this chart will not be included in the report-outs for the scenarios disclosed below so that the overall reporting and evaluation process can be simplified.

With reference now to FIGS. 16-32, several non-limiting scenarios are provided for illustrative purposes. More specifically, these non-limiting scenarios illustrate some of the benefits of a 30,000-foot-level predictive performance reporting systems of embodiments.

On that note, executives are often presented a monthly summary of the current level of key performance indicators (KPIs) or metrics 304 in their organizations. Often information from this goal setting theory approach is presented as a PowerPoint presentation where the last month's data is reported with possibly some previous months. Red-yellow-green scorecards may be used to track against goal setting objectives; however, stoplight scorecarding has issues which will later be illustrated through the goal setting worksheet scenarios. Traditional goal setting and track-reporting against these goals can:

• • Divert much resource from other tasks that are important to the business.
  • Provide only historical observations (i.e., no prediction statement).
  • Variance to a goal that may have been arbitrarily set and does not have direct aligned to overall business needs.
  • Are dated relative to the timeliness of the information presented.

Instead of using a stoplight goal setting theory approach to scorecards, organizations gain much benefit when they use a 30,000-foot-level reporting approach that provides, when appropriate, a prediction statement of what could be expected in the future if nothing changes. If there is process stability with 30,000-foot-level reporting and the response is undesirable, some form of structured process improvement efforts are needed.

The following six goal setting worksheet scenarios illustrate the benefits of 30,000-foot-Level® predictive performance metric reporting over a traditional format, where these metrics can be automatically updated so that anyone authorized can get ready access to the metrics through a click of the mouse using Enterprise Performance Reporting System (EPRS) software.

In the following real goal setting scenarios, red-yellow-green scorecards are shown to have issues that can be resolved through 30,000-foot-level reporting. Using a goal setting worksheets like the one shown in FIG. 16 is common. However, this form of reporting can lead to much firefighting where the process is not really improved. The question is how would one undertake the objective to have the business goal setting worksheet scenarios improved? One could respond to this question as:

• • Examine the data from a process point of view.
  • Create a predictive performance metric 304 statement for the process 302 whenever possible.

The need for predictive metrics 304 is supported by the article Gartner Says Organizations Using Predictive Business Performance Metrics Will Increase Their Profitability 20 Percent by 2017. See the Gartner Inc. website “Newsroom” article dated Jan. 16, 2014.

What is described below is how six of these metrics 304 could be reported in a predictive performance metric 304 format. The approach that will be used for this reporting is 30,000-foot-level for the data shown in FIGS. 17, 20, 24, 27, 29, and 31.

Scrap Costs of Production: Goal Setting Scenario 1

FIG. 17 illustrates a traditional stoplight scorecard for one scenario in FIG. 16. A highlight from the table above scrap costs of production reporting one observes the data seen in FIG. 17. With this report-out formation, one is to take action to determine what specifically occurred when the goal was not met for a month; i.e., the color was red. One doesn't know what action, if any, occurred by simply looking at this data. However, from this form of reporting one does statistically know:

• • If the process was really improved with a transition from red to green.
  • Know what might be expected in the future.

Let's now examine this data using a 30,000-foot-level reporting for scrap costs as presented in FIG. 18. FIG. 18 illustrates an individuals chart with a probability chart for a scenario, along with a non-conformance prediction rate relative to a specification for the associated process. FIG. 18 therefore illustrates an alternative or supplement to the reporting illustrated by FIG. 17. A prediction statement is included at the bottom of the chart shown in FIG. 18. With 30,000-foot level reporting, one first notes that scrap costs is a continuous variable. The first assess is for process stability, while the next effort is provide a prediction statement when the process 301 is stable. For this continuous-data situation, the 30,000-foot-level individuals control chart assesses stability, while a probability plot provides a prediction statement. With 30,000-foot-level reporting there is also a statement at the bottom of the report-out which provides a prediction statement, when appropriate.

From this 30,000-foot-level report-out, one has no reason to state that the process 301 is not stable. Data from the recent region of stability can be considered a random sample of the future. This data are then plotted on a probability plot. If the data follow a straight line, the data are presumed to be from the distribution associated with the probability plot; i.e., normal in this case. From this individual control chart, one notes that no improvements occurred as the stoplight score-carding had indicated. The probably plot indicates an expectation that about 27% of the months we should expect not to achieve our goal of 1.41 or less.

Let's now consider this goal setting in objective. When goal setting for this particular type of measurement would it be better to set have Specific Measurable Actionable Relevant, and Time-based goal setting (i.e., SMART goal setting) based on the mean? If this were done, one would tend to give focus to the process and not what happened specifically during the latest time period. With 30,000-foot-level performance metric 304, rather than report-out proportion non-compliant per month, one could report-out the expected mean with an 80% frequency of occurrence. For this particular situation, this methodology could provide a good baseline for setting goals. See FIG. 19 which FIG. 19 illustrates another individuals chart with a probability chart for the current scenario, along with a predicted process median, and 80% frequency of occurrence rate when no process specification exists. Again, a prediction statement is included at the bottom of the chart.

This form of reporting for this particular situation would be very desirable. From this form of reporting, one would begin to view that this metric 304 as the result of variability in the process 301 and that improvement activities are needed to reduce the scrap costs from the process 301. A Pareto chart of the types of failures that occurred in the recent region of stability could provide insight to what issues occur most frequently. This insight can be very beneficial to target areas of the process 301 that might cause these defectives occurrences.

Quality Cost Production ($/unit): Goal Setting Scenario 2

The line item from the goal setting worksheet scenarios for this measurement is shown in FIG. 20. FIG. 20 illustrates yet another traditional stoplight scorecard for one scenario. There is a lot of red in this goal setting scenario. Let's now evaluate this metric 304 from a 30,000-foot-level point of view as illustrated by FIG. 21. FIG. 21 illustrates an individuals chart (I-chart) and a probability chart as an alternative report-out to FIG. 20, where this charting indicates that the process is not predictable, since a data point is beyond an upper control limit (UCL) for this scenario. A prediction statement decisions is included at the bottom of the chart.

This report-out indicates that there was a special-cause situation in the chart that warrants investigation. However, one should not react to all the ups and downs of the metric in the statistically calculated upper and lower control limit regions (UCL and LCL), which are function of the collected data and its variability; i.e., not what desired. Note how this report-out provides a very different perspective about the process than the stoplight scorecard goal setting theory application.

One could stage the process 301 at the special cause region to examine how the process 301 is performing since that the special cause condition. One perhaps did this assessment after understanding the special cause occurrence and then made adjustments so this particular occurrence does not happen again. The result from this effort would be is shown in FIG. 22. FIG. 22 illustrates another I-chart and another probability chart pair for a scenario where a stage was created when it was believed that the process output shown in FIG. 21 had changed and there was a specification requirement. A prediction statement is included at the bottom of the chart.

Using the value in the goal setting worksheets for the monthly goal, one could state that the process is now stable where about 55% of the months will not meet the monthly objective. Again, since this goal is not necessarily a specification, a median best-estimate report-out with 80% frequency of occurrence seems to be a better report-out method.

FIG. 23 seems to be a good baseline to act as a goal setting tool from which SMART goal setting can occur. FIG. 23 illustrates yet another I-chart and yet another probability chart for a scenario where a stage was created when it was believed that the process output shown in FIG. 21 had changed and there was NOT a specification requirement. (estimated median and 80% frequency of occurrence reported) A prediction statement is included at the bottom of the chart. Again, with this approach would be given to improve the process as opposed to reacting to all the ups and downs in the common-cause stability region.

Defects (ppm): Goal Setting Scenario 3

For defects this business goal setting worksheet scenarios, a goal of 1000 parts per million (PPM) was given. As FIG. 24 shows, there is much red in this goal setting item. FIG. 24 illustrates another traditional stoplight scorecard for one scenario. Since the data from this scenario are pass/fail attribute data, a probability plot should not be created for the 30,000-foot-level report-out. A 30,000-foot-level attribute assessment for this data would be as shown in FIG. 25. The gap in the plot occurred because the raw data set had a missing datum point.

The estimated performance for this chart was determined from the centerline of FIG. 25. FIG. 25 illustrates an I-chart for the the FIG. 24 scenario, which involves attribute data, where a prediction statement is included at the bottom of the chart. One can see that the process 301 is producing about 4327 ppm units, where there was a goal of 1000 ppm. However, note how the value of zero is within the UCL and LCL limits. When this occurs, one should examine what is getting measured. If the measurement is bounded by zero, this indicates that a data transformation may be necessary to establish stability and quantify predictability; however, a transformation should make physical sense.

For this data, an assessment indicated that a log transformation was appropriate. The result of this effort is shown in FIG. 26. FIG. 26 illustrates an I-chart for the FIG. 24 scenario, which involves attribute data which was transformed, where a prediction statement is included at the bottom of the chart.

When one has a transformation, they have no need to address the transformed units on the y-axis since when the process is stable a performance metric 304 statement will be made at the bottom of the chart. The reader should note that even though there was additional complexity when creating the chart, the interpretation of the graphical output is similar to previous outputs and easy to understand.

The question one could ask is whether the above goal setting in process application is for the overall process 301n mean or individual months. For this type situation, a statement of how well the process 303 is performing would be best, understanding that some months could have a higher reporting and others a lower one.

Total Unclean Sales Orders %: Goal Setting Scenario 4

The goal for this measurement is 8. For this measurement from the goal setting spreadsheet scenarios, there are many red points as shown by FIG. 27. FIG. 27 illustrates another traditional stoplight scorecard for a scenario. An attribute 30,000-foot-level predictive performance metric 304 for this measurement from the business goal setting worksheet scenarios would be as shown in FIG. 28. FIG. 28 illustrates an I-chart for the FIG. 27 scenario with the inclusion of a prediction statement. The same discussion points that were made in the last data-plot situation can again be made for this plot. This plot could also be transformed because of the zero boundary; however, this was not done since the zero value is within the UCL and LCL limits. This process 302 indicates stability and that if the predicted response is undesirable a systematic process improvement effort is needed.

Avoidable Unclean Sales Orders-%: Goal Setting Scenario 5

Five was the result of the organization's goal setting effort for this measurement. There are many red occurrences in this goal setting template response as shown by FIG. 29. FIG. 29 illustrates a traditional stoplight scorecard for one scenario. A 30,000-foot-level attribute report-out for this data set is shown in FIG. 30. FIG. 30 illustrates an I-chart for an attribute (pass/fail situation), where the process is believe stable/predictable and the prediction statement is included at the bottom of the chart.

One could have undertaken using a transformation for this report-out; however, this was not done since the zero value is barely inside the LCL. Similar to previous report-outs this process response is stable and has common-cause variation that, if considered unacceptable, would result in these metric 304 enhancement needs pulling for a process improvement effort.

First Pass Yield (FPY) %: Goal Setting Scenario 6

The goal for first pass yield (FPY) is 96%. From this business goal setting worksheet scenarios illustration, we note the data shown in FIG. 31. FIG. 31 illustrates another traditional stoplight scorecard. This goal setting theory for reporting methodology indicates that everything appears to be in good order. Let's now examine the data in a 30,000-foot-level report-out format as shown in FIG. 32. FIG. 32 illustrates an I-chart alternative to FIG. 31 which provides more information about the process and its variability. Since the process is stable one can conclude that the process is predictable, where the prediction statement is noted at the bottom of the chart. From this goal setting in report-out, the process 302 appears stable with an estimated first pass yield of 96.7%. One should note that for a percentage response and if 100% is within the control limits, one should consider changing the response from percent acceptable to percent non-acceptable, where an appropriate transformation would be selected.

For this situation, the goal of 96% FPY was achieved; however, one might ask whether this was a SMART goal that benefited for the organization as a whole. If a higher yield would seem to be beneficial, improvement efforts would then be appropriate.

In summary, of the foregoing, non-limiting examples, for these business goal setting scenarios, the following observations can be considered. In all the above comparison plots, a different decision was made about the process relative to actions or non-actions for the output formats. In five out of the six shown goal setting worksheet issues, there was a switching between green and red where the 30,000-foot-level reporting indicated that these transitions were from common-cause variability. Stoplight score-carding can lead to unhealthy if not destructive behaviors that can cost an organization a lot of money. Organizations gain much from viewing the output of their process at the 30,000-foot-level.

There is a tendency for reporting annually, as the charts above did; however, one should not be bounded by the calendar when creating 30,000 foot-level reporting. Several years of data could provide much more insight than a short calendar-year plot. Organizations can look at their metrics 304 collectively to determine what metrics 304 need focus so process improvement efforts benefit the enterprise as a whole would be given to these areas of the business. Organizations do not have enough resources to do a significant amount of improvement for everything. The above 30,000-foot-level approach for metric 304 tracking throughout the organization can lead to improved SMART goal setting.

An organization can have their metrics 304 automatically reported at the 30,000-foot-level using EPRS software. Updates could be made daily. Those who have authorization and Internet/network access could get up to date information about their predictive performance metrics, where there is an alignment to an organization's IEE value chain 300. The dynamics of status meetings can change to the better when an organization's value chain 300 and its associated 30,000-foot-level metrics 304 are referenced during the meeting instead of giving a sole focus to the issues of the day.

Note also, that while some illustrative metrics 304 are disclosed above, these scenarios are non-limiting. But they do show how metrics 304 can be programmed into systems of embodiments.

As alluded to above, in some situations upper management (and/or other personnel) might not want to know the “truth” about a given situation. The reasons vary but bad news could impact their bonuses for meeting the next quarter's goals. Plus, or in the alternative, they might not want to be the bearer of because doing so could be career limiting. EPRS® systems disclosed herein provide transparency with respect to metrics that personnel involved agreed to before situations develop and which are automatically reported from a process point of view. Metrics reported in accordance with embodiments cannot be gamed. Nor can recipients of bad news “kill the messenger” because these metrics are reported by systems of embodiments without user involvement. Users at all levels and who have read-privileges can view the system-reported metrics for various processes at any time, not just at the end of the quarter or month for executive periodic “reviews”. The “truth” relative to how processes are being executed and their performance cannot be “played with” to make situations look better than they are (from a process point of view).

As disclosed herein, embodiments provide systems report performance metrics which are integrated with the processes from which they arose and which are reported from a process point of view. Systems of embodiments also enable users to implement process improvement efforts that benefit their respective organizations at the “big picture” level. Moreover, the metric improvement need pulls for an improvement project creation

CONCLUSION

Although the subject matter has been disclosed in language specific to structural features and/or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts disclosed above. Rather, the specific features and acts described herein are disclosed as illustrative implementations of the claims.

Claims

1. A system for monitoring a physical process, the system comprising:

a processor co-located with the physical process and being configured to accept a safety-related metric regarding the physical process;

a network in communication with the co-located processor;

a processor located remotely from the physical process and in communication with the network, the remote processor being configured to receive the safety-related metric regarding the physical process from the co-located processor, to transform the safety-related metric regarding the physical process to a probability metric, and to determine, based on the probability metric, whether the physical process is predictable; and

an output device in communication with the remote processor wherein the remote processor is further configured to output the safety-related predictability determination regarding the physical process via the output device.

2. The system of claim 1 wherein the physical process is associated with a petrochemical well.

3. The system of claim 1 wherein the physical process is one of a food or beverage production process.

4. The system of claim 1 further comprising a memory in communication with the remote processor, the memory being configured to store a flowchart representation of the physical process and wherein the co-located processor is further configured to associate the probability metric with the physical process.

5. The system of claim 1 further comprising a memory in communication with the remote processor, the memory being configured to store a flowchart representation of the physical process and wherein the co-located processor is further configured to associate the safety-related metric with the physical process.

6. A system for monitoring a physical process, the system comprising:

a processor co-located with the physical process and being configured to accept a safety-related metric regarding the physical process;

a network in communication with the co-located processor;

a processor located remotely from the physical process and in communication with the network, the remote processor being configured to receive the safety-related metric from the co-located processor, to transform the safety-related metric to a probability metric, and to determine, based on the probability metric, whether the physical process is predictable; and

an output device in communication with the remote processor wherein the remote processor is further configured to output the safety-related predictability determination regarding the physical process via the output device.

7. The system of claim 6 wherein the physical process is associated with a petrochemical well.

8. The system of claim 6 wherein the physical process is one of a food or beverage production process.

9. The system of claim 6 further comprising a memory in communication with the remote processor, the memory being configured to store a flowchart representation of the physical process and wherein the co-located processor is further configured to associate the probability metric with the physical process.

10. The system of claim 6 further comprising a memory in communication with the remote processor, the memory being configured to store a flowchart representation of the physical process and wherein the co-located processor is further configured to associate the safety-related metric with the physical process.

11. A system for monitoring a process, the system comprising:

a processor co-located with the process and being configured to accept a metric regarding the process;

a network in communication with the co-located processor;

a processor located remotely from the process and in communication with the network, the remote processor being configured to receive the metric from the co-located processor, to transform the metric to a probability metric, and to determine, based on the probability metric, whether the process is predictable; and

an output device in communication with the remote processor wherein the remote processor is further configured to output the predictability determination regarding the process via the output device.

12. The system of claim 11 wherein the process is associated with a petrochemical well.

13. The system of claim 11 wherein the process is one of a food or beverage production process.

14. The system of claim 11 further comprising a memory in communication with the remote processor, the memory being configured to store a flowchart representation of the process and wherein the co-located processor is further configured to associate the probability metric with an operation of the process.

15. The system of claim 11 further comprising a memory in communication with the remote processor, the memory being configured to store a flowchart representation of the process and wherein the co-located processor is further configured to associate the metric with the process.

16. The system of claim 11 wherein the metric is a safety-related metric.