Зачем ITIL обычному среднестатистическому администратору (10-500 ПК)

Привет. Сразу скажу, что тема применима не только к администраторам, но и к фрилансерам, аутсорсерам.
Прошёл на днях тренинг «HF421S, ITIL Foundation for IT Service Managment», под впечатлением несу Прометеев огонь ^[1] в массы.
Надеюсь, большинство знает, что такое ITIL, для остальных выдержка из вики ^[2]:

ITIL (произносится как «айти́л», англ. — библиотека инфраструктуры информационных технологий) — библиотека, описывающая лучшие из применяемых на практике способов организации работы подразделений или компаний, занимающихся предоставлением услуг в области информационных технологий.

Бытует мнение, что ITIL это серьёзно, сложно и запутано, необходимо только очень большим компаниям, а большинство справляется со всем «на коленке», держит в памяти, и это нормально и удобно.
Отнюдь.
Следование принципам ITIL помогает в первую очередь администратору компании любого размера работать спокойно, стабильно, спланировано. Это просто.

Библиотеки ITIL — это как делали в других компаниях ИТ лучше всего. Верно и обратное: можно делать ИТ наилучшим образом, используя рекомендации ITIL.
Примечательно, что ИТ везде одинаковые, значит все в разной мере используют ITIL, часто не зная о его существовании.
По сути, если администратор работает не ногами, а головой, он шаг за шагом прийдёт к тому, что описано в ITIL по тем вопросам, которые его волнуют.
У меня именно так и получилось.
Разница между следованием рекомендациям и самостоятельными изобретениям состоит в стоимости полученного опыта (количество ошибочных экспериментов, потраченного времени и денег).
К тому же о многих процессах и решениях не задумываешься, потому что не возникает необходимости (инцидентов, требований) их моделирования.
Со своего опыта я выделил несколько основных примеров популярных проблем администрирования в небольших компаниях:

1. Работа с инцидентами и заявками пользователей обычно занимает большую часть рабочего времени, наименее результативна (время/задачи), убивает любое планирование и приносит хаос.
2. Изменения (обновление, установка) в ИТ-инфраструктуре влекут за собой падение всего, и победоносное решение новоиспечённых проблем неоцененными никем ночными сменами администратора.
3. Смена администратора (часто одного единственного) приводит к новым расходам и простоям в работе ИТ, так как новый админ ничего не знает, всё ищет, переделывает чужие неудобные костыли на свои любимые костыли, и тоже не напишет документацию.
4. Риски обсуждаются довольно абстрактно, «а вдруг», «авось», «ну я же говорил», «ну сейчас же работает», «нам не нужно супер, лишь бы работало» — основные теги таких рассуждений.
5. Процедуры резервного копирования и восстановления подлежат обсуждению максимум в течении месяца после серьёзного сбоя, аж пока шеф не увидит счёт для покупки SOHO-коллайдера.
6. и т.д. администраторы действуют с душой, на совесть, лучше всех, но почему-то так и не могут наладить качественную работу и обслуживание сервисов и всё больше ненавидят людей.

К моему большому удивлению, на третий день тренинга, когда собралась целостная картина, мне вдруг резко стало понятно, как легко можно было организовать обслуживание инфраструктуры клиентов, больше заработать, больше вырасти, сэкономить время, усилия, нервы, не ругаться по пустякам с клиентами и сотрудниками и т.д.
Большое удивление вызвано потому, что я не узнал ничего принципиально нового, и вместо ожидаемой горы бюрократических проблем увидел возможности для отличной оптимизации процессов.

Итак. Всё-таки зачем ITIL обычному среднестатистическому администратору (10-500 ПК)?
В ITIL коротко и понятно описаны принципы, следование которым поможет облегчить ваш труд и наладить желаемую работу ИТ в компании.
Варианты для вышеописанных примеров:

1. Простой работающий Service Desk ^[3] поможет решить проблемы с инцидентами и сроками их решения. Анализ инцидентов даст понимание узких мест, которые обычно в рамках небольших компаний решаются довольно легко.
2. Использование Change Management'a позволит избавиться от многих проблем из-за банальных ошибок по глупости, из-за невнимательности или незнания.
3. Документирование инфраструктуры не так страшно, как кажется на первый взгляд. Поддержание актуальности документов в рамках Change Management'a требует не много усилий и экономит массу времени.
   А ведение внутренней базы знаний на самом простом wiki-движке ^[4] сэкономит время при решении проблем, или даже предоставит отличную возможность самообслуживания для пользователей.
4. Понимание рисков и их правильная оценка помогают определить критичные сервисы, оптимизировать инфраструктуру, найти и устранить ошибки и т.д., в итоге избавиться от головной боли через аргументированное привлечение финансирования, или же полную передачу ответственности на высшее руководство.
5. Резервное копирование может стать простой автоматизированной процедурой, ведь у вас уже всё расписано, распланировано, определены риски, минимизированы случайные поломки, а руководство выделило деньги, потому что уже оценило рентабельность данной операции и выделило необходимые средства.
6. и т.д. администраторы работают спокойно в запланированные часы, сервисы в вечном апптайме, заказчик/работодатель доволен и соглашается на повышение оплаты труда, освобождаются ресурсы, привлекаются новые клиенты, наконец-то можно заняться собственным бизнесом, а не рутиной и найти время сходить в магазин за новым бентли.

Автор: MrBalu