Преимущества сервисного подхода

Легко ли люди расстаются с деньгами, если не знают, за что платят? Легко — в случае оплаты услуг магов и прочих мастеров манипулирования, а если речь идет о материальном мире, то просьба заплатить деньги только за то, что «вами занимались», обычно энтузиазма не вызывает. ИТ перестали быть чем-то потусторонним еще полвека назад, однако с финансовой точки зрения ситуация здесь до сих пор напоминает оплату оккультных услуг — счета за то, что «вами занимались», распространены практически у всех провайдеров ИТ-сервисов. Как это выглядит на практике? Приходит отчет от провайдера со списком из десятка позиций, с указанием услуги, к примеру, «Устранение инцидента, срок выполнения строго меньше граничных значений в SLA». На вопрос «Что было сделано?» получаем ответ «Перегрузили сервер приложений», и так десять раз в течение месяца за немалые деньги. При ближайшем рассмотрении выясняется, что никакого «Устранения инцидента» на площадке заказчика не было, а реальные трудозатраты составили чуть больше получаса, справедливой стоимостью в несколько сотен рублей. Конечно, на первый взгляд кажется, что проблему заказчика все-таки решили, однако на деле устранили лишь ее последствия, а заказчик хочет в первую очередь, чтобы больного вылечили, а не просто сбивали температуру — ему не нужен десяток устраненных сбоев в месяц, а нужно, чтобы их вообще не было. Применительно к SLA время реакции выдержано, но к качеству и стоимости услуг заказчик вполне может предъявить претензии.

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

До недавнего времени заказчик, как правило, занимал такую позицию: «Мне ни к чему знать ваши ИТ-подробности, я хочу заплатить деньги за то, чтобы все хорошо работало». Но тут возникает проблема: как определить, что значит «все хорошо работает», особенно когда исполнитель говорит, что все хорошо, а представители заказчика — что нет. При этом обе стороны приводят весьма веские аргументы в свою пользу.

Цели проекта

После этой преамбулы можно сформулировать одну из целей проекта «Каталог услуг», которая состоит в создании возможности продавать страховые продукты с использованием корпоративной информационной системы. Мы рассматриваем услугу как набор работ, имеющий ценность для заказчика, пакет услуг составляет сервис, а каталог сервисов — это фактически пакет услуг из каталога услуг, его верхний уровень (см. рисунок). В нашей реализации каталог сервисов рассматривается как верхний уровень общего каталога услуг. По сервису заключается внутреннее соглашение SLA, которое определяет пакет услуг из каталога услуг, условия и параметры их предоставления.

Восстановление работоспособности такой системы – это ИТ-услуга, обычно состоящая из набора работ, оформленного заданиями (work order). Цель проекта в ОАО «Альфастрахование» – обеспечение прозрачности работы департамента ИТ. Задача — объяснить на понятном внутреннему заказчику языке, за какие сервисы он платит, сколько эти сервисы стоят и почему, насколько качественно они были оказаны.

Такую задачу нельзя решить, не разработав каталог услуг, поскольку без детализации проделанных работ заказчик не поймет ни объемов, ни сроков, ни содержания работ. А можно ли организовать и запустить процесс управления инцидентами без каталога услуг? Да. В 2005-2006 годах мы внедрили систему HP OpenView Service Desk с подобием каталога услуг на уровне «починили машинку», причем процессы управления инцидентами и проблемами работали весьма эффективно. Более того, аналогичные процессы внедряют сегодня многие крупные компании и интеграторы, и, как правило, эти процессы начинают работать весьма эффективно, действительно повышая качество обслуживания внутренних и внешних клиентов. Так стоит ли овчинка выделки?

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

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

На вершине пирамиды находится заказчик, которому доступны сервисы – конкретная информационная система или инфраструктура, предоставляемые в соответствии с соглашением об уровне обслуживания (Service Level Agreement, SLA).

В сервисе имеется конечный набор предоставляемых услуг, выполнение каждой из которых имеет ценность для заказчика. Услуга универсальна и может выполняться для многих сервисов, например, «Поддержка бизнес-приложений» — это услуга второй линии поддержки, она определена для всех сервисов, по которым департамент информационных технологий имеет вторую линию. Но оказываться услуга может по-разному, например, «Восстановление работоспособности базы данных» для сервиса, использующего СУБД Oracle, будет реализована иначе, чем такая же услуга по сервису, использующему СУБД Microsoft SQL Server.

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

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

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

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

Стоимость услуг – без аллокаций

Сверхзадача проекта, поставленная перед нами руководством компании, формулируется достаточно просто – посчитать реальную стоимость потребленных ИТ-услуг для управленческого учета в разрезе центров финансовой ответственности (ЦФО). Можем ли мы это сделать, опираясь на известную стоимость универсального кирпичика? Да, но с учетом структуры затрат на ИТ.

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

Распределяемые косвенные расходы — это те, которые мы можем отнести к ЦФО, используя какие-либо аналитические признаки. Парадигма проекта в данном случае сформулирована следующим образом: мы относим на ЦФО те потребленные услуги, которые можем отнести. То есть, если имеется достаточная информация для отнесения того или иного обращения пользователя к ЦФО, то мы делаем это. Если нет – в этом случае стоимость уходит на нераспределенные расходы. Важно отметить, что распределяется стоимость на ЦФО по обращениям, а не по каждой оказанной в нем услуге.

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

Имея развитый механизм учета реально потребленных услуг, мы предъявляем конкретный и обоснованный счет за эти услуги. Объемом и стоимостью потребленных услуг заказчик может управлять, применяя различные инструменты, начиная от найма более квалифицированного в информационных технологиях персонала и заканчивая инструментами процесса управления уровнем обслуживания (Service Level Management, SLM).

Внедряя процесс SLM, мы создали развитую схему по управлению уровнем услуг, в которой заказчик, манипулируя пакетами услуг, может воздействовать на итоговую сумму поддержки. Кроме того, планируя к внедрению новый сервис, заказчик может получить общую смету внедрения, включая и суммы за сопровождение, которые в будущем будут ложиться в расходную часть ЦФО.

Потери и приобретения

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

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

***

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

Александр Огнивцев (Ognivtseval@alfastrah.ru) – руководитель управления сервисной поддержки ОАО «Альфастрахование» (Москва).