Главная

Статьи

Библиотека статей

Финансовый менеджмент

Как выбрать систему бюджетирования?

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

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

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

• состав и свойства информационных объектов СБ;
• функциональность и алгоритмы;
• организация работы пользователей с системой;
• архитектура, платформа и средства интеграции.

Состав и свойства информационных объектов СБ.

Первое, на что стоит обратить внимание при изучении СБ, это состав ее информационных объектов. Именно они характеризуют информационную мощность системы, т. е. определяют, какими понятиями и с какой степенью детализации можно оперировать при выполнении работ по бюджетированию. Перечислим эти объекты:

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

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

1.2. Валюты, курсы. Как правило, консолидированный бюджет приводится к какой-нибудь определенной валюте, но иногда требуется его представление и в других их видах (чаще всего - в одной дополнительной). На первый взгляд, для данной цели можно обойтись простым пересчетом бюджета из одной валюты в другую. Однако если принять во внимание процесс планирования и учета, то окажется, что на этих этапах в систему просто необходимо вводить значения в разных валютах. Следовательно, нужно вести курсы, а еще лучше - различные виды курсов валют. Это может пригодиться при учете внешних и внутренних цен предприятия.

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

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

2. Бюджетные планы статей (информационное "сердце" СБ). Статьи бюджета в разрезе перечисленных выше справочников по своему назначению объединяются в планы статей. СБ должна содержать как минимум три таких плана: бюджет доходов и расходов, бюджет движения денежных средств, бюджет активов и пассивов (баланс). Но, как правило, для более полного учета специфики работы предприятия, реализации определенной методики бюджетирования и создания удобных в эксплуатации рабочих мест применяются следующие исходные и производные планы:

• бюджеты продаж и закупок (в стоимостном и натуральном выражении), определяющие операционную деятельность (прямые доходы и расходы), бюджет размещения и привлечения ресурсов, бюджет по бизнес-направлениям, бюджет проектов (это далеко не полный список видов бюджетов, применяемых для построения бюджета доходов и расходов);
• смета капитальных вложений и план резервов, определяющие косвенные и другие виды расходов, необходимые для получения общей картины движения денежных средств;
• бюджет движения финансовых ресурсов (специфичный для кредитных учреждений план), товаров, запасов, бюджет задолженности (БДДС - баланс движения денежных средств - в разрезе дебиторов и кредиторов), платежный календарь - средство контроля расходования средств;
• управленческий баланс, финансовый план и другие вспомогательные таблицы, облегчающие расчет финансовых результатов.

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

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

• хранение значений за определенный временной период (день, месяц, квартал, год), что может обеспечить различные режимы планирования и учета (в течение года - по кварталам, в течение квартала - по месяцам и т. д.), а также выполнение всестороннего анализа бюджета;
• неограниченная иерархия статей бюджета для обеспечения процессов агрегации и "сверления" информации (drill down) при анализе структуры бюджета;
• собственное и консолидированное состояние, план, факт, отклонение (абсолютное и процентное);
• возможность учета значений статьи в разных валютах и натуральном измерении;
• дополнительная аналитика статей (например, учет остатка невыполнения плана в условиях его перевыполнения с помощью внеплановых операций);
• проводки по бюджетным статьям, позволяющие документировать изменение их значений.

3. Первичная информация, используемая при расчете плановых и фактических значений бюджетных статей. Ее наличие в СБ является признаком развитости системы, устраняет ограничения "табличного" представления информации о бюджете (т. е. только в виде планов статей). К первичной информации для бюджетирования относятся:

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

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

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

1. Алгоритмы планирования. По своему назначению различаются следующие алгоритмы:

• расчет значений статей по временному горизонту планирования (их пересчет за разные временны/е периоды);
• расчет значений статей по ЦФО (Центры финансовой ответственности) (при планировании “сверху вниз” позволяет вычислить значение статьи для разных ЦФО на основании ее целевого значения, при этом применяются как весовые коэффициенты, так и справочники коэффициентов);
• статистические методы расчета для отражения в бюджете логики объемных операций, учета сезонных колебаний, розничных операций. Применение шаблонов расчета статей и настроек в виде языка формул;
• расчет одних значений статей на основании других;
• расчет значений статей по бюджетным документам и другой первичной информации;
• обеспечение процесса планирования “от достигнутого” - перенос значений статей с предыдущего периода, как планового, так и фактического, с использованием коэффициентов и без них;
• моделирование ситуаций “что, если”. Пересчет исходного распределения значений статей на основании изменения одного из запланированных показателей;
• реализация технологии “скользящего бюджета”, когда временной горизонт плана, равный кварталу, ежемесячно переносится на один месяц вперед по окончании очередного отчетного периода.

