Відображення і моделювання процесів

Таблиця 3.1.

Основні етапи реінжінірінга

Етап	Заходи
Планування і початок робіт	Виявлення головних причин проведення реформи на підприємстві і оцінка наслідків відмови від такої реформи
Виявлення найважливіших процесів, що вимагають реінжінірінга
Виявлення однодумців серед керівництва і створення робочої групи з представників адміністрації
Забезпечення підтримки проекту керівництвом
Підготовка плану проекту: визначення об'єму, позначення вимірних цілей, вибір методології, складання докладного графіка
Узгодження цілей і об'ємів проекту з керівництвом
Формування групи реінжінірінга
Вибір консультантів або зовнішніх експертів
Проведення ввідної наради
Доведення цілей проекту до керівників нижчої ланки; початкове інформування всієї організації
Навчання групи реінжінірінга
Підготовка плану і почало робіт
Дослідження	Аналітичне дослідження досвіду компаній з подібними процесами
Опит клієнтів і контрольних груп для виявлення існуючих і майбутніх вимог
Опит службовців і керівників для виявлення питань; мозковий штурм
Пошук в літературі і пресі даних про тенденції в галузі і про чужий досвід
Оформлення докладних документів на початкові процеси і збір робочих даних; виявлення недоробок
Огляд змін і варіантів технологій
Опит власників і представників керівництва
Відвідини кружків і семінарів
Збір даних від зовнішніх експертів і консультантів
Проектування	Мозковий штурм і вироблення новаторських ідей; вправи по творчому мисленню, щоб "зняти шори"
Опрацьовування сценаріїв "а що, якщо?" і застосування "шаблонів успіху" інших компаній
Створення за допомогою фахівців 3-5 моделей; розробка комплексних моделей, в яких зібрано краще від кожної з попередніх
Створення картини ідеального процесу
Визначення моделей нового процесу і їх графічне уявлення
Розробка організаційної моделі в поєднанні з новим процесом
Визначення технологічних вимог; вибір платформи для нових процесів
Виділення короткострокових і довгострокових заходів
Твердження	Аналіз витрат і переваг; розрахунок прибутку на капітал
Оцінка впливу на клієнтів і службовців; оцінка впливу на конкурентоспроможність
Підготовка офіційного документа для вищого керівництва
Проведення оглядових нарад для ознайомлення і затвердження деталей проекту оргкомітетом і вищим керівництвом
Впровадження	Завершення докладної розробки процесів і організаційних моделей; визначення нових робочих обов'язків
Розробка систем підтримки
Реалізація попередніх варіантів і первинні випробування
Ознайомлення працівників з новим варіантом; розробка і здійснення плану реформи
Розробка поетапного плану; впровадження як таке
Розробка плану навчання; навчання працівників новим процесам і системам
Подальші заходи	Розробка заходів щодо періодичної оцінки; визначення підсумків нового процесу; впровадження програми безперервного вдосконалення нового процесу
Надання остаточного звіту оргкомітету і адміністрації

На сьогодні набули поширення три основні методології функціонального моделювання (і супутній їм інструментарій): IDEF (Integrated DEFinition), UML (Unified Modeling Language) і ARIS (Architecture of Integrated Information Systems). Для кожної з них існують певні програмні продукти, які крім розробки дозволяють проводити перетворення і операції для подальшої роботи з одержаними моделями. Найбільшого поширення сьогодні набули методології IDEF і програмні продукти BPWin, що містять методології IDEF0, IDEF3, DFD (Data Flow Diagrams) і ERWin (IDEF1x) від компанії Computer Associates.

Історія IDEF починається з 70-х років ХХ століття з методології SADT (Structured Analysis and Design Technique), розробленої Дугласом Росом (Softtech INC). Спочатку SADT застосовувалося Міністерством оборони США для практичного моделювання процесів в рамках програми ICAM (Integrated Computer Aided Manufacturing). Принциповою вимогою при розробці даного сімейства методологій була можливість ефективного обміну інформацією між всіма фахівцями - учасниками програми ICAM (Icam DEFinition). У подальшому ця методологія була трансформована в стандарт IDEF0 (Function Modeling, FIPS №183). Сімейство IDEF включає вже згадані IDEF3 (Process Description Capture) і IDEF1x (Data Modeling, FIPS №184).

Після публікації стандарти були успішно застосовані в самих різних областях бізнесу, показавши себе ефективним засобом аналізу, конструювання і відображення процесів бізнесу (доречно зауважити, вони активно застосовується і у вітчизняних держструктурах, наприклад, в Державній Податковій Інспекції). Більш того, власне з широким застосуванням IDEF (і попередньої методології SADT) і зв'язано виникнення основних ідей популярного нині поняття "реінжінірінг процесів бізнесу" (Business Process Reengineering - BPR).

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

