Practice ITIL for a small company. Change management
Today, many people have heard about ITIL: IT processes, incidents, tickets and other components of IT management.
Did you hear? - Cool!
Not? - do not worry, still discuss.
Immediately make a reservation: I did not read a single book from the ITIL library, did not attend courses and, for the time being, I am not a certified specialist - therefore, please do not throw tomatoes at me, but correct and politely correct me if I’m wrong about something.
At the same time, I was lucky to work on these IT processes (in the very form in which they were conceived by the authors of ITIL) for three and a half years - so I know the whole “kitchen” from the practical side and I know that all this is real, damn it It works not only on paper, but also in life.
')
Today we will talk about one of the most important IT processes in terms of maintaining the stability of the organization's infrastructure - Change Management, or Change Management .
Change Management is most closely associated with the following processes: Incident Management, Problem Management, Configuration Management.
Its essence lies in the control of actions associated with any kind of changes (they are also in use "change" from "change") in the IT infrastructure. You need to change the server configuration - make a plan, approve, apply, update the documentation. You need to put into operation a new router - make a plan, approve, apply, update the documentation. It is necessary to transfer the database from one host to another - ... well, you understand.
It may seem that all this is excessive bureaucracy, which takes up your valuable time. Partly - yes. However, no one suggests getting into the bureaucracy right from the start. Bureaucracy can be left to large corporations that can afford any costs for the sake of maintaining stability.
No matter what the IT management aesthetes say, I sincerely believe that in companies of any size you can use Change Management techniques - quietly, introducing all the best that is in it gradually, and not in one fell swoop, without fanaticism.
And you can start with one small, but very useful document - the so-called. Change Plan - a document that describes how the change will take place. At one time, he himself developed his template for the company in which he worked - the document was very practical. Below are his sections. I hope it will come in handy:
Everything. With the contents of the plan finished.
In addition to the obvious advantages of drawing up such plans, there is one nice bonus: over time, they will accumulate so much that a good half of the changes can be carried out according to the previously worked out scheme. At the same time, they can be implemented not only by one employee, but by any person who is more or less in the subject. Everyone needs to go on vacation sometime.
Despite all the simplicity, in 95% of organizations such approaches are not used even closely. This is far from ITIL, but it is already a piece of it, which will make the organization’s infrastructure more stable. An IT specialist who applies such approaches, albeit curtailed, will be able to upgrade their skills, which will undoubtedly be useful in their careers.
Learn, implement.
Thanks for attention.
Did you hear? - Cool!
Not? - do not worry, still discuss.
Immediately make a reservation: I did not read a single book from the ITIL library, did not attend courses and, for the time being, I am not a certified specialist - therefore, please do not throw tomatoes at me, but correct and politely correct me if I’m wrong about something.
At the same time, I was lucky to work on these IT processes (in the very form in which they were conceived by the authors of ITIL) for three and a half years - so I know the whole “kitchen” from the practical side and I know that all this is real, damn it It works not only on paper, but also in life.
')
Today we will talk about one of the most important IT processes in terms of maintaining the stability of the organization's infrastructure - Change Management, or Change Management .
Change Management is most closely associated with the following processes: Incident Management, Problem Management, Configuration Management.
Its essence lies in the control of actions associated with any kind of changes (they are also in use "change" from "change") in the IT infrastructure. You need to change the server configuration - make a plan, approve, apply, update the documentation. You need to put into operation a new router - make a plan, approve, apply, update the documentation. It is necessary to transfer the database from one host to another - ... well, you understand.
It may seem that all this is excessive bureaucracy, which takes up your valuable time. Partly - yes. However, no one suggests getting into the bureaucracy right from the start. Bureaucracy can be left to large corporations that can afford any costs for the sake of maintaining stability.
No matter what the IT management aesthetes say, I sincerely believe that in companies of any size you can use Change Management techniques - quietly, introducing all the best that is in it gradually, and not in one fell swoop, without fanaticism.
And you can start with one small, but very useful document - the so-called. Change Plan - a document that describes how the change will take place. At one time, he himself developed his template for the company in which he worked - the document was very practical. Below are his sections. I hope it will come in handy:
- Description
What will be done in a nutshell.
Why it will be done (if you think about it, it may turn out that you don’t need to do anything);
Who will participate.
Links to documentation. It is desirable for the official, but it is possible for other trusted sources. Documentation determines the correctness of your actions. In general, it is useful to read. - Preparation (Pre-installation)
All you need to do before the moment of X - the time for which the change is planned. Important points of this section are:
Negotiation and Backup.
For what I need a backup, I will not be distributed, but about coordination I will clarify that this item is extremely important. All who may be affected by the change should be warned, and those responsible should give their consent. For example, from 16 to 17 you are going to replace the printer, and it is at this time that the payroll will be sent to print in the accounting department ... You will agree that it will be unpleasant. - Install plan
All actions that will be performed at time X. Step by step - as detailed as possible: go to a server like this over SSH, execute commands: 1, 2, 3 ... And so on.
If you wish, you can specify how long this or that operation will take. - Final Actions (Post-installation)
Check that the system and all other systems interacting with it work correctly;
Return back all the settings that were made in preparation for the changj;
Make changes to the documentation; - Backout Plan
Actions that will be performed in case of problems and the impossibility of their elimination within a reasonable time. - Applications
If in terms of a lot of background information, then you can collect it all. IP addresses, server names, file system paths, and so on.
Everything. With the contents of the plan finished.
In addition to the obvious advantages of drawing up such plans, there is one nice bonus: over time, they will accumulate so much that a good half of the changes can be carried out according to the previously worked out scheme. At the same time, they can be implemented not only by one employee, but by any person who is more or less in the subject. Everyone needs to go on vacation sometime.
Despite all the simplicity, in 95% of organizations such approaches are not used even closely. This is far from ITIL, but it is already a piece of it, which will make the organization’s infrastructure more stable. An IT specialist who applies such approaches, albeit curtailed, will be able to upgrade their skills, which will undoubtedly be useful in their careers.
Learn, implement.
Thanks for attention.
Source: https://habr.com/ru/post/148136/
All Articles