Программные продукты и системы

В крупных корпорациях и холдингах несколько компаний объединяются в группы предприятий. По результатам своей деятельности они составляют консолидированную отчетность, цель формирования которой – получение полной картины реального финансового состояния дел холдинга (корпорации) как единого целого [1].

По международному стандарту финансовой отчетности (IFRS) консолидированная отчетность формируется последовательным выполнением следующих шагов:

-      подготовка предприятиями, входящими в холдинг, финансовой и производственной отчетности о результатах своей деятельности;

-      объединение данных – показателей отчетности всех предприятий в единые показатели деятельности всего холдинга;

-      исключение из объединенных данных значений, относящихся к показателям внутригрупповых операций;

-      расчет дополнительных показателей для группы компаний (холдинга).

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

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

Из-за сложности объединения отчетности и наличия в ней больших массивов данных компании используют автоматизированные системы консолидированной отчетности. Одни компании разрабатывают их своими силами, а другие пользуются специализированными программными средствами. Такие программные средства очень часто включены в состав многих BI-систем [1], но далеко не всегда удовлетворяют потребительским требованиям компаний. Из-за этого компаниям приходится либо выполнять сложную дополнительную доработку этих систем, либо приобретать другие программные средства, либо разрабатывать их своими силами.

В данной статье описывается методология построения автоматизированной системы консолидированной отчетности для ее разработки собственными силами компании.

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

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

–      определение системы кодирования и формата информационных объектов системы;

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

Построение объектной модели. Построение автоматизированной системы консолидированной отчетности необходимо начинать с разработки ее объектной модели.

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

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

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

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

Например, система кодирования для сущности «Компания» может быть следующей: <2 буквы> <3 буквы>.

Здесь первые 2 буквы обозначают код страны в соответствии с международным обозначением, а следующие 3 буквы – код компании.

Система кодирования информационных объектов определяет формат обмена данными с внешними системами и задает правила обращения к этим данным, расположенным в хранилище данных (обращение к данным производится по их уникальному коду).

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

Построение хранилища данных производится на основании разработанной объектной модели автоматизированной системы и системы кодирования информационных объектов. В его основе используются реляционные БД (СУБД Oracle, MySQL), построенные по схеме «звезда» или «снежинка» (www.prj-exp.ru).

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

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

Схема «снежинка» является модификацией схемы «звезда»: в ней данные об измерениях хранятся в нескольких связанных между собой таблицах (рис. 2). Основное функциональное отличие схемы «снежинка» от схемы «звезда» – возможность обеспечения детализации данных различной степени.

При построении БД рекомендуется использовать схему «снежинка», так как она позволяет строить более детализированное многомерное аналитическое пространство, достигать более высокой скорости и гибкости выполнения аналитических запросов. Итак, в основе многомерности лежат два понятия – измерения и факты [2, 3]. Куб данных рассматривается как система координат, осями которого являются измерения. Измерениями могут быть «Компании», «Временные периоды», «Клиенты», «Товары» и т.д. (рис. 3) [3].

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

Таблицы измерений БД описывают и задают формат информационных объектов, определенных при построении объектной модели системы. Связи между таблицами определяются связями объектов.

За счет такой организации достигается высокая скорость получения данных (достаточно указать только координаты ячейки, и данные будут получены) [2]. Гибкость выполнения запросов в таком многомерном представлении данных достигается за счет фиксирования нескольких значений в одном или нескольких из указанных измерений. Полученные таким образом срезы данных (сечения куба) отображают значения показателей для указанных измерений.

Для формирования запросов к кубам данных разработаны специализированные языки обращения к данным (например язык MDX – Multidimen­sional Expressions) [2]. Выражения, написанные на таких языках, задают параметры формирования необходимых срезов данных. В настоящее время разработано достаточное количество различных решений для реализации и работы с кубами данных, которые обеспечивают хранение и обращение к данным в многомерных аналитических пространствах. В процессе разработки автоматизированной системы консолидированной отчетности необходимо использовать тот язык обращения к многомерным данным, который поддерживается используемой СУБД.

База данных, построенная по одной из описанных выше схем, в совокупности с языком обращения к многомерным пространствам является хранилищем данных.

