Change Documentation

Document Number: D0000004084 Windchill Revision: AD State: Released
Document number: D0000004084

Name: Change Management – Normal Change Creation
Revision: AD
Work instruction
Table of Contents
1. Purpose .............................................................................................................................................................................. 2
2. Scope ................................................................................................................................................................................... 2
3. References......................................................................................................................................................................... 2
4. Definitions......................................................................................................................................................................... 2
5. Roles and responsibilities .......................................................................................................................................... 3
6. Process flow ..................................................................................................................................................................... 5
7. Work Instructions.......................................................................................................................................................... 7
8. Appendices ..................................................................................................................................................................... 44
9. Revision History ........................................................................................................................................................... 51
Printed copies for reference only Stryker Confidential – This document contains information that is confidential and
proprietary. Neither this document nor the information herein may be reproduced, used, or
disclosed to or for the benefit of any third party without the prior written consent of Stryker.
Date Released: Jan 11, 2022 18:11:56 GMT Page 1 of 52
Page 1 of 51

Revision: AD
Work instruction
1. Purpose
1.1. The purpose of this work instruction is to provide detailed instructions for managing
Stryker Information Technology (IT) Normal change records (CHG) in ServiceNow (SN). It
builds on the change management principles described in ISSOP_CMA_001.
2. Scope
2.1. The scope of this work instruction includes all changes made to any hardware or software
managed by IT globally for Normal Changes only.
2.2. This work instruction applies to all staff, service, location, contractors/consultants, and/or
third parties providing services to Stryker IT on Stryker-managed systems or services.
3. References
3.1. Internal references
 ISSOP_CMA_001, Change Management
 ISSOP_INM_001, Incident Management
 ISSOP_SDM_001.T07, Test Script
 KB11876, ServiceNow: Change Control Access
3.2. External references
Not applicable
4. Definitions
4.1. Locally defined terms
4.1.1. CAB: Change Advisory Board
4.1.2. CCB: Change Control Board (phase)
4.1.3. Configuration Item (CI): A CI can be any conceivable IT component, including
software, hardware, documentation, and personnel, as well as any combination
of them, under the control of configuration management. Configuration items
may vary widely in complexity, size, and type, ranging from an entire service or
system including all hardware, software, documentation and support staff to a
single software module or a minor hardware component.
4.1.4. Configuration Management Database (CMDB): The CMDB is a database that
contains all relevant information about the components of the information
system used in the organization's IT services, and the relationships between
those components. The CMDB provides an organized view of data and a means
of examining that data from any desired perspective. Within this context,
components of an information system are referred to as configuration items
(CIs).
Page 2 of 51

Revision: AD
Work instruction
4.1.5. Emergency Change: A change introduced as soon as possible (e.g., to restore a
critical business process or implement a security patch where adherence to the
normal change process would negatively impact the business).
4.1.6. GxP: A general term for Good Practice quality guidelines and regulations. For
IT, the term specifically refers to systems or services that contribute to product
quality, patient safety, or quality system records.
4.1.7. IT: Information Technology
4.1.8. Normal Change: A change initiated from business need or request (e.g., Request
[REQ], Incident [INC), Problem [PRB], Project [PRJ), etc.), and follows the
complete change management process.
4.1.9. Sarbanes-Oxley (SOX): System changes that impact or potentially impact
accounting or reporting processes or related data. This includes changes to
reports or data that are used for financial analysis, reporting, or the
performance of key controls.
4.1.9.1. For reference: The federal law called Sarbanes–Oxley Act of 2002
(Pub.L. 107–204, 116 Stat. 745, enacted July 30, 2002). The law also
known as “Public Company Accounting Reform and Investor
Protection Act” and “Corporate and Auditing Accountability and
Responsibility Act”. This legislation came into force in 2002 and
introduced major changes to the regulation of financial practice and
corporate governance. The act specifically applies to publicly traded
companies.
4.1.10. Standard Change: A change that is an accepted solution to an identifiable and
relatively common set of requirements, where authority is effectively given in
advance of implementation. These changes are low risk, occur on a regular
basis, and are initiated using a Request (REQ).
4.1.11. UAT: User Acceptance Testing
5. Roles and responsibilities

5.1. Approver
5.1.1. Role given to all approvers in the approval groups (CAB, QA, and SOX approval
groups) - these roles have limited visibility to the change tabs in ServiceNow.
5.1.2. Evaluates change requests for risk, business need, and potential impacts to
other systems or processes.
5.1.3. Grants permission to perform a change procedure action (e.g., initiate
development or deploy change into controlled environment).
5.1.4. Represents expertise as required; includes business processes, IT,
Quality\System, regulatory (GxP, SOX), etc.
Page 3 of 51

Revision: AD
Work instruction
5.2. Change Lead (Assigned to)
5.2.1. Develops, schedules, and coordinates change activities from New to Closed.
5.2.2. Ensures any training, procedure updates, and changes to validated state are
considered and addressed.
5.2.3. Can edit all the fields of the change record in new phase. See KB11876 for the
change lead access request process.
5.3. ITIL role: This role can only view the change but cannot modify the record or make any
changes.
5.4. Requestor
5.4.1. Initiates the change process to support a request to create, update, or
decommission an IT solution, or any of its components.
5.4.2. A change is generally initiated by a business user or IT staff responsible for the
IT solution.
Page 4 of 51

Revision: AD
Work instruction
6. Process flow
6.1. Workflow of a Normal change with GxP and SOX Impact
Printed copies for reference only Stryker Confidential – This document contains information that is confidential and proprietary. Neither this document nor the information herein
may be reproduced, used, or disclosed to or for the benefit of any third party without the prior written consent of Stryker.
Page 5 of 51


Revision: AD
Work instruction
6.2. Workflow of a Normal change with Non-GxP and Non-SOX Impact
Page 6 of 51


