Бізнес-процеси: види, власники й приклади

Сформулюйте результат зміни одним реченням. Назвіть, хто приймає рішення, у яких межах і коли залучає керівника. Орієнтири: «Подія старту» і «Послідовність».

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

Для «Подія старту» потрібен видимий результат. Формулювання «ми домовилися» замало, якщо строки, якість або спосіб рішення не змінилися.

Кроки перетворюють вхід на результат і містять рішення, передачі та контрольні точки.

Заздалегідь домовтеся, за якою ознакою переглядатимете «Послідовність». Інакше тимчасове рішення швидко стане незручним правилом.

Ролі можуть належати різним підрозділам; процес показує їхню спільну відповідальність за потік.

Якщо «Учасники» працює лише після нагадування керівника, домовленість ще не стала частиною звичайної роботи.

Вихід має клієнта й критерії приймання, інакше неможливо відрізнити завершення від формальної активності.

Домовленість має витримати звичайний робочий тиск. Якщо правило «Результат» обходять за першої терміновості, причина не усунута.

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

Наявність документа тут нічого не доводить. Подивіться, чи змінила домовленість «Керованість» поведінку команди в реальній задачі.

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

Визначте, яка частина роботи дала збій. Спочатку перевірте «Подія старту». Не намагайтеся одночасно виправити всю компанію.

Домовтеся про новий спосіб дії, одного відповідального та межі його самостійності. Окремо узгодьте «Послідовність».

Перевірте домовленість у реальній роботі. Подивіться, як спрацювала частина «Учасники», і порівняйте результат із початковим станом.

Не поширюйте перше рішення одразу на всю компанію. Спочатку подивіться, як «Подія старту» витримує навантаження й нестандартний випадок.

Ця дія створює видимість порядку, але не змінює спосіб роботи. Потрібно повернутися до конкретної причини й перевірити її на реальному випадку. Поверніться до «Подія старту» і перевірте домовленість на реальній ситуації.

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

Перший збій після зміни не доводить, що підхід хибний. Розберіть причину, уточніть межі й повторіть перевірку. Наступний крок — з’ясувати, що саме не працює в частині «Учасники».

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

Перед зміною зафіксуйте кілька доступних показників. Для першої перевірки зосередьтеся на «Подія старту», а не створюйте великий звіт. Не робіть висновок за одним випадком: перевірте «Подія старту» щонайменше на кількох робочих ситуаціях.

Бізнес-процес — це послідовність роботи від події на вході до корисного результату. Відділи беруть участь у процесі, але не замінюють його. Рухайтеся від реальної проблеми до правила, а не від назви інструмента до пошуку, де його застосувати.

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