2. Классификация КИС
Корпоративные информационные системы можно также разделить на два класса: финансово-управленческие и производственные.
Финансово-управленческие системы включают подкласс малых интегрированных систем. Такие системы предназначены для ведения учета по одному или нескольким направлениям (бухгалтерия, сбыт, склад, кадры и т.д.)- Системами этой группы может воспользоваться практически любое предприятие.
Системы этого класса обычно универсальны, цикл их внедрения невелик, иногда можно воспользоваться «коробочным» вариантом, купив программу и самостоятельно установив ее на ПК.
Финансово-управленческие системы (особенно системы российских разработчиков) значительно более гибкие в адаптации к нуждам конкретного предприятия. Часто предлагаются «конструкторы», с помощью которых можно практически полностью перестроить исходную систему, самостоятельно или с помощью поставщика установив связи между таблицами БД или отдельными модулями.
Производственные системы (также называемые системами производственного управления) включают подклассы средних и крупных интегрированных систем. Они предназначены в первую очередь для управления и планирования производственного процесса. Учетные функции, хотя и глубоко проработаны, играют вспомогательную роль, и порой невозможно выделить модуль бухгалтерского учета, так как информация в бухгалтерию поступает автоматически из других модулей.
Эти системы функционально различны: в одной может быть хорошо развит производственный модуль, в другой - финансовый. Сравнительный анализ систем такого уровня и их применимости к конкретному случаю может вылиться в значительную работу. А для внедрения системы нужна целая команда из финансовых, управленческих и технических экспертов. Производственные системы значительно более сложны в установке (цикл внедрения может занимать от 6 - 9 месяцев до полутора лет и более). Это обусловлено тем, что система покрывает потребности всего предприятия, и это требует значительных совместных усилий сотрудников предприятия и поставщиков программ.
Производственные системы часто ориентированы на одну или несколько отраслей и/или типов производства: серийное сборочное (электроника, машиностроение), мелкосерийное и опытное (авиация, тяжелое машиностроение), дискретное (металлургия, химия, упаковка), непрерывное (нефтедобыча, газодобыча).
Специализация отражается как в наборе функций системы, так и в существовании бизнес - моделей данного типа производства. Наличие встроенных моделей для определенного типа производства отличает производственные системы друг от друга. У каждой из них есть глубоко проработанные направления и функции, разработка которых только начинается или вообще не ведется.
Производственные системы по многим параметрам значительно более жестки, чем финансово-управленческие. Основное внимание уделяется планированию и оптимальному управлению производством. Эффект от внедрения производственных систем проявляется на верхних эшелонах управления предприятием, когда становится видна вся картина его работы, включая планирование, закупки, производство, сбыт, запасы, финансовые потоки и другие аспекты.
При увеличении сложности и широты охвата функций предприятия системой возрастают требования к технической инфраструктуре и программно-технической платформе. Все производственные системы разработаны с помощью промышленных баз данных. В большинстве случаев используются технология клиент-сервер или Internet-технологии.
Для автоматизации больших предприятий в мировой практике часто используется смешанное решение из классов крупных, средних и малых интегрированных систем. Наличие электронных интерфейсов упрощает взаимодействие между системами и позволяет избежать двойного ввода данных.
3. Преимущества внедрения корпоративных информационных систем
получение достоверной и оперативной информации о деятельности всех подразделений компании;
повышение эффективности управления компанией;
сокращение затрат рабочего времени на выполнение рабочих операций;
повышение общей результативности работы за счет более рациональной ее организации.
Самый важный вопрос. Давайте на секунду спросим себя: что даёт человеку нервная система? Конечно же, способность управлять собой, сопротивляться неблагоприятным внешним факторам и гибко реагировать на изменения окружающей среды. Если представить компанию в качестве живого организма, то КИС лучше всего подходит на роль его нервной системы, пронизывающей все органы, все частички корпоративного организма.
Повышение внутренней управляемости, гибкости и устойчивости к внешним воздействиям увеличивает эффективность компании, её конкурентоспособность, а, в конечном счёте - прибыльность. Вследствие внедрения КИС увеличиваются объёмы продаж, снижается себестоимость, уменьшаются складские запасы, сокращаются сроки выполнения заказов, улучшается взаимодействие с поставщиками. Но, несмотря на привлекательность приведённых утверждений, вопрос об окупаемости инвестиций в КИС не теряет свою актуальность. Соотношение выгоды от использования системы и ее стоимости является одним из наиболее важных факторов, оказывающих влияние на решение "покупать или не покупать". Любой инвестиционный проект, а внедрение КИС, несомненно, нужно рассматривать как инвестиционный проект, представляет собой своего рода "покупку" и, соответственно, требует оценки его стоимости и ожидаемой выгоды.
Прямую окупаемость КИС посчитать непросто, поскольку в результате внедрения оптимизируется внутренняя структура компании, снижаются трудноизмеримые транзакционные издержки. Сложно определить, например, в какой степени увеличение доходов компании явилось следствием работы КИС (читай - программной системы), а в какой - результатом настройки бизнес-процессов, то есть плодом управленческих технологий. Однако в некоторых аспектах деятельности компании оценка вполне реальна. В первую очередь это касается логистики, где внедрение КИС приводит к оптимизации материальных потоков и к снижению потребности в оборотных средствах. Постановка на базе КИС системы финансового контроллинга приводит к снижению накладных затрат компании, ликвидации убыточных подразделений и исключению из ассортимента нерентабельных продуктов.
Совсем трудно оценить эффект от ликвидации хаоса. Для того чтобы это сделать, нужно чётко представлять масштабы хаоса, что в силу самой природы беспорядка невозможно. Действительно, можете ли Вы сказать, сколько денег Ваша компания не зарабатывает (читай - теряет) из-за перекосов в ассортименте, или, скажем, из-за срыва сроков исполнения заказов? Какие ресурсы компании оказываются выведенными из оборота вследствие "посмертного" учёта и нестыковки данных в бухгалтерии, на складе и в цехах? А как оценить объём воровства и разбазаривания ресурсов?
В настоящее время для оценки эффективности IT-проектов применяется метод инвестиционного анализа Cost Benefit Analysis (CBA) Метод назван так, поскольку в основе лежит оценка и сравнение выгод от осуществления проекта, с затратами на его реализацию.
Глобальная цель внедрения КИС - повышение эффективности компании. Каждая компания определяет ключевые сферы, влияющие на ее эффективность, так называемые "критические факторы успеха" (Critical Success Factor -- CSF). Повышение эффективности происходит за счет реализации задач в каждой из ключевых областей. Поэтому в основе СВА лежат именно бизнес-цели компании, определенные на этапе стратегического планирования.
Но достигнуть цели можно несколькими путями, поэтому второй краеугольный камень СВА - сравнение альтернативных вариантов. При этом одним из возможных является вариант "без КИС", т. е. рассматривается развитие во времени текущей ситуации без внесения в нее каких-либо изменений. Сравнение альтернативных вариантов производится на основании измерения приносимых ими выгод и требуемых для этого затрат. Учитываются как количественные, так и качественные показатели. Анализу качественных показателей в последнее время уделяется особое внимание. Помимо соотношения выгод и затрат, альтернативные варианты также отличаются степенью риска и факторами, которые эти риски определяют. Поэтому анализ влияния таких факторов на соотношение выгод и затрат является еще одной сферой внимания СВА. Это о методах оценки конкретного случая.
Если же говорить о статистических данных, характеризующих эффективность внедрения КИС, могу привести следующие цифры:
- Снижение транспортно-заготовительных расходов на 60%;
- Сокращение производственного цикла по заказным изделиям на 50%;
- Сокращение количества задержек с отгрузкой готовой продукции на 45%;
- Уменьшение уровня неснижаемых остатков на складах на 40%;
- Снижение производственного брака на 35%;
- Уменьшение административно-управленческих расходов на 30%;
- Сокращение производственного цикла по базовым изделиям на 30%;
- Уменьшение складских площадей на 25%;
- Увеличение оборачиваемости средств в расчётах на 30%;
- Увеличение оборачиваемости ТМЗ на 65%;
- Увеличение количества поставок точно в срок на 80%.
Информационное хранилище и технологии анализа данных как основа информационно-аналитической системы
1. Пространственная интерпретация данных
Программные инструментальные средства, обеспечивающие автоматизацию аналитических работ в целях поддержки принятия решений, в литературе получили два распространенных названия: ОLАР - системы и информационные Хранилища.
Как правило, все инструментальные средства, предназначенные для автоматизации аналитических работ, приспособлены для обработки многомерных массивов информации, для хранения которых используются многомерные базы данных.
Информационное пространство, отображающее функционирование объекта, многомерно. Естественно стремление аналитика и ЛПР к тому, чтобы иметь дело с моделью данных в наиболее естественном виде. Это обстоятельство привело к тому, что с помощью современных программно-технических средств, имеющих
широкие возможности интерпретации данных, были созданы оответствующие многомерные модели.
Многомерная модель данных представляет исследуемый объект в виде многомерного куба, чаще используют трехмерную модель.
По осям или граням куба откладываются измерения или реквизиты - признаки. Реквизиты - основания являются наполнением ячеек куба.
Многомерное представление при описании структур данных
Основными понятиями, с которыми оперирует пользователь и проектировщик в многомерной модели данных, являются:
• измерение (Dimension);
• ячейка (Cell). Иногда вместо термина "Ячейка" используется
термин "Показатель" (Measure).
Измерение - это множество однотипных данных, образующих
одну из граней гиперкуба. Например - Дни, Месяцы, Кварталы, Годы - это наиболее часто используемые в анализе временные Измерения.
Примерами географических измерений являются: Города, Районы, Регионы, Страны и т.д.
В многомерной модели данных Измерения играют роль индексов, используемых для идентификации конкретных значений (Показателей), находящихся в Ячейках гиперкуба.
В свою очередь, Показатель - это поле (обычно цифровое), значения которого однозначно определяются фиксированным набором Измерений. В зависимости от того, как формируются его значения, Показатель может быть определен, как:
• Переменная (Variable) - значения таких Показателей один раз вводятся из какого-либо внешнего источника или формируются программно и затем в явном виде хранятся в многомерной базе данных (МБД);
• Формула (Formula) - значения таких Показателей вычисляются по некоторой заранее специфицированной формуле. То есть для Показателя, имеющего тип Формула, в БД хранится не его значения, а формула, по которой эти значения могут быть вычислены.
Заметим, что это различие существует только на этапе проектирования и полностью скрыто от конечных пользователей.
Заметим, что, в отличие от Измерений, не все значения Показателей должны иметь и имеют реальные значения.
Гиперкубические и поликубические модели данных
В различных МСУБД используются два основных варианта организации данных:
• Гиперкубическая модель;
• Поликубическая модель.
Методы извлечения информации из кубов данных
Для извлечения информации из кубов данных используются различные операции манипулирования Измерениями:
1) Формирование "Среза".
Пользователя редко интересуют все потенциально возможные комбинации значений Измерений. Более того, он практически никогда не работает одновременно сразу со всем гиперкубом данных.
Подмножество гиперкуба, получившееся в результате фиксации
значения одного или более Измерений, называется Срезом (Slice).
2) Операция "Вращение".
Изменение порядка представления (визуализации) Измерений (обычно применяется при двухмерном представлении данных) называется Вращением (Rotate). Эта операция обеспечивает возможность визуализации данных в форме, наиболее комфортной для их восприятия. Например, если менеджер первоначально вывел отчет, в котором Модели автомобилей были перечислены по оси X, а Менеджеры по оси Y, он может решить, что такое представление мало наглядно, и поменять местами координаты (выполнить Вращение на 90 градусов).
3) Отношения и Иерархические Отношения.
В нашем примере значения Показателей определяются только тремя измерениями. На самом деле их может быть гораздо больше и между их значениями обычно существуют множество различных Отношений (Relation) типа "один ко многим".
Заметим, что для Измерений, имеющих тип Время (таких как День, Месяц, Квартал, Год), все Отношения устанавливаются автоматически, и их не требуется описывать.
В свою очередь, множество Отношений может иметь иерархическую структуру - Иерархические Отношения (Hierarchical Relationships). И часто более удобно не объявлять новые Измерения и затем устанавливать между ними множество Отношений, а использовать механизм Иерархических Отношений. В этом случае все потенциально
возможные значения из различных Измерений объединяются в одно
множество. Например, мы можем добавить к множеству значений
Измерения Менеджер ("Петров", "Сидоров", "Иванов", "Смирнов"), значения Измерения Подразделение ("Филиал 1", "Филиал 2", "Филиал 3") и Измерения Регион ("Восток", "Запад") и затем определить между этими значениями Отношение Иерархии.
4) Операция Агрегации.
С точки зрения пользователя, Подразделение, Регион, Фирма, Страна являются точно такими же Измерениями, как и Менеджер. Но каждое из них соответствует новому, более высокому уровню агрегации значений Показателя Объем продаж. В процессе анализа пользователь не только работает с различными Срезами данных и выполняет их Вращение, но и переходит от детализированных данных к агрегированным, т.е. производит операцию Агрегации (Drill Up).
5) Операция Детализации.
Переход от более агрегированных к более детализированным данным называется операцией Детализации (Drill Down). Например, начав анализ на уровне Региона, пользователь может захотеть получить более точную информацию о работе конкретного Подразделения или Менеджера.
2. Понятие хранилища данных
Термин "OLAP" неразрывно связан с термином "хранилище данных" (Data Warehouse).
Приведем определение, сформулированное "отцом-основателем" хранилищ данных Биллом Инмоном: "Хранилище данных – это предметно-ориентированное, привязанное ко времени и неизменяемое собрание данных для поддержки процесса принятия управляющих решений".
Данные в хранилище попадают из оперативных систем (OLTP-систем), которые предназначены для автоматизации бизнес-процессов.
Кроме того, хранилище может пополняться за счет внешних источников, например статистических отчетов.
Зачем строить хранилища данных - ведь они содержат заведомо избыточную информацию, которая и так "живет" в базах или файлах
оперативных систем? Ответить можно кратко: анализировать данные оперативных систем напрямую невозможно или очень затруднительно.
Это объясняется различными причинами, в том числе разрозненностью данных, хранением их в форматах различных СУБД и в разных "уголках" корпоративной сети. Но даже если на предприятии все данные хранятся на центральном сервере БД (что бывает крайне редко), аналитик почти наверняка не разберется в их сложных, подчас запутанных структурах.
Таким образом, задача хранилища - предоставить "сырье" для анализа в одном месте и в простой, понятной структуре.
Есть и еще одна причина, оправдывающая появление отдельного хранилища - сложные аналитические запросы к оперативной информации тормозят текущую работу компании, надолго блокируя таблицы и захватывая ресурсы сервера.
Под хранилищем можно понимать не обязательно гигантское скопление данных - главное, чтобы оно было удобно для анализа.
Вообще говоря, для маленьких хранилищ предназначается отдельный термин - Data Marts (киоски или витрины данных).
В основе концепции Хранилищ Данных лежат две основополагающие идеи:
• Интеграция ранее разъединенных детализированных данных:
исторические архивы,
данные из традиционных СОД,
данные из внешних источников
в едином Хранилище Данных, их согласование и возможно
агрегация.
• Разделение наборов данных используемых для операционной обработки и наборов данных используемых для решения задач анализа.
Предметом концепции Хранилищ Данных являются сами данные.
То есть, её предметом являются не способы описания и отображения объектов предметной области, а собственно данные, как самостоятельный объект предметной области, порожденной в результате функционирования ранее созданных информационных систем.
Основные требования к данным в хранилищах приведены в таблице 1.
Таблица 1
Основные требования к данным в Хранилище Данных
Для правильного понимания данной концепции необходимо понимание следующих принципиальных моментов: Концепция Хранилищ Данных - это концепция подготовки данных для анализа.
• Концепция Хранилищ Данных не предопределяет архитектуру целевой аналитической системы. Она говорит о том, какие процессы должны выполняться в системе, но не о том, где конкретно и как эти процессы должны выполняться.
• Концепция Хранилищ Данных предполагает не просто единый логический взгляд на данные организации. Она предполагает реализацию единого интегрированного источника данных.
Без поддержки хронологии (наличия исторических данных) нельзя говорить о решении задач прогнозирования и анализа тенденций. Но наиболее критичными и болезненными, оказываются вопросы, связанные с согласованием данных.
Основным требованием аналитика, является даже не столько оперативность, сколько достоверность ответа. Но достоверность, в конечном счете, и определяется согласованностью. Пока не проведена работа по взаимному согласованию значений данных из различных источников, сложно говорить об их достоверности.
Реализация ИХ может быть осуществлена несколькими способами:
Централизованное хранилище данных
Такой подход означает, что при нескольких источниках информации - операционных базах данных создаётся единоецентрализованное хранилище (рис. 1).
Рис. 1. Единое централизованное хранилище
Вся поступающая в ИХ информация должна быть преобразована в принятую в данном ИХ структуру. Передача данных из операционных БД в ИХ, которая сопровождается доработкой, может быть организована по заданному временному графику и правилам доработки Распределенное хранилище данных Возможен и имеет место противоположный подход к хранению данных на основе распределения функций ИХ по местам их возникновения или группировки нескольких операционных БД вокруг локального или регионального информационного хранилища. Эти хранилища могут быть ориентированы на определённую предметную область или на регион в корпоративных структурах. Система локальных хранилищ действует в качестве распределённого хранилища (рис. 2).
Централизованное хранилище данных
Рис. 2. Распределенное хранилище данных
Не исключается и наличие центрального хранилища, но в такой структуре требования к его размерности значительно облегчаются.
Автономные витрины данных
Одним из вариантов организации централизованного хранения и представления информации является концепция витрин данных. При таком подходе информация, относящаяся к крупной предметной области – например, информационному пространству крупной корпоративной системы, имеющей несколько достаточно самостоятельных направлений деятельности, группируется по этим направлениям в специально организованных базах данных, которые называют витринами данных.
Этот подход является развитием концепции распределенного ИХ в части придания функций предметной ориентированности некоторым локальным ИХ.
Такой подход позволяет обойтись сравнительно менее ресурсоемкими аппаратными и программными средствами,обеспечивает повышение адаптируемости системы к изменяющимся условиям, расширяет доступность для внедрения. Пользователь предприятия или другого подразделения корпорации получает своё ИХ,
обслуживающее местные потребности.
Единое интегрированное хранилище и много витрин данных
Эта структура ИХ объединяет две концепции: единого интегрированного хранилища и связанных с ним и получающих из него информацию витрин данных. В таком варианте имеется крупное информационное хранилище агрегированной и подработанной информации, которое может удовлетворить потенциальные запросы по отдельным направлениям деятельности.
Здесь очевидны преимущества: данные заранее агрегируются, обеспечивается единая хронология, согласованы различные форматы, устраняются противоречивость и неоднозначность данных – информация приобретает необходимую кондицию для быстрого и достаточно полного удовлетворения необходимого множества запросов, Недостатком является необходимость применения высокопроизводительных аппаратных средств и специализированных многомерных или гибридных программных инструментальных средств.
3. Структура хранилищ данных
ИХ представляет собой базу обобщенной информации, формируемую из множества внешних и внутренних источников, на основе которой выполняются статистические группировки и интеллектуальный анализ данных.
В основе ИХ лежит понятие многомерного информационного пространства или гиперкуба, в ячейках которого хранятся анализируемые числовые показатели (например: объемы продаж,
инвестиций, оборота и др.) Измерениями (осями) гиперкуба являются признаки анализа (например: время, группа продукции, регион и др.)
При хранении признаки анализа отделяются от фактических данных.
Основными составляющими структуры хранилищ данных являются таблица фактов (fact table) и таблицы измерений (dimension tables).
Таблица фактов
Таблица фактов является основной таблицей хранилища данных.
Как правило, она содержит сведения об объектах или событиях, совокупность которых будет в дальнейшем анализироваться. Обычно говорят о четырех наиболее часто встречающихся типах фактов. К ним относятся:
• факты, связанные с транзакциями (Transaction facts). Они основаны на отдельных событиях (типичными примерами которых являются телефонный звонок или снятие денег со счета с помощью банкомата);
• факты, связанные с «моментальными снимками» (Snapshot facts). Основаны на состоянии объекта (например, банковского счета) в определенные моменты времени, например на конец дня или месяца.
Типичными примерами таких фактов являются объем продаж за день или дневная выручка;
• факты, связанные с элементами документа (Line-item facts).
Основаны на том или ином документе (например, счете за товар или услуги) и содержат подробную информацию об элементах этого документа (например, количестве, цене, проценте скидки);
• факты, связанные с событиями или состоянием объекта (Event or state facts). Представляют возникновение события без подробностей о нем (например, просто факт продажи или факт отсутствия таковой без иных подробностей).
Таблица фактов, как правило, содержит уникальный составной ключ, объединяющий первичные ключи таблиц измерений. Чаще всего это целочисленные значения либо значения типа «дата/время» — ведь таблица фактов может содержать сотни тысяч или даже миллионы записей, и хранить в ней повторяющиеся текстовые описания, какправило, невыгодно — лучше поместить их в меньшие по объему таблицы измерений. При этом как ключевые, так и некоторые неключевые поля должны соответствовать будущим измерениям OLAP-куба. Помимо этого таблица фактов содержит одно или несколько числовых полей, на основании которых в дальнейшем будут получены агрегатные данные.
В данном примере измерениям будущего куба соответствуют первые шесть полей, а агрегатным данным — последние четыре.
Отметим, что для многомерного анализа пригодны таблицы фактов, содержащие как можно более подробные данные (то есть соответствующие членам нижних уровней иерархии соответствующих измерений). В данном случае предпочтительнее взять за основу факты продажи товаров отдельным заказчикам, а не суммы продаж для разных стран — последние все равно будут вычислены OLAP-средством.
Исключение можно сделать, пожалуй, только для клиентских OLAP-средств, поскольку в силу ряда ограничений они не могут манипулировать большими объемами данных.
Отметим, что в таблице фактов нет никаких сведений о том, как группировать записи при вычислении агрегатных данных. Например, в ней есть идентификаторы продуктов или клиентов, но отсутствует информация о том, к какой категории относится данный продукт или в каком городе находится данный клиент. Эти сведения, в дальнейшем используемые для построения иерархий в измерениях куба, содержатся в таблицах измерений.
Таблицы измерений
Таблицы измерений содержат неизменяемые либо редко изменяемые данные. В подавляющем большинстве случаев эти данные представляют собой по одной записи для каждого члена нижнего уровня иерархии в измерении. Таблицы измерений также содержат как минимум одно описательное поле (обычно с именем члена измерения) и, как правило, целочисленное ключевое поле для однозначной идентификации члена измерения. Если будущее измерение, основанное
на данной таблице измерений, содержит иерархию, то таблица измерений также может содержать поля, указывающие на «родителя»
данного члена в этой иерархии. Нередко (но не всегда) таблица измерений может содержать и поля, указывающие на «прародителей», и иных «предков» в данной иерархии (это обычно характерно для сбалансированных иерархий), а также дополнительные атрибуты членов измерений, содержавшиеся в исходной оперативной базе данных (например, адреса и телефоны клиентов).
Каждая таблица измерений должна находиться в отношении «один ко многим» с таблицей фактов.
Отметим, что скорость роста таблиц измерений должна быть незначительной по сравнению со скоростью роста таблицы фактов;
например, добавление новой записи в таблицу измерений, характеризующую товары, производится только при появлении нового товара, не продававшегося ранее.
Отметим, что даже при наличии иерархических измерений с целью повышения скорости выполнения запросов к хранилищу данных нередко предпочтение отдается схеме «звезда».
Говоря об измерениях, следует упомянуть о том, что значения, могут иметь различные уровни детализации. Например, нас может интересовать суммарная стоимость заказов, сделанных клиентами в разных странах, либо суммарная стоимость заказов, сделанных иногородними клиентами или даже отдельными клиентами.
Естественно, результирующий набор агрегатных данных во втором и третьем случаях будет более детальным, чем в первом. Заметим, что возможность получения агрегатных данных с различной степенью детализации соответствует одному из требований, предъявляемых к хранилищам данных, — требованию доступности различных срезов данных для сравнения и анализа.
Существуют также иерархии, занимающие промежуточное положение между сбалансированными и несбалансированными (они обозначаются термином ragged — "неровный"). Обычно они содержат такие члены, логические "родители" которых находятся не на непосредственно вышестоящем уровне.
4. Хранилище данных предприятия
Тема Хранилищ данных имеет необычайную актуальность для современных российских предприятий городского хозяйства. Причин этому две. Во-первых, большинство средних и крупных предприятий уже прошли стадию первичной автоматизации, то есть автоматизации бухгалтеров. Во-вторых, происходит быстрое укрупнение предприятий за счет их слияний, а также развития региональной сети. Поэтому настало время автоматизации менеджеров среднего и высшего звена.
Задачи Хранилища данных
В классическом представлении под целью создания Хранилища данных понимается поддержка принятия решений, другим словами обеспечение всех менеджеров предприятия полной, достоверной, согласованной и своевременной информацией из единого источника.
Для реализации этой цели Хранилище данных должно выполнять ряд задач:
1. Консолидация данных
2. Интеграция данных
3. Агрегация данных
4. Расчеты производных показателей
5. Предоставление данных для поддержки принятия решений (DSS).
Консолидация данных
Консолидация данных – это сбор в единую базу данных из удаленных филиалов многофилиального предприятия, или предприятий, входящих в холдинг. Консолидированные данные необходимы центральному руководству, чтобы осуществлять глобальное управление бизнесом, внедрять единую политику в филиалах и осуществлять контроль над их деятельностью.
Задача консолидации осложняется тем, что часто распределенные структуры создаются путем слияния предприятий, уже имеющих некоторый уровень автоматизации, обученный определенным системам персонал. Поэтому во многих случаях в филиалах работают различные системы автоматизации. Единственным способом консолидации данных в этих условиях является применение разрозненных программ сбора показателей отчетности или единого Хранилища данных.
Интеграция данных
Интеграция данных – это объединение данных, которые изначально вводятся в разные системы. Сами эти системы могут располагаться в одной локальной сети, но иметь различные платформы и внутреннюю архитектуру (рис. 10). Такая ситуация практически неизбежна во всех предприятиях занимающихся сложным бизнесом. Как правило, один единственный поставщик не может создать систему, в которой одинаково хорошо решены вопросы бухгалтерского учета и автоматизации производственного цикла, управления кадрами и документооборота и так далее.
Кроме того, существуют задачи, например, маркетингового анализа, привлечения клиентов, анализа конкурентной среды, которые по своей природе требуют получения (покупки) информации от разных поставщиков. Эта информация поставляется в виде разнообразных баз данных или электронных таблиц и требует загрузки в общую базу данных для совместного анализа.
Агрегация данных
Агрегация данных – это вычисление обобщенных показателей для поддержки стратегического или тактического управления из детальных данных. Например, все записи о продажах двухсот тысяч наименований товаров тысяче оптовых покупателям за каждый день года преобразуются в данные о продажах десяти категорий товаров пяти категориям покупателей в разрезе месяцев и кварталов года и регионов (рис. 11). Эти данные используются впоследствии менеджерами для принятия решений об изменениях направлений бизнеса, расширении рынка, анализа сезонных колебаний спроса на товары разных категорий.
Предварительный расчет агрегированных показателей применяется для того, чтобы руководитель получал ответы на подобные запросы предельно быстро. В то же время в хранилище собираются максимально детальные данные, что позволяет строить отчеты в произвольных аналитических разрезах, вычисляя агрегаты по мере возникновения в них потребности.
Расчеты производных показателей
В управленческой практике собранные из подразделений первичные оперативные данные используются для расчета сложных финансовых и оперативных показателей, таких как прибыль на капитал, средневзвешенные цены, ликвидность, доходность клиента и т.д.
Хранилище данных предоставляет формульный язык для настройки алгоритмов расчета показателей и специальные механизмы быстрого выполнения расчетов над огромными массивами первичной информации.
Предоставление данных для поддержки принятия решений (DSS)
Как уже указывалось выше, изначально концепция Хранилища данных была разработана с единственной целью – для информационной поддержки принятия решений. Поэтому предполагалось, что данные Хранилища должны быть неизменяемы. Пользовательский интерфейс обеспечивает всего две основные функции – выпуск отчетов для печати и интерактивный анализ данных. В связи с этим в качестве front-end можно применять универсальные системы выполнения запросов, анализа данных и выпуска отчетов. Эти инструменты позволяют свести к минимуму затраты на разработку отчетов, во многих случаях сводя создание новых форм отчетов к настройке, выполняемой самим пользователем.
Системы поддержки принятия решений
1. Понятие и назначение систем поддержки принятия решений
Современные системы поддержки принятия решения (СППР) представляют собой системы, максимально приспособленные к решению задач повседневной управленческой деятельности, являются инструментом, призванным оказать помощь лицам, принимающим решения (ЛПР). С помощью СППР может производится выбор решений некоторых неструктурированных и слабоструктурированных задач, в том числе и многокритериальных.
СППР, как правило, являются результатом мультидисциплинарного исследования, включающего теории баз данных, искусственного интеллекта, интерактивных компьютерных систем, методов имитационного моделирования.
Ранние определения СППР (в начале 70-х годов прошлого века) отражали следующие три момента: (1) возможность оперировать с неструктурированными или слабоструктурированными задачами, в отличие от задач, с которыми имеет дело исследование операций; (2) интерактивные автоматизированные (то есть реализованные на базе компьютера) системы; (3) разделение данных и моделей. Приведем определения СППР: СППР — совокупность процедур по обработке данных и суждений, помогающих руководителю в принятии решений, основанная на использовании моделей.
СППР — это интерактивные автоматизированные системы, помогающие лицу, принимающему решения, использовать данные и модели для решения слабоструктуризированных проблем.
СППР — это система, которая обеспечивает пользователям доступ к данным и/или моделям, так что они могут принимать лучшие решения.
Последнее определение не отражает участия компьютера в создании СППР, вопросы возможности включения нормативных моделей в состав СППР и др.
В настоящее время нет общепринятого определения СППР, поскольку конструкция СППР существенно зависит от вида задач, для решения которых она разрабатывается, от доступных данных, информации и знаний, а также от пользователей системы. Можно привести, тем не менее, некоторые элементы и характеристики, общепризнанные, как части СППР:
СППР — в большинстве случаев — это интерактивная автоматизированная система, которая помогает пользователю (ЛПР) использовать данные и модели для идентификации и решения задач и принятия решений. Система должна обладать возможностью работать с интерактивными запросами с достаточно простым для изучения языком запросов.
Согласно Turban, СППР обладает следующими четырьмя основными характеристиками:
СППР использует и данные, и модели;
СППР предназначены для помощи менеджерам в принятии решений для слабоструктурированных и неструктурированных задач;
Они поддерживают, а не заменяют, выработку решений менеджерами;
Цель СППР — улучшение эффективности решений.
2. Классификации СППР
Для СППР отсутствует не только единое общепринятое определение, но и исчерпывающая классификация. Разные авторы предлагают разные классификации.
На уровне пользователя Haettenschwiler (1999) делит СППР на пассивные, активные и кооперативные СППР. Пассивной СППР называется система, которая помогает процессу принятия решения, но не может вынести предложение, какое решение принять. Активная СППР может сделать предложение, какое решение следует выбрать. Кооперативная позволяет ЛПР изменять, пополнять или улучшать решения, предлагаемые системой, посылая затем эти изменения в систему для проверки. Система изменяет, пополняет или улучшает эти решения и посылает их опять пользователю. Процесс продолжается до получения согласованного решения.
На концептуальном уровне Power (2003) отличает СППР, управляемые сообщениями (Communication-Driven DSS), СППР, управляемые данными (Data-Driven DSS), СППР, управляемые документами (Document-Driven DSS), СППР, управляемые знаниями (Knowledge-Driven DSS) и СППР, управляемые моделями (Model-Driven DSS). СППР, управляемые моделями, характеризуются в основном доступ и манипуляции с математическими моделями (статистическими, финансовыми, оптимизационными, имитационными). Отметим, что некоторые OLAP-системы, позволяющие осуществлять сложный анализ данных, могут быть отнесены к гибридным СППР, которые обеспечивают моделирование, поиск и обработку данных.
Управляемая сообщениями (Communication-Driven DSS) (ранее групповая СППР — GDSS) СППР поддерживает группу пользователей, работающих над выполнением общей задачи.
СППР, управляемые данными (Data-Driven DSS) или СППР, ориентированные на работу с данными (Data-oriented DSS) в основном ориентируются на доступ и манипуляции с данными. СППР, управляемые документами (Document-Driven DSS), управляют, осуществляют поиск и манипулируют неструктурированной информацией, заданной в различных форматах. Наконец, СППР, управляемые знаниями (Knowledge-Driven DSS) обеспечивают решение задач в виде фактов, правил, процедур.
На техническом уровне Power (1997) различает СППР всего предприятия и настольную СППР. СППР всего предприятия подключена к большим хранилищам информации и обслуживает многих менеджеров предприятия. Настольная СППР — это малая система, обслуживающая лишь один компьютер пользователя. Существуют и другие классификации (Alter [3], Holsapple и Whinston, Golden, Hevner и Power). Отметим лишь, что превосходная для своего времени классификация Alter‘a, которая разбивала все СППР на 7 классов, в настоящее время несколько устарела.
В зависимости от данных, с которыми эти системы работают, СППР условно можно разделить на оперативные и стратегические. Оперативные СППР предназначены для немедленного реагирования на изменения текущей ситуации в управлении финансово-хозяйственными процессами компании. Стратегические СППР ориентированы на анализ значительных объемов разнородной информации, собираемых из различных источников. Важнейшей целью этих СППР является поиск наиболее рациональных вариантов развития бизнеса компании с учетом влияния различных факторов, таких как конъюнктура целевых для компании рынков, изменения финансовых рынков и рынков капиталов, изменения в законодательстве и др. СППР первого типа получили название Информационных Систем Руководства (Executive Information Systems, ИСР). По сути, они представляют собой конечные наборы отчетов, построенные на основании данных из транзакционной информационной системы предприятия, в идеале адекватно отражающей в режиме реального времени основные аспекты производственной и финансовой деятельности. Для ИСР характерны следующие основные черты:
отчеты, как правило, базируются на стандартных для организации запросах; число последних относительно невелико;
ИСР представляет отчеты в максимально удобном виде, включающем, наряду с таблицами, деловую графику, мультимедийные возможности и т. п.;
как правило, ИСР ориентированы на конкретный вертикальный рынок, например финансы, маркетинг, управление ресурсами.
СППР второго типа предполагают достаточно глубокую проработку данных, специально преобразованных так, чтобы их было удобно использовать в ходе процесса принятия решений. Неотъемлемым компонентом СППР этого уровня являются правила принятия решений, которые на основе агрегированных данных дают возможность менеджерам компании обосновывать свои решения, использовать факторы устойчивого роста бизнеса компании и снижать риски. СППР второго типа в последнее время активно развиваются. Технологии этого типа строятся на принципах многомерного представления и анализа данных (OLAP).
При создании СППР можно использовать Web-технологии. В настоящее время СППР на основе Web-технологий для ряда компаний являются синонимами СППР предприятия.
Архитектура СППР представляется разными авторами по-разному. Приведем пример. Marakas (1999) предложил обобщенную архитектуру, состоящую из 5 различных частей: (a) система управления данными (the data management system — DBMS), (b) система управления моделями (the model management system — MBMS), (c) машина знаний (the knowledge engine (KE)), (d) интерфейс пользователя (the user interface) и (e) пользователи (the user(s)).
Стадии принятия решений могут следовать и в другой последовательности.
СППР предназначены, чтобы помогать проектировать, оценивать альтернативы и контролировать процесс реализации.
СППР помогают находить ответы на следующие типичные вопросы:
Анализ примеров (case analysis) - оценка значений выходных величин для заданного набора значений входных переменных.
Параметрический анализ («Что, если... ?»)- оценка поведения выходных величин при изменении значений входных переменных.
Анализ чувствительности - исследование поведения результирующих переменных в зависимости от изменения значений одной или нескольких входных переменных.
Анализ возможностей - нахождение значений входной переменной, которые обеспечивают желаемый результат (известен также под названием «поиск целевых решений», «анализ значений целей», «управление по целям»).
Анализ влияния - выявление для выбранной результирующей переменной всех входных переменных, влияющих на ее значение, и оценка величины изменения результирующей переменной при заданном изменении входной переменной, скажем, на 1 %.
Анализ данных - прямой ввод в модель ранее имевшихся данных и манипулирование ими при прогнозировании.
Сравнение и агрегирование - сравнение результатов двух или более прогнозов, сделанных при различных входных предположениях, или сравнение предсказанных результатов с действительными, или объединение результатов, полученных при различных прогнозах или для разных моделей.
Командные последовательности (sequences) - возможность записывать, исполнять, сохранять для последующего использования регулярно выполняемые серии команд и сообщений.
Анализ риска - оценка изменения выходных переменных при случайных изменениях входных величин.
Оптимизация - поиск значений управляемых входных переменных, обеспечивающих наилучшее значение одной или нескольких результирующих переменных.
3. Структура СППР
В состав системы поддержки принятия решений входят три главных компонента: база данных, база моделей и программная подсистема, которая состоит из трех подсистем: системы управления базой данных (СУБД), системы управления базой моделей (СУБМ) и системы управления интерфейсом между пользователем и компьютером. Структура СППР, а также функции составляющих ее блоков, определяющих основные технологические операции, представлены на рисунке 1.
Рис. 1 Основные компоненты информационной технологии поддержки принятия решений
Любая система поддержки принятия решений содержит подсистему данных, которая состоит из двух основных частей: БД и системы управления базой данных (СУБД). БД играет в информационной технологии поддержки принятия решений важную роль. Данные могут использоваться непосредственно пользователем для расчетов при помощи математических моделей. СППР получают информацию из управленческих и операционных ИС.
Источники данных и их особенности:
|
