Patterns of Business Activity (PBA)

• A Workload profile of one or more Business Activities
• Patterns of Business Activity are used to help the IT Service Provider understand and plan for different levels of Business Activity

User Profiles  (UP)

• A pattern of User demand for IT Services
• Each User Profile includes one or more Patterns of Business Activity

Differntial Charging simply means charging more for services at times when capacity is most scarce and charging less when capacity not an issue. 

Costs, which are clearly attributable to a single customer.

Costs incurred on behalf of all or a group, which have to be apportioned.

Any indirect costs, which cannot be apportioned fairly

Costs, which vary with some factor such as time or usage.

the division of cost types into subsets, for example hardware broken down into Servers, Desktops, Laptops etc.

costs applying to physical substantial assets of the company. To qualify these costs must be larger than a minumn sum and last for longer than on financial year.

costs resulting from day-to-day running of the IT services, related to repeating payments whose effects can only be measured for a short timeframe, usually less than 12 months

costs that do not vary even when resource usage varies

Hardware, Software, People, Accommodation, Transfer Cost, External

The costs of a product or service over its whole lifecycle

Average increase in profits (over a specific period) divided by the investment

Return on capital employed (= net profit before tax and interest / total assets less current liabilities)

Cost Units are usually things that can be easily counted, such as staff numbers,

software licences or things easily measured, such as filestore usage, CPU usage,

network packets sent

Cost Units are the basic items of resource for which Customers are held accountable

i.e. provide the method of apportioning Indirect Costs or calculating the actual cost of Variable Costs

the cost of each Cost Unit must be determined. Following the example of CPU-seconds,

if a business’s IT organisation knows the total cost of the necessary Capacity, the average

unit cost of a CPU-second can be calculated and apportioned to each Customer as it is

used, in the same manner that an electricity company calculates the consumption of each

of its Customers in KWh

A framework in which all known costs can be recorded and allocated to specific Customers,

activities, or other category. Most Cost Models are based on calculating the cost for each

Customer, but other models can be developed to show the cost for each service or the

cost for each location. The calculation of Costs-by-Customers is the usual start-point if a

Charging system is to be introduced.

The measure of the wearing out, consumption or other reduction in the useful economic

life of a fixed asset, whether from use, passage of time, or obsolescence through

technological or market changes.

Accounting

• The Process responsible for identifying actual costs of delivering IT Services,
• comparing these with budgeted costs, and managing variance from the Budget

IT Accounting aims to provide the information about what the money was spent on. All Configuration

Items necessary to deliver an IT Service to the Customer bear a certain cost. These costs together

add up to the total costs necessary for IT Service delivery. In order to understand costs we need to

discuss costs in a general way.

Budgeting

The Activity of predicting and controlling the spending of money

Consists of a periodic negotiation cycle to set future Budgets (usually annual) and the day-to-day monitoring and adjusting of current Budgets

Activities:

Determine the budget method:

• Incremental budgeting
• Zero-based budgeting

Determine the budget period (financial (fiscal) year)

Set up the budget

Charging - Requiring payment for IT Services

Charging policy considerations:

• Communication of information
• Pricing flexibility
• Notional charging

Pricing methods:

• Cost price
• Cost price plus
• Market prices
• Going rate
• Fixed price

This is a document that contains all the Services that are provided, a description of the service, service levels,

cost of the service, the customer and the person/department responsible for the maintenance of the service.  

The content of a Service Catalogue will vary depending on the requirements of the IT organization.  S

ervice Specification sheets often form part of the Service Catalog.

The Business Service Catalog contains details of all the IT services delivered to the customer,

together with relationships to the business units and the business process that rely on the

IT services.

This is the customer view of the Service Catalogue.

The Technical Service Catalog contains details of all the IT services delivered to the customer,

together with relationships to the supporting services, shared services, components, and

CIs necessary to support the provision of the service to the business. This should underpin

the Business Service Catalogue and not form part of the customer view.

Some organizations only maintain either a Business Service Catalogue or a Technical Service

Catalog. The preferred situation adopted by the more mature organizations maintains both aspects

within a single Service Catalogue, which is part of a totally integrated Service Management

activity and Service Portfolio.

Managing risks to ensure that at all times the business can conutine to operate to, at least, a pre-determined minimum level

