CA2312653A1 - Customer service impact reporting - Google Patents

Abstract

The Customer Service Impact Reporting scheme establishes an overall measure of how well information technology systems are performing from the customers' perspective of the provision of customer services, instead of just a system-by-system tracking of system outages.
This scheme uses forecasts of the customer demand for various services for a given period, actual systems outage data, and a known relationship between systems and customer services to estimate the number of customers affected by system outages.

Description

CUSTOMER SERVICE IMPACT REPORTING
FIELD OF THE INVENTION
The field of the invention relates generally to systems and methods for assessing the impact of system failure or downtime.
BACKGROUND OF THE INVENTION
It is known for information technology operations to provide to the management of a business a listing of times when various computing systems are not operating (known as "outages", "down times" or "system outages" and the like, which for the purposes of this description shall be referred to as "outages") and to provide a numerical value of the percentage of time various computing systems were operational, often known as "percent availability".
While this method provides a way to measure the technology operations against a service level agreement of percent availability, it suffers from a number of drawbacks. It provides very limited information on which information technology decisions can be based. If a person is not familiar with the operations of the affected system, the information can be meaningless. Very few people within an organization are familiar with the operations of these systems. This problem increases with the size and complexity of systems used to facilitate customer service.
Alternative means of measuring system performance are desirable.
SUMMARY OF THE INVENTION
In a first aspect the invention provides a method for measuring the impact of system outages in a scheme of systems provisioned to support customer services. The method receives actual system outages data, and converts the actual system outages data to actual service interruptions data for customer services that are dependent on the systems.
The method also receives forecasts of customer transaction demand for customer services. The method calculates an estimated number of customers impacted by service interruptions using the actual service interruption data and the forecasts of customer transaction demand.
The method may measure the impact of system outages in a scheme of systems supporting automated customer services. The method may record the service interruptions data, and may record the forecasts of the customer transaction demand. The method may receive actual customer transaction data, use the actual customer transaction data to make new forecasts of the customer transaction demand; and record the new forecasts of the customer transaction demand. The method may receive platform outages data, and process the platform outages data to extract service interruptions data for customer services that are dependent on the platforms.
The method may also receive application outages data and process the application outages data to extract service interruptions data for customer services that are dependent on the applications. The method may determine a rounded number of customers impacted by service interruptions by rounding the number of customers impacted by service interruptions, and may use a recursive rounding logic to produce a non-zero rounded number. The method may record the rounded number of customers impacted by service interruptions. The method may communicate the rounded number of customers impacted by the interruptions via web-browser readable HTML code, or may communicate the rounded number of customers impacted by the interruptions in a form readable by dedicated analysis tools.
The method may calculate the estimated number of customers impacted by service interruptions using the actual service interruptions data and the forecasts of customer transaction 20732936.10 demand by constructing a set of rules reflecting the effect of simultaneous system failures on the provisioning of customer service transactions, using the rules to determine the percentage of total customers using a customer service impacted by the actual system outages, and multiplying the percentage of total customers using a customer service impacted by the system outages by the forecast of customer transaction demand to determine a number of customers denied use of a customer service by system outages.
The method may calculate the estimated number of customers impacted by service interruptions using the actual service interruptions data and the forecasts of customer transaction demand by constructing a set of rules reflecting the effect of simultaneous system failures on the provisioning of customer service transactions, assigning class codes to the systems to identify their relationship to other systems for the provisioning of customer service transactions in the event of simultaneous system failures, using the codes and the rules to determine the percentage of total customers using a customer service impacted by the actual system outages, and multiplying the percentage of total customers using a customer service impacted by the system outages by the forecast of customer transaction demand to determine a number of customers denied use of a customer service by system outages.
The method may calculate the estimated number of customers impacted by service interruptions using the actual service interruptions data and the forecasts of customer transaction demand by constructing a set of rules reflecting the effect of simultaneous system failures on the provisioning of customer service transactions, using the rules to determine the percentage of total customers using a customer service impacted by the actual system outages, multiplying the percentage of total customers using a customer service impacted by the system outages by the forecast of customer transaction demand to determine a number of transactions of a customer 20732956.10 service disrupted by system outages, and multiplying the number of transactions of a customer service disrupted by system outages by a ratio of customers to transactions to determine a number of customers denied use of a customer service by system outages.
The method may calculate the estimated number of customers impacted by service interruptions using the actual service interruptions data and the forecasts of customer transaction demand by constructing a set of rules reflecting the effect of simultaneous system failures on the provisioning of customer service transactions, assigning class codes to the systems to identify their relationship to other systems for the provisioning of customer service transactions in the event of simultaneous system failures, using the codes and the rules to determine the percentage of total customers using a customer service impacted by the actual system outages, and multiplying the percentage of total customers using a customer service impacted by the system outages by the forecast of customer transaction demand to determine a number of transactions of a customer service disrupted by system outages, and multiplying the number of transactions of a customer service disrupted by system outages by a ratio of customers to transactions to determine a number of customers denied use of a customer service by system outages.
The method may have an element in the class code reflect the position of a system in the hierarchy of systems provisioning a customer service. The method may have an element in the class code reflect the set of transactions of a customer service provisioned by a system.
In a second aspect the invention provides a method for measuring the impact of system outages in a scheme of systems provisioned to support customer services. The method receives system outages data for a first given time period, and converts the actual system outages data for the first given time period to actual service interruptions data for the first given time period for customer services that are dependent on the systems. The method also receives forecasts of 20732956.10 customer transaction demand for customer services for a second given time period. The method calculates an estimated number of customers impacted by service interruptions for the first given time period using the actual service interruption data for the first given time period and the forecasts of customer transaction demand for the second given time period.
The method may measure the impact of system outages in a scheme of systems supporting automated customer services. The method may calculate the number of customers impacted by service interruptions for the first given time period by calculating the maximum or the minimum number of customers impacted by service interruptions for the first given time period.
In a third aspect, the invention provides software on a computer readable medium for measuring the impact of system outages in a scheme of systems provisioned to support customer services. The software receives actual system outages data, and converts the actual system outages data to actual service interruptions data for customer services that are dependent on the systems. The software also receives forecasts of customer transaction demand for customer services. The software calculates an estimated number of customers impacted by service interruptions using the actual service interruption data and the forecasts of customer transaction demand. The software may measure the impact of system outages in a scheme of systems supporting automated customer services.
In a fourth aspect, the invention provides a computer data signal embodied in a carrier wave and representing sequences of instructions which, when executed by a processor, cause the processor to perform steps to measure the impact of system outages in a scheme of systems provisioned to support customer services. The processor receives actual system outages data, and converts the actual system outages data to actual service interruptions data for customer services 20732956.10 that are dependent on the systems. The processor also receives forecasts of customer transaction demand for customer services. The processor calculates an estimated number of customers impacted by service interruptions using the actual service interruption data and the forecasts of customer transaction demand.
In a fifth aspect, the invention provides apparatus for automating the measuring the impact of system outages in a scheme of systems provisioned to support customer services. The apparatus receives actual system outages data, and converts the actual system outages data to actual service interruptions data for customer services that are dependent on the systems. The apparatus also receives forecasts of customer transaction demand for customer services. The apparatus calculates an estimated number of customers impacted by service interruptions using the actual service interruption data and the forecasts of customer transaction demand.
The apparatus may measure the impact of system outages in a scheme of systems supporting automated customer services.
In other aspects the invention provides schemes, software, and processes for carrying out the methods of the above aspects.
BRIEF DESCRIPTION OF THE DRAWINGS
For a better understanding of the present invention and to show more clearly how it may be carried into effect, reference will now be made, by way of example, to the accompanying drawings which show the preferred embodiment and in which:
Figure 1 is a diagram of example dependencies of customer services on platforms and applications (systems) on which the preferred embodiment operates;
Figure 2A is a schematic of a customer service impact reporting scheme according to the preferred embodiment of the present invention;
20732936.10 Figure 2B is a schematic of a transaction database preparation scheme embodied in the scheme of Figure 2A;
Figure 2C is a schematic of a system outage database preparation scheme embodied in the scheme of Figure 2A;
Figure 3 is a flow chart of an annual hourly distribution process employed in the scheme of Figure 2A;
Figure 4 is a flow chart of a hourly distribution update process employed in the scheme of Figure 2A;
Figure 5 is an example of a normal hourly distribution table produced by the processes described in Figures 3 and 4 and employed in the scheme of Figure 2A;
Figure 6 is an example of a special days hourly distribution table produced by the processes described in Figures 3 and 4 and employed in the scheme of Figure 2A;
Figure 7 is a flow chart of a transaction database preparation process employed in the scheme of Figure 2B;
Figure 8A is a flow chart of a system outage database preparation process employed in the scheme of Figure 2C;
Figure 8B is an example of a business problem statement list used in the system outage database preparation process described in Figure 8A and employed in the scheme of Figure 2A;
Figure 8C is an example of a system outage reporting form used in the system outage database preparation process described in Figure 8A and employed in the scheme of Figure 2A;
Figure 9A is an example of a link {impact) table employed in the scheme of Figure 2A;
20732956.10 Figure 9B is an example of a set of rules employed in the scheme of Figure 2A;
Figure 9C is a diagram of example dependencies of customer service ABM Account Inquiries on platforms and applications on which the preferred embodiment operates;
Figure 10 is an example of a table of platform names employed in the link (impact) table employed in the scheme of Figure 2A;
Figure 11 is an example of a table of application names employed in the link (impact) table employed in the scheme of Figure 2A;
Figure 12 is a flow chart of an annual forecasting process employed in the scheme of Figure 2A;
Figure 13 is a flow chart of a monthly forecasting process employed in the scheme of Figure 2A;
Figure 14 is a flow chart of the customer impact computation process employed in the scheme of Figure 2A;
Figure 15 is an example of a rounding algorithm table used in the customer impact computation process described in Figure 14 and employed in the scheme of Figure 2A;
Figure 15A is an example of a transaction to customer ratio table used in the customer impact computation process described in Figure 14 and employed in the scheme of Figure 2A;
Figure 16 is a flow chart of a recursive rounding logic used in the customer impact computation process described in Figure 14 and employed in the scheme of Figure 2A;
20732936.10 Figure 17 is a layout of an SQL table for passing daily values of customer service impact numbers from the customer impact computation process of Figure 14 to a publishing process employed in the scheme of Figure 2A;
Figure 18 is a layout of an SQL table for passing monthly values of customer service impact numbers from the customer impact computation process of Figure 14 to the publishing process employed in the scheme of Figure 2A;
Figure 19 is a layout of an SQL table for passing service interruption level values of customer service impact numbers from the customer impact computation process of Figure 14 to the publishing process employed in the scheme of Figure 2A;
Figure 20 is a layout of an SQL table for passing control data from the customer impact computation process of Figure 14 to the publishing process employed in the scheme of Figure 2A;
Figure 21 is a flow chart of a CSIR Intranet publishing process employed in the scheme of Figure 2A;
Figure 22 is an output screen display of service interruption status information made available on a company Intranet website through the publishing process of Figure 2A;
Figure 23 is an output screen display of summary information regarding a particular service interruption made available on a company Intranet website through the publishing process of Figure 2A;
Figure 24 is an output screen display of gaphical information regarding customers impacted by service interruptions for a particular service on a daily basis over one month 20732956.10 made available on a company Intranet website through the publishing process of Figure 2A; and Figure 25 is an output screen display of service interruptions indicating the nature of the problem causing the interruption made available on a company Intranet website through the publishing process of Figure 2A.
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
The preferred embodiment described herein is applied in the financial services industry.
However, the principles described herein are not limited to the financial services industry, and could be applied in other "customer service" industries, including industries where the "customers" are other businesses (such as business to business e-commerce), as well as industries where the "customers" are members of the general public.
Although the examples of customer services in the preferred embodiment are examples of automated customer services (such as customer services provided through ATMs, Point of Sale devices, and teller terminals), the general principles as described herein can be applied to non-automated customer services as well.
Throughout this description, the terms "database" and "table" are used. It should be recognized that the databases could equally well be stored as separate tables in a common database, and the tables could be stored as separate databases, without departing from the general principles described herein.
The appropriate time periods for collecting data and running the various processes and updates and performing calculations depends upon the nature of the business and services being analyzed. In the preferred embodiment, data is collected and the processes run on an hourly, 20732956.10 monthly, daily and yearly basis: however, the principles described herein are not limited to such time periods.
Referring to Figure 1, a financial institution's information technology may be viewed as a set of systems 110, made up of platforms 112 and application software, or "applications" 114, that provide services 116 to a user, hereinafter referred to as customer 118.
Platforms 112 are hardware and associated operating system level software, not shown. As seen in Figure 1, services 116 as seen by customers 118 may be reliant on a wide variety of applications 114 running on different platforms 112.
For example, service ABM PIN code changes 120 relies on application CSP 122 running on platforms SY01 124, LNP28 126 and LNP27 128; as well as on application ATM

