Move to ProductionProcedures

APPLICATION DEVELOPMENT

CHANGE MANAGEMENT

(ADCM)

Implemented March 31, 2004Revised April 12, 2004Revised July 12, 2004

Revised October 29, 2004Revised January 27, 2005

Last Revised February 21, 2005

Last Revised April 30, 2007Documented 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.................................................................................................9Scheduled – Expedited Change Steps............................................................................................................10Scheduled – Expedited Change Request Process Tutorial............................................................................11

VII. Emergency Access Change:....................................................................................................................20

Emergency Access Change Process Flow.....................................................................................................20Emergency Access Change Steps..................................................................................................................21Emergency Access Change Request Process Tutorial...................................................................................22

VIII. Revision History:...................................................................................................................................29

Page 2 of 30

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 production-computing 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 30

III. Change Type:

A Normal Change is planned and entered at least 3 business days in advance. It is approved, thought out, tested, and communicated to all affected parties well in advance of the update. In all cases, there is plenty of time to follow the normal approval process before the change is made. Normal Scheduled changes are processed thru the Production Control group (PCG) who performs the change to the production-computing environment.

An Expedited Change is something that has 1-2 business days notice. 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. These changes are also processed thru the Production Control group (PCG) who performs the change to the production-computing environment. 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.

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. Usually, some type of problem or event has occurred (or soon will) that will negatively impact a production system (i.e. Device, database, application, etc.) In this case, an immediate resolution is needed and there may not be enough time to follow the normal approval process before applying the change. It is a change that could be related to an off hours callout or an unscheduled run, restart, or cancellation of a scheduled batch job or job stream or a restart of a failed application server process. This change has little to no notification but the developers still need the PCG to make the change. The normal pre-approval is not needed for this type of change. The approval will be provided when the TL signs off on the change after the fact.

An Emergency Access change is similar to the Expedited Schedule change except for this change the developer is making the change themselves. Again it is characterized by the inability to anticipate or plan for it in advance. Usually, some type of problem or event has occurred (or soon will) that will negatively impact a production system (i.e. Device, database, application, etc.) Also in this case, an immediate resolution is needed and there may not be enough time to follow the normal approval process before applying the change. 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.

NORMAL CHANGE:Lead Time = 3 business days or more.A Normal Change is planned. It is approved, thought out, tested, and communicated to all affected parties well in advance of the update.

EXPEDITED CHANGE:Lead Time = 1 – 2 business days.An Expedited Change is a special request of the customer or IT to implement as soon as possible. There is still time to receive ALL reviews and sign-offs and those are available BEFORE the migration will take place. 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.

EMERGENCY CHANGE:Lead Time = 0 – 8 hours (Same Day Request).An Emergency Change is a change that has very little notice but still requires PCG to execute the change. There is no time to receive any reviews or sign-offs before the change will take place. Developer and Team Lead must follow up with anything missing within 1 business day and approval is provided by the Team Lead sign-off.

EMERGENCY ACCESS:Lead Time = none.An Emergency Access change is characterized by the inability to anticipate or plan for it in advance; there is no Lead Time. 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 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. Developer and Team Lead must follow up with anything missing within 1 business day and approval is provided by the Team Lead sign-off.

Page 4 of 30

IV. 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 DB is located on Sever OHAPPS01/OH/Server, the path is local\NCS\IT\App_Dev_Chg_Req.nsf

To add the DB to your Lotus workspace, perform the following:

1. While in Lotus Drop Down File >>> Database>>>Open>>

2. Put OHAPPS01 in the server name

3. Follow the path to find the DB

4. Once found, highlight, and click push the open button and that will open the DB and add it to the workspace for future access

Page 5 of 30

V. ADCM Field Names and Descriptions:

Field Name Description Values/DetailsRequest Status: This value is auto-generated based on where the

scheduled change is in the workflow process. New Submitted Approved In Production Control Production Access Granted Production Access Revoked Completed Signed Off Cancelled

Submit Date: Auto-populated with current date. Current DateSubmit Time: Auto-populated with current time. Current Time

Request ID: Auto-generated unique request identifier. Generated numberRequestor: Auto-generated with the person creating the request. User Name

Change Type: Select Type from drop down. The help button next to field provides a definition of the types available.

Normal Change Expedited Change Emergency Change Emergency Access

