Влияние внедрения СППР на управление предприятием

Влияние внедрения СППР на управление предприятием состоит в следующем.

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

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

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

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

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

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

– часто устанавливаются критерии, которые напрямую не связаны с успехом предприятия;

– общие цели ставятся (если это имеет место) на крайне ограниченную временную перспективу;

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

– сферы компетенций и ответственности за решение задач распределяются нечетко.

СТРУКТУРА СППР

В состав СППР входят следующие компоненты (рис. 2): источники данных, модель данных, база моделей и программная подсистема, которая состоит из системы управления базой данных (СУБД), системы управления базой моделей (СУБМ) и системы управления интерфейсом между пользователем и компьютером.

Источники данных

Рассмотрим источники данных и их осо­бенности.

 

Математических

 

 

 

Рис. 2. Структура СППР

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

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

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

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

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

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

Модель данных

Модель данных современных СППР строится на основе пяти классов данных:

- источников данных;

- хранилища данных (в узком смысле);

- оперативного склада данных;

- витрины данных;

- метаданных.

Хранилище данных

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

Определение понятию «хранилище данных» первым дал Уильям Инмон: «предметно-ориентированная, интегрированная, неразрушаемая совокупность данных, предназначенная для поддержки принятия управленческих решений».

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

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

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

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

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

 

Хранилище на самом верхнем уровне состоит, как правило, из трех подсистем:

- подсистемы загрузки данных;

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

- подсистемы администрирования хранилища.

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

Каждый источник данных требует разработки собственного загрузочного модуля. Каждый модуль должен решать два класса задач:

- начальной загрузки ретроспективных данных;

- регламентного пополнения хранилища данными из источников.

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

Подсистема обработки запросов и представления данных – ПО, которое обеспечивает извлечение данных, их аналитическую обработку и представление конечным пользователям. Как правило, можно выделить три типа этого ПО:

1) программное обеспечение регламентированной отчетности, которое характеризуется заранее предопределенными запросами данных и их представлениями бизнес-пользователям. От данного ПО не требуется быстрого времени реакции. Из соображений стоимости эффективности для его реализации в наибольшей степени подходит технология ROLAP;

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

3) программное обеспечение добычи знаний, которое реализует сложные статистические алгоритмы и алгоритмы искусственного интеллекта, предназначенные для поиска скрытых в данных закономерностей, представления этих закономерностей, представления этих закономерностей в виде моделей и многовариантного прогнозирования по ним развития ситуаций по схеме «Что если …?».

Подсистема администрирования хранилища – ПО, связанное с поддерживанием системы и обеспечением ее устойчивой работы и расширения. Можно выделить, по крайней мере, четыре класса задач, расширение которых должна обеспечивать данная подсистема:

1) администрирование данных, которое включает в себя регулярное пополнение данных из источников, если необходимо; ручной ввод, сверку и корректировку данных в оперативном складе. Администрирование данных ведется, как правило, бизнес-пользователями, а ответственность распределяется по предметно-ориентированным сегментам;

2) администрирование хранилища данных. В задачу администрирования хранилища входят все вопросы, связанные с поддержанием архитектуры хранилища, обеспечением его эффективной и бесперебойной работы, защитой и восстановлением данных после сбоев;

3) администрирование доступа к данным обеспечивает сопровождение профилей пользователей, разграничение доступа к конфиденциальным данным, защиту информации от несанкционированного доступа;

4) администрирование метаданных системы.

Оперативный склад данных

Оперативный склад данных (Operational Data Store – ODS) − техноло­ги­ческий элемент хранения данных в СППР, который служит буфером между транзакционными источниками данных и хранилищем. Данные, прежде чем попасть в хранилище, должны быть преобразованы в единые форматы, очищены, объединены и синхронизированы. Например, данные, необходимые для поддержки принятия решения, могут существовать в транзакционной системе более короткое время (часы, дни), чем период пополнения данных хранилища (дни, недели). Или семантически однородные данные поступают из транзакционных систем в разное время.
В этом случае оперативный склад данных служит аккумулятором данных, поступающих от источников, перед их загрузкой в хранилище. В отличие от хранилища данных информация в складе данных может изменяться со временем в соответствии с изменениями, происходящими в источниках данных.

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

- имеет изменяемое содержимое,

- содержит только детальные данные,

- содержит текущие значения данных.

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

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

Витрины данных (Data mart)

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

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

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

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

Метаданные

Метаданные − это любые сведения о данных. Метаданные имеют немаловажное значение в построении СППР. Одновременно – это один из наиболее сложных и недостаточно практически проработанных объектов. В общем случае можно выделить, по крайней мере, три аспекта метаданных, которые должны присутствовать в системе.

1. С точки зрения пользователей:

- метаданные для бизнес-аналитиков;

- метаданные для администраторов;

- метаданные для разработчиков.

2. С точки зрения предметных областей:

- структуры данных хранилища;

- модели бизнес-процессов;

- описания пользователей;

- технологические и пр.

3. С точки зрения функциональности системы:

- метаданные о процессах трансформации;

- метаданные по администрированию системы;

- метаданные о приложениях;

- метаданные о представлении данных пользователям.

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

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

База моделей

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

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

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

По цели использования могут быть:

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

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

По способу оценки модели подразделяются:

- на детерминистские, использующие оценку переменных одним числом при конкретных значениях исходных данных;

- стохастические, оценивающие переменные несколькими параметрами, так как исходные данные заданы вероятностными характеристи-ками.

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

По области возможных приложений различают следующие виды моделей:

- специа­лизированные – предназначены для использования только одной системой;

- уни­версальные – для использования несколькими системами.

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

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

Стратегические модели используются на высших уровнях управления для установления целей организации, объемов ресурсов, необходимых для их достижения, а также политики приобретения и использования этих ресурсов. Они могут быть также применимы при выборе вариантов размещения предприятий, прогнозировании политики конкурен­тов. Для стра­те­гических моделей характерны значительная широта охвата, множество переменных, представление данных в сжатой агрегированной форме. Часто эти данные ба­зируются на внешних источниках и могут иметь субъективный характер. Горизонт плани­рования в стратегических моделях, как правило, измеряется в годах. Эти модели (обычно детерминистские, описательные, специализированные) созданы для использования какой-то опреде­ленной фирмой.

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

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

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

Система управления базой моделей должна обладать следующими возможностями: создавать новые модели или изменять существующие, поддерживать и обновлять парамет­ры моделей, манипулировать моде-лями.

⇐ Предыдущая12345678910Следующая ⇒

Поделиться:

Воспользуйтесь поиском по сайту: