Интерпроком: Информационные технологии в бюджетировании

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


index.jpg

47bde893b4df1b64285393ec6676783a.jpg Чтобы использовать бюджет как инструмент управления и развития предприятия, он должен быть не только простым и понятным при формировании и выполнении, но и гибким для адаптации к изменениям. О том, как избежать возможных рисков в подобных проектах, рассказывает Любовь Ведешина, руководитель практики бизнес-аналитики компании «Интерпроком».

Статья в журнале "Экономика и жизнь", №23, 17 июня 2016

Практика

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

Все хотят применять анализ «что если…» и быстро получать информацию для принятия верных управленческих решений. При этом финансис ты становятся все более требовательными к скорости и простоте формирования получаемых отчетов. Результаты анализа должны быть актуальными, достоверными и наглядными, визуализация стала общей потребностью. «Если большие таблицы — это данные, то визуализированные данные (дашборды1) — уже информация», говорят пользователи. « Дашбордизация» — тренд 2016 г. Соответственно, без автоматизации для решения таких задач обойтись невозможно.

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

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

Приведем лишь некоторые типы препятствий, которые могут встретиться на пути к поставленной цели:

  • методологические;
  • организационные;
  • проектно­технические.

Методологические риски проявляются в отсутствии:

  • четко сформулированных требований к системе бюджетирования;
  • ее формализованной методологии;
  • связанности учета и бюджета.

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

Организационные риски можно выявить в процессе:

  • установления сроков выполнения проекта, их сложно определить точно;
  • выбора исполнителя работ, здесь возникают просчеты;
  • определения человеческих ресурсов со стороны заказчика, их часто недостаточно.

Описание ситуации с организационными рисками, анализ возникающих ошибок и возможные рекомендации по предотвращению подобных рисков приведены в табл. 2.

Проектно­технические риски связаны с:

  • неправильным выбором уровня детализации данных;
  • недооценкой важности стандартизации НСИ и фактических данных;
  • отсутствием четких границ проекта;
  • неправильным выбором инструментария (программного обеспечения).

Как избежать подобных рисков в той или иной ситуации, можно понять, исходя из информации, приведенной в т абл. 3.

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

В заключение приведем самые важные и часто возникающие вопросы, а также подходы к их решению (табл. 4).


Примеры методологических рисков и рекомендации по их недопущению (таблица 1)
Описание ситуации Причины Рекомендации
В области требований к системе

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

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

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

Примеры организационных рисков и рекомендации по их предотвращению (таблица 2)
Описание ситуации Причины Рекомендации
Определение сроков

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

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

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

Примеры проектно-технических рисков и как не допустить их (таблица 3)
Описание ситуации Причины Рекомендации
Детализация данных

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

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

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

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

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

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

Основные вопросы и подходы к их решению (таблица 4)
Основные вопросы Подходы к решению

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

Определить четкие критерии оценки успешности.
Не хочу сразу покупать ПО на время разработки системы, а купить непосредственно перед вводом в эксплуатацию. Использовать демоверсию ПО.
Мои коллеги из другой компании внедрили систему, и она отлично работает. Мы внедрили такую же, но она неэффективна! Бизнес один, цели могут быть одни, но методы их достижения различаются.
Внешние консультанты придут и решат все мои проблемы сразу. У системы должны быть свои внутренние «хозяева»: бизнес- и ИТ-специалисты
Есть опасность «подсесть» на услуги внешних консультантов. Развивать собственную экспертизу и уделить особое внимание до кументированию.
Один недорогой продукт сразу «заткнет все дыры» в моих бизнес-требованиях Каждой задаче свое решение. Эффективные пилотные проекты. «Есть слона по частям»

 

За дополнительно информацией обращайтесь, пожалуйста:

компания «Интерпроком», +7 (495) 781 92 64 доб. 290

Скачать статью:
Crystal_Clear_mimetype_pdf.png



Другие Мнение экспертов: