Content

Document Number: GL-IM-WI-03030
Document Title: Change Management System (ClearQuest)

Current Content Brown, Kim Document Adye, Arthur
Owner: Coordinator:
Status: Effective Effective Date: 03/07/2016
Version: 4.0 End Effective
Date:
Approver's Name and Title Approver's Signature Date/Time

Motiwala, Naeem Director, Global Controls & Risk motiwaln 3/7/2016 4:12:00 AM
Management
Brown, Kim Manager, Global Applications Testing brownkj 1/29/2016 8:22:36 PM
Excellence
GL-IM-WI-03030 Change Management System (ClearQuest) User Page 1 of 28

Instructions
This document is Mead Johnson Nutrition Company confidential and proprietary information.
Individuals printing a copy of an MJNProcedural Documents are responsible for ensuring that revisions to the document have not
been issued since it was printed.
Printed on 03-Sep-2017
Work Instruction
GL-IM-WI-03030
1. Purpose and Scope

The purpose of this Work Instruction (WI) is to provide instructions for creating change
requests in Mead Johnsons Change Management System, ClearQuest.
This Work Instruction is governed by:

PPM-SVCMGT-MJN-1036, MJN Change-Release-Deployment Management PM
GL-IM-SOP-05522, Mead Johnson Nutrition (MJN) Change Management
This WI applies to all personnel working with changes in the Mead Johnson IT environment.
2. Requirements
The following requirements must be met prior to executing this WI:
All ClearQuest users must be trained on this WI.

All ClearQuest users must be trained on the Mead Johnson Change Management
Process.
Active Directory account password must exist.
3. Instructions
3.1 Login to ClearQuest

Note: Users will access the ClearQuest application through a web-based server, and will be
authenticated via an interface with MJN Enterprise Directory.
Step No. Description

1. Type the ClearQuest web address in your browser (such as Internet Explorer)
https://cms.net.mjn.com/cqweb/
2. Click on the User ID field and enter your Active Directory username.
3. Click on the Password field and enter your password corresponding to your username.
4. Click on the Repository field and select the desired repository.

Instructions
5. Click in the Remember User ID check box if you would like for the system to automatically
remember the user name the next time you login.
6. Click the Connect button to log into ClearQuest.
7. To log out of ClearQuest, click the Log out link in the upper right corner.
3.2 Create a Simple Change Request

Note: ALMRequest is the ClearQuest system's term for a Change Request. When a change
request is created, an ALMRequest ID starting with MJNC is created.

1. Click on the New ALMRequest button on the top left of the ClearQuest
Welcome Page.
2. Click on the Request tab in the change request.
a. Choose the appropriate Category Type for the change from the drop down
menu
b. Choose the appropriate Category for the change from the drop down menu
c. Click on the Drill into Category button
d. Click again on Category and choose the appropriate Sub-Category from the
drop-down menu
e. Choose the appropriate Type from the drop-down menu
f. Click on the Headline field and provide a brief description of the change.
Include details such as application names, server names, host names, etc
g. Click in the OwnerRole field and select the appropriate OwnerRole.
h. Click on the Owner field and select the owner for the Change Request. This
is the person from the Owner Role (Group) who is responsible for ensuring
the change requested is completed with all the required information, that the
change is approved prior to the Task Start Date, that the change begins at the
Scheduled Start and that the change is actually done within the agreed upon
change window as indicated in the change record.
Note:Owner can only be selected once the Owner Role is selected.
Note 2: If assigning the change record to another group, do not select an Owner.
It is the responsibility of the leader of the change owner role (group) to distribute
the workload to members of the group. For Pre-Authorized Changes (PAC), the
PAC owner should be selected.
a. Click on the Business Severity drop down menu to choose a severity option.
Low is the default option.

Instructions
b. Click on the Description field. Provide a detailed description of the change
being requested. For PAC, the governing work instruction for the specific PAC
type must be referenced in the description.
3. Click on theDetails tab.
a. Click the CAB Approval Required check box only if the change requires
formal CAB Approval (Critical, Major, or any change that requires
outage/impact).
b. Click on the GxP field and choose an appropriate option (Yes or No). Choose
Yes only if the change is being made to a validated application.
NOTE: If the GxP field is Yes, you MUST ALWAYS add an ad-hoc task for
Validation Approval and assign it to the MJN-IM-QC-Approval workgroup.
You must always do that unless a validation approval task is pre-defined in
the workflow.
c. Click on the Scope of the Change field. Choose either Global or Local
depending on who will be impacted by the change.
d. Click on the Work Type field and choose appropriate work type. Elective
Enhancements (Business Enhancements) are minor automations, new features
or enhancements, new reports or new data requirements. Required
Modifications are code / configuration changes required to address corporate /
legal / audit / compliance driven changes. Major Enhancements are changes
that require the effort of a project. Incidents are changes that are being
implemented to fix an incident record (these require a valid Incident
Management System incident record to be listed on the Related Records tab
in the Impact ID field). PAC should have this field left blank.
e. Click on the Scheduled Start field and choose the Scheduled Start date and
time to indicate when the change will begin. This field will default to the
current date and time. Click inside of the box to select the accurate or
intended Scheduled Start date and time for the overall Scheduled Change
Window (this could include dev/test/QA). Unless the change has already
been implemented as either an Emergency Change or hard copy process
change, the Scheduled Start date will not be earlier than the Change Request
creation date.
f. Click on the Request Complete field and choose the required date and time
for completion of the request.
g. Click on the Risk field and choose appropriate risk level. Risk is the risk for
MJN as a business to do the change it is not how important it is to get the
change implemented. If there is potential impact to financials, many users or
many systems, impact to vital applications, etc. the risk to MJN is greater;
therefore, the risk is greater. The greater the risk, the longer the change needs
to be entered in ClearQuest prior to implementation.

