Главная
страница 1страница 2страница 3 ... страница 5страница 6

Постановка задачи

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


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


Здесь нам придется коснуться такого важного термина как нормализация. Схемы транзакционных баз данных должны быть нормализованы во избежание аномалий удаления, обновления, чтения и т.д. Схемы аналитических систем являются денормализованными или многомерными – это позволяет наиболее оперативно получать информацию по запросам чтения, а конкретнее – в разрезе определенных аналитик (slicing and dicing).

Также для повышения оперативности ответа на запрос данные в многомерной схеме (иначе – схема-звезда, или куб) хранятся не только детальные, но и агрегированные – в соответствие с настроенными иерархиями, их узлами и т.д. Обычно размер хранилищ данных существенно больше, чем размер транзакционных систем.
В чем же несогласованность, когда речь идет о системах бюджетирования? Именно в том, что они должны умело совмещать свойства аналитических систем. Во-первых, они служат для построения топ-менеджментом компании аналитических бюджетных форм. Во-вторых – являются системами обработки транзакций (обновления, удаления), которыми является сбор данных на этапе формирования бюджета. Также необходим контроль объемов данных, которые обрабатывает такая смешанная система. Ведь зачастую сложно с уверенностью сказать, что такое тактический бюджет, а что такое операционный. А данные, как известно, появляются в системе только с боевым стартом, и поэтому важно на этапе проектирования установить границы «гранулярности» обрабатываемых системой данных.


1.1.1 Техническая постановка задачи

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




  1. OLTP требования:

  • Ввод данных (insert/update)

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

  • Статусы блокировки срезов данных

Отслеживание данных по статусам необходимо для контроля версий данных в процессе согласования бюджета.

  • Ввод комментариев по записям

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

  • Аудит данных и действий

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

  • Драйверы затрат и курсы валют

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

  • Измерения в реляционном отношении

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


  1. OLAP требования:

  • Быстрые аналитические запросы по срезам данных (slice and dice)

Аналитические запросы по срезам данных необходимы для возможности анализа сводной и агрегированной информации специалистами финансового блока.

  • Ведение иерархий и навигация по ним (drill-down and drill-up)

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

  • Расчетная логика (MDX, скрипты)

Расчетная логика необходима для реализации функций планирования (распределение затрат, централизация, вычисление амортизации, нормируемых затрат)

  • Сводный многомерный анализ (pivoting)

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


2.1.2 Постановка задачи с точки зрения бизнеса

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


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

ССП головного офиса;

дополнительные офисы Москвы и Московской области;

головные офисы (ГО) филиалов (региональные офисы - операционные офисы 1-го уровня);

дополнительные офисы филиалов (операционные офисы 2-го уровня);

международные представительства;

дочерние компании.

Нормативно-справочная информация

Для целей планирования сметы расходов и доходов в Системе планирования реализованы следующие справочники:

справочник ССП;

справочник статей;

справочник видов расходов;

справочник курсов валют;

справочник драйверов;

Подход к реализации процесса планирования

Процесс планирования Сметы АХР состоит из двух групп бизнес-процессов:

БП01.Годовое планирование АХР

БП02.Полугодовая коррекция бюджета АХР

Ниже представлен весь перечень процессов и подпроцессов планирования сметы АХР.

3.БП01. Годовое планирование сметы АХР


    1. БП01.01.Подготовка к планированию АХР

      1. БП01.01.01. Обновление справочников

      2. БП01.01.02. Настройка алгоритмов расчета

      3. БП01.01.03. Обновление прав доступа

      4. БП01.01.04. Загрузка графиков платежей из системы ИСУ АХД

    2. БП01.01.05. Загрузка фактических значений драйверов и норм

    3. БП01.02. Сбор данных ССП

      1. БП01.02.01. Сбор заявок по расходам от ССП ГО

      2. БП01.02.02. Сбор заявок по расходам от подразделений Московского региона

      3. БП01.02.03. Сбор заявок по расходам от региональных подразделений

      4. БП01.02.04. Сбор заявок по расходам от региональных подразделений (Филиалы)

    4. БП01.03. Контроль и согласование ПП

    5. БП01.04. Контроль Куратором

    6. БП01.05. Ревизия ПП

    7. БП01.06. Согласование ФД

    8. БП01.07. Внесение изменений в бюджет

    9. БП01.08. Агрегация данных и передача в смету АХР. Факт и внешние системы

