Диаграми за описаниебизнес процеси

За нашите последващи разсъждения е важно да изясним, че не говорим за описанието на никакви процеси, а за процеси на бизнес ниво, които:

- познати на нашия клиент (крайни потребители на автоматизираната информационна система, наричана по-долу Системата);

- оперират с понятията на предметната област на клиента ("купувач", "поръчка", "плащане" и др.).

Без обратна връзка, моделът постепенно става все по-малко съгласуван с внедряването му в системата и следователно става неуместен и следователно ненужен.

Категорията бизнес процеси не включва по-специално процеси, които изпълняват определени функции на Системата на техническо ниво и включват взаимодействието на нейните технологични компоненти (сървъри, бази данни, класове, обекти и др.).

Искам веднага да кажа, че текстовите и графичните изображения не трябва да се разглеждат като взаимно изключващи се алтернативи: те се допълват взаимно. От една страна, диаграмата може да побере значително по-малко информация (включително обяснения), отколкото в текстов документ. От друга страна, графичното представяне е по-визуално, помага да се разбере сложната логика и да се види цялостната картина на процеса.

Преди да обсъдим различни опции за графични описания, трябва да вземем решение за целите, които искаме да постигнем, като започнем да "чертаем" процеси.

Описание на бизнес процесите като един от етапите на автоматизация

Въпреки че описанието на бизнес процесите може да се окаже полезно само по себе си, в тази статия ще приемем, че рано или късно, директно или в резултат на верига от действия, то ще бъде отразено (въплътено, внедрено) в автоматизирана система и участниците в бизнес процеса (хора, организации, други системи.) ще станатпотребителина Системата.

Трябва да се отбележи, че в [1], който сравнява диаграмите, използвани за това преди пет години, „описание на бизнес процеси“ и „разработване на система за автоматизация“ се считат за различни задачи, за които бизнес процесите са описани с помощта на различни методи и диаграми. През годините индустрията на информационните технологии не само разработи нови методи за описване на бизнес процеси (и съответните диаграми) и ги представи под формата на спецификации, но също така осъзна възможността за изпълнение на бизнес процеси от автоматизирани системи. Днес има не само комерсиални „машини за изпълнение на бизнес процеси“, но и подобни продукти, разпространявани от общността с отворен код. Всичко това помага за значително намаляване на разходите за автоматизация и намаляване на времето за проекти от този вид. За нас, в рамките на темата на тази статия, е важно, че формирането на модел (описание) на бизнес процеси не е крайната цел (на проект, клиент.), а само следващата стъпка към изграждането на Система, която изпълнява (изцяло или частично) тези бизнес процеси.

1. Първо, искаме да получим някакъв вид диаграми, които могат да се използват в презентации и дискусии. В допълнение, те могат да допълват текстови документи, описващи процеси: онези текстови документи, които ще станат основа за дизайна на Системата.

Ние правим следните изисквания за тези блокови диаграми (диаграми).

- Те трябва да описват логиката на процеса достатъчно подробно и точно - толкова, колкото е необходимо за решаване на всяка конкретна задача. Искаме обаче да използваме същите диаграми, дори ако изискванията за детайлност и точност се променят.

- Блок-схемите трябва да се разбират по един и същи начин от различните хора, които се занимават с тях. Това са предимно служители(клиенти), чиято работа описваме, както и себе си - бизнес анализатори, консултанти и т.н. В идеалния случай всеки, който е запознат с начина, по който описваме процеса (по-специално с графичното му обозначение), но не е задължително да познава нас и нашите предпочитания, трябва правилно да разбере какво сме изобразили.

Текстът и графиките не трябва да се считат за взаимно изключващи се:

те се допълват взаимно

И така, какви качества трябва да има един модел на бизнес процес?

- Първо, трябва да позволява автоматично създаване на отчети за неговия състав (например, за оценка на разходите за разработване на системата).

- Второ, да се позволи автоматична проверка по формални характеристики: по-специално, като пълнотата на модела, правилността на използването на неговите елементи, логиката на връзките между тях.

- Трето, да се осигури възможност за електронен обмен на модели и диаграми (а не само "снимки") между различни инструменти, както и тяхното прехвърляне в Системата.

- Четвърто, да е достатъчно пълен за автоматизирано изпълнение на съответния бизнес процес както за целите на тестването (използване на тестови входни данни, външни събития и др.), така и за реалната работа на Системата.