running on platforms LNP26 132, LNP27 134, LNP28 136 and LNP 29 138. Different outages amongst the various platforms and applications may have very different effects upon the delivery of service 120 to customers 118. For example, platforms 132, 134, 136 and 138 may be supporting services 116 in four different geographic regions. If one of these platforms 132, 134, 136 or 138 had an outage, the outage would affect only some, but not all, of customers 118 when they attempted to access service 120. Such an outage would have no effect upon customers 118 if they tried to access service POS debit card purchases 140.
However, it may also be the case that application CSP 122 running on platform is a necessity for all services 120, so an outage on platform 124 will deny all customers 118 access to service 120. Finally, application CSP 122 running on platforms LNP28 126 and LNP27 128 may be a redundant system, so that a failure in either platform LNP28 126 or LNP27 128 (but not both simultaneously) will have no adverse effect upon the delivery of service 120 to customers 118.
20732956.10 Similarly, outages in any of the applications CSP 122 or ATM 130 may have an adverse effect on the delivery of service 120 to customers 118. As outages in either platforms or applications may aiTect service delivery, this description uses the term "system" 110 to refer to both applications 114 and platforms 112.
As a further complication, it should be noted that any of the systems 110 may be supplied, supported and maintained either by external providers or by internal information technology departments.
Referring to Figure 2A, many drawbacks inherent in percent system availability reporting may be met by a customer service impact reporting ("CSIR") scheme 202. The purpose of CSIR
scheme 202 is to establish an overall measure of how well information technology systems 110 are performing from the customers' 118 perspective of the provision of customer services 116, instead of just a system-by-system tracking of system 110 outages.
The CSIR scheme 202 has four main daily processes 210: Impact Computation 212, Intranet Publishing 214, CIA Viewing 216 and Hourly Distribution 218.
Hour~r Distribution 218: Hourly distribution tables 219 and 221, as will later be discussed with respect to Figures 5 and 6, provide hourly maximum and minimum customer transaction demand for a service 116 as a percentage of total daily transaction demand, and are stored in daily forecasts and hourly distribution database 220. The hourly distribution tables 219 and 221 are updated daily using the hourly volume of transactions obtained from transactional data in hourly distribution update process 218.
There are two hourly distribution tables: the special days hourly distribution table 219;
and the "normal" hourly distribution table 221. A transaction is a customer 118 use of a service 116.
20732956.10 Transactional data is extracted daily, on the next business day, through automated processes from log files of the business' business transaction processing systems or business data, and stored in daily transactional database 222. The transaction data provides the actual hourly volume of transactions for each of the customer services 116, and is used in hourly distribution process 218.
Impact Computation 212: The Impact Computation process 212 calculates the number and percentage of potentially impacted customers for identified customer service interruptions and totals for the day and month. The main inputs for the computation are the system outage data from system outage database 224, the daily forecasts and the hourly distribution from daily forecasts and hourly distribution database 220.
System outage data is extracted daily, on the next business day, through automated processes (not shown) from external provider and internal information technology department outage log files of systems 110 as further described with reference to Figure 2C. The extracted information consists of the platform, application, date, start and end times of the system outage, and a business problem statement applicable to the system outage. The system outage data is converted to service interruption data in customer impact computation process 212.
The computation also requires several internal tables:
~ a link (impact) table 213 (to be described with reference to Figure 9), which provides an impact percentage for every customer service 116;
~ a transaction to customer ratio table 215 (to be described with reference to Figure 15A) which provides the average ratio of customer transactions to customers 118 for 20732956.10 each different type of customer service 116 (and is used to convert the number of transactions imported to the number of customers 118 impacted);
~ a rounding algorithm table 217 (to be described with reference to Figure 15), which provides initial rounding criteria for rounding off customer impact numbers;
~ a generic platform name table 256 (to be described with reference to Figure 10) and a generic application name table 254, which provide translations of the technical names of platforms and applications to plain text names, suitable for use in publishing processes.
Customer services 116 are defined at the level of services 116 that are actually used by the customer 118, rather than the systems 110 that support the provisioning of the customer services 116. For example, in a financial institution, customer services 116 may include Automatic Bank Machine ("ABM") PIN code changes 120, ABM account inquiries 142, ABM bankbook updates 144, ABM bill payments 146, ABM deposits 148, ABM PIN code changes 120, ABM transfers 150, ABM withdrawals 152, and Point of Sale ("POS") debit card purchases 140.
Publishing 214: The outputs from the impact computation process 212 are saved in tables 227 which are saved in CSIR publishing database 226. In the preferred embodiment tables 227 are stored in a structured query language ("SQL") format.
Intranet publishing process 228 accesses the SQL tables 227 and other daily textual publishing data, pre-builds HTML pages, such as those described in Figures 22-25, of impact information and stores them on server 233.
20732956.10 These HTML pages report daily and monthly results of the CSIR scheme 202 and are viewable by users 230 through a company Intranet (not shown). In the preferred embodiment it was found desirable, although not strictly necessary, that the HTML pages make available the published information of numbers and percentage of customers 118 impacted daily, and the trends for the current month as well for the past 15 months.
CIA Viewing Tools 216: The outputs from the impact computation process 212 are also saved in tables 229 which are saved in Customer Impact Analysis ("CIA") database 232. In the preferred embodiment, Table 229 is also in an SQL format.
The CIA tools 216 are set up to allow management groups 234 to access the information .
stored in CIA database 232 to perform comparative analysis of the impacts with other related information. This tool facilitates better understanding of the customer service impacts by various management groups 234, and allows the selection of timing for changes to applications 114 and platforms 112 to minimize customer 116 disruption.
The daily forecasts are updated monthly (using the recent actual transactional volumes) by monthly forecasting process 240. Monthly forecasting process 240 uses the data stored in CIA database 232 to make these forecasts. The resulting forecast of daily volumes of customer service transactions is a key input to the impact computation process 212, and is stored in daily forecasts and hourly distribution database 220. There are two forecasts: the special day forecast 223; and the "normal" daily forecasts 225. During the running of monthly forecasting process 240, additional input by the business' service teams 234 may be taken to allow adjustments to reflect business factors.
20732936.10 The daily forecasts and hourly distribution tables 219, 221, 223 and 225 are initially created (using historical transactional volumes) by annual forecasting process 236 and annual hourly distribution processes 238, which are run once a year to update special day forecast table 223 and special day hourly distribution table 219. Annual forecasting process 236 and annual hourly distribution processes 238 access the data in CIA database 232 to perform their calculations.
In the preferred embodiment, the daily CSIR processes 212, 218, 214 and 216 run on two separate Windows/NT servers: server 231 to host the impact computation process 212 and hourly distribution update process 218; and server 233 to host the publishing process 214 and CIA tools 216. The forecasting processes 236, 238 and 240 run on a separate server 235.
Referring to Figure 2B, transaction log files 244 and data warehouse files 246 are accessed by transaction database preparation process 242 to prepare transaction database 222.
Referring to Figure 2C, external provider system outage log files 250 and internal information technology department system outage files 252 are accessed by system outage database preparation process 248 to prepare system outage database 224.
Referring to Figure 3, annual hourly distribution process 238 first accesses special day calendar and special day transaction histories stored in CIA database 232 in step 310. Special days are days with unusual patterns of customer service demand, such as Christmas, Thanksgiving or other national or religious holidays.
A ratio of the maximum and minimum hourly demand for each customer service 116 to the total daily demand for the customer service 116 (expressed as a percentage) is calculated for every hour of every special day in step 312. The resulting special day hourly distribution table 219 is saved in daily forecasts and hourly distribution database 220 as step 314.
20732956.10 Similarly, process 238 then accesses the historical transaction data stored in CIA database 232 in step 316. A ratio of the maximum and minimum hourly demand for each customer service 116 to the total daily demand for the customer service 116 (expressed as a percentage) is calculated for every hour of every day of the week in step 318. The resulting hourly distribution table is saved in daily forecasts and hourly distribution database 220 as step 320.
As noted above, annual hourly distribution process 238 is run at the initialization of the CSIR scheme 202, and is thereafter run once a year to refresh special day hourly distribution table 219.
Hourly distribution tables 221 is thereafter updated daily by hourly distribution update process 218.
Referring to Figure 4, hourly distribution update process 218 first accesses the customer service transaction data from transaction database 222 and the daily system outage data in database 224 in step 410. Process 218 matches the customer service transaction data with the service outage data to determine if a particular customer service 116 has experienced an interruption in step 412. If it has been determined that a service 116 interruption has occurred for the customer service 116 on the processing day, the transactional volumes are not analyzed for purposes of updating the daily customer demand tables, as shown in step 414.
If it has been determined that there has been no interruption, the service transaction volumes for the day are analyzed and compared to that weekday's or special day's hourly distribution values in step 416. Step 416 calculates, for each customer service 116, the service transaction demand for each hour as a percentage of the day's total service transaction demand.
If the percentage is less than the value stored in the relevant hourly distribution table 219 or 221 as the minimum value for that how, then the relevant hourly distribution table 219 or 221 is 20732956.10 updated with the new minimum value. Conversely, if the percentage is more than the value stored in the relevant hourly distribution table 219 or 221 as the maximum value for that hour, then the relevant hourly distribution table 219 or 221 is updated with the new maximum value.
The relevant hourly distribution table 219 or 221 in the daily forecasts and hourly distribution database 220 to be updated depends on whether the day is a special day, as seen in decision step 418. If the day is a special day, the hourly distribution table 219 or 221 that is updated is the special day hourly distribution table 219 in step 420. If the day is not a special day, the normal hourly distribution table 221 is updated if necessary in step 422. The resulting new and revised records are stored in daily forecasts and hourly distribution database 220, and are available for daily computation procedure. All results are also stored in CIA database 232, and may be viewed using CIA analysis and viewing tools 216.
Referring to Figure 5, there is an example of the normal hourly distribution table 221 stored in daily forecasts and hourly distribution database 220. Column 510 lists the various customer services 116 monitored by the CSIR scheme 202 and whether the information is a minimum or maximum, column 512 lists the days of the week, and columns 514 lists the hourly percentage of the day's total service demand from hour zero (midnight to 1 a.m.) to hour 24 (11 p.m. to midnight).
Referring to Figure 6, there is an example of a special days hourly distribution table 219 stored in daily forecasts and hourly distribution database 220. Column 610 lists the name of the special day, column 612 lists the customer services 116, column 614 lists the date of the special day for the current year, and columns 616 lists the minimum and maximum hourly percentage for all 24 hours of the special day as a percentage of the total daily demand for the customer service 116 on the indicated special day.
20732956.10 Referring to Figure 7, the steps undertaken by transaction database preparation process 242 are illustrated. The process 242 first receives automated data feeds from transaction log files 244 and data warehouse files 246 in step 710. It then matches the data to the customer services in step 712, and sums the actual customer demand for each service 116 for every hour in step 714. The results are saved in transaction database 222.
Referring to Figure 8A, the steps undertaken by system outage database preparation process 248 are illustrated as a flow chart. The process first accesses the external service providers' system outage log files 250 in step 810, and accesses the internal information technology system outage files 252 in step 812. In step 814, process 248 selects the system outages that are relevant for the CSIR scheme 202 using the data in the link (impact) table 213.
Finally, in step 816, the selected system outage data is saved in system outage database 224.
When a system outage occurs, an application support analyst fills out a system outage reporting form, an example of which is given as Figure 8C, which is entered into a computerized problem tracking system (not shown). The analyst enters a platform name (choosing from the platform name list pictured in Figure 10, described below) into column 818 or application name (choosing from the application name list pictured in Figure 11, described below) into column 820 of the failed element; the time and date the system outage started and ended into columns 822 to 828; and optionally a problem name (choosing from the business problem statement list pictured in Figure 8B) into column 832. This data is then saved to internal information technology files 246 or external service provider files 244.
Referring to Figure 8B, there is a column 811 of example short form problem names, and a column 813 of corresponding full text business problem statements.
20732956.10 Referring to Figure 12, the steps of annual forecasting process 236 are given as a flow chart. In initial step 1210 annual forecasting process 236 accesses CIA
database 232 to obtain the historical transaction volumes for special days as well as a calendar of special days. In step 1212, input may be obtained from management groups 234 for any special considerations that may affect the forecast. From the historical data, a forecast of the total demand for each special day for every customer service 116 is made in step 1214. In step 1216, the special day forecast table 223 is created by including the specific dates of the special days, and is saved in daily forecasts and hourly distribution database 220.
Similarly, in step 1218, annual forecasting process 236 accesses CIA database 232 to obtain the historical transaction volumes for normal days, a history of service interruptions and a listing of unusual events. In step 1220, input may be obtained from management groups 234 for any special considerations that may affect the forecast. From the historical data, a forecast of the total demand for each normal day for every customer service is made in step 1222, disregarding any data that is affected by a service interruption or an unusual event. If any anomalous patterns of demand are noted that are not accounted for in the unusual events listing, a flag may be created to alert management reviewers 234 to a possible unidentified unusual event. Finally, in step 1224, the daily forecast table 225 is created, and is saved in daily forecasts and hourly distribution database 220.
There are a number of forecasting methods that could be used to make these forecasts, including multiple regression models, ARIMA (Auto Regressive Integrated Moving Average), AutoReg (Automatic Regression) or Winters methods, or Xl 1 (as used by the U.
S. Census Bureau).
20732956.10 Process 236 should be re-run once a year to refresh the special day hourly distribution table 219 with the correct dates for the upcoming year, and to look for unidentified unusual events.
Referring to Figure 13, the steps in monthly forecasting process 240 are given in a flow chart. In step 1310, monthly forecasting process 240 accesses CIA database 232 to obtain the historical transaction volumes for normal days, recent transaction volumes for normal days, and a listing of recent service interruptions ("recent" transactions will be those performed since the last running of a forecasting process). In step 1312, input may be obtained from management groups 234 for any special considerations that may affect the forecast. From the historical and recent data, a forecast of the total demand for each normal day for every customer service 116 is made in step 1314, disregarding any data that is affected by a service interruption. Finally, in step 1316, the daily forecast table 225 is created, and is saved in daily forecasts and hourly distribution database 220.
Referring to Figure 9A, an example of a link(impact) table 213 is given.
Columns 910 and 912 hold the platform name and application name for the various computing systems 110 monitored by CSIR scheme 202. Columns 914 hold the percentage values measuring the impact of the various systems 110 on various customer services 116.
The platform and application code names are related to their descriptive, though technical, names in a platform name table 256, illustrated as Figure 10, and an application name table 254, illustrated as Figure 11.
Referring to Figure 10, column 1010 lists code names of computer platforms 112 monitored, and column 1012 gives a plain text description of the platforms 112.
20732956.10 Referring to Figure 11, column 1110 lists code names of the applications 114 monitored, and column 1112 gives a plain text description of the applications 114.
Link (impact) table 213 correlates the platforms 112 and applications 114 to the services 116 supported by the platforms 112 and applications 114. Through columns 914, link (impact) table 213 also provides a measure of the extent to which failures in various systems 110 will affect customer services 116. For example, referencing row 920, it may be seen that a failure in platform SY01, running application CSP, will affect 100 percent of the "ABM
PIN Code Changes" customer service 120 transactions. However, referencing row 922, a failure in platform LNP28 running application CSP will only affect 50 percent of the "ABM
PIN Code Changes" customer service 120 transactions.
Reflecting these complications, a set of rules 909 (Figure 9B) should be created to prevent double counting when a customer service 116 is impacted by the simultaneous failures of more than one system 110. Referring to Figure 1, for example, suppose that simultaneous system outages occurred in platforms SY01 and LNP28. The outage of SY01 affects 100% of the ABM PIN Code Changes 120, while the outage of LMP28 affects only 50% of the ABM PIN
Code Changes 120. It would be an error to sum these figures and determine that 150% of the ABM PIN Code Change transactions during this period were affected: 100% is the maximum possible failure rate.
Referring to Figure 9B, the set of rules 909 chosen for the preferred embodiment assign to each system 110 a class code 919, consisting of a first element given in column 916 and a second element given in column 918, which classifies the systems 110 by priority of impact on services 116. This class code 919 is used to implement rules 909 in the customer impact computation process 212 to determine a correct total percentage of transactions affected when 20732956.10 presented with multiple simultaneous system 110 failures. Although the preferred embodiment utilizes a specific set of class codes 919 and rules 909, it will be evident to those skilled in the art based on the principles described herein that the rules 909 and corresponding class codes 919 may take alternate forms, some of which are described below.
In the preferred embodiment, the first element of class code 919 given in column 916 reflects the hierarchy of how the platform 112 and application 114 combination (from columns 910 and 912) interacts with other platform 112 and application 114 combinations in provisioning customer services 116.
An example of this is illustrated in Figure 9C. Referring to Figure 9C, suppose the application INST-UPD 930 running on platform SY05 932 (row 926 in link (impact) table 213 of Figure 9A) is an application that provisions every transaction of customer service ABM Account Inquiries 142 in cities CAL, VAN, HAL and OTT (indicated as 934, 937, 936 and 938); while the application SAV-CAL 940 also running on platform SY05 932 (row 928 in link (impact) table 213 of Figure 9A) is an application 114 that provisions only the subset of transactions of customer service ABM Account Inquiries 142 located in a particular city CAL
934. If the application SAV-CAL 940 experiences an outage, it will interrupt customer service ABM
Account Inquiries 142 for only its subset of transactions in city CAL 934. All other transactions in city HAL 936, city VAN 937 and city OTT 938 of customer service ABM Account Inquiries 142 will be unaffected. In contrast, if application INST-UPD 930 experiences an outage, all transactions of customer service ABM Account Inquiries 142 will be interrupted, including those in city CAL 934. Furthermore, if application INST-UPD 930 experiences an outage, a further outage of application SAV-CAL 940 will not interrupt any additional transactions of customer service ABM Account Inquiries 142. In contrast, if application SAV-CAL 940 experiences an 20732956.10 outage, a further outage of application INST-UPD 930 will interrupt additional transactions of customer service ABM Account Inquiries 142. As a result, application INST-UPD
930 running on platform SY05 932 is highest in the hierarchy of platforms 112 and applications 114 provisioning customer service ABM Account Inquiries 142, and receives a first element of class code 919 of 1. Application SAV-CAL 940 running on platform SYOS 932 is secondary in the hierarchy of platforms 112 and applications 114 provisioning customer service ABM Account Inquiries 142, and receives a first element of class code 919 of 2. Similarly, the first element of class code 919 for applications SAV-VAN 946, SAV-HAL 942 and SAV-OTT 944 running on platform SOS 932 is also 2.
It should be noted that in the example illustrated in Figure 9C, if platform experiences an outage, all applications 930, 940, 942, 944 and 946 will be affected, and all customer service ABM Account Inquiries 142 in cities CAL, VAN, HAL and OTT
will be interrupted. This is an identical result to an outage of application INST-UPD
930 simultaneously with an outage of application SAV-CAL 940.
Referring to Figure 9C, the second element of class code 919 given in column indicates whether the platform 112 and application 114 combination (from columns 910 and 912) provisions customer services from distinct subsets of customers 118 or for overlapping sets of customers 118. Suppose that the transactions for customer service ABM
Account Inquiries 142 occurring in cities VAN and CAL are assigned to a subset of transactions "A", indicated by a dotted box 950, and that the transactions for customer service ABM Account Inquiries 142 occurring in cities HAL and OTT are assigned to a subset of transactions "B", indicated by a dotted box 952.
20732956.10 The application 114 and platform 112 combination of application SAV-VAN 946 running on platform SY05 932 provisions customer service ABM Account Inquiries 142 in subset of transactions "A" 950, so the second element of its class code 919 is A. Similarly, the second element of class code 919 for application SAV-CAL 940 running on platform SY05 932 is A.
In contrast, the application 114 and platform 112 combination of application SAV-HAL
942 running on platform SY05 932 provisions customer service ABM Account Inquiries 142 in subset of transactions "B" 952, so the second element of its class code 919 is B. Similarly, the second element of class code 919 for application SAV-OTT 142 running on platform SY05 932 is B.
Finally, the application 114 and platform 112 combination of application INST-running on platform SY05 932 provisions customer service ABM Account Inquiries 142 for both subsets of customers "A" 950 and "B" 952, so it is assigned a second element of its class code 919 of C.
The class codes 919 for the platforms and applications illustrated in Figure correspond with the class codes in rows 926, 928, 921, 923 and 925 in link (impact) table 213 in Figure 9.
However, it should be emphasized that these particular interpretations of the class code 919 are dependent upon the particular implementation of the preferred embodiment. The class code 919 could contain more or less columns, reflect different aspects of the platforms 112 or applications 114, or consist of numbers or letters without changing the general principles described herein. In particular, the division by cities and into a hierarchy in the preferred 20732956.10 embodiment reflects the particular facts of the preferred embodiment, and may not be desirable or possible in other contexts.
In the preferred embodiment, the following rules 909, given in Figure 9B, would correspond with the above-noted code:
1) When the first and second elements of the class codes are the same, add the percentage impact values.
This first rule of rules 909 indicates that if the systems at the same hierarchical level (as indicated by identical first elements of class code 919), it is appropriate to add the percentage impacts to get a total percentage impact. Since the systems will affect the same set of customers (as indicated by identical second elements of class code 919), they cannot by design sum to greater than 100% and give an incorrect total percentage.
2) When the first elements of the class codes are different and the second elements of the class codes are the same, select the higher percentage impact value.
This second of rules 909 indicates that if the systems affect the same subset of customers (as indicated by identical second elements of class code 919) but the two systems are at different hierarchical levels (as indicated by different first elements of class code 919), it is appropriate to select the higher percentage impact value.
20732936.10 3) When the second elements of the class codes are different, add the percentage impact values, to a maximum of 100%.
This third of rules 909 indicates that if the systems affect different sets of customers (as indicated by differing second elements of class code 919), it is appropriate to add the percentage impact values. However, since there is the potential for overlap of customers (if, for example, the two systems had second element of class code 919 of "A" and "C"
respectively), the sum must be capped to a maximum of 100% to prevent double counting.
Once again, these specific rules 909 reflect the specific circumstances of systems and services used in association with the preferred embodiment. Different rules 909 could be used without changing the general principles described herein. If the matrix of platforms 112, applications 114 and services 116 in the preferred embodiment were to change, a different set of rules 909 and class codes 919 might be necessary.
The platforms analyzed in the preferred embodiment are "major" platforms, that provision customer services 116 across a relatively wide geogaphic area. It is possible to extend the general principles described herein to apply this approach to "minor" or individual platforms, such as individual ABM machines.
It should be noted that the link (impact) table 213 provided as an example in Figure 9A is listed by platforms 112. Those skilled in the art will appreciate that a similar table could also be listed by applications 114 without significantly altering the principles described herein.
Referring to Figure 14, the steps performed in customer impact computation process 212 are given as a flow chart. Process 212 first accesses system outage database 220 to load the 20732956.10 system outages and the times of the outages in step 1410. For the first customer service (step 1412), for the first minute of the day (step 1414), customer impact computation process 212 determines the percentage impact for every system outage during that minute (step 1416).
Customer impact computation process 212 then applies the rules 909, using link (impact) table 213, to determine a total impact percentage in step 1418.
The next step depends on whether the day being analyzed is a special day, as noted in decision box 1420. If it is not a special day, customer impact computation process 212 in step 1422 multiplies:
the daily forecast for the day being analyzed (for the service being analyzed, from daily forecast table 225); times the minimum or maximum hourly distribution (for the service being analyzed and the appropriate hour, from hourly distribution table 221); times (1/60) (to estimate the number of potentially impacted transactions in the minute); times the total impact percentage (for the impacted service, as calculated in step 1418); times the customers to transactions ratio (for the impacted service, from transaction to customer ratio table 215).
If it is a special day, customer impact computation process 212 in step 1424 multiplies:
the special day daily forecast for the day being analyzed (for the service being analyzed, from special day daily forecast table 223); times the minimum or maximum special day hourly distribution (for the service being analyzed and the appropriate hour, from special day hourly distribution table 219);
times (1/60) (to estimate the number of potentially impacted transactions in the minute); times the total impact percentage (for the impacted service, as calculated in step 1418); times 20732956.10 the customers to transactions ratio (for the impacted service, from transaction to customer ratio table 215).
The transaction to customer ratio table 215 will have been previously constructed using historical data from previous transactions. An example of a transaction to customer ratio table 215 is given in Figure 15A, where column 1 S 14 lists customer services 116 and column 1516 lists the average number of transactions per customer for the service 116. For example, it might be found that the average customer 118 using customer service ABM bill payments 146 performs 1.5 bill payments. If 1500 ABM bill payments 146 are affected by a service interruption, the service interruption will have affected approximately 1000 customers 118.
Step 1422 or 1424 is performed for both the maximum and minimum values from the hourly distribution and special day hourly distribution tables 221 and 219.
This analysis is repeated for every minute of the day, as indicated by decision step 1426.
When the final minute of the day (23:59 to midnight) has been analyzed, process 212 sums the minimum and maximum numbers of customers 118 impacted for consecutive minutes in step 1428, stopping when the customer service 116 is restored. For example, if a service 116 was available from 11:04 to 11:05, interrupted between 11:05 and 11:08, and available again at 11:08 to 11:09, process 212 would sum the minimum and maximum customer impact numbers for the minutes 11:05 to 11:06, 11:06 to 11:07, and 11:07 to 11:08, to create a minimum and maximum number of customers 118 impacted that service 116 interruption. Since a customer service 116 may be interrupted several times during the day, each separate interruption (defined as above as a series of consecutive minutes of service 116 interruption) is given a sequence number: 1 for the first interruption during that day, 2 for the second, etc.
20732956.10 The minimum and maximum number of customers 118 impacted is then rounded in step 1428 using the initial rounding criteria in the rounding algorithm table 217 and a recursive rounding logic. Refernng to Figure 15, an example of a rounding algorithm table 217 is given.
Column 1510 lists the impacted service 116 to be rounded, and column 1 S 12 lists the initial rounding criteria to be used.
Referring to Figure 16, the recursive rounding logic used in step 1428 is illustrated. The minimum or maximum number of customers 118 impacted is first rounded using the initial rounding criteria (for the impacted service) from the rounding algorithm database in step 1610.
For example, a value of 443 rounded to the nearest 1000 is 0. Next, the rounding logic assesses whether the rounded value of the minimum or maximum number of customers 118 impacted is non-zero in decision step 1612. If it is, the rounded minimum or maximum number of customers 118 impacted is reported in step 1614. If the rounded minimum or maximum number of customers 118 impacted is zero, then the rounding criteria is divided by 10 in step 1616, and the minimum or maximum number of customers 118 impacted is rounded using the new rounding criteria in step 1618. For example, the value of 443 would now be rounded to the nearest 100 to reach a rounded value of 400. As is shown in Figure 16, the recursive rounding logic used in step 1424 then recursively returns to step 1612.
The above calculations are repeated for every customer service 116 being tracked by the CSIR scheme 202, as noted in decision step 1430 of Figure 14.
The above calculations including the use of rules 909 may be demonstrated through the following example. Suppose that the following nine system 110 outages occur during a day:
System Platform ApplicationStart TimeEnd Time Code Percentage Outage Impact from link im act 20732956.10 .._ table 213 ~ ~

