Цілком згоден. Але темою розмови був опис процесів, а не їхній моніторинг. Однак відповім наскільки це можливо в рамках консалтингу offline.
Природно, що необхідно проводити моніторинг процесів, а інакше вся наша робота не вартує і ламаного гроша.
Показники виходу, входу та процесу необхідні для управління цим процесом. Для вертикальних входів теж бажано мати показники. Для входу «Ресурси» кількісні показникидозволяють здійснювати розрахунок витрат та моніторинг відповідності показників якості. Як показники ресурсів, і показники обмежень будуть використовуватися при періодичних аудитах і самооцінці.

Але чи потрібно проводити моніторинг кожного процесу? Чи потрібно встановлювати показники для кожного процесу? У які процеси вкладати кошти?
Ні і ще раз ні. Необхідна вибірковість. Насамперед необхідно стежити за собівартістю та витратами на збір даних. І насамперед моніторингу піддавати пріоритетні процеси. Як виділити пріоритетні процеси і як визначити які з процесів вимагають поліпшень, які реінжинірингу і які тільки підвищеної уваги? особливої ​​увагипотрібно виходити з наступних критеріїв:
1. Важливість процесу:
чим процес важливіший, тим більше уважно слідкувати за ним;
важливість процесу визначається важливістю його результатів.
-Показники: і результативність, і ефективність.
2. Результативність процесу – здатність процесу відповідати цілям, що вимірюються задоволеністю споживача процесу.
3. Ефективність процесу – витрати та терміни виконання.
Критерієм вибору є визначальне значення показників Щодо важливості найкращим суддею за визначенням є керівництво організації. Однак, хоча керівництво і має визначати пріоритетність різних сфер діяльності та категорій споживачів чи інших зацікавлених осіб, у межах кожного класу споживачів чи інших зацікавлених осіб найкраще судити про відносну важливість того, що вони отримують від організації можуть самі споживачі чи інші зацікавлені особи. Тому саме з них слід виміряти ступінь важливості.
! Само собою зрозуміло, рішення щодо остаточної оцінки результатів, зокрема, рішення щодо відносної важливості різних процесівсеред основних процесів корпорації, має приймати керівництво. Щодо показників суддею завжди має бути користувач результатів процесу.
Споживачі найкраще можуть судити про придатність до використання – і взагалі про відповідність очікуванням – виробів і послуг, які вони отримують.
Інші зацікавлені особи (акціонери, керівництво, працівники, ділові партнери, суспільство) також краще за інших можуть судити про якість того, що вони отримують.! Визначення відносної важливості різних категорій споживачів та інших заінтересованих осіб – це питання стратегії, отже, лежить на відповідальності керівництва.
Після цього слід залучити споживачів та інших заінтересованих осіб до визначення відносної важливості кожного елемента очікуваної якості.
-Внутрішній споживач для допоміжних процесів;
-Зовнішній споживач для процесів, спрямованих на ринок;
-Інші зацікавлені особи для процесів, спрямованих на них.
Іншими словами, споживачі та інші зацікавлені особи знають фактори, що викликають задоволеність, і як визначити їхню вагомість.
! Вище керівництво приймає кінцеве рішення про «затвердження» результатів процесу, в якому споживачі та інші зацікавлені особи визначали важливість (і доповнює її тим, що стосується її

Схема бізнес-процесу відображає його суть і механізм роботи. Створити схему саме по собі не дуже складно. Достатньо розуміти на які питання має відповідати схема та дотримуватись алгоритму створення. Якщо вам не терпиться розпочати створення моделей або ви не знаєте з чого почати – ця стаття для вас.

Перед тим, як почати описувати бізнес процеси, необхідно . компанії – платформа, з якої потрібно починати.

Алгоритм, який я тут наводжу, буде корисним для тих, хто тільки збирається описувати бізнес-процеси. Для тих, хто проходив у мене навчання, стаття буде чудовим повторенням пройденого))))

Схема бізнес процесу – інструкція для нетерплячих

1 – Встановіть межі процесу

Кожен бізнес процес починається та закінчується з події. Перше, що необхідно зробити, це позначити події початку та закінчення.

2 – Намалюйте основні блоки процесу

Розташуйте основні блоки (підпроцеси, операції) в тому порядку, в якому вони виконуються.

Не ускладнюйте схему на цьому етапі. Відобразіть блоки так, ніби процес виконується окремо.

3 – Додайте розвилки та інші події

