ITIL Foundation Online Training - $47/mo Description: 14+ Hours, 200+ Practice Questions, Lifetime Access, 100% Online, Self-paced Click Here

10 Full ITIL Mock Exams for only $25/mo.Check if you are ready to take the ITIL Exam and crack it in the first attempt Click Here

Thursday, December 29, 2011

The Continual Service Improvement model


The Continual Service Improvement model can be applied to any improvement plan. The model consists of six steps as shown below:


Step 1: Clarify the vision, taking into account both the business and IT vision, mission, goal and objectives, and ensuring that everyone has a common understanding. Visions are aspirational and represent a desired state.
Step 2: Assess the current situation and establish a baseline of exactly where the organisation is currently. This can be challenging and there is a need to be honest, which is why external input can be useful.
Step 3: Define steps towards the vision based on priorities for improvement and setting measurable targets. It is usually impossible to leap from wherever you currently are direct to the state represented by the vision.
Step 4: Document an improvement plan, using service and process improvement techniques.
Step 5: Monitor achievements, making use of appropriate measures and metrics as defined earlier.
Step 6: Maintain the momentum by ensuring that improvements are embedded and looking for further improvement opportunities.

Delivering improvements

A key to successful improvement is measurement. CSI advocates the use of industry approaches such as the Deming ‘Plan—Do—Check—Act’ model and a process known as the ‘Seven-step Improvement Process’. We will be covering both of these aspects at a later stage in detail.

Prev: Goals, Purpose and Objectives of Continual Service Improvement

Next: Introduction to Service Portfolio Management

Goals, Purpose and Objectives of Continual Service Improvement


Let us now take a look at the Goals, Purpose and Objectives of the Continual Service Improvement process.

Goals

Continual Service Improvement (CSI) aims to deliver business value by ensuring that the Service Management implementation continues to deliver the desired business benefits (and if possible add value to the service)

Objectives

CSI has the following objectives:
• To review, analyze and make recommendations on where improvements could be made at any point throughout the lifecycle.
• To review and analyze service level achievements against targets.
• To identify and implement individual activities to improve service quality and the efficiency and effectiveness of service management processes.
• To improve the cost-effectiveness of delivering IT services without impacting customer satisfaction.
• To apply quality management methods to support continual improvement activities.

CSI must be an objective for everyone in the organization, but improvement activities will only happen if they are properly managed. A senior responsible owner must be appointed and they must possess the appropriate authority to make things happen. This is not a trivial role, since improvements may mean significant disruption of current work patterns.

Improvement activities need to be planned and scheduled on an ongoing basis and their effects monitored to ensure that the desired improvement is achieved. Ideally, the culture of ‘improvement’ will become embedded within the organization.

Scope

CSI is applicable across all stages of the Service Lifecycle and addresses three main areas:
• The overall health of Service Management as a discipline.
• Continual alignment of the Service Portfolio with current and future business needs.
• The maturity of the enabling IT processes.

Value to business

CSI recognizes that the value IT provides to the business can be realized and measured in different ways:
Improvements: Outcomes that are better when compared with the previous state.
Benefits: The gains achieved through the implemented improvements.
Return on investment (ROI) : The difference between the realized benefit and the cost of achieving it.
Value of investment (VOI) : The extra value created by the improvement including non-monetary benefits and outcomes.

Implementing CSI means committing to continued investment in order to create and maintain Service Improvement Plans (SIPs).
The expected value from an investment is a critical component of any business case, and CSI stresses the need for periodic re-evaluation following the implementation of improvements by:
• checking that benefits/ROI/VOI are realized by specific improvements;
• identifying the best investments by estimating benefits from different initiatives;
• Assessing the impact on current benefit of any proposed change of organization structure or business strategy, or of regulatory or legislative change.

Many organizations have been traditionally very poor at checking that planned benefits have actually been delivered in the manner intended and hence often compound the situation by making future decisions on the assumption that some significant change in value has occurred. This is not only incorrect but also creates chaos and service disruption.

Prev: Introduction to Continual Service Improvement

Next: Continual Service Improvement Model

Introduction to Continual Service Improvement


Once a Service Management solution has been implemented, it is not a good idea to sit back and think that the job has been done. It is a good idea to think about how the service can be improved to benefit both the organization and the end customer. All aspects of the environment will be continually changing, and the service provider must always continue to seek improvements. Continual Service Improvement is responsible for ensuring that these improvements are identified and implemented. The performance of the IT service provider is continually measured and improvements are made to processes, IT services and the IT infrastructure in order to increase efficiency, effectiveness and cost-effectiveness.

A Real Life Example:
Remember the www.abcbank.com website example in the chapter on Introduction to Service Operation? Let’s say that due to security issues in the internet, customers’ accounts are being hijacked. It would be a good idea to implement a multi-level authentication mechanism, wherein the customer has to key-in a onetime password sent via sms or email to ensure that the person who is logging in is indeed who they claim to be. This would be a value addition to the website and a superb example of how Continual Service Improvement can benefit both XYZ IT Services and ABC Bank

Prev: Key Activities & Functions of Service Operation

Next: Goals, Purpose and Objectives of Continual Service Improvement

Sunday, December 25, 2011

Key Activities and Functions in Service Operation


In the previous chapters, we learnt what Service Operation is and how valuable it is to the organization. Service Operation is not a standalone activity. There are a number of processes that are performed as part of Service Operations. They are:
Event Management: This is the process responsible for the monitoring of all events throughout the IT infrastructure and applications to ensure normal operation. Event Management is there to detect, escalate and react to exceptions.
Incident Management: This is the process for dealing with all Incidents. These may be Incidents where service is being disrupted or where service has not yet been disrupted.
Request Fulfillment: This is the process that carries out Service Requests from users. Request Fulfillment covers Standard Change requests, requests for information and complaints. From a Service Desk perspective, the process of Request Fulfillment tends to cover all the calls that are neither Incidents nor relate to Problems.
Problem Management: This process is responsible for the management of all Problems in the IT infrastructure. The process includes root cause analysis and arriving at the resolution of Problems. Problem Management remains responsible until resolutions are implemented via the processes of Change Management and Release Management.
Access Management: This process enables users with the correct level of authorization to access an application or service. It is also ensures that those without the required level of authorization are not able to access applications and services. Access Management allows an organization to control access to applications and services.
The functions of Service Operation are:
The Service Desk: This conducts a number of processes, in particular Incident Management and Request Fulfillment. The Service Desk is made up of a group of staff trained to deal with service events. Service Desk staff will have access to the necessary tools to manage these events. The Service Desk ought to be the single point of contact for IT users within an organization.
Technical Management: This is the function that provides the resources and ensures that knowledge of relevant technologies is kept up to date. Technical Management covers all the teams or areas that support the delivery of technical knowledge and expertise. This includes teams such as Networks, Mainframe, Middleware, Desktop, Server and Database.
Application Management: This will manage applications through the totality of their lifecycle. This starts with the first business ‘idea’ and completes when the application is taken out of service. Application Management is involved in the design, testing and continual improvement of applications and the services that the applications support.
IT Operations Management: This is responsible for operating the organization’s IT infrastructure and applications on a day to day basis.