Instructions
NOTE 1: Use the Risk Assessment Template to assist with risk level
assignment.
NOTE 2: Do NOT choose Information Only unless the change is an

approved PAC type or the change is really for communicating information
(nothing is being changed).
h. The Expedite Code becomes a mandatory field if the duration between the
date of change entry and scheduled start is less than the lead time for Risk
planning. For every risk there is a specific amount of time that the change
must be in ClearQuest before it can be implemented. This is called lead time
and is there to allow all parties time to review the change and get it approved
prior to the scheduled start time. For example, the current date is Sept 16,
2014 04:00 PM CDT. The Scheduled Start is Sept 18, 2014 09:00 PM CDT.
The scheduled start is thus 2 days and 5 hours from now. However, the Risk
is Major and needs a lead time of 8 days. Since 2 days is less than the
required 8 days, the Expedite Code becomes mandatory. Click on the drop
down next to the Expedite Code field and choose the appropriate option (If
Incident or Emergency is selected, the Related Records Tab becomes
mandatory. You will have to enter a valid Incident Management System
incident record number in the Impact ID field on the Related Records tab).
NOTE: If Emergency is selected, all tasks within the request are required to be
completed within three business days of the implementation of the change. This
is a critical compliance requirement.The Change Record must be closed within 7
business days after implementation has been completed. The 7 days includes
Process Review time + Changing of the state to the final value.
i. Click in the Expedite Reason field. Detail the business reason for expediting
the change as per the chosen expedite code. This field becomes required if
the lead time based on the risk is not met. The Expedite reason listed must
match the Expedite code chosen or the change will need to be rescheduled to
meet the required lead time for the risk.
Expedite Code When its used Required detail
Customer Customer has business Full name of

reason for an urgent requesting customer
request and reason for
urgency

Instructions
Expedite Code When its used Required detail
Emergency Ongoing severity 1 or Emergency changes

2 incident requires are changes needed to
change to resolve recover from valid,
ongoing Severity 1
incidents.
Severity 2
(Minor/Medium Risk
w/no outage) may also
be handled as
Emergency changes to
meet business SLAs.
Incident Change needed to Associated incident

resolve an open record and reason for
incident urgency
Schedule Conflict Schedule modification Detailed explanation

to resolve a change of the conflict
collision or business including conflicting
conflict change record number
if applicable
j. Click in the Remediation Plan field and document how this change can be
backed out and service restored to the state it was prior to beginning the
change. This field is optional at the Request Level, but required at the
Planning Task Level.
k. Click in the Business Assessment field and describe how this change will
benefit MJN and whether the request is within scope of the contract (if
applicable). This field is optional at the Request Level, but required at the
Planning Task Level.
l. Click in the Technical Assessment field. Describe whether this change is
following technical standards and whether all resources are available to
implement the change when scheduled. This field is optional at the Request

Instructions
Level, but required at the Planning Task Level.
4. a. Click the Save button on top right corner of the request to save the request.
Note: clicking the Save button will close down the record.
b. If routine PAC execution, do not perform steps 5, 6, and 7 below.

5. Reopen the request from the Recently Viewed box on the left pane.
6. Click the Utilities button on the upper right and click on Create Task. The pre-
defined workflow for the Change Request is populated in the Task section of the
Request. See 3.12 below for creating ad-hoc tasks.
7. To enter details for additional tabs (Attachments, Related Records, SAP) please
see instructions below).
3.3 Retrieve a Change Request

1. A change request can be found by entering the Request ID in the Search textbox in the
top of the left panel. Enter the Request ID and click on the Search button. An easier
way to search for the ID is to just input the numerical values (ignoring the leading
zeros) in the request. For example, if the ALMRequest ID is MJNC00000852, a user can
search just for 852 to open the request.
3.4 Working with Attachments

Note: Attachments can be added at the Request and Task levels. The process is the same for
both levels. Attachments cannot be deleted but can only be inactivated. For PAC all
attachments should be performed at the Request level.
3.4.1 Add an Attachment

1. Click on the Attachments tab.
2. Click Modify.
3. Click the Add button to add an attachment to the Request.
4. Click on Browse to select the file to attach.
5. Choose the file and double-click on the file you would like to attach.
NOTE: If the path to your document is greater than 50 characters, you will receive an
error when you attempt to save. To remedy, move your target file to a different
location and attempt to reattach.

Instructions
6. Enter a description for the file to be attached in the Description field. The description
should indicate the purpose of the attachment (i.e., if the attachment is evidence that
the change was completed, the description should indicate that it contains completion
evidence: i.e. the Description could be listed as Completion Evidence).
7. Click the Add button to add the attachment.
8. Click the Save button to save the request with the attachment. After the request is
saved, the attachment will appear in the Attachment Extension box.
3.4.2 Inactivate an Attachment