An unplanned situation in which it is expected that the period during which one or more IT services will be unavailable will exceed threshold values agreed to with the customer.

BIA is the Activity in Business Continuity Management that identifies Vital Business Functions and their dependencies. These dependencies may include Suppliers, people, other Business Processes, IT Services, etc. BIA defines the recovery requirements for IT Services. These requirements include Recovery Time Objectives, Recovery Point Objectives, and minimum Service Level Targets for each IT Service.

Business impact analysis

• critical business processes

  • the potential damage or loss that may be caused to the organisation as a result of a disruption to critical business processes
  • the form that the damage or loss may take including lost income, additional costs, damaged reputation, loss of goodwill, loss of \competitive advantage  
  • how the degree of damage or loss is likely to escalate after an service disruption
  • the staffing, skills, facilities and services (including the IT Services) necessary to enable critical and essential business processes to continue operating at a minimum acceptable level  
  • the time within which minimum levels of staffing, facilities and services should be recovered
  • the time within which all required business processes and supporting staff, facilities and services should be fully recovered
  • Impacts are measured against the scenarios and typically fall into one or more of the following categories:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~  *  failure to achieve agreed internal service levels   *  financial loss   *  additional costs   *  immediate and long-term loss of market share   *  breach of law, regulations, or standards   *  risk to personal safety   *  political, corporate or personal embarrassment   *  breach of moral responsibility   *  loss of goodwill   *  loss of credibility   *  loss of image and reputation   *  loss of operational capability, for example in a command and control environment.

Risk Assessment

• Identify risks – i.e. risks to particular IT Service components (assets) that support the business process which cause an interruption to service

  • Assess threat and vulnerability levels – the threat is defined as ‘how likely it is that a service disruption will occur’ and the vulnerability is defined as ‘whether, and to what extent, the organisation will be affected by the threat materialising’. A threat is dependent on such factors as:  *  likely motivation, capability and resources for deliberate service disruptions such as       malicious damage to computer systems, commercial failure of a key technology provider,       attack against a organisation’s web servers and corruption of Internet sites for accidental       service disruptions, the organisation’s location, environment, and quality of internal systems       and procedures   *  business processes are vulnerable where there are single points of failure for the delivery      of IT Services (for example, a travel agent relies on information feeds for flight bookings,      if the link were to fail and no backup is available, flights cannot be sold).
  • Assess the levels of risk – the overall risk can then be measured. This may be done as a measurement if quantitative data has been collected, or qualitative using a subjective assessment of, for example, low, medium or high

Organization / Implementation Planning

• + - Organisational Planning

  • Executive – including senior management/executive board with overall authority and control

    Co-ordination – typically one level below the Executive group and responsible for co-ordinating

    Recovery – a series of business and service recovery teams representing the critical business functions and the services that need to be established to support these functions. Each team is responsible for executing the plans within their own areas and for liaison with staff, Customers and third parties

• + - Implementation planning
  • overall co-ordination plans that include
  • Emergency Response Plan
  • Damage Assessment Plan
  • Salvage Plan
  • Vital Records Plan
  • Crisis Management and Public Relations Plan.
  • --------key support functions PLANS---------
  • Accommodation and Services Plan
  • Computer Systems and Network Plan
  • Telecommunication Plan
  • Security Plan
  • Personnel Plan
  • Finance and Administration Plan.

Stand-by arrangements

• negotiating for third party recovery facilities and entering into a contractual arrangement

  purchasing and installing stand-by computer systems

  preparing and equipping the stand-by accommodation

  negotiating with external service providers on their ITSCM plans and undertaking due diligence if necessary

this should cover the organisation and in particular, the IT organisation, for Service

Continuity-specific items. This ensures that all staff are aware of the implications of

Business Continuity and of Service Continuity and consider these as part of their

normal working routine and budget.

regular review of all of the deliverables from the ITSCM process needs to be undertaken to ensure that they remain current. With respect to IT this is required whenever there is a major Change to the IT Infrastructure, assets or dependencies such as new systems or networks or a change in service providers, as well as when there is a change in business direction, business strategy or IT strategy. As organisations typically have rapid change, it is necessaryto invest in an ongoing review programme and incorporate ITSCM into the organisational business justification processes. New requirements will be implemented in accordance with the Change control process.

