© 2014 IBM Corporation

IBM Control Desk Configuration Management Workshop – Self-Facilitated

Designed for Interconnectivity to Change & Release

o

© 2014 IBM Corporation

Your company has recently purchased IBM Control Desk and wish to enable functions in the area of configuration management, with interlocking processes for change & release management.

Planning an implementation of a configuration, change and release solution is more than just an install of the software.

Process Workshops are conducted to design and define the processes, configuration and use of the new tool set. Workshops are simply one of the steps in the overall methodology of software implementations.

Allowing your stakeholders and users to come together to define business processes helps ensure adoption of the software.

– Ensure that you include all the stakeholders in the planned workshop.– Use the workshop to design how the tool will support the process, or improve the process.

To ensure faster agreement of new process changes for configuration management.

Establish your project focus and momentum.

Confirm ownership and mission.

2

oWhy Use this Deck?

© 2014 IBM Corporation

This deck is constructed to facilitate a workshop and to be used in a group setting. – The slides should facilitate discussion and ensure design and configuration decisions.– The collaborative workshop should take hours or days to ensure complete design.

The workshop should be more than just talking about current processes, it is improving and determining configurations for IBM Control Desk (ICD) capabilities.

– Do not recreate current tool capabilities into IBM Control Desk, this will produce failure before you start.

– Always assess and ask “why?” when appraising current processes. Be cognizant of what works and what doesn’t. Build on what works in your current processes, do not be afraid to reconstruct what does not work!

Draw diagrams, write on whiteboards or present diagrams/documents to help illustrate points or relay information among the attendees.

Always ask “WHY?” If the “why?” doesn’t come quickly, skip over and return to ask Why.

The slides are not designed to ask every question for each process, they are meant to focus the group on what configuration and processes are necessary for the implementation.

This deck was designed to be used in conjunction with the change management & release management workshops. Configuration, change and release management processes are tightly intertwined, and we recommend considering all when working the configuration workshop.

3

ooHow to Use This PowerPoint Deck

© 2014 IBM Corporation

Activities to complete before conducting workshop:– Have leaders/organizers or all of the attendees read the following list of pre reads (details in

note section below)– Ensure the project team has completed the base data design or ensure the focus of this

workshop to define the necessary base data during this workshop.• If the base data design is complete it should be understood by attendees (details on Base

Data in Project Configure link in notes section below)

Collect any current documentation or diagrams on current processes to reference during workshop.

Consider using the Process Content Packs, if you determine their use, understand the impact on the workshop decisions and design.

Process Content Packs - Informational

Before beginning this workshop, you should consider whether you would like to roll out configuration management in conjunction with change and release management. If so, there is a change management workshop & a release management workshop to use in collaboration. Alternatively, these workshops can be used separately, depending on your roll out and process decisions.

Ensure Design Document is updated as part of the workshop! See embedded doc.– Identify a documenter for the workshop and provide them this Design Document

4

ooTo Be Completed Before the Workshop

Microsoft Word Document

© 2014 IBM Corporation5

The Next Slides Should Be Used in the Actual Workshop !

o

© 2014 IBM Corporation

oDefine Project Objectives, Goal, and/or Mission

Describe and document the project mission, goals – Where do you want to be?

– Understand your strategy for Configuration, change and or release management processes and how it fits into the wider operational & business context.

• Does it align to the overall business goals? – This is a critical step for all attendees, to ensure all in the organization are in agreement of the

goal and objectives of the project.– Ensure this mission is agreed to at the executive level.– These goals drive the overall project, approach, and timeline.

Measure for success - How do you know you made it?

– This does not need to be endless set of metrics but you need to be able to measure the success, or milestones of the project work.

– Examples:• Percentage reduction in unplanned changes, on configuration items.• Configuration Item audits result in 90 % accuracy that they Configuration Items are as

they are in the infrastructure. • All Configuration Items have owners and they are alerted for pending changes to the CI.

6

© 2014 IBM Corporation

oHigh Level Discussion Topics

Are there shortcomings of processes or capabilities that should be discussed & what priority should they be addressed in this project?

• It may not be possible to tackle them all so priority is key• Do not try and rebuild old tool in new tool, you will carry the shortcomings with you.

What data if any will need to be migrated from existing tools (discovered data, categorizations, organization, relationships, configuration items, work groups, black out periods, change windows)?

Are there any regulatory, audit compliance or best practice (ISO19770, ISO2000, ITIL, COBIT, SOXS) requirements that must be met?

• If yes, who is the stakeholders or interested parties, that can ensure compliance?

Does the project have in scope items or exclusions? • Ensure they are documented and adhered to throughout workshop session.

What metrics, SLA, KPIs & reports are produced now, and what is required additionally going forward? How does the process perform against targets today?