1. Click on the Attachments Tab.
2. The attachment that was added will be displayed in the Attachment Extension box.
Here the attachment can be inactivated if the user has the privileges to inactivate the
attachment.
3. To inactivate an attachment, right-click on the attachment information.
4. Click on Open Record.
5. Click the Modify button on top right corner of the dialog box.
6. Click on the Inactivate option to inactivate the attachment. The inactivate option is
shown if the user has the privileges to inactivate attachments.
7. Click in the Status field and enter reason for inactivation.
8. Click the Save button in the dialog box.
9. The Status of the attachment is shown as Inactive in the Attachment Extension Box.
3.4.3 Download an Attachment

1. Click on the Attachments Tab.
2. To download an attachment, click on the attachment you wish to download.
3. Click on the Download button.
4. Click the Save button and save the file to the desired location.
3.5 Working with Related Records Tab

1. Click on the Related Records tab.

Instructions
2. Click Modify.
3. Click on the Impact ID field. This is a mandatory field if the Expedited Code on the
Details tab has the value Incident or Emergency. Type a validIncident Management
SystemIncident or Problem number into the Impact ID field. if applicable.
4. The Requests Related field can be used to associate other change requests to the
current request.
a. To add an existing record, click the Add button to add an existing related change
request to the current request. Click the Search button, select the change request
you would like to relate to the current record and then click on OK. The added
change request is displayed in the Related Records box.
b. To remove a related record, click on the record to select it. Then click the Remove
button to remove the related record.
c. To create a new record, click on the New button to create a new change request
that relates to the current change record. The 'New Request Related' window
opens. You can now create the new change request as you would create any other
change request.
5. The Requests Related Back field provides a list of change requests that are
referencing the current request.
6. Click on Save to save the changes.
3.6 Working with SAP Tab

3.6.1 Add a New SAP Record
Only privileged user groups will be able to perform these actions and only after a specific task has
been completed.

1. Once a request is ready to receive the transport numbers, open the request and click on
the SAP tab.
2. Click on the Modify button (in the top right corner of the request).
3. To add a New SAP record: click the New button to add a new SAP record.
4. Click on the External ID Type field and select the appropriate option.
5. Choose the correct ID type:
Transport (SAP system ID to move the objects to the next system)
OSS (on line SAP service)
DVL (Development)

Instructions
TPR (Test Problem Report)
6. Click on the SAP Reference Number field and type in the unique SAP Reference
Number.
7. Click on the SAP Sequence Number and type in the SAP sequence number.
8. Click on the Transported field. When the transport has been moved to the target
system, change the No to Yes. Only privileged user groups will be able to perform this
action.
9. The Request ID is automatically filled in the Request ID field.
10. Click on the Obsolete field only if the record is obsolete.
11. Click on the Save button to save the new SAP record.
12. The New SAP record that was created will be displayed.
Note: The SAP record can be modified by opening the record and clicking on Modify
on the top right corner of the SAP record.
3.6.2 Add an Existing SAP Record to a Request

1. The SAP tab fields cannot be modified until a request is saved. Once a request is
saved, open the request and click SAP tab.
2. Click the Modify button (in the top right corner of the request) to modify the request.
3. Click the Add button to add an existing SAP record.
4. Click Search button from the dialog box that pops up.
5. Choose the SAP record you would like to add from the list of records that populate
when the Search button is clicked.
6. Click the OK button.
7. The SAP record that you added will be displayed in the SAP box.
8. Click on the Save button to save the changes made to the request.
3.6.3 Remove a SAP Record

1. The SAP tab fields cannot be modified until a request is saved. Once a request is
saved, open the request and click on the SAP tab.
2. Click on the Modify button (in the top right corner of the request) to modify the
request.
3. To remove a record, click on the record and then click on the Remove button.

Instructions
4. Click the Save button to save the changes made to the request.
3.6.4 View Audit Log for SAP

1. The Audit Trail tab has a detailed log of changes made to the SAP record. This is
populated after the SAP record has been saved. Double-click on the SAP record that
you wish to view the audit log for.
2. Click on the Audit tab when the SAP record dialog box opens. The details of changes
made to that particular record can be seen.
3. Click on the x button (upper right of the pop up window) to close the SAP record
after the audit log has been viewed for that SAP record.
3.7 Changing the State of a Request

3.7.1 Accepting (i.e. Closing) a Request
For the change request to be accepted, all the tasks must be completed and the Change Manager must
click on the Process Reviewed box.The Change Record must be closed within 7 business days after
implementation has been completed. The 7 days includes Process Review time + Changing of the
state to the final value.

1. Change requests can be closed only by the change owner.
2. Click on Change State on the top right corner of the request.
3. Click on the Accept option. The resolution tab becomes mandatory as soon as the
Accept option is clicked.
4. Click on the Resolution tab to enter details.
a. Click on the Resolution Code field and select appropriate resolution code.

Instructions
b. Click on each field under Actual Complete and enter the date and time that the
change was completed (do not choose the current date and time: be specific and
accurate).
c. Click in the Resolution Summary field and enter details for resolution. Describe
the outcome of the change request in detail.
d. If the change was not successful, the reason as well as the actions taken to recover
to original state must be noted. Paste these questions into the Resolution
Summary field and answer them:
What happened?
What was the impact to MJN?
What caused the change to fail?
What was done to restore service?
What was done to ensure this would not fail again?
NOTE 1: A RCA will be completed for ALL failed change implementations

resulting in an impact to the business and all Unauthorized changes. Change
Owners are to open an Incident Ticket and/or Problem Ticket to begin the RCA
Procedures. The approvers of the change will be identified in the RCA.
NOTE 2: Any subsequent attempts to implement a failed change must be initiated

