Interview: IT service management and how to apply it outside IT

Magnus (00:04):

What's your uptime on the QA environment? Maybe it's 80%. I don't know. Nobody knows because somebody just goes in and press that button and it just crashes the entire system down. And at the same time you're doing your marketing, you're doing your demo, the system is down. You look like a complete fool on stage and that's not what you're there for.

Lauri (00:31):

Hello there, and welcome to the DevOps Sauna Podcast. IT service management often referred to as ITSM is simply how IT teams manage the end to end delivery of IT services to their customers. This includes all the processes and activities; design, create, deliver, and support IT services. Now, that definition has many occurrences of IT, and because the working practices have been adopted by teams other than IT, ITSM has morphed into something now called ESM, Enterprise Service Management. ESM is the extension of IT service management principles to enable better service delivery for business teams like human resources, legal, facilities, marketing, and finance. We managed to snatch Christoffer Johansson and Magnus Sundset from their intense work with their customers, and we sat down to talk about what's going on in ITSM and ESM. Enjoy the talk.

Lauri (01:37):

Thank you, both Christoffer and Magnus for taking the time, and welcome to the DevOps Sauna Podcast. How are you doing today?

Magnus (01:45):

All good from Stockholm. Thank you very much.

Christoffer (01:48):

Yeah, same here. We can really feel that the weather is turning and autumn is starting here in Stockholm.

Lauri (01:56):

It's same here in Finland. My son is driving a motorcycle driving license. It's coming to be just the last possible days in the year when you can do that. Because otherwise it's going to be a little too cold in the morning to rely that you have the necessary friction for your two wheel motorcycle.

Magnus (02:14):

Yeah.

Lauri (02:14):

But the days are getting shorter. You probably have noticed that yourself.

Magnus (02:18):

Yeah. I'm out walking every day at 6:00 and it is dark. Sun goes up, I don't know, like 6:30 or something, but it's still dark now.

Lauri (02:30):

There was a wonderful expression somebody said it in the office that in the wintertime we keep our shades closed in the windows to keep the darkness out.

Magnus (02:42):

That's good. I like that.

Lauri (02:45):

Yeah. It's funny. We are talking today about IT service management. It's an interesting topic and it's also an interesting topic for your audience because as I said, this is DevOps Sauna, and for some of our listeners, it may sound like IT service management is a departure from DevOps. And our argument is that it is not. It is essentially part of it, which we shall discuss. And I was going back to my own career and trying to think that when was it and how has it been that I have come across different type of service management products and solutions. Because I was a Unix administrator back in time, and I was working in the R&D department to providing Unix support. That was my first permanent job. And there was a product called Remedy ARS, which was Action Request System.

Lauri (03:45):

This must have been 2000 and 2001 when it was deployed. And back in that time, the focus was like, we have to get all of the ticket flow into the system from the mailboxes. Well, there was no chat at that time, but primarily from mailboxes, and people walking up and requesting for services and trying to resolve them on time. And I have some control over the SLAs that there was. But it has been a long time since I have heard Remedy ARS being mentioned after 2000 and 2001. Now, as a marketer, I have been more involved in and taking advantage of Jira Service Desk and Jira Service Management, that of course our own people use ourselves and have been so curious to see how we can apply the service management practice at marketing. But as I said, back in that time 2000, the focus was on capturing tickets and resolving them on time. But my question to both of you is, what's going on in ITSM today? I'm pretty sure that the industry has advanced from capturing the tickets and resolving them.

Magnus (05:04):

It's really funny that you say and mentioned that system. I was also involved with that system in an implementation, working with those tickets and a lot has happened since 2000. Especially if you look at ITIL Version 2 going and over to Version 3, now we're in ITIL Version 4. And since three to four, we talk more about practices, et cetera, and lean agile and DevOps has become a more of a part of the ITIL roadmap. So it is now part of it, because we talk about in the ITIL and ITSM world that you need to take care of your CICD pipeline. You could deliver really super fast, really good software. The guys around may not be ready to adapt to the new application or the new features that are being developed. So maybe sometimes it's good to be a little bit slower. Sometimes you can actually adapt to this fast development lines of code being delivered.

Magnus (06:18):

