лучшие книги по экономике
Главная страница

Главная

Замовити роботу

Последние поступления

Форум

Создай свою тему

Карта сайта

Обратная связь

Статьи партнёров


Замовити роботу
Книги по
алфавиту

Б
В
Г
Д
Е
Ж
З
И
К
Л
М
Н
О

системи підтримки прийняття рішень

Страницы [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ 12 ] [ 13 ] [ 14 ] [ 15 ]
[ 16 ] [ 17 ] [ 18 ] [ 19 ] [ 20 ] [ 21 ] [ 22 ] [ 23 ] [ 24 ] [ 25 ] [ 26 ] [ 27 ] [ 28 ] [ 29 ] [ 30 ] [ 31 ] [ 32 ]
[ 33 ] [ 34 ] [ 35 ] [ 36 ] [ 37 ] [ 38 ] [ 39 ] [ 40 ] [ 41 ] [ 42 ] [ 43 ] [ 44 ] [ 45 ] [ 46 ] [ 47 ] [ 48 ] [ 49 ] [ 50 ]

 

5.4.3.Системи керування базою моделей у СППР
Керування моделями в СППР
Система керування моделями є одним із компонентів архітектури універсальної СППР. Функціями цієї системи є класифікація, організація і доступ до моделей, тобто ці функції аналогічні функціям системи керування базами даних. На рис. 5.7 наведено схему керування моделями, яка містить важливі елемен­ти: базу моделей, систему керування базою моделей і керування діалогом як основну частину користувацького інтерфейсу.