4.БП02. Полугодовая коррекция сметы АХР

    1. БП02.01.Подготовка к полугодовой коррекции АХР

      1. БП02.01.01. Создание версии плана для полугодовой коррекции

      2. БП02.01.02. Обновление справочников

      3. БП02.01.03. Настройка алгоритмов расчета

      4. БП02.01.04. Обновление прав доступа

      5. БП02.01.05. Загрузка плана из системы ИСУ АХД.

      6. БП02.01.06. Загрузка графиков платежей из системы ИСУ АХД (с обратным знаком)

5.БП02.02. Ввод корректировок Профильными Подразделениями

6.БП02.03. Согласование ФД

7.БП02.04. Внесение изменений в бюджет

8.БП02.05. Агрегация данных и передача в смету АХР. Факт и внешние системы

Процесс планирования реализован с максимальной унификацией всех входящих в него вспомогательных процессов (подпроцессов).

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

Основными процессами являются: сбор данных, проверка профильными подразделениями, проверка кураторами, согласование ФД, внесение изменений, утверждение бюджета.

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

В системе реализованы следующие процессы (подпроцессы) и шаги:


  1. Подготовка планирования: загрузка данных из системы «ИСУ АХД» (графики платежей, справочники), загрузка данных из внешних файлов (справочники, реестры), настройка полномочий пользователей.

9.Сбор данных.

10.Контроль ПП.

11.Согласование ФД.

Ручной ввод плановых затрат

При помощи ручного ввода будут планироваться все ненормируемые расходы. Планирование вручную должно осуществляться следующим образом: пользователь определяет все аналитики планирования – ССП, статью, вид расхода, объект и проект. Далее пользователь задает распределение плановой суммы кассовым методом. Также пользователь задает даты «с» и «по» для распределения плановой суммы методом начисления.

Документооборот и статусы

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

В системе реализованы следующие статусы:

«Ввод данных» - значение по умолчанию;

«Контроль ПП» – проставляется на этапе контроля ПП;

«Контроль ФД» – проставляется на записи, на этапе контроля ФД;

статус «Согласовано» является конечным (никакие изменения данных невозможны).

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

Описание интерфейсов ввода данных

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

В системе планирования интерфейс ручного ввода подразделяются на следующие категории:

интерфейс просмотра данных;

интерфейс ручного ввода плановых сумм;

интерфейс ручного ввода;

интерфейс ввода драйверов;

интерфейс расчета плановой амортизации;



Планирование на основе нормируемых затрат

Расчет расходов по нормируемым статьям осуществляется автоматически путём умножения установленных норм на количество драйвера.

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

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

Расчет сумм планирования по нормам и драйверам осуществляется автоматически при сохранении значений норм или драйверов.

Расчет амортизации

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



Планирование общебанковских расходов

Требования к планированию общебанковских расходов (ОБР) заключаются в следующем.

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

Отчеты по комментариям

Отчет по комментариям позволяет просматривать все комментарии, относящиеся к текущему приложению (в текущем ракурсе).

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

Отчет по аудиту данных

В отчете показано, кем изменены данные, в какое время, как (например, с помощью логики или интерфейса для Excel), а также подробные сведения об измененной записи. В отчете отражается новое введенное значение.



Отчет по рабочим статусам

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

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


<< предыдущая страница   следующая страница >>
Смотрите также:
«Методы моделирования данных в аналитических информационных системах»
411.45kb.
6 стр.
Методика определения актуальных угроз безопасности персональных данных при их обработке в информационных системах персональных данных
150.02kb.
1 стр.
Специализированные методы визуализации 2d и 3d изображениq в бортовых картографических системах
88.09kb.
1 стр.
Учебная программа Дисциплины р1 «Моделирование информационных процессов»
125.21kb.
1 стр.
Программа по дисциплине администрирование в информационных системах растягаев Д. В
128.76kb.
1 стр.
Политика безопасности персональных данных, обрабатываемых в информационных системах персональных данных в
227.68kb.
1 стр.
Методы анализа данных Кредиты: 3 Аннотация дисциплины
17.78kb.
1 стр.
Инструкция операторам по обработке персональных данных на пэвм
211.62kb.
1 стр.
1. Термины и определения (документы фстэк россии) Безопасность персональных данных
153.09kb.
1 стр.
Лабораторные работы по дисциплине "Теория экономических информационных систем"
95.98kb.
1 стр.
30. Методы моделирования сложных систем
85.7kb.
1 стр.
Базовая модель угроз безопасности персональных данных при их обработке в информационных системах персональных данных
1254.82kb.
8 стр.