Все по-разному относятся к ITIL. В основном отрицательно. Не нужно много думать о причинах—они просты. Невежество—ключевая причина всех бед. Сертифицированное невежество—причина многих катастроф. Молоток не виноват в том, что кто-то ударил по пальцу вместо гвоздя, даже если этот кто-то с медалями.

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

— Я не против, давайте просто накидаем целевую схему, в которой вы не участвуете. Смотрите: согласование, обследование инфраструктуры, окружающей рабочее место, происходит без вашего участия. Вы просто наблюдаете за подразделением с дашборда и раздаёте люли или премии.

— Неплохо, думаю за пару недель можно организовать, — отвечает начальник, используя восторженный мат.

Чтобы внедрять ITSM, нужно знать про IT практически всё: системы резервного копирования, сеть, базы данных, web-сервера, архитектура информационных систем и т.п.

Чтобы внедрять ITSM, нужно уметь в менеджмент: стратегия, коммуникации, организационные изменения, коммуникации, риски, коммуникации, организационная проблематика, коммуникации, управление требованиями и т.п.

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

Пусть у нам в августе нужно внедрить информационную систему(ИС), но поставка виртуальных мощностей запланирована на декабрь. Пусть внедрением системы занимается менеджер проектов, а за эксплуатацию отвечает отдел эксплуатации виртуальной среды. Пусть резервных ресурсов не хватает и система регулярно сбоит. К примеру, копятся очереди SQL-запросов.

Приведённое противоречие обычно и логика его устранения понятна:

Управление ИТ-сервисом — это на данный момент «серая» зона: непрозрачны механизмы, подходы к реализации разнятся, отсутствуют детальные стандарты и практики. Незрелость сервисных подходов — это временная проблема...

Сервисный сегмент предоставляет технологии управления ИТ для стратегического сегмента предприятия, для руководителей подразделений, для операционного блока предприятия. Управление сервисом начинается со стратегии.

Согласно методологии управления ИИ COBIT 5 стратегия управления сервисом определяется потребностями заинтересованных сторон бизнеса(учредители, государство, внешняя среда). Потребности, определяющие стратегию можно классифицировать, как: Получение выгод, Оптимизация рисков, Оптимизация ресурсов.

Решение коммуникативных задач — это один из основных вопросов управления ИТ. Такая точка зрения у Роберта Гоутэма, довольно весомого специалиста в области проектного управления из Канады.

Если присмотреться к процессам управления ИТ, то можно заметить, что большинство из них направлены на решение задач оптимизации и структурирования коммуникаций.

Управление изменениями решает такие коммуникативные вопросы, как согласование требований, планирование и информирование. Управление инцидентами информирует об оперативности устранения сбоев, о наиболее оптимальных обходных решениях, о том, что делать во время сбоя. Управление проблемами информирует о состоянии ИТ, о лучших практиках решения проблем, о готовых моделях проблем, о сценариях решения и порядке взаимодействия при решении проблем. Управление обращениями базируется на диалоге с пользователем.

Плохие коммуникации дорого стоят.

Вопрос формирования лучших практик управления ИТ становится всё актуальней—на hh.ru появились вакансии. Некоторые продвинутые предприятия начинают формирование собственных библиотек управленческих решений. Практики управления завязаны на конкретные особенности организации, такие, как организационная структура, процессная архитектура и зрелость, производственные особенности. Вместе с тем, есть общие моменты, которые могут быть полезны для всех. Вроде бы управление лучшими практиками —дело, не хитрое, но не такое уж и простое. Рассмотрим типичную схему работы контакт-центра.

Среди управленцев становится модным проблем-менеджмент(Problem manadement) или проблемно-ориентированное управление. Трактовка проблем-менеджмента разнится от толкователя к толкователю. Поделюсь своими взглядами. Проблем- менеджмент лучше внедрять сверху. Верхи оперируют отчётностью, которая описывает состояние ИТ- предприятия. Совершенно логично начать рассуждения с формирования проблемно-ориентированной отчётности.

На многих ИТ-предприятиях отчётность состоит из показателей и метрик. Столкнувшись с с показателями и метриками в первый раз, я предположил, что их важность преувеличена. Однако вскоре отогнал эту мысль, решив, что многого не понимаю в управлении. Сейчас, проработав с моделированием инструментов управления ИТ много лет, я до сих считаю, что отчётность, ограниченная показателями и метриками не несёт большого смысла.
Представьте, что вы директор по ИТ или CIO. Типовая отчётность о состоянии ИТ-услуг и ИТ-инфраструктуры в показателях выглядит примерно так:

Известная ошибка в ITIL — это проблема, которая уже была проанализирована, но ещё не была решена

Как работают известные ошибки и зачем они нужны? Покажу между делом.

Пусть у нас есть абстрактная служба ИТ, в которой разработка в одном подразделении, а эксплуатация в другом. К примеру такая:

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

Фармацевтическая компания Fox-Meyer Drugs, стоившая порядка 40 миллиардов долларов, из-за неверного внедрения ERP системы обанкротилась и была продана конкурентам за 80 миллионов долларов. Банкротство произошло потому, что складская логистика компании не измерялась, не мониторилась, не была охвачена ни метриками, ни показателями, ни KPI. При внедрении ERP не заметили разрушение ключевых бизнес-процессов: склады оказались переполнены, клиенты не получали продукцию. В компании отслеживалась прибыль, но не были формализованы логистические бизнес-процессы, которые разрушились за несколько дней. Отсутствие управления—неприятный нюанс, присутствующий на всех предприятиях. Это нужно принять, как данность, вопрос критичности, в том, какие зоны предприятия неуправляемы.