Computer System
Configuration Management and
Change Control
What Your IT Department Is Really Doing
Justin J. Fisher, Pfizer
Agenda
1.
Background
2.
Audience Demographics
3.
Scope
4.
Introduction
5.
Overview
6.
Computer System Configuration Management
7.
Computer System Change Control
8.
The Valuable Interaction between Change Control and Configuration
Management
9.
Interactive Exercise
Background
•
Education
− B.A. Education, Flagler College, St. Augustine, FL
•
Experience
− Financial/Mortgage Industry
• IT Service Manager/ IT Change Manager
− Pharmaceutical Industry
• Internal and Independent Quality and Compliance Roles
− Computer Systems Validation and Infrastructure Qualification − Quality systems
• Change Control, Incident Mgmt, CAPA/Investigations and Commitments
• Document and Records Management, etc.
Getting To Know You
•
Audience Poll
− Are you in IT?
• Delegated Quality or Compliance unit?
• Current Role in Change and Configuration
Mgmt in your organization?
− Are you in Quality?
Scope
•
In Scope:
− Guidance for process expectations based on risk, scale, and
complexity
•
Out of Scope:
− Definitive application of processes at the technology level
• Risk of different architecture is varied, and we will not affix a
risk categorization or specific process expectation to
technologies (ie. Enterprise computer system used at multiple
sites versus a desktop solution)
− Theoretical definitions of “Validation” and “Qualification”
• Multiple resources available on understanding evolving industry
expectations
Introduction
•
Computer System Configuration Management
− “Appropriate configuration Mgmt processes should be established such
that a computerized system and all its constituent components can be
identified and defined at any point.”
1•
Computer System Change Control
− “Change management procedures should…be established. The point at
which change management is introduced should be defined. Appropriate
change processes should be applied to both project and operational
phases.”
11
ISPE. (2008). GAMP 5 A Risk-Based Approach to Compliant GxP Computerized
Systems.
Change Control Configuration
Overview
Project
Configuration
Management
Change
Control
Operations
Configuration
Management
Change
Control
C lear hand -of f from one phase to anotherComputer System Configuration
Management
“…a computerized system and all its constituent components can be
identified and defined at any point.”
1Computer System Configuration
Management
Configuration Identification
Configuration Control
Configuration Status Accounting
Identify
•
Configuration Identification (What to keep under control)
•
Configuration Item: “Component of the system which does not
change as a result of the normal operation of the system.”
1•
Deliverables that support the computer system
− User Requirements
− Functional Requirements
− Technical Architecture
− Configuration Specifications, etc.
•
Computer System components
− Application modules and code
− Infrastructure Hardware
Define
•
Use a risk-based approach to determine the scale
and complexity of a computer system configuration
management process
•
Finding the right granularity
− Scale, complexity, and risk
•
Elements are controlled through Change Control
•
Tell the story of the system through time
Key Elements of an Effective
Configuration Management Solution
•
Accessible
− Allows for more appropriate Impact Analysis and
decision making
•
Updateable
− Sufficient controls in place to prevent unauthorized
modifications
•
Accountability
− Change controls should adequately plan for
Computer System Change Control
URS 1.0
FS 1.1 FS 1.2 FS 1.3
“Change management procedures should…be established. The
point at which change management is introduced should be
defined. Appropriate change processes should be applied to both
Computer System Change Control
Describe the proposed change Document and Justify the change Evaluate Risks and Impact of the Change Accept or Reject the Request Develop and Verify the change Approve and Implement the Change Close the ChangeRisk Based Change Control
•
Increase rigor and formality as we move
up the chart
− Applying the same rigor and formality to a server change as we would new functional code to
support new business processes is not risk-based decision making
•
Impact continuum
− Impact cannot be viewed solely as “outage”, but the further down the pyramid, the greater
likelihood of a failure causing “outage” rather than “functional” failure
•
Consistent processes must be scalable for
risk
− The same SOPs and Change Control processes can be used for all categories, however the rigor and formality that is prescribed by the process should be scaled accordingly.
Category 5:
Custom
applications
Category 4:
Configured
products
Category 3:
Non-Configured
products
Category 1:
Infrastructure
Software
Increase formality and rigor of change controlFlexibility
•
Different types of technological components of a computer
system require nuanced management
− For many application changes, the change moves through a pre-production
workflow for appropriate development and verification prior to moving into
the production environment.
− For many changes to infrastructure, there is no concept of “moving a change
through prerequisite environments”, but if using one Change Control process,
it must allow for both types of movements of change.
•
Shared infrastructure
− Infrastructure that is not allocated for one computer system and has an
inherent design that does not relate back to a business process
• Data Centers and Computer Rooms • Shared Databases
• Physical and virtual Server Farms • Storage arrays
− A Change control process that is overly focused on application change control
will be impossible to implement for shared infrastructure concepts
Priority
•
Automate as much of the regulatory and
internal requirements into the process as
possible to keep the business running
•
Expectations to understand regulatory impact
and requirements is scaled based on the
category of technology supported
− A server technician doesn’t need to know the GMP regulatory requirements for the business processes supported by a
Customized application hosted on their server, but they need to know how GMP regulations apply to how they are expected to exhibit control over a component of a regulated computer system
•
Communicate process design to the business to
level-set expectations
Impact Analysis
•
Change control process should provides sufficient guidance for
evaluating the impact of a proposed change
− Reasonable estimate of the positive and/or negative impact to:
• Computer system configuration items
• Business processes
• Functions
• Availability
• Other scheduled activities (scheduled backups, disaster recovery activities,
other planned changes)
− Reasonable and Scalable
Category 5: Custom applications
Category 4: Configured products
Category 3: Non-Configured products
Category 1: Infrastructure Software
Less likelihood of functional
Proceduralizing Change Control
•
Much of what happens in IT is
repeatable in nature, therefore
duplicate changes may be
implemented repeatedly
− Not a part of the “normal use” of the
computer system or component
− Not used for novel or “one-off” changes
•
Build the elements of the
repeatable change into procedures
− Reduces documentation during change
control execution
− Built in planning in accordance with
known impact
Category 5:
Custom
applications
Category 4:
Configured
products
Category 3:
Non-Configured
products
Category 1:
Infrastructure
Software
Greater likelihood of repeatable changesThe Valuable Interaction between Change
Control and Configuration Management
Change
Control
Configuration
Benefits of Strong Process Design
•
Accurate, dependable, and
defendable decision making
•
Improved integration into other
Quality Systems processes
•
Audit and Inspection efficiencies
•
Reporting capabilities
•
Metrics and greater visibility for
process improvements
•
Improved communication with
business partners
Approval and Notification
Clearly defined
Configuration Items
Notification to
stakeholders
Approval from relevant
and required groups
Activity
Impact Analysis and
Mitigation
RESOLUTION
Discuss possible resolutions
IMPACT
Discuss possible negative impacts
ISSUE
Common Issues encountered in Computer System Configuration Management and Change Control Processes and Solution
Scenario 1
RESOLUTION
Increase accountability and verification Periodic auditing of system/solution
IMPACT
Decisions may be made based on inaccurate
information May lead to rework and project delays
ISSUE
Scenario 2
RESOLUTION
Clearly define the configuration expectations within your Configuration Management plan or SOPs
IMPACT
Inability to perform thorough impact analysis
of a proposed change or a reported event Critical changes to configuration may not be appropriately controlled
ISSUE
Scenario 3
RESOLUTION
Consider the risk of a configuration item to the overall system and the intended use of the system when determining the
granularity that is appropriate for the CI
Do not include configurations that change as a part of the normal use of the system
IMPACT
Unable to determine true impact of a
proposed change or a reported event Difficult to maintain
ISSUE
Scenario 4
RESOLUTION
Develop CM solutions to ensure that the system is user friendly, intuitive, and makes sense to an IT
professional.
Consider the use of Industry Standard tools and processes.
IMPACT
Easy to overlook/avoid CM expectations because it slows down the ability for IT to get the job done.
ISSUE
Scenario 5
RESOLUTION
Implement a common solution that meets process
requirements (TrackWise, HP OpenView ServiceCenter) Configure a solution in alignment with the process
IMPACT
Very little automation in alignment
with process requirements Greater variability in how the records are documented achieve sufficient documentationSME is required to be able to
ISSUE
Scenario 6
RESOLUTION
Create technical and procedural
linkages between the two systems Automate changes to CIs within the CC system configuration evaluationIncrease periodic
IMPACT
Inability to meet requirements Lack of understanding of how to use the processes triggered independently and Two separate processes are inconsistently
ISSUE
The Change Control process is not appropriately linked to configuration management processes
Scenario 7
RESOLUTION
Embed Change Control coordination into
process Ensure Impact Analysis includes review of scheduled activities
IMPACT
Greater potential for failure Significant potential for impact to other scheduled events
ISSUE
Scenario 8
RESOLUTION
Integrate perspective of all IT teams and technologies into process development
IMPACT
Open to significant interpretation by the other teams
May drive multiple processes; creating wrapper documents and sub-procedures to meet the requirements of the SOP by different technologies
