Как правило, построение процессов ITIL компании начинают с управления инцидентами и создания service desk. Но опыт Вадима Бекетова, руководителя отдела АСУТП ФССИ «Краснодеревщик», показывает, что можно добиться гораздо большего успеха, если одновременно внедрять и другие процессы. И особая роль здесь принадлежит управлению конфигурациями. Интервью у Вадима Бекетова взято во время конференции CIO Summit Ural 2007.

Intelligent Enterprise: Что с вашей точки зрения препятствует автоматизации ИТ­службы? Какие мифы и иллюзии мешают построению ИТ­процессов в области поддержки пользователей?

Вадим Бекетов: Первый миф, на мой взгляд, — это дороговизна ПО и услуг консультантов, а также большая продолжительность и сложность внедрения. В настоящее время появился необходимый класс программного обеспечения для поддержки процессов ITIL/ITSM и организации единой точки контакта с пользователями — службы service desk. Так, бюджет нашего проекта составил 2000 долл., и при этом всего за три месяца была сформирована база конфигураций, список сервисов, организована служба поддержки. В результате внедрение окупилось в несколько раз в течение первого же года.

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

Еще распространен такой миф: «У меня работают квалифицированные сотрудники, кандидаты наук и специалисты MCSE, и им не нужна единая точка контакта с пользователями, не нужна какая­то особая служба, они эффективно решают проблемы, достаточно позвонить напрямую». Непрозрачные бизнес­процессы в области ИТ в условиях жесткой рыночной конкуренции не позволят эффективно бороться со скрытыми потерями. Время высокооплачиваемых сотрудников зачастую будет расходоваться на решение банальных вопросов. А вы как руководитель просто будете транжирить деньги, отпущенные вам бизнесом. Кроме того, при отсутствии единой точки контакта с пользователем бульшая часть времени при устранении сбоев приходится на согласование работ между службами.

Наконец, последняя иллюзия: «Я хорошо понимаю, что происходит в области обслуживания пользователей». Это классическое заблуждение руководителей. На самом деле опросы показывают, что чем ближе стоит специалист к источнику проблем, тем ниже его оптимизм, поскольку он знает реальное положение дел в компании. Отсутствие достоверной статистики по отказам делает невозможным принятие управленческих решений. В моей практике был, например, случай, когда в течение долго периода автоматизированная система работала вполовину своей производительности из­за остановок, вызываемых пылью. Вопрос выделения средств на реконструкцию системы вентиляции не решался до тех пор, пока техническому директору не была представлена статистика по инцидентам.

Эффект от внедрения HP OpenView Service Desk по данным IDC

Как свидетельствуют результаты опроса, проведённого компанией IDC по всему миру, после внедрения Service Desk отмечается следующий эффект (усреднённые данные):

  • производительность ИТ­среды повышается на 14%;
  • компании тратят на 75,5% меньше рабочего времени на поиск и устранение неисправностей;
  • затраты рабочего времени на управление уровнем обслуживания сокращаются на 20%;
  • управление изменениями требует на 41,1% меньше рабочего времени;
  • время на поддержку справочной службы сокращается на 29%;
  • доля вызовов, вопросы по которым удаётся решить на первом уровне поддержки, повышается с 63% до 76%;
  • время простоев снижается на 57%;
  • количество инцидентов уменьшается на 45%.

Кроме помощи в обосновании инвестиций на замену или внедрение оборудования аналитика по инцидентам может стать настоящим подспорьем в развитии компании. Любой ИТ­руководитель вспомнит массу примеров, когда новая система или новая её версия в момент внедрения вызывала волну протестов и претензий к ИТ­службе: «Вообще ничего не работает». В моей практике был случай, когда меня вызвали на совещание к генеральному директору по поводу якобы не работающей новой системы учета движения полуфабрикатов. Ключевые пользователи, мягко говоря, не были заинтересованы в ее внедрении, поскольку она не позволяла скрывать брак. Как обычно, во главе стола — генеральный директор, по одной линии — сторона нападения (производственники), по другой — обороняющиеся (группа внедрения), и стандартная фраза: «Вечно всё не работает». Я успел распечатать статистику инцидентов и говорю: «Давайте анализировать. Вот, было десять отказов. По одному из них рапорт задержали на день, но технолог в вашем отделе не ввел вес заготовки. Было такое? Было. А вот здесь неправильно указали группу продукции, и в сводке в общем тоннаже она попала в другую колонку. Такое было? Тоже было. А вот ещё один отказ — система не работала, отказала сеть, устранение заняло 20 минут, вот данные. Так к кому должны быть вопросы?» Только таким анализом инцидентов удалось отстоять необходимость внедрения оперативного управленческого учета и внедрить эту систему.

Расскажите, какие цели преследовал ваш проект и какие задачи вы хотели решить.

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

