You are on page 1of 33

Move to Production Procedures

APPLICATION DEVELOPMENT CHANGE MANAGEMENT (ADCM)

Implemented March 31, 2004
Revised April 12, 2004 Revised July 12, 2004 Revised October 29, 2004 Revised January 27, 2005 Last Revised February 21, 2005

Last Revised April 30, 2007
Documented by Bret Wayne (219) 241-6775

Documented Procedures for Usage of the ‘Application Development Change Management’ (ADCM) Application
Table of Contents

I. Background:........................................................................................................................................................3 II. Roles and Responsibilities:...............................................................................................................................3 III. Change Type:...................................................................................................................................................4 IV. How To Access:................................................................................................................................................5 V. ADCM Field Names and Descriptions:...........................................................................................................6 VI. Scheduled - Expedited Change:.....................................................................................................................9 Scheduled – Expedited Change Process Flow.................................................................................................9 Scheduled – Expedited Change Steps............................................................................................................10 Scheduled – Expedited Change Request Process Tutorial............................................................................11 VII. Emergency Access Change:........................................................................................................................21 Emergency Access Change Process Flow.....................................................................................................21 Emergency Access Change Steps..................................................................................................................22 Emergency Access Change Request Process Tutorial...................................................................................23 VIII. Revision History:........................................................................................................................................31

Page 2 of 33

I.

Background:
Application Development Change Management (ADCM) is a Lotus notes developed tool that is used by Applications Development personal to request migrations or code or data from test to production. ADCM provides SOX compliance and separation of duties on application production migrations. ADCM forms can be viewed from the web but the users of the system must use it from NiSource notes client workspace. This can be accessed while on NiSource notes or CITRIX.

II.

Roles and Responsibilities:
Change Request Originator – can be anyone inside or outside of the IT Application Development Areas who seeks IT application development assistance that results in a change to a production application. A change request typically originates via a Remedy Problem Management Ticket (Break/Fix), or a ProjecTrak End-User Request (Enhancement or Maintenance). Requestor’s Manager – is the Manager to whom the Request Originator reports to and will authorize a change request to be accepted by IT. Business Owner - is the individual who ‘owns’ the application and takes full responsibility for the application’s features, functionality and performance. Business Contact - This individual is most apt to report to the Business Owner and either request or authorize the change, validate the testing of it, and approve its implementation. This may/may not be the Business Owner. In the ADCM application, this field is automatically populated from the Application Portfolio with information housed in the field entitled: Client Contact. Application Developer - is the developer who is responsible for making a change to an assigned application in accordance with an approved change request. This individual is also responsible for adequately testing the change, obtaining user-signoff, reviewing disaster recovery and system flowchart impacts in prior to preparing the Application Development Change Management (ADCM) request form that will initiate the change. The Application Developer is required to be on standby during a scheduled change or actually perform the change in an emergency break/fix situation. In all cases, once the change has been completed, the Application Developer is responsible for verifying/effecting its correctness. IT Team Lead – It is the IT Team Lead’s responsibility to approve all changes going into production and to signoff on all changes once they have been completed. For Scheduled Changes, the approval is obtained prior to the change being submitted. For Emergency Changes, both the approval and the signoff take place after the Application Developer performs the migration. Production Control Group (PCG) – Key to the SOX separation of duties requirement, PCG staff is responsible for performing all scheduled moves to the production-computing environment as requested by the application developer. In most cases, the application portfolio contains the names of the primary and secondary PCG staff for a given application, and this information is populated into the ADCM at the time the application developer completes the form. This information then serves to alert PCG to the change request by automatically sending an email to them and to the Production Control Mailbox. ENOC – ENOC staff is responsible for assisting the Application Developer with Emergency/Off-hour changes. When an Emergency ADCM is submitted, ENOC will facilitate the granting of security access to the productioncomputing environment for the developer who then will make the change himself. ENOC is alerted to the emergency access change request by the ADCM application sending an email to the ENOC Monitor Mailbox.

Page 3 of 33

