Skip to main content

Service Offerings and Agreements

When we think about what services we are going to offer we immediately think of the Service Catalog.  We must also consider what agreements go along with the delivery of those services.  What levels of utility and warranty are going to be expected over the life of our services?   What about services that will be supplied by external service providers; who is going to manage those?  Let’s take a look at which ITSM processes we will need to engage to ensure that we are able to strategize, design, deliver and maintain services that will meet our customers’ needs over the lifetime of the services.

In Service Offerings and Agreements (SOA), we look at Service Portfolio Management (SPM), Financial Management (FM), Demand Management (DM) and Business Relationship Management (BRM).  These are all processes within the Strategy stage of the Lifecycle.  We also explore Service Catalog Management (SCM), Service Level Management (SLM) and Supplier Management (SM) processes within the Design stage of the Service Lifecycle. We are going to examine how these processes are integrated to ensure that we are able to deliver the right services at the appropriate levels of performance and within the defined budgets. Now there are additional processes engaged but we will limit our discussions to the processes mentioned earlier.

Let’s start with the Service Portfolio. It describes a provider’s services in terms of business value and is utilized to ensure that a service provider has the right mix of services to balance the investment in IT with the ability to meet business outcomes. It’s divided into three parts, the pipeline which represents future investment, and where BRM introduces the Service Level Requirements (SLR) which are utilized in the creation of the definition of the service and are used later in the Service Catalog (2nd part of the portfolio) to establish the Service Level Agreements (SLAs) defined by SLM.   SPM along with other stakeholders will make the strategic decision on when it is time to retire older or underutilized services which is the final and 3rd part of the Service Portfolio (Retired Services).  Of course, Financial Management for IT Services is engaged throughout to provide us with accurate financial data for our decision making.

Increasingly important in today’s complex environments is Supplier Management.  We find more and more of our services and supporting services are being supplied by external suppliers.  The purpose of Supplier Management is to ensure that our suppliers are being appropriately managed so that we are receiving value for our money and that suppliers are delivering quality IT services to the business.  These relationships must be managed and assure that contracts are defined to meet business needs and align and underpin targets established in our SLRs and SLAs in conjunction with SLM.  It is critically important that a Supplier Policy and a Supplier/Contract Management Information System be established to guarantee the success of this process.

If you would like to take a deeper dive and have a more in-depth discussion about how these best practice processes can enhance you and your organization's success in delivering and managing IT services, come join one of our SOA classes.  See you soon!


For more information on Service Offering and Agreements:  http://www.itsmacademy.com/itil-soa/

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…