Почему бюджетирование не взлетает: 4 ошибки банков

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

Познакомьтесь, и пусть эта информация поможет кому-то избежать ошибок. Предупрежден – значит, вооружён.

Причина 1. Когда софт выбирают ушами

Вспоминаю пару тендеров, состоявшихся с разницей лет в 7, с разным софтом и проблемами «под копирку».

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

Спрашивается, почему это не выяснилось в ходе тендеров? Когда вендоры заполняли опросники по функциональности ПО, когда проводили демонстрации, когда настраивали макеты? Согласитесь, сложно не заметить добрую половину ИТ-системы.

А всё просто. Заказчик выбирал вендора, который услаждал его слух: «У вас будет крутой иностранный софт!» А то, что этот софт будет не пригоден для решения стоящих задач, предпочитал не видеть.

Кстати, в первом случае потом внедрили систему контроля от российского разработчика, а во втором просто продолжили контролировать платежи «на коленке».

Причина 2. Когда «баба-яга против»

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

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

Реакция «звезды Excel’я» тоже известна: жесткий саботаж на всех этапах – от выбора ПО, до передачи методических требований, согласования ТЗ и тестирования настройки системы. И да, в таких условиях стартовать и тем более реализовать проект с пользой получается далеко не у всех.

Но выход есть: воля и заинтересованность куратора проекта в результате способны творить чудеса.

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

Причина 3. Когда привычка сильнее здравого смысла

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

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

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

Эти и другие инициированные привычками рукотворные ограничения использования возможностей ПО способны свести «на нет» все преимущества автоматизации.

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

Причина 4. Когда упали при ходьбе

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

Причины бывают разные: затянули с началом работ, а сроки уже объявлены и надо отчитаться, или сложно перенести бюджет, или что-то еще. Увы, это не меняет сути проблемы – задачу, решение которой требует 6 месяцев, как например, разворачивание и настройка решения для контроля хозрасходов, невозможно решить за 2 или 3. Половина этого срока уйдет только на согласование методических требований к настройке ПО. То же самое при планировании – фиксация методики подготовки бюджета – задача, которая требует времени, в том числе на поиск решения «узких» методических вопросов. Предполагать, что можно завершить ее быстрее, чем за пару месяцев, - просто обманывать себя и других.

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