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

Главная

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

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

Форум

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

Карта сайта

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

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


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

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

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

Страницы [ 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.1.5. Проектування СППР
і реінжиніринг бізнес-процесів

Реінжиніринг бізнес-процесів і його вплив
на інформаційне обслуговування

Заміна застарілих процесів новими називається перепроек­туванням бізнес-процесу (business process redesign — BPR). Часто
використовується також термін «реінжиніринг бізнес-процесу» (business process reengineering), що має таку ж англомовну абревіатуру — BPR. Цей термін був започаткований Хаммером 1990 року, щоб позначати ним радикальне повторне розроблення бізнес-про­цесів з метою досягнення відчутних продуктивних удосконалень. Повторне проектування або розроблення, зазвичай, використовує су­часну інформаційну технологію і змінює фокус за створення рішень так, щоб це охопило функціональні й відомчі контури організації.
У загальному випадку BPR потребує: організації певних дій стосовно наслідків (а не завдань); створення рішень з погляду підвищення продуктивності праці; розроблення відповідних заходів щодо контролю; однократного «захоплення» інформації з її джерела.
BPR впливає на інформаційні послуги (ІП) двома шляхами. По-перше, ОПР може застосувати BPR для перепроектування основаних на комп’ютерах систем (інформаційних систем), які не можуть більше підтримуватися ординарним супроводом. Такі системи називають успадкованими (legacy systems) через те, що вони дуже цінні, щоб їх відкидати, але потребують значних витрат ресурсів інформаційного обслуговування. По-друге, коли фірма застосовує BPR до головних операцій, то зусилля на це незмінно закінчується перепроектуванням інформаційних систем.
Інформаційне обслуговування організацій має три методики для застосування BPR до інформаційних систем. Вони відомі як три Rreverse engineering (зворотний інжиніринг), restructuring (реструктуризація) і reengineering (реінжиніринг), які можуть бути застосовані окремо або в комбінації.
Зворотний (реверсивний) інжиніринг. Щодо використання в комп’ютеризації це є процес аналізування системи з метою ідентифікувати елементи і їхні взаємозв’язки, а також для створення документації на вищому рівні абстракції, ніж вона є в даний момент. Реверсивний інжиніринг застосовується до системи, коли є потреба в тому, щоб підготувати нову документацію. Дуже часто взагалі немає документації. Зворотний інжиніринг слідує за зворотним маршрутом через життєвий цикл системи, реконструюючи проект системи і планування, що увійшло в первинний варіант розроблення. Результатом цього є повністю документована система.
Однак система після виконує такі самі операції, які оригіна­льно були розроблені на початку проектування. Реверсивний інжиніринг не змінює функціональних можливостей системи, тобто функцій, які вона виконує. Скоріше, його мета полягає в тому, щоб краще зрозуміти систему та уможливити створення змін іншими засобами, зокрема, реструктуризацією або реінжинірингом.
Реструктуризація (Restructuring) — це перетворення системи в іншу форму без зміни функціональних можливостей. Прикладом її є трансформація програми, яка писалася протягом перших років комп’ютеризації, коли було кілька програмних стан­дартів, в один структурний формат єрархічних модулів. Як тільки програма повністю повторно структурована, вона приймається до використання на своєму місці. Як і за реверсивного інжинірингу, реструктуризація здійснюється в зворотному напрямку, проходячи через кожну фазу життєвого циклу системи. Результатом є пов­ністю структурована система від плану до кодів.
Реінжиніринг (Reengineering) — це комплексне перепроектування системи з метою зміни функціональних можливостей. Це не є підхід «з чистого листка» через те, що первинна система не ігнорується. Первинний варіант системи спершу змінюється в ході реверсивного інжинірингу. В такому разі нова система розробляється звичайним способом. Назва прямий інжиніринг (forward engineering) процесу означає слідування за життєвим циклом системи звичайним способом.
Компоненти BPR (три R) можна застосовувати окремо або в комбінаціях, залежно від ступеня необхідної зміни. Відповідне змішування залежить від поточного стану системи, її функціональної та технічної якості. Функціональна якість є мірою того, що система може виконувати, а технічна — у який спосіб це здій­снюється.
СППР і РБП
Розглянемо реінжиніринг бізнес-процесу (РБП) стосовно його співвідношення з проектом СППР. Оскільки РБП має вплив на створення рішень і використання технології, то резонно виникає запитання: «Чи є зв’язок між проектом СППР і РБП?». Зокрема, Саутер ставить і дає відповіді на такі три запитання [103]:

  1. Чи є розроблення СППР одночасно реінжинірингом бізнес-процесу?
  2. Чи потребує розроблення проекту СППР також здійснення РБП?
  3. Чи може проектування СППР полегшити РБП?

Відповіддю на перше запитання є: проектування СППР не є тим самим, що і реінжиніринг бізнес-процесів. Хоч відповідні технології і швидке розроблення дають змогу досягнути однакової мети в обох випадках, проте, як цілі їх аналізу, так і очікувані результати суттєво відрізняються.
Реінжиніринг бізнес-процесу за своєю суттю фокусується на основних видах діяльності відділу або процесах організації, які необхідно завершити і вдосконалити, та на видах діяльності, що вдосконалюють хід дій в організації. Це могло б, звичайно, включати аналіз того, яка інформація і які моделі є доступними і для кого, але ймовір­ніше зосередження має бути на тому, хто розробляє рішення, як де­централізувати процес створення рішень і які засоби управління слід передбачити для гарантування того, що все це відбудеться добре.
Замість цього СППР зосереджені на процесі, яким створюються рішення. Подібно до реінжинірингу бізнес-процесу, проектування СППР не ставить за мету зниження витрат. Скоріше, метою є отримання кращої альтернативи у процесі розроблення рішення, наслідком якої є зменшення витрат і збитків. Крім того, досконалий проект СППР подібно ефективному реінжинірингу бізнес-процесу може мати побічну вигоду за рахунок удосконалень у корпоративній продуктивності через те, що створення рішень удосконалюється. Є паралелі, але СППР і РБП являють собою по суті два різні види діяльності.
Друге запитання: Чи потребує розроблення проекту СППР також РБП? Не завжди. Інколи проектувальники і творці рішень мають намір за допомогою СППР тільки вдосконалити доступ до даних і моделей, а не робити генеральні зміни в тому, як вико­нуватимуться операції. У такому разі реінжиніринг не є важливим компонентом проекту СППР. Однак інколи розроблення СППР здійснюється в такому напрямі, що вона стає частиною корпоративного стратегічного рішення. У такому разі за створення СППР визначають потреби, що пов’язані з реінжинірингом процесу прийняття рішень. Процес проектування дає змогу розробникам і ОПР так само одночасно думати про процес прийняття рішень за допомогою розгляду того, що творцям рішень явно потрібно знати і як їм має надаватися необхідна інформація, тобто у такий спосіб надається можливість природним шляхом оцінювати альтернативи та ін.
Третє запитання: Чи може розроблення СППР полегшити РБП? Так! СППР може бути засобом, який спрощує зусилля реінжинірингу. Однією з головних проблем за реінжинірингу є брак необхідних даних. Неможливо спланувати зміни або передбачити їх вплив без відповідної інформації щодо поточних операцій та навколишнього середовища. На жаль, такі дані не є легкодоступними в більшості організацій. Однак СППР може забезпечити доступ адміністраторам до даних і до засобів для їх інтерпретації. За рахунок цього менеджери зможуть створювати обґрунтованіші рішення і краще використовувати моделі шляхом здійснення відомих їм процедур і створення нових кращих альтернативних версій рішення. За допомогою групової технології СППР творці рішень різних функціональних галузей можуть співпрацювати за допомогою розподілення інформації, аналізів і моделей. Використання технологій СППР може дійсно допомогти процесу реінжинірингу бути ефективнішим і продуктивнішим.
8.2. Загальна схема, методологія
SDLC та технології створення СППР

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

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

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

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

Заключна фаза процесу створення СППР — оцінювання використання і формування можливих вимог щодо дальших змін як у процесі прийняття рішень, так і у функціях СППР.
Велика розбіжність у розумінні терміна «СППР», та нечітка визначеність поняття «відповідне рішення проблеми», а також диференціація організаційних обставин приводять до того, що неможливо однозначно встановити, коли і як розпочати процес проектування СППР. Але якщо питання про створення і про початок розроблення СППР прийняте, то для колективу проектувальників може бути досить корисною низка стандартних процедур та методів проектування систем. На рис. 8.4. зображена універсальна за своїм обсягом і структурою SDLC методологія розроблення СППР, подана у вигляді сітьового графіка.



Рис. 8.4. Сітьовий графік проектування СППР


8.2.2. СППР-адаптована методологія
розроблення життєвого циклу системи

Детальна схема проектування СППР на основі СППР-адап­тованої методології розроблення життєвого циклу системи (System Development Life Cycle — SDLC) об’єднує сім стадій, які, у свою чергу, поділяються на окремі послідовно або паралельно виконувані роботи: 1) вивчення опису системи; 2) попереднє про­ектування; 3) детальне проектування; 4) розроблення програм і задач для користувачів; 5) тестування; 6) перетворення даних і впровадження системи; 7) експлуатація і супроводження системи. На рис. 8.4 зображено послідовність виконання окремих робіт кожної стадії. Зауважимо, що кожна стадія розроблення СППР закінчується підготовкою письмового звіту. Опишемо ці роботи.
1.0. Вивчення опису системи: 1.1. Формулювання задачі та визначення обсягу досліджень; 1.2. Збір даних про існуючі методи розв’язання задачі і процедури; 1.3. Аналіз існуючих методів і процедур; 1.4. Розроблення цілей системи і критеріїв оцінювання її характеристик; 1.5. Визначення ресурсів, обмежень, передумов і питань, які потребують розв’язання; 1.6. Специфікація виходів, входів та функцій системи; 1.7. Визначення вимог до можливостей системи і до потенційних підходів щодо її використання; 1.8. Оцінювання і вибір системного підходу; 1.9. Визначення реалізації, вимог до перетворення і можливих змін системи; 1.10. Підготовка зведеного плану і аналіз витрат/вигід пропонованої системи; 1.11. Складання звіту про вивчення опису системи.
2.0. Попереднє проектування: 2.1. Специфікація вимог до розширення системи; 2.2. Визначення навколишнього середовища системи; 2.3. Описання підсистем; 2.4. Розроблення вимог до підсистем введення, виведення та інтерфейсу; 2.5. Побудова блок-схем системи і підсистем; 2.6. Розроблення опису процесів; 2.7. Формування вимог до захисту системи; 2.8. Ідентифікація проблемних галузей інженерної психології; 2.9. Проектування логічної структури бази даних і визначення методів доступу до неї; 2.10. Формування вимог до комунікації даних; 2.11. Специфікація апаратної конфігурації; 2.12. Специфікація програмного забезпечення системи; 2.13. Підготовка плану розроблення і реалізації; 2.14. Складання звіту про попереднє проектування.
3.0. Детальне проектування: 3.1. Розроблення ергономічних процедур; 3.2. Проектування ручних форм і інтерфейсів введення/виведення; 3.3. Проектування фізичної бази даних; 3.4. Розроблення характеристик захисту підсистем; 3.5. Визначення програм для підсистем; 3.6. Розроблення блок-схем і таблиць; 3.7. Фор­мування переліку утиліт і загальних підпрограм; 3.8. Розроблення плану тестування підсистем; 3.9. Складання звіту про детальне проектування.
4.0. Розроблення програм і задач користувачів: 4.1. Синтез описів для підсистем персоналу; 4.2. Розроблення вимог до персоналу і до середовища; 4.3. Розроблення детальних блок-схем програм; 4.4. Кодування програм; 4.5. Підготовка вихідних програм і компіляція/ассемблювання; 4.6. Підготовка даних для налагоджування програм; 4.7. Налагоджування програм; 4.8. Підготовка звіту про програмування і розроблення задач користувача.
5.0. Тестування: 5.1. Розроблення докладного плану і процедур тестування; 5.2. Підготовка місця і встановлення апаратних засобів та допоміжного обладнання; 5.3. Визначення середо­вища, в якому буде проходити випробування системи; 5.4.
Тестування навчальних курсів, допоміжних засобів і ергономічних процедур; 5.5. Побудова тестової бази даних і файлів транзакцій; 5.6. Випробування системи і підсистем; 5.7. Приймально-здавальні випробування; 5.8. Підготовка звіту про результати тестування.
6.0. Перетворення даних і впровадження системи: 6.1. Скла­дання плану і графіка перетворення даних і впровадження системи; 6.2. Навчання операторського персоналу користуванню новою системою, апаратними і програмними засобами; 6.3. Створення інструкцій для користувачів нової системи; 6.4. Виконання перетворення даних; 6.5. Уточнення і переробка інструкції для нової системи; 6.6. Розподіл і навчання персоналу користувачів нової системи; 6.7. Навчання обслуговуючого персоналу за програмним і апаратними засобами та за новою системою; 6.8. Передача системи та документування процесу перетворення даних і її впровадження.
7.0. Експлуатація і супроводження системи: 7.1. Розроблення й контроль найважливіших індикаторів (параметрів); 7.2. Складання графіка обслуговування системи; 7.3. Складання графіка роботи комп’ютера; 7.4. Запобігання відмов у функціонуванні та відновлення його в процесі виконання; 7.5. Перевірка засобів аварійного контролю і планів захисту; 7.6. Оброблення пропозицій щодо змін і підготовка документації про зміни; 7.7. Проведення додаткового навчання; 7.8. Перевірка стану системи і складання річних планів експлуатації та обслуговування.

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