1 SY05 SAV-REG 10:05 10:15 2A 0.434 2 SY05 PCA-REG 10:05 10:15 2A 2.375 3 LNP26 ATM 10:09 10:12 lA 25 4 SY05 SAV-REG 10:25 10:35 2A 0.434 SY05 PCA-REG 10:25 10:35 2A 2.375 6 LNP28 ATM 10:29 10:32 1B 25 7 SY05 SAVINGS 10:45 10:55 2C 16.6810 8 SY05 PCA- 10:45 10:55 2A 71.575 BANK

9 LNP28 ATM 10:49 10:52 1B 25 For this example, the daily forecast for the ABM Account Inquiries service 142 is 240,000 transactions, the maximum Hourly Distribution for the hour from 10:00 to 11:00 is 0.1, the customer to transaction ratio for the ABM Account Inquiries service 142 is (1/1.09) = 0.917, and the initial rounding criteria from the rounding algorithm table 217 is 100.
For the minutes from 10:05 to 10:09 and from 10:12 to 10:15, outages 1 and 2 are occurring. Since the codes for these outages are 2A and 2A, applying the first of rules 909 for identical codes, the percentage impacts are added together to get a total percentage impact of 2.809% in step 1418. For the minutes from 10:09 to 10:12, outages 1, 2 and 3 are occurring.
Since the codes for these outages are 2A, 2A and lA, applying the second of rules 909 for codes that differ in their first element but are identical in their second element, the highest percentage impact is selected to get a total percentage impact of 25% in step 1418.
To determine the number of transactions impacted per minute in step 1422, for the minutes from 10:05 to 10:09 and from 10:12 to 10:15, the daily forecast of 240,000 is multiplied by the maximum hourly distribution of 0.1, multiplied by (1/60), multiplied by the total percentage impact of 2.809%, multiplied by the customer to transaction ratio of 0.917, for a maximum number of customers 118 impacted per minute of 10.303. Similarly, for the minutes from 10:09 to 10:12, the daily forecast of 240,000 is multiplied by the maximum hourly 20732956.10 distribution of 0.1, multiplied by (1/60), multiplied by the total percentage impact of 25%, multiplied by the customer to transaction ratio of 0.917, for a maximum number of customers impacted per minute of 91.7.
These numbers are summed in step 1428 for the minutes from 10:05 to 10:15 to generate a maximum number of customers 118 impacted for this service 116 interruption of 438.923, which is rounded to 400. Since this is the first interruption of the day for the ABM Account Inquiries service 142, this interruption is assigned a sequence number of 1.
For the minutes from 10:25 to 10:29 and from 10:32 to 10:35, outages 4 and 5 are occurring. Since the codes for these outages are 2A and 2A, applying the first of rules 909 for identical codes, the percentage impacts are added together to get a total percentage impact of 2.809% in step 1418. For the minutes from 10:29 to 10:32, outages 4, 5 and 6 are occurring.
Since the codes for these outages are 2A, 2A and 1B, applying the third of rules 909 for codes that differ in their second element, the percentage impacts are summed to get a total percentage impact of 27.809% in step 1418.
To determine the number of transactions impacted per minute in step 1422, for the minutes from 10:25 to 10:29 and from 10:32 to 10:35, the daily forecast of 240,000 is multiplied by the maximum hourly distribution of 0.1, multiplied by (1/60), multiplied by the total percentage impact of 2.809%, multiplied by the customer to transaction ratio of 0.917, for a maximum number of customers 118 impacted per minute of 10.304. Similarly, for the minutes from 10:29 to 10:32, the daily forecast of 240,000 is multiplied by the maximum hourly distribution of 0. l, multiplied by (1/60), multiplied by the total percentage impact of 27.809%, multiplied by the customer to transaction ratio of 0.917, for a maximum number of customers 118 impacted per minute of 102.003.
20732956.10 These numbers are summed in step 1428 for the minutes from 10:25 to 10:3 S to generate a maximum number of customers 118 impacted for this service interruption of 480.137, which is rounded to 500. Since this is the second interruption of the day for the ABM
Account Inquiries service 142, this interruption is assigned a sequence number of 2.
For the minutes from 10:45 to 10:49 and from 10:52 to 10:55, outages 7 and 8 are occurring. Since the codes for these outages are 2C and 2A, applying the third of rules 909 for identical codes, the percentage impacts are added together to get a total percentage impact of 88.256% in step 1418. For the minutes from 10:29 to 10:32, outages 7, 8 and 9 are occurring.
Since the codes for these outages are 2C, 2A and 1B, applying the third of rules 909 for codes that differ in their second element, the percentage impacts are summed to get a total percentage impact of 113.256% which is capped at 100%, in step 1418.
To determine the number of transactions impacted per minute in step 1422, for the minutes from 10:45 to 10:49 and from 10:52 to 10:55, the daily forecast of 240,000 is multiplied by the maximum hourly distribution of 0.1, multiplied by (1/60), multiplied by the total percentage impact of 88.256%, multiplied by the customer to transaction ratio of 0.917, for a maximum number of customers impacted per minute of 323.723. Similarly, for the minutes from 10:49 to 10:52, the daily forecast of 240,000 is multiplied by the maximum hourly distribution of 0. l, multiplied by (1/60), multiplied by the total percentage impact of 100%, multiplied by the customer to transaction ratio of 0.917, for a maximum number of customers impacted per minute of 366.8.
These numbers are summed in step 1428 for the minutes from 10:45 to 10:55 to generate a maximum number of customers 118 impacted for this service interruption of 3733.261, which 20732956.10 is rounded to 3700. Since this is the third interruption of the day for the ABM Account Inquiries service 142, this interruption is assigned a sequence number of 3.
Finally, in step 1432 the rounded minimum and maximum numbers of customers 118 impacted with their associated sequence numbers (and, optionally, problem statements) are then saved in SQL tables 227 and 229 in CSIR publishing database 226 and CIA
database 232 respectively, in association with information on the system failure and time of the outage.
Examples of SQL databases 227 and 229 are provided as Figures 17 to 20.
Referring to Figure 17, the SQL table is generally referred to as 1710. Table 1710 refers to service impacts reported on a daily basis. Row 1712 lists the customer service 116 name, row 1714 lists the date the service 116 interruption occurred, and row 1716 gives the sequence number. Row 1718 lists the (rounded) minimum number of customers 118 affected, row 1720 lists the (rounded) maximum number of customers 118 affected, row 1722 lists the minimum number of customers 118 affected as a percentage of the days total number of customers 118, and row 1724 lists the maximum number of customers 118 affected as a percentage of the day's total number of customers 118.
Row 1726 notes if the report has been revised (in Figure 17, the report has not been revised), row 1728 lists the date the report was printed, row 1730 lists a business problem description for the service interruption, and row 1732 lists a generic name of the system causing the service interruption.
Columns 1734 and 1736 list the data for the customer services "Point of Sale Debit Card Purchases" 140 and "ABM PIN Code Changes" 120, respectively.
Referring to Figure 18, the table generally referred to as 1808 reports service interruptions on a monthly basis. Row 1810 lists the customer service 116, row 1812 lists the 20732936.10 date of the reported interruption, row 1814 lists the sum of the rounded minimum numbers of customers 118 impacted for the service for the month, row 1816 lists the sum of the rounded maximum numbers of customers 118 impacted for the month, row 1818 lists the average rounded minimum number of customers 118 affected for every service 116 interruption, row 1820 lists the average rounded maximum number of customers 118 affected for every service 116 interruption, row 1822 indicates whether these numbers have been revised (in Figure 17, they have not been revised), and row 1824 lists the date the table was printed. Columns 1828 and 1826 list the data for the customer services "Point of Sale Debit Card Purchases" 140 and "ABM PIN Code Changes" 120, respectively.
Referring to Figure 19, the table generally indicated by 1908 contains information for each service 116 interruption. Row 1910 indicates the customer service 116, row 1912 indicates the date of the service 116 interruption, row 1914 lists a sequence number, rows 1916 and 1918 list a start and end time for the interruption, row 1920 lists the interruption time in minutes (reflecting the consecutive minutes found in step 1428, Figure 14), rows 1922 and 1924 list the minimum and maximum number of customers 118 impacted, row 1926 indicates whether this report has been revised subsequent to the calculation (in Figure 19, both reports have been revised), and row 1928 indicates the date the report was updated. Columns 1930 and 1932 list the data for the customer services "Point of Sale Debit Card Purchases" 140 and "ABM PIN
Code Changes" 140, respectively.
Referring to Figure 20, the "control data" table is indicated generally as 2010. Row 2012 lists the customer services 116, row 2014 lists the date of the reported service 116 interruption, row 2016 lists the customer to transaction ratio for the service 116 (also seen in customer to transaction ratio table 215 in Figure 15A), row 2018 shows the date the report was printed, and 20732956.10 row 2020 lists the rounding criteria for the services 116 (also seen in rounding algorithm table 217 as illustrated in Figure 15). Columns 2022 refer to various customer services 116.
Refernng to Figure 21, a flow chart for the steps in CSIR Intranet publishing process 214 is given. CSIR Intranet publishing process 214 first accesses the daily and monthly computed impact data stored as tables 227 in CSIR publishing database 226. Process 214 then computes and prepares plots of the monthly trends and 15 month trends in the customer services 116 in step 2112. After accessing additional HTML documents and text in step 2114, process 214 builds various web pages, such as those in Figures 22 to 25, in step 2116. The additional HTML
documents and text bring into the Intranet web site standard information and text. For example, these could be related to a glossary or frequently asked questions (FAQ) section.
The web pages built could include pages related to the current day's customer service impact information, the current month's customer service impact information, 15 month trends in the customer service impact information, or any other information of interest to persons in the company. These pages are finally saved to a web server in step 2118 for viewing over the company Intranet.
Examples of the possible information available on a company Intranet site related to the CSIR scheme 202 are illustrated in Figures 22 to 25. Note that these are only suggested reports, and many alternative reports and reporting formats would fall within the scope of the invention.
As well, the reports may be published by alternative means, such as paper reports.
Figure 22 includes a list 2210 of monitored customer services 116. These include various automatic bank machine ("ABM") services, such as account inquiries 142, bankbook updates 144 or deposits 148. The shade of the buttons 2212 indicates whether or not that customer service has experienced an interruption that day.
20732956.10 Figure 23 shows an analysis of system failures in the "ABM PIN code changes"
customer service 120, including minimum percentage of customers impacted on a daily basis 2310, maximum percentage of customers 118 impacted on a daily basis 2312, time of the interruption 2314, maximum and minimum number of impacted customers 118 2316, a description of the problem 2318 and an identification of the platforms 112 and applications 114 affected 2320.
Figure 24 is a trend graph of the number of customers 118 impacted daily by service interruptions in the "ABM PIN code changes" customer service 120. Figure 25 is a listing of all the customer service 116 interruptions that occurred on the reported day.
It is noted that those skilled in the art will appreciate that various modifications of detail may be made to the preferred embodiments described herein, which would come within the spirit and scope of the invention as described in the following claims.
20732956.10

