Завод холодильников «Стинол» в Липецке, построенный в начале 90-х компанией Merloni Projetti как один из цехов Новолипецкого металлургического комбината, в сентябре 2000 года был куплен корпорацией Merloni Elettrodomestici. Сегодня завод обеспечивает существенную долю общих объемов производства корпорации, выпуская помимо хорошо известных в России холодильников одиннадцать новых моделей брэнда Indesit. Цеха завода выглядят вполне современно, имея чуть ли не самый высокий уровень автоматизации в компании Merloni.

С приходом на завод нового хозяина остро встала проблема информационной интеграции российского предприятия в западную компанию. Для расположенного в Италии головного офиса Merloni липецкий «Стинол» выглядел своеобразным «черным ящиком». Не имея эффективных инструментов предоставления информации о деятельности предприятия корпоративному руководству, Стинол некоторое время оставался обособленным образованием и лишался возможности двигаться по пути совершенствования своих бизнес-процессов и органичного вхождения в организационную структуру Merloni. Специфика «Стинола» определялась не только тем, что предприятие расположено в России, где бухгалтерское и налоговое законодательство существенно отличается от европейского, а неразвитая транспортная инфраструктура усложняет и без того непростые процессы логистики и доставки продукции. Основное отличие — уникальная для Merloni комбинация производства и коммерческой службы в одном юридическом лице и на одной территории. «Стинол» не только производит холодильники, но и имеет свою службу продаж, которая полностью контролирует реализацию готовой продукции, поэтому и объемы информации о состоянии дел на заводе, которые должны поступать в корпоративный офис, выходят далеко за рамки привычных для Merloni потоков данных. Но составление отчетных документов средствами Microsoft Office не в состоянии удовлетворить самых элементарных требований по срокам и уровню детализации предоставляемой информации.

Решение проблемы, казалось бы, напрашивалось само собой. Корпоративным стандартом автоматизации управления в Merloni является SAP R/3, внедрение которой на «Стиноле» было начато еще до приобретения завода. Форсировать развертывание этого решения и на его основе осуществить плавное вхождение «Стинола» в информационную среду головной компании — такой сценарий можно было бы считать оптимальным. Если бы не одно «но». R/3 — не единственный источник данных для подготовки отчетов руководству компании. Кроме нее, на «Стиноле» функционируют индустриальная система собственной разработки на основе СУБД Oracle и своя система расчета заработной платы. Только использование всех данных может дать полномасштабную картину состояния дел на предприятии, однако переход всех подразделений на R/3 повлек бы за собой накладные расходы на синхронизацию данных и, что особенно неприятно, приостановку работы в информационной среде отделов, которые будет затрагивать такое внедрение. А это противоречило одной из главных задач, поставленных руководством Merloni — в минимальные сроки сделать работу завода прозрачной для головного офиса.

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

При выборе платформы для построения хранилища рассматривались три альтернативы: SAP R/3 BW, средства для построения хранилищ данных Oracle и DataStage компании Ascential Software. Несмотря на то что R/3 является корпоративным стандартом, создание хранилища с помощью средств этого семейства продуктов было признано чрезмерно дорогим. На Oracle работают все информационные системы «Стинола», но выбор, тем не менее, пал на другой вариант — решающим фактором стал опыт компании «Терн», продвигающей на российский рынок семейство продуктов Ascential.

Архитектура информационно-аналитической системы

Ситуация, возникшая на «Стиноле», создавала классические исходные условия для построения хранилища данных [1, 2] — несколько разных систем, не имеющих между собой ничего общего ни по структуре, ни по используемой терминологии, должны были стать источником аналитической информации для руководства компании. Транзакционные системы завода являются поставщиками оперативных данных, которые сами по себе не представляют большой ценности для руководства. Чтобы стать пригодным для анализа материалом, исходная информация должна быть консолидирована из всех возможных источников, обработана, сгруппирована по определенным предметным областям, очищена от избыточных, противоречивых и некачественных данных, описана в терминах, понятных конечному пользователю. Такая информация заносится в хранилище не в реальном времени, как в оперативных системах, а через заданные промежутки, определяемые спецификой отчетов. Все эти условия невозможно соблюсти, работая с оперативными базами данных. Именно поэтому для систем поддержки принятия решений, частным случаем которых является информационная система для руководства, строятся специальные хранилища, оптимизированные для аналитических запросов.

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