Revision: AD
Work instruction
6.3. Change Workflow Phases
New Phase Definition
New Default value upon creation.
Authorize Change approval by SOX and/or QA approvers, if applicable.
QA Approved CHG code promotion to the controlled environment takes place, CHG is
tested in a controlled environment, and evidence attached.
Submit to CCB Change approved by the Business Owner, IS Owner, and as required by IT
Quality for deployment to production.
Scheduled Change is CCB approved, awaiting implementation.
Implement Production Deployment is started and production evidence is gathered.
Review Review results of implemented change/evidence and update close notes.
Closed Change closed successfully.
Canceled Cancelled change.
6.4. Also see Appendix A, which contains a quick reference guide.
7. Work Instructions
7.1. Change Initiation
7.1.1. The IT Change Management process begins in SN as a task type. The SN task
types include: Request, Incident, Problem, Enhancement, and Project (PRJ). The
task may be created by IT or business customers.
7.1.2. The IT Change Lead creates a change request (CHG) to support the task and
identifies it by category: Break-fix, Maintenance, Project, Regulatory/Legal, or
Enhancement. This CHG should be created as soon as the Change Lead is made
aware of the respective task (i.e., INC, PRB, ENHC, REQ).
Page 7 of 51


Revision: AD
Work instruction
7.1.3. The following table describes the relationship between change category and SN
task type.
Change Categories and Associated Tasks Relationship

CATEGORY TASK TYPE
(CHG) Request Incident Problem Enhancement Project
Break-fix X X
Maintenance X
Project X
Regulatory/
X
Legal X
Enhancement X
7.2. New Phase: Planning and creation of a Change Record

The information in the New phase can be only entered by a Change Lead. This phase is
used to plan a change. Enter the respective data/information regarding the intended
change to an application/infrastructure component and select/name the appropriate
approvers.
7.2.1. Normal changes shall follow one of the following workflows based on
regulatory impact. The regulatory impact is pre-determined based on the CI
selected.
7.2.1.1. GXP / SOX impacted Workflow (Regulatory impact)
7.2.1.2. Non GxP/Non SOX impacted Workflow (Non Regulatory Impact)
7.2.1.3. For a Non GxP/Non SOX change there is no Regulatory approval

(Authorize) required. From New phase, the change enters QA
Approved phase (Refer to Section 7.5.).
7.2.2. In the New phase, a new CHG is created. Change Leads – SN and ITIL access in
SN is required to open a change record. No approvals are required in this
phase.
Page 8 of 51


Revision: AD
Work instruction
7.2.3. After any updates, it is important to Save the record, otherwise the information
will be lost and will require re-entry. Right click on the header and select Save
from the drop-down menu.
7.3. Steps to open a New change record

7.3.1. Login to ServiceNow and the Home Page appears.
Page 9 of 51


Revision: AD
Work instruction
7.3.2. Type “Change” in the Filter Navigation field to display the Change menu.
7.3.3. Select Change > Create New.
Page 10 of 51


Revision: AD
Work instruction
7.3.4. Select Normal change.
7.3.5. Complete required fields.
 Requested by: The business/IT user requesting the change

 Category: Type of change
o Break-fix: Associate to an Incident (INC) or Problem (PRB) record
o Project: Associate to a Project (PRJ) record
o Maintenance: Associate to a Request (SCTASK).
o Regulatory/Legal: Associated to a PRJ/Enhancement record
o Enhancement: Associate to an Enhancement record (ENHC).
o Note: See Section 7.4. to see how to associate the above records.
 CMDB Category: Select applicable CMDB Category from drop-down list
o Application
o Hardware
o Network
o Server
 CMDB Subcategory: Select relevant Subcategory from drop-down list
o Note: If CMDB Category and/or Subcategory is unknown, type CI name in
Configuration Item field or using lookup to select relevant CI. The
applicable CMDB Category and Subcategory will be auto-populated.
Page 11 of 51


Revision: AD
Work instruction
 Configuration item: The primary Configuration Item (CI) modified by the
change.
o Note: After the change is submitted/saved the first time, additional CIs
can be added using the Affected CI tab.
 Assignment group: IT group responsible for implementing the change. Click
on the field; use the Find icon to select a name from the list.
 Assigned to: The Assigned to person (Change Lead) moves the record
through the workflow. They are responsible to follow the change process,
and confirm the change is in the correct state during implementation. Click
on the field; use the Find icon to select a name from the list. Only a user
listed in the Assignment Group may be entered in this field.
 GxP/SOX Checkboxes: Checkboxes that denote GxP/SOX impact for the
selected CI. Manually check the checkboxes for GxP/SOX CIs if the CI is not
pre-checked as GxP/SOX. Work with the CMDB Support Team to update CIs
missing GxP/SOX impact designation.
 Priority (Manual Selection): Value rating the urgency of the change, based
on the sequence in which an incident or problem needs to be resolved.
 Risk of Change (Automatically Populated, applies to GxP/SOX CIs): Value
calculated based on the Risk Questionnaire selections made in the Risk
Assessment.
 Quality System Risk: (Automatically Populated, applies only to GxP CIs):
Value that populates only if the CHG/CI is been classified as GxP. It
calculates automatically based upon the Risk Questionnaire selections made
in the Risk Assessment.
 Impact (Manual Selection): Expected impact to the business.
 Short Description: A summary of the change.
 Description: A detailed description of the change.
7.3.6. Select Save to save the CHG record and stay on the same page. Right click on the
header and select Save from the drop-down menu.
7.3.7. Click the Submit button to submit the CHG. The Submit button returns user to
the Home Page. Re-open the CHG record to return to the CHG.
Page 12 of 51


Revision: AD
Work instruction
7.3.8. Complete the Planning, Scheduled, and Approval Information tabs.
7.3.8.1. Complete the Planning tab.
 Justification: Provide justification to support the benefits of implementing

this change. Explain the impact if the change is not implemented.
 Implementation Plan: Describe the plan to implement the change, the steps
required, any dependencies, and assignee details for each step in production.
 Risk and Impact Analysis: Provide a rationale based on the rating from the