as a new change record to provide authentic change measurements and reports.
5. Click the Save button which will change the state to Completed.
3.7.2 Rejecting a Request

1. Changes should not be rejected at the request level as this will close the change as
Rejected. If a change is not going to be implemented, the request should be cancelled

Instructions
(withdrawn). See 3.7.3 below.
NOTE: Changes rejected at the Request Level will render the record unusable and
completely closed (end of change cycle). Rejecting at the task level will keep the
record alive and usable and open for rescheduling/modifications, if necessary.
3.7.3 Cancelling (withdrawing) a Request

1. Change requests can be cancelled only by the change owner.
2. Click on Change State on the top right corner of the request.
3. Click on the Cancel option. The resolution tab becomes mandatory as soon as the
Cancel option is clicked.
a. Click on the Resolution Code field and select Cancelled as the resolution code.
b. Click on the fields under Actual Complete and enter the date and time when the
change is being cancelled.
c. Click on the Resolution Summary field and enter a detailed reason why the
change is being cancelled.
5. Click the Save button to save and cancel the request. A request in the Withdrawn state
cannot be reopened.
3.8 Indicate that CAB Approval has been Received

Note: This activity can only be performed by users with the CAB Approval role.

1. Click on Modify on the top right corner of the request.
2. Click in the box next to the CAB_ApprovalReceived option. This option is available
only to privileged groups/users. CAB Approval can be done at any time during the
request, but must be done before the overall request is Accepted (closed).
3. The eSignature tab becomes mandatory as soon as the CAB_ApprovalReceived box
is clicked. Click on the eSignature tab to sign and approve.
4. Enter your username in the Username field.
5. Enter your ClearQuest password in the Password field.
6. Click the Save button to save the request.

Instructions
3.9 Editing the Task Tab in a Task
1. Click on Modify on the top right corner of task.
2. Click on the Owner field to choose owner of the task (REQUIRED). Select
appropriate task owner.
NOTE: The default response of admin is acceptable for the owner field at the task
level.
3. Click on the Description field to modify the description, if required.
4. Priority and Status fields will not be used for change management.
5. Click the Save button to save changes made to the task.
3.10 Editing the Planning Tab in the Planning Task

1. A Planning Task is mandatory for all non PAC Requests (on the CMS Configuration
tab the Does Type contain planning information? field is set to YES for the task).
For AdHoc tasks, click CMS Configuration to select YES for the Does Type contain
planning information?
2. Click the Planning tab to enter required information in the tab.
3. Click Operator Intervention Required check box if a server operator needs to take
part in this change.
4. Enter the date and time when the change will begin in the Task Start Date field. Be
specific. Do not choose the current time.
NOTE: The Scheduled Task Window must be included as part of the overall
Scheduled Change Window (Request Level).
5. Click on the Planned End Date field and list the date/time when this task should be
completed. NOTE: This should be the Task Start Date and Time PLUS the Estimated
Duration (which includes the Back out Duration). Example: if the Task Start Date &
Time is July 22, 2014 04:00PM and the Estimated Duration is set for 5 hours and 15
minutes, the Planned End Date and Time should be July 22, 2014 09:15PM.
6. Click on the Customer Impact During Change field and select Yes if MJN will be
impacted during the change implementation. If there will be no Customer impact,
select No.
NOTE: If Customer Impact During Change is YES, details must be documented

Instructions
in the Assets/Outage Tab (Planning Task Level).
7. Click on the Estimated Duration field and list how long it will take to install this
change AND back it out. Note: this should indicate the worst case scenario of how
long it will take to install and to potentially back it out if something goes wrong
during the installation.
8. Click in the Business Assessment field and copy and paste the questions below into
the field and answer in detail.
Is the Risk to the business documented correctly?
Does the change conform to the business goals and objectives?
Is there any impact on business cycles (like month-end processing)?
Will this change impact any SLAs?
9. Click in the Technical Assessment field and copy and paste the questions below into
the field and answer in detail.
Does the change conform to industry technical standards?
Is the Change Plan complete?
Does the change have an accurate estimated service outage or impact to
committed service level agreements?
10. Click on the Back-out Duration fields and list how long it will take to back out the
change and restore the system/application back to its original state.
11. Click on the Back-out Duration in Estimated Duration field and select Yes or No.
The Estimated Duration is an estimation of the total time will take to install a change
and potentially back it out and restore the system/application back to its original state.
If the Estimated Duration does NOT include the Back out Duration, select No and
provide a detailed explanation in the Step-by-Step Back-out/Remediation Plan
field.
12. Click in the Step-by-Step Back-out/Remediation Plan field and list all the steps
necessary to Back-out the task. This should be a DETAILED list of what needs to be
done and how it will be done.
13. Click in the Step-by-Step Implementation Plan field and detail the step-by-step
instructions needed to be followed to implement the change. This details HOW the
task will be installed.
14. Click in the Pre-Implementation Test Results field and detail how this task was
tested to ensure it would go into production successfully AND what the results were
of that testing. All test results MUST be attached to the change record or referenced
back to a separate task or different change record.
15. Click in the Post- Implementation Test Plan field and detail what steps must be
taken to test that the change was implemented correctly after this change has been
implemented (WHO will test and/or HOW the change will be tested).
16. Click the Save button to save the changes to the task.

