ИТ Скептик, в свойственной ему юмористической манере, прошелся по одной из логических неувязок библиотеки ITIL – управление изменениями и постоянное совершенствование.
Смысл управления изменениями – сделать так, чтобы продуктивная среда была максимально стабильна. Цель постоянного улучшения – непрерывно изменять продуктивную среду (услуги и процессы), отвечая на изменяющиеся условия.
Постоянное совершенствование [как его описывает ITIL] похоже на ученых в белых халатах, которые аккуратно поворачивают ручки и снимают показания приборов, занося их в журнал наблюдений, чтобы по чуть-чуть оптимизировать производительность… ИТ-службы, которые я знаю и люблю – это кричащие люди в рабочих комбинезонах, которые носятся вокруг с огнетушителями…
…Руководство компании объявляет, что сделан выбор прикладного ПО для нового направления бизнеса. Приложение написано в гараже, в одной из стран Варшавского договора, двумя бывшими студентами Хьюлитцом и Паккардовым. Документация написана кириллицей, на языке, определить который не удалось. Поддержка в вашей стране осуществляется иммигрантом (кузеном Хьюлитца), который продает холодильники и учит английский…
Кое-как вы установили это ПО, опоздав на полтора года, и лишь с половиной обещанных функций. Вскоре выясняется, что интеграционные потоки были разработаны молодыми консультантами в костюмах (бывшими студентами), выдавшими себя за опытных разработчиков, и которые не отличают бизнес-аналитику от гречневой каши. Короче говоря, ваши данные понемногу, но безвозвратно превращаются в мусор. Количество звонков в службу поддержки зашкаливает. Чтобы вычистить данные и поправить интеграцию, выделяются дополнительные средства, однако на полпути начинается экономический спад. Вам приходится попрощаться с внешними подрядчиками, в том числе с главным экспертом и менеджером проекта. Количество звонков снова зашкаливает, но в этот раз дополнительных людей нанять не получается. Очень скоро менеджер службы поддержки – единственный, кто знал, какие ИТ-услуги мы предоставляем, и как – находит другое место работы.
Снизив очередь инцидентов до четырехзначного числа (удалив все записи старше трех месяцев), вы узнаёте, что руководство компании приобрело стартап, в котором техподдержки никогда не было: разработчики сами отвечали пользователям. Вы пишете подробное описание новой системы, и тут вам сообщают, что руководство подписало «меморандум о намерениях» с SAP. Вы несёте ответственность за то, что SAP начнёт работу к следующему финансовому году.
А в это самое время группа серверов достигла конца жизненного цикла, а ПО, которое вы купили со стартапом, не запускается ни на одной из известных вашим сотрудникам операционных систем. Вы установили виртуальную машину для приложения, а сразу после этого пошли на встречу с новым CIO, который сообщил, что, по его мнению, соблюсти бюджет удастся только если быстро реализовать в вашей ИТ-службе бережливое производство. Пять огромных проектов заморожены (включая очистку данных, которую вам удалость возобновить)… Вскоре компания объявляет о слиянии, а следующее письмо от CIO гласит, что теперь с пользователями мы будем общаться только через Твиттер…
У ИТ-организации из примера нет времени и ресурсов для постоянного улучшения. Да и результаты измерения сегодняшней среды не с чем сравнивать, ведь годмесяцнеделю назад всё было организовано иначе.
Еще больше ярких метафор и олицетворений – в блоге Скептика.
Отличная аналогия.
Но мне кажется зерно истины в постоянном улучшении есть -)
Понятно, что постоянно улучшать ИТ невозможно, глупо и бессмыслено. Оно “само” улучшается, но не виде проектов, скачками под воздействием внешних факторов.
А вот постоянно обеспечивать соответствие процессов управления ИТ, самой структуре ИТ – надо.
Именно обеспечивать соответствие, а не постоянно улучшать. Ну я как бы так пытался “переврать” эту дисциплину заказчикам -)