Risk Assessment form. (See section 7.3.13. for instructions to complete the
Risk Assessment form.)
o IT Risk: Rate the impact to IT (Low/Medium/High) if the change does
not work as intended.
o Business Risk: Rate the impact to business (Low/Medium/High) if the
change does not work as intended.
o Impact to Quality System: Rate the to the Quality System
(Low/Medium/High). Does the change impact: product quality,
shipping data, product data, patient data, or any of the QMS elements?
o Likelihood of Occurrence: What is the likelihood that this same
incident/issue resulting in a change will occur?
o Probability of Detection: What is the probability of detecting a failure
with the change (Low/Medium/High)?
 Back-out Plan: List steps to revert change to its state prior to
implementation. Include information regarding the timing of a back-out
during implementation, and if the change window includes time for a back-
out.
 Test Plan: Describe the test plan and the expected results including desired
outputs, evidence, production verification plan, and downstream systems
that are impacted by the change and documentation impact (i.e., IT SOPs,
functional/technical documentation). Attach all evidence to a CTASK.
7.3.9. If the change is a Direct-to-Production change, note as Direct-to-Production in
the test plan field.
Page 13 of 51


Revision: AD
Work instruction
7.3.10. Complete the Schedule tab.
 Requested by Date: The go-live date requested by the business.
 Planned Start Date: Date the change implementation window starts.
 Planned End Date: Date the change implementation window ends.
 Actual Start Date: This field populates automatically when the CHG record
enters the Implement phase.
 Actual End Date: This field populates automatically when the CHG record
enters the Review phase.
7.3.11. When multiple CHGs are scheduled during the same deployment window, the
Conflict Status field alerts users if there is a potential scheduling conflict. If
there are potential conflicts, communicate with the respective Change Lead and
ensure the conflicts do not impact each other. The red font banner provides an
alert only; it has no workflow impact. The alert shows up when a change is
submitted for approval.
Page 14 of 51


Revision: AD
Work instruction
7.3.12. Complete the Approval Information tab. Based upon the CI selected, the
approvers default to those listed in the CMDB. (Adding additional CIs is
discussed in Section 7.4.6.)
 Owned by – Business Owner of the CI (automatically populated from CI)
 Managed by – IT Manager Owner of the CI (automatically populated from CI)
 QA Approval Group – If the CI has GxP impact and the CI is populated with
the QA Approval group, the QA approvers will be automatically populated. If
the CI has GxP impact and the QA approval group does not appear, the
Change Lead can always add Additional QA groups.
 SOX Approver Group - If the CI has SOX impact and the CI is populated with
the SOX Approval group, the SOX approvers will be automatically populated.
If the CI has SOX impact and the SOX approval group does not appear, the
Change Lead can always add Additional SOX groups.
 Additional QA Approval Groups – If multiple QA approval groups are
associated to a change, additional groups can be added here. Also, if the CI is
GxP and QA approval group is not populated, this field can be used to add
the appropriate QA group.
 Additional SOX Approval Groups – If multiple SOX approval groups are
associated to a change, additional groups can be added here. Also, if the CI is
SOX and SOX approval group is not populated, this field can be used to add
the appropriate SOX group.
 Additional CCB Approvers: If additional individual approvers from the
business/IT needs to be associated to a change, it can be added here. Also, if
the ‘Managed by’ and ‘Owned by’ fields are not populated in the CI, they can
be manually added in this field. While manually adding ensure that an IT
Manager (Managed by) and Business Requestor/Owner (Owned by) is
added.
7.3.13. Complete the Risk Assessment form. This is a two-step process to fill and
execute the Risk Assessment.
7.3.13.1. Click Fill Out Risk Assessment under Related Links.
Page 15 of 51


Revision: AD
Work instruction
7.3.13.2. Complete the Risk Assessment based upon the Regulatory impact.
Click Submit button.
Page 16 of 51


Revision: AD
Work instruction
7.3.14. Execute the risk.
7.3.14.1. Click Execute Risk Calculation link under Related Links to get the
assessment results.
Note: Once the Execute Risk Calculation step is completed, the Primary CI
cannot be changed. If there is a need to change the Primary CI after this
step, cancel the CHG and create a new CHG.
7.3.14.2. The following fields are auto-populated:

 Risk of Change
 Quality System Risk (This field populates only when the GxP
checkbox is marked.)
7.3.15. Create a new CTASK: If there is need to perform other tasks within a change
record, the CTASK tab can be used to assign tasks to other teams and
assignment groups. The description field in CTASK can be used explain what
needs to be performed in the task. CTASKS can be opened any time until the
implement phase.
7.3.16. CTASKs can also be used to attach the testing documentation for the respective
environment (e.g., DEV/QA/TST/PRD).
7.3.17. All CTASKs must be closed before the workflow can move from Implement
phase to Review phase.
Page 17 of 51


Revision: AD
Work instruction
7.3.18. Creating a CTASK:

7.3.18.1. Click on Change task tab and click New
7.3.18.2. Fill in the following details:

 Affected CI (optional) – The service that is impacted.
 Due date (optional) – Expected date the task needs to be
completed.
 Assignment Group (Required) – Name of the assignment group
that will be performing the task.
 Assigned to (Required) – Person who will perform or be
responsible for the task. This can be assigned by the assignment
group manager.
 Short Description (Required) – A summary of the task that needs
to be performed.
 Description (Required) – A detail description of what task needs
to be performed and how.
 Click Submit
7.3.18.3. Note: Once the task is completed change the state to Closed Complete,
or if incomplete, change the state to Close Incomplete with a rationale
in the Work notes. By default, when a CTASK is opened the state will
be in Open state.
Page 18 of 51


Revision: AD
Work instruction
7.3.19. Right click on the header. Select Save from the drop-down menu to save the
record. After any updates, it is important to Save the record, otherwise the
information will be lost.
7.4. Associating Records to a change record

7.4.1. Associating Problem (PRB) Records
7.4.1.1. Select the Problems tab to link PRB record associated with the
change.
7.4.1.2. Click on the Edit button.
7.4.1.3. Select the PRB record(s) from the list or search for it. Click Save
button.
Page 19 of 51