Рис. 5.7. Схема керування моделями в СППР
СППР безпосередньо забезпечує ОПР багатьма моделями. Через систему керування базою моделей (СКБМ) СППР забезпечує легкий доступ до моделей та допомагає їх використовувати. Очевидно, що база моделей є важливим аспектом цієї системи. Вона містить різноманітні статистичні, фінансові та управлінські моделі, які є важливими для розв’язування специфічних проблем, що зустрічаються.
Основними функціями СКБМ є: створення нових моделей; каталогізація й оцінювання широкого діапазону моделей; поєднання компонентів моделей у базі моделей; виконання ряду загальних функцій управління.
Система керування базою моделей в СППР надає спектр можливостей користувачу, зокрема, забезпечує легкий доступ до моделей, допомагає усвідомлювати результати моделювання, забезпечує інтегрування моделей, дає змогу досліджувати чутливість рішень, надає інструментальні засоби керування моделями, уможливлює застосування зовнішніх моделей.
Програмне забезпечення СКБМ
Програмне забезпечення для СКБМ розроблене значно менше, ніж для СКБД чи користувацького інтерфейсу; наявним СКБМ притаманне розмаїття, а комерційні пакети СППР нерідко містять основні комбінації аналітичних методів розв’язування, статистичних пакетів та інших засобів моделювання. Повний комплект усіх сімей і підсімей методів моделювання зустрічається рідко, а частіше вони вмонтовані в систему процедури і засоби користувацького інтерфейсу. СКБМ для систематизованого формування, аналізу та інтерпретації моделей часто бувають спрощеними і обмеженими за своєю суттю. Перспективним напрямом створення ефективних СКБМ є структурне моделювання. Розроб­лено також кілька мов програмування досить високого рівня,
спеціально пристосованих для створення елементів СКБМ для СППР.
Значна частина програмного забезпечення СКБМ має формат електронних таблиць. Зокрема, пакет Excel надає користувачеві можливість доступу до широкого діапазону математичних функцій та різних типів графіків; шляхом оброблення стовпців як послідовних часових інтервалів можна також моделювати систему змінних у часі. Цей пакет забезпечує розв’язання задач за допомогою аналізу рішень та інструментів динамічного програмування.
Зв’язок між користувацьким інтерфейсом і СКБМ
Важлива роль у системі керування моделями відводиться зв’язку користувацького інтерфейсу із СКБМ. Зокрема, проводяться роботи зі створення графічного інтерфейсу з вмонтованими засобами взаємодії на базі природної мови з метою надання користувачам змоги вводити команди і запитання зрозумілою для них мовою. При цьому дуже важливо, аби система мала здатність автоматично вибирати найпридатніший модуль розв’я­зування задачі на підставі параметрів вхідного запиту і виду математичної моделі (наприклад, залежно від того, чи є поставлена задача оптимізаційною, чи ні). Це означає, що користувачеві потрібно вводити лише характеристики задачі або предметної галузі, а СКБМ автоматично та інтелектуально (тобто сама розпізнає задачу) здійснить вибір найпридатнішого методу чи інструменту. Також варто звернути увагу на роботи,
в яких механізм інтерактивної взаємодії між користувачем і СКБМ розглядається з погляду об’єднання трьох факторів: мов структуру­вання даних, запитів моделей і процесорів запитів природною мовою, зокрема, з орієнтацією на ключові слова процесора запитів для СКБМ, який інтегрує деякі характеристики цих компонентів. Прикладом мови запитів для структурованих моделей може бути система, в якій три операції — виконання, оптимізація й аналіз чутливості — утворюють критерій відносної повноти операцій.
Система на основі меню чи структурованої процедурної мови є нині найдоцільнішим варіантом у галузі інтерфейсів природною мовою (з урахуванням технологічних обмежень щодо природних мов у контексті комп’ютерного оброблення інформації). У варіанті оброблення структурованої природної мови запит вводиться в довільній формі, після чого він фільтрується з метою одержання низки ключових слів. Система має певні правила, згідно з якими проводиться опитування користувача, коли здобута послідовність ключових слів не збігається із записаним у пам’яті зразком. Як і в будь-якій іншій системі, у межах природної мови труднощі за створення такого інтерфейсу полягають у тому, аби забезпечити здатність системи правильно формулювати наміри користувачів і у відповідний спосіб реагувати на них.
5.4.4. Структурне моделювання
Загальна концепція структурного моделювання
У галузі архітектур і концепцій систем керування базами моделей останнім часом був досягнутий певний прогрес завдяки розвитку нового напряму— структурного моделювання, яке може служити формальною математичною основою і обчислювальним середовищем для складання, подання і маніпулювання множиною моделей. Концепцію структурного моделювання запропонував 1987 року Артур Джеоффріон (Arthur M. Geoffrion), як відповідну реакцію на серйозні недоліки систем моделювання, доступних у 80-х роках ХХ ст. (mailto:[email protected]
edu). Цей підхід ґрунтується на ідеї, що будь-яка модель може бути розглянута, як сукупність чітких елементів, кожний з яких має визначення, яке, або є примітивним, або основаним на визначенні інших елементів моделі.
Структурне моделювання може бути розглянуте як використання єрархічно організованого, розділеного і атрибутивного (attributed), направленого (без циклів) графа для відображення прикладу моделі або класу прикладів моделей. Кожна модель визначена з погляду впорядкованого ациклічного графа елементів (вузлів) і «викликів» (дуг). Головний вузол кожної дуги є «викликаючим елементом»,
а хвостовий — елементом, що «викликається».
Структурне моделювання може бути також розглянуте як система визначень для моделювання, що ґрунтується на таких п’яти засадних принципах:
1. Кореляція. Кожна взаємозалежність між елементами моделі має бути точно визначеною, щоб уникнути визначення за допомогою інших елементів.
2. Ациклічність. Граф моделі має бути ациклічним, щоб жоден елемент не міг бути безпосередньо або опосередковано визначений самим собою. Якщо в групі елементів існує циклічна залежність у визначеннях, то елемент не може бути визначений, оскільки буде існувати нескінченне поле для визначень.
3. Класифікація. Елементи моделі або вузли графа поділяють на п’ять типів, які називаються: первинні об’єкти, складові об’єкти, атрибути/змінні, функції і тести. Це забезпечує формальну семантичну основу для моделі і для полегшення програм-ної реалізації системи.
4. Групування. Елементи, які мають подібні визначення, об’єднуються в групи. Групування робить моделі прозорими і простими для керування. Це також скорочує розмірність моделі, оскільки кількість груп, які об’єднують у собі подібні елементи, не залежить від кількості самих елементів.
5. Єрархія. Групи єрархічно організовані.
У центрі концепції структурного моделювання знаходиться система визначень усіх елементів, які складають сутність поняття «модель». У відповідності з Джеоффріоном схема структурного моделювання базується на єрархічній побудові й має три рівні — елементну структуру, родову структуру і модульну структуру (elemental structure, generic structure, modular structure).
В елементній структурі модель розглядається як ряд дискретних елементів (елементів примітивних об’єктів), що має бути зображений у вигляді направленого графа елементів (вузлів) і «викликів» (дуг). Метою елементної структури є охоплення всіх детальних елементів у специфічному прикладі моделі. Елементна структура моделі складається з окремих елементів з точною взаємозалежністю їх визначень.
Елементна структура будується на основі п’яти типів елементів:
1. Примітивний об’єкт (РЕ) використовується для відображення сутностей у проблемній сфері (або моделі) і він не має асоційованих значень.
2. Складовий об’єкт (СЕ) використовується для відображення визначення, яке посилається на один або більше вже певних об’єктів. Ці об’єкти можуть бути або примітивними, або складовими складних елементів (наприклад, зв’язок у транспортній системі між виробником і споживачем). Він також не має асоційованих значень.
3. Атрибут (ATTR) або змінний атрибут (VATTR) визначається в об’єднанні з деяким об’єктом або низкою об’єктів. Підтримка значень використовується для відображення окремих значень об’єкта, який визначений. Відмінність між атрибутом і змінним атрибутом полягає в тому, що в той час як атрибут використовується для відображення «коефіцієнтів даних» звичайних моделей, змінний атрибут використовується для відображення «змінних рішень».
4. Функція (FUNC) визначається як правило, що асоціюється з більш ніж одним об’єктом, який підтримує роботу зі значеннями, відповідно до правила.
5. Тест (TEST). Цей перевірочний елемент такий же як і функ-ція, з тією лише відмінністю, що він може набувати одного з двох значень: «істинність» або «хибність». Використовується для визначення логічних аспектів моделювання.
Родова структура складається з груп елементів (родів, класів). Кожний рід у цій структурі об’єднує елементи одного типу (наприклад, ряд усіх примітивних елементів, які відображають центральну концепцію в предметній галузі), тобто родова структура використовується для групування подібних елементів. Вона визначається на елементній структурі як ряд розділів, по одному для кожного з п’яти типів елементів. Кожний із цих розділів називається родом (класом), елементи яких однакові за винятком дрібниць.
Модульна структура використовується для згрупування класів у концептуальні одиниці, які називаються модулями відповідно до загальних або семантичних відношень, далі для об’єднання цих модулів у модулі вищого рівня і т. д. Модульна структура утворює єрархічну організацію другого рівня.
Головні переваги використання структурного моделювання такі:

  1. Всезагальність. Майже кожна схема моделі може бути визначена як структурна модель.
  2. Зв’язок. Структурна модель є дуже легкою для розуміння навіть для користувачів з невеликими знаннями про проблеми і семантику дослідження операцій. Більшість мов, визначених на основі структурного моделювання, мають цю властивість.
  3. Керованість. Структурна модель є легкою для керування не тільки користувачами на рівні підтримки, але також і як частина системи. Структурні моделі легко об’єднуються для створення більших моделей.