Instructions
3.11 Editing the Assets/Outage Tab in the Planning Task
Note: The Assets and Outage Tab Contains a list of impacted assets and expected outage
information. This tab must be completed every time there will be impact to a server, even if
it is in a maintenance window or has a redundant server.
1. Click on the Assets/Outage tab.
2. Click on the Outage Required field. The field defaults to No. If an outage is
required, change the value to Yes. If Yes is chosen, the Outage Type, Scheduled
Down and Scheduled Up fields will become required fields.
NOTE: Outage/Impact can be defined as interruption to an IT service or reduction in
the quality of an IT service: anything outside of the normal delivery of a
service/system/application; such as, but not limited to: service/performance
availability, disruption, degradation, accessibility, etc...
3. Click on the Outage Type field and choose the appropriate outage type from the drop
down menu.
Backup means the server is down, but it has a redundant server. It means
there is no customer impact during the change on this server
Degraded means the server will still be active, but users will experience slow
response while working on that server.
Exempt means there will be an outage to the server, but the customer agrees
with the time and duration that the server will be down; therefore, there will be no
impact to Service Level Agreements (SLAs).
Outage means there will be an outage to a server and it will impact one or
more SLAs. This usually only occurs while resolving an incident where the
outage is unplanned.
4. Click on the Scheduled Down field and enter the date and time that the outage will
begin. NOTE: This outage must be within the change window so if the change needs
to be rescheduled, the outage times will need to be rescheduled.
5. Click on the Scheduled Up field and enter the date and time that the outage will end.
NOTE: This date and time must be at or before the end of the Estimated Duration.
6. To add an asset:
a. Click the Add button and a dialog box opens.
b. Click on the Search button in the dialog box.
NOTE 1: Server names are case sensitive.
NOTE 2: If an asset cannot be located or is not available, send an email with

Instructions
your asset update request to MJNs Change Management Function.
c. Lists of assets are displayed. Choose the asset to add from the list of assets and
click OK button.
d. The asset will be displayed in the asset box in the Assets/Outage tab.
To remove an asset:
a. Click on the asset in the Assets box and then click Remove button.
7. Click the Save button to save changes to the task.
3.12 Adding an Ad-Hoc Task

Notes: In addition to the pre-defined tasks that are populated for a Request, Ad-Hoc tasks
can also be added to a request. Once an Ad-Hoc task is created, the task can be modified
just like any other task. An Ad-Hoc task cannot be deleted once it is added. The CMS
Configuration tab and fields are disabled for pre-defined tasks; however, if an Ad-Hoc task
is added by any user, the CMS Configuration tab becomes active and must be filled out with
the necessary information. If an Ad-Hoc task is mistakenly added, it must be closed as not
applicable.
These steps can ONLY be performed after the predefined tasks have been created.

1. Click Utilities on the top right corner of the request and then choose Create Task
create an AdHoc task.
2. The AdHoc task will be added to the bottom of the Task list. Double-Click on the
AdHoc task to open it.
3. Click the Modify button on the top right corner of the task.
4. Click on the CMS Configuration tab. This is a mandatory tab for AdHoc tasks.
a. Click on the IBM Planning Fields? and choose Yes if the task will be for adding
planning information. This should only apply when using the generic CTI. If Yes
is chosen, then the Planning Tab becomes mandatory. If this is any other type of
task, the value should be No.
b. Click the Is Type an Approval Task? field and choose Yes if the task is an
additional Approval task. Otherwise, leave it as No.
Note: if this change is impacting a validated application, database or server an
approval AdHoc task must be added and assigned to the MJN-IM-QC-Approval
workgroup. You must always do that unless a validation approval task is pre-
defined in the workflow.
c. Click on the Complete Order field and enter the sequence number according to
the order of completion. Make sure that the sequence number for the AdHoc task
Instructions
is not the same as another defined task in the workflow. This field should never
be left with a value of 0.
Example: If the Validation Approval is needed, the sequence number should be set
to a number that is BEFORE the last approval task (which is generally the Owner
Group Approval task).
d. Click on Rollback Start and enter the sequence number of the task to roll back to
if the task is rejected. All tasks that had been completed after that sequence
number will be re-opened and the Rollback Start task will be activated. This field
should never be left with a value of 0.
Example: For AdHoc approval tasks for an application change, the Rollback start
should be set to the sequence number of the planning task. All approvals that had
been given will be reopened and the planning task will become Activated.
e. To assign the task to a particular workgroup, remove all other workgroups (except
for Change_Management). To remove a role, click on the role in the Roles field
and click on the Remove button. Do not leave only Change_Management in the
Roles field or it will be rejected.
f. Click on the 'Reason for AdHoc Task' field and detail the reason for adding the
task.
5. Click on the Task tab to enter details in the Task tab.
a. Click on the Headline field of the AdHoc task and edit it to reflect the task
purpose. The task name for an AdHoc task cannot be changed, but the Headline
can be changed.
b. Enter the description of the task in the Description Field.
c. Click on the Owner field to choose owner of the task (REQUIRED). Select
appropriate task owner.
NOTE: The default response of admin is acceptable for the owner field at the
task level.
6. Click the Save button to save the changes made to the AdHoc task.
3.13 Changing State of a Task

Note: Only an Activated task can be completed. Additionally, any required attachments
must be added before changing the task state to Completed.
3.13.1 Completing an Activated Task

1. Select the task to be completed and double-click to open it.