Revision: AD
Work instruction
7.4.2. Associating Incident (INC) Records
7.4.2.1. Select the Incident tab to link INC record associated with the change.
7.4.2.3. Select the INC record(s) from the list or search for it. Click Save
button.
7.4.3. Associating a Maintenance Record (SCTASKS)

7.4.3.1. For any maintenance kind of activity, associate an SCTASK.
7.4.3.2. Select the Catalog Task tab to link the SCTASK record associated with
the change.
Page 20 of 51


Revision: AD
Work instruction
7.4.3.4. Select the SCTASK record(s) from the list or search for it. Click Save
button.
7.4.3.5. Note: To find the SCTASK Number, please go to Request (REQ)

associated to maintenance activity and the SCTASK number is found
within the RITM record of the Request.
7.4.4. Associating a Project Record (PRJ)
7.4.4.1. Select the Project tab to link the PRJ record associated with the
change.
Page 21 of 51


Revision: AD
Work instruction
7.4.4.3. Select the PRJ record(s) from the list or search for it. Click Save
button.
7.4.5. Associating an Enhancement Record (ENHC)

7.4.5.1. Select the Enhancement tab to link the ENHC record associated with
the change.
Page 22 of 51


Revision: AD
Work instruction
7.4.5.3. Select the ENHC record(s) from the list or search for it. Click Save
button.
7.4.6. Affected CIs

7.4.6.1. Select Affected CIs tab. Use this tab to add CIs when the CHG is
associated with more than one CI, or there are secondary CIs.
7.4.6.2. Click Add button.
7.4.6.3. Search, select the respective CI(s), and click Add. CIs can be added
only in the ‘New’ phase.
Note: if the Primary CI is non-GxP, but the Secondary CI has GxP/SOX
impact, manually mark the change as SOX/GxP and complete the
appropriate Risk Assessment. If the secondary CI is GxP/SOX, the
Page 23 of 51


Revision: AD
Work instruction
change will enter the Authorize phase for Regulatory Approvers to
approve the change.
When a change record has multiple CIs, only the primary CI
information can be visible in the Approval Information tab. To view the
secondary CI information, the respective CI information icon must be
clicked.
When a change record has multiple CIs, all approvers listed in the
primary and the secondary CI will be sent out for approval
automatically in the respective phases.
7.4.7. Review that all the fields in the Planning, Schedule, Approval Information tabs,
and the Risk Assessment calculation are completed prior to submitting the CHG
for approval.
7.4.8. Change Assessment: The Change Lead shall present the change in their
respective Tower CABs to evaluate the change request:
 for risk, business need, and potential impacts/conflicts to other systems or
processes.
 to perform a change procedure action (e.g., initiate development or deploy
change into controlled environment).
Page 24 of 51


Revision: AD
Work instruction
7.4.9. Click the Request Approval button to submit the CHG for approval. The change
moves to Authorize phase
7.4.10. Open the Approval tab to view all requested approvers and the status of the
approval. This option is available at any phase in the workflow.
Page 25 of 51


Revision: AD
Work instruction
7.4.11. Note: The view of the approval tab can be personalized to view different
columns:
7.4.11.1. Click the Funnel icon to add/remove selection criteria
7.4.11.2. Click the Settings(gear) icon to move /add fields
7.5. Authorize – QA/SOX Regulatory Approval

In this phase, approvals are obtained based upon the CI’s/ Change’s regulatory impact. In
this phase, approvals are required to progress the record to the next phase. In the
Authorize phase the change record is reviewed by the Business Regulatory Approval
groups for:
 The overall change to be implemented
 Change Description
 Risk Assessment / Justification
 Impacted Quality Management System
 Impacted SOX controls
 Any documentation/procedure related to the CHG that needs to be updated
Page 26 of 51


Revision: AD
Work instruction
7.5.1. Changes with regulatory impact (GxP/SOX):

7.5.1.1. Approvals are sent automatically to pre-populated approval groups
from the CIs.
 SOX Approval Groups – if the change has SOX-only impact
 QA Approval Groups – if the change has GxP-only impact
7.5.1.2. Approvals are also sent automatically to any approval groups that
were added in the additional SOX and additional QA group fields.
 Additional QA Approvers – any additional QA approval groups
impacted by the change are seen in this field in the Approval
Information tab. The input to this field should have been
manually added in the New phase.
 Additional SOX Approvers – any additional SOX approval groups
impacted by the change are seen in this field in the Approval
Page 27 of 51


Revision: AD
Work instruction
Information tab. The input to this field should have been
manually added in the New phase.
7.5.2. If a change is Rejected in this phase it returns to the New phase.

7.5.3. The change automatically moves to QA Approved once all the approvals are
received in Authorize phase.
7.6. QA Approved – Testing
In this phase, initial approvals are complete; testing begins in a controlled environment
after code promotion to QA.
7.6.1. No approvals are required in this phase, but the below actions should be
performed by the Change Lead:
7.6.1.1. Complete required testing in a controlled (production equivalent)
environment.
7.6.1.2. Attach completed testing evidence to the CTASKs. (Please refer in
the above New phase section, how to create a CTASK). Note: Use
ISSOP_SDM_001.T07 for authoring test scripts, and if a testing tool is
being used for testing, reference the location of the testing suite in
the CHG record.
7.6.1.3. Click Submit to CCB button after attaching all testing evidence, which
confirms that the change is ready for production deployment. A pop-
up note appears as a reminder to attach documentation/evidence to
the CTASK.
Page 28 of 51


Revision: AD
Work instruction
7.6.2. Once OK is clicked, the change moves to Submit to CCB phase.

7.6.3. If the CHG is a Direct to PRD change, attach “before” screenshots or any pre-
requisites in this phase.
Page 29 of 51


Revision: AD
Work instruction
7.7. Submit to CCB – Request/Approval for Production Deployment
In this phase, all testing is complete in a controlled environment and approvals are
secured for change deployment in production. Approvals are required in this phase to
move to the next phase.
7.7.1. Required Approvals for a GxP/ SOX Change:

 IT Manager – found on the Manager field in the CI.
 Business Owner/Requestor – found on the Owned by field in the CI/added as
