Обобщённый портрет СППР

Обобщенный портрет СППР(DSS)-систем можно составить на основе краткого анализа предложений компаний Cognos, SAS, Hyperion, Oracle.

Прежде всего, следует обратить внимание на то, что перечень ключевых игроков на рынке DSS-систем не совпадает с лидирующим списком производителей систем ERP. Присутствие компании Oracle в приведенном списке отражает явно выраженное намерение компании Oracle развивать данное направление, наличие действительно развитого инструментального набора для выполнения подобных проектов, последние приобретения компании в данной области. С этой точки зрения в анализируемый список можно было бы добавить и IBM с Microsoft, но эти производители все-таки больше относятся к инструментальной области и платформам, чем к прикладной.

В основной функциональный набор DSS-систем входят:

· финансовое планирование и бюджетирование;

· формирование консолидированной отчетности (до 200 преднастроенных отчетов);

· создание информационной системы стратегического управления на основе ключевых показателей деятельности (Balance Scorecards) с преднастроенными библиотеками показателей (до 500);

· анализ взаимоотношений с клиентами и поставщиками;

· анализ рыночных тенденций;

· функционально-стоимостный анализ (ABC-Costing);

· функционально-стоимостное управление (Activity Based Management, ABM);

· система постоянных улучшений (Kiezen Costing);

· многомерный анализ данных (OLAP);

· выявление скрытых закономерностей (Data Mining);

· выявление моделей (структур) данных;

· статистический анализ и прогнозирование временных рядов;

· событийное управление бизнесом (Event-driven BI);

· анализ рисков;

· формирование преднастроенных запросов (до 500-600);

· интеллектуальный поиск (по неполным данным и неформальным запросам);

· бизнес-моделирование и анализ эффективности выполнения бизнес-процессов;

· референтные отраслевые модели.

Количество преднастроенных областей анализа достигает 30-40.

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

· уведомления об определенном состоянии;

· исполнение;

· операционные события.

Информационной платформой являются хранилища данных (Data Warehouse).

Инструментальная среда — интеграционные системы, основанные на открытых стандартах. Эти системы соответствуют требованиям:

· информационной безопасности;

· масштабируемости;

· открытости;

· многомерного и многовариантного представления данных;

· интеллектуального интерфейса;

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

· обеспечивают сервис по «очистке» данных при их загрузке в хранилища.

Техническое обеспечение связано с:

· обработкой данных;

· надежным хранением данных и обеспечением целостности;

· архивацией и восстановлением данных;

· сетевым и телекоммуникационным обеспечением;

· криптографическим обеспечением;

· управлением доступом пользователей;

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

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

Целевые результаты

Результаты выполнения проектов целевым образом соответствуют предоставлению возможности получения ответов на вопросы:

· здоров ли бизнес?

· кто мой лучший клиент?

· какой мой лучший продукт или услуга?

· какого поставщика мне выгодно выбрать и почему?

· где мы типично не укладываемся в сроки и почему?

· какова эффективность деятельности нашего персонала?

· какая дочерняя компания внесла наибольший (наименьший) вклад в результат?

· что показывает анализ фондоотдачи оборудования?

· какой сценарий и подход выбрать при слиянии (реструктуризации) компаний?

2.10. OLAP

OLTP и OLAP

Ситуацию с корпоративной информацией, складывающуюся в настоящее время на большинстве предприятий, можно сравнить с сокровищем, которое лежит под ногами, но которое никто не может извлечь. По данным Gartner Group, большая часть корпоративной информации – 90 % - лежит невостребованной и никак не анализируется. Между тем многие из проблем, которые возникают в текущей деятельности предприятия и которые требуют оперативного решения, не являются для него абсолютно новыми. Как правило, предприятие уже когда-то сталкивалось с похожей ситуацией, и в этой связи были приняты определенные управленческие решения, которые привели к соответствующим результатам. Этот опыт (позитивный или негативный) может оказаться очень ценным при решении проблем, стоящих перед предприятием в настоящий момент.

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

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

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

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

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

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

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

Выход из этой ситуации один, и сформулирован он Биллом Гейтсом в виде выражения: "Информация на кончиках пальцев". Исходная информация должна быть доступна ее непосредственному потребителю – аналитику. Именно непосредственно доступна (!). А задачей сотрудников информационного отдела является создание системы сбора, накопления, хранения, защиты информации и обеспечения ее доступности аналитикам.

OLAP-технологии и предназначены именно для того, чтобы бизнес-аналитики имели возможность оперировать с накопленными данными, непосредственно участвовать в их анализе. Подобные аналитические системы противоположны OLTP-системам в том плане, что они устраняют информационную избыточность ("сворачивают" информацию). Вместе с тем очевидно, что именно избыточность первичной информации определяет эффективность анализа. СППР, объединяя эти технологии, дают возможность решать целый ряд задач:

