Управление услугами ИТ: первые шаги и первые ошибки

Заурбек Алехин,
директор департамента консалтинга "Ай-Теко"

Тема управления услугами ИТ обсуждается в российском ИТ-сообществе уже более трех лет. И если изначально это было в большей степени теоретизирование, то сегодня, пожалуй, уже можно обсуждать практические результаты работ по данному направлению, включая опыт компании "Ай-Теко".

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

На данный момент сложились два толкования понятия "управление услугами ИТ". В узком смысле - это деятельность, непосредственно связанная с контролем состояния предоставляемых услуг и выполнением некоторых допустимых управляющих воздействий. В более широком смысле - это любые действия, соответствующие рекомендациям ITIL и призванные в конечном итоге обеспечить управления в приведенном выше узком смысле данного понятия. Расширенное понимание становится все более распространенным; при этом, например, внедрение даже отдельных компонентов управления конфигурациями рассматривается как этап построения управления услугами ИТ. С понятиями обычно не спорят, поэтому в дальнейшем мы будем придерживаться именно такого подхода.

Основные работы были направлены на улучшение ситуации в наиболее уязвимых местах в деятельности служб ИТ, к которым традиционно относится прием заявок и управление ими, а также учет имеющихся ИТ-активов заказчика. С точки зрения ITIL сюда можно отнести создание механизма Service Desk, внедрение управления инцидентами и управления конфигурациями. Определенные шаги предпринимались для регламентирования порядка внесения изменений (в терминах ITIL - управление изменениями).

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

Управлять заявками или управлять инцидентами?

Действительно, велик соблазн создать службу Service Desk и свалить все заявки на нее, избавившись от этой головной боли. Принципиально никто против этого не возражает, но существуют некоторые детали, на которые следует обратить внимание. Какова основная цель создания службы Service Desk и внедрения процесса управления инцидентами?

Большинство компаний однозначно отвечают, что основной целью является обеспечение максимально быстрого устранения инцидентов. Если так, то основные усилия (по крайней мере на начальном этапе) должны быть обращены именно на построение контролируемого и оптимизируемого процесса управления инцидентами, на отслеживание необходимых для этих целей метрик и разработку механизмов улучшения целевых показателей. К сожалению, нередко на эти аспекты внимание не обращается, а цель подменяется на "своевременную регистрацию всех заявок клиентов и передачу их исполнителям", что несколько отличается от сказанного ранее.

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

В данном случае можно рекомендовать на начальном этапе четко ограничить состав принимаемых заявок инцидентами и направить максимальные усилия на остальные компоненты процесса: контроль сроков исполнения, методы эскалации, способы оптимизации контролируемых параметров (как правило, это время обработки и время передачи инцидента в рамках процесса). Только добившись здесь положительных результатов, можно будет расширять сферу ответственности Service Desk и обрабатывать иные заявки, поскольку то, что мы умеем делать хорошо, мы уже умеем контролировать и улучшать.

Как должна быть организована единая точка контакта?

Существует две крайности в данном вопросе. Во-первых, многие некорректно понимают под термином "единая точка контакта" конкретно одного оператора-телефониста c одним-единственным телефоном. На самом деле это конечно жене так. ITIL предполагает использование самых разных способов взаимодействия между пользователями и службой ИТ. А "единая точка" подразумевает, что обращения по всем каналам обрабатываются в итоге одним и тем же способом. Более того, обмен информацией, поступающей по различным каналам, осуществляется в реальном времени - и это важно! Только обеспечив быстрое поступление информации из всех источников в единое хранилище, мы можем добиться согласованности действий всех сотрудников и независимости способа обработки от первоначального канала взаимодействия.

С не совсем корректным толкованием положения ITIL о множественности каналов взаимодействия связана и вторая группа ошибок. Типичная ошибка - отказ от выделения единых для всех пользователей каналов взаимодействия под. В таких случаях подразумевается, что любой контакт с любым представителем службы ИТ - и есть тот самый канал, а значит, все и так хорошо и вполне соответствует рекомендациям. Но обеспечено ли в этом случае четко обозначенное нами требование по обмену информацией? Вовсе нет! И в результате следует признать, что единая точка контакта здесь не обеспечена! В качестве доказательства просто представим себе ситуацию, что пользователь задал вопрос одному сотруднику ИТ, и пока тот думает - потребовал ответ у другого. В худшем случае пользователь получит два противоречивых ответа, что может стать основанием для предъявления претензий к работе службы ИТ.

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

А нужна ли вообще единая точка контакта?

Действительно, многие пользователи уже давно тесно взаимодействуют с отдельными сотрудниками службы ИТ, и особых неприятностей это не вызывает. Зачем ломать сложившийся порядок? Может быть, предпочтительнее оставить все как есть, добавив лишь возможность обращения в службу Service Desk? Хотя бы на первое время?

И в данном случае мы не станем изобретать велосипед, а обратимся к здравому смыслу и к первоисточнику. Будет ли организация четко знать о текущем состоянии заявки, если о ней знает только один специалист? Да, но только в том случае, если он ее зарегистрирует непосредственно при получении. Станет ли он так делать? Скорее всего нет, поскольку будет занят ее решением, а регистрация для него - не основная задача. Что будет происходить, если заявка связана с некоторым инцидентом, затрагивающим более одного пользователя? Пользователи начнут обращаться в общем случае либо к другим специалистам ИТ, либо на Service Desk. При этом будет происходить дублирование усилий на устранение инцидента или (что хуже) возникнет ситуация, когда "мы вам уже сообщали, а вы ничего не знаете". Реально кто-то конечно же знает, но больше никому об этом не говорит.

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

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

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

