Моделювання бізнес-процесів – використовуємо корисне, відкидаємо зайве
- Іван Баранюк
- 4 січ. 2024 р.
- Читати 5 хв

Чи знайома вам ситуація, коли, здавалось би, сталі процеси чомусь перестають працювати? Або коли процес, який здається керівнику інтуїтивно зрозумілим, постійне потребує «ручного» втручання? Найм персоналу, прийняття замовлення від клієнта або формування звітності щоразу потребують «винаходу велосипеда».
Власники та менеджери компаній завжди мріяли знайти «панацею» від усіх своїх проблем. Універсальні ліки, які б позбавили організацію більшості проблем управління, зробили її більш ефективною та конкурентоздатною. Вони посилали своїх співробітників на різні новомодні тренінги та полювали на консультантів, які знали «магічні», як правило, іншомовні слова.
Так, в різні часи, на потенційну «панацею» претендували Total Quality Management, а трохи пізніше Six Sigma – методи управління якістю продукції та виробничими процесами і зменшення дефектів до мінімуму. Трохи пізніше на сцені з’явився Project Management, який, здавалося б, забезпечував 100% досягнення цілей в будь-якій сфері діяльності. Пізніше до нього приєднались Kanban, Scrum та Agile, які ще більше додали «магічності» та універсальності. Цей перелік майже безкінечний: Lean, Balanced Scorecard, Management by Objectives та багато-багато інших.
Сьогодні шукачі універсальних рішень виводять на перші ролі управління бізнес-процесами. Головна увага при цьому приділяється моделюванню бізнес-процесів. До речі, абревіатура цих двох концепцій пишеться однаково – BPM: як для Business process management, так і для Business process modeling. Це іноді також може заплутати зацікавлену в пошуку істини особу. Але, як свідчить останній досвід, з даних концепцій також не вийшло ліків від всіх управлінських хвороб. І ось чому.

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

Проблема у відсутності мети моделювання. Адже для того, щоб вирішити, чи потрібна модель взагалі, якої складності та ступеню деталізації вона має бути – треба розуміти, що ми від неї хочемо. Це можуть бути цілі щодо проектування нових бізнес процесів, аналітики та оптимізації, або, навіть, автоматизації в спеціалізованих платформах. До речі, треба пам’ятати, що і моделювати можна за допомогою різних інструментів, з яких BPMN не є найпростішим. Адже описати нескладні «офісні» процеси цілком можливо просто текстом. Згадайте, скільки регламентів, посадових інструкцій, ілюстрованих графічним зображенням бізнес-процесів, ви бачили? Всі вони мають лише текстовий опис того, що треба робити. Отже, в деяких випадках, найефективніший інструмент – це найпростіший інструмент.

Міф про те, що графічне зображення бізнес-процесів – це дуже просто. Прихильники «універсальних ліків» говорять, що графічні моделі інтуїтивно зрозумілі навіть непідготовленому користувачу. З цим можна погодитись, але частково. Модель бізнес-процесу буде корисною лише при дотриманні наступних умов: зрозуміла мета, рівень деталізації, знайомство користувача з нотацією (стандартом побудови) моделювання та доповнення моделі додатковими інструментами. Стосовно «простоти» саме BPMN-нотації - повний арсенал нараховує близько 200 елементів, які розподілені по 8 категоріям. А для перевірки вірності побудови моделі використовують близько 80 логічних правил. Не дуже просто, так? Зрозуміло, що використання всіх елементів в одній моделі не обов’язкове, але певна підготовка користувача необхідна.

Рис. 1. Нотація моделювання бізнес-процесів BPMN 2.0.
В цьому місці хочеться сказати ось що. Я не є критиком моделювання бізнес-процесів. Так як і будь якої іншої концепції або методики в управлінні. Але, як не існує жодних універсальних ліків від хвороб організації, так і не існує єдиної універсальної методики управління компанією. Відносно ж моделювання бізнес-процесів, то я навіть прихильник цієї методики, але - якщо підходити до цього критично та отримувати всі переваги, які вона надає. Кілька прикладів.
Нижче наведена модель головного бізнес-процесу торгівельної організації.

Рис.2. Головний бізнес-процес.
Вона дає концептуальне розуміння щодо діяльності компанії, але основні елементи такої моделі – це «чорні скриньки», які відображають лише входи та виходи. До речі, символом «+» позначаються підпроцеси, які також можуть бути деталізовані.
Один з таких підпроцесів відображений на наступній моделі. Метою моделювання цього підпроцесу було отримання схематичного зображення основних його етапів з метою подальшої оптимізації. Також дуже важливою частиною даного підпроцесу є спілкування з клієнтом, тому це також відображено на моделі. Що робимо далі?
1.Час. Як правило, якщо модель складається вперше, то ніхто і гадки не має, скільки часу займає внесення однієї строки замовлення в базу, або яка середня кількість строк в замовленні клієнтів. Це відкриває дуже цікаве поле для дослідження. Я впевнений, ви будете здивовані, скільки реального часу займають ті чи інші роботи. А досвід говорить, що саме звертання уваги на ці питання здатне збільшити продуктивність праці на 15-20% відсотків. Хронометраж, застосування статистичних методів тощо дають можливість для визначення стартової межі для оптимізації по часу.

Comments