Instructions
2. Click Change State on the top right corner of the window and select Complete
3. The Resolution tab becomes mandatory when the state of the task is set to Complete.
If the task is an Approval task, the eSignature tab also becomes mandatory.
a. Click on the Resolution Code field and select appropriate resolution code.
NOTE: If you choose Not Applicable, you must enter a detailed valid reason why
the task is not applicable.
b. Click on the fields under Actual Complete and enter date and time of task
completion. NOTE: On the last task which is for confirming that the change was
implemented, the date and time must be entered accurately to indicate when a
change was completed. If not, the change will appear to have been completed
after the approved change window ended. Do not just select those fields without
selecting the correct date and especially the correct time (be aware of AM and
PM).
c. Click on the Resolution Summary field and enter whether the task was
successful or not.
For approval tasks, just put Approved in this field.
For the last task confirming the change was implemented, state whether
the change was successful AND where the evidence is attached that
proves the change was completed.
5. For Approval tasks, click on the eSignature tab.
a. Click on the Username field and enter your username.
b. Click on the Password field and enter your password.
c. Click the Save button to save the changes.
d. The task has been approved after the above steps. The state of the task is now
Completed.
3.13.2 Rejecting a Task

1. Select the task to be rejected and double-click to open it.
2. Click Change State on the top right corner of the task window and choose Reject
3. The Resolution tab becomes mandatory when the state of the task is set to reject.
a. Click in the Reject Reason field and enter reason for rejection.
5. Click the Save button to save the changes.
6. All tasks from the rejected task back to the Rollback Start number task will be re-
Instructions
opened and the Rollback Start number task will become the Activated task.
3.14 Documenting Emergency Changes
NOTE: In order to perform an emergency change, there must be an existing and valid
Severity 1 or Severity 2 (if Severity 2, the risk must be Medium/Minor and no production
outage required for resolution) incident record in Incident Management System. DO NOT
change the severity once the incident has been resolved. All tasks in an emergency change
request must be documented and approved within 3 business days of the implementation of
the change.The Change Record must be closed within 7 business days after
implementation has been completed.The 7 days includes Process Review time + Changing of
the state to the final value.
1. In the Incident Management System, document the full name of the IBM and/or MJN
representatives (or their delegate) who gave verbal approval to perform the
Emergency Change. Also include the date and time approval was received.
Approvals must come from IBM SDM and/or MJN IM System Owner.
2. Save the record in the Incident Management System.

3. Create and Record RFC
a. Create and record RFC to begin the process of documenting the Emergency
Change. Collect basic information about the Change from the appropriate
parties. This information may already be documented in the form of an Incident
Record or Problem Record. Only the request needs to be completed before
implementing the change.
b. Enter the names of the persons who gave verbal approval (include the date and
time approval was received) in the Description field along with the detailed
description of the change that was performed.
NOTE: Verbal approval is required by the appropriate IBM and/or MJN
representatives (or their delegate). Document verbal approval in the Emergency
Change record and also in the Incident Ticket. Include the name of the person
who provided the approval and the date/time approval was received. Approvals
must come from IBM SDM and/or MJN IM System Owner.
c. In the Expedite Code field, choose Emergency.
d. In the Expedite Reason field, describe why the change needed to be
implemented as an emergency.
e. On the Related Records tab, enter the Incident Management
Systemrecord number in Impact ID field.
4. Implement Change.
a. Implement the change.
Instructions
b. Test the change to verify everything is working as planned.
c. If needed, execute the back-out plan in order to restore the system/component
to its pre-change status.
d. Update the Incident Management System record and Emergency Change
record with the results of the implementation and any post-implementation
testing results.
5. After the change is completed, follow instructions outlined in Sections 3.2 to 3.6 and
3.8 to 3.13, above, to complete all tasksand finish documenting the Emergency
Change record, in ClearQuest.
a. On the Planning task, the Task Start Date field must correspond to when the
emergency change actually began. The Planned End Date and time should
indicate when the change was completed
b. When closing the final task confirming the change was implemented,
accurately indicate the date and time when the change was completed in the
Actual Complete fields on the Resolution tab.
c. All Emergency Changes must be properly approved (as required),
documented, complete, correct, installed, verified, tasks complete, and the
record approved within 3 business days. The Change Record must
be closed within 7 business daysafter implementation has been
completed.The 7 days includes Process Review time + Changing of the state
to the final value.
NOTE: Process Review Check (PRC) will be required prior to closing the change
record. Please contact your IBM Change Manager to complete the PRC.
6. Close the Emergency Change Record
a. Follow instructions as referenced in Section 3.7, above, to close your
Emergency Change record.
3.15 Establishing Pre-Authorized Changes
NOTE: In order to be eligible for a Pre-Authorized Change type, the change must be low
risk, low complexity, low or no financial impact, have a minimum of four documented
successful executions of the change in CQ, and have a document work instruction that
outlines the modification process, implementation steps, and testing required.
1. Complete PAC Request form and discuss change applicability for PAC status with the
MJN Change Management Function. Upon agreement with the PAC Request form,
the MJN Change Manger will create a PAC CTI for the change.
2. Create work instruction for the specific type of change desired to become pre-
authorized.

