Skip to main content

Posts

Co-Creating Service – Customer and Provider Responsibilities

Best practice has proven that to be dynamic and to consistently meet changing business requirements, services must be co-created with our customers.  I learned in a recent ITIL 4 certification class titled Driving Stakeholder Value (DSV)  that providers will start with a stakeholder map and follow up with a customer journey map. If you are not yet familiar with Customer Journey Mapping, I strongly recommend learning about this critical skill needed to enable the co-creation of services.  Once you have a stakeholder map and have mapped the customer/user journey, you will need to identify the roles required. In our example below, we use the two roles of customer/consumer and service provider. Each of these, although not the only stakeholders involved, is critical to the success of co-creation.  Notice a relationship is being established via these responsibilities  Both the service provider and the consumer have responsibilities.  An IT service provider, for example, manages resource

Constructs of a “Service Relationship” – ITIL 4

Generally, when we think of “relationships” we immediately think of the people aspect.  In ITSM we are referring to the relationships between third-party vendors, suppliers, customers, and many other stakeholders necessary to deliver the optimum service. It is mandatory to be able to manage those relationships at the appropriate level. One way to understand the “organization and people” involved in those relationships is to understand the constructs of a “Service Relationship” .  ITIL provides us this model.  Starting from the bottom of the diagram and moving up, let's  discuss the critical elements   of a Service Relationship:  Resources – All resources including people, process, and technology. In ITIL terms that includes resources from all Four Dimensions: People and Organizations  Information and Technology Partners and Suppliers  Value Streams and Processes  Products – A configuration of resources provided by the service provider that are potentially valuable to their cus

Virtual Classroom Training Guide

I am  often asked for tips and tricks for virtual classroom success. The team at ITSM Academy has put together this guide for your viewing and downloading pleasure... I hope it helps (and that you get to use it soon!)   Download the .pdf

What's in Your Strategy?

One of the things we frequently hear from individuals who attend the advanced ITIL ®  4 classes such as High Velocity IT and Drive Stakeholder Value is how very different ITIL 4 is, and more specifically, how relevant it is to challenges currently facing organizations. So how can organizations leverage this guidance? They need a strategy. More specifically, they need a set of aligned strategies that are linked to the  organization’s overall objectives. According to  ITIL  4 ®  Digital and IT Strategy , this set of strategies includes: A  business strategy  – how an organization defines and achieves its purpose A  digital strategy  – a business strategy that is based all or in part on using digital technology An  IT strategy  – a technology strategy and corresponding architecture that supports the digital strategy; along with the back-office strategy and administrative elements of information technology (e.g., the data center and infrastructure) While seemingly separate and distinct, th

Effective and Efficient Incident Response – Rethinking the way YOU work!

Learn more about new ways to do work! Explore DevOps, ITIL, SRE, XLA’s and more ! Silos are not uncommon, but when you silo the service desk from second and third-tier support staff, you likely have a recipe for pain. An ineffective incident response system within the organization is painful and disrupts the entire organization, especially the customers. We must shift the way we think and work to stabilize and improve the situation. One organization felt that they had a grip on service desk and incident management, but they blamed the subject matter experts for breaches to Service Level Agreements . The blame game is always detrimental. Their process consisted of the service desk agents receiving the incident, performing the initial triage, and then forwarding it to the subject matter expert based on how they categorized the incident. Sound familiar? Sometimes we pass tickets to and fro, get everybody and their brother involved, wait on email responses, and create chaos that frustrat

Grilled Pizza, or How I Stopped Worrying and Learned to Love Continual Improvement

Originally posted on owlpoint.com  August 6, 2020, written by Greg Smith , Director of Service Delivery and Resident Pizza Maker at OwlPoint Like many others, I’ve recently taken up a few “COVID hobbies” to keep me occupied (and sane). After homebrewing a few gallons of root beer, I decided I needed a hobby that didn’t result in such large quantities of food that had to be consumed in a relatively short amount of time. After some thought, I landed on making pizza on the grill as my next hobby attempt. Though I’ve always liked cooking and grilling, I’d never made pizza from scratch before, let alone doing so on the grill. It seemed like it would be finicky and have plenty of opportunities to mess up. But I’ve heard that there’s no such thing as a bad pizza, so I ordered two cast iron skillets from Amazon and set about my new hobby. Normally, when I engage in something new, I research the entirety of Google for hints, tips and what to avoid. After spending a couple of nights researchi

ITIL® 4 and Site Reliability Engineering

Originally posted on owlpoint.com , August 11, 2020, and written by Mark Blanke , CEO of Owlpoint, and Chairman of The CIO Initiative One of the aspects of ITIL 4 that has impressed me the most is the integration and reference to so many other best practices and frameworks. One such reference is to Site Reliability Engineering aka SRE . SRE was originally developed by Google in the mid 2000s as a way of operating and administering productions system with a software development mindset. One of Google’s key drivers in building out SRE was to help bring developers and operations people together. Sounds like DevOps , right? In reality, they come from the same mindset, but there are key differences. Google only recently started sharing the SRE concepts. It was their secret sauce and a way to be far more effective in operating their systems and maintaining a highly reliable environment. However, over time, they realized that it would be better for them to share their methods, so the