ИНФОРМАЦИООНЫЙ_МЕНЕДЖМЕНТ / Бочаров_Интегрированные корпоративные ИС(галактика)

Далее по всем изделиям и операциям вводятся необходимые параметры (рис. 1.7).

': Ssmmmmmwnm'l з^мш) Нт»як\ 'timemml №«ywiuMirpi] ||М1м*«>Ш^| i

Рис. 1.7. Система «МЗ-online». Окно ввода параметров в модуле M3-Expert

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

Возможен вывод из оптимизации каких-либо операций (вклад­ ка Вывод из оптимизации - см, рис. 1.8), если точно известно, что, например, на каком-то станке должно быть обработано опреде­ ленное количество деталей.

Система отслеживает балансовые уравнения по дефицитным ресурсам (вкладка. Дефицитные ресурсы). Например, она «не по­ зволит» перегрузить трансформаторную подстанцию, если все включенное оборудование способно «выбить» электропроводку.

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

30

'-Mr*-

[Навоэможна

Рис. 1.8. Система «МЗ-online». Окно ввода параметров рабочих центров в модуле M3-Expert

и| Рм]|ймг«гр«очкг<|

g

Рис. 1.9. Система «МЗ-online». Окно ввода приоритетов заказов в модуле M3-Expert

Далее выполняется балансировка весов ограничений оптими­ зационной задачи (рис. 1.10). В основе этой процедуры лежат критерии, которые менеджеры предприятия выбрали приоритет­ ными.

Предположим, что основным критерием является выполне­ ние заказов практически «любой ценой» в смысле перегрузки рабочих центров. Таким образом, перегрузка персонала прине­ сена в жертву выполнению плана (см. рис. 1.10).

31

шии

РисЛЛО. Окно установки балансировки весов ограничений оптимизационной задачи

в модуле M3-Expert

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

о 200со 150- S. 100

я 50 со

2 3 4 Рабочие центры

Рис. 1.11. Оптимальная загрузка рабочих центров

После проведения оптимизационных расчетов в распоряже­ нии менеджеров оказывается огромный объем информации по организации производственного процесса. На рис. 1.11 представ­ лен случай, когда 2, 4 и 5-й рабочие центры должны будут рабо­ тать с огромной перегрузкой. Отсюда следует, например, вывод о необходимости приема на работу соответствующих специалис­ тов, покупки либо аренды оборудования.

32

1.4.2. Аналитическая обработка данных для поддержки принятия решений

В базе данных интегрированной корпоративной информаци­ онной системы накапливается огромный объем информации. Перед менеджерами предприятия встает вопрос: как и для каких целей использовать это море информации?

Чаще всего пользователи ограничиваются простыми запро­ сами, например: выдать отчет по всем заказчикам, задерживаю­ щим по данным на сегодняшний день оплату отгруженной в их адрес продукции. Но можно поставить и более сложное задание: каков информационный «портрет» (т.е. характерные черты) за­ казчика, задерживающего оплату? Кто по преимуществу эти за­ казчики: крупные или малые предприятия? К какой отрасли они чаще всего относятся - транспортники, сельхозпроизводители, связисты? В каких регионах находятся? Есть ли сезонные законо­ мерности в поведении таких недобросовестных заказчиков? И самое главное - есть ли ассоциации (т.е. одновременрюе присут­ ствие) между перечисленными атрибутами предприятий?

Если удастся получить такой информационный «портрет», то может быть принято решение об особом порядке взаимоотноше­ ний с подобными заказчиками - например, требовать от них пол­ ную предоплату за выполнение заказа.

Вторая задача на два порядка сложнее первой. Если первую задачу можно решить, используя стандартный аппарат запросов к базам данных, то для решения второй придется применить ме­ тоды интеллектуального анализа данных. Однако результаты ре­ шения и первой, и второй задачи можно использовать для под­ держки принятия решений.

Выделяют три основные технологии поддержки принятия уп­ равленческих решений на основе накопленной информации [23]:

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

область детализированных данных. Классические реляционные СУБД нормально справляются с подобными задачами, поэтому

вподробном их рассмотрении нет необходимости;

