Навіщо потрібно малювати блок-схеми бізнес-процесів? Конкретний приклад ...

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

Якщо фахівець каже що описав процеси і як результат буде показувати мені мальовані схеми, в Visio, Aris, в нотациях BPMN, EPC або IDEF і т д, то у мене в голові відразу включає сигнал тривоги: "розумник прямо по курсу, від якого треба триматися по далі ".

Чому то в співтоваристві "фахівців з управління / MBA / консультантів / експертів / програмістів" - потрібно підкреслити, склалася думка що опис бізнес-процесів це аля малювання схемок і вимова розумних слів.

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

Ось. Виговорився)))

Цей потік "компліментів" відноситься саме до фахівців по BPMN / EPC / IDEF ітд, але не до нотаціям як таким. Самі нотації - є звичайний інструмент. Але як і ножем - ними потрібно вміти користуватися і розуміти де це потрібно. Наприклад марно ножем є суп, навіть якщо у вас дуже модний ніж і вам дуже сильно хочеться їм похвалитися.

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

Завдання коса процедури вхідних документів. Там є проблема з контролем (як з'ясувалося через помилки в ПЗ Директум), яку потрібно було знайти, визначити, обґрунтувати керівництву і поставити задачу програмістам. Ось під цю конкретну задачу і знадобилося написати схему.

Відновимо хронологію подій:

1. Поставлено мету: відмова від паперу

2. Почали опрацювання нового порядку дій

3. З'ясували, що відмовитися від паперу не можемо, тому що в Директум немає контролю виконання РКК

4. Почали думати над постановкою контролю в Директум, щоб бачити показники типу: "Середня тривалість виконання вхідних документів", "Частка документів виконаних в терміни". Ну і увіедть конкретні записи щодо порушень. Наприклад: РКК №123 - порушення терміну на 5 днів. Відповідальний: Петров і Сидоров

5. Намагаюся вивести звіт. Але не тут то було. У звіті є план.дата, але в 99% записів немає факт.дати. А як порахувати середню тривалість? І як дізнатися порушений термін чи ні? Ніяк! І ті РКК, де План.дата менше сьогоднішньої дати = прострочені. Хоча люди говорять що все виконали і натиснули Виконано.

6. Починаємо розбирати ситуацію, чому в 1% записів факт дата є, а в 99% - ні. З'ясовуємо, що факт.дата проставляється і не проставляється в наступних варіантах:

6.1. Факт дата проставляється, якщо реквізит "На контролі" = "Так", документи виконаний, хтось надіслав завдання контроль на керівника і прийнято. Усе!

6.2. А чи не проставляється в усіх інших випадках, включаючи:

6.2.1. Реквізит "На контролі" = "Так", але керівник не прийняв завдання-контроль. Факт дата = Пусто. Документ вважається простроченим.

6.2.2. Реквізит "На контролі" = "Ні". В цьому випадку ПО взагалі не ставить Факт.дату. Всі доручення позначаються як прострочені.

7. І тут отримуємо велику проблему, в частині п.6.1 - керівництво, яке відповідає за процедурний тип діяльності, змушене обробляти дуже великий потік Вхідні документів (ставити резолюції), і крім того що людині йде кілька десятків входять на резолюцію, сюди ж навалюється навантаження цих же документів з контролю і отримуємо завал. Керівник перестає справлятися з потоком. ТМ зависає на контролі. Все РКК видно як прострочені.

Саме цю картинку я і спробував відобразити у вигляді схеми.

Мета у цієї схеми не описати процес, а показати проблемну точку в процедурі, швидко поставити завдання програмісту з пошуку помилки в ТМ і пояснити керівництву, від куди завал.

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

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