Бізнес-процеси: the good, the bad and the ugly

У великій і навіть не дуже великої компанії ніяк без процесів. Консалтинговий підрозділ Hewlett Packard Enterprise Software займається побудовою процесів в ІТ-підрозділах своїх замовників. ITSM/ITIL, управління проектами, управління розробкою та DevOps – всі ці слова. В рамках майже кожного проекту так чи інакше ми проектуємо і малюємо процеси.

У даній замітці ми не будемо говорити про теорії, поговоримо більше про практику з урахуванням того досвіду, який накопичився в російському HP, тепер вже в HPE. Щоб говорити не абстрактно, візьмемо предметну область управління ІТ-послугами – ITSM, і кажучи про процеси, будемо мати на увазі процеси ITIL, наприклад. На абсолютну правоту не претендуємо, будемо раді обговорити дану тему.

Навіщо потрібні процеси
Ми вважаємо, що процеси потрібні, щоб люди в організації однаково розуміли, що і як вони повинні робити. Ще можна говорити «щоб структурувати діяльність організації» і багато інших слів.

Тут важливо дотримувати розумний баланс між «структуруванням» і практичним використанням людьми в роботі. Проектування (побудова) процесу – досить трудомістка задача, тому вона повинна мати практичний результат. У процесних документів повинна бути досить широка аудиторія. В ідеалі – люди повинні дивитися безпосередньо в процеси і розуміти, що і в якому порядку вони повинні робити в тій чи іншій ситуації.

У ряді замовників ми спостерігаємо картину, коли процеси з ряду причин (про них трохи нижче) стають долею вузького кола профільних процесних фахівців. Це як раз той випадок, коли «структурування» (навколонаукова завдання) переважає над практичним використанням. А якщо процес не є «настільною книгою» людей, які в рамках цього процесу працюють, то зникає або різко зменшується потік зворотного зв'язку від виконавців, які бачать, що процес потребує зміни (вдосконалення).

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

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

В описі процесу є процесні діаграми. Їх можна малювати по-різному, у різних нотаціях і з різним ступенем деталізації. Порівняємо два варіанти (це не один і той же процес, ми про нотації зараз поговоримо)


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

Ми в HPE Software Services – переконані прихильники першого варіанта, бо його розуміння не вимагає практично ніяких спеціальних навичок і знань, усе більш-менш очевидно. Це, зокрема, забезпечує можливість розуміння процесу широкою цільовою аудиторією. Зміст переважає над формою, і це, на наш погляд, непогано.

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

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

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

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

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

Результат малювання процесів важливіше і цінніше процесу малювання процесів, якщо завгодно.
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.