Skip to main content

Anatomy of an XLA


That is not a typo!  Alan Nance of CitrusCollab recently spoke about The Anatomy of an XLA in an ITSM Academy webinar.  I learned that the days of SLAs are behind us and the future lies with digital experience and eXperience Level Agreements (XLA’s). 

If this is the first time you have heard of XLAs then this is a sticky-note moment.  

By that I mean; find a sticky note, write down today's date.  Now write down XLA.  Remember that this is the day that you heard it and you heard it here! 

XLAs are the foundation of a fresh and optimistic approach to managing the business of technology. Research for yourself and staff members. Learn and explore more about XLA’s!

A little history:
“Service Management exists to guarantee a valuable experience to customers and colleagues. Despite years of implementing best practices, the reputation of most technology departments is below par in the eyes of business leaders. Consider that 90% of CEOs feel they aren’t meeting their customer needs. 85% of CEOs don’t think technology is performing critical functions. One of the core reasons is that technology teams are often trapped into measuring output rather than outcome, and KPIs on activities rather than XPIs that guarantee experience.” LEAN stresses the voice of the customer, ITIL4 has a focus on co-creation of outcomes with the customer, and all best practices stress the importance of customer experience and customer satisfaction.  All of us know how important our customers are and yet our measurements do not align with their outcomes.  The internal siloed metrics of the past must go. Even Customer Satisfaction (CSAT) measurements of the past did not give us the real story.

XLAs go beyond tradition and beyond CSAT Scores.  Think about this idea for a moment and focus on “Shared Context”. Shared Context is a concept and principle that is POWERFUL.  When considering how to measure performance for the customer we as an industry must consider the shared context of the XLA with our customers, consumers and other stakeholders within the value stream.  It is only now that you can begin to realize the Dream-Discover-Design phases of XLA, and how these are supported by Ecosystems with automation. The link to business transformation is made through the Patterns-Possibilities and Pathways approach.  We must consider human-centric measurements and we as an industry should do so now.







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…