The area which delivers the value has been modeled and designed elsewhere, so Service Operation will have many interfaces to processes that are part of the other Lifestyle phases, in particular Service Asset and Configuration Management, Release and Deployment Management, Knowledge Management, IT Service Continuity Management and Service Level Management.

Good communication is crucial for Service Operation. There needs to be active communication between IT teams and departments and with business areas and users. Members of staff undertaking Service Operation processes should be aware of the requirement to communicate on a regular basis with members of staff conducting other processes.

One should remember, however, that effective communication must have an understood purpose and, ideally, a specified audience. Too much communication without specific purpose or desired outcome can and usually will be counterproductive. Information overload tends to dull people’s attention to new information, and this can be just as bad as not communicating.

Previous: Goals of Service Operation

Next: Introduction to Continual Service Improvement

Goals, Purpose and Objectives of Service Operation


The purpose of Service Operation is to organize and conduct the activities and processes needed to deliver services to business users at agreed levels of service. Additionally, Service Operation is responsible for the ongoing management of the technology (both infrastructure and applications) that is utilized to deliver and support the services.

Service Operation is the balancing act. It is not just a matter of carrying out the processes on a day to day basis. There is a dynamic ‘debate’ that is taking place on four levels. These are known as the Four Balances of Service Operation:

Internal IT view versus external business view: The external business view of IT will relate to the services delivered to users and customers while, internally within IT, those services will be viewed as a number of components. Individuals or teams responsible for the running of particular components may not understand how their components fit into the overall delivery of a particular service. If an organization is too externally focused, there is the risk that agreements will be made with the business that cannot be actually delivered due to a lack of understanding of how the internal constituent parts need to operate. Conversely, an organization that is too internally focused is likely to struggle to understand and deliver business requirements.
Stability versus responsiveness: Changes are frequently the causes of Incidents and loss of availability, so it may be tempting to limit the number of changes in order to boost the stability of services. However, changes will always be needed in order to keep service up to date and to adapt to evolving business needs. The balance is between being able to speedily respond to changes and focusing on the stability of the infrastructure.
Quality of service versus cost of service: There will always be pressures to boost the quality of IT services while controlling costs. Intense budgetary pressures may lead to reduced levels of service with more failures and less support. On the other hand, organizations out of balance on the ‘other side’ may be paying too much for their services with resilience built in that cannot be justified. The key is to have a meaningful dialogue over costs ensuring that the business fully understands what it gets and does not get for a certain amount of money and what it would get if it spent a bit less or a bit more.
Reactive versus proactive: An extremely proactive organization will always be predicting where things could go wrong and taking action to mitigate or prevent the situation. Taken to the extreme, such organizations may over monitor and apply unnecessary changes. Conversely, organizations that are purely reactive spend most of their time ‘firefighting’ and dealing with situations as they arise, and they need to move more to the ‘fire prevention’ approach of predicting and avoiding Incidents and Problems.

The Value of Service Operation

Each of the stages of the ITIL Service Lifecycle adds and provides value to the business. Service Operation does this by carrying out the processes and running the services as intended by the Service Strategy, Service Design and Service Transition stages of the Lifecycle. Service Operation is the visible face of the IT organization and is the ‘nearest’ to the users and customers. Effective and efficient delivery of service is what is expected of Service Operation.

Remember the www.abcbank.com website example in the introduction chapter of Service Operation?

Previous: Introduction to Service Operation

Next: Key Activities in Service Operation

Introduction to Service Operation


Service Operation is the phase of the IT Service Management Lifecycle that is responsible for ‘business as usual’ activities. If services are not utilized or are not delivered efficiently and effectively, they will not deliver their full value, irrespective of how well designed they may be. It is Service Operation that is responsible for utilizing the processes to deliver services to users and customers.

Service Operation is where the value that has been modeled in Service Strategy and confirmed through Service Design and Service Transition is actually delivered. Without Service Operation running the services as designed and utilizing the processes as designed, there would be no control and management of the services. Production of meaningful metrics by Service Operation will form the basis and starting point for Service Improvement activity.

A Real Life Example:

Let us say ABC Bank comes to XYZ IT services company to design an Internet Banking Website. After the Service Strategy, Service Design & Service Transition, XYZ IT Services has delivered the website www.abcbank.com where the customers of ABC Bank can login and perform banking transactions. However, unless the Website is up and operational, there is no point in the Strategy, Design & Transition of the website happening. If the website isnt operational, what is the value that was created by these 3 phases that happened before?

Its pretty useless right? That is why, the Service Operation phase is extremely vital and is an integral part of the Service lifecycle.

Previous: Challenges in Service Transition

Next: Goals of Service Operation

Wednesday, December 21, 2011

Challenges in Service Transition


Establishing effective Service Transition can be challenging. The following are some of the issues that can arise and need to be addressed to ensure that the Service Transition happens smoothly:
• Ensuring that all change activity is driven through Service Transition.
• Balancing the evolving needs of the business against the need to protect live services (i.e. being responsive while maintaining suitable protection).
• Integrating with development and project lifecycles which traditionally are independent.
• Having the appropriate authority and empowerment to execute the processes as defined.
• Managing people’s perceptions so that the processes are not seen as a barrier to change or as being over bureaucratic.

The Service Transition Manager

The Service Transition Manager is responsible for planning and coordinating the resources to deploy a major release within the predicted cost, time and quality estimates. He will be the Go-To guy for the whole Service Transition Process.

Previous: Service Transition - Process Objectives & Value

Next: Introduction to Service Operation

Service Transition - Process Objectives and Value


As part of Service Transition, the following four processes need to be done.

Transition Planning and Support:

An integrated approach to planning improves the alignment of Service Transition plans with the plans of the customers, suppliers and the business, and can significantly improve a service provider’s ability to handle high volumes of change and releases.

Service Validation and Testing:
The objective of Service Validation and Testing is to ensure that a new or changed service and its associated release process will meet the needs of the business at the agreed cost.
Service Validation and Testing activities can be applied throughout the Service Lifecycle to provide quality assurance of any aspect of a service. The complete end to end service needs to be considered and both internally and externally developed service components included.
Service Validation provides value by preventing service failures that can harm the service provider’s and the customer’s assets, which can result in outcomes such as loss of reputation, financial loss, time delays, injury or even death.

Service Evaluation:
Evaluation is a generic process that considers whether the performance of something is acceptable, value for money, fit for purpose and whether implementation can proceed based on defined and agreed criteria. The objectives of Service Evaluation are:
• To evaluate the intended effects of a service change and as much of the unintended effects as reasonably practical given capacity, resource and organizational constraints;
• To provide good quality outputs from the evaluation process so that change management can expedite an effective decision about whether a service change is to be approved or not.
The scope includes the evaluation of any new or changed service defined by Service Design, during deployment and before final transition to the production environment.