Application Affected: Select from drop-down. Drop down populated from Application Portfolio

SOX 404 Application: Is this flag to indicate if this is a 404 Application Auto Populated via Application Portfolio

Environment? Select test or production Test or ProductionRequested Start Date / Time: Date and Time the implementation of this request is to

begin. Date / Time Value

Requested Completion Date / time: Date and Time the implementation of this request is to end. Date / Time ValueReason for Emergency Access:

Emergency Access type ONLY.Short description of why this access was required. Text

PersonnelApplication Primary Support

Contact:Auto-populated from Application Portfolio

Developer & Phone Number: Auto-generated with your name & phone number determined by your Logon-ID. Cannot be changed.

Developer ACID: Auto-generated with your fully qualified User-ID determined by your Logon-ID. Cannot be changed.

Business Contact: Auto-populated from Client Contact field on the application portfolio. Cannot be changed.

Primary Team Lead: & Phone Number:

Auto-populated from Primary IT Team Lead fields on the application portfolio. Cannot be changed.

Secondary Team Lead: & Phone Number:

Auto-populated from Secondary IT Team Lead fields on the application portfolio. Cannot be changed.

Alternate Team Lead:& Phone:

Select from NiSource address book drop-down in the event that neither the Primary nor Secondary IT Team Lead is available. The selection list is limited to a group of NiSource IT approvers.

Optional

Others to Notify of Change: Select from NiSource address book drop-down Optional

Primary Production Control: & Phone Number:

Auto-populated from PC Primary Support fields on the PROD CNTL tab of the application portfolio. Cannot be changed.

Secondary Production Control: & Phone Number:

Auto-populated from PC Secondary Support fields on the PROD CNTL tab of the application portfolio. Cannot be changed.

Alternate Production Control: & Phone Number:

Select from NiSource address book drop-down in the event that neither the Primary nor Secondary Production Control person is available. The selection list is limited to a group of PCG members in the address book.

Optional

Page 6 of 30

Change Description

Remedy Help Desk Ticket #: Enter the associated Remedy Problem Ticket number. To tie the ADCM to the original source of the change, at least one (1) of these four (4) fields (ProjectTrack, DevTrack, Remedy, or TPR) number must be completed.

ProjecTrak #: Enter the associated ProjectTrack number, if available.DevTrack #:

& DevTrack Database:Enter the associated DevTrack number and DevTrack Database name, if available.

TPR #: Enter the associated Remedy Problem Ticket number.

Change Reason: Select from Change Type drop-down depending on the general type of change being implemented.

Back-out Previous Change Minor Enhancement New Development Production Support Scheduled Maintenance

Change Complexity: Select from Change Complexity drop-down depending upon the impact anticipated.

High Impact Low Impact Medium/High Impact Medium/Low Impact

Platform:(To select multiple values, 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.

Mainframe--Blue Mainframe—Gold Mainframe—Red Open VMS UNIX Windows Other

Change Description Enter short description of the change. Text

Change Instructions(Please include the application server

name, server location, location of the code to be migrated)

Enter very detailed instructions about how to perform the change to production.

Text

Back-out Instructions Enter detailed instructions that will be followed in the event that the change needs to be backed out.

Text

Checklist All three Checklist items must be addressed prior to implementation of the change. See pre-steps 5, 6, & 7 above:

Testing has occurred and test results approved. (If testing is not possible, enter the reason why.)

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)

Emergency ChecklistEmergency Access type ONLY.

Only the ‘Testing’ checkbox needs to be checked at this time, however all must be followed up on by the IT Team Leader and/or Application Developer as soon as possible (typically, the next business day). 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).

Page 7 of 30

Attachments

DBA Template If there is a DBA step with this migration the DBA template flag must be set to YES and the template should be attached.

Optional

CICS Template If there is a CICS step with this migration the CICS template flag must be set to YES and the template should be attached.

Optional

Distributing Scheduling Template 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.

Optional

Mainframe Scheduling Template 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.

Optional

Other Attachments Any other attachments such as implementation plans, backout plans, TPR lists, can be attached here.

Optional

Approval

Approved By: Automatically filled with name of Team Lead that is approving. Cannot be changed.

Auto generated when Approved

Approval Date and Time: Automatically filled with date and time that IT Team Lead approved this change. Cannot be changed.

Auto generated when Approved

Reason for Rejection: Text to be filled in if migration was rejected Text

