Service Management—A Modern Way of Supporting Clients

Maciej Kłodaś (MK): Hello everyone, my name is Maciej, I’m the leader of analytics experience competency group at C&F and this is C&F Talks, a place where experts discuss about ideas and experiences from the perspective of an IT vendor. And my guest today is Adam. Adam is the head of service management competency group at C&F.

Adam Kościaniuk (AK): Hello Maciej. Hi everyone.

Are service management and IT Support the same thing?

MK: Today we’ll talk about another very interesting topic, both technical and non-technical, which is service management, a very fancy word for support.

AK: You can call it like that.

MK: I can? Okay. So I knew that, you know, I know that there is a support and there are L1s and L2s and tickets handling. So tell us about the service management. What is it? Is it support?

AK: Yeah, you can call it support. In the old fashioned way. It’s ticket handling, catch and dispatch made by L1 team, service desk, going to the layer two, layer three if needed. However, time’s changing and we are not in the year of 2000. So even in old way fashioned support, there are changes. We’ve got a lot of implementation of AI tools these days.

There’s a hype on that. And we’ve got the culture shifts into the DevOps as well. You probably discussed it with Konrad.

MK: Yes, we did.

AK: So it’s not like 20 years ago. It’s slightly different because currently we are more focusing on tailoring the support to the business needs, to our customer needs.

MK: Okay. Any particular use cases you’ve seen along the way? Because you are handling all of our clients across the globe and these are very big companies. And do you see this culture shift with those clients?

AK: Yeah, of course. I believe that the knowledge is quite common about the need of having support, about the need of changing the way we are supporting the services as organizations. For instance, this year we had a service transition for one of our customers of service desk from their internal team to our team.

We already had very good relations for the past few years. So having all the teams together inside our company, we were able to switch to the DevOps team setup and having a new approach. It doesn’t mean we don’t handling tickets anymore. It’s still in the place. But we are creating a one team, instead of siloed teams shooting at each other.

MK: From your perspective, what is the perception of service management or support with our clients?

AK: Usually for customer, unfortunately, it’s still connected with the cost and still connected with the good old term “we’re working on solving your issue”. So we are talking about it all the time in the old fashioned way. However, it’s a wider term because as an organization, as a customer, you can have a different service setup based on the stage where you are.

For instance, you can have a new project, the development is up and running, you are getting close to the end and you start thinking about the supporting. Either you’ve already got service in the production up and running and users are using it, or you’ve got some internal or external support team and you are not satisfied and you are looking for a change. Or you’ve got a service application on the production used by users, your project team still supporting the application, fixing bugs, but you don’t have a proper support team. So there are different scenarios when you as a customer can need the support.

Differences between supporting enterprise clients and smaller companies

MK: Okay. And by the type of the client, do you see any differences between, you know, big companies? We are working for Fortune 500 companies across the globe, leaders in the market, and they have different processes in place.

They have different needs, many divisions, different stakeholders. And also we have smaller companies, more of a startup type companies. What are the differences between those companies and the owners and the approach to service management?

AK: Of course, in the big companies from the Fortune 500, you can observe bigger maturity and bigger awareness, having processes in place. However, the most important is a stakeholder you’re working with and his or her awareness about the support or how important it is, rather than having globally implemented processes and standards. Sometimes even in a smaller company, there’s a better understanding of the needs and having the awareness because of the stakeholders, rather than in a huge enterprises.

MK: For the bigger clients, I’ve seen, well, the level of complexity in terms of who is handling what is very, very big. Usually there are many vendors delivering different applications, different solutions. One vendor is for, I don’t know, web solutions. Another one is for BI solutions. Another vendor is only responsible for service management or support.

AK: Or you’ve got five vendors responsible for the BI solutions.

MK: Exactly. And you have many vendors responsible for supporting certain solutions. I remember one case from the past. This was a leader of a CPG area in the US. And I remember that they started a project. It was like, I don’t know, five years ago or something like that. They wanted to aggregate all of the projects. I mean, service management under one central vendor.