Managing organizational and stakeholder change:

While Service Transition’s basic role is to implement a new or changed service, a change of any significance may involve an organizational change, ranging from moving a few staff to work from new premises through to major alterations in the nature of business working

Organizational change efforts fail or fall short of their goals because changes and transitions are not led, managed and monitored efficiently across the organization and throughout the change process. Service Transition therefore needs to ensure that any such implications are considered and brought to the attention of relevant stakeholders to ensure that the organization is ready to receive and use the new service when it is introduced.

Previous: Goals, Purpose & Objectives of Service Transition

Next: Challenges in Service Transition

Goals, Purpose and Objectives of Service Transition


The goals of Service Transition are to:
• Set customer expectations on how the new or changed service will enable business change;
• Enable the customer to integrate a release seamlessly into their business processes and services;
• Reduce variations in the predicted and actual performance of the services once they are introduced;
• Reduce known errors and minimize the risks from change;
• Ensure that the service can be used in the manner in which it is required.

The objectives of Service Transition are to:
• Plan and manage the resources to introduce and activate a new or changed service to the live environment within the predicted cost, quality and time estimates
• Minimize any unpredicted impact on the production services, operations and support organization
• Increase customer, user and service management staff satisfaction with the deployment of new or changed services, including communications, release documentation, training and knowledge transfer
• Increase correct use of the services and any underlying applications and technology solutions
• Provide clear and comprehensive plans that enable alignment between the business and Service Transition.

Service Transition includes the management and coordination of the resources that are needed to package, build, test and deploy a release into production and to establish new or changed services as specified by the customer and stakeholder requirements. Service Transition also manages the transfer of services to or from external service providers.

When done well, Service Transition helps organizations to be more agile, with the capability and capacity to respond more rapidly and with greater certainty of success to change. This ability to adapt makes organizations more competitive as market places adjust to economic, social, environmental and political change.

In summary, effective Service Transition is an essential part of good governance. Change can be embraced more rapidly and more effectively without damaging the business, and the business, its customers and its employees can all face change with greater confidence in the outcome. Everyone knows what to expect and, if Service Transition is effective, those expectations will be satisfied in reality.

Previous: Introduction to Service Transition

Next: Service Transition - Process Objectives & Value

Introduction to Service Transition


There has frequently been a disconnection between the Development and Operations departments within IT, which has consequently led to many failed implementations of new or changed services. Service Transition is concerned with bridging that gap smoothly, ensuring that operational requirements are fully considered and catered for before anything is moved into the live environment, including documentation and training for users and support staff. Service Transition is also responsible for the decommissioning and removal of services that are no longer required.

Smooth transition is achieved by taking a new or changed Service Design Package (SDP) from the Service Design stage, testing it to ensure that it correctly meets the needs of the business, and deploying it within the production environment.
Some of the processes that are part of this phase are also used within other phases, in particular Service Knowledge, Change and Configuration Management.

Previous: Service Design Package

The Service Design Package


The Design Stage takes a set of new or changed business requirements and develops a solution to meet them. The developed solution is passed to Service Transition to be built, tested and deployed into the live environment.

However, it is not enough simply to pass the technical or architectural design to Service Transition. The Service Transition teams will need more than this to deliver a fully functioning service that provides the Utility and Warranty expected. They need a blueprint that covers all aspects of the new service. This blueprint is known as the Service Design Package.
Note:
Service Design Package - (Service Design) Document(s) defining all aspects of an IT Service and their Requirements through each stage of its Lifecycle. A Service Design Package is produced for each new IT Service, major Change or IT Service Retirement.

The key contents of the Service Design Package include:
• The Service definition, agreed business requirements and how and where the Service will be used
• The Service Design including the architectural design, functional requirements, SLRs/ SLAs (if available), service and operational management requirements including metrics and key performance indicators, supporting services and agreements
• A service model showing the overall structure and dynamics of the Service, showing how customer and service assets, Service Management Functions and Processes come together to deliver value
• An assessment of organizational readiness and its implications
• A plan covering all stages of the Service Lifecycle
• Plans for Service Transition (covering build and assembly, test, release and deployment) and for operational service acceptance
• Acceptance criteria and the strategy and plan for User Acceptance Testing

Previous: Goal of Service Design

Next: Introduction to Service Transition

The Goals of Service Design


In the previous Chapter, we saw the 5 pillars of Service Design. In this chapter, let’s look at the main goals of Service Design. i.e., what exactly Service Design is supposed to do.

The purpose or Goals of Service Design are:
• To design services that not only satisfy business and stakeholder objectives in terms of quality, ease of use, compliance and security, but also minimize the Total Cost of Ownership
• To design efficient and effective policies, plans, processes, architectures and frameworks to manage services throughout their lifecycle
• To support Service Transition in identifying and managing the risks associated with introducing new or changed services
• To design measurement systems for assessing the efficiency and effectiveness of Service Design and its deliverables
• To contribute to Continual Service Improvement (CSI), particularly by designing in features and benefits and then responding to improvement opportunities identified from the operational environment

Previous: Five Major Aspects of Service Design

Next: Service Design Package

The Five Major Aspects of Service Design


ITIL formally recognizes five separate aspects of Service Design that together describe the Service Design Process:
• The introduction of new or changed services through the accurate identification of business requirements and the agreed definition of service requirements.
• The Service Management systems and tools such as the Service Portfolio, ensuring mutual consistency with other services and appropriate tools support.
• The capability of technology architectures and management systems to operate and maintain new services.
• The capability of all processes, not just those in Service Design, to operate and maintain new and changed services.
• Designing in the appropriate measurement methods and metrics necessary for performance analysis of services, improved decision-making and continual improvement.


Previous: Why Service Design?

Next: Goals of Service Design

Why Design Services?


Without a well-established Service Design, services will become less stable and more expensive to maintain and become increasingly less supportive of business and customer needs. Furthermore, the cost of correcting these deficiencies is almost always higher than the costs that would have been incurred to prevent them at the design stage.

Not every change will require Service Design activities. Rather these are reserved for ‘Significant’ changes. Each organization must decide its own definition of ‘Significant’ and use the Change Management process to assess the significance of each change and therefore whether or not Service Design activities need to be used.

Good Service Design will deliver a range of business benefits that help to underline its importance in the design of new and changed services. These are summarized below:
• Lower cost services because of the lower support and enhancement costs, leading to lower Total Cost of Ownership (TCO).
• Services that consistently provide the required level of quality and alignment to business and customer needs.
• Faster and easier introduction of new services and service changes.
• Better governance to ensure compliance to legal and corporate rules and guidelines.
• Better measurement capability to support decision-making and continual improvement.