following the initial testing it is necessary to establish a programme of regular testing to ensure that the critical components of the strategy are tested at least annually or as directed by senior management or audit. It is important that any changes to the IT Infrastructure are included in the strategy, implemented in an appropriate fashion and tested to ensure that they function correctly within the overall provision of IT Services.

Modeling method include:

• Estimation (cheap, fast, inaccuarate)
• Trend Analysis (cheap, fast, more accurate)
• Analytical Modelling (more expensive,  slower, more accurate)
• Simulation Modelling (expensive, slow, accurate)
• Benchmarking the prototype (very slow, very accurate)

Application sizing has a finite life-span. It is initiated at the Project Initiation stage for a new

application or when there is a major Change of an existing application, and is completed

when the application is accepted into the operational environment.

The primary objective of application sizing is to estimate the resource requirements to

support a proposed application Change or new application, to ensure that it meets its

required service levels. To achieve this application sizing has to be an integral part of the

applications lifecycle.  

It is important that the utilisation of each resource and service is monitored on an on-going

basis to ensure the optimum use of the hardware and software resources, that all agreed

service levels can be achieved, and that business volumes are as expected

Part of the monitoring activity should be of thresholds and baselines or profiles of the normal

operating levels. If these are exceeded, alarms should be raised and exception reports produced.

These thresholds and baselines should have been determined from the analysis of previously

recorded data

The data collected from the monitoring should be analysed to identify trends from which

the normal utilisation and service level, or baseline, can be established. By regular monitoring

and comparison with this baseline, exception conditions in the utilisation of individual

components or service thresholds can be defined, and breaches or near misses in the SLAs

can be reported upon

The analysis of the monitored data may identify areas of the configuration that could be

tuned to better utilise the system resource or improve the performance of the particular

service

Timely resource requirement forecasts

Accurate forecasts of trends

Breached SLAs because of old technology

Performance and throughput measures of all services

Reduction in panic buying

Accurate forecasts of planned expenditures

Reduction in incidents

Act on recommendations

Incident Management keeps Capacity Management informed of Incidents related to Capacity and performance

Capacity Management supports the Incident Management process by resolving and documenting Capacity related Incidents

Capacity Management provides a specialist support role to identify, diagnose and resolve Capacity related Problems

Capacity Management is represented on the Change Advisory Board, to assess the impact of Changes on existing Capacity and to identify additional Capacity requirements

Capacity Management helps determine the distribution strategy, particularly where the network is used for distribution. Factors such as network bandwidth, host and target Capacity, distribution window and number of targets need to be considered as part of the distribution strategy

Conceptually the Capacity DB forms a subset of the Configuration Management Database ( CMDB ). The technical, service, utilisation, financial and business data all pertain to attributes of CIs (CIs) maintained in the CMDB. Without this information on individual CIs, Capacity Management cannot function effectively.

Capacity Management supports Service Level Management ( SLM ) to ensure that performance

and Capacity targets for new or changed requirements can be achieved

Performance is dependent on a given workload, therefore both are required in an SLA with

specific performance targets

there may be a requirement for Capacity Management to assist SLM in drafting and reviewing

Operational Level Agreements and external contracts where Capacity or performance issues are involved

Capacity Management is concerned with economic provision of services

Financial justification and efficiency gains are demonstrated with the assistance of Financial Management

A cost summary should be provided as part of the Capacity Plan

Procurement recommendations included in the Capacity Plan should be compared with budget forecasts and actuals before purchase

Capacity Management determines the Capacity required for all recovery options used. The minimum hardware and software configurations required are defined to provide the required performance and throughput levels following an invocation

Performance and Capacity Problems result in Unavailability i.e. unacceptably slow performance is effectively the same as Unavailability

Therefore Capacity and Availability Management share common goals and complement each other

A Third Party responsible for supplying goods or Services that are required to deliver IT Services

Examples of suppliers include commodity hardware and software vendors, network and telecom

providers, and outsourcing organizations

A legally binding Agreement between two or more parties

In order to achieve consistency and effectiveness in the implementation of the policy, a Supplier and

Contracts Database (SCD) should be established, with clearly defined roles and responsibilities.

Ideally the SCD should form an integrated element of a comprehensive CMS or SKMS, recording all