So I think the emerging ITIL, ITSM, that way of thinking with the DevOps, those pipelines has been evolving the last... I would say maybe five to 10 years that they need to work more better together. And the trip has been like a lot of people has adapted to the agile world using Scrum for the planning parts, et cetera. And that is also now agile is part of the ITIL roadmap. So I think it's a more mature way of looking it and it's more updated to what the companies need today.

Christoffer (07:00):

I totally agree with that. And as Magnus mentioned, the step and the update of the framework ITIL from version three to version four was really, really necessary. And now we really can see that we have adopted to the agile way of working.

Lauri (07:26):

This can be a controversial question, but I'm putting it out, nevertheless, because not too long ago we had Lande Castberg from Norway joining us with Kristoffer Ryeng who was a guest in the podcast, and they talked about basically agile enterprise. And you cannot talk about agile enterprise without somehow relating to the agile frameworks. And like it or not, in agile, you have multiple frameworks and they are necessary, but they're also necessary evil. And it's interesting that when we start to talk about ITSM, then the ITIL framework comes up so prominently. So it almost gives me a feeling that the ITSM world has agreed on ITIL. There is no disagreement that it's a good thing, and there are no other frameworks and that's the one way forward. Am I hearing it correctly that ITIL has really established itself as indisputable framework in this, and there's no room for anything else and there's no need for debate because it's so good?

Magnus (08:39):

I think rather than asking the direct question if it's right or wrong or this and that, I would say it's more of a colorful spectrum that we see today is that you could use whatever incident, problem process, or practice. What you need for your purpose, it's not you have to adapt to all the practices you have in ITIL, you could choose incident problem change and those, and you could talk about... The lingo around it is the same. It's very easy to use, and it's very... I mean, people use it today. It's very natural, natural language type of thing. And adapting to other frameworks is very, very easy. Also like for instance, if you have a first line support, there's a service portal, maybe you have a ticket that comes into the first line support, a help desk, service desk, or whatever you call it. They need to take care of that issue, solve it somehow. Maybe they log into another system, solve the ticket there, and then just report back, "Now we have done this."

Magnus (09:57):

That's what you did before in Remedy, you now do it in other tools that have other names, et cetera. It doesn't really matter. The collaboration and the cooperation with the customer or the person, the requester is super important. It's more of ways of collaborating internally and externally. And how you structure that work, you need to find out a good way that is suited in that particular business or in that industry. For instance, if you have HR, they're really now into this, oh, maybe we should have a Kanban boards, or maybe we should have an onboarding process that is automated. You get this DocuSign digital signatures into the HR work. And 10 years ago, that was very much the beginning of signing documents online. So now even HR has been adapting to the new technology that is out there.

Magnus (11:07):

And it's all about, get rid of all these paperwork. We need that person to work here and start collaborating and operating within our team. That is more important than having, oh, you have to fill in this form. You have to be in this office between 8:00 an 5:00. So the whole new world has changed. So what I'm saying is that everybody needs to be more adapted to changes and choose a good framework that is available out there that is good for you and that you may change rapidly within. If it's ITIL or if you use ADKAR or whatever framework, safe, whatever you need to be fast moving in the market today.

Lauri (11:58):

Christoffer, what do you think?

Christoffer (12:00):

I totally agree. It is controversial but see it as a toolbox and pick what you need basically. You don't have to use it all. You don't have to use all the tool. Use the tools that you need. And as Magnus mentioned, we see today that it's not only ITSM, Magnus mentioned HR and so on. And we see today what's happening. It's that more and more of the different processes and departments of the company tend to lean towards that the agile solution. And the challenge today is how can we integrate them together?

Lauri (12:50):

And if I build on that, there's some parallels in what you're saying, let's say to adopting agile practices and tools around agile practices outside software. So as we know, for instance Jira was... there's one Jira, which is called Jira Software, which already the name says that probably it has been thought from software development teams point of view. But we as marketing team, we use Jira Software because we regard that some of the functionality that software teams use is so critical for marketing. We would have to spend extra energy to find a better way or at least the same way of doing it if we used a version of Jira which is not for software teams. And why I say that is you said that ITSM for more than IT.

Magnus (13:50):