Production Control

Production Control Contact: Select (your name) the name of the Production Control person who will perform this change from the Production Control Contact drop-down.

Phone: Auto-generated based on the Production Control Contact name selected.

Total Time spent on this Request: Number field for hours spent on the request by PCG. This should be the TOTAL hours including all pre-preparation time.

Number

Comments: Enter any comments that may be helpful/necessary to completing this request.

Optional

Production Access Information

ENOC Support Analyst: Select the ENOC analyst that is granting the access Name

Access Granted: Text field to describe the access that was granted TEXT

Completion

Actual: Start Date Completion Date Duration (Hours)

Filled in by Production Control Person when the change has been completed. Enter the Start and Completion Dates, along with the elapsed time spent performing the change.

Completion Code: Code that indicates if this migration was successful or not.

Successful Successful with Problems Unsuccessful

Lessons Learned 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.

Audit Trail

Modified Date: Historical date of workflow entries.

User: Identification of person performing workflow entries.

Action: Specific activity performed.

Page 8 of 30

VI. Scheduled - Expedited Change: Scheduled – Expedited Change Process Flow

Page 9 of 30

Scheduled – Expedited Change Steps(Processed via Production Control Group)

Pre-steps: Please refer to the Application Change Management Processes and Procedures documentation.

At this point, a scheduled change is ready to be implemented.

Step 1: Fill out an ADCM Scheduled Change Request form. Fill out a separate online ADCM for each application that you will be modifying. The following fields are required unless specified otherwise:

Step 2: Submit the Change Request. When all information has been entered properly in the request form, 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. An audit trail entry is made for each request activity to show the history of change, such as: Submitted, Approved, in Production Control, Completed and Signed-off. Modifications to significant field data along the way are also captured and reflected in the audit trail at the bottom of the form. Developer can still go back in a edit the request UNTIL the request is marked approved.

Step 3: Approve the Change Request. (This step is skipped for Emergency Change Requests) The IT Team Lead will receive an email notification, click on the link, and enter the ADCM. At the bottom of the form is an EDIT button, which he/she will press in order to approve. 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. Once approved, the developer can no longer edit or make any changes.

Step 4: Assign yourself (PCG) as Production Control. When the Production Control person becomes aware of the request, he/she must go into edit on the ADCM form and assign himself/herself to do the work. The status changes to ‘In Production Control’ when this occurs.

Step 5: Production Control person makes the change as described. Using the instructions written by the developer in the ADCM, perform the change to production. You may want to confer with the developer to verify complete understanding of the change. 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.

Step 6: Mark the change complete. When finished making the change, go into edit once again on the ADCM and enter the Start Date, End Date and Duration, also any comments that may be helpful about the change. Click the ‘Complete’ button, which will initiate the sending of email to the developer, the IT TEAM LEAD and any others specified to receive such notifications. The status changes to ‘Complete’.

Step 7: IT Team Lead signs off. After the change has been made, it must be verified as correct by the developer. With the developer’s input, the IT Team Lead may then go in and signoff on the ADCM request. Before doing so, however, the IT Team Lead must confirm that the change was successful and all pre-requisites have been met. At this point, any Lessons Learned may also be logged into the ADCM.

In the event that the changes were incorrect or were not applied correctly, the Application Developer will fill out another ADCM form and specify the reason for the back out and the process that must be followed. The entire ADCM scheduled change process then starts over.

Page 10 of 30

Scheduled – Expedited Change Request Process Tutorial

ADCM Process flow with Production Control Group’s involvement

Who What HowDeveloper 1. Fill out ADCM

form and select the Change Type. Pressing the help button next to this drop down will help select the proper type. Also fill in the requested start and completion date and time. This is the when the change should begin and the LATEST that this change should be completed by.

Developer 2. Select the Application Affected from the dropdown list. This will trigger most of the Personnel Section to be auto populated from the Application Portfolio. Complete the form by following the instructions provided. Pay particular attention to the Team Lead names populated from the Application Portfolio for this app. If not correct or not available use the ‘Alternate’ TL field to enter a name of someone that is available to approve.

Page 11 of 30

Developer 3. The next two sections have more detail about the change. There MUST be a associated request number that began the need for this change. At least one of those numbers MUST be proveded. The remander of the fields ARE required as well. The form will remind the developer to fill them in before the form can be saved.

