Methodologies and Technologies for Rapid Enterprise Architecture Delivery

Google
 
Web www.ies.aust.com

| Home | Courses | Projects | Papers | Contact Us |

 Strategic Information Systems Plan

THE APPROACH

Printable PDF Version

Contents

 


Projects Identified from KJB Strategic Model

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.

How to Identify Business Activities 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.

figure9.gif (17340 bytes)

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.

Business Activity Description: Market Plan Activity

"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."

figure10.gif (19261 bytes)

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.

How to Derive Project Plans from a Strategic Model

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.

Project Map for Market Need Analysis

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.

Detailed Project Plans Derived from a Data Model

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.

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

Relating Activities to Functions and Business Units

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.

Business Activities and Functions

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.

Business Units and Functions

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.

KJB Information Warehouse

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.

Information Warehouse Systems (EIS, DSS, OLAP, DEW)

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.

Management Use of 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.

Decision Early Warning using an Information Warehouse

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.

Development of a Decision Early Warning System

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).

Using the Decision Early Warning System

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.

Performance Measures in the Decision Early Warning System

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.

Project Plan for the Decision Early Warning System

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.

figure22.gif (9191 bytes)

Figure 22 : Project Plan for Decision Early Warning System

The next section documents the results of the SISP and the Recommendations.

 

 

Home
Courses

Projects

EA_Projects

Strategic_Modeling

Business_Planning

Tactical_Modeling

Activity_Modeling

Project_References
Contact_or_Email_Us

Papers
TEN Archive

Contact Us

Search

 

 

| Home | Courses | Projects | Papers | TEN Archive | Contact Us | [Search |

(c) Copyright 1995-2015 Clive Finkelstein. All Rights Reserved.