Что может дать система аллокации расходов?

Аллокация расходов

Что такое функционально-стоимостной анализ?

Это подход к калькуляции себестоимости, основанный на следующих препозициях:

• затраты всегда возникают в результате выполнения определенных бизнес-процессов (операции, функции)
• эти процессы формируют цепочки создания стоимости, выполняемые в определённом внутренними регламентами порядке
• каждый из процессов в своём месте цепочки потребляет часть ресурсов и/или результатов предшествующих, которые можно оценить
• на финальном этапе всех цепочек оказываются реализуемые на рынке продукты/услуги
• простой имеет стоимость, для выделения из стоимости цены простоя (idle capacity, idle costs), требуется использовать драйвера в абсолютных значениях*, к каждой операции указать метрику ёмкости/технологическую производительность.

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

Такой подход к расчету себестоимости производимой продукции (работ, услуг) позволяет поэтапно разнести косвенные расходы, применить замеренные в реальном производстве доли потребления, и в итоге определить стоимость продуктов с учётом всей специфики преобразования ресурсов в финальный продукт компании.

Наиболее заметен эффект — для процессных компаний со сложным массовым производством по широкой номенклатуре, с высокой долей косвенных в конечной стоимости, с типовыми рутинными операциями, выстроенными в длинные производственные цепочки.

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

Цель методики — калькулировать себестоимость продукта/услуги, исходя из знаний о цепочках создания стоимости внутри компании, порядке и объёме вкладов ресурсов и участников каждого этапа.

Согласно CIMA, the Chartered Institute of Management Accountants, ABC — это подход к калькуляции стоимости и мониторингу процессов, базирующийся на отслеживании потребления ресурсов и получении стоимости результатов процессов. Ресурсы переносятся на активности, а активности — на объекты затрат на основе оценок потребления.

Таким образом, всю модель можно условно разделить на три модуля:

• ресурсы — тут формируется база расходов, по необходимости раскрашивается по пулам затрат, например: `ИТ`, `Кадры`, `Недвижимость`;
• активности — тут воспроизводятся цепочки бизнес-процессов, потребляющие ресурсы и результаты других бизнес-процессов в объёмах, задаваемых драйверами (по носителям затрат);
• объекты затрат — здесь досчитывается стоимость продуктов/услуг, исходя из необходимого для их создания объёма активностей.

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

Особенности внедрения:

• пластичная архитектура: финансовая модель строится под специфику конкретного предприятия и актуализируется вслед за организационными изменениями;
• автоматизация формирования источников: для минимизации трудоёмкости подготовки драйверов проводится дообогащение, "прокраска" и унификация расходов из систем первичного учёта;
• программная реализация ядра внедряемого решения: механизм калькуляции аллокации проектируется с соблюдением баланса времени пересчёта модели и стоимости программно-аппаратной части.

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

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

Где они обитают? Место в управленке

Место калькуляции себестоимости по методу ФСА

Случаи из практики

Имеются примеры реализации на IBM Planning Analytics всех приведённых ниже моделей аллокации.

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

Внутри одной отрасли особенности схем аллокации проявляются уже на уровне бизнес-процессов и определяются, скорее, наличием статистики для драйверов и требованиями руководства к отчётности.

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

Банки

В банковской деятельности характерно выделение пулов затрат: недвижимость, ИТ и расходы на персонал. В финтех влияние расходов на недвижимость может быть несущественным, вместо этого вырастает доля ИТ и RnD.

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

1. Каскадное распределение с множеством шагов внутри Этапа 1 с выбором для каждого отправителя (функция, процесс) драйвера аллокации и

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

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

Результатом Этапа 1 является стоимость функции, результатом Этапа 2 является стоимость Продукта.

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

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

Телеком

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

• системы линейно-технического учёта
• системы выполнения заказов
• биллинги
• системы автоматизации тех. процессов.

Позволяет отследить:

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

Типовая схема процесса аллокаций в Телекоме:

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

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

1. Бизнес-направления/Продукт/бизнес-услуга

    1.1. Телекоммуникационные — мобильная, фиксированная связь, ШПД

    1.2. Медиа/развлечения

    1.3. Розница/салоны продаж

    1.4. Финансовые услуги

    1.5. Корпоративные услуги (ЭДО, колл-центры, аналитика)

    1.6. M2M и IoT: облачные услуги и инфраструктурные решения, IOT, системная интеграция...

2. ARPU

3. Тарифный план

4. Сегмент

5. География:

    5.1. Субъект РФ

    5.2. Населенный пункт

    5.3. Адрес/Площадка локации сетевого оборудования (узел)

