The Configuration Management Database (CMDB) is the foundation for all ITSM processes and acts as a data warehouse containing the CIs (configuration items) of a company. The
configuration management process is intended to manage the life cycle of each CI. The Change Management process is used to
document and approve changes to CIs.
The IT Asset Management (ITAM) process is focused on the lifecycle management of physical devices and Software from a financial and contractual perspective. The ITAM process is covering the
complete life cycle of an Asset from procurement to disposal.
Configuration Management is focusing on managing the business and IT services and it's logical and physical Infrastructure underneath from a technical perspective e.g.
- Application Services (e.g. SAP)
- IT Services (e.g. Database Administration, Windows Server Engineering)
- Application Service Environments (Production, Test, Development)
- Middleware (e.g. webapplication servers)
- Databases (e.g. oracle database)
- Servers (e.g. windows or unix servers)
- Network Devices (e.g. routers and switches)
By relating the CIs to each other a so called Service Tree is created. These Service Trees help the IT organization to manage, support and understand the IT Service Landscape and it's
infrastructure. Furthermore this information can be used for efficient impact analysis and outage management.
The goal of Change Management is to plan and control changes to IT Services and avoid any impact to users and business. The Change Management process is about to ensure that each change is
- documented and assessed
We distinguish normally between
A standard change is used for well documented re-occuring activities. A standard change is often pre-approved and is used only to document an activity against a IT Service or infrastructure CI
e.g. data import, database restore etc.
A normal change follows the defined normal change flow of a IT organization involving phases such as Logging & Assessment, Approval, Build & Test, Deploy, Post Implementation Review
An emergency change is normally raised from a Priority 1 Incident. The issue to be solved by this change must have a big impact and urgency for the users and the business. In most of the IT
organizations an emergency change is roughly processed as follows
- Describe & Impact Assessment
- Change Advisory Board Approval
- Documentation & Formal Testing
Knowledge Management is about to create and provide knowledge and information to the organisation. The ultimate goal is to document the knowledge and make it efficiently available to share it
with others and reduce the risk of losing knowledge by employees leaving the organization.
The knowledge base can be populated with information following different strategies. A knowledge base is only being actively used if the knowledge base contains useful and correct information. On
the other hand side people only document and publish knowledge if this is not creating too much effort for them.
Therefore it's key to have a smooth knowledge management process supported by the organization.
Subject Matter Experts (SME's) should be defined within the organization responsible to review, approve and publish new or updated knolwedge documents. Knowledge Administrators should
manage the knowledge base continuously to ensure data quality and accuracy based on reports e.g.
- Knowledge Documents not viewed since a longer period
- Knowledge Documents having low ratings
- Knowledge Documents related to out dated products or services
Furthermore it's important to ingegrate the knowledge managmeent process and it's content smartly with the Incident and Problem Management process. For instance it should be easy to search the
knowledge base based on incident ticket description and use fitting knowledge documents to document the resolution of the incident ticket. It should also be possible to publish Known Erros and
it's workarounds coming out of the Problem Management process into the Knowledge Base directly.
An incident is a generic term used for any unplanned issue which is either interrupting an IT Service or is reducing the quality of an IT service. Within Incident Management such issues/incidents
are documented, tracked and measured. The goal of an incident is to restore the IT service as quick as possible to its normal functionality with the least impact to business and users. This
happens very often by a temporary workaround (e.g. restarting a service). If an issue occurs occasionally the root cause is identified and solved via the Problem Management Process. Solving an
issue permanently requires often more time and leads mostly into a change managed via the Change Management Process. During the Problem Management Process the root cause can be documented as a so
called Known Error which documents the issue and it's workaround and helps the IT support organization to solve the issue as long as the root cause is not fixed.
Request Fulfillment is about managing and fulfilling the requests of employees or customers.
The so called service request catalog is used to document and offer defined services to customers and/or employees. The service catalog supports to structure the Service Catalog Items in a
meaningful way allowing the employee or customer to browse through and search against it.
Each service catalog item can be configured for
- user friendly description
- availability - who may request it?
- approval - who needs to approve before fulfillment?
- costs - charge back against cost centers
- item specific attributes (e.g. the size of a monitor, size of a database)
- fulfillment flow - the workflow to be processed to deliver the service
- service level agreement - agreed fulfillment duration time
The goal of the Employee Self Service Portal is to provide certain functions to customers and employees without the need to contact the Service Desk via phone. It's
about to lower the calls for the service desks and improve the service quality for customers and employees.
Employee Self Service Portals normally support to
- raise incident tickets
- raise service requests via the service request catalog
- track incidents and service requests raised by the user or affecting him
- approve service requests and changes
- search the knowledge base