• Аналитические задачи: вычисление заданных показателей и статистических характеристик бизнес-процессов на основе ретроспективной информации, находящейся в хранилищах данных.
• Визуализацию данных: представление всей имеющейся информации в удобном для пользователя графическом и табличном виде.
• Получение новых знаний: определение взаимосвязи и взаимозависимости бизнес-процессов на основе существующей информации (проверка статистических гипотез, кластеризация, нахождение ассоциаций и временных шаблонов).
• Имитационные задачи: математическое моделирование поведения сложных систем в течение произвольного периода времени. Иными словами, это задачи, связанные с необходимостью ответить на вопрос: "Что будет, если ...?"
• Синтез управления: определение допустимых управляющих воздействий, обеспечивающих достижение заданной цели.
• Оптимизационные задачи: интеграция имитационных, управленческих, оптимизационных и статистических методов моделирования и прогнозирования.

Менеджеры предприятия, использующие инструментальные средства OLAP-технологии, даже без специальной подготовки могут самостоятельно и оперативно получать всю необходимую для исследования закономерностей бизнеса информацию, причем в самых различных комбинациях и срезах бизнес-анализа. Бизнес-аналитик имеет возможность видеть перед собой список измерений и показателей бизнес-системы. При столь простом интерфейсе аналитик может строить любые отчеты, перестраивать измерения (скажем, делать кросс-таблицы – накладывать одно измерение на другое). Кроме этого, он получает возможность создавать свои функции на базе существующих показателей, проводить анализ "что, если" – получать результат, задавая зависимости каких-либо показателей бизнес-функций или бизнес-функцию от показателей. При этом максимальный отклик любого отчета не превышает 5 секунд.

OLAP (Аббрев. от: On-Line Analytical Processing) - Технологии интерактивной аналитической обработки данных в системах баз данных, предназначенные для поддержки принятия решений и ориентированные главным образом на нерегламентированные интерактивные запросы. OLAP имеет дело, как правило, с историческими данными, которые могут быть не представленными в операциональных информационных системах. В силу особенностей интерактивной аналитической обработки для ее реализации требуются несколько иные средства управления данным по сравнению с предоставляемыми традиционными системами управления базами данных, ориентированными на обработку транзакций. По указанным причинам в качестве источников данных для OLAP часто используют не операциональные базы данных, а хранилища данных.

2.10.2. Технологии OLAP[21]

Одной из наиболее актуальных сфер применения систем баз данных, которая стала активно развиваться в начале 90-х гг., являются системы поддержки принятия решений. Именно в связи с ними получили распространение технологии, называемые интерактивной аналитической обработкой данных (On-Line Analytical Processing, OLAP).

Термин OLAP был введен Э. Коддом в 1993г. Он сформулировал требования (известные 12 правил) к программным продуктам, воплощающим необходимую для поддержки технологии OLAP функциональность. Среди них одно из центральных требований — поддержка многомерного анализа данных. При этом многомер­ность данных рассматривается Э. Коддом с точки зрения их концептуального представления, а не представления в источнике данных.

Если принять во внимание способы организации источников данных систем OLAP, то различаются технологии ROLAP (Relational OLAP), MOLAP (Multi-Dimensional OLAP) и HOLAP (Hybrid OLAP). В первом случае много­мерное представление данных для технологии OLAP поддерживается над реля­ционной базой данных. Во втором случае источник данных представляет собой базу данных, основанную на многомерной модели данных, специально ориенти­рованную на OLAP. Наконец, в третьем случае используется комбинация источ­ников данных указанных видов.

Основной структурой данных при многомерном их представлении является куб данных. База данных состоит в таком случае из одного или нескольких таких кубов. Куб данных обладает двумя или более независимыми измерениями, опре­деляющими своего рода систему координат представляемого им пространства данных. Координаты по данному измерению представляются значениями соответствующего атрибута данных, и на множестве этих значений могут быть установлены отношения иерархии. Совокупности координат по разным изме­рениям соответствуют значения данных в точках куба, часто называемые эле­ментами (Item) или ячейками (Cell). Существование иерархии значений "коор­динат" измерений позволяет агрегировать значения соответствующих данных, осуществлять анализ данных с тем или иным уровнем детализации.

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

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

Иногда возможна и обратная операция — детализация (Drill-down), позво­ляющая получать более детализированные данные.

Операция поворота (Rotation) позволяет изменить порядок измерений в кубе данных нужным для пользователя образом.

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

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

К настоящему времени сформировалась индустрия технологий OLAP. Вы­пускается большое количество программных продуктов, поддерживающих эти технологии. Среди их поставщиков ведущие участники рынка технологий баз данных — компании Oracle, IBM, Informix, а также целый ряд новых компаний, специализирующихся на этом секторе рынка информационных технологий.

2.10.3. Основы OLAP[22]

Трудно найти в компьютерном мире человека, который хотя бы на интуитивном уровне не понимал, что такое базы данных и зачем они нужны. В отличие от традиционных реляционных СУБД, концепция OLAP не так широко известна, хотя загадочный термин "кубы OLAP" слышали, наверное, почти все. Что же такое OnLine Analytical Processing, где он обитает, и с чем его едят, мы и попытаемся разобраться.

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

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

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

