Рабочий месяц март был очень горячим с точки зрения событий:
- Событием первостепенной важности для меня лично, но, вероятно, малозаметным для окружающих, было завершение острого периода, когда я был вынужден совмещать роли постановщика задачи и разработчика в одном лице. Совмещение конфликтующих сторон в одном человеке никогда не дарило последнему счастья и всегда негативно влияет на результаты. Моя прошлая заметка была посвящена как раз этой беде.
- Некоторые мои коллеги погрузились в работу над большим и чрезвычайно интересным проектом по формированию финансовой модели услуг. Проект сложный. Существенные сложности есть с технической стороны, с выбором и применением надлежащего инструментария. С методической точки зрения также есть о чем поговорить, т.к. охват включает в себя не только подсчет фактической стоимости услуг, но и прогнозирование её стоимости, с учетом изменяющихся параметров.
- Практически одновременно с этими событиями прошел вебинар, посвященный подсчету себестоимости услуг. Было приятно видеть в гостях такое количество заинтересованных людей. Однако же, модель, рассмотренная в его завершающей части, по моему ощущению была донесена очень скупо. Поэтому у меня осталось желание посмотреть на некоторые её части более пристально. Сегодня мы с вами поговорим о вопросах стоимости услуг более подробно.
Подготовка финансовой модели
Рассмотрим подробно одну из веток, правую, этой модели.
Подход к расчету стоимости услуг опирается на следующие аксиомы:
- Полезная ценность/ ресурс каждой конфигурационной единицы, входящей в модель, может быть представлен в виде вектора из одной или несколькими скалярными единицами измерения :
- Для "производства" собственной ценности конфигурационная единица потребляет собственные ресурсы, затраченные на собственную работоспособность, а также ресурсы конфигурационных единиц которых зависит её работоспособность и производительность. Эта зависимость выражается некоторой векторной функцией :
- Распределение стоимости затрат понесенных на её работу осуществляется на основании функции распределения, которая определяет скалярное значение доли распределяемой стоимости согласно количеству ресурсов , потребленных –м потребителем.
Выбор единицы измерения
Выбор набора единиц измерения конфигурационной единицы должен определяться природой этой конфигурационной единицы.
Для инфраструктурных единиц выбор этих единиц измерения может быть достаточно простым, а для приложений более сложным. В качестве примера рассмотрим СХД, ферму виртуализации, виртуальный сервер и приложение интернет магазина.
СХД
Вектор единиц измерения будет представлен всего одной единицей измерения – объемом выделяемого хранилища, в гигабайтах (Гб).
Для обеспечения работоспособности СХД не требуются ресурсы иных конфигурационных единиц. Таким образом, функция потребления ресурсов тривиальна
Общий объем ресурса равен общему объему СХД, измеренному в Гб.
Распределение стоимости СХД на элементы, которые потребляют её ресурсы, осуществляется при помощи простого отношения потребления конкретного потребителя к общему объему СХД
Не востребованные объемы СХД не распределяются. С финансовой стороны соответствующая доля не отнесенной стоимости включается в затраты будущих периодов.
Ферма виртуализации
Вектор единиц измерения будет представлен двумя единицами измерения:
- Количество процессорных ядер (упростим задачу, считая, что все современные процессорные ядра одинаковые), в штуках;
- Объем оперативной памяти, в гигабайтах (Гб).
Для обеспечения работоспособности фермы виртуализации не требуются ресурсы иных конфигурационных единиц. Таким образом, функция потребления ресурсов тривиальна
Общий объем ресурса равен произведению мощностей пулов вычислительных ядер на совокупный доступный объем распределяемой оперативной памяти.
Распределение стоимости фермы виртуализации на элементы, которые потребляют её ресурсы, осуществляется при помощи простого отношения потребления ядер и памяти конкретным потребителем к общему объему ресурсов
Не востребованные объемы ресурсов не распределяются. Заметим, что формулу распределения можно усложнять весовыми коэффициентами по единицам измерения, если из-за существенной разницы в стоимости этих единиц измерения возникает такая потребность .
Виртуальный сервер
Вектор единиц измерения виртуального сервера будет представлен несколькими единицами измерения:
- Количество процессорных ядер;
- Объем оперативной памяти, в гигабайтах (Гб);
- Объем дисков, в гигабайтах (Гб).
Для обеспечения работоспособности сервера кроме собственных ресурсов (например, лицензия MS Windows Server) требуются ресурсы иных конфигурационных единиц. Функция потребления ресурсов для виртуального сервера представляет собой сумму векторов ресурсов СХД и ресурсов фермы виртуализации.
Общий объем ресурса равен, например, 16 процессорным ядрам, 64 Гб RAM, выделенными фермой виртуализации VMware под этот сервер и 500Гб дискового пространства.
Распределение стоимости Виртуального сервера на элементы, которые потребляют её ресурсы, тривиально, т.к. потребителем этого сервер является только один элемент – СУБД SQL Server
Если бы ресурсы виртуального сервера являлись разделяемыми, то можно было бы составить формулу распределения, аналогичную формуле распределения для системы виртуализации.
Приложение Интернет-магазин
Единицами изменения для приложения интернет магазина, интересующими наш бизнес будут две величины:
- Размер каталога товаров/контента, количество в штуках;
- Количество единовременных пользователей, в штуках.
Приложение интернет магазина потребляет ресурсы фермы веб-серверов, на которых это приложение запущено и ресурсы базы данных, в которой лежат медиа материалы и контент связанный с позициями каталога товаров.
Функция зависимости производительности приложения от количества одновременных пользователей и размера библиотеки контента представлена таблицей рекомендованных требований от поставщика приложения. Фактически, это кусочно-заданные функции.
Если в построенной финансовой модели корректно выстроены связи между услугами, приложениями, инфраструктурой, для элементов определены единицы измерения, функции потребления ресурсов и распределения затрат, то по такой модели можно осуществлять распределение и прогнозирование ресурсов в их натуральном выражении.
Если приложение интернет магазина является разделяемым ресурсом, то функцию распределения затрат можно сформулировать на основании основных единиц измерения приложения.
Расчет фактической себестоимости
Начнем со сбора затрат и расчета фактической себестоимости, как с наиболее простой задачи.
Первый шаг, который необходимо будет выполнить – это идентифицировать и локализовать затраты связанные с эксплуатацией элементов модели.
Такими затратами для приведенной модели будут:
- ФОТ администраторов интернет-магазина
- ФОТ администраторов БД
- ФОТ администраторов вычислительной инфраструктуры
- ФОТ на обслуживание СХД
- Размещение СХД в ЦОД
- Поддержка серверного оборудования
- Размещение серверного оборудования в ЦОД
- Поддержка MS SQL Server
- Поддержка MS Windows
- Амортизация СХД, серверов, лицензий на приложение, SQL Server
- Затраты на управление (ФОТ Scrum master)
- Прочие затраты.
Часть этих затрат будут отнесены на конкретные элементы полностью, как то ФОТ администраторов интернет магазина и ФОТ руководителя команды разработчиков и по совместительству Scrum мастера могут быть полностью отнесены на приложение интернет магазина.
Долю ФОТ системных администраторов, отнесенная на наш сервер СУБД, ферму веб серверов необходимо будет выделить. Этому может способствовать статистическая информация об объеме их работ или нормирование работ по обслуживанию.
Суммы амортизации необходимо будет получить из данных бухгалтерского учета и отнести на амортизируемые конфигурационные единицы. Несоответствие бухгалтерского учета активов и управленческого учета ИТ-активов может внести сложности в отнесении амортизации. Наиболее часто проблемы возникают при учете комплектов, дорогостоящих (амортизируемых) серверных или сетевых плат расширения, ЛВС.
Таким образом, для каждой конфигурационной единицы можно получить суммарные фактические затраты понесенные на её эксплуатацию. Использование же функций распределения затрат позволяет распределить затраты с нижележащих элементов на вышестоящие, узнать полную себестоимость эксплуатации элемента, себестоимость одной единицы измерения в разрезе статей затрат или суммарно.
Прогнозирование себестоимости
Задача прогнозирования стоимости является более сложной, т.к. потребует более аккуратного обращения с функциями расчета стоимости ресурса в зависимости от объемов прогнозного потребления.
В качестве примитивного примера давайте рассмотрим СХД. Если объем имеющейся СХД составляет 100Тб, то при повышении этого значения спросом на дисковые ресурсы график затрат на амортизацию изменится, т.к. закупленное для расширения хранилища оборудование внесет свой вклад в размер амортизации за период. При этом, допустим, что все прочие затраты останутся без изменения (ФОТ администраторов СХД).
Если мы посмотрим на сервер СУБД, то аналогичная ситуация возникнет с лицензией на SQL Server, т.к. при превышением определенного числа процессоров, использование лицензии типа Standard будет невозможно и она должна быть замещена на Enterprise версию.
Фактически, для конфигурационной единицы с одной единицей измерения функция прогнозирования затрат будет кусочно-заданной (или в случае упрощения кусочно-линейной)
В результате объединения (суммирования) функций локализованных затрат итоговая функция будет достаточно сложной.
Если такую функцию удалось сформировать, то рассчитать плановую стоимость, зная абсолютное потребление, будет делом техники.
Дополнительную сложность в этот процесс вносят два фактора:
- Формирование списка и функций плановых отнесенных затрат для конкретной конфигурационной единицы может быть нетривиальной задачей и требовать человеческого участия. Задача может быть упрощена привязкой типов затрат к различным видам конфигурационных единиц, или используя наследование списка типов фактических затрат, если они изветны.
- Если элемент потребляет ресурсы нижележащих по модели элементов, то функция прогнозирования затрат будет существенно зависеть от функций прогнозируемых затрат этих нижележащих элементов. Соответственно, такой расчет должен быть проведен сначала для них, и лишь позднее для вышестоящих элементов.
Послесловие
Коллеги, как вы можете видеть, изложению недостает строгости, но оно уже сейчас отмечает места вызывающие сложность при практическом решении подобных задач, а также поднимает вопросы в спорных моментах. Многое говорит о том, что предметный подход к проблеме расчета стоимости услуг является весьма насущным, и мы всегда рады дискуссии, вашим вопросам и экспертному обсуждению.
Вдогонку: Если взглянуть на эту задачу с точки зрения существующих инструментов, то картина выглядит достаточно грустной. Не смотря на то, что эта задача универсальная по своей сути, для решения различных частей задачи приходится применять специальный зоопарк решений: для хранения конфигурационной информации, для хранения финансовых данных, для выполнения расчетов, для отчетности и отображения результатов.
В общем, приглашаю вас к соучастию. Давайте обсудим.
Опять коллеги из Cleverics публикуют статьи под видом заметок… И опять здорово получается.