Куди подівся керівник
Аналітичний огляд присвячений питанням формування моделей бізнес-процесів, що використовуються для регламентації та управління. Розглядають проблеми, пов'язані з описом бізнес-процесів як потоків робіт (Work flow). При побудові таких моделей особливо постає питання опису діяльності керівника (власника процесу).
Моделі потоків робіт (ARIS eEPC, >
проблеми, пов'язані з відсутністю розуміння суті процесу та процесного підходу та, як наслідок, некоректна постановка задачі опису процесів з використанням потокових діаграм;
невміння ефективно використовувати самі моделі під час опису бізнес-процесів.
Що означає фраза «описати бізнес-процес», що криється за цим коротким формулюванням? Перш ніж дати відповідь на це питання, відзначимо, що схеми процесів розглядаються нами як один з необхідних елементів опису процесів, але далеко на найважливішого. З метою подальшого викладу зробимо кілька необхідних визначень.
Бізнес-процес - стійка, цілеспрямована сукупність взаємозалежних видів діяльності (послідовність робіт), яка за певною технологією перетворює входи у виходи, що становлять цінність для споживача.
Власник бізнес-процесу – посадова особа, яка має у своєму розпорядженні персонал, інфраструктуру, програмне та апаратне забезпечення, інформацію про бізнес-процес, управляє ходом бізнес-процесу та несе відповідальність за результати та ефективність бізнес-процесу.
Вхід бізнес-процесу - ресурс, необхідний для виконання бізнес-процесу.
Вихід бізнес-процесу - результат (продукт, послуга) виконання бізнес-процесу.
Модель – графічне,табличне, текстове, символьне опис бізнес-процесу чи його взаємозалежна сукупність.
Постачальник - суб'єкт, що надає ресурси.
Споживач (клієнт) - суб'єкт, який отримує результат бізнес-процесу. Споживач може бути:
внутрішній - тобто що знаходиться в організації і, в ході своєї діяльності, використовує результати (виходи) попереднього бізнес-процесу;
зовнішній - тобто що знаходиться за межами організації та використовує або споживає результат діяльності (вихід) організації.
Операція (робота) - частина бізнес-процесу.
Регламент бізнес-процесу - документ, що описує послідовність операцій, відповідальність, порядок взаємодії виконавців та порядок прийняття рішень щодо поліпшень.
Ресурси - інформація (документи, файли), фінанси, матеріали, персонал, обладнання, інфраструктура, середовище, програмне забезпечення, необхідні для виконання бізнес-процесу.
Функція - напрям діяльності елемента організаційної структури, що є сукупністю однорідних операцій, що виконуються на постійній основі.
IDEF 0 – FIPS 183 США «Integration definition for function modeling (IDEF0)» – «Інтеграційне визначення для моделювання функцій»
IDEF 3 - (workflow modeling, Рrocess Description Capture Method) методологія опису бізнес-процесів (потоків робіт).
Наше визначення бізнес-процесу ґрунтується на визначенні, сформульованому у стандарті ISO-9001:2000. Ми вважаємо, що це найбільш адекватне, практично важливе визначення. З нього випливають вимоги до опису бізнес-процесу та підходи до його управління. У нашому розумінні описати бізнес-процесу означає:
визначити власника бізнес-процесу;
визначити межі бізнес-процесу (межі відповідальності та повноважень власника процесу з управління процесом);
визначити клієнтів та виходи бізнес-процесу;
визначити постачальників та входи бізнес-процесу;
визначити ресурси, необхідні виконання бізнес-процесу (- перебувають у розпорядженні власника процесу);
описати технологію виконання бізнес-процесу (наприклад, з використанням графічних схем у вибраних нотаціях);
розробити показники, за якими оцінюється бізнес-процес, його результати та задоволеність клієнтів бізнес-процесу;
описати роботу власника з аналізу та поліпшення бізнес-процесу, а також його звітність перед вищим керівником.
Управління бізнес-процесом здійснюється за певними технологіями та з використанням певних документів, до яких входять: регламент виконання бізнес-процесу, положення про підрозділ, посадові та робочі інструкції, методичні документи щодо вимірювання показників бізнес-процесів, звітні форми, специфікації входів/виходів і т.д. (Див. малюнок 1).
Малюнок 1. Документи, які використовуються під час управління бізнес-процесом.
Таким чином, завдання регламентації та ефективного управління бізнес-процесом не зводиться до розробки лише графічних схем процесів. Графічні схеми (моделі) бізнес-процесів є лише частиною документації, як правило, що несе інформацію з покрокової технології виконання процесу. Важливо розуміти, що, окрім розробки графічних схем, необхідно виконати багато іншої, важливої роботи з опису та регламентації процесу.
Звернемося власне до графічних схем чи, іншими словами, моделей бізнес-процесів. В даний час для цілейОписи бізнес-процесів часто використовують схеми потоків робіт (Work Flow): ARIS eEPC, IDEF3, блок-схеми у Visio або MS Word. В основі зазначених підходів лежить принцип побудови бізнес-процесу у вигляді операцій, що послідовно виконуються в часі (робіт), як показано на малюнку 2.
Малюнок 2. Приклад схеми потоку робіт.
Модель потоку робіт складається з операцій (робіт), символів логіки, стрілок. Логічні символи або, як їх прийнято називати в IDEF3, перехрестя є логічним «І», логічним «АБО», що виключає «АБО». Вони служать для відображення розгалуження та злиття процесу. Стрілки можуть бути використані для відображення послідовності виконання операцій у часі або потоку об'єктів (документи, ресурси). У різних підходах (нотаціях) моделі потоку робіт можуть відображатися виконавці, документи, використовуване обладнання, програмні засоби і т.д. Суть схем процесів від цього не змінюється – моделі залишаються плоскими та показують потік робіт, що переходить від одного робочого місця до іншого.
При побудові моделей потоків робіт можна використовувати декомпозицію, коли кожна операція більш докладно описується на окремому аркуші у вигляді моделі в тій же (або іншій) нотації. Під час проведення декомпозиції виникає низка проблем з ув'язкою моделей різних рівнях і моделей у межах рівня. Оскільки вони є переважно технічними, то розглядатись у нашому огляді не будуть.
Зупинимося на наступному питанні. Якщо ми хочемо використовувати схему бізнес-процесу для регламентації (наприклад, у документі «Регламент виконання бізнес-процесу»), то ця схема має відповідати таким вимогам:
всі відображені на схемі операції бізнес-процесу повинні бути реальними і бутизакріпленими за конкретними виконавцями;
на схемі мають відображатись реальні документи, файли, ресурси;
схема процесу має бути простою і зрозумілою для візуального сприйняття;
Схема процесу повинна мати компактний розмір.
Ці вимоги означають, що будувати потокову діаграму має сенс в описах операцій рівня робочого місця виконавця, у разі – для –операцій невеликого (3-4 людини) підрозділи. На більш рівні моделі потоків робіт можуть дати загальну інформацію про процес, але використовувати такі моделі для регламентації важко внаслідок розмивання відповідальності між виконавцями процесу.
Якщо ми описуємо бізнес-процес на детальному рівні, то на виході цієї роботи отримуємо схеми, що містять потік операцій та їх виконавців. Саме при формуванні таких моделей і виникає найважливіша, на наш погляд, проблема: з розгляду виключаються повністю керівники. Виникає така ситуація. Група аналітиків (або внутрішніх експертів) приходить до підрозділу, отримує дозвіл керівника, починає працювати з виконавцями процесу, переходячи від одного робочого місця до іншого відповідно до ходу руху бізнес-процесу.
Формується модель бізнес-процесу, що включає операції всіх рядових виконавців, але навіть натяка на керівників, власників бізнес-процесу. Крім того, такі моделі найчастіше описують нормальний перебіг бізнес-процесу. Можливі відхилення часто залишаються поза розглядом. Так само часто опускають такі важливі моменти, як: дії при отриманні входів, що не відповідають (наприклад, документ із сусіднього підрозділу), отримання невідповідних вимог виходів (шлюб, недоробка), реєстрацію параметрів процесу (вимірювання),контроль тощо. Чи потрібний такий результат роботи керівнику? Відповідь очевидна. Отримані схеми бізнес-процесу є плоскими, неповними, що неспроможні ефективно використовуватися запровадження системи процесного управління. Проте багато компаній, особливо великі, виконують окремі проекти зі створення внутрішніх стандартів моделювання «плоських» бізнес-процесів, «створення баз знань компанії з бізнес-процесів» і т.п. Через війну, отримані «гори» чітко структурованої, але «односторонньої», неповної інформації виявляються практично марними для реального управління.
На малюнку 3 показаний "об'ємний" бізнес-процес. Він складається з кількох моделей потоків робіт, сформованих кожного рівня: виконавці, зам. керівника, керівник (власник) бізнес-процесу
Малюнок 3. «Об'ємний бізнес-процес»
На малюнку 3 видно, що керівник та його заступник беруть активну участь у процесі. Існує постійний, циклічний потік інформації в процесі процесу від виконавців - вгору, і управлінських рішень від керівників - вниз. Навіть якщо (у граничному випадку) ми повністю делегуємо всі права на прийняття управлінських рішень щодо процесу виконавців, у керівника залишиться ключова функція – аналіз ефективності бізнес-процесу та його покращення з орієнтиром на стратегічні цілі компанії (якщо є). Поліпшення процесу керівник здійснює з допомогою управління ресурсами: персонал, фінанси, матеріали, устаткування, програмне забезпечення, інформація тощо.
Яким чином ув'язати діяльність керівників та виконавців при побудові моделей потоків робіт (ARIS eEPC, IDEF3)? Очевидно, що це можна зробити кількома способами. Перший і найпростіший спосіб полягає в наступному: окремоописуються потоки робіт, виконуваних як керівниками, і виконавцями. Такий найпростіший підхід має кілька недоліків, основний з яких полягає в тому, що взаємодія керівника та виконавця стає в моделі неявною, а опосередкованою за допомогою зворотних зв'язків за інформацією. Інший спосіб полягає в тому, що при описі робіт виконавців можна вказати прямі посилання на процеси, які виконують керівники, або прямо відобразити їх втручання в роботу. Сказане ілюструє рисунок 4.
Малюнок 4. Від «плоського» процесу до «об'ємного».
На малюнку 4, вгорі показано найпростіший ланцюжок бізнес-процесу, що складається з двох операцій. Уявімо, що ці операції виконуються виконавцем та вимагають управління з боку керівника. Як ми можемо відобразити цей факт на моделі? Згідно з першим запропонованим вище способом, ми вказуємо на моделі процесу зворотний зв'язок за інформацією. У цьому прикладі, нотація ARIS eEPC дозволяє показати вхідний та вихідний документ А, що містить деяку інформацію. Документ А потрапляє від виконавця керівнику після виконання функції 2, і потім може бути повернений на доопрацювання при виконанні функції 1. При цьому «десь в іншому місці» ми повинні описати роботу керівника з перевірки цього документа та прийняття рішення. Це означає, що ми маємо створити модель, яка описує діяльність керівника.
На малюнку 4 наводиться ще два способи "вбудовування" керівника в бізнес-процес. Перший передбачає пряме включення у процес «Функції управління», другий – як додаткової події «Прийнято управлінське рішення».
Який спосіб для відображення участі керівника у бізнес-процесі вибрати? Це визначає сама організація. Можна скластисхему бізнес-процесу рівня виконавців, а діяльність керівника розписати як докладної таблиці із зазначенням операцій, вхідних і вихідних документів, прийнятих рішень. Можна сформувати схеми процесу до роботи самого керівника. Можна намагатися відобразити участь керівника на одній плоскій схемі, збільшуючи кількість можливих розгалужень та злиття процесу. Ми вважаємо, що потрібно вибирати той спосіб, який найкраще підходить для подальшої регламентації та управління бізнес-процесом. Моделюючи, головне не забути про керівника, оскільки саме він відповідає за управління та покращення бізнес-процесу і, зрештою, моделі бізнес-процесів створюються саме для нього.