2. Алгоритмы учета исполнения бюджета.

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

• учет факта на основании данных бухгалтерского учета. Это алгоритмы расчета значений статей на основании остатков, оборотов и проводок по счетам. При этом применяются фильтры по маске, корреспонденции счетов и признакам аналитики, таблицы разноски по статьям и многие другие приемы, позволяющие получить в автоматическом режиме максимум информации по исполнению бюджета;
• расчет значений статей по данным внесистемного учета, по бюджетным документам и другой первичной информации. Он возможен только в системах с расширенным набором информационных объектов. Если сложности с получением первичной информации в СБ решены, то алгоритмы расчета будут представлять собой набор специализированных процедур, ассоциированных с видами документов.

3. Агрегация и консолидация - алгоритмы, в равной мере применяемые как при планировании, так и при фактическом учете.

3.1. Агрегация - расчет значений статей по временным периодам (например, квартальных значений - на основании ежемесячных). Агрегация должна выполняться по всем измерениям и иерархиям бюджетных статей, валютам, контрагентам и т. д. Эти алгоритмы просты, но требуют немалой вычислительной мощности системы.

3.2. Консолидация финансовых и количественных значений статей (значения статей нижестоящего уровня агрегируются в значения статей вышестоящего уровня). В данном случае речь идет о консолидации бюджетов ЦФО вплоть до бюджета всей организации. По способу реализации алгоритма консолидации системы с “таблично-файловой” организацией данных существенно отличаются от систем с единой базой данных (БД). В первом случае это множество операций, в том числе и неавтоматизированных, что требует специального рабочего места для “консолидатора”. Во втором - автоматическая процедура, мало отличающаяся от процесса агрегации.

Эти алгоритмы используются для перераспределения доходов и расходов по ЦФО в связи с учетом общекорпоративных затрат, а также в случае внутреннего ценообразования на ресурсы, материальные ценности, товары и т. п. Учет общекорпоративных затрат (в том числе на управление, коммунальные службы и пр.), как правило, выполняется в “обеспечивающих” подразделениях: АХО, службе автоматизации, автопарке и т. д. Нередко аллокации рассматриваются не только как набор алгоритмов разноски значений статей, но и как последовательность выполнения этих алгоритмов, когда исходными данными являются результаты предыдущих этапов расчета аллокаций.

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

• использование шаблонов при разноске значений статей - самый простой для пользователей способ, однако отличающийся максимальной жесткостью и не всегда удовлетворяющий требованиям методик бюджетирования;
• использование нормативов и дополнительных справочников при разноске значений статей (например, затрат на аренду в соответствии с занимаемыми ЦФО площадями); является расширением механизма шаблонов, позволяющим при описании алгоритмов оперировать массовыми данными;
• использование языка формул - как правило, позволяет реализовать практически все требования методик бюджетирования, однако неаккуратная их реализация в системе может привести к долговременным вычислениям;
• язык сценариев - самый гибкий и наиболее эффективный с точки зрения исполнения инструмент для описания алгоритмов аллокаций и трансфертов, однако требующий знания программирования.

5. Алгоритмы расчета финансовых результатов. Эти алгоритмы одинаково важны как при планировании, так и при учете исполнения бюджета; они предоставляют информацию о наиболее критических параметрах финансового управления (себестоимости, марже, рентабельности продуктов, активов, капитала, прибыли, оборачиваемости активов) по итогам выполнения тех или иных этапов бюджетирования. Анализ эффективности работы алгоритмов следует проводить на реальных объемах данных: только на них можно обнаружить, что время расчетов может оказаться непозволительно долгим.

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

При автоматизации коллективной работы с бюджетом различаются два принципиально разных подхода:

• файловая СБ;
• СБ с единой БД.

Типичный представитель файловой системы - СБ с применением Excel, где каждый специалист работает со своей персональной таблицей с последующим сбором и расчетом консолидированных данных. Слабой стороной файловых систем является жесткая регламентированность действий участников и высокие накладные расходы при консолидации данных. Например, изменение состава статей в процессе планирования приемлемо только до момента передачи файлов исполнителям процесса бюджетирования, а интерактивное планирование, защита и утверждение статей вообще невозможны. Как следствие, количество итераций при планировании существенно ограничивается временны/ми рамками.

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

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

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

