Strategic Information Systems Plan
THE APPROACH
Printable
PDF Version
The Strategic Model can be analyzed to identify
Business Activities and develop Project Plans to manage detailed tactical and operational
data modelling. Many Activities can be identified in this way from the Strategic Model,
for assessment by management to identify priority activities. These become priority
projects for databases and systems that should be developed and delivered early to provide
maximum benefit to the Bank. The following pages describe how business activities and
projects can be identified from a Strategic Model.
The CASE tool Visible Advantage was used to
analyze the Strategic Model to identify business activities and processes that will be
used to provide information to management from the KJB databases and systems. This
analysis results in derivation of "clusters" of related data entities
needed by each activity or process. For example, Figure 9 shows one cluster derived from
the Strategic Model. It is the Market Need Activity - represented by the entity
MARKET NEED.
Figure
9 : Analysis identified the Market Need Activity from MARKET NEED
Cluster analysis objectively and precisely
identifies subsets of the data model based on the dependency and the commonality of data
shown in it. This indicates data frequently shared by the same activities. Cluster
analysis thus provides feedback to management so that an assessment can be made whether
all required business rules have been defined; the Strategic Model can then be refined
where necessary. The CASE tool suggests activities or processes for implementation of the
KJB databases and systems. We will look at this in more detail.
Figure 9 shows that Market Need Activity is based on the
last line, showing the data entity MARKET NEED in bold. The entity on the last line is
called the "Cluster Endpoint": the focus of the business activity. The
cluster shows that MARKET NEED is directly dependent on each entity listed above it that
is also bold. These are (reading from the bottom, up): CSI, MARKET, NEED and PERIOD. This
indicates that data from all of these data entities is required so that KJB can determine
a market's needs over time. (Of course other details about the market are also required to
determine those needs, but that detail has not yet been included in the data model; it
will be added during more detailed tactical data modelling.)
The right-bracketed number preceding each entity
indicates the project phase to implement that entity; we will discuss this later in Detailed
Project Plans derived from a Data Model. Data entities supporting this activity were
shown highlighted in Figure 7, which is a data map that graphically shows the dependent
entities from the cluster in Figure 9.
Activities shown as clusters derived from the
Strategic Model can help managers identify relevant information needs. A narrative
statement that describes the Market Need Activity is illustrated by the following
typical example.
Business
Activity Description: Market Need Activity
"Market needs are determined by regular
surveys of our customers' and prospective customers' requirements for banking and other
financial products and services that we can provide now or in the future. Our main focus
is to support the needs of our domestic markets (ie. the needs of our loan market for
small firms in the Kwangju area). But our goal for global expansion requires that we also
address the needs of overseas markets; these may be different to those of our domestic
markets."
Only Management and Marketing staff can decide
whether this description of the activity is correct; an agreed definition of the activity
is then established. Marketing management can then decide whether tactical and operational
business processes for market needs analysis, as required for domestic and overseas
markets, are adequate.
Figure 10 shows another part of the strategic
model, with MARKET PLAN in the data map and Market Plan Activity in the Cluster
Report. The cluster indicates that MARKET PLAN is dependent on PLAN, PLAN TYPE and MARKET
(as these are shown in bold). However it also shows another activity that is not bold, but
instead is in plain text: Market Need Activity. The CASE tool has identified in the
Strategic Model that the Market Need Activity (discussed earlier) is a prerequisite
activity to the Market Plan Activity. This is very true; an effective Market Plan
cannot be defined without an understanding of the relevant needs of each market to which
the plan refers, whether domestic or overseas. The MARKET PLAN entity may be defined in
the Strategic Model as follows:
MARKET PLAN: A Marketing Plan is defined for
each market where we operate or plan to operate. This plan addresses the needs of each
market, whether domestic or overseas, for banking and financial products and services. It
defines the current plan and sets Key Performance Indicators (KPIs) to monitor market
penetration and growth over time.
This leads to a description of the Market Plan Activity,
which also incorporates the earlier defined Market Need Activity - for review and
refinement by management as appropriate.
"A Marketing Plan is defined for each
market where we operate or plan to operate. This plan addresses the needs of each market,
whether domestic or overseas, for banking and financial products and services. It defines
the current plan and sets Key Performance Indicators to monitor market penetration and
growth over time.
Market needs are determined by regular surveys of
our customers' and prospective customers' requirements for banking and other financial
products and services that we can provide now or in the future. Our main focus is to
support the needs of our domestic markets (ie. the needs of our loan market for small
firms in the Kwangju area). But our goal for global expansion requires that we also
address the needs of overseas markets; these may be different to those of our domestic
markets."
Figure
10 : Entities for the Market Plan Activity cluster are shown highlighted
We combined the MARKET PLAN and Market
Need Activity definitions above. The Market Plan Activity could then be
expanded to address the Global Banking goal (from Figure 1):
"Our Marketing Plans take these different
market needs into account. They establish firm objectives and strategies in each market
where we plan to operate for market entry, market growth and market penetration - to
achieve the defined KPIs.
To gain competitive advantage from opportunities
offered by Internet technologies, each Marketing Plan will define objectives and
strategies for Electronic Banking and Electronic Commerce. This will help Kwangju Bank
achieve its Global Banking goal. The Internet particularly will enable KJB to enter
overseas markets at low cost, for rapid market growth and penetration."
This activity description is more extensive than
is suggested only by the entities in Figure 10. It was developed from one Goal in the
Strategic Plan, focusing on Internet Technology that the Bank will be able to deploy for
expansion into overseas markets.
Referring to Appendix 2: Cluster Report,
it can be seen that the Market Need Activity exists in many different clusters in
the Strategic Model as derived by the CASE tool. This indicates it is a common business
activity (or process) that should only be implemented once, but which can be reused as a
standard activity so that management and staff are aware (at all times) of the needs of
each market. This information is very important; it is essential knowledge that managers
and staff must have access to, if they are to correctly deal with the needs of customers
in those markets.
Each cluster discussed above is a separately
implementable subset of the KJB Strategic Model for construction of databases and systems.
In Appendix 2: Cluster Report we see that the CASE tool identified over 160
activities and data bases based on data entities defined in the Strategic Model in the
facilitated session. Which of these should be implemented first?
From the discussion above, we determined that the
Market Need Activity is a prerequisite activity for the Market Plan Activity.
The Market Need Activity should be implemented first. Appendix 2 shows that it is a
prerequisite also for many other marketing activities. It thus becomes a prerequisite
project before projects defined to implement those other activities in Appendix 2. It is
used to develop a Project Map to build relevant KJB databases and systems.
The relationship between Market Need Activity
and Market Plan Activity is represented in Figure 11. This diagram is a Project Map
of these two clusters, used to manage implementation of some of the KJB databases and
systems: it shows an implementation sequence for these clusters. This diagram and
associated principles will be used later in this document for project planning.
Phase 1 |
Phase 2 |
|
Figure
11 : Project Map showing a Prerequisite Activity to be Implemented First
Figure 11 shows that the right-most activity (Market
Plan Activity) is in Phase 2, as it depends on the Market Need Activity which
precedes it in Phase 1. Because many other clusters also depend on this activity as a
prerequisite (see Appendix 2: Cluster Report), it should be one of the first
clusters implemented. It is thus given an implementation status of Mandatory.
Other activities may follow, depending on
management priorities for specific information. These activities are therefore each given
an implementation status of Optional.
The Market Plan Activity is documented as
a project cluster in Appendix 2: Cluster Report. It has been extracted and is shown
in Figure 12.
10. MARKET NEED ACTIVITY (derived)
1)PERIOD
2)NEED
1)CSI
3)MARKET NEED (MARKET NEED ACTIVITY)
2)MARKET
1)PLAN TYPE
2)PLAN
4)MARKET PLAN (MARKET PLAN ACTIVITY)
|
Figure
12 : Market Plan Activity, used for Project Planning
Figure 12 shows, in the right-bracketed number
preceding each entity, the relevant project phase for detailed definition and
implementation of that entity. This represents a project plan that can be illustrated in a
Gantt Chart for Project Management purposes - as shown in Figure 13 for the Market Plan
Activity.
| CLUSTER
CONTENT |
1 |
2 |
3 |
4 |
5 |
6 |
1)PERIOD
|
|
|
|
|
|
|
2)NEED
|
|
|
|
|
|
|
1)CSI
|
|
|
|
|
|
|
3)MARKET NEED (MARKET NEED ACTIVITY)
|
|
|
|
|
|
|
2)MARKET
|
|
|
|
|
|
|
1)PLAN TYPE
|
|
|
|
|
|
|
2)PLAN
|
|
|
|
|
|
|
4)MARKET PLAN (MARKET PLAN ACTIVITY)
|
|
|
|
|
|
|
Figure
13 : Gantt Chart showing Project Phases for the Market Plan Activity
Project phase dependencies in the cluster are
clearly shown in the Gantt Chart of Figure 13. The specific duration for each entity in
its phase has not been defined yet, as it depends on the complexity of definition and
implementation of the relevant entity. This is determined during detailed modelling at
tactical and operational levels.
We will examine activities related to financial
statements in different currencies for Kwangju Bank. This will enable us to identify
interdependent and independent activities.
Activities that address financial statements and
accounts in different currencies are documented in Appendix 2: Cluster Report. The
Currency Financial Account Activity and Currency Financial Statement Activity from that
Appendix are both shown in Figure 14.
29. CURRENCY FINANCIAL ACCOUNT ACTIVITY (derived)
1)LOCATION TYPE
1)PERIOD
2)LOCATION
1)EXTERNAL FACTOR TYPE
4)EXTERNAL FACTOR
3)CURRENCY
1)FINANCIAL ACCOUNT TYPE
1)BUDGET TYPE
2)BUDGET
1)F S TYPE
4)CURRENCY FINANCIAL STATEMENT
(CURRENCY FINANCIAL STATEMENT ACTIVITY)
1)FINANCIAL STATEMENT FOCUS
3)FINANCIAL STATEMENT
4)FINANCIAL ACCOUNT
5)CURRENCY FINANCIAL ACCOUNT
(CURRENCY FINANCIAL ACCOUNT ACTIVITY)
30. CURRENCY FINANCIAL STATEMENT ACTIVITY (derived)
1)BUDGET TYPE
1)PERIOD
2)BUDGET
1)F S TYPE
1)FINANCIAL ACCOUNT TYPE
1)LOCATION TYPE
2)LOCATION
1)EXTERNAL FACTOR TYPE
4)EXTERNAL FACTOR
3)CURRENCY
5)CURRENCY FINANCIAL ACCOUNT
(CURRENCY FINANCIAL ACCOUNT ACTIVITY)
4)FINANCIAL ACCOUNT
1)FINANCIAL STATEMENT FOCUS
3)FINANCIAL STATEMENT
4)CURRENCY FINANCIAL STATEMENT
(CURRENCY FINANCIAL STATEMENT ACTIVITY)
|
Figure
14 : Inter-Dependent Currency Financial Activities in the Strategic Model
Figure 14 clearly shows that these activities are
both interrelated: they are called "Interdependent Activities". A
financial statement that is expressed in a particular currency clearly uses financial
accounts also expressed in the same currency, and vice versa. The interdependency of these
activities is shown schematically in Figure 15. Double-headed arrows joining the two
activities show that they are interdependent: both activities must be fully defined, then
both must be implemented together. This suggests that the two activities should
implemented in one project, perhaps called the "Currency Financial Statement"
project.
Figure
15 : Interdependency of Currency Financial Activities
The Cluster Report in Appendix 2 includes a
cluster for the COST STRUCTURE entity in the Strategic Model. This is used to maintain
expert knowledge of interrelationships between costs that are of interest to the Bank.
This cluster is called the Cost Relationships Knowledgebase in Figure 16. All entities are
bold; there are no entities in plain text. This cluster is not dependent on any activity:
it is therefore independent and can be implemented as a project at any time.
24. COST RELATIONSHIPS KNOWLEDGEBASE (derived)
1)PERIOD
1)COST TYPE
2)COST
3)COST STRUCTURE (COST RELATIONSHIPS KNOWLEDGEBASE)
|
Figure
16 : The Cost Relationships Knowledgebase is Independent
In Figure 17 we see the Cost Financial Account
Activity. This requires the two interdependent activities above: the Currency Financial
Statement Activity and the Currency Financial Account Activity. It also requires the Cost
Relationships Knowledgebase as a prerequisite.
22. COST FINANCIAL ACCOUNT ACTIVITY (derived)
1)PERIOD
1)COST TYPE
3)COST STRUCTURE (COST RELATIONSHIPS KNOWLEDGEBASE)
2)COST
1)FINANCIAL ACCOUNT TYPE
1)BUDGET TYPE
2)BUDGET
1)F S TYPE
1)LOCATION TYPE
2)LOCATION
1)EXTERNAL FACTOR TYPE
4)EXTERNAL FACTOR
3)CURRENCY
4)CURRENCY FINANCIAL STATEMENT
(CURRENCY FINANCIAL STATEMENT ACTIVITY)
1)FINANCIAL STATEMENT FOCUS
3)FINANCIAL STATEMENT
5)CURRENCY FINANCIAL ACCOUNT
(CURRENCY FINANCIAL ACCOUNT ACTIVITY)
4)FINANCIAL ACCOUNT
5)COST FINANCIAL ACCOUNT (COST FINANCIAL ACCOUNT ACTIVITY)
|
Figure
17 : The Cost Financial Account Activity has Several Prerequisites
We can summarize these dependencies in a cluster
representing all of the related activities in a project. This is shown in Figure 18.
22. COST FINANCIAL ACCOUNT PROJECT (derived)
1)COST STRUCTURE
(COST RELATIONSHIPS KNOWLEDGEBASE)
1)CURRENCY FINANCIAL STATEMENT
(CURRENCY FINANCIAL STATEMENT ACTIVITY)
1)CURRENCY FINANCIAL ACCOUNT
(CURRENCY FINANCIAL ACCOUNT ACTIVITY)
2)COST FINANCIAL ACCOUNT (COST FINANCIAL ACCOUNT ACTIVITY)
|
Figure
18 : Cluster of Prerequisite Activities in Cost Financial Account Project
The prerequisite activities detailed for the Cost
Financial Account Activity in Figure 18 are shown schematically in Figure 19. The Currency
Finance activities are at the left of Figure 19 to show that they must be implemented in
Phase 1 of a Cost Financial Account project. As we discussed above, a double-headed arrow
joins them, to show that they are interdependent.
The Cost Relationships Knowledgebase box is drawn
at the left as it also is in Phase 1. It is an independent activity as we discussed above.
It can be implemented as an independent project at any time as it is not dependent on any
prerequisite activities.
The Cost Financial Account Activity box is drawn
to the right of these boxes, to show that it is implemented in Phase 2. It is dependent on
the prerequisite activities at the left in Phase 1. This is indicated by arrows from the
Phase 1 activities to this Phase 2 activity.
| Phase 1 |
Phase 2 |
 |