supplier and contract details, together with details of the type of service(s) or product(s) provided by

each supplier, and all other information and relationships with other associated CIs. The services

provided by suppliers will also form a key part of the Service Portfolio and the Service Catalogue.

The relationship between the supporting services and the IT and business services they support

are key to providing quality IT services.

This information within the SCD will provide a complete set of reference information for all Supplier

Management procedures and activities:

• Supplier categorization and maintenance of the Supplier and Contracts Database (SCD)
• Evaluation and setup of new suppliers and contracts
• Establishing new suppliers
• Supplier and Contract Management and performance
• Contract renewal and termination

The first two elements within the above list are covered within the Service Design stage.

The third element is part of Service Transition, and the last two are part of the Service Operation stage.

protecting sensitive info from unauthorised disclosure

safeguarding the accuracy and completeness of info

ensuring that information and vital IT services are availble when required

the confidentiality of data that can be linked to one person

the confidentiality of a user's identity

the possibility of veryfying that information is used properly and of demonstrating that the security measures is working properly

Ability of an IT service or component to perform its required function at a stated instant or over a stated period of time.

Freedom from operational failure.

Maintenance done on systems from an internal focus.

Maintenance done on systems from an external focus.

Redundancy, to allow IT's continued operation despite the incorrect functioning of one of more of its subsystems.

The element of a business process considered business critical.

The requirements that are the basis for building SLAs. In general, the more specifc the requirements,

the more successful the SLA will be.

Agreement between two internal IT areas / departments, e.g. Network Management and Service Desk.

Contract with an external supplier providing services to IT.

Defines services available to the customer from IT. See Service Portfolio management

Formal project undertaken within Service Level Management to improve processes or IT Services,

focusing on customer/staff satisfaction.

A listing of clients' service requirements that form the basis for SLAs.

Keep SLA simple -

Specific, Measurable, Agreed, Realistic, Timely

Key Performance Indicator (KPI): A Metric that is used to help manage a Process, IT Service, or Activity

Many Metrics may be measured, but only the most important of these are defined as KPIs

and used to actively manage and report on the Process, IT Service, or Activity

KPIs should be selected to ensure that Efficiency, Effectiveness, and Cost Effectiveness are all managed.

Key Performance Indicators (KPIs) and metrics can be used to judge the efficiency and effectiveness of the SLM

activities and the progress of the SIP. These metrics should be developed from the service, customer and

business perspective and should cover both subjective and objective measurements

Critical Success Factor (CSF): Something that must happen if a Process, Project, Plan, or IT Service is to succeed.

KPIs are used to measure the achievement of each CSF. For example a CSF of “protect IT Services when making Changes”

could be measured by KPIs such as “percentage reduction of unsuccessful Changes,” “percentage reduction in Changes causing Incidents,” etc.

A change of state that has significance for the management of a Configuration Item or IT Service

The term Event is also used to mean an Alert or notification created by any IT Service, Configuration Item, or Monitoring tool

Events typically require IT Operations personnel to take actions, and often lead to Incidents being logged

Once an Event Notification has been generated, it will be detected by an agent running on the same system,

or transmitted directly to a management tool specifically designed to read and interpret the meaning of the Event.

The purpose of filtering is to decide whether to communicate the Event to a management tool or to ignore it.

If ignored, the Event will usually be recorded in a log file on the device, but no further action will be taken.

ITIL suggests the following levels of significance:

Informational  -  No action required

Warning  -  Requires investigation

Exception  -  Requires action

Event Correlation is the decision making process on the significance of events.

Many event management tools incorporate Event Correlation Engines that apply

Business Rules to perform event correlation automatically.

Event Correlation Engines are typically state aware, that is, they maintain an awareness of

events over time in order to relate events and make decisions based on the flow over events,

for example:

• Suppressing repeated events
• Making Pairwise comparaisons (an up status event maps to a previous down status event)
• Flagging downstream events (handling floods of down status events on the other side of a router)

An unplanned interruption to an IT Service or reduction in the Quality of an IT Service

Failure of a Configuration Item that has not yet affected Service is also an Incident

For example Failure of one disk from a mirror set

Measure of the business criticality of an Incident. Often equal to the extend on the amount of damage or distortion of agreed and expected service levels.

Impact + Urgency = Priority