Claims (27)

1. A method for measuring the impact of system outages in a scheme of systems provisioned to support customer services, comprising the steps of:
receiving actual system outages data;
converting the actual system outages data to actual service interruptions data for customer services that are dependent on the systems;
receiving forecasts of customer transaction demand for customer services; and calculating an estimated number of customers impacted by service interruptions using the actual service interruptions data and the forecasts of customer transaction demand.

2. The method of claim 1 wherein the systems support automated customer services.

3. The method of claim 2 further comprising recording the service interruptions data.

4. The method of claim 3 further comprising recording the forecasts of the customer transaction demand.

5. The method of claim 4 further comprising the steps of:
receiving actual customer transaction data;

using the actual customer transaction data to make new forecasts of the customer transaction demand; and recording the new forecasts of the customer transaction demand.

6. The method of claim 5 wherein the steps of receiving actual system outages data; and converting the actual system outages data to actual service interruptions data for customer services that are dependent on the systems, further comprises the steps of:
receiving platform outages data; and processing the platform outages data to extract service interruptions data for customer services that are dependent on the platforms.

7. The method of claim 6 wherein the steps of receiving actual system outages data; and converting the actual system outages data to actual service interruptions data for customer services that are dependent on the systems, further comprises the steps of:
receiving application outages data; and processing the application outages data to extract service interruptions data for customer services that are dependent on the applications.

