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

Главная

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

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

Форум

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

Карта сайта

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

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


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

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

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

Страницы [ 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 ]

 

8.3.2.3. Моделювання

Структурування задач для проектування й розроблення інтерактивних систем не буде повним і закінченим, поки процес узгодження й зіставлення не буде функціонально змодельований. Але після завершення моделювання системи її розробниками слід повертатися назад до моделей, задач, користувачів, організаційної доктрини, оскільки проектування та розроблення — це ітераційний процес, що потребує повторного моделювання. Можна виділити чотири форми подання моделей системи: описові (вербальні) моделі; моделі у вигляді блок-схем; математичні (кількісні) моделі; оболонки (альбоми, набори) сюжетів. Розглянемо ці форми моделей детальніше.
Описові (вербальні) моделі мають містити відомості про задачі, які буде виконувати система, подавати перелік вимог до вхідної інформації, описувати та ілюструвати вихід СППР і пропонувати програмну й апаратну конфігурацію. Описове подання має бути точним і лаконічним, за можливості ілюструватися симульованими екранними зображеннями. Слід зазначити, що описовий підхід прийнятний для нескладних застосувань СППР і непізнавальних системних задач.
Є кілька різних видів блок-схем, які можна досить продуктивно використати для розроблення моделей прототипів СППР. Сюди відносяться:

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

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

Оболонки (альбоми) сюжетів. Моделі екранних зображень і оболонки сюжетів (низки копій екранних зображень) являють собою найкорисніші моделі, як такі, що дають можливість продемонструвати кінцевому користувачу, якими будуть остаточні можливості системи і як вони будуть реалізовані. Такі оболонки сюжетів симулюють людино-машинну взаємодію в міру розгортання їх за проектування СППР. Сучасні пакети мультиплікаціювання дають змогу «оживляти» всі низки сюжетів, імітуючи складні інтерактивні графічні засоби. Розробники СППР усе частіше поєднують оболонки сюжетів із швидким макетуванням застосувань.

8.3.2.4. Вибір методів

Оцінювання і вибір аналітичних методів для створення методологічної бази підсистеми СППР є змістом третього етапу макетування. Відправною точкою для розробників цього етапу служать досить грубі й абстрактні результати зіставлення задач і методів, одержані за аналізу вимог. Добре ідентифіковані характеристики задачі СППР на першому етапі дають можливість легко і виразно вивчати розумні пропозиції відносно застосованих методів. Наприклад, якою є галузь СППР за своєю суттю: індуктивною чи дедуктивною (чи деякою комбінацією цих концепцій)? Відповіді на ці запитання стануть орієнтирами для вибору потрібного типу методів.
Перед тим, як вибрати для СППР метод (або комбінацію методів), необхідно оцінити пов’язаний з ним епістемологічний (пізнавальний) і аналітичний супровід та переконатися в сумісності методів, задач, користувачів і організацій з відповідними доктринами.

8.3.2.5. Вибір і (або) проектування
програмного забезпечення

Програмне забезпечення (ПЗ) реальної СППР можна отримати двома шляхами: купити готове чи замовити його розроблення. Готові або комерційні програми для системи підтримки прийняття рішень можуть бути цілком прийнятними. Готове ПЗ завжди дешевше ніж замовлене, але менше пристосоване до конкретних потреб користувачів. Замовлене ПЗ має розроблятися за висхідним принципом, починаючи від урахування вимог користувачів. Є і проміжний варіант, коли куплене готове програмне забезпечення пристосовується до потреб користувачів за рахунок його дальшого модифікування і вдосконалення. Вибір для цього питання правильного рішення вимагає застосування структурованого підходу, зокрема, за допомогою методів аналізу рішень або аналізу затрат і вигід.
Є кілька важливих показників ефективного інтерактивного ПЗ, головними з яких є:

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

Структура інтерактивного діалогу має враховувати ініціацію, гнучкість, складність, потужність та інформаційне навантаження під час проектування і розроблення високоякісного, орієнтованого на користувача ПЗ для СППР. Найважливіші типи інтерактивного діалогу були розглянуті раніше.
Розроблення програмного забезпечення СППР має проводитись у відповідності із загальноприйнятими стандартами програмування. Добре програмне забезпечення створюється в результаті процесу інженерії зусиллями систематично працюючих про­грамістів під керівництвом обережних аналітиків. Структуровані методи програмування, правильне використання міток і ретельне документування — це лише деякі із характерних ознак якісних програм СППР.
За умови вибору шляху вдосконалення замовленого ПЗ проектування і розроблення його мають здійснюватися на базі перегляду альбому сюжетів і реалізації всіх доцільних модифікацій навіть у тому разі, коли в даний момент уже є «робоча» система для демонстраційних цілей. «Живий» альбом (оболонки) сюжетів належить модифікувати, тому що на цій стадії проектування СППР це забезпечує найкраще подання функцій системи: крім того, оболонка сюжетів буде служити «контрольним журналом» або пам’яттю для проектувальників систе-
ми. Важливим є залучення користувачів в усі аспекти створення ПЗ під час розроблення нових екранних зображень інтерактивних послідовностей. Їм потрібно передавати відповідальність за підтримку «живої» оболонки сюжетів і частину фун­кцій щодо складання початкової версії посібника для користувачів.

