In this episode we discuss service management in general and SeviceNow in particular with our guest Steve Nixon.
In this episode, Steve Nixon delves into the intricacies of ServiceNow, a pivotal tool in service management, emphasizing its alignment with ITIL practices and its vital role in modern IT operations. He explains how ServiceNow facilitates incident, problem, and change management, and its adaptability in handling DevOps and Agile methodologies. Nixon highlights the platform’s ability to integrate with various tools like Jira, enhancing operational efficiency. The discussion also covers the challenges and solutions in maintaining service operations and the evolving landscape of IT service management.
Inhalt
- Steve Nixon’s Background and Role
- Defining DevOps and Its Evolution
- ServiceNow’s Role in Service Management
- Challenges in DevOps and Service Management Integration
- Handling Incident, Problem, and Change Management
- ServiceNow’s Adaptability with Agile and DevOps
- Integration with Other Tools (e.g., Jira, Dynatrace)
- ServiceNow and ITIL Framework Compatibility
- The Future of IT Service Management and DevOps
- Closing Remarks and Contacts
Shownotes
Steve’s LinkedIn: https://www.linkedin.com/in/steve-nixon-9a24b3/
ServiceNow: https://www.servicenow.com/
Transkript (automatisiert erstellt, wer Fehler findet darf sie behalten)
Welcome to a new episode of DevOps auf die Ohren und ins Hirn, or in English, DevOps
from your ears straight to your brain.
Usually, this is a German-language podcast, but we sometimes make exceptions for international
guests.
Today is one such exception.
My name is Luca Ingianni, and I host this podcast together with my colleagues Dierk Söllner
and Falko Werner.
We are DevOps consultants, trainers, and coaches trying to get teams to work together better
and create better products for their customers.
Today, it’ll be Falco and me running the episode, and we are joined by Steve Nixon to talk to
us about ServiceNow.
Hi, Steve.
Very welcome to the show.
Hi there.
Thanks for having me.
Steve, who are you anyway?
So, I run as Head of Service Management, or Head of Service Operations.
So, I’m the guy who takes the incidents, the changes, the problems, and sees those
through, and DevOps people are usually my third line.
So, we have a first line, which is the help desk.
We have a second line, which takes scripts and generally works things.
And then we have the third line, which is support teams and stuff that’s going to take
a bit more in-depth knowledge and a bit more time to fix.
Which brings us to another fun question that we ask every guest who shows up on the show.
Steve, please tell us, what is your definition of DevOps?
So, DevOps to me, traditionally, we’ve had app dev teams.
Application development teams that are put together, they develop a product, they throw
it over the wall to support, and they disappear and disband and become somebody else again.
In this modern world, development doesn’t tend to finish.
We don’t do a lot of waterfall-type projects that finish and never update ever again.
We’re much more web-based, so development is agile, it’s ongoing, and the development
team…
becomes the operations team.
So, when something goes wrong with it, we phone the actual development team.
And because they’ve got the insight and the knowledge on how it’s built, they know how
to fix it, which is a lot easier than the app dev team that we used to deal with, which
are usually just given a huge load of documentation by the dev team, which may be very incomplete
and are left to just support the thing and usually can’t reach a developer because he’s
disappeared off to another project.
And how does it work for you?
Is it better than before or worse?
It’s better from my perspective.
When we reach out to people, to teams, and need them to join a call, the in-depth knowledge
that the development team brings to the incident generally resolves it quicker.
Where we do hit issues is where the development team have gone…
from a development with an app support team to a devops team.
They don’t necessarily realize that they’re going to get called at two o’clock in the morning
to fix an incident, and management aren’t very good at explaining this until it actually
happens.
They hand over their phone number freely until they get called, right?
Well, yes, and that’s part of being a third-line support team.
You have a designated person on call.
But it just doesn’t seem to register to people that on call means you’re going to get called
at some point.
Yeah, well, I mean, it is surprising, isn’t it?
You get told you’re on call and then people call you.
Yeah, well, the way that a lot of devops teams work in the organizations I’ve worked, they’ll
have a development team and then they’ll have a rotating area of support people.
So they’ve got a queue of incidents that my guys are sending them.
Those need fixing.
The customers need updating.
It’s not usually the most glamorous piece of work.
So they don’t generally allocate people to it full time, but they’ll have people switch
in to it.
So when they say they’re on call, they expect that that means we’ll get, if something goes
wrong during the day, we’ll be called into the bridge.
Yeah.
We’ll have to deal with it.
But sometimes we have the bridge at two o’clock in the morning because these apps on the web
are 24 seven.
And, you know, the organizations I’ve worked at are international organizations and there’s
people using them all the time.
So when they break, I get a phone call at two o’clock in the morning.
My team get on bridges at two o’clock in the morning.
We pull in who we need to fix it.
But wouldn’t it in that case also make sense to have a distributed support team so that
nobody gets called at two AM because it’s always like, uh, three in the afternoon someplace.
To a, to an extent.
I mean, I’ve worked in organizations that have people in Singapore, UK and America.
But what tends to happen is that they’re localized to their markets.
Um, cost saving initiatives generally put service management in one place.
How often does it happen that you need to resort to third line?
And support in the first case, do you escalate, I guess you’d not escalating anything because
then you’d just be a glorified like phone answering machine.
Um, but who gets to make that decision?
How is it made?
Um, how do you maybe talk about that afterwards?
Yes, that’s, that’s a reasonable question.
I mean, we have, um, service operations processes.
Generally, we want to fix as many things as we can at first line because we’ve got the
user on the phone.
They’ve.
They’ve got the problem.
If our staff can pick up the procedures, do whatever they need to do on the system and
get that user back up and running, that’s great.
Um, if it’s going to take a little bit more than they can or a little bit more in depth
or the, the manual, and I’m not joking here, the manual might be 80 pages long.
Um, we’ll hand that off to level two, which again falls in my remit.
It’s a team of people usually siloed across desktop network, telephony, data center, probably
a team specific to email.
Um, and they’ve got a lot more in depth, you know, specialist knowledge of those systems.
Um, so the call will go to them, but the user won’t, the user will be taken off the call
and told to expect a call back.
Um, and we’ve got SLAs around.
Those pieces that say that they’ve got to pick that call up from the queue within a
certain period of time.
They’ve got to put an update on the system.
Um, and they’ve got to get back in touch with the user in some way to give them an update
on what they’re doing.
Um, now as to the rough numbers, we try to fix around 60 to 80% of calls at first and
second line.
Um, depending on the organization.
Depending on the processes that we have, we try to fix the majority at first line,
but in a real world scenario, we probably get 50, 60% at first line.
Forgotten passwords and the like, I guess.
We’re trying to get away from password resets altogether, to be honest.
Um, yeah, fair enough.
The last three organizations I’ve worked at have had more and more, um, sort of secure
and robust methods of.
Yeah.
Self-service password reset.
And actually one of the things that the pandemic has achieved for us is the understanding
of people having two-factor authentication, um, self-service password reset has become
the norm.
We’re using mobile devices a lot more than we were.
Um, you know, every organization I’ve worked at used to be primarily desktop based.
It’s now primarily laptop based.
And that thought.
Along with the ubiquitous of mobile phones that goes along with it has generally taken
password resets out of the equation.
So, you know, it used to be 45% easily of the amount of calls that my help desk would get.
And the last place that I worked, we were down to eight or 9% a week were password resets.
So those eight or 9% were, were the, the complicated cases where the,
the self-service just broke down for some reason, right?
It was usually because the two-factor authentication got out of sync.
So actually we’re naming this podcast session, something about service now, where does that
fit in?
So service now is the management software that we use within service operations.
Um,
um,
um,
um,
um,
um,
um,
um,
um,
um,
um,
um,
um,
um,
um,
um,
um,
um,
um,
um,
um,
um,
um,
um,
um,
um,
um,
um,
um,
um,
um,
um,
um,
um,
um,
um,
um,
um,
um,
um,
um,
um,
um,
Zendesk, es könnte etwas sein, das sie intern gemacht haben, HP macht einen, es gibt viele von ihnen, aber ServiceNow ist auf jeden Fall der größte.
Und es ist auch nicht wirklich aus dem Versuch, etwas anderes zu sein, es wurde von der Grunde her gebaut, um ein Service-Management-System zu sein.
Oder wir haben, und was wir preferieren, ist, dass wenn man auf die interne Website geht,
wird da ein Button da sein, das sagt Login-Incident, und sie können da gehen und sie können nur ein paar Dinge über ihre Sachen schreiben.
Es werden Dropdowns geben, die sie ein bisschen mehr targetiert machen können, weil wir Freetext-Feels nicht mögen,
weil die User alle Art von Dingen schreiben werden.
Die Anzahl der Leute, die Probleme mit ihrem Monitor haben, wenn ihr PC nicht aufhört, ist sehr groß.
Also kriegen wir…
Ja, wir geben ihnen Dropdowns, wir geben ihnen Formen, die sie in die richtige Richtung führen,
und wenn jemand das inschreibt, wird das automatisch zu dem Team zurückgehen, das es am besten handeln muss.
Und das ist, warum wir diese Dinge benutzen.
Wenn ich zurückgehe zu den frühen Tagen in meiner Karriere,
alles ging auf die Helpdesk, und die Helpdesk logierte es manuell.
Das erste System, das ich jemals gearbeitet habe, war basiert auf einem
Mainframe, also mussten wir alle Green Screen Emulators benutzen, um auf den Mainframe zu loggen und die Tickets aufzunehmen.
Und es gab keine Dropdowns, es war alles Freetext, und die Helpdesk machte ihr Bestes, um die Informationen reinzunehmen,
und dann würde es auf die einzelne zweite Linie der Unterstützungsteam gehen, wo ich meine Karriere begonnen habe.
Und dann würden wir es aufnehmen und wir distribuierten es zwischen den paar Leuten, die wir in der Office hatten,
die verschiedene Spezialitäten hatten.
Und dann, wenn wir es brauchten,
gingen wir zu einer dritten Linie der Unterstützungsteam, einer App-Team,
und wir gingen literally nach unten mit der Anrufung und gingen mit ihnen sitzen und versuchen,
was da los war, und dann kamen wir zurück zum Benutzer.
Als die Dinge erhöht wurden und die Dinge ein bisschen mehr automatisch wurden,
macht ServiceNow viel davon, dass ein richtig formattierter Ticket mit der richtigen Informationen in ihm
zu einem von mehreren hundert Resolver-Gruppen korrekt gesendet kann.
So dass er nicht über die Systeme gespeichert werden muss, und das bekommt der Benutzer schneller gespeichert, was wir hier alles umfasst sind.
Es klingt also so, als wäre ServiceNow nur ein normaler Issue-Tracker, ein normaler Backtracker, nicht wahr?
Das ist also die Insidenz-Gruppe. Es trackt auch Problem-Tickets. Für diejenigen, die es nicht kennen, ist eine Insidenz etwas, was falsch ist.
Man kann nicht auf dein E-Mail loggen.
Dein PC fängt nicht an zu booten.
Dein Browser fängt an zu crashen.
Es macht dir ein echtes Problem, da und dann.
Ein Problem-Ticket ist etwas, das wahrscheinlich eine größere Anzahl von Leuten beeinflusst,
aber es schafft nicht, dass sie in ihrem Job nicht mehr arbeiten.
Wir haben wahrscheinlich einen Workaround, oder wir haben einen Patch im System,
den wir in der IT kennen, das ist keine gute Idee, aber es macht die Dinge funktionieren, damit das Geschäft weitergehen kann.
Also haben wir ein Problem-Ticket, um daran zu arbeiten.
Das dritte, was ServiceManagement-Tools tun, und ServiceNow im Wesentlichen, ist Veränderungsmanagement.
Alles in der Organisation muss kontrolliert werden, wo es Veränderungen gibt.
Wir bekommen Veränderungen aus dem Hintergrund von Problem-Tickets.
Die meisten Sachen, über die wir gesprochen haben, sind user-relevant.
Aber wenn wir ein ganzes System aufbauen, dann gibt es wahrscheinlich einen Patch dazu.
Oder es gibt einen Reboot des Systems.
Oder es gibt einen Reboot des Systems.
Oder es gibt einen Reboot des Systems.
Oder es gibt einen Reboot des Systems.
Oder es gibt einen Clickdown, die Veränderung der Rát
Es muss alles secret gespeichert und überprüft werden, bis die Unternehmen mit Fehlverordnung
sicher sind von dem, was wir tun.
ServiceManagement automatisiert all das.
weil sie ein Upstream-System haben, das intern ausgebildete E-Mails sendet.
Man muss einfach die Leute kennen lassen.
Und das ist das, was das Modul für Veränderungen macht.
Wenn man die Systeme einlädt,
hat man automatische Anschlüsse darauf, wer sich beeinflusst.
Und sie bekommen automatische E-Mails.
Und wo es notwendig ist, bekommen sie Anerkennungse-E-Mails.
Und der Veränderung geht nicht weiter,
bis man von allen hat, die es beurteilen müssen.
Das bedeutet einfach, dass alle informiert sind.
Und das andere, was es tut,
und nicht jede Organisation hat das noch nicht implementiert,
weil es ein großes Werkzeug ist,
aber es hat ein Konfigurations-System darin.
Und das verbindet sich in alle anderen Teile,
der Veränderung, der Problem, der Veränderung.
Also im Konfigurations-Management
trackst du nicht nur deine Hardware.
Du trackst die Netzwerke,
die mit den Systemen verbunden sind.
Du trackst die Applikationen, die darin sind.
Dann trackst du deine Bezeichnungsinformationen
zu diesen Applikationen.
Und wenn du die ganze Sache ausgebaut hast,
und es ist kein einfaches Job,
aber wenn es ausgebaut ist,
kannst du ein System auswählen
und all die Abstands- und Abstandsabhängigkeiten davon schauen.
Du kannst total kontrollieren,
was auf dieser Maschine läuft,
was auf der anderen Maschine läuft.
Welche Teams müssen beurteilt werden,
wenn etwas gebootet wird,
oder gepatcht oder geupgradiert wird.
Und das ganze Ganze kommt wieder rein.
Wenn du also einen Unfall auf etwas erzeugst,
hast du die richtigen Resolver-Teams
automatisch geupdatet.
Wenn du ein Veränderungs-Ticket erzeugst,
hast du die richtigen Support-Teams
und die richtigen Business-Teams automatisch geupdatet.
Und das macht unsere Leben einfach viel einfacher.
Wie wird das mit cloud-basierten Systemen verbunden?
Wie mit skalierbaren, container-basierten Systemen?
ServiceNow folgt einer Infrastruktur,
ich versuche, die richtigen Wörter zu finden,
einer Prozesse, die ITIL heißt.
ITIL hat verschiedene Iterationen durchgeführt.
Wir sind jetzt bei ITIL 2.0.
ITIL Version 4.
Und ServiceNow hat geupgradiert,
als ITIL gekommen ist.
ITIL Version 4 gibt spezifisch Prozesse
und Wege, um mit Cloud zu handeln.
Wir haben mit ITIL Version 3 angefangen,
mit Virtualisierung.
Du hättest also eine Maschine,
und dort hättest du 200 VMs.
Und innerhalb der Config-Management-Database
hättest du die Möglichkeit,
die VMs an einem bestimmten Zeitpunkt zurückzuholen.
Sie arbeiten mit den Verbrauchern,
um sicherzustellen, dass, wenn VMs für Load-Balancing umgehen,
alles in der Config-Management-Database geupdatet wird.
Als sie in Cloud-basiert sind,
dauerte es eine Weile, bis ITIL Version 4 aufgekommen ist
und Prozesse umgesetzt wurde.
Aber ServiceManagement-Tools,
ServiceNow im Wesentlichen,
haben Module, die in die Hauptplattform hüpfen.
Google, Azure, Amazon.
Wir können in ihre Management-Console hüpfen
und die Informationen zurückbekommen,
die wir brauchen.
Die Informationen, die wir von dort bekommen,
sind bemerkenswert.
Du wirst nicht wissen,
welches Prozessor es läuft,
welche Erinnerung es läuft.
All diese Sachen.
Wir haben keine Ahnung,
um ehrlich zu sein.
Wir behandeln sie nur als Virtual Machines.
Und wir haben bereits Wege,
mit Virtual Machines zu handeln,
auch wenn sie im On-Premium sind.
Wir sind jetzt nur in der Cloud.
Und in ServiceManagement
liaisieren wir mit den Cloud-Providern
extrem nahe.
Also, wenn sie irgendwelche
Backend-Infrastruktur-Upgrades machen,
werden sie uns wissen,
es sollte nachhaltig sein.
Sie sollten Load-Balance
über die Dinge,
die sie nicht updaten.
Aber sie lassen uns sowieso wissen.
So haben wir,
wenn etwas um 3 Uhr morgens kommt,
eine sehr gute Idee,
warum.
Das klingt sehr interessant.
Ich war nicht sicher,
dass es so viele
Verbindungen gibt
zu den verschiedenen Cloud-Providern
und direkt
diese zu Service-Management-Systemen
hüpfen können,
in dem Fall,
was wir hier über Service-Now sprechen.
Es ist also gut,
das zu hören und
versuchen zu verstehen,
was die Vorteile sind.
Es kann noch besser werden.
Eine der Firmen,
mit denen ich ein paar Mal gearbeitet habe,
ist eine Firma namens Dynatrace.
Aber es gibt auch andere Firmen,
die ähnlich machen.
Sie können dir
eine holistische Sicht
deines App-Stacks zeigen.
Es ist egal,
ob es Cloud, Container,
virtuell oder physisch ist.
Es gibt einfach
kleine Teile des Codes,
die in den Code
eingebunden werden.
Du arbeitest mit den Dev-Teams,
um das einzusetzen.
Und das ganze
hüpft zurück.
Das Dynatrace-Modul
monitoriert
den Traffic,
der zwischen den Dingen
geht,
alle Verbindungen
zwischen
Applikationen.
Es weiß,
was normal ist.
Deshalb kann es
Abnormalitäten beurteilen.
Und Dynatrace kann automatisch
die Tickets in ServiceNow
aufbauen,
um sie zu den Teams zu bringen,
oft bevor sie realisieren,
dass es ein Problem gibt.
Das klingt wie Magie.
Es ist teure Magie.
Aber es ist.
Es ist Magie.
Ist Magie immer teuer?
Du musst etwas bezahlen.
Entweder musst du studieren
und es in Hogwarts lernen,
oder du musst
die Wunde kaufen.
Und diese Zeit,
ja,
ist Dynatrace
eine
IT-Magie-Wunde.
Ja,
tatsächlich.
Wenn ich
über
Servicemanagement
denke,
hast du
über
Helpdesk
gesprochen
und
mehrere
Niveaus
der Unterstützung
ähm
Problem
und
Incident-Management
und
Change-Management
und
Configuration-Management
um
wie
ähm
Availability-Management ähm
ähm
Dinge wie äh
Kapazitätsmanagement und ähm
Ähm
Verbesserung
Teil davon
es ist
es ist alles
in der Art
der Art der Service
jetzt funktioniert
es gibt Module für
all diese Dinge
es ist einfach
abhängig, wo eine
Firma ist
auf ihrer Reise durch
Servicemanagement
in Bezug auf
wo diese Dinge sind
es dauert
eine sehr lange Zeit
und viel Arbeit
um Konfigurationen zu erstellen
um Konfigurationen zu erstellen
der nächste offizielle Schritt danach ist
Lizenzmanagement
auf der Rückseite
kann man
Availability-Management bekommen
Kapazitätsmanagement
tendiert
parallel
an einem bestimmten Punkt
zu laufen
ich habe
ähm
meinen ersten
echten
Kontraktjob
lange
zurück
in
ich weiß nicht
2007
war eine
Kapazitätsmanagement-Rolle
Kapazitätsmanagement für
eine
Bankenorganisation
und
wir haben das
ziemlich manuell gemacht
wir mussten
die Konfigurations-Management-Sache
immer noch bauen
aber es war
sehr
grundlegend
wir konzentrierten uns
auf Server
nicht auf Desktop
und wir haben nur
die Informationen
die wir brauchten
aber auf der Rückseite
dieser
Arbeit
sahen die Teams
mit denen wir
gearbeitet haben
den Vorteil davon
und diese Organisation
ging auf
eine volle
CMDB
und als ich
weggegangen bin
machten sie
das ganze
ein
Baublock
das eine
das
scheint
im Moment
die Bewegung
von
Change Management
zu
Release Management
viele
Dev-Teams
hüpfen
in
deine
DevOps-Konversation
ich glaube
das
das
Hauptproblem
mit
Dev-Teams
ist
dass sie
versuchen
den
Change-Management-Prozess
zu vermeiden
und das
ist
eine
typische Organisation
die
erwartet,
dass du
deinen
Veränderung
ein paar Tage
vor dem
Zeitpunkt
erwartet wirst
du erwarten,
dass du
es
erwartest
es wird
eine
Anzahl von
Anleitungen
spezifisch
zu dieser Veränderung
und
es wird
generell
ein Veränderungs-Board
sitzen
und durch diese Veränderungen
wird es
nicht möglich
dass
du
den
Veränderungs-Board
auf
einer
Anleitung
auf
einer
Anleitung
auf
einer
Anleitung
ein
Veränderungs-Board
auf
einer
Anleitung
auf
einer
Anleitung
auf
einer
Anleitung
auf
einer Anleitung
auf
einer Anleitung
unter
einer hardened
ist
ich
Consumer
Services
uschrift
das habe
situations
wagen
wahnsinnig
enrichiert
ähnliche
alerts
die
er
er
Albs
die
solche
die
sociale
jetzt
degree of flexibility in a rigorous change management process so in
organizations that are doing that service now has a module that does
release management and there you can put in standard releases standard things
that are going to be done and get pre approval you can get a schedule and
understanding and the system will know when these things are going on and alert
accordingly if anything goes wrong but they don’t have to go through the
formality of a change management process and a change board which you know we’ve
had a joke within service management for years dev teams calling themselves agile
just means they want to avoid the change management process they just carry on
working exactly the same as they were but you know now they’re agile they
don’t need to do change management okay but then in fact they do right of course
you’re right but then in fact they do right of course
they have to do it in somehow in some way the worst thing that they can get is
being called it to ignite yeah well it this this organization I worked at a few
years ago that was very very web-based major website that’s where all the
traffic was driven through they they did one of these release without change
management processes just a simple change and they in in the process they
excluded ie6 from working because they
they’ve done all their due diligence there was less than two percent of their
user base across thousands and thousands of hits that were using ie6 so so well
we’ll just take the hit on them they could see from their data that they
weren’t actually generating a lot of sales they were just doing searches and
utilizing the system because they hadn’t informed us and we didn’t have a change
management board and we didn’t listen to them and talk to the others
What they didn’t realize was that 2% was the stores.
We had IE6 still on the Citrix version that the stores were using.
And the customers would go into the stores, sit at the desk, talking to the person.
And on a Thursday morning, it just stopped dead.
Fantastic.
So within the service management and the operations piece,
we had to scramble to get Google Chrome put onto the Citrix piece.
And then I went into town on a Saturday morning because we put the change live on a Friday night.
And I went into town on a Saturday morning into one of these stores and just said,
is it working today?
And they were like,
And they said, also that was you, wasn’t it?
Well, they’d understood what was going on by that point.
They’d had a nice couple of days.
A couple of days just sitting around drinking tea and chatting.
Ah, so actually they were quite happy with you, weren’t they?
Yes.
But you know, it’s those sort of things that when people are outside of the change process,
it does have knock-on effects sometimes.
And 99% of the time they can make the changes and do their A-B testing and it’ll have no effect whatsoever.
But if we’re not aware,
it can have…
It can have unforeseen fallout.
And that’s why we’re moving for teams like that from change management to release management so that we can work with them to get a schedule of what they’re doing and understanding of the timings of when they’re doing it and they can get a system that they can work with that doesn’t shoehorn them into weekly change board meetings and unnecessary to them delay.
That brings me to an interesting point.
Because the reason I invited you on this podcast was that I came across a remark of yours where somebody was complaining about the service management processes and you kind of quipped,
well, looks like your ServiceNow instance has just been bent to a process.
And I found that really interesting.
What do you mean by this?
So when you go to a service management tool,
you’ve generally come from…
something else.
You know,
you’ll have had a help desk for years.
And, you know,
in my instance that I mentioned earlier,
where we used to have a mainframe
and, you know,
we literally had a guy in the office that would print out the tickets in the morning
and you’d walk around with a stack of papers
fixing those things.
If you take what we were doing there
and then try and get it
to the point where you’re…
you’ve got a service management tool,
if you don’t change your way of working,
to the way the service management tool works,
but you try and make the service management tool work the way you do,
it’s not going to go well.
For a more concrete example,
the change management process
at a very large organization that I’d worked with,
before ServiceNow came along,
they had this concept of standard changes.
And you didn’t need approval for a standard change.
But they were generally…
thought of as small, understandable changes.
They put that into ServiceNow.
Now, ServiceNow, in the change management piece,
has approval built in.
That’s the way it works.
That’s the way change management works.
But they modified the code
in such a way that they could have this concept of a standard change
that would then bypass all the approval.
And the daft thing about it was
the engineer raising the change,
was the one that made the classification
as to whether it was standard or non-standard.
And there was an instance of the engineer
making a standard change
that knocked out the entirety
of the booking system for a large British airline
for an entire weekend.
And nobody knew that it was going on
because it was a standard change.
Until it happened.
That is kind of what I meant.
I can’t remember what the exact instance was,
what the comment was,
but it was something that they were saying
was just counter to the way ServiceNow works.
And I’ve seen it in so many organizations
where the teams in existence have a process
and here comes this new tool,
but they don’t want to change the process.
But aren’t they right to say,
look, we have a system that works for us.
Maybe ServiceNow is not the right tool for us.
Maybe we should go with, you know,
something else.
But should you really bend your process to ServiceNow
or shouldn’t it rather be the other way around?
So from my perspective on that,
if your process doesn’t fit with ServiceNow,
it’s probably wrong.
Because ServiceNow is built to the ITIL foundation,
you know, the ITIL framework.
The ITIL framework has been built up
by service management professionals.
Over many, many years.
The processes within that on how to deal with an incident,
how to deal with problem, how to deal with change,
have been embedded and, you know, forged in fire
over many, many years.
If your organization gets a tool that does things that way
and you go, nah, we do it this way.
You’re probably wrong.
Fair enough.
So in that sense, you can say that ServiceNow,
is opinionated enough, if I hear you right,
to sort of serve as this expression of this body of knowledge
and not just as a business process automation engine.
Yeah, to an extent.
I’m just trying to, I’ve got slightly distracted
because I’m looking at what they were saying.
Yeah.
So in the original thread that we were looking at,
they’d said that the process owners were annoyed
that he filled in a form instead of watching a training video
to find out where the secret hidden questions were.
And that is exactly the sort of thing that I’ve seen.
In ServiceNow, they’ll take a form
that was in their original way of doing things
and it’ll have all sorts of esoteric questions.
And, you know, if you use ServiceNow properly,
you go onto an incident or a service request form,
and you’ll start filling in the information you want.
The first few things you’ll get will be drop-downs
because that allows you to tailor
what questions you need to ask the person.
But the amount of times that I’ve seen it where they don’t do that
and they leave free text information in,
and if you don’t type in exactly the right thing
that the person who created the catalogue
thought you were going to do,
it doesn’t give you the options that you need to fill in
to actually get your request.
I mean, we haven’t really touched on service requests,
but that’s just a slightly different side of service management.
You know, we deal with incident problem,
which is where something’s broken,
but we deal with service requests as well,
which is if you need something.
If you need a user creating,
you need access to a printer,
you need a new laptop.
The big one in that is obviously
the new joiners, new leavers process,
which will kick off hundreds of jobs to different teams
if it’s set up right
to make sure that, you know,
when the person walks in the door on day one,
they’ve got a laptop, they’ve got a phone,
they’ve got their email set up
and all that sort of stuff.
All that’s run through ServiceNow and service request modules.
And it certainly sounds like on the one we were reading
that they’d gone through a basic service request
process that hadn’t been set up right.
And there were hidden fields and hidden stuff
that if you didn’t type exactly the right keywords,
you wouldn’t get them.
And therefore you would never get your request actually acknowledged.
That sounds kind of like an escape room.
To a certain extent it can be, yes.
But it’s more like one of those really annoying crawler dungeons
that we used to play on text screens,
back in the day.
You know, you type…
You’re in a tasty maze of passages.
That’s it, exactly.
All alike.
Yeah.
Turn left.
I don’t know how to turn.
Walk left.
Ah, yeah.
I now walk left.
And if you don’t type exactly the right thing,
it’s not going to work.
But, you know, when these things are set up properly,
you should, as I say,
you should have a number of dropdowns at the top
that allow us
to tailor the form
to ask exactly what you want.
Because it doesn’t help anybody
that if you’ve got a service request coming through
or an incident that goes to the wrong team,
all that does is put a delay in.
And it doesn’t make anybody happy.
As we’ve listened to you talk,
I was wondering, you know,
you are pretty much in favor of announcing your intentions in advance,
of, you know, making changes known in advance,
of…
asking for approval for a change to go through, et cetera, et cetera.
Yes.
Isn’t that sort of really contrary to Agile,
where you just sort of try it out and see if it works?
And then if, you know,
if all of the shops in all of Britain suddenly fail,
then oops, let’s maybe roll back.
So I guess what I’m getting at is
that sounds a little more restrictive
than the average developer would enjoy these days.
So there’s two sides of it.
I mean,
a lot of change management processes
are based around infrastructure changes,
things that aren’t time critical,
but need to be done.
So, you know, every Tuesday,
the first Tuesday of the month,
we get the latest Microsoft patches.
Some of those might be critical
and need to go out quite quickly.
We get patches on networking equipment.
We get upgrades on stuff that need to be done.
And all of those things can change.
So we generally go through
a normal change management process,
because you’re not really running
to get those things in ASAP,
like this afternoon.
You can wait a couple of days and get those in.
Where we have a high priority incident,
where something’s gone wrong,
or we’ve got something that’s come along,
like that one that came along and did the…
Log4j.
Log4j, yeah, that’s what I’m thinking of, yes.
That was quite critical.
Yeah, sounded like it.
And the change management process
has two things that we can do.
We can either do a urgent change
or an emergency change.
And those things just massively reduce
the amount of time needed
and the amount of approval needed.
And in the case of a high priority incident,
we may reboot and raise
a retrospective emergency change later.
To cover the fact that we did something.
In the case of developers,
there’s two sides of it.
A lot of them do know
when they’re going to do something.
They’ll be working towards a release,
or they’ll be working towards something specific.
And they can schedule that one in.
And the change management process is flexible enough
that if it moves or shifts a couple of weeks,
we can deal with that.
Where you’ve got the stuff
that we’ve been talking about previously,
the change management doesn’t really lend itself to it.
And that’s what I was mentioning earlier
with the release management module.
ServiceNow have realized,
like they’re moving to cloud infrastructure,
they’re realizing that developers
aren’t doing big bucket release.
They’re doing minor changes,
things that are constantly ongoing.
And with the release management module,
you can manage that sort of information.
The developers work with us,
and we get the right information in there,
and we get the right level of understanding.
It’s not so much trying to shoehorn the developers
and get them to follow our process.
It’s more making everybody aware of what’s going on.
Service management is that at its heart.
If we know what’s going on in an organization
and something goes wrong,
we know who to call.
If you’ve got developers just throwing stuff onto the servers
and trying what they like,
and then we start getting users calling in
to say something’s broken,
if we don’t know what’s going on,
it’s going to take us a lot longer
to get the right people on the call.
And developers with the best will in the world
don’t always have the information at their fingertips
that something’s not working.
How good is it possible to integrate this
either change or release management process
into automated processes developers like to use,
like continuous delivery pipelines
in one or the other way?
So the release management module within ServiceNow
hooks into the major players of that thing.
So that’s what I mean when I say
we work with the developers to get a flow
that works for them,
so that we’re aware of what’s going on,
the system is aware of what’s going on,
so that we can update the CMDB
and therefore all the dependencies within the organization,
but they still work within their tool.
A flip side of that, one that I’m very au fait with,
when we raise a ticket
that goes off to a third party app dev team,
it will quite often automatically
raise that ticket in Jira.
Mhm.
And Jira will automatically update
the ticket in ServiceNow.
So the developer doesn’t ever need
to go into the ServiceNow ticket to update it.
They can live in Jira and keep their workflow going
and they can get their bug ticket raised
and they can do all their development
and hook the patch back into their system
and the updates feedback seamlessly to ServiceNow.
When they close the Jira ticket,
it triggers into the service
into the ServiceNow ticket
to let the user know that update’s been done
and we’ll put it into a resolve state
and then the user will get three days to confirm
and then it’ll close the ticket.
So with something like that,
the app dev team or the DevOps team
is never going anywhere near ServiceNow.
They’re living in Jira,
which is where they want to live.
And for release management,
it’s very, very similar.
They’ll live within their tool,
but that tool will talk to ServiceNow.
It will raise the relevant tickets
or the relevant announcements that we need
and everybody will be happy.
All right.
Are those connectors to the different tools
part of the ServiceNow ecosystem?
Are they developed in each of those surrounding systems
or is there some kind of,
I don’t know,
service bus or central connector
that you support or you would, yeah.
Yeah, I mean, there’s two ways you can do it.
In the first case
and the one that you default to if possible,
they’ve generally worked
with the other third party organization
to provide the connector.
So if you hook into Jira,
like I just said,
they’ve worked with Confluence.
So there is an official connector
that talks from ServiceNow to Jira and back again.
But if you’re talking to something
that doesn’t have connectivity between systems
through an official connector,
then there’s an API.
And at the very worst,
you can just call HTTP
and just talk directly to the calls
on the backend system.
Excellent.
So I’m kind of running out of questions here.
Steve, is there a question
that you think I should have asked,
but somehow didn’t?
I don’t think so.
I think we’ve covered off
the vast majority of what we do.
I mean, you know,
service management isn’t this magical black box
where things happen.
It’s just that bit of IT
that everybody uses
when things go wrong
or when they want something.
Kind of like the glue that holds things together?
It is indeed, yes.
Okay, wonderful.
In that case,
I guess we can safely wrap up the show.
So any final words,
anything you would like to tell the listeners, Steve,
before we send you off?
Only if they need
a new head of service management,
give me a call.
Oh, yes.
So, dear listeners,
if you are in need
of a new head of service management,
reach out to us
and we’ll get you in touch with Steve.
And I suppose, Steve,
you can be easily found on LinkedIn
and all of these places, right?
I can indeed, yes.
Okay, wonderful.
So, Steve,
thank you so much
for taking the time to talk to us today.
This was really interesting
and very enjoyable.
Thank you.
Thank you very much
and enjoy your weekend.
Yeah, you too.
Ciao, instincts.
Ciao.
Ciao.
Ciao.
Ciao.
Ciao.
Ciao.
Ciao.
Ciao.
Ciao.
Ciao.
Ciao.
Ciao.
Ciao.
Ciao.
Ciao.
Ciao.
Ciao.
Ciao.
Ciao.
Ciao.
Ciao.
Ciao.
Ciao.
Ciao.
Ciao.
Ciao.
Ciao.
Ciao.