Poor planning, preparation and management are common reasons for the failure of plans and projects in general and the design and deployment of new and changed services in particular. ITIL helps prevent this by offering guidance on preparing and planning the use of people, processes, products and partners: the Four Ps of Service Design.

Note: Don’t confuse these four P’s of Service Design with the four P’s of Service Strategy.

Previous: Introduction to Service Design

Next: Five Major Aspects of Service Design

Introduction to Service Design


Once an organization has determined the IT strategy it wishes to pursue, it uses the Service Design phase of the lifecycle to create new services which Service Transition then introduces into the live environment. In so doing, Service Design aims to take the necessary steps to ensure that the new service will perform as planned and deliver the functionality and benefits intended by the business. This principle is at the heart of the ITIL approach and is why the majority of the Service Design processes are focused on operational control:
• Service Catalogue Management
• Service Level Management
• Capacity Management
• Availability Management
• IT Service Continuity Management
• Information Security Management
• Supplier Management

The purpose of the Service Design phase of the lifecycle can be summarized as ensuring the creation of cost-effective services that provide the level of quality required to satisfy customers and stakeholders throughout the life of the service.
However, the fact that business requirements change over time and generate the need or opportunity for further improvement, means that even an organization with mature Service Design processes will need to make changes to services throughout their existence.
Service Design therefore has an important role to play in supporting Continual Service Improvement and is as important for managing changes to existing services as it is in designing new services. In this respect, Service Design must also consider the impact of its activities on the overall services, systems, architecture, tools and measurements in order to minimize the potential for disruption when a new or changed service is introduced into the live environment.

Previous: Service Assets

Next: Why Design Services?

Tuesday, December 20, 2011

Service Assets


In delivering a service, the IT service provider exploits its own assets to add value to the customer’s assets and generate value for the organization.

The assets used by the IT service provider can be described in terms of its capabilities and resources. They were covered in the Chapter on Service Assets.

The development of a successful Service Strategy needs to be built on an understanding of the service assets that can be brought into play in service delivery. There is no point in formulating a Service Strategy that requires service assets that are not or will not be available. Making assumptions about the organization’s ability to improve its service asset base, especially its capabilities, introduces an element of risk that needs to be acknowledged, understood and managed.

The picture below is a diagrammatic representation of how we generate value to customers using both the service provider’s assets as well as the customers assets.


In developing a Service Strategy it is essential to recognize that generation of value to the business requires a combination of the IT service provider’s assets and the customer’s assets. This means that the development of Service Strategy must be informed by knowledge of the customer’s resources and capabilities, and the opportunities, threats, vulnerabilities and risks associated with them. The IT service provider must look outwards as well as inwards.

Value

The idea that services add value is fundamental to IT service delivery and is a key input to the development of Service Strategy. There is little point in developing services that have no recognized value. In the chapter on Service Value we saw how value is created through Utility or fitness for purpose, and Warranty or fitness for use. We can measure value not only in terms of quantifiable benefits such as financial savings or increased income, but also in terms of benefits such as service quality, which are less easily quantified and often depend on the perception of the customer or service user. The principle that value depends on customer perception leads us to conclude that effective service strategy requires a way of thinking, a ‘marketing mindset’, which captures the customer’s perspective, through which we can understand both the customer and the outcomes that the customer really values and why, and to what extent they are valued.

Automating the Service Management Process

Automating business processes delivers higher Utility and Warranty thereby generating better performance and value from service and customer assets.

The same applies to IT Service Management. Earlier in this chapter, we learnt that IT Service Management capability is a strategic asset. Building this capability through automation is fundamental to providing value to the business by remaining competitive.

Of course, effective Service Management in all but the smallest organizations is inconceivable without a level of automation. For example, Configuration Management based on paper records could hardly deliver in an organization of any significant scale.
Beyond this basic level, we can identify a number of areas where automation can improve capability. For example:
• Monitoring and measuring to an extent not possible by other means, handling high levels of complexity and volume irrespective of time or location.
• Generating automated alerts helps us respond more rapidly to events, helping us maintain service availability.
• Discovery tools enable us to maintain an up-to-date Configuration Management System and identify and deal with a range of control related problems.
• Sophisticated modeling and simulation helps us design infrastructure and applications, and model complex options for service delivery.
• Artificial intelligence is able to offer a range of capabilities from root cause analysis, through sophisticated alarm and control systems, to complex scheduling and resource management.
• Workflow management systems improve customer service and efficiency across a range of processes.

At a more basic level, automation increases productivity, enables us to handle fluctuating demand and generally do more for less. Critically for IT Service Management, it also enables us to integrate across different Service Management Processes and Functions, for example through improved coherence, shared workflow and escalation processes, shared alarms and alerts, better inter-process communication, information sharing and organizational learning. This improves efficiency, helps reduce errors and duplication of effort, and delivers better value and better service to the customer.

Previous: Service Strategy Development

Next: Introduction to Service Design

Service Strategy Development


A good strategy is mandatory for any business to be successful. Be it the overall strategy for the business or a strategy for the service that is being provided.

The long-term success of a business can be analyzed in terms of three strategic factors or building blocks:
• The market focus and position of the organization, which define where and how to compete in the marketplace.
• Performance anatomy, which is about the cultural and organizational, attributes of the service provider; it is about values and mindsets that color key decisions taken by the organization and the individuals within it.
• Distinctive capabilities, which are capabilities the organization has that the competition would find difficult to equal or copy. These differentiate the service provider at the delivery level.

Before we jump into the topic of how to create a good strategy, lets first look at the different types of Service Providers in the IT Industry

IT Service Provider Types

In the IT Industry, there are numerous types of IT service providers. Different providers are characterized by their relationship with customers and their positioning in relation to the business or businesses they service. It is helpful to simplify this complexity and identify a small number of provider types that represent the wider variety in the marketplace. This simplification leads to the following three types:
• Type I — Internal service provider: This is the in-house IT unit typically positioned within the business units they serve, although it is common for these smaller scale IT units to be consolidated into a corporate IT department that has to balance the interests, demands and priorities of the corporate organization against those of individual business units. Ex: The IT Departments of Banks or other institutions that exclusively serve their parent organizations.
• Type II — shared services unit: This is where a range of functions, regarded as non-core to the business, are grouped together into a corporate shared service unit. The functions involved are typically IT, finance and HR, sometimes with legal service, logistics and facilities management.
• Type III — External service provider: This is a separate commercial entity from the businesses it services, and operates as a competitive business in the marketplace. Ex: The IT company’s in India (like Infosys, TCS etc) provide IT Services to customers across the globe. Apart from the service they provide, they have no further relationships with their customers.

The Four P's of Strategy

