Using ITIL methodology in small business
This article is intended for all those system administrators working in small companies who sometimes face misunderstanding on the part of superiors and ordinary employees. Such people — that is, you and I — are sometimes perceived negatively by others, and not always according to merit. Relations with employees spoil when we close access to social networks. Bosses perceives with hostility any request for the purchase of new equipment. Meanwhile, communication in a team is your comfort, and relations with your boss are your money and career.
That is why I would like to offer you to change this scheme. Namely - a few recommendations from the library ITIL. They will become the filter on which the entire inevitable negative of our profession will settle. If you're still interested - welcome under cat.
Consider two processes from the Service Operation book (Incident Management, Problem Management) and two from the Service Transition book (Change Management, Configuration Management). In other words, I propose to implement the management of incidents, problems, changes and configurations.
')
As an example, take a company where one administrator works. He has bosses and some constant amount of work to support the internal IT infrastructure and its users.
Incidents occur daily. Printers, computers break, anything can fail. You honestly work correcting errors. The flow of breakdowns and repairs is mixed in your memory, and when at the end of the quarter you are asked a question about the work done, you will only be able to report in general terms. Of course, such a response will not make a proper impression on the management, which means that there will be no salary increase or the allocation of a new workplace for your assistant. To create an objective report, you only need to implement one of the incident management systems. Paid, free, developed by yourself or collected from a bundle of mail with a table editor - it does not matter. The main thing that she was.
No need to run on each request personally, often hearing from users something in the spirit of "it has already fixed itself." Get people to send requests by mail or via the web interface, in the extreme case, accept their applications by phone.
However, be reasonable: to spoil relations with users is unprofitable for you, and therefore present it as an innovation from the top management. They also sympathize with you. To the top management, first prescribe for signature a short order about the procedure for contacting the IT department, and keeping records of appeals. Explain to management what it is for order. The manual likes order.
Maintaining a database of incidents will allow you to plan your work day, get rid of constant walks under the auspices of "look, I have a computer there does not work ..", and so on. Your boss at any time will receive a clear and understandable report on the work done, resources spent and stupid user requests for any period of time. Users will be able to view the status of their application online, without annoying you personally.
The system will become an isolating layer between your personality and any negative that inevitably circulates in human society in search of a convenient "lightning rod." She has no personality. The system is silly to ask, it is useless to scold; nothing to argue with her about. In security, access control and video surveillance systems have, in addition to the main, also an important function of removing human aggression from the guard. The late employee is angry with the janitor for recording him in a magazine - but he won’t be angry with the card turnstile. Do the same for yourself, and the user of the broken printer, instead of telling you about the need to print invoices, just look at the status of the request - and print out your invoices in the next section.
After implementing incident management, the next logical step will be the implementation of problem management. Imagine that you have a very harmful printer that breaks down every month, constantly taking your time to coordinate its repair work, devouring the company's money. Having already configured a database of incidents, you can select those that relate directly to this printer, and then create a problem - in which all the data will be linked together. Show the authorities that the repair has already cost you half the cost of the new, and in the future will even exceed it. The expediency of buying a new printer will become obvious even to the most distant IT manager.
The problem is not just repetitive, but in general any incidents that have a critical impact on your infrastructure. For example, a crash raid of a controller on an email server that caused a temporary suspension of business correspondence should have a problem status. In other words, maintaining such a database will allow identifying incidents and groups of incidents for which solutions it is necessary to use changes in the infrastructure.
Ideally, in terms of workflow organization, you should strive to solve problems. All incidents should be transferred to the assistant, whom you managed to get thanks to clear and detailed reports for the previous quarter.
Our next step is implementing change management. Any replacement of important equipment, all changes to server settings, must be documented. With small volumes of production, or sufficient staffing of the IT department, you can even add a mouse replacement to the configuration management database so that you can track which user, when and what ordered.
The base with which all the listed processes work is called CMDB (Configuration management database). This is part of configuration management. It contains all the available hardware, software solutions and company personnel, each of which is assigned an inventory number. Each such record in the database is called a configuration unit. Whether it is an incident or a problem, any request must have a connection within it with any configuration unit from this database.
If you already have an assistant by the time you implement change management, it is highly preferable to introduce a change request system (RFC) in the department. Any action to change the configuration of the equipment, or to replace it by your assistant, must have your formal permission. Without which, this very assistant for any change would receive a disciplinary sanction - or, more simply, a cap, even if he entered the information into the database.
I repeat: the most budgetary version of the introduction of this whole economy can be realized through mail, a table editor and html.
In this article, I tried to describe the general ideology as simply as possible, without possibly going into details and details. If you are interested, I can go more deeply through each process or describe other processes and recommendations of the ITIL library with their adaptation to the realities of our life.
That is why I would like to offer you to change this scheme. Namely - a few recommendations from the library ITIL. They will become the filter on which the entire inevitable negative of our profession will settle. If you're still interested - welcome under cat.
Consider two processes from the Service Operation book (Incident Management, Problem Management) and two from the Service Transition book (Change Management, Configuration Management). In other words, I propose to implement the management of incidents, problems, changes and configurations.
')
As an example, take a company where one administrator works. He has bosses and some constant amount of work to support the internal IT infrastructure and its users.
Incident management
Incidents occur daily. Printers, computers break, anything can fail. You honestly work correcting errors. The flow of breakdowns and repairs is mixed in your memory, and when at the end of the quarter you are asked a question about the work done, you will only be able to report in general terms. Of course, such a response will not make a proper impression on the management, which means that there will be no salary increase or the allocation of a new workplace for your assistant. To create an objective report, you only need to implement one of the incident management systems. Paid, free, developed by yourself or collected from a bundle of mail with a table editor - it does not matter. The main thing that she was.
No need to run on each request personally, often hearing from users something in the spirit of "it has already fixed itself." Get people to send requests by mail or via the web interface, in the extreme case, accept their applications by phone.
However, be reasonable: to spoil relations with users is unprofitable for you, and therefore present it as an innovation from the top management. They also sympathize with you. To the top management, first prescribe for signature a short order about the procedure for contacting the IT department, and keeping records of appeals. Explain to management what it is for order. The manual likes order.
Maintaining a database of incidents will allow you to plan your work day, get rid of constant walks under the auspices of "look, I have a computer there does not work ..", and so on. Your boss at any time will receive a clear and understandable report on the work done, resources spent and stupid user requests for any period of time. Users will be able to view the status of their application online, without annoying you personally.
The system will become an isolating layer between your personality and any negative that inevitably circulates in human society in search of a convenient "lightning rod." She has no personality. The system is silly to ask, it is useless to scold; nothing to argue with her about. In security, access control and video surveillance systems have, in addition to the main, also an important function of removing human aggression from the guard. The late employee is angry with the janitor for recording him in a magazine - but he won’t be angry with the card turnstile. Do the same for yourself, and the user of the broken printer, instead of telling you about the need to print invoices, just look at the status of the request - and print out your invoices in the next section.
Problem management
After implementing incident management, the next logical step will be the implementation of problem management. Imagine that you have a very harmful printer that breaks down every month, constantly taking your time to coordinate its repair work, devouring the company's money. Having already configured a database of incidents, you can select those that relate directly to this printer, and then create a problem - in which all the data will be linked together. Show the authorities that the repair has already cost you half the cost of the new, and in the future will even exceed it. The expediency of buying a new printer will become obvious even to the most distant IT manager.
The problem is not just repetitive, but in general any incidents that have a critical impact on your infrastructure. For example, a crash raid of a controller on an email server that caused a temporary suspension of business correspondence should have a problem status. In other words, maintaining such a database will allow identifying incidents and groups of incidents for which solutions it is necessary to use changes in the infrastructure.
Ideally, in terms of workflow organization, you should strive to solve problems. All incidents should be transferred to the assistant, whom you managed to get thanks to clear and detailed reports for the previous quarter.
Change and Configuration Management
Our next step is implementing change management. Any replacement of important equipment, all changes to server settings, must be documented. With small volumes of production, or sufficient staffing of the IT department, you can even add a mouse replacement to the configuration management database so that you can track which user, when and what ordered.
The base with which all the listed processes work is called CMDB (Configuration management database). This is part of configuration management. It contains all the available hardware, software solutions and company personnel, each of which is assigned an inventory number. Each such record in the database is called a configuration unit. Whether it is an incident or a problem, any request must have a connection within it with any configuration unit from this database.
If you already have an assistant by the time you implement change management, it is highly preferable to introduce a change request system (RFC) in the department. Any action to change the configuration of the equipment, or to replace it by your assistant, must have your formal permission. Without which, this very assistant for any change would receive a disciplinary sanction - or, more simply, a cap, even if he entered the information into the database.
I repeat: the most budgetary version of the introduction of this whole economy can be realized through mail, a table editor and html.
In this article, I tried to describe the general ideology as simply as possible, without possibly going into details and details. If you are interested, I can go more deeply through each process or describe other processes and recommendations of the ITIL library with their adaptation to the realities of our life.
Source: https://habr.com/ru/post/119752/
All Articles