Организация процесса загрузки данных из различных источников. Исходными данными для выполнения консолидации являются значения показателей деятельности, полученные со всех предприятий холдинга (корпорации). Данные деятельности компаний холдинга зачастую расположены в различных источниках: в различных системах учета (банк–клиент, 1С: Предприятие, Парус и др.), в базах данных (Oracle, Access, MySQL, dBase и др.) и в отдельных офисных документах (Excel, Word, текстовые файлы). Прямая загрузка данных в хранилище данных из сторонних источников осложняется несколькими факторами:

–      различные учетные системы неоднородны по типу используемых синтаксических соглашений и концептуальных допущений (единицы измерения, наименования, кодирование и т.п.);

–      учетные системы часто имеют так называемые грязные данные – данные, замусоренные ненужной информацией, влияющей на корректность их анализа;

–      учетные системы имеют излишнюю детализацию данных, когда для решения задач консолидации требуются обобщенные показатели;

–      в учетных системах могут использоваться разные модели данных (иерархическая, реляционная, объектно-ориентированная), что влияет на формат и структуру получаемых из системы данных;

–      отсутствуют возможности выгрузки данных из системы в необходимом формате.

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

Процесс загрузки (импорта) данных из различных внешних систем может осуществляться по-разному, но последовательность шагов остается одинаковой: извлечение данных из источников различного формата, преобразование их в единый формат и загрузка в хранилище данных. Для реализации данных функций в BI-системах используются так называемые ETL-средства – инструменты для извлечения данных (extract), их загрузки (load), преобразования (transform), то есть приведения данных к необходимому формату (www.prj-exp.ru).

Первый способ загрузки информации заключается в том, что ETL-система (www.prj-exp.ru) сама забирает и преобразует данные из стороннего источника (приведение к общему формату и очистка от мусора) в соответствии с определенными правилами и затем загружает их в хранилище (рис. 5) [1, 4]. Этот способ осложняется тем, что для получения данных из различных учетных систем в ETL-системе необходима разработка дополнительных обработчиков обращения, извлечения и преобразования данных для учетной системы, используемой для получения данных (учетные системы имеют различные структуры и формат данных).

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

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

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

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

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

Для реализации процесса загрузки с заданной периодичностью рекомендуется использовать стандартные средства планирования операционной системы (например, в Linux – планировщик задач Cron, в Windows – стандартный планировщик задач в разделе администрирования системы). Планировщик настраивается таким образом, что через определенные промежутки времени он запускает ETL-систему, которая проверяет наличие новых измененных данных (выгруженные XML-файлы из сторонней системы) и в случае их наличия выполняет загрузку. Для контроля процесса выполнения загрузки рекомендуется настроить ETL-систему таким образом, чтобы по завершении импорта данных она формировала отчеты о результатах его выполнения (можно также настроить рассылку данных отчетов по электронной почте ответственным лицам).

Обобщенная схема работы ETL-системы представлена на рисунке 7.

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

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

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

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

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

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

После завершения обработки данных временные таблицы БД удаляются.

Схема работы подсистемы расчета и фильтрации данных представлена на рисунке 8.

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

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

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

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

Одной из важнейших задач консолидации является учет внутригрупповых операций [5, 6].

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

Если в процессе деятельности групп компаний производились внутригрупповые операции, при агрегации данных учитываются значения введенных операций. В зависимости от типа внутригрупповой операции (вычитание, сложение, умножение и т.д.) осуществляется корректировка значения показателя каждой компании, участвующей в операции, на значение, указанное во внутригрупповой операции. И именно скорректированное значение участвует при получении агрегированного показателя [5, 6].

Полученные значения показателей записываются в соответствующие ячейки таблицы фактов БД для условной компании.

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

Для учета и расчета дополнительных показателей при выполнении консолидации для условной компании (RUCON) создаются дополнительные объекты системы: формы первичных показателей, в которых указываются необходимые рассчитываемые показатели, формулы их расчета и правила их проверки (валидации). Расчет показателей, содержащихся в дополнительной форме, производится сразу же по завершении процесса агрегации данных. При расчете производится проверка значений показателей на корректность. Рассчитанные и проверенные данные должны загружаться в специальную таблицу фактов для дополнительных показателей. Это необходимо для того, чтобы данные не перекрывали значения показателей из основных таблиц фактов системы.

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