Как отмечает заместитель генерального директора завода «Стинол» по информационным технологиям Илья Садовенко, проект задумывался как тактический — преследовалась только цель информационной интеграции завода без изменения его бизнес-процессов

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

Проведя анализ предметных областей, команда разработчиков в составе специалистов «Терн» и «Стинол» соответствующим образом сгруппировала данные и сформировала схему будущего хранилища в виде так называемой «мультизвезды» (рис. 2). На основе общего набора таблиц «Измерений» (например, продукция, склад, период времени и т.д.) построен набор таблиц «Фактов» (количество продуктов на складе, план/факт произведенной продукции и т.д.), рассматриваемых в срезах соответствующих измерений.

Рис. 2. Схема хранилища данных «мультизвезда»

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

Система R/3 определена как приоритетный источник данных, поэтому во всех неоднозначных случаях данные, полученные из R/3, имеют преимущество перед остальными. Для каждой области данных сначала загружаются справочники или таблицы измерений, а для того чтобы избавиться от часто встречающихся в базах данных транзакционных систем составных ключей и для унификации ключевых полей во всем хранилище, таблицы дополняются так называемыми суррогатными ключами независимо от наличия ключевых полей в источниках. Вслед за справочниками в хранилище загружаются факты — данные, по которым будет проводиться анализ и составление отчетов. Фактические данные из источников дополняются при преобразовании набором суррогатных ключей связанных с ними измерений. Преобразования включают предварительные расчеты, суммирование и группировку данных, а также их денормализацию для ускорения последующего формирования отчетов. Была также проведена работа по формализации файлов ручного ввода в текстовом формате и таблиц Excel, которые обычно являются наиболее уязвимым местом автоматизированных систем управления.

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

Дмитрий Князев, консультант компании «Терн»: «Структура хранилища определялась требованиями головного офиса Merloni, сотрудники которого должны были стать основными пользователями информационно-аналитической системы «Стинола».

На данный момент объем хранилища составляет около миллиона записей (порядка 200 Мбайт) и большую его часть занимают данные по движению материалов, закупкам и продажам. DataStage позволил построить хранилище, открытое для дальнейшего наращивания, при этом увеличение его размеров не отражается на скорости заполнения отчетов. По оценкам разработчиков, прирост будет составлять не более десятков процентов — немалая часть первоначального объема занята справочниками, изменения которых происходят медленно. Очистка (фильтрация) и агрегирование данных позволяют сократить объем хранимой информации до необходимого для анализа минимума, а разделение фактических данных по областям благодаря использованию семантических слоев позволяет при создании отчета формировать запросы по возможно меньшему числу таблиц.

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

Юниверсы и готовые формы отчетов (шаблоны), помещены в репозиторий, откуда пользователи с соответствующими правами доступа могут получать нужные отчеты по почте при помощи средств автоматической рассылки Business Objects Broadcast Agent. Права доступа к данным определяются также средствами Business Objects, которые позволяют ограничивать доступ к определенным объектам, отчетам или даже части отчета в зависимости от функциональной роли пользователя.

Подводные камни объединения

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

Проект был начат в конце 2001 года, а в мае 2002-го система «задышала». По словам Садовенко, был получен удовлетворивший руководство Merloni результат за разумное время и разумные средства. Сегодня систему, которая предоставляет консолидированные данные о работе большого предприятия, обслуживает всего один человек — специалист ИТ-отдела «Стинола». В его задачи входит не только поддержка нормального функционирования этого решения, но и его развитие. Получив с помощью системы четкое представление о деятельности завода, сотрудники головного офиса теперь могут заинтересоваться такими деталями, которые в отчетах не предусмотрены, и требовать внесения в них определенных изменений. Это делается средствами Business Objects и не затрагивает структуры и содержания хранилища.

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

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

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

Литература

[1] Дубова Н. Устройство и назначение хранилищ данных. // Открытые системы, 1998, № 4

[2] Сураджит Чаудхури, Умешвар Дайал, Венкатеш Ганти. Технология баз данных в системах поддержки принятия решений. // Открытые системы, 2002, № 1


«Стинол» в структуре Merloni