Instructions
This work instruction must contain step-by-step instructions on how to make the
change, what testing is required and how to implement the change. The title of the
work instruction should begin with PAC. Individuals who support the PAC-related
application or have the responsibility to perform an implementation step that is
outlined within the procedure are required to be trained on the procedure.
3. Create and process a change ticket in CQ with the PAC CTI. All standard approvals
are required with the addition of the IBM and/or MJN Change Managers. The PAC
Request form (IM-FRM-006) and the approved work instruction must be attached to
the ticket.
3.16 Recertifying and Reviewing Pre-Authorized Changes Semi-

annually
NOTE: Pre-Authorized changes are required to have semi-annual review and recertification.
1. The PAC owner must create a PAC CQ ticket on a semi-annual basis using the PAC
CTI with approval tasks (including IBM and/or MJN Change Managers), attaching a
list of the specific PAC executions for the six month period (if any), the approved
PAC work instruction, and the PAC Request form (IM-FRM-006).
If no PAC executions exist for the semi-annual period that should be noted in the
change description.
2. The PAC CTI approvers must review all PAC executions for the six month period (if
any) verifying activities executed were appropriate for the PAC and adhere to the
implementation procedure. As part of the review, the PAC CTI approvers verify that
the type of change covered by the PAC still meets the criteria for PAC status. Upon
receipt of all approvals, the PAC will be approved for another six months.
3.17 Open and Run Queries

1. Only queries in the Public folder are approved to be opened and run for regulated
purposes.
2. Click on the arrow before Public Queries in the ClearQuest Navigator, to display the
Instructions
corresponding list of existing queries.
3. The list of Public Queries opens in the ClearQuest Navigator. They are categorized
by use. The Admin, Security and Support folders contain queries for Administrator
and Change Management usage only.
4. Double-click on the query and the results of the query are displayed.
5. Personal queries are NOT to be used for regulated purposes. If a new Public query is
required, please contact the ClearQuest system owner.
4. Roles and Responsibilities
Roles Responsibilities
Manager, SDLC Approve this WI
and IT Change
Management
Director, IT Approve this WI
Governance, Risk
and Compliance
ClearQuest Users Create Change Requests and perform work entailed in the workflows
MJN Change MJNs Change Management Function together with the IBM Change
Management Manager are responsible for the overall quality of the Change
Function Management process and verifies that Changes are communicated in a
timely and adequate manner. He or she is the main coordinator within
this process and is the focal regarding Changes for both MJN and the IT
organization. Therefore, managers in the IT organization are required to
support the individual in this role. MJNs Change Management
Function consists of 2 distinct teams: 1 A production control function
responsible for overall change scheduling and CAB coordination and 2
The individual technology team that will review and execute an
individual change.
IBM Change The IBM Change Manager is primarily responsible for the overall
Manager quality of the Change Management Process, serving as the main
coordinator and the focal point regarding Changes for both the customer
and the IT Organization. Managers in the IT Organization support the
individual in this role.
Requester The Requester is the person who represents the function that has the
business/service/technical need for the change.
Change Owner The Change Owner is responsible for an individual Change and follows
the Change from beginning to end, bringing in analysts and specialists as
needed to complete the project. The Change Owner is responsible for

Instructions
seeing that analysts and specialists bring the Change to a close.
Change Analyst TheChangeAnalystusesdeeptechnicalknowledgeandsubjectmatterexper
seto understandbusiness
andtechnicalissuesandimpactsregardingproposedChange.Analysisinvol
estheunderstandingof
causesandeffects.TheChangeAnalystusestheknowledgegainedfrom
analysistomake recommendationsorresolutions.
Change Assessor AChangeAssessoris
responsibleforassessingaRequestforChangeandassigningitto oneof the
approvalstatuses.ChangeAssessorsaretypicallyrepresentativesof
groupsdirectlyinvolvedin or impactedbytheChange.
Change Authority TheChangeAuthority,whichmaybe
theChangeAdvisoryBoard(CAB),hasthepowertoauthorizea
Change.Thisrightmaybeprovidedto amanager,an executive,orateam of
people.
Change Reviewer TheChangeRevieweris
anadvisoryrolewithintheChangeManagementprocessanddoesnotformal
y approveorreject.
Change TheChangeImplementercarriesoutan authorizedChange.
Implementer
Change Queue TheChangeQueueManagermaintainsaqueueof prioritizedChanges.
Manager
Change Advisory Approve change requests that require CAB Approval and or Review.
Board (CAB)
IT Governance, Verify change control includes the correct validation documentation
Risk and and signatures.
Compliance
Manager, SDLC Ensures the Change Management Process is followed by the
and IT Change Organization. Owns and oversees the process and supporting
Management documentation for the Change Management Process.
5. Definitions (optional)
Not Applicable
6. Appendices (optional)
Not Applicable

Instructions
7. Forms and Templates
GL-IM-FRM-05313, Pre-Authorized Change Request
8. References
PPM-SVCMGT-MJN-1036, MJN Change /Release/ Deployment Management PM
V4
GL-IM-SOP-05522, Mead Johnson Nutrition (MJN) Change Management
GL-IM-FRM-05344, Change Risk/Impact Categorization Form
GL-IM-FRM-05347, Business and Technology Assessment Form
9. Contact Information
Direct Questions about this Procedural Document to:
Manager, SDLC and Change Management

Mead Johnson Nutrition
Evansville, Indiana

Instructions
Document History
Effective Date Version Author(s) Description

