4. Взаимодействие со сторонними организациями в рамках деятельности департамента:
5. Ежедневный мониторинг наличия денежных средств на счетах ЗАО «Телмос»; анализ достаточности денежных средств для финансирования текущей деятельности Компании;
6. Контроль за своевременным и правильным исполнением налогового календаря;
7. Организация процесса подготовки и контроль за своевременным представлением отчетов для руководства и акционеров ЗАО «Телмос», регулирующих органов, которая включает:
8. Анализ финансовых условий и визирование хозяйственных и клиентских договоров;
9. Оценка и дальнейший контроль за финансово-экономической обоснованностью долгосрочных финансовых вложений (инвестиционный анализ);
10. Анализ результатов финансово-хозяйственной деятельности ЗАО «Телмос»;
11. Осуществление мероприятий по совершенствованию текущей деятельности Департамента, а именно:
Глава 3. Автоматизация бюджетного управления в деятельности финансовой службы ЗАО «Телмос»
В первой главе данного дипломного проекта были сформулированы и обоснованы критерии, которым должна соответствовать система, предназначенная для ведения бюджета. В рамках данных критериев оценка систем дана по следующим направлениям:
В таблице 1 представлен сравнительный анализ наиболее известных из существующих на сегодняшний момент систем бюджетирования.
Таблица 1.
На основании сравнения и анализа вышеперечисленных систем автором была смоделирована система бюджетного управления для ЗАО «Телмос», которая полностью отвечает потребностям данного предприятия и при этом содержит элементы, присущие системам вышеперечисленных разработчиков
Система управления финансами ЗАО «Телмос» формировалась спонтанно. Сначала была создана база данных, которая включила в себя информацию по договорам, контрагентам, оборудованию и так далее. Потом был организован доступ сотрудников подразделений к этой базе данных. В процессе работы сотрудников подразделений с базой, данные в ней изменялись, а в задачу финансовой службы (в части бюджетного управления) входил сбор, анализ и корректировка измененных данных с целью формирования бюджета предприятия.
Все усовершенствования в базе производились по мере возникновения проблем или неудобств, с которыми сталкивались сотрудники при работе с ней.
Руководством ЗАО «Телмос» было принято решение о самостоятельном решении проблем бюджетного управления, без обращения в консалтинговые компании и без покупки готового программного продукта по автоматизированному финансовому управлению.
... Предметом экономического анализа являются хозяйственная деятельность строительной организации и её результаты, изучаемые по данным учёта ... анализе хозяйственной деятельности особое значение приобретает изучение экономической эффективности технического прогресса, специализации и кооперирования, совершенствования форм и методов хозяйствования, организации и управления. При экономическом анализе ...
В данном дипломном проекте система бюджетного управления смоделирована в полном объеме таким образом, чтобы упорядочить и усовершенствовать деятельность существующей.
SADT — одна из самых известных и широко используемых систем проектирования. SADT (аббревиатура выражения Structured Analysis and Design Technique — методология структурного анализа и проектирования) — это методология, разработанная специально для того, чтобы облегчить описание и понимание искусственных систем, попадающих в разряд средней сложности.
Описание системы с помощью SADT называется моделью. В SADT-моделях используются как естественный, так и графический языки. Для передачи информации о конкретной системе источником естественного языка служат люди, описывающие систему, а источником графического языка — сама методология SADT. В дальнейшем вы увидите, что графический язык SADT обеспечивает структуру и точную семантику естественному языку модели. Графический язык SADT организует естественный язык вполне определенным и однозначным образом, за счет чего SADT и позволяет описывать системы, которые до недавнего времени не поддавались адекватному представлению.
С точки зрения SADT модель может быть сосредоточена либо на функциях системы, либо на ее объектах. SADT-модели, ориентированные на функции, принято называть функциональными моделями, а ориентированные на объекты системы — моделями данных. Функциональная модель представляет с требуемой степенью детализации систему функций, которые в свою очередь отражают свои взаимоотношения через объекты системы. Модели данных представляют собой подробное описание объектов системы, связанных системными функциями. Полная методология SADT поддерживает создание множества моделей для более точного описания сложной системы.
Одна SADT-диаграмма сложна сама по себе, поскольку она содержит от трех до шести блоков, связанных множеством дуг. Для адекватного описания системы требуется несколько таких диаграмм. Диаграммы, собранные и связанные вместе, становятся SADT-моделью. В SADT дополнительно к правилам синтаксиса диаграмм существуют правила синтаксиса моделей. Синтаксис SADT-моделей позволяет аналитику определить границу модели, связать диаграммы в одно целое и обеспечить точное согласование между диаграммами. Никакой другой метод структурного анализа не позволяет так точно, как SADT, соединять диаграммы в тщательно организованные комплекты, называемые моделями.
Декомпозиция формирует границы, и каждый блок в SADT рассматривается как формальная граница некоторой части целой системы, которая описывается. Другими словами, блок и касающиеся его дуги определяют точную границу диаграммы, представляющей декомпозицию этого блока. Эта диаграмма, называемая диаграммой с потомком, описывает все, связанное с этим блоком и его дугами, и не описывает ничего вне этой границы. Декомпозируемый блок называется родительским блоком, а содержащая его диаграмма — соответственно родительской диаграммой. Таким образом SADT-диаграмма является декомпозицией некоторого ограниченного объекта.
Принцип ограничения объекта встречается на каждом уровне. Один блок и несколько дуг на самом верхнем уровне используются для определения границы всей системы. Этот блок описывает общую функцию, выполняемую системой. Дуги, касающиеся этого блока, описывают главные управления, входы, выходы и механизмы этой системы. Диаграмма, состоящая из одного блока и его дуг, определяет границу системы и называется контекстной диаграммой модели. Таким образом, этот блок изображает границу системы: все, лежащее внутри него, является частью описываемой системы, а все, лежащее вне него, образует среду системы.
SADT-модели развиваются в процессе структурной декомпозиции сверху вниз. Сначала декомпозируется один блок, являющийся границей модели, на одной диаграмме, которая имеет от трех до шести блоков, затем декомпозируется один (или больше) из этих блоков на другой диаграмме с тремя-шестью блоками и т.д. Название диаграммы совпадает с названием декомпозируемого блока. Результатом этого процесса является модель, диаграмма верхнего уровня которой описывает систему в общих терминах «черного ящика», а диаграммы нижнего уровня описывают очень детализированные аспекты и операции системы.
|
Контур Корпорация. Бюджет. Разработчик: Intersoft Lab. Партнер: ТрастКонто.
|
|
1. Состав и свойства информационных объектов
|
|
1.1. Измерения бюджетных статей
|
Система поддерживает все необходимые измерения для ведения бюджета многофилиальной организации. Бюджет можно планировать и анализировать в следующих разрезах:
- Организационно-штатная и финансовая
- Валюты, курсы.
- Продукты, услуги, материальные ценности.
- Клиенты, потребители и поставщики.
|
|
1.2. Бюджетные планы статей
|
В системе предлагаются планы статей для ведения:
- бюджета доходов и расходов,
- бюджета активов и пассивов,
- бюджета движения денежных средств,
- сметы капитальных вложений,
- бюджета проектов (направлений деятельности).
Состав статей этих планов может быть изменен и настроен под задачи конкретной организации. Кроме того, можно дополнительно создать свои бюджетные планы, их состав неограничен.
|
|
1.3. Первичная информация
|
Система построена на базе Хранилища данных, в котором может быть собрана вся необходимая первичная информация для бюджетирования:
- Бюджетные строки и бюджетные документы. Для расчета значений бюджетных статей могут быть использованы бюджетные документы, заявки, договора, аналитические и другие виды документов, данные счетов и показателей.
- Объекты поддержки финансовой логики. Система обеспечивает сбор и хранение в едином Хранилище первичных данных бухгалтерского и управленческого учета: документов с проводками по счетам, остатков и оборотов по счетам, показателей. Эти данные можно использовать для автоматического расчета фактического исполнения бюджета.
|
|
2. Функциональность и алгоритмы системы
|
|
2.1. Алгоритмы планирования
|
Реализация технологии «скользящего бюджета». В системе предусмотрена возможность планирования по кварталам с разбивкой по месяцам.
|
|
2.2. Алгоритмы учета и исполнения бюджета
|
- Учет факта на основании данных бухучета.
Предлагаемое в системе Хранилище ориентировано также на хранение первичных данных бухгалтерского учета. Механизм интеграции системы позволяет собирать эти данные из различных внешних источников, а специальные алгоритмы рассчитывать на их основе фактические значения бюджетных статей.
- Расчет значений статей по данным внесистемного учета.
Штатные режимы системы обеспечивают расчет значений статей по данным внесистемного учета, находящимся в Хранилище (бюджетным документам, показателям и др. первичным данным).
|
|
2.3. Агрегация и консолидация учетных данных
|
- Агрегация значений статей.
В системе выполняется автоматическая агрегация значений бюджетных статей по временным периодам и по иерархии статей в плане.
Система обеспечивает автоматический расчет:
|
|
2.4. Аллокация и трансферты
|
- Использование шаблонов при разноске значений статей.
- Использование нормативов и дополнительных справочников.
- Использование языка формул. Система имеет встроенный язык формул. С помощью формул можно задавать, например, алгоритм перекрестных распределений затрат (аллокаций) в виде системы линейных уравнений.
- Скриптовый язык.
Для описания алгоритмов аллокаций и трансфертов могут использоваться языки Python и Visual Basic.
|
|
2.5. Алгоритмы расчета финансовых результатов
|
По итогам этапов бюджетирования (планирования, учета исполнения бюджета) рассчитывается ряд показателей, в частности, смета капитальных вложений по бизнесам и подразделениям, расходы на каждого сотрудника, финансовый план по бизнесам и подразделениям и др.
|
|
3. Организация работы пользователя с системой
|
|
3.1. Автоматизация коллективной работы с бюджетом
|
Пользователи могут работать с Хранилищем данных через клиентские приложения в локальной сети, через удаленных клиентов и web-клиентов. Пользователь может вводить, редактировать, просматривать и анализировать бюджетные данные, в зависимости от заданного для него уровня доступа.
Коллективно составляя бюджет в едином Хранилище, все пользователи могут интерактивно взаимодействовать друг с другом, обсуждая и согласовывая бюджетные показатели.
|
|
3.2. Удобства в работе с системой
|
- Лимиты, защищенные статьи. Руководители могут задавать лимиты на значения бюджетных статей подразделений, выше которых планировщики не смогут задавать показатели.
- Утверждение статей и планов. После согласования любую статью бюджетного плана можно утвердить, после чего она будет заблокирована от изменений. Также можно утвердить целый бюджетный план, после чего будет запрещена корректировка всех его статей.
- Примечания к статье. Для каждой статьи бюджетного плана можно писать примечание.
- Визуализация расхождений. Разделы бюджетного плана, в которых выявлено расхождение плана и факта помечаются красным цветом.
- Контроль ошибок. В системе операции по загрузке данных и все расчеты, выполняемые на этапе бюджетирования, протоколируются. Информация о текущем процессе загрузки\расчета и его результатах приводится в специальных журналах.
- Версионность планов. В системе по каждой статье плана хранится история изменения ее состояний — даты открытия и закрытия статьи в плане и история установки значений статьи.
- Возможность одновременного планирования в произвольных временных периодах. В рамках одного плана можно задавать показатели за год, квартал, месяц, день.
- Возможность изменять состав и структуру статей одновременно для плана и факта (исполнения) бюджета.
- Средства анализа бюджета. Среди них:
-
- Интерфейс контроля исполнения бюджета, в котором можно получить информацию об исполнении бюджета в абсолютном и процентном выражении, пояснения об исполнении плана по бюджетным статьям и др. информацию.
- Генератор отчетов, встроенный во все интерфейсы для работы с данными Хранилища. Чтобы получить отчет достаточно сделать нужную выборку данных и нажать кнопку запуска генератора.
- Кластерный анализ, позволяющий объединять статьи в группы (кластеры) по заданным признакам, сравнивать группы, выявлять среди них наиболее и наименее доходные\расходные.
- Факторный анализ для выявления обстоятельств (факторов), повлиявших на значение статьи бюджета.
OLAP-анализ. С помощью OLAP-клиента Контур Стандарт можно выполнят ь динамический анализ данных Хранилища, генерировать «на лету» произвольные отчеты. В составе OLAP-клиента предлагается набор готовых форм динамических отчетов для получения и анализа финансовых планов по бизнес – направлениям и подразделениям, сметы капитальных вложений, структуры доходов и расходов по сотрудникам и др.
|
|
3.3. Секретность и безопасность данных
|
Типы пользователей и права доступа.
В системе предопределены следующие группы пользователей:
В специальном журнале протоколируются все действия пользователей системы.
|
|
4. Архитектура, платформа, средства интеграции
|
|
4.1. Архитектура
|
Система построена на базе Хранилища данных. Хранилище данных имеет реляционную (relational) архитектуру со схемой «снежинка» (ROLAP).
Архитектуру Хранилища данных можно сделать гибридной (HOLAP), используя многомерные БД в качестве витрин данных, в которые будет импортироваться информация из Хранилища.
Структура Хранилища данных настроена на хранение бюджетных данных (бюджетных планов), данных бухгалтерского учета (лицевых и балансовых счетов, документов), данных внесистемного учета (бюджетных документов и др.)
|
|
4.2. Программно – аппаратная платформа
|
- Сервер: Требования к машине-серверу диктуются предполагаемым объемом данных Хранилища.
- Клиентские ПК: Клиенты могут работать на ПК с процессором Pentium и ОЗУ не менее 32 Mb. От мощности процессора и объема оперативной памяти клиентской машины, зависит скорость аналитической обработки данных Хранилища.
- Программное обеспечение: ОС MS Windows NT; дополнительное ПО: Internet Explorer v. 5.0, MS Excel, MS Word.
|
|
4.3. Средства расширения функций системы
|
Система открыта для расширения и модернизации ее функциональных возможностей. Разработчику новых приложений предлагаются:
- Win API, Web API, Mail API — интерфейсы доступа к данным Хранилища. Используя API системы, можно создавать приложения к системе на любых языках программирования: Delphi, Си++ и др.
- Открытая библиотека прикладных классов системы и хранимые процедуры SQL для манипулирования данными Хранилища: выборки, ввода, изменения, удаления и др. операций с данными.
- Встроенный интерпретатор языка Python и функции вызова интерпретатора языка Visual Basic Script для реализации алгоритмов расчетов.
Редактор макропрограмм для написания программного кода на языках Python и VB Script.
|
|
4.4. Средства интеграции с другими средствами автоматизации
|
- Данные можно импортировать в офисные приложения Exсel, Word, Outlook
- Обмен данными между Хранилищем и внешними автоматизированными системами организуется с помощью XML-файлов.
|
|
Comshare MPC. Разработчик: Comshare Software. Партнер: Корус Консалтинг
|
|
1. Состав и свойства информационных объектов
|
|
1.1. Измерения бюджетных статей
|
Основные измерения, необходимые для ведения бюджета реализованы следующим образом:
- Организационно-штатная и финансовая структура поддерживается как стандартное измерение бюджетных статей, которое позволяет описать иерархию центров ответственности и пунктов консолидации.
- Валюты, курсы. Являются стандартным измерением бюджетных статей.
- Продукты, услуги, материальные ценности. Могут быть представлены как отдельные измерения бюджетных статей.
Клиенты, потребители и поставщики. Могут быть представлены как отдельные измерения бюджетных статей.
|
|
1.2. Бюджетные планы статей
|
В системе нет понятия «бюджетный план». Вместо этого статьи бюджета объединяются в группы, причем каждая статья может быть включена одновременно в несколько групп.
Заполнение группы статей может быть закреплено за каким-то одним конкретным подразделением.
Система позволяет хранить неограниченное количество различных версий бюджета.
Основные свойства бюджетных статей:
- Хранение значений во временных периодах.
- Иерархии статей бюджета нет. Статьи бюджета представляют собой плоский список.
- Собственное и консолидированное состояние, план, факт, отклонение. Встроенных типов данных «плановое значение», «фактическое значение» и «отклонение» в системе нет.
- Возможность учета значений статьи в разных валютах и натуральном измерении ограниченная.
- Дополнительная аналитика статей допускается.
|
|
1.3. Первичная информация
|
В системе не хранятся первичные данные (платежные поручения, мемориальные ордера, бюджетные документы, заявки и т.д.), которые могут быть использованы для расчета значений бюджетных статей. В качестве первичной информации представляются только данные по плановым расходам на зарплату сотрудников и амортизационным начислениям, причем в рамках отдельного модуля.
Система имеет механизмы поддержки финансовой логики. Например, каждая статья бюджета может быть одного из двух типов — статья Баланса и статья Отчета о прибылях и убытках. Это влияет на алгоритм расчета значений по ней.
|
|
2. Функциональность и алгоритмы системы
|
|
2.1. Алгоритмы планирования
|
|
|
2.2. Алгоритмы учета и исполнения бюджета
|
- Учет факта на основании данных бухучета. Автоматизированный учет факта является непростой задачей, поскольку все исходные данные находятся во внешних системах.
- Расчет значений статей по данным внесистемного учета. Выполняется только с применением внешних по отношению к системе средств.
|
|
2.3. Агрегация и консолидация учетных данных
|
Агрегация может производиться во всех аналитических разрезах в режиме реального времени. Все вычисления выполняются на сервере.
В системе реализованы различные алгоритмы консолидации. По умолчанию данные на более высоком уровне рассчитываются путем суммирования данных нижних уровней.
|
|
2.4. Аллокация и трансферты
|
- Использование шаблонов при разноске значений статей. Реализуется с помощью формул.
- Использование нормативов и дополнительных справочников, в которых задаются параметры расчета. Для ввода нормативов и других параметров могут быть созданы дополнительные группы бюджетных статей.
- Использование языка формул. Язык формул — неотъемлемая составляющая работы с системой.
- Скриптовый язык. Отсутствует
|
|
2.5. Алгоритмы расчета финансовых результатов
|
Система имеет механизмы поддержки финансовой логики (дебет/кредит, актив/пассив и т.д.).
Например, можно рассчитать исходящий остаток по балансовому счету за период как сумму его входящего остатка и оборотов, определяемых как значение по некоторой статье.
Система может автоматически выполнять перекрестную проверку значений указанных статей.
|
|
3. Организация работы пользователя с системой
|
|
3.1. Автоматизация коллективной работы с бюджетом
|
Многопользовательская работа в едином информационном пространстве — это один из ключевых элементов концепции системы Comshare MPC.
Все пользователи в режиме реального времени работают в единой базе данных.
В процессе планирования руководитель видит кто, когда и какие ввел значения, и имеет возможность вмешаться в этот процесс, самостоятельно снабжая те или иные данные пояснениями, пополняя план новыми показателями или не принимая очередной версии, если она приводит на верхнем уровне бюджета к неблагоприятной финансовой картине. Количество подобных уровней согласования бюджетов неограниченно.
|
|
3.2. Удобства в работе с системой
|
- Лимиты, защищенные статьи. Возможна эмуляция этой технологии посредством создания дополнительных версий бюджета и распределения прав доступа на просмотр и запрет редактирования.
- Утверждение статей и планов. С помощью функции focus range в системе существует возможность установить так называемые заблокированные области, которые определяются для каждой версии бюджета и периода времени.
- Примечания к статье. Пользователь имеет возможность присоединить текст к значению любого показателя в качестве пояснения.
- Визуализация расхождений. В системе поставляются отчеты, показывающие отклонение.
- Контроль ошибок. В системе для этого есть стандартный отчет.
- Версионность планов. Контролируется. Есть возможность установить дату, с которой начинает действовать та или иная версия бюджета.
- Возможность одновременного планирования в произвольных временных периодах. Предусмотрен способ привязки различных данных к определенным временным отрезкам.
- Возможность изменять состав и структуру статей одновременно для плана и факта (исполнения) бюджета. Можно непосредственно в процессе планирования пополнять бюджет новыми показателями.
- Средства анализа бюджета. Система поддерживает различные форматы и методы представления и анализа данных.
Во-первых, это разработка и предоставление по электронной почте стандартных отчетов, готовых к распечатке.
Во-вторых, это подготовка отчетов пользователями «на лету» с помощью встроенной в систему OLAP-компоненты. OLAP-отчеты имеют устойчивую связь с базой данных.
|
|
3.3. Секретность и безопасность данных
|
- Типы пользователей и права доступа.
Права пользователей в системе настраиваются в зависимости от их роли в процессе бюджетирования, а также от права доступа к той или иной структурной единице.
В системе выделяются следующие группы пользователей:
Для ведения пользователей и групп пользователей в системе предусмотрен отдельный модуль.
- Фиксация действий пользователей.
Фиксируется кто, когда и какие устанавливал значения и выполнял корректировочные проводки по бюджетным статьям.
|
|
4. Архитектура, платформа, средства интеграции
|
|
4.1. Архитектура
|
Comshare MPC имеет открытую архитектуру и может функционировать на основе различных как реляционных, так и многомерных СУБД. Это реализуется за счет выделения в качестве промежуточного слоя сервера приложений.
Для организации хранения данных в Comshare MPC используется схема «Звезда», которая состоит из центральной таблицы фактов (транзакций) и связанных с ней таблиц внешних ключей.
Собственного Хранилища исходных первичных данных нет.
|
|
4.2. Программно – аппаратная платформа
|
Одно- или двухпроцессорный компьютер класса Pentium III. Объем памяти — 1 GBОперационная система — Windows 2000, Windows NT, Unix, AS400. СУБД — Oracle 8i, MS SQL Server 7.0 или 2000, Hyperion Essbase 5.х или 6.0, IBM OLAP Server.
Операционная система — Windows 2000, Windows NT Microsoft Internet Information Server Microsoft Internet Authentication Services
Компьютер класса Pentium с ОС Windows 95, 98, 2000 или NT 4. 128-256 MB RAM Internet Explorer 4 (Service Pack 2) или 5. Связь с локальной сетью или доступ к Интернет
|
|
4.3. Средства расширения функций системы
|
- Генераторы отчетов. В качестве генератора отчетов применяется OLAP-компонента собственной разработки, которая предоставляет стандартные возможности по настройке источников данных и генерации отчетов.
- Язык формул, скриптовый язык. Язык формул имеется и является одним из важнейших инструментов системы. Скриптового языка в системе нет.
- Открытый API для программиста. Система имеет открытую архитектуру и предоставляет API для доступа к данным.
|
|
4.4. Средства интеграции с другими средствами автоматизации
|
- Интеграция с другими системами. Декларируется, что в системе существуют средства загрузки данных из внешних учетных систем, но, что конкретно они собой представляют, выяснить не удалось.
- Интеграция с офисными приложениями. Есть средства интеграции с MS Excel.
- Применение XML для интеграции с другими системами. В источниках информации упоминаний не обнаружено.
|
|
Hyperion Pillar. Разработчик: Hyperion Solutions Corporation. Партнер: Вестона (в составе холдинга Ланит).
|
|
1. Состав и свойства информационных объектов
|
|
1.1. Измерения бюджетных статей
|
Основные измерения, необходимые для ведения бюджета, реализованы следующим образом:
Клиенты, потребители и поставщики. Присутствуют плоские справочники — предприятия,
|
|
1.2. Бюджетные планы статей
|
В системе предложен следующий состав бюджетных планов: баланс, бюджет доходов и расходов, бюджет движения денежных средств. При планировании различаются также планы задолженности, собственных средств, основных средств, позволяющие автоматическое выполнение некоторых функций, характерных для этих планов.
Основные свойства статей бюджетных планов:
- Хранение значений во временных периодах. Период планирования в системе жестко определен — на 5 лет по месяцам, или на 15 лет по кварталам.
- Иерархия статей бюджета. Иерархия статей имеет 2 уровня: тип, номер.
- Собственное и консолидированное состояние, план, факт, отклонение. Собственное состояние есть только у планов нижнего уровня. Выше — только консолидированные состояния. Отклонение не присутствует в системе в виде данных, а моделируется связыванием различных бюджетов — плана и факта. При этом необходимо безусловное совпадение их
- Возможность учета значений статьи в разных валютах и натуральном измерении. Есть.
- Дополнительная аналитика статей. Нет.
- Проводки по бюджетным статьям. Нет.
|
|
1.3. Первичная информация
|
- Бюджетные строки и бюджетные документы. Вся первичная информация в системе представлена бюджетными строками предопределенной структуры.
- Объекты поддержки финансовой логики. Эта задача обеспечивается другим программным продуктом — Hyperion Enterprise (решение для финансовой консолидации в управленческих и отчетных целях).
|
|
2. Функциональность и алгоритмы системы
|
|
2.1. Алгоритмы планирования
|
- Расчет значений статей по временному горизонту планирования. С успехом настраивается с применением шаблонов.
- Расчет значений статей по ЦФО. В шаблоне возможно указание кода ЦФО.
- Применение статистических методов расчета. Предусмотрены некоторые встроенные функции статистического распределения. Реализовано в шаблонах.
- Расчет значений статей на основании значений других статей. Реализуется установкой связей между бюджетными строками через механизм шаблонов.
- Расчет значений статей по бюджетным документам и другой первичной информации. Это возможно, если только первичная информация будет преобразована вне системы в представление бюджетных
- Обеспечение процесса планирования «от достигнутого». Применяется режим процентного изменения и «пошагового увеличения/уменьшения».
- Моделирование «что если» присутствует в виде штатного средства, основанного на шаблонах.
- Реализация технологии «скользящего бюджета». Возможно ее моделирование посредством корректировки шаблонов.
|
|
2.2. Алгоритмы учета и исполнения бюджета
|
- Учет факта на основании данных бухучета. Весьма нетривиальная задача для системы. Для ее реализации необходимы внешние средства для преобразования данных бухгалтерского учета к структуре управленческого учета.
- Расчет значений статей по данным внесистемного учета. Также решается только с применением внешних средств по отношению к системе. Если удается подготовить текстовые файлы в строго заданном формате, соответствующем бюджетным строкам, то возможен их импорт в систему. Факт может быть введен в натуральном и денежном выражении.
|
|
2.3. Агрегация и консолидация учетных данных
|
- Агрегация. Агрегация выполняется по запросу «планировщика».
- Консолидация. После того, как «консолидатор» собирает от «планировщиков» бюджетные файлы, механизм контроля изменений выбирает изменившиеся бюджетные строки и автоматически выполняет их консолидацию.
|
|
2.4. Аллокация и трансферты
|
- Использование шаблонов при разноске значений статей. В системе существует единый универсальный интерфейс для настройки и выполнения разноски значений статей, рассчитанный на высококвалифицированного пользователя.
- Использование нормативов и дополнительных справочников. Программа позволяет задавать стандартные нормативы (такие, как уровень налогообложения или нормы расхода сырья) в виде системных переменных и затем использовать их в рамках всего бюджета.
- Использование языка формул. Представлено на уровне возможностей при настройке шаблонов.
- Скриптовый язык в системе. Отсутствует.
|
|
2.5. Алгоритмы расчета финансовых результатов
|
Автоматически выполняется расчет ликвидности, а также основных финансовых результатов в базовом финансовом инструменте. Для расчета себестоимости и подобных ей показателей необходимы дополнительные настройки.
|
|
3. Организация работы пользователя с системой
|
|
3.1. Автоматизация коллективной работы с бюджетом
|
Требуется отдельный сотрудник – «администратор бюджета» для дистрибуции и консолидации бюджетов подразделений и филиалов.
|
|
3.2. Удобства в работе с системой
|
- Лимиты, защищенные статьи. Возможна эмуляция этой технологии посредством выдачи прав доступа (на просмотр и запрет редактирования).
- Утверждение статей и планов. Возможно на уровне утверждения версии плана.
- Примечания к статье. Предусмотрен ввод комментариев на уровне бюджетных строк.
- Визуализация расхождений. Для контроля исполнения бюджета в системе необходимо создавать отдельные бюджетные файлы и следить за соответствием структур бюджета в файлах планов и файлах исполнения бюджета.
- Контроль ошибок. Отсутствует. Протокол вычислений в системе не ведется.
- Версионность планов реализована в системе очень удобно.
- Возможность одновременного планирования в произвольных временных периодах. К сожалению, в системе это не предусмотрено.
- Возможность изменять состав и структуру статей одновременно для плана и факта (исполнения) бюджета — отсутствует. При наличии подчиненных бюджетных планов необходимо вручную отслеживать в них изменения структуры статей.
- Средства анализа бюджета. Для OLAP-анализа необходимо применять Hyperion Essbase.
|
|
3.3. Секретность и безопасность данных
|
- Типы пользователей и права доступа. Распределение доступа пользователей к данным и функциям осуществляется с помощью типов пользователей – «планировщик», «консолидатор», «администратор бюджета». «Администратор бюджета» определяет для «планировщиков» доступ к бюджетным строкам на просмотр и редактирование.
- Фиксация действий пользователей. Фиксируется время и автор внесения изменений в бюджетных строках.
|
|
4. Архитектура, платформа, средства интеграции
|
|
4.1. Архитектура
|
- Hyperion Pillar — файловая система бюджетирования. Информационная основа — многомерные локальные файлы. Отдельный модуль Autopilot ответственен за автоматический выпуск отчетов, выполнение дистрибуции, консолидации файлов, экспорт-импорт информации.
- Хранилище данных может быть реализовано с применением другого программного продукта — Hyperion Essbase.
|
|
4.2. Программно – аппаратная платформа
|
Персональные компьютеры под управлением Windows или Macintosh.
|
|
4.3. Средства расширения функций системы
|
- Генераторы отчетов. Предусмотрено изменение состава и очередности колонок в формах при формировании отчетов. Применяется технология drag and drop. Предусмотрена интеграция с Hyperion Essbase OLAP Server (к сожалению, с единственным OLAP-сервером, с которым работает Hyperion Pillar).
- Язык формул, скриптовый язык. Существует язык формул, применяемый в шаблонах настройки расчетов. Скриптовый язык отсутствует.
- Открытый API для программиста. Система не предусматривает развитие функциональности силами пользователей.
|
|
4.4. Средства интеграции с другими средствами автоматизации
|
- Hyperion Application Link — специальный модуль, предназначенный для организации обмена данными с внешними реляционными источниками через ODBC. Предусмотрены специализированные интерфейсы для обмена данными с наиболее известными ERP-системами, например, SAP, Oracle Applications, BAAN, J.D. Edwards — в виде частных решений. Импорт данных из иных систем возможен посредством их загрузки из предопределенных текстовых форматов, отражающих структуру данных Hyperion Pillar.
- Интеграция с офисными приложениями. Предусмотрен экспорт и импорт бюджетных строк в Excel-таблицу.
- Применение XML для интеграции с другими системами. Отсутствует.
|
|
Adaytum e.Planning. Разработчик: Adaytum Software. Партнер: Robertson & Blums Corporation.
|
|
1. Состав и свойства информационных объектов
|
|
1.1. Измерения бюджетных статей
|
Допускается произвольное количество измерений. Предопределенных измерений нет. В «плоских» справочниках могут быть описаны все измерения, которые необходимы для детализации бюджета:
- Организационно-штатная и финансовая структура. Может быть описана как отдельное измерение бюджетного плана. При этом центры финансовой ответственности задаются в виде «плоского» справочника. Иерархия центров ответственности может быть эмулирована с помощью формул.
- Валюты, курсы. Валюты могут быть описаны как отдельное измерение бюджетного плана. Курсы для пересчета в сводную валюту могут быть эмулированы с помощью формул.
- Продукты, услуги, материальные ценности. Могут быть представлены как отдельные измерения бюджетного плана в виде «плоских» справочников.
- Клиенты, потребители и поставщики. Также могут быть представлены как отдельные измерения бюджетного плана в виде «плоских» справочников.
|
|
1.2. Бюджетные планы статей
|
В системе нет предопределенных планов и, соответственно, нет характерной для них бизнес-логики. Допускается произвольное количество бюджетных планов, которые пользователю предстоит создать и настроить самостоятельно.
Основные свойства бюджетных статей:
Встроенных типов данных «плановое значение», «фактическое значение» и «отклонение» в системе нет. План, факт и отклонение могут быть представлены как дополнительное измерение бюджетного плана. При этом расчет отклонения может быть настроен с помощью формул.
- Возможность учета значений статьи в разных валютах и натуральном измерении. Есть.
- Дополнительная аналитика статей. Есть.
- Проводки по бюджетным статьям. Нет.
|
|
1.3. Первичная информация
|
- Бюджетные строки и бюджетные документы.
Документы в системе хранить нельзя. Вся первичная информация может быть представлена только как значения ячеек многомерных таблиц (например, плановое и фактическое количество продаж).
- Объекты поддержки финансовой логики. Нет
|
|
2. Функциональность и алгоритмы системы
|
|
2.1. Алгоритмы планирования
|
- Расчет значений статей по временному горизонту планирования. Реализуется посредством функции пересчета исходного распределения. Требует предварительной настройки.
- Расчет значений статей по ЦФО. Реализуется посредством функции пересчета исходного распределения. Требует предварительной настройки.
- Применение статистических методов расчета. Реализуется посредством функции пересчета исходного распределения. Требует предварительной настройки.
- Расчет значений статей на основании значений других статей. Реализуется с помощью формул.
- Расчет значений статей по бюджетным документам и другой первичной информации. Реализуется с помощью специальных объектов D-Link, позволяющих настроить связь значений бюджетных статей с исходными данными. Пересчет значений на основе первичных данных выполняется непосредственно в момент загрузки данных в систему.
- Обеспечение процесса планирования «от достигнутого». Реализуется с помощью формул.
- Моделирование «что если». Реализуется с помощью формул и функции пересчета исходного распределения.
- Реализация технологии «скользящего бюджета». В явном виде данная технология не поддерживается. Она может быть эмулирована посредством корректировки значений бюджетных статей. При этом ранее установленные плановые значения не сохраняются.
|
|
2.2. Алгоритмы учета и исполнения бюджета
|
- Учет факта на основании данных бухучета.
Является достаточно сложной для системы задачей, поскольку отсутствует поддержка финансовой логики (счет, двухсторонняя проводка и т.д.) и все исходные данные находятся во внешних системах. Требуется разработка специальных внешних макропрограмм.
- Расчет значений статей по данным внесистемного учета. Также решается только с применением внешних по отношению к системе средств.
|
|
2.3. Агрегация и консолидация учетных данных
|
- Агрегация. Агрегация выполняется автоматически на компьютере пользователя и заключается в суммировании значений ячеек многомерной таблицы D-cube. Может быть задан один из нескольких простых алгоритмов агрегации — сумма, средневзвешенная и т.д.
- Консолидация. Консолидация также выполняется автоматически на компьютере пользователя. При этом отсутствует консолидация отдельных бюджетов на уровне приложения в целом.
|
|
2.4. Аллокация и трансферты
|
- Использование шаблонов при разноске значений статей. Не представлено.
- Использование нормативов и дополнительных справочников. Возможно. Для ввода нормативов и баз распределения могут быть созданы дополнительные многомерные таблицы D-cube.
- Использование языка формул. Это один из основных инструментов работы с системой.
- Скриптовый язык. Отсутствует.
|
|
2.5. Алгоритмы расчета финансовых результатов
|
Могут быть реализованы с помощью базовых механизмов системы, но потребуют дополнительной настройки.
Декларируется, что в системе есть большое количество специфических встроенных функций, предназначенных для финансового планирования. Но, что конкретно они собой представляют, выяснить не удалось.
|
|
3. Организация работы пользователя с системой
|
|
3.1. Автоматизация коллективной работы с бюджетом
|
Организация коллективного планирования бюджета является, пожалуй, самой сильной стороной системы.
Система построена по традиционной технологии «клиент-сервер» — все пользователи в режиме реального времени работают в единой базе данных.
Прогнозирование на уровне подразделений выполняется посредством специальных Web-шаблонов. Шаблоны можно настраивать, трансформируя столбцы и строки, выводя на экран или скрывая пустые и заполненные нулями поля.
После того, как пользователь ввел в систему всю необходимую информацию, ее можно сохранить в системе или передать на рассмотрение и утверждение менеджеру следующего уровня. Сохраненные данные отмечаются флажком «work in process» и остаются доступными для последующего редактирования. Переданным на рассмотрение данным присваивается флажок «locked», они доступны только для просмотра.
Менеджеры высшего уровня могут просмотреть статус всех шаблонов, за которые они непосредственно несут ответственность, увидеть детальную информацию по каждому изменению в отдельности и по всем изменениями в целом. После этого менеджеры высшего уровня могут принять их, либо попросить внести дополнительные изменения, либо самостоятельно исправить значения. В случае внесения дополнительных изменений менеджер получает сообщение по электронной почте о том, что ему нужно предупредить нижестоящих пользователей о необходимости внесения изменений, при этом статус изменяется с «locked» на «work in progress». В случае утверждения шаблона вышестоящим менеджером, он становится доступным для менеджера следующего уровня
|
|
3.2. Удобства в работе с системой
|
- Лимиты, защищенные статьи. В явном виде не реализовано. Возможна эмуляция этой технологии посредством выдачи прав доступа (на просмотр и запрет редактирования)
- Утверждение статей и планов. Возможно утверждение всего шаблона целиком. Утвердить отдельно взятую статью нельзя.
- Примечания к статье. Не реализовано. Процедура обсуждения значений статей может быть реализована посредством обмена между участниками бюджетного процесса сообщениями по электронной почте. Для хранения переписки используются стандартные средства электронной почты.
- Визуализация расхождений. Требует дополнительной настройки. Если настроено соответствующее измерение в таблице D-Cube, то можно на одном экране увидеть план, факт и отклонение.
- Контроль ошибок. Формулы в системе хранятся как отдельные сущности отдельно от ячеек, поэтому исключена возможность в процессе работы «испортить» формулы. Есть возможность выявлять незаполненные ячейки.
- Версионность планов. Не контролируется.
- Возможность одновременного планирования в произвольных временных периодах. Есть. Для каждой таблицы D-Сube можно создать измерение «периоды бюджетирования» и в нем описать такие периоды бюджетирования, какие требуются для данного бюджетного плана.
- Возможность изменять состав и структуру статей одновременно для плана и факта (исполнения) бюджета. Реализована. Можно в процессе работы изменять состав статей и содержимое справочников по каждому измерению таблицы D-Сube
- Средства анализа бюджета. В системе существуют достаточно мощные средства OLAP-анализа. Например, имеется функция детализации (drill down), с помощью которой можно, стоя на конкретной ячейке, посмотреть исходные данные, на основе которых она была посчитана.
|
|
3.3. Секретность и безопасность данных
|
- Типы пользователей и права доступа. Можно выделить такие группы пользователей, как:
- «Аналитик», который занимается моделированием и бюджетным планированием.
- «Менеджер», просматривающий бюджеты своих подчиненных и утверждающий их.
- «Исполнитель», собственно выполняющий ввод бюджетных значений.
Пользователям разрешено работать только с шаблонами, относящимися к их подразделению, и вводить данные в шаблоны, авторизированные для ввода.
Разграничение прав доступа к данным может выполняться на уровне подразделений, групп пользователей или индивидуально.
Не очень удобно то, что для каждого модуля системы существует свой отдельный интерфейс администрирования.
Фиксация действий пользователей. Обеспечивается средствами СУБД и Интернет-сервера.
|
|
4. Архитектура, платформа, средства интеграции
|
|
4.1. Архитектура
|
Adaytum e.Planning имеет реляционную базу данных, эмулирующую многомерные таблицы. Собственного хранилища данных нет.
Система четко делится на три функциональных модуля:
- e.Planning Analyst — обеспечивает настройку структуры бюджетных планов, создание математических и логических связей между статьями бюджета, динамическое моделирование и бизнес-планирование с возможностью сценарного анализа, просмотр и консолидацию результатов прогнозирования и учета фактических результатов деятельности в различных аналитических разрезах.
- e.Planning Contributor — позволяет на основе специализированных Интернет-шаблонов создавать рабочие места конечных пользователей с целью сбора бюджетных данных, согласования и утверждения плановых заданий и отслеживания исполнения бюджета.
- e.Planning Reporter — предоставляет пользователям возможности OLAP-анализа бюджетной информации, формирования собственных отчетов и публикации их через Интернет. Фактически представляет собой хорошо известный продукт Business Objects.
|
|
4.2. Программно – аппаратная платформа
|
Одно- или двухпроцессорный компьютер класса Pentium III. Операционная система — Windows NT Server 4. Обязательна установка 3-го , 4-го и 5-го Service pack. Объем памяти — 256 MB и 1 GB СУБД — Microsoft SQL Server 7.0 или Oracle 8i. Microsoft Internet Information Server
Компьютер класса Pentium с ОС Windows 95, 98, 2000 или NT 4. 28 MB RAM для Analyst (рекомендуется.256 MB для больших вычислений) Internet Explorer 4 (Service Pack 2) или 5. Связь с локальной сетью или доступ к Интернет
|
|
4.3. Средства расширения функций системы
|
- Генераторы отчетов. В качестве генератора отчетов применяется Business Object, соответственно доступны все его возможности по настройке источников данных и генерации отчетов.
- Язык формул, скриптовый язык. Язык формул существует и является одним из основных инструментов системы. Скриптовый язык отсутствует.
Открытый API для программиста. Система предоставляет API для доступа к данным
|
|
4.4. Средства интеграции с другими средствами автоматизации
|
- Интеграция с другими системами. В системе существуют специальные объекты D-Link, предназначенные для ввода данных из внешних источников. Источниками данных могут быть текстовые ASCII-файлы, а также другие базы данных, имеющие ODBC-драйверы.
Система не обеспечивает автоматический контроль соответствия значений в таблице D-Cube и первичных данных во внешних источниках.
- Интеграция с офисными приложениями. С системой поставляется Add-in для MS Excel.
- Применение XML для интеграции с другими системами. Отсутствует. XML применяется для взаимодействия удаленных Web-клиентов с центральной базой данных.
|
|
Бюджетное управление для 1С:Предприятие. Разработчик: Консультационно-внедренческая фирма «Инталев».
|
|
1. Состав и свойства информационных объектов
|
|
1.1. Измерения бюджетных статей
|
В системе предусмотрены измерения статей — ЦФО, товар, контрагент (клиент, поставщик):
- Организационно-штатная и финансовая структура. В системе применяется иерархическая структура ЦФО, обеспеченная средствами 1С. Типы ЦФО — Центр затрат, Центр доходов, Центр прибыли, Центр инвестиций. Для ЦФО назначается руководитель и исполнитель.
- Валюты, курсы. Ведется справочник валют и курсов. При бюджетировании используются 2 валюты — базовая и вторая валюта планирования.
- Продукты, услуги, материальные ценности. Ведение иерархических каталогов товаров, материальных ценностей обеспечивается в масштабе возможностей системы «1С: Предприятие».
Клиенты, потребители и поставщики. Ведение иерархических каталогов контрагентов в масштабе возможностей «1С:Предприятие».
|
|
1.2. Бюджетные планы статей
|
В системе представлены следующие бюджетные планы:
- Бюджет продаж,
- Бюджет закупок,
- Бюджет прямых расходов,
- Бюджет операционной деятельности,
- Бюджет косвенных расходов,
- Бюджет задолженности,
- Бюджет доходов и расходов (БДР),
- Бюджет движения денежных средств (БДДС),
- Бюджет по балансу,
- Платежный календарь.
Система предусматривает взаимосвязи бюджетов и логику их использования в строгом соответствии с методикой «Пять шагов».
Основные свойства статей бюджетных планов:
- Хранение значений во временных периодах. Планирование и учет ведется по месяцам на квартал. Границы периода планирования устанавливаются для вида бюджета и вида сценария.
- Иерархия статей бюджета — соответствует возможностям синтетического учета «1С:Предприятие».
- Собственное и консолидированное состояние, план, факт, отклонение. Собственное состояние есть только у бюджетов нижнего уровня. Выше — только консолидированные состояния. Отклонение присутствует в анализе плана и факта.
- Возможность учета значений статьи в разных валютах и натуральном измерении. Присутствует.
- Дополнительная аналитика статей. Можно настроить дополнительные аналитические признаки на статьи.
Проводки по бюджетным статьям. В системе это скрыто. О внутренней природе установки значений по бюджетным статьям можно судить, основываясь на понимании архитектуры «1С:Предприятие».
|
|
1.3. Первичная информация
|
- Бюджетные строки и бюджетные документы. Планирование ведется на основе операций, документов и отчетов. Возможен ввод первичных документов, в том числе заявок. Развитая система управленческого документооборота (ввод, проверка, корректировка, утверждение, маршрутизация и т.д.) — все как в «1С:Предприятие».
- Объекты поддержки финансовой логики. В полной мере используются данные системы «1С:Предприятие2. Если в организации задействованы модули «1С:Предприятие» для ведения бухгалтерского учета, склада, расчета зарплаты и т.д. — то все эти данные автоматически становятся доступны в системе.
|
|
2. Функциональность и алгоритмы системы
|
|
2.1. Алгоритмы планирования
|
- Расчет значений статей по временному горизонту планирования. В основном применяется расчет статей на основании первичной информации и посредством ручного ввода. Специализированные алгоритмы увязки временных горизонтов не обнаружены.
- Расчет значений статей по ЦФО. Алгоритмы настраиваются при описании планов статей.
- Применение статистических методов расчета. Учитываются среднедневные объемы продаж, ограничения по объему партий, сезонные изменения цен продаж и закупок, прямые расходы на продажу и закупку и т.д. в соответствии с методикой «Пять шагов».
- Расчет значений статей на основании значений других статей. Алгоритмы настраиваются при описании планов статей.
- Расчет значений статей по бюджетным документам и другой первичной информации. В полной мере возможно с применением штатных средств «1С: Предприятие».
- Обеспечение процесса планирования «от достигнутого». Можно скопировать значения статей из предыдущего периода планирования.
- Моделирование «что если». Декларировано, но как действует — определить не удалось.
|
|
2.2. Алгоритмы учета и исполнения бюджета
|
- Учет факта на основании данных бухучета. Используются данные бухучета системы «1С: Предприятие».
- Расчет значений статей по данным внесистемного учета. Используются данные внесистемного учета системы «1С:Предприятие».
|
|
2.3. Агрегация и консолидация учетных данных
|
- Агрегация. Данные агрегируются автоматически при выполнении функции «сохранить в БД».
- Консолидация. Данные консолидируются автоматически при выполнении функции «сохранить в БД». Однако, если необходимо выполнить консолидацию бюджетов, расположенных в разных базах данных, то это выливается в отдельный процесс.
|
|
2.4. Аллокация и трансферты
|
- Использование шаблонов при разноске значений статей. Не представлено.
- Использование нормативов и дополнительных справочников. Используются штатные и дополнительные справочники «1С:Предприятие».
- Использование языка формул. Скрыто в настройках системы.
- Скриптовый язык. Скрыто в настройках системы.
|
|
2.5. Алгоритмы расчета финансовых результатов
|
В системе хорошо проработан анализ структуры затрат, расчет безубыточности, себестоимости, маржи, рентабельности. Это обеспечивается построением дерева расчета взаимосвязанных финансовых показателей.
|
|
3. Организация работы пользователя с системой
|
|
3.1. Автоматизация коллективной работы с бюджетом
|
В рамках возможностей «1С:Предприятие» очень удобно организована работа пользователей с единой базой данных. Помимо работы пользователей со статьями предусмотрен управленческий документооборот, применение которого позволяет автоматически изменять состояние статей.
|
|
3.2. Удобства в работе с системой
|
- Утверждение статей и планов. План утверждается финансовым директором и закрывается для изменений одновременно для всех ЦФО.
- Примечания к статье. Реализовано в виде отправки и получения сообщений и документов между участниками бюджетного процесса.
- Визуализация расхождений. Предлагается анализ «план-факт» БДДС, БДР по ЦФО с углублением до первичных документов.
- Контроль ошибок. Проверка корректности планов с учетом ограничения сбыта, снабжения и остатка товаров. Помимо них есть функции оптимизации планов.
- Версионность планов. Реализовано в виде сценариев бюджета.
- Возможность одновременного планирования в произвольных временных периодах. Нет.
- Возможность изменять состав и структуру статей одновременно для плана и факта (исполнения) бюджета. Возможно в пределах одной базы данных.
- Средства анализа бюджета. Предусмотрен сравнительный анализ по ЦФО, бизнесам, временным периодам, ABC-анализ. Для многомерного анализа применяется другой продукт – «Гипер Куб». Его возможности по составу данных и функциональности ограничены возможностями Pivot Table, входящей в состав MS Excel.
|
|
3.3. Секретность и безопасность данных
|
- Типы пользователей и права доступа. Разграничение доступа к статьям на уровне ЦФО. Права доступа сгруппированы в роли. В поставке системы содержится некоторый набор ролей, например, таких как «ответственный распорядитель».
- Фиксация действий пользователей. Реализована средствами системы «1С:Предприятие».
|
|
4. Архитектура, платформа, средства интеграции
|
|
Проще говорить об архитектуре, платформе и средствах интеграции системы «1С:Предприятие», чем системы «Бюджетное управление», поскольку последняя является конфигурацией первой. Поэтому в отличие от остальных систем бюджетирования, этот раздел не будет подробно рассматриваться.
Единственное, на что стоит обратить внимание — это генератор отчетов. Модуль «Репортер» предназначен для формирования любой управленческой отчетности и произвольных выборок из различных баз данных (IB Database, MS SQL Server, Oracle, Sybase, DB/2, Informix, Paradox, Dbase, Access, FoxPro, а также из любых других, к которым есть ODBC-драйверы).
|