Having considered the IT service provider’s strategic approach to the marketplace, the next part of the strategic equation is the IT service provider’s approach to Service Strategy. This may be analyzed in terms of the four Ps:
• Strategy as a Perspective: This relates to vision, direction and the IT service provider’s philosophy for doing business with its customers.
• Strategy as a Position: This describes strategy in terms of the IT service provider’s general approach to its service offerings (e.g. high value or low cost, emphasis on utility or warranty).
• Strategy as a Plan: This describes strategy as a plan showing how the IT service provider will move from where it is today to where it wants to be.
• Strategy as a Pattern: This describes strategy as a consistent way of making decisions.

Service Management as a Strategic Asset

There are two components of Service Strategy. Service strategy is clearly about developing strategies for the delivery of specific services, but there is also the development of Service Management as a competence for providing services as part of the business strategy and as a basis for good governance.

The development of Service Management as a strategic asset is central to Service Strategy.

Note:
Strategic Asset - Strategic assets are assets that provide the basis for core competence, distinctive performance, durable advantage, and qualifications to participate in business opportunities. IT organisations can use the guidance provided by ITIL to transform their Service Management capabilities into strategic assets.

Service Management provides the framework within which value is delivered to the customer in the shape of specific services represented collectively in the Service Catalogue. The customer’s confidence in commissioning new service offerings depends on the Service Management capabilities of the IT service provider.

Developing Strategy for Specific Services

In terms of the development of a strategy for a specific service offering, the key elements are concerned with a series of activities that involve:
• understanding the customer and the ways IT can deliver value to them
• understanding the outcomes the customer wants from the service and how the service will deliver benefit
• defining critical success factors for the service
• developing a specification based on the outcomes required by the customer, including the utility and warranty required
• Developing through Demand Management an understanding of the customer’s priorities in relation to Patterns of Business Activity (PBAs).

It is important to remember that individual services have to operate in a broader context. New services must fit into the framework of existing services and any other new services with which they will likely share common services and compete for resources. The development of a Service Strategy has to take this fully into account.

At an early stage in the development of the Service Strategy, the initial, conceptual details of the new service will be captured in the Service Portfolio and the new service will begin its journey through its lifecycle. Through Service Portfolio Management, the new service offering will be put into the broader context of other services, business trends, regulation, the developing marketplace, emerging technologies, competition, risks and so on. The business case, developed in conjunction with Financial Management, will reflect these factors and explain why the Service Strategy developed represents the best way forward as well as describing how and to what extent it will deliver value.

The outcome of the Service Strategy process is a decision to continue with the service or not. Approved services are ‘chartered’ at which point they are ready to move forward to Service Design. The transfer into Service Design requires the production of a Service Package, which describes in detail the IT service to be delivered to the customer, including the service levels to be achieved and the supporting services that will underpin its delivery.

Notes:
Service Package - ITIL defines a Service Package as a detailed description of an IT service that is available to be delivered to customers. A Service Package includes a Service Level Package (SLP) and one or more Core Services and Supporting Services.

Service Level Package - A Service Level Package is a defined level of Utility and Warranty for a particular Service Package. Each SLP is designed to meet the needs of a particular Pattern of Business Activity.

Previous: Introduction to Service Strategy

Next: Service Assets

Introduction to Service Strategy


The objective of Service Strategy is to offer better services than the competition. You need to beat the opposition to survive. Of course, to be successful in the longer term, as the industrial landscape adjusts to the inevitable economic, social, technological and political changes, organizations have to think long term. So Service Strategy is not just about the strategy for individual services today, but also about positioning the IT service provider for the long run. It also includes the design, development and implementation of Service Management as a foundation for sound governance and as part of the organization’s strategic asset base.

Governance

The concept of governance is central to the sound operation and management of all healthy organizations. It covers the various policies, processes and structures established by senior management to ensure the smooth running and effective control of the organization. The guidance provided through the ITIL disciplines offers a sound foundation for the development of effective governance, which is as important to the IT provider as to any other organization.

Effective IT procedures and controls are a vital component of good governance. The ITIL framework can be a key part of the foundations for excellent IT governance.

IT is a service business, and the adoption of ITIL Service Management practices is an effective way to address IT governance. Every part of the Service Lifecycle has a role to play. For example, Service Strategy ensures that IT investments not only address issues that are important to the business, but also that they are sound investments that take proper account of costs, benefits and risks. Continual Service Improvement helps the business achieve greater value and higher levels of efficiency while conforming to standards.

Risk

The effective management of risk, an important issue for all successful organizations, is a key component of governance.

Note:
Risk is defined as uncertainty of outcome, whether positive opportunity or negative threat

Effective risk management requires a consistent framework in which risks are identified and analyzed and appropriate measures put in place to deal with them.

Key Processes

The key processes in Service Strategy are:
• Service Strategy Development
• Demand Management
• Service Portfolio Management
• Financial Management

These processes will be covered in detail in Section 3 where they will have a chapter dedicated to themselves. So, for now, just know that these 4 processes are part of Service Strategy

Previous: ITIL Processes & Functions

Next: Service Strategy Development

ITIL Processes and Functions


Section 3 of this ITIL Preparation Series is all about the various Processes & Functions that are part of the ITIL V3 Library. Each Process/function belongs to one of the 5 areas of the Service LifeCycle which are:
1. Service Strategy (SS)
2. Service Design (SD)
3. Service Transition (ST)
4. Service Operation (SO) and
5. Continual Service Improvement (CSI)

ITIL has many processes and Functions that are part of Service Management.

The table below is the full list of processes & functions that are part of ITIL.

ITIL Processes
Process Name Parent Group
Seven-step Improvement Process Continual Service Improvement
Access Management Service Operation
Application Management Service Operation
Availability Management Service Design
Capacity Management Service Design
Change Management Service Transition
Demand Management Service Strategy
Evaluation Service Transition
Event Management Service Operation
Financial Management Service Strategy
Incident Management Service Operation
Information Security Management Service Design
IT Operations Service Operation
IT Service Continuity Management Service Design
Knowledge Management Service Transition
Problem Management Service Operation
Management of Organisational and Stakeholder Change Service Transition
Release and Deployment Management Service Transition
Request Fulfilment Service Operation
Service Asset and Configuration Service Transition
Service Catalogue Management Service Design
Service Desk Service Operation
Service Level Management Service Design
Service Measurement Continual Service Improvement
Service Portfolio Management Service Strategy
Service Reporting Continual Service Improvement
Service Validation and Testing Service Transition
Strategy Generation Service Strategy
Supplier Management Service Design
Technical Management Service Operation
Transition Planning and Support Service Transition
Note: Don’t worry too much about these processes right now. We will be covering them up in sufficient detail in section 3.

Previous: Authority Matrix

Next: Introduction to Service Strategy

Authority matrix


An authority matrix is often used within organizations to indicate specific roles and responsibilities in relation to Processes and activities.

