Консалтинг и автоматизация в области управления
эффективностью банковского бизнеса

Журнал ВРМ World

Контур Корпорация и финансовая консолидация

Усложнение концепции Хранилищ данных.
Модель сбора финансовых данных Контур Копрорации.
Как настроить правила консолидации.
Как выгружаются данные.
Как загружаются данные.
Что получится в результате?
Только ли сводный бухучет?
Что если в филиалах нет систем для ввода показателей?
Заключение.

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

Усложнение концепции Хранилищ данных

Для того чтобы объяснить архитектуру ситемы необходимо сделать некоторое отступление. В кругах специалистов, концепция Хранилищ данных в последние годы претерпевает серьезные изменения.

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

Неизменяемые Хранилища данных, инкрементально пополняемые записями с двумя датами – датой собятия и датой обновления данных орб этом событии оказались идеальными лишь в теории. Эта технология неподъемно сложна для каскадного отражения изменений в прошлом в будущее, и требует парадоксального мышления от практических специалистов. В таком копроративном Хранилище данных содержтся столько правд, сколько было изменений. Например, для получения данных за прошлый период, вы должны вввести «дату точки зрения», а после этого дату интересующего периода. Представьте себе «фугу времени». С точки зрения вчерашнего дня позавчерашний объем основных средств составлял 1 миллион, с точки зрения позавчерашнего дня – 3 миллиона, а с точки зрения сегодняшнего – 2 миллиона. В некоторых задачах такая информация действительно нужна, но в большинстве случаев лишь усложняет понимание данных.

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

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

Статьи на эти темы регулярно появляются на отраслевых сайтах, например, таких уважаемых, как www.dmreview.com.

Модель сбора финансовых данных Контур Копрорации

Система Контур Корпорация не является фотографическим Хранилищем данных, особенно в ее финансовом блоке. И это не случайно. Для того чтобы собрать финансовые и бухгалтерские данные из десятка, а то и десятков филиалов коммерческого банка, или холдинга и гарантировать их качество недостаточно скопировать в одну таблику остатки счеотв за каждый день. Необходимо обеспечить выполнение десятков проверок, в частности базовых правил бухгалтерского учета:

  1. Сходимость входящих и исходящих остатков. Другими словами, остатки за сегодня должны строго равняться остаткам вчерашним, измененным на сумму оборотоов. Это правило должно соблюдаться для всех стандартных учетных периодов - дня, месяца, квартала, года.
  2. Сходимость остатков и оборотов за периоды. Остатки за месяц должны строго равняться остаткам за последний день месяца, обороты за месяц должны равняться сумме оборотов за все дни месяца, и так для каждого страршего периода.
  3. Сходимость проводок и оборотов. Сумма оборотов должна равняться сумме проводок, которые часто бывают необходимы для финансового анализа и бухгалтерского контроллинга.
  4. Сходимость агрегированных осттатков и оборотов. Остатки и обороты по синтетическим счетам должны равняться сумме осттаков и оборотов по аналитическим счетам, остатки и так по всей иерархии счетов.
  5. Сходимость консолидированных остатков и оборотов. Консолидированные остатки и обороты многофилиальной организации дролжны сттрого равняться сумме остатков и обротов ее филиалов за кажный период и на каждом уровне иерархии.

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

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

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

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

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

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

Как настроить правила консолидации

Во-первых, нужно описать организационную иерархию, Например, такую:

  • Головной офис
    • Сибирская дирекция (Новосибирск)
      • Краснодарский филиала
      • Алтайский филиал
    • Уральская дирекция (Ижевск)
      • Кировский филиал
      • Екатеринбургский филиал

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

Во-вторых, вы должны настроить «шаблоны планов счетов».

Например, такие:

  • Фискальный план счетов организации (количестов уровней иерархии 2):
    • Счет 1
      • Счет 11
      • Счет 12
    • Счет 2
      • Счет 11
      • Счет 12

Для шаблонов планов счетов можно настройть дополнительные свойтсва - периодичность учета (день, месяц, кварта, год), алгоритм агрегации и другие.

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

В четвертых, необходимо настроить типы документов, к которым будут привячзаны проводки, которые в свою очередь будут изменять состояние счетов.

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

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

Как выгружаются данные

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

  1. Данные в Хранилище можно собрать при помощи сервера репликаций.
  2. Данные в Хранилище можно собрать при помощи универсальной програмы извлечения данных, не требующей программирования.

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

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

Универсальные программы извлечения данных, так же как и сервер репликаций настраиваются на физический уровень. Например, при помощи MS Data Transformation Services можно с легкостью указать таблицы и поля источников и соотвествующих им приемников данных для справочников и несоложных таблиц, содержащих фактографические данные. Однако в финансовых и транзакционных системах основополагающие данные могут остутствовать в базе данных. Для уменьшения требований к дисковому пространству в этих системах часто не хранятся, а вычисляются остатки счетам за каждый день, суммы текущих задолженностей и другие финанансовые данные. Таким образом, только совокупность база данных+клиент знают о том, как извлечь финансовые данные. В любом случае в программе выгрузки придется описать это алгоритм. При этом неизбежно понадобится применить условные операторы и циклы. Что в свою очередь полностью отвергает концепцию визуальной настройки маппинга полей.

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

Как загружаются данные

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

Что получается в результате

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

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

Поставляемая в комплекте с Хранилищем – Контур Корпорацией OLAP-система Контур Стандарт позволяет выполнить сравнение филиалов по выбранным счетам синтетического учета, проследить динамику любого счета филиала, или консолидированного счета организации.

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

Только ли сводный бухучет?

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

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

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

А если в филиалах нет систем для ввода показателей?

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

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

Заключение

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

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