It's really interesting that you say the marketing in here, because just imagine a case where some guys have developed a really good software, deployed it, and it's in production. Now marketing is using that software for marketing purposes. All of a sudden somebody is working on another release on that application that you are using in marketing. Now you have a great conference coming up, marketing is going out, you use all the channels, you're working hard on it. Boom, there is a downtime here. Woo, what's going on? Nobody can sign up for the event because somebody took down your web page to deploy another code, and it was maybe not planned. Or was it planned? Where do you find out the plan? Who can say to the guys deploying, "Hey, stop. We're doing marketing stuff now. Stop doing the deployment on our marketing platform. We need it. Now it's critical point of time."

Magnus (15:04):

It's the same with finance. You don't deploy a new feature on a financial system when you're closing your books. And it's the same with marketing. I mean, there will be very critical for you during a set time period when people are signing up for the event or such. And it's very good to have that type of knowledge sharing. When are we going to deploy? What's our planned deployment dates, service windows, et cetera? Ask around in the company; is anybody have any arguments around having these service windows? Is that okay? Yeah. Well marketing here or finance here, HR, whatever say, "No, please don't touch these applications."

Magnus (15:54):

Then you need to have a structure and you need to have change control. If you don't have change control, anything can happen. I know a particular incident that happened was even on a demo environment, needs to be up and running. When you do a huge show and you do your marketing and maybe you have a demo of the system, et cetera. And if you're doing a demo in, let's say a QA environment, what's your uptime on the QA environment? Maybe it's 80%. I don't know. Nobody knows because somebody just goes in and press that button and it just crashes the entire system down. And at the same time you're doing your marketing, you're doing your demo, the system is down. You look like a complete fool on stage and that's not what you're there for.

Magnus (16:52):

So even on the QA and the demo environments, you have to have change control. And how do you get there to have control on your environments and the up and down times, et cetera. You need to be on top of these things. So if you have a really great CICD pipeline taking down the systems, whatever, then you need to talk to people. But if you have the redundant systems, you take down this node, you deploy on that and the other one is up, then you can continuously work on the system. So technology really needs to work with the processes, and especially with the people. This is like a fact today. How does everything get structured and you know what's going on and who is doing what, at what time. Maybe somebody produces a really fantastic code, puts it on the wrong spot. It's not there. It's not on that server you were going to deploy or the other one. So anything can happen if you're not having a good release process in place.

Lauri (17:56):

And I think my takeaway from my controversial question about ITIL was that it makes things easier because you can think through the processes, and then you can select the tools that does the job in the best way. How hard is it to find one tool that fits all of the needs? We have discussed about finance and marketing and HR and the original IT ops team. Is it necessary to find one tool that fits all of your needs? Then if you get to this point where the answer is, no, it's not possible to have one tool that fits all of your needs, then how do you approach the integration challenge?

Christoffer (18:38):

I would say that it is possible to at least make it one tool, but that will demand so much of configuring the tool that in the end it will not work. So I would say from my perspective that you can't really have one tool that fits all the different teams. You need to have different tools, because the different tools, they do what they do best. You have perhaps one HR tool, one finance invoicing tool. And in our world, it is how can we integrate these different tools and help and support. So that's what we do.

Magnus (19:32):

I totally agree with that because one size fits all, it doesn't. If you look at the carpenter's toolbox, what they have in their toolbox, that is for that carpenter. And if you're a plumber, you have another tool set. So when they're working together, they can restore your bathroom and whatnot. And how do they collaborate and integrate with their tool set? Because they bring that to the table and they start working together. Maybe I'm an architect coming in, "Well, we're going to build a new house, and you guys are going to build this stuff. This is how it's going to look like to have the planing tools at hand." And they will be in different environments and they're coming from different worlds, they talk different languages maybe. But they can look at the blueprint, this is how we're going to build the house.

Magnus (20:25):

And they understand how these pictures are evolving. So just mapping out the process an infrastructure map or something. That's a really good way of looking at ITSM as well. If you put the pieces together, maybe there's a company that buys many other companies, then they always come in with their tool sets and it takes years to just get rid of all these redundant systems to get one unified enterprise system that works for all. It takes time because they come from different worlds. Then you find ways to integrate these ones and then it boils down to the data. Do we have one master data source or something? And the tool set that you surround the data set is that matters.

Magnus (21:25):

