Управление расходами (лучшие практики и автоматизация процесса)

Юнит-экономика показывает, сколько компания зарабатывает с одного юнита — продукта или клиента. Для того, чтобы рассчитать, сколько компания заработала с продажи одного страхового продукта, нужно рассчитать сколько стоит этот продукт компании в расходах, другими словами, рассчитать его юнит-кост (unit-cost).

Процессы управления расходами включают в себя процессы по учету фактически понесенных расходов и их аллокацию на продажи.

Аллокация расходов – это распределение расходов на ресурсы по ЦФУ (центрам финансового учета) с учетом того, как эти ресурсы потребляются ЦФУ для оказания сервисов, при этом как сервисов для конечных потребителей, так и сервисов, оказываемых одним ЦФУ другому внутри компании. Ресурс — это любой ресурс компании, потребляемый в рамках предоставления сервиса.

Все просто, когда еще на этапе учета расхода на ресурс, мы уже точно знаем, к какому ЦФУ его отнести, а этот ЦФУ – одновременно и центр прибыли (получает выручку от конечного потребителя). Гипотетически такая ситуация возможна, например, в случае, когда у компании только один продукт. Тогда совсем не сложно отнести все затраты компании на него. В реальности такая ситуация – большая редкость, бизнес-модель страховой компании обычно предусматривает продажу множества страховых продуктов, и на них необходимо корректно разнести все расходы, например затраты на персонал и ИТ-ресурсы. Доля последних только увеличивается, зачастую и в абсолютном, и в процентном выражении, по мере цифровизации страховой отрасли.

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

Можно, конечно, все расходы на ИТ-ресурсы собрать на один ЦФУ, а потом разделить между бизнес-подразделениями (аллоцировать) на основе драйверов – показателей, которые определяет в какой пропорции ресурс будет аллоцирован на ЦФУ.

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

А что, если драйверы для разных подразделений будут разные?  Как тогда сравнивать эффективность расходования ресурсов подразделений между собой? Как оценивать, что все запрошенные на этапе планирования бюджета ресурсы были выделены, а потом и израсходованы? Что делать с теми ресурсами, потребляемыми обеспечивающими подразделениями, которые в свою очередь, предоставляют сервисы другим подразделениям, включая подразделения, чьи сервисы они потребляют?

Пример: Бухгалтерия рассчитывает оплату труда и сотрудникам отдела продаж, и ИТ-специалистам, и кадровой службе. Служба продаж пользуется услугами ИТ-поддержки и несколькими внутренними АС (автоматизированными системами). Подразделение, занимающееся разработкой внутренних АС, пользуется сервисом ИТ-поддержки. Бухгалтерия пользуется АС, обращается за помощью в ИТ-поддержку. Таких взаимосвязей в любой компании множество. И для корректного расчета юнит-кост любого продукта аллоцировать расходы нужно на всех этапах.

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

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

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

2)     Первоначальное создание системы для учета довольно трудоемко и требует солидных навыков владения MS Excel

3)    Таблицы трудно защитить от ошибочных действий пользователей, нельзя отследить изменения и “откатить” назад, найдя ошибку.

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

Другое решение, которое нередко обсуждается, когда встает вопрос о налаживании управления расходами, – использование дорогостоящей ERP системы. Если такая система уже внедрена, то можно попробовать использовать ее и для цели аллокации расходов, ведь скорее всего информация обо всех расходах, итак, уже учитывается в ней.

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

Нередко внедрение аллокации расходов начинают с применения каскадного метода. Он заключается в том, что с целью бюджетирования компанию дробят на много ЦФУ (сотни, а то и даже тысячи в крупных компаниях). Любые незначительные изменения в оргструктре и бизнес-процессах компании приводят к тому, что нужно добавлять и удалять ЦФУ, по сути, пересматривать каждый раз всю систему аллокации при создании или упразднении подразделения, а иногда даже при появлении новой должности или перераспределения функционала между сотрудниками. При этом, поскольку часто КПЭ (KPI) по расходам ЦФУ влияют на мотивацию и вознаграждение менеджмента, каждый руководитель для повышения эффективности своей работы старается «на бумаге» уменьшить размер расходов своего ЦФУ. Все это приводит к многочасовым совещаниям со сложными таблицами, понятными только подготовившим их финансистам, по сути к растрате ценного рабочего времени топ-менеджмента, при любом изменении в системе ЦФУ  компании.

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

Хочется найти удобное решение, не требующее существенных расходов как на этапе внедрения, так и в процессе использования системы. Таким решением является российский программный комплекс управления расходами – ClariTech, предназначенный для учета и расчета финансовых и нефинансовых показателей с целью аллокации расходов на ресурсы любых типов и ведения юнит экономики. С его помощью можно моделировать и визуализировать затраты на любые ресурсы.

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

Для целей однозначного описания и визуализации любого ресурса в ClariTech введено понятие узел. Узел — это формализованное описание ресурса, то есть сервис. Любому ресурсу/сервису в ClariTech соответствует свой узел. Система основана на визуализации TCO (Total Cost of Ownership/полная стоимость владения ресурсом) — ключевого финансового показателя, который есть в системе у каждого узла, и который позволяет понятно показать на экране пользователя расходы на этот узел. ТСО ресурс включает в себя все прямые и аллоцированные на данный ресурс расходы. Диаметр узла ресурса в ПК ClariTech прямо пропорционален размеру TCO этого ресурса (см. рис. 1).

[kode_images=5527]

Визуально благодаря тому, что узлы с большим ТСО занимают больше места на графе, пользователь сразу видит на модели ресурсы/сервисы, которые наиболее значимы.  При этом просто по кнопке пользователь может поменять хочет ли он видеть ТСО или Тариф (Рис 2.).

Модель — это совокупность связанных ресурсных узлов. Именно с моделью и работают пользователи ПК ClariTech.

В ПК ClariTech одновременно реализовано несколько типов аллокации:

○      аллокация по драйверам/метрикам,

○      прямая аллокация по заранее заданным долям (выражаются в процентах),

○      аллокация пропорционально совокупной стоимости владения ресурсом.

Пользователь сам определяет для каждого узла тип его аллокации, задает метрики, где это необходимо. Метрика — это единица измерения полезного использования ресурса, мера, позволяющая получить численное значение полезного свойства ресурса (количество сотрудников, гигабайты базы данных, клиенты, квадратные метры, …).

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

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

[kode_images=5528]

Из рис. 2 видно, что Продукт 1 обходится компании в 22 рубля, в продукт 2 уже в 50.2 руб.

С помощью ПК ClariTech можно также:

1. Сопоставить ИТ-инфраструктуру с финансовой моделью компании.
2. Провести сценарный анализ возможных расходов и развития инфраструктуры.
3. Проводить Root Cause анализ: построив в модель, пройтись по всей модели от одного узла к другому, пока не станет понятно, почему тариф изменился, например стал выше.
4. Планировать, осуществлять аллокацию и проводить план-факт анализ в одной модели.
5. Формировать необходимую отчетность, как по плановым, так и по фактическим периодам.

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

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

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

Существенное преимущество – локализация контекста. Модель может быть любой, как иерархической, так и с любым порядком связей. Это позволяет локализовать контекст обсуждения каждого ЦФУ без обязательной привязки ко всей цепочке центров затрат. А значит на совещании можно обсуждать конкретную часть модели, а не искать ответы, продираясь через «простыни» цифр классического каскадного бюджета.

Программный комплекс основан на open-source решениях и может быть установлен в open-source среде. Компании не нужно приобретать какого-либо дополнительное лицензированное ПО. Более подробная информация: https://profpartnership.ru/claritech