- И накрая, пето, да има обратна връзка със Системата: когато се правят промени в Системата (включително разяснения), те трябва да бъдат автоматично отразени в модела. В резултат на това целта на модела и жизненият цикъл на неговото използване се променят драматично: той продължава да "живее" дори след завършване на разработката на Системата.

Без такава обратна връзка моделът постепенно става все по-малко съгласуван с внедряването му в системата и следователно става неуместен и следователно ненужен. Насвоевременно "ръчно" въвеждане в модела на тези промени, на които операционната система е подложена по искане на клиента, предприятието обикновено няма достатъчно ресурси. И дори да се правят такива корекции, те може да са непълни, да съдържат грешки и т.н.

Обхватите на BPMN и UML са ясно разделени от разработчика на двете спецификации.

Предимството на модела на бизнес процесите в сравнение с „моделите на системните компоненти“ (на които UML ни научи) е, че първият е създаден на различно, по-високо ниво на абстракция и позволява на бизнес анализаторите и клиентите да участват директно в развитието на системата по време на нейната търговска експлоатация. В същото време, за да направи значителни промени в Системата от гледна точка на бизнес логиката, клиентът вече не трябва да бъде сам програмист или да използва програмист като преводач на своите идеи на езика на машината (и обратно, от езика на машината на езика на бизнеса).

Започнете да избирате диаграми

Желанието ни да използваме диаграми, за да опишем бизнес процеси, които се разбират еднакво от различни хора, ни кара да избираме от малък брой от най-популярните им разновидности, като IDEF, EPC (eEPC), UML диаграми на активност и BPD (диаграма на бизнес процес) диаграми, дефинирани от спецификацията BPMN [2].

описаниебизнес

Описание на най-високо ниво на процеса за разрешаване на спорове чрез гласуване по имейл

в BPMN нотация - действителният процес, използван при колективното разработване на самата BPMN спецификация

С цялото ми уважение към историческото интелектуално наследство, диаграмитеIDEF​​​​иEPC(за повече подробности вижте [1]) са продукти от ерата, когато не е имало въпрос за директно изпълнение на описания на бизнес процеси от Системата(подобно на начина, по който компютърът изпълнява текста на програма). Ние вярваме, че използването на тези диаграми трябва да бъде изоставено, главно защото не са достатъчно изразителни и достатъчно точни, за да бъдат изпълнени в Системата. Въпросът не е, че Системата е "глупава", а просто, че не всичко необходимо е посочено на диаграмата, а това, което е посочено, позволява двусмислено тълкуване.

Да, напредъкът в областта на автоматизирането на изпълнението на бизнес процесите е толкова значителен, че днес можете да „завършите“ всеки тип диаграма, като добавите или изясните всичко, от което се нуждаете. Можете да напишете някакъв „макро“, за да експортирате описанието на бизнес процеса във формат, разбираем от машината. Но всичко това ще бъдат наши собствени "кръпки", с тясно приложение и ниско качество.

Отминаха дните, когато спецификациите за описание на бизнес процеси бяха създадени от доставчици за техните собствени нужди. Днес те са разработвани и открито обсъждани от години. Приемането на отворени стандарти е съдбата на международни организации с нестопанска цел (консорциуми), които включват представители на всички заинтересовани страни. В резултат на това се раждат документи (дебели книги), които се четат предимно от методисти и разработчици на инструменти за моделиране. Но именно благодарение на тези "дебели книги" се постига еднозначното тълкуване на диаграмите.

По едно време аз самият бях изненадан: защо след като екип от професионалисти описа процесите и създаде диаграми, е невъзможно да се внедри работеща система, използвайки ги, но е необходимо многократно да се обикалят всички „носители на знания“ за бизнес процесите и да се подготви друго описание на тях. Причината е проста: това е свойство на самата нотация, в този случай eEPC. eEPC диаграмата не е описание на това как работи бизнес процес, а декларация за това какво ще се случи, кой участва в процеса и т.н. Не казвам, че не етрябва да направя. Освен това, когато се описват нетривиални бизнес процеси, е необходимо да се създадат допълнителни документи. Например не може без тезаурус (речник) на предметната област; може да е необходимо описание (включително под формата на диаграми) на структурата на организациите, участващи в бизнес процесите и т. н. В този случай просто констатирам факта, че eEPC диаграмите са "недостатъчни".