6. Клиент (по типам B2B, B2C, B2O)

7. Канал продаж

8. Структурное подразделение

9. ТФО (типовой физический объект)

10. Виды используемых ресурсов:

    10.1. Персонал

    10.2. Транспорт

    10.3. Сеть

    10.4. Оборудование

    10.5. Недвижимость

11. Функции:

    11.1. Ключевые бизнес-процессы:

    11.1.1. Техническая поддержка клиентов

    11.1.2. Подключение/отлкючение/переключение клиентов/услуг

    11.1.3. ТО

    11.1.4. АВР

    11.2. Внутренние услуги между функциональными блоками

12. Элементы услуги

13. Элементы сети

    13.1. Транспорт

    13.2. Коммутация

    13.3. ТС - транспортная сеть

    13.4. БС - базовая станция

    13.5. САД - сеть абонентского доступа

    13.6. Сервисные платформы

    13.7. ИТ системы

14. Уровни сети:

    14.1. Магистральный

    14.2. Зоновый

    14.3. Местный

    14.4. Абонентский

15. Производитель

16. Тип оборудования

17. Проект

18. Площадка локации сетевого оборудования:

    18.1. Обслуживаемые

    18.2. Необслуживаемые

Консалтинг (Professional services)

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

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

Дополнительная сложность возникает при оценке прибыльности проектов. Если в процессной деятельности доход (и прибыль) продукта относительно просто получить из первичного учёта.

Производственные

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

Основные блоки модели:

• Прямые затраты, которые считаются на основании рассчитанных или статистических данных об удельном объеме потребности ресурсов на каждом шаге производственной цепочки, фактических объёмных показателей и фактической стоимости ресурсов.
• Косвенные затраты, которые считаются методом пропорционального распределения фактически понесённых на МВЗ расходов на продукцию, прошедшую через этот МВЗ. Драйверами такого распределения для каждого ресурса может служить отдельный объёмный показатель (объем продукции, время работы, площадь поверхности и т.д.).
• Прочие затраты по производственной, логистической и сбытовой цепочке «от ресурса» до продажи передела.
• Учёт дополнительных факторов — например, выход несоответствующей продукции, потери производительности агрегатов, высвобождение/замораживание оборотного капитала.
• Затраты по МВЗ дополняются затратами на потери металла, связанные с технологическими операциями: учёт технологических потерь, возникающих в процессе производства. В случае возникновения потерь при производстве продукции для справедливого учёта затрат от этих потерь, возникает необходимость не просто усреднить сумму потерь на всю продукцию, прошедшую через МВЗ, а произвести более точный расчёт. Например, часть промежуточной продукции может быть использована для обеспечения непрерывной работы агрегатов на производственном маршруте и в результате утрачена. Себестоимость такой промежуточной продукции должна быть распределена на прошедшие после этого через данный МВЗ единицы продукции. В свою очередь, эти единицы продукции далее тоже могут быть задействованы для схожих целей на других агрегатах. Помимо справедливого учёта потерь возникает необходимость отследить, себестоимость каких заказов/продукции была зачтена через потери на других заказах/продукции.
• Использование продукции поздних переделов для обеспечения тех. процесса ранних переделов в рамках производственного цикла.

Для производств с задачей снизить материалоёмкость, ключевым становится учёт потерь при производстве и их выделение в результате аллокации на конечную продукцию.

Что не является аллокацией расходов

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

Подготовка базы расходов к разнесению

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

Качество данных

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

Рабочий аналитический минимум

Враждебная/непродуктивная детализация — до заявок. Кадры, ИТ — каждый хочет привнести свою детализацию и сломать вам аллокацию. Это ваша система.

Полиграфическое качество отчётности

Продукты, на которых эффективно работает система аллокации расходов не имеют встроенного инструментария генерации красивых презентаций. Правильное решение: просмотр встроенными в продукт средствами для выверки калькуляции (ad-hoc), демонстрация пользователям в режиме сводных таблиц, связанных фильтрами, выгрузка для целевой управленческой отчётности требуемого состава данных в специализированный инструментарий, умеющий выдать публикацию с повышенными требованиями к качеству оформления.

Что ещё вам может дать система аллокации расходов

Система аллокаций полезна не только базовой своей задачей — калькуляцией себестоимости объектов затрат, но и ещё большим количеством полезной информации.

Например, добавление в расчёт калькуляции себестоимости внутренних процессов позволяет сравнить их с рыночными альтернативами и аргументировать переход на аутсорсинг. Используя элементы time-driven подхода к калькуляции, а говоря проще — проставив к носителям затрат (сотрудникам, станкам) их плановую производительность, можно оценивать стоимость и объём простоя.

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

