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

Наприклад, стандартний модуль дозволяє встановити лише один набір умов, щоб відфільтрувати записи, для яких буде запущено бізнес-процес. У Дизайнер бізнес-процесівє завдання Умова, що дозволяє встановити різний спосіб обробки різних типів записів. Ви можете використовувати завдання Умову будь-яку кількість разів! Серед іншого це дозволяє обробляти помилки (наприклад, з Контрагентом немає пов'язаних угод).

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

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

Ви можете додавати кнопки у табличний та детальний вигляд! Запуск бізнес-процесу можна не тільки за умовою або за розкладом, але і вручну!

Можливо, ваші старі бізнес-процеси у візуальному редакторі Дизайнера Бізнес-Процесів виглядають якось так:

(нижня картинка показує як можна розділити шлях виконання Бізнес-Процесу)

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

Новий модуль Бізнес-Процесів дозволяє пов'язати останній РЕЗУЛЬТАТ з першими ВХІДНИМИ ДАНИМИ. Таким чином ви можете створити бізнес-процес, що нескінченно повторюється!

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

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

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

Інструмент для моделювання та управління бізнес-процесами – системи BPM, що дозволяють швидко створювати, запускати, моніторити та змінювати процеси завдяки тісній інтеграції середовищ проектування, розробки та виконання. В основі ВРМ-систем, як правило, лежить один із найпрогресивніших світових стандартів моделювання — нотація BPMN 2.0.

Що таке нотація BPMN

BPMN — найгнучкіша і найпростіша методологія моделювання, аналізу та реорганізації бізнес-процесів. Гнучкість забезпечує набір елементів та правил нотації, а наочність досягається за рахунок візуальних діаграм процесів та блок-схем. Основна мета BPMN — забезпечити доступною нотацією опису бізнес-процесів усіх користувачів: аналітиків, які створюють моделі процесів, розробників, які впроваджують технології їх виконання, простих бізнес-користувачів та керівників, які керують процесами та відстежують їх виконання.

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

5 BPM-систем з нотацією BPMN в основі

bpm’online

bpm"online - платформа для управління бізнес-процесами від компанії Terrasoft. В основі системи - найпрогресивніший стандарт моделювання бізнес-процесів BPMN. Система дозволяє не тільки здійснити моделювання та схеми бізнес-процесу і змінити її за допомогою зручного дизайнера, але і запустити тільки що створений процес без залучення розробника.

Для моделювання бізнес-процесів у нотації BPMN у bpm'online доступні два інструменти:

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

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

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

BizAgi Suite

Безкоштовний (до 20 співробітників) інструмент для графічного опису процесів у нотації BPMN. Система підтримує спільну роботу, імітаційне моделювання, експорт створених моделей до текстових редакторів та інших форматів. Система складається з двох модулів: BizAgi Modeler, який використовується для опису та моделювання бізнес-процесів та BizAgi Studio, що дозволяє перетворити створені моделі на виконувані програми. Система також дає змогу відстежувати виконання процесів у реальному часі.

Business Studio

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

ELMA BPM

Для моделювання бізнес-процесів у системі використовується нотація BPMN. Система дозволяє також у реальному часі виконувати та відстежувати змодельовані процеси. Крім побудови моделей система також дозволяє призначати ролі бізнес-процесів відповідальним співробітникам, організувати роботу з документообігом, інтегрувати систему з 1С.

Visual Paradigm

Система підтримує велику кількість нотацій та блок-схем моделей, серед них і BPMN. Створені у системі моделі можуть бути пов'язані між собою, що легко дозволить створити модель всього бізнесу. Крім цього, є можливість провести імітаційне моделювання та перевірку діаграм процесів.

Visual Paradigm забезпечує можливість керувати атрибутами елементів та автоматично генерувати описи процесів. Система спочатку була орієнтована на розробників, тому кожному елементу можна задати умови поведінки у системі, бізнес-правила.

Документуємо новий дизайн бізнес-процесу

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

Генерал, який виграє битви, робить безліч розрахунків в умі до того, як битва

починається.

Коригуємо оновлений дизайн процесу

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

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

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

Редизайн бізнес-процесів: корисні поради

• Змінюйте процес таким чином, щоб покращення максимально відповідали побажанням клієнтів – наприклад, підвищуйте швидкість, ефективність та акуратність роботи, знижуйте вартість або скорочуйте кількість контактів між клієнтом та компанією до одного.
• Нехай вас не пов'язують такі фактори, як наявний штатний розклад, розподіл обов'язків, місце роботи. Якщо для підвищення ефективності процесу необхідно ввести нову штатну одиницю, заплануйте.
• Якщо базові ресурси для процесу природно формують групи, створіть окремий процес для кожної групи.
• Насамперед займіться зміною тих частин процесу, у яких втрачається найбільше часу, - там, де доводиться довго чекати, переміщатися чи переробляти роботу.
• У тих випадках, коли ті чи інші кроки в рамках процесу можуть бути здійснені незалежно один від одного і поза певною послідовністю, можливо, є сенс створити кілька процесів, які можуть відбуватися паралельно.
• Проаналізуйте обґрунтованість нинішньої послідовності етапів у рамках процесу. Подумайте, чи стане він швидшим та ефективнішим, якщо її змінити.
• Шукайте можливості позбутися зайвого контролю над вже виконаною роботою. Коли люди знають, що результати їхньої праці багато разів перевірятимуть, вони перестають намагатися все зробити правильно з першого разу.
• Щоб зменшити кількість етапів у рамках процесу, виключіть усі випадки затвердження документів та схвалення дій співробітниками, які особливо не розуміються на змісті виконуваної роботи. Переведіть процес прийняття рішень на нижчий рівень, де ведеться основна діяльність.
• Шукайте можливість спростити надмірно складні кроки.
• Зробіть так, щоб у процесі було задіяно якнайменше людей. Таким чином, ви заздалегідь знижуєте кількість можливих труднощів і ймовірність виникнення проблем.
• Щоб ідентифікувати проблемні області в рамках процесу, запитуйте залучених до нього

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

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

• Tutorial

Цю статтю я написав у продовження статті про BPM-системи. І тут я хочу розповісти про принципи роботи BPMS на прикладі конкретної системи – Bizagi. Я постараюся пояснити, як відбувається процес моделювання, розробки та виконання бізнес-процесу у цій системі на практичному прикладі.

Bizagi: Model. Build. Run

Bizagi – це BPM-система, розроблена однойменною компанією, та спрямована на моделювання, виконання, автоматизацію та аналіз бізнес-процесів. Система Bizagi включає 3 модулі для повноцінного налаштування процесів:

• Modeler – повнофункціональне середовище моделювання процесів у нотації BPMN;
• Studio – середовище розробки бізнес-процесів;
• Engine - середовище виконання процесів, яке доступне користувачам у будь-якому браузері з будь-якого пристрою.

Розглянемо кожен із цих модулів докладніше.

Modeler

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

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

Ви можете використовувати один із трьох способів моделювання бізнес-процесу:

• New Process – створити свій новий бізнес-процес;
• Import Process – імпортувати бізнес-процес;
• Process Xchange – вибрати готову модель з бази бізнес-процесів, запропонованої компанією Bizagi. Вибравши шаблон, ви можете доопрацювати під реалії свого бізнесу. Усі представлені моделі написані англійською мовою.

Створений у Modeler бізнес-процес можна редагувати, зберегти, експортувати в різних форматах (pdf, html).

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

Створені в Modeler карти бізнес-процесів можна як "розшарувати" на порталі Bizagi, так і використовувати колаборатив, тобто кілька співробітників можуть виконувати спільну роботу, що дуже зручно.

Мodeler має російськомовний варіант інтерфейсу, на відміну двох інших модулів.

Ще раз нагадаю, що Modeler призначений лише для моделювання бізнес-процесів. Тобто якщо вам потрібний тільки дизайн бізнес-процесу, цього модуля вам буде достатньо. Якщо вам необхідно не тільки моделювати, але і розробляти і виконувати бізнес-процеси, вам знадобиться модуль Studio, в якому є свій моделлер бізнес-процесів.

Studio

Змодельована карта бізнес-процесу має запрацювати. Користувач повинен входити до системи та взаємодіяти з різними формами. Studio дозволяє розробити інтерфейс та форми, з якими працюватиме людина. Нижче ми розглянемо всі аспекти розробки бізнес-процесу в Bizagi Studio.

Хочу зазначити, що Modeler та Studio безкоштовні. У базовий пакет Studio включено до 20 тестових користувачів.

Engine

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

Ліцензії Engine платні. Безкоштовний лише тестовий режим.

В Engine передбачено два види ліцензії:

• постійна ліцензія;
• ліцензія на рік.

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

Engine передбачає покрокове виконання розробленого бізнес-процесу з урахуванням усіх прописаних у Studio умов.

Без модуля Engine ви не зможете повноцінно працювати в системі та виконувати прописані бізнес-процеси.

Як працює Bizagi

Що ми робимо у Bizagi, якщо нам необхідно автоматизувати будь-який бізнес-процес? Розглянемо алгоритм дій з прикладу узгодження заявки витрата коштів. У статті про BPM-системи ми бачили, як цей бізнес-процес був реалізований на реальному проекті за допомогою облікової системи, зараз ми подивимося, як це правильно організувати у системі BPM.

1. Моделювання

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

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

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

Завдання полягає у контролі оплати рахунків. Послідовність дій даного бізнес-процесу має такий вигляд:
1. Співробітник, якому надходить рахунок на оплату, повинен створити запит на оплату.
2. Керівник повинен перевірити запит і вибрати один із варіантів дії:

• Відмовити;
• Схвалити.

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

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

2. Розробка структури даних

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

У нашому прикладі ми маємо розробити три сутності (Entity):

• Запит на оплату рахунку;
• Контрагент (постачальник, якому необхідно сплатити рахунок);
• Причина відмови.

Для кожної з цих сутностей необхідно прописати атрибути (поля), які будуть доступними для заповнення. Атрибути поділяються на:

• Попередньо (їх дуже багато) - атрибути, які пропонує сама система;
• Користувальницькі - ті, що користувач створює вручну.

На скріншоті видно які атрибути прописані для кожної сутності.

Також необхідно вказати зв'язок між цими сутностями. Ми прописуємо, що сутності Причини відмови та Контрагенти входять до сутності Запиту на оплату рахунку.

3. Створення форм (інтерфейсу користувача)

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

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

Форма - це те, з чим згодом працюватиме користувач.

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

У нашому прикладі необхідно розробити 3 форми:

• створення запиту на оплату;
• Перевірка запиту на оплату;
• Формування друкарської форми.

Ці форми використовують одні й самі дані. Основа в кожній із цих форм одна - запит на оплату рахунку. Але кожна наступна форма має розширений функціонал, ніж попередня. Наприклад, у формі перевірки запиту є вся інформація з форми створення запиту + статус заявки (схвалено чи ні). А наступна форма має, порівняно з попередньою, ще й можливість друку запиту. За потреби непотрібні поля з попередніх форм можна приховати.

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

Тепер розглянемо процес створення форми (наприклад, Створення запиту на оплату).

Форма створюється за допомогою вибору та перетягування в активне вікно необхідних полів. Для вибору пропонують поля (атрибути), які ми призначили конкретним формам на попередньому етапі.

Форма створення запиту буде виглядати так:

Тут ми бачимо поля:

• Термін оплати;
• Сума рахунку;
• Номер рахунку;
• Контрагент;
• Приєднаний файл (можливо закріпити рахунок на оплату).

Також для зручнішого використання форм можна скористатися Layot (варіанти розташування частин форми).

Макет форми можна розділити:

• на три рівні частини (33%-34%-33%);
• на дві рівні (50%-50%) частини;
• на дві нерівні (70%-30%, 30%-70%) частини;
• залишити макет неподільний (Full layout).

На етапі створення форм можна налаштувати видимість полів та функції редагування для різних користувачів.
Наприклад, наступний етап перевірки запиту має свою форму, в якій керівнику видно поля, створені співробітником на попередньому етапі, але керівник ці поля редагувати не може. Натомість йому доступні власні поля, які не видно співробітнику: поле схвалено з варіантами Yes/No.

Поле Причина відмови стає помітною для керівника, тільки якщо в полі Схвалено він вибрав варіант No. Тобто видимість полів можна налаштувати у форматі Видно-Не видно, а й у залежність від будь-яких умов. Ця умова виглядає так
PaymentRequestApproved is equal to false

Якщо Керівник встановив варіант Yes, доступна функція роздрукувати запит на оплату. Він уже ніякі функції недоступні, крім Generate template.

4. Визначення бізнес-правил

У Bizagi передбачено три етапи встановлення бізнес-правил:

• Define Expressions - передбачає обробку умов
• Activity Actions (Events) - передбачає обробку подій
• Perfomance – передбачає обробку користувачів, які працюють на тому чи іншому етапі бізнес-процесу.

Define Expressions
На етапі Define Expressions йде визначення варіантів поведінки системи за тих чи інших умов. У нашому випадку це результат перевірки запиту, два варіанти (дві стрілки), що ведуть від Результату перевірки. При натисканні на стрілку, яка веде до наступного етапу, відкривається форма, у яких заповнюються умови переходу той чи інший етап.

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

Якщо за результатами перевірки Керівник схвалив запит, процес переходить до етапу Роздрукувати рахунок.

Activity Actions
На етапі Activity Actions ми можемо прописати визначені поля. Зумовлені поля можуть заповнюватись у трьох випадках (на вибір):

• при відкритті форми;
• за збереження;
• при виході із форми.

Наприклад, на етапі створення запиту на оплату, ми можемо вказати, що при відкритті форми у нас є два зумовлені поля:

• Дата – тут ми вказуємо, що дата запиту автоматично заповнюється поточною датою DateTime.Today
• Автор (співробітник) – тут прописуємо, що той, хто ініціював документ, автоматично стає його автором Me.Case.Creator.Id

Perfomance
Наступний крок – це Perfomance. Тут ми прописуємо, хто на якому етапі працює із бізнес-процесом, відповідає за його виконання.

• На етапі створення угоди працює співробітник, який створив цю угоду. User Id Equal Case Creator
• На етапі перевірки запиту працює Керівник того, хто створив документ. User Id Equals CurrentAssigneeBoss

5. Опис правил оповіщення
Після того, як ми прописали, як працюють бізнес-правила, ми описуємо правила оповіщення.

Співробітник не може постійно перебувати в одній системі, має поточні справи та роботу в інших програмах. Як він отримуватиме інформацію про зміни щодо бізнес-процесу, які вимагають його участі? Це налаштовується за допомогою Notification. BPMN 2.0 має таке поняття, як notification, і тут ми можемо оповіщення прив'язати до системи.

Оповіщення бувають двох видів:

• автоматичні (в самій системі є свій email-сервер) – наприклад, при переході з однієї стадії до іншої;
• створювані вручну – наприклад, коли користувач сам хоче відправити повідомлення для будь-якого уточнення, але без зміни етапу заявки.

Використовувати можна обидва види сповіщень одночасно.

У нашому бізнес-процесі при зміні етапу (Схвалено або Не схвалено запит на оплату), Співробітнику надсилається повідомлення про те, що рахунок схвалено або вимагає уточнення.

6. Створення друкованої форми

У нашому прикладі співробітник, окрім електронного документа, хоче набути ще й друкованої форми. Тобто якщо керівник схвалив запит на оплату, то він роздруковує, підписує документ і віддає секретареві для подальшої передачі до бухгалтерії. Документ зберігається у системі, а й у друкованої формі.

У системі можна створювати так званий document templates. Для друкованої форми запиту можна використовувати word, excel чи простий текст. Ми створили форму, яку має роздрукувати той, на кому закінчується процес, і поставити свій підпис. У цій друкованій формі видно всю основну інформацію на запит:

• Дата створення;
• Користувач;
• Номер рахунку;
• Дата рахунку;
• Сума рахунку;
• Заснування;
• Підпис відповідальної особи.

При отриманні такої форми бухгалтерія може ідентифікувати рахунок, який необхідно оплатити.

Виконання бізнес-процесу

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

Розглянемо, як відбувається виконання створеного нами бізнес-процесу:

Користувач вибирає бізнес-процес із тих, що запропоновані в системі. У цьому випадку це бізнес-процес Request Payment. Відкривається форма створення запиту.

1. Користувач заповнює необхідні поля (поле Дата та Автор заповнені автоматично). Користувач прикріплює рахунок на оплату.

2. Керівник отримує повідомлення про те, що необхідно перевірити запит.
3. Керівник входить у форму запиту, де бачить форму перевірки запиту з доступними діями - вибрати, схвалено чи схвалено запит.

Якщо керівник вибрав Yes:
4. З'являється кнопка Generate document для друку запиту. Керівник виводить друковану форму та підписує її.
5. Співробітник, який ініціював запит, отримує повідомлення про схвалення рахунку.

Якщо керівник вибрав No:
4. Співробітник, який ініціював запит, одержує повідомлення про відмову в оплаті рахунку.
Бізнес-процес виконаний.

Ще кілька слів про Bizagi

У Bizagi ви завжди зможете переглянути аналітику з виконання бізнес-процесів.

У системі передбачена інтеграція: можливо "зовні" підключатися до Bizagi, або з самої Bizagi підключатися до інших програм за допомогою API. Вона використовує web-сервіси та SOAP.

Система має локалізацію - варіанти різними мовами. Є у Bizagi Modeler і російська переклад. Відразу скажу, що цей переклад, на жаль, не завжди є правильним. До того ж, вся документація Bizagi представлена ​​лише англійською. Тому я волію працювати з системою англійською мовою.

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

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

Для адміністраторів

Вбудовані інструменти візуального моделювання

Процес представляється як послідовність статусіві переходівміж ними – у «Першій Формі» це називається маршрутомпроцесу. Для створення маршруту достатньо додати потрібні статуси і потім з'єднати з переходами (найзручніше робити це методом drag-and-drop).

Візуальний редактор маршруту.

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

Маршрут погодження

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

Маршрут погодження з послідовним та паралельним запитом підписів.

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


Приклад маршруту погодження договору

Для користувачів

Стрічка основного маршруту

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