Готовя тему номера, посвященную автоматизации процессов в ИТотделе, мы много говорили с ИТдиректорами самых разных компаний. Несколько серьезных дискуссий состоялись на CIO Summit Ural 2007, организованном Клубом профессионалов АСУ Урала, данной теме было посвящено заседание клуба CIO металлургии и несчетное количество кулуарных бесед. Все эти встречи позволяют сделать несколько обобщений.
Детально о service desk
Никого уже не нужно было агитировать за сервисную службу — вопросы эффективной организации service desk волнуют практически всех. При этом темы, которые обсуждают ИТдиректора, касаются конкретики и деталей. Например, как добиться, чтобы 85—90% инцидентов закрывалось на первом уровне поддержки, какова должна быть квалификация у диспетчера этой линии и насколько это дорогой ресурс? Много вопросов связано с тем, откуда вообще брать сотрудников первой линии поддержки. Часто ИТдиректора высказывают радикальное мнение — старых уволить и набрать новых, ведь работа service desk во многом связана с вводом информации, и ИТдиректора нередко сталкиваются с тем, что «старые» ИТкадры не хотят тратить время на ведение базы данных инцидентов, приведение в порядок базы данных конфигураций и т. д. Однако многие полагаются на эффективные схемы мотивации. Другой аспект вопроса касается культуры общения с сотрудниками собственной компании — как научить ИТперсонал видеть в них нужных клиентов, а не назойливых просителей? Ситуации, когда именно вследствие этого для работы на первой линии service desk набирают новых специалистов, причем, как правило, женщин (да еще желательно с психологическим образованием — такую рекомендацию я слышал от одного из ИТдиректоров), довольно часты.
Еще один хороший вопрос — как регламентировать взаимоотношения первого и второго уровней. Типовой ответ таков: «Если диспетчер первой линии поддержки знает, как решить возникшую проблему, он отвечает, если нет — регистрирует запрос и передает его на второй уровень». Но такое отношение быстро превращает работу первой линии в перекидывание ответственности на вторую. Как же сделать, чтобы первый был заинтересован в закрытии инцидентов, а последний не оказался «крайним» ответчиком за все инциденты?
На втором уровне зрелости
Однако большинство обсуждений, которые велись и на CIO Summit Ural 2007, и на других встречах ИТдиректоров, очень редко выходили за рамки управления инцидентами. Создавалось ощущение, что все с большим интересом разговаривают о service desk, но дальше не продвигаются. Даже сильно связанное с управлением инцидентами управление конфигурациями (читайте интересное интервью с Вадимом Бекетовым в этом номере) нередко инсталлируется в компаниях «по умолчанию» и не служит реальным инструментом сокращения времени реакции на инциденты. Что же говорить о других процессах ITIL? Управление изменениями, доступностью, SLA, совет по изменениям — всё это в западных компаниях внедрено, но в российскую практику, увы, пока не входит. Крайне мало отечественных фирм, которые дошли до формализации SLA с бизнесом, и буквально по пальцам можно пересчитать тех, кто смог подсчитать затраты на ИТсервисы во времени и деньгах и таким образом действительно научился управлять своими ресурсами (читайте об этом «круглый стол»).
С чем это связано? Ответ напрашивается сам: со степенью зрелости российских компаний, причем зрелости не только ИТотдела, но и бизнеса в целом. Пока речь идет о процессах, минимально затрагивающих бизнес, например о service desk, этот фактор практически не играет, но как только мы перейдём к управлению доступностью и SLA, он непременно выйдет на первый план. Интересно, что ряд ИТдиректоров при обсуждении ITSMпроекта уже напрямую обсуждает такую его цель, как повышение культуры топменеджмента предприятия (опять отсылаю к «круглому столу»).
Однако повальная незрелость российских компаний для ITSMпроектов — это сильный перебор. Более продуктивно будет связать степень продвижения по ITSMпути с моделью зрелости ИТпроцессов по COBIT. Второй уровень зрелости ИТпроцессов (если не принимать во внимание фазу хаоса) — это их повторяемость и регламентация, хотя бы в смысле самых примитивных мер по управлению ИТ. На мой взгляд, для начала продвижения по ITSMпути достаточно находиться на таком втором уровне и не нужна какаято более высокая степень зрелости. А наблюдения показывают, что этой второй степени зрелости достигли уже очень многие компании и значит достаточно зрелы для небольших ITSMпроектов.
