Should we consider ITSM for polygamy?

11 Aug

ITSM (IT Service Management) has been enjoying the success of being a bachelor, groomed by various product vendors and attracted by customers. It has been a darling of customer success and customer support for a while.

Of late, many of the customers have started adopting it further and considering the customer interactions via different sources like Facebook, Twitter etc. Some vendors have been able to offer such features for their ITSM tools. However, I think that they are still transactional, not to ignore that significant data can be derived from it for different business purposes.

Considering the trends like Big Data, AI (Artificial Intelligence), IoT (Internet of Things) and AR (Augmented Reality) that are taking the world by storm, I think that ITSM is an ideal candidate to marry all these and preferably, at the same time.

Undoubtedly, the data the ITSM is churning these days, especially, when used by retailers is huge. It’s high time to leverage big data aspects for ITSM for speeding up the performance and yet, obviously leveraging analytical capabilities.

Marrying with AI will help ITSM to pro-actively generate incidents/Change requests etc while also offering the SMART solutions depending on the role, team, type, kind of incidents that the requesters has raised etc. Knowledge Management, one of the most critical, yet ignored modules can be heavily benefited by populating relevant knowledge articles using AI rules.

Do I really need to write about advantages of integrating ITSM with IoT? I had shared few thoughts on this couple of years ago.

AR, the products of which excite mostly the gamers is another prospect to get hitched by ITSM. Imagine logging in the issues, making changes and releasing the new versions of AR by integrating ITSM tightly with it. Since it is ‘augmented’ reality, I will leave it to the imagination of readers on what off-springs can be produced by coupling AI and ITSM.

Modern IT architects/integrators aka IT wedding planners can also suggest proposals for other suitable ITSM brides 🙂


The Paradox

1 May

According to a survey, less than 5% of all Information Technology spending is allocated to end-user support. Interestingly, support drives customer satisfaction for ALL of Information Technology. According to some findings published over internet, 84% people surveyed believe that Service Desk is most important for customer satisfaction!

Isn’t it strange? The above details that I’ve talked are about IT; however, I am sure that they could be in similar range for any support as well. The average cost of resolution per ticket for North America comes to about USD 22 for Level 1 Service Desk while it shoots up significantly to USD 471 if it is outsourced to a vendor to provide support! Indeed there are different metrics like agent utilization, average speed of answer, net first contact resolution rate etc that need to be considered as well.

As I have shared my thoughts in previous blogs, the maturity about Helpdesk or ITSM still seems to be low at customer end and we have observed that very few customers are ITSM-literate and know how to define the requirements towards it properly. Most of customers start stating that they would need basic features of Helpdesk to keep the costs low; not understanding long term aspects of how critical a Helpdesk is, or, not focusing on how issues/problems that are specific to their organization can be resolved by getting Helpdesk implemented properly. They tend to ignore a fact that Helpdesk is a medium between them (service/support provider) and the customers and they better ensure that they do a good job in having the best and optimal solution implemented.

Essentially, implementing a Helpdesk or ITSM is just setting up your first step towards right direction of enhancing productivity and cutting down costs. The further steps of customizing the solutions/features as per business requirements, ensuring best practices, deriving meaningful reports, analytics, providing historical details, impact analysis, projections etc form a core part of an effective and efficient Helpdesk/ITSM system. Sadly, seldom organizations look into these aspects and most of the ‘so called leaders’ seem to be interested only in boasting of how they could get Helpdesk implemented with the least cost, not realizing the long term implications or what critical data they would be missing. It is ironical that they seem to spend least on a system that would give them real time data and information to enhance and have greater customer satisfactions. Do you think if you were on the verge of making similar mistakes and/or have already done it? Do you need any help to get that sorted? You know how to reach out to us in that caseSmile

RIP ‘traditional’ ITSM

2 Mar

As I read the funny quote, “Growing old is mandatory, growing up is optional”, I couldn’t stop thinking about how ITSM (IT Service Management) market segment has evolved. It started as a tool to log or track issues and then gradually grew as Helpdesk (both Incident & Problem Management) only to accommodate Change, CMDB, Asset, Knowledge and Service Request Management tools later.

For years, this traditional solution sufficed, as many of the customers’ ITSM maturity level was not very great. My experience tells me that many of the early customers implemented ITSM just because someone they knew in IT suggested and (convinced even without understanding the requirements?) that it is a great tool. The standard ITSM was implemented by respective tool vendors/consultants and the customers were expected to use the tool depending on available features.