Когда я знакомился с мировой практикой, я обнаружил интересные цифры, показывающие эффект от внедрения service desk (см. врезку. — Прим. ред.). Я предполагал, что сокращение рабочего времени на 75% — это западные данные, у меня же вряд ли такое получится. Но я ошибся. На самом деле по окончании проекта время устранения инцидентов у нас сократилось больше, чем на 75%. За счет чего?

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

Чего мы добились в результате? Если раньше в случае отказа сервиса или его установки на новое рабочее место нужно было привлечь либо специалиста по прикладной программе, либо администратора, чтобы восстановить настройки, то теперь есть инструкция, в которой конкретно сказано, как установить тот или иной сервис и какие настройки нужно сделать. За счет этого время развертывания системы или новых рабочих мест сократилось в несколько раз. При отказе систему можно восстановить очень быстро по паспорту рабочего места, где указаны все его спецификации, и инструкциям. Мы уже забыли о таких инцидентах, которые требуют трёх­четырёх дней для устранения — то нет системной платы, так как она вовремя не поставлена, то заболел специалист. Теперь наши сотрудники могут нормально уходить в отпуск, поскольку критичная необходимость присутствия специалиста по какой­либо системе практически снята.

Должен отметить и ещё один момент: как правило, построение процессов ITIL компании начинают с управления инцидентами и создания service desk, и это вполне оправданный подход. Но на мой взгляд, наибольшего успеха добиваются те, кто осуществляет комплексное внедрение и других процессов — управления конфигурациями, доступностью и непрерывностью.

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

Мы можем снизить и время устранения инцидента — за счет четкого описания конфигурации, определения типовых рабочих мест и процедур восстановления данных. Централизованное хранение данных позволяет обеспечить их быстрое восстановление в случае отказа системы.

Кроме того, надо отметить, что очень важно от реактивного управления — чиним, когда сломалось, — перейти к проактивному, т. е. к анализу структуры инцидентов, слабых мест, когда вы смотрите, где еще есть аналогичное оборудование, и принимаете меры, чтобы ничего подобного больше не случилось. И здесь я хотел бы обратить внимание на методику анализа дерева сбоев — Fault Tree Analysis, или FTA, описанную в библиотеке ITIL, а также на историю работ, привязанную к элементам конфигурации: скажем, год назад настраивали какую­то систему, о чем сейчас уже не вспомнишь, а это может быть важно для устранения нового инцидента и очень эффективно работает.

Есть ли у вас какие­то количественные показатели эффекта?

В результате реорганизации высвободился специалист по разработке ПО; ремонтом, техническим и профилактическим обслуживанием трёхсот автоматизированных рабочих мест, заправкой расходных материалов занимаются два инженера, один из которых одновременно является руководителем службы. Многие не верили, что мы сможем обслуживать парк в 300—350 машин и большое количество сервисов такими небольшими силами. Максимальное время восстановления при любых отказах, развертывание новых рабочих мест определяется формулой «до следующего рабочего дня», а время устранения типичных отказов приближено к теоретически минимально возможному. Например, перенастройка рабочего места при модернизации компьютера проходит вообще без простоя пользователя. По окончании его трудового дня дежурный инженер, работающий по «железнодорожному» графику, забирает системный блок, и на следующий день сотрудник приходит на своё рабочее место и включает уже настроенный компьютер с полностью сконфигурированным ПО. По некоторым отказам среднее время устранения инцидентов у нас снизилось на порядок — с трех дней до пятнадцати минут. Ну и кроме того, по моим субъективным ощущениям высвободилось 50% рабочего времени, которое вместо решения текущих вопросов можно посвятить вопросам развития.

Каким образом вы доказывали менеджменту оправданность и необходимость проектов?

При обосновании подобных проектов есть одна трудность — отсутствие статистики до внедрения. Подсчитать эффект от проекта, на мой вгляд, можно по шести параметрам: экономия ФЗП, эффективность использования ИТ­бюджета, снижение оплачиваемых простоев, уменьшение числа отказов, снижение времени простоев, сокращение затрат на обучение сотрудников. Обычно я применяю наиболее заметный показатель, например фиксирую время простоя критических сервисов компании и рассчитываю стоимость простоя. А затем можно попробовать применить мировой опыт по сокращению на 75% времени устранения инцидента. Однако бюджет нашего проекта был не того масштаба, чтобы готовить инвестиционное обоснование. Есть распространенное заблуждение, что постановка ITSM­процессов связана с дорогими и комплексными системами. Но на мой взгляд, качество реализации процессов никак не коррелирует со стоимостью закупленного ПО. Наше решение мы делали на основе недорогой системы ServiceDesk Plus (затраты на лицензии составили 60 тыс. руб). При этом реализованы service desk и полноценное управление инцидентами, каталог сервисов и учет показателей работы технических служб в привязке к ним, управление конфигурациями и работами. А вот на обучении ключевых сотрудников в службе экономить, уверен, не нужно. В нашем проекте, например, затраты на обучение двух сотрудников в «Академии АйТи» вдвое превысили стоимость лицензий.