Диаграмите на дейността на езикаUMLсъщо се използват за описание на бизнес процеси. Въпреки че тези диаграми не работят с бизнес концепции в самата UML спецификация, ентусиастите са измислили специални разширения, наречени "профили", за да опишат бизнес процесите. Профилите са по същество същите конвенции за моделиране, за които говорихме по-горе, с всичките им недостатъци. (Вижте също раздела „OMG за графична нотация за моделиране на бизнес процеси“ за това защо UML диаграмите на активността са неподходящи за тази задача.

BPMN(нотация за моделиране на бизнес процеси) [2] е спецификация, съдържаща графична нотация за описание на бизнес процеси, базирани на BPD диаграми. Разработен е от Инициативата за управление на бизнес процеси (BPMI) през 2001-2004 г. като се вземат предвид много вече съществуващи диаграми (включително всички споменати по-горе). Основната цел на тази инициатива беше да се получи нотация, която е лесна за разбиране от всички потребители - от бизнес анализатор, създаващ първите чернови на описания на процеси, до технически специалисти, отговорни за внедряването на тези процеси в Системата, и мениджъри, управляващи тези процеси и контролиращи тяхното функциониране.

Самият стандарт BPMN не дефинира файлов формат за запис на описания и обмен на информация (включително със системата), но вече има поне единспецификацията, която описва този формат, е XPDL. XPDL v.2.00 (www.wfmc.org/standards/docs/TC-1025_xpdl_2_2005-10-03.pdf) изрично посочва, че една от целите му е да служи като описание на файлов формат за BPMN нотация. С други думи, XPDL ви позволява да съхранявате не само логиката на процеса (като BPEL, друга спецификация за описание на бизнес процес, разбираем от машина), но също така и неговото графично BPMN представяне. Така файловият формат BPMN вече съществува, което позволява на различните инструменти за моделиране да се „разбират“.

След като се запознах по-подробно със спецификацията на BPMN (която всеки може да изтегли безплатно), най-накрая видях диаграми за описание на бизнес процеси с такова качество и такова ниво на сложност, че да могат веднага да бъдат използвани на практика. И според прегледите на хора, които не са запознати с нотациите за моделиране на бизнес процеси, BPMN диаграмите са наистина разбираеми на интуитивно ниво. За най-„заетите“ има и кратки извадки от спецификацията, подобно на комикси (www.bpmn.org/Documents/BPMN%20Fundamentals.pdf).

Що се отнася до инструментите за изграждане на BPMN модели, поради отвореността и разработката на тази спецификация, създаването на подходящи продукти (по-често разширяването на функционалността на съществуващите инструменти) е много активно днес. Сред десетките инструменти от този вид има и безплатни версии на програми с широк спектър от възможности - от моделиране на бизнес процеси до тяхното изпълнение от Системата (например Intalio).

Боже за графичната нотация на моделирането на бизнес процеси

В наскоро публикуван документ (www.omg.org/news/newsletters/OMG-Standard-Spring_2006.pdf), OMG изяснява своето разбиране за Service Oriented Architecture (SOA) и описания на бизнес случаи.процеси като част от управлявана от модел архитектура. Той също така показва как OMG стандартите (включително BPMN и UML) се вписват в слоевете на SOA модела.

И така, BPMN, според OMG, се използва на най-високото ниво - нивото на бизнес процесите, а UML - на нивото на софтуерните компоненти (за описание на интерфейсите между софтуерните компоненти и бизнес услугите).

В резултат на това обхватите на BPMN и UML са ясно разделени от разработчика на двете спецификации. Следователно, по-специално, човек може уверено да използва спецификацията на BPMN за моделиране на бизнес процеси, без да се страхува да бъде заменен от UML диаграми на активност.

OMG планира да въведе метамодела за дефиниране на бизнес процеси (BPDM) под BPMN, който работи по отношение на слоя на бизнес процеса, а не на софтуера. И само там, където има пресичания с вече съществуващ UML 2 метамодел, се предполага, че се използват елементи от последния в BPDM метамодела. Това може би е много съществената разлика между BPMN диаграмите и UML диаграмите на активността: елементите на техните модели имат различна семантика. Ето защо е по-правилно да се моделират бизнес процеси с помощта на диаграми, които имат подходящо значение (семантика), т.е. BPMN.

За да избегна недоразумения, бих искал да отбележа, че BPMN стандартните диаграми не заместват напълно подобни UML или ARIS конструкции. Те са предпочитани за описание на бизнес процеси (вместо процеси от всякакъв вид). Трябва да се помни, че в реален проект не можете да правите само без диаграми за описание на бизнес процеси: вие също трябва да използвате методологии за процес на разработка (например Extreme Programming или Rational Unified Process). Но това е тема на отделна статия.