And I remember that this was a big case. You know, the setting up or estimating how much money will it cost and how much time would take to transition everything from multiple vendors to this one central vendor. This was a very huge initiative and I don’t really remember how it ended up.

I don’t know. So, okay. Assuming that I’m the client and I am very aware that we have developed a tool and I have lots of users in the business that will be using the tool and I assume that there will be many bugs or incidents or whatever needs they will have. I need support.

AK: Good for you. To know this at this stage.

MK: And I’m calling you and I said, Adam, listen, I need support. I don’t know how to approach it. How should we do it?

Different stages of implementing service management

AK: Usually we are starting from the assessment phase where we are checking what does your organization need, what is your project about, the outcome of the project, the system platform, BI dashboard, whatever. And based on that, we are discussing the potential needs in the future because you probably, as our customer, you’ve got some plans towards the application or service. So, you know that you would like to implement it globally or the application will be used only in one country, for instance, in Poland.

The second thing is about the complexity, the new features, changes you are making. And based on that, we are start designing what kind of service you need. So, after assessment, we are in the service design part.

If you are an aware customer and you plan it in advance, usually we’ve got the time for making some MVP phase where we can test our service design ideas together with you, make the final tailoring, start engaging the future supporting members already in the MVP phase to start the learning curve, the knowledge transition to those people much earlier. And after the MVP, once it’s agreed, we’ve got a better understanding of the business needs, what is the business value going from the service, we are going to the service transition and final service setup.

MK: Okay. So, by the way, the assessment questionnaire is available for download in the description. Adam has prepared a very wonderful playbook with all best practices also for you.

So, be sure to check it out. About the service transition, it’s a very interesting element. I suppose the service transition quality impacts the outcome of the whole setup.

AK: Exactly. I wouldn’t say it better.

Service transition: the pivotal point in support setup

MK: Okay. So, how would you approach the service transition? How does it look and where to start from your perspective?

AK: The service transition, according to ITIL, is the process which is responsible of moving the service application from the development to the product environment. What does it mean? It’s a process which is supposed to be planned properly in advance. It defines how you plan to transition the developed application to further support.

If we’ve got time, because you are our customer and we are living in the ideal world, we start discussing about the service transition and service setup at the beginning when you are planning your project. So, you start planning.

MK: In the beginning. Okay.

AK: Time, cost, resources needed for the proper service transition to the support team.

MK: Who does that in the beginning?

AK: Some of our stakeholders do.

MK: Okay. That’s very interesting.

AK: Sadly to say, it’s not common knowledge. However, in some organizations, some of the stakeholders, we’ve got such customers who are aware enough to start the discussion.

Usually, it’s happening when they’ve been working with us for a few. It’s a learning curve for us, but also for the customer. Later on, we are checking where you are with the development phase. Very often, we start engaging to trigger the knowledge transfer, the shift left.

Earlier, we start engaging the future support team members into the test phasing, start knowledge transfer when first users start using and you’ve still got the hyper care period covered by your project team. Even we’ve got the service transition checklist, so we are checking along the way where we are. And once the full checklist is fulfilled and so we are saying we are ready to finalize the service transition and we are ready to go, then only support teams start supporting the solution.

MK: Okay. I’ve heard an expression from you that the service transition is the king.

AK: One of my colleagues, she says that service transition is a king of the processes.

MK: King of the processes. So this is, from your perspective, the most important element of the whole process. Without it, the quality of the whole setup is lacking or this whole setup is lacking the quality that it’s supposed to have.

I wanted to ask you about the value of this service transition, but rather what is the risk of wrong setup and cost of a wrong setup, I would say.

The risks and costs associated with a poor service setup

AK: So you can imagine that according to Gartner, even up to 80% of incidents in the first year of ongoing support is a result of having in place. A good or bad service transition. So it’s a really important thing.

What’s following, it’s not only the incidents. If you create the service on very last moment and then you start thinking about the support, definitely you will start creating siloed teams in your organization. So you will have the project development team who is engaged already in the second project.

