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

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

1. Центр финансовой ответственности, далее ЦФО — одно или несколько организационных подразделений компании, отвечающие за финансовые результаты своей деятельности. Не усложняя, разделим ЦФО на две группы: зарабатывающие (Profit Center) и затратные (Cost Center).
2. Основная услуга, далее ОУ — ИТ-услуга, непосредственно оказываемая одному или нескольким бизнес-подразделениям (ЦФО). Например, поддержка информационной системы Х. Это просто пример, не будем здесь обсуждать подходы к структурированию каталога ОУ (от бизнес-процессов, от информационных систем или ещё как-то).
3. Техническая услуга, далее ТУ — обобщённое название однотипных работ, выполняемых специалистами одного профиля. Например, администрирование виртуальных сред, поддержка СХД и т.п.

Основная задача, которую необходимо решить с помощью аллокации — определение финансового результата деятельности зарабатывающих ЦФО. Действительно, хорошо бы оценить деятельность ЦФО в денежном выражении по его прибыльности (доходы минус расходы), а не только по доходам. Заметим попутно, что данная задача применима не всегда и не для каждой компании. Если компания выходит на рынок, много инвестирует (=тратит), то оценивать её прибыльность рано. Однако, для зрелых рынков, где борьба идёт именно за маржу, такая задача имеет смысл.

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

Кратко основные положения данной методики.

1. Рассматриваются только операционные затраты (OPEX) на ИТ, включая ФОТ собственных сотрудников и договоры на поддержку с внешними поставщиками.  Инвестиционные, проектные затраты (CAPEX) не рассматриваются. Не включена в модель также малоценка.
2. ИТ-затраты относятся на ТУ.
3. Затраты на ТУ перераспределяются на ОУ согласно драйверам распределения.
4. Затраты на ОУ перераспределяются на ЦФО согласно драйверам распределения.
5. На ЦФО в итоге нужно отнести все затраты.
6. ТУ могут относиться только на ОУ. ТУ на ТУ относиться не могут.
7. Драйверы распределения могут быть любые. Если значение драйвера не может быть рассчитано точно на основании имеющейся информации, оно определяется экспертным путём.

Т.о. аллокационная модель может быть представлена следующей картинкой.

 
 Информационный ландшафт представлен следующим набором систем:

– кадровая система — учёт собственных сотрудников, их ФОТ, а также справочник ЦФО:

• передаёт список сотрудников в ITSM-систему и систему учёта рабочего времени, в систему отчётности — список сотрудников, ЦФО, ФОТ;

– контрактная система — учёт договоров с внешними поставщиками:

• получает справочник ТУ из ITSM-системы;
• отдаёт данные по договорам в разрезе ТУ в систему отчётности; 

– система учёта рабочего времени — по-русски говоря, таймшитинг:

• получает справочник ТУ из ITSM-системы;
• отдаёт данные по рабочему времени в разрезе людей и ТУ в систему отчётности;

– ITSM-система — в ней размещена аллокационная модель: ОУ, ТУ, ЦФО, связи ТУ-ОУ, связи ОУ-ЦФО, без денег;

• получает данные по сотрудникам и ЦФО из кадровой системы;
• отдаёт аллокационную модель в систему отчётности;

– система отчётности — в неё поступают и в ней сводятся все необходимые для расчётов данные.

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

1. ТУ должна иметь прямое сопоставление с ОУ, что на практике получить, во-первых, сложно (как отнести, например, затраты на инженерно-техническое обеспечение ЦОД непосредственно на информационную поддержку определённого бизнес-процесса), а во-вторых, только "экспертным путём".
2. Поскольку в контрактных системах, как правило, не ведётся позиционный учёт входящих в него ИТ-активов, это приводит к очередным гаданиям на тему "как мне распределить сумму контракта на ТУ". Учитывая тот факт, что контрактные администраторы не всегда понимают содержательную сторону договора и смутно отличают одну ТУ от другой, это приводит к существенным погрешностям в распределении. А такие ситуации (разнести дорогой договор на обслуживание большого количества разнородных ИТ-активов на различные ТУ) весьма жизненны.
3. Необходимость более-менее точного распределения приводит к расщеплению ТУ и ОУ. Например, в интересах определённого ЦФО закуплены серверы под тестовый контур его бизнес-системы. Если не разделить ТУ "Все серверы" на ТУ "Все серверы, кроме ЦФО Х" и ТУ "Серверы для ЦФО Х", то стоимость серверов под тестовый контур этой системы будет распределена на все ЦФО. Это вряд ли порадует владельца другого ЦФО, премия которого зависит от "повешенных" на него затрат. Но чем больше ТУ/ОУ, тем сложнее и ненадёжнее процесс распределения.
4. Свобода выбора драйверов распределения может привести, например, к такому варианту: распределить стоимость поддержки серверов на определённую ОУ пропорционально процессорной мощности, потребляемых входящими в данную ОУ информационными системами. Можно ли это сделать неэкспертно?

В попытке ослабить данные ограничения мы пришли… ба-баааам… к ресурсной модели. Обратите внимание, что ресурсная модель сама по себе является каркасом для правильного распределения стоимости: ресурсы одного актива, потребляемые другим активом, могут являться хорошим драйвером. Например, стоимость сервера можно распределить пропорционально процессорной мощности и объёму памяти, потребляемыми СУБД или серверами приложений, а стоимость СХД — пропорционально объёму данных, требуемому для хранения данных серверами.

