U.S. patent application number 10/237021 was filed with the patent office on 2008-01-31 for knowledge based performance management system.
Invention is credited to Jeff Scott Eder.
Application Number | 20080027769 10/237021 |
Document ID | / |
Family ID | 38987489 |
Filed Date | 2008-01-31 |
United States Patent
Application |
20080027769 |
Kind Code |
A1 |
Eder; Jeff Scott |
January 31, 2008 |
Knowledge based performance management system
Abstract
An automated system (100) and method for knowledge based
performance management for an organization. After extracting data
from existing narrowly focused systems, mission measures and
organization levels are defined for one or more organizations. The
elements, factors and risks that contribute to mission measure
performance by organization level and organization are
systematically defined and stored in a ContextBase using up to six
context layers. ContextBase information is extracted for specified
combinations of context layers, organization levels and
organizations as required to produce complete context frames. The
complete context frames are then used by a series of applications
for reviewing, analyzing, forecasting, planning and optimizing
organization performance.
Inventors: |
Eder; Jeff Scott; (Mill
Creek, WA) |
Correspondence
Address: |
ASSET TRUST, INC.
2020 MALTBY ROAD, SUITE 7362
BOTHELL
WA
98021
US
|
Family ID: |
38987489 |
Appl. No.: |
10/237021 |
Filed: |
September 9, 2002 |
Current U.S.
Class: |
705/7.28 ;
705/7.29; 705/7.31; 705/7.36; 705/7.37; 705/7.38; 707/E17.108 |
Current CPC
Class: |
G06Q 40/12 20131203;
G06Q 10/06311 20130101; G06Q 30/0202 20130101; G06Q 10/06375
20130101; G06Q 10/0639 20130101; G06Q 10/0635 20130101; G06Q
10/0631 20130101; G06F 16/951 20190101; G06Q 10/0637 20130101; G06Q
30/0201 20130101; G06Q 10/06 20130101 |
Class at
Publication: |
705/7 |
International
Class: |
G06F 17/50 20060101
G06F017/50 |
Claims
1-58. (canceled)
59. An apparatus, comprising: organization narrow systems, means
for aggregating and analyzing the data from said systems as
required to develop context layers from the group consisting of
physical, tactical, instant impact, organization, mission, social
environment and combinations thereof, and means for providing
access to the data from said systems in accordance with an
organization context where the organization context is defined by
one or more context layers.
60. The apparatus of claim 59 where narrow systems are selected
from the group consisting of accounting systems, alliance
management systems, asset management systems, brand management
systems, budgeting/financial planning systems, business
intelligence systems, call management systems, cash management
systems, channel management systems, commodity risk management
systems, content management systems, contract management systems,
credit-risk management system, customer relationship management
systems, data integration systems, demand chain systems, decision
support systems, document management systems, email management
systems, employee relationship management systems, energy risk
management systems, executive dashboard systems, expense report
processing systems, fleet management systems, fraud management
systems, freight management systems, human capital management
systems, human resource management systems, incentive management
systems, innovation management systems, insurance management
systems, intellectual property management systems, intelligent
storage systems, interest rate risk management systems, investor
relationship management systems, knowledge management systems,
learning management systems, location management systems,
maintenance management systems, material requirement planning
systems, metrics creation system, online analytical processing
systems, ontology management systems, partner relationship
management systems, payroll systems, performance management
systems, price optimization systems, private exchanges, process
management systems, product life-cycle management systems, project
management systems, project portfolio management systems, revenue
management systems, risk management information system, risk
simulation systems, sales force automation systems, scorecard
systems, sensor grid systems, service management systems, six-sigma
quality management systems, strategic planning systems, supply
chain systems, supplier relationship management systems, support
chain systems, taxonomy development systems, technology chain
systems, unstructured data management systems, visitor (web site)
relationship management systems, weather risk management systems,
workforce management systems, yield management systems and
combinations thereof.
61. The apparatus of claim 59 where the mission layer identifies
the net impact of elements, risks and external factors on one or
more mission measures where said measures are selected from the
group consisting of alliance risk, brand risk, channel risk,
content risk, contingent liabilities, customer risk, customer
relationship risk, current operation risk, derivative risk,
employee risk, employee relationship risk, energy risk, enterprise
risk, external factor risk, event risk, fraud risk, information
technology risk, total return, intellectual property risk,
investment risk, knowledge risk, market sentiment risk, market
risk, market volatility, organization risk, partnership risk,
process risk, production equipment risk, product risk, real option
risk, technology risk, vendor risk, vendor relationship risk,
weather risk, revenue, expense, capital change, alliance return,
brand return, channel return, content return, customer return,
customer relationship return, current operation return, derivative
return, employee return, employee relationship return, enterprise
return, external factor return, event return, information
technology return, intellectual property return, investment return,
knowledge return, market sentiment return, market return, market
volatility, organization return, partnership return, process
return, production equipment return, product return, real option
return, shareholder return, technology return, vendor return,
vendor relationship return, alliance value, brand value, channel
value, content value, contingent liabilities, customer value,
customer relationship value, current operation value, derivative
value, employee value, employee relationship value, enterprise
value, external factor value, event value, information technology
value, intellectual property value, investment value, knowledge
value, market sentiment value, market value, market volatility,
organization value, partnership value, process value, production
equipment value, product value, real option value, technology
value, vendor value, vendor relationship value and combinations
thereof.
62. The apparatus of claim 59 that supports the development of
context frames where context frames are defined by attributes
selected from the group consisting of mission measures, context
layers, organization levels, organizations and combinations
thereof.
63. The apparatus of claim 59 where the means for providing access
to the data from narrow systems in accordance with an organization
context further comprises a datamart, a data warehouse, a storage
area network or a virtual database.
64. The apparatus of claim 59 where mission measures further
comprise any quantifiable measure.
65. The apparatus of claim 59 that defines an organization
ontology.
66. The apparatus of claim 59 where the context layers are
developed by learning from the data.
67. The apparatus of claim 59 where an organization further
comprises an organization combination.
68. The apparatus of claim 59 that supports the development and
alignment of measures by organization level in an automated
fashion.
69. A program storage device readable by machine, tangibly
embodying a program of instructions executable by a machine to
perform method steps for performing an organization management
method, the method steps comprising: aggregating data from
organization narrow systems and learning from said data as required
to develop one or more contexts for organization performance where
said contexts are defined by context layers selected from the group
consisting of physical, tactical, instant impact, organization,
mission, social environment and combinations thereof.
70. The program storage device of claim 69 where the method steps
further comprise: defining one or more subsets of the organization
for separate management using at least a portion of said context,
creating a context frame for the one or more subsets of the
organization, and managing the performance of each of the one or
more organization subsets using said context frame and one or more
standard applications.
71. The program storage device of claim 69 where narrow systems are
selected from the group consisting of accounting systems, alliance
management systems, asset management systems, brand management
systems, budgeting/financial planning systems, business
intelligence systems, call management systems, cash management
systems, channel management systems, commodity risk management
systems, content management systems, contract management systems,
credit-risk management system, customer relationship management
systems, data integration systems, demand chain systems, decision
support systems, document management systems, email management
systems, employee relationship management systems, energy risk
management systems, executive dashboard systems, expense report
processing systems, fleet management systems, fraud management
systems, freight management systems, human capital management
systems, human resource management systems, incentive management
systems, innovation management systems, insurance management
systems, intellectual property management systems, intelligent
storage systems, interest rate risk management systems, investor
relationship management systems, knowledge management systems,
learning management systems, location management systems,
maintenance management systems, material requirement planning
systems, metrics creation system, online analytical processing
systems, ontology management systems, partner relationship
management systems, payroll systems, performance management
systems, price optimization systems, private exchanges, process
management systems, product life-cycle management systems, project
management systems, project portfolio management systems, revenue
management systems, risk management information system, risk
simulation systems, sales force automation systems, scorecard
systems, sensor grid systems, service management systems, six-sigma
quality management systems, strategic planning systems, supply
chain systems, supplier relationship management systems, support
chain systems, taxonomy development systems, technology chain
systems, unstructured data management systems, visitor (web site)
relationship management systems, weather risk management systems,
workforce management systems, yield management systems and
combinations thereof.
72. The program storage device of claim 69 where the method steps
further comprise: storing organization related data in accordance
with one or more organization contexts by context layer.
73. The program storage device of claim 72 where the means for
storing data in accordance with an organization context further
comprises a datamart, a data warehouse, a storage area network or a
virtual database.
74. The program storage device of claim 69 where the method steps
further comprise: developing and aligning measures by organization
level in an automated fashion.
75. The program storage device of claim 69 where context frames are
defined by attributes selected from the group consisting of mission
measures, context layers, organization levels, organizations and
combinations thereof.
76. The program storage device of claim 69 where the standard
applications support organization management activities selected
from the group consisting of analysis, forecast, optimization,
planning, project management, review, transaction and combinations
thereof.
77. A data method, comprising: establishing an interface with a
narrow system; testing the ability of said narrow system to process
different types of data from different combinations of context
layers using said interface; and tailoring the data provided to
said narrow systems based on the results of said test.
78. The method of claim 77 that further comprises assigning a score
to each narrow system based on the test results.
79. The method of claim 77 that further comprises assigning points
for the ability to process data from each of one or more context
layers.
80. The method of claim 77 that further comprises assigning points
for the ability to change the type of data processed from a given
context layer.
81. The method of claim 77 where narrow systems are selected from
the group consisting of accounting systems, alliance management
systems, asset management systems, brand management systems,
budgeting/financial planning systems, business intelligence
systems, call management systems, cash management systems, channel
management systems, commodity risk management systems, content
management systems, contract management systems, credit-risk
management system, customer relationship management systems, data
integration systems, demand chain systems, decision support
systems, document management systems, email management systems,
employee relationship management systems, energy risk management
systems, executive dashboard systems, expense report processing
systems, fleet management systems, fraud management systems,
freight management systems, human capital management systems, human
resource management systems, incentive management systems,
innovation management systems, insurance management systems,
intellectual property management systems, intelligent storage
systems, interest rate risk management systems, investor
relationship management systems, knowledge management systems,
learning management systems, location management systems,
maintenance management systems, material requirement planning
systems, metrics creation system, online analytical processing
systems, ontology management systems, partner relationship
management systems, payroll systems, performance management
systems, price optimization systems, private exchanges, process
management systems, product life-cycle management systems, project
management systems, project portfolio management systems, revenue
management systems, risk management information system, risk
simulation systems, sales force automation systems, scorecard
systems, sensor grid systems, service management systems, six-sigma
quality management systems, strategic planning systems, supply
chain systems, supplier relationship management systems, support
chain systems, taxonomy development systems, technology chain
systems, unstructured data management systems, visitor (web site)
relationship management systems, weather risk management systems,
workforce management systems, yield management systems and
combinations thereof.
82. The method of claim 77 where the context layers are selected
from the group consisting of physical, tactical, instant impact,
organization, mission, social environment and combinations
thereof.
83. An architecture for use in designing, deploying, and managing a
plurality of applications on a distributed computing system for an
organization, the architecture comprising: a plurality of layers
where at least one layer is an application layer where a single set
of common applications resident in the application layer manage and
optimize a performance of any subset of an organization for a
complete context, where said complete context for an organization
subset comprises the context of claim 105 with one or more
quantitative measures for evaluating performance, and where the
common applications incorporate an analysis of a network effect of
a plurality of risks and elements of value on one or more
performance measures and are selected from the group consisting of
analysis, forecast, optimization, planning, project management,
review, transaction and combinations thereof.
84. The software architecture of claim 83 where a quantitative
measures is selected from the group consisting of alliance risk,
brand risk, channel risk, content risk, contingent liabilities,
customer risk, customer relationship risk, current operation risk,
derivative risk, employee risk, employee relationship risk, energy
risk, enterprise risk, external factor risk, event risk, fraud
risk, information technology risk, total return, intellectual
property risk, investment risk, knowledge risk, market sentiment
risk, market risk, market volatility, organization risk,
partnership risk, process risk, production equipment risk, product
risk, real option risk, technology risk, vendor risk, vendor
relationship risk, weather risk, revenue, expense, capital change,
alliance return, brand return, channel return, content return,
customer return, customer relationship return, current operation
return, derivative return, employee return, employee relationship
return, enterprise return, external factor return, event return,
information technology return, intellectual property return,
investment return, knowledge return, market sentiment return,
market return, market volatility, organization return, partnership
return, process return, production equipment return, product
return, real option return, shareholder return, technology return,
vendor return, vendor relationship return, alliance value, brand
value, channel value, content value, contingent liabilities,
customer value, customer relationship value, current operation
value, derivative value, employee value, employee relationship
value, enterprise value, external factor value, event value,
information technology value, intellectual property value,
investment value, knowledge value, market sentiment value, market
value, market volatility, organization value, partnership value,
process value, production equipment value, product value, real
option value, technology value, vendor value, vendor relationship
value and combinations thereof.
85. The software architecture of claim 83 where a subset of the
organization is defined by attributes selected from the group
consisting of context layers, organization levels, organizations
and combinations thereof.
86. The software architecture of claim 83 where a common
application within a set of common applications is selected from
the group consisting of an application for analyzing the impact of
user specified changes on a defined organization subset, an
application for forecasting the value of a specified variable using
context layer data for a specified defined organization subset, an
application for simulating organization performance and identifying
the optimal mode for operating a defined organization subset for
one or more measures, an application for establishing expected
levels and priorities for actions, events and measures for a
defined organization subset, an application for developing action,
element, impact, measure performance and risk reports in standard
formats for a defined organization subset, an application that
analyzes the impact of a project or a group of projects on a
defined organization subset and determines the feature set that
will optimize the impact of the project or group of projects on
said defined organization subset and combinations thereof.
87. A data method, comprising: integrating organization data in
accordance with an organization context model, and using said model
to develop an organization ontology that supports the management
and optimization of performance for one or more quantitative
measures for any subset of the organization using a set of common
applications.
88. The method of claim 87 where the ontology is developed by
learning from the data.
89. The model of claim 87 where organization context further
comprises one or more context layers where the layers are selected
from the group consisting of physical, tactical, instant impact,
organization, mission, social environment and combinations
thereof.
90. The model of claim 87 where the ingredients driving
quantitative measure performance are selected from the group
consisting of elements of performance, projects, resources, risks,
social environment factors and combinations thereof.
91. The model of claim 87 where elements of performance are
selected from the group consisting of alliances, brands, capital,
channels, customers, customer relationships, employees, employee
relationships, human capital, intellectual property, inventory,
investors, investor relationships, knowledge, partners, partner
relationships, processes, products, suppliers, supplier
relationships, support chains, visitors, the workforce, workforce
time and combinations thereof.
92. The model of claim 87 where social environment factors are
selected from the group consisting of numerical indicators of
conditions external to the organization, numerical indications of
prices external to the organization, numerical indications of
organization conditions compared to external expectations of
organization condition, numerical indications of the organization
performance compared to external expectations of organization
performance and combinations thereof.
93. The model of claim 87 where risks are selected from the group
consisting of factor variability risks, element variability risks,
base market risk, industry market risk, market volatility,
strategic event risks, extreme event risks, event risks, contingent
liabilities and combinations thereof.
94. The model of claim 87 that supports developing and aligning
measures by organization level in an automated fashion.
95. A database that provides access to organization related data by
context layer in accordance with one or more organization
contexts.
96. The database of claim 95 that further comprises a datamart, a
data warehouse, a storage area network or a virtual database.
97. The database of claim 95 where the context layers are selected
from the group consisting of physical, tactical, instant impact,
organization, mission, social environment and combinations
thereof.
98. The database of claim 95 where the one or more organization
contexts are defined by context frames.
99. An architecture for use in designing, deploying, and managing a
plurality of applications on a distributed computing system for an
organization, the architecture comprising: a plurality of layers
where at least one layer is an application layer where a single set
of common applications resident in the application layer manage a
performance of any subset of the organization for a complete
context, where the architecture enables an optimization of any
subset of the organization for a complete context, where said
complete context for an organization subset comprises the context
from claim 111 with one or more quantitative measures for
evaluating performance, and where the common applications
incorporate an analysis of the network effect of a plurality of
risks, external factors and elements of value on one or more
performance measures and are selected from the group consisting of
analysis, forecast, optimization, planning, project management,
review, transaction and combinations thereof.
100. The software architecture of claim 99 where a quantitative
measure is selected from the group consisting of alliance risk,
brand risk, channel risk, content risk, contingent liabilities,
customer risk, customer relationship risk, current operation risk,
derivative risk, employee risk, employee relationship risk, energy
risk, enterprise risk, external factor risk, event risk, fraud
risk, information technology risk, total return, intellectual
property risk, investment risk, knowledge risk, market sentiment
risk, market risk, market volatility, organization risk,
partnership risk, process risk, production equipment risk, product
risk, real option risk, technology risk, vendor risk, vendor
relationship risk, weather risk, revenue, expense, capital change,
alliance return, brand return, channel return, content return,
customer return, customer relationship return, current operation
return, derivative return, employee return, employee relationship
return, enterprise return, external factor return, event return,
information technology return, intellectual property return,
investment return, knowledge return, market sentiment return,
market return, market volatility, organization return, partnership
return, process return, production equipment return, product
return, real option return, shareholder return, technology return,
vendor return, vendor relationship return, alliance value, brand
value, channel value, content value, contingent liabilities,
customer value, customer relationship value, current operation
value, derivative value, employee value, employee relationship
value, enterprise value, external factor value, event value,
information technology value, intellectual property value,
investment value, knowledge value, market sentiment value, market
value, market volatility, organization value, partnership value,
process value, production equipment value, product value, real
option value, technology value, vendor value, vendor relationship
value and combinations thereof.
101. The software architecture of claim 99, wherein a subset of the
organization is defined by attributes selected from the group
consisting of context layers, organization levels, organizations
and combinations thereof.
102. The software architecture of claim 99, wherein a common
application within a set of common applications is selected from
the group consisting of an application for analyzing the impact of
user specified changes on a defined organization subset, an
application for forecasting the value of a specified variable using
context layer data for a specified defined organization subset, an
application for simulating organization performance and identifying
the optimal mode for operating a defined organization subset for
one or more measures, an application for establishing expected
levels and priorities for actions, events and measures for a
defined organization subset, an application for developing action,
element, impact, measure performance and risk reports in standard
formats for a defined organization subset, an application that
analyzes the impact of a project or a group of projects on a
defined organization subset and determines the feature set that
will optimize the impact of the project or group of projects on
said defined organization subset and combinations thereof.
103. An architecture for context aware computing, the architecture
comprising: a data access layer operable to exchange data with a
plurality of systems and to present the data to a context modeling
layer through a uniform interface; a context modeling layer
operable to develop a context from the data obtained from the data
object access layer and to present the context to a frame layer
through a uniform interface; a frame layer operable to obtain a
perspective from a user interface and to develop a context frame
which provides a context for the perspective to an application in a
uniform format, and an application layer that contains one or more
applications that use said context frame to complete one or more
useful context-aware functions.
104. The architecture of claim 103, wherein one or more
applications are selected from the group consisting of analysis,
forecast, optimization, planning, project management, review,
transaction and combinations thereof.
105. A computer program product embodied on a computer readable
medium and comprising program code for directing at least one
computer to complete processing in accordance with an architecture
for context aware computing, comprising: a data access layer
operable to exchange data with a plurality of systems and to
present the data to a context modeling layer through a uniform
interface; a context modeling layer operable to develop a context
from the data obtained from the data access layer and to present
the context to a frame layer through a uniform interface; a frame
layer operable to obtain a perspective from a user interface and to
develop a context frame which provides a context for the
perspective to a plurality of applications in a uniform format, and
an application layer that contains one or more applications that
use said context frame to complete one or more useful context-aware
functions where a context further comprises a complete context that
contains information that defines an impact of changes in operation
on a long term performance measure, information that defines a
social environment context and information selected from the group
consisting of information that defines a tactical context,
information that defines a physical context, information that
defines a measure context and combinations thereof.
106. The computer program product of claim 105, wherein one or more
applications are selected from the group consisting of analysis,
forecast, optimization, planning, project management, review,
transaction and combinations thereof.
107. The computer program product of claim 105, wherein a plurality
of systems are selected from the group consisting of accounting
systems, alliance management systems, asset management systems,
brand management systems, budgeting/financial planning systems,
business intelligence systems, call management systems, cash
management systems, channel management systems, commodity risk
management systems, content management systems, contract management
systems, credit-risk management system, customer relationship
management systems, data integration systems, demand chain systems,
decision support systems, document management systems, email
management systems, employee relationship management systems,
energy risk management systems, executive dashboard systems,
expense report processing systems, fleet management systems, fraud
management systems, freight management systems, human capital
management systems, human resource management systems, incentive
management systems, innovation management systems, insurance
management systems, intellectual property management systems,
intelligent storage systems, interest rate risk management systems,
investor relationship management systems, knowledge management
systems, learning management systems, location management systems,
maintenance management systems, material requirement planning
systems, metrics creation system, online analytical processing
systems, ontology management systems, partner relationship
management systems, payroll systems, performance management
systems, price optimization systems, private exchanges, process
management systems, product life-cycle management systems, project
management systems, project portfolio management systems, revenue
management systems, risk management information system, risk
simulation systems, sales force automation systems, scorecard
systems, sensor grid systems, service management systems, six-sigma
quality management systems, strategic planning systems, supply
chain systems, supplier relationship management systems, support
chain systems, taxonomy development systems, technology chain
systems, unstructured data management systems, visitor (web site)
relationship management systems, weather risk management systems,
workforce management systems, yield management systems and
combinations thereof.
108. The computer program product of claim 105 that further
comprises a plurality of intelligent agents.
109. An architecture for context aware applications, comprising an
application layer with: a data access function operable to exchange
data with a plurality of systems and to present the data to a
context modeling function through a uniform interface; a context
modeling function operable to develop a context from the data
obtained from the data access function and to present the context
to a frame function through a uniform interface; a frame function
operable to obtain a perspective from a user interface and to
develop a context frame which provides a context for the
perspective to a plurality of application in a uniform format, and
one or more applications that uses said context frame to complete
one or more useful context-aware functions.
110. The application layer of claim 109, wherein one or more
applications are selected from the group consisting of analysis,
forecast, optimization, planning, project management, review,
transaction and combinations thereof.
111. A computer program product embodied on a computer readable
medium and comprising program code for directing at least one
computer to complete processing in accordance with an architecture
for context aware computing, comprising an application layer with:
a data access function operable to exchange data with a plurality
of systems and to present the data to a context modeling function
through a uniform interface; a context modeling function operable
to develop a context from the data obtained from the data access
layer and to present the context to a frame function through a
uniform interface; a frame function operable to obtain a
perspective from a user interface and to develop a context frame
which provides a context for the perspective to a plurality of
applications in a uniform format, and one or more applications that
use said context frame to complete one or more useful context-aware
functions. where a context further comprises a complete context
that contains information that defines an impact of changes in
operation on a short term performance measure, information that
defines a social environment context and information selected from
the group consisting of information that defines a tactical
context, information that defines a physical context, information
that defines a measure context and combinations thereof.
112. The computer program product of claim 111, wherein one or more
applications are selected from the group consisting of analysis,
forecast, optimization, planning, project management, review,
transaction and combinations thereof.
Description
CROSS REFERENCE TO RELATED APPLICATIONS AND PATENTS
[0001] The subject matter of this application is related to the
subject matter of: application Ser. Nos. 09/295,337 filed Apr. 21,
1999 (now abandoned), 09/421,553 filed Oct. 20, 1999 (now
abandoned), 09/775,561 filed Feb. 5, 2001 (now abandoned),
application Ser. No. 09/678,109 filed Oct. 4, 2000, application
Ser. No. 09/938,555 filed Aug. 27, 2001 (now abandoned),
application Ser. No. 09/994,720 filed Nov. 28, 2001, application
Ser. No. 09/994,739 filed Nov. 28, 2001, application Ser. No.
10/046,316 filed Jan. 16, 2002, application Ser. No. 10/012,375
filed Dec. 12, 2001, application Ser. No. 10/025,794 filed Dec. 26,
2001, application Ser. No. 10/036,522 filed Jan. 7, 2002,
application Ser. No. 10/124,240 filed Apr. 18, 2002, application
Ser. No. 10/166,758 filed Jun. 12, 2002, U.S. Pat. No. 5,615,109
"Method of and System for Generating Feasible, Profit Maximizing
Requisition Sets, U.S. Pat. No. 6,321,205 "Method of and System for
Modeling and Analyzing Business Improvement Programs" and U.S. Pat.
No. 6,393,406 "Method and System for Business Valuation" by Jeff S.
Eder, the disclosure of which is incorporated herein by
reference.
BACKGROUND OF THE INVENTION
[0002] This invention relates to a computer based method of and
system for knowledge based performance management for any
organization with one or more quantifiable mission measures.
[0003] Leaders in business, industry and government have
collectively invested billions of dollars in a wide variety of
software systems over the last twenty years. This enormous
investment was initially focused on automating core processes such
as order management, payroll, procurement and production. In the
last several years a wide variety of analytical applications have
been developed to supplement the capabilities of the increasingly
complex systems and suites that manage core processes. As a result,
the size and cost of the information technology infrastructure in
the average organization has increased dramatically over the last
twenty years. Information technology (IT) is now the second largest
cost--after personnel--in many corporations and the average Fortune
500 firm now uses over thirty separate software systems to manage
performance. In the global marketplace there are over seventy
different types of enterprise software systems being offered to
manage a narrow slice of organization performance (hereinafter,
will be referred to as narrow systems).
[0004] The good news is that many of these separate, narrow systems
provide useful information and have become integral parts of the
organizations that they support. The bad news is that these
independent, narrow systems utilize a wide variety of languages,
platforms and technologies. This complexity has made it challenging
and expensive to integrate these systems. As a result, the number
of systems that are being integrated is limited. The limited
integration of disparate, independent systems has several negative
impacts on the effectiveness of the overall IT infrastructure
including: [0005] the ability to flexibly respond to constantly
evolving business requirements is restricted; [0006] the ability to
partner with other companies to improve quality and efficiency is
limited; [0007] the ability to analyze and manage business
performance is constrained by the functional "silos" defined by the
different systems; and [0008] the ability to transition to an
Internet-centric operating mode is compromised.
[0009] Many feel that these limitations are already responsible for
the poor financial returns a number of organizations have received
from their IT investments. A recent article in an industry trade
magazine echoed this sentiment when noting that "most businesses
are home to scores of information systems that remain uselessly
disconnected from one another. Until those systems are integrated,
technology investments won't live up to expectations." The sheer
complexity of managing and maintaining this large number of systems
is another factor contributing to poor financial returns for many
companies that have installed these systems. Another factor
contributing to the poor financial returns is the fact that the
explosive growth in the size and complexity of their information
technology systems has surpassed the ability of many companies to
organize and apply the data generated by these same systems. The
caption from a recent cartoon in the New Yorker summarized the
situation of many "we have lots of information technology . . . we
just don't have any information."
[0010] Unfortunately, the New Yorker cartoon reflects the reality
in most organizations that have mountains of digital content and
data that cannot be located, accessed or used. These mountains of
data and content contain nuggets of knowledge that have high
creation costs and high value. To date there has been no economical
way to catalog such information or provide effective ways to
search, identify, retrieve and use the valuable knowledge and
business data available on the world wide web and hidden in the
hard drives, databases, datamarts and data-warehouses of
corporations and government agencies around the globe. Examples of
the enormous waste caused by not being able to identify and
retrieve the right information at the right time are legion. The
most visible example is obviously the Sep. 11.sup.th disaster. Many
feel that if only the "FBI knew what the FBI knew" about flight
training in Phoenix and a suspected terrorist in Minnesota, then
the entire disaster could have been avoided with the consequent
savings of human life, suffering and property damage. The FBI is
not the only organization having a problem identifying and applying
all the information contained in its systems. For example, Hewlett
Packard recognizes that its knowledge about markets, products and
customers is its biggest source of competitive advantage. But
because the firm is highly decentralized, its knowledge is
dispersed across business units that have little perceived need to
share with one another. Many large hospitals and HMO's also suffer
from the same sort of diffusion of expertise and knowledge
throughout the organization. All too often, a crisis is solved
before the expert can be located. A method for organizing and
applying the knowledge that is already available would clearly help
this alleviate this problem. Many feel that business process
integration will be a cure all for many of these ills. While
business process integration is of some help, it is not a panacea
because it only replaces the vertical "functional silos" with
horizontal, "process silos".
[0011] Improving our ability to develop and apply knowledge will do
more than prevent disasters and ease crises it will also help
improve performance and create value. Value will be created in
several ways. First, the limitations on IT infrastructure
effectiveness described previously will be reduced or eliminated.
Second, support for the new collaborative approach to projects and
work that increasingly pervades the modern economy will be
increased if knowledge can be more readily shared. The head of
research from a large pharmaceutical company recently noted that
"the creation of value is coming increasingly from the
collaboration of groups . . . the point is no longer to manage the
silos, but to bring together around a problem the right group of
people with the right knowledge." The increasing amount of
partnerships that are being formed between different companies is
another force that will increase the value impact of providing a
more systematic, method for developing, storing and sharing
knowledge.
[0012] From the preceding discussion, it is clear that in an era of
data overload and increasing collaboration, we need a new approach
to get the right information to the right person and/or to the
right system at the right time. As discussed later, once a system
is in place to get the right information to the right person and/or
system at the right time new systems to process the information
will also be needed. Fortunately, these new systems will also
reduce the complexity associated with using information technology
systems to manage organization performance by an order of
magnitude.
[0013] A critical first step in defining a new approach to solving
the problem of "getting the right knowledge to the right place" is
to clearly define the terms: data, information, context and
knowledge. Data is anything that is recorded. This includes records
saved in a digital format and data stored using other means. A
subset of the digital data is structured data such as transaction
data and data stored in a database for automated retrieval. Data
that is not structured is unstructured data. Unstructured data
includes data stored in a digital format and data stored in some
other format (i.e. paper, microfilm, etc.). Information is data
plus context of unknown completeness. Knowledge is data plus
complete context. Complete context is defined as: all the
information relevant to the decision being made using the data at a
specific time. If a decision maker has data and the complete
context, then providing additional data or information that is
available at the time the decision is being made will not change
the decision that was made. If additional data or information
changes the decision, then the decision maker had "partial
context".
[0014] We will use an example to illustrate the difference between
data, partial context, complete context and knowledge. The example
is shown in Table 1 and Table 2.
TABLE-US-00001 TABLE 1 Data: We received a check for $6,000 from
Acme Tool today. Partial Context: Acme Tool owed our division
$36,000 and promised to pay the entire balance due last week. We
are due to ship them another 100 widgets next Tuesday, since we
have only 50 in the warehouse we need to start production by Friday
if we are going to meet the promised date. Decision based on data +
partial context: Stop production and have customer service put a
credit hold flag on their account, then have someone call them to
find out what their problem is.
TABLE-US-00002 TABLE 2 Data: We received a check for $6,000 from
Acme Tool today. Complete context: Acme Tool owed our division
$36,000 and promised to pay the entire balance due last week. We
are due to ship them another 100 widgets next Tuesday, since we
have only 50 in the warehouse we need to start production by Friday
if we are going to meet the promised date. Acme is a key supplier
for Project X in the international division. The international
division owes Acme over $75,000. They expected to pay Acme last
week but they are late in paying because they have had some
problems with their new e.r.p. system. Netting it all out, our
organization actually owes Acme $45,000. We have also learned that
our biggest competitor has been trying to get Acme to support their
efforts to develop a product like Project X. Decision based on
knowledge (data + complete context): See if there is anything you
can do to expedite the widget shipment. Call Acme, thank them for
the payment and see if they are OK with us deducting the money they
owe us from the money the materials division owes them. If Acme OKs
it, then call the international division and ask them to do the
paperwork to transfer the money to us so we can close this out.
The example in Tables 1 and 2 illustrates that there is a clear
difference between having data with partial context and having
knowledge. Data with partial context leads to one decision while
data with complete context creates knowledge and leads to another
completely different decision. The example also suggests another
reason (in addition to not being able to find anything) that so
many firms are not realizing the return they expect from their
investments in narrow performance management systems. Virtually
every information technology system being sold today processes and
analyzes data within the narrow silo defined by the portion of the
enterprise it supports. As a result, these systems can not provide
the complete context required to turn data into knowledge. Recently
announced products for federated data analysis do not fully address
this problem because they are not capable of developing and/or
processing all the types of information required to produce a
complete context analysis.
[0015] Another limitation of all known performance management
systems is their complete reliance on structured historical data.
The problem with this is that not all data are stored and that most
of the data that is stored is stored in an unstructured format that
is difficult to process. The most common estimate is that 80% of
the data that is stored digitally is stored in an unstructured
format. A number of products are being developed to help structure
unstructured digital data. The system of the present invention is
capable of accepting input from these systems. The system of the
present invention also has the ability to structure and process
unstructured: text data, video data, geo-coded data and web data on
its own. This leaves the problem of data that has not been stored
in any system as an area needing further development. While much of
the data that has not been stored may not be useful for performance
management, the data that resides with subject-matter experts is
potentially very valuable. In fact, as the world moves into an
increasingly uncertain environment with a growing number of
non-traditional threats and increasingly volatile weather patterns,
the need to rely on information from subject-matter experts is
expected to increase dramatically.
[0016] A method for systematically incorporating data from
subject-matter experts into knowledge based systems is clearly
needed. However, to be successful, this method needs to overcome a
few potential problems. While subject-matter experts have a great
deal of knowledge about a particular field, it is more likely than
not that: [0017] 1. they do not have any expertise in knowledge
representation, and [0018] 2. they do not have any expertise in
probability theory. As a result, the subject-matter experts may
have difficulty communicating their expertise in a manner that can
be readily processed by a data fusion analysis. While overcoming
both problems is important, solving the second problem is
particularly important because subject-matter experts involvement
is most likely to be critical in developing assessments for the
increasing number of situations that have little or no precedent,
very limited data and a consequent high degree of uncertainty.
[0019] In light of the preceding discussion, it is clear that it
would be desirable to develop methods and systems that could define
the complete context required for effectively managing performance.
The system should support individuals working alone, individuals
working in teams, teams working independently, teams working
together, organizations working alone and organizations that are
collaborating with other organizations. Ideally, this system would
be capable of reducing IT infrastructure complexity while sifting
through all the available data and incorporating newly created data
as required to define the full context for performance related
analysis and decision making. In short, the new methods and systems
should help organizations improve their performance by developing,
storing, retrieving and applying complete context knowledge in an
automated fashion.
SUMMARY OF THE INVENTION
[0020] It is a general object of the present invention to provide a
novel, useful system that develops, analyzes, stores and applies
complete context information for use in improving the performance
of any organization combination, organization or subset of an
organization with a quantifiable mission. For simplicity, we will
refer to the collection of different subsets of an organization
that can be supported by the system for knowledge based performance
management as organization levels. This new system overcomes the
limitations and drawbacks of the prior art that were described
previously.
[0021] Processing in the Knowledge Based Performance Management
System is completed in three steps: The first step in the novel
method for knowledge based performance management involves using
data provided by existing narrow systems and the nine key terms
described previously to define mission measures for each
organization level. As part of this processing data from the world
wide web. unstructured data, geo-coded data, and video data are
processed and made available for analysis. The automated
indexation, extraction, aggregation and analysis of data from the
existing, narrow computer-based systems significantly increases the
scale and scope of the analyses that can be completed by users.
This innovation also promises to significantly extend the life of
the narrow systems that would otherwise become obsolete. The system
of the present invention is capable of processing data from the
"narrow" systems listed in Table 3.
TABLE-US-00003 TABLE 3 1. Accounting systems; 2. Alliance
management systems; 3. Asset management systems; 4. Brand
management systems; 5. Budgeting/financial planning systems; 6.
Business intelligence systems; 7. Call management systems; 8. Cash
management systems; 9. Channel management systems; 10. Commodity
risk management systems; 11. Content management systems; 12.
Contract management systems; 13. Credit-risk management system 14.
Customer relationship management systems; 15. Data integration
systems; 16. Demand chain systems; 17. Decision support systems;
18. Document management systems; 19. Email management systems; 20.
Employee relationship management systems; 21. Energy risk
management systems; 22. Executive dashboard systems; 23. Expense
report processing systems; 24. Fleet management systems; 25. Fraud
management systems; 26. Freight management systems; 27. Human
capital management systems; 28. Human resource management systems;
29. Incentive management systems; 30. Innovation management
systems; 31. Insurance management systems; 32. Intellectual
property management systems; 33. Intelligent storage systems 34.
Interest rate risk management systems; 35. Investor relationship
management systems; 36. Knowledge management systems; 37. Learning
management systems; 38. Location management systems; 39.
Maintenance management systems; 40. Material requirement planning
systems; 41. Metrics creation system 42. Online analytical
processing systems; 43. Ontology management systems; 44. Partner
relationship management systems; 45. Payroll systems; 46.
Performance management systems; (for IT assets) 47. Price
optimization systems; 48. Private exchanges 49. Process management
systems; 50. Product life-cycle management systems; 51. Project
management systems; 52. Project portfolio management systems; 53.
Revenue management systems; 54. Risk management information system
55. Risk simulation systems; 56. Sales force automation systems;
57. Scorecard systems; 58. Sensor grid systems; 59. Service
management systems; 60. Six-sigma quality management systems; 61.
Strategic planning systems; 62. Supply chain systems; 63. Supplier
relationship management systems; 64. Support chain systems; 65.
Taxonomy development systems; 66. Technology chain systems; 67.
Unstructured data management systems; 68. Visitor (web site)
relationship management systems; 69. Weather risk management
systems; 70. Workforce management systems; and 71. Yield management
systems
[0022] The quantitative mission measures that are initially created
using the extracted narrow system data from each organization can
take any form (please note: a new organization could use the
Knowledge Based Performance Management System to generate the
information required to create mission measures without the use of
narrow system data). For many of the lower organization levels
(combinations being the highest level and an element being the
lowest organization level) the mission measures are simple
statistics like percentage achieving a certain score, average time
to completion and the ratio of successful applicants versus
failures. At higher levels more complicated mission measures are
generally used. For example, Table 5 shows a three part mission
measure for a medical organization mission--patient health, patient
longevity and financial break even. As discussed in the
cross-referenced patent application Ser. Nos. 10/071,164 filed Feb.
7, 2002; 10/124,240 filed Apr. 18, 2002 and 10/124,327 filed Apr.
18, 2002, commercial businesses that are publicly traded generally
require five risk adjusted measures per enterprise--a current
operation measure, a real option measure, an investment measure, a
derivatives measure and a market sentiment measure. The system of
the present invention will support the use of each of the five
measures described in the cross referenced patent applications in
an automated fashion. Also, as described in the cross-referenced
patent application Ser. Nos. (10/124,240 filed Apr. 18, 2002 and
10/124,327 filed Apr. 18, 2002) the total risk associated with
these five measures equals the risk associated with equity in the
organization. The Knowledge Based Performance Management System
will also support the automated definition of other mission
measures including: each of the different types of event risks
alone or in combination, each of the different types of factor
risks alone or in combination, cash flow return on investment,
accounting profit, and economic profit.
[0023] The system of the present invention provides several other
important advances over the systems described in these
cross-referenced applications, including: [0024] 1. the same
performance management system can be used to manage performance for
all organization levels; [0025] 2. the user is free to specify more
than five mission measures for every organization level; [0026] 3.
the user can assign a weighting to each of the different mission
measures which is different than the risk adjusted value measure;
and [0027] 4. the user is free to specify mission measures that are
different than the ones described in the prior cross-referenced
patent applications.
[0028] After the user defines the mission measures and the data
available for processing is identified, processing advances to
second stage of processing where mission-oriented context layers
for each organization level are developed and stored in a
ContextBase (60). In the final processing step the context layers
and organization levels are combined as required to develop context
frames for use in analyzing, forecasting, planning, reviewing
and/or optimizing performance using Complete Context.TM. Systems
(601, 602, 603, 604, 605, 606, 607 and 608) and closing the loop
with any remaining narrow systems as required to support Knowledge
Based Performance Management.
[0029] The system of the present invention is the first known
system with the ability to systematically develop the context
required to support the comprehensive analysis of mission
performance and turn data into knowledge. Before completing the
summary of system processing, we will provide more background
regarding mission-oriented context, context layers and the Complete
Context.TM. Systems (601, 602, 603, 604, 605, 606, 607 and
608).
[0030] The complete context for evaluating a mission performance
situation can contain up to six distinct types of information:
[0031] 1. Information that defines the physical context, i.e. we
have 50 good widgets in the warehouse available for shipment. If we
need to make more, we need to use the automated lathe and we need
to start production 2 days before we need to ship; [0032] 2.
Information that defines the tactical (aka administrative) context,
i.e. we need to ship 100 widgets to Acme by Tuesday; [0033] 3.
Information that defines the instant impact, i.e. Acme owes us
$30,000 and the price per widget is $100 and the cost of
manufacturing widgets is $80 so we make $20 profit per unit (for
most businesses this could be defined as the short term economic
context). [0034] 4. Information that defines the organizational
context, i.e. Acme is also a key supplier for the new product line,
Project X, that is expected to double our revenue over the next
five years; [0035] 5. Information that defines the mission impact,
i.e. Acme is one of our most valuable customers and they are a key
supplier to the international division, and [0036] 6. Information
that defines the social environment, i.e. our biggest competitor is
trying to form a relationship with Acme. We will refer to each
different type of information as a context layer. Different
combinations of context layers from different organization levels
and/or organizations are relevant to different decisions. Each
different combination of context layers, organization levels and
organizations is called a context frame.
[0037] The ability to rapidly create context frames can be used to
rapidly analyze a number of different operating scenarios including
an alliance with another organization or a joint exercise between
two organizations. For example, combined context frames could be
created to support the Army and the Air Force in analyzing the
short and long term implications of a joint exercise as shown in
Table 4. It is worth noting at this point that the development of a
combination frame is most effective when the two organizations
share the same mission measures.
TABLE-US-00004 TABLE 4 Context Frame From These Description
Combines These Layers Organizations JV short term Physical,
Tactical & Instant Army and Air Force JV strategic Physical,
Tactical, Instant, Army and Air Force Organization, Mission &
Social Environment
Using the context frames from the combined organizations to guide
both tactical (short-term) and strategic analysis and decision
making would allow each organization to develop plans for achieving
a common goal from the same perspective (or context) while still
maintaining independence. This capability provides a distinct
advantage over traditional analytical applications that generally
only consider the first three layers of context when optimizing
resource allocations. In taking this approach, traditional analytic
systems analyze and optimize the instant (short-term) impact given
the physical status and the tactical situation. Because these
systems generally ignore organization, mission and environmental
contexts (and some aspects of instant impact), the recommendations
they make are often at odds with common sense decisions made by
line managers that have a more complete context for evaluating the
same data. This deficiency is one reason many have noted that
"there is no intelligence in business intelligence
applications".
[0038] Before moving on to better define context, it is important
to re-emphasize the fact that the six layers of context we have
defined can also be used to support performance management,
analysis and decision making in areas other than commercial
business. In fact, the system of the present invention will measure
and help manage performance for any organization or group with a
quantifiable mission. For example, Table 5 illustrates the use of
the six layers in analyzing a sample business context and a sample
medical context.
TABLE-US-00005 TABLE 5 Business Medical (patient health &
longevity, (shareholder value maximization mission) financial break
even missions) Social Environment: competitor is trying to Social
Environment: malpractice form a relationship with Acme insurance is
increasingly costly Mission: Acme is a valuable customer and a
Mission: treatment in first week key supplier, relationship damage
will improves 5 year survival 18%, 5 year decrease returns and
increase risk reoccurrence rate is 7% higher for procedure A
Organization: Acme supports project X in Organization: Dr. X has a
commitment to international division assist on another procedure
Monday Instant: we will receive $20 profit per unit Instant:
survival rate is 99% for procedure A and 98% for procedure B
Tactical: need 100 widgets by Tuesday for Tactical: patient should
be treated next Acme, need to start production Friday week, his
insurance will cover operation Physical: 50 widgets in inventory,
automated Physical: operating room A has the lathe is available
Friday right equipment and is available Monday, Dr. X could be
available Monday
Our next step in completing the background information is to define
each context layer in more detail. Before we can do this we need to
define nine key terms: mission, element, resource, asset, agent,
action, commitment, priority and factor, that we will use in the
defining the layers. [0039] 1. Mission--purpose of organization
translated into one or more mission measures--examples: market
value, patient survival rate, and production efficiency; [0040] 2.
Element--something of value (note value may be negative) that is
related to an organization--examples: property, relationships and
knowledge; [0041] 3. Resource--subset of elements that are
routinely transferred to others and/or consumed--examples: raw
materials, products, employee time and risks; [0042] 4.
Asset--subset of elements that support the consumption, production
or transfer of resources. They are generally not transferred to
others and/or consumed--examples: brands, customer relationships;
and equipment; [0043] 5. Agent--subset of elements that can
participate in an action--examples: customers, suppliers,
salespeople. [0044] 6. Action--consumption, production, acquisition
or transfer of resources that support organization
mission--examples: sale of products and development of a new
product (actions are a subset of events which include anything that
is recorded); [0045] 7. Commitment--an obligation to perform an
action in the future--example: contract for future sale of
products; [0046] 8. Priority--relative importance assigned to
actions and mission measures; and [0047] 9. Factor--conditions
external to organization that have an impact on organization
performance--examples: commodity prices, weather, earnings
expectation. In some cases agent, element and/or action classes may
be defined by an industry organization (such as the ACORD
consortium for insurance). If this is the case, then the
pre-defined classes are used as a starting point for key term
definition. In any event, we will use the nine key terms to define
the six context layers shown below. [0048] 1. Physical
context--information about the physical status, location and
performance characteristics of elements; [0049] 2. Tactical
context--information about completed actions, action procedures,
action priorities, commitments and events; [0050] 3. Instant
context--information about the short-term impact of actions, the
short term impact of events and the expected impact of commitments;
[0051] 4. Organization context--information about the
inter-relationship between factors, elements and/or actions
(includes process maps and may be action specific); [0052] 5.
Mission context--information about the impact of elements, factors
and actions on mission measures (may be agent specific) and mission
measure priorities; and [0053] 6. Social Environment
context--information about factors in the social environment in
which the organization is completing actions (includes market
dynamics). Management can establish alert levels for data within
each layer. Management control is defined and applied at the
tactical and mission levels by assigning priorities to actions and
mission measures. Using this approach the system of the present
invention has the ability to analyze and optimize performance using
management priorities, historical measures or some combination of
the two. It is worth noting at this point that the layers may be
combined for ease of use, to facilitate processing or as
organizational requirements dictate. We will refer to the first
three layers (physical, tactical and instant) as the administrative
layers and the last three layers (organization, mission and social
environment) as the strategic layers (aka strategic business
context layers).
[0054] As discussed previously, analytical applications are
generally concerned with only the first three (3) context layers
(physical, tactical and instant). One reason for this is that the
information to define the last three layers of context
(organization, mission and social environment--the strategic
context layers) are not readily available and must be developed.
The Knowledge Based Performance Management System (100) develops
context in a manner similar to that described previously in cross
referenced application Ser. Nos. 10/071,164 filed Feb. 7, 2002;
10/124,240 filed Apr. 18, 2002 and 10/124,327 filed Apr. 18, 2002.
In the preferred embodiment, the Knowledge Based Performance
Management System works in tandem with a Business Process
Integration Platform to integrate narrow systems into a complete
system for performance management as shown in FIG. 13. However, in
an alternate mode the system would provide the functionality for
process integration in the organization tier of the software
architecture. In either mode, the system of the present invention
supports the development of the strategic context layers and the
storage of all six context layers as required to create a
mission-oriented ContextBase (60).
[0055] The creation of the mission-oriented ContextBase (60)
provides several important benefits. One of the key benefits the
mission-oriented ContextBase (60) provides is that it allows the
system of the present invention to displace the seventy plus narrow
systems with seven Complete Context.TM. Systems (601, 602, 603,
604, 605, 606 and 607) that provide more comprehensive analytical
and management capabilities. The seven Complete Context.TM. Systems
(601, 602, 603, 604, 605, 606 and 607) are briefly described below:
[0056] 1. Complete Context.TM. Analysis System (602)--analyzes the
impact of specified changes on a specific context frame. Software
to complete these analyses can reside on the application server
with user access through a browser, it can reside in an applet that
is activated as required or it can reside on a client computer with
the context frame being provided by the Knowledge Based Performance
Management System as required. Context frame information may be
supplemented by simulations and information from subject matter
experts as appropriate. Cross referenced U.S. patent application
Ser. No. 10/025,794 describes a similar client-side application for
asset and process analysis. Cross referenced U.S. patent
application Ser. No. 10/036,522 describes a similar client-side
application for risk analysis. Cross referenced U.S. patent
application Ser. No. 10/166,758 describes a similar client-side
application for purchasing analysis. Cross referenced application
Ser. Nos. 10/046,316 and 10/124,240 describe a server based system
for analyzing a multi-enterprise organization. [0057] 2. Complete
Context.TM. Forecast System (603)--forecasts the value of specified
variable(s) using data from all relevant context layers. Completes
a tournament of forecasts for specified variables and defaults to a
multivalent combination of forecasts from the tournament using
methods similar to those first described in U.S. Pat. No.
5,615,109. Software to complete these forecasts can reside on the
application server with user access through a browser, it can
reside in an applet that is activated as required or it can reside
on a client computer. [0058] 3. Complete Context.TM. Optimization
System (604)--simulates organization performance and identifies the
optimal mode for operating a specific context frame. If there is
more than one mission measure, the optimization system can use
management input or the relative levels or relevance found
historically to weight the different measures. Software to complete
these simulations and optimizations can reside on the application
server with user access through a browser, it can reside in an
applet that is activated as required or it can reside on a client
computer with the context frame being provided by the Knowledge
Based Performance Management System as required. Cross referenced
U.S. patent application Ser. No. 10/025,794 describes a similar
client-side application for asset and process optimization. Cross
referenced U.S. patent application Ser. No. 10/036,522 describes a
similar client-side application for risk optimization. Cross
referenced U.S. patent application Ser. No. 10/166,758 describes a
similar client-side application for purchasing optimization. Cross
referenced application Ser. Nos. 10/046,316 and 10/124,240 describe
a similar server based system for optimizing a multi-enterprise
organization. [0059] 4. Complete Context.TM. Planning System
(605)--system that management uses to: establish mission measure
priorities, establish action priorities, establish expected
performance levels (aka budgets) for actions, events, instant
impacts and mission measures. These priorities and performance
level expectations are saved in the corresponding layer in the
ContextBase (60). For example, mission measure priorities are saved
in the mission layer table (175). This system also supports
collaborative planning when context frames that include one or more
partners are created. Software to complete this planning can reside
on the application server with user access through a browser, it
can reside in an applet that is activated as required or it can
reside on a client computer with the context frame being provided
by the Knowledge Based Performance Management System as required.
[0060] 5. Complete Context.TM. Project (606)--system for analyzing
and optimizing the impact of a project or a group of projects on a
context frame. Software to complete these analyses and
optimizations can reside on the application server with user access
through a browser, it can reside in an applet that is activated as
required or it can reside on a client computer with the context
frame being provided by the Knowledge Based Performance Management
System as required. Context frame information may be supplemented
by simulations and information from subject matter experts as
appropriate. Cross referenced U.S. patent application Ser. No.
10/012,375 describes a similar client-side application for project
analysis and optimization. [0061] 6. Complete Context.TM. Review
System (607)--system for reviewing actions, elements, instant
impacts and mission measures. This system uses a rules engine to
transform ContextBase (60) historical information into standardized
reports that have been defined by different organizations. For
example the Financial Accounting Standards Board, International
Accounting Standards Board and Standard and Poors have each defined
standardized reports for reporting combinations of instant impacts,
elements and actions for commercial businesses--the income
statement, the balance sheet and the cash flow statement. Other
standardized, non-financial performance reports have been developed
for medical organizations, military operations and educational
institutions. The rules engine produces these reports on demand.
The software to complete these reports can reside on the
application server with user access through a browser, it can
reside in an applet that is activated as required or it can reside
on a client computer with the context frame being provided by the
Knowledge Based Performance Management System as required. [0062]
7. Complete Context.TM. Transaction System (601)--system for
recording actions and commitments into the ContextBase. The
interface for this system is a browser based template that
identifies the available physical, tactical, organization and
instant impact data for inclusion in an action transaction. After
the user has recorded a transaction the system saves the
information regarding each action or commitment to the ContextBase
(60). Other applications such as Complete Context.TM. Analysis,
Plan or Optimize can interface with this system to generate actions
or commitments in an automated fashion. The Complete Context.TM.
Systems (601, 602, 603, 604, 605, 606 and 607) can be supplemented
by a Complete Context.TM. Search Engine (608) that can help a user
(20) locate relevant information using the indices developed by
layer in the ContextBase (60). Complete Context.TM. Frames can also
be defined for any collaboration with another group or for any
subset of the organization including an individual, a team or a
division. The data for these frames can then be made available to
the user (20) or managers (21) on a continuous basis using a
portal. Each of the seven different systems can be flexibly bundled
together in any combination as required to complete the analysis,
planning and review required for Knowledge Based Performance
Management. For example, the systems for Complete Context.TM.
Review (607) , Forecast (603) and Planning (605) Systems are often
bundled together. The Complete Context.TM. Analysis and
Optimization Systems are also bundled together in a similar
fashion.
[0063] The Complete Context.TM. Systems (hereinafter, referred to
as the standard applications) can replace seventy plus narrow
systems currently being used because it takes a fundamentally
different approach to developing the information required to manage
performance. Narrow systems (30) try to develop a picture of how
part of the organization is performing. The user (20) is then left
to integrate the picture. The Knowledge Based Performance
Management System (100) develops a complete picture of how the
organization is performing, saves it in the ContextBase (60) and
then divides this picture and combines it with other pictures as
required to provide the detailed information regarding each narrow
slice of the organization These details are included in the context
frames that are produced using information in the ContextBase (60).
The context frames are then mapped to one or more standard
applications for analysis and review. Developing the complete
picture first, before dividing it and recombining it as required to
produce context frames, enables the system of the present invention
to reduce IT infrastructure complexity by an order of magnitude
while dramatically increasing the ability of each organization to
manage performance. The ability to use the same system to manage
performance for different organizational levels further magnifies
the benefits associated with the simplification enabled by the
system of the present invention. Because the ContextBase (60) is
continually updated by a "learning system", changes in organization
context are automatically captured and incorporated into the
processing and analysis completed by the Knowledge Based
Performance Management System (100).
[0064] The mission-centric focus of the ContextBase (60) provides
four other important benefits. First, by directly supporting
mission success the system of the present invention guarantees that
the ContextBase (60) will provide a tangible benefit to the
organization. Second, the mission focus allows the system to
partition the search space into two areas with different levels of
processing. Data that is known to be relevant to the mission and
data that is not thought to be relevant to mission. The system does
not ignore data that is not known to be relevant, however, it is
processed less intensely. Third, the processing completed in
ContextBase (60) development defines a complete ontology for the
organization. As detailed later, this ontology can be flexibly
matched with other ontologies as required to interact with other
organizations that have organized their information using a
different ontology and extract data from the semantic web in an
automated fashion. Finally, the focus on mission also ensures the
longevity of the ContextBase (60) as organization missions rarely
change. For example, the primary mission of each branch of the
military has changed very little over the last 100 years while the
assets, agents, resources and the social environment surrounding
that mission have obviously changed a great deal. The same can be
said for almost every corporation of any size as almost all of them
have a shareholder value maximization mission that has not changed
from the day they were founded. The difference between the
mission-oriented approach and a more generic approach to knowledge
management are summarized in Table 6A.
TABLE-US-00006 TABLE 6A Characteristic/ Mission-oriented Generic
System ContextBase (60) Knowledge Tangible benefit Built in Unknown
Search Space Partitioned by mission Un-partitioned Longevity Equal
to mission longevity Unknown
[0065] Another benefit of the novel system for knowledge based
performance management is that it can be used for managing the
performance of any entity with a quantifiable mission. It is most
powerful when used to manage an organization with different levels
and each of these levels are linked together as shown in the
following example.
[0066] In the example, summarized in Table 6B, the Marines are
interested in understanding what drove their mission performance in
a recent conflict.
TABLE-US-00007 TABLE 6B Organizational hierarchy of mission
performance drivers Marines find Division A is biggest contributor
to mission performance Division A finds Camp Pendleton training is
biggest contributor to mission performance Camp Pendleton
identifies the Sergeant Mack as biggest contributor to mission
performance
[0067] As shown in Table 6B, after using the Knowledge Based
Performance Management System they were able to determine that
Division A made the biggest contribution to their mission measure
performance. Divisions A uses the Knowledge Based Performance
Management System to determine that it was the training they
received at Camp Pendleton that made the biggest contribution to
their mission measure performance. Camp Pendleton then uses the
Knowledge Based Performance Management System to identify Sergeant
Mack as the biggest contributor to their high level of training
mission measure performance.
[0068] Using an overall system for evaluating mission performance,
each of the three performance drivers: Division A, Camp Pendleton
and Sergeant Mack would be identified. However, because their
contributions to mission performance are closely inter-related it
would be difficult to identify their separate contributions using
an overall analysis. A better use of the results from an overall
analysis in an environment where there is a hierarchy to
performance management is to ensure that there is an alignment
between the mission measures at each level. For example, if the
Camp Pendleton performance management system had identified Captain
Black as the strongest contributor, then the Camp Pendleton system
would clearly be out of alignment with the higher level measures
that identified Sergeant Mack as the strongest contributor. The
Camp Pendleton mission measures would need to be changed to bring
their performance management system into alignment with the overall
mission. Because efforts to achieve organizational alignment have
relied exclusively on management opinion and subjective measures
like scorecards, some have concluded that achieving ongoing
organizational alignment is "impossible". While it may have been
impossible, the innovative system of the present invention provides
a mechanism for establishing and maintaining alignment between
different levels of a hierarchy for any organization with a
quantifiable mission. It also provides a separate mechanism for
aligning the operation of every level of the organization in
accordance with the priorities established by the management
team.
[0069] In addition to providing the ability to systematically
analyze and improve mission performance, the Knowledge Based
Performance Management System (100) provides the ability to create
robust models of the factors that drive action, event and instant
impact levels to vary. This capability is very useful in developing
action plans to improve mission measure performance. One of the
main reasons for this is that most mission measures relate to the
long term impact of actions, events and instant impacts.
[0070] To facilitate its use as a tool for improving performance,
the system of the present invention produces reports in formats
that are graphical and highly intuitive. By combining this
capability with the previously described capabilities for: flexibly
defining robust performance measures, ensuring organizational
alignment, identifying complete context information, reducing IT
complexity and facilitating knowledge sharing, the Knowledge Based
Performance Management System gives executives and managers the
tools they need to dramatically improve the performance of any
organization with a quantifiable mission.
BRIEF DESCRIPTION OF DRAWINGS
[0071] These and other objects, features and advantages of the
present invention will be more readily apparent from the following
description of the preferred embodiment of the invention in
which:
[0072] FIG. 1 is a block diagram showing the major processing steps
of the present invention;
[0073] FIG. 2 is a diagrams showing the application layer portion
of software architecture of the present invention;
[0074] FIG. 3 is a diagram showing the tables in the application
database (50) of the present invention that are utilized for data
storage and retrieval during the processing in the innovative
system for knowledge based performance management;
[0075] FIG. 4 is a diagram showing the tables in the ContextBase
(60) of the present invention that are utilized for data storage
and retrieval during the processing in the innovative system for
knowledge based performance management;
[0076] FIG. 5 is a block diagram of an implementation of the
present invention;
[0077] FIG. 6A, FIG. 6B, FIG. 6C and FIG. 6D are block diagrams
showing the sequence of steps in the present invention used for
specifying system settings, preparing data for processing and
defining the mission measures;
[0078] FIG. 7A, FIG. 7B, FIG. 7C, FIG. 7D and FIG. 7E are block
diagrams showing the sequence of steps in the present invention
used for creating a mission-oriented ContextBase for by
organization and organization level;
[0079] FIG. 8 is a block diagram showing the sequence in steps in
the present invention used in defining and distributing context
frames and overall performance reports;
[0080] FIG. 9 is a diagram showing the data windows that are used
for receiving information from and transmitting information via the
interface (700);
[0081] FIG. 10 is a diagram showing how the enterprise risk
matrices can be combined to generate the organization matrix of
risk;
[0082] FIG. 11 is a diagram showing how the enterprise performance
matrices can be combined to generate the organization performance
matrix;
[0083] FIG. 12 is a sample report showing the efficient frontier
for Organization XYZ and the current position of XYZ relative to
the efficient frontier;
[0084] FIG. 13 is a diagram showing how the Knowledge Based
Performance Management System can be integrated with a business
process integration platform;
[0085] FIG. 14 is a block diagram shown the relationship between
different organization levels; and
[0086] FIG. 15 is a diagram showing the format of a standard
management report.
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT
[0087] FIG. 1 provides an overview of the processing completed by
the innovative system for knowledge based performance management.
In accordance with the present invention, an automated system (100)
and method for developing a mission-oriented ContextBase (60) that
contains the six context layers for each mission measure by
organization and organization level is provided. Processing starts
in this system (100) when the data extraction portion of the
application software (200) extracts data from an organization
narrow system database (5); optionally, a partner narrow system
database (10); an external database (20); and a world wide web (25)
via a network (45). Data may also be obtained from a Complete
Context.TM. Transaction System (601) via the network (45) in this
stage of processing. The processing completed by the system (100)
may be influenced by a user (20) or a manager (21) through
interaction with a user-interface portion of the application
software (700) that mediates the display, transmission and receipt
of all information to and from a browser software (800) such as the
Netscape Navigator.RTM. or the Microsoft Internet Explorer.RTM. in
an access device (90) such as a phone, personal digital assistant
or personal computer where data are entered by the user (20).
[0088] While only one database of each type (5, 10 and 20) is shown
in FIG. 1, it is to be understood that the system (100) can process
information from all narrow systems listed in Table 3 for each
organization being supported. In the preferred embodiment, all
functioning narrow systems within each organization will provide
data to the system (100) via the network (45). It should also be
understood that it is possible to complete a bulk extraction of
data from each database (5, 10 and 20) and the World Wide Web (25)
via the network (45) using peer to peer networking and data
extraction applications. The data extracted in bulk could be stored
in a single datamart, a data warehouse or a storage area network
where the analysis bots in later stages of processing could operate
on the aggregated data. A virtual database could also be used that
would leave all data in the original databases where it could be
retrieved as needed for calculations by the analysis bots over a
network (45).
[0089] The operation of the system of the present invention is
determined by the options the user (20) and manager (21) specify
and store in the application database (50) and the ContextBase
(60). As shown in FIG. 3, the application database (50) contains a
system settings table (140), a bot date table (141) and a Thesaurus
table (142).
[0090] As shown in FIG. 4, the ContextBase (60) contains tables for
storing extracted information by context layer including: a mission
measures table (170), a physical layer table (171), a tactical
layer table (172), an instant impact layer table (173), an
organization layer table (174), a mission layer table (175), a
structured data table (176), an internet linkage table (177), a
video data table (178), a social environment layer table (179), a
text data table (180), a geo data table (181), an ontology table
(182), a report table (183), an element definition table (184), a
factor definition table (185), an event risk table (186), a
scenarios table (187), an event model table (188), an impact model
table (189), a context frame table (190) and a context quotient
table (191). The ContextBase (60) can exist as a datamart, data
warehouse, a virtual repository or storage area network. The system
of the present invention has the ability to accept and store
supplemental or primary data directly from user input, a data
warehouse or other electronic files in addition to receiving data
from the databases described previously. The system of the present
invention also has the ability to complete the necessary
calculations without receiving data from one or more of the
specified databases. However, in the preferred embodiment all
required information is obtained from the specified data sources
(5, 10, 20, 601 and 25) for each organization, organization level
and organization partner.
[0091] As shown in FIG. 5, the preferred embodiment of the present
invention is a computer system (100) illustratively comprised of a
user-interface personal computer (110) connected to an
application-server personal computer (120) via a network (45). The
application-server personal computer (120) is in turn connected via
the network (45) to a database-server personal computer (130). The
user interface personal computer (110) is also connected via the
network (45) to an Internet browser appliance (90) that contains
browser software (800) such as Microsoft Internet Explorer or
Netscape Navigator.
[0092] The database-server personal computer (130) has a read/write
random access memory (131), a hard drive (132) for storage of the
application database (50) and the ContextBase (60), a keyboard
(133), a communication bus (134), a display (135), a mouse (136), a
CPU (137) and a printer (138).
[0093] The application-server personal computer (120) has a
read/write random access memory (121), a hard drive (122) for
storage of the non-user-interface portion of the enterprise section
of the application software (200, 300 and 400) of the present
invention, a keyboard (123), a communication bus (124), a display
(125), a mouse (126), a CPU (127) and a printer (128). While only
one client personal computer is shown in FIG. 3, it is to be
understood that the application-server personal computer (120) can
be networked to fifty or more client, user-interface personal
computers (110) via the network (45). The application-server
personal computer (120) can also be networked to fifty or more
server, personal computers (130) via the network (45). It is to be
understood that the diagram of FIG. 5 is merely illustrative of one
embodiment of the present invention as the system of the present
invention could reside in a single computer or be support by a
computer grid.
[0094] The user-interface personal computer (110) has a read/write
random access memory (111), a hard drive (112) for storage of a
client data-base (49) and the user-interface portion of the
application software (700), a keyboard (113), a communication bus
(114), a display (115), a mouse (116), a CPU (117) and a printer
(118).
[0095] The application software (200, 300 and 400) controls the
performance of the central processing unit (127) as it completes
the calculations required to support knowledge based performance
management. In the embodiment illustrated herein, the application
software program (200, 300 and 400) is written in a combination of
Java and C++. The application software (200, 300 and 400) can use
Structured Query Language (SQL) for extracting data from the
databases and the World Wide Web (5, 10, 20 and 25). The user (20)
and manager (21) can optionally interact with the user-interface
portion of the application software (700) using the browser
software (800) in the browser appliance (90) to provide information
to the application software (200, 300 and 400) for use in
determining which data will be extracted and transferred to the
ContextBase (60) by the data bots.
[0096] User input is initially saved to the client database (49)
before being transmitted to the communication bus (124) and on to
the hard drive (122) of the application-server computer via the
network (45). Following the program instructions of the application
software, the central processing unit (127) accesses the extracted
data and user input by retrieving it from the hard drive (122)
using the random access memory (121) as computation workspace in a
manner that is well known.
[0097] The computers (110, 120, 130) shown in FIG. 5 illustratively
are personal computers or workstations that are widely available.
Typical memory configurations for client personal computers (110)
used with the present invention should include at least 1028
megabytes of semiconductor random access memory (111) and at least
a 200 gigabyte hard drive (112). Typical memory configurations for
the application-server personal computer (120) used with the
present invention should include at least 5128 megabytes of
semiconductor random access memory (121) and at least a 300
gigabyte hard drive (122). Typical memory configurations for the
database-server personal computer (130) used with the present
invention should include at least 5128 megabytes of semiconductor
random access memory (131) and at least a 750 gigabyte hard drive
(132).
[0098] Using the system described above, data is extracted from the
narrowly focused enterprise systems, external databases and the
world wide web as required to develop a ContextBase (60), develop
context frames and manage performance. Before going further, we
need to define a number of terms that will be used throughout the
detailed description of the preferred embodiment of the Knowledge
Based Performance Management System: [0099] 1. A transaction is any
event that is logged or recorded (actions are a subset of events);
[0100] 2. Transaction data are any data related to a transaction;
[0101] 3. Descriptive data are any data related to an element,
factor, event or commitment. Descriptive data includes forecast
data and other data calculated by the system of the present
invention; [0102] 4. An element of performance (or element) is "an
entity or group that as a result of past transactions, forecasts or
other data has provided and/or is expected to benefit to one or
more organization mission measures"; [0103] 5. An item is a single
member of the group that defines an element of performance. For
example, an individual salesman would be an "item" in the "element
of performance" sales staff. It is possible to have only one item
in an element of performance; [0104] 6. Item variables are the
transaction data and descriptive data associated with an item or
related group of items; [0105] 7. Item performance indicators are
data derived from transaction data and/or descriptive data for an
item; [0106] 8. Composite variables for an element are mathematical
or logical combinations of item variables and/or item performance
indicators; [0107] 9. Element variables or element data are the
item variables, item performance indicators and composite variables
for a specific element or sub-element of performance; [0108] 10.
External factors (or factors) are numerical indicators of:
conditions external to the enterprise, conditions of the enterprise
compared to external expectations of enterprise conditions or the
performance of the enterprise compared to external expectations of
enterprise performance; [0109] 11. Factor variables are the
transaction data and descriptive data associated with external
factors; [0110] 12. Factor performance indicators are data derived
from factor transaction data and/or descriptive data; [0111] 13.
Composite factors are mathematical or logical combinations of
factor variables and/or factor performance indicators for a factor;
[0112] 14. Factor data are defined as the factor variables, factor
performance indicators and composite factors; [0113] 15. A layer is
software and/or information that gives an application, system or
layer the ability to interact with another layer, system,
application or set of information at a general or abstract level
rather than at a detailed level; [0114] 16. An organization is
defined as an entity with a mission and one or more defined,
quantified mission measures, organizations include multi-enterprise
organizations and enterprises; [0115] 17. An organization level is
defined as a subset of an organization characterized by a unique,
defined, quantifiable mission measure, organization levels include
divisions, departments, teams and individuals; [0116] 18. A value
chain is defined by two or more organizations that have joined
together to complete one or more actions; [0117] 19. A combination
is defined by two or more organizations that have joined together
to plan and/or complete one or more actions (value chains are a
subset of combinations); [0118] 20. Frames are sub-sets of an
organization level that can be analyzed separately. For example,
one frame could group together all the elements and external
factors by process allowing each process in an organization to be
analyzed by outside vendors. Another frame could exclude the one
mission measure from each enterprise within a multi-enterprise
organization. Frames can also be used to store short and long term
plan information; [0119] 21. Context frames include all information
relevant to mission measure performance for a defined combination
of context layers, organization levels and organizations. Context
frames can exist as virtual databases that point to the relevant
information in one or more databases, they can be designated by
adding tags to stored data or they can be physically established as
one or more tables within a database. In the preferred embodiment,
each context frame is a series of pointers (like a virtual
database) that are stored within a separate table; [0120] 22. Full
context frames are context frames that contain all relevant data
from the six context layers (physical, tactical, instant,
organization, mission and social environment) for a specified
organization level; [0121] 23. Administrative context frames are
context frames that contain all relevant data from the first three
context layers (physical, tactical and instant) for a specified
organization level; [0122] 24. Strategic context frames are context
frames that contain all relevant data from the last three context
layers (organization, mission and social environment) for a
specified organization level; [0123] 25. Complete Context is a
designation for applications with a context quotient of 200 that
can process full context frames; [0124] 26. ContextBase is a
database that organizes data by context layer; [0125] 27. Risk is
defined as events or variability that cause reduced performance;
[0126] 28. Total risk for an organization with publicly traded
equity is defined by the implied volatility associated with
organization equity. The amount of implied volatility can be
determined by analyzing the option prices for organization equity.
For organizations without publicly traded equity, total risk is the
sum of all variability risks and event risks; [0127] 29.
Variability risk is a subset of total risk. It is the risk of
reduced or impaired performance caused by variability in external
factors and/or elements of performance. Variability risk is
generally quantified using statistical measures like standard
deviation per month, per year or over some other time period. The
covariance between different variability risks is also determined
as simulations require quantified information regarding the
inter-relationship between the different risks to perform
effectively; [0128] 30. Factor variability (or factor variability
risk) is a subset of variability risk. It is the risk of reduced
performance caused by external factor variability; [0129] 31.
Element variability (or element variability risk) is a subset of
variability risk. It is the risk of reduced performance caused by
the variability of an element of performance; [0130] 32. Base
market risk is a subset of factor variability risk for an
organization with publicly traded equity. It is defined as the
implied variability associated with a portfolio that represents the
market. For example, the S&P 500 can be used in the U.S. and
the FTSE 100 can be used in the U.K. The implied amount of this
variability can be determined by analyzing the option prices for
the portfolio; [0131] 33. Industry market risk is a subset of
factor variability risk for an organization with publicly traded
equity. It is defined as the implied variability associated with a
portfolio that is in the same SIC code as the
organization--industry market risk can be substituted for base
market risk in order to get a clearer picture of the market risk
specific to stock for an organization; [0132] 34. Market volatility
is a subset of total risk for an organization with publicly traded
equity. It is defined as the difference between market variability
risk and the calculated values of: base market risk, factor
variability, element variability, event risk (includes strategic
event risk and contingent liabilities) over a given time period;
[0133] 35. Event risk is a subset of total risk. It is the risk of
reduced performance caused by an event. Most insurance policies
cover event risks. For example, an insurance policy might state
that: if this event happens, then we will reimburse event related
expenses up to a pre-determined amount. Other event risks including
customer defection, employee resignation and supplier bankruptcy
are generally overlooked by traditional risk management systems;
[0134] 36. Standard event risk is a subset of event risk. It is the
risk associated with events that have a one time impact; [0135] 37.
Extreme event risk is a subset of event risk. It is the risk
associated with events that have a one time impact three or more
standard deviations above the average impact for an event; [0136]
38. Contingent liabilities are a subset of event risk. They are
liabilities the organization may have at some future date where the
liability is contingent on some event occurring in the future,
therefore they can be considered as a type of event risk. They are
different from standard event risks in that the amount of "damage"
is often defined contractually and is known in advance. Many feel
that the bankruptcy of Enron was triggered by a contingent
liability from one of the infamous "off balance sheet entities".
The system of the present invention quantifies contingent
liabilities for all organization levels--even if the liability
comes from a entity that isn't on the balance sheet--a distinct
advantage over current financial systems; [0137] 39. Strategic risk
(or strategic event risk) is a subset of event risk. It is the risk
associated with events that can have a permanent impact on the
performance of an enterprise or organization. Examples of strategic
risk would include: the risk that a large new competitor enters the
market and the risk that a new technology renders existing products
obsolete; [0138] 40. Real options are defined as options the
organization may have to make a change in its operation at some
future date--these can include the introduction of a new product,
the ability to shift production to lower cost environments, etc.
Real options are generally supported by the elements of performance
of an organization; [0139] 41. Narrow systems are the systems
listed in Table 3 and any other system that supports the analysis,
measurement or management of an element, event, commitment or
priority of an organization or enterprise; and [0140] 42. The
efficient frontier is the curve defined by the maximum performance
the organization can expect for given levels of risk. We will use
the terms defined above when detailing the preferred embodiment of
the present invention. In this invention, analysis bots are used to
determine element of performance lives and the percentage of
mission measure performance that is attributable to each element of
performance organization level. The resulting values are then added
together to determine the contribution of each element of
performance to the mission performance at each organization level.
External factor contributions and risk impacts are calculated in a
similar manner, however, they generally do not have defined
lives.
[0141] As discussed previously, the Knowledge Based Performance
Management System completes processing in three distinct stages. As
shown in FIG. 6A, FIG. 6B, FIG. 6C and FIG. 6D the first stage of
processing (block 200 from FIG. 1) extracts data, defines mission
measures and prepares data for the next stage of processing. As
shown in FIG. 7A, FIG. 7B, FIG. 7C, FIG. 7D and FIG. 7E the second
stage of processing (block 300 from FIG. 1) develops and then
continually updates the mission-oriented ContextBase (60) by
organization and organization level. As shown in FIG. 8, in the
third and final stage of processing (block 400 from FIG. 1)
prepares context frames for use by the standard applications and
optionally prepares and print reports. If the operation is
continuous, then the processing described above is continuously
repeated.
Mission Measure Specification
[0142] The flow diagram in FIG. 6A, FIG. 6B, FIG. 6C and FIG. 6D
details the processing that is completed by the portion of the
application software (200) that establishes a virtual database for
data from other systems that is available for processing, prepares
unstructured data for processing and accepts user (20) and
management (21) input as required to define the mission measures
for each organization level. As discussed previously, the system of
the present invention is capable of accepting data from all the
narrowly focused systems listed in Table 3. Data extraction,
processing and storage is completed by organization and
organization level. Operation of the system (100) will be
illustrated by describing the extraction and use of structured data
from a narrow system database (5) for supply chain management and
an external database (20). A brief overview of the information
typically obtained from these two databases will be presented
before reviewing each step of processing completed by this portion
(200) of the application software.
[0143] Supply chain systems are one of the seventy plus narrow
systems identified in Table 3. Supply chain databases are a type of
narrow system database (5) that contain information that may have
been in operation management system databases in the past. These
systems provide enhanced visibility into the availability of
resources and promote improved coordination between organizations
and their suppliers. All supply chain systems would be expected to
track all of the resources ordered by an organization after the
first purchase. They typically store information similar to that
shown below in Table 7.
TABLE-US-00008 TABLE 7 Supply chain system information 1. Stock
Keeping Unit (SKU) 2. Vendor 3. Total quantity on order 4. Total
quantity in transit 5. Total quantity on back order 6. Total
quantity in inventory 7. Quantity available today 8. Quantity
available next 7 days 9. Quantity available next 30 days 10.
Quantity available next 90 days 11. Quoted lead time 12. Actual
average lead time
[0144] External databases (20) are used for obtaining information
that enables the definition and evaluation of elements of
performance, external factors and event risks. In some cases,
information from these databases can be used to supplement
information obtained from the other databases and the Internet (5
and 10). In the system of the present invention, the information
extracted from external databases (20) includes the data listed in
Table 8.
TABLE-US-00009 TABLE 8 External database information 1. Text
information such as that found in the Lexis Nexis database; 2. Text
information from databases containing past issues of specific
publications, 3. Geospatial data; 4. Multimedia information such as
video and audio clips; and 5. Event risk data including information
about risk probability and magnitude
[0145] System processing of the information from the different
databases (5, 10 and 20) and the World Wide Web (25) described
above starts in a block 202, FIG. 6A. The software in block 202
prompts the user (20) via the system settings data window (701) to
provide system setting information. The system setting information
entered by the user (20) is transmitted via the network (45) back
to the application-server (120) where it is stored in the system
settings table (140) in the application database (50) in a manner
that is well known. The specific inputs the user (20) is asked to
provide at this point in processing are shown in Table 9.
TABLE-US-00010 TABLE 9* 1. Continuous, If yes, new calculation
frequency? (by minute, hour, day, week, etc.) 2. Organization(s)
(can include partners) 3. Organization structure(s) (organization
levels, combinations) 4. Organization industry classification(s)
(SIC Code) 5. Names of primary competitors by SIC Code 6. Base
account structure 7. Base units of measure 8. Base currency 9.
Knowledge capture from subject matter expert? (yes or no) 10. Event
models? (yes or no) 11. Instant impact models? (yes or no) 12.
Video data extraction? (yes or no 13. Internet data extraction?
(yes or no) 14. Text data analysis? (if yes, then specify maximum
number of relevant words) 15. Geo-coded data? (if yes, then specify
standard) 16. Maximum number of generations to process without
improving fitness 17. Maximum number of clusters (default is six)
18. Management report types (text, graphic or both) 19. Missing
data procedure (chose from selection) 20. Maximum time to wait for
user input 21. Maximum number of sub elements 22. Most likely
scenario, normal, extreme or mix (default is normal) 23. Simulation
time periods 24. Risk free interest rate 25. Date range for
history-forecast time periods (optional) 26. Minimum working
capital level (optional) *settings over 4 for each organization
level (if different)
[0146] The system settings data are used by the software in block
202 to establish organization levels and context layers. As
described previously, there are six context layers for each
organization level. The application of the remaining system
settings will be further explained as part of the detailed
explanation of the system operation. The software in block 202 also
uses the current system date to determine the time periods
(generally in months) that require data to complete the
calculations. In the preferred embodiment the analysis of
organization level performance by the system utilizes data from
every data source for the four year period before and the three
year forecast period after the date of system calculation. The user
(20) also has the option of specifying the data periods that will
be used for completing system calculations. After the date range is
calculated it is stored in the system settings table (140) in the
application database (50), processing advances to a software block
203.
[0147] The software in block 203 prompts the user (20) via the
organization layer data window (702) to define the different
organization levels, define process maps, identify the elements and
factors relevant to each organization level and graphically depict
the relationship between the different organization levels that
were saved in the system settings (140). For example, an
organization could have two enterprises with each enterprise having
three departments as shown in FIG. 14. In the case shown in FIG. 14
there would be nine organization levels as shown in Table 10.
TABLE-US-00011 TABLE 10 Organization Level Location in example
hierarchy 1. Organization Highest Level 2. Enterprise A Middle
Level 3. Enterprise A - Department 100 Lowest Level 4. Enterprise A
- Department 200 Lowest Level 5. Enterprise A - Department 300
Lowest Level 6. Enterprise B Middle Level 7. Enterprise B -
Department 101 Lowest Level 8. Enterprise B - Department 201 Lowest
Level 9. Enterprise B - Department 301 Lowest Level
[0148] In the system of the present invention an item within an
element of performance is the lowest organization level. The
organization level and process map relationships identified by the
user (20) are stored in the organization layer table (174) in the
ContextBase (60). It is also possible to obtain the organization
layer information directly from narrow system input. The element
and factor definitions by organization level are stored in the
element definition table (184) and the factor definition table
(185) in the ContextBase (60) After the data is stored, processing
advances to a software block 204.
[0149] The software in block 204 communicates via a network (45)
with the different databases (5, 10, and 20) that are providing
data to the Knowledge Based Performance Management System. As
described previously, a number of methods can be used to identify
the different data sources and make the information available for
processing including bulk data extraction and point to point data
extraction using bots or ETL (extract, test and load) utilities.
Data from the lower levels of the hierarchy are automatically
included in the context layers for the higher organization levels.
In the preferred embodiment the systems providing data are
identified using UDDI protocols. The databases in these systems (5,
10 and 20) use XML tags that identify the organization level,
context layer, element assignment and/or factor association for
each piece of data. In this stage of processing the software in
block 204 stores the location information for the data of interest
as required to establish a virtual database for the administrative
layers for each organization level that was specified in the system
settings table (140). Establishing a virtual database eliminates
the latency that can cause problems for real time processing. The
virtual database information for the physical layer for each
organization level is stored in the physical layer table (171) in
the ContextBase (60). The virtual database information for the
tactical layer for each organization level is stored in the
tactical layer table (172) in the ContextBase (60). The virtual
database information for the instant layer for each organization
level is stored in the instant impact layer table (173) in the
ContextBase (60). Structured data that was made available for
processing that could not be mapped to an administrative context
layer, organization level, factor and/or element is stored in the
structured data table (176) in the Context Base (60). World Wide
Web data that needs to be processed before being mapped to a
context layer, organization level, factor and/or element are
identified using a virtual database stored in the Internet data
table (177) in the ContextBase (60). Video data that needs to be
processed before being mapped to a context layer, organization
level, factor and/or element are identified using a virtual
database stored in the video data table (178) in the ContextBase
(60). Unstructured text data that needs to be processed before
being mapped to a context layer, organization level, factor and/ or
element are identified using a virtual database stored in the text
data table (180) in the ContextBase (60). Geo-coded data that needs
to be processed before being mapped to a context layer,
organization level, factor and/ or element are identified using a
virtual database stored in the geo data table (181) in the
ContextBase (60). In all cases, data from narrow partner system
databases (10) can be extracted and stored in a manner similar to
that described for organization narrow system data. This data can
include feature designations that define the acceptable range for
data that are changed during optimization calculations. After
virtual databases have been created that fully account for all
available data from the databases (5, 10 and 20) and the World Wide
Web (25), processing advances to a software block 205 and then on
to a software block 210.
[0150] The software in block 210 prompts the user (20) via the
review data window (703) to review the elements and factors by
context layer that have been identified in the first few steps of
processing. The element--context layer assignments and the
factor--context layer assignments were created by mapping data to
their "locations" within the ContextBase (60) using xml tag
designations. The user (20) has the option of changing these
designations on a one time basis or permanently. Any changes the
user (20) makes are stored in the table for the corresponding
context layer (i.e. tactical layer changes are saved in the
tactical layer table (172), etc.). As part of the processing in
this block, the user (20) is given the option to establish data
categories for each context layer using an interactive GEL
algorithm that guides the process of category development. The
newly defined categories are mapped to the appropriate data in the
appropriate context layer and stored in the organization layer
table (174) in the ContextBase (60). The user (20) is also prompted
by the review data window (703) to use data and/or the newly
created data categories from each context layer to define six of
the nine key terms--element, agent, asset, resource, action and
commitment (mission measures and priorities will be defined in the
next step) for each organization level. The resulting definitions
are saved in the key terms table (170) in the ContextBase (60) by
organization and organization level. Finally, the user (20) is
prompted to define transaction data that do not correspond to one
of the six key terms. For example, transaction data may relate to a
cell phone call or an email--both events that are not defined as
actions for the current organization level. The user (20) will
define these events using standardized definitions from a Thesaurus
table (142) in the application database (50) with synonyms that
match business concepts like "transfer", "return" and "expedite" as
required to define each transaction. The new definitions are also
stored in the key terms table (170) in the ContextBase (60) before
processing advances to a software block 215.
[0151] The software in block 215 prompts the manager (21) via the
mission measure data window (704) to use the key term definitions
established in the prior processing step to specify one or more
mission measures for each organization level. As discussed
previously, the manager (21) is given the option of using
pre-defined mission measures for evaluating the performance of a
commercial organization or defining new mission measures using
internal and/or external data. If more than one mission measure is
defined for a given organization level, then the manager (21) is
prompted to assign a weighting or relative priority to the
different mission measures that have been defined. The software in
this block also prompts the manager (21) to identify keywords that
are relevant to mission performance for each organization level in
each organization. After the mission measure definitions are
completed, the value of the newly defined mission measures are
calculated using historical data and forecast data and stored in
the mission layer table (175) by organization and organization
level. After this has been completed, the mission measure
definitions, priorities and keywords are stored in the key terms
table (170) in the ContextBase (60) by organization and
organization level before processing advances to a software block
231.
[0152] The software in block 231 checks the structured data table
(176) in the ContextBase (60) to see if there is any structured
data that has not been assigned to an organization level and/or
context layer. If there is no structured data without a complete
assignment (organization, organization level, context layer and
element or factor assignment constitutes a complete assignment),
then processing advances to a software block 232. Alternatively, if
there are structured data without an assignment, then processing
advances to a software block 235.
[0153] The software in block 235 prompts the manager (21) via the
identification and classification data window (705) to identify the
context layer, organization level, element assignment or factor
assignment for the structured data in table 176. After assignments
have been specified for every data element, the resulting
assignment are stored in the appropriate context layer table in the
ContextBase (60) by organization and organization level before
processing advances to a software block 232.
[0154] The software in block 232 checks the system settings table
(140) in the Application Database (50) to see if video data
extraction is going to be used in the current analysis. If video
data extraction is not being used, then processing advances to a
software block 236. Alternatively, if video data extraction is
being used, then processing advances to a software block 233.
[0155] The software in block 233 extracts text from the video data
stored in the video data table (178) and stores the resulting text
in the text table (180) in the ContextBase (60). The information in
the video comes in two parts, the narrative associated with the
image and the image itself. In the preferred embodiment, the
narrative portion of the video has been captured in captions. These
captions along with information identifying the time of first
broadcast are stored in the text table (180). This same procedure
can also be used for capturing data from radio broadcasts. If
captions are not available, then any of a number of commercially
available voice recognition programs can be used to create text
from the narratives. The image portion of the video requires
conversion. The conversion of video into text requires the use of
several conversion algorithms and a synthesis of the results from
each of the different algorithms using a data fusion algorithm. The
algorithms used for video conversion include: coefficient energy
block classification, local stroke detection and merge and
graphics/text block classification. Again, the resulting text
information along with information identifying the time of first
broadcast are stored in the text table (180) before processing
advances to a software block 236.
[0156] The software in block 236 checks the system settings table
(140) in the Application Database (50) to see if internet data
extraction is going to be used in the current analysis. If internet
data extraction is not being used, then processing advances to a
software block 241. Alternatively, if internet data extraction is
being used, then processing advances to a software block 237.
[0157] The software in block 237 checks the bot date table (141)
and deactivates internet text and linkage bots with creation dates
before the current system date and retrieves information from the
key terms table (180). The software in block 237 then initializes
text bots for each keyword stored in the key terms table. The bots
are programmed to activate with the frequency specified by user
(20) in the system settings table (140).
[0158] Bots are independent components of the application that have
specific tasks to perform. In the case of internet text and linkage
bots, their tasks are to locate and extract keyword matches and
linkages from the World Wide Web (25) and then store the extracted
text in the text data table (180) and the linkages in the internet
linkages table (177) in the ContextBase (60). Every Internet text
and linkage bot contains the information shown in Table 11.
TABLE-US-00012 TABLE 11 1. Unique ID number (based on date, hour,
minute, second of creation) 2. Creation date (date, hour, minute,
second) 3. Storage location 4. Mapping information 5. Home URL 6.
Linkage URL (if any) 7. Organization 8. Organization Level 9.
Keyword
After being initialized, the text and linkage bots locate, extract
and store text and linkages from the World Wide Web (25) in
accordance with their programmed instructions with the frequency
specified by user (20) in the system settings table (140). These
bots will continually extract data as system processing advances a
software block 241.
[0159] The software in block 241 checks the system settings table
(140) to see if text data analysis is being used. If text data
analysis is not being used, then processing advances to a block
246. Alternatively, if the software in block 241 determines that
text data analysis is being used, processing advances to a software
block 242.
[0160] The software in block 242 checks the bot date table (141)
and deactivates text relevance bots with creation dates before the
current system date and retrieves information from the system
settings table (140), the key terms table (170) and the text data
table (180). The software in block 242 then initializes text
relevance bots to activate with the frequency specified by user
(20) in the system settings table (140). Bots are independent
components of the application that have specific tasks to perform.
In the case of text relevance bots, their tasks are to calculate a
relevance measure for each word in the text data table (180) and to
identify the type of word (Name, Proper Name, Verb, Adjective,
Complement, Determinant or Other). The relevance of each word is
determined by calculating a relevance measure using the formula
shown in Table 12.
TABLE-US-00013 TABLE 12 Relevance (word) = N (nm' - n'm)/ (n +
n')(n + m)(n' + m')(m + m') where N = total number of phrases (n +
n' + m + m') n = number of relevant phrases where word appears n' =
number of irrelevant phrases where word appears m = number of
relevant phrases where word does not appear m' = number of
irrelevant phrases where word does not appear Note: relevance is
determined by the presence of a keyword in a phrase.
One advantage of this approach is that it takes into account the
fact that text is generally a sequence of words and not just a "bag
of words". The type of word is determined by using a probabilistic
speech tagging algorithm. If the amount of text that needs
processing is very large, then a multi layer neural net can be used
to sort the text into blocks that should be processed and those
that should not. Every text relevance bot contains the information
shown in Table 13.
TABLE-US-00014 TABLE 13 1. Unique ID number (based on date, hour,
minute, second of creation) 2. Creation date (date, hour, minute,
second) 3. Mapping information 4. Storage location 5. Organization
6. Organization Layer 7. Word
After being activated, the text relevance bots determine the
relevance and type of each word with the frequency specified by the
user (20) in the system settings table (140). The relevance of each
word is stored in the text data table (180) before processing
passes to a software block 244.
[0161] The software in block 244 checks the bot date table (141)
and deactivates text association bots with creation dates before
the current system date and retrieves information from the system
settings table (140), the tactical layer table (172), the instant
impact layer table (173), the mission measure table (175), the text
table (180), the element definition table (184) and the factor
definition table (185). The software in block 244 then initializes
text association bots for the words identified in the prior stage
of processing in order of relevance up to the maximum number for
each organization (the user (20) specified the maximum number of
keywords in the system settings table). Bots are independent
components of the application that have specific tasks to perform.
In the case of text association bots, their tasks are to determine
which element or factor the relevant words are most closely
associated with. Every bot initialized by software block 244 will
store the association it discovers with the most relevant words
stored in the text data table (180). Every text association bot
contains the information shown in Table 14.
TABLE-US-00015 TABLE 14 1. Unique ID number (based on date, hour,
minute, second of creation) 2. Creation date (date, hour, minute,
second) 3. Storage location 4. Organization 5. Organization Level
6. Word
After being initialized, the bots identify the element or factor
that each word is most closely associated with and stores the
association "assignment" in the text data table (180) and the
element definition table (184) or factor definition table (185) in
the ContextBase (60) before processing advances to a software block
245.
[0162] The software in block 245 prompts the user (20) via the
review data window (703) to review the associations developed in
the prior step in processing. Options the user (20) can choose for
modifying the associations include: changing the association to
another element or factor, removing the assigned association, or
adding an association to one or more other elements or factors.
When all the user (20) completes the review of the assignments, all
changes are stored in the text data table (180), the element
definition table (184) and/or the factor definition table (185)
before system processing advances to a software block 246.
[0163] The software in block 246 checks the system settings table
(140) in the Application Database (50) to see if geo-coded data is
going to be used in the current analysis. If geo-coded data is not
being used, then processing advances to a software block 251.
Alternatively, if geo-coded data is being used, then processing
advances to a software block 247.
[0164] The software in block 247 retrieves the data stored in the
geo table (181), converts the data in accordance with applicable
geo-coding standard, calculates pre-defined attributes and stores
the resulting data in the physical context layer table (171) by
element or factor in the ContextBase (60) before processing
advances to software block 251.
[0165] The software in block 251 checks each of the administrative
context layer tables--the physical layer table (171), the tactical
layer table (172) and the instant impact layer table (173)--and the
social environment layer table (179) in the ContextBase (60) to see
if data is missing for any required time period. If data is not
missing for any required time period, then processing advances to a
software block 256. Alternatively, if data for one or more of the
required time periods is missing for one or more of the
administrative context layers, then processing advances to a
software block 255.
[0166] The software in block 255 prompts the user (20) via the
review data window (703) to specify the method to be used for
filling the blanks for each field that is missing data. Options the
user (20) can choose for filling the blanks include: the average
value for the item over the entire time period, the average value
for the item over a specified period, zero, the average of the
preceding item and the following item values and direct user input
for each missing item. If the user (20) does not provide input
within a specified interval, then the default missing data
procedure specified in the system settings table (140) is used.
When all the blanks have been filled and stored for all of the
missing data, system processing advances to a block 256.
[0167] The software in block 256 calculates pre-defined attributes
by item for each numeric, item variable in each of the
administrative context layer tables--the physical layer table
(171), the tactical layer table (172) or the instant impact layer
table (173)--in the ContextBase (60) by element. The attributes
calculated in this step include: summary data like cumulative total
value; ratios like the period to period rate of change in value;
trends like the rolling average value, comparisons to a baseline
value like change from a prior years level and time lagged values
like the time lagged value of each numeric item variable. The
software in block 256 also derives attributes for each item date
variable in each of the administrative context layer tables (171,
172 and 173) in the ContextBase (60). The derived date variables
include summary data like time since last occurrence and cumulative
time since first occurrence; and trends like average frequency of
occurrence and the rolling average frequency of occurrence. The
software in block 256 derives similar attributes for the text and
geospatial item variables stored in the administrative context
layer tables--the physical layer table (171), the tactical layer
table (172) or the instant impact layer table (173)--by element.
The numbers derived from the item variables are collectively
referred to as "item performance indicators". The software in block
256 also calculates pre-specified combinations of variables called
composite variables for measuring the strength of the different
elements of performance. The item performance indicators and the
composite variables are tagged and stored in the appropriate
administrative context layer table--the physical layer table (171),
the tactical layer table (172) or the instant impact layer table
(173)--by element and organization level before processing advances
to a software block 257.
[0168] The software in block 257 uses attribute derivation
algorithms such as the AQ program to create combinations of
variables from the administrative context layer tables--the
physical layer table (171), the tactical layer table (172) or the
instant impact layer table (173)--that were not pre-specified for
combination in the prior processing step. While the AQ program is
used in the preferred embodiment of the present invention, other
attribute derivation algorithms, such as the LINUS algorithms, may
be used to the same effect. The resulting composite variables are
tagged and stored in the appropriate administrative context layer
table--the physical layer table (171), the tactical layer table
(172) or the instant impact layer table (173)--in the ContextBase
(60) by element before processing advances to a software block
260.
[0169] The software in block 260 derives external factor indicators
for each factor numeric data field stored in the social environment
layer table (179). For example, external factors can include: the
ratio of enterprise earnings to expected earnings, the number and
amount of jury awards, commodity prices, the inflation rate, growth
in gross domestic product, enterprise earnings volatility vs.
industry average volatility, short and long term interest rates,
increases in interest rates, insider trading direction and levels,
industry concentration, consumer confidence and the unemployment
rate that have an impact on the market price of the equity for an
enterprise and/or an industry. The external factor indicators
derived in this step include: summary data like cumulative totals,
ratios like the period to period rate of change, trends like the
rolling average value, comparisons to a baseline value like change
from a prior years price and time lagged data like time lagged
earnings forecasts. In a similar fashion the software in block 260
calculates external factors for each factor date field in the
social environment layer table (179) including summary factors like
time since last occurrence and cumulative time since first
occurrence; and trends like average frequency of occurrence and the
rolling average frequency of occurrence. The numbers derived from
numeric and date fields are collectively referred to as "factor
performance indicators". The software in block 260 also calculates
pre-specified combinations of variables called composite factors
for measuring the strength of the different external factors. The
factor performance indicators and the composite factors are tagged
and stored in the social environment layer table (179) by factor
and organization level before processing advances to a block
261.
[0170] The software in block 261 uses attribute derivation
algorithms, such as the Linus algorithm, to create combinations of
the external factors that were not pre-specified for combination in
the prior processing step. While the Linus algorithm is used in the
preferred embodiment of the present invention, other attribute
derivation algorithms, such as the AQ program, may be used to the
same effect. The resulting composite variables are tagged and
stored in the in the social environment layer table (179) by factor
and organization level before processing advances to a block
262.
[0171] The software in block 262 checks the bot date table (141)
and deactivates pattern bots with creation dates before the current
system date and retrieves information from the system settings
table (140), the physical layer table (171), the tactical layer
table (172), the instant impact layer table (173) and the social
environment layer table (179).
[0172] The software in block 262 then initializes pattern bots for
each layer to identify frequent patterns in each layers. Bots are
independent components of the application that have specific tasks
to perform. In the case of pattern bots, their tasks are to
identify and frequent patterns in the data for each context layer,
element, factor and organization level. In the preferred
embodiment, pattern bots use the Apriori algorithm to identify
patterns including frequent patterns, sequential patterns and
multi-dimensional patterns. However, a number of other pattern
identification algorithms including the PASCAL algorithm can be
used alone or in combination to the same effect. Every pattern bot
contains the information shown in Table 15.
TABLE-US-00016 TABLE 15 1. Unique ID number (based on date, hour,
minute, second of creation) 2. Creation date (date, hour, minute,
second) 3. Storage location 4. Organization 6. Context Layer,
Element, Factor or Organization level 7. Algorithm
After being initialized, the bots identify patterns in the data by
element, factor, layer or organization level. Each pattern is given
a unique identifier and the frequency and type of each pattern is
determined. The numeric values associated with the patterns are
item performance indicators. The values are stored in the
appropriate context layer table by element or factor. When data
storage is complete, processing advances to a software block
303.
ContextBase Development
[0173] The flow diagrams in FIG. 7A, FIG. 7B, FIG. 7C, FIG. 7D and
FIG. 7E detail the processing that is completed by the portion of
the application software (300) that continually develops a mission
oriented ContextBase (60) by creating and activating analysis bots
that: [0174] 1. Supplement the organization layer information
provided previously by identifying inter-relationships between the
different elements of performance, external factors and risks;
[0175] 2. Complete the mission measure layer of the ContextBase
(60) by developing robust models of the elements, factors and risks
driving mission measure performance; [0176] 3. Optionally, develop
robust models of the elements, factors and risks driving action
occurrence rates; [0177] 4. Optionally, develop robust models of
the elements, factors and risks causing instant impact levels to
vary, and [0178] 5. Combine the mission measure analyses by
organization and organization level as required to evaluate
strategic alignment and determine the relationship between the
mission measures and mission performance.
[0179] Each analysis bot generally normalizes the data being
analyzed before processing begins. As discussed previously,
processing in the preferred embodiment includes an analysis of all
mission measures by organization and organization level. It is to
be understood that the system of the present invention can combine
any number of mission measures as required to evaluate the
performance of any organization level.
[0180] Processing in this portion of the application begins in
software block 301. The software in block 301 checks the mission
layer table (175) in the ContextBase (60) to determine if there are
current models for all mission measures for every organization
level. If all the mission measure models are current, then
processing advances to a software block 321. Alternatively, if all
mission measure models are not current, then the next mission
measure for the next organization level is selected and processing
advances to a software block 303. The software in block 303
retrieves the previously calculated values for the mission measure
from the mission layer table (175) before processing advances to a
software block 304.
[0181] The software in block 304 checks the bot date table (141)
and deactivates temporal clustering bots with creation dates before
the current system date. The software in block 304 then initializes
bots in accordance with the frequency specified by the user (20) in
the system settings table (140). The bot retrieves information from
the mission layer table (175) for the organization level being
analyzed and defines regimes for the mission measure being analyzed
before saving the resulting cluster information in the mission
layer table (175) in the ContextBase (60). Bots are independent
components of the application that have specific tasks to perform.
In the case of temporal clustering bots, their primary task is to
segment mission measure performance into distinct time regimes that
share similar characteristics. The temporal clustering bot assigns
a unique identification (id) number to each "regime" it identifies
before tagging and storing the unique id numbers in the mission
layer table (175). Every time period with data are assigned to one
of the regimes. The cluster id for each regime is saved in the data
record for the mission measure and organization level being
analyzed. The time regimes are developed using a competitive
regression algorithm that identifies an overall, global model
before splitting the data and creating new models for the data in
each partition. If the error from the two models is greater than
the error from the global model, then there is only one regime in
the data. Alternatively, if the two models produce lower error than
the global model, then a third model is created. If the error from
three models is lower than from two models then a fourth model is
added. The process continues until adding a new model does not
improve accuracy. Other temporal clustering algorithms may be used
to the same effect. Every temporal clustering bot contains the
information shown in Table 16.
TABLE-US-00017 TABLE 16 1. Unique ID number (based on date, hour,
minute, second of creation) 2. Creation date (date, hour, minute,
second) 3. Mapping information 4. Storage location 5. Maximum
number of clusters 6. Organization 7. Organization Level 8. Mission
Measure
When bots in block 304 have identified and stored regime
assignments for all time periods with mission measure data for the
current organization, processing advances to a software block
305.
[0182] The software in block 305 checks the bot date table (141)
and deactivates variable clustering bots with creation dates before
the current system date. The software in block 305 then initializes
bots as required for each element of performance and external
factor for the current organization level. The bots activate in
accordance with the frequency specified by the user (20) in the
system settings table (140), retrieve the information from the
physical layer table (171), the tactical layer table (172), the
instant impact layer table (173), the social environment layer
table (179), the element definition table (184) and/or the factor
definition table (185) as required and define segments for the
element data and factor data before tagging and saving the
resulting cluster information in the element definition table (184)
or the factor definition table (185).
[0183] Bots are independent components of the application that have
specific tasks to perform. In the case of variable clustering bots,
their primary task is to segment the element data and factor data
into distinct clusters that share similar characteristics. The
clustering bot assigns a unique id number to each "cluster" it
identifies, tags and stores the unique id numbers in the element
definition table (184) and factor definition table (185). Every
item variable for every element of performance is assigned to one
of the unique clusters. The cluster id for each variable is saved
in the data record for each variable in the table where it resides.
In a similar fashion, every factor variable for every external
factor is assigned to a unique cluster. The cluster id for each
variable is tagged and saved in the data record for the factor
variable. The element data and factor data are segmented into a
number of clusters less than or equal to the maximum specified by
the user (20) in the system settings table (140). The data are
segmented using the "default" clustering algorithm the user (20)
specified in the system settings table (140). The system of the
present invention provides the user (20) with the choice of several
clustering algorithms including: an unsupervised "Kohonen" neural
network, decision tree, support vector method, K-nearest neighbor,
expectation maximization (EM) and the segmental K-means algorithm.
For algorithms that normally require the number of clusters to be
specified, the bot will use the maximum number of clusters
specified by the user (20). Every variable clustering bot contains
the information shown in Table 17.
TABLE-US-00018 TABLE 17 1. Unique ID number (based on date, hour,
minute, second of creation) 2. Creation date (date, hour, minute,
second) 3. Mapping information 4. Storage location 5. Element of
performance or external factor 6. Clustering algorithm type 7.
Organization 8. Organization Level 9. Maximum number of clusters
10. Variable 1 . . . to 10 + n. Variable n
When bots in block 305 have identified, tagged and stored cluster
assignments for the data associated with each element of
performance or external factor in the element definition table
(184) or factor definition table (185), processing advances to a
software block 306.
[0184] The software in block 306 checks the mission layer table
(175) in the ContextBase (60) to see if the current mission measure
is an options based measure like contingent liabilities, real
options or strategic risk. If the current mission measure is not an
options based measure, then processing advances to a software block
309. Alternatively, if the current mission measure is an options
based measure, then processing advances to a software block
307.
[0185] The software in block 307 checks the bot date table (141)
and deactivates options simulation bots with creation dates before
the current system date. The software in block 307 then retrieves
the information from the system settings table (140), the element
definition table (184) and factor definition table (185) and the
scenarios table (152) as required to initialize option simulation
bots in accordance with the frequency specified by the user (20) in
the system settings table (140).
[0186] Bots are independent components of the application that have
specific tasks to perform. In the case of option simulation bots,
their primary task is to determine the impact of each element and
factor on the mission measure under different scenarios. The option
simulation bots run a normal scenario, an extreme scenario and a
combined scenario. In the preferred embodiment, Monte Carlo models
are used to complete the probabilistic simulation, however other
probabilistic simulation models such as Quasi Monte Carlo can be
used to the same effect. The element and factor impacts on option
mission measures could be determined using the processed detailed
below for the other types of mission measures, however, in the
preferred embodiment a separate procedure is used. The models are
initialized specifications used in the baseline calculations. Every
option simulation bot activated in this block contains the
information shown in Table 18.
TABLE-US-00019 TABLE 18 1. Unique ID number (based on date, hour,
minute, second of creation) 2. Creation date (date, hour, minute,
second) 3. Mapping information 4. Storage location 5. Type: normal,
extreme or combined 6. Option type: real option, contingent
liability or strategic risk 7. Organization 7. Organization level
8. Mission measure
After the option simulation bots are initialized, they activate in
accordance with the frequency specified by the user (20) in the
system settings table (140). Once activated, the bots retrieve the
required information and simulate the mission measure over the time
periods specified by the user (20) in the system settings table
(140) as required to determine the impact of each element and
factor on the mission measure. After the option simulation bots
complete their calculations, the resulting sensitivities are saved
in the element definition table (184) and factor definition table
(185) by organization and organization level in the application
database (50) and processing advances to a software block 309.
[0187] The software in block 309 checks the bot date table (141)
and deactivates all predictive model bots with creation dates
before the current system date. The software in block 309 then
retrieves the information from the system settings table (140), the
mission layer table (175), the element definition table (184) and
the factor definition table (185) as required to initialize
predictive model bots for each mission layer.
[0188] Bots are independent components of the application that have
specific tasks to perform. In the case of predictive model bots,
their primary task is to determine the relationship between the
element and factor data and the mission measure being evaluated.
Predictive model bots are initialized for every organization level
where the mission measure being evaluated is used. They are also
initialized for each cluster and regime of data in accordance with
the cluster and regime assignments specified by the bots in blocks
304 and 305 by organization and organization level. A series of
predictive model bots is initialized at this stage because it is
impossible to know in advance which predictive model type will
produce the "best" predictive model for the data from each
commercial enterprise. The series for each model includes 12
predictive model bot types: neural network; CART; GARCH, projection
pursuit regression; generalized additive model (GAM), redundant
regression network; rough-set analysis, boosted Naive Bayes
Regression; MARS; linear regression; support vector method and
stepwise regression. Additional predictive model types can be used
to the same effect. Every predictive model bot contains the
information shown in Table 19.
TABLE-US-00020 TABLE 19 1. Unique ID number (based on date, hour,
minute, second of creation) 2. Creation date (date, hour, minute,
second) 3. Mapping information 4. Storage location 5. Organization
6. Organization Level 7. Global or Cluster (ID) and/or Regime (ID)
8. Element, sub-element or external factor 9. Predictive model
type
After predictive model bots are initialized, the bots activate in
accordance with the frequency specified by the user (20) in the
system settings table (140). Once activated, the bots retrieve the
required data from the appropriate table in the ContextBase (60)
and randomly partition the element or factor data into a training
set and a test set. The software in block 309 uses "bootstrapping"
where the different training data sets are created by re-sampling
with replacement from the original training set so data records may
occur more than once. After the predictive model bots complete
their training and testing, the best fit predictive model
assessments of element and factor impacts on mission measure
performance are saved in the element definition table (184) and the
factor definition table (185) before processing advances to a block
310.
[0189] The software in block 310 determines if clustering improved
the accuracy of the predictive models generated by the bots in
software block 309 by organization and organization level. The
software in block 310 uses a variable selection algorithm such as
stepwise regression (other types of variable selection algorithms
can be used) to combine the results from the predictive model bot
analyses for each type of analysis--with and without clustering--to
determine the best set of variables for each type of analysis. The
type of analysis having the smallest amount of error as measured by
applying the mean squared error algorithm to the test data are
given preference in determining the best set of variables for use
in later analysis. There are four possible outcomes from this
analysis as shown in Table 20.
TABLE-US-00021 TABLE 20 1. Best model has no clustering 2. Best
model has temporal clustering, no variable clustering 3. Best model
has variable clustering, no temporal clustering 4. Best model has
temporal clustering and variable clustering
If the software in block 310 determines that clustering improves
the accuracy of the predictive models for an enterprise, then
processing advances to a software block 314. Alternatively, if
clustering does not improve the overall accuracy of the predictive
models for an enterprise, then processing advances to a software
block 312.
[0190] The software in block 312 uses a variable selection
algorithm such as stepwise regression (other types of variable
selection algorithms can be used) to combine the results from the
predictive model bot analyses for each model to determine the best
set of variables for each model. The models having the smallest
amount of error, as measured by applying the mean squared error
algorithm to the test data, are given preference in determining the
best set of variables. As a result of this processing, the best set
of variables contain the: item variables, item performance
indicators, factor performance indications, composite variables and
composite factors (aka element data and factor data) that correlate
most strongly with changes in the mission measure being analyzed.
The best set of variables will hereinafter be referred to as the
"performance drivers".
[0191] Eliminating low correlation factors from the initial
configuration of the vector creation algorithms increases the
efficiency of the next stage of system processing. Other error
algorithms alone or in combination may be substituted for the mean
squared error algorithm. After the best set of variables have been
selected, tagged and stored in the element definition table (184)
and the factor definition table (185) for each organization level,
the software in block 312 tests the independence of the performance
drivers for each organization level before processing advances to a
block 313.
[0192] The software in block 313 checks the bot date table (141)
and deactivates causal predictive model bots with creation dates
before the current system date. The software in block 313 then
retrieves the information from the system settings table (140) and
the element definition table (184) and factor definition table
(185) as required to initialize causal predictive model bots for
each element of performance, sub-element of performance and
external factor in accordance with the frequency specified by the
user (20) in the system settings table (140).
[0193] Bots are independent components of the application that have
specific tasks to perform. In the case of causal predictive model
bots, their primary task is to refine the performance driver
selection to reflect only causal variables. The Bayesian bots in
this step also refine the estimates of element or factor impact
developed by the predictive model bots in a prior processing step
by assigning a probability to the impact estimate. A series of
causal predictive model bots are initialized at this stage because
it is impossible to know in advance which causal predictive model
will produce the "best" vector for the best fit variables from each
model. The series for each model includes five causal predictive
model bot types: Tetrad, MML, LaGrange, Bayesian and path analysis.
The software in block 313 generates this series of causal
predictive model bots for each set of performance drivers stored in
the element definition table (184) and factor definition table
(185) in the previous stage in processing. Every causal predictive
model bot activated in this block contains the information shown in
Table 21.
TABLE-US-00022 TABLE 21 1. Unique ID number (based on date, hour,
minute, second of creation) 2. Creation date (date, hour, minute,
second) 3. Mapping information 4. Storage location 5. Component or
subcomponent of value 6. Element, sub-element or external factor 7.
Variable set 8. Causal predictive model type 9. Organization 10.
Organization level
After the causal predictive model bots are initialized by the
software in block 313, the bots activate in accordance with the
frequency specified by the user (20) in the system settings table
(140). Once activated, they retrieve the required information for
each model and sub-divide the variables into two sets, one for
training and one for testing. After the causal predictive model
bots complete their processing for each model, the software in
block 313 uses a model selection algorithm to identify the model
that best fits the data for each element of performance,
sub-element of performance and external factor being analyzed. For
the system of the present invention, a cross validation algorithm
is used for model selection. The software in block 313 tags and
saves the refined estimates of probable impact and the best fit
causal factors in the element definition table (184) or the factor
definition table (185) in the ContextBase (60) before processing
advances to a block 321.
[0194] If software in block 310 determines that clustering improves
predictive model accuracy, then processing advances directly to
block 314 as described previously. The software in block 314 uses a
variable selection algorithm such as stepwise regression (other
types of variable selection algorithms can be used) to combine the
results from the predictive model bot analyses for each model,
cluster and/or regime to determine the best set of variables for
each model. The models having the smallest amount of error as
measured by applying the mean squared error algorithm to the test
data are given preference in determining the best set of variables.
As a result of this processing, the best set of variables contains:
the element data and factor data that correlate most strongly with
changes in the components of value. The best set of variables will
hereinafter be referred to as the "performance drivers".
Eliminating low correlation factors from the initial configuration
of the vector creation algorithms increases the efficiency of the
next stage of system processing. Other error algorithms alone or in
combination may be substituted for the mean squared error
algorithm. After the best set of variables have been selected,
tagged as performance drivers and stored in the element definition
table (184) and factor definition table (185) for all organization
levels, the software in block 314 tests the independence of the
performance drivers at every organization level before processing
advances to a block 315.
[0195] The software in block 315 checks the bot date table (141)
and deactivates causal predictive model bots with creation dates
before the current system datr. The software in block 315 then
retrieves the information from the system settings table (140) and
the element definition table (184) and factor definition table
(185) as required to initialize causal predictive model bots for
each element of performance, sub-element of performance and
external factor for every organization level in accordance with the
frequency specified by the user (20) in the system settings table
(140).
[0196] Bots are independent components of the application that have
specific tasks to perform. In the case of causal predictive model
bots, their primary task is to refine the element and factor
performance driver selection to reflect only causal variables.
(Note: these variables are grouped together to represent a single
element vector when they are dependent). In some cases it may be
possible to skip the correlation step before selecting causal the
item variables, factor variables, item performance indicators,
factor performance indicators, composite variables and composite
factors (aka element data and factor data). A series of causal
predictive model bots are initialized at this stage because it is
impossible to know in advance which causal predictive model will
produce the "best" vector for the best fit variables from each
model. The series for each model includes four causal predictive
model bot types: Tetrad, LaGrange, Bayesian and path analysis. The
Bayesian bots in this step also refine the estimates of element or
factor impact developed by the predictive model bots in a prior
processing step by assigning a probability to the impact estimate.
The software in block 315 generates this series of causal
predictive model bots for each set of performance drivers stored in
the element definition table (184) and factor definition table
(185) in the previous stage in processing. Every causal predictive
model bot activated in this block contains the information shown in
Table 22.
TABLE-US-00023 TABLE 22 1. Unique ID number (based on date, hour,
minute, second of creation) 2. Creation date (date, hour, minute,
second) 3. Mapping information 4. Storage location 5. Component or
subcomponent of value 6. Cluster (ID) and/or Regime (ID) 7.
Element, sub-element or external factor 8. Variable set 9.
Organization 10. Enterprise 11. Causal predictive model type
After the causal predictive model bots are initialized by the
software in block 315, the bots activate in accordance with the
frequency specified by the user (20) in the system settings table
(140). Once activated, they retrieve the required information for
each model and sub-divide the variables into two sets, one for
training and one for testing. The same set of training data are
used by each of the different types of bots for each model. After
the causal predictive model bots complete their processing for each
model, the software in block 315 uses a model selection algorithm
to identify the model that best fits the data for each element,
sub-element or external factor being analyzed by model and/or
regime by organization and organization level. For the system of
the present invention, a cross validation algorithm is used for
model selection. The software in block 315 saves the refined impact
estimates and the best fit causal factors in the element definition
table (184) or the factor definition table (185) in the ContextBase
(60) before processing advances to a block 321.
[0197] The software in block 321 tests the performance drivers to
see if there is interaction between elements, between elements and
external factors or between external factors by organization and
organization level. The software in this block identifies
interaction by evaluating a chosen model based on stochastic-driven
pairs of value-driver subsets. If the accuracy of such a model is
higher that the accuracy of statistically combined models trained
on attribute subsets, then the attributes from subsets are
considered to be interacting and then they form an interacting set.
The software in block 321 also tests the performance drivers to see
if there are "missing" performance drivers that are influencing the
results. If the software in block 321 does not detect any
performance driver interaction or missing variables for each
enterprise, then system processing advances to a block 324.
Alternatively, if missing data or performance driver interactions
across elements are detected by the software in block 321 for one
or more mission measure processing advances to a software block
322.
[0198] The software in block 322 prompts the user (20) via the
structure revision window (706) to adjust the specification(s) for
the elements of performance, sub-elements of performance or
external factors as required to minimize or eliminate the
interaction that was identified. At this point the user (20) has
the option of specifying that one or more elements of performance,
sub elements of performance and/or external factors be combined for
analysis purposes (element combinations and/or factor combinations)
for each enterprise where there is interaction between elements
and/or factors. The user (20) also has the option of specifying
that the elements or external factors that are interacting will be
evaluated by summing the impact of their individual performance
drivers. Finally, the user (20) can choose to re-assign a
performance driver to a new element of performance or external
factor to eliminate the inter-dependency. This process is the
preferred solution when the inter-dependent performance driver is
included in the going concern element of performance. Elements and
external factors that will be evaluated by summing their
performance drivers will not have vectors generated.
[0199] Elements of performance and external factors generally do
not share performance drivers and they are not combined with one
another. However, when an external factor and an element of
performance are shown to be inter-dependent, it is usually because
the element of performance is a dependent on the external factor.
For example, the performance of a process typically varies with the
price of commodities consumed in the process. In that case, the
external factor impact and the element of performance would be
expected to be a function of the same performance driver. The
software in block 322 examines all the factor-element dependencies
and suggest the appropriate percentage of factor risk assignment to
the different elements it interacts with. For example, 30% of a
commodity factor risk could be distributed to each of the 3
processes that consume the commodity with the remaining 10% staying
in the going concern element of performance. The user (20) either
accepts the suggested distribution or specifies his own
distribution for each factor-element interaction. After the input
from the user (20) is saved in the system settings table (140), the
element definition table (184) and factor definition table (185)
system processing advances to a software block 323. The software in
block 323 checks the system settings table (140) and the element
definition table (184) and factor definition table (185) to see if
there any changes in structure. If there have been changes in the
structure, then processing returns to block 201 and the system
processing described previously is repeated. Alternatively, if
there are no changes in structure, then the information regarding
the element interaction is saved in the organization layer table
(174) before processing advances to a block 324.
[0200] The software in block 324 checks the bot date table (141)
and deactivates vector generation bots with creation dates before
the current system date. The software in block 324 then initializes
bots for each element of performance, sub-element of performance,
element combination, factor combination and external factor for
each enterprise in the organization. The bots activate in
accordance with the frequency specified by the user (20) in the
system settings table (140), retrieve the information from the
system settings table (140), the element definition table (184) and
factor definition table (185) as required to initialize vector
generation bots for each element of performance and sub-element of
performance in accordance with the frequency specified by the user
(20) in the system settings table (140). Bots are independent
components of the application that have specific tasks to perform.
In the case of vector generation bots, their primary task is to
produce formulas, (hereinafter, vectors) that summarize the
relationship between the causal performance drivers and changes in
the component or sub-component of value being examined for each
enterprise. The causal performance drivers may be grouped by
element of performance, sub-element of performance, external
factor, factor combination or element combination. As discussed
previously, the vector generation step is skipped for performance
drivers where the user has specified that performance driver
impacts will be mathematically summed to determine the value of the
element or factor. The vector generation bots use induction
algorithms to generate the vectors. Other vector generation
algorithms can be used to the same effect. The software in block
324 generates a vector generation bot for each set of causal
performance drivers stored in the element definition table (184)
and factor definition table (185). Every vector generation bot
contains the information shown in Table 23.
TABLE-US-00024 TABLE 23 1. Unique ID number (based on date, hour,
minute, second of creation) 2. Creation date (date, hour, minute,
second) 3. Mapping information 4. Storage location 5. Organization
6. Organization level 7. Element, sub-element, factor or
combination 8. Factor 1 . . . to 8 + n. Factor n
When bots in block 324 have identified, tagged and stored vectors
for all time periods with data for all the elements, sub-elements,
combinations or external factors where vectors are being calculated
in the element definition table (184) and factor definition table
(185) by organization and organization level, processing advances
to a software block 325.
[0201] The software in block 325 checks the bot date table (141)
and deactivates element life bots with creation dates before the
current system date. The software in block 325 then retrieves the
information from the system settings table (140) and the element
definition table (184) as required to initialize element life bots
for each element and sub-element of performance for each
organization level being analyzed.
[0202] Bots are independent components of the application that have
specific tasks to perform. In the case of element life bots, their
primary task is to determine the expected life of each element and
sub-element of performance. There are three methods for evaluating
the expected life of the elements and sub-elements of performance:
[0203] 1. Elements of performance that are defined by a population
of members or items (such as: channel partners, customers,
employees and vendors) will have their lives estimated by analyzing
and forecasting the lives of the members of the population. The
forecasting of member lives will be determined by the "best" fit
solution from competing life estimation methods including the Iowa
type survivor curves, Weibull distribution survivor curves,
Gompertz-Makeham survivor curves, polynomial equations using the
methodology for selecting from competing forecasts disclosed in
cross referenced U.S. Pat. No. 5,615,109; [0204] 2. Elements of
performance (such as patents, long term supply agreements and
insurance contracts) that have legally defined lives will have
their lives calculated using the time period between the current
date and the expiration date of the element or sub-element; and
[0205] 3. Finally, for commercial business evaluations elements of
performance and sub-elements of performance (such as brand names,
information technology and processes) that do not have defined
lives and/or that may not consist of a collection of members will
have their lives estimated as a function of the enterprise
Competitive Advantage Period (CAP). In the latter case, the
estimate will be completed using the element vector trends and the
stability of relative element strength. More specifically, lives
for these element types are estimated by: subtracting time from the
CAP for element volatility that exceeds enterprise volatility
and/or subtracting time for relative element strength that is below
the leading position and/or relative element strength that is
declining. In all cases, the resulting values are tagged and stored
in the element definition table (184) for each element and
sub-element of performance by organization and organization level.
Every element life bot contains the information shown in Table
24.
TABLE-US-00025 [0205] TABLE 24 1. Unique ID number (based on date,
hour, minute, second of creation) 2. Creation date (date, hour,
minute, second) 3. Mapping information 4. Storage location 5.
Organization 6. Organization Level 7. Element or sub-element of
performance 8. Life estimation method (item analysis, date
calculation or relative to CAP)
After the element life bots are initialized, they are activated in
accordance with the frequency specified by the user (20) in the
system settings table (140). After being activated, the bots
retrieve information for each element and sub-element of
performance from the element definition table (184) as required to
complete the estimate of element life. The resulting values are
then tagged and stored in the element definition table (184) by
organization and organization level in the ContextBase (60) before
processing advances to a block 326.
[0206] The software in block 326 checks the bot date table (141)
and deactivates event risk bots with creation dates before the
current system date. The software in the block then retrieves the
information from the system settings table (140) and the event risk
table (186) as required to initialize event risk bots for each
organization level in accordance with the frequency specified by
the user (20) in the system settings table (140). Bots are
independent components of the application that have specific tasks
to perform. In the case of event risk bots, their primary tasks are
to forecast the frequency of standard event risks by organization
and organization level and forecast the impact on the mission
measure. In addition to forecasting risks that are traditionally
covered by insurance, the system of the present invention also uses
the data to forecast standard, "non-insured" event risks such as
the risk of employee resignation and the risk of customer
defection. The system of the present invention uses the forecasting
methods disclosed in cross-referenced U.S. Pat. No. 5,615,109 for
standard event risk forecasting. Other forecasting methods can be
used to the same effect. Every event risk bot contains the
information shown in Table 25.
TABLE-US-00026 TABLE 25 1. Unique ID number (based on date, hour,
minute, second of creation) 2. Creation date (date, hour, minute,
second) 3. Mapping information 4. Storage location 5. Organization
6. Organization level 7. Event risk
After the event risk bots are initialized, the bots activate in
accordance with the frequency specified by the user (20) in the
system settings table (140). After being activated the bots,
retrieve the data from the element definition table (184) and
factor definition table (185) and then forecast the frequency and
severity of the event risks. The resulting forecasts for each
enterprise are then stored in the event risk table (186) before
processing advances to a software block 327.
[0207] The software in block 327 checks the bot date table (141)
and deactivates extreme value bots with creation dates before the
current system date. The software in block 327 then retrieves the
information from the system settings table (140), the element
definition table (184), the factor definition table (185) and the
event risk table (186) as required to initialize extreme value bots
in accordance with the frequency specified by the user (20) in the
system settings table (140). Bots are independent components of the
application that have specific tasks to perform. In the case of
extreme value bots, their primary task is to forecast the
probability of realizing extreme values and identify the range of
extreme values for every event risk, action and causal, performance
driver (for both elements of performance and external factors). The
extreme value bots use the Blocks method and the peak over
threshold method to identify extreme values. Other extreme value
algorithms can be used to the same effect. Every extreme value bot
activated in this block contains the information shown in Table
26.
TABLE-US-00027 TABLE 26 1. Unique ID number (based on date, hour,
minute, second of creation) 2. Creation date (date, hour, minute,
second) 3. Mapping information 4. Storage location 5. Organization
6. Organization level 7. Method: blocks or peak over threshold 8.
Event risk, performance driver or action
After the extreme value bots are initialized, they activate in
accordance with the frequency specified by the user (20) in the
system settings table (140). Once activated, they retrieve the
required information and forecast the likelihood of realizing
extreme values and determine the extreme value range for each
performance driver or event risk. The bot tags and saves the
extreme values for each causal performance driver in the element
definition table (184) or the factor definition table (185) by
organization and organization level. The extreme event risk
information is stored in the event risk table (186) by organization
and organization level in the ContextBase (60) before processing
advances to a software block 328.
[0208] The software in block 328 checks the bot date table (141)
and deactivates strategic event bots with creation dates before the
current system date. The software in block 328 then retrieves the
information from the system settings table (140), the element
definition table (184), the factor definition table (185) and the
event risk table (186) as required to initialize strategic event
bots in accordance with the frequency specified by the user (20) in
the system settings table (140). Bots are independent components of
the application that have specific tasks to perform. In the case of
strategic event bots, their primary task is to identify the
probability and magnitude of strategic events that can impact
mission measure performance for each organization level. The
strategic event bots use game theoretic real option models to
forecast strategic risks.. Other risk forecasting algorithms can be
used to the same effect. Every strategic event bot activated in
this block contains the information shown in Table 27.
TABLE-US-00028 TABLE 27 1. Unique ID number (based on date, hour,
minute, second of creation) 2. Creation date (date, hour, minute,
second) 3. Mapping information 4. Storage location 5. Organization
6. Organization level
After the strategic event bots are initialized, they activate in
accordance with the frequency specified by the user (20) in the
system settings table (140). Once activated, they retrieve the
required information and forecast the frequency and magnitude of
strategic events. The bots save the strategic event forecast
information in the event risk table (186) by organization and
organization level in the ContextBase (60) and processing advances
to a block 329.
[0209] The software in block 329 checks the bot date table (141)
and deactivates statistical bots with creation dates before the
current system date. The software in block 329 then retrieves the
information from the system settings table (140), the element
definition table (184), the factor definition table (185) and the
event risk table (186) as required to initialize statistical bots
for each causal performance driver and event risk. Bots are
independent components of the application that have specific tasks
to perform. In the case of statistical bots, their primary tasks
are to calculate and store statistics such as mean, median,
standard deviation, slope, average period change, maximum period
change, variance and covariance between each causal performance
driver and event risk. Every statistical bot contains the
information shown in Table 28.
TABLE-US-00029 TABLE 28 1. Unique ID number (based on date, hour,
minute, second of creation) 2. Creation date (date, hour, minute,
second) 3. Mapping information 4. Storage location 5. Organization
6. Organization level 7. Performance driver or event risk
The bots in block 329 calculate and store statistics for each
causal performance driver and event risk in the element definition
table (184), factor definition table (185) or event risk table
(186) by organization and organization level. The covariance
information is also stored in the organization layer table (174)
before processing advances to a software block 331.
[0210] The software in block 331 checks the bot date table (141)
and deactivates forecast update bots with creation dates before the
current system date. The software in block 331 then retrieves the
information from the system settings table (140) and factor
definition table (185) as required to initialize forecast bots in
accordance with the frequency specified by the user (20) in the
system settings table (140). Bots are independent components of the
application that have specific tasks to perform. In the case of
forecast update bots, their task is to compare the forecasts for
external factors and with the information available from futures
exchanges and update the existing forecasts as required. Every
forecast update bot activated in this block contains the
information shown in Table 29.
TABLE-US-00030 TABLE 29 1. Unique ID number (based on date, hour,
minute, second of creation) 2. Creation date (date, hour, minute,
second) 3. Mapping information 4. Storage location 5. Organization
6. Organization level 7. External factor 8. Forecast time
period
After the forecast update bots are initialized, they activate in
accordance with the frequency specified by the user (20) in the
system settings table (140). Once activated, they retrieve the
required information and determine if any forecasts need to be
updated to bring them in line with the market data on future
values. The bots save the updated factor forecasts in the factor
definition table (185) by organization and organization level and
processing advances to a software block 334.
[0211] The software in block 334 checks the bot date table (141)
and deactivates scenario bots with creation dates before the
current system date. The software in block 334 then retrieves the
information from the system settings table (140), the element
definition table (184), the factor definition table (185) and the
event risk table as required to initialize scenario bots in
accordance with the frequency specified by the user (20) in the
system settings table (140).
[0212] Bots are independent components of the application that have
specific tasks to perform. In the case of scenario bots, their
primary task is to identify likely scenarios for the evolution of
the causal performance drivers and event risks by organization and
organization level. The scenario bots use information from the
element definition table (184), the factor definition table (185)
and the event risk table (186) to develop forecasts for the
evolution of causal performance drivers and risks under normal
conditions, extreme conditions and a blended extreme-normal
scenario. Every scenario bot activated in this block contains the
information shown in Table 30.
TABLE-US-00031 TABLE 30 1. Unique ID number (based on date, hour,
minute, second of creation) 2. Creation date (date, hour, minute,
second) 3. Mapping information 4. Storage location 5. Type: normal,
extreme or blended 6. Organization 7. Organization level
After the scenario bots are initialized, they activate in
accordance with the frequency specified by the user (20) in the
system settings table (140). Once activated, they retrieve the
required information and develop a variety of scenarios as
described previously. After the scenario bots complete their
calculations, they save the resulting scenarios in the scenario
table (187) by organization and organization level in the
ContextBase (60) and processing advances to a block 341.
[0213] The software in block 341 checks the system settings table
(140) in the application database (50) to see if knowledge is going
to be captured from a subject matter expert. If the current
calculations are not going to utilize knowledge from a subject
matter expert (25), then processing advances to a software block
344. Alternatively, if the current calculations are going to
utilize knowledge captured from a subject matter expert (25), then
processing advances to a software block 342.
[0214] The software in block 342 will guide the subject matter
expert (25) through a series of steps as required to capture
knowledge via the knowledge capture window (707). The subject
matter expert (25) will provide knowledge by selecting from a
template of pre-defined elements, events, actions and organization
structure graphics that are developed from the information stored
in the ContextBase (60). The subject-matter expert (25) is first
asked to define what type of knowledge will be provided. The
choices will include each of the six context layers as well as
element definition, factor definition, event risk definition and
scenarios. On this same screen, the subject-matter expert (25) will
also be asked to decide whether basic structures or probabilistic
structures will provided in this session, if this session will
require the use of a time-line and if the session will include the
lower level subject matter. The selection regarding type of
structures will determine what type of samples will be displayed on
the next screen. If the use of a time-line is indicated, then the
user will be prompted to: select a reference point--examples would
include today, event occurrence, when I started, etc.; define the
scale being used to separate different times--examples would
include seconds, minutes, days, years, etc.; and specify the number
of time slices being specified in this session. The selection
regarding which type of knowledge will be provided determines the
display for the last selection made on this screen. As shown in
Table 31 there is a natural hierarchy to the different types of
knowledge that can be provided by subject-matter experts (25). For
example, mission level knowledge would be expected in include
relationships with the organization, instant impact, tactical and
physical context layers. If the subject-matter expert (25) agrees,
the knowledge capture, window (707) will guide the subject-matter
expert (25) to provide knowledge for each of the "lower level"
knowledge areas by following the natural hierarchies shown in Table
31.
TABLE-US-00032 TABLE 31 Starting point ''Lower level'' knowledge
areas Mission Organization, Instant Impact, Tactical, Physical
Organization Instant Impact, Tactical, Physical Instant Impact
Tactical, Physical
Summarizing the preceding discussion, the subject-matter expert
(25) has used the first screen to select one of ten types of
knowledge to be provided (mission, organization, instant impact,
tactical, physical, social environment, element, factor, event risk
or scenario). The subject-matter expert (25) has also chosen to
provide this information in one of four formats: basic structure
without timeline, basic structure with timeline, relational
structure without timeline or relational structure with timeline.
Finally, the subject-matter expert (25) has indicated whether or
not the session will include an extension to capture "lower level"
knowledge. Each selection made by the subject-matter expert (25)
will be used to identify the combination of elements, events,
actions and organization structure chosen for display and possible
selection. This information will be displayed in a manner that is
very similar to the manner in which stencils are made available to
Visio.RTM. users for use in the workspace.
[0215] The next screen displayed by the knowledge capture window
(707) will, of course, depend on which combination of knowledge,
structure and timeline types the subject-matter expert (25) has
selected. In addition to displaying the sample structures and
elements to the subject-matter expert (25), this screen will also
provide the subject-matter expert (25) with the option to use
graphical operations to change the relationship structures, define
new relationships and define new elements. The thesaurus table
(142) in the application database provides graphical operators for:
adding an element or factor, consuming an element, acquiring an
element, changing element or factor values, adding a relationship,
changing the strength of a relationship, identifying an event
cycle, identifying a random relationship, identifying commitments,
identifying constraints and indicating preferences.
[0216] The subject-matter expert (25) would be expected to select
the organization structure that most closely resembles the
knowledge that is being communicated and add it to the workspace in
the knowledge capture window (707). After adding it to the
workspace, the subject-matter expert (25) will then edit elements
and events and add elements, events and descriptive information as
required to fully describe the knowledge being captured from the
perspective represented by the screen. If relational information is
being specified, then the knowledge capture window (707) will give
the subject-matter expert (25) the option of using graphs, numbers
or letter grades to communicate the information regarding
probabilities. If a timeline is being used, then the next screen
displayed by the knowledge capture window (707) will be the screen
for the same perspective from the next time period in the time
line. The starting point for the next period knowledge capture will
be the final version of the knowledge captured in the prior time
period. After completing the knowledge capture for each time period
for a given level, the knowledge capture window (707) will guide
the subject-matter expert (25) to the "lower level" areas where the
process will be repeated using samples that are appropriate to the
context layer or area being reviewed. At all steps in the process,
the subject matter background information in the ContextBase (60)
and the knowledge collected during the session will be used to
predict elements, actions, events and organization structures that
are likely to be added or modified in the workspace. These
"predictions" will be displayed using flashing symbols in the
workspace. The subject-matter expert (25) will also be provided
with the option of turning the predictive prompting feature off.
After knowledge has been captured for all knowledge areas, the
graphical results will be converted to data base entries and stored
in the appropriate tables (171, 172, 173, 174, 175, 179, 184, 185,
186 or 187) in the ContextBase (60) before processing advances to a
software block 344. Data from simulation programs could be added to
the ContextBase (60) to provide similar information.
[0217] The software in block 344 checks the bot date table (141)
and deactivates segmentation bots with creation dates before the
current system date. The software in the block then retrieves the
information from the system settings table (140), the element
definition table (184) and factor definition table (185) and
scenario table (187) to initialize segmentation bots for each
organization level in accordance with the frequency specified by
the user (20) in the system settings table (140). Bots are
independent components of the application that have specific tasks
to perform. In the case of segmentation bots, their primary task is
to use the historical and forecast data to segment the performance
contribution of each element, factor, combination and performance
driver into a base value and a variability or risk component. The
system of the present invention uses wavelet algorithms to segment
the performance contribution into two components although other
segmentation algorithms such as GARCH could be used to the same
effect. Every segmentation bot contains the information shown in
Table 32.
TABLE-US-00033 TABLE 32 1. Unique ID number (based on date, hour,
minute, second of creation) 2. Creation date (date, hour, minute,
second) 3. Mapping information 4. Storage location 5. Organization
6. Organization level 7. Element, factor, or combination 8.
Segmentation algorithm
After the segmentation bots are initialized, the bots activate in
accordance with the frequency specified by the user (20) in the
system settings table (140). After being activated the bots
retrieve data from the element definition table (184) and the
factor definition table (185) and then segment the performance
contribution of each element, factor or combination into two
segments. The resulting values by period for each organization
level are then stored in the element definition table (184) and
factor definition table (185) before processing advances to a
software block 345.
[0218] The software in block 345 checks the bot date table (141)
and deactivates simulation bots with creation dates before the
current system date. The software in block 345 then retrieves the
information from the system settings table (140), the element
definition table (184), the factor definition table (185), the
event risk table (186) and the scenario table (187) as required to
initialize simulation bots in accordance with the frequency
specified by the user (20) in the system settings table (140).
[0219] Bots are independent components of the application that have
specific tasks to perform. In the case of simulation bots, their
primary tasks are to run three different types of simulations for
the organization by organization level and to develop an overall
summary of the risks to mission measure performance. The simulation
bots run probabilistic simulations of mission measure performance
for each organization level using: the normal scenario, the extreme
scenario and the blended scenario. They also run an unconstrained
genetic algorithm simulation that evolves to the most negative
value possible over the specified time period. In the preferred
embodiment, Monte Carlo models are used to complete the
probabilistic simulation, however other probabilistic simulation
models such as Quasi Monte Carlo can be used to the same effect.
The models are initialized using the statistics and relationships
derived from the calculations completed in the prior stages of
processing to relate mission measure performance to the performance
driver and event risk scenarios. Every simulation bot activated in
this block contains the information shown in Table 33.
TABLE-US-00034 TABLE 33 1. Unique ID number (based on date, hour,
minute, second of creation) 2. Creation date (date, hour, minute,
second) 3. Mapping information 4. Storage location 5. Type: normal,
extreme, blended or unconstrained genetic algorithm 6. Mission
measure 7. Organization 8. Organization level
After the simulation bots are initialized, they activate in
accordance with the frequency specified by the user (20) in the
system settings table (140). Once activated, they retrieve the
required information and simulate mission measure performance by
organization and organization level over the time periods specified
by the user (20) in the system settings table (140). In doing so,
the bots will forecast the range of performance and risk that can
be expected for the specified mission measure by organization and
organization level within the confidence interval defined by the
user (20) in the system settings table (140) for each scenario. The
bots also create a summary of the overall risks facing the
organization for the current mission measure using the general
format shown in FIG. 10. After the simulation bots complete their
calculations, the resulting forecasts are saved in the scenario
table (187) by organization and organization level and the risk
summary is saved in the mission layer table (175) and the report
table (183) in the ContextBase (60) before processing advances to a
software block 346.
[0220] The software in block 346 checks the bot date table (141)
and deactivates mission measure bots with creation dates before the
current system date. The software in block 346 then retrieves the
information from the system settings table (140), the mission layer
table (175), the element definition table (184) and the factor
definition table (185) as required to initialize bots for each
element of performance, external factor, combination or performance
driver for the mission measure being analyzed. Bots are independent
components of the application that have specific tasks to perform.
In the case of mission measure bots, their task is to determine the
contribution of every element of performance, external factor,
combination and performance driver to the mission measure being
analyzed. The relative contribution of each element, external
factor, combination and performance driver is determined by using a
series of predictive models to find the best fit relationship
between the element of performance vectors, external factor
vectors, combination vectors and performance drivers and the
mission measure. The system of the present invention uses 12
different types of predictive models to identify the best fit
relationship: neural network; CART; projection pursuit regression;
generalized additive model (GAM); GARCH; MMDR; redundant regression
network; boosted Naive Bayes Regression; the support vector method;
MARS; linear regression; and stepwise regression. The model having
the smallest amount of error as measured by applying the mean
squared error algorithm to the test data is the best fit model. The
"relative contribution algorithm" used for completing the analysis
varies with the model that was selected as the "best-fit". For
example, if the "best-fit" model is a neural net model, then the
portion of the mission measure attributable to each input vector is
determined by the formula shown in Table 34.
TABLE-US-00035 TABLE 34 ( k = 1 k = m j = 1 j = n I jk X O k / j =
1 j = n I i k ) / k = 1 k = m j = 1 j = n I jk X O k ##EQU00001##
Where I.sub.jk = Absolute value of the input weight from input node
j to hidden node k O.sub.k = Absolute value of output weight from
hidden node k M = number of hidden nodes N = number of input
nodes
After completing the best fit calculations, the bots review the
lives of the elements of performance that impact mission measure
performance. If one or more of the elements has an expected life
that is shorter than the forecast time period stored in the system
settings, then a separate model will be developed to reflect the
removal of the impact from the element(s) that are expiring. The
resulting values for relative element of performance and external
factor contributions to mission measure performance are and saved
in the element definition table (184) and the factor definition
table (185) by organization level and organization. If the
calculations are related to a commercial business then the value of
each contribution will be saved. The overall model of mission
measure performance is saved in the mission layer table (175) by
organization level and organization. Every mission measure bot
contains the information shown in Table 35.
TABLE-US-00036 TABLE 35 1. Unique ID number (based on date, hour,
minute, second of creation) 2. Creation date (date, hour, minute,
second) 3. Mapping information 4. Storage location 5. Organization
6. Organization level 7. Element, factor, combination or
performance driver 8. Mission Measure
After the mission measure bots are initialized by the software in
block 346 they activate in accordance with the frequency specified
by the user (20) in the system settings table (140). After being
activated, the bots retrieve information and complete the analysis
of the mission measure performance. As described previously, the
resulting relative contribution percentages are saved in the
element definition table (184) and the factor definition table
(185) by organization level and organization. The overall model of
mission measure performance is saved in the mission layer table
(175) by organization level and organization before processing
advances to a software block 352.
[0221] Before continuing the discussion the remaining calculations
in this section it is appropriate to briefly review the processing
that has been completed in this portion of system (100) processing.
At this point, the physical layer table (171), tactical layer table
(172) and instant impact layer table (173) contain information that
defines the administrative status of the organization by element.
The social environment layer table (179) contains information that
identifies the external factors that affect mission measure
performance. As detailed above, the organization layer table (174)
now contains information that identifies the inter-relationship
between the different elements, risks and factors that drive
mission measure performance. The mission layer table (175) now
contains a model that identifies the elements and factors that
support mission measure performance by organization level and
organization. The mission layer table (175) also contains a summary
of the event risks and factor risks that threaten mission measure
performance. The event risks include standard event risks,
strategic event risks, contingent liabilities and extreme risks
while the variability risks include both element variability risks
and factor variability risks. In short, the ContextBase (60) now
contains a complete picture of the factors that will determine
mission measure performance for the organization. In the steps that
follow, the ContextBase (60) will be updated to support the
analysis of all organization mission measure, organizational
alignment will be evaluated, the efficient frontier for
organization performance will be defined and the organization
ontology will be formalized and stored. The next step in this
processing is completed in software block 352.
[0222] The software in block 352 checks the mission layer table
(175) in the ContextBase (60) to determine if all mission measures
for all organizations have current models. If all mission measure
models are not current, then processing returns to software block
301 and the processing described above for this portion (300) of
the application software. Alternatively, if all mission measure
models are current, then processing advances to a software block
354.
[0223] The software in block 354 retrieves the previously stored
values for mission performance from the mission layer table (175)
before processing advances to a software block 355. The software in
block 355 checks the bot date table (141) and deactivates measure
relevance bots with creation dates before the current system date.
The software in block 355 then retrieves the information from the
system settings table (140) and the mission layer table (175) as
required to initialize a bot for each organization being analyzed.
Bots are independent components of the application that have
specific tasks to perform. In the case of measure relevance bots,
their task is to determine the relevance of each of the different
mission measures to mission performance. The relevance of each
mission measure is determined by using a series of predictive
models to find the best fit relationship between the mission
measures and mission performance. The system of the present
invention uses 12 different types of predictive models to identify
the best fit relationship: neural network; CART; projection pursuit
regression; generalized additive model (GAM); GARCH; MMDR;
redundant regression network; boosted Naive Bayes Regression; the
support vector method; MARS; linear regression; and stepwise
regression. The model having the smallest amount of error as
measured by applying the mean squared error algorithm to the test
data is the best fit model. Bayes models are used to define the
probability associated with each relevance measure and the Viterbi
algorithm is used to identify the most likely contribution of all
elements, factors and risks by organization level as required to
produce a report in the format shown in FIG. 11. The relative
contribution each of mission measure to mission performance is
saved in the mission layer table (175) by organization level and
organization. Every measure relevance bot contains the information
shown in Table 36.
TABLE-US-00037 TABLE 36 1. Unique ID number (based on date, hour,
minute, second of creation) 2. Creation date (date, hour, minute,
second) 3. Mapping information 4. Storage location 5. Organization
6. Organization level 7. Mission Measure
After the measure relevance bots are initialized by the software in
block 355 they activate in accordance with the frequency specified
by the user (20) in the system settings table (140). After being
activated, the bots retrieve information and complete the analysis
of the mission performance. As described previously, the relative
mission measure contributions to mission performance and the
associated probability are saved in the mission layer table (175)
by organization level and organization before processing advances
to a software block 356.
[0224] The software in block 356 retrieves information from the
mission measure table (175) and then checks the mission measures by
organization level to determine if they are in alignment with the
overall mission. As discussed previously, lower level measures that
are out of alignment can be identified by the presence of measures
from the same level with more impact. For example, employee
training could be shown to be a strong performance driver for the
organization. If the human resources department (that is
responsible for both training and performance evaluations) was
using a timely performance evaluation measure, then the measures
would be out of alignment. If mission measures are out of
alignment, then the software in block 356 prompts the manager (21)
via the mission edit data window (708) to change the mission
measures by organization level as required to Alternatively, if
mission measures by organization level are in alignment, then
processing advances to a software block 357.
[0225] The software in block 357 checks the bot date table (141)
and deactivates frontier bots with creation dates before the
current system date. The software in block 357 then retrieves
information from the system settings table (140), the element
definition table (184), the factor definition table (185), the
event risk table (186) and the scenarios table (187) as required to
initialize frontier bots for each scenario. Bots are independent
components of the application that have specific tasks to perform.
In the case of frontier bots, their primary task is to define the
efficient frontier for organization performance under each
scenario. The top leg of the efficient frontier for each scenario
is defined by successively adding the features, options and
performance drivers that improve while increasing risk to the
optimal mix in resource efficiency order. The bottom leg of the
efficient frontier for each scenario is defined by successively
adding the features, options and performance drivers that decrease
performance while decreasing risk to the optimal mix in resource
efficiency order. Every frontier bot contains the information shown
in Table 37.
TABLE-US-00038 TABLE 37 1. Unique ID number (based on date, hour,
minute, second of creation) 2. Creation date (date, hour, minute,
second) 3. Mapping information 4. Storage location 5. Organization
6. Scenario: normal, extreme and blended
After the software in block 357 initializes the frontier bots, they
activate in accordance with the frequency specified by the user
(20) in the system settings table (140). After completing their
calculations, the results of all 3 sets of calculations (normal,
extreme and most likely) are saved in the report table (183) in
sufficient detail to generate a chart like the one shown in FIG. 12
before processing advances to a software block 358.
[0226] The software in block 358 takes the previously stored
definitions of key terms, events, organization levels, context
layers, event risks and stores them in the ontology table (182)
using the OWL language. Use of the rdf based OWL language will
enable the synchronization of the organizations ontology with other
organizations and will facilitate the extraction and use of
information from the semantic web. After the organization ontology
is saved in the ContextBase(60), processing advances to a software
block 362. The software in block 362 checks the system settings
table (140) in the application database (50) to determine if event
models will be created. If event models are not going to be
created, then processing advances to a software block 372.
Alternatively, if event models are going to be developed, then
processing advances to a software block 364. The software in block
364 prompts the user (20) via the event selection window (709) to
select the events that will have models developed. Actions are a
subset of events so they can also be selected for modeling. The
events selected for modeling are stored in the event model table
(188) in the ContextBase (60) before processing advances to a
software block 365. The software in block 365 retrieves the
previously stored event history and forecast information from the
tactical layer table (172) before processing advances to a software
block 304 where the processing used to identify causal performance
drivers is used to identify causal event drivers. When models for
each selected event are stored in the event model table (188)
processing advances to software block 372.
[0227] The software in block 372 checks the system settings table
(140) in the application database (50) to determine if impact
models will be created. If impact models are not going to be
created, then processing advances to a software block 402.
Alternatively, if impact models are going to be developed, then
processing advances to a software block 374. The software in block
374 prompts the user (20) via the impact selection window (710) to
select the impacts that will have models developed. The impacts
selected for modeling are stored in the impact model table (189) in
the ContextBase (60) before processing advances to a software block
375. The software in block 365 retrieves the previously stored
impact history and forecast information from the instant impact
layer table (173) before processing advances to a software block
304 where the processing used to identify causal performance
drivers is used to identify causal impact drivers. When models for
each selected impact are stored in the impact model table (189)
processing advances to software block 402.
Context Frame Definition
[0228] The flow diagram in FIG. 8 details the processing that is
completed by the portion of the application software (400) that
generates context frames and optionally displays and prints
management reports detailing the mission performance of the
organization. Processing in this portion of the application starts
in software block 402.
[0229] The software in block 402 retrieves information from the
system settings table (140), the physical layer table (171), the
tactical layer table (172), the instant impact layer table (173),
the organization layer table (174), the mission layer table (175),
the social environment layer table (179), the element definition
table (184), the factor definition table (185) and the event risk
table (186) as required to define context frames for every
organization level and combination specified by the user (20) in
the system settings table. The resulting frame definitions are
stored in the context frame table (190) before processing advances
to a software block 403.
[0230] The software in block 403 prompts the user (20) via the
frame definition data window (711) to define additional context
frames. If the user defines new context frames, then the
information required to define the frame is retrieved from the
physical layer table (171), the tactical layer table (172), the
instant impact layer table (173), the organization layer table
(174), the mission layer table (175), the social environment layer
table (179), the element definition table (184), the factor
definition table (185) and/or the event risk table (186) and the
context frame specification is stored in the context frame table
(190). The context frames developed by the software in block 402
will identify and include information regarding all elements that
are impacted by a change in a given context frame. In block 403,
the user (20) has the option of limiting the elements included in
the frame to include only those elements that have a certain level
of impact. For example, if a change in supply chain operation had a
very weak causal impact on brand strength, then brand information
could be excluded from the frame specified by the user (20) in this
block. If event models or impact models have been created, then the
software in block 403 can define context frames for event and
impact analysis using the same procedure described for developing
mission measure context frames. The newly defined context frames
for events, impacts and mission measures are stored in the context
frame table (190) processing passes to a software block 404.
[0231] The software in block 404 supports the complete context
interface data window (712). The complete context interface data
window (712) is where the Complete Context.TM. Systems (601, 602,
603, 604, 605, 606, 607 and 608) request context frames for use in
completing their functions. In addition to supplying context frames
to the standard applications via a network (45), the software in
block 404 supports integration and translation with other
ontologies as required to complete transactions and analysis in
automated fashion. The Complete Context.TM. Systems (601, 602, 603,
604, 605, 606, 607 and 608) all have the ability to support other
ontologies as well as the translation and integration of these
ontologies with the ontology developed by the system of the present
invention. The software in block 404 provides context frames to the
standard applications upon request. Processing continues to a
software block 410.
[0232] The software in block 410 completes two primary functions.
First it uses the narrow system interface data window (713) to
interact with each narrow system (30) as required identify the
context quotient for that system. Second, it provides context frame
information to each narrow system (30) in a format that can be used
by that narrow system (30). The context quotient is a score that is
given to each narrow system (30) that identifies the relative
ability of the narrow system to flexibly process information from
the six different context layers. The scores range from 2 to 200
with 200 being the highest score. The Complete Context.TM. Systems
(601, 602, 603, 604, 605, 606, 607 and 608) all have context
quotients of 200. Twenty points are given for each context layer
the narrow system is able to process. For example, a supply chain
optimization system with the ability to optimize supplier purchase
cost (instant impact) given an inventory status (physical) and
order status (tactical) would be given sixty points--twenty points
for each of the 3 layers it is able to process. If the supply chain
optimization system was able to change its optimal solution based
on new information regarding the relationship between the supply
chain and other elements of performance (organization) like the
customer base and channel partners, then another twenty points
would be given for its ability to process organization layer
information. The process is repeated for each layer. When the
narrow system (30) changes its results in response to input from a
new layer, then another twenty points are added to the context
quotient for that system. Another thirteen points are awarded for
the ability to respond to changes in the relative importance of
different attributes within a context layer. For example, many
systems include one or two factors from the social environment in
their analyses, however, as new factors become important, these
systems fail to recognize the new factors. The points awarded for
each "ability" are not particularly important, what is important is
that the context quotient score consistently reflects the ability
of each system to reliably process the full spectrum information
from each of the six context layers in the current environment and
in the future when the relative importance of different attributes
when each layer are expected to change. The results of the
evaluation of the context quotient for a narrow system (30) seeking
data from the system of the present invention are saved in the
context quotient table (192) in the ContextBase (60). The results
of the context quotient analysis are used to determine which
context layers should be included in the context frame sent to each
narrow system (30). After defining a context frame for the narrow
system in a manner similar to that described previously for
complete context frames, a packet containing the required
information is transmitted to the narrow system (30) via a network.
Alternatively, an operating system layer could be propagated as
described in cross-referenced patent application Ser. Nos.
10/071,164 filed Feb. 7, 2002; 10/124,240 filed Apr. 18, 2002 and
10/124,327 filed Apr. 18, 2002. The ability to support ontology
translation and integration is not provided in this software block
as there are no known narrow systems with the ability to support
the development and communication of a complete ontology. The
ability to support this function could easily be added. The
software in block 410 evaluates context quotients and provides
customized context frames to the narrow systems (30) upon request.
Processing continues to a software block 411.
[0233] The software in block 411 prompts the user (20) via the
report display and selection data window (714) to review and select
reports for printing. The format of the reports is either
graphical, numeric or both depending on the type of report the user
(20) specified in the system settings table (140). If the user (20)
selects any reports for printing, then the information regarding
the selected reports is saved in the report table (182). After the
user (20) has finished selecting reports, the selected reports are
displayed to the user (20) via the report display and selection
data window (714). After the user (20) indicates that the review of
the reports has been completed, processing advances to a software
block 412. The processing can also pass to block 412 if the maximum
amount of time to wait for no response specified by the user (20)
in the system settings table is exceeded and the user (20) has not
responded.
[0234] The software in block 412 checks the report table (182) to
determine if any reports have been designated for printing. If
reports have been designated for printing, then processing advances
to a block 415. It should be noted that in addition to standard
reports like the performance risk matrix (FIG. 10), the mission
performance matrix (FIG. 11), and the graphical depictions of the
efficient frontier shown (FIG. 12), the system of the present
invention can generate reports that rank the elements, external
factors and/or risks in order of their importance to mission
performance and/or mission risk by organization level, by mission
measure and/or for the organization as a whole. A format for a
report of this type is shown in FIG. 15. The system can also
produce reports that compare results to plan for actions, impacts
and mission measure performance if expected performance levels have
been specified and saved in appropriate context layer as well as
"metrics" reports that trace the historical values for performance
drivers over time. The software in block 415 sends the designated
reports to the printer (118). After the reports have been sent to
the printer (118), processing advances to a software block 417.
Alternatively, if no reports were designated for printing, then
processing advances directly from block 412 to block 417.
[0235] The software in block 417 checks the system settings table
(140) to determine if the system is operating in a continuous run
mode. If the system is operating in a continuous run mode, then
processing returns to block 205 and the processing described
previously is repeated in accordance with the frequency specified
by the user (20) in the system settings table (140). Alternatively,
if the system is not running in continuous mode, then the
processing advances to a block 418 where the system stops.
[0236] Thus, the reader will see that the system and method
described above transforms data and information from disparate
narrow systems into a Knowledge Based Performance Management System
(100). The level of detail, breadth and speed of the analysis gives
users of the integrated system the ability to manage their
operations in an fashion that is less complex and more powerful
than any method currently available to users of the isolated,
narrowly focused management systems.
[0237] While the above description contains many specificities,
these should not be construed as limitations on the scope of the
invention, but rather as an exemplification of one preferred
embodiment thereof. Accordingly, the scope of the invention should
be determined not by the embodiment illustrated, but by the
appended claims and their legal equivalents.
* * * * *