Patent Application
20050222893
1. Technical Field
The present invention relates generally to the field of computer software and, more specifically, to.
2. Description of Related Art
Globally, industry is experiencing significant pressure to operate at increasingly higher speeds. Financial markets have a lower tolerance for mistakes or missed opportunities, penalizing companies with large losses in market capitalization and increased costs of capital. Organizations, facing powerful forces such as global competition, the Internet, and customer demand for continuous product and service availability, are required to effectively manage global operations on a round-the-clock basis. This market landscape is characterized by unprecedented volatility and a decreasing organizational life expectancy. The average lifetime of a company in the S&P 500 has fallen from approximately 65 years in the 1930s to approximately 20 years in the 1990s, with the trend projected to continue downward.
Thus, Companies, long focused on functional optimization, now understand that they must optimize enterprise outcomes. This external focus may come at the expense of de-tuning highly optimized internal business silos, but the increased enterprise results will more than make up for any inefficiencies created.
The focus on employees is changing as well. Attempts to accelerate current employee processes by providing more and faster information are leading to information overload and employee burnout. New approaches to how employees work and how they work together are needed to drive the next level of employee productivity. Workforce management and providing an organizational environment for integration is now a required core competency.
The focus on “value-chains” expands to embrace “value-nets” and optimizing the company's processes with immediate suppliers is giving way to a longer view of creating visibility for all members of the network.
The largest change is the focus on change itself. Change moves from something that occurs at irregular intervals to something that occurs continuously. Change becomes integrated into the very fabric of the organization and the ability to capitalize on that change becomes the most critical capability demonstrated by those that thrive in the Innovation Economy.
Customer expectations are also changing. Customers are demanding that businesses change to accommodate their needs, not that they change to accommodate the company's way of working. This shift to customer-centric products and services is quickly becoming a mandate, not an option.
Those companies who are agile will always be offering their customers the best possible products and services. Customers are now able to seed and feed the best solutions where switching costs are minimized. New business models are required every three years whereas this used to be a 10 year cycle. Product life cycles have shortened to six months or less.
Customers are expecting proactive interaction—“bring me the best option/price/capability rather than making me go looking for it” is the requirement of the day. Customers are expecting “local service levels” from global service providers. “You know what I want, you guide my decisions, and you take care of me as an individual customer, not just as one embedded in millions.”
To cope with these forces, organizations must become more agile. The reality, however, is that many are built on rigid Information Technology (IT) systems originally designed to optimize functional silos, resulting in inefficient, fragmented business processes and significant delay in accessing critical information. Thus, there is a need for enterprise systems that are more flexible and adaptable, enabling organizations to access the right information at the right time to drive the right decisions. Therefore, there it would be desirable to have a method, system, and computer program product for quantitatively assessing organizational adaptability.
The present invention provides a method, system, and computer program product for improving an organization's business adaptability. In one embodiment, a taxonomy is created wherein the taxonomy comprises a hierarchical list of taxonomy indicators that captures organizational elements that can be used to measure an organization's responsiveness to change and wherein the taxonomy indicators are industry specific. A set of weights associated with the elements of the taxonomy, indicating a relevant contribution of each element to an overall adaptability of an organization, are assigned. The weights are industry specific. An enterprise profile for the organization is determined and an adaptability result of the organization is calculated from the weights, taxonomy, and enterprise profile. The adaptability result provides a quantitative assessment of the organization's adaptability. Recommendations for improving the adaptability of the organization are then determined using a rules engine and/or heuristics and utilizing the adaptability result, the taxonomy, the enterprise profile, and data gathered in creating the taxonomy, the enterprise profile, and the set of weights.
The novel features believed characteristic of the invention are set forth in the appended claims. The invention itself, however, as well as a preferred mode of use, further objectives and advantages thereof, will best be understood by reference to the following detailed description of an illustrative embodiment when read in conjunction with the accompanying drawings, wherein:
With reference now to the figures, and in particular with reference to
An operating system runs on processor 102 and is used to coordinate and provide control of various components within data processing system 100 in
An Agility Enterprise Index (AEI) tool also runs on data processing system 100. The AEI may be stored, for example, on hard disk drive 124 and loaded into main memory 104 as a set of computer readable instructions for execution by processor 102. AEI is a tool and method for measuring the agility of an enterprise. This tool utilizes a taxonomy of organizational factors, along with a set of customizable weights and scores to quantify the agility of an organization as well as provide insights into actions that would elevate agility. AEI can be applied either to an entire enterprise, or a specific division. When using AEI, care must be taken to distinguish between correlation and causality relationships among the agility factors and the agility of the target business unit.
AEI consists of an Agility Taxonomy, several indices, and a tool for the computation of the indices. The basis for the taxonomy and the indices are considered to be temporally dynamic, requiring frequent updates and validation. When validated, the indices can be used in multiple forms to establish the level of agility of an organization, as well as a consultative tool for defining a plan of action to improve organizational agility.
The phrases “Agile Enterprise,” “Organization Adaptability,” and “Organizational Agility” are used interchangeably throughout the description of the present invention. The change in use of terminology from one to another should not be taken to imply a difference in scope or meaning of one term with respect to the others.
Those of ordinary skill in the art will appreciate that the hardware in
With reference now to
Organizational adaptability is often a subjective matter. The present invention comprehends the subjectivity of the problem, and supports multiple adaptability views of the same organization, in different contexts.
In one embodiment of the present invention, the AEI comprises multiple components and a process for measuring an organization's adaptability, and uses this output for assessment, consultation and implementation purposes. The methodology of the present invention comprises taxonomy 206, profiles 208, an index 214, a model 212, a validation process 210, organizational characteristics 202 and an organization 204.
Taxonomy 206 is a hierarchical list that captures the organizational elements that can be used to measure or predict an organization's responsiveness to change. A single or multi taxonomies may be utilized. An example of a taxonomy 206 is illustrated in
The taxonomy 206 primarily relies on the expertise of the consultant, which is industry-specific (in fact the index itself is also industry-specific). The weights of the elements within the taxonomy 206 may be based on the knowledge of consultants (at least at the starting point), but will rely on the analysis of empirical data—this analysis is based on creating two lists of companies, one considered agile, and one not. Then, through the applications of data mining and statistical analysis, we determine the contribution of each element of the taxonomy 206, and thus the associated weight for the computation of the index. This analysis may be non-linear.
Profiles 208 is a set of weights associated with the elements of the taxonomy which indicate the relevant contribution of each element to the overall adaptability of an organization. Multiple profiles 208 may be present to assess the organization in different contexts.
To better understand the concept of profiles 208, consider the example of a startup software company versus a mining company. Such a software company must develop new products, test them, and market them very rapidly, as well as be prepared to discontinue the product and start a whole new line of products very rapidly—or, it will be out of business. In contrast, a mining company, with significant investments in capital equipment can not and will not make changes to its core business so rapidly; instead, they will need to change in other ways such as improving procurement and discovering new mining locations. So, what contributes to adaptability in one industry may be very different than another. These contributions can be captured via sets of weights on the taxonomy elements. Each of these sets is represented as a profile. So, the profile for a startup software company may have high weights for product development, and the profile for a mining company may have very low weights for new product development, but high weights for making changes to the internal administrative processes.
Index 214 is a set of algorithms that calculate and quantify the adaptability of an organization 204. The index 214 may measure organizational adaptability at various levels of detail (e.g., coarse to fine), as defined by the taxonomy. The index 214 comprehends the context of analysis using profiles' 208 weights. The index 214 also establishes confidence factors based on the available input and profiles' 208 weights. There are many different algorithms for computing the confidence factors which will be well know to those of skilled in the art. One example of an algorithm for computing the confidence factor is:
ICF=(NE*SW)/(TNE*STW)
Where, ICF is the Index Confidence Factor, NE is the total number of elements (from the taxonomy 206) that were actually used to calculate the index (since not all questions about the elements may be answered), SW is the sum of the weights of the elements that were used to calculate the index 214, TNE is the total number of the elements in the taxonomy 206, and STW is the sum of all the weights of the elements in the taxonomy 206. It should be noted that the confidence factor is typically a relative measure and not an absolute one.
Model 212 (also referred to as an AEI Computation Tool) is a tool for implementing the calculation of the Index, implemented on a data processing system, such as, for example, data processing system 100 depicted in
Validation 210 is a process that verifies the assumptions in the taxonomy 206 and profiles 208. This validation 210 process includes collection and use of empirical data, clustering and correlation analysis, visualization, data mining, and other techniques. Validation 210 prunes and adjusts the taxonomy 206, and establishes optimal profile 208 weights. Due to the dynamic nature of the business environment, the process of Validation 210 should be conducted frequently.
The validation 210 process is the same as the initial setup process. It is in fact manual for the taxonomy 206, but could be automated for the weights of the elements in the taxonomy 206. The validation 210 is important because the business factors that contribute to adaptability or the need for adaptability can change over time. The taxonomy 206 is validated by industry consultants reviewing the existing taxonomy 206 and updating it's elements; for example, in the automotive industry, the rate at which embedded systems are used could be much more significant in year 2005 than it was in 2000. The weights are updated via data mining and statistical analysis, just to make sure that the contributions of the taxonomy 206 elements to adaptability is up-to-date.
Another component of the methodology of the present invention is consultation 216. Consultation 216 is a process that includes evaluating an organization's characteristics 202, as defined by the taxonomy 206, selecting an appropriate profile 208, and calculating an index 214 using the model 212 after the validation 210. Traditionally, an assessment or consultation was conducted manually by one or more consultants. However, the present invention provides an automated consultation 216 that analyzes the index 214 and other data gathered to create the index 214 and determines recommendations that can be provided to the organization to improve the organization's business adaptability. The consultation 216 relies on expert systems that utilize heuristics and rules based on the industry and particular organization to analyze the index and related data to determine recommendations. In the prior art, one or more consultants, after the index 214 was created, would then spend time within the organization gathering data and then utilize the data, their expertise, and the index 214 to determine specific recommendations for the organization that would help the organization to become more adaptable.
However, much of the data gathered had already been gathered in the creation of the index 214, thus resulting in the duplication of effort. Furthermore, different experts may provide different recommendations thus possibly resulting in differing levels of service for different organizational clients. By automating the consultation 216 process, costs for the consulting company and for the organization under study are reduced since duplication of effort is eliminated or substantially reduced. Furthermore, the organization under study receives their recommendations much faster, thus allowing them to implement changes sooner, which in today's fast paced business world can be critical.
Furthermore, the rules utilized by the consultation 216 process can be determined by combining the expertise of several consultants familiar with a particular industry and/or organization, thus resulting in consistent recommendations and improved recommendations conforming to industry best practices. Expert systems, such as employed by consultation 216, are well known to those of ordinary skill in the art. However, for those less familiar with expert systems, more detail is provided about expert systems below.
However, turning now to
User interface includes an organizational name entry block 402 allowing a user to enter that name of an organization under analysis as well as a session description entry box 404 allowing the user to enter a description of the organization and purposes of the analysis. A profile drop down menu 406 is provided allowing a user to select a profile for which the analysis is focused. A profile description entry box 408 is also provided to allow a user to enter explanatory notes and other data associated with the profile selected.
The user interface 400 also provides assessment inputs 410-416 as well as an indicator value input 422. Buttons 416 and 418 allow a user to clear values or update as desired. A current value display window 424 allows a user to view the current values for each assessment input and a compute index button 426 allows a user to instruct the AEI tool to compute an index as is discussed in more detail below.
An assessment indices window 428 provides the user with the results of the computing the index allowing the user to observe the quantitative assessment index with explanations. The user may save the session and results, if desired, by entering a session name in the session name input box 432 and selecting the save session button 430.
User interface 400 is an example of a user interface that may be used in conjunction with the tools for determining quantitative assessment of organizational adaptability of the present invention. However, as those skilled in the art will recognize, other user interfaces may be utilized as well.
With reference now to
AEI consists of an Agility Taxonomy 518, several indices 510 (e.g., profile index 512 and assessment indices 514), and a AEI Computation tool 508 for the computation of the indices 510. The basis for the taxonomy 518 and the indices 510 are considered to be temporally dynamic, requiring frequent updates and validation. When validated, the indices 510 can be used in multiple forms to establish the level of agility of an organization, as well as a consultative tool for defining a plan of action to improve organizational agility.
The computation of AEI is based on a taxonomy of an enterprise attributes. The organization of the taxonomy 518 defines the enterprise attributes that correlate with enterprise agility in a hierarchical manner, consisting of pertinent terms, questions, and issues. It is also understood that the taxonomy 518 is a living representation and will need to be updated on a regular basis. As described above, an exemplary taxonomy is depicted in
The enterprise attributes defined in the taxonomy 518 are believed to be dynamic over time. Therefore, it is preferable to update the taxonomy 518 on a regular basis. The frequency of the updates will be a function of the attributes as well as changes in the economy and market place. A governance body may be required to determine the necessity for any updates. Therefore, any use of AEI must be in the confines of a specific timeframe.
The taxonomy 518 is used as a tool to score the AEI for an enterprise. Each indicator in the taxonomy 518 is given a relative weight stored in weight profiles 516, which implies the contribution or association of the indicator with an enterprise's agility. When analyzing an enterprise, each indicator is assigned a score, for example 1 (low)-7 (high); the scores are multiplied by the weights for each indicator, summed up, and normalized into a 0-100% range.
Each indicator in the taxonomy 518 is assigned a relative weight. The weights are multiplied by the Score for each indicator when calculating the indices 510. A weight may be a single number (e.g., 42) or a function of other indicators. Care must be taken to avoid self-referencing functions.
The agility of enterprises must be measured in a proper context. Factors such as the industry and government regulations impact an enterprise's capacity to be agile. Therefore, any mechanism for measuring the AEI must comprehend the natural capacity for change. AEI uses the notion of weight profiles 516 to adjust the agility measures, so that enterprises may be fairly assessed along a common scale, analogous to handicap in golf.
Each weight profile is a separate set of weights for the indicators. The criteria for the weight profile are essentially the agility factors beyond an enterprise's control. Examples of such factors are:
A single index can not possibly measure every aspect of the factors that lead to an enterprise's agility. Therefore, the AEI model implements multiple indices (profile 512 and assessment 514) to enable the measurement of agility at different levels and along appropriate dimensions, as well as a confidence factor for each index 512 and 514 to allow for any ambiguities in the assessment process.
The profile index 512 is a single number, 0-100%, which provides a coarse and high-level indication of an enterprise's agility. The profile index 512 does not comprehend any details, causes, or corrective actions. This index 512 is typically based on publicly available information. This index is obtained by the normalized sum of the scores (1-7) assigned to each dimension, multiplied by the dimension's weight. The weight for each dimension is the average of the weights of the dimension's indicators.
The Assessment Index 514 is in fact a set of indices that can be used to measure the specific factors that impact agility. This index 514 provides insights into the organization issues that affect agility, thus can be used as a tool to improve agility. This index 514 is based on a detailed analysis of an enterprise, typically requiring interviews and access to information not publicly available. This index is obtained by the normalized sum of the scores (1-7) assigned to each indicator, multiplied by the indicator's weight.
The Profile and Assessment Indices may be compared as follows:
Each index 512 and 514, as noted above, will be calculated based on certain inputs. It is quite possible that the calculations may be based on incomplete or ambiguous information. Therefore, a confidence factor (%) is also calculated for each index 512 and 514. The confidence factor is based on the completeness and certainty of the inputs.
As mentioned above, the taxonomy 518 is the agility taxonomy described, for example, via dimensions, categories, elements, and indicators. The weight profiles 506 are a set of unique indicator weights to be applied by AEI computation 508 to the elements within taxonomy 518. Enterprise profile 504 is a set of responses (for example, 1-7 scores) to issues defined by the taxonomy indicators. The context drivers 502 are a sub-set of the enterprise profile 504 used for selecting an appropriate weight profile from weight profiles 516. The weight profile selector 506 is a tool for selecting a suitable weight profile based on the context drivers 502. AEI Computation 508 calculates the indices 510 and confidence factors. The AEI indices 510 are the output, consisting of a single profile index 512 and a set of assessment indices 514 and confidence factors.
The agility index 510 can be a key tool in an approach to enterprise agility improvement. During the initial assessment, the tool 510 aids in benchmarking current levels of agility and estimating the size of the improvement opportunities. Its output is key to tailoring an “agility roadmap”—an agility improvement program for the client's unique situation. On an ongoing basis, the tool 510 provides a measurement and assessment platform for gauging progress and for fine tuning or redirecting the improvement program as conditions change.
In an initial assessment, the index tool 510 can be used to calibrate and score current levels of performance across a wide range of agility indicators covering the key dimensions of the enterprise. Included are indicators of agility for the enterprise's current processes, practices and assets, and for its improvement initiatives both planned and underway. Indicators also measure performance on key agility metrics.
Individual indicator scores can be aggregated into elements and categories within each dimension. This sets the agility baseline for the enterprise as a whole, and for relevant operating units, geographies or other organizational units. Next, the tool 510 can be used to determine and select appropriate “best agile” benchmark targets for the enterprise that reflect the unique characteristics of its industry and operating environment.
Comparing the agility indicators with the benchmarks, the tool 510 can then be used to determine the size of the gaps between baseline and “best agile.” Drawing on improvement benchmark databases, the tool helps to estimate the benefit/ROI opportunity based on the size of the gaps. Finally the tool 510 classifies and arrays each gap on a criticality (green-yellow-red) scale based on the size of the gap and how important closing that gap is toward achieving the enterprise's strategy and goals.
As a part of the overall assessment process, the tool helps provide unique insight and guidance to executives. The rigor and breadth of coverage embodied in the index tool 510 helps to:
Prioritizing improvement actions begins with a solid understanding of the impact and ease of implementing each opportunity.
Sequencing is also important. Some improvements will be foundational, in areas that need to be shored up before other, more sophisticated actions are taken. Some improvements may produce significant short-term payback, thereby helping to fund other improvements. Some may simply be “must-haves” to respond to a window of opportunity or a pressing customer requirement. And even so, virtually no organization has the resources or the capacity for change to launch all potential initiatives simultaneously.
Most enterprises already have a number of initiatives underway (e.g.; systems implementation, CAPEX projects, process improvements and transformational programs like Six Sigma). Some of these initiatives may directly support or complement new agility-oriented initiatives. Others may no longer be as attractive a place to invest resources. Others still may be at odds with the new agility agenda. The design of the agility roadmap needs to factor-in existing programs and accelerate, decelerate, integrate, redirect and/or kill those initiatives based on the fit with the array of opportunities identified in the agility assessment.
The agility index tool provides a foundation for ongoing agility improvement in the enterprise.
First, beginning with the initial assessment, the tool 510 helps establish and promote a common framework and a common language for communicating about agility measurement and improvement within the enterprise. The organization can use this verify (or expand) its current thinking on what agility means and to focus its efforts going forward.
Second, the index helps create a basis for measuring the total value received from improving agility. The index tool's 510 linkage between improvement actions and benefits/ROI helps to define balanced scorecard components related to ongoing agility improvement.
Finally, the index 510 also helps clients to reassess and reprioritize the agility roadmap as the enterprise makes improvements. The tool 510 helps make possible a cost-effective assessment process, based on repeatable, efficient agility assessment methods. Also, the index tool 510 is refreshed and updated to reflect new levels of best agile so that enterprises can track their competitive agility position over time.
Agility of an enterprise consists of both tangible and intangible measures. Any index that attempts to quantify the agility of an enterprise must recognize inherent ambiguities, the dynamic nature, and the perceptions involved. Therefore, validation of an index plays a significant role in designing and maintaining such an index. Validation of an agility index will consist of two distinct but necessary components, as follows:
The agile enterprise must always learn to adapt, that is incessantly modifying the economic structure from within, to keep pace with the incessant demands for renewal that are constantly furnished by the innovation economy environment.
What do owners do in this process? They provide risk capital. When an owner provides equity, he absorbs the time lag between costs and revenues, a time lag that may never be bridged. However owners are not gamblers—they should not be. Owners have to confront and manage the risks that their investments are being exposed to. They must be, in fact, concerned with the reduction or the elimination of the fundamental risks that their business operations are involved in.
Therefore, the competence that owners must demonstrate is two-fold, both of which are equally important:
The external environment constantly forces owners to examine their capital allocation efficiency and ability to go through the process of constant renewal. It means not only being able to handle the risks of new innovations, but also mastering these new risks—for new risks also mean new opportunities.
All systems-thinking is based on feedback loops that use the principles of positive and negative feedback. Applied to businesses, renewing an established way of doing business without changing its fundamental structure would be an example of negative feedback whereas being agile in renewal, that is, developing a new way of doing business or fundamentally renewing an existing one would be an example of positive feedback. An owner will always be faced with difficult decisions as to which feedback loop to utilize in relation to his external environment. Risk mitigation also comes by constantly embracing these difficult decisions.
The AEI demonstrates how agility based decisions affect the net present value of cash to shareholders. This tool 510 is used at two levels within a company: the operating business unit and the corporation as a whole. Within business units, the AEI measures the value the unit has created by analyzing cash flows over time.
At the corporate level, the AEI provides a framework to assess options for increasing value to shareholders: the framework measures tradeoffs among reinvesting in existing businesses, investing in new businesses, and returning cash to stockholders.
The innovation economy's shrinking competitive advantage periods (CAPs) necessitate that an investor as well as a manager understands the agility and quickness dynamics of organizational change and the mental models that owners need to have not only sense and respond but rather to anticipate in order to keep up with the incessant change.
The use of the AEI begins with a comprehensive assessment of an organization's business agility from front-line customers to shareholders. The AEI identifies key drivers of total shareholder return now and in the future, and measures:
AEI can be used both as a tool to aid in strategic decisions and to guide normal decision-making throughout the organization. When used as an everyday tool by managers, the AEI can be applied in many ways to:
The AEI will enable focused initiatives on people, supply chains, systems, and environments that:
Turning again now to expert systems, expert systems (also known as rules engines) are a method used to implement knowledge-based systems. In these systems, the domain knowledge is represented by IF-THEN rules (heuristics) and used in forward or backward chaining modes by an inference engine. Expert systems were pioneered by Edward Feigenbaum of Stanford University in the 1960s. His chemistry system, DENDRAL, used the chemical knowledge gathered from Nobel Prize winning scientist, Joshua Ledenberg, best known today as the father of genetic engineering.
With reference now to
An expert system consists of the several components shown in
Inference engines are typically commercial products that are integrated within computer applications. The knowledge-base 606 is generally a user-maintained set of rules (heuristics) that is used by the inference engine 604 for reasoning and problem solving purposes. Thus, the application logic can be stored in the knowledge-base 606, and readily updated as necessary. Since changes in the knowledge-base 606 do not require the traditional software development steps (e.g., authoring, compiling, system testing), the length of time and costs associated with maintaining are application reduced, and thus the application is considered to be more flexible and responsive.
The knowledge base 606 is a set of IF-THEN rules that contain the high-level principles about the domain. Knowledge bases, as is well known to those skilled in the are, are very application specific and can be built by knowledge engineers using commercial products.
The inference engine 604 and the knowledge base 606 are the permanent parts of the system. The rule-based system can be used many times with different data entered into it to solve different problems. The system's users enter data into working memory 602 (working memory 602 is a list of facts about a topic can be expanded during the operation of a rule-based system) and the inference engine 604 takes the data from working memory 602, applies the rules in the knowledge base 606 to it, and deduces more facts. These new facts are then added back into the working memory 602.
There are two types of knowledge represented in expert systems, facts and relationships. The following statement shows the logical relationship between two concepts, age and adulthood:
Facts tend to be put into objects in most rule-based systems. Relationships are put into rules. Rules are used to capture conditional knowledge, such as what actions to perform under various conditions, or what causes lead to various symptoms. Rules are, in effect, logic statements that use the implication connective (=>), and can involve quantifiers and variables.
Clauses are the building blocks of rules. A rule joins two clauses (simple or compound) and states that the truth of the first clause implies the truth of the second clause. The following statements are examples of clauses:
Algorithms are at the center of procedural computing. Most application developers have been trained to think in terms of algorithms and their knowledge is often best expressed on the computer in algorithmic terms. Flow charts often represent algorithms and are the process side of computing systems.
Heuristics as used in expert systems are rules-of-thumb that often work, though not always. The following statements are examples of heuristics:
An example of a set of rules or heuristics that might be utilized in an expert system for improving an organization's adaptability in accordance with one embodiment of the present invention are as follows:
With reference now to
Rules in an expert system can resemble the conditional statements in procedural languages, but they are inherently different. The conditional statements in procedural languages control the flow of the program, but rules in expert system are used to define actionless relationships among the domain entities.
In an expert system, the rules 802 essentially float in the system and are sequenced at run-time by the inference engine 708 based on the availability of data or goals. Unlike conditional statements 804, changes to the rule base do not require any rewriting of the program.
The rules in conventional software (conditionals) control the flow of an application, where as the rules in an expert system assert new facts from an existing body of knowledge; another key difference is that the low of conditional is pre-programmed, but the flow of rules is determined at run-time based on the available data.
Further, the function of an IF-THEN conditional statement is to specify which branch of program logic is to be followed next as shown in the following table.
But, the functions of rules are to express a relationship of logical dependence between facts as shown in the following table.
The following table shows that the IF and THEN portions of a rule are called a variety of names.
Inference engines 708 are specialized software programs designed to be used with expert systems. However, programmers working on intelligent system projects rarely write original inference engines 708. Instead, a third party usually provides this software, along with a language for writing rules that can be manipulated by the inference engine 708. There are dozens of companies that market inference engines as are will known by those skilled in the art. Many inference engines 708 are extremely well developed and sophisticated, with complex rule languages and control mechanisms highly optimized for speed.
Inference engines for expert system programming, provide two basic control methods:
Although forward and backward chaining use the same body of rules, they perform very different functions. Each chaining mechanism is suitable for different classes of problems. Selecting the appropriate chaining mechanism is critical to the success of the expert system. The knowledge engineer must not be mislead by the title of the project or problem, instead, the knowledge engineer must focus on the domain knowledge and how decisions are made to select the proper chaining mechanism. Examples of classes of problems addressed by each chaining mode are listed below.
Forward Chaining Examples:
This sub-section provides an overview of forward chaining. In forward chaining, the rules engine attempts to assert knowledge based on available facts (data) in the fact base. Forward chaining is used when the application attempts to design or configure a new solution. The rules engine typically performs the following tasks in forward chaining:
When the inference engine 708 stops firing rules, all the asserted facts are left in the fact base, which may be interrogated for answers to a specific question. A predefined goal may also be used by the inference engine, which may help accelerate the inference process. A goal is an inquiry about the value of unknown fact. When the inference engine 708 discovers the value of the unknown fact (goal), it terminates the process and will not fire other rules.
To aid in understanding forward chaining, reference will be made to
The following simple example illustrates the process of forward chaining. In the example, the output is a vacation plan, which includes when to go, whether to go abroad, and where to stay. The facts in this example are the following: the vacationers have plenty of funds, plenty of time, and can travel in Fall.
Step 1
The inference engine 904 examines PM 902 to determine if any of the antecedents can be satisfied with the information in the WM 908. It selects these rules and places them in the CS 906 as encountered as depicted in
Step 2
The inference engine 904 examines the rules in the CS 906 to determine which rule to fire. It uses a conflict resolution strategy that may or may not be user specified. Rule 1 is fired and “go during off season” is placed in the WM 908 as depicted in
Step 3
The inference engine 904 re-examines the PM 902 (because the WM 908 has changed) to determine if any other rules should be placed in the CS 906 and adds Rule 2 and Rule 6 to the CS 906 as depicted in
Step 4
The inference engine 904 determines that Rule 2 and Rule 6 should be activated. The conflict resolution strategy decides to fire Rule 2. Thus “go broad” is added to the WM 904 as depicted in
Step 5
PM 902 is now re-examined to determine if any other rules should be added to the CS 906 because the WM 908 has changed. However, no new rules were added as depicted in
Step 6
Because there were not any rules added to the CS 906, Rule 3 fires based on the ordering conflict resolution. “Travel_mode=cruise” is placed in the WM 908 as depicted in
Step 7
Once again the PM 902 is examined to determine if any new rules should be added to the CS 906. Because none of the new rules were added, Rule 6 fires and “stay in a 5-star hotel” are added to the WM 908 as depicted in
Step 8
The PM 902 is examined to determine if any new rules should be placed in the CS 906. Because none of the new rules were activated, the system stops.
Backward Chaining
This sub-section provides an overview of backward chaining. In backward chaining, the rules engine attempts to determine the value of some variable. Forward chaining is used when the application attempts to design or configure a new solution. The process begins by identifying a goal or hypothesis, such as, “Why does my car not start?” The rules engine then attempts to identify a condition that supports the stated hypothesis.
In backward chaining, the rules engine performs the following tasks:
While evaluating the premise of any given rule, one of the following three states can occur:
Goals in a backward chaining system are common in real life situations, such as the following:
Backward chaining rules engines are organized around providing answers to these goals. In general, backward chaining is used for diagnostic problems.
Referring now to
The inference engine 1704 finds the first rule in Knowledge Base 1702 that sets a value to travel_mode which in this case is Rule 5 as depicted in
Step 2
The inference engine 1704 then checks the premise of Rule 5 to see if it is true. The premise says funds_OK is false, but funds_OK is unknown. So funds_OK becomes the intermediate goal.
Step 3
The inference engine 1704 finds that Rule 1 sets a value to funds_OK.
Step 4
The inference engine 1704 checks whether the premise of Rule 1 is true. The premise is not true ($1500>$1000), so Rule 1 fails.
Step 5
The inference engine 1704 now looks for other rules that set a value to funds_OK. It finds Rule 2.
Step 6
The inference engine 1704 checks the premise of Rule 2. The premise is true ($1500>=$1000). Rule 2 fires causing funds_OK to be set to true (and added to FACTS 1706) as depicted in
Step 7
The inference engine 1704 now returns to Rule 5. The first condition in the premise is not satisfied, so Rule 5 fails.
Step 8
The inference engine 1704 looks for the rule that sets a value to travel_mode. It finds Rule 6. The first condition is true, but the second is unknown. So, a new intermediate goal is formed, find the value of time_OK.
Step 9
The inference engine 1704 finds that Rule 3 sets a value to time_OK. The premise of the rule is false (time is not less than 2 weeks), so Rule 3 fails.
Step 10
The inference engine 1704 finds that Rule 4 sets a value to time_OK. This rule has a true premise (time>=2 weeks), so Rule 4 fires and time_OK=true is added to the facts 1706 as depicted in
Step 11
The inference engine 1704 returns to Rule 6. The second condition in the premise is false, so Rule 6 fails.
Step 12
The inference engine 1704 finds that Rule 7 sets a value to travel_mode. The premise of this rule is true, so the rule fires, and travel_mode=train is added to the facts 1706 as depicted in
It is important to note that while the present invention has been described in the context of a fully functioning data processing system, those of ordinary skill in the art will appreciate that the processes of the present invention are capable of being distributed in the form of a computer readable medium of instructions and a variety of forms and that the present invention applies equally regardless of the particular type of signal bearing media actually used to carry out the distribution. Examples of computer readable media include recordable-type media such a floppy disc, a hard disk drive, a RAM, and CD-ROMs and transmission-type media such as digital and analog communications links.
The description of the present invention has been presented for purposes of illustration and description, but is not intended to be exhaustive or limited to the invention in the form disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art. The embodiment was chosen and described in order to best explain the principles of the invention, the practical application, and to enable others of ordinary skill in the art to understand the invention for various embodiments with various modifications as are suited to the particular use contemplated.
The present invention is related to an application entitled “A System and Method for Quantitative Assessment of Organizational Adaptability,” Ser. No. ______, attorney docket no. LEDS.00106, filed even date herwith, assigned to the same assignee, and incorporated herein by reference for all purposes.
