Abstract:
The present invention is a Change Management Procedure that enables businesses and other enterprises to effectively manage, record, and communicate changes by employing a centralized control agency to review, approve, document, and communicate changes taking place within an enterprise. While the Change Management Procedure is applicable to any type of change, in the preferred embodiment the procedure manages changes in electronic computer systems including but not limited to architecture changes, outages (e.g., hardware, software or facility), replacement of hardware, upgrading of software, and rebooting of devices. By requiring that all changes be formally requested and approved, the Change Management Procedure prevents unauthorized changes. The Change Management Procedure also creates an audit trail that keeps a record of all changes for future reference. Another advantage of the Change Management Procedure is the communication of changes to operating units within the enterprise that are potentially interested in the change. At any step within the Change Management Procedure, entities that might be affected by a change may be notified of the change. Thus, potentially interested operating units can be aware of changes before they occur and can be informed of all changes that have occurred.

Description:
FIELD OF THE INVENTION 
   The invention is a method for managing change within an enterprise, more particularly for auditing and communicating changes made to electronic computing systems of the enterprise. 
   BACKGROUND OF THE INVENTION 
   Changes occur frequently in the processes and equipment of businesses and other enterprises and adverse effects can occur when unauthorized changes take place. Electronic computing systems, in particular, often undergo various modifications and unintended results can readily occur if the modifications are not approved by a knowledgeable authority or are not adequately communicated to all parties that might be impacted. Thus, a process for managing change comprising a centralized control agency is desirable to review, approve, document, and communicate changes taking place within an enterprise. 
   SUMMARY OF THE INVENTION 
   The method of the present invention, referred to herein as the Change Management Procedure, enables businesses and other enterprises to effectively manage, record, and communicate changes that occur within the enterprise. While the Change Management Procedure is applicable to any type of change, in a preferred embodiment the procedure manages modifications in electronic computer systems including, but not limited to, architecture changes, outages (e.g., hardware, software, or facility), replacement of hardware, upgrading of software, and rebooting of devices. By requiring that all changes be formally requested and approved, the Change Management Procedure prevents unauthorized changes. The Change Management Procedure also creates an audit trail that keeps a record of all changes for future reference. Another advantage of the Change Management Procedure is the communication of changes to operating units within the enterprise that are potentially interested in the change. At any step within the Change Management Procedure, entities that might be affected by a change may be notified of the change. Thus, potentially interested operating units can be aware of changes before they occur and can be informed of all changes that have occurred. 

   
     DESCRIPTION OF THE DRAWINGS 
     The invention, together with further advantages thereof, may best be understood by reference to the following description taken in conjunction with the accompanying drawings in which: 
       FIG. 1A  is a flowchart depicting the steps in a planned change request process. 
       FIG. 1B  is a flowchart depicting further steps in the planned change request process. 
       FIG. 2A  is a flowchart depicting the steps in an emergency change request process. 
       FIG. 2B  is a flowchart depicting further steps in the emergency change request process. 
       FIG. 3  is a printout of a computer screen depicting a web page used for logging in to the change management system. 
       FIG. 4  is a printout of a computer screen depicting a web page used for viewing active change requests. 
       FIG. 5  is a printout of a computer screen depicting a menu of options available for users with security level 3. 
       FIG. 6  is a printout of a computer screen depicting a menu of options available for users with security level 4. 
       FIG. 7  is a printout of a computer screen depicting a web page used for user registration. 
       FIG. 8  is a printout of a computer screen depicting a web page used for submitting change requests. 
       FIG. 9  is a printout of a computer screen depicting a web page used for managing email distribution groups. 
       FIG. 10  is a printout of a computer screen depicting a web page used for editing email distribution groups. 
   

   DETAILED DESCRIPTION 
   Management of change in the Change Management Procedure is achieved through the use of a change request document. The change request document can be a paper form, an email, a web page, or any similar means of documenting the changes to be made and the steps taken in the implementation of the changes. The entity requesting the changes and responsible for ensuring that the change request document is complete and accurate is known as the change requester. Alternatively, one entity can complete the change request document and another entity can ensure its completeness and accuracy. In this case, the entity completing the change request document would be known as the change requester and the entity ensuring its completeness and accuracy would be known as the change owner. For purposes of this application, unless otherwise specified, the change requester and the change owner are considered the same entity and are referred to as the change requester. The entity that manages changes and oversees the Change Management Procedure is known as the change manager. The change requester can be considered a client of the change manager. If the change requester and the change manager are members of different enterprises, a client service manager may be employed to act as a liaison between the change requester and change manager. In the case where the need for a change is identified by the change manager, the change manager can also function as the change requester. Implementation of changes is typically accomplished by an entity designated by the change manager or the change requester. The change requester, change manager, change implementer, and client service manager can be either individuals or organizations. 
   Access to the Change Management Procedure may be restricted to registered users authorized to submit change requests via the change request document. Registration can be done by means of a paper form, an e-mail, a web page, or any similar means of documenting information about the entity requesting authority to submit change requests. The registration documentation is submitted to the change manager for approval, which may further comprise checking to ensure that data has been entered in all fields of the registration form and/or performing background checks on the user submitting the registration form to ensure that the user has the proper authority and/or knowledge level to submit change requests. 
   Within the Change Management Procedure, different levels of authority may exist for users who submit change requests based upon a security clearance level and corresponding to an approved set of operations (such as viewing, editing, and/or submitting a change request document) that the change requester may perform. For example, the lowest level (0) could be new users who have submitted registration requests but whose registration requests have not yet been approved. Such users would be allowed access only to the registration form. The next highest level (1) could be users who are not employees of the same company as the change manager and are not under contract to that company but who may have a need to submit change requests. Such users would be allowed limited ability to complete and submit the change request document but would not have access to change requests made by others. The next highest level (2) could be users who are not employees of the same company as the change manager but who are under contract to that company. Such users would be allowed to complete and submit change request documents and would have access to change request documents submitted by others within their organization. The next highest level (3) could be users who are employees of the same company as the change manager. Such users would be allowed to complete and submit change request documents and would have the authority to see the change requests submitted by all other users. The highest level (4) could be members of the change management organization. Such users would have the authority to edit the change requests submitted by all other users. 
   A change can be either planned in advance or necessitated by an emergency. Planned change management is typically achieved through the following steps: submission of a change request document from the change requester to the change manager, broadcasting notice of a proposed change to potentially interested operating units within an enterprise, review of the proposed change by a change review team comprising the change manager and representatives of other potentially interested operating units who choose to participate, approval or rejection of the proposed change by the change review team, scheduling of an approved change by the change manager, possibly with input from the change review team, and implementation of the approved change by an individual or organization the change requester or the change manager designates. These steps, and variations and combinations thereof, constitute embodiments of the Change Management Procedure and are described in detail below. 
   The first step in the Change Management Procedure is typically the submittal of a change request document from a change requester to the change manager. The change request document typically includes information such as a description of the proposed change, justification of the proposed change, the predicted results and impact of the proposed change, the preferred date and time for implementation of the proposed change, and a plan for reversing the proposed change if implementation is unsuccessful. The change requester is responsible for ensuring that the change request document is complete and accurate. 
   The next step in the Change Management Procedure is typically the validation of the change request by the change manager. In the validation procedure, the change manager checks the change request document to ensure that it has been completed fully and accurately but no evaluation is made of the merits of the proposed change. If errors are found in the change request document, the document is returned to the change requester for revision. If no errors are found, the review process is initiated for the change request. 
   After validating a change request, the change manager sends notification about the proposed change to at least one representative of each operating unit within the enterprise that is potentially interested in the proposed change. Notification can be achieved through email, telephone, or other means of communication and is typically broadcast widely within the enterprise. For example, the change manager may maintain email distribution lists of operating units that are potentially interested in changes. The members of the lists may vary based upon their interest in disparate types of changes, and the change manager would choose the appropriate list to be notified for a proposed change. 
   All proposed changes are reviewed by a review team comprising the change manager and a representative of each potentially interested operating unit receiving notification of the proposed change and choosing to participate in the review team. The review team will recommend a course of action with respect to the proposed change, typically either approving or rejecting the proposed change, and will notify the change requester of the recommendation. If the proposed change is rejected, the change requester can either cancel the request or revise and resubmit the request. If the proposed request is approved, the change requester establishes a schedule for implementation of the change. Other members of the review team may offer input into the scheduling of the change. The potentially interested operating units can then be notified of the schedule for and the details of implementation of the change. 
   When a change is implemented by the change requester or a designee of the change requester or change manager, the implementation can occur as requested or some modification to the change as proposed may be necessary. If the change is implemented as requested, the change request document can be updated with information regarding the work that was done and all potentially interested operating units can be notified that the request was completed. If an asset management agency exists to oversee an organization&#39;s physical assets and the physical assets of that organization are impacted by a change implemented through the Change Management Procedure, the asset management agency can be notified of the change and their asset inventory and/or maintenance records updated accordingly. 
   If a change is not implemented successfully, the request for the change can be cancelled or the change can be rescheduled. If the request is cancelled, the steps taken in the attempted implementation of the change can be reversed, all potentially interested operating units can be notified, and the change request document can be updated with a description of the work that was and was not done and the reason for the cancellation. If the change is rescheduled, the partial, successful steps taken in the implementation of the change can be left in place, any remaining steps to be taken in the implementation of the change can be rescheduled, all potentially interested operating units can be notified, and the change request document can be updated with a description of the work that was and was not done. 
   When change requests are completed, whether the change was successfully implemented or not, a review of the change implementation process can be performed and reports can be created describing the results of the review. 
   In the preferred embodiment, the Change Management Procedure may be used to manage modifications in electronic computer systems including, but not limited to, architecture changes, outages (e.g., hardware, software or facility), replacement of hardware, upgrading of software, and rebooting of devices. Due to the highly interconnected nature of many computer systems, changes such as these in one part of a system can cause unintended effects in another part of the system. Use of the Change Management Procedure ensures that organizations and/or individuals within an enterprise that are potentially affected by a proposed change to a computer system are informed of the proposed change and are given the opportunity to offer comments on the scheduling, implementation, and consequences of the proposed change. Revisions to the proposed change can then be made, if necessary, so that all interested parties grant approval to the proposed change. Unanticipated adverse effects to computer systems can thus be minimized. 
   The Change Management Procedure can be applied to operating units within a single enterprise or to operating units in multiple enterprises. For example, the change requester and the change manager can be members of different departments within the same company. Alternatively, the change requester could be a member of one company and the change manager could be a member of another company. In the latter case, the change manager&#39;s organization may employ an individual or a group to act as a liaison between the change manager and the change requester. 
   When changes must be made due to an emergency, the procedures for planned change management cannot always be followed. In an embodiment of the Change Management Procedure, an emergency change request process can be instituted to manage changes that must be made on an emergency basis or in response to problem tickets generated through a problem management process. 
   Many organizations have a process for handling problems in which a document describing the problem is created and then assigned to the proper group for resolution. Any such document used in such a problem management process will be referred to as a problem ticket. Problem tickets are often assigned severity levels depending on the seriousness of the problem. An emergency would have a high severity level while a minor problem that has few adverse consequences would have a low severity level. 
   The emergency change request process is initiated in two ways: by the creation of a problem ticket requiring a change and by the occurrence of an emergency that does not require the creation of a problem ticket. For high severity problem tickets that can be resolved immediately, a change request is not necessary before commencement of problem resolution activities—the severity of the problem serves as the approval to make any necessary changes. In this case, the change implementer creates an emergency change request document after implementation of the change is complete. This post-problem emergency change request, containing a description of the change that was implemented, is submitted to the change manager for record keeping purposes. 
   For lower severity problems, high severity problems that cannot be resolved immediately, and emergencies not requiring a problem ticket, a modified form of the planned change request process is implemented. For emergencies not requiring a problem ticket, the change requester creates an emergency change request document and submits it to the change manager. In the cases where a problem ticket exists, the change manager reviews the problem ticket, determines that implementation of the change can be deferred, and notifies the change requester that an emergency change request must be submitted for approval. The change requester then creates an emergency change request document and submits it to the change manager. The change manager obtains approval for the change, a schedule for the implementation of the change is established with collaboration between the change manager, the change owner, and any potentially interested operating units, the potentially interested operating units are notified of the schedule, the change request is updated with the approval and scheduling information, and the change is implemented. The change request document is then updated with information regarding the change that was made, all potentially interested operating units are notified that the change has been completed, and the asset management agency is notified, if necessary. When the emergency change process is complete, a review of the process can be performed and reports can be created describing the results of the review. 
   If a change made in response to an emergency is not implemented successfully, the steps taken in the attempted implementation of the change are reversed, all potentially interested operating units are notified, and the change request document is updated with a description of the work that was and was not done. 
   As is the case in planned change management, the emergency change management procedure can be used to manage modifications in electronic computer systems. The emergency change management procedure can also be applied to operating units within a single enterprise or to operating units in multiple enterprises. 
   Use of the Change Management Procedure can be facilitated by implementing the procedure on an electronic computer system. In particular, the change request document can be placed on an interactive web page. Access to and authorization to enter data on this web page can be restricted to registered users according to their security clearance levels as described previously. Original submittal of and subsequent updates to a change request document would then be accomplished by an authorized change requester entering data into the fields of the online document and submitting the data to the change manager. The various notification steps within the Change Management Procedure, including broadcasting notice of a proposed change to potentially interested operating units, notifying the change requester of the review team&#39;s recommended course of action for a proposed change, and notifying potentially interested operating units of the status of a proposed, scheduled or implemented change, can also be accomplished electronically. These notification steps can be done through email or through updates to a web page accessible to the potentially interested operating units. Likewise, the review team meetings can be held by means of broadcasted emails or publicly updateable web pages rather than face-to-face meetings. Any reports evaluating the Change Management Procedure can be distributed by similar means. 
   EXAMPLES 
   Example 1 
   Planned Change 
   An example of the Change Management Procedure for a planned change is summarized in the flow charts in  FIGS. 1A and 1B . The change requester is referred to as the change owner in the charts. In this example the change owner is not a member of the same enterprise as the change manager and therefore a client service manager is employed as a liaison between the change owner and the change manager. The change implementer can be a member of the change owner&#39;s organization, the change manager&#39;s organization, or a third party organization designated by the change owner or change manager. 
   At steps  1 ,  2 ,  3 , and  4  a need for a change is identified by a member of the change owner&#39;s organization, a member of the change manager&#39;s organization, a third party, or a member of the change manager&#39;s enterprise outside the change manager&#39;s organization, respectively. The change owner tests the needed change at step  6  to ensure that it can be implemented successfully and with minimal impact to others. The testing may include conducting peer reviews to ensure the change implementation will accomplish the intended result. The change owner completes a change request document at step  8  and submits the change request document at step  10 . At step  20  the change manager validates the change request. If a person within the change owner&#39;s organization has not been designated to take responsibility for the proposed change, the change manager designates such a person in step  24 . The change manager, change owner, and client service manager review the proposed change at step  28  and establish a tentative schedule for implementation of the change. At step  30  the change manager distributes the change request document to the review team. Preliminary approval or rejection of the proposed change by the review team occurs at decision point  40 . If the proposed change is rejected, two options are possible at decision point  50 . If all parties involved in the review process reject the change, then the change manager closes the change request document in step  60  and sends notification to all potentially interested operating units in step  70 . If all parties involved in the review process do not reject the proposed change, then the change owner can revise the change request document in step  80  and resubmit the document to the change manager in step  90 . The Change Management Procedure then begins again at step  10  for the resubmitted change request. If, at decision point  40 , the proposed change is approved, the change manager distributes the change request document to all potentially interested operating units in step  100 . At step  110  a review meeting is held for a final clarification of any outstanding content, scheduling, or implementation issues. At step  120  the change manager provides a finalized list of approved changes to the other members of the review team. 
   The finalized change request document is distributed in a broadcast message from the change manager to all potentially interested operating units in step  122 . At step  124  the change owner coordinates the approved change with the change implementer. At step  126  the change owner coordinates access to the facility at which the change will take place. At step  128  the change owner and/or the change implementer update the change request document with any information pertinent to the change management process as it has been implemented to that point. The change is implemented at step  130  and the change request document is again updated at step  140 . When the implementation activities are complete, decision point  150  is reached. If the change was not successful, the change implementer reverses the attempted changes in step  160 , updates the change request document in step  165 , and notifies the change manager of the unsuccessful change implementation in step  170 . The change owner updates the change request document in step  180 . In an alternative course of action for an unsuccessful change, if the partial changes can be left in place in step  190  without impact, the remaining changes are rescheduled in step  200 , the change implementer notifies the change manager as in step  170 , and the change owner updates the change request document as in step  180 . If the change was successful, the change implementer updates the change request document in step  210 , notifies the change manager in step  220 , notifies the change owner that the change has been successfully implemented in step  230 , and notifies the change owner of any problems that occurred or may occur as a result of the change implementation process in step  240 . At step  250  the change manager closes the change request document and at step  260  the change manager performs an analysis of the Change Management Procedure as it was applied in the newly completed change. At step  270  the client service manager notifies the change owner&#39;s organization that the change has been implemented successfully. In step  280  the asset management agency is notified of any changes that were made to physical assets. 
   Example 2 
   Emergency Change 
   An example of the Change Management Procedure for an emergency change is summarized in the flow charts in  FIGS. 2A and 2B . The change management process starts at decision point  310  where proposed emergency changes are divided into two groups: those related to severity level 1 or 2 problem tickets (the two most severe levels) and those related to lower severity problem tickets or unrelated to the problem ticketing system. If the changes are related to severity 1 or severity 2 problem tickets, the change owner, in step  316 , determines whether the resolution of the problem ticket can be deferred. If the resolution of the ticket cannot be deferred, the problem is resolved and then, in step  320 , the change implementer creates a post-change emergency change request. If the resolution of the problem can be deferred, an emergency change request is created in step  330 . The emergency change process then continues at step  340  as described below. 
   For changes related to lower severity problem tickets and for changes unrelated to the problem ticketing system, the change owner, in step  314 , determines that an emergency change request document must be completed. For these cases and for severity 1 or 2 problems that can be deferred, an emergency change request is created as in step  330 . At step  340  the change owner notifies the management of the change owner&#39;s organization that an emergency change request has been created. At step  350  the change owner submits the emergency change request to the change manager. The change manager obtains approval of the request in step  360  and notifies the client service manager in step  362 . The client service manager sends a broadcast notice of the approved change to the change owner&#39;s organization step  364  and obtains final approval in step  366 . A schedule for implementation of the change is established by the change owner and the client service manager in step  370 . In step  380  the change owner notifies the change manager of the schedule for the change. The change owner and/or the change implementer update the emergency change request in step  390 . 
   The change implementer implements the change in step  400 . Alternative courses of action are taken at decision point  405  depending on whether or not the emergency change is backed out. If the emergency change is not backed out, the change implementer notifies the change owner and the client service manager in step  410  that the change was not backed out. At step  420  the change implementer notifies the change owner of any potential problems created by the change. The change owner and/or the change implementer update the emergency change request in step  460  and the change implementer notifies the change manager in step  470 . The change manager closes the emergency change request in step  480  and notifies the asset management agency in step  490 . If, at decision point  405 , the emergency change is backed out, the change owner and/or the change implementer update the emergency change request in step  430  and notify the change manager and client service manager in step  440 . If a third party other than the change owner and change manager is involved in the emergency change process, the client service manager notifies the third party in step  450 . The change implementer updates the emergency change request in step  500  and notifies the change manager in step  510 . The change manager performs an analysis of the Change Management Procedure as it was applied in the newly completed emergency change in step  520  and then closes the emergency change request in step  530 . 
   Example 3 
   Computer Implementation 
   Sample screens from a version of the Change Management Procedure implemented on a computer system are shown in  FIGS. 3 ,  4 ,  5 ,  6 ,  7 ,  8 ,  9 , and  10 .  FIG. 3  is an example of a web page users can use to log in to the computerized version of the Change Management Procedure. The user&#39;s name and password are entered in fields  610  and  620 , respectively. Registered users use button  630  to log in to the change management system. New users who wish to register themselves into the system can use button  640 . Button  650  provides help to users who cannot remember their passwords. 
     FIG. 4  is an example of a web page that displays active change requests. Column  710  allows a user to select whether a change request is to be viewed or edited and also allows a search to be performed. Column  720  lists the identification numbers of the change requests. Column  730  displays the titles of the change requests. Column  740  displays the customers requesting changes. Column  750  shows the status of the change requests. Column  760  displays the group to which the change requests have been assigned. Column  770  displays the individuals who submitted the change requests. Column  780  lists the dates the changes requests were submitted. 
     FIG. 5  is an example of a menu listing the options available to a user who has a security level of 3. Field  810  allows the user to log out. Field  820  allows a user to edit user information. Field  830  allows a user to display the change request list. Field  840  allows a user to enter a new change request. 
     FIG. 6  is an example of a menu listing the options available to a user who has a security level of 4. Field  910  allows the user to log out. Field  920  allows a user to edit user information. Field  930  allows a user to display the change request list. Field  940  allows a user to enter a new change request. Field  950  gives a user access to the user management screen. Field  960  gives a user access to the email group management screen. 
     FIG. 7  is an example of a web page users can complete to register themselves into the computerized version of the Change Management Procedure or to edit previously entered registration information. The user&#39;s first name and last name are entered in fields  1010  and  1020 , respectively. The user&#39;s email address is entered in field  1030 . The user&#39;s business phone number, mobile phone number, pager number, and pager PIN are entered in fields  1040 ,  1050 ,  1060 , and  1070 , respectively. The user&#39;s password is entered in field  1080  and is confirmed in field  1090 . Button  1095  is used to submit a completed registration form. An email notification is sent to the change manager when the user submits the registration information for authentification. Another email is sent to the user when the change manager authenticates the user and assigns the permission level of the user. 
     FIG. 8  is an example of a section of a web-based change request document. A short description of the proposed change is entered in field  1102 . This becomes the title of the change. The change request type is entered in field  1104 , the customer category is entered in field  1106 , and the group initiating the change request is entered in field  1108 . The latter three fields are drop-down boxes allowing the user to choose from a predefined list of valid entries. Fields  1110 ,  1112 ,  1114 ,  1116 , and  1118  allow the user to specify the trouble ticketing system associated with the proposed change. The location of the organization requesting the change is entered in field  1120 . The name and phone number of the change requester are entered in fields  1122  and  1124 , respectively. If a person in the requesting organization other than the change requester oversees the change request process, that person&#39;s name and phone number are entered in fields  1126  and  1128 , respectively. The names and phone numbers of the change implementer or implementers are entered in fields  1130 ,  1132 ,  1134 ,  1136 ,  1138 ,  1140 ,  1142 , and  1144 . Field  1146  is a scroll box in which one or more types of devices or systems to which the proposed change applies are chosen. Field  1148  is a scroll box in which organizations potentially impacted by the proposed change are chosen. Button  1150  allows a user to save a partially completed change request form without submitting the form. Button  1152  allows a user to submit a completed form to the change manager. Additional sections of the web-based change request document, not shown, may include, but are not limited to, a detailed description of the change, details of the device, software, or facility affected, database or application outages due to the change, the test plan and test results, and the backout plan. 
   Examples of email distribution lists are shown in  FIG. 9 . Radio buttons  1210 ,  1220 , and  1230  allow a user to select the distribution list to which an email should be sent. Button  1240  takes the user to a screen that allows new email distribution groups to be created. 
   The screen used to edit the email distribution lists is shown in  FIG. 10 . Email distribution lists allow the ability to tailor the broadcast notifications and review team notifications to specific team members based on the status of the change request, who initiated the change, the content of change, or any combination of the three. The group name of the distribution list is entered in field  1310 . The change request status that causes an email to be sent to the specified group is selected in field  1320 . The organization to which the specified group belongs is selected in field  1330 . The department within the organization is selected in field  1340 . A description of the group can be entered in field  1350 . The individuals within the group are listed in field  1360 . Button  1370  is used to submit updated information after changes have been made to the other fields on the screen. Button  1380  is used to delete a group and button  1390  is used to cancel any changes and return the group&#39;s information to its previous state.