Service management ideas
I always had a hard time naming services that my IT department was delivering. I wanted to be able to talk about them both internally but also externally. Naming a service was therefore sometimes troublesome. I did some internet searching and talked to service managers and they all seem to agree on the following:
A former colleague of mine told me that delivering IT is a team sport. After thinking about that statement for a while I recognized how correct he was. He was of course talking about the fact that many IT organizations are a bit dysfunctional. There are to many silos within and behind the scenes blame-game going on. In the end the entire IT department is a team on a joint mission to deliver value to the consumers it works for. You can't blame one team or team-member as everyone should at least have tried to help out or assist before things got bad.
The most obvious blame-game around is blaming service desk for incompetence or ignorance or just being lazy... Fact remains that there is no way a servivce desk can fulfill it's mission without everyone else empowering it to do so. Who is the expert of infrastructure and applications? Well they are not in service desk they are in the product teams. That means that the only way service desk are able to give excellent user support is to have product teams make sure they can. In my opinion service desk is only as good as the product teams have made them.
There are of course two sides to everything. The above statement doesn't mean that servicedesk should just sit there and wait for product teams to appear and hand them instructions and so on. It means that servicedesk should actively seek product teams and ask them for instructions, training and anything else that makes them successfull in their joint mission to fulfill the service and product delivery.
If you want to learn more about servicedesk, kowledge management and how product teams should work with servicedesks then attend any ITIL training course. Start with ITIL foundation and then move on to more advanced ones.
There are several reasons according to Axelos. Among other things, that something called Organizational Change Management (OCM) has been added and that the name of that practice is too similar to Change Management. OCM is about change in organizations, especially the people in these, while Change Enablment is about changes in services and their components.
The best reason in my opinion is that the name clarifies what this practice is all about. Change Management as it was called before and Change enablement as it is now have the same goal of enabling change management at a maximum pace without us losing control of the changes. If you allow changes to services or components to take place without control, accidents will occur and incidents appear. In fact, the most common reason why IT has disruptions in its delivery is because of this. In my opinion, it is possible to compare the lack of Change Enablement with the fact that there would be no air traffic controllers or air traffic rules. If all pilots could decide when and on which runway they want to land, it would not be long before the disaster was a fact.
Change Enablement gives through its name a clarity in what must be achieved. A change management that enables the customer's business. ITIL contains a lot of tips, tricks and tools to succeed with this. For example, how to identify changes where decision-making power can be delegated far into the organization. Maybe all the way to users but definitely to the person or people who are most suited to make quick decisions without bureaucracy but with complete control so that incidents do not occur.