Нині вже розроблено кілька пакетів програмного забезпечення структурного моделювання, зокрема, програмний продукт VMS, в якому поєднані концепції структурного та візуального моделювання.
Мова структурного моделювання
Метою структурного моделювання є забезпечення фун­даменту для комп’ютерного середовища моделювання, яке ви-
користовує мову структурного моделювання SML (Structured Modeling Language), що підтримує цю моделюючу систему. SML вперше була розроблена Джеоффріоном, а після нього ряд інших авторів запропонували свої підходи до цієї проблеми.
SML може бути подана чотирма рівнями. Перший з них містить прості визначені системи і моделі орієнтованих графів. До другого рівня належать більші комплексні їх розширення, моделі електронних таблиць, числові формули й моделі числення вислов­лень. Третій рівень охоплює математичне програмування і моделі числення предикатів з простою індексацією над множиною і декартовими добутками. Врешті, четвертий рівень містить розріджені версії вищезазначеного та реляційні і семантичні моделі бази даних.
Розглянемо використання SML на прикладі відомої задачі про раціон (дієту) або задачі про оптимальний склад суміші, відомої в англомовній літературі як Classical Feedmix Model. Нагадаємо суть цієї задачі.
Задача про дієту або задача про раціон — це задача лінійногопрограмування, що полягає у визначенні такого раціону, який задовольняв би потреби людини або тварини в поживних речовинах за мінімальної загальної вартості продуктів, що використовуються. Це окремий і найпоширеніший приклад загальнішої задачі про оптимальний склад суміші.
Задача визначення оптимального раціону для людини складна, оскільки доводиться враховувати багато додаткових чинників, що не завжди можна формалізувати: смакову прихильність, різноманітність блюд тощо. Однак у тваринництві визначення раціонів для худоби за допомогою задачі лінійного програмування сьогодні не просто реальне, але й необхідне. Досвід свідчить, що годівля худоби за раціонами, розрахованими цим методом, дає істотну економію. Наприклад, у США такі раціони використовують багато фермерів. Це не означає, зрозуміло, що кожний з них сам розв’язує задачі лінійного програмування: для різних регіонів країни видаються довідники раціонів годівлі тварин, ураховуючі місцеві особливості й можливості, породи худоби тощо.
Наведена нижче схема SML (третій рівень) описує загальну структуру класичної моделі раціону (feedmix), а приклади SML для елементних детальних таблиць, які конкретизують елементи моделі, разом зі схемою визначають специфічну (конкретну) модель feedmix.