А ось тепер настав час трохи ускладнити. Додайте основні варіанти розвитку процесу та основні проміжні події. Доповніть схему відсутніми операціями.

4 – Позначте ролі учасників процесу

У бізнес-процесах немає посад чи конкретних співробітників. Натомість використовується поняття – роль. Одні співробітник може виконувати багато ролей. Одну роль може виконувати багато співробітників. З набору ролей складається посада.

За потреби додайте відсутні операції.

5 – Розмістіть на схемі документи

Документ, це не обов'язково офіційний папір із сімома підписами. З точки зору управління бізнес-процесами, документ це інформація на будь-якому інформаційному носії. Електронний лист, доповідь, презентація, СМС – це документи.

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

6 – Додайте використовувані програми та бази даних

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

7 – Розташуйте інструменти та матеріали

Якщо в процесі використовуються інструменти та/або матеріали, це також потрібно відобразити. Основні моменти можна окреслити на схемі бізнес-процесу. Детальний опискраще дати в коментарях та спеціальних розділах опису. Відмінний варіант - скласти схему, орієнтовану саме на використання інструментів та матеріалів. У подібній схемі акцент робиться не на потік робіт, а на те, як, в якій кількості і які матеріали використовуються в бізнес-процесі.

8 – Визначте показники ефективності у бізнес-процесі

Розташуйте на схемі бізнес-процесу показники ефективності, які в той чи інший спосіб враховуються в системі.

9 – Зв'яжіть отриману схему з іншими процесами

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

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

У принципі схема готова. Схема бізнес-процесу має відповідати на такі питання:

• З чого починається і чим закінчується бізнес-процес?
• З якими процесами він пов'язаний? Чим обмінюється?
• Які операції виконуються? В якому порядку?
• Хто виконує операції у процесі?
• Які документи використовуються та з'являються у процесі? У яких операціях ці жокументи використовуються/з'являються?
• Які інструменти, матеріали, ПЗ та бази даних використовуються в процесі та в яких операціях?
• Які показники ефективності та де саме фіксуються у бізнес-процесі?

Якісно підготовлена ​​схема має бути простою для сприйняття і досить інформативною.
Схема бізнес-процесу має бути зрозумілою «людині з вулиці».
Схема бізнес-процесу, на етапі опису, повинна відображати те, як процес виконується в реального життя.

Даний алгоритм дозволить вам досить просто і швидко описати необхідні бізнес-процеси. Далі я докладно розповідатиму про опис бізнес-процесів. Залишайтеся на зв'язку.

Метою будь-якого проекту 6 сигма є покращення показників, що характеризують роботу будь-якого бізнес-процесу організації.

Перше, з чим доводиться зіткнутися в ході проекту 6 сигма, – необхідність зрозуміти бізнес-процес. Що означає «зрозуміти»? Розібратися, як він працює, які ресурси для цього потрібні, які фактори впливають на якість роботи. Для цього всю зібрану про процес інформацію необхідно якось структурувати. З цією метою в рамках методики 6 сигм використовуються такі інструменти:

• SIPOC
• Блок-схема процесу
• VSM (карта потоку створення цінності)

У статті ми розберемо особливості застосування перших двох інструментів.

SIPOC

Абревіатура SIPOC розшифровується як Supplier (постачальник), Input (вхід), Process (процес), Output (вихід), Customer (споживач чи замовник). Вже з розшифровки стає зрозумілим, про що йтиметься: цей інструмент дає можливість коротко описати ключові особливості процесу, не вдаючись до деталей. Свого роду «погляд із висоти пташиного польоту». Тому саме з нього корисно розпочати роботу з опису бізнес-процесу.

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

Приклад заповнення таблиці SIPOC для процесу «Приймання сировини на склад»:

При заповненні таблиці необхідно звернути увагу на такі моменти:

• Починати заповнення таблиці краще із середнього стовпця – переліку операцій, у тому числі складається процес. Ступінь деталізації (наскільки докладно ви опишите процес) залишається на ваш розсуд, проте при використанні саме цього інструменту (SIPOC) не рекомендується дробити процес на дрібні операції.
• Після виділення операцій визначте входи процесу. Що може бути входом: безпосередньо сировина або матеріал, який буде перетворюватися в ході процесу або над яким виконуватимуться операції процесу; допоміжні матеріали та інструменти (реактиви, вимірювальне обладнання, інструменти для обробки тощо); обладнання; документи чи інформація (в усному вигляді чи вигляді записів в інформаційної системі).
• У загальному випадку люди, які беруть участь у процесі (у нашому прикладі – водій автомобіля, комірники, вантажники), не розглядаються як ресурс і не перераховуються серед входів процесу. Вони належать до категорії «виконавці» та в рамках SIPOC не розглядаються. Виняток – процеси роботи з персоналом (підбір, адаптація, оцінка персоналу). В цьому випадку входами процесів якраз і будуть люди (кандидат на вакансію, новий співробітник, співробітник до атестації тощо).
• Повнота опису входів залежить від ступеня деталізації процесу та цілей вашого проекту. Наприклад, в описаному випадку як входи можна було також виділити ваги для зважування сировини, інструменти для відбору проб і реактиви для проведення аналізів сировини, комп'ютер з доступом до інформаційної системи компанії для внесення даних про сировину. Але в більшості випадків такої деталізації при складанні таблиці SIPOC немає необхідності. Якщо для розуміння процесу в рамках цілей проекту в якихось деталях немає особливої ​​потреби, то краще їх опустити.
• Постачальників всіх отриманих входів можна легко перерахувати в 1м стовпці таблиці. У цьому випадку кількість постачальників може не відповідати числу входів (у прикладі входів два, а постачальник тільки 1). Це традиційний варіант таблиці. Але за бажання поліпшення сприйняття можна зіставити входи та його постачальників, тобто. поруч із кожним входом написати його постачальника (як у наведеному прикладі). Як постачальник можуть виступати зовнішні організації, підрозділи або співробітники компанії, інформаційні системи.
• Тепер потрібно виділити виходи процесу. Виходом може бути напівфабрикат, готова продукція, Упакована продукція, відходи виробництва, документи, інформація у вигляді згенерованих звітів і т.д. Зауваження про ступінь деталізації, вказівку людей як виходи процесу, зроблені вище щодо входів, тут теж залишаються чинними.
• Споживачі/замовники виходів виділяються аналогічно до постачальників входів. Ними є зовнішні організації, підрозділи та співробітники компанії, інформаційні системи, яким передаються виходи. Звертаю вашу увагу: у наведеному прикладі як замовник сировини вказаний склад. Здається, кінцевим споживачем сировини є виробничий цех. Але на етапі приймання сировини на склад, до моменту його відпустки у виробництво, сировина розміщується і зберігається на складі, тому як замовник вказується саме склад. Аналогічно при описі виробничого процесу некоректно вказувати постачальником сировини зовнішню організацію, т.к. цех отримує сировину зі складу, тому цеху постачальником сировини буде саме склад. Тобто. виділення постачальників та споживачів залежить від встановлених меж процесу: що ви визначите його початком і що – кінцем.
• Зауваження щодо відповідності числа постачальників числу входів відноситься і до співвідношення виходи/замовники.
• Всі входи, що перераховуються, і виходи повинні відноситися до процесу в цілому і надходити в нього ззовні (передатися зовні). Некоректно вказувати як входи/виходи міжопераційні потоки, тобто. об'єкти, що передаються від однієї операції до іншої усередині процесу. Наприклад, якщо в рамках процесу деталь, що надійшла, спочатку шліфується, а потім забарвлюється, то в якості входу/виходу не можна вказувати відшліфовану, але незабарвлену деталь. Вхід – деталь невідшліфована та незабарвлена, вихід – деталь відшліфована та забарвлена.

Блок-схема процесу

Блок-схема – інструмент для більш докладного описубізнес-процесу, ніж SIPOC. Крім входів та виходів, на блок-схемі вже знаходять відображення міжопераційні потоки процесу. Також можуть з'явитися додаткові операції – при необхідності відобразити процес докладніше. Для створення блок-схеми потрібно зібрати додаткову інформацію.

Нотації (правила підготовки) блок-схем можуть відрізнятися. Нижче наведено найпоширеніший варіант.

Позначення, що використовуються на блок-схемі процесу:

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

Можливе застосування інших символів. Головне, щоб усі учасники проекту розуміли їхній зміст.

