АвтоАвтоматизацияАрхитектураАстрономияАудитБиологияБухгалтерияВоенное делоГенетикаГеографияГеологияГосударствоДомДругоеЖурналистика и СМИИзобретательствоИностранные языкиИнформатикаИскусствоИсторияКомпьютерыКулинарияКультураЛексикологияЛитератураЛогикаМаркетингМатематикаМашиностроениеМедицинаМенеджментМеталлы и СваркаМеханикаМузыкаНаселениеОбразованиеОхрана безопасности жизниОхрана ТрудаПедагогикаПолитикаПравоПриборостроениеПрограммированиеПроизводствоПромышленностьПсихологияРадиоРегилияСвязьСоциологияСпортСтандартизацияСтроительствоТехнологииТорговляТуризмФизикаФизиологияФилософияФинансыХимияХозяйствоЦеннообразованиеЧерчениеЭкологияЭконометрикаЭкономикаЭлектроникаЮриспунденкция

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

Читайте также:
  1. IV. СОЦІАЛЬНЕ ЗАБЕЗПЕЧЕННЯ, ЖИТЛОВО-ПОБУТОВЕ ТА МЕДИЧНЕ ОБСЛУГОВУВАННЯ
  2. VI. Вплив виборчих систем на політичні системи
  3. А. Чандлер, Дж. Томсон, П. Лоуренс, Дж. Лорш і дослідження впливу зовнішнього середовища на організацію.
  4. Аналіз витрат на обслуговування виробництва
  5. Аналіз впливу збутової діяльності на прибуток підприємства
  6. Аналіз факторів, що впливають на зміну товарних запасів
  7. Аналіз факторів, що впливають на рівень фінансово-економічних ризиків
  8. Аналіз факторів, що впливають на цінову політику підприємства
  9. Антропогенний вплив.
  10. Антропогенний вплив.
  11. Аудиторія є головним об'єктом аргументативного впливу в спорі.
  12. Бар, який зазвичай працює в ночі , обслуговування здійснюється через офіціантів, комплектується бар, в основному, жіночим персоналом називають...

Заміна застарілих процесів новими називається перепроек­туванням бізнес-процесу (business process redesignBPR). Часто використовується також термін «реінжиніринг бізнес-процесу» (business process reengineering), що має таку ж англомовну абревіа­туру — BPR. Цей термін був започаткований Хаммером 1990 року, щоб позначати ним радикальне повторне розроблення бізнес-про­цесів з метою досягнення відчутних продуктивних удосконалень. Повторне проектування або розроблення, зазвичай, використовує су­часну інформаційну технологію і змінює фокус за створення рішень так, щоб це охопило функціональні й відомчі контури організації.

У загальному випадку BPR потребує: організації певних дій сто­совно наслідків (а не завдань); створення рішень з погляду підви­щення продуктивності праці; розроблення відповідних заходів щодо контролю; однократного «захоплення» інформації з її джерела.

BPR впливає на інформаційні послуги (ІП) двома шляхами. По-перше, ОПР може застосувати BPR для перепроектування ос­нованих на комп'ютерах систем (інформаційних систем), які не можуть більше підтримуватися ординарним супроводом. Такі си­стеми називають успадкованими (legacy systems) через те, що во­ни дуже цінні, щоб їх відкидати, але потребують значних витрат ресурсів інформаційного обслуговування. По-друге, коли фірма застосовує В PR до головних операцій, то зусилля на це незмінно закінчується перепроектуванням інформаційних систем.

Інформаційне обслуговування організацій має три методики для застосування BPR до інформаційних систем. Вони відомі як три R — reverse engineering (зворотний інжиніринг), restructuring (реструктуризація) і reengineering (реінжиніринг), які можуть бути застосовані окремо або в комбінації.

Зворотний (реверсивний) інжиніринг. Щодо використання в комп'ютеризації це є процес аналізування системи з метою іденти­фікувати елементи і їхні взаємозв'язки, а також для створення до­кументації на вищому рівні абстракції, ніж вона є в даний момент. Реверсивний інжиніринг застосовується до системи, коли є потреба в тому, щоб підготувати нову документацію. Дуже часто взагалі не­має документації. Зворотний інжиніринг слідує за зворотним марш­рутом через життєвий цикл системи, реконструюючи проект систе-


ми і планування, що увійшло в первинний варіант розроблення. Ре­зультатом цього є повністю документована система.

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