Figure
19 : Project Map for implementation of Service-related activities
We can now relate Business Activities identified
in the Strategic Model to the current Functions and Business Units of the Bank. To achieve
this, other Model Views were defined using Visible Advantage to represent the Bank's major
Business Functions and Business Units. We will shortly see how these model views will be
used to assign Business Activities to Functions or Business Units. These are (or will be)
responsible for the implementation, operation and management of those activities and the
tactical business processes and operational systems that are within them.
Some activities may already be carried out as
current functions in various business units of the Bank. Other activities will exist in
current functions that have not yet been identified because of the high-level focus of the
Strategic Model. However the Strategic Model may also include activities suggesting
functions that do not yet exist; they may address new directions to be taken by the Bank -
such as Internet-related activities for Electronic Banking or Electronic Commerce to
support the Bank's Global Banking goal using the Internet.
Each Business Activity identified by Visible
Advantage as a cluster in the Strategic Model was described in detail, as discussed
earlier in How to Identify Business Activities from a Strategic Model. These
Activities were entered as Planning Statements into the Planning Dictionary of Visible
Advantage. The description that was developed for each activity was entered as planning
statement text to describe the purpose of that activity. This purpose describes in banking
terms what the activity represents, why it is needed and how the Bank uses it. Examples
that illustrate the operation of the activity are also included, drawn from current
functions or described for new functions that are needed to support that activity. These
Business Activity Planning Statements are documented in Appendix 3 - Planning Statement
Report
Each Activity was then assigned to the relevant
Function that is (or should be) responsible for that Activity. This was achieved using the
Statement - Model View Matrix of Visible Advantage as described earlier in relation to
Figure 5. The assignment of Activities to Functions is included with other matrices in Appendix
6 - Activities by Business Function and Business Unit.
Some activities may relate to specific functions
in particular business units. Other activities may apply to different business units, but
not as part of a function of that business unit. Therefore it is useful to assign
Activities also to Business Units, using the same approach as described above for
assignment of activities to functions. These are documented with other matrices in Appendix
6 - Activities by Business Function and Business Unit.
Definition of Goals, Objectives and KPIs in
Strategic Plans indicates information that may be required by managers. Some of this can
be summarized from operational databases on a periodic basis and printed in reports. Other
information might first need to be converted ("transformed") into a different
format that is suitable for analysis. This conversion ("transformation") and
analysis of information is done in an Information Warehouse - to avoid any performance
impact from analysis processing carried out directly against operational KJB databases and
systems.
Software packages that enable managers to request
information - to analyze it and present results in graphical, tabular or report format on
a desktop computer - are readily available for use with an Information Warehouse. These
packages are Executive Information Systems (EIS), Decision Support Systems (DSS) and
OnLine Analytical Processing (OLAP) systems. Key criteria for the purchase of EIS, DSS or
OLAP packages are ease of use and flexibility for specification by managers of any
required analysis and presentation formats.
What cannot be purchased from outside, however,
is information to be analyzed and presented by these packages. The Strategic Model
represents this information; it will be defined in greater detail later, through tactical
and operational data modelling.
Much information is performance-related: the
specific information needs of managers depend on KPIs that have been set in Tactical and
Operational Business Plans for achievement by Business Units of the Bank. Goals,
Objectives and KPIs should all be measurable and can be calculated and presented by an
Information Warehouse using EIS, DSS and OLAP packages. But a problem exists: one of
monitoring progress towards achievement of the results (or "targets") over time.
This monitoring is carried out automatically within manager-defined boundaries by Decision
Early Warning (DEW) systems.
However packages to provide this decision early
warning function cannot be purchased. If such a capability is required, a DEW system must
be developed for the Information Warehouse. The KJB Strategic Model has included the data
entities needed to develop a Decision Early Warning System. Its development and use are
discussed in Decision Early Warning using an Information Warehouse.
An Information Warehouse delivers information
from many perspectives or dimensions; this is called "multi-dimensional
analysis". This enables managers to examine change trends over time. Demographic
change trends (or other population changes) that affect needs for banking products and
services - and help management assess the most effective ways of delivering those products
and services to satisfy the needs - are all of great interest to KJB management.
An Information Warehouse can deliver this
information to a manager's desktop in Head Office or in bank branches throughout the
country and overseas. It enables bank managers to interrogate data at the branch level, to
analyze data themselves, and to create ad-hoc reports - without time-consuming and
expensive programming to develop inflexible hardcopy reports.
Goals, Objectives and KPIs are all
performance measures that are documented in Strategic, Tactical and Operational Business
Plans. They should all be measurable, and the results of these performance measures are
plotted over time. They are monitored by a Decision Early Warning System as shown in
Figure 20. The Performance Measure is plotted on the Y-axis, with time plotted as Periods
on the X-axis. The target performance measure at each time period can then be
plotted, shown by a dashed and dotted line in Figure 20.
Figure
20 : A Decision Early Warning System
The target may not be achieved exactly, but a
manager will want to know if the performance result is within acceptable boundaries: shown
by the lines above and below the target line. If performance falls outside these
boundaries, the manager responsible for the performance measure can be notified
immediately by an automatic e-mail message from the Information Warehouse. This e-mail
message will include the appropriate Decision Early Warning graph in Figure 20, and may
also automatically include statements from the relevant Business Plan that is relevant to
the performance measure, such as KPIs or objectives that it addresses. A decision can then
be taken by the manager to allocate resources to resolve the unacceptable performance.
If the performance result falls within the
boundaries of acceptable performance, the manager need take no action. The actual result
at the end of each time period is plotted: the actual performance result over time is the
solid heavy line in Figure 20. This shows a trend developing that will result in
unacceptable performance in the future: shown by a dashed line. A decision may need to be
taken by the responsible manager: perhaps by changing resources previously allocated to
achieve the desired change in performance, or by allocating other or additional resources.
The shaded vertical band from the X-axis
indicates an "Early Warning Period" representing an expected delay before
allocated resources can work to change the trend. For example, once a decision has been
made it may take time for relevant resources to become available (called the "resource
lead time"). When available, it may take further time for the resources to take
effect (the "resource lag time"). A safety factor may also need to be
included (the "decision safety factor"). The total of resource lead time,
resource lag time and decision safety factor then indicates the early warning period for
the performance measure.
The responsible manager is also notified by
automatic e-mail if a trend has been detected that will cross into unacceptable
performance within the early warning period, as shown in Figure 20. The manager can then
make an early decision before the unacceptable performance boundary is crossed: allocating
resources to change the trend and avoid that unacceptable result.
Figure
21 : Data Map of the Decision Early Warning System
A Decision Early Warning System as described
above can be incorporated in an Information Warehouse. This will enable managers at every
level within the Bank to track the achievement of their performance measures or
performance agreements automatically. The data map for the Decision Early Warning system
is shown in Figure 21 and is discussed next.
The data map in Figure 21 shows the data entities
needed to develop a Decision Early Warning System. A KPI has one or many PERFORMANCE
MEASURE. A PLAN has one or many KPI and also one or many PLAN PERFORMANCE RESULT over time
(PERIOD). A manager is a PERSON who may be responsible for many KPI.
A PROCESS calculates each plan performance
result. A process is documented as a narrative activity description in a process statement
or it can be documented in a computer programming language, such as an SQL query
statement.
The process operates against source data for the
performance measure. Each source data value is a ROW for a data COLUMN of a TABLE in a
DATA BASE, whose values are filtered by a CONDITION (such as an SQL where clause).
This data map includes all of the data entities
needed for performance monitoring to deliver decision early warning information
automatically to management. A Decision Early Warning System can be implemented as part of
the Information Warehouse - or it may be installed on any computer attached to the Bank's
Intranet.
We have assumed Intranet access of the DEW
computer in the discussion below. This offers flexibility to connect to the Internet if
external source data is required by a process and performance measure to calculate a plan
performance result. The DEW computer does not have to be powerful; a server or a desktop
computer will do. It avoids the need for a firewall, or compromising the security of the
Bank's Information Warehouse by a direct Internet connection.
Performance results are monitored over time
periods using the Decision Early Warning System as described step-by-step next:
- A time period is defined by the responsible
manager with a start date and duration, which may be expressed in any time unit - such as
hours, days, weeks, months or years.
- When the period duration ends, an automatic
request is sent from the DEW computer via the Intranet to the Information Warehouse. This
request specifies the process (or includes an SQL query), the data source and the relevant
source data filtering condition. It also specifies the performance measure and the plan
for which performance is to be monitored.
- Once initiated, the process operates on the source
data - filtered by the condition defined for the process. The source data may be in
operational databases and systems, or may reside in the Information Warehouse computer
attached to the Bank's Intranet. It may involve a large quantity of data and take
considerable time to produce a result.
- The result of this processing is transmitted from
the Warehouse back to the DEW computer, as a performance result for that period. The DEW
computer compares this result value to the target value and to the upper and lower bounds
of acceptable performance for that period.
- If these bounds are exceeded, or a trend is
detected that will cross those bounds within the early warning period (ie. a trend towards
unacceptable performance), the person responsible for the relevant plan is notified by
email with the DEW graph as an email-attached file.
- The next performance period begins. Another
performance result is then calculated on its completion, as described above.
Once initiated by the start date and period
duration, performance monitoring is automatic. The person responsible for the performance
measure and KPI is only notified if a performance result value falls outside the
acceptable boundaries (as earlier defined by that manager), or if a performance trend has
developed that requires an early warning notification.
The performance result is calculated by a process
executed by the Information Warehouse computer, or by any other computer within the Bank.
Alternatively, if appropriate arrangements are made with other organisations to use the
data sources on their computers, those machines may carry out the processing when
contacted by the DEWS computer. This approach can be used to contact any computer
worldwide that has a data source of interest to the Bank - by using the Internet and the
World Wide Web.
A Decision Early Warning System developed in this
way is also dynamic: any performance measure and its relevant SQL query and Where clause
(or other programs for processing) can be added to tables used by the DEW computer as
follows:
- The performance measure is entered as a new row in
the Performance Measure table.
- The SQL query is added to the Process table,
and the Where clause is added to the Condition table.
- The names of the relevant column, table and data
base that provide the data source for the performance indicator are added to the Column,
Table and Data Base tables.
- The location of the data base is added to the Data
Base table (as a LAN or WAN address for a KJB data base, a dial-up phone number for an
external data base, or instead as a URL ["Universal Resource Locator"] for a
data base accessed via the Internet).
Thus new performance measures can be dynamically
and easily added to the Decision Early Warning system: by adding appropriate SQL query and
Where clauses specifying relevant processing to derive performance results for that
measure; and by identifying the data source. The responsible manager can then set targets
and upper and lower performance boundaries and specify the period frequency for automatic
performance monitoring.
The Decision Early Warning System in Figure 21
can be built for the Information Warehouse based on the two clusters shown in the Cluster
Report in Figure 22. This specifically derived only those clusters for the DEW system: the
three asterisks following some entity names indicate that those entities are defined
elsewhere in the KJB Strategic Model.
Figure
22 : Project Plan for Decision Early Warning System
The next section documents the results of the
SISP and the Recommendations.
|