Добавив модуль расчёта доходности в сопоставимой с объектами затрат детализации, получим возможность оценить прибыльность не только продуктов per se, но и других продуктовых аналитик, например, сравнить эффект от каналов продаж.

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

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

Быстрое прототипирование и контролируемое развитие системы аллокаций

Проект внедрения можно разбить на несколько фаз.

Первую версию системы аллокаций лучше реализовать как прототип для целевой большой модели. Такая реализация, в минимуме аналитик, на упрощённых драйверах, наглядна, легко проверяема, её просто исправить, полезный результат будет готов быстро, в горизонте недель/нескольких месяцев.

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

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

Activity-based budgeting

Подход к калькуляции бюджета под целевой план продаж ABB — это не инверсия ABC уже потому, что потребуется множество итераций и активное участие подразделений планирования и закупок/производства для пересчёта, для схождения к финансово-реалистичному результату.

Обычно ABB противопоставляют "традиционному" подходу, где объём расходов планируют от прошлого года, меняя бюджетные статьи пропорционально предлагаемым изменениям плана. Последнее в наше время уже редкость, в большинство бюджетов уже принято включать элементы аллокаций, используя драйвера и нормы расходов. ABB похож на target costing.

Основная идея: реализуется две калькуляции, отвечающие за производственный цикл и финансовый цикл.

Производственный цикл калькулируется по аллокациям: план продаж => объекты затрат => Процессы/операции => Ресурсы. Далее, если потребности в ресурсах не соответствуют ожиданиям (финансовый цикл даёт неприемлемый результат, например, потребуются существенные вложения в закупки или капитальные — в мощности) делается балансировка производственного цикла, на одном из уровней аллокации корректируем: ресурсы (новые поставщики/собственные мощности, кадры и ФОТ...), техпроцесс (удешевление), план продаж.

Финансовый цикл калькулируется по аллокациям: Ресурсы => Процессы/операции => объекты затрат => ценовая политика & финансовый результат. Если финансовый результат не соответствует ожиданиям, то возможна балансировка цикла: Ресурсы (торги по ценам, смена поставщиков, кадры и ФОТ...) => Процессы (аутсорс/инсорс) => Объекты затрат (ценовая политика/маркетинговые усилия) =>

Time-driven Activity-based costing

Подход Time-driven Activity-based costing появился как альтернатива базовой методике, как ответ на трудоёмкость актуализации баз ключей и человеческий фактор в целом, когда исполнители все расходы анкетируют как 100% потраченные на рабочие активности. Сторонники time-driven подхода используют аргументацию вида:

• обычный расчёт драйверов со 100% разнесением скрывает информацию о простое, делает невозможным оценку загрузки мощностей
• регулярное анкетирование исполнителей потребляет несоизмеримый объём человеко-часов
• пересчёт всей модели ресурсоёмок
• но можно посчитать стоимость часа работ (сотрудника или оборудования) на каждом процессе, аллокацией первичных ресурсов
• считать от наблюдаемых линейным менеджментом норм потребления в абсолютных значениях, а не процентов из анкет рядовых исполнителей
• финальный расчёт стоимостей процессов вести, перемножая два фактора:
  • стоимость единиц — например, стоимость часа сотрудника + стоимость часа рабочего места + стоимость часа оборудования
  • на количество потребовавшихся часов в течение отчётного периода

• заменять громоздкие цепочки переносов линейными формулами со встроенными условиями:
• Трудоёмкость оформления доставки = ЕСЛИ([морем], T1) + ЕСЛИ([ЖД], T2) ) + ЕСЛИ([авиа], T3)...

Такой подход предполагает упрощение моделирования: можно независимо варьировать стоимость часа процесса и сразу видеть влияние на стоимость. Также предлагается внедрить непрерывную актуализацию модели с интерактивным пересчётом.

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

Уголок ИТ и проектный офис

Рецепты неудачи при автоматизации или миграции на новую технологию

Методика аллокаций не проверена

Если нет эталона, по которому можно понять логику расчёта, то не только приёмка может стать нетривиальной, но и в целом в требования может попасть нереализуемая логика. Варианта тут два, либо всё-таки сделать такой макет в понятном всем участникам продукте (Excel?), либо явно в проект заложить поэтапное развитие системы, начиная с минимально проверяемой вручную аллокации, с отдельными этапами развития, с заложенными трудозатратами на переделку, если предыдущий этап "не получится". Сама работа над макетом поможет формализовать используемую терминологию, выявить в ней неявные противоречия.

