Но бюджетирование сложно именно как организационная техника, которая требует синхронной и целенаправленной деятельности большого количества трудящихся менеджеров. До его внедрения в положении изгоя на предприятия традиционно находится бухгалтерия. Нелегкая судьба бухгалтера обусловлена необходимостью регулярно и вовремя сдавать различные отчеты, причем строго по той форме, которая предусмотрена действующими нормативными актами. После внедрения бюджетирования вся фирма превращается в большую бухгалтерию и начинает считать, писать и сдавать. То есть нелегкая судьба уготована теперь практически всем менеджерам предприятия. Положение усугубляется еще и тем, что сдавать надо не только отчеты, но и планы, и делать это ежемесячно. Кроме того, за выполнение бюджета надо еще и отвечать.
Начиная процесс постановки бюджетирования, многие руководители не всегда понимают организационные последствия внедрения этого метода. Поэтому этот процесс обычно не доводится до конца, и полученные результаты, как правило, только добавляют «головной боли» финансовому директору, который его инициировал!
Схематически типовые стадии процесса внедрения приведены в таблице 2.
А) На первой стадии осуществляется структуризация статей бюджета и схем их консолидации. При правильном понимании финансово-экономической модели деятельности эта задача по силам любому профессиональному финансовому менеджеру. После ее решения у него появляется возможность планирования финансов в разрезе бюджетных статей, а также анализа того, какие отклонения не позволили предприятию достичь запланированного финансового результата. Но это только первый шаг в построении бюджетной системы. (Хотя часть компаний на нем ее и заканчивает).
Таблица 2 Стадии внедрения бюджетирования
|
А) Информационная структуризация
|
|
Кто Что
|
Планирование в разрезе бюджетных статей |
Консолидация бюджетов |
Ответственность за исполнение бюджетов |
Ответственность за соблюдение бюджетных регламентов |
Финансовый директор |
|
|
| |
|
Менеджеры компании
|
|
|
| |
|
Б) Распределение функций бюджетного планирования
|
|
Финансовый директор
|
|
|
| |
|
Менеджеры компании
|
|
|
| |
|
В) Стимулирование выполнения бюджетов
|
|
Финансовый директор
|
|
|
| |
|
Менеджеры компании
|
|
|
| |
Б) На следующем шаге необходимо распределить планирование значений бюджетных статей по так называемым «центрам финансового учета» (ЦФУ). Так проявляется еще одна базовая идея «бюджетирования», как метода краткосрочного финансового управления – компетентность в определении реальных значений бюджетных статей (как в части выручки, так и затрат) выше в месте их формирования, т.е. в подразделениях, ответственных за сбыт, производство и обеспечение деятельности, а не в финансовых и планово-экономических отделах. В организационном плане здесь должна быть решена задача построения регламентов оперативного сбора и консолидации плановых и фактических показателей. Эту стадию уже могут реализовать немногие – мешает отсутствие на предприятии четких организационных регламентов вообще! Добавление новых функций финансового планирования затруднено, когда неточно определены другие функции, выполняемые подразделением…
В) И, наконец, подлинная система бюджетного управления немыслима без создания модели финансовой ответственности – построение финансовой структуры с выделением центров финансовой ответственности (ЦФО). Только данная модель, предусматривающая ответственность и стимулирование менеджеров в зависимости от выполнения декларированных ими бюджетных показателей, делает систему бюджетирования работающей. То есть, в систему бюджетного управления вводится механизм, целью которого является обеспечение максимальной сходимости плановых и фактических данных. Теперь бюджет это не только консолидированный прогноз, составленный компетентными менеджерами, но и реальный финансовый план, который имеет конкретных исполнителей, лично заинтересованных в его выполнении!
Большие трудности при построении бюджетной системы вызывает также выделение в компании центров финансовой ответственности – ЦФО.
ЦФО могут включать объекты двух типов – влияющие на прибыльность и влияющие на платежеспособность. Первые – это традиционные центры доходов (ЦД), затрат (ЦЗ), прибыли (ЦП) и т.п. Они позиционируются относительно различных статей БДР – если подразделение отвечает хотя бы за одну статью, отражаемую в БДР, оно является ЦФО. Второй тип ЦФО – это центры ответственности за получение (поступление) и расходование (выбытие) денежных средств, которые позиционируются относительно различных статей БДДС! К ним целесообразно также отнести и центры инвестиций (ЦИ), которые полностью отвечают за денежные потоки по выделенному проекту.
В пределах одного ЦФО могут быть как центры обоих типов, так и только одного из них. Следует также обратить внимание, что финансовая структура предприятия, элементами которой являются ЦФО, базируется на отношениях функциональной подчиненности. В идеале следует стремиться к построению такой структуры организации, в которой организационная и финансовая структуры максимально бы совпадали!
Честно признаемся, что такая система бюджетирования, по нашим данным, пока не доведена до конца ни на одном российском предприятии. Да и на Западе правильно поставленное бюджетирование – это показатель высшей управленческой зрелости предприятия.
Надо иметь в виду, что задача внедрения бюджетирования не решается с помощью какой-то уникальной компьютерной программы – нашей или зарубежной. Традиционная автоматизация ориентирована на менеджмент ресурсов (финансовых или материальных). Напротив, при бюджетировании на первый план выходит согласованная и мотивированная работа большого числа людей, которая нереализуема без адекватной структурной организации деятельности и менеджмента персонала. Такое же различие, между специальными техниками логистики (например, статистическим управлением запасами) и организацией бизнес-процессов, что, опять таки, связано с синхронизацией и мотивацией работы «команды процесса»!
[9,19,20,25]
3. Состав и характеристика программного продукта для поддержки финансового планирования и учета (ИС "Инталев: Бюджетное управление для 1С: Предприятия 7.7")
3.1 Описание программного продукта
Обычно в компаниях существуют практически несвязанные контуры программной поддержки для отдельных функций и служб: бухгалтерской, коммерческой, финансовой. Часть данных собирается в торгово-учетном контуре (производственном, оперативном), еще часть собирается в бухгалтерской программе, а часть информации учитывается в электронных таблицах финансовой службы.
Бухгалтерия, используя свою программу, имеет цель подготовить отчетную информацию для фискальных органов, следовательно, регламент работ зависит от налоговой инспекции. Для принятия управленческих решений информации из бухгалтерских отчетов недостаточно в силу ее слабой детализации и оперативности и, кроме того, часто неадекватности реальной картине отчетной информации.
Торгово-учетный контур дает полное представление только об одном участке деятельности компании - закупке и реализации продукции. Этот контур обычно функционально не готов для ведения планирования и учета затрат на основную деятельность. Кроме того, на предприятии обычно нет возможности автоматического получения сводной отчетности по всем филиалам и подразделениям.
Сотрудники отделов самостоятельно пишут в электронных таблицах программы и макросы, которые предназначены для учета фактических затрат и ведения управленческого учета по основной деятельности. У каждого отдела непроизвольно рождается свой регламент сбора данных и форматы предоставления информации. Очень скоро система из электронных таблиц становится настолько разобщенной, что просто распадается на отдельные программные куски, которые трудно состыковать не только с программами других контуров, но даже между собой.
Компания "1С" проделала огромную работу и разработала комплексную конфигурацию, включающую в себя бухгалтерский, кадровый и торгово-учетный контуры. Это решило часть проблем учета, однако единой автоматизированной системы управления в российских компаниях практически нет. Для разработчиков данной конфигурации очевидно, что для качественной поддержки системы управления необходимо реализовать в ИС функции планирования, учета, контроля и анализа деятельности. Поэтому разработчики дополнили комплексную конфигурацию функциями финансового планирования и контроля (бюджетирования).
Специалистами были выделены следующие важные задачи при постановке бюджетирования, которые не имели адекватной программной поддержки:
·составление платежного календаря и определение приоритетов платежей;
·определение финансовых результатов и управление по центрам финансовой ответственности (ЦФО);
·планирование движения денежных средств и движения товарно-материальных ценностей;
·планирование доходов и расходов компании;
·построение и оценка внутренних показателей ликвидности и рентабельности компании и отдельных бизнесов;
·поддержка процесса коллективного планирования, документооборота.
Именно решение этих проблем и легло в основу разработанного специалистами фирмы "Инталев" модуля бюджетирования для комплексной конфигурации программного продукта "1С: Предприятие 7.7". В ходе решения поставленных задач выяснилось, что создаваемый модуль должен стать не только центром консолидации плановой и отчетной информации, но и центром получения всей управленческой отчетности: БДДС (бюджет движения денежных средств) и БДР (бюджет доходов и расходов) в форме, удобной для принятия управленческих решений. При этом благодаря тому, что модуль полностью внедрен в среду "1С: Предприятие 7.7", фактическая информация передается непосредственно от первичных фактических данных "1С: Предприятия 7.7", введенных всеми пользователями ИС. Плановая же информация вводится непосредственно в модуль бюджетирования сотрудниками, ответственными за планирование. Таким образом, была решена задача поддержки процесса коллективного планирования (несколькими менеджерами, бизнесами, отделами на разных уровнях управления) всей хозяйственно-финансовой деятельности.
Программный продукт должен создавать на предприятии интегрированное решение, не ломая, а дополняя имеющийся программный контур "1С: Предприятие 7.7. Комплексная конфигурация".
Необходимо заметить, что постановка бюджетирования в компании – процесс довольно трудоемкий, прежде всего в области организации: необходимо разработать структуру центров финансового учета компании, структуру бюджетов, регламенты бюджетирования и многое другое. При организации системы бюджетирования в компании можно использовать методические указания, разработанные "Инталев" и распространяемые отдельно. Таким образом, специалистами фирмы "Инталев" создан не только программный продукт по поддержке системы финансового управления, но и разработана методика постановки и внедрения бюджетирования, ставшая отдельным, не менее ценным продуктом. Программа стала только инструментом, резко увеличивающем свое значение в "умелых руках", т.е. при квалифицированном внедрении.
Таким образом, конфигурация служит для поддержки процесса бюджетного (финансового) управления. Его основная задача - это максимально способствовать менеджерам при принятии финансовых решений, освобождать их время от рутинных операций и обрабатывать большие массивы данных, предоставляя отчетную информацию в удобной для принятия решений форме.
Программный продукт разработан в среде "1С: Предприятие 7.7" и может работать только при наличии на компьютере установленной ИС "1С: Предприятие 7.7".
В зависимости от желания пользователя возможны следующие варианты установки программного продукта:
·Установка типовой конфигурации;
·Установка типовой конфигурации с внесенными в нее демоданными;
·Установка к существующей конфигурации.
При выборе первого варианта в процессе установки будет создана чистая БД программного продукта "Бюджетное управление". Прежде всего, она используется для промышленной эксплуатации ИС.
При выборе второго варианта в процессе установки будет создана БД программного продукта "Бюджетное управление" с внесенными в нее демоданными. Данная БД используется для знакомства пользователей с возможностями ИС и примерами заполнения объектов метаданных.
Третий вариант установки необходимо использовать в том случае, когда в фирме уже существует БД программного продукта "1С: Предприятие 7.7" с внесенными в нее первичными документами. Данный вариант установки позволит без потери информации обновить существующую конфигурацию программного продукта "1С: Предприятие 7.7" и создать в ней объекты ведения бюджетирования.
Если выбирается третий вариант установки программного продукта "Бюджетное управление", то непосредственно перед началом установки необходимо произвести архивирование обновляемых баз данных. [21,22,24]
3.2 Методология внедрения
Внедрение многих системных решений имеет весьма печальные последствия для компании, поскольку чаще всего система не оправдывает возложенных на нее ожиданий и организация не достигает поставленной цели. Внедрениесистемы – это далеко не только покупка программного обеспечения. Неважно, насколько хорош пакет программ, само по себе это не является гарантией того, что данное системное решение будет функционировать успешно. Составляющими успеха в данном случае являются: качественное программное обеспечение и проектирование системы, применение лучших достижений в области управленческого планирования и контроля и опыта высококвалифицированных специалистов по внедрению. При невыполнении хотя бы одного из этих условий проект обречен на провал. Компания 1C имеет большой опыт успешного внедрения системных решений. Она является признанным лидером в области разработки пакетов бухгалтерских программ.
3.2.1 Этапы внедрения системного решения
Методология разбивает процесс внедрения на 8 этапов:
·Выяснение потребностей организации
·Описание системного решения
·Адаптация системы к нуждам пользователей
·Технический дизайн
·Настройка системы
·Тестовая эксплуатация
·Ввод системы в эксплуатацию
·Анализ функционирования системы после ввода в эксплуатацию
Выяснение потребностей организации
Выяснение потребностей организации обычно происходит во время нашей первой встречи с клиентами. Сначала мы исследуем те проблемы, с которыми приходится сталкиваться компании. Изучив проблемную область, мы определяем сферу применения нового системного решения.
Описание системного решения
На данном этапе происходит идентификация процессов и характеристик, необходимых для успешного функционирования новой системы. Также выясняется, насколько эффективны возможности предлагаемого системного решения для удовлетворения потребностей органисов и характеристик, необходимых для успешного функционирования новой системы. Также выясняется, насколько эффективны возможности предлагаемого системного решения для удовлетворения потребностей организации
Адаптация системы к нуждам пользователей
Этот этап является прямым продолжением предыдущего. Здесь происходит детальное определение того, как система будет функционировать: как будет осуществляться сбор данных, их обработка. Кроме того, задаются параметры графического интерфейса пользователя.
Технический дизайн
На этом этапе мы определяем, как внедрить систему с технической точки зрения так, чтобы наилучшим образом совместить ее с имеющейся у вас ИТ-инфраструктурой.
Настройка системы
Следующим шагом является создание системы. Вся собранная на предыдущих этапах информация используется для того, чтобы сконструировать систему, способную обеспечить выполнение потребностей организации.
Тестовая эксплуатация
Ввод готовой системы в тестовую эксплуатацию. Система тщательно тестируется в соответствии с предварительно разработанным планом, поскольку необходимо убедиться в том, что она функционирует именно так, как было предусмотрено изначально.
Ввод системы в эксплуатацию
При условии успешного завершения тестовой эксплуатации, система вводится в промышленную эксплуатацию. На данной стадии проекта происходит обучение пользователей, настройка справочной системы и загрузка статистических данных компании, после чего система готова к работе.
Анализ функционирования системы после ввода в эксплуатацию
Значение этой последней стадии часто недооценивают, хотя мы полагаем, что она просто необходима. Оценка функционирования системы после ее внедрения подразумевает анализ работы, как конкретных исполнителей, так и руководителей всех уровней. Цель данного этапа - определить, действительно ли данная система обеспечивает поставленные задачи, а также какие изменения/усовершенствования (в том случае, если они необходимы) должны быть сделаны.
В ходе реализации проекта обязательно возникнет необходимость внесения изменений, вследствие чего:
·некоторые аспекты процесса внедрения могут оказаться вне пределов компетенции координационного совета
·могут потребоваться дополнительные затраты времени и средств
·внедрение может занять гораздо больше времени, чем планировалось изначально
·может потребоваться изменение исходной спецификации
Для полной адаптации системы к нуждам организации необходимо тщательное планирование процесса реализации проекта, применение лучших достижений в области управленческого планирования и контроля и качественное обучение персонала. Кроме того, в каждом конкретном случае внедрения программных продуктов обязательно надо учитывать специфику компании.
Невыполнение хотя бы одного из этих условий повлечет за собой либо полный провал проекта, либо превышение запланированных расходов и почти наверняка не обеспечит выполнение потребностей пользователей.
При выборе системного решения не следует делать поспешных выводов о необходимости внедрения его в вашей организации, основываясь только на впечатлении от демонстрации. Опытному продавцу не составит труда представить продукт в выгодном свете, скрыв от вас возможные проблемы как при его эксплуатации, так и в процессе внедрения. Риск в данном случае является неоправданным.
Гарантией успеха является не только высокое качество программного обеспечения, но и тщательно разработанная методология внедрения, применение которой позволит вашей организации получить эффективное системное решение без дополнительных затрат как времени, так и средств.
3.3 Начало работы
3.3.1 Заполнени е констант
В момент первого запуска конфигурации появляется диалоговое окно заполнения констант программного продукта "Бюджетное управление" (обработка ввода начальных данных). При этом часть констант является обязательной для заполнения, а часть констант – необязательной.
Работа с конфигурацией возможна только в случае заполнения всех обязательных констант. Такие константы располагаются на закладкеОсновныеобработки ввода начальных данных. Если обязательная к заполнению константа ссылается на справочник, в котором еще нет данных, то непосредственно в диалоговом окне выбора значения из справочника необходимо создать по крайней мере один элемент и указать его в качестве значения константы.
Необязательные к заполнению константы (располагаются на вкладкеВспомогательные) могут быть заполнены позже в процессе эксплуатации ИС как при помощи обработки заполнения констант планирования, так и непосредственно в общем списке констант ИС.
3.3.2 Настройка безопасности
Информация, хранящаяся в программе, часто имеет конфиденциальный характер, поэтому разработчики заранее предусмотрели гибкую систему безопасности.
Можно выделить несколько классов пользователей программы:
·Пользователи, которым не требуется никакого доступа к плановой и фактической информации (например, операторы или бухгалтеры расчета зарплаты)
·Пользователи, которым требуется полный доступ ко всей информации (например, финансовый или генеральный директора)
·Пользователи, которым требуется полный доступ только к фактической информации (например, бухгалтеры банка или кассы)
·Пользователи, которым требуется ограниченный доступ для введения части плановой информации (например, сотрудники ЦФО (ответственные распорядители по статьям БДДС и БДР), подающие заявки руководителю ЦФО)
·Пользователи, которым требуется ограниченный доступ к части плановой и фактической информации (например, Руководители ЦФО, ответственные за планирование в пределах данного ЦФО)
·Пользователи, которые вводят и изменяют только регламентную информацию (например, изменяют структуру справочников ЦФО, Статей и т.д.)
Каждый из указанных классов пользователей – это отдельная роль в системе. И возможны случаи, когда один и тот же сотрудник (должность) имеет несколько ролей в системе (наборы прав и интерфейс). Например, должность "Финансовый директор" может иметь роли "Финансовый директор группы" и "Менеджер планирования ЦФО "Управление".
Для первой группы пользователей реализовать безопасность просто – закрыть в Конфигураторе доступ к соответствующим пунктам интерфейса и закрыть права. Оставить можно только журналы и документы сообщений. Примером такого интерфейса является интерфейс бухгалтера ввода факта.
Для пользователей, которым требуется полный доступ ко всей информации (в частности, директорам) создается специальный интерфейс и набор прав. В справочнике пользователей следует установить свойствоПросмотр всех документов. При необходимости можно ограничить для данного круга пользователей ввод данных в документы и справочники, например, с помощью настройки интерфейса. В этом случае необходимо учесть, что для ввода данных через модуль "Гибкие бюджеты" требуется право на создание и проведение документов "Планирование". Разработчики в составе поставки предлагают свой вариант для пользователей такого класса (набор прав "Финансовый директор", интерфейс "Финансовый директор").
Есть ряд пользователей, которым нужно дать доступ только для ввода фактической информации. Типичным примером являются бухгалтеры, которые, вводя первичные документы, создают на их основании документыФактическое движение денежных средствиФактическое начисление доходов и расходов. Для таких пользователей надо дать полный доступ к этим документам и журналам, а также доступ на чтение к справочникамЦФО,Статьи,Аналитики. Если для данных пользователей предполагается получение отчетной информации по всей фактической, то в справочнике пользователей следует установить свойствоПросмотр всех документов. Но при этом запретить всякий доступ к действиям с документами планирования и запуску модуля "Гибкие бюджеты" (вызова обработкиГибкий бюджет). Разработчики в составе поставки предлагают свой вариант для пользователей такого класса (набор прав "Бухгалтер ввода факта", интерфейс "Бухгалтер ввода факта").