Impact is a measure of the business criticality of an incident or problem, and is often equal to the extent to which an

incident leads to degradation of agreed service levels. Impact can be measured by the number of people or

systems affected. Specific criteria for assigning impact should be included in the SLA, after consulting with

the business managers.

The determination of impact should be based on information from the CMDB to detect how many users will

suffer as a result of the technical failure of, for example, a hardware component.

The Service Desk should have access to tools that enable it to rapidly perform the following tasks:

• Assess the impact on users of significant equipment failures
• Identify users affected by equipment failure
• Establish contact to make them aware of the problem
• Give a prognosis and alert second-line (specialist) support groups

measure of the business criticality of an incident or problem based on the impact on and on the business needs of the customer.

Impact + Urgency = Priority 

Urgency is the necessary speed of solving an incident of a certain impact. All high-impact incidents do not, by default,

have to be solved immediately. For example, a user having operational difficulties with a workstation (“high” impact)

can have the fault registered with a “low” urgency if they are leaving the office for an extended holiday right after reporting the incident.

Sequence in which an incident or problem needs to be resolved, based on impact and urgency.

Impact + Urgency = Priority 

Priority is the defined Sequence in which an Incident or Problem needs to be resolved, based on impact and urgency.

Incident Models predefine the necessary steps for dealing with a particular incident and

ensure standard incidents are handled in a predefined path within predefined timescales

Incident Models within the Incident Management Process define:

• The steps that should be taken
• The order of the steps
• Responsibilities
• Timescales and thresholds
• Escalation procedures
• Evidence preservation activities

The Incident Model should include:

• The steps that should be taken to handle the incident
• The chronological order these steps should be taken in, with any dependences or co-processing defined
• Responsibilities; who should do what
• Timescales and thresholds for completion of the actions
•  Escalation procedures; who should be contacted and when
• Any necessary evidence-preservation activities (particularly relevant for security- and capacity-related incidents)

A separate procedure, with shorter timescales and greater urgency, must be used for ‘major’ incidents. A definition of what

constitutes a major incident must be agreed and ideally mapped on to the overall incident prioritization system – such that

they will be dealt with through the major incident process.

Agree on timescales for all incident-handling stages:

• Based on SLAs
• Captured as targets within OLAs and
• Underpinning Contracts

Make all support groups aware of these timescales

Use Service Management tools to:

• Automate timescales
• Escalate the incident as required based on predefined rules

Detection and Recording

Inputs

• Incident details
• Configuration details

Actions:

•  record basic details of the Incident
• alert specialist support group(s) as necessary
• start procedures for handling the service request (if it is one)

Outputs

• Incident Record (updated)
• Identifier number
• possible errors detected in CMDB..
• Raise a problem for significant Incidents
• Notice to customes of the Incident status progress

Initial Classificaton & Support

Classification:

One of the most important aspects of Incident Management andone of the most difficult to get right.

The classifcation is used to:

• specify the service with which the Incident is related
• associate with an SLA where appropriate
• select / define the best specialist group to handle the incident
• identify the priority based upon the business impact
• define what questions should be asked or information checked
• determine a primary reporting matrix for management information
• identify a relationship to match against Known Errors or solutions
• Version number (of application in use)
• Supplier
• Module (e.g. printing)
• Grouping (e.g. business application)

Inputs

• Incident record
• configuration details from the CMDB
• response from Incident matching against Problems and Known Errors

Outputs

• work-arounds for Incidents
• RFC for Incident resolution
• Possible resolution of the Incident
• updated Incident details
• escalate to next level if unable to diagnose
• Notice to customes of the Incident status progress

Assigning impact and urgency, and thereby defining priority

When determining impact, information in the CMDB should be accessed to detect how many users will suffer as a result of        

the technical failure of a component or service. The SD should have access to tools that enable it rapidly to:          

• assess the impact on users of significant equipment failures          
• identify users affected by equipment failure          
• establish contact to make them aware of the problem          
• give a prognosis (information from AVM "design for recoverability")          
•  alert second-line (specialist) support groups    
•  the urgency to the business (necessary speed of solving)
•  the resources available for coping in the meantime and for correcting the fault.

Investigation and diagnosis by a support group is required in cases where classification matching is

unsuccessful or the resolution process is complex. Even when an incident is handed over to another