Even today, we have lot of product vendors offering ITSM solutions using the standard features that they have been developing and working right from version 1.0. Undoubtedly, they have introduced many new features; however, how many of them are “really” useful or leveraged by the customers? We predominantly find many customers face 2 types of fundamental challenges – defining Service Management requirements (note that I am not referring it as IT Service Management requirements) and using the solution effectively/efficiently post implementation. Most of them tend to just use the features offered by the ITSM products that they may have bought. I strongly believe that many customers still lack defining the Service Management requirements and envisaging tons of benefits that they would get otherwise. A few of the customers do not seem to be inclined to understand best practices or how the solutions can be implemented more effectively. Some customers, in order to save cost, tend to keep postponing implementing solutions only to find later that the delay causes them more costs. Indeed, they will define certain criteria, inputs and what they would expect post implementation; however, I think many critical information/details that the customers can derive and get benefited are left out, not discussed or perhaps not thought of either.

Some customers who were slightly better educated in ITSM or ITIL, came up with few critical data like measuring SLAs (Service Level Agreements), performance of support desk, ensured that customer details are available for support desk agents, linking the incident tickets with appropriate assets etc. They presumed that providing inputs and getting data about the above parameters would suffice to get the benefits post ITSM implementation. Well, this was ok when ITSM tool was in its infancy stage and when other tools like Change Management or CMDB were getting added as a part of ITSM suite. Not anymore.

Long live such traditional ITSM that does not offer value addition other than standard features that are available in most of the ITSM tools!

Today, the customers do not tend to buy just because you are selling ITSM solutions. They tend to understand if the solutions are worth the cost as several ITSM tools/products are available in the market. Most of the ITSM tools provide standard features and reports; hence the customers tend to explore what other benefits they can derive. They are trying to explore if they can find the losses they are making due to issues reported more than planned. They would like to know whether they need to spend their budget on training or make changes in the teams or approve leaves of support desk agents depending on the projected tickets etc. As you can note, merely managing services in IT (fundamental goal of ITSM) does not suffice. The tool now needs to be reasonably configurable and customizable AND domain agnostic, to be leveraged across industries – indeed, yet keeping the costs reasonable.

Sounds complicated or impossible? Should you not be able to find losses or ROI using the same tool rather than additional investment since it is in fact measuring the work done in the organization? Now, you are reading attentively, huh? I know what would be your next question – “Mr. (so called) expert, do you guys have such mechanisms/value additions to provide what other traditional ITSM tools aren’t offering?” The answer is “Yes!”

You may have to reach out to us to know why our response is a resounding “Yes” and why we are convinced that traditional ITSM is dead. The new Service (and Support) Management is the sure shot way to know how your organization is doing and can benefit significantly by its usage. Our team has worked hard to be “The choice” for our customers, rather than being a “Hobson’s choice”

Defining eStomism

2 Mar

These days, talking about religions seem to be back in fashion. Jains talk about Jainism, Buddhists talk about Buddhism and so do the rest of other religious people. Every other person seems to be inclined to prove how his/her religion is superior to other ones. We have read and known to what extremes people have created chaos under the guise of religion. I am not sure if all of them understand it religiously (pun intended) or do they seem to follow it blindly.

Interestingly, we too have a religion at eStomi and we follow only one religion – CUSTOMER. Call it simple eStomism or eStomism (eStomiServiceManagement). However, we have only 5 commandments that our team members follow –

  • Serve the customer with optimal solution
  • Ensure value additions with every deliverable to the customer
  • Trust thy team member
  • Keep learning and upgrading knowledge
  • Reduce turnaround time while maintaining/enhancing quality

Our team members are devotees of our customers. We do design/programming/development in the form of puja every day. We meet for our planning activities as a part of satsang at 10 AM. We have our daily checkpoints to ensure that our activities are on track at 2 PM in the form of namaz. We baptize our team members in the form of new technologies/aspects every Wed. We tend to hold team bonding activities every Friday in the form of carnival. Once in a while, we do the deployments/Go-Lives of our solutions in the form of yagna. Getting sign-off from our happy customers is like getting prasadam towards our dedicated efforts. Do we fight? You bet we do. We fight to ensure that we do not compromise on quality. Don’t we kill? We kill defects/bugs identified in our solutions. Hell, we preach as well! We preach best practices.

