Побудова моделі бізнес-процесу - Статті з процесного управління - Статьи - Системи управління

Поділитись "Побудова моделі бізнес-процесу"

Артур Хедж

Перший крок до підвищення ефективності процесу: визначте де ви зараз знаходитесь.

Короткий опис процесу побудови моделі бізнес-процесу

Етап підготовки.

  • Визначити межі процесу
  • Визначити кінцевого споживача процесу
  • Встановити склад учасників

Етап розробки моделі процесу.

  • Визначити ініціюючу подію
  • Визначити результат процесу
  • Створити діаграму процесу
  • Визначити винятки

Етап перевірки (валідації).

  • Перевірити відповідність діаграми процесу дійсності
  • Визначити винятки

У цій статті обговорюється побудова моделі за допомогою нотації графічного представлення бізнес-процесів (BusinessProcessModelingNotation - BPMN). Стандарт BPMN є типовим набором символів і правил для опису бізнес-процесів. Стандарт підтримується консорціумом Object Model Group (OMG), специфікацію стандарту можна знайти на сайті консорціуму OMG. BPMN — добрий варіант для застосування, бо багато розробників програмних засобів для цієї галузі вже підтримують цей стандарт. Крім того, BPMN дозволяє перетворювати на додатковий набір стандартів, який називається мовою для виконання бізнес-процесів BPEL (BusinessProcessutionLanguage). Ця командна мова дозволяє серверу процесів виконувати код, що генерується безпосередньо з BPMN. Для організації, що інвестує значні кошти у BPM, використання відкритих стандартів для розробки має довгострокову стратегічну перевагу. Згодом такий підхід дозволить створювати модельпроцесу за допомогою одного інструменту, а виконувати за допомогою іншого, виходячи з того, що вони підтримують зазначені стандарти.

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

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

Підготовка

Перший крок підготовчого етапу – це опис процесу від початку до кінця з погляду бізнесу. На цій стадії важливо окреслити межі процесу настільки широко, наскількице можливо. Згодом набагато простіше деталізувати межі процесу, якщо вони задані для процесу надто широко, ніж розширювати опис, коли межі спочатку вузькі.

І це важливо з кількох причин. По-перше, якщо опис процесу неповний, можна запросто випустити з уваги якісь важливі взаємодії між підрозділами організації. Саме через це рішення часто бувають неефективними. Вірний спосіб переконатися у правильності бачення процесу – визначити його кінцевого споживача. Наприклад, приймальній комісії університету потрібна допомога у підвищенні ефективності процесу прийому абітурієнтів. І тут важливо пам'ятати, що кінцевим споживачем цього процесу є абітурієнт, а чи не приймальна комісія. Правильне питання, яке вимагає відповіді, звучить так: «Для кого саме це все робиться?».