group for resolution, the Service Desk should retain ownership and manage it until the user is satisfied.

Once the incident has been assigned to a specialist support group, they should:

• Accept assignment of the incident
• Specify the date and time (preferably automatically)
• Advise the Service Desk/user of any identified workaround
• Review the incident against known errors, problems, solutions, planned changes, or knowledge bases
• Assessment of the Incident details
• Collection and analysis of all related information, and resolution (including any workaround), or Route to n-line support

Inputs

• updated incident record
• configuration details from the CMDB

Actions:

•   Assessment of the Incident details
•   collection and analysis of all related information, and resoution    (including any work-around) or a route to the next support line.

Outputs

• incident details further updated
• Notice to customes of the Incident status progress

Reaching Resolution and Recovery

Resolution activities include:

• Resolve the Incident using the solution/workaround or, alternatively, to raise a Request for Change (RFC) – including a check for resolution
• Take recovery actions

After successful incident resolution (or some circumvention activity), service recovery can begin and recovery actions carried out.

This phase often involves specialist staff (i.e., second- or third-level support).

The Incident Management system records events and actions during the resolution and recovery activity.

Inputs

• updated Incident details
• any response from RFC to effect the solution for the Incident(s)
• any derived work-around or solution

Actions:

•   resolve the Incident using the solution /work-around or, alternatively,  to raise an RFC (including a check for resolution)

Outputs

• RFC for future incident resolution
• resolved status update on Incident  including recovery details
• updated incident detail

Obtaining Closure

After an incident is resolved, the Service Desk should ensure:

• Details of actions taken to resolve the incident are concise and readable
• Classification is complete and accurate according to root cause
• Resolution/action is agreed with the user – verbally or, preferably, by e-mail or in writing
• All details applicable to the incident control are recorded, such that the user is satisfied
• Cost center project codes are allocated
• Time spent on the incident is recorded
• The responsible person, date, and time of closure are recorded

The incident closure routine should have restricted access and should be controlled by the Service Desk Manager.

If a service provider and a user disagree about the validity of closure, the above details will be essential to resolving the dispute.

Inputs

• updated incident details
• resolved incident

Actions:

•   obtain confirmation of the resolution with the customer or originator
•   the time spent on the Incident is recorded      
•   the person, date and teime of closure are recorded

Outputs

• further updated and closed Incident
• closed Incident record
• request for customer satisfaction feedback

A request from a User for information or advice, or for a Standard Change or for Access to an IT Service

For example to reset a password, or to provide standard IT Services for a new User

Service Requests are usually handled by a Service Desk, and do not require an RFC to be submitted

Error - Incident - Problem - Known Error - RFC 

The cause is not usually known at the time a Problem Record is created, and the Problem

Management Process is responsible for further investigation

A problem is the “unknown underlying cause of one or more incidents”.  

This is the second stage of "root cause analysis"/problem management.  

From the general incidents, more investigation is required for Problems.  A “network problem” is a

good example of a problem definition in this case.  Users don't call saying I have a "network

problem", they call and say "I can't save to my H: drive" or "I can't print or surf the web".

IT staff then piece all these incidents together and identify that we are facing a "network problem".

Root cause analysis has taken us closer to finding the root cause but not completely. 

 A problem is then a more specific definition.

Error - Incident - Problem - Known Error - RFC 

A Known Error is the final step in the root cause analysis process.  

A Known Error can be defined as, “when the root cause of the problem is known”.  

In our network problem example it is where the faulty equipment or system has been identified.

This is the end of the root cause analysis process.  Following the above example the Known error would be “Router x is faulty”.

The Known Error database:

• Stores historical knowledge of incidents and problems and how they were overcome
• Allows quicker diagnosis and resolution if they recur

Each Known Error record minimally includes:

• Details of the fault and the symptoms that occurred
• Details of any workaround or resolution action
• Incident count

Method of avoiding an incident or problem, either from a temporary fix or from a technique that

means that the customer is not reliant on a particular aspect of a service that is known to have a problem.

The Main activities within Problem Control are:

Error Control is the process in which the Known Errors are researched and corrected.

The request for change comes from this sub-activity and is submitted to Change Management and then

following approval the change is actioned.

The Objective of Error Control is to change IT components to remove known errors thus to prevent and