Developer 4. The last available section is an area for attachments. 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.

Page 12 of 30

IT Team Lead

(This step is skipped for Emergency Change requests)

1.IT Team Lead receives an email notification that an ADCM request is awaiting his/her approval.

The PCG also receives the same mail to warn them that a pending change has been submitted.

IT Team Lead

(This step is skipped for Emergency Change requests)

2. Click on the link in the email to open the ADCM request. Click on the edit button to set the record to Edit.

Page 13 of 30

IT Team Lead

(This step is skipped for Emergency Change requests)

3. Approve the request by hitting the approval button. The approve date will automatically be captured in the audit trail and set in the approval section. If this record is rejected, it will require a reason to be filled in and then the Reject button can be pressed.

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 14 of 30

PRODUCTION CONTROL Mailbox

1. An email is also sent to the Production Control Mailbox

PCG Person 2. Open the email and click on the link to the ADCM

Page 15 of 30

PCG person 3. Select your name in the Production Control Contact drop-down list. Then hit the ‘Assign Production Control’ button.

PCG Person 4. Perform the migration as instructed by the developer in the ADCM ‘Change Instructions’ field.

Perform ‘Move to Production’by following instructions contained in the

ADCM ‘Change Instructions’ field.

PCG Person 5. Go back into the ADCM and click on the ‘Edit’ button.

Page 16 of 30

PCG Person 6. Enter the Start Date, Completion Date, and Duration and Hit the ‘complete’ button.

Page 17 of 30

IT Team lead. 1. 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 requirements have been met before he/she signs off.

IT Team lead 2. When ready

to sign off, Team Lead will hit the EDIT button.

Page 18 of 30

IT Team lead 3. ‘Lessons learned’ (post mortem) should be entered as appropriate, and the request signed off by hitting the ‘Sign Off’ button.

All 4. The change will be officially ‘signed off’ and the audit trail will be updated.

Page 19 of 30

VII. Emergency Access Change: Emergency Access Change Process Flow

Page 20 of 30

Revised 10/27/2004

Emergency Access Change Steps (Processed via ENOC for Access to Production)

Pre-steps: Please refer to the Application Change Management Processes and Procedures documentation.

At this point, an emergency change is ready to be implemented.

Step 1: Fill out an ADCM Emergency Request Change Request form. Fill out a separate online ADCM form for each application that you will be modifying. The following fields are required unless specified otherwise.

Step 2: Submit the Change Request. When all information has been entered properly in the ADCM request form, click the ‘Submit’ button. An email notification will be created that will be routed to the Monitor Mailbox (ENOC) to alert them to the Emergency change. 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. IT Team Leaders and Others will be copied on the emails generated from the ADCM.

Anytime an email is generated, all specified parties receive a copy of it that they should review. This includes those individuals whose name is present in the following fields:DeveloperPrimary Team LeadSecondary Team LeadBusiness ContactAlternate Team Lead(Others to) Notify of change

An audit trail entry is made for each request activity to show the history of change: Submitted, PROD access granted, Access revoked, completed, signed off, and/or cancelled.

Step 3: Grant access. When notified via email of impending Emergency Access that the Application Developer is requesting, 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. This causes an email to be issued to the developer and IT Team Leader notifying them of the access that has been granted.

Step 4: Make the Change and Verify Correctness of Change. Making use of the temporary privileges granted by ENOC, 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, goes into the Emergency Change Request once again to update the Lessons Learned with any pertinent information. If the changes were incorrect or if they were not applied correctly, it will be necessary to back them out (See Step 6 below). If the changes are ok, the Application Developer enters the Actual Start Date, Completion Date, 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.

Step 5: Revoke Access. ENOC is automatically notified via the Monitor Mailbox that the change has been completed and that the special access privilege is no longer needed. 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’.

Step 6: As soon as possible (typically, next business day): Signoff to Verify Correctness of Final Change State and Update Lessons Learned. Assuming the Emergency Change was processed during off-hours, the IT Team Lead and the Business Contact should further verify its correctness on the next business day, or as soon as possible. At that time, the Application Developer will also update any Disaster Recovery plans and/or System Flowchart impacts that are necessary.

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 impactsBusiness Contact follow-upLessons Learned entered into the Emergency Change Request form.

Page 21 of 30

Emergency Access Change Request Process TutorialADCM Process flow with ENOC’s involvement