Реструктуризація (Restructuring) — це перетворення систе­ми в іншу форму без зміни функціональних можливостей. При­кладом її є трансформація програми, яка писалася протягом пер­ших років комп'ютеризації, коли було кілька програмних стан­дартів, в один структурний формат єрархічних модулів. Як тільки програма повністю повторно структурована, вона приймається до використання на своєму місці. Як і за реверсивного інжинірингу, реструктуризація здійснюється в зворотному напрямку, проходя­чи через кожну фазу життєвого циклу системи. Результатом є пов­ністю структурована система від плану до кодів.

Реінжиніринг (Reengineering) — це комплексне перепроек­тування системи з метою зміни функціональних можливостей. Це не є підхід «з чистого листка» через те, що первинна система не ігнорується. Первинний варіант системи спершу змінюється в ході реверсивного інжинірингу. В такому разі нова система роз­робляється звичайним способом. Назва прямий інжиніринг (forward engineering) процесу означає слідування за життєвим циклом системи звичайним способом.

Компоненти BPR (три R) можна застосовувати окремо або в комбінаціях, залежно від ступеня необхідної зміни. Відповідне змі­шування залежить від поточного стану системи, її функціональної та технічної якості. Функціональна якість є мірою того, що система може виконувати, а технічна — у який спосіб це здійснюється.

СППР і РБП

Розглянемо реінжиніринг бізнес-процесу (РБП) стосовно його співвідношення з проектом СППР. Оскільки РБП має вплив на створення рішень і використання технології, то резонно виникає за­питання: «Чи є зв'язок між проектом СППР і РБП?». Зокрема, Сау-тер ставить і дає відповіді на такі три запитання [103]:

1) Чи є розроблення СППР одночасно реінжинірингом бізнес-процесу?


2) Чи потребує розроблення проекту СППР також здійснення
РБП?

3) Чи може проектування СППР полегшити РБП?
Відповіддю на перше запитання є: проектування СППР не є

тим самим, що і реінжиніринг бізнес-процесів. Хоч відповідні технології і швидке розроблення дають змогу досягнути однако­вої мети в обох випадках, проте, як цілі їх аналізу, так і очікувані результати суттєво відрізняються.

Реінжиніринг бізнес-процесу за своєю суттю фокусується на ос­новних видах діяльності відділу або процесах організації, які необ­хідно завершити і вдосконалити, та на видах діяльності, що вдоско­налюють хід дій в організації. Це могло б, звичайно, включати аналіз того, яка інформація і які моделі є доступними і для кого, але ймовір­ніше зосередження має бути на тому, хто розробляє рішення, як де­централізувати процес створення рішень і які засоби управління слід передбачити для гарантування того, що все це відбудеться добре.

Замість цього СППР зосереджені на процесі, яким створюють­ся рішення. Подібно до реінжинірингу бізнес-процесу, проекту­вання СППР не ставить за мету зниження витрат. Скоріше, ме­тою є отримання кращої альтернативи у процесі розроблення рішення, наслідком якої є зменшення витрат і збитків. Крім того, досконалий проект СППР подібно ефективному реінжинірингу бізнес-процесу може мати побічну вигоду за рахунок удоскона­лень у корпоративній продуктивності через те, що створення рі­шень удосконалюється. Є паралелі, але СППР і РБП являють со­бою по суті два різні види діяльності.

Друге запитання: Чи потребує розроблення проекту СППР та­кож РБП? Не завжди. Інколи проектувальники і творці рішень ма­ють намір за допомогою СППР тільки вдосконалити доступ до да­них і моделей, а не робити генеральні зміни в тому, як вико­нуватимуться операції. У такому разі реінжиніринг не є важливим компонентом проекту СППР. Однак інколи розроблення СППР здійснюється в такому напрямі, що вона стає частиною корпоратив­ного стратегічного рішення. У такому разі за створення СППР ви­значають потреби, що пов'язані з реінжинірингом процесу прийнят­тя рішень. Процес проектування дає змогу розробникам і ОПР так само одночасно думати про процес прийняття рішень за допомогою розгляду того, що творцям рішень явно потрібно знати і як їм має надаватися необхідна інформація, тобто у такий спосіб надається можливість природним шляхом оцінювати альтернативи та ін.