•технологии OLAP (On-line Analytical Processing - интерак­ тивная аналитическая обработка данных), ориентированные на

область агрегированных показателей]

33

• технологии интеллектуальной обработки данных, ориенти­ рованные на область закономерностей. Интеллектуальная обра­ ботка проводится методами интеллектуального анализа данных (ИАД, в западной литературе - Data Mining [10]). С помощью этих технологий решаются задачи поиска функциональных и логичес­ ких закономерностей в накопленной информации, объяснения аномалий в данных.

Рассмотрим подробнее перечисленные технологии.

Технологии OLAP

Технологии OLAP основаны на понятии хранилище данных, которое определено родоначальником этого направления Бил­ лом Инмоном (W. Inmon) как «предметно-ориентированное, ин­ тегрированное, поддерживающее хронологию собрание данных для поддержки процесса принятия управленческих решений».

Данные в хранилище поступают из оперативных систем (OLTP-систем), из внешних источников, например статистичес­ ких отчетов, «скачанных» из Интернета прайс-листов других ком­ паний и т.п.

Зачем создавать хранилища данных, ведь информация и так находится в файлах оперативных систем? Еще несколько лет на­ зад в качестве главных причин назывались различие форматов хранящихся данных, их разрозненность, локализация в разных местах корпоративной сети. Действительно, до 1998-2000 гг. хра­ нение всех данных на центральном сервере БД было редким яв­ лением. Сейчас в связи с интенсивным внедрением ИКИС поло­ жение меняется. Однако принципиальны такие причины необхо­ димости создания хранилищ данных:

•сложные аналитические запросы к оперативным данным «забирают» ресурсы сервера и тормозят работу информацион­ ной системы;

•оперативные данные мало пригодны для непосредственно­ го сложного анализа;

•системы OLTP предназначены для оперативной обработ­ ки данных, поэтому они не приспособлены для хранения инфор­ мации за длительный (более нескольких месяцев) период, в то время как для OLAP интересен анализ объекта «в исторической ретроспективе».

34

Оперативные корпоративные данные, а также данные из раз­ личных внешних источников «очищаются», интегрируются, «складываются» в хранилище, затем готовятся для OLAP-анали- за и ИАД (рис. 1.12).

Рис. 1.12. Структура корпоративной информационно-аналитической системы

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

На рис. 1.13* в качестве мер в трехмерном кубе использованы суммы продаж, в качестве измерений - Время, Товар и Магазин.

*Пример из статьи М. Альперовича, http://www.cfin.ru/itm/olap/ intro.shtml.

35

Измерения показаны на определенных уровнях агрегирования (группировки): товары группируются по категориям, магазины - по странам, данные о времени продаж - по месяцам.

Рис. 1.13. Пример OLAP-куба

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

На рис. 1.14 приведен двумерный срез куба для одной меры - Unit Sales {Продано штук) и двух «неразрезанных» измерений -

Магазин и Время.

Рис. 1.14. Двумерный срез куба для одной меры

На рис. 1.15 показано одно «неразрезанное» измерение - Ма­ газин, но зато отображаются значения трех мер: Unit Sales {Про­ дано штук), Store Sales {Сумма продаэ/с) и Store Cost {Расходы магазина).

Рис. 1.15. Двумерный срез куба для нескольких мер

36

Возможны и более сложные варианты. Так, на рис. 1.16 отра­ жен случай, когда на осях среза (строках и столбцах) будут раз­ мещены два (или более) измерения.

Рис. 1.16. Двумерный срез куба с несколькими измерениями на одной оси

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

Может возникнуть вопрос: а разве представленные на рис. 1.13-1.16 результаты нельзя получить с помощью обычного ап­ парата создания запросов и отчетов к реляционным базам дан­ ных? Конечно, можно. Но тогда пользователю-аналитику при­ дется каждый раз вызывать программиста для подготовки соот­ ветствующих отчетов. Количество всевозможных «срезов» и «разрезов» данных, как видно из приведенного примера, огром­ но. Очевидно, что пользователю-аналитику, не обладающему на­ выками в программировании, необходим инструмент, который бы позволил «сворачивать», «разворачивать», «разрезать» дан­ ные быстро и удобно. Именно таким инструментом и является технология OLAP.

