Опис нотації EPC
Основним принципом нотації, на якому все будується, є поняття подієвості. Головними елементами для побудови каркасу діаграми є "Подія" і "Функція". Після моделювання основного алгоритму з використанням цих елементів відбувається наповнення діаграми іншими елементами, наприклад, "Учасник процесу", "Об'єкт діяльності", "База даних". У загальному вигляді готова схема в нотації EPC виглядає як послідовність подій і функцій з деталізацією до використовуваних об'єктів і учасників процесу.
Для більш детального розуміння розглянемо приклад дзвінка, менеджеру з продажу. Все починається з події "Надійшов дзвінок". В нотації EPC елемент подія позначається шестикутником з рожевим фоном.
Події є пасивними елементами, що відображають факт здійснення чого-небудь, переклад або знаходження будь-якого об'єкта в якомусь стані. Наприклад "договір підписаний", "матеріал надійшов на склад". Подія може позначатися до або після функції. Діаграми в нотації EPC повинні починатися і закінчуватися подіями. Найменування події вказується всередині елемента.
Побудова діаграми починаємо зі створення події "Надійшов дзвінок". За вимогами нотації після події повинна бути функція обробки події. Для нашого прикладу такий обробної функцією є "Обробка вхідного дзвінка".
Функції є активними елементами діаграми. Цей елемент описує виконувану діяльність. Кожна функція може мати такі параметри як "Виконавець", "Використовувані об'єкти", "Загальна тривалість", "Результат виконання". Найменування функції вказується всередині елемента.
Після того, як менеджер поспілкувався з клієнтом, виникає подія "Дзвінок завершено". На цю подію і закінчується опис простого процесу.
Зазвичай, ці базові елементи нотації розташовуються по вертикальній осі відносно один одного, тобто діаграма будується зверху вниз, менш поширеним способом є побудова зліва-направо.
Як видно з прикладу, напрямок діяльності вказується з використанням стрілок.
Стрілка призначена для відображення послідовності потоку подій і робіт. Напрямок та тип стрілки залежить від елементів, що з'єднуються. Наприклад, якщо інформація використовується в функції, то стрілка йде від інформації, якщо інформація створюється в функції, то стрілка повинна йти від функції.
Для прикладу використання додаткових елементів нотації, деталізуємо наш приклад великою кількістю елементів. Припустимо, що для обробки вхідного дзвінка у менеджера є інструкція і використовується програма "CRM". Для розташування цих елементів немає жорстких правил, є лише загальні рекомендації. Наприклад, намагатися використовувати з'єднувальні лінії строго по осях X або Y. Якщо не можна для цього використовувати прямі, то можна створювати прямокутні коннектори. При створенні конекторів треба намагатися мінімізувати кількість їх перетинів, велике число накладень ліній сильно знижує читабельність схеми.
Елемент використовується позначення учасників процесу (посади, підрозділу, зовнішнього учасника). До функції на діаграмі можуть бути підключені всі беруть участь ролі (власник, виконавці, консультанти). Найменування ролі вказується всередині елемента.
Елемент призначений для позначення використання (читання, зміни, створення і ін.) Бази даних на діаграмі. Може бути з'єднаний з функцією прямого або зворотного стрілкою, в залежності від напрямку використання. Найменування бази даних вказується всередині елемента.
Елемент призначений для позначення використання (читання, зміни, створення і ін.) Паперового документа на діаграмі. Може бути з'єднаний з функцією прямого або зворотного стрілкою, в залежності від напрямку використання. Найменування документа вказується всередині елемента.
Після додавання деталізують елементів, діаграма набула більш наочний, інтуїтивно зрозумілий вид. Ми бачимо, що після дзвінка клієнта, менеджер використовує для своєї роботи базу даних "1С: Торгівля" і паперовий документ "Правила обробки вхідного дзвінка".
Досить часто бізнес-процес в нотації EPC використовують для опису складних послідовностей дій, які передбачають умовні розгалуження. На нашому прикладі з дзвінком клієнта може бути умова, що той, хто телефонує покупець може закінчити розмову, а може попросити комерційну пропозицію. Для таких опису ситуацій використовуються логічні елементи "І", "АБО", "XOR".
Логічний елемент "І" використовується для об'єднання або розгалуження потоків дій.
В даному прикладі оператор "І" використовується для одночасного запуску двох наступних подій після виконання функції "Функція 1".
Приклад моделюванні діаграми, коли має бути відображено виникнення події тільки після одночасного всіх вхідних функцій. Собитіе1 очікує виконання Функціі1 і Функціі2. При цьому різниця в часі виконання функцій ігнорується.
Цей патерн застосовують, якщо після одного події має одночасно запуститися все наступні обробні функції (в даному прикладі дві).
Цей патерн застосовують, якщо є потреба позначити, що функція може запуститися тільки після виконання всіх подій. На прикладі Функція1 очікує Собитіе1 і Собитіе2.
Логічний елемент "АБО" використовується для позначення злиття або умовного вибору наступної функції або події для потоку дій.
Якщо виконання Функціі1 може згенерувати Собитіе1 або Собитіе2, або обидві події одночасно, то це моделюється з використанням оператора "АБО". В наведеному вище прикладі частина купленого товару може бути доставлена кур'єром, а друга частина упакована і видана відразу. Або покупку заберуть відразу, або все відправлять кур'єром.
Шаблон вище використовується, якщо на діаграмі має бути відображений запуск Собитія1 після завершення Функціі1 або Функціі2, або обох функцій одночасно.
Елемент "АБО" використовується для моделювання ситуації, коли Функція1 може запуститися після Собитія1, Собитія2 або по двох дітях подій.
Ситуація вибору наступної функції після події заборонена за правилами нотації моделювання EPC, тому що події не можна робити вибір. Визначати наступний елемент для потоку виконання може тільки функція.
Логічний елемент "XOR" застосовується для моделювання ситуацій умовного розгалуження або злиття, коли може бути тільки один з попередніх або наступних елементів.
Якщо виконання Функціі1 може згенерувати тільки Собитіе1 або Собитіе2, то це моделюється з використанням оператора "XOR".
Шаблон вище використовується, якщо на діаграмі має бути відображений запуск Собитія1 після завершення тільки Функціі1 або тільки Функціі2.
Елемент "XOR" використовується для моделювання ситуації, коли Функція1 може запуститися тільки після Собитія1 або тільки Собитія2.
Ситуація вибору наступної функції після події заборонена за правилами нотації моделювання EPC, тому що події не можна робити вибір. Визначати наступний елемент для потоку виконання може тільки функція.
Правильне застосування логічних операторів вимагає деякого досвіду і приходить з часом. В якості практичної тренування можемо рекомендувати подивитися приклади діаграм EPC. яких є багато на просторах інтернету.
Основне правило для роботи з логічними елементами свідчить, що оператор розгалуження має дорівнювати оператору злиття.
Для практичного застосування елементів логіки повернемося до нашого прикладу. Додамо в наш приклад раніше описане розгалуження, що той, хто телефонує покупець може закінчити розмову, а може попросити комерційну пропозицію. Ми використовували елемент "XOR", тому що клієнт повинен зробити тільки один вибір: йому цікаво або він хоче подумати і звернутися пізніше.
Позначення циклів і зворотного зв'язку
Бізнес-аналітику може знадобитися описати процес, в якому якась робота повинна виконуватися циклічно, до виконання умови виходу з циклу. Прикладом такого процесу може бути розробка та узгодження договору. В такому випадку в тілі циклу цей договір розробляється, а умовою виходу є його узгодження. У разі відмови клієнта це може бути підставою для завершення процесу в нотації EPC.
Розширення елементів нотації
Фігура позначає посилання на процес, який є зовнішнім по відношенню до поточної діаграмі. Це може бути:
*) Попередній або наступний процес
*) Джерело використовуваних даних
*) Одержувач створених даних
Усередині фігури позначається найменування процесу разом з кодом в ієрархії процесів.
Фігура повинна використовуватися для позначення електронного документа, який використовується (створюваного) всередині описуваної діаграми. Усередині фігури вказується найменування документа.
Використовується на діаграмі для позначення стану об'єкта, до якого прикріплений. Один об'єкт може змінювати свої статки на протязі все діаграми.
Рекомендації по розташуванню елементів на діаграмі нотації EPC
В нотації немає чітких вимог по розташуванню деталізують елементів. З одного боку в цьому мало хорошого, тому що якщо цим зловживати, то можна отримати зоопарк з схем з різним оформленням. З іншого боку, якщо домовитися про правила, то цим можна управляти для отримання зручно читаються схем. При виконанні великих проектів для фіксації вимог до оформлення створюється документ "Угода про моделювання". Приклади таких документів можна знайти в інтернеті.
Якщо використовувати неформальні угоди, то ми можемо привести короткий перелік рекомендацій, яким самі намагаємося слідувати.
*) Елементи "Подія" і "Функції" по можливості розташовувати зверху вниз. Якщо місця мало, то можна зліва направо.
*) Елементи учасників процесу розташовувати з правого боку.
*) Фігури входять об'єктів (використовуваних в функції) малювати зліва зверху. Стрілка повинна йти від об'єкта до функції.
*) Вихідні об'єкти розташовувати зліва знизу. Зв'язує коннектор направляти від функції до об'єкта.
*) Стрілки для зв'язку елементів намагатися розташовувати по осях X або Y (вертикально або горизонтально).
*) Зменшувати кількість перетинів конекторів для збільшення наочності схеми.
*) Якщо декілька конекторів входять в одну сторону елемента, то розташовувати точки входу на однаковій відстані одна від одної.
*) Намагатися дотримуватися симетричність елементів відносно один одного.
Виконання створеної моделі бізнес-процесів в 1С
Ну і наостанок варто згадати, що програма ОптімаСофт: Менеджер процесів має вбудований BPMS движок, який дозволяє з мінімальними доробками запустити на виконання створену діаграму. При цьому система самостійно зможе ставити користувачам завдання для виконання. Більш детальну інформацію можна прочитати в керівництві користувача.