КАК ИЗБЕЖАТЬ ОШИБОК ПРИ ВНЕДРЕНИИ ФИНАНСОВЫХ СИСТЕМ

Неправильный выбор
системы под задачу

Многие компании совершают ошибку, выбирая систему автоматизации только по стоимости и базовым функциям, не учитывая масштабируемость, производительность и архитектурные особенности. Это приводит к техническим ограничениям, росту затрат и иногда — к полному пересмотру проекта после неудачного внедрения. Чтобы избежать подобных ошибок, необходим глубокий анализ требований, сравнение альтернативных решений и учет долгосрочных бизнес-потребностей.
СИТУАЦИЯ
Компания выбирает систему для решения определенного класса задач, например автоматизации финансового планирования и прогнозирования. Инициатором внедрения новой системы является финансовый департамент; он же единолично принимает решение по выбору итоговой платформы.
У сотрудников финансового департамента нет серьезного опыта в многокритериальном подходе сравнения различных платформ. В качестве основных критериев оценки используется «функциональное соответствие существующей методологии» и «стоимость решения». IT департамент не привлекается, и такие критерии как «масштабируемость», «производительность», «возможность доработки», «интеграционные возможности», «партнерская сеть» и т.д. даже не рассматриваются.
В итоге выбирается неподходящая платформа. Уже в процессе внедрения выясняются существенные ограничения, устранение которых либо требует существенных дополнительных затрат, либо вообще невозможно в силу совершенно иной парадигмы архитектуры (например, вместо быстрого in-memory движка по пересчету сложных цепочек зависимостей финансовой модели используется более медленный транзакционный подход с записью и последующим чтением данных с жесткого диска).
СУТЬ
Ключевая ошибка заключается в недостаточно системном подходе по выбору системы. Иногда выбор нужно начинать даже не с составления «шот-листа» систем, а непосредственно с выбора платформы. Например, до сих пор достаточно распространённой практикой являются попытки использования BI платформ в качестве основы для задач планирования и прогнозирования. Одной из причиной такого явления является путаница между понятиями CPM и BI. Отчасти, эту путаницу создают сами вендоры продуктов, пытающиеся охватить максимально широкий рынок и рекламирующие свои платформы как «универсальные решения».

Маркетологи, стараясь выделить преимущество своей платформы, в огромном количестве употребляют такие “преимущества”, как “Decision-making”, “Performance analysis”, “Analytics”, “ Data exploration”, “ Reporting” и создают у конечного потребителя, не являющимся экспертом в упомянутых классах систем, ложное впечатление взаимозаменяемости.

Несмотря на то, что с помощью BI систем действительно можно решить большую часть задач финансового планирования, такой выбор далеко не всегда будет удачным решением. Подробное отличие классов систем и области их применения мы описали в статье «CPM vs. BI: о чем не расскажут продавцы».
К ЧЕМУ ПРИВОДИТ
  • Большие дополнительные затраты на доработку
    В системе нет базовых, ключевых функций для решения специализированных задач. Например, для автоматизации FP&A на BI платформе скорее всего придется приобретать решения сторонних разработчиков или дорабатывать такую функциональность как «Удобный механизм ввода данных», «Аудит изменения данных», «Механизм согласования бюджетов» и т.д.
  • Проблемы с производительностью
    Система требовательна к производительности on-line пересчета больших массивов данных. Например, вместо быстрого in-memory движка по пересчету сложных цепочек зависимостей финансовой модели используется более медленный транзакционный подход с записью и последующим чтением данных с жесткого диска. Обеспечить оперативный пересчет больших моделей и получение итоговой отчетности за может стать нетривиальной задачей.
  • В сложных случаях: остановка проекта и выбор другой платформы
    Иногда неверный выбор платформы приводит к необходимости принятия непростых решений, таких как перезапуск проекта на новой платформе. Например, после окончания MVP оказывается, что масштабирование системы на новые задачи или площадки компании требуют серьезных вложений, которых в бюджете проекта просто не предусмотрено. Или производительность системы для решения поставленных задач резко падает на «промышленных» объемах данных и решить эту задачу в разумные сроки и за приемлемые деньги невозможно, потому что ограничения обусловлены архитектурой ядра системы.
ПРИМЕР ИЗ ПРАКТИКИ
Пример 1: Ошибка выбора BI вместо CPM

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

Однако после старта внедрения выясняется, что система не соответствует ожиданиям: Возможности ручного ввода ограничены – приходится искать и интегрировать альтернативное решение; наполнение справочников в интерфейсах системах затруднено – приходится максимально использовать НСИ из внешних систем; отсутствует полноценный механизм согласования бюджетов. Проект буксует, сроки запуска постоянно смещаются, расходы растут, а системой все еще нельзя полноценно пользоваться.

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

