Модели и хранилища

Продолжение. Начало см. PC Week/RE, № 32/2002, с. 20; № /2002, с. 26; N 36/2002, с. 28.

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

Мы уже некоторым образом обращались к бизнес-моделям, когда в начале года обсуждали особенности систем-конструкторов, присутствующих на российском рынке (см. PC Week/RE, N 11/2002 и N 23/2002) а сейчас смотрим на них глубже и шире.

В статье “Качество информации: от очистки данных - к модели предприятия” (см. PC Week/RE, N 36/2002, с. 28) была описана трехуровневая модель обработки информации на предприятии, которая предполагает три перспективы (концептуальную, логическую и физическую) и три уровня моделирования (источник, хранилище, пользователь).

Чтобы лучше понять роль моделей и метамоделей в обеспечении качества информации в ИИ, мы обратились к экспертам в области хранилищ данных со следующими вопросами.

1. Какие модели существуют в концептуальной перспективе ИИ?

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

В роли наших респондентов выступили представители трех компаний - Андрей Волков, консультант SAP по BI (www.sap.com/cis/), Андрей Сахаров консультант Oracle по OLAP и DW (www.oracle.com/ru/) и Лев Тришанков, исполнительный директор “Алеф Консалтинг & Софт” (www.alef.ru).

Андрей Волков

Андрей Волков: Давайте сначала определимся, какие бывают модели. На мой взгляд, в концептуальной перспективе есть два вида моделей - формальные и прикладные. Для развития формальных моделей создаются консорциумы, в которые входят ученые и специалисты различных компаний. Они строятся на обобщении накопленного практического опыта, их оптимальность глубоко обоснована. Примерами таких моделей могут быть EVA (Economic Value Added), SVA (Shareholder Value Added), SCOR (Supply Chain Operations Refe-rence) или BSC (Balanced Score Card). Каждая из них имеет свою специфику, а следовательно, и свою область применения. С другой стороны, их применение целесообразно рассматривать в рамках внедрения системы управления эффективностью деятельности компании. Здесь мы уже не обойдемся без соответствующего набора ключевых показателей эффективности (KPI - Key Performance Indicators), причем для каждой модели - своего.

Дадим краткую характеристику перечисленным моделям. EVA позволяет весьма объективно оценить деятельность компании за прошедший период, поскольку сравнивает прибыль со средневзвешенной стоимостью капитала. SVA наиболее полезна на этапе определения стратегии развития компании, в том числе стратегии инвестиций. SCOR - это формальная модель, описывающая оптимальную цепочку поставок (расширенную цепочку “от поставщика до потребителя”). Она развивается консорциумом Supply-Chain Council, в который входит большое количество компаний, в том числе и SAP. Что же касается BSC, то эта уже ставшая классической (несмотря на небольшой срок развития - 10 лет) система управления компанией не только позволяет построить правильную систему KPI, но и помогает оценить деятельность компании в привязке к следованию стоящим перед ней стратегическим целям, т. е. приводит стратегию в действие. Продукты SAP поддерживают все перечисленные модели.

При построении конкретного решения для управления компанией с учетом таких моделей создается более детализированная прикладная модель, которая и реализуется на логическом и физическом уровнях. Например, при внедрении решений SCM (Supply Chain Management) средствами продуктов SAP можно использовать результаты оптимизации, полученные с помощью модели SCOR. Однако в итоге мы будем иметь весьма подробную и гибкую систему, пригодную как для организации оперативной работы, так и для получения аналитики, необходимой для принятия управленческих решений. При этом набор KPI, описанных моделью SCOR, будет дополнен аналитикой, характерной для SCM. Это же касается решений в области управления взаимоотношения с клиентами (CRM), стратегического управления компанией (SEM) и др.

Рис. 1. Модели в SAP

Применяемая в решениях SAP аналитика основана на использовании хранилища данных SAP BW (Business Warehouse). На логическом уровне данные собираются в инфокубах *1 хранилища, при этом данные в самом общем случае имеют иную структуру, чем KPI из соответствующих моделей. Проще говоря, мы собираем в BW информацию, имеющую “техническую” природу (привязка к полям базы данных), в то время как KPI - это бизнес-ориентированные показатели. Для того чтобы рассчитать KPI для моделей концептуального уровня, надо определить процедуру их вычисления на основе данных BW. Для большинства KPI SCOR-модели такие процедуры в mySAP.com уже определены (рис. 1).

_____

*1. Так в SAP BW принято называть кубы.

Что касается средств контроля целостности данных и связности кубов на логическом уровне SAP BW, то я не уверен в их необходимости, если данные поступают из SAP. Там предусмотрен настолько жесткий контроль связности и целостности данных, что просто речи быть не может об их несогласованности. Для обеспечения качества данных служит и единая семантическая структура бизнес-контента. Тем не менее с каждой новой версией BW арсенал средств для согласования и коррекции загружаемых данных расширяется. Это действительно нужно в тех случаях, когда компании, не использующие R/3, хотят строить свои стратегические системы управления на аналитическом слое SAP BW.

