In my ITIL consulting experience, though customer is a term we use more often than not, its the customer who somehow comes up as of the least thought of entities when it comes to processes and implementation. Now that happens because Organizational Change Management is looked at post the design of a solution or a strategy, which I am not sure is the right thing to do.
While any change in the processes or its execution is going to cause ripples in the way things have been working for and worked by customers (often called Users in some situations), it is important to have a selected group review and validate the plans in great detail. This helps any project team build up on customer confidence, take critical execution related feedback, and make amendments in time to ensure customer concerns. Makes the execution easy and adds to the chances of a successful implementation.
Arne Van Oosterom in his recent article on mycustomer.com has written about Customer Journey Experience and detailed out 10 essential elements of a Customer Journey Map. Read more of the article here.
- Context or Stakeholder map
- Customer Journey
- Moments of Truth
- Service Delivery
- Emotional Journey
- Improve and Innovate
In this article by Rob England he provides a point of view on the some not so desirable metrics for Service Desk and an approach towards a Balanced Scorecard. What I really admire about Rob’s approach is his different point of view on the usual norms and the way he would force you to validate your thinking and provide a different point of view.
In this article he has written about too much focus on Abandoned Calls undesirable. While it might be ok for an in-house service desk to not give too much focus on Abandoned Call Rate, more often than not SLAs which are written between third party/external service providers and customers have Abandoned Call Rate as an important statistic. This is something that is an indicator of the service to customers and drives customer satisfaction. Rob mentions that too much focus on ACR might force Service Desk agents to finish the calls in a rush, and a similar situation would occur with focus on AHT (Average Handle Time) for calls. I personally feel that these two metrics are an important indicator of the Service Desk quality and need to be measured. Some of the actions which need to be taken with these numbers going up could be
1. Identify a trend in Call Abandon Rate and staff Service Desk agents to handle those volumes (most call centers do that)
2. Identify agents which high AHT and identify reasons for high AHT. This might trigger a need for some training to be imparted to those agents
In my opinion, its not possible to reach a conclusion on these metrics unless a deeper analysis is done on them and over time a consistent performance should take these down the priority list.
A term mostly used either with printing or photography, but I use it to today in Not Just ITSM to link to two very different thoughts on CMS or Configuration Management System as most would know it!
In the latest DITY newsletter, Carlos Casanova has written about A-FIRM structure for CMS and mentions CMS as a successful IT System. A-FIRM stands for
A – Architect: Architect and map out your ascent before actually setting out on your climb. If you do not do this, you will be lucky to reach a base camp from where to launch your serious climb.
F – Federate: Determine which camps may already be well established along your climbing route and which you can leverage on your ascent. These are components that you must factor into your long-term solution and are vital to any success you achieve.
I – Integrate: You will not be able to carry all your supplies on your journey so seek out others who can provide insight and assistance. Be on the lookout for those who may have already succeeded in partial ascents and can work with you to reach the peak. There will be times where you will have to leverage these for short periods of time until you can find a more sustainable long-term solution to accomplish that portion of your climb.
Compared to Federated components, these components are ideally just short-term solutions. They may be able to mature into a long term-federated solution, or they will need to eventually be replaced by a different long-term solution.
The key is to recognize which of these two categories they fall into. Wrongly assess a short-tem stopgap measure as a long-term solution, and you may die on the mountain during your climb because of faulty or incomplete data provided by them.
R – Reconcile: This will likely be one of your most challenging tasks because you will undoubtedly face many situations where you need to make a critical decision armed with less-than-ideal data. These decisions will make or break your entire ascent. Choose the wrong data and your team dies on the climb; choose the right data and you have a chance to succeed. Notice that there are no guarantees of success even if you choose the correct data.
M – Merge: Over time, you will identify situations and groups that you can combine to provide more reliable data and/or support you on the next leg of your ascent. You need to carefully execute these mergers to ensure you do not negatively impact the value you are seeking to achieve. Eliminate the wrong data or people, and you endanger the entire mission. Do it properly and you reach the peak faster, with less risk and at a lower cost.
On the other hand, Rob England, the IT Skeptic writes at length about CMDB and CMS being an Industry created myth.
These two are masters of their trade, and have very different views on the same topic. In my limited experience with CMDB, I cannot help but agree with both of them right now. Also I feel that CMDB is a term that is very loosely used by many without realizing or knowing the content that should go in there… For a lot CMDB is the solution to all their problems, and now CMS is the solution to all their problems. I, however, think that CMS or CMDB being the solution to a problem is just a hypothesis, which needs to be proven right or wrong after the roll-out. Small or big, simple or complicated, CMDB or CMS, would NOT work, if one is not aware of what the objective of creating it is for the organization and what we want to achieve from it.
Rob England in a recent post brought up the topic of distinction between a Call and Incident in the ITIL V3 Books! I then went to the book and started reading through the IM Process and did not really find a classification there, which Rob also confirmed in his update on the post here.
Now if I look at it closely, ITIL V3 book in a way achnowledges that the source of an Incident can be more than one places, e.g. Event Management, Web Interface, User Phone Call, Email technical staff, but really does not talk about where a call or an event would become an Incident (Fig 4.2 in the Service Operations book)
In my experience with two IM Processes here is how it worked
1. The User Interfacing process was Call Management (based off IBM EOPs) and it determined where the call should go and be tracked. In case of an Incident, it would trigger an incident management process for service restoration and incident resolution, for the rest, it would either end at the Service Desk as a question which was answered or a first contact resolution or would trigger a request fulfillment process. This was based on IBM EOPs, which I felt were much more comprehensive and implementable than ITIL recommended processes.
2. Everything that comes to the Service Desk is a Service Management ticket, and becomes an incident ticket only when its determined that it is an interruption to service and has an SLA impact
In both the cases, there was a many to one relationship between the calls/SM tickets to Incidents… multiple calls could be logged or multiple SM tickets could be logged for the same issue if there were multiple users calling or logging tickets themselves using a web interface, however these tickets would be associated with one single master incident which would then be published and pursued for resolution and service restoration.
From an ITIL V3 perspective, I think one would have to leverage on the Event Management process to be able to log events and then classify them into Incidents, however leaves the How-To questions, and Service Requests aside, and does not tell how to deal with them.
Was reading through an interesting article by Stephen Hirsch from SAP Education… he in this article talks about building and maintaining ROI through performance management. What I like about this article is that it does not talk about typical performance management of an application or a system, but is talking about a whole cycle of organizational change management to ensuring that the organization achieves what it set itself up for through this change.
The phases that Stephen has stressed on are
- Change Management
- Assessment, Strategy and Development
- Knowledge Transfer
- Performance Management
My view on this
Knowledge transfer and Performance Management would be two very very important steps that would prove instrumental in the success of a project/organizational change!
Like Stephen also mentioned in the article that most users would rely on quicker methods to gain information and not the large documents or LMS modules post implementation, there is a requirement for consistent and crisp information flow and availability of that simple information to do the job well!!!
What is mentioned as performance management in this article is something that I percieve as process adoption… and without well built checks (not controls as yet) one would not know how well the organization is doing! Do going back to the Strategy and Development phase, one of the key things is to identify
- How do we know we are successful?
- What do we measure to substantiate the achievement of goals?
- What would be the error correction or process adoption plans in case of things not going as expected?
You can read the detailed article here (Requires registration).
Image source : End-user Performance : Building and Maintaining ROI article from SAP