an additional CCB approver.
 ISQC QA – approvals from the ISQC/CCI team are requested automatically if
the CHG has GxP and/or SOX impact.
 Any approvers added in Additional CCB Approvers field. The input to this
field should have been manually entered in the New phase.
7.7.2. Required Approvals for a Non GxP/Non SOX Change:

 IT Manager – found on the Manager field in the CI
 Business Owner/Requestor – found on the Owned by field in the CI/added as
an additional CCB approver.
 Any approvers added in Additional CCB Approvers field. The input to this
field should have been manually added in the New phase.
Page 30 of 51


Revision: AD
Work instruction
7.7.3. All approvals in “Submit to CCB” phase need to be obtained in ordered to start
deployment activities in production.
7.7.4. No e-mail approvals accepted; all approvals shall be obtained on the Change
record.
7.7.5. If a change is Rejected in this phase it returns to the New phase.
7.7.6. Once the change is approved in the Submit to CCB phase, the change moves to
the Scheduled phase automatically.
7.8. Scheduled – Change Pending Deployment
In this phase all approvals are complete, the change is ready to be implemented based
upon the Planned Start Date. The change will remain in Scheduled phase until the
Implementation begins.
7.8.1. Per the Planned Start Date, click the Implement button to capture the Actual
Start Date in the scheduled tab.
7.8.2. The Actual Start Date populates in the Schedule tab automatically when the
change enters the Implement phase.
Page 31 of 51


Revision: AD
Work instruction
7.8.3. The Change Lead is responsible to manually push the CHG record from
Scheduled to Implement phase.
7.8.4. Once a CHG is in Scheduled phase, it cannot be moved back to a previous phase.
7.9. Implement – Change Deployed
In this phase, the change is implemented in production per the Planned Start Date. No
approvals are required.
7.9.1. Click the Implement button in the Scheduled phase to move the CHG to
Implement phase.
7.9.2. In the Implement phase, the system automatically opens two CTASKS:
 Implementation CTASK – Use this task to assign the group/individual
responsible for performing the deployment activities in the CHG. Close
when deployment/implementation window is complete.
 Post-implementation CTASK – Use this task to attach the results of the
implementation. Attach production evidence of the change/business
acceptance to this CTASK.
 Note: Close all related CTASKs in this phase to permit the CHG to advance
to the Review phase. The CHG will remain in Implement until all CTASKs are
closed.
Page 32 of 51


Revision: AD
Work instruction
7.9.3. Click the Review button to move the CHG to the Review phase.
 The Actual Planned End Date populates automatically in the Schedule tab.
 A pop-up appears as a reminder to attach production
documentation/evidence to the CTASK.
7.10. Review – Change Post-Deployment

In this phase, the change is in production environment and CHG close information
entered. No approvals required.
7.10.1. Note that a CHG moves into Review phase when:
 The CHG has implemented in production environment.
 Production evidence attached to CTASKs.
 All associated CTASKs are closed.
7.10.2. Open the Closure Information tab. Complete the following fields:
7.10.2.1. Close Code – Select Successful or Unsuccessful from the drop down
menu.
7.10.2.2. Closes Notes – Provide close code rationale based upon the selected
Close Code.
7.10.3. Note: If a change is Unsuccessful, provide a clear rationale as to why the change
was unsuccessful and also mention if the rollback was successful before closing
the change record. After the rollback is completed the same change record
Page 33 of 51


Revision: AD
Work instruction
cannot be used to implement the change. Use a new change record to
implement the change and reference the unsuccessful change number in the
Notes tab, or the closed notes if the change is still in the Review phase.
7.10.4. Click the Close button to move the CHG to Closed phase.
7.11. Closed – Change Completed

In this phase, all documentation and change activities are complete. When the Closure
Information in the Review phase is updated, the record automatically moves to Closed
state. No additional actions are required. Closed records cannot be re-opened.
7.12. Canceled – Change Canceled
A change can be cancelled until the Scheduled phase. To cancel a CHG in Implement phase
or after, close the change as Unsuccessful in the Review phase with a rationale in the
closed notes and move it to the Closed phase.
7.12.1. Right click on the header and select the Cancel Change option.
Page 34 of 51


Revision: AD
Work instruction
7.12.2. The change moves to Canceled phase.
7.13. Steps to Approve a Change Record

7.13.1. Change records can be approved via the email notification link or directly in
ServiceNow.
7.13.2. https://strykercorp.service-now.com/nav_to.do?uri=%2Fhome.do%3FType in “My
Approvals “in the Filter Navigator and select it.
Page 35 of 51


Revision: AD
Work instruction
7.13.3. A page appears that lists all the changes that requiring approval. To review the
details of the change, click a change number or state.
7.13.4. After reviewing the record for approval scroll down to the “Approvers” tab
where user’s name will be listed as one of the approvers.
Page 36 of 51


Revision: AD
Work instruction
7.13.5. Click on the state “Requested” link adjacent to user’s name.
7.13.6. The page is directed to the Approval record.

7.13.7. Note: The Approver can add attachments to the Approval record, if deemed
appropriate, to further document review. Click on the paperclip icon to browse
to the desired file.
7.13.7.1. Approvers can select one of the following options based on review of
the change record:
 Approved – Agree and approve the change for deployment.
 Rejected – Disagree and need additional detail.
 More Information Required – Keeps the change in the same phase

for the Change Lead to address comments mentioned.
Page 37 of 51


