August 10

Кейс по внедрению методики расчета ИТ-услуг для защиты бюджета

CIO нужно начинать думать как CFO, иначе он не сможет договориться с бизнесом!

Сложные взаимоотношения между айтишкой и бизнесом — распространенная история в компаниях. Часто при защите бюджета CIO слышат: «У нас нет денег, уменьшите свои хотелки!» И одна из причин отказа — обоснования бюджета, основанные на феерических идеях айтишников, а не на фактах и расчетах. Бизнес готов «раскошелиться» только в том случае, если ему предоставлены конкретные цифры.

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

О компании

Я работал в нефтяной компании «Газпром нефть» и отвечал за эксплуатацию ИТ-сервиса блока разведки и добычи. Компания «Газпром нефть» большая, у нее есть дочерние структуры, которые управляют непосредственно добычей в своей зоне. Наш центр сопровождения бурения круглосуточно в онлайн-режиме вел мониторинг бурения всех скважин компании в России и за границей. Данные поступали в центр с самого низа, через системы уровня MES. Это уровень промышленной автоматизации: с агрегатов снимается статистика, которая поднимается в аналитический центр и консолидируется. ИТ-сервис объединял около 40 информационных систем.

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

Точки, в которых собиралась статистика

Какие были проблемы в работе

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

Весь ИТ-сервис компании можно разделить на три типа систем:

  1. Общекорпоративные — СЭД, ERP.
  2. Общеблоковые — сервисы, которые уникальны для одного блока.
  3. Локальные (нецентрализованные) — обслуживание принтера, железа, поддержка рабочего места офисного или производственного сотрудника.

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

Общеблоковые системы были сделаны таким же образом. Я мог спокойно сравнить показатели работы сервиса в каждой из дочек, и стоимость у меня была одинаковая.

С локальными сервисами дело обстояло по-другому: состав ИТ-услуг был абсолютно разный. И, например, ответить на вопрос бизнеса, почему поддержка рабочего места в Томске стоит 3000 рублей в месяц, а в Ханты-Мансийске — 5000 рублей в месяц, я не мог. А если ты не можешь ответить на вопросы бизнеса, то, значит, и не можешь защитить бюджет. Бизнесу важно понимать, на что и в каком объеме уходят деньги.

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

В компании для расчета стоимости услуг применялась классическая ресурсно-сервисная модель, которая у нас называлась расчетно-технологической картой (РТК). Простой вариант РТК выглядит так:

Услуга разбивается на отдельные компоненты. Например, обслуживание компьютера состоит из трех компонентов:

  • запросы на обслуживание и инциденты;
  • регламентные работы;
  • управление сервисом.

Для каждого компонента услуги определяются трудозатраты разных специалистов и стоимость их работ. После все данные суммируются, и мы получаем количество специалистов, необходимое для оказания услуги, и ее общую стоимость.

Вроде бы все просто. Но проблема в том, что в компании 12 дочерних предприятий, в каждой дочке по 150–180 услуг, а в каждой услуге по 50–60 операций. И получается, что интегратор мне приносит не расчетно-технологическую карту, а целую «простынь», которую нужно проверить.

Третья проблема — в компании регулярно появлялись новые услуги, и чтобы посчитать их стоимость, нужно было тратить много времени.

Как мы решили проблемы

Мы сделали конструктор, который позволил быстро создавать новые услуги с понятными составом и стоимостью.

На первом этапе мы собрали все сервисные услуги и распределили их по группам. Группа — это услуги, связанные одной сущностью, одним главным объектом.

На втором этапе мы создали структуру услуги и определили правила сбора в ней операций.

Рассмотрим формирование уровней услуги на примере двух услуг: поддержка физического сервера и поддержка ПО с выделенным сервером.

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

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

Поддержка ПО с выделенным сервером входит в группу «Поддержка прикладного локального ПО», и в состав всех услуг этой группы должна входить операция установка ПО.

Постановка на мониторинг и установка ПО — операции второго уровня услуг.

У любого физического сервера есть установка ОС, а у любого ПО с выделенным сервером есть подключение к серверу приложения. Добавляем эти операции в структуру услуг.

И дальше повышаем детализацию услуг, получая в итоге следующую структуру:

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

Услуги стало легко сравнивать, потому что у них все, что не оранжевое, одинаковое, а отличаются они только маленьким кусочком — специфическими операциями по компоненте.

Каких результатов мы достигли

Чтобы проверить, как работает эталонный каталог услуг, мы внедрили его на пилотном объеме в двух дочках. Результаты получились следующие:

  • На 40% снизилось время ввода новых услуг в каталог, так как их стоимость стала считаться гораздо быстрее.
  • В два раза сократилось количество итераций при защите сервисного бюджета.
  • На 60% уменьшилось время сравнения стоимости и состава услуг в разных ДО.

Потом эталонный каталог приняли за основу и в других дочках.

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

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

За счет внедрения каталога мы снизили влияние человеческого фактора на конструирование услуг, минимизировали изменения, которые могут вносить сервис-менеджеры в их структуру. Например, если мы определили, что услуга всегда выполняется за 6 часов, то офис-менеджер не может поставить показатель 8 часов.

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

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

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

— Состав услуги соответствует составу шаблона?

— Да.

— Расчет стоимости услуги соответствует методике, которую мы с вами приняли?

— Да.

— Бюджет одобрен!

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

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

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

У проектантов только две цели — получить деньги и быстро закончить проект. А жить потом с этим буду я, и отвечать перед бизнесом буду я. Поэтому чем раньше будут задаваться вопросы о сервисе, тем понятнее будет бизнесу, сколько стоит система. И иногда бывает, что я говорю: «Компании такая система не нужна, так как она себя не окупает».

Что нам не удалось сделать

Единственный вопрос, который мы не решили — это автоматическое изменение расчетов при изменении качества услуги. Например, я говорю заказчику, что время решения критических инцидентов — 2 часа, обычных — 8 часов, а он хочет уменьшить эти показатели.

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