Внутригрупповые операции. Консолидированная отчетность отражает результаты деятельности группы компаний как единого целого. Если между компаниями осуществлялись хозяйственные операции, то при консолидации отчетности их влияние должно исключаться. Этот процесс называется элиминированием внутригрупповых оборотов и является необходимым условием при выполнении консолидации данных [6].

Внутригрупповые операции происходят взаимосвязанно (продажа товаров одной компанией другой, передача активов и др.), то есть при выполнении внутригрупповой операции всегда есть две компании-оппонента, в которых значение операции равнозначно (значение операции в одной компании должно быть равным значению операции в компании-оппоненте) [6]. Основной сложностью выполнения внутригрупповых операций в BI-системах является их несогласованность.

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

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

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

Общепринятыми средствами предоставления данных в современных аналитических системах являются формы, витрины данных, отчеты, информационные аналитические панели (рис. 11).

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

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

Отчеты, как правило, состоят из числовых значений показателей, представляющих тот или иной информационный срез данных деятельности компании. Обычно отчеты – это табличные экранные формы или файлы форматов Excel и Word.

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

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

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

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

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

Методология разработана и использована в рамках Федеральной целевой программы «Исследования и разработки по приоритетным направлениям развития научно-технического комплекса России на 2007–2013 годы» при выполнении ОКР по теме «Разработка программного комплекса и облачного сервиса для автоматизированного обобщения и анализа финансово-экономической информации о деятельности предприятий и обеспечения принятия управленческих решений» (Гос­контракт № 14.527.12.0020 от 14 октября 2011 г.) ЗАО «МБК Груп» совместно с ОАО МХК «ЕвроХим» при финансовой поддержке Министерства образования и науки Российской Федерации.

Литература

1.     Шитов Д., Баев Н. Консолидированная отчетность: собрать, сверить, исключить и сложить // Экономика бизнеса. 2008. № 06 (42). С. 4–5.

2.     Барсегян А., Куприянов М., Степаненко В., Холод И. Технологии анализа данных. Data Mining, Text Mining, Visual Mining, OLAP. СПб: БХВ-Петербург. 2007. С. 19–58.

3.     Стариков А. Ядро OLAP системы // Лаборатория Base­Group. 2003. URL: http://www.basegroup.ru/ (дата обращения: 23.08.2013).

4.     Ковтун М.В. Реализация ELT-процессов корпоративного хранилища данных // Корпоративные хранилища данных. Интеграция систем. Проектная документация. 2011. URL: www.prj-exp.ru (дата обращения: 23.08.2013).

5.     Ястребкова Е. Элиминирование внутригрупповых оборотов при консолидации // МСФО: практика применения. 2006. № 6. С. 54–61.

6.     Ястребкова Е. Консолидация отчетности при использовании в производстве активов, закупленных внутри группы // МСФО: практика применения. 2007. № 2. С. 20–30.

References

1.     Shitov D., Baev N. Ekonomika biznesa [Business econo­mics]. 2008, no. 06 (42), pp. 4–5.

2.     Barsegyan A., Kupriyanov M., Stepanenko V., Holod I. Tekhnologii analiza dannykh. Data Mining, Text Mining, Visual Mining, OLAP [Data analysis technologies. Data Mining, Text Mi­ning, Visual Mining, OLAP]. St. Petersburg, BHV-Petersburg Publ., 2007, pp. 19–58 (in Russ.).

3.     Starikov A. Yadro OLAP sistemy [The core of OLAP sys­tem]. BaseGroup, 2003, available at: http://www.basegroup.ru/ (accessed 23 August 2013).

4.     Kovtun M.V. Korporativnye khranilishcha dannykh. Integratsiya sistem. Proektnaya dokumentatsiya [Data Warehouse. Systems integration. Project documents]. 2011, available at: http:// www.prj-exp.ru/dwh/implementation_of_etl_process.php (accessed 23 August 2013).

5.     Yastrebkova E. MSFO: praktika primeneniya [IFRS: practice]. 2006, no. 6, pp. 54–61.

6.     Yastrebkova E. MSFO: praktika primeneniya [IFRS: prac­tice]. 2007, no. 2, pp. 20–30. На основании унифицированной структуры корпоративной отчетности и методик расчета ключевых показателей в холдинге определяются основные сущности, участвующие в принятии решений и составлении консолидированной отчетности. К ним могут относиться компании, временные периоды, информационные срезы, категории показателей, внутригрупповые операции и т.д.

2.