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

Заміна застарілих процесів новими називається перепроек­туванням бізнес-процесу (business process redesign — BPR). Часто використовується також термін «реінжиніринг бізнес-процесу» (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 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. Перевірка стану системи і складання річних планів експлуатації та обслуговування.

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

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

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

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