recurrence of Incidents related to these errors. This requires:

• Awareness of errors
• Monitoring errors
• Eliminate when feasible and cost justified

Error Resolution Steps:

•  Recording of error resolution
•  Error closure

The best problems are the ones that never happen!

Proactive Problem Management focuses the analysis of data gathered from other processes and

the goal is to define “Problems”.  These problems are then passed off to Problem and Error Control

procedures, as if they had happened.

The activity includes:

• Trend analysis
• Using data to highlight potentially weak components.
• Targeting preventative action
• Trend analysis can lead to identifying general problem areas.

The aim of proactive Problem Management is to redirect efforts away from always being reactive, to proactively preventing incidents occurring in the first place

Major problem review

• what was done right
• what was done wrong
• what could be done better next time
• how to prevent the problem from happening again

An action that results in a new status for one or more IT infrastructure CIs.

Change types:

Standard (pre-authorized)

• Pre-authorized
• Low impact
• Routine

Normal

• Not pre-authorized

Emergency

• Reserved for a change needed immediately
• Should be kept to a minimum

The addition, modification or removal of authorized, planned or supported service or service component and its associated documentation

A formal proposal for a Change to be made

An RFC includes details of the proposed Change, and may be recorded on paper or electronically

The term RFC is often misused to mean a Change Record, or the Change itself

A schedule that contains details of all changes approved and their proposed implementation dates.

A Document that identifies the effect of planned Changes on agreed Service Levels, based on the Forward Schedule of Change (FSC).

A group of people that advises the Change Manager in the Assessment, prioritization, and scheduling of Changes

This board is usually made up of representatives from all areas within the IT Service Provider,

representatives from the Business, and Third Parties such as Suppliers

A subset of the Change Advisory Board that makes decisions about high-impact Emergency Changes

Membership of the ECAB may be decided at the time a meeting is called, and depends on the nature of the Emergency Change

A Document that identifies the effect of planned Changes, maintenance Activities, and Test Plans on agreed Service Levels

Endorses major changes before passing back to the CAB for scheduling and implementation.

• Who RAISED the change?
• What is the REASON?
• What is the RETURN?
• What are the RISKS?
• What RESOURCES are required?
• Who is RESPONSIBLE?
• What is the RELATIONSHIP between this change and the other changes?

Top FIve Risk Indicators are:

• Unauthorized Changed
• Unplanned Outages
• A Low change success rate
• A High Number of emergency changes
• delayed project implementations

A secure software compound where all authorized versions of software are kept.

A library, which stores in their definitive, accepted form, all the versions of software configuration items

that have been accepted from the developer or supplier. This logical library can be physically present in several locations.

An area set aside for the secure storage of hardware spares.

A physical secure storage of definitive hardware spares. These are spare components and assemblies that are

maintained at the same level as the comparative systems within the live environment.

A software CI introduced into the test environment and subsequently into the production

environment. In most cases documentation and accompanying hardware also are part of the release.

 Development. Only here can new software be developed. Newer versions will be based on a copy of the software in the DSL. Each new version will cause an increased version number.

 Testing. Should be a replication of the live environment in order to reduce risks of the implementation. Developers do not work in this area.

 Production. Where the software/hardware is in production. Developers do not work in this area.

 Archiving.  Old release versions that are no longer in use

general guidance is that if a CI can be regarded as slightly different from another related CI, and Problems affecting one are likely to affect the other, or Changes mad to the one will probably have to be made to the other, then a suse of a variant should be considered; otherwise, a different CI should be used

A set of tools and databases that are used to manage an IT Service Provider’s Configuration data

The CMS also includes information about incidents, problems, known errors, changes, and releases

It may also contain data about employees, suppliers, locations, business units, customers, and users

The CMS includes tools for collecting, storing, managing, updating, and presenting data about all Configuration Items and their Relationships

The CMS is maintained by Configuration Management and is used by all IT Service Management Processes

The CMS contains Configuration Baselines

A database used to store Configuration Records throughout their Lifecycle

The Configuration Management System maintains one or more CMDBs,

and each CMDB stores Attributes of CIs, and Relationships with other CIs

One or more locations in which the definitive and approved versions of all software Configuration Items are securely stored

