Abstract:
An event management system initializes an event associated with a process. Corrective actions are executed to resolve the event. The corrective actions are monitored after the event is resolved to continuously improve the process.

Description:
CROSS-REFERENCE TO RELATED APPLICATION 
     This application claims the benefit of U.S. Provisional Patent Application Ser. No. 60/721,275, entitled “SYSTEMS AND METHODS FOR MANAGING EVENTS,” and filed Sep. 27, 2005, the specification for which is hereby incorporated by reference. 
    
    
     BACKGROUND 
     This application discloses an invention that is related, generally and in various embodiments, to systems and methods for managing events that impact an information technology system. 
     For many entities, the response to events that impact their information technology system is conducted on a less than consistent basis. Confusion and frustration are often experienced because event information may be spread among multiple applications, may not be accessible from certain locations, and in some cases may not be available at all. 
     SUMMARY 
     In one embodiment a method to initialize an event associated with a process at an event management system, execute corrective actions to resolve the event and monitor the corrective actions after the event is resolved to continuously improve the process. 
    
    
     
       DESCRIPTION OF THE DRAWINGS 
         FIG. 1  illustrates one embodiment of a system for managing an event; 
         FIG. 2  illustrates one embodiment of a logical architecture of a system for managing an event; 
         FIG. 3  illustrates one embodiment of a method for managing an event; and 
         FIGS. 4-14  illustrate various examples of information provided by the system during execution of the method. 
     
    
    
     DETAILED DESCRIPTION 
     The figures and descriptions of the disclosed invention have been simplified to illustrate elements that are relevant for a clear understanding of the disclosed invention. It should be understood that the methods, products, and systems described below may include various other processes, components, and elements in actual implementation. 
     In one general respect, this application discloses a system for managing events that impact an information technology system. In another general respect, this application discloses a method for managing events that impact an information technology system. 
     Aspects of the disclosed invention may be implemented by a processor, computer system and/or by a computer program stored on a computer readable medium. The computer readable medium may comprise a disk, a device, and/or a propagated signal. 
     Other features and advantages will be apparent from the following description, including the drawings, and from the claims. 
       FIG. 1  illustrates one embodiment of a distributed system  100 . The distributed system  100  comprises one embodiment of a system  10  for managing an event. As used herein, the word event may refer generally to an event that impacts an information technology system, although the term is not necessarily limited in this context. For a financial services entity, an outage that impacts its information technology system also may impact its risk portfolio. The embodiments associated with the didtributed system  100  are not limited in this context. 
     The system  10  comprises a database  12  and a number of different modules  14  that are integrated with one another to provide the functionality of the system  10 . Although only three of the modules  14  are shown in  FIG. 1 , it is understood that the system  10  may include any number of the modules  14 . In one embodiment, the database  12  may be a centralized, searchable database to store information relevant to any number of events. 
     The modules  14  may be implemented utilizing any suitable computer language (e.g., C, C++, Java, JavaScript, Visual Basic, VBScript, Delphi) and may be embodied permanently or temporarily in any type of machine, component, physical or virtual equipment, storage medium, or propagated signal capable of delivering instructions to a device. The modules  14  (e.g., software application, computer program) may be stored on a computer-readable medium (e.g., disk, device, and/or propagated signal) such that when a computer reads the instructions stored on the medium, the functions described herein are performed. 
     The system  10  may be utilized to capture, manage and report events. For example, the system  10  may be utilized to facilitate communication during an event, provide simplified entry of event information that is accessible by a number of groups, facilitate easy communication and dissemination of time sensitive information, allow for detailed analysis or review of documentation of a finished event (e.g., post mortem), improve the management of follow up actions, and enhance data integrity associated with event reporting. The system  10  is structured and arranged such that all event information may be hosted at a single location, and users may manage every event from start to finish. 
     In general, the system  10  may be accessible by a user via a device  16  in communication with a network  18  that is in communication with the system  10 . The device  16  may be embodied as, for example, a personal computer, a workstation, a laptop computer, a network-enabled personal digital assistant, a network-enabled mobile telephone, etc. The device  16  may be in wired or wireless communication with the network  18 . A user may view the progress of a particular event at any given time via a display screen of the device  16 . According to various embodiments, a user may access a high-level view of all events in an environment by utilizing simple search/sort functionality. Armed with this information, a user may filter the event information based on multiple criteria (e.g., progress, severity, etc.). Any number of users may access the system  10  via any number of the devices  16 . 
     The network  18  may include wired or wireless data pathways in communication with the system  10 . The network  18  may include any type of delivery system including, but not limited to, a local area network (e.g., Ethernet), a wide area network (e.g. the Internet and/or World Wide Web), a telephone network (e.g., analog, digital, wired, wireless, PSTN, ISDN, GSM, GPRS, and/or xDSL), a packet-switched network, a radio network, a television network, a cable network, a satellite network, and/or any other wired or wireless communications network configured to carry data. The network  18  may include elements, such as, for example, intermediate nodes, proxy servers, routers, switches, and adapters configured to direct and/or deliver data. 
     In general, the system  10  may be structured and arranged to communicate with the network  18  using various communication protocols (e.g., HTTP, TCP/IP, UDP, WAP, WiFi, Bluetooth) and/or to operate within or in concert with one or more other communications systems. 
       FIG. 2  illustrates one embodiment of a logical architecture  200  for the system  10 . The logical architecture  200  may comprise a presentation portion  202 , an event management system portion  220  comprising an outage management system portion  222  and a data store portion  240 . In other embodiments, the logical architecture  200  also may comprise other systems  250 . Although the logical architecture  200  may be representative of one embodiment of the system  10  illustrated in  FIG. 1 , the system  10  is not necessarily limited in this context. The logical architecture  200  is not limited in the context of the illustrated embodiment. 
     The presentation portion  202  may comprise one or more methods of and devices for composing, sending, storing and receiving information over electronic communication systems. For example, in various embodiments, the presentation portion  202  may comprise methods and devices to compose, send, store and receive information over global, read-write information space such as the Web available via the Internet over one or more web server(s)  204 . Other devices and methods may comprise one or more: pager(s)  206 , email server(s)  208 , personal digital assistant(s) (PDA)  210 , which may be coupled to the email server  208  via a link  212  and a Java applications manager(s) (JAM)  214 . The information available at the presentation portion  202  may comprise, for example, text documents, images, multimedia and many other items of information, which may be referred to as resources that may be found, accessed and cross-referenced in any possible manner. The presentation portion  202  may be coupled to the event management system portion  220  through a communication link  213 . 
     The event management system portion  220  may comprise an outage management system portion  222 . In one embodiment, the outage management system portion  222  may comprise an outage module  224  to manage an outage event that may impact an information technology system. The outage module  224  may comprise various components to enable or facilitate communication with various other modules, the presentation portion  202  and/or the data store portion  240 . These components may comprise, for example, Web based graphical user interfaces (GUI) and may enable the outage management system portion  222  to create information technology center tickets, manage and/or track workflow, timestamp, invoke paging and/or email, create and/or manage information technology center events of a finished event and attach and/or route documents. 
     In one embodiment, the outage management system portion  222  may be coupled to a service center module  228 . The service center module  228  may comprise one or more components to provide a client GUI, manage and/or track workflow, timestamp events, provide system alerts and attach and/or route documents. The service center module  228  may receive information from a services portal module  230 . The services portal module  230  also may comprise or implement a web based GUI, create problem tickets and attach and/or route documents. 
     In one embodiment, the outage management system portion  222  may be coupled to a code module  226 . The code module  226  may comprise one or more components to provide a Web based GUI, create and/or manage mainframe outages (e.g., TAPSCO mainframe outages) and invoke paging and/or email applications. 
     In one embodiment, the outage management system portion  222  may be coupled to a TOR module  232 . The TOR module  232  may comprise one or more components to provide a Web GUI, create and/or manage mainframe outage after the occurrence of the event and provide mainframe outage reports. 
     In one embodiment, the outage management system portion  222  may be coupled to one or more other systems  250 . The other systems  250  may comprise one or more modules. For example, the other systems  250  may comprise a lightweight directory access protocol (LDAP) directory module  252  an elemental security platform (ESP) server portfolio module  254 , an on-call paging module  256 , a voice module  258  and a traffic management system (TMS) module  260 . Those skilled in the art will appreciate that the ESP server portfolio module  254  may provide a view of traffic flows and hosts, as well as tolls to enforce network policies. The ESP server portfolio module  254  enables system administrators to know which devices are located on their network and control what resources those devices may access. The event management system portion  220  and the other systems  250  may be coupled to the data store portion  240 . 
     In one embodiment, the data store portion  240  may comprise one or more databases. For example, the event management system portion  220  may be coupled to a production application relational database  242 . In one embodiment, the relational database  242  may be implemented as an adaptive server enterprise database made by Sybase, Inc. The relational database  242  may be coupled to a data warehouse database  244 . In one embodiment, the data warehouse database  244  may be a structured query language (SQL) database. The other systems  250  may be coupled to one or more other applications databases  246 , for example. 
       FIG. 3  illustrates one embodiment of a method  300  for managing an event. In one embodiment, the method  300  may be implemented to manage events and outages that may impact the enterprise technology infrastructure. One embodiment of the method  300  may comprise various portions such as: initialization  310 , execution  320  and continuous improvement  330  portions, for example. As shown in  FIG. 3 , the initialization  310  portion may comprise a detecting  312  block to detect an event (phase 1) and an assessing  314  block to assess the initial impact (phase 2) of the event. The execution  320  portion may comprise a communicating  322  block to communicate information associated with the event (phase 3), a resolving  324  block to resolve the event (phase 4), and a closure generating  326  block to generate a report, analysis or review of the finished event (phase 5). The continuous improvement  330  portion may comprise a managing  332  block to manage the post-closure period (phase 6) and a historical reporting  334  block to generate a historical report (phase 7). The embodiments associated with the method  300  are not limited in this context. 
     One embodiment of the method  300  may be implemented as a highly scalable, highly efficient process and may be utilized to improve formal communications around events, incorporate cross-regional escalation notification processes to risk managers and information technology managers, identify clear roles and responsibilities within an organization and share best practices for new situations. Each block associated with each phase in the method  300 , may comprise one or more processes and may involve one or more persons. For example, each block may be characterized as having one or more objectives, inputs, outputs, persons and other criteria to manage events, such as, for example, events that may impact an information technology system. 
     Examples of these various criteria for each block are now described with reference to  FIG. 3 . Accordingly, as shown in  FIG. 3 , the initialization  310  portion may comprise the detecting  312  block to detect an event (phase 1). One objective of the detecting  312  block may be to determine whether to escalate a process affected by the event in response to detecting the occurrence of an event. Inputs to the detecting  312  block may comprise information associated with an individual process, a technical and business assessment, a process owner, a process action item and notifications to date. The information may be provided by an outage owner and/or a core team. The outputs of the detecting  312  block may comprise an assessment in response to an event and whether or not to escalate the process (e.g., an information silo process). For example, if the assessment is negative in that the event has no impact on the process, the process remains. Otherwise, if the assessment is positive and the event does have an impact on the process, the process is escalated. Other outputs may comprise, for example, mobilization of resources, assignment of roles, notification, assessing the initial severity of an event, initial communication and schedule a meeting. 
     The initialization  310  portion also may comprise the assessing  314  block to assess the initial impact of an event (phase 2). Various objectives of assessing the initial impact of the event may be to get an assessment of what actually happened and the impact that the event may have on the process. Other objectives may comprise passing the initial message that an event has occurred to a technical and/or business team and identifying relevant risks and their impact on the process. Inputs to the assessing  314  block may be a roll call and a summary of current status and impact, as well as technical and business related priorities. The core team and invited non-business representatives may provide the inputs to the assessing  314  block. The outputs of the assessing  314  block may comprise, for example, assessing the firm-wide impact, implementing an action plan, assigning roles including a senior level communicator, implementing a communication plan and executing a communication/notification plan. 
     The execution  320  portion may comprise the communicating  322  block to communicate information associated with the event (phase 3). The communicating  322  block may comprise providing relevant event (e.g., outage) information which may be used for decision making/risk management. A technical and business assessment may be conducted to determine the severity and/or impact of the event. The communication may involve the core team, a team to conduct business communication at the operational level, for example, information technology and business risk level managers and a group to determine technical turnover and/or reengineering. Additionally, senior level strategic communication may involve communicating to the business risk managers and business level leaders. The communicating  322  block may be implemented via conference calls, prioritization of updated action plan activities and/or point in time communication. 
     The execution  320  portion also may comprise the resolving  324  block to resolve the event (phase 4). Resolution actions may comprise, for example, resolving an outage, executing a contingency plan and/or workarounds, mobilizing technical resources and providing updates to the core team. The resolving  324  block may receive event information such as definitions and scope of the problem, technical and business priorities, historical workarounds, work performed to-date, turnovers, configuration management and/or time constraints. This information may be provided by the event manager (e.g., outage manager), core team facilitators and/or technical resources. Based on the event information communicated in the communicating  322  block, the resolving  324  block may provide suitable workarounds, estimated time of arrival (ETA), latest statements for communicating, updated action plan, escalation information, change ticket and/or communication. 
     The execution  320  portion also may comprise the closure generating  326  block to generate an analysis, review or report of the finished event (phase 5). The closure generating  326  block report of the finished event may comprise creating and distributing a document, including timeline, impact, follow-ups and process feed-back after the event is finished. The information inputs may comprise all documents and communication related to the event, participation of team members, impact analysis and/or third party inputs. The input may be provided by the event manager owner (e.g., outage manager owner), chaser function, process owners and information technology and/or business team members. The closure generating  326  block output may comprise a document, assignment for follow-ups, action plan and/or communication after the event is finished. 
     The continuous improvement  330  portion may comprise the managing  332  block to manage the post-closure period (phase 6) (e.g., follow-up management phase). During the post-closure period, the managing  332  block may comprise ensuring that action items are executed, continuously improving processes and ensuring ultimate closure. Information input may comprise action items, team updates and/or cost/benefit and risk assessments after the event is finished. Managing the post-closure period may be implemented by silo representatives assigned and responsible for follow-up and/or the core team. During the post-closure period, the managing  332  block may provide spin-off projects (which may be tracked in an outage process but closed in follow-up process), reports to risk management, information technology management center (ITMC) and/or information technology. 
     The continuous improvement  330  portion also may comprise the historical reporting  334  block to generate a historical report (phase 7). Generating the historical report may comprise holistic views into the event environment and providing sufficient data so management can make informed decisions. Information input may comprise any output of any other blocks (e.g.,  312 ,  314 ,  322 ,  324 ,  326  and/or  332 ), which may be referred to herein as the event data. The historical reports may be generated by any process owners, business unit, ITMC, risk management group and/or representative groups, for example. Generating the historical reports may provide process metrics, stability metrics (e.g., multiple views, risk impact, etc.) and/or report review meetings. 
       FIGS. 4-14  illustrate various examples of information provided by the system  10  during the execution of the above-described method. The information may be presented on a display screen to a user and may be available on an event by event basis. 
     The information shown in  FIG. 4  is an example of one embodiment of a welcome screen shot  400  that may viewed by a user (e.g., a process owner) during the detection phase of an event (detecting  312  block  FIG. 3 ). A brief description of the event is provided in the “Outage Brief Description” field  402 . In the illustrated welcome screen shot  400 , the “Outage Brief Description” field  402  shows that the outage event is a server that does not re-start. The information may be utilized to invoke the event. During this time period, the process owner may perform data entry, select participants to join an assessment, invoke tickets, extract data, etc. The user may enter a description of the outage event in the problem description field  404  and also may enter the business impact of the outage event in the business impact field  406 . Participation may be selected in the setup core team section  408  and tickets may be invoked in the initiate, email, JAM and beep section  410 . 
     The information shown in  FIG. 5  is an example of one embodiment of a core team edit screen shot  500  that may be viewed by a user (e.g., an outage manager) defined in the outage manager field  502  during the assessment (assessing  314  block in  FIG. 3 ), communications (communicating  322  block  FIG. 3 ) and resolution (resolving  324  block  FIG. 3 ) phases of the event. During this time period, as shown in the core team edit screen shot  500 , the outage manager may join/manage a core team assessment telephone conference in section  504 , assign roles in section  506 , identify and/or assign action items, create additional follow-up calls and email minutes in section  508 . 
     The information shown in  FIG. 6  is an example of one embodiment of a core team assessment call screen shot  600  that may be viewed by a user (e.g., a core team participant) as shown in the name field  604 . The participants on the call are shown in the chart  602  section of the core team assessment call screen shot  600 . The user may view the information displayed in the core team assessment call screen shot  600  during the assessment (assessing  314  block  FIG. 3 ) and communications (communicating  322  block  FIG. 3 ) phases of the event. During this time period, as shown in the core team assessment call screen shot  600 , the core team participant may join the core team assessment telephone conference in section  606 , view outage details in section  608  and create actions in section  610 . 
     The information shown in  FIG. 7  is an example of one embodiment of an outage manager administration screen shot  700  that may be viewed by a user (e.g., an outage manager) as shown in the outage manager field  702 . The outage manager administration screen shot  700  may be viewed during the assessment (assessing  314  block  FIG. 3 ) and communications (communicating  322  block  FIG. 3 ) phases of the event. During this time period, as shown in the outage manager administration screen shot  700 , the outage manager may modify details, change status and cancel the event at any point in the outage life cycle in the manage calls in sections  704 ,  706 ,  708 . 
     The information shown in  FIG. 8  is an example of one embodiment of an outage status screen shot  800  that may be viewed by a user (e.g., an employee of a financial services entity) as identified in the outage status tab  802 . The outage status screen shot  800  may be viewed during the assessment (assessing  314  block  FIG. 3 ) and communications (communicating  322  block  FIG. 3 ) phases of the event. During this time period, the employee may view a high-level communications schedule  804  and join any call in progress or scheduled in the current calls sections  806 ,  808 ,  810  of the outage status screen shot  800 . 
     The information shown in  FIG. 9  is an example of one embodiment of a technical follow up call screen shot  900  that may be viewed by a user (e.g., a technical participant) as identified in the technical follow up call tab  902 . The technical follow up call screen shot  900  may be viewed during the communications (communicating  322  block  FIG. 3 ) phase of the event. During this time period, the technical participant may join a technical telephone conference, view outage event details and create actions in the technical follow up call sections  904 ,  906  of the technical follow up call screen shot  900 . 
     The information shown in  FIG. 10  is an example of one embodiment of a business unit (BU) briefing call screen shot  1000  that may be viewed by a user (e.g., a business unit participant) as identified in the BU briefing call tab  1002 . The BU briefing call screen shot  1000  may be viewed during the communications (communicating  322  block  FIG. 3 ) phase of the event. During this time period, the business unit participant may join a business unit briefing, view outage event details and create actions in the BU briefing call sections  1004 ,  1006  of the BU briefing call screen shot  1000 . 
     The information shown in  FIG. 11  is an example of one embodiment of a screen shot  1100  after a finished event that may be viewed by a user (e.g., an outage manager) as identified in the outage manager field  1102 . The screen shot  1100  after a finished event may be viewed during the post mortem (closure generating  326  block  FIG. 3 ) and managing (managing  332  block  FIG. 3 ) phases of the event. During this time period, the outage manager may record pertinent technical and process information regarding the outage event for future reporting and analysis purposes in section  1104  of the screen shot  1100  after a finished event. 
     The information shown in  FIG. 12  is an example of one embodiment of a post outage follow up screen shot  1200  that may be viewed by a user (e.g., an employee of a financial services entity) as identified in the post outage follow up tab  1202 . The post outage follow up screen shot  1200  may be viewed during the managing (managing  332  block  FIG. 3 ) phase of the event. During this time period, the employee may manage large follow-up actions from an outage event following the resolution (resolving  324  block  FIG. 3 ) and post mortem (closure generating  326  block  FIG. 3 ) phases of the event. This is shown in the summary section  1204  of the post outage follow up screen shot  1200 . 
     The information shown in  FIG. 13  is an example of one embodiment of an outage summary screen shot  1300  that may be viewed by a user (e.g., an employee of a financial services entity) as identified in the outage summary tab  1302 . The outage summary screen shot  1300  may be viewed during all phases of the event. During this time period, the employee may produce a formatted summary that can be emailed and/or sent to a printing device in the summary section  1304  of the outage summary screen shot  1300 . 
     The information shown in  FIG. 14  is an example of one embodiment of an outage dashboard screen shot  1400  that may be viewed by a user (e.g., an employee of a financial services entity) as identified in the outage dashboard tab  1402 . The outage dashboard screen shot  1400  may be viewed during all phases of the event. During this time period, the employee may gain a high-level view of an outage event by filtering on status and drill-down to view outage event details in the open outages  1404  and summary sections  1406  of the outage dashboard screen shot  1400 . 
     The benefits of the disclosed methods, systems and computer-readable media are readily apparent to those skilled in the art. The term “computer-readable medium” as used herein may include, for example, magnetic and optical memory devices such as diskettes, compact discs of both read-only and writeable varieties, optical disk drives, and hard disk drives. 
     A computer-readable medium may also include memory storage that can be physical, virtual, permanent, temporary, semi-permanent and/or semi-temporary. A computer-readable medium may further include one or more data signals transmitted on one or more carrier waves. The various portions and components of various embodiments of the disclosed invention can be implemented in computer software code using, for example, Visual Basic, C, or C++ computer languages using, for example, object-oriented techniques. 
     While several embodiments of the invention have been described, it should be apparent, however, that various modifications, alterations and adaptations to those embodiments may occur to persons skilled in the art with the attainment of some or all of the advantages of the disclosed invention. Therefore, this application is intended to cover all such modifications, alterations and adaptations without departing from the scope and spirit of the disclosed invention as defined by the appended claims.