8. The method of claim 7 wherein the step of calculating an estimated number of customers impacted by service interruptions using the actual service interruptions data and the forecasts of customer transaction demand further comprises determining a rounded number of customers impacted by service interruptions by rounding the number of customers impacted by service interruptions.

9. The method of claim 8 where the rounding involves a recursive rounding logic to produce a non-zero rounded number.

10. The method of claim 9 further comprising recording the rounded number of customers impacted by service interruptions.

11. The method of claim 10 further comprising communicating the rounded number of customers impacted by the interruptions via web-browser readable HTML code.

12. The method of claim 11 further comprising communicating the rounded number of customers impacted by the interruptions in a form readable by dedicated analysis tools.

13. The method of claim 2 in which the step of calculating an estimated number of customers impacted by service interruptions using the actual service interruptions data and the forecasts of customer transaction demand further comprises:
constructing a set of rules reflecting the effect of simultaneous system failures on the provisioning of customer service transactions;
using the rules to determine the percentage of total customers using a customer service impacted by the actual system outages; and multiplying the percentage of total customers using a customer service impacted by the system outages by the forecast of customer transaction demand to determine a number of customers denied use of a customer service by system outages.

14. The method of claim 2 in which the step of calculating an estimated number of customers impacted by service interruptions using the actual service interruptions data and the forecasts of customer transaction demand further comprises:
constructing a set of rules reflecting the effect of simultaneous system failures on the provisioning of customer service transactions;
assigning class codes of one or more elements to the systems to identify their relationship to other systems for the provisioning of customer service transactions in the event of simultaneous system failures;
using the codes and the rules to determine the percentage of total customers using a customer service impacted by the actual system outages; and multiplying the percentage of total customers using a customer service impacted by the system outages by the forecast of customer transaction demand to determine a number of customers denied use of a customer service by system outages.