Блок-схему можна підготувати і Word, і Excel. У цих програмах є все необхідні інструменти. Але найзручніше малювати блок-схеми в Microsoft Visio. Як правило, операції процесу мають вертикально одна під іншою. Входи процесу показують ліворуч (стрілки входів спрямовані до тих операцій, де ці об'єкти вперше використовуються), виходи – праворуч (стрілки спрямовані від операцій, де ці об'єкти з'являються). Постачальники та споживачі процесу на блок-схемах, як правило, не відображаються.

Нижче наведено 2 варіанти блок-схеми процесу - спрощений і більш докладний.

Спрощена блок-схема процесу «Приймання сировини на склад»:

Така блок-схема навіть менш інформативна, ніж таблиця SIPOC, хоч і наочніша. Тому найчастіше готують її розгорнутий варіант.

Детальна блок-схема процесу «Приймання сировини на склад»:

На блок-схемі вже можна показати виконавців процесу. Для цього на схему додають так звані свімлейни (від англ. Swimlane - «плавальна доріжка», за аналогією з доріжками в басейні). Блок схему поділяють лініями на ділянки та на кожній з ділянок розміщують операції лише одного виконавця. Зверху вказують на посаду виконавця. У такому разі блок-схема набуває наступного вигляду.

Блок-схема процесу «Приймання сировини на склад» зі свімлейнами:

Свимлейни можуть розташовуватися на аркуші як вертикально (див. приклад вище), і горизонтально.

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

Олешко Вікторія, бізнес-тренер, консультант, головний редакторсайту сайт. Автор книги “ ” та блогу “ ”. Бажаєте дізнатися більше про управління знаннями? Приєднуйтесь до

Що таке бізнес-процеси? Приклади дозволять нам краще розібратися в цьому предметі, тому ми активно їх використовуватимемо.

Загальна інформація

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

Давайте розглянемо побутовий приклад. Є домогосподарка, яка хоче помити посуд (бізнес-процес). Вона доручає це завдання посудомийній машині. На вході ми маємо брудний посуд. Під час процесу використовуватимуться вода, миючий засібта електрику. І на виході ми отримаємо чистий посуд. За такою схемою і будуються бізнес-процеси. Приклади, які будуть наведені надалі, лише підтвердять ці слова.

Функціональний підхід

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

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

Процесний підхід

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

Уявіть карту. У самому центрі знаходиться Він поділяється на окремі складові. Їх супроводжують керуючий та підтримуючий процеси, які стежать за тим, щоб все виконувалося так, як потрібно. Це буде процесний підхід. Коли роботу одного елемента завершено, його напрацювання передаються наступному.

Опис бізнес-процесів

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

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

Порядок розробки

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

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

Чому слід звернути увагу?

Слід зосередитися на наступних розділах:

1. Стандартні форми.
2. Карта.
3. Маршрути.
4. Матриці.
5. Блок-схеми.
6. Опис стиків.
7. Допоміжні описи.
8. Документування.
9. Розгорнутий опис.
10. Визначення індикаторів та показників.
11. Регламент виконання.

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

Про карти замовимо слово

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

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

Матриці

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

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

Мене часто запитують – що почитати про бізнес-процеси?
Одним з найкращих сайтів на просторах рунету є www.klubok.net. Я сам "виріс" на форумі та статтях цього сайту. Багато статей не втратили актуальності і зараз. Почати вчитися рекомендую саме з нього.

А от якщо говорити про книги - то впевнено можу сказати найкраща книгапро бізнес-процеси - це книга, написана Рєпіним та Єліферовим: "Бізнес-процеси компанії. Побудова, аналіз, регламентація".

Опис бізнес-процесів: прагнення простоти.

У статті розглянуто питання щодо вибору нотації для опису процесів з метою подальшої регламентації. Порівнюються між собою нотації Work Flow, що часто використовуються, такі як: «Проста блок-схема» в MS Visio, «Процедура» Business Studio, нотація ARIS eEPC та інші.

При порівнянні нотацій основна увага приділяється питанням створення простих та зрозумілих співробітникам організації схем процесів.

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

Вступ

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

Порівняння нотацій

Для порівняння були обрані такі нотації опису процесів:

1. "Проста блок-схема" (з відображенням руху документів, з використанням блоку "Рішення");
2. «Проста блок-схема» (без відображення руху документів, без використання блоків «Рішення»);
3. «Процедура» системи Business Studio (один із можливих варіантівуявлення);
4. ARIS eEPC.

Як тестовий приклад було обрано простий та інтуїтивно зрозумілий процес. Результати опису цього процесу представлені на рис. 1-4.

Мал. 1. Схема процесу у нотації «Проста блок-схема» у MS Visio (з рухом документів, з використанням блоку «Рішення»).

На схемі рис. 1. Послідовність виконання операцій процесу у часі показано з допомогою жирних стрілок, а рух документів - з допомогою тонких пунктирних стрілок. Блоки "Рішення" використані класичним чином. Вони відображають інформацію (питання), від яких «залежить» подальший перебіг процесу. Такий підхід до використання «ромбиків» дуже поширений. Але фактично, вся логіка прийняття рішень та формування тих чи інших виходів (документів) має полягати всередині операцій процесу. Якщо замислитись, то цінність (сенс) малювання цих «ромбиків» не є очевидною. Що це за об'єкти: операції процесу, події? Начебто ні те, і не інше. Це швидше оператори ухвалення рішення за якоюсь умовою. Але ж ми розробляємо схему процесу для людей, а не пишемо комп'ютерну програму спеціальною мовою. У комп'ютерної програми«ромбик» був би повноцінною операцією порівняння умов тощо. Але на схемі процесу потрібно показувати реальні об'єкти – процеси, які виконують люди, документи, інформаційні системи тощо. Подумайте, чи правильно показувати «ромбики» окремо від операції процесу на схемі? Натомість можна:

а) описати логіку прийняття рішення у вигляді послідовності операцій на схемі аналізованого процесу;
б) описати логіку у вигляді схеми кроків відповідного підпроцесу, переходячи до рівня нижче;
в) описати логіку текстом (у текстових атрибутах операції) й надалі вивести регламент виконання процесу.