The RACI model is an example of an authority matrix. It is probably one of the most widely used Authority Matrices in the IT Industry. It is used to map the Process activities to the Roles involved in their execution. The acronym RACI is derived from the distinct ways a Role can be involved in a Process.
• R – Responsible – The Person who is going to do the work/activity – Ex: Team Member
• A – Accountable – The person who owns the Activity - Ex: Project Manager
• C – Consulted – The person who may provide inputs for the Activity – Ex: Technical Architect
• I – Informed – The person who needs to be informed of the work/activity – Ex: Project Sponsor or PMO

Within the RACI model, each activity must have a role identified as Accountable and Responsible, whereas Consulted and Informed are optional. There must be exactly one Accountable role for each activity.

Generic roles are normally used in the RACI model, but it is vitally important that the Role - Activity links it describes are mapped back to specific individuals within the organization.

Separating the role involvement from the organization allows flexibility in the application of Role - Activity relationships to the realities and constraints of organizational design:
• It recognizes that the same Process (or activity) may be carried out by more than one organizational role or unit.
• It allows organization design to change without impacting the underlying process model.
• It recognizes constraints of geographically diverse organizations which may have to combine many responsibilities in fewer roles in smaller sites.
• It allows for complex organizations covering diverse businesses to adopt the same underlying process model without extensive adaptation.

Previous: Roles

Next: ITIL Processes & Functions

Roles



A role describes what an individual actually does. Every organization will define those Roles that it requires in order to perform the necessary tasks and will allocate individuals to perform those roles. The relationship between Roles and persons is a many-to-many one (i.e. an individual may perform more than one role and a role may be performed by more than one person). Roles may or may not be related to job titles.

Note:
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

As stated above, there should be one role that is accountable for any specific task or process. ITIL advocates that two generic roles should be defined:

Process Owner

The person who is accountable for ensuring that all activities within a Process are undertaken with responsibility for:
• defining the process strategy
• assisting with the design of the process
• ensuring that process documentation is available and current, and that all staff are trained correctly
• defining policies and standards to be followed
• defining KPIs and auditing to ensure that the Process is being followed correctly and is effective and efficient
• Reviewing proposed enhancements and providing input to the Service Improvement Plan.

Service Owner

The person who is accountable to the customer for a particular service with responsibility for:
• acting as the prime customer contact for all service-related enquiries and issues, and as an escalation point for major incidents
• representing the Service in CAB and customer meetings
• participating in negotiating SLAs and OLAs, and ensuring the Service is correctly defined in the Service Catalogue
• ensuring that the service is delivered as agreed (i.e. service levels are met)
• identifying opportunities for improving the service provided
• Ensuring that effective service monitoring is implemented.

Previous: Service Functions & Processes

Next: Authority Matrix

Service Functions and Processes


In the ITIL context a Function is a structural part of an organization (e.g. a division or a business unit) established to do specific things. For example, the Service Desk is a Function that is created to perform defined activities and produce specified outcomes. People within a function have defined roles that they perform to deliver the outcomes required. By their nature, functions are specialized and have their own disciplines, skills, performance measures and knowledge base. Functions perform activities that are elements of Processes. Individual Functions may perform an entire Process or, quite commonly, share Processes with other Functions.

Note:
A team or group of people and the tools they use to carry out one or more Processes or activities is called a Function

A process consists of a set of coordinated activities using resources and capabilities to produce an outcome, which, directly or indirectly, creates value for an external customer or stakeholder.

Every process consists of a number of elements. A process takes inputs and transforms them, using the appropriate enablers, to produce the required outputs in a closed-loop system that allows for feedback and improvement. Process control ensures that consistent repeatable processes are established, regulated and managed so that their performance is effective and efficient.

Note:
A Process is a structured set of activities designed to accomplish a specific objective. A Process takes one or more defined inputs and turns them into defined outputs. A Process may include any of the Roles, responsibilities, tools and management controls required to reliably deliver the outputs. A Process may define policies, standards, guidelines, activities and work instructions if they are needed.

Characteristics of a Process:

Processes are usually initiated by an event or trigger, transform inputs into outputs through a series of activities carried out by people or systems with specific roles with procedures or work instructions. It makes use of organization resources and capabilities as process enablers. It is has an owner responsible for it. It has documented policy, terms of reference and objectives, and it is controlled to ensure it meets its specified purpose. The process is measured against defined metrics to determine how effectively it is operating and the results are fed back to drive continual improvement

The Main Qualities that you expect from a Process are:
Measurable - We must be able to measure the Process. The performance of the Process is incredibly important. Managers will want to measure the cost and quality. People involved operationally with the Process are concerned with how long it takes and how easy it is to use.
Specific results - A Process exists in order to deliver a specific result, which must be identifiable and countable.
Customers - Each Process delivers its main results to a customer or stakeholder, who may be internal or external, and the results must meet their expectations.
Responds to a specific event - Each Process, whether it is ongoing or iterative, will have a specific trigger.

A Real Life Example:

Let us take a real life example “A Teller Accepting Cash Deposits from a Customer in a Bank”

Measurement – The Bank Management will want to ensure quality. Transactions are correctly recorded, customer is not made to wait for long etc

Results – The cash is collected from the Customer and deposited into his/her bank account

Customer – The person who wants to make a deposit into his/her bank account. Customers usually don’t like to be kept waiting. So, it is important that the teller work quickly to reduce customer wait time. At the same time, the teller must ensure that the money is deposited into the correct bank account

Trigger – The Arrival of the Customer at the Tellers Counter.

Previous: Service Model

Next: Roles

Monday, December 19, 2011

Service Model


A Service Model describes how a service provider creates value for a given portfolio of customer contracts by connecting the demand for service from the assets of its customers with the service provider’s service assets. It describes both the structure and the dynamics of the service:
Structure - The particular service assets needed to deliver the service and the patterns in which they are configured.
Dynamics - The activities, flow of resources, coordination, and interactions between customer and service provider assets (e.g. interaction between service users and service agents). Service dynamics include Patterns of Business Activity (PBAs), demand patterns, exceptions and variations.

A Service Model may include:
• process maps
• workflow diagrams
• queuing models
• activity patterns
• etc

Once defined, variants of a service model can be created in order to tailor a service to a customer’s specific needs. There is no “One-Shoe-Fits-All” in the service industry. Each team within the organization may have to adapt their services to best suit the needs of the customer for whom the service is being created.

Previous: Service Assets

Next: Service Functions & Processes

Service Assets


Service providers create value through using their assets in the form of resources and capabilities.

Note:
Resources is a generic term that can signify IT Infrastructure, People, Money or any other entity that can help deliver an IT Service. Resources are considered the assets of any organization.

Capabilities:

The ability of an organization, person, process, application, configuration item or IT service to carry out an activity. Capabilities are intangible assets of an organization.

The key difference between resource assets and capability assets is that, typically, resources can be purchased in the marketplace while distinctive capabilities can only be developed over time. Capabilities reflect the knowledge and experience of the organization and are used to transform physical resources into services. The distinctive capabilities of a service provider, often quite intangible, set it apart from its competitors, and enable it to attract and retain customers by offering unique value propositions.