• Do not recreate reports just to create them, validate they are needed as many reports exist in legacy systems that are unused or of no value with next or current processes.

How many expected users? How many self service users? Will there be 3rd party/external users?

7

© 2014 IBM Corporation

oHigh-level Process Flow

Identify Configuration Items

Solution Assembly

Change

Solution Development& Integration

Change Management

Configuration Information

Control Configuration

Items

Any Process CI Data Update

Package

CIs

Solution Development & Integration, Solution Test

Requesting Process

Asset Management

Configuration Information Request

Report Configuration

Status

Configuration Information

Configuration Audit RequestVerify & Audit Configuration

Items

Configuration Audit ReportCompliance

Management, Asset Management

Configuration Audit Action Request

Configuration Audit Action Request

© 2014 IBM Corporation

oDesigning Through Use Cases

Slides 10 – 17 are use case slides, created to help you through the design workshop if you do not have use cases documented or they are similar to these.

If your business already has use cases defined, use them as the basis for the workshop discussions independently or in conjunction with the ones provided.

– There are common use cases on the next few slides, and same as used in Project Start– The next slides provide use cases for configuration management processes. The

questions in the gray box at the bottom of the slides should be discussed, in order to extrapolate as much design, process discussions and aid you to establish the configurations for the Control Desk UI.

If the business only has a list of requirements and not use cases, it is suggested to utilize said list in conjunction with the use cases provided in the following slides.

– It is not recommended to base the design solely on a requirements list. This will cause the tool/process not to flow based on user tasks and cause user dissatisfaction.

Discuss the use cases in the following slides collaboratively, as the slides help with general use questions.

– The general questions apply to all of the use cases to help facilitate a good business discussion and define the design for configuration.

9

© 2014 IBM Corporation

o

Discovery is one way Configuration items can be identified in your environment.

As a Configuration Manager it is common to Import data that was discovered using IBM® Tivoli® Application Dependency Discovery Manager (TADDM), or other discovery tools into the CMDB, which then allows you to find the items, identify their relationships, and list their attributes. Not all discovered data is a CI that you will

upload into a configuration Item to be managed.

10

Is there currently a discovery tool identifying the configuration items in your IT infrastructure?

Have you defined persons to each role or to perform configuration management tasks and activities in the area of Identifying configuration items?

Are there predefined processes for when to create a Configuration Item?

Are Configuration items more than physical boxes or what is the level of data depth you control using change processes?

Is the data for configuration management loaded into other tooling, or are you leveraging it in the discovery UI?

How today is the discovered data shared with the other ITIL processes such as; change, incident, problem, release?

Are the physical configuration items linked to any IT asset data?

Are there configuration items that cannot be “discovered and if so how are the items identified and entered?

Identify Configuration Items – Configuration Item Discovery

© 2014 IBM Corporation

o

Manually creating a configuration item may be necessary if you will not be leveraging a discovery system now or for a period of time.

As a configuration manager or auditor it is necessary to create configuration items that can not be discovered or for configuration items that will not be discovered for various reasons, say security on

production systems. These configuration items will need relevant data in order to be located and selected for other processes such as change or release management.

11

Have you defined persons to each role or to perform configuration management tasks and activities in the area of Identifying and creating configuration items?

Are there predefined processes for when to manually create a Configuration Item?

If manually creating configuration items, what guidelines and detail will be necessary for creating a configuration item?

Have you defined a procedure for how to align the new configuration items to a person or configuration item owner?

Are there plans to implement a discovery system, if so how might it influence the way you create configuration items?

How today is the configuration item data interconnected with the other ITIL processes such as; change, incident, problem, release?

Are the physical configuration items linked to any IT asset data, or asset source?

Are you using a data model to help ensure configuration item data structure?

Identify Configuration Items – Manual Creation of a Configuration Item

© 2014 IBM Corporation

o

Throughout the life of the Configuration Items it is common for the configuration manager or auditor to need to oversee the configuration item, through change management activities for updates or change of relationships. A request may come from the change team to ensure configuration before a change.

12

Are there currently change processes that drive the control of your configuration items?

If a configuration item is the target of a change, is there a repository for which the configuration item is stored?

Are there configuration persons, configuration item owners, that ensure or review changes to the configuration items.

Is there a discovery source for verifying a configuration item has been changed? Is this step done manually as part of the tasks of the overall change?

Are there baselines or known parameters for configuration items to ensure configuration item control?

Is there continuous or periodic configuration item verification to ensure the item has not had any unplanned changes performed?

Is the control of the configuration items interlocked to other processes? Asset management or release?

Control Configuration Items – Configuration Item Control

© 2014 IBM Corporation

o

A Configuration Manager or change resource may use a topology view which allows the user to see a graphical representation of the configuration item and its relationship with other CIs. This view will may also

provide any information about what CIs would be affect should there be a change, being requested on a particular CI.

