The Professor was recently asked for real life examples or best practices for the criteria that organizations have used to define major incidents. ITIL defines a major incident as an incident that results in significant disruption to the business and so real world examples are going to vary from one business to the next. For a financial services company, for example, a major incident could be an incident affecting live money transactions. For a retail company, a major incident could be an incident affecting its point of sale service. For a manufacturing company, a major incident could be an incident that affects the production line. Simply put… real dollars are being lost. A major incident could also be a service outage that affects are large number of users. Those users could be your company’s external customers, or it could be your internal employees. So for many organizations, outages affecting the company’s web site, or its email or customer relationship management (CRM) service

A close friend of mine has a saying that I always remember “All roads lead through incident management”. We know that the primary goal of the incident management process is to restore normal service operations as quickly as possible and to minimize any adverse impact on business operations. This will insure the highest levels of service quality and availability are delivered to the user community, guaranteeing that the business is receiving value and facilitating the outcomes it wants to achieve. The value this process produces for the business is in the ability to: detect and resolve incidents quickly, resulting in higher availability of IT services. align IT activities to real time business priorities and dynamically allocate resources as necessary. identify potential improvements to services, through the analysis of incident trends. So it sounds like we have everything covered as long as we handle all incidents in the same consistent and proceduralized manner. Well not so fast

Our senior IT executives are being held accountable to better manage the quality and reliability of IT in business and respond to a growing number of regulatory and contractual requirements. Every enterprise needs to tailor the use of standards and practices to suit its individual requirements. Control Objectives for Information and Related Technology (COBIT) and the IT Infrastructure Library (ITIL) can both play a useful role in IT governance. Very simply COBIT helps our senior management teams to define what should be done and ITIL provides the framework for how to manage our services. When we think about COBIT and IT governance at the most fundamental level, there are four questions that every leader asks him or herself when it comes to IT initiatives: Is my IT organization doing the right things? Are we doing them the right way? Are we getting them done well? Are we getting value from our IT department? COBIT helps answer these questions by defining IT activities in a gen

During one of my recent classes a discussion came up about the difference between roles and jobs. ITIL v3 speaks to the importance of roles in performing the steps or activities of a process or procedure. A role is a set of responsibilities, Activities and authorities granted to a person or team. A Role is defined in a Process. One person or team may have multiple Roles, for example the Roles of Configuration Manager and Change Manager may be carried out by a single person.               -- Service Strategy Glossary This appears to be a fairly clear definition of “role”. So why do some people have difficulty identifying the proper roles to play during the execution of a process? As the recent discussion showed, it may be because of our long focus on jobs as opposed to roles. Most learners recognize a difference between the two. When asked how many “job titles” they have, the answer is inevitably that they have one job title. When asked how many roles they perform, they inevitably r

One of my favorite sets of analogies to use in class is food, the making of  food or restaurant operations. We make what we eat by pulling together ingredients into recipes. In the same way, we design services. We use the elements of services combined into the five aspects of design (solutions, tools, architectures, process and measurement) to produce the Service Design Package (SDP). When we think about designing services, we must remember it takes a number of elements. ITIL v3 says there are four elements of service design: People Process Products Partners I like to think of these elements as the “ingredients” of a service. The most important “ingredient” in any service is the “people”. We can have effective processes, efficient products, and loyal partners, but without people the service will get nowhere.   People are the elements that make the value for the customer truly possible. Processes do not execute themselves, products do not spontaneously build and partners are not

The Professor has been asked, “Does ITIL address Technology Lifecycle management?” In version 2 of ITIL, the ICT Infrastructure Management book focused on technology management.  This is still a good resource, although availability of the publication may now be very limited.   In Version 3, the same information is spread across the lifecycle - most heavily in Service Design, Service Transition and Service Operation.  There are a couple of updates in ITIL Version 3 for technology management.   Configuration Management is now "Service Asset and Configuration Management" so that Asset Management and Configuration Management are integrated.   Service Design now defines a Technical Service Catalog to acknowledge underpinning technical services that are critical elements of business services.  ITIL also includes a Technical Management function as the custodian of technical expertise. While the Technical Management function performs most of it's work in Service Operation, it

In a previous Blog I spoke to Application Management from the point of view that they do not actually develop the application but manage it throughout its entire lifecycle. This is done through the Application Management Lifecycle along with Operational Models. Operational Models are the specifications of the operational environment in which the application will run after it has been deployed. This model is used to simulate and evaluate the live environment during the Design and Transition stages. It also ensures that proper environmental requirements and sizing can be documented and understood by all groups or teams involved with application development and management. Many of you are familiar with “Software Lifecycle (SLC) and “Software Development Lifecycle” (SDLC). These are use by application development and project teams to manage the designing, building, testing, deployment and support of applications. From an ITIL perspective the Application Management Lifecycle looks at the