Після коректного опису бізнес-процесу необхідно визначити всі сторони, що задіяні в ньому. У BPMN вони називаються "учасниками" ("participants"). Ті, хто знайомий з UML, можуть розглядати їх як actors (виконавці, суб'єкти). Термін "учасник" при описі процесу відноситься до особи або системи, а термін "область" ("pool") - до існуючої діаграми. Учасники — це люди або речі, які беруть участь у моделюваному процесі. Людей краще ідентифікувати не за іменами, а за ролями, які вони відіграють. Наприклад, якщо декан Роберт Сміт, який відповідає за набір студентів, хоче прийняти всіх абітурієнтів, які перебувають у списку очікування, то відповідна доріжка (swimlane) діаграми називатиметься декан, який відповідає за набір студентів, а не Роберт Сміт. Абітурієнти на BPD представлені у вигляді областей, і до областей можна звертатись так само, як до доріжок.

Однією з причин для формування попередньогосписку задіяних у процесі учасників є необхідність переконатися, що інтерв'юються «правильні» люди. Хороше знання учасників гарантує, що всі вони будуть включені у процес побудови моделі процесу. Зрозуміло, що на етапі створення моделі може виявитися якась група учасників, яка бере участь у процесі як виняток, і яка внаслідок цього була втрачена з уваги.

Починаємо складати діаграму

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

Моделювання зазвичай відбувається у групі, що з представників кожного учасника. Це, як правило, менеджери або супервайзери, які мають уявлення, як і куди рухається бізнес. Аналітик забезпечує організацію нарад та відповідає за реалізацію проекту. При груповому обговоренні обов'язково виникнуть розбіжності щодо опису процесу. Не слід витрачати на них багато часу, доки відкладете, все вирішиться на етапі перевірки.

Починати роботу слід з аналізу меж процесу. Потім потрібно визначити подію, яка ініціює процес, і подія, яка говорить про нормальне (штатне) завершення процесу, тобто необхідно з'ясувати, як починається і як закінчується процес. Ще раз хочеться загострити увагу: дуже важливо позначити стартову та кінцеву точки саме з погляду користувача. Наприклад, у тому ж випадку з вступом до коледжу потрібно почати те, з чого починаєабітурієнт (у цій ситуації до нього спочатку виникає інтерес як до потенційного учасника спортивної команди коледжу). Щоб це врахувати, необхідно виділити окремий процес («підбір кандидатів у спортивну команду»). Також важливо мати чітке визначення процесу, якого створюється модель ще до початку роботи.

Якщо ініціюючих подій кілька, спробуйте розбити подію на частини та розробити нову високорівневу модель, що включає всі події, що ініціюють. Звичайно, це може виявитися підступним завданням, з яким не так просто впоратися. Наприклад, у нашому прикладі з процесом вступу до коледжу, можливо, буде необхідно доопрацювати нашу модель, щоб вона передбачала подання заяви абітурієнтом через Web або звичайною поштою, і, таким чином, могла відслідковувати процес розгляду заяви з настанням будь-якої з вищенаведених подій. Закономірно виникає питання: це дві різні події, що ініціюють, або одна, що має два різновиди? При побудові моделі існуючого процесу, швидше за все, немає необхідності вирішувати це приватне завдання, бо мета даного етапу — визначення критичних областей існуючого процесу, які потребують удосконалення. Однак, на етапі створення оптимізованої моделі, яка вже буде використовуватися в управлінні виробничими процесами, рішення все ж таки треба буде прийняти.

Визначаємо кроки процесу

Отже, змістом вищезгаданого спільного обговорення є визначення основних стадій або, інакше кажучи, кроків процесу. Зробити це можна за допомогою кількох ітерацій. Спочатку відкиньте всі винятки і спробуйте швиденько накидати план всіх кроків, які, загалом утворюють процес, для випадку, якщо все йде «за планом». Далі, залиште місце надошці або на аркуші паперу, куди записуватимете найнеймовірніші речі, які, на думку учасників, можуть статися. Після того, як опис нормального виконання процесу буде закінчено, має сенс повернутися та проаналізувати цей список надзвичайних подій. Ось приклад підходу для складання списку завдань: потрібно пройти крок за кроком весь «нормальний» процес, ретельно виділяючи всі точки прийняття рішень та артефакти [1], що виробляються під час процесу. Як правило, кожна дія подається у вигляді прямокутника із закругленими краями, що містить опис завдання у форматі «дієслово-іменник». Наприклад, опис «Розглянути заяву» означає, що приймальна комісія має розглянути заяву абітурієнта.

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

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

Зрозуміло, якби все було однаковим та постійним, цей етап, можливо, і не знадобився б. Крім того, як уже було сказано, існують різні винятки у виконанні процесу. Спочатку проаналізуйте винятки, виявлені під час моделювання, та перевірте, наскільки вони враховані. Потім складіть список винятків, виявлених на етапі перевірки.

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

Переклад компанії DIRECTUM

Джерело: AIIM (Developing a Business Process Model)

Поділитись "Побудова моделі бізнес-процесу"