They forgot about what they did in the previous one. You’ve got the support team who is not properly trained. So they are like children in the fog and looking for the answer. There is a lot of communication barriers, a lot of communication mismatches.

MK: Pointing fingers.

AK: Yeah, it’s not our fault. We haven’t received any information about that. As a result of that, your users, your end users, the people in your organization who use your application or service dashboard starts to be disappointed. The quality of services is going down. The business value supposed to coming from your dashboard is going down because the end users, they don’t know how to deal with that, how to correct the data and so on.

So from many different angles, you’ve got pros and cons coming from the proper service transition.

MK: So it’s not, I would say, it’s not about technology. It’s rather connected to organizational culture.

AK: And processes.

MK: And processes. So it’s how people or teams cooperate with each other rather than which technology they are using. Technology is something different, right? So ticketing tools or whatever. It’s something in addition.

AK: We’ve got it in the service transition checklist. During assessments, we are both together with customer, we agree how we want to cooperate.

Building a business case for service management

MK: All right. So my perspective is that, again, support or service management is a topic which is not too sexy. I mean, it’s a necessary evil for most of our clients. It’s a necessary cost or maybe something that they can shave a bit.

And so assuming that we have a client who is very aware, but this is only his team, they are delivering different tools for their business partners. And having in mind, it’s difficult to sell it internally.

How would you help me as this aware client to equip me with information to sell it internally to my superior to get funding for this initiative?

AK: Great question. I’m always advising to focus on the what would be the cost of not having the support. So asking your organization the question, what is the cost of downtime?

It can be lower or higher, but if you are a production organization, one minute of downtime, one of your core systems in one of your factories can cost you millions. Second thing, ask questions. Do you have capacity to work on the new project or your project team members, your development internal teams or your other vendors are focusing on the bug fixing and trying to help your end users to start using the application developed in the previous projects.

The next question you can ask and think, do we have, especially these days when the AI topic has a huge hype, do we have space for innovation or are your team members occupied with the bug fixing of previous applications? These kind of questions can easily help you sell it internally and show it what is the importance of properly set up service.

MK: Okay. So can you somehow estimate the cost of such initiative? Can you do it in stages? Can you, you know, after the assessment, I assume that you can have a full blown process in place, or you can address certain elements of the process to optimize some of the stages of this, you know, I don’t know, service transition, for instance. You can implement one tool here or a new process here.

From your perspective, or maybe you have some use cases, examples that, you know, we worked with a client and we only optimized a part of the process because they have, they had less budget or they had some processes in place. But later on, we had to, you know, change something in the process to make it more efficient.

AK: As always, it depends. But we’ve got both cases.

We are working only on assessment and service design and customer takes it and further on sets it up according to our consultancy and advices with the internal teams. And we are super happy to do it. We’ve got cases where we’ve got experience and history with our customers when we’re providing some development teams and they ask us also to cover the support.

And when we gather not only development, but the support, it’s much easier to take responsibility for the whole process, the whole life cycle of the services applications. We’ve got also cases where we are taking the support from a different project team, from our customers, different vendors. And we’ve got also when we are taking the support from different vendors because our customers were not satisfied with the previous setup.

MK: Okay. So we have a lot of use cases and me as a client, I would be a bit lost, I guess. I assume that you could advise me on where to start.

AK: Definitely.

MK: So this is the checklist, I guess. We can be sure to download it and use it because this is also something that we or you and your team is using internally where we’re working with our clients. Okay.

Any last advice for our clients or people who are on the fence and struggle and think whether they need support or your help in optimizing the process?

AK: I believe if you are a customer who thinks, “do I need support?” You can check it with our questionnaire. And if for some of the questions you will answer no, I believe it’s a high time to start thinking about the need of having support.

MK: Okay. Great. Thank you very much. Thank you for watching and hopefully we will see each other in the next episode. Thanks, Adam.

AK: Thanks, Maciej. Thanks, everyone.