Робота з використанням методу IDEF починається з постановки мети моделювання. Світовий досвід свідчить, що помилки при постановці мети приводять в середньому до 50% невдач в процесі моделювання. Формулювання мети спочатку направляє роботу в заданому напрямі, а значить, обмежує круг питань для аналізу. Практична робота починається з визначення контексту (Context, Context Diagram), тобто верхнього рівня системи, в нашому випадку - підприємства. Після формулювання мети необхідно обкреслити область моделювання (Scope), яка в подальшому визначатиме загальні напрями руху і глибину деталізації (Decomposition). Власне, сама методологія IDEF визначає стандартизовані об'єкти для роботи і відображення. Наприклад, до таких відносяться функція (Activity), інтерфейсна дуга (Arrow), замітка (Note), а також спосіб їх розташування і трактування (Semantics).

Останнім часом на російському ринку з'явився програмний продукт Business Studio, який спеціально створений для роботи з методами IDEF і володіє інтуїтивним і дружнім інтерфейсом (User-friendly Interface).

У основі нотації і методології IDEF0 лежить поняття "блоку", тобто прямокутника, який виражає деяку функцію бізнесу (рис. 3.10). Відповідно до стандарту функція повинна бути виражена дієслівним оборотом. У IDEF0 ролі сторін прямокутника (функціональні значення) різні: верхня сторона має значення "управління", ліва - "вхід", права - "вихід", нижня - "механізм виконання".

Рис. 3.10. Базовий блок методології IDEF0

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

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

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

І, нарешті, "третім китом" методології IDEF0 є принцип функціональної декомпозиції блоків, який є модельною інтерпретацією тієї практичної ситуації, що будь-яка дія (тим більше таке складне, як бізнес-процес) може бути розбита (декомпозовано) на простіші операції (дії, бізнес - функції). Або, іншими словами, дія може бути представлена як сукупність елементарних функцій.

Приклад функціональної моделі процесу відвантаження і доставки продукції показаний на рис. 3.11.

Ступінь формалізації опису процесів бізнесу може бути різним залежно від вирішуваних при цьому задач. Для опису інформаційних процесів розроблена спеціалізована мова BPEL (Business Process Execution Language). BPEL створений на основі XML для формального опису процесів бізнесу і протоколів їх взаємодії між собою. BPEL розширює модель взаємодії Web-служб і включає в цю модель підтримку транзакцій.

Рис. 3.11. Приклад функціональної моделі процесу відвантаження і доставки

В даний час активно розвивається методологія BPMS (Business Process Management System) - клас програмного забезпечення для управління процесами бізнесу і адміністративними регламентами. (Уживаються також терміни "BPM-система" і просто "BPM"). Застосування BPMS дозволяє організувати ефективну взаємодію між управлінцями і ІТ-фахівцями, краще використовувати існуючі підсистеми і прискорити розробку нових.

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

Сучасні методи розробки і розвитку програмного забезпечення ІС повною мірою прагнуть орієнтуватися на можливості автоматизованого оперативного внесення змін. Найбільш складним виявився процес стандартизації мови BPEL для уніфікації використання одних і тих же конструкцій програмним забезпеченням різних виробників. Фірми IBM і Microsoft визначили дві досить-таки схожі мови: WSFL (Web Services Flow Language) і Xlang відповідно.

Зростання популярності BPML і відкритий рух BPMS до користувачів привело корпорації Intalio Inc., IBM і Microsoft до рішення об'єднати ці мови в нову мову BPEL4WS. У квітні 2003 року корпорації BEA Systems, IBM, Microsoft, SAP і Siebel Systems передали BPEL4WS версії 1.1 в OASIS (Organization for the Advancement of Structured Information Standards) для стандартизації в Web Services BPEL Technical Committee. Хоча BPEL4WS з'явився у версіях 1.0 і 1.1, технічний комітет WS-BPEL OASIS проголосував 14 вересня 2004 року за те, щоб назвати специфікацію WS-BPEL 2.0. Цю зміну було зроблено, щоб вирівняти BPEL з іншими стандартами Web-сервісів за угодою про іменування починаються на WS-.

У червні 2007 року корпорації Active Endpoints, Adobe, BEA, IBM, Oracle і SAP опублікували специфікації BPEL4People і WS-HumanTask, в яких описувалося, як може бути реалізовано в BPEL взаємодію з людьми. Про подальший напрям розробки BPEL розгорається жарка дискусія. Передбачається додавання семантики в BPEL у формі WS-HumanTask і інших різноманітних доповнень.

Читайте також:

<== попередня сторінка	\|	наступна сторінка ==>
Реінжинирінг процесів бізнесу	\|	Забезпечення процесу аналізу і проектування ІС можливостями CASE-технологій

Не знайшли потрібну інформацію? Скористайтесь пошуком google:

Генерація сторінки за: 0.004 сек.