Пример 2: Использование модуля ERP системы

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

Стартует пилотный проект, для «обкатки» выбраны 2 компании группы. MVP заканчивается успешно – все требуемые функциональные бюджеты реализованы, аналитичность соблюдена, итоговые отчеты компании собраны. Начинается тиражирование моделей на остальные компании группы. Все компании работают в одной базе – конечной целью проекта является получение консолидированных планов и прогнозов по всей группе в целом. Одновременно вычисляемых данных становится на порядок больше, и финансовая модель начинает «тормозить». Сначала это кажется не очень критичным замедлением, но к концу проекта оказывается, что в некоторых случаях пересчет всей консолидированной модели занимает почти сутки.

Причина – специализированный модуль в ERP является хорошей альтернативной для небольших и средних финансовых моделей, но для очень больших моделей такой подход не работает. Модуль бюджетирования построен на транзакционных принципах (как, собственно, и вся остальная ERP). Бюджетная модель не может быть целиком загружена в оперативную память для быстрых пересчетов. ПО не использует OLAP принципы, в нем не реализованы различные оптимизационные механизмы по распараллеливанию он-лайн пересчетов.

В итоге, через полгода, принимается решение о переводе бюджетной модели на платформу одной из специализированных CPM систем. Перед этим каждый из потенциальных поставщиков решений получает задание на прототип с обязательным проведением нагрузочного тестирования. Наученное горьким опытом руководство компании требует убедительных доказательств, что система справится с объемами данных и количеством пересчетов модели холдинга.
ПРИЗНАКИ ПРОБЛЕМЫ
  • Отсутствие формализованных требований к системе
    Решение о выборе принимается без анализа собственных бизнес-процессов, проработки функциональных и технических требований к будущей системе, планов масштабирования.
  • Отсутствие сравнительного анализа альтернативных решений
    Компания выбирает решение без глубокой оценки рыночных предложений, анализа платформы на применимость к своим задачам, оценки систем по исчерпывающему набору критериев. Не проводятся конкурентные тендерные процедуры.
  • Основной критерий выбора – стоимость текущего решения
    Решение о внедрении системы принимается, главным образом, исходя из минимальной стоимости лицензий или экономии средств на начальном этапе. Не оцениваются долгосрочные затраты на поддержку, развитие, доработку и кастомизацию системы под изменяющиеся потребности бизнеса.
  • Отсутствие плана масштабирования системы
    Система выбирается под текущие задачи без анализа роста модели по мере накопления данных за прошлые периоды или расширения функционального покрытия на новые площадки компании. Уже через несколько лет выбранная платформа может не справляться с возросшими объемами данных, что вынуждает бизнес нести новые затраты на миграцию на более мощное решение.
КАК ИЗБЕЖАТЬ ОШИБКИ
Глубокий анализ требований перед выбором системы
Необходимо сформулировать и зафиксировать ожидания от будущей системы. Это может быть исчерпывающее техническое задание, или, если выбирается платформа,чек-лист, содержащий исчерпывающие аспекты выбора.
Консультации с экспертами рынка
При выборе системы рекомендуется обратиться к профессионалам, имеющим опыт внедрения различных классов систем, которые смогут объективно оценить плюсы и минусы каждого решения. Хорошей практикой являются референс-визиты к компаниям, уже использующим рассматриваемые системы для аналогичных или схожих задач.
Сравнение альтернативных решений
Помимо функционального покрытия и стоимости решения, используйте такие критерии оценки как производительность, интегрируемость, возможность доработки, масштабируемость, развитость партнерской сети и наличие специалистов по системе на рынке.
Прототипирование ключевых процессов
До заключения контракта на полномасштабное внедрение создайте совместно с подрядчиком прототип. Оцените применимость продукта для ваших задач на базе Minimal Viable Product (MVP).
Учитывайте перспективы развития бизнеса
Выбирайте платформу с учетом долгосрочных планов компании: предусмотрите возможности масштабирования, интеграции новых функций роста нагрузки на систему.
Считайте не текущую стоимость лицензии, а Совокупную Стоимость Владения ПО (TCO)
Для критерия «Цена» используйте не начальную стоимость текущих лицензий или подписки на год (вендоры очень часто вначале дают огромные скидки, чтобы «продать» свое решение), а стоимость программного обеспечения на 3-5 лет вперед. Это включает дозакупку лицензий, стоимость обновления версий, техническое сопровождение, а для on-premise инсталляции также затраты на аппаратное обеспечение (серверы, хранилища и т.д.).