Андрей Сахаров

Андрей Сахаров: Существует два пути создания качественной ИИ с помощью инструментария Oracle. Первый путь - классический, описанный Инмоном, Кимбелом и другими авторами. Он поддерживается методологией Oracle по построению хранилищ (ODWM, Oracle Data Warehouse Method). Это набор шагов с оценочными таблицами, основанными на практическом опыте, который подсказывает, как правильно учесть технологические особенности, требования пользователей и политические моменты при построении хранилища данных.

Второй путь - это Oracle EDW (Embedded Data Warehouse). В этом случае предполагается, что у клиента есть внедренные модули Oracle e-Business Suite (прежнее название - Oracle Application).

В EDW имеются преднастроенные решения, которые опираются на опыт внедрения и известную структуру данных e-Business Suite. Кроме того, существуют аналитические отчеты в составе BIS (Business Intelligent System), реализованные на базе OLAP Discoverer и также настроенные на структуру хранилища данных EDW.

Еще один модуль, ориентированный на EDW, - Balanced Score Card. С его помощью пользователи сразу получают построенную на основе накопленного опыта систему KPI для конкретной отрасли, средства сбора данных из e-Business Suite и множество предопределенных отчетов.

Что касается моделей логического уровня и их роли в обеспечении качества информации, то отличной иллюстрацией может быть уже упоминавшийся в прошлых публикациях продукт - OFSA (Oracle Financial Services Application).

При использовании EDW и Oracle e-Business Suite мы не сталкивается с необходимостью жесткого контроля согласованности данных, получаемых из первоисточников, поскольку они приходят уже в согласованном виде. Но в банковском секторе клиенты очень консервативны и обычно не идут на инновации в области приложений оперативного уровня. Работает+ и слава Богу. Появилась новая задача, возникли новые потребности - рядом строится еще одно приложение. И тогда согласование данных из различных оперативных источников, равно как и выверка достоверности информации, становятся очень серьезной проблемой.

Идея OFSA заключается в том, что данные, поступающие в хранилище из технологических систем, отвечающих, например, за депозитные счета, кредитные карты, ипотечное кредитование, проверяются с помощью данных Главной книги (GL, General Ledge). Для проверки используется правило баланса бухгалтерских счетов.

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

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

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

Рис. 2. Хранилище данных OFSA

Итак, OFSA обеспечивает качество и достоверность информации с помощью “трехуровневой” архитектуры - уровня транзакционных данных, уровня данных, агрегированных по времени, и уровня контроля сходимости баланса, который содержит данные GL (рис. 2).

Лев Тришанков

Лев Тришанков: К счастью, существует такое решение, как OFSA. Иначе мы были бы похожи на непризнанных гениев, которые всем доказывают прелести своего подхода, в то время как его практической ценности никто не видит. Мы неустанно твердим, что данные должны быть согласованы в рамках модели предприятия концептуального и логического уровня. Никого не удивляет ссылочная целостность на физическом уровне. Более того, все считают ее крайне необходимой. А о моделях более высокого порядка, но не менее важных, речи нет. Парадокс.

Раньше ответ был такой: поставьте R/3 или Baan и все ваши проблемы будут решены. Но уже становится очевидным, что какая-то конкретная ERP-система редко решает все проблемы предприятия. Сначала это поняли в SAP, затем в IBM. Сейчас практически все компании участвуют в инициативах по интеграции приложений (EAI, Enterprise Application Integration) - разрабатывают метамодели процессов, такие, как SCORE, и выделяют в своих приложениях интеграционный уровень.

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

В нашей системе “Алеф” в основе построения такой модели лежит, как и в OFSA, балансовый подход, в соответствии с которым все параметры модели подбираются и группируются так, что их суммарное изменение внутри каждой группы и в каждый момент времени равно нулю. Такие группы параметров мы называем субмоделями.

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

_____

*1. Подробное описание балансового подхода к построению моделей см.: www.alef.ru/cubes/index.html.

На рис. 3 приведен пример отражения процесса в субмоделях хранилища данных.

Рис. 3. Отражение процесса в субмоделях системы “Алеф”

Система “Алеф” предназначена для менее крупных предприятий, чем те, что используют R3 и Oracle e-Business Suite. Поэтому мы сочли возможным обеспечить пополнение многомерных параметров хранилища данных в реальном времени. OLTP-часть нашей системы построена “вокруг” хранилища: опирается на его семантическую структуру (термины “Алефа”) и хранит в его структурах большую часть информации, которая нужна для поддержки оперативных процессов. Поэтому для нас контроль целостности оперативного процесса и контроль согласованности кубов в логической перспективе - это одно и то же.

Для расчета KPI моделей концептуального уровня и передачи данных в инструменты анализа используется механизм Alef Connection, опирающийся на сервис хранимых запросов системы “Алеф”.

* * *

Итак, подводя итог сказанному, хотелось бы отметить следующие моменты.

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

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

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

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