Практика реорганизации ИТ-подразделения на основе ITIL
В последнее время реорганизация ИТ-подразделений, внедрение современных методов ITSM (IT Service Management) на основе рекомендаций ITIL (IT Infrastructure Library) становится стандартной практикой. Как подступиться к подобной задаче, с чего начать, на какие моменты обратить особое внимание?
Стоит ли вообще этим заниматься
Есть ли необходимость в формализации работы ИТ-подразделения, если в нем всего один сотрудник, а количество рабочих мест на предприятии равно, скажем, десяти? Где та грань, за которой формализация превращается из полезного инструмента в никому не нужный бюрократический механизм? Ответ таков: этой грани не существует в принципе, а степень формализации должна быть прямо пропорциональна масштабу компании и ИТ-подразделения.
В случае одного ИТ-специалиста достаточно даже бумажного блокнота, в котором он будет фиксировать поступившие обращения, — это уже позволит систематизировать работу и не забывать о нуждах пользователей. Звучит немного комично, но что это такое, если не формализация, пусть и на примитивном уровне? Если пойти дальше, то следующим шагом будет простейшая система, регистрирующая обращения пользователей и уведомляющая по электронной почте об изменении статуса их обращений. Такие системы есть в продаже, они недороги, а кроме того, их можно легко и быстро разработать силами штатного программиста.
В этой статье речь пойдет о реорганизации ИТ-службы на предприятиях среднего и крупного масштаба, когда становится оправданным достаточно высокий уровень формализма. В любом случае существует простой критерий оценки — экономический эффект, о расчете которого мы поговорим достаточно подробно.
Зачем и кому это нужно
Это вопрос, с которого стоит начать. Понимание цели проекта — ключевой момент при выборе подходов к его выполнению. Причин для запуска проекта реорганизации может быть несколько:
- начальник ИТ-подразделения (CIO) собирается решить реальные проблемы и выбирает ITIL в качестве основы;
- руководство компании недовольно работой ИТ-подразделения и требует исправить ситуацию;
- у кого-то из людей, принимающих решения, есть желание приобщиться к «передовому опыту».
Последний вариант всерьез рассматривать не будем, так как отсутствие реальной цели ни к чему хорошему, скорее всего, не приведет.
Первые два варианта фактически имеют одну цель — улучшение работы ИТ-службы, но с политической точки зрения ситуации кардинально различаются. Вероятность того, что удастся реализовать такой проект без увеличения ИТ-бюджета, крайне мала. Затраты будут в любом случае — либо на расширение штата, либо на консалтинг, либо, что вполне вероятно, и на то и на другое. Если инициатива исходит сверху, гораздо проще обосновать дополнительные расходы, иначе придется защищать не только сам проект, но и необходимость его запуска. О том, как доказать экономическую эффективность проекта и разъяснить руководству, почему выбран подход ITIL, мы расскажем ниже.
Кто этим займется
Прежде чем браться за работу, необходимо понять, кто же ее выполнит. Ситуацию с нехваткой ИТ-персонала можно считать стандартной.
Для эффективного выполнения процессов требуется разработка регламентов, установка специализированного ПО, наличие сотрудников, занятых в оперативной работе процессов и управлении ими. В большинстве случаев собственных ресурсов будет недостаточно. Выходов два: наращивать штат или привлекать консультантов. Первое, естественно, дешевле, но если квалификация рядовых сотрудников сомнений не вызывает (в крайнем случае можно провести их обучение), то для управления процессами нужен прежде всего опыт.
Печально, но факт: на рынке труда фактически отсутствуют люди с опытом полноценного менеджмента процессов ITIL. Вся реальная компетенция сосредоточена в консалтинге, но и на этом рынке мало предложений, где кроме красивых обещаний имеется адекватное понимание предмета. Скорее всего, наиболее близким к истине будет подход, при котором одновременно используется консалтинг и идет «выращивание» собственных специалистов.
Зачем это руководству
Исполнители выбраны, бюджет спланирован, дело за малым — объяснить руководству компании, зачем на это тратить деньги. Цели проекта должны быть сформулированы на языке, доступном бизнесу. Пример постановки задачи:
- обеспечить простой и удобный механизм взаимодействия пользователей с ИТ-службой;
- пользователи должны иметь полную информацию о сроках рассмотрения их обращений;
- сроки и качество рассмотрения обращений должны быть приемлемы для пользователей.
Можно сколько угодно расписывать все прелести процессного управления, но бизнес разговаривает языком цифр, и если не продемонстрировать реальную финансовую привлекательность проекта, вероятность его утверждения минимальна.
Есть вариант пойти по классическому пути, описав текущую модель ИТ-процессов и оценив изменения для новой модели. Но на практике это займет слишком много времени и потребует огромного объема работы, которой заниматься будет просто некогда. Кроме того, нам придется оценивать влияние проекта не только на ИТ, но и на бизнес, следовательно, потребуется описание бизнес-процессов всей компании. На многих ли предприятиях оно имеется?
Поэтому предлагается простая схема, у которой есть одно важное достоинство — она благотворно воспринимается руководством. Кроме того, она более или менее корректна в оценках, а расчеты достаточно просты. Эффект от реорганизации ИТ-службы вычисляется исходя из предположения, что все сотрудники равноценно участвуют в формировании прибыли компании. Это, конечно, очень большое допущение, но в качестве грубой оценки оно вполне годится. Итоговая формула — экономическая эффективность реорганизации ИТ-службы — выглядит так:
{[Прибыль компании] * [Экономия времени простоя рабочих мест в месяц (ч)]} / {[Общее число рабочих мест] * [Продолжительность рабочего дня (ч)] * [Число рабочих дней в месяце]}.
В этой формуле сложнее всего определить параметр “Экономия времени простоя рабочих мест”. Его можно оценить с учетом двух составных частей: внешнего взаимодействия ИТ-службы и внутренних ее процессов, выделив в каждой их них несколько основных статей затрат.
Внешнее взаимодействие ИТ-службы
Инциденты
Экономия рабочего времени = [Среднее количество простаивающих рабочих мест на инцидент] * [Количество инцидентов в месяц] * [Изменение времени на закрытие инцидента]
Заявки на изменение
Экономия рабочего времени = [Количество заявок в месяц] * Изменение времени на подачу заявки]
Запрос информации о состоянии разрешения инцидента или выполнения заявки
Экономия рабочего времени = [Количество заявок и инцидентов в месяц] * [Изменение времени на подачу заявки]
Анализ деятельности ИТ-службы
Экономия рабочего времени = [Изменение времени на анализ начальниками отделов ИТ]
Уведомление об изменении статуса заявки или запроса на изменение
Экономия рабочего времени = [Количество заявок и инцидентов в месяц] * [Изменение времени на информирование]
Внутренние процессы ИТ-службы
Ускорение внутреннего обмена информацией. Пример: по статистике, у каждого ИТ-сотрудника в среднем уходит до часа рабочего времени на переадресацию задач и работ другим сотрудникам.
Накопление опыта и его доступность всем ИТ-сотрудникам — из-за отсутствия базы знаний о типовых проблемах одни и те же задачи часто решаются заново.
Отсутствие потерь времени высокооплачиваемых сотрудников на решение простых проблем. Пример: по статистике у каждого сотрудника отделов программирования и администрирования в среднем уходит до часа рабочего времени на общение с пользователями.
Гарантия непрерывного поддержания надежности ИТ-инфраструктуры. При неоптимальной организации ИТ-службы нет процессов, гарантирующих непрерывный мониторинг и прогнозирование возможных сбоев. Дать числовую оценку возможных потерь затруднительно, но в случае сбоев в работе сервисов, поддерживающих основные бизнес-процессы, потери будут значительными.
Финансовая предсказуемость. Экономия за счет минимизации незапланированных затрат на модернизацию оборудования. Дать численную оценку затруднительно.
Со стороны руководства могут последовать вопросы «Цели проекта ясны, а как насчет средств? Почему именно ITIL и что это такое?». Ответ на эти вопросы следует строить на прослеживании взаимосвязей между типичными проблемами в работе ИТ-подразделения и процессами ITIL, направленными на их устранение. В таблице показано, как это может выглядеть.
Взаимосвязь между типичными проблемами в работе ИТ-подразделения и процессами ITIL
| Проблема | Решение |
| Пользователь не контролирует процесс решения своей задачи, не знает, к кому обращаться. Скорость решения задачи зависит от ИТ-сотрудника, принявшего заявку; тратится лишнее время на решение типовых проблем пользователей (одна и та же проблема, попадая к разным ИТ-специалистам, решается заново). | Процесс управления инцидентами, единая точка контакта |
| Одни и те же сбои повторяются | Процессы управления проблемами и доступностью |
| Сбои в работе из-за не согласованных с руководством действий ИТ-сотрудников | Процессы управления изменениями и конфигурациями |
| Неудовлетворительная скорость решения ИТ-задач | Процесс управления уровнем услуг |
| ИТ-служба регулярно не готова к новым задачам бизнеса | Процесс управления мощностями |
| ИТ-подразделение не готово к форс-мажорным ситуациям | Процесс управления непрерывностью услуг |
Старт проекта
Итак, проект обоснован и определены исполнители. Что дальше? Ответ во многом зависит от текущего уровня хаоса в работе ИТ-подразделения, но главная идея — двигаться надо постепенно.
Общая схема реализации проекта приведена на рисунке. Первым процессом должен стать инцидент-менеджмент с элементами процесса управления уровнем услуг. До окончания запуска и 100%-ной отладки данных процессов делать что-либо еще категорически не рекомендуется.
<Рисунок >
Схема реализации проекта ITSM.
Под «элементами процесса управления уровнем услуг» имеется в виду определение каталога сервисов и времени их восстановления. Речь, конечно, не идет о полноценном соглашении об уровне услуг. На этом этапе время восстановления сервиса оценивается исходя из статистики работы ИТ-службы и не согласовывается с внутренними заказчиками. Конечно, вполне возможно остановиться только на регистрации обращений без привязки их к определенному сервису, а время исполнения определять персонально для каждого обращения. Но такой подход приведет, во-первых, к невозможности анализа статистики обращений, а во-вторых, каждый раз придется тратить время на оценку срока исполнения.
Анализируя существующую практику, можно сделать вывод, что период выхода процесса управления инцидентами на должный уровень — не менее шести месяцев. Под «должным уровнем» понимается не только отладка регламента обработки обращений пользователей; должен присутствовать полноценный анализ потока инцидентов. По итогам анализа необходимо провести соответствующие корректирующие мероприятия (например, выявление однотипных ошибок пользователей в информационной системе может повлечь за собой инициацию обучения или доработку справочной системы). Кроме того, поскольку любая организация имеет свою специфику, то и сам процесс управления инцидентами требует регулярной оценки на предмет внесения корректив в регламенты.
На первый взгляд регламент обработки инцидентов довольно прост, и его четкое исполнение затруднений не вызывает. Но сделать это гораздо сложнее, чем кажется. Любое налаживание контура управления неизбежно вызывает дополнительную нагрузку на сотрудников, которые ей всячески сопротивляются. Кроме того, придется бороться с налаженными неформальными связями между сотрудниками ИТ-службы и пользователями, из-за которых обработка обращений происходит, минуя стандартный регламент.
Дополнительные затруднения появляются в случае территориально распределенной компании. При наличии сколь угодно сильной вертикали власти региональное подразделение всегда остается маленьким государством со своими негласными законами, которые касаются и взаимоотношений с ИТ-службой. Общих рецептов здесь нет, но основной подход заключается в одновременном использовании как «кнута», так и «пряника». А именно, с одной стороны — регламентация с четко контролируемой финансовой ответственностью сотрудников ИТ-службы за исполнение, а с другой — разъяснительная работа о пользе единой точки контакта и формальной регистрации всех обращений. Причем разъяснение необходимо проводить как для ИТ-службы, так и для остальных сотрудников компании. Последнее крайне важно, так как первая реакция на формализацию обращений в ИТ-службу обычно сводится к фразам «развели бюрократию», «почему я не могу позвонить Васе, и он мне все быстренько исправит» и т. п.
Отрадно, что через некоторое время большинство начинает осознавать плюсы новой схемы. Пользователи обретают уверенность, что про их обращение как минимум не забудут и без согласования с ними никто не изменит установленный срок исполнения. ИТ-подразделение получает возможность работать системно, и у него появляется инструмент защиты от любителей каждые пять минут справляться о ходе решения их задачи, поскольку сроки выполнения фиксируются документально.
Роли в проекте
Обсудим вопрос неформального распределения ролей в ходе проекта и при дальнейшей эксплуатации его результатов. Основные этапы проекта таковы:
- обоснование;
- проектирование;
- внедрение;
- сопровождение.
Обоснование
На этом этапе есть следующие роли: разработчик экономического обоснования и переговорщик с бизнес-руководством. Обе эти роли рекомендуется делить между CIO и представителями выбранной консалтинговой компании, так как у них за плечами наверняка не один подобный проект и есть масса «домашних заготовок».
Проектирование
Разработчик процессной модели и регламентов. Гораздо быстрее, а главное, дешевле взять за основу типовой шаблон процессов и заготовки регламентов, чем разрабатывать все с нуля. На данных работах рекомендуется использовать опыт выбранной консалтинговой компании. Здесь есть масса неочевидных нюансов, и лучше их учесть заранее, чем «набивать шишки», делая все самостоятельно.
Тренер. Рекомендуется организовать массовое обучение ИТ-сотрудников основам ITIL на одном из существующих учебных курсов.
Внедрение
Группа прикрытия. Поскольку на данном этапе начнется серьезная перестройка работы ИТ-подразделения, это неизбежно отразится на пользователях разного ранга и степеней влияния. Не исключено, что некоторые из них будут недовольны и постараются так или иначе противодействовать ходу проекта. Следовательно, необходимо заранее заручиться поддержкой на самом высоком уровне.
Командир. Один из руководителей ИТ-подразделения, отвечающий за организацию процесса внедрения. В идеале это CIO.
Эксперт. Лицо, контролирующее ход внедрения и при необходимости оперативно вносящее изменения в процессную модель и внедряемые регламенты. Рекомендуется привлечь сотрудника выбранной консалтинговой компании.
Сопровождение
Менеджеры процессов ITIL. Как уже говорилось выше, для полноценного управления процессами нужен опыт. Если в качестве менеджеров процессов выбирать собственных сотрудников, с большой долей вероятности мы получим ситуацию, когда они выполняют только набор действий, предписанных инструкциями, и полностью погружены в текучку. При этом ни на аудит работы процессов, ни на их модернизацию квалификации уже не хватит. Как один из вариантов решения данной проблемы предлагается использовать внешнее управление процессами, т. е. передачу функций менеджеров процессов на аутсорсинг специализированной компании.
Что дальше
Во-первых, следует сделать паузу. В достаточно масштабной компании на стабилизацию процесса управления инцидентами уходит от шести месяцев до года. Далее рекомендуется перейти к процессам управления конфигурациями, изменениями и проблемами (см. рисунок).
Процессы управления конфигурациями и изменениями не могут существовать автономно. Чтобы контролировать изменения, необходимо понимать, что именно надо контролировать. С другой стороны, если вести учет конфигураций без регламентации проведения изменений, это приведет к невозможности поддерживать информацию о конфигурациях в актуальном состоянии.
Выделим следующие этапы в запуске процессов управления конфигурациями и изменениями:
- анализ существующих в компании бизнес-процессов и выделение среди них наиболее критичных для основного бизнеса — назовем их «критичные процессы»;
- выделение ИТ-сервисов, поддерживающих критичные процессы — назовем их «критичные сервисы»;
- определение перечня элементов ИТ-инфраструктуры, которые поддерживают функционирование критичных сервисов, — назовем их «критичные элементы»;
- перечень критичных элементов ложится в основу CMDB (Configuration Management Dataвase) и контролируется процессами управления конфигурациями и изменениями.
Необходимо отдельно остановиться на том, что цель запуска процесса управления конфигурациями не сводится к учету ИТ-оборудования. Это может быть побочным эффектом, но главное — взять под контроль основные элементы ИТ-инфраструктуры, оказывающие существенное влияние на бизнес. Более того, попытка внести в CMDB все ИТ-оборудование и прочие элементы ИТ-инфраструктуры, скорее всего, приведет к краху как процесса управления конфигурациями, так и процесса управления изменениями. Причина подобного результата — слишком большой объем работы, ложащийся на рядовых сотрудников ИТ-подразделения, так как они будут обязаны документировать все изменения в ИТ-инфраструктуре. Более грамотный подход заключается в постепенном наращивании зоны охвата CMDB.
Процесс управления проблемами не требует серьезных трудовых затрат на этапе запуска, но очень сильно зависит от личности менеджера процесса. Основная часть работы менеджера процесса управления проблемами сводится к анализу потока инцидентов и проблем. Эта работа не регламентируема в принципе и полностью зависит от аналитических способностей конкретного специалиста.
Следующий кандидат на запуск после процессов управления конфигурациями, изменениями и проблемами — процесс управления уровнем услуг. Но стоит ли вообще приступать к его внедрению? Не секрет, что уровень управленческой культуры большинства российских компаний не изменился со времен развитого социализма. В данной ситуации разработка каталога сервисов и остальных элементов SLA вполне реальна, а вот все, что касается согласования с бизнесом, составляет проблему. Вполне возможно, что достаточно остановиться на выделении тех самых «критичных сервисов» и описать для них неформальное и, возможно, неисчисляемое соглашение о качестве работы ИТ-службы — на языке, доступном бизнес-руководству.
И в заключение отметим, что мы охватили лишь часть процессной модели ITIL, но даже один полноценно функционирующий процесс управления инцидентами способен кардинально улучшить как работу ИТ-подразделения, так и отношение к нему со стороны бизнеса.
Советы внедрившего ITSM
|