Patent Application
20070233536
This invention relates to controlling a business, and in a more particular implementation, to using a computer-based technique to control a business.
A variety of automated techniques exist for making business forecasts, including various business simulation techniques. However, these techniques are often applied in an unstructured manner. For instance, a business analyst may have a vague notion that computer-automated forecasting tools might be of use in predicting certain aspects of business performance. In this case, the business analyst proceeds by selecting a particular forecasting tool, determining the data input requirements of the selected tool, manually collecting the required data from the business, and then performing a forecast using the tool to generate an output result. The business analyst then determines whether the output result warrants making changes to the business. If so, the business analyst attempts to determine what aspects of the business should be changed, and then proceeds to modify these aspects in manual fashion, e.g., by manually accessing and modifying a resource used by the business. If the result of these changes does not produce a satisfactory result, the business analyst may decide to make further corrective changes to the business.
The above ad hoc approach has many drawbacks. For instance, the forecasting tools employed by the business analyst are not integrated with the business itself. This can introduces time delays in collecting information required by the tools, as well as time delays in implementing changes to the business after running the tools. These time delays can cause the business to “veer off course” with respect to its stated objectives. In other words, the time delays may prevent the business from recognizing and acting on opportunities or problems in a timely manner, thus allowing the business to deviate from its optimal path, and thereby increasing the level of risk facing the business or sub-optimizing a dimension of the business's performance.
Further, many businesses involve a complex interrelation of subsystems, assets processes, personnel, etc. It is often not intuitive what changes should be made to the business in response to the output result generated by a forecasting tool. This lack of insight into how a business should be changed can result in the analyst making non-optimal changes to the business, or, in some cases, making overtly incorrect changes. For instance, the changes can cause time domain oscillations in the performance of the business, where, for instance, a first change in the business yields a non-optimal result that requires the business analyst to make a corrective change to compensate for this non-optimal result, and this corrective change itself produces non-optimal results that require further corrective action, and so on. Further, business tools typically provide predictions regarding a narrow aspect of a generic business environment. Since these techniques do not attempt to model the operation of a specific business as a whole, they may produce output results which fail to take into account the complex interrelationships of many business environments that involve plural, cross-correlated processes and subsystems.
Accordingly, there is an exemplary need in the art to provide a more efficient and reliable control of a business.
According to one exemplary implementation, a method is described for affecting changes in a business including a multiple interrelated business processes. The method includes: (a) providing a business information and decisioning control system to a user, the business information and decisioning control system having a business system user interface; (b) generating an output result using a business model provided by the business information and decisioning control system, the output result providing guidance on the control of the business; (c) presenting the output result to the user via the business system user interface; (d) receiving the user's selection of a command via the business system user interface, where the command prompts at least one of the interrelated business processes to make a change, the change based on guidance provided by the output result; (e) transmitting instructions to the at least one of the interrelated business processes, where the instructions are based on the command; and (f) executing the change in the at least one interrelated business processes in response to the command.
Related method of use, system, and interface implementations are also described.
The same numbers are used throughout the disclosure and figures to reference like components and features. Series 100 numbers refer to features originally found in
An information and decisioning control system that provides business forecasts is described herein. The system is used to control a business that includes multiple interrelated processes. The term “business” has broad connotation. A business may refer to a conventional enterprise for providing goods or services for profit (or to achieve some other business-related performance metric). The business may include a single entity, or a conglomerate entity comprising several different business groups or companies. Further, a business may include a chain of businesses formally or informally coupled through market forces to create economic value. The term “business” may also loosely refer to any organization, such as any non-profit organization, an academic organization, governmental organization, etc.
Generally, the terms “forecast” and “prediction” are also used broadly in this disclosure. These terms encompass any kind of projection of “what may happen” given any kind of input assumptions. In one case, a user may generate a prediction by formulating a forecast based on the course of the business thus far in time. Here, the input assumption is defined by the actual course of the business. In another case, a user may generate a forecast by inputting a set of assumptions that could be present in the business (but which do not necessarily reflect the current state of the business), which prompts the system to generate a forecast of what may happen if these assumptions are realized. Here, the forecast assumes more of a hypothetical (“what if”) character (e.g., “If X is put into place, then Y is likely to happen”).
To facilitate explanation, the business information and decisioning control system is referred to in the ensuing discussion by the descriptive phrase “digital cockpit.” A business intelligence interface of the digital cockpit will be referenced to as a “cockpit interface.”
The disclosure contains the following sections:
A. Overview of a Digital Cockpit with Predictive Capability (with Reference to
More specifically, each of the processes (106, 108, . . . 110) can include a collection of resources. The term “resources” as used herein has broad connotation and can include any aspect of the process that allows it to transform input items into output items. For instance, process 106 may draw from one or more engines 112. An “engine” 112 refers to any type of tool used by the process 106 in performing the allocated function of the process 106. In the context of a manufacturing environment, an engine 112 might refer to a machine for transforming materials from an initial state to a processed state. In the context of a finance-related environment, an engine 112 might refer to a technique for transforming input information into processed output information. For instance, in one finance-related application, an engine 112 may include one or more equations for transforming input information into output information. In other applications, an engine 112 may include various statistical techniques, rule-based techniques, artificial intelligence techniques, etc. The behavior of these engines 112 can be described using transfer functions. A transfer function translates at least one input into at least one output using a translation function. The translation function can be implemented using a mathematical model or other form of mapping strategy.
A subset of the engines 112 can be used to generate decisions at decision points within a business flow. These engines are referred to as “decision engines.” The decision engines can be implemented using manual analysis performed by human analysts, automated analysis performed by automated computerized routines, or a combination of manual and automated analysis.
Other resources in the process 106 include various procedures 114. In one implementation, the procedures 114 represent general protocols followed by the business in transforming input items into output items. In another implementation, the procedures 114 can reflect automated protocols for performing this transformation.
The process 106 may also generically include “other resources” 116. Such other resources 116 can include any feature of the process 106 that has a role in carrying out the function(s) of the process 106. An exemplary “other resource” may include staffing resources. Staffing resources refer to the personnel used by the business 102 to perform the functions associated with the process 106. For instance, in a manufacturing environment, the staffing resources might refer to the workers required to run the machines within the process. In a finance-related environment, the staffing resources might refer to personnel required to perform various tasks involved in transforming information or “financial products” (e.g., contracts) from an initial state to a final processed state. Such individuals may include salesman, accountants, actuaries, etc. Still other resources can include various control platforms (such as Supply Chain, Enterprise Resource Planning, Manufacturing-Requisitioning and Planning platforms, etc.), technical infrastructure, etc.
In like fashion, process 108 includes one or more engines 118, procedures 120, and other resources 122. Process 110 includes one or more engines 124, procedures 126, and other resources 128. Although the business 102 is shown as including three processes (106, 108, . . . 110), this is merely exemplary; depending on the particular business environment, more than three processes can be included, or less than three processes can be included.
The digital cockpit 104 collects information received from the processes (106, 108, . . . 110) via communication path 130, and then processes this information. Such communication path 130 may represent a digital network communication path, such as the Internet, an Intranet network within the business enterprise 102, a LAN network, etc.
The digital cockpit 104 itself includes a cockpit control module 132 coupled to a cockpit interface 134. The cockpit control module 132 includes one or more models 136. A model 136 transforms information collected by the processes (106, 108, . . . 110) into an output using a transfer function or plural transfer functions. As explained above, the transfer function of a model 136 maps one or more independent variables (e.g., one or more X variables) into one or more dependent variables (e.g., one or more Y variables). For example, a model 136 that employs a transfer function can map one or more X variables that pertain to historical information collected from the processes (106, 108, . . . 110) into one or more Y variables that deterministically and/or probabilistically forecast what is likely to happen in the future. Such models 136 may use, for example, discrete event simulations, continuous simulations, Monte Carlo simulations, regressive analysis techniques, time series analyses, artificial intelligence analyses, extrapolation and logic analyses, etc.
Other functionality provided by the cockpit control module 132 can perform data collection tasks. Such functionality specifies the manner in which information is to be extracted from one or more information sources and subsequently transformed into a desired form. The information can be transformed by algorithmically processing the information using one or more models 136, or by manipulating the information using other techniques. More specifically, such functionality is generally implemented using so-called Extract-Transform-Load tools (i.e., ETL tools).
A subset of the models 136 in the cockpit control module 132 may be the same as some of the models embedded in engines (112, 118, 124) used in respective processes (106, 108, . . . 110). In this case, the same transfer functions used in the cockpit control module 132 can be used in the day-to-day business operations within the processes (106, 108, . . . 110). Other models 136 used in the cockpit control module 132 are exclusive to the digital cockpit 104 (e.g., having no counterparts within the processes themselves (106, 108, . . . 110)). In the case where the cockpit control module 132 uses the same models 136 as one of the processes (106, 108, . . . 110), it is possible to store and utilize a single rendition of these models 136, or redundant copies or versions of these models 136 can be stored in both the cockpit control module 132 and the processes (106, 108, . . . 110).
A cockpit user 138 interacts with the digital cockpit 104 via the cockpit interface 134. The cockpit user 138 can include any individual within the business 102 (or potentially outside the business 102). The cockpit user 138 frequently will have a decision-maker role within the organization, such as chief executive officer, risk assessment analyst, general manager, an individual intimately familiar with one or more business processes (e.g., a business “process owner”), and so on.
The cockpit interface 134 presents various fields of information regarding the course of the business 102 to the cockpit user 138 based on the outputs provided by the models 136. For instance, the cockpit interface 134 may include a field 140 for presenting information regarding the past course of the business 102 (referred to as a “what has happened” field, or a “what-was” field for brevity). The cockpit interface 134 may include another field 142 for presenting information regarding the present state of the business 102 (referred to as “what is happening” field, or a “what-is” field for brevity). The cockpit interface 134 may also include another field 144 for presenting information regarding the projected future course of the business 102 (referred to as a “what may happen” field, or “what-may” field for brevity).
In addition, the cockpit interface 134 presents another field 146 for receiving hypothetical case assumptions from the cockpit user 138 (referred to as a “what-if” field). More specifically, the what-if field 146 allows the cockpit user 138 to enter information into the cockpit interface 134 regarding hypothetical or actual conditions within the business 102. The digital cockpit 104 will then compute various consequences of the identified conditions within the business 102 and present the results to the cockpit user 138 for viewing in the what-if display field 146.
After analyzing information presented by fields 140, 142, 144, and 146, the cockpit user 138 may be prepared to take some action within the business 102 to steer the business 102 in a desired direction based on some objective in mind (e.g., to increase revenue, increase sales volume, improve processing timeliness, etc.). To this end, the cockpit interface 134 includes another field (or fields) 148 for allowing the cockpit user 138 to enter commands that specify what the business 102 is to do in response to information (referred to as “do-what” commands for brevity). More specifically, the do-what field 148 can include an assortment of interface input mechanisms (not shown), such as various graphical knobs, sliding bars, text entry fields, etc. (In addition, or in the alternative, the input mechanisms can include other kinds of input devices, such as voice recognition devices, motion detection devices, various kinds of biometric input devices, various kinds of biofeedback input devices, and so on.) The business 102 includes a communication path 150 for forwarding instructions generated by the do-what commands to the processes (106, 108, . . . 110). Such communication path 150 can be implemented as a digital network communication path, such as the Internet, an intranet within a business enterprise 102, a LAN network, etc. In one implementation, the communication path 130 and communication path 150 can be implemented as the same digital network.
The do-what commands can affect a variety of changes within the processes (106, 108, . . . 110) depending on the particular business environment in which the digital cockpit 104 is employed. In one case, the do-what commands affect a change in the engines (112, 118, 124) used in the respective processes (106, 108, . . . 110). Such modifications may include changing parameters used by the engines (112, 118, 124), changing the strategies used by the engines (112, 118, 124), changing the input data fed to the engines (112, 118, 124), or changing any other aspect of the engines (112, 118, 124). In another case, the do-what commands affect a change in the procedures (114, 120, 126) used by the respective processes (106, 108, 110). Such modifications may include changing the number of workers assigned to specific tasks within the processes (106, 108, . . . 110), changing the amount of time spent by the workers on specific tasks in the processes (106, 108, . . . 110), changing the nature of tasks assigned to the workers, or changing any other aspect of the procedures (114, 120, 126) used in the processes (106, 108, . . . 110). Finally, the do-what commands can generically make other changes to the other resources (116, 122, 128), depending on the context of the specific business application.
The business 102 provides other mechanisms for affecting changes in the processes (106, 108, . . . 110) besides the do-what field 148. Namely, in one implementation, the cockpit user 138 can directly make changes to the processes (106, 108, . . . 110) without transmitting instructions through the communication path 150 via the do-what field 148. In this case, the cockpit user 138 can directly visit and make changes to the engines (112, 118, 124) in the respective processes (106, 108, . . . 110). Alternatively, the cockpit user 138 can verbally instruct various staff personnel involved in the processes (106, 108, . . . 110) to make specified changes.
In still another case, the cockpit control module 132 can include functionality for automatically analyzing information received from the processes (106, 108, . . . 110), and then automatically generating do-what commands for dissemination to appropriate target resources within the processes (106, 108, . . . 110). As will be described in greater detail below, such automatic control can include mapping various input conditions to various instructions to be propagated into the processes (106, 108, . . . 110). Such automatic control of the business 102 can therefore be likened to an automatic pilot provided by a vehicle. In yet another implementation, the cockpit control module 132 generates a series of recommendations regarding different courses of actions that the cockpit user 138 might take, and the cockpit user 138 exercises human judgment in selecting a control strategy from among the recommendations (or in selecting a strategy that is not included in the recommendations).
A steering control interface 152 generally represents the cockpit user 138's ability to make changes to the business processes (106, 108, . . . 110), whether these changes are made via the do-what field 148 of the cockpit interface 134, via conventional and manual routes, or via automated process control. To continue with the metaphor of a physical cockpit, the steering control interface 152 generally represents a steering stick used in an airplane cockpit to steer the airplane, where such a steering stick may be controlled by the cockpit user by entering commands through a graphical user interface. Alternatively, the steering stick can be manually controlled by the user, or automatically controlled by an “auto-pilot.”
Whatever mechanism is used to affect changes within the business 102, such changes can also include modifications to the digital cockpit 104 itself. For instance, the cockpit user 138 can also make changes to the models 136 used in the cockpit control module 132. Such changes may comprise changing the parameters of a model 136, or entirely replacing one model 136 with another model 136, or supplementing the existing models 136 with additional models 136. Moreover, the use of the digital cockpit 104 may comprise an integral part of the operation of different business processes (106, 108, . . . 110). In this case, cockpit user 138 may want to change the models 136 in order to affect a change in the processes (106, 108, . . . 110).
In one implementation, the digital cockpit 104 receives information from the business 102 and forwards instructions to the business 102 in real time or near real time. That is, in this case, the digital cockpit 104 collects data from the business 102 in real time or near real time. Further, if configured to run in an automatic mode, the digital cockpit 104 automatically analyzes the collected data using one or more models 136 and then forwards instructions to processes (106, 108, . . . 110) in real time or near real time. In this manner, the digital cockpit 104 can translate changes that occur within the processes (106, 108, . . . 110) to appropriate corrective action transmitted to the processes (106, 108, . . . 110) in real time or near real time in a manner analogous to an auto-pilot of a moving vehicle. In the context used here, “near real time” generally refers to a time period that is sufficient timely to steer the business 102 along a desired path, without incurring significant deviations from this desired path. Accordingly, the term “near real time” will depend on the specific business environment in which the digital cockpit 104 is deployed; in one exemplary embodiment, “near real time” can refer to a delay of several seconds, several minutes, etc.
An Extract-Transform-Load (ETL) module 206 extracts information from the business data warehouses 202 and the external sources 204, and performs various transformation operations on such information. The transformation operations can include: 1) performing quality assurance on the extracted data to ensure adherence to pre-defined guidelines, such as various expectations pertaining to the range of data, the validity of data, the internal consistency of data, etc; 2) performing data mapping and transformation, such as mapping identical fields that are defined differently in separate data sources, eliminating duplicates, validating cross-data source consistency, providing data convergence (such as merging records for the same customer from two different data sources), and performing data aggregation and summarization; 3) performing post-transformation quality assurance to ensure that the transformation process does not introduce errors, and to ensure that data convergence operations did not introduce anomalies, etc. The ETL module 206 also loads the collected and transformed data into a data warehouse 208. The ETL module 206 can include one or more selectable tools for performing its ascribed tasks, collectively forming an ETL toolset. For instance, the ETL toolset can include one of the tools provided by Informatica Corporation of Redwood City, Calif., and/or one of the tools provided by DataJunction Corporation of Austin, Tex. Still other tools can be used in the ETL toolset, including tools specifically tailored by the business 102 to perform unique in-house functions.
The data warehouse 208 may represent one or more storage devices. If multiple storage devices are used, these storage devices can be located in one central location or distributed over plural sites. Generally, the data warehouse 208 captures, scrubs, summarizes, and retains the transactional and historical detail necessary to monitor changing conditions and events within the business 102. Various known commercial products can be used to implement the data warehouse 208, such as various data storage solutions provided by the Oracle Corporation of Redwood Shores, Calif.
Although not shown in
The architecture 200 can also include a digital cockpit data mart (not shown) that culls a specific set of information from the data warehouse 208 for use in performing a specific subset of tasks within the business enterprise 102. For instance, the information provided in the data warehouse 208 may serve as a global resource for the entire business enterprise 102. The information culled from this data warehouse 208 and stored in the data mart (not shown) may correspond to the specific needs of a particular group or sector within the business enterprise 102.
The information collected and stored in the above-described manner is fed into the cockpit control module 132. The cockpit control module 132 can be implemented as any kind of computer device, including one or more processors 210, various memory media (such as RAM, ROM, disc storage, etc.), a communication interface 212 for communicating with an external entity, a bus 214 for communicatively coupling system components together, as well as other computer architecture features that are known in the art. In one implementation, the cockpit control module 132 can be implemented as a computer server coupled to a network 216 via the communication interface 212. In this case, any kind of server platform can be used, such as server functionality provided by iPlanet, produced by Sun Microsystems, Inc., of Santa Clara, Calif. The network 216 can comprise any kind of communication network, such as the Internet, a business Intranet, a LAN network, an Ethernet connection, etc. The network 216 can be physically implemented as hardwired links, wireless links (e.g., radio frequency links), a combination of hardwired and wireless links, or some other architecture. It can use digital communication links, analog communication links, or a combination of digital and analog communication links.
The memory media within the cockpit control module 132 can be used to store application logic 218 and record storage 220. For instance, the application logic 218 can constitute different modules of program instructions stored in RAM memory. The record storage 220 can constitute different databases for storing different groups of records using appropriate data structures. More specifically, the application logic 218 includes analysis logic 222 for performing different kinds of analytical tasks. For example, the analysis logic 222 includes historical analysis logic 224 for processing and summarizing historical information collected from the business 102, and/or for presenting information pertaining to the current status of the business 102. The analysis logic 222 also includes predictive analysis logic 226 for generating business forecasts based on historical information collected from the business 102. Such predictions can take the form of extrapolating the past course of the business 102 into the future, and for generating error information indicating the degrees of confidence associated with its predictions. Such predictions can also take the form of generating predictions in response to an input what-if scenario. A what-if scenario refers to a hypothetical set of conditions (e.g., cases) that could be present in the business 102. Thus, the predictive logic 226 would generate a prediction that provides a forecast of what might happen if such conditions (e.g., cases) are realized through active manipulation of the business processes (106, 108, . . . 110).
The analysis logic 222 further includes optimization logic 228. The optimization logic 228 computes a collection of model results for different input case assumptions, and then selects a set of input case assumptions that provides preferred model results. More specifically, this task can be performed by methodically varying different variables defining the input case assumptions and comparing the model output with respect to a predefined goal (such as an optimized revenue value, or optimized sales volume, etc.). The case assumptions that provide the “best” model results with respect to the predefined goal are selected, and then these case assumptions can be actually applied to the business processes (106, 108, . . . 110) to realize the predicted “best” model results in actual business practice.
Further, the analysis logic 222 also includes pre-loading logic 230 for performing data analysis in off-line fashion. More specifically, processing cases using the models 136 may be time-intensive. Thus, a delay may be present when a user requests a particular analysis to be performed in real-time fashion. To reduce. this delay, the pre-loading logic 230 performs analysis in advance of a user's request. As will be described in Section D of this disclosure, the pre-loading logic 230 can perform this task based on various considerations, such as an assessment of the variation in the response surface of the model 136, an assessment of the likelihood that a user will require specific analyses, etc.
The analysis logic 222 can include a number of other modules for performing analysis, although not specifically identified in
The storage logic 220 can include a database 232 that stores various models scripts. Such models scripts provide instructions for running one or more analytical tools in the analysis logic 222. As used in this disclosure, a model 136 refers to an integration of the tools provided in the analysis logic 222 with the model scripts provided in the database 232. In general, such tools and scripts can execute regression analysis, time-series computations, cluster analysis, and other types of analyses. A variety of commercially available software products can be used to implement the above-described modeling tasks. To name but a small sample, the analysis logic 222 can use one or more of the family of Crystal Ball products produced by Decisioneering, Inc. of Denver Colo., one or more of the Mathematica products produced by Wolfram, Inc. of Champaign Ill., one or more of the SAS products produced by SAS Institute Inc. of Cary, N.C., etc. Such models 136 generally provide output results (e.g., one or more Y variables) based on input data (e.g., one or more X variables). Such X variables can represent different kinds of information depending on the configuration and intended use of the model 136. Generally, input data may represent data collected from the business 102 and stored in the database warehouses 208. Input data can also reflect input assumptions specified by the cockpit user 138, or automatically selected by the digital cockpit 104. An exemplary transfer function used by a model 136 can represent a mathematical equation or other function fitted to empirical data collected over a span of time. Alternatively, an exemplary transfer function can represent a mathematical equation or other function derived from “first principles” (e.g., based on a consideration of economic principles). Other exemplary transfer functions can be formed based on other considerations.
The storage logic 220 can also include a database 234 for storing the results pre-calculated by the pre-loading logic 230. As mentioned, the digital cockpit 104 can retrieve results from this database when the user requests these results, instead of calculating these results at the time of request. This reduces the time delay associated with the presentation of output results, and supports the overarching aim of the digital cockpit 104, which is to provide timely and accurate results to the cockpit user 138 when the cockpit user 138 needs such results. The database 234 can also store the results of previous analyses performed by the digital cockpit 104, so that if these results are requested again, the digital cockpit 104 need not recalculate these results.
The application logic 218 also includes other programs, such as display presentation logic 236. The display presentation logic 236 performs various tasks associated with displaying the output results of the analyses performed by the analysis logic 222. Such display presentation tasks can include presenting probability information that conveys the confidence associated with the output results using different display formats. The display presentation logic 236 can also include functionality for rotating and scaling a displayed response surface to allow the cockpit user 138 to view the response surface from different “vantage points,” to thereby gain better insight into the characteristics of the response surface. Section E of this disclosure provides additional information regarding exemplary functions performed by the display presentation logic 236.
The application logic 218 also includes development toolkits 238. A first kind of development toolkit 238 provides a guideline used to develop a digital cockpit 104 with predictive capabilities. More specifically, a business 102 can comprise several different affiliated companies, divisions, branches, etc. A digital cockpit 104 may be developed in for one part of the company, and thereafter tailored to suit other parts of the company. The first kind of development toolkit 238 provides a structured set of consideration that a development team should address when developing the digital cockpit 104 for other parts of the company (or potentially, for another unaffiliated company). The first kind of development toolkit 238 may specifically include logic for providing a general “roadmap” for developing the digital cockpit 104 using a series of structured stages, each stage including a series of well-defined action steps. Further, the first kind of development toolkit 238 may also provide logic for presenting a number of tools that are used in performing individual action steps within the roadmap. U.S. patent application Ser. No. 10/______ (Attorney Docket No. 85CI-00128), filed on the same day as the present application, and entitled, “Development of a Model for Integration into a Business Intelligence System,” provides additional information regarding the first kind of development toolkit 238. A second kind of development toolkit 238 can be used to derive the transfer functions used in the predictive digital cockpit 104. This second kind of development toolkit 238 can also include logic for providing a general roadmap for deriving the transfer functions, specifying a series of stages, where each stage includes a defined series of action steps, as well as a series of tools for use at different junctures in the roadmap. Record storage 220 includes a database 240 for storing information used in conjunction with the development toolkits 238, such as various roadmaps, tools, interface page layouts, etc.
Finally, the application logic 218 includes do-what logic 242. The do-what logic 242 includes the program logic used to develop and/or propagate instructions into the business 102 for affecting changes in the business 102. For instance, as described in connection with
In one implementation, the do-what logic 242 is used to receive do-what commands entered by the cockpit user 138 via the cockpit interface 134. Such cockpit interface 134 can include various graphical knobs, slide bars, switches, etc. for receiving the user's commands. In another implementation, the do-what logic 242 is used to automatically generate the do-what commands in response to an analysis of data received from the business processes (106, 108, . . . 110). In either case, the do-what logic 242 can rely on a coupling database 244 in developing specific instructions for propagation throughout the business 102. For instance, the do-what logic 242 in conjunction with the database 244 can map various entered do-what commands into corresponding instructions for affecting specific changes in the resources of business processes (106, 108, . . . 110). This mapping can rely on rule-based logic. For instance, an exemplary rule might specify: “If a user enters instruction X, then affect change Y to engine resource 112 of process 106, and affect change Z to procedure 120 of process 108.” Such rules can be stored in the couplings database 244, and this information may effectively reflect empirical knowledge garnished from the business processes (106, 108, . . . 110) over time (e.g., in response to observed causal relationships between changes made within a business 102 and their respective effects). Effectively, then, this coupling database 244 constitutes the “control coupling” between the digital cockpit 104 and the business processes (106, 108, . . . 110) which it controls in a manner analogous to the control coupling between a control module of a physical system and the subsystems which it controls. In other implementations, still more complex strategies can be used to provide control of the business 102, such as artificial intelligence systems (e.g., expert systems) for translating a cockpit user 138's commands to the instructions appropriate to affect such instructions.
The cockpit user 138 can receive information provided by the cockpit control module 132 using different devices or different media.
The exemplary workstation 246 includes conventional computer hardware, including a processor 252, RAM 254, ROM 256, a communication interface 258 for interacting with a remote entity (such as network 216), storage 260 (e.g., an optical and/or hard disc), and an input/output interface 262 for interacting with various input devices and output devices. These components are coupled together using bus 264. An exemplary output device includes the cockpit interface 134. The cockpit interface 134 can present an interactive display 266, which permits the cockpit user 138 to control various aspects of the information presented on the cockpit interface 134. Cockpit interface 134 can also present a static display 268, which does not permit the cockpit user 138 to control the information presented on the cockpit interface 134. The application logic for implementing the interactive display 266 and the static display 268 can be provided in the memory storage of the workstation 246 (e.g., the RAM 254, ROM 256, or storage 260, etc.), or can be provided by a computing resource coupled to the workstation 246 via the network 216, such as display presentation logic 236 provided in the cockpit control module 132.
Finally, an input device 270 permits the cockpit user 138 to interact with the workstation 246 based on information displayed on the cockpit interface 134. The input device 270 can include a keyboard, a mouse device, a joy stick, a data glove input mechanism, throttle input mechanism, track ball input mechanism, a voice recognition input mechanism, a graphical touch-screen display field, various kinds of biometric input devices, various kinds of biofeedback input devices, etc., or any combination of these devices.
Window 306 provides information regarding the past course (i.e., history) of the business 102, as well as its present state. Window 308 provides information regarding both the past, current, and projected future condition of the business 102. The cockpit control module 132 can generate the information shown in window 308 using one or more models 136. Although not shown, the cockpit control module 132 can also calculate and present information regarding the level of confidence associated with the business predictions shown in window 308. Additional information regarding the presentation of confidence information is presented in section E of this disclosure. Again, the predictive information shown in windows 306 and 308 is strictly illustrative; a great variety of additional presentation formats can be provided depending on the business environment in which the business 102 operates and the design preferences of the cockpit designer. Additional presentation strategies include displays having confidence bands, n-dimensional graphs, and so on.
The cockpit interface 134 can also present interactive information, as shown in window 310. This window 310 includes an exemplary multi-dimensional response surface 312. Although response surface 312 has three dimensions, response surfaces having more than three dimensions can be presented. The response surface 312 can present information regarding the projected future course of business 102, where the z-axis of the response surface 312 represents different slices of time. The window 310 can further include a display control interface 314 which allows the cockpit user 138 to control the presentation of information presented in the window 310. For instance, in one implementation, the display control interface 314 can include an orientation arrow that allows the cockpit user 138 to select a particular part of the displayed response surface 312, or which allows the cockpit user 138 to select a particular vantage point from which to view the response surface 312. Again, additional details regarding this aspect of the cockpit interface 134 are discussed in Section E of this disclosure
The cockpit interface 134 further includes another window 316 that provides various control mechanisms. Such control mechanisms can include a collection of graphical input knobs or dials 318, a collection of graphical input slider bars 320, a collection of graphical input toggle switches 322, as well as various other graphical input devices 324 (such as data entry boxes, radio buttons, etc.). These graphical input mechanisms (318, 320, 322, 324) are implemented, for example, as touch sensitive fields in the cockpit interface 134. Alternatively, these input mechanisms (318, 320, 322, 324) can be controlled via other input devices, or can be replaced by other input devices. Exemplary alternative input devices were identified above in the context of the discussion of input device(s) 270 of
In one use, the input mechanisms (318, 320, 322, 324) provided in the window 320 can be used to input various what-if assumptions. The entry of this information prompts the digital cockpit 104 to generate scenario forecasts based on the input what-if assumptions. More specifically, the cockpit interface 134 can present output results using the two-dimensional presentation shown in window 308, the three-dimensional presentation shown in window 310, an n-dimensional presentation (not shown), or some other format (such as bar chart format, spread sheet format, etc.).
In another use, the input mechanisms (318, 320, 322, 324) provided in window 316 can be used to enter do-what commands. As described above, the do-what commands can reflect decisions made by the cockpit user 138 based on his or her business judgment, that, in turn, can reflect the cockpit user's business experience. Alternatively, the do-what commands may be based on insight gained by running one or more what-if scenarios. As will be described, the cockpit user 138 can manually initiate these what-if scenarios or can rely, in whole or in part, on automated algorithms provided by the digital cockpit 104 to sequence through a number of what-if scenarios using an optimization strategy. As explained above, the digital cockpit 104 propagates instructions based on the do-what commands to different target processes (106, 108, . . . 110) in the business 102 to affect specified changes in the business 102.
Generally speaking, the response surface 312 (or other type of presentation provided by the cockpit interface 134) can provide a dynamically changing presentation in response to various events fed into the digital cockpit 104. For instance, the response surface 312 can be computed using a model 136 that generates output results based, in part, on data collected from the processes (106, 108, . . . 110) and stored in the data warehouses 208. As such, changes in the processes (106, 108, . . . 110) will prompt real time or near real time corresponding changes in the response surface 312. Further, the cockpit user 138 can dynamically make changes to what-if assumptions via the input mechanisms (318, 320, 322, 324) of the control panel 316. These changes can induce corresponding lockstep dynamic changes in the response surface 312.
By way of summary, the cockpit interface 134 provides a “window” into the operation of the business 102, and also provides an integrated command and control center for making changes to the business 102. The cockpit interface 134 also allows the cockpit user 138 to conveniently switch between different modes of operation. For instance, the cockpit interface 134 allows the user to conveniently switch between a what-if mode of analysis (in which the cockpit user 138 investigates the projected probabilistic outcomes of different case scenarios) and a do-what mode of command (in which the cockpit user 138 enters various commands for propagation throughout the business 102). While the cockpit interface 134 shown in
In a what-if/do-what portion 408 of the method 400, in step 410, a cockpit user 138 examines the output fields of information presented on the cockpit interface 134 (which may include the above-described what-has, what-is, and what-may fields of information). The looping path between step 410 and the historical database 406 generally indicates that step 410 utilizes the information stored in the historical database 406.
Presume that, based on the information presented in step 410, the cockpit user 138 decides that the business 102 is currently headed in a direction that is not aligned with a desired goal. For instance, the cockpit user 138 can use the what-may field 144 of cockpit interface 134 to conclude that the forecasted course of the business 102 will not satisfy a stated goal. To remedy this problem, in step 412, the cockpit user 138 can enter various what-if hypothetical cases into the digital cockpit 104. These what-if cases specify a specific set of conditions that could prevail within the business 102, but do not necessarily match current conditions within the business 102. This prompts the digital cockpit 104 to calculate what may happen if the stated what-if hypothetical input case assumptions are realized. Again, the looping path between step 412 and the historical database 406 generally indicates that step 412 utilizes the information stored in the historical database 406. In step 414, the cockpit user 138 examines the results of the what-if predictions. In step 416, the cockpit user 138 determines whether the what-if predictions properly set the business 102 on a desired path toward a desired target. If not, the cockpit user 138 can repeat steps 412 and 414 for as many times as necessary, successively entering another what-if input case assumption, and examining the output result based on this input case assumption.
Assuming that the cockpit user 138 eventually settles on a particular what-if case scenario, in step 418, the cockpit user 138 can change the business processes (106, 108, . . . 110) to carry out the simulated what-if scenario. The cockpit user 138 can perform this task by entering do-what commands into the do-what field 148 of the cockpit interface 134. This causes the digital cockpit 104 to propagate appropriate instructions to targeted resources used in the business 102. For instance, command path 420 sends instructions to personnel used in the business 102. These instructions can command the personnel to increase the number of workers assigned to a task, decrease the number of workers assigned to a task, change the nature of the task, change the amount of time spent in performing the task, change the routing that defines the “input” fed to the task, or other specified change. Command path 422 sends instructions to various destinations over a network, such as the Internet (WWW), a LAN network, etc. Such destinations may include a supply chain entity, a financial institution (e.g., a bank), an intra-company subsystem, etc. Command path 424 sends instructions to engines (112, 118, 124) used in the processes (106, 108, . . . 110) of the business 102. These instructions can command the engines (112, 118, 124) to change its operating parameters, change its input data, change its operating strategy, as well as other changes.
In summary, the method shown in
Steps 412, 414 and 416 collectively represent a manual routine 426 used to explore a collection of what-if case scenarios. In another implementation, the manual routine 426 can be supplemented or replaced with an automated optimization routine 428. As will be described more fully in connection with
In one implementation, the automated optimization routine 428 can be manually initiated by the cockpit user 138, for example, by entering various commands into the cockpit interface 134. In another implementation, the automated optimization routine 428 can be automatically triggered in response to predefined events. For instance, the automated optimization routine 428 can be automatically triggered if various events occur within the business 102, as reflected by collected data stored in the data warehouses 208 (such as the event of the collected data exceeding or falling below a predefined threshold). Alternatively, the analysis shown in
In any event, the output results generated via the process 400 shown in
To summarize the discussion of
Second, an airplane cockpit has various gauges and displays for providing substantial quantities of past and current information pertaining to the airplane's flight, as well as to the status of subsystems used by the airplane. The effective navigation of the airplane demands that the airplane cockpit presents this information in a timely, intuitive, and accessible form, such that it can be acted upon by the pilot or autopilot in the operation of the airplane. In a similar fashion, the digital cockpit 104 of a business 102 also can present summary information to assist the user in assessing the past and present state of the business 102, including its various “engineering” processes (106, 108, . . . 110).
Third, an airplane cockpit also has various forward-looking mechanisms for determining the likely future course of the airplane, and for detecting potential hazards in the path of the airplane. For instance, the engineering constraints of an actual airplane prevent it from reacting to a hazard if given insufficient time. As such, the airplane may include forward-looking radar to look over the horizon to see what lies ahead so as to provide sufficient time to react. In the same way, a business 102 may also have natural constraints that limit its ability to react instantly to assessed hazards or changing market conditions. Accordingly, the digital cockpit 104 of a business 102 also can present various business predictions to assist the user in assessing the probable future course of the business 102. This look-ahead capability can constitute various forecasts and what-if analyses.
Additional details regarding the what-functionality, do-what functionality, pre-calculation of model output results, and visualization of model uncertainty are presented in the sections which follow.
B. What-if Functionality (with Reference to
Returning briefly to
To simulate a what-if scenario, the cockpit user 138 adjusts the input devices (318, 320, 322, 324) to select a particular permutation of actionable X variables. The digital cockpit 104 responds by simulating how the business 102 would react to this combination of input actionable X variables as if these actionable X variables were actually implemented within the business 102. The digital cockpit's 104 predictions can be presented in the window 310, which displays an n-dimensional response surface 312 that maps the output result Y variable as a function of other variables, such as time, and/or possibly one of the actionable X variables.
In one implementation, the digital cockpit 104 is configured to allow the cockpit user 138 to select the variables that are to be assigned to the axes of the response surface 312. For instance, the cockpit user 138 can initially assign a first actionable X variable to one of the axes in response surface 322, and then later reassign that axis to another of the actionable X variables. In addition, as discussed in Section A, the digital cockpit 104 can be configured to dynamically display changes to the response surface 312 while the cockpit user 138 varies one or more input mechanisms (318, 320, 322, 324). The real-time coupling between actuations made in the control window 316 and changes presented to the response surface 312 allows the cockpit user 138 to gain a better understanding of the characteristics of the response surface 312.
With reference now to
The output variable of interest in
The role of the digital cockpit 104 in the process 500 of
In the specific context of
More specifically, the probability distribution curve 510 represents the simulated cycle time generated by the models 136 provided by the digital cockpit 104. Generally, different factors can contribute to uncertainty in the predicted output result. For instance, the input information and assumptions fed to the models 136 may have uncertainty associated therewith. For instance, such uncertainty may reflect variations in transport times associated with different tasks within the process 500, variations in different constraints that affect the process 500, as well as variations associated with other aspects of the process 500. This uncertainty propagates through the models 136, and results in uncertainty in the predicted output result.
More specifically, in one implementation, the process 500 collects information regarding its operation and stores this information in the data warehouse 208 described in
Another probability distribution curve 512 is shown that also bridges lines 506 and 508 (demarcating, respectively, the start and finish of the process 500). This probability distribution curve 512 can represent the actual uncertainty in the cycle time within process 500. That is, products (or other sampled entities) that have been processed by the process 500 (e.g., in the normal course of business) receive initial time stamps upon entering the process 500 (at point 506) and receive final time stamps upon exiting the process 500 (at point 508). The differences between the initial and final time stamps reflect respective different cycle times. The probability distribution curve 512 shows the prevalence at which different cycle times are encountered in the manner described above.
A comparison of probability distribution curve 512 and probability distribution curve 510 allows a cockpit user 138 to assess the accuracy of the digital cockpit's 104 predictions and take appropriate corrective measures in response thereto. In one case, the cockpit user 138 can rely on his or her business judgment in comparing distribution curves 510 and 512. In another case, the digital cockpit 104 can provide an automated mechanism for comparing salient features of distribution curves 510 and 512. For instance, this automated mechanism can determine the variation between the mean values of distributions curves 510 and 512, the variation between the shapes of distributions 510 and 512, and so on.
With the above introduction, it is now possible to describe the flow of operations in
The actual operations performed in boxes A, B, and C (518, 520, and 522, respectively) are not of interest to the principles being conveyed by
Assumption knob 3 (528) adjusts the workforce associated with whatever tasks are performed in operation C (522). More specifically, this assumption knob 3 (528) can be used to incrementally increase the number of staff from a current level, or incrementally decrease the number of staff from a current staff level.
Assumption knob 4 (530) also controls operation C (522). That is, assumption knob 4 (530) determines the amount of time that workers allocate to performing their assigned tasks in operation C (522), which is referred to as “touch time.” Assumption knob 4 (530) allows a cockpit user 138 to incrementally increase or decrease the touch time by percentage levels (e.g., by +10 percent, or −10 percent, etc.).
In decision block 532, the process 500 determines whether the output of operation C (522) is satisfactory by comparing the output of operation C (522) with some predetermined criterion (or criteria). If the process 500 determines that the results are satisfactory, then the flow proceeds to operation D (534) and operation E (536). Thereafter, the final product is output in operation 504. If the process 500 determines that the results are not satisfactory, then the flow proceeds to operation F (538) and operation G (540). Again, the nature of the tasks performed in each of these operations not germane to the present discussion, and can vary depending on the business application. In decision box 542, the process 500 determines whether the rework performed in operation F (538) and operation G (step 540) has provided a desired outcome. If so, the process advances to operation E (536), and then to output operation (504). If not, then the process 500 will repeat operation G (540) for as many times as necessary to secure a desirable outcome. Assumption knob 5 (544) allows the cockpit user 138 to define the amount of rework that should be performed to provide a satisfactory result. The assumption knob 5 (544) specifically allows the cockpit user 138 to specify the incremental percentage of rework to be performed. A rework meter 546 measures, in the context of the actual performance of the business flow, the amount of rework that is being performed.
By successively varying the collection of input knobs in the cockpit interface 134, the cockpit user 138 can identify particularly desirable portions of the predictive model's 136 response surface in which to operate the business process 500. One aspect of “desirability” pertains to the generation of desired target results. For instance, as discussed above, the cockpit user 138 may want to find that portion of the response surface that provides a desired cycle time (e.g., 40 hours, 30 hours, etc.). Another aspect of desirability pertains to the probability associated with the output results. The cockpit user 138 may want to find that portion of the response surface that provides adequate assurance that the process 500 can realize the desired target results (e.g., 70% confidence 80% confidence, etc.). Another aspect of desirability pertains to the generation of output results that are sufficiently resilient to variation. This will assure the cockpit user 138 that the output results will not dramatically change when only a small change in the case assumptions and/or “real world” conditions occurs. Taken all together, it is desirable to find the parts of the response surface that provide an output result that is on-target as well as robust (e.g., having suitable confidence and stability levels associated therewith). The cockpit user 138 can also use the above-defined what-if analysis to identify those parts of the response surface that the business distinctly does not want to operate within. The knowledge gleaned through this kind of use of the digital cockpit 104 serves a proactive role in steering the business away from a hazard. This aspect of the digital cockpit 104 is also valuable in steering the business out of a problematic business environment that it has ventured into due to unforeseen circumstances.
An assumption was made in the above discussion that the cockpit user 138 manually changes the assumption knobs in the cockpit interface 134 primarily based on his or her business judgment. That is, the cockpit user 138 manually selects a desired permutation of input knob settings, observes the result on the cockpit interface 134, and then selects another permutation of knob settings, and so on. However, in another implementation, the digital cockpit 104 can automate this trial and error approach by automatically sequencing through a series of input assumption settings. Such automation was introduced in the context of step 428 of
As to the data collection series of steps 602, step 606 involves collecting information from processes within a business, and then storing this information in a historical database 608, such as the data warehouse 208 described in the context of
As to the what-if/do-what series of steps 604, step 610 involves selecting a set of input assumptions, such as a particular combination of actionable X variables associated with a set of input knobs provided on the cockpit interface 134. Step 612 involves generating a prediction based on the input assumptions using a model 136 (e.g., a model which provides an output variable, Y, based on a function, f(X)). In one implementation, step 612 can use multiple different techniques to generate the output variable Y, such as Monte Carlo simulation techniques, discrete event simulation techniques, continuous simulation techniques, and other kinds of techniques. Step 614 involves performing various post-processing tasks on the output of the model 136. The post-processing operations can vary depending on the nature of a particular business application. In one case, step 614 entails consolidating multiple scenario results from different analytical techniques used in step 612. For example, step 612 may have involved using a transfer function to run 500 different case computations. These computations may have involved sampling probabilistic input assumptions in order to provide probabilistic output results. In this context, the post-processing step 614 entails combining and organizing the output results associated with different cases and making the collated output probability distribution available for downstream optimization and decisioning operations.
Step 616 entails analyzing the output of the post-processing step 614 to determine whether the output result satisfies various criteria. For instance, step 616 can entail comparing the output result with predetermined threshold values, or comparing a current output result with a previous output result provided in a previous iteration of the loop shown in the what-if/do-what series of steps 604. Based on the determination made in step 616, the process 600 may decide that a satisfactory result has not been achieved by the digital cockpit 104. In this case, the process 600 returns to step 610, where a different permutation of input assumptions is selected, followed by a repetition of steps 612, 614, and 616. This thus-defined loop is repeated until step 616 determines that one or more satisfactory results have been generated by the process 600 (e.g., as reflected by the result satisfying various predetermined criteria). Described in more general terms, the loop defined by steps 610, 612, 614, and 616 seeks to determine the “best” permutation of input knob settings, where “best” is determined by a predetermined criterion (or criteria).
Different considerations can be used in sequencing through input considerations in step 610. Assume, for example, that a particular model 136 maps a predetermined number of actionable X variables into one or more Y variables. In this case, the process 600 can parametrically vary each one of these X variables while, in turn, keeping the others constant, and then examining the output result for each permutation. In another example, the digital cockpit 104 can provide more complex procedures for changing the groups of actionable X variables at the same time. Further, the digital cockpit 104 can employ a variety of automated tools for implementing the operations performed in step 610. In one implementation, the digital cockpit 104 an employ various types of rule-based engine techniques, statistical analysis techniques, expert system analysis techniques, neural network techniques, gradient search techniques, etc. to help make appropriate decisions regarding an appropriate manner for changing X variables (separately or at the same time). For instance, there may be empirical business knowledge in a particular business sector that has a bearing on what input assumptions should be tested. This empirical knowledge can be factored into the step 610 using the above-described rule-based logic or expert systems analysis, etc.
Eventually the digital cockpit 104 will arrive at one or more input case assumptions (e.g., combinations of actionable X variables) that satisfy the stated criteria. In this case, step 618 involves consolidating the output results generated by the digital cockpit 104. Such consolidation 618 can involve organizing the output results into groups, eliminating certain solutions, etc. Step 618 may also involve codifying the output results for storage to enable the output results to be retrieved at a later point in time. More specifically, as discussed in connection with
After consolidation, step 620 involves implementing the solutions computed by the digital cockpit 104. This can involve transmitting instructions to affect a staffing-related change (as indicated by path 622), transmitting instruction over a digital network (such as the Internet) to affect a change in one or more processes coupled to the digital network (as indicated by path 624), and/or transmitting instruction to affect a desired change in engines used in the business process (as indicated by path 626). In general, the do-what commands affect changes in “resources” used in the processes, including personnel resources, software-related resources, data-related resources, capital-related resources, equipment-related resources, and so on.
The case consolidation in step 618 and the do-what operations in step 620 can be manually performed by the cockpit user 138. That is, a cockpit user 138 can manually make changes to the business process through the cockpit interface 134 (e.g., through the control window 316 shown in
C. Do-What Functionality (with Reference to
The process of
Whatever strategy is used to generate instructions, module 704 generally represents the business processes that receive and act on the transmitted instructions. In one implementation, a digital network (such as the Internet, Intranet, LAN network, etc.) can be used to transport the instructions to the targeted business processes 704. The output of the business processes 704 defines a business system output 708, which can represent a Y variable used by the business to assess the success of the business, such as financial metrics (e.g., revenue, etc.), sales volume, risk, cycle time, inventory, etc.
However, as described in preceding sections, the changes made to the business may be insufficient to steer the business in a desired direction. In other words, there may be an appreciable error between a desired outcome and the actual observed outcome produced by a change. In this event, the cockpit user 138 may determine that further corrective changes are required. More specifically, the cockpit user 138 can assess the progress of the business via the digital cockpit 104, and can take further corrective action also via the digital cockpit 104 (e.g., via the control window 316 shown in
Summation module 712 is analogous to its electrical counterpart. That is, this summation module 712 adds the system's 700 feedback from module 710 to an initial baseline and feeds this result back into the control mechanism 702. The result fed back into the control mechanism 702 also includes exogenous inputs added via summation module 714. These exogenous inputs reflect external factors which impact the business system 700. Many of these external factors cannot be directly controlled via the digital cockpit 104 (that is, these factors correspond to X variables that are not actionable). Nevertheless, these external factors affect the course of the business, and thus might be able to be compensated for using the digital cockpit 104 (e.g., by changing X variables that are actionable). The inclusion of summation module 714 in
The output of summation module 712 is fed back into the control mechanism 702, which produces an updated system output 708. The cockpit user 138 (or an automated algorithm) then assesses the error between the system output 708 and the desired response, and then makes further corrections to the system 700 as deemed appropriate. The above-described procedure is repeated to affect control of the business in a manner analogous to a control system of a moving vehicle.
The processing depicted in
Beginning at the far left of
The lead generation step 802 feeds its recommendations into a customer relationship management (CRM) database system 804. That database system 804 serves as a central repository of customer related information for use by the sales staff in pursuing leads.
In step 806, the salespeople retrieve information from the CRM database 804 and “prospect” for leads based on this information. This can entail making telephone calls, targeted mailings, or in-person sales calls to potential customers on a list of candidates, or can entail some other marketing strategy.
In response to the sale force's prospecting activities, a subset of the candidates will typically express an interest in leasing an asset. If this is so, in step 808, appropriate individuals within the business will begin to develop deals with these candidates. This process 808 may constitute “structuring” these deals, which involves determining the basic features of the lease to be provided to the candidate in view of the candidate's characteristics (such as the customer's expectations, financial standing, etc.), as well as the objectives and constraints of the business providing the lease.
An evolving deal with a potential customer will eventually have to be underwritten. Underwriting involves assigning a risk to the lease, which generally reflects the leasing business's potential liability in forming a contractual agreement with the candidate. A customer that has a poor history of payment will prove to be a high credit risk. Further, different underwriting considerations may be appropriate for different classes of customers. For instance, the leasing business may have a lengthy history of dealing with a first class of customers, and may have had a positive experience with these customers. Alternatively, even though the leasing business does not have personal contact with a candidate, the candidate may have attributes that closely match other customers that the leasing business does have familiarity with. Accordingly, a first set of underwriting considerations may be appropriate to the above kinds of candidates. On the other hand, the leasing business may be relatively unfamiliar with another group of potential customers. Also, a new customer may pose particularly complex or novel considerations that the business may not have encountered in the past. This warrants the application of another set of underwriting considerations to this group of candidates. Alternatively, different industrial sectors may warrant the application of different underwriting considerations. Still alternatively, the amount of money potentially involved in the evolving deal may warrant the application of different underwriting considerations, and so on.
Step 810 generally represents logic that determines which type of underwriting considerations apply to a given potential customers' fact pattern. Depending on the determination in step 810, process 800 routes the evolving deal associated with a candidate to one of a group of underwriting engines.
Providing that the underwriting operations are successful (that is, providing that the candidate represents a viable lessee in terms of risk and return, and providing that a satisfactory risk-adjusted price can be ascribed to the candidate), the process 800 proceeds to step 818, where the financial product (in this case, the finalized lease) is delivered to the customer. In step 820, the delivered product is added to the business's accounting system, so that it can be effectively managed. In step 822, which reflects a later point in the life cycle of the lease, the process determines whether the lease should be renewed or terminated.
The output 824 of the above-described series of lease-generating steps is a dependent Y variable that may be associated with a revenue-related metric, profitability-related metric, or other metric. This is represented in
The digital cockpit 104 receives the dependent Y variable, for example, representative of profitability. Based on this information (as well as additional information), the cockpit user 138 determines whether the business is being “steered” in a desired direction. This can be determined by viewing an output presentation that displays the output result of various what-was, what-is, what-may, etc. analyses. The output of such analysis is generally represented in
For instance, decision engine 1 (832) provides logic that assists step 802 in culling a group of leads from a larger pool of potential candidates. In general, this operation entails comparing a potential lead with one or more favorable attributes to determine whether the lead represents a viable potential customer. A number of attributes have a bearing of the desirability of the candidate as a lessee, such as whether the leasing business has had favorable dealings with the candidate in the past, whether a third party entity has attributed a favorable rating to the candidate, whether the asset to be leased can be secured, etc. Also, the candidate's market sector affiliation may represent a significant factor in deciding whether to preliminary accept the candidate for further processing in the process 800. Accordingly, the do-what instructions propagated to the decision engine 1 (832) can make adjustments to any of the parameters or rules involved in making these kinds of lead determinations. This can involve making a change to a numerical parameter or coefficient stored in a database, such as by changing the weighting associated with different scoring factors, etc. Alternatively, the changes made to decision engine 1 (832) can constitute changing the basic strategy used by the decision engine 1 (832) in processing candidates (such as by activating an appropriate section of code in the decision engine 1 (832), rather than another section of code pertaining to a different strategy). In general, the changes made to decision engine 1 (832) define its characteristics as a filter of leads. In one application, the objective is to adjust the filter such that the majority of leads that enter the process make it entirely through the process (such that the process operates like a pipe, rather than a funnel). Further, the flow of operations shown in
Decision engine 2 (834) is used in the context of step 810 for routing evolving deals to different underwriting engines or processes based on the type of considerations posed by the candidate's application for a lease (e.g., whether the candidate poses run-of-the-mill considerations, or unique considerations). Transmitting do-what instructions to this engine 2 (834) can prompt the decision engine 2 (834) to change various parameters in its database, change its decision rules, or make some other change in its resources.
Finally, decision engine 3 (836) is used to assist an underwriter in performing the underwriting tasks. This engine 3 (836) may provide different engines for dealing with different underwriting approaches (e.g., for underwriting paths UW1, UW2, and UW3, respectively). Generally, software systems are known in the art for computing credit scores for a potential customer based on the characteristics associated with the customer. Such software systems may use specific mathematical equations, rule-based logic, neural network technology, artificial intelligence technology, etc., or a combination of these techniques. The do-what commands sent to engine 3 (836) can prompt similar modifications to decision engine 3 (840) as discussed above for decision engine 1 (832) and decision engine 2 (834). Namely, instructions transmitted by the digital cockpit 104 to engine 3 (836) can prompt engine 3 (836) to change stored operating parameters in its database, change its underwriting logic (by adopting one underwriting strategy rather than another), or any other modification.
The digital cockpit 104 can also control a number of other aspects of the processing shown in
Also, instead of revenue, the digital cockpit 104 can monitor and manage cycle time associated with various tasks in the process 800. For instance, the digital cockpit 104 can be used to determine the amount of time it takes to execute the operations describes in steps 802 to 818, or some other subset of processing steps. As discussed in connection with
D. Pre-Loading of Results (with Reference to
As can be appreciated from the foregoing two sections, the what-if analysis may involve sequencing through a great number of permutations of actionable X variables. This may involve a great number of calculations. Further, to develop a probability distribution, the digital cockpit 104 may require much additional iteration of calculations. In some cases, this large number of calculations may require a significant amount of the time to perform, such as several minutes, or perhaps even longer. This, in turn, can impose a delay when the cockpit user 138 inputs a command to perform a what-if calculation in the course of “steering” the business. As a general intent of the digital cockpit 104 is to provide timely information in steering the business, this delay is generally undesirable, as it may introduce a time lag in the control of the business. More generally, the time lag may be simply annoying to the cockpit user 138.
This section presents a strategy for reducing the delay associated with performing multiple or complex calculations with the digital cockpit 104. By way of overview, the technique includes assessing calculations that would be beneficial to perform off-line, that is, in advance of a cockpit user 138's request for such calculations. The technique then involves storing the results. Then, when the user requests a calculation that has already been calculated, the digital cockpit 104 simply retrieves the results that have already been calculated and presents those results to the user. This provides the results to the user substantially instantaneously, as opposed to imposing a delay of minute, or hours.
Referring momentarily back to
Advancing now to
First, the output of a transfer function can be displayed or at least conceptualized as presenting a response surface. The response surface graphically shows the relationship between variables in a transfer function. Consider
As shown in
The digital cockpit 104 takes the nature of the response surface 900 into account when deciding what calculations to perform. For instance, the digital cockpit 104 need not perform fine-grained analysis for the flat portion 902 of
One way to assess the changeability of the response surface 900 is to compute a partial derivative of the response surface 900 (or a second derivative, third derivative, etc.). A derivative of the response surface 900 will provide an indication of the extent to which the response surface changes.
More specifically, in one exemplary implementation, the preloading logic 230 shown in
Other criteria can be used to assess the nature and scope of the pre-calculations that should be performed. For instance, there may be a large amount of empirical business information that has a bearing on the pre-calculations that are to be made. For instance, empirical knowledge collected from a particular business sector may indicate that this business sector is commonly concerned with particular kinds of questions that warrant the generation of corresponding what-if analyses. Further, the empirical knowledge may provide guidance on the kinds of ranges of input variables that are typically used in exploring the behavior of the particular business sector. Still further, the empirical knowledge may provide insight regarding the dependencies in input variables. All of this information can be used to make reasonable projections regarding the kinds of what-if cases that the cockpit user 138 may want to run in the future. In one implementation, human business analysts can examine the empirical data to determine what output results to pre-calculate. In another implementation, an automated routine can be used to automatically determine what output results to pre-calculate. Such automated routines can use rule-based if-then logic, statistical analysis, artificial intelligence, neural network processing, etc.
In another implementation, a human analyst or automated analysis logic can perform pre-analysis on the response surface to identify the portions of the response surface that are particularly “desirable.” As discussed in connection with
Still additional techniques can be used to determine what output results to calculate in advance.
In addition to pre-calculating output results, or instead of pre-calculating output results, the digital cockpit 104 can determine whether a general model that describes a response surface can be simplified by breaking it into multiple transfer functions that can be used to describe the component parts of the response surface. For example, consider
Finally, as previously discussed, the database 234 can also store output results that reflect analyses previously requested by the cockpit user 138 or automatically generated by the digital cockpit 104. For instance, in the past, the cockpit user 138 may have identified one or more case scenarios pertinent to a business environment prevailing at that time. The digital cockpit 104 generated output results corresponding to these case scenarios and archived these output results in the database 234. The cockpit user 138 can retrieve these archived output results at a later time without incurring the delay that would be required to recalculate these results. For instance, the cockpit user 138 may want to retrieve the archived output results because a current business environment resembles the previous business environment for which the archived business results were generated, and the cockpit user 138 wishes to explore the pertinent analysis conducted for this similar business environment. Alternatively, the cockpit user 138 may wish to simply further refine the archived output results.
To begin with, step 1008 describes a process for collecting data from the business processes, and storing such data in a historical database 1010, such as the data warehouse 208 of
In step 1014, the cockpit user 138 makes a request for a specific analysis. This request may involve inputting a case assumption using an associated permutation of actionable X variables via the cockpit interface mechanisms 318, 320, 322 and 324. In step 1016, the digital cockpit 104 determines whether the requested results have already been calculated off-line (or during a previous analysis session). This determination can be based on a comparison of the conditions associated with the cockpit user's 138 request with the conditions associated with prior requests. In other words, generically speaking, conditions A, B, C, . . . N may be associated with the cockpit user's 138 current request. Such conditions may reflect input assumptions expressly defined by the cockpit user 138, as well as other factors pertinent to the prevailing business environment (such as information regarding the external factors impacting the business that are to be considered in formulating the results), as well as other factors. These conditions are used as a key to search the database 234 to determine whether those conditions served as a basis for computing output results in a prior analysis session. Additional considerations can also be used in retrieving pre-calculated results. For instance, in one example, the database 234 can store different versions of the output results. Accordingly, the digital cockpit 104 can use such version information as one parameter in retrieving the pre-calculated output results.
In another implementation, step 1016 can register a match between currently requested output results and previously stored output results even though there is not an exact correspondence between the currently requested output results and previously stored output results. In this case, step 1016 can make a determination of whether there is a permissible variance between requested and stored output results by determining whether the input conditions associated with an input request are “close to” the input conditions associated with the stored output results. That is, this determination can consist of deciding whether the variance between requested and stored input conditions associated with respective output results is below a predefined threshold. Such a threshold can be configured to vary in response to the nature of the response surface under consideration. A request that pertains to a slowly changing portion of the response surface might tolerate a larger deviation between requested and stored output results compared to a rapidly changing portion of the response surface.
If the results have not been pre-calculated, then the digital cockpit 104 proceeds by calculating the results in a typical manner (in step 1018). This may involve processing input variables through one or more transfer functions to generate one or more output variables. In performing this calculation, the digital cockpit 104 can pull from information stored in the historical database 1010.
However, if the digital cockpit 104 determines that the results have been pre-calculated, then the digital cockpit 104 retrieves and supplies those results to the cockpit user 138 (in step 1020). As explained, the pre-loading logic 230 of
If the cockpit user 138 determines that the calculated or pre-calculated results are satisfactory, then the cockpit user 138 initiates do-what commands (in step 1022). As previously described, such do-what commands may involve transmitting instructions to various workers (as reflected by path 1024), transmitting instructions to various entities coupled to the Internet (as reflected by path 1026), or transmitting instructions to one or more processing engines, e.g., to change the stored parameters or other features of these engines (as reflected by path 1028).
The what-if calculation environment shown in
A procedure similar to that described above can be used in the case where a response surface is described using plural different component transfer functions. In this situation, step 1016 entails determining whether a user's request corresponds to a separately derived transfer function, such as a transfer function corresponding to the flat portion 902 shown in
E. Visualization Functionality
The analogy made between the digital cockpit 104 of a business and the cockpit of a vehicle extends to the “visibility” provided by the digital cockpit 104 of the business. Consider, for instance,
Further, it will be appreciated from common experience that a vehicle, such as the automobile 1102, has inherent limitations regarding how quickly it can respond to hazards in its path. Like an automobile 1102, the business also can be viewed as having an inherently “sluggishness” to change. Thus, in the case of the physical system of the automobile 1102, we take this information into account in the manner in which we drive, as well as the route that we take. Similarly, the operator of a business can take the inherent sluggishness of the business into account when making choices regarding the operation of the business. For instance, the business leader will ensure that he or she has a sufficient forward-looking depth of view into the projected future of the business in order to safely react to hazards in its path. Forward-looking capability can be enhanced by tailoring the what-if capabilities of the digital cockpit 104 to allow a business leader to investigate different paths that the business might take. Alternatively, a business leader might want to modify the “sluggishness” of the business to better enable the business to navigate quickly and responsively around assessed hazards in its path. For example, if the business is being “operated” through a veritable fog of uncertainty, the prudent business leader will take steps to ensure that the business is operated in a safe manner in view of the constraints and dangers facing the business, such as by “slowing” the business down, providing for better visibility within the fog, installing enhanced breaking and steering functionality, and so on.
As appreciated by the present inventors, in order for the cockpit user 138 to be able to perform in the manner described above, it is valuable for the digital cockpit 104 to provide easily understood and intuitive visual information regarding the course of the business. It is further specifically desirable to present information regarding the uncertainty in the projected course of the business. To this end, this section provides various techniques for graphically conveying uncertainty in predicted cockpit results.
To begin with, consider
The Y variable shown on the Y-axis in
More specifically,
The confidence bands 1304 which sandwich the response surface 1302 defines a three dimensional “object” 1306 that defines uncertainty associated with the business's projected course. A graphical orientation mechanism 1308 is provided that allows the cockpit user 138 to rotate and scale the object 1306 in any manner desired. Such a control mechanism 1308 can take the form of a graphical arrow that the user can click on and drag. In response, the digital cockpit 104 is configured to drag the object 1306 shown in
The graphical orientation mechanisms also allows the user to slice the object 1306 to examine two dimensional slices of the object 1306, as indicated by the extraction of slice 1310 containing response surface 302.
Again, a knob panel 1312 is available to the cockpit user 138, which allows the cockpit user 128 to vary other actionable X variables that are not directly represented in
The confidence bands shown in
To begin with, instead of confidence bands,
It should be noted that objects 1408, 1410, and 1412 are denoted as relatively “sharp” response curves. In actuality, however, the objects may reflect a probabilistic output distribution. The sharp curves can represent an approximation of the probabilistic output distribution, such as the mean of this distribution. In the manner described above, the probability associated with the output results is conveyed by the size of the objects rather than a spatial distribution of points.
Arrow 1414 again indicates that the cockpit user is permitted to change the orientation of the response surface shown in
Arrow 1514 again indicates that the cockpit user is permitted to change the orientation of the response surface shown in
Further, control window 316 of
The distributions shown in
Arrow 1710 again indicates that the cockpit user is permitted to change the orientation of the response surface shown in
In each of
In another implementation, the presentations shown in
Any of the presentations shown in this section can also present a host of additional information that reflects the events that have transpired within the business. For instance, the cockpit user 138 may have made a series of changes in the business based on his or her business judgment, or based on analysis performed using the digital cockpit 104. The presentations shown in
Further, any of the above-described presentations can also provide information regarding the considerations that played a part in the cockpit user's 138 selection of particular do-what commands. For instance, at a particular juncture in time, the cockpit user 138 may have selected a particular do-what command in response to a consideration of prevailing conditions within the business environment, and/or in response to analysis performed using the digital cockpit 104 at that time. The presentations shown in
In general terms, the above-described functionality provides a tool which enables the cockpit user 138 to track the effectiveness of their control of the business, and which enables the cockpit user 138 to better understand the factors which have lead to successful and unsuccessful decisions. The above discussion referred to tracking changes made by a human cockpit user 138 and the relevant considerations that may have played a part in the decisions to make these changes; however, similar tracking functionality can be provided in the case where the digital cockpit 104 automatically makes changes to the business based on automatic control routines.
In each of
Knob panel 1808 is again presented to indicate that the user has full control over the variables assigned to the axes shown in
Arrow 1814 again indicates that the cockpit user is permitted to change the orientation of the response surface that is displayed in
Step 1904 entails receiving a cockpit user 138's selection regarding the vantage point from which the output results are to be displayed. Step 1904 can also entail receiving the user's instructions regarding what portions of the output result surface should be displayed (e.g., what slices of the output surface should be displayed.
Step 1906 involves generating the response surface according to the cockpit user 138's instructions specified in steps 1902 and 1904. And step 1908 involves actually displaying the generated response surface.
F. Conclusion
A digital cockpit 104 has been described that includes a number of beneficial features, including what-if functionality, do-what functionality, the pre-calculation of output results, and the visualization of uncertainty in output results.
Although the invention has been described in language specific to structural features and/or methodological acts, it is to be understood that the invention defined in the appended claims is not necessarily limited to the specific features or acts described. Rather, the specific features and acts are disclosed as exemplary forms of implementing the claimed invention.
This application is a continuation of U.S. patent application Ser. No. 10/418,609, entitled “CONTROLLING A BUSINESS USING A BUSINESS INFORMATION AND DECISIONING CONTROL SYSTEM,” filed Apr. 18, 2003, which is a continuation-in-part of U.S. patent application Ser. No. 10/339,166 filed on Jan. 9, 2003, entitled “Digital Cockpit.” The foregoing applications are herein incorporated by reference in their entirety.
| Number | Date | Country | |
|---|---|---|---|
| Parent | 10418609 | Apr 2003 | US |
| Child | 11753873 | May 2007 | US |
| Number | Date | Country | |
|---|---|---|---|
| Parent | 10339166 | Jan 2003 | US |
| Child | 10418609 | Apr 2003 | US |