We at eStomi have set of doctrines taught to all our team members – “Don’t be a termite, be an eStomite. Make mistakes, learn from them and learn very quickly. Try, fail, get up and explore how we can be more productive, how we can be the game changers, how we can be THE GOTO team, how we can do value additions to our customers… Cultivate eStomism” ! Well, we believe in getting our customers eStomied.

What to do on all other days?

2 Mar

Charlie Brown in Peanuts cartoon: “Someday, we will die, Snoopy.”

Snoopy: “True, but on all other days, we will not.”

As simple as it may appear, the response seems to be profound and something which most of us take it as granted. Do we really think of doing something great, something different, every day when we get up and realize that we are alive?

News media, these days, seem to be creating enough negativity by showing the news that can generate more TRP rather than bringing out more good, genuine and inspirational news. Obviously, the moment you read newspapers daily, the first thought is – “How I can survive in this world today?”, “How am I going to tackle today’s problems and issues – be it at office or household?” By the time we solve some issues (if at all) the issues for that day, we tend to convince ourselves that we have done a great job, accomplished something and have a right to feel tired! The moment we fool ourselves of this last bit – so called “tiredness”, we are ready to procrastinate rest of the activities easily. Facebook, WhatsApp (as if we spend less time on Facebook and WhatsApp throughout the day) or TV (or these days, YouTube videos) get lined up to “relax” (or should I say for further wastage of time?). I don’t mean to say that Facebook or WhatsApp are totally useless. However, the wastage of time on the name of its “usage” is what I think is overlooked.

Well, you get the point, right? The question to be solved on the table is how do we get less distracted, reduce wastage of time and use the tools more effectively.

Thankfully, we seem to have lesser of such challenges this year. The answer perhaps to this, is in our team engagement. Our second layer of leadership seems to be ready to take up new challenges. This year, we have planned to increase the team size significantly. We have strategized a few different initiatives that can be taken up by associate team members with the mentoring of senior players. We do not want to call it as Version 3.0 of eStomi though. Cross pollinating our team members with different technologies continue and so do our efforts to develop their personalities to take up consulting in a more effective way.

We seem to have been decently positioned in ITSM market having bagged few long term projects. As you are aware, since last year, we have also increased the number of tools on which we provide consulting. Thankfully, most of the new customers that we get on board seem to have new and different requirements/challenges that help us to understand the trend in a better way, keeps us on our toes and question of distraction or time wastage seldom occurs to us as our engagement velocity is quite high.

Back to the question for less distraction, we can suggest few pointers based on our experience and what we usually do to tackle it –

  • Define the activities EVERYDAY and track them to completion. This seems easier said than done. This actually sets a culture in the team of taking an ownership of tasks and completing them. Earlier, the frequency was a weekly one; however, we realized that tracking it daily helps to action it out faster and reduce delays.
  • SHARE the new learning, designs, mistakes regularly with other team members so that they can learn or adapt as much as possible. This is similar to ‘Defect Prevention’ exercise carried out in 5th Level of CMM model.
  • CREATE a flat model as much as possible to pass a message that senior people may not be right all the time. Encourage junior people to come out with their new ideas/design rather than relying on the existing ones. Building team and convincing everybody that team work is better than individual takes time due to egos and different personalities.
  • Ensure LEARNING CURVE is steep and exceptional by getting the team exposed not only to new technologies but also on different topics or discussions regularly.
  • EVALUATE frequently if the team members are on right track of their career paths as well as aligned to the objectives laid by the organization. Ensure to take steps by providing feedback and get them onto the track by discussing on the road map.

Well, this may or may not be all the pointers; however, they have been useful for us. Have you derived how would you reduce time wastage and ensure more effectiveness, how do you plan to lead 2016 better than earlier years?

Do not Forgo, Go for it

2 Mar

Last week, I got 7 calls in a span of 5 minutes asking me to call back immediately as there was a Severity 1 issue raised by one of our customer’s end customer. I was in a middle of another important meeting and couldn’t respond. After my meeting, I called up to enquire what the issue was and I was asked to consider it as the highest priority and help get it resolved. Since I was not able to access my emails, I called up one of my colleagues requesting her to look into the issue and resolve accordingly. The issue had been raised for about 3 hours and nobody had bothered to even read the end customer’s mail to check what the issue was. The favorite corporate attitude ‘pass the buck’ was very evident. Since we have partnered with our customer to serve some of their end customers, they thought it is easier to put it on us and let the end customer know that experts are working on it.