13

Are you leveraging any tool to view the relationships of the configuration items to each other, visually?

Today do you record and maintain the relationships among configuration items and if so to what extent, does it support your change processes today?

Are the related Configuration items understood when a CI is selected on a change?

Are configuration items presented graphically for business services? Such as a business owner or change manager might see the service?

Are all configuration items assigned an owner?

Are change windows identified on all configuration items?

Are there blackout periods for certain configuration items?

Control Configuration Items – Leveraging the CI topology

© 2014 IBM Corporation

o

As a configuration item manager it will be necessary to change a configuration item's status to any state in its lifecycle to which a transition is defined from its current state. This is typically done through a change

request but can be done independently through a request for change or status transition.

14

Are all configuration items statuses controlled through change?

Can a configuration item status be updated by the configuration owner directly for any reason?

Today are there statuses that “ lock” the asset so changes or further updates cannot be done?

Are the configuration items easily identified by their status?

Is it necessary for resources to submit a request for CI status or is the data accessible via a UI for many to view the status directly in a read only manner?

For Configuration items that may be going out of operation through an upcoming change, is this noted or communicated in some way?

Does the status of a configuration item update from available to down when a change is being conducted?

Are change windows identified on all configuration items?

Report Configuration Item Status – Configuration Item status update

© 2014 IBM Corporation

o

A configuration Auditor may determine that a status of a configuration item is not correct based on review and verification of a CI state and discovery information. This would result in a change of status and a

verification of relationships and placing the Configuration item into active status.

15

Do you conduct audits of your configuration items to ensure no unplanned changes are being performed?

Are your configuration resources verifying status changes per your standard Configuration item status flow?

During incidents or problems are actions raised over incorrect statuses?

If an audit is performed and the status is incorrect, what action or procedure is followed?

During change reviews and verifications, are statuses of configuration items changed before the change is closed? (Secondary record raised?)

Are the status change procedures documented and communicated?

Report Configuration Item Status – Configuration Item status, manual (audit)

© 2014 IBM Corporation

o

A Configuration Manager or Auditor receives a configuration management request to audit a set of configuration items. The Manager or Auditor performs the audits to compare the "as built" and "as planned"

versions of configuration items, investigate discrepancies, and take action on the results.

16

Are there defined and documented processes for auditing a configuration item or set of configuration items?

Are baselines created as part of the audit process?

If a configuration item(s) are audited and found different than as the system of record states? Is there a defined procedure to follow for correction?

Are changes raised to put the configuration item(s) back into an as built state? Or is the system updated to as built with a changed noted as past tense?

Are actions taken to control undocumented changes?

Verify & Audit Configuration Items – Configuration Item Standard Audit

© 2014 IBM Corporation

o

A configuration Auditor will audit CI attributes and relationships on a regular basis to helps ensure and identify unauthorized changes or failures to carry out approved change requests.

17

What controls and processes have been enabled to ensure configuration control and no unauthorized changes?

Have configuration auditor tasks been allocated to people or an auditor role exist?

If an unapproved change was done, is it reviewed and discussed as part of change advisory board?

If an auditor does perform an audit and the configuration items prove to have been changed what actions is taken and by who?

Verify & Audit Configuration Items – Unauthorized Changes

© 2014 IBM Corporation

oWorkshop - Wrap Up

Ensure you have defined the data sets for the fields and data noted in the design document?

Have all use case flows been defined and no action items?

Have you interlocked or prepared how this design impacts change or release management?

Is there a need for other process workshops such as change and release processes?

Are there any necessary fields to be added to the user interface? Be sure the documentation has recorded these fields. • How to decide what is mandatory?

It is necessary to identify/discuss any required integrations for the implementation. • The required integration(s) should be noted in the design document • The overall design of the integration(s) should be a separate workshop, to allow the inclusion

of the technical resources

Verify with workshop attendees if there are any open items?

Set date for validation of the design as it may take the documenter a few hours/days to ensure completeness before distribution.

© 2014 IBM Corporation

oDesign Validation

19

Once the design is complete and documentation is complete, ensure full organizational buy-in/sign off on configurations. • Have a quick working session to share and explain the design and approach with any who may

not have attended the workshop but will sign off on design.

Once configuration of the software has begun, engage with the users (all roles) to review early, often and always.

Design/configuration validation should occur in varying systems such as development and User Acceptance, or what ever the systems are called, which are pre-production.

Pre-production system(s) should be configured based on the design document to the exact letter. • If configuration and tool capabilities conflict, the issue should be addressed straight away with

the full team if possible or if necessary.

© 2014 IBM Corporation

oNext Steps

20

Once validation is complete, configuration of the software should begin.

Training: Determine any training approach that may be needed for the overall project rollout.

Consider and define a rollout strategy, for go live.