Revision: AD
Work instruction
7.13.7.2. Click on Update on top right corner of the page. In the Approver
Authentication window, enter network credentials/e-signature to
complete the approval.
7.14. What an Approver looks for in the change record in each phase
Approval Phases Approver Role What is reviewed
CAB Approval in CAB Approvers Reviewing the overall change to be implemented
New Phase (This Assessing the quality of change information and the risk and impact of the
approval is not in change
the system but via Confirming the change has been assigned to the right change category and
CAB meetings) is associated with the correct task type.
Confirming the change will have the appropriate test evidence when
submitted for CCB approval.
Reviewing the content of fields in ServiceNow including:
Change Description
Risk Assessment / Justification
Appropriate approvers (Business/ RAQA/ SOX approvers/ CCB
Approvers)
Any documentation/procedure related to the CHG that needs to be
updated
Planned dates of deployment
Verify conflicts per planned dated
Authorize Phase Regulatory The overall change to be implemented.

(QA/SOX) Change Description
Approvers Risk Assessment / Justification/Test Plan
Impacted Quality Management System
Impacted SOX controls
Any documentation/procedure related to the CHG that needs to be
updated.
Page 38 of 51


Revision: AD
Work instruction
Approval Phases Approver Role What is reviewed
Submit to CCB IT Manager The overall change to be implemented works as intended and is ready to
phase /ISQC/CCI be deployed.
All content of the change record
Test evidence
Submit to CCB Business The intent of the planned change, the business impact to system and
phase Requestor/ System implementation readiness
Business Owner Change Description
Risk Assessment / Justification
Test evidence
7.15. Delegate option:

Resources with ITIL Access in ServiceNow can delegate approval in the system. Resources
with no ITIL access can open a Request (REQ) ticket in ServiceNow to set up a delegate in
the system.
Note: When submitting the REQ ticket, ensure to mention the person who will be acting as
a delegate, and start/end dates for delegation period.
Use the following steps to set up the delegate option.
7.15.1. After logging into ServiceNow, first ensure default view is selected. Click on the
menu button ( ) and select Default view.
Page 39 of 51


Revision: AD
Work instruction
7.15.2. Then click on the user name that is in the upper right corner and click on
“Profile” (Figure 1) or use the Filter navigator, type in “My Profile”, and click
(Figure 2).
Fig 1
Fig 2
7.15.3. Scroll down and click on the ‘Delegates’ tab.

7.15.4. Note: If the Delegates tab is not seen, either the user does not have ITIL access
or the profile is not on the default view (see Section 7.15.1 to change the view).
Page 40 of 51


Revision: AD
Work instruction
7.15.5. In the Delegates tab, click ‘New’ and enter the following:
 Delegate: Name of the person that serves as a delegate while user is away,
and who can approve on user’s behalf.
 Start Date: Enter the date and time from when the delegate can start
approving on user’s behalf.
 End date: Enter the date and time from when the delegate should stop
approving on user’s behalf.
Note: By default, the Start and end date are auto populated, so ensure the right
dates are entered.
7.15.6. Assigned Delegator: The individual who will be approving as a delegator. For a
respective individual who has been given the delegated authority, locate
delegated approvals via the following:
Page 41 of 51


Revision: AD
Work instruction
7.15.6.1. Type in ‘My Approvals’ in the Filter Navigator and click on My
Approvals option that is displayed.
7.15.6.2. The queue of delegated approvals displays. Select the appropriate

change record and approve.
7.15.7. Approving a change record:
7.15.7.1. After clicking the respective change record, review the record and
then scroll down to the Approvers tab.
7.15.7.2. In the Approvers tab, look for the respective individual who has
granted delegator authority. Click on the state ‘Requested’ next to
Page 42 of 51


Revision: AD
Work instruction
his/her name to allow the delegate designee to proceed with the
approval.
7.15.7.3. User will be directed to the approval record. Delegate shall select an
approval response.
 Click on the desired selection (Approved/ Rejected/ More
Information Required)
7.15.7.4. In the comments section, user shall state on behalf of whom they are
approving the change record to indicate a delegated record.
7.15.7.5. Click on update on top right corner of the page and enter network
credentials to approve or reject the record.
Page 43 of 51


Revision: AD
Work instruction
8. Appendices
8.1. Appendix A, Overview of the Respective Fields in Change Control
Page 44 of 51


Revision: AD
Work instruction
Appendix A
Overview of the Respective Fields in Change Control
Type of change Fields and Details
Normal/Emergency/ New Phase:

Standard
All content populated in the change record will be found in different tabs:
Planning
Schedule
Approval Information
Closure
Approvers
Affected CI
Incident
Problem
Notes, etc.
Normal/Emergency/ Category:
Standard
The category field ties into the CAB categories, the change lead needs to pick one of the categories from the drop down. (Break Fix, Project,
Maintenance, Regulatory/Legal, Enhancement) based on the change and associate the appropriate record.
Normal/Emergency/ Affected CI:

Standard
On the change page add only the Primary CI and if any more CI are associated to the change record, it needs to be added in the Affected CI tab,
which will be found at the bottom of the Change record.
When a Primary CI is added, the change record will be automatically populated with approvers (Managed by- IT Manager, Owned by - Business
Owner, QA approval group, and SOX approval group). The approval information can be seen in the Approval information tab.
Note: In order for the approvers to automatically populate the approval information, make sure the CI is populated with necessary approver
information. If no approvers are found on the CI, there is an ability to manually add approvers in the approval information tab using Additional
CCB approver’s field and Additional QA/ SOX approval fields.
Normal/Emergency/ Priority
Standard
Page 45 of 51


Revision: AD
Work instruction
This is drop down field where user chooses the urgency of the change.
Normal/Emergency/ Impact
Standard
This field is a drop down to measure the business criticality of the affected service.
Normal/Emergency Risk Assessment:
The risk assessment is a form and completing the risk assessment is a two-step process:
Under Related links click on “Fill out Risk Assessment” which would open a separate window with the Risk Questionnaire. Answer the
question and click on submit. Once the submit button is clicked the Risk Assessment is saved but risk calculation is not yet complete.
In order to complete the Risk calculation under Related links click on “Execute Risk Assessment”. Once clicked the Risk of change and
Quality system risk (if GxP) is automatically populated.
Note: The saved Risk Assessment can be seen in the Risk Assessment tab.
Normal/Emergency Risk of change:

This field is auto-populated based on the risk justification
Normal/Emergency Quality System Risk
This field is auto-populated based on the risk justification if there is GxP impact.
Normal/Emergency/ Planning tab -Justification
Standard
Provide a rationale as why this change needs to be implemented and impact if not implemented. This should tie in with selection made on the
impact drop down.
Normal/Emergency/ Planning tab- Implementation Plan:
Standard
This is where the technical details of the change can be entered, such as sequential steps for the change to be implemented, etc.
Normal/Emergency/ Planning tab- Risk and Impact Analysis:
Standard
The Change Lead needs to provide rationale for selection in the risk assessment form.
Normal/Emergency/ Planning tab- Backout Plan:
Standard
The Change Lead needs to include a rationale for what should occur if the change fails implementation (i.e., what is the plan to bring the system
to its prior state).
Normal/Emergency/ Planning tab- Test Plan:
Standard
Page 46 of 51


Revision: AD
Work instruction
In this section mention the how the change will be tested, what are the expected results, and what evidence will be provided to assure the
change works as intended.
Also include a statement if there is any documentation impact to IT SOP/Functional and technical documentation.
Normal/Emergency/ Schedule tab:
Standard
The schedule tab is used for better planning:
Requested by date: When does the business need the change by.
Planned start date: Date when implementation window starts.
Planned end date: Date when implementation window ends.
Actual start: Automatically populates when the change enters the implementation phase.
Actual end: Automatically populates when the change enters the review phase.
Normal/Emergency/ Conflicts tab:
Standard
This is more for informational purposes and shows the any conflicts with the current CI having the same implementation window. This does not
have any impact on the workflow.
Normal/Emergency/ Notes tab: Watch list
Standard
Anyone who needs to be informed regarding the change and needs to follow the progress on change record can be added here.
Normal/Emergency/ Notes tab: Work Notes list
Standard
Anyone who needs to be informed regarding comments can be added here. Every time an update is made, the person added will be informed.
Normal/Emergency/ Approval Information tab:
Standard
All the approvers involved in the change will be found in this tab.
There is also a separate approver tab in the change record, which shows the record of approval only.
The approvers can only be added in the new phase.
Normal Authorize Phase - The change record enters this phase only if the GxP and SOX checkbox are checked.
The QA Approval and SOX Approval if applicable will be received in the authorize phase.
Normal QA approved phase:
In this phase add the testing evidence from a lower environment to a CTASK and submit to CCB phase.
Normal/ Standard Submit to CCB
Page 47 of 51


Revision: AD
Work instruction
CCB approval is the approval for a change to deployed into PRD, all approvals must be received and change should be in scheduled phase before
any production deployment activity starts.
Normal/Emergency/ Scheduled phase
Standard
The planned start/ end date are fields that are entered in the new phase (schedule tab). The actual start date is automatically populated when
the Change Lead submits the change to implement phase.
An additional responsibility for the Change Lead to ensure proper planning, the Change Lead must click the Implement button in schedule phase
when the actual implement window starts for the change. By clicking the implement button, the Actual start date is automatically populated in
the schedule tab which helps in comparing the planned versus the actual dates. When the Implement button is clicked the change moves to
implement phase.
Once the Change Lead enters the scheduled phase it cannot go back to a previous phase in the change workflow.
Normal/Emergency/ Implement phase

Standard
The Change Lead deploys the change in PRD
Attaches PRD evidence if change is successful
If change is unsuccessful, the Change Lead moves to review phase to document it.
When the Change Lead finishes the above implementation activities, the change record is submitted to review phase. By clicking the review
button, the actual end date is automatically populated in the schedule tab which helps in comparing the planned versus the actual dates. When
the review button is clicked the change moves to review phase.
Once the change enters the change cannot be cancelled and has to be closed out.
Normal/Emergency/ Review Phase
Standard
The closure information tab needs to be populated with information in regards to the change deployment being successful/unsuccessful.
Closure Information tab: This is entered in the review phase for Normal changes. Once the change enters the review phase after
implementation, this is where we mention if the change was successfully or unsuccessfully implemented.
Close code: This is a drop down with two options a. Successful and b. Unsuccessful.
Close Notes: Rationale of close code selection.
Normal/Emergency/ Closed Phase

Standard
The change enters this phase when all change activities are completed.
Emergency New Phase
Page 48 of 51


Revision: AD
Work instruction
When adding the primary CI, the change record will be automatically populated with approvers (IT Manager, Business Owner, QA approval
group, SOX approval group). The approval information can be seen in the Approval information tab. For an emergency change, only the IS
Manager (Managed by) is requested for approval.
Note: In order for the approvers to automatically populate the approval information, make sure the CI is populated with necessary approver
information. If no approvers are found on the CI, there is an ability to manually add approvers in the approval information tab using Additional
CCB approver’s field.
Emergency Authorize phase

Authorize phase in Emergency change is the approval for a change to be deployed into PRD, which at minimum should be approved by an IS
Manager. All approvals must be received and change should be in scheduled phase before any production deployment activity starts.
Emergency Review phase

The review phase in the emergency workflow is an approval phase. When a change record is submitted from implement to review phase, the
ISQC/CCI group is requested for approval
The Change Lead will not be able to close the change. The ISQC/CCI team will review and close the change record.
If change record is rejected by ISQC/CCI the change moves to the implement phase.
If change record is approved by ISQC/CCI, the record moves to the close phase.
Standard Standard change Template Approval:
The Change Lead will have the ability to create a template with the system and seek for approval in the system.
Once the template is approved, the Change Lead can execute the template as a separate standard change with change information auto
populated every time the change is deployed.
Standard Risk Assessment
Risk Assessment form will not appear in the standard change. The Change Lead needs to manually input the risk classifications in the Risk and
Impact Analysis section of the Standard template.
Normal/Emergency/ Approval:
Standard
When a change record is submitted for approval, if the approver approves the change it moves to the next phase. For the change to move to the
next phase all approvers, or one person in an approval group, must approve.
Normal/Emergency/ Rejection:
Standard
When a change record is submitted for approval, if the approver rejects the change it moves to the new phase and not to a previous phase.
Page 49 of 51


