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

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

Посчитать стоимость услуги — лишь начало. Ее нужно предоставить, а после выставить счет. Аллокация — это часть общего процесса биллинга. Эту задачу мы решали через частное облако на ManageIQ. Об одном из таких проектов можно почитать в этом посте.

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

Проблема 1: Не знаем свою инфраструктуру

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

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

Мы: «По вашим данным мы описали ваш ИТ-сервис. Правильно ли мы поняли, что у вас вот тут 10, вот этого 3, а того вообще нет?»

Инженер заказчика: «Ну да».

ИТ-директор заказчика: «Секундочку, а почему это у нас тут 10, вот этого 3, а того вообще нет?!»

Начальник ИТ-отдела: «Так вы же нам в том году сами сказали так сделать, а потом докупить должны были. Но пока не докупили».

ИТ-директор заказчика: «Стоп, коллеги! Давайте разберемся».

И все дружно на месяц уходят разбираться. Через месяц возвращаются со словами: «Да, так и пишите: у нас вот тут 10, вот этого 3, а того вообще нет».

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

Проблема 2: Перфекционизм

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

На одном из проектов мы подготовили модель и калькулятор, наша работа была выполнена. Но еще несколько месяцев этот калькулятор не был запущен внутри компании. Проблема заключалась в том, что гендира не устраивало объяснение ИТ-департамента, почему у них в тестовом виртуальном стенде переподписка 12 к 1. Гендир сам в прошлом технарь и умеет задавать каверзные вопросы.

В отношении подготовки модели аллокации фраза «Лучшее — враг хорошего» актуальна, как нигде. Если упираться в 100% точности расчетов, обязательно зависнешь или на сборе данных, или на точности описания работы ИТ-сервисов, или на согласованиях модели. Не забываем о принципе Парето: «20% усилий дают 80% результата». По нашему опыту, 90% точности более чем достаточно.

Проблема 3: Не всё так просто

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

В наших проектах аудита мы подключаем по 1-2 инженера на каждое направление инфры или инфобеза. Каждый из них собирает выгрузки по своему направлению деятельности. К примеру, инженер по виртуализации собирает отчет RVTools и VMware HealthAnalyzer, Linux-инженер собирает и анализирует SAS report-ы, а инженер Microsoft запускает MAPT. Свои скрипты есть у сетевиков, СРК-инженеров и экспертов по базам данных. И это не считая встроенных средств мониторинга.

Прямо сейчас у меня идет средний по насыщенности проект аудита. Во внутреннем рабочем чате 30 человек, и почти всем им нужны ответы на вопросы.

Обычно мы стараемся согласовать себе определенное количество рабочих мест на площадке и доступы во все интересующие нас места. На установочной встрече заказчик активно кивает и обещает оперативно решать проблемы. На практике рабочих мест не пять, а два, а доступы мы вам не дадим — нам ИБ-шники запрещают. И вообще, мы тут очень заняты, а вы нас отвлекаете от работы.

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

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

Проблема 4: Нужно красивое решение здесь и сейчас

Я уже упомянул в начале статьи, что самым «простым» вариантом калькулятора аллокации может стать Excel-файл. Казалось бы, ну какой еще Excel, когда у нас вокруг частные облака, DevSecOps-практики и тяжелый Enterprise? Как-то это несерьезно.

Во-первых, в начале проекта заказчику большего и не нужно. Функционала Excel достаточно для подготовки формул расчета и построения первой версии калькулятора. В него уже зашито около 400 функций, из которых по факту пригодится пара десятков ключевых плюс какой-никакой VBA-код. А когда расчеты созреют и будут согласованы финальные версии, уже можно переносить их на web-application.

На одном из проектов нам достаточно было самим написать небольшое приложение для биллинга на Python. Для заказчика это было проще и дешевле, чем вкладываться в какое-то дорогое решение, когда еще не до конца понятно, будет ли у проекта развитие или он остановится на этапе пилотирования. С Excel то же самое.

Во-вторых, даже если денег на web-application в заказчике не найдется, вполне можно и дальше работать с Excel. Каждый из нас и так либо пользуется им на ежедневной основе, либо когда-то пользовался. А значит, заказчик сам сможет если ни развивать, то хотя бы наполнять Excel-калькулятор новыми данными или удалять старые.

И, как говорится, the last but not least, Excel для заказчика условно бесплатный, потому что уже есть.

Проблема 5: Мы не роботы

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

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

Да, это все одна формула в одной ячейке. Причем, это еще вариант с сокращением значений и выносом общих множителей за скобки.

Здесь первый блок — это «преамбула», блокирующая вычисление, пока не будут выбраны все необходимые параметры. Остальные блоки — формулы расчета стоимости в зависимости от выбранной пользователем политики резервного копирования.

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

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

Подведем краткие итоги:

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

2. Лучшее — враг хорошего. 90% точности в описании ИТ-процессов и инфраструктуры более чем достаточно, иначе сроки проекта стремятся в бесконечность, а с ними и бюджет.

3. Если вы решитесь писать модель и калькулятор аллокации, приготовьтесь к тому, что это full-time job. Делать это параллельно с текущими задачами, выделяя по 2-3 часа вечером, не получится.

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

5. Мы не искусственный интеллект, чтобы легко читать формулы. Подробные пошаговые объяснения расчетов позволят понимать, что происходит, и быстрее двигаться по проекту.

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

Андрей Филинов

Консультант отдела ИТ-аудита и консалтинга