Бюджетирование: типовые проектные риски, или подводные камни внедрения

В области требований к системе

Компания «X» выбрала некую систему только потому, что у коллег по отрасли из компании «Y» внедрена такая же, и они довольны. Внед­рили у себя. Жизнь почти не улучшилась: наиболее важные процессы по­прежнему трудоемки и отнимают много времени

Компания «Y» использует систему в основном для управления структурой сбыта (вариантный анализ плана продаж). В компании «X» основной задачей является мотивация эффективной работы филиалов посредством трансфертного ценообразования

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

В области методологии

До внедрения системы бюджетирования в компании «X» планирование осуществлялось силами финансового департамента, а после внедрения все подразделения участвуют в полномасштабном бюджетном цикле. При этом процесс бюджетирования идет с большим трудом. Процесс отнимает неоправданно много сил и средств

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

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

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

В области взаимосвязи учета и бюджета

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

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

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

Определение сроков

В процессе формирования бюджета на следующий год компания «Y» решила автоматизировать систему бюджетирования. В начале нового года начали согласовывать и утверждать приобретение и внедрение системы. До октября и следующего бюджета было еще далеко, поэтому решение о внедрении было окончательно принято в конце весны. К началу осени выбрали поставщика решения и подписали договор на внедрение. Бюджет на следующий год по­прежнему формировался вручную

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

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

Выбор исполнителя

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

Часто для компании­интегратора бывает выгодно держать в штате малоопытных и дешевых консультантов

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

Выделение ресурсов

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

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

Заказчик не выделил достаточное количество человеческих ресурсов на проект

Реализация проекта внедрения требует не только денежных средств, но и привлечения людских ресурсов. Управление проектом со стороны заказчика не должно быть формальным. Хорошей практикой является выделение как минимум одного сотрудника, ответственного за бюджетную модель. Такой сотрудник должен иметь возможность уделять проекту не менее 70% рабочего времени и стать, по сути, «хозяином» бюджетной модели

Детализация данных

Внедрение системы бюджетирования в компании «X» оказалось дороже и заняло существенно больше времени, чем планировалось при заключении договора.

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

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

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

Стандартные НСИ

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

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

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

Определение границ проекта

В компании «Y» принято решение о внедрении автоматизированной системы бюджетирования. К определению целей проекта и требований к сис­теме привлечены все заинтересованные подразделения, учтены все высказанные пожелания. Требования представлены потенциальным исполнителям. Оценочные сроки и стоимость проекта потенциальными исполнителями существенно превышают средние показатели для систем такого типа

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

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

Выбор инструментария

Два случая. В первом случае компания «X» приобрела ПО и на его основе внедрила систему бюджетирования. Через несколько месяцев стало ясно, что ее производительности не хватает для решения поставленных задач. Во втором случае компания «Y» выбрала в качестве основы для системы бюджетирования мощное и дорогое ПО «на вырост». ПО было дорогим, оставшегося бюджета уже не хватило на качественное внедрение самой системы

Во многом успех проекта внедрения системы бюджетирования определяется выбором программного обеспечения

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

Есть неудачный опыт прошлых внедрений. Ничего не работало!

Определить четкие критерии оценки успешности.

Не хочу сразу покупать ПО на время разработки системы, а купить непосредственно перед вводом в эксплуатацию.

Использовать демоверсию ПО, или ПО из облака.

Мои коллеги из другой компании внедрили систему, и она отлично работает. Мы внедрили такую же, но она неэффективна!

Бизнес один, цели могут быть одни, но методы их достижения различаются.

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

У системы должны быть свои внутренние «хозяева»: бизнес­ и ИТ­специалисты

Есть опасность «подсесть» на услуги внешних консультантов.

Развивать собственную экспертизу и уделить особое внимание до­кумен­тированию.

Один недорогой продукт сразу «заткнет все дыры» в моих бизнес­требованиях

Каждой задаче свое решение. Эффективные пилотные проекты. «Есть слона по частям»