Источники аллокаций не исследованы

Счетный пример позволяет заодно с алгоритмами, сформулировать требования по источникам данных:

• какие факты, в какой гранулярности (аналитической детализации) и какой периодичности потребуются
• какие возникают требования по ссылочной целостности

И ещё на этапе анализа для каждой позиции выяснить:

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

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

Меняем источники, методологию, требования к результату — на бегу

Это типичный проектный риск, при создании любой ИТ системы. Риск при внедрении систем аллокации расходов тут проявится, если полный цикл проекта разработки — от появления данных в источниках до реализации выгрузки результатов, не завершится к моменту подготовки очередной годовой бюджетной отчётности, когда на следующий год обычно происходит пересмотр требований к отчётности, методики и, в целом, многое может быть пересмотрено в учётной политике. Для снятия такого риска либо замораживаются изменения в требованиях к проекту, либо проект разбивается на этапы с дооценкой на доработки под уточнение требований в начале каждого этапа. Если риск не снимать, то проект может буквально погрязнуть в переделках, пытаясь и не успевая угнаться за требованиями бизнеса.

Недоступны носители экспертизы

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

Какие технологии скорее всего пригодятся

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

Часто, аллоцированные расходы нужно просуммировать по иерархии, например, все расходы головного офиса по одной статье — это агрегат, получаемый суммированием значений по статье по всем подразделениям ГО.

Естественными продуктами для реализации аллокаций являются специализированные OLAP системы, которые реализуют один из вариантов эволюционного развития принципов сводных таблиц Excel с адаптированным под многомерные расчёты языком формул и оптимизацией динамических (на лету) агрегаций по произвольным срезам больших (гигабайты) объёмов данных. Целевые требования производительности естественным образом склоняют к выбору in-memory систем. В них относительно небольшой объём первичных данных можно хранить на рядовых жёстких дисках, а основная расчётная нагрузка ложится на обработку массивов в памяти. И тут важна, в первую очередь, частота процессора, во вторую — многоядерность, т.к. зависит от реализации многопоточности.

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

СУБД

Вам потребуется СУБД, бесплатная, например Postgre, если всё-таки в периметр попадут не OLAP, а частично OLTP задачи.

• Для формирования единой базы расходов: "прокраски" данных первичного учёта, унификации аналитической детализации под потребности системы аллокаций.
• Оптимизация отдельных шагов аллокации. Сжатие-разжатие размерности, когда часть аналитик не задействована в аллокации. Простой по логике, но сложный по объёму драйвер.
• Если бизнес-пользователям критична трассировка, можно снизить стоимость и снизить нагрузку на механизм многомерного расчёта, выложив трассировку в виде журнала в витрину. Иногда бизнес-заказчик требует трассировку до первичного учёта, это трудоёмко, в периметр попадают регистры первичного учёта, системы ведения договоров. Снизить объём интеграции и нагрузки на внешние системы можно, сделав в витрине область первичных документов и делая driil-thorugh на неё.

Почтовая рассылка

Системе потребуется доступ к почтовому серверу для рассылки уведомлений.

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

Бекапирование сервера без остановки модели

Время простоя для снятия резервной копии должно быть минимально.

Система диспетчеризации и внешней автоматизации

Для дирижирования сложными зависимостями, запуска внешних задач, использования дополнительных вычислительных библиотек, потребуется доступ к функционалу написания скриптов. Наиболее популярный на данный момент — Python.

Механизм решения уравнений для расчёта аллокаций

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

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

Когда силами большого количества организаций и энтузиастов data science постоянно расширяется инструментарий интеллектуальной обработки данных, особенно важна возможность быстро интегрироваться, обсчитать альтернативным методом СЛАУ во внешней библиотеке, например, Python. Скорость тут основной фактор, поэтому такой подход оптимален, когда достаточно получить за один заход результат целого этапа аллокаций, но без догрузки потенциально большого объёма промежуточных расчётов.

Внешний BI

Для презентационного качества уровня систем рекомендуется использовать специализированные инструменты: Tableau, Qlick, PowerBI, IBM Cognos Analytics и им подобные.

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

Прочее

Технологии Single-signon, поддержка технологий межсистемного взаимодействия (Rest) и управления изменениями в коде (Git). Всё это сделает внедрение и работу с системой проще.

Обратная связь

За более подробной информацией или демонстрацией можно обратиться в компанию GlowByte, заполнив небольшую анкету ниже или отправить письмо по адресу fi@glowbyteconsulting.com.

<= Вернуться к спецпроекту