8.3.2.6. Вибір і компонування апаратних засобів

У разі прийняття рішень стосовно вибору апаратної бази СППР часто має місце передчасність розв’язання цього питання: тип ЕОМ, а нерідко і периферійні пристрої, і вся конфігурація загалом вручаються розробнику як визначені і розв’язані питання на самому початку проектування. Тому доводиться підганяти СППР до апаратної бази, хоча ідеальною є протилежна стратегія — вибирати апаратні засоби після встановлення вимог і моделюван­ня системи.
У центрі питання про створення апаратної бази СППР знаходиться вибір міні- і мікрокомп’ютерів. Програмне забезпечення для СППР можна придбати для будь-яких типів комп’ютерів. Існують також розроблені СППР для будь-яких апаратних конфігурацій.
Вимоги до системи і програмне забезпечення мають підтримуватися ввідними пристроями. Є різноманітні альтернативні засоби введення, але не всі вони можуть підходити до конкретних застосувань. Розроблювачі мають також різноманітні альтернативні типи відображень. У більшості застосувань СППР виникає необхідність отримання твердих копій; наявні засоби, як правило, уможливлюють це та задовольняють вимоги стосовно показника «вартість—ефективність». Важливе значення для успіху системи має загальний людино-машинний інтерфейс. Оптимальне проектування інтерфейсу для СППР потребує участі спеціаліста з інженерної психології.

8.3.2.7. Складання (комплектування) системи

Усі СППР мають бути добре укомплектованими. Ця необхідність зумовлена вимогою створення якісної документації, яка має включати специфікацію системи, функціональний опис і посібник для користувача. Часто має місце спокуса частково або цілком уникнути цієї трудомісткої і нерідко монотонної роботи зі складання «твердих» копій документів, особливо на заключній стадії розроблення системи і написання програмних (машинних) кодів. Нехтування створенням необхідної документації може мати катастрофічні наслідки, зокрема, на майже обов’язковому етапі налагоджування системи, коли потрібно здійснювати як виправлення, так і супроводження програмного забезпечення.
Частиною комплекту документації системи мають бути засоби підтримки. СППР, яка не має таких засобів, можливо, узагалі не буде використовуватись. Підтримка на місці експлуатації разом із підтримкою на основі документації має стати частиною всього комплексу системи. Підтримка означає також і навчання. Користувачам СППР мають бути надані як вбудовані, доступні в діалоговому чи автономному режимі, так і звичайні засоби навчання. Бажаними є діалогові засоби навчання, за допомогою яких користувачі мають можливість вивчати систему безпосередньо під час її експлуатації.

8.3.2.8. Передавання системи

Процес передавання СППР розвивається в часі і проходить поступово, а не є одноразовим актом. На нього впливають численні й різноманітні фактори: користувач, його середовище і організаційний контекст, характер задач і рішень тощо. Тому передавання має плануватися і контролюватися ретельно й безперервно.
Перед «випуском» системи для групи користувачів, представники яких обов’язково мають брати деяку участь у процесі розроблення СППР, колектив розроблювачів повинен визначити ситуацію стосовно можливих змін і загальну стратегію керування ними. Зрозуміло, що система, яка не буде успішно передана користувачеві, залишається ефективною тільки на папері.
Є дві концепції вивчення фази передавання за розроблення СППР. Згідно з першою з них визначальними чинниками є виділення факторів, ключових для успіху чи невдачі системи, і оцінювання їх впливу. Такими факторами, наприклад, можуть бути наявність підтримки керівників вищого рівня чи участь користувачів у розробленні СППР. Досліджуючи ці фактори, вчені розглядали такі незалежні змінні, як характеристика ОПР (наприклад, його пізнавальний стиль) і методи генерування (подання) інформації. Залежними змінними (вихідними характеристиками) можуть бути: схвалення пропонованих системою результатів; задоволення від роботи з СППР; якість рішень.
У другій концепції реалізація СППР розглядається як процес організаційних змін, що проводяться в міру розгортання процесу передавання системи. Зокрема, була запропонована модель консультацій для вивчення реалізації як процесу організаційних змін. Модель містить сім чітко виділених стадій. Стадії розвідки, введення і діагностики пов’язані з завданням підготовки системи до змін. Стадії планування і дій спричинюють реальні зміни, пов’язані із застосуванням СППР замість традиційного процесу аналізу і прийняття рішень. Стадії аналізу і завершення належать до введення (інституалізації) змін всередині організації. Передбачається, що успіх реалізації явно пов’язаний із ступенем розв’язання питань, які виникають на різних стадіях фактичного передавання системи; наприклад, на стадії введення питання полягає в тому, щоб переконати потенційних користувачів СППР у необхідності проекту. Процес упровадження СППР буде розглянуто окремо.