Третє запитання: Чи може розроблення СППР полегшити РБП? Так! СППР може бути засобом, який спрощує зусилля реінжинірин-


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

8.2. Загальна схема, методологія SOLC та технології створення СППР

8.2.1. Загальна схема процесу створення СППР

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


Рис. 8.1. Загальна схема створення СППР

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

Друга фаза — проектування та впровадження СППР — пов'я­зана з вибором структури і проектуванням функцій системи. На цьому етапі можна виділити чотири головні кроки: вибір виду сис-


теми і дослідного зразка, конструювання бази моделей, бази даних і діалогу. Детальна схема другої фази зображена на рис. 8.2.

Рис. 8.2. Детальна схема другої фази створення СППР

Вибір виду системи і дослідного зразка її застосування охоплює досить широкий діапазон функцій СППР, які у певний спосіб реалі­зують очікування ОПР стосовно підтримки його дій у контексті при­йняття рішень. Цей вибір здійснюється за умов можливості формалі-


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

Рис. 8.3. Схема вибору виду СППР

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


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

Другий шлях вибору стосується процесу впровадження. Розроб­лення сценарію можливих змін зумовлене реалістичним розглядом сподівань, що очікують від СППР замовник і проектувальник, а та­кож інтенсивністю участі сторін, залучених до процесу створення СППР. Результат виконання цього кроку може бути тісно пов'язаний з результатом аналізу управлінських проблем. Наприклад, якщо ре­зультатом аналізу є рекомендації щодо побудови великої системи, але важко отримати відповідну підтримку керівництва і необхідні кошти, то тоді можна повторити ітерацію спочатку, намагаючись одержати підтримку і кошти; повторити аналіз рішень з урахуванням нових обмежень, які стосуються пошуку найкращого рішення. Слід зауважити, що проектувальник не має ігнорувати другий шлях чи од­ну із названих ітерацій. У лівій частині схеми увага концентрується на раціональних міркуваннях проектувальника, в той час як справа наведені, насамперед, психологічні та організаційні аспекти.

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

Заключна фаза процесу створення СППР — оцінювання ви­користання і формування можливих вимог щодо дальших змін як у процесі прийняття рішень, так і у функціях СППР.

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



 


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

Детальна схема проектування СППР на основі СППР-адап-тованої методології розроблення життєвого циклу системи (System Development Life CycleSDLC) об'єднує сім стадій, які, у свою чергу, поділяються на окремі послідовно або паралельно виконувані роботи: 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. Перевірка стану системи і складання річних планів експлуатації та обслуговування.


8.2.3. Використання СППР-генераторів для створення специфічних СППР

Як уже зазначалося, з метою прискорення розроблення специфічних систем підтримки прийняття рішень проектуваль­ники використовують комерційно доступні найновіші засоби і технології. Ці інструментальні засоби і технології об'єднуються загальним поняттям «генератори СППР» або «СППР-генерато-ри». Раніше була описана сутність СППР-генераторів і наведені деякі відповідні програмні продукти. Питання полягає в тому, у який спосіб можна оцінити наявні додатки з метою створення при­кладної СППР, якими можливостями СППР-генератори мають бу­ти забезпечені з погляду їх відповідності потребам користувачів. Найґрунтовніші рекомендації щодо цього наводить Vicki Sauter у навчальному посібнику «Decision Support Systems: An Applied Managerial Approach» 1997 року (С. 293—303). До речі, достатньо змістовна інформація та джерела з проектування СППР розміще­ні на Web-сторінці цього автора — http://www.umsl.edu/~sauter/ DSS/design.html.

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


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 | 51 | 52 | 53 | 54 | 55 | 56 | 57 | 58 | 59 | 60 | 61 | 62 | 63 | 64 | 65 | 66 | 67 | 68 | 69 | 70 | 71 | 72 | 73 | 74 | 75 | 76 | 77 | 78 | 79 | 80 | 81 | 82 | 83 | 84 | 85 | 86 | 87 | 88 | 89 | 90 | 91 | 92 | 93 | 94 | 95 | 96 | 97 | 98 | 99 | 100 | 101 | 102 | 103 | 104 | 105 | 106 | 107 | 108 | 109 | 110 | 111 | 112 | 113 | 114 | 115 | 116 | 117 | 118 | 119 | 120 | 121 | 122 | 123 | 124 | 125 |

Поиск по сайту:



Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав. Студалл.Орг (0.009 сек.)