The business unit to which the service is provided will also have resources and capabilities that are harnessed to provide the end service to the customer. The integration between the service and the business unit’s own assets may be very tight, making it hard to distinguish between the two, or it may be much more clearly separated.

Previous: Service Value

Next: Service Model

Service Value


In the previous chapters where we learnt about Service & Service management, you would have figured out by now that the primary focus is on delivering value to the service consumer. Value is created through providing the right service under the right conditions.

Customers value an IT service when they see a clear relationship between that IT service and the business value that they need to generate. In the past, both IT and business management have been very poor at understanding this link. IT has often known all about the costs of components, but not the cost of providing a service that the business understands, and the business has been unable to make value-based decisions about the worth of such solutions.

Value is created through two components:
Utility - Value in the form of what the customer gets from the service. This will either be from providing new business lines or from the relaxation of existing constraints on the customer’s ability to achieve their desired outcomes. Utility is about what the product or service does, determining whether it is ‘Fit for purpose’.
Warranty: Value in the form of how this ‘utility’ is delivered to the customer. This is seen as the positive effect of the service being available when and where it is required, in sufficient capacity to meet the business needs, and being sufficiently reliable in terms of continuity and security for it to be depended on (i.e. it is ‘Fit for use’).

Note:
1. Utility can be summarized as “What this Service Does”
2. Warranty can be summarized as “A Promise that the product or service will do what it is supposed to do and most importantly do it correctly”

Neither Utility nor Warranty can deliver full value on its own. A product or service may do exactly what the customer requires, but if it performs poorly, or is unavailable, insecure or unreliable, it cannot deliver maximum value. Conversely, a service will not deliver value if it does not provide the functionality needed, even though it may be highly available, reliable and secure and offer high levels of performance.

A service that seems potentially attractive on paper to a customer in terms of the Utility that it offers won’t be perceived as providing real value if the way it is delivered is highly unreliable or it is delivered in an insecure manner. A customer’s ability to realize value from an IT service is dependent on both the Utility associated with the service and the degree to which they can rely on the consistent delivery of that service (the service Warranty).

A Real Life Example:

Banking Industry has evolved greatly over the past decade or so and is offering a suite of products to help the customer satisfy his banking needs, that too without having to go through the hassle of visiting the bank branch everytime he needs something. The ATM Machine, Internet Banking, Phone Banking are all excellent examples of the Value the Banks provide to us as Customers.
If, the ATM or the Internet Banking website doesn’t work, will there be any value in these services being available? Definitely Not.

Previous: Service Management Model

Next: Service Assets

The ITIL Service Management Model


Whether services are being provided by an internal unit of the organization or contracted to an external agency, all services should be driven solely by business needs and judged by the value that they provide to the organization. Decision-making therefore rests with the business. Within this context, services must also reflect the defined strategies and policies of the service provider organization, which is particularly significant for external providers.

The picture below illustrates how the Service Lifecycle is initiated from a change in requirements at the business level. These new or changed requirements are identified and agreed at the Service Strategy stage and documented. Each of these ‘packages’ will have an associated defined set of business outcomes.

The package is passed to the Service Design stage where a service solution is produced, defining everything necessary to take this service through the remaining stages of the lifecycle. Solutions may be developed internally or consist of bought in components that are integrated internally.

The design definition is passed to the Service Transition stage, where the service is built, evaluated, tested and validated, and transitioned into the live environment, where it enters the live Service Operation stage. The transition phase is also responsible for supporting the service in its early life and the phasing out of any services that are no longer required.
Service Operation focuses on providing effective and efficient operational services to deliver the required business outcomes and value to the customer. This is where any value is actually delivered and measured.


Continual Service Improvement identifies opportunities for improvement (which may arise anywhere within any of the lifecycle stages) based on measurement and reporting of the efficiency, effectiveness, cost-effectiveness and compliance of the services themselves, the technology that is in use and the Service Management processes used to manage these components. Although the measurements are taken during the operational phase, improvements may be identified for any phase of the lifecycle.

Previous: The ITIL Core

Next: Service Value

The ITIL Core


The Service Lifecycle is an approach to IT Service Management that emphasizes the importance of coordination and control across the various functions, processes and systems necessary to manage the full lifecycle of IT services. The Service Management Lifecycle approach considers the strategy, design, transition, operation and continual improvement of IT services.

The Service Lifecycle is described in a set of five publications within the ITIL Core set. Each of these publications covers a stage of the Service Lifecycle.
1. Service Strategy (SS)
2. Service Design (SD)
3. Service Transition (ST)
4. Service Operation (SO) and
5. Continual Service Improvement (CSI).

The term ‘continual’ is used in preference to ‘continuous’ to emphasize that this activity is not performed on a constant basis, but as a series of planned and controlled actions.

The picture below shows how these activities are connected to one another. Together they form the ITIL CORE.


Service Strategy is the hub around which everything revolves. Strategy drives all the decisions that are subsequently taken. Design, Transition and Operation are the more iterative cyclic activities. At all stages throughout the lifecycle, opportunities arise for improvement.


Previous: ITIL Framework

Next: ITIL Service Management Model

The ITIL Framework


ITIL is not a standard in the formal sense but a framework which is a source of good practice in Service Management. Just because you follow ITIL doesn’t mean that your service will be of top quality. It is just a guideline or a framework that can increase the quality of your service and the chances of success. There is no guaranteed success if you implement ITIL.

The requirements focus on what must be achieved rather than how that is done. ITIL provides guidance about how different aspects of the solution can be developed.

The International Organization for Standardization (ISO) and the Office of Government Commerce (OGC), with the cooperation of the independent user group itSMF (the IT Service Management Forum), have publicly committed to keeping the standard and the framework as aligned as possible. However, it has to be accepted that they serve different purposes and have their own development lifecycles so it is unlikely that they will ever be completely synchronized.

The ITIL Library has the following two components:
The ITIL Core: Publications describing generic best practice that is applicable to all types of organization that provide services to a business.
ITIL Complementary Guidance: A set of publications with guidance specific to industry sectors, organization types, operating models and technology architectures.

The objective of the ITIL Service Management framework is to provide guidance applicable to all types of organizations that provide IT services to businesses, irrespective of their size, complexity, or whether they are commercial service providers or internal divisions of a business.

ITIL-based solutions have been deployed successfully around the world for over 20 years. Over this time, the framework has evolved considerably. The original publications, of which there were over 40, tended to be single topic and function-based. The next iteration reduced the number of books considerably, taking a process-based view and concatenating topics together to reinforce the integrated nature of service management solutions. The latest iteration (commonly referred to as v3) now provides a broader, holistic approach to the Service Lifecycle.