Because today data is really powerful to use when it comes to understand your market, et cetera. And you shouldn't have only one tool to deliver all these things. I don't know. It's a little bit naive to think that you can have one tool for everything. Maybe if you're a startup, you start using one tool, et cetera. And then you work like really, really fast. And then you could see that you start tweaking the tool to do other things as well. And I think from the very beginning, as you mentioned, Jira Software. That's what you did with that tool. You start using it for other purposes. And therefore I was mentioning, Jira Software comes from Atlassian, Atlassian has identified those things and they have started to build the portfolio around this. You have more project management, you have a CMDB with all the master data retrieved from there. So that's how it evolves. But I totally agree with you, Christoffer, one size does not fit all. No.

Lauri (22:45):

There was the old expression that some tools really, they only break through the moment when somebody starts to use the tool for the purposes where it was not designed for. There's one example from my previous world where some organizations had very successfully deployed legal document approval and archiving using invoice approval tool.

Magnus (23:15):

Yeah. I think that's really interesting because if you go up a level from the technology and what you can do with the technology, you will find what kind of services can you apply on this platform. When we build service portals, well, what is a service portal? You go there and I have a question, where's the staff handbook? HR question goes there, or it totally finds the article referring to where it is. And then you get the self-help, and you really use the technology to enhance the experience of the end user. I think that's the target for anything you do, like all the processes, frameworks, et cetera, to enhance that user experience.

Christoffer (24:08):

I would say when we talk about service portal and the service that are provided regardless if it's HR, finance, IT, it should all revolve from a portal. And in today's society, we are quite used to search for information. So I log onto the portal and I type in my question and I get redirected towards the place I need to go. And if you take it one step further, of course you can integrate and include a shut bot in order to automate that process even further. So that would be a way to go as well.

Lauri (24:56):

Which means that the simple questions are answered more and more easily and less and less requiring people's intervention, and then those questions and those requests and those tickets that require people are more complex if I follow your line of thinking.

Christoffer (25:20):

Exactly. Today we see that most companies tend to want to automate the recurring tasks, questions, you name it. And if you have a good knowledge base of articles that are presented on the portal, and perhaps if you have a chatbot that could answer the most simple questions, you would save plenty of time and let your agents, the people who are working with the tickets, they can do the complex stuff, the fun stuff, because nobody likes simple questions, recurring tasks. Nobody wants to do that.

Magnus (26:07):

Especially if you have a high turnover in your service desk, it may mean that the tool set is not so fun to work with, it's not easy to work with. It's hard to find information and it's not so fun to work there. But if you have a modern tool of course, it's going to be more fun to work with the tool and you're empowered to also add more articles, you could publish articles that we use...

Lauri (26:36):

As the chief marketing officer of Eficode, I have constantly been on the lookout for better ways to do marketing. One predicament in this is to maintain a 30,000 feet view into everything going on, but at the same time, be able to plan and execute work in a detailed level. Our team recently adopted Atlassian's Advanced Roadmaps on top of Jira. Irrespective of your issue and project tracking software you use, I suggest you read through the blog post that Annica Andersson wrote about Advanced Roadmaps. The link is in the show notes. Now let's get back to the show.

Lauri (27:16):

So what impact does that have for SLA? Let's go back 15 years where you did not have this kind of scale of help tools or chatbots and things like that. Then you could say that any arbitrary ticket that comes in falls in some sort of Gaussian curve, that some of those tickets are solved immediately because they're just repetition. And then you could say that median ticket gets solved in X hours or X days. And then you can specify the SLA based on that. And then you have like 5% of tickets that are incredibly hard. They're valid, but they're incredibly complicated. And you cannot give any timeline because it's so multivariable problem. But now what you have described, my conclusion is every single case that ever reaches a human desk is so incredibly complicated that it's impossible to give an SLA. And I'm now using a very strong language here, but what do you say to that?

Christoffer (28:26):

I would say it's a really interesting topic. And I would say that if we look at SLA, service level agreements, in some cases, we need to have it between two companies. That you have an agreement that within X amount of minutes, hours, so on, we need to respond. And in X amount of minutes, hours, we need to resolve it. That's the classic SLAs. But I usually tend to recommend and want to talk about is SLEs, service level expectations. We don't have an agreement, but we would like to start working on a case within X amount of minutes and hours and resolve it as well. And if we do that, we have the possibility to measure, and we have the possibility to improve the service that we deliver to our customers. But as you mentioned, in some cases, it could be hard because the classic SLAs or SLEs, they are based on the priority of the ticket. And what is a priority of a ticket? Is it the impact? Is it the urgency? Is it the highest paying customer? And so on.

Christoffer (29:51):

