Так бывает, что EPM-платформа в некоторых компаниях становится чуть ли не первой платформой (после ERP), автоматизацией которой занимаются планово-экономические подразделения компании. К этому времени обычно накапливается много задач, и все их очень хочется решить в ходе проекта внедрения. В этом случае есть риск «перегрузки» системы функциональностью.

На первый взгляд кажется, что сделать всё в одном инструменте – удачное решение: уже есть лицензии и команда подрядчика, которая понимает требования и может их тем или иным способом реализовать. К сожалению, подрядчик тоже не всегда способен оценить все риски такой «перегрузки», особенно если он сконцентрирован на одном единственном продукте.

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

- «А что, так нельзя?! Ведь многие из этих функций декларирует и сам вендор», - спросите вы.

- «Можно, только осторожно!», – ответим мы.

Давайте рассмотрим подробнее эти три кейса:

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

2. EPM как хранилище данных.
Если вам нужно обработать таблицу в детализации плана счетов 1С и с помощью мэппинга преобразовать это в управленческий план счетов, то EPM легко решит эту задачу. Или вам нужно сгруппировать по аналитикам (превратить в куб) транзакционную таблицу, в которой содержится несколько тысяч записей – это тоже работает. Но вот если таких таблиц много и в каждой десятки тысяч записей, которые в дальнейшем группируются и используются только для расчета укрупненных фактических норм расходов, то лучше вынести это в витрины ХД. В противном случае вы можете получить значительную просадку в производительности вашего EPM решения.

3. Детальное планирование по Номенклатуре/Договорам/Клиентам в EPM системе.
В первую очередь стоит оценить необходимость детального планирования и горизонт составления таких планов – иногда сбор детальных данных делается по привычке, при этом такая детальность не позволяет перейти от статичных, то есть жёстко привязанных к плановому объему реализации, бюджетов, к гибким бюджетам, которые пересчитываются в зависимости от уровня деловой активности. Мы рекомендуем нашим клиентам ограничиваться наиболее значимыми/дорогостоящими ТМЦ или планировать по существенным клиентам и договорам, если такая детализация действительно необходима. В этом случае не только не пострадает производительность, но и стоимость владения EPM системой будет ниже, так как она в том числе определяется объемом процессорных мощностей, дискового пространства и оперативной памяти. Для детального оперативного планирования закупок и заявок гораздо лучше подходит ERP система.

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