Сформулюємо «плюси» та «мінуси» розглянутого вище (рис. 1) способу використання «ромбиків».

"Проста блок-схема" в MS Visio (з рухом документів, з використанням блоку "Рішення")
«Плюси»	«Мінус»
Наочне відображення "логіки" вибору тих чи інших виходів процесу. Акцентування уваги виконавця на точку прийняття рішення/розгалуження процесу в залежності від умов.	Винесення логіки прийняття рішення «назовні» операції процесу (некоректно з погляду формальної декомпозиції процесів). Незручно документувати процес (доводиться дублювати «ромбики» текстом для формування текстового опису операції). Схема процесу стає інформаційною перевантаженою. "Ромбики" часто використовуються надто формально, без реальної необхідності.

На рис. 2. показаний приклад того самого процесу, тільки описаного без використання блоків «Рішення» і документів. Легко перевірити, що на цій схемі на 24 графічні елементи менше, ніж на схемі рис. 1. Схема рис. 2. виглядає набагато простіше. Від графічних елементів не рябить в очах, а з погляду інформативності, ця схема цілком зрозуміла і доступна кінцевому користувачеві. Якщо кожної операції процесу описати вимоги до її виконання текстом, то комбінуючи табличну і графічну форми подання, можна цілком адекватно описати порядок виконання процесу співробітникам компанії.

Мал. 2. Схема процесу в нотації "Проста блок-схема" в MS Visio (без руху документів, без використання блоку "Рішення").

«Плюси» та «мінуси» графічного представлення процесу у формі, представленій на рис. 2., показано нижче.

В цілому, застосування схем у форматі, подібному до представленого на рис. 2 є зручним як для розробників, так і для співробітників, що працюють за цими схемами.

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

Друга особливість схеми процесу, представленої на рис. 3. є застосування стрілок. Для відображення послідовності операцій можна використовувати стрілку з одним наконечником – стрілку «попередження». Для відображення руху документів можна використовувати стрілку із двома наконечниками. Але саме в Business Studio можна скористатися лише одним типом стрілок - стрілками «попередження». При цьому до іменованих стрілок можна прив'язувати необхідна кількістьдокументів, визначених у довіднику об'єктів діяльності. Такий підхід дає можливість:

• суттєво скоротити кількість графічних елементів на схемі процесу, і при цьому:
• вивести в регламент процесу необхідну інформацію про вхідні та вихідні документи.

Таким чином, не захаращуючи схему зайвими елементами, ми можемо повно описати процес і вивантажити в регламент всю необхідну інформацію.

«Плюси» та «мінуси» графічного представлення процесу у формі, представленій на рис. 3., показано нижче.

Мал. 3. «Процедура» системи Business Studio (варіант із нетрадиційним використанням блоків «Рішення»).

У разі застосування Business Studio нотація «Процедура» може бути використана дещо по-різному. Автор статті схиляється до підходу, наведеного на рис. 3.

На рис. 4 представлена ​​схема аналізованого процесу, розроблена в нотації ARIS eEPC. Зауважимо, що у схему не помістилися деякі операції процесу. Ця неповна схема найпростішого процесу, виконана в нотації ARIS eEPC, містить чотири оператори логіки та вісім подій! Співробітник, який читає схему, має вміти правильно інтерпретувати всі ці логічні оператори. Без спеціального навчанняі наявності деяких навичок читання подібних схем, рядовий співробітник навряд чи зможе зрозуміти логіку процесу без докладного текстового опису або допомоги кваліфікованого бізнес-аналітика.