Заметим, что с самого начала появления ERP-систем их сла­ бость в плане возможностей анализа и составления отчетов была заметна. В англоязычной литературе даже появился термин «data (in) jail» - «данные в тюрьме» или «тюрьма для данных», кото­ рый характеризовал трудности получения нетривиальной инфор­ мации из баз данных ERP-систем.

Однако вернемся к рассматриваемому примеру OLAP-анали- за. Значения, откладываемые вдоль измерений, основоположни­ ки OLAP называют members (одни российские авторы переводят этот термин как метки, другие - как члены). С помощью меток можно «разрезать» кубы либо фильтровать данные. Значения

37

меток отображаются в двумерном представлении куба как заго­ ловки строк и столбцов.

Метки можно объединять в иерархии, состоящие из несколь­ ких уровней. Так, в рассматриваемом примере метки измерения Магазин (Store) объединяются в иерархию с уровнями:

АН (Мир)

Country (Страна) State (Регион)

City (Город)

Store (Магазин)

По каждому уровню иерархии можно вычислить агрегатные значения, например объем продаж для Франции (уровень Country), для Тамбовской области (уровень State) или для мага­ зина «Южный мост» в Саратове по ул. им. Кутякова, 41 (уровень

Store).

Пользователь может устанавливать в одном измерении не­ сколько иерархий, например, для товаров: {Товары, Продукты питания, Детские продукты питания, Соки, Сок яблочный} и {То­ вары, Продукты питания. Продукты производства компании «Вимм-Билль-Данн», Детские продукты питания. Соки, Сок яблоч­ ный}. Разумеется, второй иерархией надо воспользоваться, ког­ да осуществляется сравнительный анализ продаж товаров раз­ личных производителей.

Наиболее простые OLAP-продукты - средства многомерно­ го представления данных, или OLAP-клиенты (например, «Pivot Tables» в Excel 2000 фирмы Microsoft, «ProClarity» фирмы Knosys). Значительно большими возможностями обладают многомерные серверные СУБД (например, «Oracle Express Server») и OLAP-cep- веры (например, «Microsoft OLAP Services»).

В России разработкой технологий OLAP занимаются несколь­ ко компаний. Наиболее известный программный продукт - ана­ литическая платформа Контур фирмы «InterSoft Lab» [30]. Все большую известность приобретает модуль Галактика Zoom сис­ темы «Галактика» [38], о котором будем подробнее говорить в разд. 3.2. Отметим, что эти программные продукты получили международное признание и благодаря привлекательному соче­ танию цена/качество заняли свою нишу на западном рынке OLAP- продуктов.

38

Наличие в ERP-системе «встроенной OLAP-аналитики» ста­ нет в ближайшие годы важным конкурентным преимуществом ИКИС.

Технологии интеллектуальной обработки данных (ИАД)

В [23] дается следующее определение: ИАД - это процесс под­ держки принятия решений, основанный на поиске в данных скры­ тых закономерностей (шаблонов информации). Большинство методов ИАД было первоначально разработано в рамках тео­ рии искусственного интеллекта (ИИ) в 70-80-х гг. XX в., но полу­ чило распространение только в последние годы, когда проблема обработки быстро растущих объемов корпоративных данных потребовала их использования в качестве надстройки над храни­ лищами данных.

«Сырьем» для ИАД могут быть плоские таблицы реляцион­ ных СУБД. Именно с них и начиналась история ИАД. Во многих случаях более эффективным является применение ИАД к данным, полученным после обработки с помощью OLAP-технологий.

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

1. Классификация - позволяет выявить признаки, характери­ зующие однотипные группы объектов (классы), для того чтобы по известным значениям этих характеристик можно было отнес­ ти новый объект к тому или иному классу. Предполагается, что характеристики классов заранее (до анализа) известны. В каче­ стве методов решения задачи классификации применяют алго­ ритм ближайшего соседа (Nearest Neighbor), индукцию деревьев решений, «обучаемые учителем» нейронные сети [10, 23, 24].

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

39