Computer-Implemented Tools and Method for Developing and Implementing Integrated Model of Strategic Goals
By building a computer model operating on a computerized device that integrates a strategy model and an operations model, it may be possible to better project the impact of implementing business strategies. And by computerized monitoring of the business's status, as indicated by its current financial data in comparison to the projections arising from the computer model, it may be possible to determine whether the business strategies are being successfully implemented. It would also be useful to have an automated system that would automatically notify personnel within a business if the business strategy is not being successfully implemented, allowing those personnel to intercede more quickly to correct problems. In addition to providing such a warning, it would also be useful to present the consequences, including the impact on financial data, people, processes, and technology, arising from the actual implementation of these strategies, along with a means of capturing the business correction measures used to correct such deviations. The present computerized framework, device, and method disclose embodiments for developing and using an integrated, closed-loop computerized business model, typically using a plurality of linked database tables.
This Application is related to and claims benefit under 35 USC §119 to U.S. Provisional Patent Application Ser. No, 61/296,560 entitled “Computer-Implemented Method of Developing and Implementing Integrated Model of Strategic Goals” filed Jan. 20, 2010, which is assigned to the Assignee of the present application and hereby incorporated by reference as if reproduced in its entirety to the degree that it is not inconsistent with the information specifically set forth herein.
STATEMENT REGARDING FEDERALLY SPONSORED RESEARCH OR DEVELOPMENTNot applicable.
REFERENCE TO A MICROFICHE APPENDIXNot applicable.
FIELD OF INVENTIONThe present invention is directed generally to computer modeling, and more specifically to computerized tools for developing and implementing integrated computer models of strategic and operational goals, as well as related methods for building and using computerized models.
BACKGROUNDTo achieve real-world benefits, it would be useful if businesses could construct effective computer models that link strategic goals to the operational elements that will implement those goals. Further, it would be useful if businesses could use the computer model to project the results of a particular strategy, and then to actually measure the ongoing strategy implementation to see if projections are being realized. And if the real-world measurements do not track the projections, it would be useful if an automated warning could be transmitted to assist in correcting issues that have resulted in the warning. Embodiments of the present invention(s) may attempt to address one or more of these issues by providing a computerized framework for developing and implementing an integrated model of strategic goals. In some embodiments, the computerized framework may also be used to guide the business in making specific physical modifications, such as automating processes or upgrading to more efficient technology in order to either implement the strategy or to correct any problems giving rise to deviations from the strategic projections.
SUMMARYIn one aspect, the disclosure includes a method for building a computer model (typically including a strategy model and a related operations model), using the model to project value, checking the current financial status in comparison to the projection, and optionally transmitting a notice or warning to designated contact personnel and/or outlining financial consequences and potential corrective actions. Typically, the computer model will include benefit calculations, and the projection of value is based on these benefit calculations in conjunction with historic run-rate data. In another aspect, the disclosure includes a computer system for building a computer model (typically including a strategy model and a related operations model), using the model to project value, monitoring current value status (using current data from a host database), and evaluating whether the current value status is off-track based on the projection.
In one aspect, the disclosure includes a computerized method of automated measuring and monitoring of business progress/status comprising one or more of the following steps of: storing one or more strategy elements into a strategy model on a database; storing one or more operations elements into an operations model on the database; associating related elements in the strategy model; and associating related elements in the operations model; storing one or more benefit calculations associated with each operations element on the database; synchronizing the strategy model and the operations model; storing one or more execution control indicators and/or business process dependencies and associations on a database; storing on a database one or more corrective actions to performance deviations and associations across a series of units comprising an organization; projecting (by a computer/processor) value of the operations model; determining (by the computer/processor) current value status; comparing (by the computer/processor) current value status to projected value; transmitting (by automated means using one or more communications systems, such as telephone or wireless internet, for example) a warning in the event that the comparison of current value status to projected value is outside a pre-set limit; and determining (by computer/processor) business and financial consequences of deviation to limits set across a series of units within the organization; wherein some or all of the above steps are carried out on the computer/processor. In some embodiments, associating related elements might comprise assigning a guid to each element in the strategy model and to each element in the operations model, wherein each guid is hierarchically associated and segmented. In some embodiments, projecting value of the operations model might further comprise importing run-rate data from a run-rate database for use with the benefit calculations; and determining current value status might comprise importing current data from a host database for use with the benefit calculations (or ECI derived from the benefit calculations).
In another aspect, the disclosure includes a method of developing and implementing a computerized business model comprising one or more of the following steps of: constructing (on a computer/processor) a computerized strategy model; constructing (on a computer/processor) a computerized operations model; associating/linking elements in the operations model to related elements in the strategy model; synchronizing the strategy model and the operations model based on the associations/links; refining the operations and/or strategy models using solution design and/or process measurement; projecting (by a computer/processor) value of the operations model; determining (by a computer/processor) current value status; comparing (by a computer/processor) current value status to projected value; and transmitting a warning to pre-set contact personnel in the event that the comparison of current value status to projected value is outside a pre-set limit; wherein one or more of the above steps are carried out on/by a computer. In some embodiments, constructing a computerized strategy model comprises one or more of the following: setting a business driver, and setting one or more strategies associated with the business driver; constructing a computerized operations model comprises one or more of the following: setting one or more VCE, setting one or more goals associated with each VCE, and setting one or more business calculations associated with each goal; projecting value of the operations model comprises importing run-rate data from a run-rate database for use with the benefit calculations; and determining current value status comprises importing current data from a host database for use with the benefit calculations (or ECI derived from the benefit calculations), in some embodiments, setting a business driver might comprise selecting the business driver from a pre-set menu of business drivers on a database; setting one or more strategies associated with the business driver might comprise selecting the one or more strategies from a pre-set menu of strategies on the database; setting a VCE might comprise selecting the VCE from a pre-set menu of VCE on the database; setting one or more goals associated with the VCE might comprise selecting the one or more goals from a pre-set menu of goals on the database; and setting one or more business calculations associated with each goal might comprise selecting the one or more business calculations from a preset menu of business calculations on the database. And in some embodiments, the one or more goals might be associated with the VCE by guid; the one or more business calculations might be associated with each goal by guid; and each guid might be hierarchically associated and segmented.
In yet another aspect, the disclosure may include one or more databases (or any (computerized) means for storing) comprising or operable/configured for: one or more pre-set menus of strategy elements/components and their associations/links (i.e. how they are related), one or more pre-set menus of operations elements/components and their associations/links (i.e. how they are related), the associations between related operations elements/components and strategy elements/components, the run-rate financial data, storing a computerized model (including the strategy model and the operations model), storing contact information for notifications/warnings, storing triggers for checking current status (and evaluating it in comparison to projection) and/or limits for warning levels, and the host current financial data; and a computer (means) operable/configured for generating a projection based on the computerized model and the run-rate data, and periodically retrieving current host financial data and comparing it to the projection. In some embodiments, the computerized model might comprise a plurality of strategy elements selected from the pre-set menu of strategy elements, a plurality of operations elements selected from the pre-set menu of operations elements, and one or more benefit calculations for each such operations element in the computerized model. In some embodiments, the computer might further comprise a notification transmission unit to send a warning to contact personnel in the event that the comparison of current financial data to the projection is outside the limits and/or a user interface.
In still another aspect, the disclosure may include a computer system comprising one or more of the following: a strategy module; an operations module; a computer model; an execution control module; a run-rate database; and a host database.
In some embodiments, the strategy module might comprise a database of one or more pre-set menus of strategy elements and their associations/links (i.e. how they are related); and/or the operations module might comprises a database of one or more pre-set menus of operations elements and benefit calculations and their associations/links (i.e. how they are related). In some embodiments, the computer model might comprise a database storing one or more selected operations elements and one or more benefit calculations associated with each selected operations elements; and/or the execution control module might comprise a contact information database and a trigger/limit database. In some embodiment, the system might further comprise a database of the associations between related operations elements and strategy elements. And in some embodiments, the computer model might project value using the run-rate data and the benefit calculations, the execution control module might determine current status using the host data and the benefit calculations (or ECI based on them), and/or the execution control module might compare the current status to the projection (to determine if outside the limit and a warning should be transmitted to contact personnel).
In another exemplary aspect, a computer device/system might comprise (one or more databases having) a plurality of associated database entries, each entry having a hierarchical segmented guid (linking related electronically stored data). In some embodiments, the hierarchical segmented guid for each entry might operate to allow for associations to be determined between a specific entry and other entries in the one or more databases. In some embodiments, the associations between all related entries in the one or more databases might defined by the guid. In some embodiments, the one or more databases might comprise a plurality of operations elements and one or more benefit calculations associated via guid with each such operations element. There are many different possible variants of this inventive concept, as discussed in more detail below.
For a more complete understanding of the present disclosure, and for further details and advantages thereof, reference shall be made to the accompanying drawings:
The present invention provides tools to assist in designing and implementing an overall strategy for an entity (such as a global corporation, a regional company, a division, a department, a team, or even an individual, for example). Within a computerized framework, a strategy model outlining corporate goals and an operations model detailing the implementation of those strategy goals may be constructed and linked. By refining an overall corporate model that integrates both strategic and operational elements, an improved computer model can be built, leading to better forecasting and improved accuracy in projecting the results of a particular business strategy. Furthermore, the computerized modeling framework allows for automated tracking of the real-world implementation of the selected business strategy, using a comparison of current data to the projection to see if the business strategy is proceeding on target or if refinement and adjustments must be made operationally to correct performance. And an integrated computerized framework also allows for automated notification if projections are not being met.
To assist in accomplishing such integrated modeling, several interconnected modules may be used within the computerized framework. Each module is typically designed to serve a specific individual purpose of its own (and could be used independently as a tool for that specific purpose), but when the modules are linked and used together they may provide additional synergistic benefits. A run-rate database containing historical reference data (typically financial data) or projected data of the entity at issue may serve as a benchmark for future measurements, and may interact with other modules in building, implementing, and assessing computer models relevant to business strategy. A strategy module may provide a tool that assists business decision-makers in building an effective strategy model designed to achieve the business goals of the entity and in assessing the potential value of the proposed strategy (to see if the strategy has the potential to provide the desired level of results, perhaps and allowing for iterative manipulations of the strategy model as necessary for the corporate goals to be achievable). An operations module may provide a tool that assists operational personnel in detailing the operational elements they intend to use to achieve the specific elements in the strategy model and tying those elements to a benefit calculation that estimates value with a greater degree of granularity using run-rate data. And an execution control module may provide a tool that assists the entity in tracking real-world performance (using current data, typically housed in the entity's (host) financial database) in comparison to the projections provided by one or more of the computer models (using historic reference run-rate data), to see if the entity's strategy is being successfully implemented (and perhaps notifying appropriate personnel if off-target).
A synchronization module may also be included, providing a tool that allows for comparison of the strategy model to the operations model in order to ensure that the operations side of the business is aligned with the overall corporate strategy. Synchronization may also allow for iterative interactions with the strategy and operations models for refinement. A solution design module may also be included, providing a tool that allows for further refinement of the costs associated with operational elements in the operations model, to provide for more accurate projections. Further, a process measurement module may also be included, providing a tool that checks value with a greater degree of granularity to ensure that the operational processes of the entity can actually be modified in a way that is capable of delivering the projected value benefit to the entity. A consequence management module may also be included, providing a tool that, in the event that execution control detects a deviation from projected performance, projects the consequences if such a deviation continues. Additionally, a correction management module may be included, providing a tool that allows for recordation of any steps and resources used to address any deviation, thereby building a record of possible solutions for specific problems which may serve as a toolbox whenever future problems arise. It should naturally be understood that in some embodiments one or more of the features described in one module may be incorporated into another module (such that the number of modules is relative, so long as the features and functions are being performed). When some or all of these modules are used together, they can be cross-linked and/or used in a synergistic way, and may also be used iteratively (and in no particular order) to refine corporate strategy in an attempt to accomplish the overarching corporate goals.
In practice, the modules could be used as part of a method for developing and tracking implementation of an overall corporate strategy model. In one embodiment of such a method, a database would be populated with reference run-rate data of the entity at issue (i.e. the entity that is using the computer model). Such reference data may include standard financial data collected by businesses to track aspects of the business, and typically would include data relating to the categories set forth in the IFRS and GAAP standards for financial reporting. By way of example, the run-rate database of one embodiment might have data categories that track those shown in
A strategy model may then be developed and assessed using a computerized strategy module. In an embodiment of the invention, the strategy would be built by having a user (typically the corporate deciders atop the entity, such as a CEO and/or CFO, by way of non-exclusive example) enter/set business goal(s) and then perform value assessment of the goal(s) by estimating the value that they expect to achieve by implementing the entered goal(s). The goal(s) and value assessment would be saved in a computer accessible medium (such as a database or some portion of a database, by way of non-exclusive example). While the goal(s) may be entirely user defined (allowing for complete customization), preferably the user would select one or more goal elements from a pre-defined menu/list, and the pre-defined list may have a hierarchical structure in which primary elements are sub-divided into secondary elements (that relate to the parent primary element), and so on (with as many levels provided as might be desired).
In the embodiment shown in
So in the embodiment shown in
A user may build up a strategy model within the computerized framework shown in
While not required, the embodiment of
So a user interacts with the strategy module within the computerized framework to build the strategy model up, and in the embodiment shown in
Once the strategy model has been built, its value can be assessed (in order to preliminarily evaluate the financial impact of proposed business strategy) within the strategy module. Value assessment may take place at the strategy level or at the tactic level (depending on whether the user wishes to employ a top-down or bottom-up approach). In the embodiment shown in
So for each element in the strategy model, the user may set the amount that they believe this strategy or tactic element will affect specific run-rate data categories (either in terms of percentages or actual currency). The run-rate data categories are typically related through known calculations (since they are standard financial metrics defined by GAAP or International Finance Reporting Standards). In other words, each category of run-rate data is related to one or more of the other categories of run-rate data in pre-defined ways, such that changes to one category would result in corresponding changes in one or more other categories. Thus, the strategy model can calculate a projection by refiguring the other run-rate data categories using the historic reference data as a benchmark and the estimated effect entered by the user (related to the specific element of the strategy model). This allows for a projection of the financial impact of each element of the strategy model, which may then be aggregated (rolled up) to determine the overall financial impact of the strategy model as a whole. The refigured run-rate data projection can also be condensed into the amount of benefit and cost associated with the element, and by subtracting cost from benefit, the overall value of the element can be assessed. These values (associated with each element in the model) can be rolled up to determine the total assessed value of the strategy model.
In the embodiment shown in
If a bottom-up approach is taken, the user would perform value assessment for each element at the tactic level, and these values could then be rolled up (either automatically or by choice of the user) to determine the overall value of the related strategy element. Similarly, the value of all strategies could then be automatically rolled up to determine the total value of the entire strategy model. On the other hand, if a top-down approach is taken, the user would perform value assessment at the strategy level first and then at the tactic level, and would then be able to compare the two and to iteratively interact with each in order to approximately equalize the value. Such an iterative approach may serve as a tool for users to refine their projections.
Once value assessment is completed and saved to the database as part of the strategy model, the user may have the option to distribute the value over time, and may also graphically display the distributed value. Such optional distribution of the projected value associated with the strategy model may be useful to inform business decisions, and may later be useful if synchronization (by providing another comparison between the strategic and operational models) and/or execution control (by providing a comparison to the projection curve) is performed.
So, using the strategy module, the user may build up the elements of a strategy model and assign an assessed (estimated) value to the strategy model. In the embodiment of
Once the strategy model has been created, the user may interact with the operations module to develop an operations model (that is typically guided by the strategy model). In an embodiment of the invention, the operations model would be built by having a user (typically one or more operations level managers, by way of non-exclusive example) enter/set operational element(s) (such as listing the various operations they feel are related to each strategic element) and then setting benefit calculations related to each operational element designed to provide an operational estimate of the value that they expect to achieve by implementing each operational element. The benefit calculation(s) are designed to provide a value projection with increased granularity, being based on the reference run-rate data. The operational element(s) and benefit calculations would be saved in a computer accessible medium (such as a database or some portion of a database, by way of non-exclusive example). While the operational element(s) may be entirely user defined (allowing for complete customization), preferably the user would select one or more operational elements from a pre-defined list/menu, and the pre-defined list may have a hierarchical structure (similar to that discussed above for the strategy model) in which primary elements are sub-divided into secondary elements, and so on (with as many levels provided as might be desired). And preferably, the operations users would have access to the strategy model (with the operations module displaying the strategy model saved in the model database), so that they may view it and use it to guide their thinking as they construct an operations model intended to implement the overall corporate strategy.
In the embodiment shown in
So in the embodiment shown in
A user may build up an operations model within the computerized framework shown in
Each goal and/or business initiative would typically have a benefit calculation associated with it, allowing for determination of the operational value of the element. A benefit calculation is defined to provide a practical measurement of the element at issue, establishing the expected derived benefit from the proposed change to the operational process. Benefit calculations are formulas that typically include variables tied to the run-rate data, and are typically based on business experience relating financial data and target change in a way that provides a measurement metric for the operations element. In some embodiments, the user may define (or amend) these benefit calculations themselves (constructing the calculation using a tool kit that provides for variables linked to the reference run-rate data). By way of example, see
Once the user has selected a benefit calculation in the embodiment of
So the users interact with the operations module within the computerized framework to build the operations model up, and in the embodiment shown in
In the embodiment of
It is also possible that an embodiment could use the pre-defined links between strategy model elements and operational elements so that when the user interacts with the operations module, the list of pre-defined operational elements available for selection by the user would be limited to those that are related to strategy elements that have already been selected and added into the strategy model (or alternatively, those related operational elements could merely be highlighted to provide guidance to the operations users, without restricting their choices). This type of approach (using the links between the strategy model elements and the operational elements) might allow for automatic synchronization during the building of the operations model, reducing the need for a separate synchronization step.
More than one operations model may be built if the entity has multiple operational elements (such as retail and manufacturing, by way of non-exclusive example). Each operations model could be built up as described above. All operations models would typically be tied to the selected strategy model (which might be termed a master strategy model), so that the organization as a whole is aligned to achieve the overall corporate strategy. And if the entity decided to switch to an alternate strategy model, the operations model(s) could be reassigned (such that elements in the operations model(s) could be linked to elements within the new strategy model). Alternatively, for example, the entity could create one or more new operations models linked to the new strategy model. The opportunity to switch between strategic models allows dynamic switching of strategic associations and value assessments between a new set of models.
So in practice, the entity might first construct a strategy model, and then use that strategy model as a guide to construct an operations model. The operations model projects the value of implementing the strategy and distributes it over time. Thus, the output of the operations model is a projection curve that plots the expected value of implementing the strategy over time. The entity may use this projection in its business planning. The execution control module may then be used to evaluate whether the actual implementation of the strategy is on track with the projection, effectively monitoring the real-world effect on the entity's business as the strategy is implemented. In this way, execution control completes a closed loop design by providing the capability for users to determine (via interaction with the host database(s) storing current updated financial data, for example) if the projections are (or are not) being realized (based on how effectively the real world current data tracks the operations model value projection curve).
Execution control typically translates the benefit calculations in the operations model into execution control indicators that enable monitoring of the current value compared to the benchmark provided by the operations model. In other words, an execution control indicator (ECI) is defined within the execution control module and linked for each benefit calculation. ECI will typically employ the same calculation constructed for the related/linked benefit calculation, but will replace the historical reference run-rate data used to attribute values to the variables of the benefit calculation with the corresponding actual currently measured data (which can be extracted from the entity's host database(s) or can be entered periodically into a database associated with the execution control module). The benchmark is the value projection curve from the operations model (in which the benefit/cost has been assessed in the operations model using historic reference run-rate data and distributed over time). Within the execution control module, the user may interact with this projection curve to set limits (regarding the acceptable variance from the projection before a warning notification is generated) and to set the frequency with which execution control indicators will be compared to the projection. If the ECI returns a value that is outside the limits (i.e. that is more than the set limit(s) from the projection curve), then a warning may be automatically generated and sent to appropriate personnel. In some embodiments, such ECI deviation might also be viewed on an enterprise management module (dashboard) operable to show a hierarchical structure of connected units within an n-tier organization, or a global map view showing the units and their global geographic location to one another, or in a consequence manager module.
It should be noted that at least some of the data used in ECI might in some embodiments be collected, retrieved, and/or transmitted by sensors. For example, programmable logic controller sensors could be used at various physical locations to measure data for ECI. The execution control module might also be set to measure and/or evaluate other non-value-based measurables. For example, event-based measurables such as KPI, run rate variables, or custom variables could be used, with warnings being generated if some key measurable is outside its limits. For instance, sensors could monitor operation and performance of machines (such as various machines in an automated assembly line, for example), or could even measure human activity (such as the number of customers entering a retail store, for example). The sensor data would then typically be transmitted or input into a database for use evaluating performance in comparison to projections.
To set up the execution control module for monitoring as shown in the embodiment of
Once the execution control module has been set up by the entity, it is designed to monitor events automatically and to transmit automated warning notices. So, if a particular ECI comes back (when current data is retrieved according to the set trigger and plugged into the ECI/benefit calculation) outside the set limits, the EC″ module may send an automated warning notice to the designated contact personnel using the contact information. The warning notification could be automatically transmitted via e-mail or could be transmitted as a text message to the user's cell phone, by way of non-exclusive example, providing instant notice. In addition to transmitting a notice, in the embodiment of
In an embodiment of the invention, the execution control module could also include predictive analysis. Predictive analysis would use trending information to extrapolate if and when the ECI is likely to move outside the limits, so that early warning could be sent before the ECI actually exceeds the limits. By way of example, linear or exponential extrapolation techniques could be applied to the last two or more ECI results to predict if the ECI is trending in a way that will lead to a problem. This option would provide another level of warning that could prove helpful in keeping the entity on track with its goals.
While each of the strategy, operations, and execution control modules could have independent applications, by integrating these three modules, an entity may be better able to establish a unified corporate strategy that can be effectively implemented throughout the organization. It also provides for a closed loop system in which the strategy may be defined, implemented, monitored, and refined (perhaps iteratively), especially with the addition of optional consequence and correction management modules, in a way that should improve the running of the entity's business operations.
In addition, there are other optional modules that could also be used to further refine the process (in an attempt to provide better value projections and/or to improve the computer models, by way of non-exclusive example). Although certainly not required, an entity could use any or all of these additional optional modules to try to improve the process further. A brief discussion of embodiments of such optional modules follows.
After constructing a strategy model and an operations model, the users may then attempt to synchronize the models to ensure that the strategy model and the operations model are roughly aligned towards the same goals. This may be accomplished using the embodiment of the synchronization module of
The first view compares the content of the strategy model to that of the operations model. So, when using the content view, the user may select an element of the strategy model for consideration in the strategy window (perhaps by clicking or dragging it into the strategy window, by way of non-exclusive example). When a strategy element is selected, all possible operations elements in the operations module that are related/linked to that strategy element in the strategy module may be displayed in the operations window, with the operations window also noting those related operations elements that have been included in the operations model and those that are not included in the operations model. In a specific embodiment, these links are retrieved from the association table/database.
In the embodiment shown in
This comparison can be performed for each element of the strategy model. This allows for the models to be iteratively adjusted to bring the overall strategy and operations models into better alignment (to help the entire organization to follow through on a unified corporate strategy). It should be noted that in the embodiment of
The user may also employ the second view to compare the measurements associated with the strategy and operations models for synchronization. The user may select a KPI from the strategy model for display in the strategy window. Doing so will display (in the display window) all of the benefit calculations in the operations module that are related/linked to that KM in the strategy module (as typically determined by the association database), while designating those that have been selected for the operations model and those that have not. Again, in the embodiment shown in
The user may also employ the value view to compare the projected/assessed value, benefit, and/or costs of elements in the strategy model to the estimates in their associated elements in the operations model. As discussed above, selection of an element of the strategy model for consideration in the strategy window of the synchronization module will automatically populate the strategy window with the value information associated with that strategy element and populate the operations window of the synchronization module with all of the elements (and their associated projected values) from the operations module that are linked to that element in the strategy module. And once again, the operations elements that have been included in the operations model would be designated in a way that distinguishes them from those that have not been selected. And it should be noted that the user might also alternatively begin the synchronization process by picking an operations element from the operations model. This will allow for quick comparison of the value, benefits, and/or costs of the selected strategy element with the related selected operations elements. The user would typically perform this procedure for each element in the strategy model (by selecting and analyzing each element of the strategy model in turn). Again, this comparison allows for discussion and iterative modification of the models.
The user may also employ the fourth view, which allows benefit, cost and value distribution previously set in the strategy value assessment associations to be viewed side by side so the potential mismatches in the distribution plans for specific strategy element and its directly associated operational element may be interrogated. This may also extend to a view which displays the distribution for the total value, benefit and cost of a strategy plan directly with the distribution for the total operations plan (see for example
The user may also employ the fifth view to compare strategy projections to operations projections. When this view is selected, the projected financial metrics and cash flow based on the run-rate data (i.e. the run-rate projections) of the entire strategy model would be shown in the strategy window while those of the entire operations model would be shown in the operations window. This view may provide insight that aids in collaborative efforts to iteratively modify the plans to bring them into better alignment.
By using one or more of the views of such a synchronization module, the users may be able to refine the strategy and operations models (by comparing the two for alignment and iteratively modifying either or both models to bring them into closer alignment) to ensure that the organization as a whole is directed towards a single unified plan (in which the operational plan supports and implements the strategic plan). It may provide the impetus and forum for a discussion between business decision makers and operational managers, who each bring a different perspective and set of skills and experiences that may be useful in refining the overall corporate plan (which includes both the strategy model and the operations model). And this synchronized operations model may be used in conjunction with the execution control module to provide for improved implementation of the strategy (with the updated and modified benefit calculations included in the finalized operations model being used to develop the ECI for the execution control module).
Another optional module that may be used to further refine the process could involve a solution design module. Once an operations model has been constructed, the users may then wish to employ a more refined analysis of the costs likely to be associated with the elements of the operations model, as a check to ensure that the operations model may realistically be executed in the real world. This may be accomplished using a solution design module, such as the embodiment shown in
In the embodiment of
Once all of the cost components for an operational element have been entered, the user may then employ various views of the financial data to better analyze the impact that these costs may have on the operations model. By way of example, in
Solution design would typically be performed for each element of the operations model, so that the estimated costs entered in the operations model may be checked against reality. Often, solution design would be performed at a later stage of the strategy process, when quotes have been obtained allowing for a more real-world assessment of costs. Then, the projected costs in the operations model could be replaced by true costs, allowing for reassessment of the operations model. Typically, there is a link between the solution design module and the operations module, allowing for quick reference back to compare the costs. If solution design demonstrates that the estimated costs originally entered in the operations model are significantly off-base, then the operations model may be amended (typically by using/interacting with the operations module) to better reflect the costs. This may result in an iterative process for refining the costs of the operations model in a way that should hopefully lead to a better estimate of costs and, thus, of the associated value of the operations model (since value may be assessed as benefit minus cost). Solution design may also be used to ensure that there is a positive return on investment for the operations model. It should be noted that it is also possible to use such a solution design process as the initial way to build the costs of the elements in the operations model (rather than as a check on the initial estimate), in which case the solution design module might be integrated into the operations module. It is also possible for solution design to be updated over time as the strategy is actually implemented, providing a more accurate return on investment value projection for ongoing use within the execution control module. In such an instance, the updated cost projections would allow for refinement of ECI based on real-world implementation, perhaps providing a better gauge of performance in comparison to projections.
Another optional module that may be used to further refine the process could involve a process measurement module. Once an operations model has been created, the user may conduct process measurement to ensure that operationally the entity's processes have the capacity to provide the desired value. In other words, the process measurement module may be used to assess whether the business's processes are capable of being redesigned in a way that may provide the sought after value. Process measurement provides a greater degree of granularity in assessing the potential value that can be obtained by redesigning one or more operational processes within the entity, thus serving as a check on the ability to obtain value from the operations model in the real world (letting the user evaluate whether there is enough value in the proposed process changes that would result from implementation of the operations model to justify the changes). Operations users may use this tool to further refine the costs associated with the operational elements. Additionally, users could then modify the business's physical processes as detailed in process measurement in order to implement the business strategy. In doing so, changes could be made to the business's physical infrastructure and technology to bring then in line with the to-be process developed in process measurement. For example, new automation could be employed, upgraded machinery could be substituted, and/or production lines could be physically reconfigured to improve efficiency.
In process measurement, the user may enter/set the processes associated with supporting each operational element, comparing the current process to the process that will result from implementation of the operations model. In the embodiment shown in
The process measurement module may also provide two views that users may employ to analyze the comparison between the two processes. In the value view, each step may be defined as one of the following categories: (1) non-value added essential, (2) non-value added non-essential, or (3) value added. The user may view the number of steps falling into each category, and a sum of the costs associated with those steps. The user may also calculate a value add index for each category by calculating the percentage amount of the total process that each category represents (based on the number of steps classified in the category divided by the total number of steps in the process and multiplied by 100). By grouping the steps in these categories (and summing the number of each step in each category), the user may quickly identify additional ways in which the process may be improved (by attempting to minimize the number of non-value added steps, by way of non-exclusive example) and may quickly assess the effectiveness of the process (by looking at the value add index, by way of non-exclusive example). This may assist the user in performing a value comparison of the processes (based on the reduction of costs).
In order to evaluate the productivity of the processes, a velocity view may also be used. For a velocity view, each step in the processes may be designated as one of the following categories: work related, movement related, or delay related. The user may view the number of steps falling under each category, along with a sum of the associated costs. The user may also calculate a velocity index for each category by calculating the percentage amount of the total process that each category represents (based on the number of steps classified in the category divided by the total number of steps in the process and multiplied by 100), By grouping the steps in these categories and summing the number of each step in each category), the user may quickly identify additional ways in which the velocity of the process may be improved (by attempting to make delay steps transition to movement steps, and movement steps transition to work steps, by way of non-exclusive example) and may quickly assess the productivity of the process (by looking at the velocity add index, by way of non-exclusive example). This assists the user in performing a velocity comparison of the processes. Time is money in the business world, and the velocity index calculates the effect that unnecessary movements and/or delays can have on the process. The value add index and the velocity index may also be combined (typically by being multiplied together) to give an overall productivity index.
During the reengineering process (of defining the to-be process), the user may attempt to change the steps to move them into higher value added categories and/or to reduce movement and delays in a way that may improve efficiency. So, the process measurement module may be used to check to see if redesign of the operational processes of the business (from the as-is process to the to-be process) is capable of delivering the estimated value (from the operations model, for example) and/or is capable of being made more efficient and productive. This tool allows for iterative consideration of the steps in the to-be process, thereby assisting in reengineering the processes to deliver value (based on lean engineering principles).
In a further embodiment, activities within the processes contained in the operations model may themselves be measured and controlled using a derivation of benefit calculation specific to the activity step chosen. This would allow such a step to be considered as a constraint in the overall process and to be given a target value for measurement and control (within execution control, for example). The values could then be monitored and warnings could be generated in the execution control module in a manner similar to standard operation benefit calculations. In other words, specific to-be process steps can be measured and monitored, allowing for determination of whether such a process is off-target, and perhaps offering an earlier way to detect potential problems (before they might show up in standard ECI). Such process-based measurement also might provide the benefit of making it easier to determine the source of a problem (thereby making corrections easier to identify), while potentially also allowing process steps to be linked across units in an entity so that all potential consequences of a problem could be evaluated across the entity.
In an embodiment, solution design and/or process measurement would be performed to refine the operations model prior to synchronization of the operations model with the strategy model. This approach allows for the operations model to be fully fleshed out and finalized before synchronization compares it to the strategy model. Then, after synchronization is used (perhaps iteratively with modification of the strategy and/or operations models as needed to align the strategy and operations models), the overall corporate computer model can be finalized for execution control.
Another optional module which may be used to complete the closed loop measurement cycle is a consequence manager module. Once the various associations between strategic, operational, and financial elements have been set in the database(s) and the processes, people, and technology associations set, the user can access these associations and projections to performance once an ECI is measured. The consequence manager module typically works with the execution control module in order to provide decision makers within information about the potential consequences of a continued deviation from the operations model value projection curve, for example. The consequence manager module of the embodiment of
Another optional module that may assist in closing the planning and control loop is a correction manager module, as shown in the embodiment of
It should be understood that each of the modules described herein can be used independently or in any combination, depending on the user's purpose and desired goal. It should also be understood, however, that integrating the use of two or more of these modules provides a linked process providing synergies that enhance the effectiveness of the strategy building and implementation process. The preferred embodiment uses all of these modules to develop integrated and refined strategy and operations models (that jointly form a corporate model) that share a single direction, support each others goals, and are capable of realizing the desired value in the real world. The preferred embodiment may also link the processes in such a way that implementation of the unified corporate model can be measured and tracked to ensure that things are progressing according to plan (or alternatively that things are off-target and correction is needed).
It should also be understood that each strategy model may have multiple operations models (such as a different model for each different type of operation, or a different model for each division, by way of non-exclusive example) that together would implement the strategy model's goals. Furthermore, the process described above may be implemented for each tier of an n-tier company (i.e. a company having subsidiaries, divisions and the like, each of which may be broken into further constituent part), with the financial data rolling up to tie into an overall strategy-operations model for the n-tier company as a whole. This may provide a tool that is useful in developing a coordinated overall strategy within such a multi-tiered organization. So, the run-rate data would roll up (with lower child tier data summing to provide the parent tier data), and the projections based on run-rate data (such as the projected value/benefit calculations, by way of non-exclusive example) could also roll up (to provide an estimate of the overall value of the strategy from implementation of the operations model(s) throughout the n-tier corporate structure). Thus, the modeling process described above is quite flexible.
In the example, the n-tier organization is a global corporation with different regional companies or divisions around the world. Once division in India manufactures a part used by another division in Taiwan to build a consumer product which is sold to consumers by yet another division in the United States. Each division might have a computerized strategy operation model, which might include details about the processes used to implement the strategy. Each division could then measure the processes, tracking them to ensure that production is on-track (according to the computer model projections). Since the division in India supplies a necessary component part for the unit in Taiwan, and the unit in Taiwan then supplies a product for sale to the division in the U.S., both the U.S. and Taiwan divisions have some dependency on the division in India. Thus, an association/link could be created in the computer database tying the process in India to processes in the U.S. and Taiwan (such that a warning in India would also generate a warning in the linked divisions). That way, if there is sufficient deviation of ECI from the projection in the Indian division to activate a warning, a warning could also be activated in Taiwan and the U.S. (altering them of a possible delay in the supply chain, for example, thereby providing forewarning). This example should clarify one of the ways in which the above-described modeling processes could be used to improve an n-tier organization.
Turning now to the computerized framework which may be used to implement these processes,
The computer system of
This computerized framework allows a user to construct a corporate computer model (including a strategy model and an operations model), to optionally link elements within the strategy model and/or the operations model as well as between the strategy model and the operations model, and/or to set the triggers, limits, and contact information for execution control (to provide for automated monitoring of corporate performance and notification of contact personnel in the event that the corporate performance deviates too much from the projections arising from the computer model). Once set up by the user, the computerized framework is automated and is operable to import current financial data from the host database (typically periodically based on the pre-set triggers) to evaluate corporate performance in comparison to the projections generated from the corporate model (specifically the benefit calculations and/or projection curve using the historical run-rate data from the run-rate database) and to communicate with the appropriate contact personnel in the event that the corporate performance is off-track from the projections (i.e. is outside the pre-set limits). In this way, the computerized framework can assist in constructing the computerized corporate model and can provide for automatic monitoring and notification.
In another embodiment, the strategy module may not include a pre-defined strategy elements database, but may instead provide tools to allow users to construct their own strategy elements and associated KPI. Then the user could assess value and store the related elements/KPI and assessed values in the database to form the strategy model. In such instance (when the user defines the elements rather than selecting them from a pre-set menu), the user would also need to define the links between various elements, KPI, and assessed values (and later the links between the strategy elements and their related elements from the operations model).
Similarly, the operations module of
In one embodiment, these links/associations within the strategy or operations modules are accomplished using global unique identifiers (guid). More specifically, each piece of saved data in the computer system may be assigned a global unique identifier (saved in the database with it to serve as an address locator for that piece of data), and the global unique identifiers may be constructed in a segmented/hierarchical way that innately includes linkages to related pieces of data. So merely by way of a simplified example, if a business driver element in the strategy element database were to have a guid of 1, then one of its related strategy elements might have a guid of 1.1, one of its related tactic elements might have a guid of 1.1.1, one of its related KPI might have a guid of 1.1.1.1, and one of its related assessed values might have a guid of 1.1.1.1.1. Similarly, the links between various operations elements, benefit calculations, and/or projected values could be defined by hierarchically associated segmented guid. Thus, the guid associated with each piece of saved data (such as a strategy component (like strategy element, KPI, assessed value), or an operations components (like an operations element, benefit calculation, and/or projected value, etc.)) is comprised of hierarchically associated segments of data that indicate links and associations with other saved pieces of data in the system.
In other words, the guid incorporates the hierarchical design discussed in the above method process description, defining the linkages. The link is determined based on what type of data each particular segment of the guid represents within the hierarchy (such that by looking at the first segment of the guid, a specific category/type of association/link is being examined), and its value (which defines the specific data (perhaps by location address in a database) of that type to which the element represented by the guid is linked). So by way of example, in the guid for a specific selected KPI, the first segment might represent the specific related business driver element that was selected, the second element might represent the specific related strategy element that was selected, the third segment might represent the specific related tactic element selected, the fourth segment might represent this specific KPI, and the remaining segments would likely be empty (representing segments for additional related links further down the hierarchy). Thus, by knowing the guid for the KPI (which locates the KPI data in the database), it is easily discernable which other hierarchical elements it is related to. An automated computer query could easily look to the segments and values of the guid to identify links.
Guid could be used to effectively link/associate any hierarchical elements. So by way of example, guid could also link ECI, triggers/limits, contact personnel, solution design cost list, process measurement as-is and to-be process step charts, etc. to their related operations elements (such that these could all be operations components). And guid could be used to link descriptions, questions, notes, and attachments to their related strategy or operations elements. The size of each segment of the guid will typically depend on the number of each type of unit (such as elements, benefit calculations, KPI, assessed value, projected value, ECI, etc.) the system, and the number of segments will depend on the number of related pieces of data in the system.
While it might also be possible to use guids to relate operations elements to strategy elements, in the embodiment of
In another embodiment, the operations module may not include a pre-defined operations elements database, but may instead provide a tool that allows users to construct their own operations elements and associated business calculations. Then the user could project value and store the related elements/benefit calculations and projected values in the database to form the operations model. Similarly, in the strategy module, the user could be allowed to construct their own strategy elements and KPI (and store them in the database). In such instance (when the user defines the elements rather than selecting them from a pre-set menu), the user would also need to define the links between various elements, business calculations/KPI, and projected/assessed values (and the links between the strategy elements and their related operations elements).
Optionally, the computer system would also include a master control database, housing all of the elements of the strategy module and the operations module. The user would then be able to copy the complete master control database into one or more separate strategy and operations elements database(s), from which the user could then select specific elements for inclusion in the corporate computer model. While not required, this approach may help to prevent corruption of the data (as well as providing a secure source for correction if any data corruption does occur), as well as allowing for updating a master control database that several entities could jointly use without negatively impacting each entity's already created computer model.
Once the computer model has been built (including a strategy model and a related operations model), the user may optionally interact via the user interface with one or more of the solution design module, the process measurement module, and/or the synchronization module in order to refine the computer model. These are optional modules included in the embodiment of
The process measurement module of
The synchronization module of
The synchronization module may also provide tools for additional views to assist in comparing the operations and strategy models. By way of example, the measurement view tool could be used to compare the benefit calculations associated with the selected KPI (using guid and the associations database). Or the value view tool may display the projected value of the operations element in comparison to the assessed value of the strategy element (using guid and the association database). Or the distribution view tool may display the operational elements' effects on the run-rate data in comparison to the run-rate data effects of the strategy elements (using guid and the association database). Or the projections view tool may compare the overall projections of benefit and cost of the operations elements with the same of the strategy elements (using guid and the association database).
Once the computer model of
In another embodiment, the user can also optionally provide for greater granularity in tracking performance by setting a value calculation for process steps identified as constraints to completion of the process during process measurement, and then creating an ECI (or more specifically a process execution control indicator based on these calculations) within the execution control module to check and notify whenever that specific process is off-target (typically by comparing the projection based on historic run-rate data to the value returned using current host data). This would be quite similar to that discussed above, but the process measurement module would also need to store the process step value calculation (and its guid) in its database.
In some embodiments, the execution control module would also include consequence management and/or correction management features, allowing for more detailed warnings that might include the possible (projected) consequences if the deviation continues un-corrected, along with possible corrective measures that may be taken (based on recordation of past corrective measures). And in other embodiments, a separate consequence management module might perform consequence management features and a separate correction management module might perform correction management features. Again, guid could be used to link related elements.
For an n-tier organization, and enterprise manager module could also optionally be used to link the strategy/operations modules of units throughout the organization in a hierarchical manner.
It should be understood that the use of the word “database” is meant to be inclusive of any computer/electronic storage media (memory storage) capable of holding data and allowing the data to be extracted electronically. Thus, a database could be stored on a server, a hard-drive, or internal memory, or it could be located on a CD, disk, electronic tape, etc. by way of non-exclusive example. Likewise, the word “database” is intended to include one or more separate, independent database(s) (designated for a specific type of information) and/or a portion of a larger database (that may be partitioned into several smaller database tables). Thus, the term “database” as used herein is inclusive of a table in a database (which may include several such tables). In the preferred embodiment, most or all of the databases (such as the strategy element, operation element, model, association, trigger/limit, etc. databases, by way of non-exclusive example) described above would actually be tables within a single larger database, and this eventuality is intended to be included within any use of the term database (such that the strategy element database, by way of example could be an independent database or could be a portion of or table within a larger database, which could also hold the operations element database/table, by way of non-exclusive example). Thus, in various embodiments, there may be one or more databases for storing the model, the pre-set elements and links within the strategy and operations modules, the run-rate data, the contact personnel data, the host current financial data, the triggers/limits/alerts, the ECI results, etc.
So, in the embodiment of
The operations model may be refined using solution control and/or process measurement. This might entail creating and storing in the database a cost list associated with each element in the operations model, and the association might be in the form of a guid. Also, process steps associated with each element of the operations model (possibly related as-is and to-be processes) may be entered and stored in the database, with the association typically in the form of a guid. The operations model may be amended iteratively in accordance with solution control and/or process measurement.
The operations model may be synchronized with the strategy model, using the association database/table. This may include displaying all the operations elements (from the operations module) that are associated with the selected strategy elements within the strategy model, along with some indication of which of these operations elements have been selected for the operations model. Then, current financial data may be imported from the host database, and the ECI (based on the benefit calculations) may be calculated by the execution control module of the computer device to evaluate the current status of the entity. The current status may be compared by the computer device to the projection based on the benefit calculations (typically in the form of projection curve). If the current status is outside of the designated limits, the contact personnel would be notified, via the notification transmission unit of the computer.
The computer system may operate on the entity's own system (perhaps with software structuring the modules within their own computer and instructing their own computer to perform the specific process tasks), or it could operate on a hosted system, in which the computer model would be hosted on an outside server, with the entity accessing the computer system via the Internet, for example. Further, the computer system could be a designated specific purpose machine designed to include the physical components/modules and to perform the process tasks, or it could be a general purpose computer machine programmed to be configured with the modules and to perform the process tasks. In such case, the program may be stored on computer readable media, which is then operable to transform the general purpose computer machine into a specific purpose machine that performs as discussed above.
While various embodiments in accordance with the principles disclosed herein have been shown and described above, modifications thereof may be made by one skilled in the art without departing from the spirit and the teachings of the disclosure. The embodiments described herein are representative only and are not intended to be limiting. Many variations, combinations, and modifications are possible and are within the scope of the disclosure. Alternative embodiments that result from combining, integrating, and/or omitting features of the embodiment(s) are also within the scope of the disclosure. Accordingly, the scope of protection is not limited by the description set out above, but is defined by the claims which follow, that scope including all equivalents of the subject matter of the claims. Each and every claim is incorporated as further disclosure into the specification and the claims are embodiment(s) of the present invention(s). Furthermore, any advantages and features described above may relate to specific embodiments, but shall not limit the application of such issued claims to processes and structures accomplishing any or all of the above advantages or having any or all of the above features.
Additionally, the section headings used herein are provided for consistency with the suggestions under 37 C.F.R. 1.77 or to otherwise provide organizational cues. These headings shall not limit or characterize the invention(s) set out in any claims that may issue from this disclosure. Specifically and by way of example, although the headings refer to a “Field of invention,” the claims should not be limited by the language chosen under this heading to describe the so-called field. Further, a description of a technology in the “Background” is not to be construed as an admission that certain technology is prior art to any invention(s) in this disclosure. Neither is the “Summary” to be considered as a limiting characterization of the invention(s) set forth in issued claims. Furthermore, any reference in this disclosure to “invention” in the singular should not be used to argue that there is only a single point of novelty in this disclosure. Multiple inventions may be set forth according to the limitations of the multiple claims issuing from this disclosure, and such claims accordingly define the invention(s), and their equivalents, that are protected thereby. In all instances, the scope of the claims shall be considered on their own merits in light of this disclosure, but should not be constrained by the headings set forth herein.
Use of broader terms such as comprises, includes, and having should be understood to provide support for narrower terms such as consisting of, consisting essentially of and comprised substantially of Use of the term “optionally” and the like (such as may be used, can be included, or might, by way of non-exclusive example) with respect to any element of an embodiment means that the element or feature is not required, or alternatively, the element is included/required, both alternatives being within the scope of the embodiment(s).
Claims
1. A method comprising the steps of:
- constructing on a computer a computerized strategy model;
- constructing on the computer a computerized operations model;
- projecting by the computer value of the operations model;
- determining by the computer current value status; and
- comparing by the computer current value status to projected value.
2. The method of claim 1 wherein:
- constructing a computerized strategy model comprises: setting a business driver element; and setting one or more strategy elements associated with the business driver;
- constructing a computerized operations model comprises: setting a VCE element; setting one or more goal elements associated with the VCE; and setting one or more business calculations associated with each goal;
- projecting value of the operations model comprises importing run-rate data from a run-rate database for use with the benefit calculations; and
- determining current value status comprises importing current data from a host database for use with the benefit calculations or ECI derived from the benefit calculations.
3. The method of claim 2 further comprising:
- identifying consequences for deviation of current value from projected value based on associations;
- recording corrective actions taken to address deviation; and
- providing suggested corrective actions based on recording of prior corrective actions.
4. The method of claim 2 wherein:
- setting a business driver comprises selecting the business driver from a pre-set menu of business drivers on a database;
- setting one or more strategies associated with the business driver comprises selecting the one or more strategies from a pre-set menu of strategies on the database;
- setting a VCE comprises selecting the VCE from a pre-set menu of VCE on the database;
- setting one or more goals associated with the VCE comprises selecting the one or more goals from a pre-set menu of goals on the database; and
- setting one or more business calculations associated with each goal comprises selecting the one or more business calculations from a pre-set menu of business calculations on the database.
5. The method of claim 4 wherein:
- the one or more goals are associated with the VCE by guid;
- the one or more business calculations are associated with each goal by guid; and
- each guid is hierarchically associated and segmented.
6. The method of claim 2 further comprising refining the operations and/or strategy models using solution design and/or process measurement.
7. The method of claim 2 further comprising transmitting a warning to pre-set contact personnel in the event that the comparison of current value status to projected value is outside a pre-set limit.
8. A computer device comprising:
- a strategy module;
- an operations module;
- a computer model;
- an execution control module;
- a run-rate database; and
- a host database.
9. The device of claim 8 wherein:
- the strategy module comprises a database of one or more pre-set menus of strategy elements and their associations; and
- the operations module comprises a database of one or more pre-set menus of operations elements and benefit calculations and their associations.
10. The device of claim 9 further comprising a database of the associations between related operations elements and strategy elements.
11. The device of claim 9 wherein the computer model comprises a database storing one or more selected operations elements and one or more benefit calculations associated with each selected operations element.
12. The device of claim 11 wherein the execution control module comprises a contact personnel information database and a trigger/limit database.
13. The device of claim 12 wherein the computer model projects value using the run-rate data and the benefit calculations, and wherein the execution control module determines current status using the host data and the benefit calculations or ECI based on them.
14. The device of claim 13 wherein the execution control module compares the current status to the projection to determine if the current status is outside the limit for the projection, and if so, transmits a warning according to the contact personnel information database.
15. The device of claim 14 further comprising:
- a consequence manager module configured to project consequences in the event of a warning based on associations; and
- a correction manager module configured to suggest corrective measures in response to a warning based on past corrective measures.
16. A computerized method comprising the steps of:
- storing one or more strategy elements into a strategy model on one or more databases;
- storing one or more operations elements into an operations model on the one or more databases;
- projecting by a computer value of the operations model;
- determining by the computer current value status; and
- comparing by the computer current value status to projected value.
17. The method of claim 16 further comprising associating related elements in the strategy model; and associating related elements in the operations model.
18. The method of claim 17 wherein associating related elements comprises assigning a guid to each element in the strategy model and to each element in the operations model.
19. The method of claim 18, wherein each guid is hierarchically associated and segmented.
20. The method of claim 16 further comprising storing one or more benefit calculations associated with each operations element on the database; wherein:
- projecting value of the operations model further comprises importing run-rate data from a run-rate database for use with the benefit calculations; and
- determining current value status comprises importing current data from a host database for use with the benefit calculations or ECI derived from the benefit calculations.
Type: Application
Filed: Jan 20, 2011
Publication Date: Jul 21, 2011
Applicant: COGNITI, INC. (Plano, TX)
Inventor: George Gordon Knowles (Dallas, TX)
Application Number: 13/010,534
International Classification: G06Q 10/00 (20060101);