&NUT_DATA NUTRIENT DATA (дані про поживні речовини)
NUTRi /pe/. Це список поживних речовин(NUTRIENTS).
MIN (NUTRi) /a/ : Real+ Для кожної поживної речовини (NUTRIENT) є MINIMUM DAILY REQUIREMENT (мінімальна щоденна потреба) — одиниць на день на тварину.
&MATERIALS MATERIALS DATA (дані про матеріали)
MATERIALm /pe/ Це список кормів (MATERIALS), які можна використовувати для годівлі.
UCOST (MATERIALm) /a/ Кожний вид корму (MATERIAL) має UNIT COST (питому ціну) — дол. за фунт корму.
ANALYSIS (NUTRi, MATERIALm) /a/ : Real+ Для кожної комбінації NUTRIENT-MATERIAL (поживна речовина—продукт) проводиться аналіз (ANALYSIS) вмісту поживної речовини у фунті продукту.
Q (MATERIALm) /va/ : Real+ QUANTITY Має визначатися щоденна кількість (у фунтах) кожного виду корму (MATERIAL) на тварину.
NLEVEL (ANALYSISi., Q) /f/ ; @SUMm (ANALYSISim * Qm) Як тільки кількості (QUANTITIES) кормів вибрані, визначається рівень поживності (NUTRITION LEVEL) — одиниць щоденно на тварину для кожної поживної речовини, обчислюваний за допомогою аналізу (ANALYSIS).
T:NLEVEL (NLEVELi, MINi) /t/ ; NLEVELi >= MINi. Для кожної поживної речовини проводиться зіставлення (тестування) (NUTRITION TEST), щоб визначити, чи рівень поживності кормів (NUTRITION LEVEL) не менший, ніж мінімальна щоденна потреба (MINIMUM DAILY REQUIREMENT).
TOTCOST (UCOST, Q) /f/ ; @SUMm (UCOSTm * Qm). Це загальна сумарна вартість раціону (TOTAL COST) удоларах на день на тварину, яка обчислюється за вибраними їх кількостями (QUANTITIES).
Структура й послідовність елементних детальних таблиць залежить процедурно від схеми. Кожна таблиця має назву, тобто ім’я стовпця, яке зазвичай збігається з іменем роду, і має рядок для кожного елемента відповідного виду. Таблиці даних з кон-кретизацією схеми SML для задачі про раціон мають такий вигляд:

NUTR

NUTR

Інтерпретація

MIN

P

Protein протеїн

16

C

Calcium кальцій

4

MATERIAL

MATERIAL

Інтерпретація

UCOST

std

Standard Feed Стандартний корм

1.20

add

Additive добавка

3.00

ANALYSIS

NUTR

MATERIAL

ANALYSIS

P

std

4.00

P

add

14.00

C

std

2.00

C

add

1.00

Q

MATERIAL
Q

std

2.00

аdd

0.50

NLEVEL

NUTR
NLEVEL
T:NLEVEL

P

15.00

FALSE (хибність)

C

4.50

TRUE (істина)

TOTCOST

TOTCOST 3.90

 