So in those cases, it could actually be hard to actually set time on that ticket. And if we're talking about incident, perhaps that's not an incident, perhaps that's a problem or a change, or even a bug that needs to be resolved in order to solve that incident.

Lauri (30:10):

You said earlier that people don't want to do repetitive tasks and naturally the chatbots and knowledge centers, or any other types of self help portals help in there. The flip side is that some people are afraid of automation because they're afraid of losing their jobs. So what do you tell them?

Magnus (30:32):

No. What type of job is it? Because I did some robotics before and I got that question. The RPA, the robotics automation, does it really bring any value or just get rid of people? And I would say, "Well, you need people to run the robots. You need to have input for the robot." We can run a script that takes 11 hours rather than two weeks manual 100% work full time, 24 hours. Well, you don't want to do those manual things because it's degrading your brain to a very routine work. And if you want to get rid of the routines, you automate. So if you have that in mind, then what are you supposed to do then? Well, you can do analytical work, you could do more fun type of work in your environment where you are working.

Magnus (31:42):

So those repetitive tasks, if you get rid of them from your area... Let's say for instance, in service desk, you get hundreds of tickets every day, 99% of them are questions. If you get rid of the questions and they're answered in the service portal with just a knowledge article, then you get the real ones in. And if you're a service desk agent, you don't have to lift the phone, say, "Oh, well, today the clock is 5:00. What is the in time?" Buy your own watch. Now we have a watch in the service portal. So if you get rid of this repetitive task, very stupid metaphor anyway, but then

Lauri (32:32):

It's a good one.

Magnus (32:33):

But then people that really needs help, they get help from a person in person. If you chat with a chatbot, after a couple of questions, this chatbot will direct you to a person because, first of all, they cannot answer your questions, then you will be redirected. Then you can talk to a person. You have major companies that implementing this. Because it's not about the employee, it's about the end user experience. If you have elderly calling into the hospital or something, probably they would like to talk to a person. They don't want to talk to a chatbot because they're not in that type of environment. They don't have the computer at hand. They need to talk to somebody. Well, let them talk to somebody. But the rest is automated or in a structured way. Like we're now talking in a digital way.

Magnus (33:33):

We have in Sweden... I don't know how you have it in Finland, but at least in Sweden we have a lot of applications for doctor's appointments. You can call this application. You have the application and you could... I don't know if it's FaceTime or Zoom or whatever they have, but then you can talk face to face with your phone to this doctor. And that's also a way of optimizing things, making it more convenient for the patients. And I think that is really interesting to make it more convenient for people. And even also for the staff. The doctor doesn't have to get the people in, in the same room one by one. They can have like 10 patients within very, very short time period, because many of the questions are pre-answered. What symptoms do you have? I have this, this, this. Then you have pneumonia. You could get that answer up. You can just Google it.

Magnus (34:37):

Or you would need to talk to somebody. You have the semi-discussion with the doctor. And I think that's a really, really cool way of looking at service management. They're really providing very good service. You don't have to go to the doctors. Maybe I have a very small issue with my toe. I don't really want to go there, but let's call and show a picture and the it's fine. After five minutes, I know what to do. I got a remedy for it.

Christoffer (35:06):

That is interesting, Magnus, because that's what we tend to see in ITSM today. Now, I'm holding up my phone and you can't see it. But during the last, let's say five years, we have seen a massive change within the different ITSM tools that they have adopted to making it available in the phone. Let's be Frank, who uses their computer to order a cab or food or booking tickets? No one. Everyone uses their phone. And take the example that IT technician who is out or in the bunker, wouldn't it be convenient if he or she would be able to take a picture with the phone and create a ticket or even work with tickets on the run. So we can really see that the major tools have really been focused on providing descent apps for the two.

Lauri (36:26):

Yeah. A lot of stuff. I must ask one very specific question regarding ITSM before we go to our second to the last question, how to get started and how to put yourself in the map and decide what to do. But you mentioned earlier that some themes have now started to think about using, for instance, Kanban boards. One thing that was surprising to me was that, we are very accustomed to using boards in the marketing theme, but as we have started adopting more service management practices at marketing, we were introduced to the queues. And then suddenly we were in this boards versus queues world, and what's going on? And I couldn't piece it together for me. How do you approach this board versus queues and what's your take on that?

Magnus (37:16):

If you have a call coming in and you have this list of things in a long row, when it's a lot of things coming in, you need to do the triage, what to work on. I mean, what's the most important to work on now? That's why you have this list of stuff. Then you will start structuring it, but that's the first bucket of stuff that is just pouring in, and you need to have a structure to do this triage. And then when it comes to planning your work, then it's really a good way of doing it in a Kanban because you shouldn't have too many issues or tickets assigned to you working at the same time because you shouldn't content switch too often because you will lose time. And then you come into this lean principles of reducing waste in your calendar and your time. I mean, just moving from one meeting to another, just content switch in your brain is, you need a couple of minutes just to focus. What are we going to talk about now?

Magnus (38:28):

Imagine the list of things that come in from end users or the public, it could be high, low, it could be anything. So somebody needs to just have that mindset because that person will not content switch. The person will only do the triage and prioritize what is most important right there and right now. This is a priority one. Then that goes to the next funnel, to the second line, to the third line. If you're working with marketing and you get all these requests in, et cetera, well, have somebody doing your triage. What is most important right now? Is it the CEO of the company that has a VIP status in your world that, oh, this guy needs attention now, boom, get it there. Or this super good customer of yours that needs to have attention right now.

Magnus (39:29):

Then you do the triage and put it with a high ranking in your Kanban board, high up, this is the next thing to work on. Because every day your world is changing and your Kanban board cannot be static. It has to move around. Maybe you have to throw out tickets, oh, we're not going to do this. This thing is way bigger, way better. Now we're going to work on this thing. MTR Board, this is what we're going to work with. So that's really working agile. You need to adapt to what's going on around you on a day-to-day basis. So work with the queue list and the Kanban board is my suggestion. What do you say, Christoffer?

Christoffer (40:14):

As always, I totally agree with you on that one as well, because the boards have the possibility to really visualize the overview of the stuff that needs to be done. And the queues are therefore quicker solving all the tickets. So absolutely combine them.

Lauri (40:43):

Yeah. It's a very low level detailed question, and your answer is spot on. So it almost sounds to me that when you say triage, it's the traditional backlog management in the board. And then once we have sorted out your backlog, then start to work on those things. I haven't examined the products intimately enough, but what I have not yet found out is how to create a sub task structure on a ticket. Because when you get a ticket from somebody at least I immediately start to think, okay, what do I have to do first? What do I have to do then? What do I have to do then? And then I break down that work in as small pieces as is it meaningful?

Lauri (41:31):

Like, can you move that picture from that wall to that wall? It's easy to say, move that portrait from that wall to that wall. But the other wall is made of gypsy plate and the other wall is made of concrete. You need a drill. The drill is in the summer house, so you have to go to the summer house to get the drill. But it's winter so the road is not open. So you need your skis, but your skis are in the attic. So you have to get to the attic. But you need the ladder. And the same thing happens in this real world is you have to first do something to get to the next step. And what would really work is when you get a ticket, the first question is, what steps do you have to do as a team to accomplish what the customer wants?

Magnus (42:14):

This is super interesting, because now let's say this is a first time job you have; set up an event. The first time, then you think like that, okay, what things do I have to do? The next time, you've done it already. You just copy. So that's semi-automizing your process because the first time you've done it, why should I just type in the things? You just copy the same concept, because it worked the last time, and then you start improving, oh, maybe we should have it on the right side of the wall. It's better to have the roll ups on that side because that's where people coming in, et cetera.

Magnus (42:56):

And then you start improving your process of setting up the event. And in the end, you probably have a service catalog saying, "Can we order an event with this amount of people." And then you just put the parameters in there because that's what you need to know, how many people are coming. Are they going to eat, sleep, dine, all this surrounding things that you need to be able to set up the digital, or the conference on location. So you may have one event for online events and one for on location.

Lauri (43:35):

Yeah. So capture the requirement, then standardize the work or standardize the model of work and then repeat and improve. Makes sense.

Magnus (43:47):

Exactly. And that goes for all the processes, whatever you implement, you should continuously improve those, just not so much. But small bits here and there and just adapt to the world around you.

Lauri (44:00):

Yeah. So where should somebody start? So where should they start? How do they get themselves in the map and decide what to do now considering that you have the IT and then you have some people within support functions, let's say finance, legal, marketing, HR, and so on and so forth. What's the step one there?

Magnus (44:20):