Who What HowDeveloper 1. Fill out ADCM

form. Emergency Access from drop down and complete the remaining fields as described on the form. Hit the submit button. Note that access will be granted for 24 hours only, unless there is an IT Team Lead approval to extend.

Page 22 of 30

IT TEAM Lead An email is automatically sent to the IT Team Lead responsible for the application being modified.

MONITOR Mailbox (ENOC)

An email appears in the MONITOR mailbox alerting ENOC of the Change request.

ENOC Based on the application selected, ENOC identifies the correct access to provide the developer and grants the access.

GRANT UPDATE ACCESS

Page 23 of 30

ENOC ENOC clicks on the email and goes into the Emergency ADCM request.

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.

Page 24 of 30

Developer, IT TEAM LEAD

Receive email that access is granted.

Developer 2. Apply changes to production environment Perform Production Update.

Developer Go back into the ADCM and hit the Edit button.

Page 25 of 30

Developer Enter the start date, the end date and the duration to indicate that the change has been completed. Also enter any ‘Lessons Learned’. Hit the ‘Complete’ button.

MONITOR Mailbox (ENOC)

An email appears in the Monitor Mailbox to announce that the change is complete and that access can be revoked.

ENOC ENOC revokes access.

REVOKE ACCESS PREVIOUSLY GRANTED

Page 26 of 30

ENOC To indicate in ADCM that access has been revoked, you must first hit the ‘Edit’ button.

ENOC Hit the ‘Revoke Access’ button.

Developer,IT TEAM LEAD

1. Email arrives announcing access has been revoked.

Page 27 of 30

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

All The audit trail is updated to reflect the signoff.

Page 28 of 30

VIII. Revision History: Documentation

Date Description of the changes that were made to the Documentation.Implemented

March 31, 2004Documentation for the initial implementation consisted of a sequence diagram and a process narrative for each of the two ADCM forms (Emergency Change and Scheduled Change). At this point, the new ADCM system was primarily focused on Emergency Changes processed thru the ENOC area. 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. Scheduled changes were also rolled out, but the Scheduled Change process requiring ENOC staff to create Remedy tickets to notify the Server Support team, was just as it had been defined previously.

Revised April 12, 2004

Documentation published 2 weeks after implementation added more details to the process rolled out across IT including background, roles and responsibilities, a few screen print examples, data description and requirements, and Emergency Change and Change Complexity definitions.

Revised July 12, 2004

July’s documentation was needed to better detail the involvement of the Server Support group in the Scheduled Change process. The Scheduled Change Sequence Diagram and process narrative were updated to reflect the changes.

Revised October 29, 2004

October’s version of the documentation reflects the redirection of the Scheduled Change process away from the Server Group towards the new Production Control Group. 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. It also discusses the use of the Application Portfolio for auto-populating certain fields.

Revised January 21, 2005

The purpose of this version of ADCM documentation is to formally ‘catch up’ the documentation to match the many minor enhancements that have been made to ADCM during the 4th quarter of 2004, 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 #, DevTrack #, DevTrack Database, Remedy Help Desk Ticket #, Remedy Change Ticket #, Comments

Creation of a new ‘Production Control’ view for use by the Production Control groupRevised

February 21, 2005Emergency Request—communication around granting and revoking access:

Added new red text reminding developer that access will be revoked after 24 hours. Added reminder and ENOC’s phone number to the display that occurs upon submission of the ADCM by

the developer. Added two new (required) fields for ENOC to enter the access granted and the remedy ticket number. 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. (Save and Close). Audit trail provided.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, please contact Production Control person directly.

Added Production Control name fields and Developer name field to the email that goes to the Production Control mailbox.

Testing checkbox can be left blank if there is an explanation provided by the developer.

Page 29 of 30

Revised April 11, 2007

Completely revised. ADCM is being expanded to collapse all other application change management requests into ADCM. There are other modifications being made to also include fields to be sent to the SLA and change management reporting system called Gsmrt. 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. 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. 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. 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, Domain Name, and Detailed description fields. Changed some of the button and section security logic. Also changed to use Buttons for saving doc, not

allowing an escape and save Allowed for developers to still edit after the form is submitted up until the time it’s approved. Unhide and Hide some of the existing buttons. Added Assign ENOC staff button Added help button for Change type definitions Added several new production control views, 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 30 of 30