Итальянская корпорация Merloni Elettrodomestici входит в тройку лидеров европейского рынка бытовой техники. Merloni производит плиты, холодильники, стиральные и посудомоечные машины и сушилки под марками Ariston и Indesit. Корпорация имеет коммерческие представительства в 21 стране мира, продает в год порядка 11 млн. бытовых приборов, а ее годовой оборот приближается к 2 млрд. евро. Корпорации принадлежат 16 заводов в 7 странах мира. Помимо основных марок в ассортименте продукции Merloni представлены три региональных брэнда, в том числе 19 моделей холодильников «Стинол», производимых на заводе в Липецке. В сентябре 2000 года Merloni Elettrodomestici приобрела 100% акций завода «Стинол» с численностью сотрудников 5400 человек. В прошлом году продажи «Стинола» составили более 1 млн. холодильников, что составляет более 30% рынка бытовой холодильной техники в России и СНГ.


Ascential DataStage

Ascential DataStage — инструмент визуальной разработки процедур извлечения, преобразования и загрузки данных (ETL — Extraction, Transformation, Loading) и управления процессом трансформации данных. Особенностями DataStage является охват широкого спектра источников данных, максимальное использование возможностей параллельных вычислений и достижение предельного уровня производительности без ущерба функциональным возможностям.

Описание диаграмм ETL-процессов осуществляется с помощью модуля DataStage Designer. Каждый элемент диаграммы (stage) определяет какое-либо действие по извлечению данных, их преобразованию или загрузке. Описание ETL-процедуры заключается в перетаскивании с инструментальной панели кнопок, соответствующих определяемому действию, и описанию его свойств. Цепочка элементов диаграммы определяет одно задание (job).

В рамках одного задания может проводиться одновременно чтение данных из нескольких источников и запись преобразованных данных в несколько приемников. При этом как источники, так и приемники могут находиться в различных базах данных или файлах и иметь в сети несколько копий. Помимо SQL для ускорения процесса загрузки данных можно использовать прямой ввод/вывод в файл или быстрые загрузчики (bulk loader). В качестве источников данных могут выступать реляционные базы данных, плоские файлы, базы данных на мэйнфреймах, журнальные файлы Web-серверов, XML-файлы. Такие же форматы могут иметь и приемники. Компания Ascential также предлагает специальные средства извлечения и загрузки данных Extract PACK для наиболее популярных приложений: SAP, PeopleSoft, FirstLogic, Siebel и др., а также Load PACK для SAP BW, что позволяет упростить работу с имеющимися приложениями и более эффективно использовать возможности многомерного сервера SAP.

Потоки данных в сервере DataStage

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

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

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

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

В DataStage реализована поддержка технологий высокоскоростной загрузки данных, предлагаемых партнерами Ascential и другими поставщиками хранилищ данных. Загрузчик больших массивов данных или утилиты «быстрой загрузки» обеспечивают высокоскоростную вставку строк в реляционную таблицу, обычно отключая ведение журналов (logging) и другие служебные действия с транзакциями, которые реализуются в регистрирующих приложениях.

Системы поддержки принятия решений требуют периодического обновления данных. Время, требуемое для обновления, определяется такими параметрами, как частота обновления, доступность приемников данных, возможность доступа к источникам, ожидаемый объем измененных данных. Технология CDC (Change Data Capture — «захват изменений данных») позволяет изменять данные в хранилище непосредственно при обнаружении изменения данных в источнике. CDC описывает методологии и инструменты, требуемые для сбора, модификации, и перемещения недавно введенных или обновленных записей. Поддержка CDC в DataStage уменьшает время загрузки, требуемое для обновления хранилищ данных.


Business Objects

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

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

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

Рис. Объединение диаграмм, таблиц и графиков в одном отчете

Все документы, созданные в Business Objects, могут храниться в едином репозитории, организованном на базе реляционной СУБД, что упрощает управление системой и решает проблему безопасности передачи и хранения данных. Для доступа к данным и функциям системы поддерживаются процессы авторизации и аутентификации каждого пользователя. В репозитории также могут храниться документы других приложений, например, Adobe Acrobat, Excel и т.д.

Управление репозиторием осуществляется с помощью модуля Business Objects Supervisor, позволяющего из одной точки контролировать пользователей и ресурсы в распределенной среде. Объектная модель системы безопасности дает возможность устанавливать и изменять права доступа как группы, так и индивидуального пользователя. Администратор может определять, какая функциональность продуктов, информация и документы будут доступны каждой группе пользователей. Supervisor позволяет также использовать существующие системы безопасности, включая аутентификацию Windows NT, LDAP или обычную систему проверки паролей для баз данных. В результате появляется возможность реализовать единую процедуру аутентификации для разнородных источников данных.

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