Дамо стислі пояснення синтаксису мови структурного моделювання SML стосовно наведеного прикладу. Схеми моделі організовуються як дерево параграфів (абзаців), виходами яких є роди, а внутрішні вузли є модулями. Виділена напівжирним шрифтом частина кожного абзацу є формальним визначенням роду чи виду (genus) або модуля залежно від контексту, а решта складається з документальних коментарів про формальну частину, які є неформальними за винятком домовленостей про використання підкреслення і верхнього регістра. Формальне визначення параграфа (абзацу) роду починається з імені роду (наприклад — NUTRi); вставного твердження визначеної залежності (якщо така є, наприклад UCOST, Q); розмежованого слешем (/) твердження
типу роду (наприклад, /va/ — змінний атрибут, /f/ — функція, /t/ — тест); оголошеного двокрапкою твердження типу даних (наприклад, Real+ — дійсні додатні числа), якщо це атрибутний рід (genus); і оголошений крапкою з комою математичний вираз, який називають генеруючим правилом, якщо це функція (наприклад, @SUMm (UCOSTm * Qm) — сума добутків) або тестовий piд (genus) (наприклад, NLEVELi >= MINi — перевірка нерівності).
Формальне визначення модульного параграфа складається тільки з імені. Зверніть увагу на те, що схема завжди описується незалежно від будь-якої проблеми або завдання, яке могло б фор-мулюватися в такому разі. Загальне завдання, яке описане вищезазначеною схемою, — знайти такі значення для всіх елементів Q, що всі елементи T: NLEVEL оцінюються як істина і значення елемента TOTCOST мінімальне.
На рис. 5.8 наведений родовий граф, який відображає структуру моделі про раціон, і який пов’язаний з вищезазначеною схемою. Він зображає визначену залежність рівнів родів.


Рис. 5.8. Родовий граф багатоелементної моделі задачі про раціон:
Q — склад добового раціону; NUTR — поживні речовини;
MINмінімальна щоденна потреба в поживних речовинах;
TOTCOST — загальна вартість раціону; UCOST — ціна
за одиницю (питома ціна) корму; NLEVEL — рівень
поживності; T:NLEVEL — тестування поживності;
MATERIAL — корми, що входять до раціону;
ANALYSIS — проведення аналізу кормів на поживність
SML-базові системи моделювання можуть мати специфічні властивості, яких часто бракує в системах моделювання загальноприйнятішого проекту.
Використання структурного
моделювання для створення СКБМ

Структурна модель може відображати як одночасність, так і рекурсію, і здатна містити дійсно динамічні моделі з дискретизованим часом. Можна також використовувати й безперервний час, якщо вважати значення атрибутів і функціональних елементів функціями часу. До задач, що розв’язуються за допомогою струк-турних моделей, можна віднести оптимізацію, оброблення незапланованих запитів користувачів, пошук значень вибраних атрибутів, одержання логічних висновків за рахунок використання системи як механізму виведення. Такі широкі різнобічні дії з розв’язання завдань оброблення інформації охоплюють досить великий діапазон потреб і функцій підтримки прийняття рішень у СКБМ і одночасно забезпечують незалежність подання моделі і розв’язків, одержаних на її основі.
Використання структурного моделювання для цілей проектування і розроблення СКБМ включає:

  1. низхідне проектування моделі, що створює можливість поетапного вдосконалення за рахунок єрархічної картини зони мо­делювання;
  2. інтегроване моделювання як за функціями (наприклад, виробництво і розподіл), так і в географічному та часовому аспектах (наприклад, планування і побудова календарних графіків);
  3. досягнення цілей комунікації і документування, оскільки спрощена версія схеми моделі досить корисна для отримання повідомлень звичайною мовою і, як наслідок, для комунікації з користувачами.

Родовий граф (подібний зображеному на рис. 5.8) може виявитись досить корисним щодо комунікації: є можливість швидко безпосередньо побачити фактичну структуру моделі.

5.5. Управління поштою
(повідомленнями) в СППР

