Управление сервисом, или По газонам не ходить!

ITSM (IT Service Management, управление ИТ-обслуживанием) — подмножество библиотеки ITIL, описывающее процессный подход к предоставлению информационных технологий и обеспечению их использования. Так говорится в Wikipedia. Но чем больше приходится сталкиваться с сервисными процессами в организациях, тем скорее приходит понимание, что приставка IT в ITSM, в общем-то, ни к чему. Принципы, описанные в ITSM, весьма полезны для различных подразделений бизнеса, а  не только для ИТ. Понимание того, что в ИТ-отделе нужно что-то менять, приходит, когда количество возникающих проблем превышает некоторый внутренне определенный ИТ-менеджером порог. Обычно это случается, когда количество автоматизированных рабочих мест (АРМ) преодолевает некоторую величину, число клиентов компании подрастает, начинают появляться филиалы, со стороны бизнеса повышаются требования к непрерывности работы, срокам восстановления и т.д. Именно комбинация этих значений говорит, что организация переступила черту, после которой нужно затевать «перестройку» в ИТ. Мне не приходилось встречать однозначных правил, когда именно нужно начинать, хотя есть некоторые вехи, указующие на то, что уже пора. Скажем, если количество АРМ превысило сотню, то стоит что-то затевать для систематизации работы.

ИТ-менеджер должен постоянно прислушиваться к клиентам ИТ-отдела и бизнесу в целом, чтобы своевременно инициировать перемены. «Звоночками» для решительных действий могут стать жалобы на то, что ИТ-специалисты забывают решить какие-то проблемы пользователей, несколько «айтишников» начинают заниматься одной и той же пользовательской проблемой (позвонили одному, не было мгновенной реакции и тут же перезвонили другому), количество простоев увеличивается, ИТ-проекты не выполняются в срок и т.п.

Внедрение ITSM обычно начинается с процесса Incident Management (IM), сдобренного ПО для фиксации заявок (инцидентов) пользователей и их отработке ИТ-специалистами — Helpdesk/ServiceDesk. IM — один из основополагающих процессов, позволяющий решить наибольшее количество ИТ-проблем пользователей с минимальными затратами.

Жить хорошо, а хорошо жить — еще лучше

Впервые с проблемой обработки инцидентов мне пришлось столкнуться в 2003 г., когда количество рабочих место превысило сотню, появились филиалы (без сисадминов), да и количество ИТ-специалистов в головном офисе возросло. После продолжительной процедуры отбора остановился на достаточно простом OpenSource-решении Helpdesk OneOrZero.

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

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

Редко когда дизайнеры решают «наступить на горло собственной песне» и проложить маршрут там, где тропка уже утоптана и готова к облагораживанию. Выглядит, может, и не так эстетично, как с перпендикулярным решением, но заборчика для принуждения к порядку, скорее всего, городить не придется, потому как пользователи будут довольны и так.

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

Табличка «По газонам не ходить» действия не возымела, пользователи предпочитали протоптанные дорожки, игнорируя нововведение. После продолжительных мытарств пришлось начать «городить заборы»: запрещать ИТ-специалистам принимать заявки, не зафиксированные на Helpdesk. Пользователи продолжали звонить любимым «айтишникам», узнавали, что теперь без Helpdesk никуда, мысленно (и не только) рекомендовали идти ИТ-шникам…  со своими идеями, но все же начинали писать что-то. Они повторяли звонки с завидной регулярностью, видимо надеялись, а вдруг без Helpdesk начнут заниматься их проблемой. ИТ-шники были непоколебимы, хотя иногда нервишки сдавали. Со временем сотрудники пообвыклись и стали более благожелательно относиться к новому средству общения с ИТ-отделом. А новые сотрудники, в отличие от старожилов, без особых вопросов принимают требование о фиксации инцидентов через Helpdesk.

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

Жизнь налаживается

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

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