8.3.2.9. Оцінювання системи

Оцінювання системи має проводитися протягом усього часу її інженерії. Колектив розроблювачів постійно оцінює якість і ефективність дотримання вимог, достовірність оболонки сюжетів чи інших моделей системи, якість модулів і підсистем програмного забезпечення, а також ряд інших аспектів процесу проектування СППР і самої системи в міру того, коли вона починає функціонувати як самостійний об’єкт.
Спочатку потрібно визначити цілі процесу оцінювання. Потім необхідно дослідити можливі методи оцінювання; кілька альтернативних методів, які поділяються на суб’єктивні, об’єктивні і комбіновані. Особливо потужними і простими в користуванні засобами оцінювання СППР є розглянуті раніше методи багатоатрибутної корисності. Крім цілей іметодів потрібно також визначити критерії.
Є ряд внутрішніх критеріїв, націлених на визначення того, наскільки добре система підтримує ідеальну версію процесу прийняття рішень. За зовнішніми критеріями визначають, наскільки продуктивно СППР допомагає користувачам знаходити «правильні» відповіді. Необхідно також проявляти обережність у разі вибору або розроблення сценарію (або системи сценаріїв), які дають змогу точно й діагностично коректно випробовувати СППР. Аналіз системи на основі вибраних оцінок і критеріїв являє собою складний та інтелек­туально насичений аналітичний процес.

8.3.2.10. Зворотний зв’язок

Проектування і розроблення інтерактивних систем і особливо інтерактивних систем підтримки прийняття рішень являє собою безперервний ітераційний процес, який фактично ніколи не закінчується. Тому зворотний зв’язок має бути постійним протягом усієї інженерії СППР. Контур процесу проектування має замикатися після кожного етапу або операції. Дані, зібрані в процесі інженерії системи, а також отримана в результаті випробувань і оцінювань системи інформація мають знову повертатися в процес проектування.
Після передавання й заключного оцінювання СППР необхідно підтримувати зворотний зв’язок для аналізу дотримання вимог (і для дальших етапів створення СППР), щоб гарантувати відповідність розроблюваної системи вимогам, визначеним на останньому кроці.
8.4. Впровадження та оцінювання СППР
Впровадити СППР означає реалізувати заплановану систему. Реалізація включає трансформацію проекту в коди, але це виходить далеко за межі програмування. Вона також включає створення та початкове завантаження бази даних і бази моделей та керування кінцевим продуктом, яке передбачає інсталяцію (установку), введення в дію, компоновку та реальне випробування. Ще одним аспектом упровадження СППР є навчання користувачів та забезпечення того, щоб вони сприймали СППР як корисний та надійний інструментальний засіб. І нарешті, оціню­вання включає всі ті кроки, які б гарантували, що система здійснює те, що потрібно, і виконує все добре. Ці питання докладно описані в [103]. Змістовна інформація та джерела з приводу впровадження та оцінювання СППР розміщені на Web-сторінці — http://www.umsl.edu/~sauter/DSS/impl.html. Стисло розглянемо пи­тання впровадження та оцінювання СППР.
8.4.1. Стратегії впровадження
Успіх будь-якого впровадження суттєво залежить від процесу, прийнятого колективом впроваджувальників. Не існує стандартних кроків, що гарантують успіх впровадження СППР: підхід, що був добре реалізований в одному разі, може не підійти для іншої ситуації. 1988 року Свансон (Swanson) виявив дев’ять ключових факторів успіху або невдачі інформаційних систем, до яких належать і СППР. Вони стосуються оцінювання як самої системи (якості розроблення та рівня виконання), так і процесу розроблення (залучення користувачів, взаємного розуміння та керування проектом), а також організації, де буде використовуватися СППР (як наприклад, управлінських обов’язків, відповідності ресурсів та стабільності ситуації).
8.4.1.1. Досягнення добрих кондицій СППР
Добрі кондиції СППР — це гарантія того, що система здійснює те, що від неї очікується, добре. Успіх упровадження СППР великою мірою залежить від якості системи, простоти і гнучкості її використання. Зрозуміло, що коли ОПР не усвідомлять, що СППР полегшує прийняття їх рішень, то вони не будуть її використовувати.
Найбільша допомога, яку може забезпечувати система, полягає в організації доступу до інформації, про яку ОПР може не знати, у забезпеченні прикладами, яких ОПР може не мати, та в об’єднанні інформації, що інакше зберігалась би ізольовано, для доцільнішого використання ОПР. Крім того, чим простіший доступ до інформації та моделей, тим краще вони будуть використовуватися ОПР. Ключовими чинниками успішного розв’язання цього кола проблем є використання прототипів та інтерв’ювання користувачів. Ці питання були розглянуті раніше.
8.4.1.2. Додержуватися простого розв’язання
Важливо, щоб СППР забезпечувала саме ту підтримку, на яку сподіваються користувачі. Це означає, що система має надавати необхідні інструментальні засоби для створення рішень без використання складних технологій, що потребують значних зусиль користувачів на їх опанування. Дуже часто проектувальники втрачають бачення потреб користувачів і намагаються замість цього забезпечити їх останніми «новими технологіями» або всіма «дзвінками і свистками», пов’язаними з доступною технологією. Або проектувальники комп’ютеризують частину операцій тільки тому, що це можливо, а не тому, що це полегшує процес створення рішень. Звичайно, за бажання користувачів проек­тувальники можуть надати можливість проекспериментувати з цими технологіями, але така ситуація здається тільки відхиленням, необхідним для отримання «реально зробленої роботи» для ОПР. Тому подібні методи здатні затримувати процес упровадження.
Більшість потреб щодо прийняття рішень не є «простими».
В такому разі СППР не може бути спроектована просто. Однак, си­стема з погляду потреб ОПР має бути простою. Взагалі користу­вачам не потрібно докладно знати про виконання операцій системою. Підхід до розв’язання проблеми і необхідні для цього кроки, що мають здійснювати ОПР, повинні бути інтуїтивними та не заплутаними. Наприклад, користувачам не потрібно бути обізнаними з усіма компонентами системи для визначення повноти специфічної інформації; скоріше, їм потрібно знати, що така операція наявна. Також новим користувачам не потрібно розуміти гнучкість у разі виконання обчислень за всіма можливими моделями системи; скоріше їм потрібно знати, як отримати результат за базовою моделлю. Простота використання буде полег­шувати сприйняття ОПР і остаточну інституалізацію системи.
8.4.1.3. Розробляйте достатню
основу підтримки