Number
See document 1.0 Michelle Jolly First Issue
header
June 6, 2011 1.0 Jeff Wolf This document has been
migrated from the BMS
EpicStar Legacy system. The
current effective version in the
legacy system was selected and
loaded into the Global
Procedural Document
Management System in Draft
status. It will go through the
approval process to be made
effective and assigned version
number 1 regardless of the
previously approved version
numbers.
Updates Include: Update url
(3.1.1); Roles and
Responsibilities (4); and Contact
Information (9).
August 1, 201l 2.0 Jeff Wolf Major revisions throughout
entire document.
June 8, 2012 3.0 Jeff Wolf Revised emergency change
documentation timing from one
business day to three business
days.
March 7, 2013 4.0 Jeff Wolf Modified scope to specify
applicable to all personnel
working with changes in the
Mead Johnson IT
environment instead of just
MJN and IBM personnel.
Added instructions around
Pre-Authorized Changes
(PAC):
3.2 Step 2h
3.2 Step 3g

Instructions
3.2 Step 4b
3.10, Step 1
3.15
3.16
Added IM-FRM-006, Pre-
Authorized Change Request
Modified 3.17 to specify
non-public queries cannot be
used for regulated purposes.
October 8, 2013 5.0 Jeff Wolf Revised section 3.14 to
clarify that a change request
record must be opened
before an emergency change
can be implemented in
Production.
October 3, 2014 6.0 Jeff Wolf & Major revisions throughout
Karen Ellis entire document.
October 13, 7.0 Jeff Wolf Updated numbering
2014 Updated references
August 7, 2015 1.0 Migrated This document was
Document programmatically renamed
from IM-WI-1848 to GL-
IM-WI-03030, and version
number reset to 1.0. No
content changes were made.
October 12, 2.0 Kim Brown Updated footer and reference
2015 section for new PDMS
numbers
Documented number of
business days for closure of
changes is 7.
January 27, 3.0 Kim Brown Updated section 3.14 to
2016 include changes of type
Severity 2 and
Medium/Minor Risk with no
production outage to be
handled via the Emergency
Change Process.
Upon Last 4.0 Kim Brown Updated section 3.7.1 step
Approval 4a.
Instructions
Instructions

Content

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Content

Uploaded by

Copyright:

Available Formats

Document Number: GL-IM-WI-03030

Document Title: Change Management System (ClearQuest)

Approver's Name and Title Approver's Signature Date/Time

GL-IM-WI-03030 Change Management System (ClearQuest) User Page 1 of 28

1. Purpose and Scope

This Work Instruction is governed by:

All ClearQuest users must be trained on this WI.

3.1 Login to ClearQuest

Step No. Description

GL-IM-WI-03030 Change Management System (ClearQuest) User Page 2 of 28

3.2 Create a Simple Change Request

Step No. Description

GL-IM-WI-03030 Change Management System (ClearQuest) User Page 3 of 28

GL-IM-WI-03030 Change Management System (ClearQuest) User Page 4 of 28

NOTE 2: Do NOT choose Information Only unless the change is an

Expedite Code When its used Required detail

Customer Customer has business Full name of

GL-IM-WI-03030 Change Management System (ClearQuest) User Page 5 of 28

Emergency Ongoing severity 1 or Emergency changes

Incident Change needed to Associated incident

Schedule Conflict Schedule modification Detailed explanation

GL-IM-WI-03030 Change Management System (ClearQuest) User Page 6 of 28

b. If routine PAC execution, do not perform steps 5, 6, and 7 below.

3.3 Retrieve a Change Request

3.4 Working with Attachments

3.4.1 Add an Attachment

GL-IM-WI-03030 Change Management System (ClearQuest) User Page 7 of 28

3.4.2 Inactivate an Attachment

3.4.3 Download an Attachment

3.5 Working with Related Records Tab

GL-IM-WI-03030 Change Management System (ClearQuest) User Page 8 of 28

3.6 Working with SAP Tab

Step No. Description

GL-IM-WI-03030 Change Management System (ClearQuest) User Page 9 of 28

3.6.2 Add an Existing SAP Record to a Request

3.6.3 Remove a SAP Record

GL-IM-WI-03030 Change Management System (ClearQuest) User Page 10 of 28

3.6.4 View Audit Log for SAP

3.7 Changing the State of a Request

Step No. Description

GL-IM-WI-03030 Change Management System (ClearQuest) User Page 11 of 28

NOTE 1: A RCA will be completed for ALL failed change implementations

NOTE 2: Any subsequent attempts to implement a failed change must be initiated

3.7.2 Rejecting a Request

GL-IM-WI-03030 Change Management System (ClearQuest) User Page 12 of 28

3.7.3 Cancelling (withdrawing) a Request

3.8 Indicate that CAB Approval has been Received

Step No. Description

GL-IM-WI-03030 Change Management System (ClearQuest) User Page 13 of 28

3.10 Editing the Planning Tab in the Planning Task

NOTE: If Customer Impact During Change is YES, details must be documented

GL-IM-WI-03030 Change Management System (ClearQuest) User Page 15 of 28

NOTE 2: If an asset cannot be located or is not available, send an email with

3.12 Adding an Ad-Hoc Task

Step No. Description

3.13 Changing State of a Task

3.13.1 Completing an Activated Task

Step No. Description

GL-IM-WI-03030 Change Management System (ClearQuest) User Page 18 of 28

3.13.2 Rejecting a Task

3.14 Documenting Emergency Changes

2. Save the record in the Incident Management System.

3.15 Establishing Pre-Authorized Changes

GL-IM-WI-03030 Change Management System (ClearQuest) User Page 21 of 28