Сейчас появились достаточно качественные OpenSource-системы, автоматизирующие основные процессы ITSM, поэтому от капитальных затрат на софт можно уйти, существенно сократив стоимость внедрения. Например, стоит обратить внимание на интересную, написанную на Perl, систему OTRS (www.otrs.org), распространяемую под AGPL-лицензией, пока единственную из бесплатных, сертифицированную PinkVERIFY (http://www.pinkelephant.com/pinkverify/pinkverifytoolsetv3.htm) на соответствие 6 процессам ITIL. Для сравнения — Naumen Service Desk V3 имеет сертификацию только по 3 процессам. OTRS использует  — подразделения Philips, Toshiba, Lufthansa, NASA, Boeing, Nokia, Fujitsu и др. http://www.otrs.com/en/customers. К системе прилагается достаточно обстоятельная документация, в т.ч. для разработчиков, есть русская локализация, имеется интеграция с iPhone. Для желающих доступна коммерческая поддержка. Множество настроек позволяет достаточно легко адаптировать OTRS для нужд как ИТ-департамента, так и другого сервисного подразделения. Причем, в случае внедрения IM в варианте «без изысков» его стоимость будет стремиться к нулю. Имеет смысл начинать знакомство сразу с 3-ей версией OTRS, которая пока находится в стадии beta 2, но релиз намечен на конец года (прим. от 29.03.2011, уже доступен релиз OTRS 3.0.6 и модуля ITSM к нему). Несмотря на статус beta, работает достаточно пристойно, даже для запуска в «продакшн». Наличие исходников позволяет «бесшовно» интегрировать систему с корпоративным сайтом.

Порядок у продавцов

Отдел продаж, как показала практика, вполне типичное сервисное подразделение, к которому применимы подходы ITSM. Опыт превращения отдела продаж в, по сути, сервисное подразделение достаточно интересен.

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

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

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

Кабы я была царица…

Принципы, описанные в ITSM, на мой взгляд, идеально подходят для оптимизации работы госструктур. Не нужно ничего выдумывать, нужно просто брать и использовать отработанные в ИТ решения. Работа большинства госструктур состоит в предоставлении различных сервисов для большого количества граждан. Опыт взаимодействия с этими организациями показывает, что управление сервисом либо отсутствует, либо используется крайне ограниченно (скорее всего, только то, что настроено в системах документооборота). Слабое использование подобных механизмов в государственных структурах приводит к полному отсутствию или ограниченному контролю за работой чиновников как со стороны их клиентов (граждан), так и руководства.

Например, при работе с механизмом подачи обращений на сайте президента (http://letters.kremlin.ru/) заявитель не может отследить движение запроса (инцидента) по инстанциям (эскалацию). Будет дан ответ или нет, зависит от ведомства и конкретного чиновника, к которому поступил запрос. Но реакция чиновников не должна определяться квалификацией работника госаппарата. Клиент госорганов должен видеть организацию, а не отдельную персону. Использование механизмов управления сервисом позволило бы повысить прозрачность работы госструктур, появилась бы возможность контроля за действиями сотрудников госаппарата, в т.ч. со стороны простых граждан.

Транспорт – это пример сервиса, контролируемого госслужбами. Для него есть прописанный SLA, регламентирующий качество предоставления услуги гражданам и выражающийся, как минимум, в параметрах «интервалы движения», «время работы» и т.п. автобуса определенного номера. Этот SLA частенько нарушается, что свидетельствует о том, что цифры «взяты с потолка» и не учитывают реальную ситуацию на дорогах, либо/и есть работа для процесса Problem Management. Прием заявок (регистрация инцидентов) от граждан по качеству предоставления услуг транспортниками неупорядоченный («книга жалоб и предложений находится в следующем автобусе») и слабо контролируемый. Как отработали заявку неясно, хотя в случае официального обращения можно надеяться на получение официального письма исключительно по почте (вот куда уходят деньги налогоплательщиков – на марки). В случае использования ПО ITSM (того-же OTRS вполне достаточно) регистрация подобных заявок (жалоб и предложений) фиксируется в системе (прием по телефону, e-mail/ почте, регистрация через web-интерфейс и др.) и дальше в системе прозрачно отслеживаются все инциденты, связанные с этим сервисом. Если количество сходных инцидентов превышает некоторый порог (например, один и тот-же автобус регулярно нарушает SLA) – это повод для Problem Management.

Не очевидно, на что уходят деньги, выделенные для реализации программы электронного правительства, если даже такую относительно несложную вещь, реализуемую бесплатными OpenSource-системами, не могут внедрить в госорганах. Смею предположить, что ресурсы тратятся на реализацию масштабного, недешевого и долгоиграющего проекта, но учитывая динамику внедрения соответствующих систем в этих структурах, «жить в эту пору прекрасную уж не придется ни мне, ни тебе». Перед внедрением чего-то грандиозного стоило бы прибегнуть к какому-нибудь «костылю» («заплатке»/временному решению/workaround), дабы уже сейчас облегчить жизнь народу, чтобы можно было спокойно дожидаться окончания quest-а под названием  «Электронное правительство».

Связь без брака?

Продвинутые высокотехнологичные компании телеком-сектора, как и госструктуры, также не особо спешат использовать механизмы SM для систематизации взаимодействия с клиентами. Здесь ситуация абсолютна неясна, т.к. клиенты этих компаний — подготовленные люди, готовые к использованию подобных систем. В лучшем случае есть возможность пообщаться по e-mail и в особо «продвинутых» компаниях — по ICQ. E-mail – штука хорошая, только слабо контролируемая. Кроме того, активное использование спам-фильтров снижает гарантию доставки письма до адресата. В результате приходится делать «контрольный звонок в голову», если «продажник» не отвечает продолжительное время. Получается, что клиент ухаживает за продавцом, хотя, по идее, должно быть наоборот.

С началом кризиса сокращения персонала в телекоме были достаточно серьезными. Для корпоративщиков оптимизация персонала операторов связи особенно заметна по усилившейся «текучке» продавцов. Часть начатых проектов застопорилась из-за того, что сотрудники неожиданно пропали, просто перестав реагировать на письма. Некоторые операторы даже не удосужились перевести e-mail уволенных сотрудников на тех, кто остался в строю. В результате масса времени ушла на поиск новых контактов и на то, чтобы ввести их в курс дела. В случае использования мало-мальски продвинутой системы, поддерживающей процесс IM, в купе с CRM таких проблем не должно было быть в принципе. Получается, что даже крупные операторы все еще не доросли до систем такого уровня, хотя это очень странно.

Покупка в несколько кликов?

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

Обычно наблюдается примерно такая картина: первоначальный запрос отрабатывается определенным агентом, и если он отсутствует, другой агент с трудом ориентируется в продажах коллеги. Нет никаких жестко контролируемых регламентов по взаимодействию с клиентами. Общение с агентом происходит по электронной почте, зачастую с e-mail адресов, размещенных на публичных почтовых системах, т.е. вся переписка хранится в личной почте сотрудника и руководитель или заменяющий не в состоянии оперативно отследить, о чем шла речь в переписке с клиентом. Обещания, данные клиенту, не выполняются из-за забывчивости агента. И его тяжело в этом винить, т.к. системы интернет-магазинов, похоже, не поддерживают функционал напоминания, а клиентов на одного сотрудника может приходиться достаточно много. Использование в таких компаниях типовой системы Helpdesk/ServiceDesk, в идеале интегрированной с CRM, позволило бы вывести взаимоотношения с клиентом на новый уровень, повысив конкурентоспособность.

Заключение

Подобных примеров, когда рекомендации ITSM могли бы принести реальную пользу бизнесу, можно найти немало. К сожалению, ITSM существуют давно, а вот видимых примеров использования не так уж и много. Часто получается как в детской песенке: «нормальные герои всегда идут в обход», вместо того чтобы выбирать короткий маршрут и использовать готовые отработанные решения.

Статья опубликована в журнале «IT manager» №9, 2010 г.

Опубликовать в Facebook
Опубликовать в Google Plus
Опубликовать в LiveJournal
Опубликовать в Мой Мир
Опубликовать в Одноклассники
Опубликовать в Яндекс
Запись опубликована в рубрике IT решения для бизнеса. Добавьте в закладки постоянную ссылку.