Our L2 colleague hardly took less than 15 mins to identify that it was not even an issue, let alone it was raised as Severity 1 issue! The end customer had seen a screen, assumed certain things and without even getting clarified, had raised a Severity 1 issue.

I’ve seen this growing trend amongst few to run away from the issues even before trying to understand them. Most of them seem to have a feeling that they would be considered below par if the issue does not get resolved by them. I think that since such people keep running away from every such situation, they do not learn and tend to remain below par. They find it more lucrative to identify someone who can take responsibility to resolve the issue. Guess what? That lot of ‘someone who takes the responsibility’ keeps learning and growing and the cycle continues. Here are few tips that I can share based on my experience –

  • Acknowledge that there has been an issue and that if someone has reached out to you, that means they have some hope and entrusted you to at least look into the issue.
  • Many times, the issue is usually blown up (like the above incident that I explained). Do not tend to take a stance or assume that you may not be able to resolve it even before looking into the issue.
  • Most of the times, the issue would’ve already been resolved by someone, somewhere in the world. You may have to find out those steps/solutions in case if your skills are limited.
  • There is usually a tendency to start getting into a blame game and assume that you’ve been framed, or the issue has been assigned to you intentionally. Such things seldom help to learn or resolve the issues. Get over such negative thoughts and focus on understanding the issue and identifying the solution/cause. Discuss it with your team members and I’ll not be surprised that you get the solution, almost every time.

I can summarize the above tips into one – Do not forgo, go for it.smiley

Apprehension of comprehension !

24 Nov

“How do we identify which tool do we need to work on?” asked a participant in a panel discussion on automation. I think same question; however, in different styles was asked at least 4-5 times. It was interesting to note that question, not because it seemed ‘great question’, but I couldn’t figure out why this question was being asked. Fundamentally, it seemed like the person who is asking this question must know the answer. Have you come across a fruit vendor asking you to buy an apple without even checking if you need an apple or an orange! So, should it not be that the tool / technology / approach /architecture / design / best practices etc be derived based on customer requirements?

I am sure most of you all (especially in IT) must’ve come across the popular cartoon strip where in the sales person has convinced customer that he will deliver a palace whereas the requirement was a simple house and finally, the customer gets delivered a hut ! How many times do we genuinely try to even understand what the customer requires? It is nothing to do with automation alone. This is a question that most of the people seem to ‘presume’ that they’ve understood the requirements depending on ‘their’ experience. As David Murray explains in his book ‘Plan B’, we are taught to look out for solutions, we are seldom taught to understand the problems in the first place. Then there are some folks, who try to thrust with IT tools that they’ve worked earlier and which ‘they’ are ‘comfortable’ with. Do they even try to understand if those tools will help the customer solve the problem? Take for example that there is a requirement to implement a helpdesk. The solution is not to sell BMC Remedy or OTRS or ServiceNow just because they are used widely or that one is familiar with. One needs to first understand the needs, budget, environment and long term aspects of the customer. Often, it is either IT driven (traditional approach) or business driven (so called, agile approach). If there is no value addition to the customer by implementing (either the feature or the entire system), let’s not do it.

We’ve come across some set of customers who really understand and are crystal clear on the requirements. Most importantly, they would’ve already derived benefits of getting the system implemented. I must admit that even as practitioners, we’ve learned from such implementations and realized how such things help add value. There are many customers who would seldom be clear on requirements. It is not surprising to us anymore that they take more than several weeks to even answer the queries that we would’ve asked them for seeking clarity on the requirements that they had defined! Our first exercise when we get customer requirements is to review it carefully, comprehend and seek clarity on all requirements. The second activity (post estimating efforts) is to share what they would get as a part of deliverables or post implementation. We tend to take them through the exercise, demos and discussions so that they the expected system, not surprises. Despite this, I admit that some customers tend to squeeze last drop of the oil and ask for more features to be delivered within the same timelines. However, since we now have set a practice to get most of the requirements clarified and verify that there is a value addition; we’ve enhanced our chances of successful implementations. Have you overcome ways such of your apprehensions? Share or comment, if so pls.