CIO нужно начинать думать как CFO, иначе он не сможет договориться с бизнесом!
Сложные взаимоотношения между айтишкой и бизнесом — распространенная история в компаниях. Часто при защите бюджета CIO слышат: «У нас нет денег, уменьшите свои хотелки!» И одна из причин отказа — обоснования бюджета, основанные на феерических идеях айтишников, а не на фактах и расчетах. Бизнес готов «раскошелиться» только в том случае, если ему предоставлены конкретные цифры.
Ниже кейс о том, как айтишке рассчитывать стоимость услуг, зачем это делать и чем такой подход может помочь при защите бюджета.
О компании
Я работал в крупной нефтяной компании и отвечал за эксплуатацию ИТ-сервиса блока разведки и добычи. В структуру компании входят дочерние структуры, которые управляют непосредственно добычей в своей зоне. Наш центр сопровождения бурения круглосуточно в онлайн-режиме вел мониторинг бурения всех скважин. Данные поступали в центр с самого низа, через системы уровня MES. Это уровень промышленной автоматизации: с агрегатов снимается статистика, которая поднимается в аналитический центр и консолидируется. ИТ-сервис объединял около 40 информационных систем.
Пример самой простой системы — «Шахматка и Техрежим», которая собирает данные о добыче нефти и режиме работы скважин. Непосредственно дочерним структурам она нужна, чтобы управлять насосами и смотреть, в каком режиме работает скважина, сколько она добывает. Консолидация данных позволяет узнать общую нефтедобычу. В дальнейшем эта информация используется при бизнес-планировании.
Какие были проблемы в работе
Так как я отвечал за эксплуатацию всех систем блока разведки и добычи, мне нужно было не только обеспечить их функционирование в определенном режиме, но и сделать так, чтобы стоимость и состав ИТ-услуг были понятны.
Весь ИТ-сервис компании можно разделить на три типа систем:
Общекорпоративные — СЭД, ERP.
Общеблоковые — сервисы, которые уникальны для одного блока.
Локальные (нецентрализованные) — обслуживание принтера, железа, поддержка рабочего места офисного или производственного сотрудника.
Структура общекорпоративного сервиса такова, что есть внутренний интегратор и все дочерние предприятия компании покупают услуги у него. Чтобы сделать услугу одинаковой для всех, мы ее конструировали в корпоративном центре: совместно с заказчиком обсуждали, из чего будет состоять сервис, сколько он будет стоить.
Общеблоковые системы были сделаны таким же образом. Я мог спокойно сравнить показатели работы сервиса в каждой из дочек, и стоимость у меня была одинаковая.
С локальными сервисами дело обстояло по-другому: состав ИТ-услуг был абсолютно разный. И, например, ответить на вопрос бизнеса, почему поддержка рабочего места в Томске стоит 3000 рублей в месяц, а в Ханты-Мансийске — 5000 рублей в месяц, я не мог. А если ты не можешь ответить на вопросы бизнеса, то, значит, и не можешь защитить бюджет. Бизнесу важно понимать, на что и в каком объеме уходят деньги.
Вторая проблема заключалась в том, что ко мне раз в год приходил интегратор для согласования бюджета и вываливал на мой стол документацию, в которой разобраться было невозможно.
В компании для расчета стоимости услуг применялась классическая ресурсно-сервисная модель, которая у нас называлась расчетно-технологической картой (РТК). Простой вариант РТК выглядит так:
Услуга разбивается на отдельные компоненты. Например, обслуживание компьютера состоит из трех компонентов:
запросы на обслуживание и инциденты;
регламентные работы;
управление сервисом.
Для каждого компонента услуги определяются трудозатраты разных специалистов и стоимость их работ. После все данные суммируются, и мы получаем количество специалистов, необходимое для оказания услуги, и ее общую стоимость.
Вроде бы все просто. Но проблема в том, что в компании 12 дочерних предприятий, в каждой дочке по 150–180 услуг, а в каждой услуге по 50–60 операций. И получается, что интегратор мне приносит не расчетно-технологическую карту, а целую «простынь», которую нужно проверить.
Третья проблема — в компании регулярно появлялись новые услуги, и чтобы посчитать их стоимость, нужно было тратить много времени.
Как мы решили проблемы
Мы сделали конструктор, который позволил быстро создавать новые услуги с понятными составом и стоимостью.
На первом этапе мы собрали все сервисные услуги и распределили их по группам. Группа — это услуги, связанные одной сущностью, одним главным объектом.
На втором этапе мы создали структуру услуги и определили правила сбора в ней операций.
Рассмотрим формирование уровней услуги на примере двух услуг: поддержка физического сервера и поддержка ПО с выделенным сервером.
Это две абсолютно разные услуги, но в их базовый уровень входят одинаковые операции: прием заявок и маршрутизация. Данные операции нужно делать всегда, вне зависимости от оказываемой услуги.
Поддержка физического сервера входит в группу «Инфраструктура», и в состав всех услуг этой группы должна входить операция постановка на мониторинг.
Поддержка ПО с выделенным сервером входит в группу «Поддержка прикладного локального ПО», и в состав всех услуг этой группы должна входить операция установка ПО.
Постановка на мониторинг и установка ПО — операции второго уровня услуг.
У любого физического сервера есть установка ОС, а у любого ПО с выделенным сервером есть подключение к серверу приложения. Добавляем эти операции в структуру услуг.
И дальше повышаем детализацию услуг, получая в итоге следующую структуру:
В итоге у нас получился эталонный каталог ИТ-услуг, который сокращал время ввода новых услуг и изменения существующих.
Услуги стало легко сравнивать, потому что у них все, что не оранжевое, одинаковое, а отличаются они только маленьким кусочком — специфическими операциями по компоненте.
Каких результатов мы достигли
Чтобы проверить, как работает эталонный каталог услуг, мы внедрили его на пилотном объеме в двух дочках. Результаты получились следующие:
На 40% снизилось время ввода новых услуг в каталог, так как их стоимость стала считаться гораздо быстрее.
В два раза сократилось количество итераций при защите сервисного бюджета.
На 60% уменьшилось время сравнения стоимости и состава услуг в разных ДО.
Потом эталонный каталог приняли за основу и в других дочках.
Рассчитывать стоимость услуг стало гораздо проще, так как мы конструируем РТК не с нуля, а опираемся на определенную структуру услуги и сразу добавляем в расчетно-технологическую карту операции, которые есть в шаблонах.
При таком методе не теряются работы, которые нужно сделать обязательно для определенной услуги. Например, в услугу обслуживание компьютера входит операция подготовка сервисного отчета. Каждый месяц сервис-менеджер подготавливает сервисный отчет для заказчика и тратит на это ресурсы — рабочее время. Когда ты конструируешь услугу с нуля, ты вполне можешь забыть про эту операцию.
За счет внедрения каталога мы снизили влияние человеческого фактора на конструирование услуг, минимизировали изменения, которые могут вносить сервис-менеджеры в их структуру. Например, если мы определили, что услуга всегда выполняется за 6 часов, то офис-менеджер не может поставить показатель 8 часов.
Благодаря каталогу интегратору стало проще защищать бюджет. Например, появился сервер на удаленной площадке, который нужно поддерживать. Его в общую услугу не включили, а местному филиалу интегратора нужно обосновать ресурсы, потраченные на поездки к серверу.
Интегратор берет каталог, находит в нем шаблон нужной услуги и добавляет к нему только специфическую операцию — поездку на удаленную площадку. И когда интегратор предоставляет заказчику обоснования бюджета, ему нужно отчитаться только за стоимость поездок к серверу, так как остальная стоимость услуги стандартизирована и утверждена совместно с заказчиком.
Ну и, конечно, я тоже получил плюшки: мне больше не пришлось что-то доказывать бизнесу. По сути, в дальнейшем защита бюджета выглядела так:
— Состав услуги соответствует составу шаблона?
— Да.
— Расчет стоимости услуги соответствует методике, которую мы с вами приняли?
— Да.
— Бюджет одобрен!
Созданную нами методику расчета стоимости ИТ-услуг можно также применять при внедрении новых решений. Когда запускается новый проект, все смотрят, сколько будут стоить лицензия, внедрение. Потом это суммируют и выводят итоговую стоимость проекта. Но никто не задает вопрос: «Сколько будет стоить сервис?»
Но если посчитать стоимость сервиса, то сумма может выйти приличная. У меня были инциденты, когда внедрение системы стоило 20 млн рублей, а сервис — 10 млн рублей в год. Например, специалисты, которые разбираются в фишбон бурении — дорогие ребята. А компании уже на этапе опытно-промышленного проектирования требуется их поддержка.
Я всегда задаю очень неудобные вопросы, когда бизнес говорит: «Ой, вот классная штука, давайте ее поставим!» Хорошо, давайте поставим, но только после того, как посчитаем стоимость ее обслуживания.
У проектантов только две цели — получить деньги и быстро закончить проект. А жить потом с этим буду я, и отвечать перед бизнесом буду я. Поэтому чем раньше будут задаваться вопросы о сервисе, тем понятнее будет бизнесу, сколько стоит система. И иногда бывает, что я говорю: «Компании такая система не нужна, так как она себя не окупает».
Что нам не удалось сделать
Единственный вопрос, который мы не решили — это автоматическое изменение расчетов при изменении качества услуги. Например, я говорю заказчику, что время решения критических инцидентов — 2 часа, обычных — 8 часов, а он хочет уменьшить эти показатели.
В такой ситуации приходится пересчитывать стоимость услуги, и на это уходит много времени. Автоматическое изменение расчетов решило бы эту проблему.