Моделювання бізнес-процесів за допомогою BPMN - CMS Magazine

1. Де використовуються BMP на практиці?
2. Досвід використання BPMN нашою компанією
3. Бізнес-процеси технічної підтримки

Дана стаття продовжує наш розповідь про те, як влаштована технічна підтримка в Progressive Media .

BPM (Business Process Management) - управління бізнес-процесами, систематичний підхід для створення, уявлення, документування та контролю автоматизованих і не автоматизованих процесів, спрямованих на реалізацію цілей і бізнес-стратегії компанії.

Управління бізнес-процесами включає свідоме, комплексне і розширюване, технологічно доступне, визначення, поліпшення і підтримку end-to-end процесів.

Що означає end-to-end процеси? Насправді це не більш ніж процес від початку до його завершення.

Завдяки систематичному і усвідомленого менеджменту end-to-end процесів компанії досягають кращих результатів, процеси стають більш гнучкими. Головна мета - зрозуміти і поліпшити процес в цілому, а не тільки його окремі компоненти.

Для графічного представлення бізнес-процесів використовується BPMN.

BPMN (Business Process Model and Notation) - метод ілюстрації бізнес-процесів у формі різних діаграм, схем і графіків логічних послідовностей.

У BPMN використовується певний набір базових елементів / символів, які можна розділити на кілька основних категорій.

Об'єкти потоку. Об'єкти потоку включають завдання, які необхідно виконати в ході процесу і умови (шлюзи), від яких залежить виконання завдань. Також в схему можуть бути включені певні події.

Зв'язки. Об'єкти з'єднані між собою різними видами зв'язку. Якщо об'єкти знаходяться в одному пулі, то вони зв'язуються між собою потоком управління. Якщо необхідно пов'язати об'єкти, які знаходяться в різних пулах, то для зв'язку елементів використовується потік повідомлень. Для відображення відносин між інформацією та об'єктами потоку використовується асоціації.

Артефакти. Для відображення додаткової інформації про процес використовують артефакти. Артефакти не впливають на процес безпосередньо. Будь-артефакт може бути пов'язаний з будь-яким об'єктом потоку.

Необхідний сайт, мобільний додаток, послуги з SEO або контекстну рекламу? Тендерна майданчик

WORKSPACE допоможе вибрати оптимального виконавця. База проекту налічує більше 10 500 агентств . Сервіс БЕЗКОШТОВНИЙ для замовників.

Розглянемо приклад ілюстрації найпростішого бізнес-процесу:

На схемі представлений процес зміни тарифного плану для клієнта технічної підтримки.

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

У представленій схемі можна виділити кілька основних елементів.

У прикладі ми можемо розрізнити наступні завдання: «Підготувати додаткову угоду» і «Змінити тарифний план в системі ТП».

• Події описують суттєві моменти, які відбувалися до, протягом або в кінці процесу. У прикладі використані події, які описують різні стани процесу. Початкове подія - це подія, яка ініціює початок процесу. Початкове подія - фіксують подію. Це означає, що воно відбувається незалежно від процесу, але процес залежимо від цієї події або певним чином реагує на нього. Кінцеве подія використовується в якості статусу, який позначає закінчення процесу. Кінцеве подія може бути ініційовано тільки самим процесом.

У поточному завданні вихідною подією є бажання клієнта змінити свій тарифний план - «Клієнт повідомляє про необхідність змінити тарифний план»

• Зв'язки описують логічно-часові послідовності між потоковими елементами: завданнями, подіями, шлюзами.

На схемі представлені два типи зв'язку: керуючий потік - між елементами одного пулу і потік повідомлень - зв'язок між пулами. Так як внутрішні процеси клієнта не мають значення для даної задачі, то зв'язок встановлюється не між елементами різних пулів, а безпосередньо між елементом одного пулу і іншим пулом (згорнутим пулом).

Де використовуються BMP на практиці?

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

Наша компанія виділяє наступні напрямки використання BPM:

1. Моделювання (документування) існуючих процесів.

2. Удосконалення процесів.

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

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

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

Досвід використання BPMN нашою компанією

Причини впровадження BPMN

Основні причини, що вплинули на прийняття рішення про впровадження BPMN:

1. Відсутність чіткого регламенту взаємодії і розмежування сфери відповідальності співробітників.

2. Проблема навчання нових співробітників.

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

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

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

BPMN забезпечує коректне розподіл обов'язків для співробітників. Моделювання процесу допомагає грамотно визначити мету і відповідального за виконання процесу. Спростити оборот документів.

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

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

Бізнес-процеси технічної підтримки

На даний момент у відділі підтримки існують і змодельовані наступні бізнес-процеси:

• Новий клієнт.

• Зміна тарифного плану.

• Робота зі зверненнями.

• Передача проекту між менеджерами.

• Переклад розробника до відділу ТП.

• Зняття клієнта з підтримки.

Ці процеси сформувалися із значущих систематично виконуваних завдань відділу.

Серед процесів технічної підтримки виділяється основний і найбільш складний процес «Робота зі зверненнями». У процесі беруть участь клієнт, менеджер, а також всі необхідні фахівці (в основному, дизайнери і Frontend і Backend-розробники).

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

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

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

Незалежно від обраної гілки бізнес-процесу обов'язковим завданням є визначення типу поводження. Залежно від типу звернення може запускатися ланцюжок з додатковими завданнями, що включає оцінку і узгодження завдання.

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

Іноді в ході реалізації завдання складаються такі ситуації, що час, необхідний на вирішення завдання, перевищує час, дане за попередньою оцінкою завдання. Наприклад, виникають непередбачені обставини, пов'язані з роботою стандартного функціоналу CMS і т.п. Ми врахували подібні ситуації при складанні процесу і внесли відповідні завдання в процес. Якщо фахівця для виконання завдання необхідно додатковий час, то, відповідно до процесу, розробник повинен зв'язатися з менеджером і повідомити йому про виниклі труднощі. Менеджер, в свою чергу, повідомляє клієнту про труднощі і погоджує додатковий час, який необхідно для виконання поставленого завдання.

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

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

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

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

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