15. The method of claim 2 in which the step of calculating an estimated number of customers impacted by service interruptions using the actual service interruptions data and the forecasts of customer transaction demand further comprises:
constructing a set of rules reflecting the effect of simultaneous system failures on the provisioning of customer service transactions;
using the rules to determine the percentage of total customers using a customer service impacted by the actual system outages; and multiplying the percentage of total customers using a customer service impacted by the system outages by the forecast of customer transaction demand to determine a number of transactions of a customer service disrupted by system outages; and multiplying the number of transactions of a customer service disrupted by system outages by a ratio of customers to transactions to determine a number of customers denied use of a customer service by system outages.

16. The method of claim 2 in which the step of calculating an estimated number of customers impacted by service interruptions using the actual service interruptions data and the forecasts of customer transaction demand further comprises:
constructing a set of rules reflecting the effect of simultaneous system failures on the provisioning of customer service transactions;
assigning class codes of one or more elements to the systems to identify their relationship to other systems for the provisioning of customer service transactions in the event of simultaneous system failures;
using the codes and the rules to determine the percentage of total customers using a customer service impacted by the actual system outages; and multiplying the percentage of total customers using a customer service impacted by the system outages by the forecast of customer transaction demand to determine a number of transactions of a customer service disrupted by system outages; and multiplying the number of transactions of a customer service disrupted by system outages by a ratio of customers to transactions to determine a number of customers denied use of a customer service by system outages.

