Branimir Valentic Every organization that provides IT services in the marketplace tries to be successful at the Service Operation part of the IT service lifecycle (according to ITIL). But, there is something even better. Any guesses? It’s when you use your experience from Service Operation and apply it to the other (previous) phases of the lifecycle. In addition to Service Operation, processes and respective activities in the Service Transition phase of the service lifecycle can additionally increase the experience factor. Why is that?
For an introduction, read the article Early Life Support – Live environment introduction made easy. This article explain that once your service is operational, or in the live environment – you should use accumulated know-how in the transition phase of the service lifecycle. Don’t let it go (or, from an operational point of view, disappear) – instead, use it to be more efficient and productive, and to stay one step ahead of your users. Yes, there are many smart guys on their “side” who can become familiar with your service faster than you do. After all, they use the service on a daily basis and their knowledge grows quickly. Service Transition (particularly Release and Deployment Management process) will show you everything they learned during build, test, release, and deploy activities. And that is usually a lot.
What is it all about?
In the above situation, knowledge goes in one direction – from Service Transition to Service Operation. And there the “battle” begins. Service(s) are in the live environment, interaction between users and Service Desk is continuous and, after a while, there are no surprises in your daily operation. This means that you learned a lot about the service, the technology behind it, and user behavior when they use it. And that’s very important knowledge, because, as you know, services behave differently in the development or test phase and in the live environment.
I remember a case when an IT Service Management tool faced problems in the live environment. Namely, the Configuration Management Database (CMDB), as a constituent part of the toolkit, was tested and deployed as part of the major release. I don’t know what kind of test they performed, but when a larger company filled the CMDB – it got stuck. It’s not that it didn’t work; it just needed unacceptable time to process data, i.e., it was extremely slow. Since it’s a huge database in the background, redesign of the database wasn’t appropriate.
This case shows that:
- It’s very hard (or even impossible) to include all possible situations during the test.
- When the service enters the live environment it faces new (untested) conditions and no one can predict its behavior.
Is that a problem that belongs to the Service Design domain, solely? Well, I wouldn’t say so. The argument that Service Design has to take care about the appropriate design is correct. Service Design uses different kinds of knowledge, but it needs the experience factor. That’s something they can get from Service Operation.
What’s the gain?
So, once in the live environment or in the last phase of the Service Transition (e.g., test), you actually start winning from the knowledge point of view. After several months or years, you are familiar with details that could be learned only from experience. General knowledge is easily adaptable. You just have to identify your needs and go for the training (and, of course, have the budget for it). What makes a difference (and competitive advantage) is your knowledge from experience. You can’t buy that, but you have to make sure that you use it.
I was appointed as a consultant by a customer where three companies merged into one. One company was pure development and the other two were doing maintenance, each of them having its own Service Desk. When they merged, the first mistake was that they didn’t merge Service Desks. For no good reason, they left two independent Service Desks, which means:
- doubling of some resources (e.g., having a (underutilized) server administrator in both Service Desks)
- internal and external communication difficulties
- knowledge management is far from optimized
As you can guess, management of the three (previously independent) companies, now business units, didn’t communicate and cooperate very much. In addition to the above-mentioned disadvantages, their situation had one more gap. Everything they learned in the live environment was left inside the Service Desk. For development (read = new services), there was no use of that knowledge. In praxis, if their service contained some systematic error, which was only noticed when users started using the service (remember the first case – CMDB), the same error would be built into future releases or new services – all because development did not get feedback from operations.
Figure: Returning knowledge gained in operation into earlier phases of the service lifecycle
Could it be different?
There is a principle in ITIL called “Operations and Transition involvement.” This means that you have to divert knowledge flow. It’s good when people from Release and Deployment Management stay with operations during Early Life Support, but knowledge should flow in the opposite direction, too – from operations way back to Service Design or even Service Strategy. That what learning organizations do.
We use to say, in private life, that we live in era of life-long learning. But that’s valid also for your organization. Service Operation and Transition involvement in earlier phases of the service lifecycle do exactly that. “Trial and error” might be the best education you can get, but be careful – it could be an expensive one.
Use this free ITIL implementation diagram to build your knowledge management right from the beginning of the implementation.
