It’s always fun to sit and talk with 2nd line support folks – the ones who actually understand the technological whatsits and thingamajigs that underpin all our IT services. And it’s especially enjoyable if done over a drink or two, and when you get them onto the general intelligence level of the users they support.
What I’ve come to realize is that many have difficulty separating the concepts of intelligence and technical knowledge. I guess it’s because they have technical skill and knowledge, AND are intelligent; therefore, they sometimes see those who do not have technical skill and knowledge as NOT being intelligent.
Knowledge management is playing an increasingly important part in the IT service management (ITSM) ecosystem, and in keeping businesses running. It encompasses everything from supercharging service desk agents, to facilitating end-user self-help, to providing the fuel required by new technologies such as artificial intelligence, machine learning, and chatbots.
ITIL describes knowledge management as the process responsible for sharing perspectives, ideas, experience, and information; and for ensuring that the right knowledge is available in the right place and at the right time. This knowledge sharing enables informed decisions, and improves operational efficiency by reducing the need to rediscover knowledge.
Oftentimes it’s the every day things I do in my life that teach me about service management. So let me tell you what happened this time. I had to pick up a friend from the airport. Rather than just turn up at the designated arrival time, I was smart and tracked the flight on the web. I saw that the plane took off and set off towards us, then I saw it turn around, clearly lining up to land back at the airport it had just left. Weird, I know.
So, to try and find out what was happening, I searched the web for any reported emergencies. Didn’t find anything about that flight, got distracted (inevitably) and came across a pilot’s mantra for behaviour when things go wrong: aviate, navigate, communicate. To be done, strictly in that order. That sounds like good common-sense behaviour for a pilot in a tricky situation:
DevOps? ITIL? DevOps versus ITIL? There’s still lots of talk around which approach companies should take. But thankfully, there’s a growing appreciation that both approaches have a part to play in better IT service delivery.
The DevOps movement is still only eight years old, and it’s sometimes hard to believe that it’s younger than the smartphone – iOS or Android – in your hand. The ITIL IT service management (ITSM) best practice framework is one of the granddaddies of IT management frameworks, dating back to 1989, with its most recent update published in 2011. But despite the closeness in time of DevOps’s creation and ITIL’s latest edition, and the fact that they’re both part of the same IT family tree, there are a number of obstacles to exploiting both.
If you’ve ever worked in a manufacturing environment, then you certainly know what Work In Progress (WIP) looks like: stacks of partially-completed products waiting for the busy staff’s attention.
Easy to see that those part-made things have already cost money: the investment can’t be recovered until the product is complete and can be delivered to the customer. The longer it waits (as WIP) to be worked on, the farther away the cost recovery, and hopefully profit, gets.