Традиційно фахівці вважали поштову систему, навіть електронну пошту, додатковою функцією СППР. Тобто розробники систем підтримки прийняття рішень розуміли, що особа, яка приймає рішення, ймовірно, має системи доставлення електронної пошти, але такі системи ігноруються за проектування і
розроблення СППР. Для використання електронної пошти ОПР спочатку мали б припинити роботу з СППР. Навіть коли з’явилася технологія «роботи з вікнами» прикладних програм, яка дала змогу користувачам легко переміщуватися в прикладну програму електронної пошти, СППР і електронна пошта існували все ще як незалежні програми. ОПР не могла легко пересилати документи, графіку чи текст безпосередньо з СППР або отримувати такі, щоб використовувати всередині СППР.
У нинішньому електронному середовищі безшовна інтеграція СППР з системою електронної пошти означає серйозні обмеження на інформацію та аналізи, доступні ОПР. Усе більша кількість
менеджерів вважає електронну пошту продуктивно розширювальним інструментом. Інтерфейс із системою електронної пошти уможливлює ОПР більший доступ до груп обговорення, баз даних Інтернету, інших електронних даних та інструментальних засобів для прийняття рішень. Ці ресурси можуть розширювати діапазон доступної інформації, а також за деяких обставин забезпечувати доступ до новіших даних. Використання електрон­ної пошти може допомагати ОПР зв’язуватися з колегами, щоб
обговорити інформацію та дослідження, а також встановити загальноприйнятну перспективу рішень. Це може, у свою чергу, покращити зв’язок ОПР з підлеглими і сформувати підтримку для вибору, що є важливими кроками в процесі прийняття рішень.
Розглянемо можливості, які може забезпечити ОПР доступ до електронної пошти [103]. По-перше, електронна пошта може дати змогу ОПР легко надсилати і отримувати інформацію від колег. Така гнучкість особливо важлива, коли ОПР мають спілкуватися з колегами в інших країнах. Інакше ОПР мають обмаль часу щодня для того, щоб увійти в контакт з іноземними колегами, і не можуть підтримувати стосунки на оптимальному рівні.
Спілкування між ОПР, зазвичай складніше, ніж прості запитання і відповіді, що можуть бути реалізовані з застосуванням простого шаблону пошти. Часто вони мають формувати докумен-ти і проводити дослідження на основі аналізу чи пов’язаних записів. Якщо електронна пошта інтегрована в СППР, то вони можуть легко вкладати документи, електронні таблиці, і навіть графіки, що збагачує зв’язок. Багато із сьогоднішніх комерційних програм електронної пошти мають можливість вкладати документи і записи в електронній пошті. Якщо користувач часто вкладає окремі документи чи типи документів, то він може у відповідний спосіб настроювати панель інструментів для зручнішої реалізації своїх завдань.
Використання електронної пошти для щоденного зв’язку, який традиційно проводиться у формі зустрічей, телефонних дзвінків чи поштового обслуговування, створює в людей звичку використовувати цей засіб комунікацій. З причин, які не очевидні, більшість людей мають тенденцію відповідати на електронну пошту легше і швидше, ніж використовувати якісь інші типи зв’язку. Так само люди із задоволенням використовують електронну пошту для передавання повідомлень, які інакше не можуть бути передані, особливо особам вищого рангу. Електронна пошта забезпечує зв’язок між особами, які, зазвичай, не взаємодіють між собою. Крім цього, багато людей надають своїм повідомленням електронною поштою більш персональний характер ніж записам.
Крім прямого використання електронної пошти користувачі СППР можуть використовувати електронні дискусійні групи, щоб отримати інформацію чи оцінки від розширеної групи колег. Відкриті дискусійні групи доступні в Інтернеті майже на будь-яку тему, яку тільки можна уявити. Деякі дискусійні групи у США містять промислові теми, такі як музична промисловість, управління готелями та ресторанами, або навіть автоматизовані системи відкачування рідини. Є також дискусійні групи, які цікаві для ОПР тим, що можуть підтримувати специфічні види завдань — адміністраторів мереж, інженерів чи групи обговорення технічних стандартів. Нарешті, є деякі загальні в галузі прийняття рішень дискусійні групи, такі як загальне управління якістю (TQM), керованої охорони здоров’я і виконавчі групи.
ОПР можуть також ініціювати дискусійні групи, складені зі службовців їх корпорацій, відділів чи проектних груп, або колег з подібними інтересами та обов’язками з інших корпорацій. Так само дискусійні групи могли б використовуватися для пропозицій щодо процедурних чи стратегічних змін і (або) для ідентифікації проблеми важливості певних клієнтів чи підлеглих. Користувачі в цих закритих дискусійних групах можуть бути більш наближеними до інформації та отримувати підтримку, тому що вони саме ті, хто буде читати повідомлення; вони також не мають хвилюватися стосовно відкритості приватної інформації чи стратегічних планів корпорації. Крім того, закриті дискусійні групи мають спільну мету і відповіді на запитання можуть допомогти наблизитися до цієї спільної мети.
Деякі пакети електронної пошти, доступні на сьогодні, значно полегшують такі обговорення. Наприклад, поштова система DaVinci містить інформаційне табло для групових повідомлень. За використання такого засобу ОПР можуть формувати групові обговорення, легко і швидко відповідати на запитання чи запити, як тільки-но вони з’являються. Важливішим є те, що пакети типу DaVinci мають здатність відстежувати нитки повідомлень електронної пошти. Якщо ОПР хоче слідкувати за діалогом зі специфічної тематики, то вона може знайти початкове повідомлення, відповіді на повідомлення, і навіть відповіді на відповіді пові-домлень легко, навіть якщо було багато інших поштових повідо­млень у той же період. Тому ОПР не відволікається на інші теми
та може зосередитися на проблемі, що розв’язується.
Ще один спосіб використання електронної пошти здійснюється шляхом перегляду певного середовища, щоб ідентифікувати проблеми й можливості. Наприклад, дискусійні групи чи групи новин можуть допомогти ОПР виявити нові ідеї. Запитання, поставлені іншими користувачами відносно нових методів або процедур, можуть дійти до уваги ОПР, які можуть розглянути їх як стратегічні можливості чи використати ідеї для розв’язування наявних проблем. У такий же спосіб ОПР з міжнаціональних корпорацій, чи ті, хто беруть участь у багатонаціональних переговорах, можуть контролювати поточні події в окремих країнах, шукати зміни, які можуть потребувати змін у політиці чи планах. Так само і внутрішні дискусійні групи могли б використовуватися для виявлення проблем чи ідей.
Дискусійні групи — не єдиний шлях, яким ОПР можуть використовувати електронні комунікації. Існує ряд інформаційних служб, на повідомлення яких можна підписатися в Інтернеті, що забезпечують, наприклад, своєчасні і технологічно пов’язані промислові новини. Від них ОПР можуть отримати ряд новин, які пов’язані з вибором, що розглядається. Цей сервіс також надає фінансову інформацію, курси акцій та інші матеріали, які можуть бути цікавими для ОПР.
Не обов’язково підписуватися на всі послуги. Недавні зміни в протоколі Інтернету значно збільшили можливості отримання й пошуку електронних баз даних. ОПР можуть шукати всі електронні бази даних за окремими темами з незначними зусиллями. Вони можуть переглядати загальні телефонні книги, офіційні повідомлення для друку та щоденні звіти з усього світу.
Розглянемо, наприклад, систему infoSage від IBM. Ця система забезпечує інтелектуальне фільтрування електронної пошти, яка поступає в систему. Після переривання та читання повідомлення, infoSage пробує класифікувати його, використовуючи певні правила. Ці правила можуть відбивати важливість відправника інформації, самої інформації чи джерела повідомлення. Програма може виконувати такі дії: відбирати повідомлення з оцінюванням пріоритету, зберігати повідомлення в папці, відкидати повідомлення, переглядати їх тощо.
Подібні системи у складі СППР можуть використовуватися для фільтрації новин чи пошти, інформації дискусійних груп. Зокрема, користувач має вибрати зі списку те, що краще описує його потреби. Він може також доповнювати список специфічними ключовими словами, які можуть зустрічатися в новинах. Нарешті, користувач може розмістити за важливістю теми списку, щоб відбити свої відносні інтереси. Потім, з регулярними інтервалами, система скануватиме сервіси новин і шукатиме інформацію, яка відповідає інтересам користувача. Після цього статті будуть організовані в групи з предметними заголовками та розміщені за важливістю відповідно до інтересів користувача.
Пошук здійснюється за допомогою технології клієнт/сервер та броузерів Інтернету, таких як Netscape Navіgator. Використовуючи такі інструментальні можливості, ОПР можуть отримати доступ до даних, розподілених і підтримуваних на ЕОМ у всьому світі. Альтернативно вони можуть зосередити пошук на спеціальних індексах (пошукових сервісах), щоб знайти всі директорії, в яких використовуються певні ключові поля. Так само ОПР можуть використовувати засоби пошуку, щоб здійснити повний тек-стовий пошук за всіма документами і вивести список тих, які містять певні ключові слова.
Багато бібліотек починають забезпечувати електронні повнотекстові версії матеріалів-посилань і друкують матеріали, які можуть бути доступними через WWW. Нарешті, деякі професійні групи почали забезпечувати інтерактивний доступ до журналів чи резюме статей. Урешті-решт можливості нескінченні для тих, хто знає, як доступитися до системи.
Методи для адресування проекту поштової управлінської системи подібні до тих, які використовуються для управління даними й моделями. Зокрема, якщо ОПР мають доступ до адекватної системи електронної пошти, то розробники СППР не повинні перепроектовувати систему, а скоріше, вони мають забезпечити зв’язки між цією системою електронної пошти і СППР. Якщо, однак, ОПР не мають доступу до адекватної системи електронної пошти, було б доцільно включити цю можливість у повний проект.
Адекватна система електронної пошти — це та, яка має можли­вості, що роблять її корисною для прийняття рішень. Такі системи мусять мати доступ до стандартних можливостей електронної пошти, типу здатності індексувати повідомлення та відображати ці індекси, а також мати здатність реєструвати повідомлення, видаляти їх, направляти іншим зацікавленим особам, та відповідати на них. Крім того, вони мають містити легко і автоматично доступну адресну книгу осіб.
Щоб бути корисною в середовищі СППР, система електронної пошти потребує додаткових можливостей, які полегшують чи хоча б не перешкоджають використовувати системи електронної пошти для підтримки рішень. Одна з таких можливостей — автоматичне повідомлення системи користувачеві про доступність електронної пошти, незалежно від того, чи використовується якийсь інший додаток. Якщо автоматичне повідомлення не забезпечується, то користувач вимушений зупинити те, що він робить для того, щоб перевірити електронну пошту. За цих умов ОПР, імовірно, не будуть використовувати електронну пошту, або, у крайньому разі, не будуть використовувати її ефективно. Звичайно, ОПР мають бути здатними відключати функцію автоматичного повідомлення, коли вони не хочуть відриватися від виконання поточних завдань.
З цією можливістю пов’язана необхідність забезпечувати систему фільтрації повідомлень, оскільки автоматичне повідомлення без механізму фільтрування може зробити систему електронної пошти більше дратуючою, ніж корисною. Зрозуміло, що швидке повідомлення про нетермінову інформацію не краще, ніж взагалі не мати його.
Проте якщо система електронної пошти повідомляє користувача тільки тоді, коли повідомлення отримано від окремих осіб чи дискусійних груп, то це може бути корисною інформацією. Так само, якщо фільтруюча система може читати повідомлення і переривати роботу лише в тому разі, якщо надійшла електронна пошта відносно певної теми чи переліку тем, то це буде корисно для ОПР. Крім того, така система фільтрування могла б відрізняти повідомлення, що є відповідями на запити ОПР, від тих, які є новими, щоб надати пріоритети повідомленням про відповіді на поставлені користувачем запитання.
Якщо система електронної пошти здатна визначити джерело повідомлення, порівнявши його з переліком джерел визначеного користувача, і (або) визначити тему повідомлення та зіставити її з низкою тем визначеного користувача, то вона буде «знати», які повідомлення важливі для ОПР, і відповідно до цього переривати її роботу.

Страницы [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ 12 ] [ 13 ] [ 14 ] [ 15 ]
[ 16 ] [ 17 ] [ 18 ] [ 19 ] [ 20 ] [ 21 ] [ 22 ] [ 23 ] [ 24 ] [ 25 ] [ 26 ] [ 27 ] [ 28 ] [ 29 ] [ 30 ] [ 31 ] [ 32 ]
[ 33 ] [ 34 ] [ 35 ] [ 36 ] [ 37 ] [ 38 ] [ 39 ] [ 40 ] [ 41 ] [ 42 ] [ 43 ] [ 44 ] [ 45 ] [ 46 ] [ 47 ] [ 48 ] [ 49 ] [ 50 ]


ВНИМАНИЕ! Содержимое сайта предназначено исключительно для ознакомления, без целей коммерческого использования. Все права принадлежат их законным правообладателям. Любое использование возможно лишь с согласия законных правообладателей. Администрация сайта не несет ответственности за возможный вред и/или убытки, возникшие или полученные в связи с использованием содержимого сайта.
© 2007-2019 BPK Group.