Залучення користувачів

Більшості людей не подобаються зміни. Стосовно твор­ців рішень ця теза може бути добре обґрунтованою: часто ОПР
досягають успіху саме тому, що довго діють у визначений спосіб, зміни здаються їм непродуктивними. Пристосування до нової комп’ютерної системи, особливо, якщо людина почувається не дуже комфортно з комп’ютерами, може бути складним. Є багато причин для існування таких проблем. Наприклад, ОПР можуть боятися, що вони стануть непотрібними у разі застосування нової технології, що їх відповідальність за завдання зміниться, або що вони не матимуть гарантії стосовно подальшої зайнятості. Інші можуть відчувати конкретне занепокоєння щодо володіння інформацією, яку тільки вони могли заздалегідь отримувати або генерувати. Водночас інші можуть уявляти СППР як вторгнення до їхніх таємниць. Багато менеджерів невпевнені відносно всіх методів створення рішень і тому вважають деякі етапи аналізу (де визначаються інформаційні потреби та потреби у моделюванні) незручними. Нарешті, уявлення про СППР може змінити баланс сил управління організації. Якщо інформація — це влада, то через ефект готовності інформації, що досягається засобами СППР, може виникнути думка про СППР як загрозу силовому впливу певних осіб або відділів.
Не дивлячись на те, що боязнь змін може вплинути на процес упровадження, часто опір виникає і через те, що людина не має контролю над процесом створення СППР, що породжує велику проблему. З цієї причини проектувальникам потрібно залучати користувачів до аналізу та процесу розроблення СППР. Користувачі, які візьмуть у цьому участь, будуть краще розуміти доцільність системи та окремих варіантів проекту, і мотиви того, чому певні опції не сприймаються. Їхнє сподівання буде реалістичнішим, що є вирішальним для ефективного впровадження.
Залучення користувачів також допоможе уточнити СППР та її характеристики. Різні люди розв’язують подібні проблеми неоднаковими методами, включаючи манеру, в якій вони їх звикли розуміти, важливість характеристик і переміщення в системі. Якщо стиль користувача враховується за розроблення системи, то ймовірно, система буде частіше ним використовуватися протягом тривалого часу. Якщо користувачі залучені спочатку, то вони можуть легко впливати на стадії розроблення системи. Цей підхід недорогий і легкий для реалізації. До того ж, інші, що не залучені до процесу розроблення, можуть скоріше погодитися з потребами, сформульованими їх колегами.
Залучення користувачів до аналізу і процесу проектування потребує встановлення рівноваги між впливом проектувальників інформаційних технологій і впливом користувачів та творців рішень. Коли балансу цих впливів немає, то система страждає. Наприклад, якщо вимоги з боку фахівців з інформаційних технологій мають завеликий вплив на розроблення системи, то СППР може не забезпечувати нові зв’язки з ресурсами, тому що це може потребувати узгодження з іншими стандартами корпорації.
З іншого боку, якщо ОПР має значний вплив на систему, то про­блема стандартизації може бути ліквідована і, отже, багато ресурсів може бути використано на інтеграцію і супровід.
Кожен раз, коли люди стикаються з незнайомими ситуаціями, вони будують гіпотезу щодо того, як у результаті цього зміниться їхнє життя. Подібна обставина призводить до однієї з головних проблем упровадження. Якщо ОПР та користувачі не розуміють, що система буде робити, як вона буде це виконувати або як це буде використовуватися, то вони будуть схильні до створення сценаріїв щодо функціонування системи і її використання, що врешті-решт заважатиме впровадженню СППР.
Здійснення змін
Здійснення змін або сприяння їм також важливе. Воно з’являється вже тоді, як тільки користувачі починають працювати з системою. Якщо вони до цього були залучені до процесу розроблення СППР, то, можливо, вже звикли це робити. Якщо ні, то важко отримати їхнє сприяння змінам без демонстрування явної переваги системи. Організація має бути готовою до змін шляхів, якими люди приймають рішення і якими інформація стає доступною. Спричинення змін має виконуватися протягом усіх фаз створення, інсталяції і використання системи. Крім того, керівництво мусить сприяти значним зусиллям, щоб зробити систему функціонуючою.
Здійснення змін починається згори. Менеджери вищого рівня не можуть відноситися негативно чи навіть бути неуважними до проекту СППР, оскільки їх пріоритети задають тон і регламент для організації в цілому. Вони мають турбуватися, щоб було достатньо виконавців для створення ефективної системи.
Управління змінами
Управління змінами важливе для успішного впровадження системи. Воно включає три основні фази: розморожування, просування та повторне заморожування. Розморожування, як це випливає із назви, є процесом створення клімату, сприятливого для змін. Воно означає розуміння того, що є потреба у змінах. Просування — це процес подання нової системи, а заморожування є процесом закріплення змін, що відбулися.
У першій фазі розробники мають працювати з організацією, щоб установити клімат, який заохочував би відверте обговорення переваг і недоліків діючої системи та давав би змогу проводити сеанси мозкової атаки для отримання розв’язків проблем і можливостей удосконалення системи. В термінах СППР цей етап ґрунтується на розвитку цілей СППР, щоб вплинути на процес прийняття рішень, а отже, він має починатися раніше, у фазі аналізу проекту. Розробники хочуть оцінити фактори, які сприятимуть або не сприятимуть впровадженню.
Наприклад, організаційний клімат сприяє впровадженню нової системи, якщо користувачі можуть відверто говорити про свої потреби та інтереси через відкриті канали зв’язку завдяки достат­ньому обсягу знань та досвіду роботи з системою. Однак, навколишнє середовище може знаходитися під впливом інших незалеж­них факторів. Наприклад, корпорація під час злиття або фінан-
сових труднощів не може сприяти змінам, незважаючи на різні рівні доведення переваг та доступні комунікації. Зайняті працівники можуть бути так сконцентрованими на збереженні своїх позицій щодо зайнятості, що не зможуть зосередитися, власне, на СППР, як на її конструюванні, так і на реалізації.
Так само роль вищого керівництва в процесі впровадження СППР є важливою. Вище керівництво, яке використовує систему, забезпечує адекватні ресурси для її використання і має великі сподівання щодо вигід від неї, створює середовище, що сприятливіше для впровадження, ніж це роблять старші адміністратори, які не залучені до розроблення та використання системи. Крім того, якщо має місце тісний зв’язок між розвитком СППР і стратегічними планами для департаменту або організації, то ймовірніше, що процес реалізації буде успішним, тому що керівники і користувачі відчують потребу в системі.
Друга стадія змін — це просування. В ній зусилля концентруються на розвитку СППР. Важливу роль відіграють технічні й управлінські ресурси. Керівництво концентрується на залученні користувачів, балансуванні впливу розробників і користувачів, реагуванні на опір та створенні середовища для ситуаційного сприйняття нових засобів. Команда користувачів та розробників установлює пріоритети для проекту, оцінює та вибирає оптимальні рішення з низки можливих. Команда має забезпечувати зворотний зв’язок для всіх користувачів та шукати їхніх порад.
Кінцевою фазою змін є повторне заморожування. На цій фазі розробники мають працювати з користувачами, забезпечуючи адекватне задоволення потреб ОПР системою і розуміння ними виконання нових процедур. Це потребує розвитку організаційних зобов’язань та інституціалізації (заснування, регламентування) системи.
8.4.1.4. Інституціалізація системи
З урахуванням багатьох факторів, які протидіють успішному впровадженню, розробникам разом з менеджерами потрібно планувати поступову інституціалізацію системи. Наприклад, форма, в якій система буде подана, буде вирішальною. Якщо незаінтересованим особам пропонується система для добровільного використання, то СППР напевно не буде корисною. Добровільне використання відбудеться тільки тоді, коли особи будуть мати інтелектуальну зацікавленість до експериментів з системою, або коли потреба в системі і її можливості задовольняти користувацькі вимоги стануть очевидними. З другого боку, адміністратори, які наполягають на «мандатному» використанні СППР, також стикаються з потенційною невдачею. Важко узаконити стиль прийняття рішень. Користувачі можуть насправді не використовувати систему, а тільки запозичувати зовнішній вигляд її затосування. Інші можуть наполегливо працювати з тією метою, щоб знайти слабкі місця в системі і довести, що вона не варта витраченого часу.
Кращим підходом до інституціалізації системи є забезпечення стимулів для її використання. Зрозуміло, що відповідний для цього стимул буде, зазвичай, відрізнятися від додатку до додатку і від організації до організації. Однак не обов’язково, щоб сти­мули були розроблені детально, або були фінансовими. Наприклад, стимулом може бути пробудження заінтересованості у забезпеченні інформацією тільки від СППР, або, передусім, від СППР. Якщо система добре спроектована, то її слід потім продавати, виходячи з корисності в процесі прийняття рішень.
Коли мотивування системи сприяє посиленню уваги деяких осіб до СППР, то ці особи можуть допомогти іншим відчути переваги використання СППР. Ентузіасти можуть демонструвати вигоди системи іншим в їх роботі чи забезпечувати неформальні стимули для її використання. Фактично, це є доказом того, що вербальний метод інституалізації системи є одним з кращих.
Пов’язаною з потребою мотивування для інституціалізації системи, зазвичай, є потреба в підготовці. Оскільки не всі потенційні користувачі можуть бути залучені до процесу розроблення, то деякі користувачі не будуть знати, як діє СППР або чому вона функціонує в певний спосіб, і отже, вони потребуватимуть навчання. Ефективною формою є навчання один-на-один, що дає змогу викладачам працювати з окремими особами для отримання ними специфічних знань про роботу СППР. Зокрема, це може бути урок щодо використання маніпулятора миші, або короткий огляд можливостей Інтернету, чи інших необхідних технологій,
з якими незнайома певна ОПР. Викладачі мають гарантувати, що
програма містить інформацію та навички, необхідні для виконання специфічних завдань. Наприклад, навчання може включати інструкції стосовно того, як знайти нові БД, або як об’єднувати моделі.
8.4.2. Оцінювання впровадження системи
Питання про те, як розробник може знати, коли СППР і її впровадження буде успішним, є досить складним і неоднозначним. По суті, воно зводиться до вибору параметрів і методики оцінювання СППР. Як уже зазначалося раніше, оцінювання СППР має проводитися на всіх етапах її розроблення. Проте найскладніше оцінити успішність саме процесу впровадження системи. Зокрема, це оцінювання має визначати, як СППР допомагатиме організації добувати додаткові ресурси і як вона буде сприяти поліпшенню використання обмежених ресурсів; як СППР впливатиме на ефективність функціонування організації в цілому завдяки її впровадженню тощо. СППР можна оцінювати показниками почат­кових витрат або вигід для організації, але жоден із цих двох фак-
торів не допомагає проектувальникам зробити систему кращою, тим більше, що як було уже доведено раніше, техніко-економічний аналіз проекту СППР проводити практично неможливо.
Узагалі, СППР має допомагати у виявленні інформаційних потреб ОПР, бути простою у використанні, надавати можливості для проведення досліджень, забезпечувати інтелектуальну підтримку і бути легкою для реалізації всіх її функцій. Як службова, призначена для підтримки прийняття рішень ця система має також задовольняти потреби у створенні рішень, відповідати організаційним обмеженням та бути прийнятною для користувачів. Отже, щоб упровадження було успішним, розробник має спрямовувати зусилля на технічну і організаційну придатності СППР.
Технічна відповідність (придатність)
Якщо технічні вимоги і потреби користувачів у СППР не задовольняються, то система не буде використовуватись. Якщо система не використовується, тоді впровадження буде невдалим. Отже, одним із можливих вимірів визначення успіху впровадження є рівень використання СППР, особливо в порівнянні з призначеним використанням. Разом з тим прагматичнішою оцінкою може бути низка характеристик, відповідних інформаційним потребам користувачів, особливо в зіставленні з множиною можливих властивостей інформації на виході СППР (своєчасністю, достатністю, рівнем деталізації та агрегації, резервуванням (надлишковістю), зрозумілістю, незалежністю від упередження, надійністю, релевантністю для рішень, ефективністю витрат на інформацію, порівнюваністю, можливістю квантифікації, відповід­ністю формату). Якщо система забезпечує інформацією, яка є сумісною з потребами створення рішень за всіма вимогами до інформації, то вона матиме успіх.
СППР має також забезпечувати потреби у зміні моделей і щодо певних операцій для керування ними, таких, наприклад, як інтелектуальна допомога й інтегрування моделей. Якщо система забезпечує відповідні модифікації моделей і можливості керування ними, то вона буде вважатися вдалою.
Багато аспектів можуть бути протестовані індивідуально. Однак на відміну від взаємодіючих систем оброблення даних, СППР ніколи не може бути повністю протестована з урахуванням усіх можливих випадків, тим більше, що бувають непередбачувані обставини. Розробники не можуть передбачити всі випадки, для яких ОПР будуть використовувати систему, і тому вони не можуть гарантувати, що система буде функціонувати як слід завжди. Тому також обов’язково деякі тести мають проводитися безпосередньо потенційними користувачами.
Щоб оцінити систему в цілому, розробник має оцінити її корисність для розв’язання задач і визначити, чи полегшує система логічний аналіз проблем. По-перше, це може бути визначене ОПР за тестування системи. Необхідно мати досвідчених творців рішень протягом фази тестування. Вони мають використовувати систему і визначати, чи забезпечує вона обґрунтовані поради і пропозиції для ситуації, що розглядається. Якщо так, то функціонування може бути оцінене як правильне. Ознаки недостатньої ефективності СППР можуть бути виявлені, коли ОПР знайдуть помилки в порадах або незвичні кроки у здійснюваному за допомогою СППР аналізі. Інколи ці ознаки можуть бути фактичними проблемами програмного забезпечення, якому потрібний супровід, інколи вони пов’язані з неінтуїтивним підходом до аналізу, що може потребувати для цих цілей більше вікон допомоги або ширшого використання засобів штучного інтелекту.
Ще один шлях тестування системи — модифікований тест Тюрінга. Оригінальний тест був створений англійським ученим-
комп’ютерником Аланом Тюрінгом, щоб вимірювати чи має
комп’ютерна система властивості «штучного інтелекту». Тест Тюрінга потребував, щоб людина-інтерв’юер одночасно «проводила бесіду» з обома невидимими — людиною і комп’ютером — на певну тему. Якщо інтерв’юер не міг визначити, коли він розмовляв з людиною, а коли з комп’ютером, то комп’ютерна система вважалася системою «штучного інтелекту». Якщо було очевидно, що відповідає комп’ютер, тоді тестування системи вважалося невдалим. Для цього тесту потребувалося багато людей. Він є непідхожим для оцінювання СППР. Однак, модифікований тест Тьюрінга забезпечує оцінювання певної адекватності аналізу і порад, що надає система.
Мета цього тесту — визначити, чи забезпечує система потрібні поради і аналіз, що є сумісними з тими, які міг би зробити досвідчений аналітик. Перед тестом експерта-аналітика просять прокоментувати рішення або пояснення для ситуації, яку ОПР використовує для роботи з СППР. Ці людські експертні рішення або пояснення змішуються з тими, які були згенеровані СППР. ОПР забезпечують двома рішеннями або поясненнями проблеми і просять їх порівняти. Якщо ОПР не бачать відмінностей між відповіддю людини і комп’ютера, то СППР вважається добре функціонуючою. Для цього потрібно розробити деякі форми зіставлення результатів роботи СППР і тих, які розробив досвідчений аналітик.
Є й інші заходи, за допомогою яких проектувальники визначають, коли система оцінена як вдала. Деякі розробники перевіряють, якою мірою система відповідає первинній меті. Інші визначають кількість разів використання системи як критерій її ефективності. Однак мають місце проблеми, пов’язані з такими оцінюваннями. По-перше, як реально виміряти використання СППР? Кількість натискань на клавіші та інші механізовані вимірювання показують тільки кількість разів, коли користувач викликає специфічні команди. Кількість разів, коли система викликалася, свідчить дуже мало про те, скільки і як добре СППР сприяла процесу вибору рішень. ОПР можуть викликати команди багато разів, щоб упевнитися, що команда буде виконана так само кожного разу, або тому, що вони забули, що вже це робили. У таких випадках багаторазове використання може не відображати важливості системи або її невикористання для ОПР. Також, мала кількість використань може не відображати меншу важливість або недостатнє використання. Наприклад, іноді просто перегляд аналізу один раз може ініціювати творче розв’язання проблеми, що інакше буде неочевидним і не спонукатиме до прийняття відповідного рішення.
Оскільки електронний моніторинг використання СППР може мати щойно описані недоліки та труднощі, то можливе оцінювання системи шляхом отримання звітів про використання СППР. Якщо розробники СППР повністю довіряють користувачам оцінити використання системи, то вони можуть отримати помилкову інформацію. Більшість ОПР дуже зайняті розв’я­занням своїх задач, щоб точно знати, як багато або як мало вони використовують інструментальний засіб типу СППР. Якщо ОПР налаштовані доброзичливо до впроваджуваної системи, то вони будуть схильними оцінювати її позитивно; якщо ж вони негативно сприймають таке впровадження, то і їх оцінка буде відповідною. Нарешті, навіть якщо ми зможемо виміряти використання точно, то воно не буде еквівалентним корисності, оскільки доведено, що використання системи не корелює (тобто немає тісного зв’язку) з корисністю СППР, а отже, не забезпечує надійності вимірювання ефективності системи.
Для розв’язання цієї проблеми існують інші методи оцінювання, що задовольняють користувача. Логіка, що є її основою, полягає в тому, що СППР можна вважати ефективною тоді, якщо вона зробить користувачів задоволеними роботою системи. Багато порад було створено для того, щоб визначати, чи задоволені користувачі системою. Було проведено дослідження великої кількості підходів, які використовувались для вимірювання задоволення творців рішень від своєї СППР. Було виявлено приблизно 40 факторів, якими можна описати задоволення ОПР системою.
У той час, як надійне оцінювання можна було б зробити за допомогою запитань стосовно індивідуального задоволення користувачів кожним фактором, багато користувачів не бажають витрачати час, щоб відповідати на ці запитання. Крім того, кори­стувачі схильні до узагальнення цих факторів (як наприклад, легкість використання) і можуть відповідати про свій перший, останній чи типовий досвід скоріше, ніж про весь досвід загалом. Однак цей метод досить ефективний у процесі розроблення, якщо розробники використовують прототипи. Якщо користувачів опитують відносно специфічних технічних характеристик системи періодично (а не тільки в кінці процесу проектування), то ОПР і розробники можуть визначити компоненти системи, які функціонують добре, а які — гірше. Це потім приведе до кращого розроблення і в перспективі — до більшого задоволення від системи.
Організаційна відповідність (придатність)
Організаційна відповідність СППР може означати, що система має стати компонентом загальної системи організації. Щоб це зробити, потрібна підтримка стилю рішень користувачів і способів, якими ці стилі рішень змінюються з часом. Крім того, потрібна відповідність щодо організації, в якій СППР функціонує. Це має забезпечувати певні рівні захисту інформації і використовуватись згідно з корпоративною політикою, а також забезпечувати інформацією відповідно до очікувань користувачів. Так само як нові найняті працівники мають пристосовуватися до відділу і організації, має це робити також система. Це може означати відповідність інтерфейсу користувача, відповідність готовності даних, відповідність методологій моделювання стилю прий­няття рішень в організації. Якщо система не пристосувалася до відділу, то, напевно, вона буде «страждати» так само, як найманий працівник, що не зміг пристосуватися, а отже, вона не буде впроваджена.
Зокрема, відповідність упровадження можна оцінити визначенням управлінських характеристик стосовно системи; тим, як добре задовольняються інформаційні потреби менеджерів; впливом проекту на комп’ютерні операції фірми. Ці оцінки відображують сприйняття системи. Крім того, всі вони визначаються після впровадження системи. Отже, їх не можна застосовувати для планування і до впровадження всього проекту. Кращий метод — оцінити різні типи не технічних можливостей. СППР має також пристосуватися в потрібних місцях, визначених організацією. Наприклад, уважається, що СППР буде вдалою, якщо вона: пристосовується до методів планування організації; допомагає обдумувати проблему звичними для ОПР способами; покращує хід роздумів ОПР про проблеми; добре пристосовується до політики створення рішень; використовує результати здійснюваних альтернатив; ефективна щодо витрат і цінна відносно коштів; очікується, що буде використовуватися протягом тривалого часу. Інакше кажучи, СППР має взаємодіяти з іншими системами в організації. Навіть якщо СППР значно полегшує прийняття рішень, вона не може бути вдалою, якщо не полегшує передбачувані кроки рішень або іншої діяльності.

Страницы [ 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-2017 BPK Group.