Зауважимо, що схема процесу в нотації ARIS eEPC займає суттєво більше місця, Чим схеми, представлені на рис. 1-3. Трудомісткість формування такої схеми так само суттєво вища.

Схема процесу в нотації ARIS eEPC (побудована у Business Studio)
«Плюси»	«Мінус»
p align="justify"> При формуванні схеми витримується строга, формальна логіка процесу. Чітко визначено всі події, що виникають у процесі.	Складність сприйняття. Значна трудомісткість формування схеми. У співробітників мають бути спеціальні навички та досвід інтерпретації подібних схем. Інформаційна надмірність. Займає багато місця, що незручно для документування.

Загалом, якщо Ви не збираєтеся купувати SAP R/3, то вибір та використання нотації ARIS eEPC не є, з погляду автора статті, оптимальним рішенням. Варто звернути увагу на наочніші та інтуїтивніше зрозумілі виконавцям нотації опису процесів. Втім, комусь нотація ARIS eEPC може здатися наочнішою і зрозумілішою. До певної міри це питання смаку.

Мал. 4. Схема процесу в нотації ARIS eEPC (побудована Business Studio).

Опис процесу для цілей наступної автоматизації

Цікаво подивитися на схему процесу, що розглядається, у випадку, якщо вона описана в нотації BPMN 2.0. Ця нотація варта опису «виконуваних» процесів, тобто. процесів, які підтримує система BPM.

Своєю думкою про використання BPMN 2.0. ділиться А.А. Білайчук - Генеральний директоркомпанії «Бізнес-консоль»:

На рис. 5 зображено той же процес у нотації BPMN. Як бачимо, цей малюнок схожий на рис.1: у нотації BPMN завдання зображуються прямокутниками, розвилки - ромбами, дані - піктограмою, схожою документ. Потоки управління – суцільні лінії, потоки даних – пунктирні. Треба враховувати, що на цій діаграмі задіяна лише мала частина нотації BPMN: тільки один вид розвилок з 5 наявних на палітрі, один вид задач з 8. , що взаємодіють один з одним через повідомлення або дані. Крім того, ця нотація суворіша: у ній визначені не тільки значки, а й правила, за якими вони можуть поєднуватися один з одним. Необхідність таких правил диктується тим, що нотація BPMN орієнтована не лише на те, що її читатимуть люди, а й на безпосереднє виконання спеціальним. програмним забезпеченням- «Двигунком» BPM-системи. У той же час, як свідчить даний приклад, При використанні обмеженого підмножини палітри BPMN виявляється не складніше звичної блок-схеми. Ну а тим, хто хоче освоїти BPMN професійно, ми рекомендуємо спеціалізований тренінг www.bpmntraining.ru.

Мал. 5. Схема процесу у нотації BPMN 2.0.

Практика життя

На рис. 6 показаний фрагмент схеми процесу, розроблений бізнес-аналітиками цілком конкретної компанії у вигаданій ними нотації. Схема побудована із застосуванням принципів «Простий блок-схеми» - застосовується блок «Рішення» у своєму класичному варіанті. Крім цього, на схемі представлено безліч інших умовних позначень, використаних не зовсім стандартним чином.

p align="justify"> При формуванні схеми рис. 6, бізнес-аналітики очевидно, «боролися» за наочність та максимальну зрозумілість для пересічного користувача. Вони прагнули звести до мінімуму або взагалі відмовитися від текстового коментаря до схем процесів. Виконавцям просто друкувалася схема формату А3, під час читання якої все одразу ставало зрозуміло: що робити, як, які документи використовувати тощо.

Ця схема не є, звичайно, зразком простоти і наочності. Але її було сформовано, щоб донести максимум корисної інформації для виконавців процесу.

Висновки

Отже, очевидно, що з описі процесів слід прагнути простоті і зрозумілості для співробітників.
Використання складних формалізованих нотацій при описі процесів призводить до:

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

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

В.В. Рєпін, к.т.н., доцент, Виконавчий директор ТОВ «BPM Консалтинг Груп», зав. кафедрою Управління бізнес-процесами НОУ ВПО «ІЕФ «Синергія», засновник порталу www.FineXpert.ru

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