Тут впору задаться вот каким вопросом: а все ли затраты относить на ЦФО? Например, купили СХД (=много денег), но на начальном этапе им пользуется только одно ЦФО и использует далеко не весь его объём. Если распределить все затраты полностью, то на ЦФО "упадёт" намного больше, чем оно в реальности потребляет. Затем к СХД подключили другое ЦФО. Соответственно, затрат, отнесённых на первое ЦФО, стало меньше. Владелец ЦФО начинает сильно удивляться: "Как так, было больше, стало меньше? Вы отнесли на меня ранее больше, чем я потребляю? Отлично!" Честно говоря, я не хотел бы присутствовать при этом диалоге. Такой подход убьёт всякое доверие к цифрам — факт!

Так вот, если мы используем в качестве драйвера единицы потребления ресурсов, мы можем эту ситуацию аккуратно обыграть. Что делать с остальными затратами? Они что же, нераспределённые? Да, именно так – предложения больше, чем спроса. Вполне себе рыночная ситуация. Это можно считать инвестициями в будущее развитие бизнеса, например.

Драйверы можно проработать более серьёзно. Например, драйвер распределения может выражаться не только натуральными показателями, но и любыми синтетическими, например, нормированное произведение размера оперативной памяти и производительности ЦПУ, выраженное в PassMark. Красиво? Красиво!

При этом в CMDB не нужно вводить отдельные типы связей. Для последующего распределения можно использовать связи зависимости (главное — чтобы они были). 

 
На такой каркас повесить ТУ (т.е. распределить функциональные группы собственных сотрудников) — задача посильная. Более того, там, где есть CMDB, она почти решена, поскольку в карточке КЕ указывается рабочая группа её администраторов.

Обратите внимание, что при таком подходе, не КЕ включается в ТУ (что не имеет физического смысла), а ТУ относится на КЕ (т.е. показывает, какие виды работ собственных сотрудников выполняются по отношению к данной КЕ).

 Задачка посложнее – разнести контракты по КЕ:

• нужно найти для этого человека, у которого есть время и понимание;
• нужно получить с контрагентов спецификацию договора (т.е. понятное и точное разнесение суммы договора по программно-аппаратным компонентам, в него входящим). Тут, как выясняется, могут быть нюансы, поскольку иной поставщик натурально сам не понимает, как получилась такая цифра. Ну, действительно…

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

• систему учёта и контрактных администраторов не трогали (святые люди);
• разработали регулярную одностороннюю интеграцию данных по договорам (контрагент, номер, сумма договора, валюта, период действия и т.п.) из контрактной системы в ISTM-систему;
• в ITSM-систему включили раздел "Договоры" (в общем случае, с ним руками делать ничего не нужно, поскольку все данные берутся из контрактной системы), а также добавили раздел "Спецификация договора" — это как раз то, что позволяет связать договор с программным или аппаратным ресурсом, который он покрывает;
• кроме того, мы увязали эту картину с системой бухгалтерского учёта (но об этом в следующей серии).

Как говорил Глеб Жеглов в великом фильме: "Это, конечно, трудно и попотеть придётся, но…"

Но, согласитесь, разнесение стоимости договора таким способом существенно отличается от приблизительного разнесения его по ТУ  (что такое вообще разнесение договора на ТУ?!) и далее со всеми остановками. Не нужно, в том числе, дробить ТУ в попытке более точного последующего разнесения.

Обратите внимание, что услуги в задаче распределения имеют второстепенное значение (особенно ОУ). Бизнес-пользователи (сотрудники ЦФО) вполне понимают, какие КЕ они используют в своей работе. Это, кстати, может оказаться проще при согласовании значений драйверов (разговор в терминах информационных систем, ноутбуков или мобильных телефонов лишён абстрактности, при этом получить такую информацию, как правило, можно — есть учёт ноутбуков по сотрудникам, а значит — по ЦФО, известно, кто является пользователями системы и т.д.).

 ОУ в модели может быть полезна, например, как способ объединения КЕ. Например, необходимо распределить по ЦФО стоимость всех контуров системы (а они зачастую весьма недёшевы!). Если правила распределения стоимости тестовых контуров такие же, как и продуктива, то все контуры можно объединить под вывеской "Поддержка системы Х" и распределить их по ЦФО пропорционально количеству пользователей, например. Экономия с точки зрения количества связей небольшая, но работать удобнее.

Нужна ли система учёта рабочего времени для сотрудников эксплуатации — вопрос. Действительно, как правило, данные сотрудники стационарно закреплены за обслуживаемыми КЕ (специалисты, поддерживающие кадровую систему, не занимаются поддержкой производственной системы и т.д.). Вероятно, их участие в проектах и прочих задачах с точки зрения отнесения ФОТ на обслуживаемые КЕ можно решить просто коэффициентом утилизации. Таким образом, им не нужно будет списывать часы на ТУ (ещё то упражнение, кто пробовал), а погрешность при использовании утилизации будет незначительной. Но если она, система учёта есть и работает, то хуже не будет — точный учёт не повредит.

Ну, и в заключении ещё одна мысль. Нужно ли относить затраты на ЦФО? Не важнее ли относить затраты на продаваемые организацией продукты/услуги? Например, ЦФО отвечает за продвижение нескольких продуктов, один из которых сильно убыточен, а другой очень прибылен. При этом ЦФО в целом прибыльно. Это хорошо? Или нужно поработать над прибыльностью того самого убыточного продукта?

Собственно, на этом почти всё, что хотелось сказать.

Осталось спросить.

1. Какие есть (рабочие) альтернативы решению данной задачи?
2. Есть ли работающие примеры аллокации на базе CMDB?
3. Является ли аллокация стимулом для поддержания CMDB в актуальном состоянии?
4. Какие программные инструменты для этого используются?
5. Можно ли прийти в гости, посмотреть? 🙂 

ИНТЕНСИВ С ТРЕНЕРОМ

VAP: Экономика и финансы ИТ

Бюджетирование, аллокация, расчёт себестоимости, планирование ресурсов