EMERGENCY ACCESS: Lead Time = none. Again it is characterized by the inability to anticipate or plan for it in advance. Usually.e. Note that some “Same Day” changes could fall into this type as long as all the testing and approvals can be received and the Team Lead is available to approve the request. Note that some “Same Day” changes could fall into this type as long as all the testing and approvals can be received and the Team Lead is available to approve the request. tested. there is plenty of time to follow the normal approval process before the change is made. an immediate resolution is needed and there may not be enough time to follow the normal approval process before applying the change. Usually. application. This change has little to no notification but the developers still need the PCG to make the change. thought out. An Expedited Change is a special request of the customer or IT to implement as soon as possible. Change Type: A Normal Change is planned and entered at least 3 business days in advance. NORMAL CHANGE: Lead Time = 3 business days or more. It is a change that could be related to an off hours callout or an unscheduled run. database.) In this case. An Emergency Access change is characterized by the inability to anticipate or plan for it in advance. etc. tested. restart. An Emergency Access change is similar to the Expedited Schedule change except for this change the developer is making the change themselves. Normal Scheduled changes are processed thru the Production Control group (PCG) who performs the change to the production-computing environment. an immediate resolution is needed and there may not be enough time to follow the normal approval process before applying the change. thought out. Device.III. There is still time to receive ALL reviews and sign-offs and those are available BEFORE the migration will take place. there is no Lead Time. These changes are also processed thru the Production Control group (PCG) who performs the change to the production-computing environment. or cancellation of a scheduled batch job or job stream or a restart of a failed application server process.e. and communicated to all affected parties well in advance of the update. The approval will be provided when the TL signs off on the change after the fact. Emergency access requests are processed thru Batch Operations (ENOC) who grants (and subsequently revokes in 24 hours) the necessary production access to the developer who performs the change to the production-computing environment. Device.) Also in this case. Page 4 of 33 . application. A Normal Change is planned. Emergency access changes are processed thru ENOC who grants (and subsequently revokes) the necessary production access to the developer who performs the change to the production-computing environment. It is approved. An Emergency Change is a change that has very little notice but still requires PCG to execute the change. It is a change that may be needed to prevent or fix a high severity problem or is something the customer wants to have implemented as soon as possible but is still tested and approved by the Team Lead in advance. etc. EXPEDITED CHANGE: Lead Time = 1 – 2 business days. some type of problem or event has occurred (or soon will) that will negatively impact a production system (i. It is approved. database. Developer and Team Lead must follow up with anything missing within 1 business day and approval is provided by the Team Lead sign-off. In all cases. Developer and Team Lead must follow up with anything missing within 1 business day and approval is provided by the Team Lead sign-off. The normal pre-approval is not needed for this type of change. some type of problem or event has occurred (or soon will) that will negatively impact a production system (i. There is no time to receive any reviews or sign-offs before the change will take place. An Expedited Change is something that has 1-2 business days notice. An immediate resolution is needed and there is no time to follow the normal approval process or finding a PCG analyst before applying the change. EMERGENCY CHANGE: Lead Time = 0 – 8 hours (Same Day Request). An Emergency Change is characterized by the inability to anticipate or plan for in advance and notification may be less than 8 hours or even none at all via a callout. and communicated to all affected parties well in advance of the update.

perform the following: 1. and click push the open button and that will open the DB and add it to the workspace for future access Page 5 of 33 . Once found. 2. 3. How To Access: ADCM is a Lotus DB that is located on the NiSource network or the CITRIX NiSource client. Users must have a NiSource Lotus ID. the path is local\NCS\IT\App_Dev_Chg_Req.nsf To add the DB to your Lotus workspace. While in Lotus Drop Down File >>> Database>>>Open>> Put OHAPPS01 in the server name Follow the path to find the DB 4. The DB is located on Sever OHAPPS01/OH/Server. highlight.IV.

ADCM Field Names and Descriptions: Field Name Request Status: Description This value is auto-generated based on where the scheduled change is in the workflow process. The selection list is limited to a group of PCG members in the address book. Personnel Application Primary Support Contact: Developer & Phone Number: Developer ACID: Business Contact: Primary Team Lead: & Phone Number: Secondary Team Lead: & Phone Number: Auto-populated from Application Portfolio Auto-generated with your name & phone number determined by your Logon-ID. Select from NiSource address book drop-down in the event that neither the Primary nor Secondary IT Team Lead is available. Application Affected: SOX 404 Application: Environment? Requested Start Date / Time: Requested Completion Date / time: Select from drop-down. Cannot be changed. Cannot be changed. The selection list is limited to a group of NiSource IT approvers. Auto-populated from Client Contact field on the application portfolio. Auto-populated from Primary IT Team Lead fields on the application portfolio. Auto-generated with the person creating the request. Cannot be changed. Auto-generated with your fully qualified User-ID determined by your Logon-ID. Auto-generated unique request identifier. Date and Time the implementation of this request is to end. Cannot be changed. Is this flag to indicate if this is a 404 Application Select test or production Date and Time the implementation of this request is to begin. Values/Details New Submitted Approved In Production Control Production Access Granted Production Access Revoked Completed Signed Off Cancelled Current Date Current Time Generated number User Name Normal Change Expedited Change Emergency Change Emergency Access Drop down populated from Application Portfolio Auto Populated via Application Portfolio Test or Production Date / Time Value Date / Time Value Text Submit Date: Submit Time: Request ID: Requestor: Change Type: Auto-populated with current date. Select from NiSource address book drop-down Auto-populated from PC Primary Support fields on the PROD CNTL tab of the application portfolio. Auto-populated from Secondary IT Team Lead fields on the application portfolio. Short description of why this access was required. Cannot be changed. Auto-populated with current time. Select from NiSource address book drop-down in the event that neither the Primary nor Secondary Production Control person is available. Cannot be changed.V. Reason for Emergency Access: Emergency Access type ONLY. Cannot be changed. Select Type from drop down. The help button next to field provides a definition of the types available. Auto-populated from PC Secondary Support fields on the PROD CNTL tab of the application portfolio. Alternate Team Lead: & Phone: Others to Notify of Change: Primary Production Control: & Phone Number: Secondary Production Control: & Phone Number: Alternate Production Control: & Phone Number: Optional Optional Optional Page 6 of 33 .

location of the code to be migrated) Enter short description of the change. Enter the associated DevTrack number and DevTrack Database name. Page 7 of 33 . (If testing is not possible.Change Description Remedy Help Desk Ticket #: ProjecTrak #: DevTrack #: & DevTrack Database: Enter the associated Remedy Problem Ticket number. Remedy. if available.  Testing has occurred and test results approved  Business Owner has approved implementation  Disaster Recovery impact has been assessed and DR plan updated (if necessary) & System Flowchart(s) have been checked and updated (if necessary).  Back-out Previous Change  Minor Enhancement  New Development  Production Support  Scheduled Maintenance  High Impact  Low Impact  Medium/High Impact  Medium/Low Impact  Mainframe--Blue  Mainframe—Gold  Mainframe—Red  Open VMS  UNIX  Windows  Other Text Text TPR #: Change Reason: Change Complexity: Select from Change Complexity drop-down depending upon the impact anticipated. To tie the ADCM to the original source of the change. Platform: (To select multiple values. Disaster Recovery impact has been assessed and DR plan updated (if necessary) & System Flowchart(s) have been checked and updated (if necessary) Only the ‘Testing’ checkbox needs to be checked at this time. Change Description Change Instructions (Please include the application server name. the next business day). Back-out Instructions Checklist Text  Emergency Checklist Emergency Access type ONLY.) Business Owner has approved implementation. however all must be followed up on by the IT Team Leader and/or Application Developer as soon as possible (typically. Enter the associated Remedy Problem Ticket number. All three Checklist items must be addressed prior to implementation of the change. Enter very detailed instructions about how to perform the change to production. if available. at least one (1) of these four (4) fields (ProjectTrack. hold down on the Ctrl key) Select one or more values from the Platform values list depending upon the platform(s) affected by this change. See pre-steps 5. Enter detailed instructions that will be followed in the event that the change needs to be backed out. server location. enter the reason why. & 7 above:   Testing has occurred and test results approved. or TPR) number must be completed. Enter the associated ProjectTrack number. 6. DevTrack. Select from Change Type drop-down depending on the general type of change being implemented.

Number Optional Production Access Information ENOC Support Analyst: Access Granted: Select the ENOC analyst that is granting the access Text field to describe the access that was granted Name TEXT Completion Actual: Start Date Completion Date Duration (Hours) Filled in by Production Control Person when the change has been completed. Identification of person performing workflow entries. Enter any comments that may be helpful/necessary to completing this request. can be attached here. If there is a Distributed Schedule step with this migration the Distributed Schedule template flag must be set to YES and the template should be attached. Auto-generated based on the Production Control Contact name selected. Enter the Start and Completion Dates.Attachments DBA Template CICS Template Distributing Scheduling Template Mainframe Scheduling Template Other Attachments If there is a DBA step with this migration the DBA template flag must be set to YES and the template should be attached. along with the elapsed time spent performing the change. Used by either the Team Lead or the Developer to explain any nuances or issues that occurred that may be helpful to reference in the future. backout plans. Specific activity performed. Number field for hours spent on the request by PCG. TPR lists. If there is a Mainframe Schedule step with this migration the Mainframe Schedule template flag must be set to YES and the template should be attached. Text to be filled in if migration was rejected Auto generated when Approved Auto generated when Approved Text Production Control Production Control Contact: Phone: Total Time spent on this Request: Comments: Select (your name) the name of the Production Control person who will perform this change from the Production Control Contact drop-down. Optional Optional Optional Optional Optional Approval Approved By: Approval Date and Time: Reason for Rejection: Automatically filled with name of Team Lead that is approving. Completion Code: Lessons Learned    Successful Successful with Problems Unsuccessful Audit Trail Modified Date: User: Action: Historical date of workflow entries. If there is a CICS step with this migration the CICS template flag must be set to YES and the template should be attached. Automatically filled with date and time that IT Team Lead approved this change. Any other attachments such as implementation plans. Page 8 of 33 . Code that indicates if this migration was successful or not. Cannot be changed. This should be the TOTAL hours including all prepreparation time. Cannot be changed.

VI. Scheduled .Expedited Change: Scheduled – Expedited Change Process Flow Page 9 of 33 .

Since the application developer is to be ‘on stand by’ during the change. they will be able to provide any additional information needed to perform the promotion to production. At this point. Once approved. Page 10 of 33 . An audit trail entry is made for each request activity to show the history of change. the Application Developer will fill out another ADCM form and specify the reason for the back out and the process that must be followed. Developer can still go back in a edit the request UNTIL the request is marked approved. In the event that the changes were incorrect or were not applied correctly. go into edit once again on the ADCM and enter the Start Date. he/she must go into edit on the ADCM form and assign himself/herself to do the work. such as: Submitted. When all information has been entered properly in the request form. the IT TEAM LEAD and any others specified to receive such notifications. Step 5: Production Control person makes the change as described. With the developer’s input. it must be verified as correct by the developer. Step 1: Fill out an ADCM Scheduled Change Request form. the developer can no longer edit or make any changes. perform the change to production. however. which he/she will press in order to approve. After the change has been made. Step 6: Mark the change complete. Completed and Signed-off. Using the instructions written by the developer in the ADCM. The status changes to ‘Complete’. At this point. Click the ‘Complete’ button. At the bottom of the form is an EDIT button. This will change the status of the request to ‘Approved’ and an email will be sent to the Production Control mailbox as well as to the Production Control personnel identified in the change form.Scheduled – Expedited Change Steps (Processed via Production Control Group) Pre-steps: Please refer to the Application Change Management Processes and Procedures documentation. Step 4: Assign yourself (PCG) as Production Control. When the Production Control person becomes aware of the request. The status changes to ‘In Production Control’ when this occurs. any Lessons Learned may also be logged into the ADCM. the IT Team Lead may then go in and signoff on the ADCM request. You may want to confer with the developer to verify complete understanding of the change. in Production Control. End Date and Duration. Before doing so. The following fields are required unless specified otherwise: Step 2: Submit the Change Request. Step 7: IT Team Lead signs off. Step 3: Approve the Change Request. When finished making the change. the IT Team Lead must confirm that the change was successful and all pre-requisites have been met. also any comments that may be helpful about the change. and enter the ADCM. Modifications to significant field data along the way are also captured and reflected in the audit trail at the bottom of the form. Approved. click the ‘Submit’ button. The status will be set to ‘Submitted’ and an email notification will be routed to the IT Team Lead(s) to request its approval and to the production control team warning them of the incoming request. Fill out a separate online ADCM for each application that you will be modifying. (This step is skipped for Emergency Change Requests) The IT Team Lead will receive an email notification. The entire ADCM scheduled change process then starts over. click on the link. which will initiate the sending of email to the developer. a scheduled change is ready to be implemented.

This is the when the change should begin and the LATEST that this change should be completed by. 2. Pressing the help button next to this drop down will help select the proper type.Scheduled – Expedited Change Request Process Tutorial ADCM Process flow with Production Control Group’s involvement Who Developer What 1. Fill out ADCM form and select the Change Type. This will trigger most of the Personnel Section to be auto populated from the Application Portfolio. Select the Application Affected from the dropdown list. Complete the form by following the instructions provided. Page 11 of 33 How Developer . Also fill in the requested start and completion date and time.

There MUST be a associated request number that began the need for this change. The form will remind the developer to fill them in before the form can be saved. The remander of the fields ARE required as well.Pay particular attention to the Team Lead names populated from the Application Portfolio for this app. Developer 3. At least one of those numbers MUST be proveded. The next two sections have more detail about the change. If not correct or not available use the ‘Alternate’ TL field to enter a name of someone that is available to approve. Page 12 of 33 .

The last available section is an area for attachments .Developer 4. Nothing is required in this section. Last the developer will hit the submit button. This will send a mail out to the TL’s and PCG to notify them of the pending change. 1.IT Team Lead receives an email notification that an ADCM request is awaiting his/her approval. IT Team Lead (This step is skipped for Emergency Change requests) Page 13 of 33 . The PCG also receives the same mail to warn them that a pending change has been submitted.

If this record is rejected. Click on the link in the email to open the ADCM request.IT Team Lead (This step is skipped for Emergency Change requests) 2. it will require a reason to be filled in and then the Reject button can be pressed. Click on the edit button to set the record to Edit. Approve the request by hitting the approval button. The approve date will automaticall y be captured in the audit trail and set in the approval section. Page 14 of 33 . IT Team Lead (This step is skipped for Emergency Change requests) 3.

Developer (This step is skipped for Emergency Change requests) Receives email notification of Team Lead approval. PCG Person Receives notification that an ADCM is directed to him/her for processing. Page 15 of 33 .

PRODUCTI ON CONTROL Mailbox 1. Open the email and click on the link to the ADCM Page 16 of 33 . An email is also sent to the Production Control Mailbox PCG Person 2.

Page 17 of 33 . Perform ‘Move to Production’ by following instructions contained in the ADCM ‘Change Instructions’ field. PCG Person PCG Person 4. Perform the migration as instructed by the developer in the ADCM ‘Change Instructions’ field. Go back into the ADCM and click on the ‘Edit’ button. Select your name in the Production Control Contact drop-down list. Then hit the ‘Assign Production Control’ button. 5.PCG person 3.

Page 18 of 33 . Enter the Start Date. Completion Date.PCG Person 6. and Duration and Hit the ‘complete’ button.

The IT Team Lead is notified via email that the change is complete. He/she will need to make sure that the developer has verified that the move was successful and all other change requiremen ts have been met before he/she signs off. When ready to sign off. IT Team lead 1.IT Team lead. 2. Team Lead will hit the EDIT button. Page 19 of 33 .

All 4. and the request signed off by hitting the ‘Sign Off’ button. Page 20 of 33 . The change will be officially ‘signed off’ and the audit trail will be updated.IT Team lead 3. ‘Lessons learned’ (post mortem) should be entered as appropriate .

Emergency Access Change: Emergency Access Change Process Flow Revised 10/27/2004 Page 21 of 33 .VII.

Step 1: Fill out an ADCM Emergency Request Change Request form. Assuming the Emergency Change was processed during off-hours. Step 6: As soon as possible (typically. all specified parties receive a copy of it that they should review. the Application Developer enters the Actual Start Date. an emergency change is ready to be implemented. At that time. Making use of the temporary privileges granted by ENOC. When notified via email of impending Emergency Access that the Application Developer is requesting. IT Team Leaders and Others will be copied on the emails generated from the ADCM. When all information has been entered properly in the ADCM request form. the IT Team Lead and the Business Contact should further verify its correctness on the next business day. Anytime an email is generated. it will be necessary to back them out (See Step 6 below). Fill out a separate online ADCM form for each application that you will be modifying. ENOC will then place the Developer’s User-ID into a special security access group that will grant them write access to the production environment. completed. ENOC will grant the access (outside of ADCM) and update the ADCM with the exact access that was granted to the developer and last press the ‘grant access button’ on the ADCM form.Emergency Access Change Steps (Processed via ENOC for Access to Production) Pre-steps: Please refer to the Application Change Management Processes and Procedures documentation. An email notification will be created that will be routed to the Monitor Mailbox (ENOC) to alert them to the Emergency change. and/or cancelled. ENOC is automatically notified via the Monitor Mailbox that the change has been completed and that the special access privilege is no longer needed. This causes an email to be issued to the developer and IT Team Leader notifying them of the access that has been granted. or as soon as possible. and Duration (Hours) into the Completion area of the request form signifying that they no longer need the granted access and that the change has been completed. PROD access granted. the Application Developer will also update any Disaster Recovery plans and/or System Flowchart impacts that are necessary. goes into the Emergency Change Request once again to update the Lessons Learned with any pertinent information. Step 5: Revoke Access. Step 4: Make the Change and Verify Correctness of Change. Step 2: Submit the Change Request. click the ‘Submit’ button. If the changes are ok. Access revoked. The following fields are required unless specified otherwise. This includes those individuals whose name is present in the following fields: Developer Primary Team Lead Secondary Team Lead Business Contact Alternate Team Lead (Others to) Notify of change An audit trail entry is made for each request activity to show the history of change: Submitted. the Application Developer will move the change into production and verify that it is correct. The Application Developer monitors the execution of the software to make sure the changes were made correctly and if so. signed off. The Team Lead has responsibility for finalizing the Emergency Change Request by signing off on its completion including: Verification that the remaining checklist items were addressed: Disaster Recovery impacts & System Flowchart impacts Business Contact follow-up Lessons Learned entered into the Emergency Change Request form. Page 22 of 33 . ENOC then removes the Developer’s User-ID from the special security group and presses the ‘revoke access button’ on the ADCM request to change the status to ‘Access Revoked’. next business day): Signoff to Verify Correctness of Final Change State and Update Lessons Learned. Completion Date. Step 3: Grant access. If the changes were incorrect or if they were not applied correctly. At this point.

How Page 23 of 33 . Emergency Access from drop down and complete the remaining fields as described on the form. unless there is an IT Team Lead approval to extend. Hit the submit button. Fill out ADCM form.Emergency Access Change Request Process Tutorial ADCM Process flow with ENOC’s involvement Who Developer What 1. Note that access will be granted for 24 hours only.

IT TEAM Lead An email is automaticall y sent to the IT Team Lead responsible for the application being modified. ENOC Based on the application selected. MONITOR Mailbox (ENOC) An email appears in the MONITOR mailbox alerting ENOC of the Change request. ENOC identifies the correct access to provide the developer and grants the access. GRANT UPDATE ACCESS Page 24 of 33 .

Page 25 of 33 . ENOC Click on the Edit button ENOC Changes the status of the ADCM from submitted to “Prod Access Granted” by clicking on the ‘Grant Access’ button.ENOC ENOC clicks on the email and goes into the Emergency ADCM request.

Developer. Developer Go back into the ADCM and hit the Edit button. Page 26 of 33 . IT TEAM LEAD Receive email that access is granted. Developer 2. Apply changes to production environmen t Perform Production Update.

Also enter any ‘Lessons Learned’. MONITOR Mailbox (ENOC) An email appears in the Monitor Mailbox to announce that the change is complete and that access can be revoked. REVOKE ACCESS PREVIOUSLY GRANTED Page 27 of 33 . Hit the ‘Complete’ button. the end date and the duration to indicate that the change has been completed. ENOC ENOC revokes access.Developer Enter the start date.

you must first hit the ‘Edit’ button. ENOC Hit the ‘Revoke Access’ button. Email arrives announcing access has been revoked. Page 28 of 33 .ENOC To indicate in ADCM that access has been revoked. Developer . IT TEAM LEAD 1.

Page 29 of 33 . When the IT Team Lead is sure that: (1) the change was successful. scroll to the bottom. There are two boxes that must be checked before the IT Team Lead can click the ‘sign off’ button. (3) the system flowcharts & DR plans are current. (2) the business owner is aware and approves of the change. The IT Team Lead should first hit the ‘edit’ button on the ADCM and when the form appears.IT TEAM LEAD 2. he/she is ready to signoff on the ADCM-typically the next day.

All The audit trail is updated to reflect the signoff. Page 30 of 33 .

Remedy Change Ticket #. Change process away from the Server Group towards the new Production Control 2004 Group. The Scheduled Change Sequence Diagram and process narrative were updated to reflect the changes. the new ADCM system was primarily focused on Emergency Changes processed thru the ENOC area. data description and requirements. and Emergency Change and Change Complexity definitions. Revised Documentation published 2 weeks after implementation added more details to April 12. • Added new red text reminding developer that access will be revoked after 2005 24 hours. DevTrack Database. but the Scheduled Change process requiring ENOC staff to create Remedy tickets to notify the Server Support team. Comments • Creation of a new ‘Production Control’ view for use by the Production Control group Revised Emergency Request—communication around granting and revoking access: February 21. including such new fields/features as: • Production Control Comments box • Primary and Secondary Production Control support personnel • Alternate Production Control support personnel • Assignment of Production Control support personnel • Status description changes to accommodate Production Control support assignment • Platform (added to both the ADCM form and email) • Production Domain Name (added to both ADCM form and email) • Window of Time access is needed (used by ENOC for Emergency Changes only) • Change to allow the Requested Completion Date to be modified by the PCG staff • Update audit trail to reflect new fields and field changes (listed above) and for the following existing fields: ProjecTrak #. More fields were added to assist with this process and the workflow itself was modified to directly route the work thru the Production Control group. A Production Control Mailbox was added allowing the PC group to be notified of incoming requests and a daily ‘sweep agent’ was set up to automatically move matched (submitted with completed/cancelled) emails from the inbox of the new mailbox. Revision History: Documentation Date Description of the changes that were made to the Documentation. a 2004 few screen print examples. was just as it had been defined previously. roles and responsibilities. Revised July’s documentation was needed to better detail the involvement of the Server July 12. Implemented Documentation for the initial implementation consisted of a sequence diagram March 31. At this point. documentation to match the many minor enhancements that have been made to 2005 ADCM during the 4th quarter of 2004. Revised October’s version of the documentation reflects the redirection of the Scheduled October 29. It also discusses the use of the Application Portfolio for auto-populating certain fields. Scheduled changes were also rolled out. Remedy Help Desk Ticket #.VIII. DevTrack #. and a process narrative for each of the two ADCM forms (Emergency Change and 2004 Scheduled Change). • Added reminder and ENOC’s phone number to the display that occurs upon Page 31 of 33 . Revised The purpose of this version of ADCM documentation is to formally ‘catch up’ the January 21. 2004 Support group in the Scheduled Change process. the process rolled out across IT including background. It provided for the separation of duties requirement of SOX to be met by providing a means for the application developer to request production access to make a change and an audit trail to provide the history of access granted and revoked by ENOC.

submission of the ADCM by the developer. • Page 32 of 33 . Audit trail provided. Added two new (required) fields for ENOC to enter the access granted and the remedy ticket number. please contact Production Control person directly. • Testing checkbox can be left blank if there is an explanation provided by the developer. (Save and Close). • Added Production Control name fields and Developer name field to the email that goes to the Production Control mailbox. • Built in new functionality to allow ENOC to edit the access granted field and remedy help ticket field without changing the status of the ADCM. Scheduled Change Request —communication around urgent changes thru Production Control Group: • Text on initial ADCM form changed to say ‘If this change is needed sooner than 2 business days after approval.

Revised Completely revised. Added TPR# and changed the edits that tests for the input from the change numbers Restructured the attachments section and added buttons to indicate if anything is attached Removed the Category. Added Assign ENOC staff button Added help button for Change type definitions Added several new production control views. ADCM is being expanded to collapse all other application April 11. Added a submit time field at top of form Added a SOX 404 indicator that is populated from the NiSource Application Portfolio Added a Test / Production toggle button Added a start time that is required for all changes both normal and emergency Added a completion date / time that is also required. Unhide and Hide some of the existing buttons. Domain Name. removed old one Did some restructuring of the form for easier display and entering of the data Fixed audit trail so it works in the notes client • • • • • • • • • • • • • Page 33 of 33 . not allowing an escape and save Allowed for developers to still edit after the form is submitted up until the time it’s approved. Changed some of the button and section security logic. Moved these date and time fields to the top section of the form Enhanced the drop down for alternate TL so it only selects from the approved approvers list and not from the whole mailbox. There are other modifications being made to also include fields to be sent to the SLA and change management reporting system called Gsmrt. 2007 change management requests into ADCM. Also changed to use Buttons for saving doc. and Detailed description fields. Below is a high level summary of changes. • • • • • • • Modified so that DB form works on native notes and set web interface to read only Added fields necessary for Gsmrt report interface Changed the Change type field from a toggle button from Emergency / Scheduled to a drop down with 5 values.