• лимиты, защищенные статьи. Позволяют руководителям ЦФО более высокого уровня финансовой структуры устанавливать значения статей для ЦФО нижнего уровня, в рамках которых они могут выполнять планирование;
• утверждение статей и планов. Согласованные планы или значения отдельных статей фиксируются с целью предотвращения их несанкционированного изменения;
• примечания к статье. Своеобразный протокол комментариев к статье, который совместно ведут участники бюджетного процесса при согласовании ее значения;
• визуализация расхождений. Фильтрация или цветовое выделение критически важных рассогласований между планом и фактом с целью оперативного их контроля;
• контроль ошибок. Поскольку СБ помимо всего прочего - это широкий набор алгоритмов и взаимосвязанных вычислительных процессов, то наличие в системе средств протоколирования хода расчетов позволяет оперативно разобраться в возможных коллизиях и противоречиях значений бюджетных статей;
• версионность планов. Поддержка нескольких вариантов плана бюджета (как правило, достаточно трех - “оптимистичного”, “пессимистичного” и “оптимального”);
• возможность одновременного планирования в произвольных временны/х периодах. Устраняет искусственные ограничения временных периодов бюджетирования при планировании значений статей;
• возможность изменять состав и структуру статей одновременно для плана и факта (исполнения) бюджета (наиболее эффективно решается в СБ с единой БД);
• средства анализа бюджета (“сверление данных”, OLAP-анализ, ранжирование, кластерный анализ, тренды, анализ отклонений, долей и т. д.).

Архитектура и платформа, предусмотренные в СБ, должны удовлетворять общей концепции автоматизации предприятия. СБ с единой БД в технологии клиент - сервер может быть реализована как в двухуровневой, так и в многоуровневой архитектуре (с выделенным сервером расчетов, сервером для организации взаимодействия с пользователями и т. д.). В качестве БД можно использовать реляционную или многомерную модель, причем последняя применяется не только в связи с необходимостью многомерного представления бюджетной статьи, но и с целью ускорения вычислений. Вариант с хранилищем данных предъявляет особые требования к построению БД и применяется для решения задач финансовой консолидации данных системного и внесистемного учета, а также для автоматизации контроля исполнения бюджета.

При изучении СБ необходимо также учитывать имеющиеся в ней средства интеграции с другими системами (такими, как Excel, Word, электронная почта), а также наличие:

• генераторов отчетов. К ним могут относиться специализированные конструкторы отчетов, OLAP-средства, встроенные генераторы отчетов для конечных пользователей типа “одна кнопка”;
• языка формул и/или сценариев;
• открытого API-интерфейса, позволяющего развивать систему собственными силами.

Вместе со стандартными средствами СУБД и ОС система бюджетирования должна обеспечивать защиту информации и эффективное разделение доступа пользователей как к функциям (алгоритмам), так и к данным. Выбирая систему, вы выбираете и поставщика, поэтому не забудьте поинтересоваться условиями поставки, внедрения и сопровождения продукта.

С авторами можно связаться по адресу:  [email protected], [email protected].

Источник: www.bigspb.ru

Коротко о системе Е-МАСТЕР

Е-МАСТЕР® — система управления корпоративной информацией. Е-МАСТЕР® включает в себя возможности систем класса ECM (Enterprise Content Management). Система обеспечивает: Совместное создание и согласование документов Каждый документ может быть обсужден как при помощи прикрепленного к нему мини-форума, так и в главном форуме Разработанный документ может быть направлен на согласование по указанному маршруту Хранение документов любых форматов Хранение и передача документов в зашифрованном виде Встроенные системы восстановления после сбоев и резервного копирования Поиск документов Возможность поиска по ключевым словам и другим атрибутам документов (автор, дата создания…) Возможность поиска с помощью навигации по рубрикам Управляемый доступ к документам Возможность установки доступа к документам для различных категорий пользователей Возможность введения ограничений на работу с документами Функциональный интерфейс пользователя Веб-интерфейс, позволяющий просматривать карточки и скачивать файлы из системы хранения документов Удаленный доступ или работа пользователя из любой точки мира (при условии подключения к Интернету). Подробнее о Е-МАСТЕР >>

Система FLAMORY™

FLAMORY™ — уникальный программный продукт, позволяющий сохранять историю действий пользователя на компьютере, таких, например, как работа в приложениях Windows, посещения сайтов и д.р. Сохраненные последовательности действий, далее, можно просмотреть, сохранить в файл и передать коллегам. FLAMORY позволяет аккумулировать и делиться знаниями. Работая с FLAMORY, обмен опытом, обучение новых сотрудников, обсуждения технологий, становятся, как никогда ранее, простой и удобной, в практических аспектах, задачей. FLAMORY™ разрабатывается при участии специалистов KMSOFT. Скачать бета-версию можно по этой ссылке.

Версия для печати  |  Пользовательское соглашение