Yeah, exactly. That's a good point. In ITIL 4, there's one of the guidelines saying start where you are. So you have to create a baseline, where are you, so you know where you're moving from. So if you start on step one in our CMMI level or TDMI or whatever you have, and we want to reach to operational excellence, how do you get there? Then you create a roadmap where to go. We want to reach operational excellence in this department. How do we get there? Where are we now? That's the focus, and what's the next step?

Magnus (44:57):

You cannot jump up to operational excellence. You have to start somewhere. Start small, baby steps and then you grow your picture. The system map, you will probably already have it. Let's say you bought another company and you have to add those systems and all the people and processes into the new one. Well, the thing that they are on their first step is to start entering the new company. And the first step for the receiving company is, okay, well, we are here. The next step is to incorporate them into this. And how do we do those things? Because you may also have that strategy as... we have to reach operational excellence within five years or so. And how do we get there? Okay. We buy companies, we do all these things and you create your roadmap, but start small and start where you are.

Lauri (45:56):

Very similar to the Improvement Kata model from Lean, the four steps.

Magnus (46:03):

Absolutely.

Lauri (46:03):

I don't remember them top of my heart, but roughly speaking, where am I now? Where do I want to go? What are the steps to go there? Which one should I take now? And then you do that. And then you come back to the where am I now? Where do I want to go? It's probably a zigzag line but it will take you eventually where... Because you learn as you go.

Magnus (46:24):

Yeah. And some people I've heard, they're arguing, "Oh, well, we cannot use these types of methodologies because we need to have a big program, lots of projects. We have to work in a waterfall methodology because we don't know where we're landing and we have to structure everything because we're working in total chaos." Well, on the contrary, you need to be very adaptive if you're working in a chaotic environment. And if it's super fast moving, your competitors are just bypassing you all the time. And why is that? It's because you're not agile and lean enough. You need to adapt to those fast moving principles. Otherwise you're not going to survive the year.

Lauri (47:13):

And I assume it is fair to say that organizations who feel that they are not where they need to be to do the assessment, they can always get help on doing the assessment. And then once you get the help for doing assessment, then you get the recipe, and then you can start implementing that.

Lauri (47:31):

Last question is about ITSM for companies that develop their own software to their customers. As we were preparing for this episode, we were entertaining about the thought that in the same way that security or performance or scalability is a non-functional requirement, you could argue that service ability is also a non-functional requirement and you should plan for it when you are creating software. Maybe it's a topic for another podcast, but I think it was really intriguing thought that when you are a software architect and when you are a software developer, then you have to have these different things in your mind that you are keeping in your mind as you are creating the functionality and wondering, can this function at this scale? Is this functionality secure? How do I create this function so that it is as available as possible, so it doesn't cause downtime? And then the other aspect on top of that is how do I create software that is easy to deliver to the customer and it's easily serviceable?

Christoffer (48:52):

Yeah. I mean, if you take a look at some of the processes practices within ITSM, of course they can assist the development processes. If we take change, for example, we want to have control of what code we actually are releasing out to production in the software that we are building. That could be one example on how we really can integrate and use one of the tools in the ITSM toolbox.

Lauri (49:28):

Thank you, Christoffer and Magnus for joining. I'm sure this raised a lot of thoughts in our relationship as I am sure that you agree with me when I say that ITSM is a crucial part of building and maintaining a platform for sound DevOps practices. With that, I thank you again for great company. As usual, let's give the floor back to our guests, that they can introduce themselves properly. I say to you, take care of yourself, start small and work together to form a sustainable structure.

Christoffer (49:58):

My name is Christoffer Johansson, and I work as a solution architect at Riada, now part of Eficode. And what I usually do during the days is to help our customers with the architecture of their Jira tools or Jira products, Atlassian products, design, do some developments and build some integration. So I have most of the times a full day.

Magnus (50:30):

My name is Magnus Sundset, born and raised in Stockholm, Sweden, been working a little bit abroad and also here at home, of course. And I work at Riada since 2021, this year. So I'm pretty new in the company. And now we're part of Eficode as well. I work as a business consultant, and as a business consultant I'm part of the team implementing processes and tools to enhance the user experience for the end-user. We work with any industry out there. So to the full extent of ITIL 4, with all the practices that we have there, with all the agile frameworks out there, we can create a good structure to work with and starting off from where you are today.