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 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 33
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 33
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 33
V. ADCM Field Names and Descriptions:

Field Name Description Values/Details

Request Status: This value is auto-generated based on where the New
scheduled change is in the workflow process. Submitted
Approved
In Production Control
Production Access Granted
Production Access Revoked
Completed
Signed Off
Cancelled
Submit Date: Auto-populated with current date. Current Date
Submit Time: Auto-populated with current time. Current Time
Request ID: Auto-generated unique request identifier. Generated number
Requestor: Auto-generated with the person creating the request. User Name
Change Type: Select Type from drop down. The help button next to field Normal Change
provides a definition of the types available.
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 Production
Requested Start Date / Time: Date and Time the implementation of this request is to Date / Time Value
begin.
Requested Completion Date / time: Date and Time the implementation of this request is to end. Date / Time Value
Reason for Emergency Access: Short description of why this access was required. Text
Emergency Access type ONLY.
Personnel
Application Primary Support Auto-populated from Application Portfolio
Contact:
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: Auto-populated from Primary IT Team Lead fields on the
& Phone Number: application portfolio. Cannot be changed.
Secondary Team Lead: Auto-populated from Secondary IT Team Lead fields on
& Phone Number: the application portfolio. Cannot be changed.
Alternate Team Lead: Select from NiSource address book drop-down in the event Optional
& Phone: that neither the Primary nor Secondary IT Team Lead is
available. The selection list is limited to a group of
NiSource IT approvers.
Others to Notify of Change: Select from NiSource address book drop-down Optional
Primary Production Control: Auto-populated from PC Primary Support fields on the
& Phone Number: PROD CNTL tab of the application portfolio. Cannot be
changed.
Secondary Production Control: Auto-populated from PC Secondary Support fields on the
& Phone Number: PROD CNTL tab of the application portfolio. Cannot be
changed.
Alternate Production Control: Select from NiSource address book drop-down in the event Optional
& Phone Number: 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.

Page 6 of 33

Remedy Help Desk Ticket #:
ProjecTrak #:
DevTrack #:
& DevTrack Database:
TPR #:
Change Reason:
Change Complexity:
Platform:
(To select multiple values, hold down on the
Ctrl key)
Change Description
Change Instructions
(Please include the application server
name, server location, location of the code
to be migrated)
Back-out Instructions
Checklist
Emergency Checklist
Emergency Access type ONLY.
Change Description
Enter the associated Remedy Problem Ticket number. To tie the ADCM to the original
Enter the associated ProjectTrack number, if available. source of the change, at least one
Enter the associated DevTrack number and DevTrack (1) of these four (4) fields
Database name, if available. (ProjectTrack, DevTrack, Remedy,
Enter the associated Remedy Problem Ticket number. or TPR) number must be
completed.
Select from Change Type drop-down depending on the  Back-out Previous Change
general type of change being implemented.  Minor Enhancement
 New Development
 Production Support
 Scheduled Maintenance
Select from Change Complexity drop-down depending  High Impact
upon the impact anticipated.  Low Impact
 Medium/High Impact
 Medium/Low Impact
Select one or more values from the Platform values list  Mainframe--Blue
depending upon the platform(s) affected by this change.  Mainframe—Gold
 Mainframe—Red
 Open VMS
 UNIX
 Windows
 Other
Enter short description of the change. Text
Enter very detailed instructions about how to perform Text
the change to production.
Enter detailed instructions that will be followed in the Text
event that the change needs to be backed out.
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)
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 33
 Attachments
DBA Template If there is a DBA step with this migration the DBA Optional
template flag must be set to YES and the template
should be attached.
CICS Template If there is a CICS step with this migration the CICS Optional
template flag must be set to YES and the template
should be attached.
Distributing Scheduling Template If there is a Distributed Schedule step with this Optional
migration the Distributed Schedule template flag must
be set to YES and the template should be attached.
Mainframe Scheduling Template If there is a Mainframe Schedule step with this Optional
migration the Mainframe Schedule template flag must
be set to YES and the template should be attached.
Other Attachments Any other attachments such as implementation plans, Optional
backout plans, TPR lists, can be attached here.
Approval
Approved By: Automatically filled with name of Team Lead that is Auto generated when Approved
approving. Cannot be changed.
Approval Date and Time: Automatically filled with date and time that IT Team Auto generated when Approved
Lead approved this change. Cannot be changed.
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. Number
This should be the TOTAL hours including all pre-
preparation time.
Comments: Enter any comments that may be helpful/necessary to Optional
completing this request.
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 Filled in by Production Control Person when the change
Completion Date has been completed. Enter the Start and Completion
Duration (Hours) Dates, along with the elapsed time spent performing the
change.
Completion Code: Code that indicates if this migration was successful or  Successful
not.  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 33
VI. Scheduled - Expedited Change:
Scheduled – Expedited Change Process Flow