Здесь "Страна", "Товар", "Год" являются атрибутами, а "Объем продаж" - тем самым числовым значением. Задачей аналитика, повторимся, является выявление стойких взаимосвязей между атрибутами и числовыми параметрами. Посмотрев на таблицу, можно заметить, что ее легко можно перевести в три измерения: по одной из осей отложим страны, по другой - товары, по третьей - годы. А значениями в этом трехмерном массиве у нас будут соответствующие объемы продаж.

Рис. 2.8. Трехмерное представление таблицы. Серым сегментом показано, что для Аргентины в 1988 году данных нет

Вот именно такой трехмерный массив в терминах OLAP и называется кубом. На самом деле, с точки зрения строгой математики кубом такой массив будет далеко не всегда: у настоящего куба количество элементов во всех измерениях должно быть одинаковым, а у кубов OLAP такого ограничения нет. Тем не менее, несмотря на эти детали, термин "кубы OLAP" ввиду своей краткости и образности стал общепринятым. Куб OLAP совсем не обязательно должен быть трехмерным. Он может быть и двух-, и многомерным - в зависимости от решаемой задачи. Особо матерым аналитикам может понадобиться порядка 20 измерений - и серьезные OLAP-продукты именно на такое количество и рассчитаны. Более простые настольные приложения поддерживают где-то 6 измерений.

Измерения OLAP-кубов состоят из так называемых меток или членов (members). Например, измерение "Страна" состоит из меток "Аргентина", "Бразилия", "Венесуэла" и так далее.

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

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

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

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

Рис. 2.9. Пример иерархии

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

Концепция OLAP появилась именно для разрешения подобных проблем. Кубы OLAP представляют собой, по сути, многомерные отчеты. Разрезая многомерные отчеты (кубы, то есть) по измерениям, аналитик получает, фактически, интересующие его "обычные" двумерные отчеты (это не обязательно отчеты в обычном понимании этого термина - речь идет о структурах данных с такими же функциями). Преимущества кубов очевидны - данные необходимо запросить из реляционной СУБД всего один раз - при построении куба. Поскольку аналитики, как правило, не работают с информацией, которая дополняется и меняется "на лету", сформированный куб является актуальным в течение достаточно продолжительного времени. Благодаря этому, не только исключаются перебои в работе сервера реляционной СУБД (нет запросов с тысячами и миллионами строк ответов), но и резко повышается скорость доступа к данным для самого аналитика. Кроме того, как уже отмечалось, производительность повышается и за счет подсчета промежуточных сумм иерархий и других агрегированных значений в момент построения куба. То есть, если изначально наши данные содержали информацию о дневной выручке по конкретному товару в отдельно взятом магазине, то при формировании куба OLAP-приложение считает итоговые суммы для разных уровней иерархий (недель и месяцев, городов и стран).

Конечно, за повышение таким способом производительности надо платить. Иногда говорят, что структура данных просто "взрывается" - куб OLAP может занимать в десятки и даже сотни раз больше места, чем исходные данные.

Теперь, когда мы немного разобрались в том, как работает и для чего служит OLAP, стоит, все же, несколько формализовать наши знания и дать критерии OLAP уже без синхронного перевода на обычный человеческий язык. Эти критерии (всего числом 12) были сформулированы в 1993 году Е.Ф. Коддом - создателем концепции реляционных СУБД и, по совместительству, OLAP. Непосредственно их мы рассматривать не будем, поскольку позднее они были переработаны в так называемый тест FASMI, который определяет требования к продуктам OLAP. FASMI - это аббревиатура от названия каждого пункта теста:

· Fast (Быстрый). Приложение OLAP должно обеспечивать минимальное время доступа к аналитическим данным - в среднем порядка 5 секунд;

· Analysis (Анализ). Приложение OLAP должно давать пользователю возможность осуществлять числовой и статистический анализ;

· Shared (Разделяемый доступ). Приложение OLAP должно предоставлять возможность работы с информацией многим пользователям одновременно;

· Multidimensional (Многомерность). См. выше;

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

Работа с OLAP-системами может быть построена на основе из двух описанных ниже схем.

Для "легковесного" применения подойдут OLAP-средства, встроенные в настольные приложения. Такие средства, как правило, имеют множество ограничений: на количество измерений, на допустимые иерархии и так далее. К подобным средствам, например, относится модуль Pivot Table, позволяющий работать с кубами в Microsoft Excel. Pivot Table входит в Microsoft Office с незапамятных времен и до недавнего времени был единственным OLAP-продуктом в его составе. В этом случае данные извлекаются модулем-клиентом непосредственно из реляционной СУБД.

В "тяжелых" случаях применяют двухступенчатую схему "клиент-сервер". Сервер обеспечивает непосредственно извлечение информации из СУБД и все прочее, необходимое для создания кубов. Специализированное же приложение-клиент предназначено для удобного (а главное - эффективного) просмотра кубов и выявления тех самых аналитических закономерностей, с которых мы начинали наш экскурс. В линейке продуктов Microsoft серверная часть представлена в лице Microsoft Analysis Services, которые входят в MS SQL Server. Кроме того, в состав MS Office включен OLAP-клиент под названием Microsoft Data Analyzer.

 

2.11. Хранилища данных