Кто должен быть оператором первой линии Service Desk?

Велик соблазн использовать уже имеющиеся ресурсы в качестве операторов первой линии Service Desk. Действительно, большинство крупных компаний имеют в составе службы ИТ некоторую группу (а иногда и несколько групп), которую именуют, например, "сменные администраторы" или как-то похоже. Определяющим признаком является то, что они, как правило, имеют свою дежурную смену, уже сегодня принимающую какие-нибудь звонки (по своему определенному направлению) и в дальнейшем обрабатывающую соответствующие заявки. Вроде бы выгоды налицо: нет необходимости пересматривать штатное расписание, люди и так все вокруг знают...

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

Конечно, если организация небольшая, создание отдельного подразделения и расширение штата - вопрос довольно сложный. Но для таких организаций в рамках ITIL имеются особые рекомендации - отдельный том под названием IT infrastructure Library practices in small IT units. В общем же случае деятельность персонала Service Desk достаточно сложна и ответственна, и организовать ее целесообразно на базе выделенной структурной единицы с необходимым штатом. И поскольку ключевая задача персонала первой линии службы поддержки - это общение с пользователями, серьезным пожеланием остается именно умение общаться и понимать, что хочет сказать пользователь. И именно эти качества нужно считать приоритетным при подборе персонала на соответствующие должности.

Зачем нужен дорогой продукт автоматизации процессов?

Казалось бы, если поставлена задача создания Service Desk и построения управления инцидентами (совсем не обязательно очень хорошего), какой смысл тратиться на продукты? Почта, Word, Excel - разве этого не достаточно? А затраты на новые средства - ох какие немалые...

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

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

Можно ли положиться на процессы, диктуемые продуктами?

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

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

И все же в данном подходе есть рациональное зерно, которое, кстати, используется и при внедрении систем класса ERP, - это так называемый "экспресс-метод". Суть его - в проведении сокращенного обследования для определения того, насколько применимы в данной конкретной компании стандартизованные процессы без их дополнительной настройки. Если итогом обследования окажется вывод о применимости - никаких серьезных проблем скорее всего не возникнет, и можно будет действовать таким методом. Но если обследование покажет неприменимость подхода - лучше даже не делать попыток: практика говорит о том, что средства будут потрачены напрасно и идея - дискредитирована.

Куда делся энтузиазм менеджера инцидентов?

Предположим, компания старательно выполнила все рекомендации и приложила максимум усилий для организации управления инцидентами. Создана служба Service Desk, разработаны необходимые регламенты и инструкции, обучен персонал, предоставляется отчетность по процессу. Первые пару месяцев все воспринимают деятельность в рамках процесса с интересом, но постепенно все стало обыденным и соблюдение ряда правил уже начало вызывать негативные эмоции. Отчеты никто уже не читает, дальнейшего развития не происходит. Похоже, каких-либо особых преимуществ для всей службы ИТ в целом построение данного процесса не дало. Может быть, и не стоило тратить деньги и тормошить всю структуру?

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

Только восприятие руководством идей ITIL как своих собственных, стремление изменить работу всего персонала, включая свою собственную, может обеспечить прогресс в организации деятельности служб ИТ. Возможно, компания просто не достигла того состояния, когда потраченные усилия стали приносить действительно пользу, возможно, ожидания были завышенными. Следует более точно прогнозировать результаты и в первую очередь добиваться максимального понимания. Если отчеты никто не читает, - значит, они никому не нужны. А это значит, что следовало разрабатывать другие, действительно востребованные отчеты! Почему же с самого начала не были выяснены истинные потребности? И почему теперь мы удивляемся полученному результату?

Зачем разрабатывать какие-то документы?

Все и так понятно, а разработка документов только затягивает и удорожает совершенствование процессов. Конечно, у консультантов свой интерес, и почему просят документы они - понятно. Но если все делать собственными силами, бумаги - это совершенно лишний элемент!

В древние времена, когда еще не была изобретена письменность, информация распространялась устно, возникали легенды и предания. Что из них правда, а что вымысел - загадка, разгадывать которую человечеству предстоит еще долгие годы. Ситуация усложняется еще и тем, что на каждом этапе очередной рассказчик добавлял к истории что-то свое, интерпретировал ее с учетом своих ощущений и своего понимания мира. Конечно, можно обратить внимание на то, что всякая компания - это живой, развивающийся организм, с постепенно меняющимися правилами, отношениями, взглядами. Тем более важно периодически делать "слепки", описывающие текущие принципы взаимодействия и порядки. Это даст возможность не только обучать и оценивать персонал, но и анализировать возникающие трудности, предлагать пути дальнейшего движения, исключать "зацикливания", когда с уже ранее проверенным и признанным неудачным подходом продолжают экспериментировать.

Отдельным пунктом стоят описания настроек систем автоматизации. Их наличие - это возможность при необходимости полностью восстановить систему, проанализировать причины сбоев. Это также снижение зависимости от конкретного администратора.

Вообще говоря, документов не должно быть слишком много, они должны быть действительно необходимы. Они должны быть простыми и понятными. Они должны предполагать возможность изменения и совершенствования. Но они должны быть!

Разработать и утвердить документы, затем издать приказ

Зачем тратить время на внедрение? Во всякой организации есть механизмы для принятия решений и доведения их до исполнителей. Далее остается только проследить, чтобы установленные в нормативной документации требования четко исполнялись, - и задача будет полностью решена. Ничего с ними не случится - в памятках опишем все подробно, затем - пусть сами читают и выполняют. А мы проследим.

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

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

***

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

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