Page 9 of 33
 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 33
 Scheduled – Expedited Change Request Process Tutorial

ADCM Process flow with Production Control Group’s involvement

Who What How
Developer 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.

Page 11 of 33
 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.
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.

Page 12 of 33
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.
IT Team 1.IT Team
Lead Lead
receives an
(This step is email
skipped for notification
Emergency that an
Change ADCM
requests)
request is
awaiting
his/her
approval.

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

Page 13 of 33
IT Team 2. Click on
Lead the link in
the email to
(This step is open the
skipped for ADCM
Emergency request.
Change Click on the
requests)
edit button
to set the
record to
Edit.

IT Team 3. Approve
Lead the request
by hitting
(This step is the approval
skipped for button. The
Emergency approve
Change date will
requests)
automaticall
y 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.

Page 14 of 33
Developer Receives
email
(This step is notification
skipped for of Team
Emergency Lead
Change approval.
requests)

PCG Receives
Person notification
that an
ADCM is
directed to
him/her for
processing.

Page 15 of 33
PRODUCTI 1. An email
ON is also sent
CONTROL to the
Mailbox Production
Control
Mailbox

PCG 2. Open the

Person email and
click on the
link to the
ADCM

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

PCG 4. Perform
Person the Perform ‘Move to Production’
migration as by following instructions contained in the
instructed ADCM ‘Change Instructions’ field.
by the
developer in
the ADCM
‘Change
Instructions’
field.
PCG 5. Go back
Person into the
ADCM and
click on the
‘Edit’
button.

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

Page 18 of 33
 IT Team 1. The IT
lead. 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.
IT Team 2. When
lead ready to
sign off,
Team Lead
will hit the
EDIT
button.

Page 19 of 33
IT Team 3. ‘Lessons
lead 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 20 of 33
 VII. Emergency Access Change:
Emergency Access Change Process Flow

Revised 10/27/2004

Page 21 of 33
 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:
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, 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 impacts
Business Contact follow-up
Lessons Learned entered into the Emergency Change Request form.

Page 22 of 33
 Emergency Access Change Request Process Tutorial
ADCM Process flow with ENOC’s involvement
Who What How
Developer 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 23 of 33
IT TEAM An email is
Lead automaticall
y sent to the
IT Team
Lead
responsible
for the
application
being
modified.

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

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

Page 24 of 33
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 25 of 33
Developer, Receive
IT TEAM email that
LEAD access is
granted.

Developer 2. Apply
changes to
production Perform Production Update.
environmen
t

Developer Go back into

the ADCM
and hit the
Edit button.

Page 26 of 33
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 An email
Mailbox appears in
(ENOC) 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 27 of 33
 ENOC To indicate
in ADCM
that access
has been
revoked,
you must
first hit the
‘Edit’
button.

ENOC Hit the

‘Revoke
Access’
button.

Developer 1. Email
, arrives
IT TEAM announcing
LEAD access has
been
revoked.

Page 28 of 33
IT TEAM 2. When the
LEAD 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.

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

Page 30 of 33
VIII. Revision History:
Documentation
Date Description of the changes that were made to the Documentation.
Implemented Documentation for the initial implementation consisted of a sequence diagram
March 31, and a process narrative for each of the two ADCM forms (Emergency Change and
2004 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 Documentation published 2 weeks after implementation added more details to
April 12, the process rolled out across IT including background, roles and responsibilities, a
2004 few screen print examples, data description and requirements, and Emergency
Change and Change Complexity definitions.
Revised July’s documentation was needed to better detail the involvement of the Server
July 12, 2004 Support group in the Scheduled Change process. The Scheduled Change
Sequence Diagram and process narrative were updated to reflect the changes.
Revised October’s version of the documentation reflects the redirection of the Scheduled
October 29, Change process away from the Server Group towards the new Production Control
2004 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 The purpose of this version of ADCM documentation is to formally ‘catch up’ the
January 21, documentation to match the many minor enhancements that have been made to
2005 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 group
Revised Emergency Request—communication around granting and revoking access:
February 21, • Added new red text reminding developer that access will be revoked after
2005 24 hours.
• Added reminder and ENOC’s phone number to the display that occurs upon
Page 31 of 33
 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 32 of 33
 Revised Completely revised. ADCM is being expanded to collapse all other application
April 11, 2007 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 33 of 33