Skip to main content

Definitely Definitions

What is a Service? ITIL defines a Service as "a means of delivering value to customers by facilitating outcomes customers want to achieve without the ownership of specific costs and risks."  In other words, when we do something for another party that gives them something they need or creates value for them, we are providing a service. Customers/users want to enjoy the benefits of the services we provide but don’t want to take on the challenge of managing those items themselves, therefore we provide those items to them in the form of services. It is also important to differentiate between client-facing services that allow end users to do their work and internal technical services that enable those services to be delivered efficiently and effectively.

At a strategic level it is important to understand the concepts of services, customers, value, service providers and how organizations relate to them to help us define which services will be delivered and to whom they will be delivered to.  What we are going to discuss here is how to identify customers, their requirements and if there is an opportunity that we as a service provider can fulfill.  There are eight distinct steps that should be undertaken as part of portfolio management.

Step 1: Define the market and identify customers.   Are we a Type I, II, III type service provider? Which type of markets are we competing in and how will they be defined?  Industry specific, Geographical, Demographical or Corporate relationships.

Step 2: Understanding the customer For internal service providers this means understanding the overall business strategies.  For external service providers this means understanding why the customer needs the services they are purchasing.  With both we should understand in detail desired business outcomes, customer assets, constraints and how value will be perceived and measured.

Step 3: Quantify the outcomes Working with customers, clear and measurable outcomes which can be directly linked to the service must be defined, documented and agreed. An outcome based definition of the service ensures a strong business relationship with your customers.

Step 4: Classify and visualize the service. Each service in our portfolio is unique, however many of our services have similar characteristics and may share common resources and dependencies.  Classifying services and expressing them visually will allow us to identify if they are within the current perspective or if they represent a growth of the strategy.

Step 5: Understand the opportunities (market spaces). Aligning the service provides capabilities (strengths) with the requirements of the customer.

Step 6: Define services based on outcomes. Outcome based services ensure that service providers plan and execute all aspects of a service from the perspective of what is significant to the customer.  This approach ensures value creation for the customer and value capture for the service provider.

Step 7: Service models. These demonstrates how customer assets and service assets interact with each other to create value.  They should describe both the structure and dynamics of the service.

Step 8: Define service units and packages. A service package is a collection of two or more services that have been combined to offer a solution to specific customer need.  Service packages packages are made up of core, enabling and enhancing servises.

Comments

Popular posts from this blog

What is the difference between Process Owner, Process Manager and Process Practitioner?

I was recently asked to clarify the roles of the Process Owner, Process Manager and Process Practitioner and wanted to share this with you.

Roles and Responsibilities:
Process Owner – this individual is “Accountable” for the process. They are the goto person and represent this process across the entire organization. They will ensure that the process is clearly defined, designed and documented. They will ensure that the process has a set of Policies for governance.Example: The process owner for Incident management will ensure that all of the activities to Identify, Record, Categorize, Investigate, … all the way to closing the incident are defined and documented with clearly defined roles, responsibilities, handoffs, and deliverables. An example of a policy in could be… “All Incidents must be logged”. Policies are rules that govern the process. Process Owner ensures that all Process activities, (what to do), Procedures (details on how to perform the activity) and the policies (r…

How Does ITIL Help in the Management of the SDLC?

I was recently asked how ITIL helps in the management of the SDLC (Software Development Lifecycle).  Simply put... SDLC is a Lifecycle approach to produce the software or the "product".  ITIL is a Lifecycle approach that focuses on the "service".
I’ll start by reviewing both SDLC and ITIL Lifecycles and then summarize:
SDLC  -  The intent of an SDLC process is to help produce a product that is cost-efficient, effective and of high quality. Once an application is created, the SDLC maps the proper deployment of the software into the live environment. The SDLC methodology usually contains the following stages: Analysis (requirements and design), construction, testing, release and maintenance.  The focus here is on the Software.  Most organizations will use an Agile or Waterfall approach to implement the software through the Software Development Lifecycle.
ITIL  -  is a best practice for IT service management (ITSM) that focuses on aligning IT services with the needs …

Incidents when a Defect is Involved

Question: We currently track defects in a separate system than our ticket management system. With that said, my question is does anyone have suggestions and/or best practices on how to handle incidents when a defect is involved? Should the incident be closed since the defect is being worked on in another defect tracking system if it is noted in the incident ticket? I am considering creating an incident statuses of 'closed-unresolved' so the incident can still be reported on in our ticket management system but know it is being worked on/tracked in the defect system. With defects, it is possible that we may never work on them because they are very low priority and the impact is low to the user. However, in some cases a defect is being worked on. Should we create a problem ticket instead?
Thanks, René W.

Answer: RenĂ©. In ITIL, the activity you are describing is handled by the Problem Management process. ITIL does not use the term “defect” but it does use the term “known error” to…