CC BY
51
2. Moiseev Yu.B., Kukushkin Yu.A., Bogomolov A.V., Loz-bin A.S. Problemy bezopasnostipolyotov [Problems of flights safety]. 2010, no. 11, pp. 28-39.
3. Kukushkin Yu.A., Dvornikov M.V., Bogomolov A.V., Shishov A.A., Sukholitko V.A., Simonenko A.P., Stepanov V.K. Problemy bezopasnosti i chrezvychaynykh situatsiy [Safety and Emergency problems]. 2009, no. 6, pp. 74-79.
4. Esev A.A., Bazarov S.A., Russkin A.V., Soldatov T.A. Nauchnye i obrazovatelnye problemy grazhdanskoy zashchity [Scientific and educational issues of civil protection]. 2011, no. 4, pp. 45-52.
5. Fedorov M.V., Esev A.A., Eremin E.M. Informatsionno-izmeritelnye i upravlyayushchie sistemy [Information-measuring and control systems]. 2011, no. 5, vol. 9, pp. 12-17.
6. Esev A.A., Golovkin A.P., Antoshin A.A., Atroshen-ko A.I. Polyot [Flight]. 2012, no. 2, pp. 40-44.
7. Maslov S.V., Esev A.A. Problemy bezopasnosti polyotov [Problems of flights safety]. 2010, no. 4, pp. 27-35.
8. Ushakov I.B., Kukushkin Yu.A., Bogomolov A.V. Fiziolo-giya truda i nadezhnost deyatelnosti cheloveka [Physiology of labor and human reliability]. Moscow, Nauka Publ., 2008.
9. Zinkin V.N., Akhmetzyanov I.M., Soldatov S.K., Bogo-molov A.V. Meditsina truda i promyshlennaya ekologiya [Occupational Medicine and Industrial Ecology]. 2011, no. 4, pp. 33-34.
10. Fedorov M.V., Kalinin K.M., Bogomolov A.V., Ste-tsyuk A.N. Informatsionno-izmeritelnye i upravlyayushchie sistemy
[Information-measuring and control systems]. 2011, vol. 9, no. 5, pp. 46-54.
11. Medvedev V.R., Bogomolov A.V., Murashev N.V., Gamaliy V.N, Sidorov V.A. Oboronny kompleks - nauchno-tekhnicheskomu progressu Rossii [Defense complex - to the scientific and technological progress in Russia]. 2011, no. 4, pp. 95-103.
12. Averyanov A.A., Zotov V.A., Tverdokhleb V.A., Tazetdinov R.G., Yanitorial M.V., Bogomolov A.V., Shishov A.A. Problemy bezopasnosti polyotov [Problems of flights safety]. 2010, no. 10, pp. 30-35.
13. Zinkin V.N., Soldatov S.K., Akhmetzyanov I.M., Bogomolov A.V., Zosimov V.V., Eremin G.I. Informatika i sistemy upravleniya [Computer science and control systems]. 2011, no. 1, pp. 72-80.
14. Shibanov G.P. Informatsionnye tekhnologii [Information Technologies]. 2003, no. 12, pp. 26-29.
15. Bogomolov A.V., Zueva T.V., Chikova S.S., Golosov-skiy M.S. Informatika i sistemy upravleniya [Computer science and control systems]. 2009, no. 4, pp. 134-136.
16. Bogomolov A.V. Informatika i sistemy upravleniya [Computer science and control systems]. 2008, no. 2 (16), pp. 11-13.
17. Kozlov V.E., Bogomolov A.V., Rudakov S.V., Olen-chenko V.T.Mir izmereniy [The world measurements]. 2012, no. 9, pp. 42-49.
УДК 004.021
МЕТОДОЛОГИЯ ПОСТРОЕНИЯ АВТОМАТИЗИРОВАННОЙ СИСТЕМЫ КОНСОЛИДИРОВАННОЙ ОТЧЕТНОСТИ
В.Н. Чибисов, директор по информационным технологиям (МХК «ЕвроХим», ул. Дубининская, 53, стр. 6, 115054, г. Москва, Россия, vladimir. chibisov@eurochem. ru); В.Н. Гаврилов, генеральный директор («МБК Груп»>, ул. Петровка, 17, стр. 1, г. Москва, 107031, Россия, vladimirng@mbcgroup.ru)
Рассматриваются построение и проектирование системы консолидированной отчетности. Определены основные операции и функции, необходимые для выполнения консолидации данных, а также описаны способы организации данных, загрузки данных из сторонних источников, средства построения хранилища данных. Описаны проблемы загрузки данных из внешних источников и пути их решения, решения по обеспечению скорости обработки выполнения запросов, целостности и непротиворечивости данных, по фильтрации и обработке загружаемых в систему данных. Рассмотрены понятия агрегации и внутригрупповых операций, их назначение и особенности реализации. Описаны средства представления результатов обработки данных и решения по их реализации. Даны рекомендации к организации работы по построению системы консолидированной отчетности.
Ключевые слова: консолидация, бизнес-анализ, IAS 10, методика, проектирование, OLAP-кубы, ELT, агрегация, внутригрупповые операции.
THE METHODOLOGY OF CONSTRUCTING A CONSOLIDATED REPORTING SYSTEM
Chibisov V.N., IT-director
(EuroChem, Dubininskaya St., 53/6, Moscow, 115054, Russian Federation, vladimir.chibisov@eurochem.ru);
Gavrilov V.N., director general (Middle Business Consulting Group, Petrovka St., 17/1, Moscow, 107031, Russian Federation, vladimirng@mbcgroup.ru)
Abstract. The article describes the issues of constructing and projecting consolidated reporting system. It defines main operations and functions which are necessary for data consolidation, and describes ways of data organization, data loading from external sources, means of data warehouse construction. The paper describes problems of data uploading from external sources and ways of their solutions. It discusses solutions of providing requests processing speed, data integrity and consistency, filtration and processing of data, which are loaded into the system. The article contains descriptions of aggregation and intergroup operations, their intention and features of implementation. It describes means of providing data processing results and ways of their implementation. It also gives recommendations how to organize construction of consolidated reporting system.
Keywords: consolidation, business analysis, IAS 10, methodology, design, OLAP-cubes, ELT, aggregation, intra-group transactions.
В крупных корпорациях и холдингах несколько компаний объединяются в группы предприятий. По результатам своей деятельности они составляют консолидированную отчетность, цель формирования которой - получение полной картины реального финансового состояния дел холдинга (корпорации) как единого целого [1].
По международному стандарту финансовой отчетности (IFRS) консолидированная отчетность формируется последовательным выполнением следующих шагов:
- подготовка предприятиями, входящими в холдинг, финансовой и производственной отчетности о результатах своей деятельности;
- объединение данных - показателей отчетности всех предприятий в единые показатели деятельности всего холдинга;
- исключение из объединенных данных значений, относящихся к показателям внутригруппо-вых операций;
- расчет дополнительных показателей для группы компаний (холдинга).
В зависимости от деятельности компаний в холдинге (корпорации) консолидация производится только по определенным сферам деятельности (данные компании, производящей продукцию, не могут быть объединены с данными компании, оказывающей услуги, так как это разные сферы деятельности).
При формировании консолидированной отчетности данные отчетности материнской и дочерних компаний объединяются, при этом процесс объединения отчетности сложен и не сводится к построчному сложению показателей: он определяется в корпоративных методиках формирования консолидированной отчетности, зависит от структуры корпорации и схемы взаимодействия компаний внутри корпорации, а также от ряда других причин [1].
Из-за сложности объединения отчетности и наличия в ней больших массивов данных компании используют автоматизированные системы консолидированной отчетности. Одни компании разрабатывают их своими силами, а другие пользуются специализированными программными средствами. Такие программные средства очень часто включены в состав многих В1-систем [1], но далеко не всегда удовлетворяют потребительским требованиям компаний. Из-за этого компаниям приходится либо выполнять сложную дополнительную доработку этих систем, либо приобретать другие программные средства, либо разрабатывать их своими силами.
В данной статье описывается методология построения автоматизированной системы консолидированной отчетности для ее разработки собственными силами компании.
Алгоритм построения системы консолидированной отчетности следующий:
- построение объектной модели системы, основанной на унифицированной структуре корпоративной отчетности, и методик расчета ключевых показателей холдинга (корпорации);
- определение системы кодирования и формата информационных объектов системы;
- разработка хранилища данных, системы ввода и загрузки данных из различных источников (БЬТ-система), механизма фильтрации и расчета данных, функций ввода и учета внутригрупповых операций, функций агрегирования данных и расчета дополнительных показателей, средств формирования отчетности и анализа данных.
Построение объектной модели. Построение автоматизированной системы консолидированной отчетности необходимо начинать с разработки ее объектной модели.
1. На основании унифицированной структуры корпоративной отчетности и методик расчета ключевых показателей в холдинге определяются основные сущности, участвующие в принятии решений и составлении консолидированной отчетности. К ним могут относиться компании, временные периоды, информационные срезы, категории показателей, внутригрупповые операции и т. д.
2. На основании сущностей определяются объекты, которые будут участвовать в процессе консолидации данных, и их взаимосвязи друг с другом, то есть строится объектная модель будущей системы.
Объектная модель автоматизированной системы консолидированной отечности служит для определения информационных объектов и их связей, которые используются при построении структуры хранилища данных.
Определение системы кодирования информационных объектов. Для каждого объекта системы определяется код, необходимый для их унификации и идентификации в больших многомерных массивах данных. Система кодирования должна быть определена таким образом, чтобы код объекта однозначно его идентифицировал и был уникальным в пределах однотипных сущностей (для сущности «Компания» не может быть двух компаний с одинаковым кодом).
Например, система кодирования для сущности «Компания» может быть следующей: <2 буквы> <3 буквы>.
Здесь первые 2 буквы обозначают код страны в соответствии с международным обозначением, а следующие 3 буквы - код компании.
Система кодирования информационных объектов определяет формат обмена данными с внешними системами и задает правила обращения к этим данным, расположенным в хранилище данных (обращение к данным производится по их уникальному коду).
Построение хранилища данных. В процессе работы с консолидированной отчетностью накап-
ливаются большие объемы информации. Информация собирается за различные промежутки времени, для различных компаний, производимой продукции и т.д. Для последующей обработки такого большого массива разнородной информации необходимо построение хранилища данных, которое будет структурировать всю хранящуюся информацию [2].
Построение хранилища данных производится на основании разработанной объектной модели автоматизированной системы и системы кодирования информационных объектов. В его основе используются реляционные БД (СУБД Oracle, MySQL), построенные по схеме «звезда» или «снежинка» (www.prj-exp.ru).
Такие БД применяются для построения многомерного аналитического пространства (куба данных), используемого в хранилище данных для обработки и структурирования информации.
Схема «звезда» характеризуется одной центральной таблицей фактов, связанной с таблицами измерений (рис. 1). Таблицы фактов содержат фактические значения показателей деятельности компаний, а таблицы измерений - данные о показателях (координатах многомерного аналитического пространства), для которых определены значения в таблицах фактов.
Таблица измерений «Компании»
Таблица измерений «Периоды»
Таблица фактов
Таблица измерений «Клиенты»
Таблица измерений «Товары»
Рис. 1. Схематическое изображение структуры БД по схеме «звезда»
Схема «снежинка» является модификацией схемы «звезда»: в ней данные об измерениях хранятся в нескольких связанных между собой таблицах (рис. 2). Основное функциональное отличие схемы «снежинка» от схемы «звезда» - возможность обеспечения детализации данных различной степени.
При построении БД рекомендуется использовать схему «снежинка», так как она позволяет строить более детализированное многомерное аналитическое пространство, достигать более высокой скорости и гибкости выполнения аналитических запросов. Итак, в основе многомерности лежат два понятия - измерения и факты [2, 3]. Куб
Таблица «Страны»
Таблица измерений «Компании»
Таблица измерений «Периоды»
Таблица фактов
3 ж
Таблица измерений «Клиенты»
Таблица измерений «Товары»
Рис. 2. Схематическое изображение структуры БД по схеме «снежинка»
данных рассматривается как система координат, осями которого являются измерения. Измерениями могут быть «Компании», «Временные периоды», «Клиенты», «Товары» и т.д. (рис. 3) [3].
TOBAF
> Х- / / /
/ / / /
/ / / / /
Фосфор / / /
Карбомид / / /
Серная кислота / / ООО «ПГ Фосфорит»
Аммиак / / ОАО «Ковдорский ГОК» ОАО «Невинномысский Азот»
/ 01.13 02.13 03.13 04.13 ПЕРИОД
КОМПАНИЯ/
Рис. 3. Схематическое представление куба данных
В ячейке многомерного массива, определяемой с помощью координат (значений измерений), содержатся фактические значения показателей (факты) (рис. 4).
Фосфор
Карбомид
Серная кислота
ООО «ПГ Фосфорит» ОАО «Ковдорский ГОК» ОАО «Невинномысский Азот»
КОМПАНИЯ
I I I I I I I I I I I I
01.13 02.13 03.13 04.13
I 1 /I 1 / ^
Рис. 4. Схематическое представление ячейки куба данных
Таблицы измерений БД описывают и задают формат информационных объектов, определенных при построении объектной модели системы. Связи между таблицами определяются связями объектов.
Таблица «Сегменты»
За счет такой организации достигается высокая скорость получения данных (достаточно указать только координаты ячейки, и данные будут получены) [2]. Гибкость выполнения запросов в таком многомерном представлении данных достигается за счет фиксирования нескольких значений в одном или нескольких из указанных измерений. Полученные таким образом срезы данных (сечения куба) отображают значения показателей для указанных измерений.
Для формирования запросов к кубам данных разработаны специализированные языки обращения к данным (например язык MDX - Multidimensional 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). Этот способ более предпочтителен, так как учетная система всегда имеет
Источник данных
Извлечение данных Преобразование данных Загрузка данных
Хранилище данных
Рис. 5. Получение данных средствами ETL-системы
Источник данных
ETL-система
Данные Извлечение данных Преобразование данных
Получение данных Загрузка данных
Хранилище данных
Рис. 6. Получение данных, сгенерированных в источнике данных
ETL-система
Данные
одну и ту же структуру данных, и выгрузка данных осуществляется всегда одинаково, а ETL-систему необходимо настроить только на получение и загрузку данных уже необходимого формата (далее рассматривается только второй подход к загрузке данных).
Основным принципиальным решением, позволяющим реализовать взаимодействие со сторонними программными средствами (системами), является выбор универсального метода обмена информацией. Решение реализуется применением формата XML в качестве формата входных данных. Этот формат - широко распространенный инструмент обмена данными между различными информационными системами. Практически все современные системы учета и BI-системы имеют средства для работы с языком XML.
В формируемом сторонней системой (источником данных) файле XML должны содержаться данные о временных срезах, компаниях, показателях, для которых будет производиться загрузка данных, а также значения этих показателей.
Для согласования структуры входных данных и структуры хранилища данных (преобразование к общему формату) необходимо использовать преобразования, написанные на языке XSLT, рекомендованном для осуществления трансформаций над XML-данными.
При выполнении консолидации все данные, полученные из различных источников, должны быть сформированы (в соответствии с Международным стандартом финансовой отчетности) на одну дату (это одно из условий выполнения процесса консолидации), то есть даты отчетности, получаемой из различных компаний холдинга, должны быть одинаковыми. Поэтому при выполнении загрузки данных необходимо задание параметров периодичности ее выполнения.
Для реализации процесса загрузки с заданной периодичностью рекомендуется использовать стандартные средства планирования операционной системы (например, в Linux - планировщик задач Cron, в Windows - стандартный планиров-
щик задач в разделе администрирования системы). Планировщик настраивается таким образом, что через определенные промежутки времени он запускает ЕТЬ-систему, которая проверяет наличие новых измененных данных (выгруженные ХМЬ-файлы из сторонней системы) и в случае их наличия выполняет загрузку. Для контроля процесса выполнения загрузки рекомендуется настроить ETL-систему таким образом, чтобы по завершении импорта данных она формировала отчеты о результатах его выполнения (можно также настроить рассылку данных отчетов по электронной почте ответственным лицам).
Обобщенная схема работы ЕТЬ-системы представлена на рисунке 7.
Механизм фильтрации и расчета данных. В процессе импорта могут загружаться некорректные или излишне детализированные данные. Поэтому необходимо загружать их не в таблицы фактов БД, а в промежуточные представления (временные таблицы БД). Именно данные из промежуточных представлений должны обрабатываться на предмет отсеивания излишней детализации и некорректных данных.
В процессе разработки системы необходимо при создании показателей предусмотреть возможность задания правил валидации (математических и логических операций проверки значения показателя) и формул расчета показателя.
Для обработки данных, получаемых в процессе ввода и загрузки, должны использоваться правила валидации и формулы расчета. Для показателей, требующих проверки корректности, задаются формулы валидации, содержащие логические операции сравнения и проверки вводимых значений. А для показателей, рассчитываемых на основании других зависимых показателей (детализирующие показатели), задаются формулы расчета, содержащие математические и арифметические операции вычисления значений.
Автоматизированная система консолидированной отчетности настраивается таким образом, что по завершении загрузки данных ЕТЬ-системой
Рис. 7. Схема работы системы загрузки данных
для каждого показателя (для которого определены формулы валидации или расчета) выполняются расчет и проверка необходимых значений. Если значение показателя ошибочно (неуспешное выполнение валидации), данный показатель должен помечаться как некорректный (можно визуально выделить данный показатель и организовать вывод соответствующего сообщения), чтобы пользователь системы мог увидеть проблемную область и внести соответствующие корректировки. Вали-дация значений показателей может быть использована и для проверки зависимостей.
Рассчитанные и проверенные данные записываются в таблицы фактов БД в соответствии с показателями, содержащимися на формах, для которых они загружаются, и измерениями, указанными в процессе загрузки.
Если в данных таблицах нет необходимых показателей, они не загружаются (например, излишние детализирующие показатели). А если для необходимых показателей, содержащихся в таблицах фактов, нет данных, в них записываются нулевые значения (для проверки показателей может быть настроена валидация - проверка на нулевые значения).
После завершения обработки данных временные таблицы БД удаляются.
Схема работы подсистемы расчета и фильтрации данных представлена на рисунке 8.
Агрегирование и расчет данных. Основой для принятия решений по дальнейшему развитию холдинга являются обобщенные данные деятельности компаний, входящих в холдинг. Каждая компания является отдельной юридической единицей, которая собирает, обрабатывает и анализирует данные своей деятельности, формирует соответствующую отчетность. Эти данные агрегируются, то есть показатели компаний, входящих в холдинг, объединяются в единые показатели всего холдинга.
В разрабатываемой системе необходимо создать функции, которые автоматически выполняли бы агрегирование данных. Под агрегацией в простейшем случае подразумевается суммирование
Таблица показателей
Правила валидации Формулы расчета
ЕТ^система Данные Данные т Валидация и расчет значений Значения показателей
Временная таблица БД Таблица фактов
Признак корректности показателя
Рис. 8. Схема работы подсистемы очистки
показателей всех компаний, входящих в холдинг. Рекомендуется разработать данные функции таким образом, чтобы агрегация выполнялась сразу после сохранения данных. Это позволяет снизить время подготовки консолидированной отчетности за счет того, что рассчитанные агрегированные данные уже будут храниться в системе, а не рассчитываться каждый раз при открытии отчетности.
Сохранение агрегированных данных нельзя осуществлять в таблицу фактов БД для материнской компании, так как они перекроют фактические данные этой компании, именно поэтому в системе создается дополнительная условная компания (например, «Консолидирующая компания» с кодом RUCON), таблицы фактов БД для которой будут хранить консолидированные данные холдинга.
Для этой компании в системе необходимо предусмотреть настройку правил агрегации данных, включающих параметры расчета для различных периодов. Агрегация данных может производиться для различных временных периодов (текущий период, квартал, полугодие, год). Расчет значений агрегированных показателей может выполняться одним или несколькими способами расчета одновременно (сумма, среднее значение, медиана и т.д.).
Одной из важнейших задач консолидации является учет внутригрупповых операций [5, 6].
Если в процессе деятельности групп компаний не было произведено ни одной внутригрупповой операции, агрегирование выполняется для всех показателей в рамках заданного направления деятельности. Значение показателя для каждой компании рассчитывается в соответствии с правилом расчета агрегации. Результатом такой операции являются агрегированные значения показателя по всем компаниям холдинга [5, 6].
Если в процессе деятельности групп компаний производились внутригрупповые операции, при агрегации данных учитываются значения введенных операций. В зависимости от типа внутри-групповой операции (вычитание, сложение, умножение и т.д.) осуществляется корректировка значения показателя каждой компании, участвующей в операции, на значение, указанное во внутригруппо-вой операции. И именно скорректированное значение участвует при получении агрегированного показателя [5, 6].
Полученные значения показателей записываются в соответствующие ячейки таблицы фактов БД для условной компании.
Помимо рассчитанных агрегированных значений показате-
лей, для принятия решений по управлению бизнесом менеджерами компании может потребоваться расчет дополнительных показателей. Такими показателями могут быть гудвилл, накопленный капитал, права меньшинства [6].
Для учета и расчета дополнительных показателей при выполнении консолидации для условной компании ^иСО№) создаются дополнительные объекты системы: формы первичных показателей, в которых указываются необходимые рассчитываемые показатели, формулы их расчета и правила их проверки (валидации). Расчет показателей, содержащихся в дополнительной форме, производится сразу же по завершении процесса агрегации данных. При расчете производится проверка значений показателей на корректность. Рассчитанные и проверенные данные должны загружаться в специальную таблицу фактов для дополнительных показателей. Это необходимо для того, чтобы данные не перекрывали значения показателей из основных таблиц фактов системы.
Схема работы подсистемы агрегации и расчета дополнительных показателей представлена на рисунке 9.
Внутригрупповые операции. Консолидированная отчетность отражает результаты деятельности группы компаний как единого целого. Если между компаниями осуществлялись хозяйственные операции, то при консолидации отчетности их влияние должно исключаться. Этот процесс называется элиминированием внутригрупповых оборотов и является необходимым условием при выполнении консолидации данных [6].
Внутригрупповые операции происходят взаимосвязанно (продажа товаров одной компанией другой, передача активов и др.), то есть при выполнении внутригрупповой операции всегда есть две компании-оппонента, в которых значение операции равнозначно (значение операции в одной компании должно быть равным значению операции в компании-оппоненте) [6]. Основной слож-
ностью выполнения внутригрупповых операций в BI-системах является их несогласованность.
Поэтому в автоматизированную систему консолидированной отчетности должен быть включен механизм ввода внутригрупповых операций и их согласования между компаниями-оппонентами данной операции. При этом внутригрупповая операция должна считаться введенной только после того, как обе стороны операции согласовали введенные значения.
В крупных компаниях и холдингах может быть много дочерних компаний. Соответственно может производиться большое количество внутригруп-повых операций. Постоянный ввод одних и тех же операций для разных компаний может быть трудоемким, поэтому рекомендуется, чтобы в системе было предусмотрено создание шаблонов для выполнения внутригрупповых операций, в которых должны описываться распределения операции, допустимые значения, тип операции (вычитание, сложение, деление и т.д.). При использовании таких шаблонов пользователям при вводе внутригрупповых операций необходимо выполнять ввод только наименования шаблона внутри-групповой операции для компаний, участвующих в операции, и значения самих операций. Учет внутригрупповых операций производится в процессе консолидации данных. Схематическое изображение процесса учета внутригрупповых операций представлено на рисунке 10.
Средства отчетности и анализа данных. Бизнес-аналитику для принятия решений необходимо иметь инструменты, предоставляющие все необходимые для анализа данные в удобном, интуитивно понятном виде с максимальной степенью достоверности и детализацией.
Общепринятыми средствами предоставления данных в современных аналитических системах являются формы, витрины данных, отчеты, информационные аналитические панели (рис. 11).
Рис. 9. Агрегация и расчет показателей
Рис. 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 economics]. 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 Mining, Visual Mining, OLAP]. St. Petersburg, BHV-Petersburg Publ., 2007, pp. 19-58 (in Russ.).
3. Starikov A. Yadro OLAP sistemy [The core of OLAP system]. 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: practice]. 2007, no. 2, pp. 20-30.
УДК 355.01: 004.056
АВТОМАТИЗИРОВАННОЕ ФОРМИРОВАНИЕ ПЕРСОНАЛЬНЫХ ДОЛЖНОСТНЫХ ИНСТРУКЦИЙ СОТРУДНИКОВ ПРОЕКТНЫХ ОРГАНИЗАЦИЙ
П.И. Соснин, д.т.н., профессор, зав. кафедрой; К.В. Святов, к.т.н., доцент, директор центра новых информационных технологий
(Ульяновский государственный технический университет (УлГТУ), ул. Северный Венец, 32, г. Ульяновск, 432027, Россия, sosnin@ulstu.ru, kir@ulstu.ru); А.А. Перцев, соискатель (УлГТУ), начальник отдела (НПО «Марс», ул. Солнечная, 20, г. Ульяновск, 432022, Россия, mars@mv.ru)
Рассмотрены процессы коллективной разработки сложных автоматизированных систем, компетенции проектной организации и ее членов. Особое место занимает конструктивное управление организационными ресурсами и опытом проектной организации, поскольку результативность работы любой проектной организации в существенной мере зависит от профессионального опыта и компетенции ее специалистов. Основной формой группирования компетенций являются роли, с каждой из которых связывают не только группу компетенций, но и инструментально-технологическое обеспечение. Для закрепления ответственности конкретных членов проектной организации необходимо персонифицировать должностные инструкции и закреплять их в договорных обязательствах. Для формализации системы персонифицированных должностных инструкций членов проектной организации используется онтологический подход. Основная часть статьи посвящена инструментальным средствам автоматизированного формирования персонифицированных должностных инструкций сотрудников проектной организации, разрабатывающей семейства автоматизированных систем. Реализация ориентирована на процессы проектирования, для информационного обслуживания которых используется база опыта.
Ключевые слова: автоматизированное проектирование, база опыта, должностная инструкция, профессиональная зрелость.
AUTOMATED ORGANIZATION OF PERSONAL JOB DESCRIPTIONS FOR DESING ORGANIZATIONS EMPLOYEES Sosnin P.I., Dr. Tech. Sc., professor, head of chair;
Svyatov K.V., Ph.D. Tech. Sc., associate professor, director of Center for New Information Technology (Ulyanovsk State Technical University (UlSTU), Severny Venets St., 32, Ulyanovsk, 432027, Russian Federation,
sosnin@ulstu.ru, kir@ulstu.ru);
Pertsev A.A., candidate (UlSTU), head of department (Research-and-Production Association «Mars», Solnechnaya St., 20, Ulyanovsk, 432022, Russian Federation, mars@mv.ru) Abstract. The paper considers the processes for the collective development of complex automated systems (software intensive systems), and the competencies of a design organization and its members. The constructive management of organizational resources and design organization experience is very important. Its efficiency depends highly on professional experience and employee competency. A common form for the competency grouping is roles. Every role is linked not only to a group of competencies, but to an engineering tool set. Assignment of employees' responsibilities needs job descriptions to