• The DML may also contain associated CIs such as licenses and documentation
• The DML is a single logical storage area even if there are multiple locations
• All software in the DML is under the control of
• Change and Release Management and is recorded in the Configuration Management System
• Only software from the DML is acceptable for use in a Release

Any Component that needs to be managed in order to deliver an IT Service

Information about each CI is recorded in a Configuration Record within the Configuration

Management System and is maintained throughout its Lifecycle by Configuration Management

CIs are under the control of Configuration Management

CIs typically include IT Services, hardware, software, buildings, people, and formal documentation such as Process documentation and SLAs

Details that uniquely identify CIs such as location, version number, serial number, etc.

A value is the quantifiable part of an attribute. (examples of values are "red", "10", "E9", "critical")

The range of responsibility covered by Configuration Management.

A configuration / product / system established at a specific point in time, whichcaptures both the structure and the details of that product / configuration / system.It serves as a reference for further activites and provides the ability to change orrebuilt a specific version at a later date.It is also a "snapshot" or a position that is recorded and remains fixed as the originalstate and available to be compared with the current position.

A configuration baseline maybe created for the following reasons: 

• • • as a sound basis for future work from which to progress*  
    • as a record of what CIs were affected by an RFC and what CIs were actually changed*  
    • as a point to fall back to if something goes wrongExamples of Baselines:
    • as a sound basis for future work from which to progress*  
    • as a record of what CIs were affected by an RFC and what CIs were actually changed*  
    • as a point to fall back to if something goes wrongExamples of Baseline
    • sas a sound basis for future work from which to progress*  as a record of what CIs were affected by an RFC and what CIs were actually changed*  
    • as a point to fall back to if something goes wrongExamples of Baselines:

Includes hardware, software and any associated documentation.

A database which holds a record of all CIs associated with IT infrastructure (Configuration Management Database).

Selection of Configuration Managment tool

• make sure the tool supports all the platform of the organisation

  understand the functionality to avoid any overlaps or gaps

  some tools only support two levels of CI and this can be very restrictive

  the ability to control software automatically can save time and reduce errors

  the length of identifyers is crucial with software because there are often duplicate filenames in different parts of a structure

The following considerations should be considered when defining Configuration Items (CIs):

- CI naming convention

• relatively short, meaningful, potential for growth, use manufacturer identifiers

- Decide on the CI-Level

• Granularity (pc mice included etc)

 - Classifying CI's into Types / Lifecycles, define Attributesand also roles that can promote CI's in their life-cycles

- The relationships between CIs should be stored so as to provide dependency information

Planning: 

This includes setting up the process "boundaries" like the goal, scope, objectives, policies, procedures and interaction expected with other processes.

It is the task of the Configuration Manager to determine what can be achieved, at what cost - balanced against the business requirements.

This combination affects the level of detail and how many C.I.'s will be specified.

CI Level is a key part of the Planning activity. The CI Level refers to the amount of detail that will be captured for each CI.

Identification: 

The identification activity involves the gathering of all CI information within the scope of the process. 

C.I. information is gathered either manually and/or by the use of automated tools. 

The information gathered will be governed by the scope, C.I. level and attributes decided upon.

Before gathering any information control procedures and the Change Management process should be in place so that

after information is gathered and populated into the CMDB changes to the infrastructure don’t make it redundant.

Control 

Before the CMDB is populated control procedures should be in place.  It is vital that changes to the CMDB and the

CI’s within are only made with the proper authorization. Procedures need to be set up so that all changes are always

documented, for example with authorized RFC’s.  We can start to see the very strong relationship that Change and

Configuration Management share.

Status accounting 

Status accounting is the activity that records the current and historical states of a C.I. so every change to a C.I. is

traceable. Status levels can be defined as part of the planning process (eg. On order, In use, Out of order,

Under repair, Retired).

Verification and audit 

By conducting regular audits an organization can verify that all C.I.’s are recorded correctly.

The first audit should be held right after the CMDB has been implemented to be make sure it is a correct

representation of the actually IT infrastructure.

Other times for audits can be after disasters, major changes and following a pre-defined timetable.

The degree of audit will again need to take into consideration the value that will be derived from the audit

and the size (and therefore cost) of doing the audit. Partial audits, spot audit checks are all feasible strategies

to "get a feeling" about the level of C.I. accuracy.