17. The method of claim 16 in which an element of the class code reflects the position of a system in the hierarchy of systems provisioning a customer service.

18. The method of claim 16 in which an element of the class code reflects the set of transactions of a customer service provisioned by a system.

19. A method for measuring the impact of system outages in a scheme of systems provisioned to support customer services, comprising the steps of:
receiving actual system outages data for a first given time period;
converting the actual system outage data for the first given time period to actual service interruptions data for the first given time period for customer services that are dependent on the systems;
receiving forecasts of customer transaction demand for customer services for a second given time period; and calculating an estimated number of customers impacted by service interruptions for the first given time period using the actual service interruptions data for the first given time period and the forecasts of customer transaction demand for the second given time period.

20. The method of claim 19 wherein the systems support automated customer services.

21. The method of claim 20, where the step of calculating the number of customers impacted by service interruptions for the first given time period comprises calculating the maximum number of customers impacted by service interruptions for the first given time period.

22. The method of claim 21, where the step of calculating the number of customers impacted by service interruptions for the first given time period comprises calculating the minimum number of customers impacted by service interruptions for the first given time period.

23. Software on a computer readable medium for measuring the impact of system outages in a scheme of systems provisioned to support customer services, comprising instructions for:
receiving actual system outages data;
converting the actual system outages data to actual service interruptions data for customer services that are dependent on the systems;
receiving forecasts of customer transaction demand for customer services; and calculating an estimated number of customers impacted by service interruptions using the actual service interruption data and the forecasts of customer transaction demand.

24. The software on a computer readable medium of claim 23 wherein the systems support automated customer services.

25. A computer data signal embodied in a carrier wave and representing sequences of instructions which, when executed by a processor, will cause the processor to perform steps comprising:
receiving actual system outages data;
converting the actual system outages data to actual service interruptions data for customer services that are dependent on the systems;
receiving forecasts of customer transaction demand for customer services; and calculating an estimated number of customers impacted by service interruptions using the actual service interruption data and the forecasts of customer transaction demand.

26. An apparatus for automating the measuring the impact of system outages in a scheme of systems provisioned to support customer services, comprising:
means for receiving actual system outages data;
means for converting the actual system outages data to actual service interruptions data for customer services that are dependent on the systems;
means for receiving forecasts of customer transaction demand for customer services; and means for calculating an estimated number of customers impacted by service interruptions using the actual service interruption data and the forecasts of customer transaction demand.

27. The apparatus of claim 26 wherein the systems support automated customer services.