Revision: AD
Work instruction
Normal/Emergency/ More Information required:

Standard
An approver can choose “More Information Required” as an option where the change remains in the same phase and Change Lead is sent a
notification in regards to what information is needed.
Once the required information is provided the approver can then approve the change to next phase.
Normal/Emergency/ Restart Workflow:

Standard
There is no Restart workflow option. The only option is to have one of the change approvers reject the Change record or cancel and open a new
change if the approval phases have been crossed.
Normal/Emergency Primary CI and Risk Assessment:
Once the risk assessment is completed (Risk Calculation is executed) on the Primary CI, the Primary CI cannot be changed. If that situation
occurs, either cancel the change or the new CI can be added as a secondary CI in the affected CI tab if the Primary CI still applicable to the CHG.
Page 50 of 51


Revision: AD
Work instruction
9. Revision History
Revision Effective Reason
Description
number Date (CR/CN)
 Removed references of the Assess phase through

the document.
 Updated Process flow for Normal change with
GxP and SOX impact.
AB 12-Nov-2019  Updated section 7.4. to reflect Change ECR-13376/ECN-05412
Assessment and tower CAB process
 Removed assess phase and added CAB approval
to table in section 7.14.
 Removed Assess phase from Appendix A.
 Updated section 5.3 to add the refrence to

KB11876.
 Updated section 7.3.5 to add CMDB Category,
AC 18-Sep-2020 CMDB subcategory fields and screenshot with ECR-21264/ECN-11575
new fields
 Updated 7.3.7 to add new screenshot with CMDB
Category and CMDB Subcategory fields
 Changed Revision from AC to AD
 Section 7.2.2 change Stryker ITIL to Change
Leads - SN
AD See onePLM  Section 4.1.4, 7.3.8.1, 7.3.12, 7.7.1, 7.7.2, 7.14 ECR-44606/ECN-28038
change IS to IT
 Appendix A changed IS to IT
 Add CCI next to ISQC
Page 51 of 51

Signatures for document: Change Management - Normal Change

Creation
Document Number: D0000004084
Date: 2021-11-29 13:29:51.0
Revision: AD
ECR Number: ECR-44606
ECN Number: ECN-28038
This document has been signed using an electronic signature within Windchill. To access the original source
document and relevant information, please access the system directly.
Approval Information
Group Approval Role Name Date Vote
Quality Leadership Loomis Colleen 2021-11-29 19:48:12.0 Approve

Information Services -
Subject Matter Expert Bush, Mindy 2021-11-30 20:14:49.0 Approve
Subject Matter Expert
Process Owner Howley, Martin 2021-11-30 12:45:50.0 Approve

Change Documentation

Uploaded by

Document Information

Original Title

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

Change Documentation

Uploaded by

Copyright:

Available Formats

Document Number: D0000004084 Windchill Revision: AD State: Released

Document number: D0000004084

Document number: D0000004084

Document number: D0000004084

5. Roles and responsibilities

Document number: D0000004084

Document number: D0000004084

Date Released: Jan 11, 2022 18:11:56 GMT Page 5 of 52

Document number: D0000004084

6.2. Workflow of a Normal change with Non-GxP and Non-SOX Impact

Date Released: Jan 11, 2022 18:11:56 GMT Page 6 of 52

Document number: D0000004084

New Default value upon creation.

Authorize Change approval by SOX and/or QA approvers, if applicable.

Implement Production Deployment is started and production evidence is gathered.

Review Review results of implemented change/evidence and update close notes.

Closed Change closed successfully.

Canceled Cancelled change.

6.4. Also see Appendix A, which contains a quick reference guide.

Date Released: Jan 11, 2022 18:11:56 GMT Page 7 of 52

Document number: D0000004084

Change Categories and Associated Tasks Relationship

7.2. New Phase: Planning and creation of a Change Record

7.2.1.2. Non GxP/Non SOX impacted Workflow (Non Regulatory Impact)

7.2.1.3. For a Non GxP/Non SOX change there is no Regulatory approval

Date Released: Jan 11, 2022 18:11:56 GMT Page 8 of 52

Document number: D0000004084

7.3. Steps to open a New change record

Date Released: Jan 11, 2022 18:11:56 GMT Page 9 of 52

Document number: D0000004084

7.3.3. Select Change > Create New.

Date Released: Jan 11, 2022 18:11:56 GMT Page 10 of 52

Document number: D0000004084

7.3.5. Complete required fields.

 Requested by: The business/IT user requesting the change

Date Released: Jan 11, 2022 18:11:56 GMT Page 11 of 52

Document number: D0000004084

Date Released: Jan 11, 2022 18:11:56 GMT Page 12 of 52

Document number: D0000004084

 Justification: Provide justification to support the benefits of implementing

Date Released: Jan 11, 2022 18:11:56 GMT Page 13 of 52

Document number: D0000004084

Date Released: Jan 11, 2022 18:11:56 GMT Page 14 of 52

Document number: D0000004084

Date Released: Jan 11, 2022 18:11:56 GMT Page 15 of 52

Document number: D0000004084

Date Released: Jan 11, 2022 18:11:56 GMT Page 16 of 52

Document number: D0000004084

7.3.14.2. The following fields are auto-populated:

Date Released: Jan 11, 2022 18:11:56 GMT Page 17 of 52

Document number: D0000004084

7.3.18. Creating a CTASK:

7.3.18.2. Fill in the following details:

Date Released: Jan 11, 2022 18:11:56 GMT Page 18 of 52

Document number: D0000004084

7.4. Associating Records to a change record

Date Released: Jan 11, 2022 18:11:56 GMT Page 19 of 52

Document number: D0000004084

7.4.3. Associating a Maintenance Record (SCTASKS)

Date Released: Jan 11, 2022 18:11:56 GMT Page 20 of 52

Document number: D0000004084

7.4.3.5. Note: To find the SCTASK Number, please go to Request (REQ)

Date Released: Jan 11, 2022 18:11:56 GMT Page 21 of 52