The generic nature of ITIL has both strengths and weaknesses. Since it is generic, it truly can be applied to any organization of any size in any market sector and regardless of whether the service provider is internal to the business or a commercial enterprise. However, organizations have to adopt and adapt the guidance that it contains to their specific requirements, which in some cases requires considerable effort and commitment.

Unfortunately, much of the focus in learning programmes is on the specifics of terminology and process definitions included within the ITIL volumes, which means that individuals aren’t always equipped to make the necessary decisions about how to implement key processes and functions.

Organizations should not be seeking to ‘implement ITIL’, but to implement a service management solution based on ITIL that meets the needs of the organization.

Note:
Implementing ITIL in your organization improves the quality of the service, provided it is done the right way. Considerable effort is required to successfully implement ITIL

Previous: Introduction to Service Management

Next: The ITIL Core

Introduction to Service Management


This is the first chapter in our series to learn about ITIL V3 and proceed towards our goal of being ITIL V3 certified.
In order to understand what Service Management is, and why it is so important to enterprises, we need to understand what services are, and how Service Management can help service providers to deliver and manage these services.

ITIL defines a service as follows:
A service is a means of delivering value to customers by facilitating outcomes that customers want to achieve without the ownership of specific costs and risks.

The outcomes that customers want to achieve are the reason why they purchase or use a service. Typically this will be expressed as a specific business objective. For ex: A hospital may want to keep track of all its patients and the treatment they were offered. To enable the Hospital an IT company may create an “Hospital Management System” using which the Hospital can meet its requirement. The value of the service to the customer is directly dependent on how well a service facilitates these outcomes.

Although the enterprise retains responsibility for managing the overall costs of the business, they often wish to devolve responsibility for owning and managing defined aspects to an internal or external entity that has acknowledged expertise in the area.

This is a generic concept that applies to the purchase of any service. Another example could be financial planning. As a normal individual, we realize that we don’t have the expertise, or the time, or the inclination to handle all the day-to-day decision-making and management of individual investments that are required. Therefore, we engage the services of a professional manager to provide us a service. As long as their performance delivers a value (increasing wealth) at a price that we believe is reasonable, we are happy to let them invest in all the necessary systems and processes that are needed for the wealth creation activities. (The above is a simple example of how an Investment Manager or a Mutual Fund works)

From an investors perspective, the above is a Service but from the Service Providers perspective, whatever they do to keep us (the customer) satisfied of the service that is being provided it is “Service Management”

Service Management is what enables a service provider to:
• understand the services that they are providing from both a consumer and provider perspective;
• ensure that the services really do facilitate the outcomes that their customers want to achieve;
• understand the value of those services to their customers and hence their relative importance;
• Understand and manage all of the costs and risks associated with providing those services.

The definition of Service Management is:
Service Management is a set of specialised organisational capabilities for providing value to customers in the form of services.

These ‘specialized organizational capabilities’ include the processes, activities, functions and roles that a service provider uses to let them to deliver services to their customers, as well as the ability to establish suitable organization structures, manage knowledge, and understand how to facilitate outcomes that create value.

Although there is no single definition of a profession, it is widely accepted that the word profession applies where a group of people share common standards and disciplines based on a high level of knowledge and skills, which are gained from organized education schemes supported by training through experience and are measured and recognized through formal qualifications. Moreover, a profession seeks to use its influence through the development of good practice guidance and advice in order to improve the standard of performance in its given field. Service Management has a clear right to regard itself as a profession and the exercise of Service Management disciplines as professional practice.

Service Management is also a professional practice performed and supported by a global community drawn from all market sectors. There is a rich body of knowledge and experience including formal schemes for the education of individuals.

Difference between “Best Practice” and “Good Practice”

Enterprises operating in dynamic environments need to improve their performance and maintain competitive advantage. Adopting practices in industry-wide use can help to improve capability. If you were a customer who wants to acquire a service, you will most probably choose the company that implements industry wide best practices and offers the best quality product. Of course, this comes at a cost, but in most cases customers are willing to shell out some extra cash in order to receive the best possible product/service.

The term ‘best practice’ generally refers to the ‘best possible way of doing something’. As a concept, it was first raised as long ago as 1919, but it was popularized in the 1980s through Tom Peters’ books on business management.
The idea behind best practice is that one creates a specification for what is accepted by a wide community as being the best approach for any given situation. Then, one can compare actual job performance against these best practices and determine whether the job performance was lacking in quality somehow. Alternatively, the specification for best practices may need updating to include lessons learned from the job performance being graded.

Enterprises should not be trying to ‘implement’ any specific best practice, but adapting and adopting it to suit their specific requirements. In doing this, they may also draw upon other sources of good practice, such as public standards and frameworks, or the proprietary knowledge of individuals and other enterprises.

These sources have different characteristics:
• Public frameworks and standards have been validated across diverse environments.
• Knowledge of them is widely distributed among industry professionals.
• Training and certification programmes are publicly available.
• The acquisition of knowledge through the labor market is more readily achievable.

The proprietary knowledge of enterprises and individuals is usually customized for the local context and specific business needs of an organization. It may only be available to a wider market under commercial terms and may be poorly documented and hard to extract. If embedded within individuals it may not be documented at all.

Enterprises deploying solutions based on good and best practice should, in theory, have an optimal and unique solution. Their solution may include ideas that are gradually adopted by other enterprises and, having been widely accepted, eventually become recognized inputs to good and best practice.

Trivia:
Company’s sometimes choose the good practice over the best practice due to cost constraints or feasibility constraints.

Previous: What is ITIL?

Next: The ITIL Framework

Sunday, December 18, 2011

What is ITIL?

Well, ITIL is a Certification that is for the IT Service Industry. At a high level, it is a framework for delivering high quality IT Services. According to the official ITIL Website, the definition for ITIL is:
"ITIL is the most widely adopted approach for IT Service Management in the world. It provides a practical, no-nonsense framework for identifying, planning, delivering and supporting IT services to the business."

What are the benefits of ITIL?

Benefits of ITIL are two-fold and can be classified as following:
a. As an IT Service Providing Organization
b. As an IT Professional

As an IT Service Providing Organization:

Benefits of Adopting ITIL in an organization can result in:
• Improved/Better Quality IT services
• Lower costs
• Higher Customer Satisfaction
• Higher Productivity

Benefits of getting ITIL Certified as an IT Professional
• Signifies the fact that you know the standard approach to high quality IT Services
• Better Employment/Career Prospects
• Better Productivity
• Lastly, Better Salary!!!

More details on ITIL can be found below:

ITIL – Wikipedia Link: Click Here

Official ITIL Website: Click Here

Next: Introduction to Service Management

ShareThis

© 2013 by www.learnitilv3.blogspot.com. All rights reserved. No part of this blog or its contents may be reproduced or transmitted in any form or by any means, electronic, mechanical, photocopying, recording, or otherwise, without prior written permission of the Author.

Followers

Popular Posts