Fundamentals of Business Process Managem-301-414.en - MK

284 8 Редизајн на процеси
опишано формално. Друг пример е функцијата за овластување што мора да се изврши за да се утврди
дали предлог за заем може да се испрати на клиент. Општо, оваа функција е прашање на човечко
расудување, кое мора да земе предвид голем број фактори. Од друга страна, ако износот на заемот е
мал, клиентот е познат клиент со соодветно покритие, а целта за набавка е стандардна, предлогот може
да биде прифатлив без дополнителен преглед.
Кога се опишани сите елементи на информации, нивната меѓузависност и логиката на производство, следува
чекор на финална анализа. Овој последен чекор е потребен за да се идентификуваат сите карактеристики кои се
релевантни за да се дизајнира деловен процес кој е ефикасен во однос на трошоците, сигурноста или брзината.
Чекорот на финалната анализа се состои од три чекори, кои ние овде ќе ги опишеме само:
Изворна анализа Изворната анализа е насочена кон идентификување на изворите на сите

лист елементи во моделот на податоци на производот, т.е. оние што не се потпираат на други информативни
елементи. Обично, повеќе извори се достапни за да се добие ист дел од информациите. На пример, евиденција
за историски дотации за надоместоци за невработеност може да се добие директно од подносителот на
барањето или од агенциите што ги обезбедиле овие додатоци во минатото. Друг пример е нечија позиција што
се плаќа на долг. Во Европа, банка може да ги добие овие информации од различни агенции за бодување (на
пр. Experian, Equifax, Schufa, BKR). Различни начини за добивање информации може да имаат различни
карактеристики. Клиентот може да биде многу подготвен да се само-пријавува информации за кредитни
позиции, но овие информации не можат да бидат многу сигурни. Слично на тоа, локалните власти можат да
обезбедат точни домашни информации по многу ниска цена, но нивното време на одговор може да биде
значително. Во зависност од критериумите што се идентификуваат во фазата на опсег, паметно е да се
идентификуваат можните извори за секој елемент од лисјата и последователно да се постигнат на релевантни
точки за споредување. Претпоставувајќи општи цели за извршување, како што се подобрување на ефикасноста,
враќање на времето на проток при одржување на (или подобрување) постојно ниво на квалитет, релевантни
точки за споредба за секој лист се: цена за добивање на истата, брзина на достава на информациите,
достапност на специфични информации и сигурност на дадените информации.
Анализа на производството Анализата на производството се фокусира на идентификуваното производство
правила со цел да се проценат вмешаните трошоци, брзина и квалитет на производство на нови

информации. Бидејќи може да има различни начини за да се добие дел од информациите, слично,
различни правила за производство обично постојат за истото парче информации. Дизајнирање на
процесот е во голем дел што е во прашање изборот на вистинскиот сет и правилниот ред за извршување
на правилата за производство, дадени збир на цели за изведба. Од овие цели станува јасно кои
критериуми за оптимизација преовладуваат. На пример, да претпоставиме дека важна цел за
постигнување има за цел намалување на цената на трудот. Ако има две правила за исто парче на
информации, може да се претпочита оној што трае најмалку време. На крајот на краиштата, формалното
правило за производство може да се автоматизира. Очигледно, оваа ефикасност треба да се тргне
наспроти трошоците и времето, што е вклучено во развојот на софтверот. Тука треба да се напомене дека
анализата на производството е многу одземаат многу време од фазата на анализа, уште повеќе кога
постои лоша традиција на мерење на работењето во рамките на оваа компанија. Времето тоа
8.4 Дизајн заснован на производи 285
треба да се инвестира во добивање на доверливи информации треба да биде избалансиран во однос на посакуваната
сигурност на проценките за квалитет на дизајнот на процесот.
Анализа на фракции Анализата на фракциите вклучува студија за распределбата на ин-

вредности на елементите на формирање. Како што веќе објаснивме, информативниот елемент може да
носи специфични вредности. На пример, вредноста на информативниот елемент „се бара патничко
осигурување“ може да биде да или не. Позициите за веројатноста информативните елементи да земат
специфични вредности може да бидат многу релевантни за дизајнирање на ефикасен процес. Во
комбинација со резултатите од анализата на производството (цена, брзина и сл.), Може да се утврдат
поволни нарачки за извршување на правилата за производство. На пример, да претпоставиме дека
постојат два правила за производство за ист информативен елемент со различни домени за
применливост, со многу различни влезни елементи, но со слична структура на трошоците за да се добијат
вредности за нив. Во таков случај, можеби е паметно од аспект на трошоците да се стремат кон
спроведување на правилото со најширока примена на првото место.
Како што стана јасно, секоја од одделните анализи е корисна за одлучување за вистинскиот дизајн на деловниот
процес што треба да се биде. Забележете дека чекорите не мора да бидат извршени според редоследот што е
опишано овде. Основа на материјата е дека резултатите од овие анализи заедно даваат добра основа за
вистинскиот чин на дизајнирање на процесите.
8.4.2 Дизајн: Добивање процес од модел на податоци на производот
Во овој дел, ќе разгледаме како може да се користи модел на податоци за производот за да се добие дизајн на процес.
За таа цел, ќе се осврнеме повторно на моделот на податоци на производите за пилотски хеликоптери. Кога развиваме
процес на дизајнирање, ќе овозможиме создавање активност за секој информативен елемент во моделот на податоци
на производот. Ваквата активност се занимава со создавање вредност за тој елемент на информации според одредено
правило за производство. Доколку има потреба, може да се појават повеќе од една активност за секој елемент на
информации. Таквите дупликати, на пример, можат да помогнат да се подобри читливоста на моделот на процеси што
го опишува дизајнот на процесот.
Активностите можат да бидат вклучени само во процесниот модел на начин што ќе се почитуваат зависностите
помеѓу информативните елементи во моделот на податоци на производот. Ова значи дека информативниот елемент
може да се создаде само со повикување соодветна активност ако дизајнот на процесот гарантира дека потребните
вредности за неговите влезни елементи може да бидат достапни. Така, на пример, ако сакаме да создадеме активност
што произведува вредност за елемент X врз основа на правило за производство што бара влезни вредности за Ј и З, дизајнот
на процесот треба да обезбеди дека вредностите за Ј и З. се создадени пред да се започне оваа нова активност.
Проектниот дизајн што се генерира со Дизајн заснован на производи на таков начин се нарекува точни Забележете дека
активностите за создавање вредности за елементите на лисјата можат да бидат вметнати во која било фаза: На крајот
на краиштата, тие не бараат влезови.

Сл. 8.5 Неправилен процес на дизајнирање за моделот на податоци на производи за пилотски хеликоптери
Слика 8.6 Правилен дизајн процес за модел на податоци за пилотски хеликоптери
Разгледајте ги моделите на процеси кои се прикажани на сл. 8.5 и 8,6 . Тие претставуваат
алтернативни дизајни дизајни. Двата дизајни вклучуваат активност што е вклучена во креирањето на
информативниот елемент А. На сл. 8.5 може да се види дека активноста „Креирај А“ ќе биде повикана по креирањето
на информативниот елемент Б, што се создава паралелно со последователното создавање вредности за Е и В. Сепак,
моделот на податоци на производот на Сл. 8.4 не покажува правило за производство за создавање вредност за В врз
основа на Е сам Сепак, постои правило за производство што покажува како комбинираната употреба на Е и F може
да се користи за тоа, но во овој дизајн нема вредност за F се определува пред создавање на вредност за В. Дизајнот
на сл. 8.5 е, според тоа, неточно.
Споредете го овој дизајн со оној на Сл. 8,6 . Еве, сите активности за создавање се
или производство на вредности за елементите на лисјата во моделот на податоци на производот ( Е, ,, Б) или создадете
вредности за информатички елементи врз основа на правила за производство за кои влезовите се создадени со претходни
активности ( Ц, А) Дизајнот во оваа насока е, според тоа,
точни
8.4 Дизајн заснован на производи 287
Сл. 8.7 Алтернативен дизајн процес за модел на податоци за пилотски хеликоптери
Вежба 8.10 Разгледајте го дизајнот на процесот што се визуелизира на сл. 8,7 . Дали е ова правилен дизајн процес?
Мотивирајте го вашиот одговор.
Се нарекува втор важен критериум што треба да се земе предвид за дизајнирање на процес што се генерира
со Дизајн заснован на производи комплетност. Дизајн на процес може или не може да ги опфати сите информации
што се идентификуваат во модел на податоци за производот. Ако дизајн процес ги опфати сите информативни
елементи во даден модел на податоци за производот, ние ќе го наречеме заврши. Размислете за дизајни на сл. 8.5 ,
8,6 , и 8,7 . Ниту еден од овие дизајни не опфаќа создавање вредност за Д, иако
Д е дел од моделот на податоци на производот на кој се однесуваат овие дизајни. Затоа велиме дека овие дизајни се не
заврши.
Да се остави создавање вредности за информатички елементи од дизајнот на процесот може да биде намерен
избор. Во таков случај, напуштање Д го инхибира потенцијалното определување на вредност за А користејќи го
правилото за производство што го има Д како влез. Многу е веројатно дека врз основа на анализата на податоците,
дизајнерот на процесите намерно одлучи да не ја вклучи оваа опција. Ова ќе има смисла во ситуација кога многу малку
апликанти се обидуваат повторно да се пријават за да станат пилотски хеликоптер. На крајот на краиштата, вклучително
и оваа опција може да го комплицира дизајнот, но да не додаде многу вредност во практични термини. Од друга страна,
дизајнерот можеби ја надгледувал оваа опција во целост, што објаснува зошто е корисно да се провери за
комплетноста.
Вежба 8.11 Развијте заврши процес на дизајнирање врз основа на хеликоптер пилот модел на податоци на
производи и фаќање на тој дизајн како процес процес.
Забележете дека дизајнот на процесот кој е комплетен во однос на информатичките елементи сè уште не може да
ги искористи сите достапни правила за производство. Без точни информации за тоа кои правила за производство се
користат за кои активности за создавање, сепак, ова може да биде тешко да се утврди. Јасно е, може да биде важно за
дизајнерите да проверат во практични апликации на Дизајн-базиран на производи, дали ги искористиле сите можности
што ги нуди моделот на податоци на производот.
Можеме да наметнеме други критериуми за квалитет на дизајнирање на процеси и многу од овие критериуми
можат да бидат извлечени од пошироко применливи. На пример, честопати сакаме да фатиме дизајн процес во
форма на а звук модерен процес, видете Поглавје. 5.4.1 . Во овој момент, го сметаме како поважно прашање перформанси
на процесот што е дизајниран со Дизајн заснован на производи. Споменавме дека за време на фазата на опсег на
проектот, треба да се утврдат критериуми за изведба за предметниот процес. Една од најважните отстапки е дали
дизајнот треба да резултира во а брз процес наспроти ефикасно процес. Брз процес може да биде дизајниран со
искористување на можностите за работа паралелно. Сепак, ова воопшто не може да биде ефикасен процес. Со
оглед на тоа што, генерално, може да има различни начини да се утврди вредност за истиот информативен
елемент, паралелен процес потенцијално предизвикува премногу работа. Поефикасен начин за спроведување на
процес ќе биде да се направи што е можно помалку работа, да се даде приоритет на помалку скапи, но ефективни
активности и да се однесува само на алтернативи доколку е апсолутно неопходно. Забележете како овие две
различни перспективи се совпаѓаат со паралелизам и нокаутирање на реунизацијата на хеуристиката за којашто
разговаравме претходно во ова поглавје.
Вежба 8.12 Да се развие целосен процес на дизајнирање врз основа на модел на податоци за пилотски
хеликоптери и да се фати како модел на процеси. Дизајнот треба да вклучува ефективен процес. Може да
претпоставите дека правилата за производство се создава вредност за А врз основа на Д или F се прилично, исто
како и создавање вредности за елементите на листот. Употреба на правилото за производство за А тоа има Б и В како
влезови, сепак, е многу поскап.
Додека многу други критериуми за изведба можат да бидат земени предвид при примена на
Дизајн-базиран на производи, нема да се справиме со нив на ова место. Важно е да се сфати дека
пософистициран поим за перформанси исто така ќе претпостави дека се достапни подетални информации. На
пример, ако е важно да се дизајнира a безбеден
процесот е важно да се разбере ризици кои се вклучени во добивање или создавање вредности за
елементи на информации.
8.5 Докажи
Во ова поглавје, разговаравме за мотивацијата за редизајн на процесите. Adаволот четириаголник ни помогна да
разјасниме дека многу опции за редизајн треба да се дискутираат од гледна точка на размена помеѓу времето, цената,
квалитетот и. Егзибилноста. На редизајн може да се пристапи како чисто креативна активност или со користење на
систематска техника. Во ова поглавје, ние се фокусираме на два од таквите систематски пристапи, имено, дизајн на
регрутација на хеуристички процеси и дизајн базиран на производи.
Методологијата на редизајн на хеуристички процеси вклучува фази на иницирање, дизајн и

евалуација. Различни хеуристики се достапни за поддршка на фазата на дизајнирање. Тие се фокусираат
на седумте области кои се поврзани со процеси, вклучувајќи клиенти, деловни процеси, деловно
однесување, организација, организација, информации, технологија и надворешно опкружување. Ние ја
проучувавме примената на некои хеуристики во случај на здравствена установа.
8.6 Решенија за вежби 289
Како алтернативен метод, разговаравме за пристапот за дизајн базиран на производи. Идејата е да се користи
моделот на распаѓање на производот како почетна точка и да се заклучи опции за тоа како би можел да изгледа
процесот на модел за конструирање на производот. Основно за овој метод е анализата и спецификацијата на
моделот на податоци на производот. Потоа, вистинскиот дизајн може да се подеси на посакуваните карактеристики
на изведбата на процесот.
8.6 Решенија за вежби
Решение 8.1 Ова е практична вежба. Потенцијал да се пристапи кон ова прашање може да биде да се
размислува за компании што нудат услуги што сега ги даваат другите компании преку Интернет.
Решение 8.2
1. „Авиокомпанијата забележа дека нејзините производи паѓаат во текот на изминатата година. Одлучува да започне маркетинг
кампања меѓу своите корпоративни клиенти со надеж дека може да го прошири своето деловно работење со шпедиција “: Не
е иницијатива за редизајн, нема врска за процесирање.
2. „Владина агенција забележува дека е структурно доцна да се одговори на прашањата на граѓаните. Одлучува
да му додели на раководителот да го надгледува овој конкретен процес и да преземе соодветни
контра-активности “: Редизајн се однесува учесници и
деловен процес самото.
3. „Компанија за изнајмување видеа дека нејзината база на клиенти испарува. Одлучува да се префрли на деловна
активност за промовирање и продажба на електронски услуги преку кои клиентите можат да гледаат филмови
преку Интернет и по барање “: Не толку многу иницијатива за редизајн на процеси; иако секако има врска до
процеси и производи, ова е многу повеќе стратешка иницијатива.
4. „Банката ги забележува внатрешните договори меѓу две различни оддели за начинот на постапување со
апликациите за хипотека. Одлучува да ја анализира улогата на различните одделенија во начинот на
прием и ракување со апликациите за да се појави нова структура на улоги “: Се допира иницијатива за
редизајн процес и учесници.
5. „Клиниката сака да воведе едношалтерски концепт за да се подобри состојбата со која нејзините пациенти
треба да направат одделни состаноци за различните дијагностички тестови, кои се дел од процедурата за
скрининг за карцином на кожата“: Се допишува иницијатива за редизајн процес и клиенти.
Решение 8.3
1. Справување со жалби од клиент: Соодветно.

2. Вршење кардиоваскуларна хирургија: Нежно погоден, тука се вклучени физички ограничувања.
3. Производство на машина за засилување на нафора: Не е многу погоден, високо физички процес.

4. Транспортирање на пакет: Нежно погоден, тука се вклучени физички ограничувања.
5. Давање финансиски совети за составување на портфолио: Погоден.

6. Дизајн на железничка станица: Погодно.
Решение 8.4 Разгледајте ги следните акти за редизајн. Кои мерки за изведба влијаат од нив,
позитивно или негативно?
1. „Развиена е нова компјутерска апликација што ја забрзува пресметката на максималниот износ на заем
што може да се понуди даден клиент“: Времето е позитивно влијание, развојот на апликацијата може
да биде скап.
2. „Секогаш кога службеникот сака да понуди понуда од финансиски давател на услуги, службеникот треба да користи директен
систем за пораки наместо е-пошта“: Квалитетот и времето може да бидат позитивно прикажани бидејќи повратните
информации се добиваат директно и може да бидат повеќе на точка. Квалитетот исто така може да има негативно влијание,
во зависност од видот на повратните информации што ги создава оваа интеракција.
3. „До крајот на годината, дополнителни, привремени работници се ангажирани и се распоредени да одберат предмети за
пополнување на Божиќни налози“: Ова обезбедува поголема сигурност што може да се искористи за подобрување на
навременоста. Јасно е дека е скапа афера и привремените работници може да испорачаат понизок квалитет бидејќи
се помалку запознаени со работењето.
Решение 8.5 На + знакот означува позитивен развој во однос на временската димензија. Бидејќи
редизајнирањето на процесите генерално се занимава со забрзување на процесот, позитивен придонес се
однесува на враќање на времето во однос на, на пример, време на циклус или време на услуга. Во случај
на хеуристичко намалување на контакт, најверојатно сценарио е времето да се намали што е поврзано со
чекање за одговор на клиенти или трети страни. Ова го објаснува знакот +.
Решение 8.6 Ова е практична вежба. Она што е важно е да се идентификува под кои претпоставки може да се
очекуваат позитивни или негативни влијанија.
Решение 8,7 Моделот за податоци на производот е прикажан на сл. 8,8 . Значењето на етикетите на информативните
елементи е како што следува:
1. ЛП: Предлог за заем, врвен елемент. Во рамките на предвидениот текст, ова е крајниот дел од
информациите што можат да се утврдат.
2. ДП: Одредба за отстранување. Ова е единствениот елемент што се споменува во дадениот текст како
информација што мора да биде вклучена во предлогот за заем.
3. ФК: Трошоци за финансирање на заемот. Токму овој информативен елемент мора да се спореди со rtp,
следниот елемент.
4. РТП: Награди на привремено сместување. Овој дел од информациите треба да се спореди со fc.
Одредбата за отстранување се заснова на оваа споредба.
5. Пратеник: Минималниот процент. Ова е всушност константа, која се користи под одредени услови.
8.6 Решенија за вежби 291
Слика 8.8 Решение за предлогот за заем
Решение 8,8 Правило за производство 1. Да се утврди вредноста за А врз основа на Б

и В: „Ако и психолошката сигурност и физичката моќ на кандидатот се сметаат за одлични, тогаш
кандидатот може да се смета за погоден да стане хеликоптерски пилот“.
Правило за производство 2. Да се утврди вредноста за А врз основа на Д: „Ако претходниот резултат на

тестот посочи дека кандидатот не е погоден да стане пилот на хеликоптер, тогаш кандидатот (сè уште) се смета
за несоодветен да стане пилот на хеликоптер“.
Правило за производство 1 е секогаш применливо. Правилото за производство 2 важи само доколку кандидатот
поминал претходен тест за соодветност.
Решение 8,9 Информативен елемент 1: Класа за издавање. Овој елемент на информации ја дава сериозноста на
проблемот што го носи клиентот. Може да се замисли како информативен елемент што произлегува од формалното
правило на производство, кога вработениот мора да користи пондерирана формула за проценка за да ја утврди оваа
сериозност.
Информативен елемент 2: Договор за клиент. Овој елемент за информации обезбедува мислење на клиентот
за тоа дали некое прашање е задоволително решено. Не постои формално правило за производство што го
поврзува со него. Клиентот дава свое мислење, кое не е регулирано со алгоритам.
Решение 8.10 Решението е прикажано на сл. 8,9 . Забележете дека дизајнот е завршен бидејќи се опфатени сите
информативни елементи на моделот за податоци на производот. Забележете дека не се вклучени сите правила за
производство, т.е. не постои начин да се утврди вредност за А врз основа на вредност за Б. Ова, сепак, не влијае на
неговата комплетност. Забележете исто така дека дизајнот е точен (проверете сами).
Решение 8.11 Решението е прикажано на сл. 8,10 . Забележете дека во овој дизајн колку што е направено малку
работа на секој чекор, во потрага по можности за брзо завршување на процесот. Прво, употребата на вредност за Д се
следи, но, се разбира, порано резултат може да не биде достапен. Следно, вредност за F е создадено. Под одредени
околности, т.е. кога
Сл. 8.9 Комплетен процес на дизајнирање за хеликоптерскиот пилот модел на податоци на производи
Сл. 8.10 Ефикасен дизајн на трошоците за модел на податоци за пилотски хеликоптери
погледот е многу лош, ова може да доведе до утврдување на вредност за А ( не е соодветно). Ако ова не успее да го
запре процесот, не постои друга опција освен да се произведат вредности за сите останати информативни
елементи. Споредете го овој дизајн со решението за претходната вежба.
8.7 Понатамошни вежби
Вежба 8.13 Следното е буквалниот опис на случајот за редизајн во IBM кредитна корпорација, земен од
книгата „Реинженеринг на корпорацијата“ од Хамер и Чампи [ 29 ] Таа е поделена на неколку делови. Ве
молиме, прочитајте ги овие и одговорете на прашањата.
Првиот наш случај се однесува на IBMCredit Corporation, целосно подружница на IBM, која, доколку беше
независна, ќе се рангираше меѓу услужните компании Fortune 100. IBM кредитот е во деловно финансирање на
компјутерите, софтверот и услугите што ги продава IBM Corporation. Тоа е бизнис за кој е fondубител ИБМ, бидејќи
финансирањето на набавките на клиентите е исклучително про-маса за бизнис. Во раните години, работењето на
ИБМ Кредит беше позитивно Дикенсијан. Кога се повикаа продавачите на IBM, со барање за финансирање, тие
достигнаа едно од 14 лица што седеа околу трпезаријата во Олд Гринич, Конектикат. Лицето кое го повикувало
повикот го напишал барањето за договор на парче хартија. Тоа
8.7 Понатамошни вежби 293
беше првиот чекор. Во чекор два, некој го испрати тоа парче хартија горе до одделот за кредитирање, каде специјалист
ги внесе информациите во компјутерски систем и ја провери веродостојноста на потенцијалниот заемопримач.
Специјалистот ги напиша резултатите од кредитната проверка на парче хартија и го испрати на следната алка во
ланецот, а тоа беше одделот за деловни практики. Секторот за деловни практики, чекор 3, беше задолжен за
изменување на стандардниот завет за заем како одговор на барањето на клиентот. Деловните практики имаа сопствен
компјутерски систем. Кога е готово, едно лице во тој оддел ќе ги приложи посебните услови на формуларот за барање.
Следно, барањето се упати кон побар, чекор 4, кој ги внесе податоците во табела за персонален компјутер за да утврди
соодветна каматна стапка за наплата на клиентот. Починот ја напиша стапката на парче хартија, која, со другите
трудови, беше доставена до клерична група, чекор по чекор. Таму, администраторот ги претвори сите овие информации
во понуда што може да му биде доставена на поранешниот претставник за продажба од страна на Федералниот
експрес.
(а) Модели го опишаниот деловен процес. Користете базени и ленти кога е потребно. Целиот процес трошеше во
просек шест дена, иако понекогаш траеше две недели. Од гледна точка на претставниците на продажбата, овој
пресврт беше предолг, бидејќи му даде на клиентот шест дена да најде друг извор на финансирање, да биде заведен
од друг продавач на компјутер, или едноставно да се исклучи целиот договор. Така, претставникот би повикал
повторно и повторно да праша: „Каде е мојот договор, и кога ќе го искористите?“ Секако, никој немаше поим, бидејќи
барањето беше изгубено некаде во ланецот.
б) Која димензија на adаволот четириаголник би била доминантна за редизајн? Дадете точна

дефиниција на критериумот за изведба.
Во нивните напори да го подобрат овој процес, ИБМ Кредит се обиде со неколку наоди. Тие, на пример, решија
да инсталираат контролен биро, за да можат да одговорат на прашањата на претставниците за статусот на
договорот. Тоа е, наместо секое одделение да го проследи кредитното барање на следниот чекор во ланецот,
тоа ќе го врати на контролното биро, каде што првично биле направени повиците. Таму, администраторот го
најавил завршувањето на секој чекор пред повторно да ја испрати хартијата. Ова fi x навистина реши еден
проблем: Контролната табла ја знаеше локацијата на секое барање во лавиринтот и може да им ги даде на
претставниците информациите што ги сакаат. За жал, овие информации беа купени по цена на додавање повеќе
време на пресвртот. (в) Моделирајте го прилагодениот процес. Користете базени / ленти кога е потребно.
Конечно, двајца високи менаџери на ИБМ Кредит имаа бура од мозок. Тие зедоа финансиско барање и го
проследија сами низ сите чекори, барајќи од персоналот во секоја од службениците да остават настрана што и да
прават и да го процесуираат ова барање како што тоа би го правеле, само без одлагање да седнат во куп на нечија
биро . Од нивните експерименти дознале дека извршувањето на вистинската работа трае вкупно само 90 минути -
еден и пол часа. Остатокот - сега во просек повеќе од седум дена - беше потрошен со предавање на формуларот од
едно одделение до другото. Менаџментот започна да го разгледува срцето на проблемот, што беше целокупниот
процес на издавање кредити. Навистина, ако преку бран на некое волшебно стапче компанијата можеше да ја удвои
личната продуктивност на секој поединец во организацијата, вкупното време на пресврт ќе се намали за само 45
минути. Проблемот не лежеше во активностите и луѓето што ги извршуваат, туку во структурата на самиот процес.
Со други зборови, тоа беше процесот што требаше да се промени, а не индивидуалните чекори.
На крајот, ИБМ Кредит ги замени своите специјалисти - кредитни четки, цени и сл. Со генералисти. Сега, наместо да
испрати апликација од канцеларија до канцеларија, едно лице наречено структурист на зделки ја обработува целата
апликација од почеток до крај: Нема испраќања.
Како може еден генералист да замени четворица специјалисти? Всушност, стариот дизајн беше
основан врз длабоко претпоставена (но длабоко скриена) претпоставка: дека секое барање за понуда
беше уникатно и тешко за обработка, со што се бара интервенција на четири високо обучени
специјалисти. Всушност, оваа претпоставка беше лажна; повеќето барања беа едноставни и директни.
Стариот процес беше премногу дизајниран да се справи со најтешките апликации што може да се
замислат управувањето. Кога постарите менаџери на ИБМ Кредит внимателно ја испитуваа работата
што ја направија специјалистите, тие откриле дека повеќето од нив биле малку повеќе од свештени: fi
вметнување кредитен рејтинг во базата на податоци, приклучување броеви во стандарден модел,
повлекување на клаузулите за котлитарките од le.
IBM кредит, исто така, разви нов, софистициран компјутерски систем за поддршка на структуторот на зделките. Во повеќето
ситуации, системот му обезбедува на раководителот на зделките насоки потребни за да се продолжи. Во навистина тешки ситуации,
структуристот на договорот може да добие помош од мал базен на вистински специјалисти-експерти за проверка на кредити, цени и
сл. Дури и овде откачените одбори исчезнаа затоа што структурите на договорот и специјалистите што тој или таа ги повикува да
работат заедно како тим.
Подобрувањето на перформансите постигнато со редизајнот е извонредно. ИБМ Кредит го намали седумдневниот
пресврт на четири часа. Тоа го стори без зголемување на фабриката за глава, има постигнато мало намалување на
глава. Во исто време, бројот на зделки со кои се справува се зголеми за сто пати. Не 100 проценти, туку 100 пати. (д)
Разгледајте го списокот на хеуристиката што е опфатена во овој труд. Кој од овие може да го препознаете во
редизајнирање на новиот процес?
Вежба 8.14 Наведете во кој поглед примената на Екстернализација хеуристички и составот на поголемите
активности - како специфичен случај на Активен состав хеуристички — може да доведе до слични или различни
резултати. Користете ги димензиите на перформансите на Четворицата на ѓаволот и дадете специфични
толкувања.
Вежба 8.15 Разгледајте го процесот на изнајмување опрема опишан во Пример 1.1

(стр. 2 ) и соодветните изданија документирани во Пример 6.4 (стр. 199 ) а Применете ја редизајнската хеуристика со
цел решавање на проблемите документирани во Испитот-

молам 6.4 .
б Фатете го како резултат моделот во BPMN.

в Објаснете го влијанието на промените што ги предлагате во смисла на дијалог за перформанси
тензии на четириаголникот на ѓаволот.
Вежба 8.16 Разгледајте го процесот на прием во универзитет опишан во вежба 1.1

(стр. 4 ) и соодветните теми документирани во вежба 6.4 (стр. 201 година ) а Применете ја редизајнската хеуристика со
цел решавање на проблемите документирани во Ексер-

лечи 6.4 .
Вежба 8.17 Разгледајте го целиот процес на рецепт во аптека опишан во вежба 1.6 (стр. 28 ) и
соодветните теми документирани во вежба 6,9
(стр. 209 година )
8.8 Понатамошно читање 295
а Применете ја редизајнската хеуристика со цел решавање на проблемите документирани во Испитот-
молам 6,9 .

Вежба 8.18 Размислете за постапката на набавка за плаќање опишана во вежба 1.7 (стр. 29 ) и соодветните теми
документирани во вежба 6.10 (стр. 210 ) а Применете ја редизајнската хеуристика со цел решавање на проблемите
документирани во Испитот-
молам 6.10 .

8.8 Понатамошно читање
Мајкл Хамер напишал многу, многу вредни книги со своите коавтори за редизајн на процеси, на
пример [ 27 , 29 ] Други книги за управување што се занимаваат со темата се, на пример, [ 10 , 46 , 86 ] За
разлика од темата моделирање на процеси, редизајнирањето на процесите не привлече толку
големо внимание од научната заедница. Кога се изучува BPR, фокусот е претежно на студии на
случаи или се изучува дифузија на концептот во самата практика, на пример во кои домени се
применува или во кои земји е најпопуларен. Една од најинтересните студии во оваа категорија е
доста датирана [ 62 ], но јасно ги покажува проблемите со она што првично се сметаше за редизајн на
деловните процеси и како тоа брзо се разви во постепен пристап. Многу интересна студија за
карактеристиките на различните методологии за редизајн е дадена во [ 41 ], кој инспирирал различни
поими што биле разгледани во овој дел од книгата.
Редизајнската хеуристика за која се дискутираше во ова поглавје е опишано во неколку детали. По

нивната првична презентација како најдобри практики во [ 72 ], тие се потврдени и понатаму анализирани во
следните студии [ 47 , 48 ] Тековните напори од страна на разни истражувачи се насочени кон поддршка на
практичарите во правење разумен избор на редизајнска хеуристика во специфични случаи [ 30 , 44 ] Исто така,
направени се обиди да се прошири сетот на редизајн-хеуристика на нивната примена во други домени, на
пример во [ 58 ]
Дизајн заснован на производи е развиен на Универзитетот за технологија во Ајндховен во соработка со

холандска консултантска компанија. Достапни се различни студии на случаи, кои даваат подобра идеја за
практична примена на овој метод и за нејзините потенцијални придобивки [ 70 , 71 ] Неодамна, акцентот на
истражувачите кои работат на оваа тема се движи кон автоматско создавање на дизајни на процеси и
автоматска поддршка за извршување на ваквите процеси [ 100 ] Друг начин за разгледување на Designbase
Design е дека тоа е пристап што ги меша податоците и процесите. Ова е моментално жешка тема: Во оваа
смисла, пристапот за моделирање на процесите на IBM за артефакт-центрично [ 36 ]
и структурите на процесот управувано од податоците развиени од Универзитетот во Улм [ 57 ] се споредливи

пристапи.
Едно од главните отворени прашања во областа на редизајнирање на процесите е во која мера има смисла да се
следат индустриски референтни модели или да се обидат и да се развијат дизајни за специфични компании. Додека
индустриските референтни модели ги нудат многу продавачи, не е толку очигледно што тие претставуваат најдобар можен
начин за спроведување на процеси.

Поглавје 9
Автоматизација на процеси
Покрај црната уметност, постои само автоматизација и механизација.

Федерико Гарсија Лорка (1898–1936)
Ова поглавје се занимава со автоматизација на процесите. Прво, ќе објасниме што е автоматизиран деловен
процес, по што ќе се фокусираме на специфичен вид технологија што е особено погодна за да се постигне
автоматизација на процесите, т.е. Системи за управување со деловните процеси (BPMSs). Ние ќе ги објасниме
карактеристиките и предностите на овие системи, ќе ги претставиме различните видови на BPMS и ќе разговараме
за некои од предизвиците што се поврзани со воведување на BPMS во една организација. Конечно, ќе разговараме
за тоа какви промени се потребни во а деловно ориентирана процес процес како оние што се гледале досега, да го
направат извршна и работи во BPMS.
9.1 Автоматизирање на деловните процеси
Автоматизацијата на процесите е предмет на кој може да се пристапи од различни агли. Во широка смисла, може
да се однесува на намерата да се автоматизира кој било замислив дел од процедурална работа што е содржан во
деловниот процес, од едноставна операции кои се дел од а сингл процесна активност до автоматизирана
координација на цела, сложени процеси.
На пример, земете го процесот на целосна нарачка што го моделиравме во Поглавје. 3 . Ау-
tomating таков процес може да значи дека секој пат кога продавачот добива нарачка, ова автоматски се
испраќа до системите ERP на одделот за складирање и дистрибуција, каде достапноста на производот се
проверува против базата на податоци на магацинот. Ако производот не е во залиха, соодветните
добавувачи автоматски се контактираат, на пр. Преку Интернет-услуга, за производство на производот. Во
спротивно, упатствата се испраќаат до работник во магацин, на пр. Со употреба на електронска форма,
рачно да го повратат производот од магацин. Последователно, службеникот за нарачки од продажба
добива нотификација дека треба да се потврди нова нарачка,
на пр. преку е-пошта. Тој службеник потоа се најавуваше во системот за следење на нарачките во рамките на продажбата, ја
гледаше нарачката електронски и ја потврдуваше со притискање на копче и слично.
М. Думас и др., Основи на управување со деловните процеси, 297

ДОИ 10.1007 / 978-3-642-33143-5_9 , © Springer-Verlag Berlin Heidelberg 2013
298 9 автоматизација на процеси
Во овој пример, испраќањето на нарачката, автоматската проверка на достапноста на производот или

автоматизираните веб-пораки се сите манифестации на автоматизација на процесите во најширока смисла: тие
автоматизираат одреден аспект на еден процес. Во овој контекст, ќе се осврнеме на една автоматизиран
деловен процес, исто така познато како работа ow, како процес што е автоматизиран во целост или делумно од
страна на софтверски систем, кој пренесува информации од еден учесник на друг за дејствување, според
временските и логичките зависности поставени во основниот модел на процеси. Да разгледаме сега системи
кои работат со автоматски деловни процеси.
9.1.1 Системи за управување со деловните процеси
Специфичен вид автоматизација на процесите, за што особено се занимаваме во оваа книга, го искористува
знаењето за тоа како различни процесни активности се однесуваат еден на друг. Со други зборови, типот на
информациони системи што ги сметаме се процесор Главната категорија на процесни информативни системи за
кои ќе разговараме се т.н. Системи за управување со деловните процеси ( БПМС). Додека постојат и други
видови на системи за запознавање со процесите, како што се системите за управување со врските со клиентите
(CRM) и системите за планирање на ресурсите на претпријатијата, посебната карактеристика на BPMS е дека
тие користат експлицитен опис на деловниот процес, во форма на а процесен модел, да го координира тој процес.
Во таа смисла, БПМС може да се прилагоди на специфични процеси од секаков вид.
Целта на BPMS е да се координира автоматизиран деловен процес на таков начин што целата работа е
извршена во вистинско време од вистинскиот ресурс. Да се објасни како BPMS го остварува тоа, корисно е да
се види дека BPMS е на некој начин сличен на a
Систем за управување со бази на податоци ( DBMS). DBMS е стандард, надвор од полицата софтверски пакет што го
нудат многу продавачи во многу различни авори, како што се Microsoft SQL Server, IBM DB2 или Oracle база на
податоци. Со DBMS е можно да се фаќаат специфични податоци за компанијата на структуриран начин, без притоа
да се земе предвид како се одвива точното пребарување и чување на вклучените податоци. Овие задачи се грижат
за стандардните капацитети на системот. Се разбира, во одреден момент е неопходно да се конструира ДБСМ, тоа
ќе биде со податоци и може да биде потребно периодично да се прилагодува системот и неговата содржина на
реалните барања.
На сличен начин, BPMS е исто така стандарден вид софтверски систем. Продавачите нудат
различни BPMS со различен сет на карактеристики, опфаќајќи го целиот животен циклус на
процесите: од едноставни системи, кои се грижат само за дизајнирање и автоматизација на
деловните процеси, до покомплексни системи, кои вклучуваат и функционална интелигенција на
процесите (пр. Напреден мониторинг и рударство на процеси), сложено обработка на настани,
функционалност на SOA и интеграција со трети апликации и социјални мрежи. И покрај
разновидноста на функционалност што може да ја понуди BPMS, основната карактеристика на таков
софтверски систем престојува во автоматизација на деловните процеси. Со BPMS, можно е да се
поддржи извршувањето на специфичен деловен процес со користење на стандардни капацитети
што ги нуди системот. Сепак,
9.1 Автоматизирање на деловните процеси 299
Сл. 9.1 Архитектурата на BPMS
БПМС може да го поддржи неговото извршување. Од моментот кога процесот ќе биде фатен во формат со кој
BPMS може да работи со, важно е тој опис на деловниот процес да биде ажуриран, така што процесот ќе биде
поддржан правилно со текот на времето.
Во минатото, главно пред појавата на BPMS, постоеја голем број на алатки фокусирани на
автоматизација на процесите, кои не опфаќаа функционална интелигенција на процесите и кои имаа
релативно минимална поддршка за моделирање на процеси. Овие алатки беа познати под името на Системи
за управување со работа
(WfMSs). Со текот на времето, многу од овие алатки се развија кон BPMS. Покрај тоа, постојат мноштво на самостојни алатки кои
опфаќаат единствена карактеристика на напредни BPMS, како што се самостојни алатки за моделирање на процеси, алатки за
симулирање на процеси и алатки за аналитички процеси. Сите овие алатки обезбедуваат вредност за поддршка на различни
делови од циклусот на животниот циклус на БПМ, но генерално не ја поддржуваат автоматизацијата на процесите. Поради оваа
причина, тие нема да бидат во фокусот на ова поглавје.
9.1.2 Архитектура на БПМС
Слика 9.1 ги покажува главните компоненти на BPMS, имено моторот за извршување, алатката за моделирање на
процесите, управувачот на работната листа и алатките за администрација и мониторинг. Моторот за извршување може да
комуницира со надворешни услуги.
Мотор за извршување Централно за БПМС е мотор за извршување. Моторот про-

опфаќа различни функционалности, вклучувајќи: (i) можност за создавање случаи на извршна постапка (исто
така наречени случаи); (ii) можност за дистрибуција на работа за да се процесираат учесниците со цел да се
изврши деловен процес од почеток до крај; (iii) можност за автоматско преземање и чување на податоците
потребни за извршување на процесот и за делегирање (автоматизирани) активности на софтверски
апликации низ целата организација. Севкупно, моторот континуирано го следи напредокот на различните
случаи и ги координира кои активности да работат понатаму со генерирање
работни артикли, односно случаи на процесни активности за кои треба да се води грижа
Сл. 9.2 Алатка за моделирање на процеси на Отворено решение на Bonita од Bonita Soft
специфични случаи. Работните артикли потоа се распоредуваат на ресурси кои се квалификувани и овластени
да ги спроведат овие работи. Поточно, моторот за извршување комуницира со другите компоненти, како што е
дискутирано следно.
Алатка за моделирање на процеси Компонентата за алатки за моделирање на процеси нуди функционалност
како што е (i) можноста на корисниците да создаваат и модифицираат модели на процеси; (ii) можност за анотација
на модели на процеси со дополнителни податоци, како што се внесување и излез на податоци, учесници, деловни
правила поврзани со активности или мерки за изведба поврзани со процес или активност; и (iii) можност за чување,
споделување и преземање на модели на процеси од а складиште за моделен процес. Може да биде процес на модел
распоредени до моторот за да се изврши. Ова може да се направи или директно од алатката за моделирање
или од складиштето. Моторот го користи моделот на процеси за да го одреди временскиот и логичкиот
редослед според кој треба да се извршат активностите на еден процес. Врз основа на тоа, утврдува кои работи
треба да се генерираат и на кого треба да бидат распределени или кои надворешни услуги треба да бидат
повикани. Слика 9.2 ја покажува алатката за моделирање на процесите на Отвореното решение Бонита од
Бонита Мек.
Ракувач со работни листи Ракувачот со работни списоци е компонента на BPMS преку кој
учесниците во процесот се (i) понудени работи за работи и (ii) се обврзуваат на нив. Тоа е моторот за
извршување кој следи кои работи се должни и ги прави достапни преку ракувачите со работните листи на
индивидуалните учесници во процесот. Стандардниот управувач со работни списоци на BPMS најдобро може
да се замисли како таков инбокс, слично на оној на клиент за е-пошта. Преку инбокс, учесниците можат да
видат кои работи се подготвени за нивно извршување. Ракувачот со работната листа може да користи
електронски формулари за податоци за влез и излез на активност. Кога работната ставка од оваа активност е
избрана и започната од учесникот од нивната работна листа, корелот
Слика 9.3 Ракувачот со работни листи на BPM Suite на Bizagi
електронската форма што се пренесува се прикажува на екранот. Овој чекор се нарекува одјавување
Учесниците потоа можат да внесат податоци во формуларот и да го завршат сигналот до моторот. Овој чекор се
нарекува проверка Потоа, моторот ги одредува следните работни артикли што мора да се извршат за предметниот
случај. Честопати, учесниците можат до одреден степен да извршат контрола врз работните елементи во нивната
работна листа, на пример, во однос на редоследот по кој се прикажани и приоритетот што им го даваат на овие
работни артикли. Исто така, управувачот со работни списоци обично поддржува учесник во процесот привремено
суспендирање на работните предмети или предавање на контролата на некој друг. Кои точни карактеристики се
достапни, зависи од односниот БПМС и неговите специфични гаранции. Прилично е вообичаено да се прилагодат
ракувачите со работни листи, на пример според корпоративниот дизајн, за да се поттикне нејзиното ефикасно
користење и прифаќање во рамките на една организација. Слика 9,3 го прикажува управувачот на работната листа на
BPM Suite на Bizagi.
Надворешни услуги Можеби е корисно да се вклучат надворешни апликации во извршувањето
на деловниот процес. Во многу деловни процеси, постојат активности што не треба да се извршуваат на
целосно рачен начин. Некои од овие активности можат да се извршат целосно автоматски, така што моторот
за извршување може едноставно да повика надворешна апликација, на пример за да ја процени
кредибилитетот на клиентот. Надворешната апликација треба да изложи сервисен интерфејс со кој моторот
може да комуницира. Така, ние едноставно се повикуваме на такви апликации како што се надворешни
услуги. Моторот за извршување обезбедува повикана услуга со потребните податоци што им се потребни за
вршење на дејноста за специфичен случај. По завршувањето на барањето, услугата ќе го врати исходот на
моторот и ќе сигнализира дека работната ставка е завршена. Ова, повторно, се чува во дневникот за
извршување. Некои други активности во деловниот процес не се ниту целосно рачни, ниту целосно
автоматизирани. Наместо тоа, ваквите активности треба да ги извршуваат учесниците во процесот со
некаква форма на автоматска поддршка. За оваа категорија активности, моторот за извршување ќе се
повика на соодветни услуги со соодветни параметри, точно во моментот
Слика 9.4 Алатка за набудување на BPMOne на перцептивен софтвер
дека вработениот избира одредена работна ставка на која ќе работи. Типичен пример би бил повикувањето на
Систем за управување со документи (DMS) за прикажување на учесникот во процесот што е важно за
извршување на специфична работна ставка. Помислете на барањето за изнајмување опрема, каде тоа ќе му
помогне на службеникот да го одреди соодветното парче опрема за нарачка. Понекогаш исто така, БПМС
можеби ќе треба да пренесе контрола врз случаи помеѓу различни организациони единици или организации.
Еден начин да се постигне ова е преку интеракција со надворешен BPMS кој изложува сервисен интерфејс за
оваа намена. На пример, размислете за глобална осигурителна компанија која има канцеларии во три различни
временски зони: Јапонија, Велика Британија и Калифорнија. На крајот на работниот ден во секоја од овие
временски зони, сите работни артикли можат да се пренесат на моторот за извршување во следната зона каде
штотуку започна работниот ден. На овој начин, извршувањето на деловниот процес никогаш не запира.
Алатки за администрација и мониторинг Алатки за администрација и мониторинг се

алатки потребни за администрирање на сите оперативни работи на БПМС. Размислете, како главен пример,
вистинската достапност на специфичните учесници. Ако некој е недостапен да работи заради болест или одмор,
БПМС треба да биде запознаен со овој факт за да се избегне распределба на работни артикли на такво лице.
Алатките за администрација исто така се потребни за справување со исклучителни ситуации, на пример за
отстранување на застарените работни артикли од системот. Алатките за администрација се исто така опремени
со функционалност за набудување на процесите. Може да се користат овие алатки за да се следат
перформансите на деловните процеси, особено во однос на напредокот на поединечни случаи. Овие алатки
можат да соберат податоци од различни случаи, како што се просечни случаи на циклус на случаи или дел од
случаи што се доставуваат премногу доцна. BPMS го запишува извршувањето на моделот на процеси чекор по
чекор. Настаните поврзани со извршувањето, снимени на овој начин, се чуваат и можат да се извезуваат во
форма на трупци за извршување. Некои алатки за набудување можат да ги анализираат историските податоци
извлечени од дневниците и да ги споредат со податоците во живо (види Поглавје. 10 ) Слика 9,4 ја покажува
алатката за набудување на BPMOne на перцептивниот софтвер. Оваа генеричка архитектура, која го поддржува
функционирањето на кој било BPMS, е еволуција на референтен модел за WfMSs, предложен од работата
Менаџмент коалиција (WfMC) во деведесеттите години. На овој модел се проширува посветен кутија „WfMC
Reference Model“.
За да илустрирате како работи БПМС, потсетете се на деловниот процес на „Изградба“ за изнајмување опрема
од Поглавје. 1 . Да претпоставиме дека е поддржано од БПМС. Моторот за извршување може да го следи тоа за
нарачките # 1.220 и # 1.230 инженери на страници веќе ги објавивме барањата за изнајмување опрема. Врз основа
на процесен модел на процес на опрема за изнајмување, моторот за извршување може да открие дека и за двата
случаја мора да се утврди соодветно парче опрема. Ова треба да го направи кој било службеник во депо. Затоа,
BPMS го доставува барањето до сите ракувачи со списоци на работни места од сите службеници за понатамошна
обработка. За нарачката # 1.240 од друга страна, барањето за изнајмување на опрема сè уште не е достапно. Значи,
моторот BPMS сè уште нема да помине на слично барање за оваа нарачка. Наместо тоа, ќе чека завршувањето на
оваа работна ставка.
Вежба 9.1 Во која состојба се спроведува процесот по извршување на сите активности на процесот на изнајмување на
„Изградба“ како што е опишано погоре? Кои работни артикли можете да ги идентификувате кои се под контрола на
BPMS? Осигурете се да ги идентификувате случајот и активноста за секоја работна ставка.
Модел за референца на WfMC

Коалицијата Work ow owManagement (WfMC) е организација за стандардизација, основана во 1993
година, во којашто седиште имаат продавачите, корисниците и истражувачите на BPMS. Целта на
WfMC е да се постигнат општо прифатените стандарди за терминологија и интерфејси за
компонентите на BPMS [ 35 ]
WfMC има произведено т.н. Референтен модел WfMC кој стана добро воспоставен во светот на
автоматизација на процесите. Идејата што стои зад овој референтен модел е дека секој снабдувач на
BPMS може да го објасни функционирањето на специфичниот систем врз основа на истиот.
Оригиналниот референтен модел вклучуваше шест компоненти, кои потсетуваат на компонентите на
архитектурата BPMS на Сл. 9.1 . Тие се: работен мотор, алатки за моделирање на процеси, алатки за
администрирање и мониторинг, управувач со списоци со работа, надворешни апликации и
надворешни BPMS. Во референтниот модел, интеракциите помеѓу неговите компоненти се одвиваат
преку т.н. интерфејси, кои се нумерираат од 1 до 5. Три од овие интерфејси сè уште се препознатливи
во архитектурата BPMS за која се дискутира во ова поглавје:
• Интерфејс 1 се однесува на интеракцијата помеѓу моторот и алатките за моделирање на процеси,
• Интерфејс 2 се однесува на интеракцијата помеѓу моторот и управувачот со работната листа,
• Интерфејс 5 се однесува на интеракцијата помеѓу моторот и администрацијата и алатките за

набудување.
Другите интерфејси на референтниот модел WfMC се поткопани од неодамнешните случувања. Интерфејс

3 управуваше со интеракцијата помеѓу ИТ апликациите и моторот за извршување, но ова стана
застарено со доаѓањето на стандардни сервисни интерфејси преку Интернет (на пр. веб-услуги).
Слично на тоа, интерфејс 4 „Она што се осврна на интеграцијата со надворешните BPMS-а“ исто така се
претпоставува дека ова може да се реализира и преку стандардни интерфејси за услуги.
Додека повеќето компоненти на референтниот модел WfMC повторно се појавуваат во

архитектурата BPMS на Сл. 9.1 , треба да се напомене дека архитектурата WfMC не го вклучува
складиштето на моделот на процеси и не ги изразува експлицитно логовите за извршување. Сепак, овие
елементи станаа клучни средства во областа на автоматизација на процесите, анализа и редизајн.
Вежба 9.2 Разгледајте ги следниве прашања за BPMS:
• Зошто не би било соодветно да се создаде само модел на деловен процес со алатки за

моделирање, без никакви информации за видовите ресурси што се достапни?
• Во каква ситуација, моторот за извршување ќе генерира повеќе работни артикли врз основа на завршување на
единствена работна ставка?
• Можете ли да дадете примери на надворешни услуги што можат да бидат корисни за да бидат повикани кога
учесникот сака да изврши работна ставка?
• Кој би бил минимален услов да може да се пренесат работни артикли помеѓу BPMS на
осигурителната компанија што беше даден како пример?
• Ако е важно БПМС да им подари работни артикли на расположивите ресурси, дали можете да замислите
други, релевантни типови информации за ресурси што се корисни за да бидат зафатени со алатка за
администрација (за разлика од тоа дали се болни или на одмор)?
9.1.3 Случај на ACNS
Земајќи го предвид објаснувањето на архитектурата BPMS во претходниот дел, сега е можно да се скицира
пример за оперативен BPMS. Ние користиме поедноставен приказ за процес во кој побарувањата се
проценуваат во рамките на компанијата ACNS ( Тврдење не е срам). Првата активност во овој процес е
проценка на побарувањето, што треба да ја изврши постар примател или редовен примател. Редовниот
прифаќач е квалификуван само за да ја направи оваа проценка во ситуација кога износот на побарувачката
на случајот е подолу € 1.000. Во случај на негативна проценка, одговорно е на менаџерот на сметката да ги
пренесе лошите вести на клиентот. Во случај на позитивна проценка, електронска фактура се генерира од
службеникот на одделот за финансии, кој треба да му ја испрати на клиентот за кој станува збор. После
овие активности, процесот е завршен.
Горенаведениот опис покажува дека постојат две димензии кои мора да бидат опфатени со алатката за
моделирање на процеси на BPMS: (1) постапката што ги специфицира различните активности и (2) различните
учесници кои се вклучени во спроведувањето на овие активности. Поранешниот дел е снимен во процесен
модел; вториот е зафатен, како што честопати се нарекува, а класификација на ресурси. Покрај тоа, односите
помеѓу овие модели или спецификации мора да бидат дефинирани, т.е. кој е способен и квалификуван да ја
извршува која активност. Честопати, овие односи се специфицирани како дел од процесниот модел. Овие
односи можеби не се статични, но зависат од сите видови на деловно правило. На пример, разликата помеѓу
нивоата на овластување на постариот и обичниот прифатен во проценката на побарувањата е пример за
динамично правило, т.е. се определува според сегашната вредност на едно парче од информации.
Откако ќе се дефинираат овие описи, моторот за извршување на BPMS генерално ќе може да го поддржи
овој процес. Сега да претпоставиме дека скоро истовремено се појавуваат две побарувања:
1. Оштетување на автомобил од € 12.500, како што тврди г-дин Буман.
2. Оштетување на автомобил од € 500, како што тврди г-ѓа Филерс.
Г-ѓа Отаген е подолго време со ACNS и, изминатите години, функционира на ниво на постар
прифаќач. Овој месец, г-дин Триенекенс започна со тренинзи и работи како прифаќач. На почетокот на
неговиот договор, администраторот на системот, г-дин Вербејк, ја искористи алатката за администрација
на БПМС за да додаде г-дин Триенекс во базенот на достапни прифаќачи.
Врз основа на моделот на постапката, класификацијата на ресурсите и оперативните податоци за достапноста на
различните вработени, услугата за донесување решенија на БПМС сега се грижи да ги пренасочи и новите примени побарувања
до раководителите на работните списоци на г-ѓа Отаген. На крајот на краиштата, таа може да ги процени и двете побарувања
врз основа на нејзините квалификации. Г-дин Триенексенс, пак, ќе го види само во својот управувач со работни списоци
побарувањето за штета на г-ѓа Филерс.
Забележувајќи ја работната ставка во работната листа, г-дин Триенексенс веднаш започнува да работи на
тоа. Тој избира барање за штета на г-ѓа Филерс да се справи. Како одговор на таа акција, моторот за
извршување гарантира дека соодветната работна ставка исчезнува од работната листа на г-ѓа Отаген.
Причината, се разбира, е дека ова дело треба да се изврши само еднаш. Во секој случај, г-ѓа Отаген сè уште
работи на справување со претходен случај, но кратко потоа потоа го избира тврдењето на г-дин Буман да се
справи преку својот управувач со работни списоци.
Како одговор на изборот на работните артикли од г. Триенекенс и г-ѓа Тоаген, моторот за извршување ќе
осигури дека и двајцата ќе го видат електронското побарување на нивниот екран на соодветните клиенти.
Моторот за извршување го прави тоа со употреба на соодветни параметри при повикување на DMS на ACNS
на работните станици на прифаќачите. ДМС исто така ја прикажува скенираната верзија на побарувањата,
кои првично беа испратени на хартија. Покрај тоа, BPMS се грижи да им прикаже на двата прифаќачи
електронска форма што можат да ја користат за да ја снимат својата проценка, исто така, преку повик за
услуга.
Г-дин Триенекенс одлучи да го одбие барањето. Управувачот со работната листа го забележува ова, затоа што ги
следи специфичните податоци за електронската форма што добива негатива

вредност. Врз основа на логиката зафатена со моделот на процеси, моторот за извршување може да утврди
дека случајот мора да му се предаде на управителот на сметката на г-ѓа Филери и испраќа работна ставка до
тој учесник, барајќи да го извести клиентот за негативната проценка.
Г-ѓа Отаген пристигнува на позитивна проценка на побарувањето под нејзиниот часовник и одлучува да го
одобри. Моторот за извршување гарантира дека е повикана услуга за да се утврди новата месечна премија за
г-дин Буман, земајќи ја предвид неговата историја на побарувања, која е регистрирана во базата на податоци за
побарувања. Преземањето на информациите од оваа база на податоци се реализира и преку услуга. Откако ќе
заврши оваа пресметка, се создава работна ставка за различните расположливи финансиски вработени за да се
плати штетата. Работната ставка се појавува во работната листа на секој од овие финансиски услуги, сè додека
еден од нив не го избере за обработка. По извршената уплата, процесот е завршен.
Како што може да се види во примерот ANCS, сите компоненти на BPMS архитектурата играат улога во
координирањето на работата, поточно за да се осигурат дека соодветните работни артикли се создадени и
спроведени од вклучените учесници.
Вежба 9.3 Разгледајте ги следниве случувања и наведете кои компоненти на архитектурата

BPMS се погодени кога треба да се земат предвид:
1. Изработен е нов систем за поддршка на одлуки за поддршка на прифаќачите во проценката на

побарувањата.
2. Г-ѓа Отаген се пензионира.
3. Новата разлика помеѓу побарувањата станува релевантна: редовните прифаќачи сега се квалификувани да се
справат со побарувањата погоре € 1.000 сè додека работеле на претходни побарувања од ист клиент.
4. Побарувањата што се издаваат на автомобили стари над 10 години, треба постојано да се следат од страна на
раководството.
До оваа точка, разговаравме за BPMS, како да се специфични софтверски пакети кои обезбедуваат повеќе
или помалку иста функционалност. Сепак, поблиску е до вистината да се каже дека постојат различни авори на
BPMS и дека различните организации или различни процеси во рамките на истата организација можат
најдобро да им служат на различни типови на BPMS. Ова набудување е дискутирано во рубриката „Видови на
БПМС“.
ВИДОВИ НА БПМС
Постојат неколку начини да се направи разлика помеѓу достапните BPMS. Една класификација се заснова
на употреба на две оски: оној што го фаќа степен на поддршка дека БПМС дава и другиот што изразува
како тие системи се разликуваат едни од други во однос на нивните ориентација на процеси или податоци. Ние
опишуваме и илустрираме четири различни типови на системи: системи за групни системи, системи за
адок работа, системи за производство и работа и системи за ракување со случаи. Овие системи можат да
бидат позиционирани во спектарот на BPMS, како што е прикажано на сл. 9.5 .
Сл.9.5 Спектарот на типови BPMS
Групни системи: Двата основни принципи на системите за групни софтвери

се дека на корисникот му е овозможено лесно да споделува документи и информации од една страна
и директно да комуницира со другите корисници од друга страна. Најпознатиот пример за систем на
групни софтвери е Lotus Notes на IBM. Системите за групни мрежи се многу широко користени и
особено популарни за нивната висока оперативна fl егзибилност. Кога станува збор за поддршка на
деловните процеси, овие системи не можат да го сторат тоа во строга смисла. Системите за групни
мрежи традиционално не поддржуваат експлицитен поим за деловните процеси; како и да е, постојат
наставки како Lotus Domino Work.
Ад-хок системи за работа: Ад-хок BPMS, како деловни активности на TIBCO

или Ad-hoc Work-задачи на Comalatech, овозможете дефинирање на процесите што може да се создадат и да ги
модифицираат. Значи, иако постои веќе дефинирање на постапката за справување со типот на случајот, можно е за
време на извршувањето на тој процес да се прилагоди процесот, на пример, да се вклучи дополнителен чекор. За
овие видови на систем, често е така што секој случај (налог, побарување, тужба, итн.) Има своја приватна
определба за процеси. Ова спречува многу проблеми што се аклиматизираат со ажурирање на општа дефиниција
на процеси кога има примери. Јасно е, ad-hoc BPMSs овозможуваат најголема егзистентност. На пример, BPMS
InConcert, дури им дозволува на корисниците да активираат пример за деловен процес врз основа на целосно
празно дефинирање на процесите, кое се проширува бидејќи станува појасно што треба да се случи и по кој
редослед. Друга насока е дека првично BPMS работи врз основа на стандардно решение или урнек, кој може да се
модифицира по своја волја. Интересно е што таквата модифицирана постапка може да се користи како образец за
започнување со обработка на нов случај. Општо, постојат два главни барања за успешно примена на ad-hoc BPMS
во една организација. Првиот услов е крајните корисници да бидат многу свесни за процесите во кои работат. Ова
значи дека само процесите треба да се дефинираат или модифицираат од луѓе со многу добар преглед на процесот
и постојат два главни барања за успешно примена на ad-hoc BPMS во една организација. Првиот услов е крајните
корисници да бидат многу свесни за процесите во кои работат. Ова значи дека само процесите треба да се
дефинираат или модифицираат од луѓе со многу добар преглед на процесот и постојат два главни барања за
успешно примена на ad-hoc BPMS во една организација. Првиот услов е крајните корисници да бидат многу свесни
за процесите во кои работат. Ова значи дека само процесите треба да се дефинираат или модифицираат од луѓе со
многу добар преглед на процесот и

последици од отстапување од вообичаена пракса. Вториот услов е корисниците да имаат

на располагање софистицирани алатки за да моделираат деловни процеси и дека се
способни да моделираат. Комбинацијата на овие барања ја попречува широката примена
на ad-hoc BPMS во овој момент.
Системи за производство на производство: Најпознат вид на BPMS е про-

систем на работа на duct. Типични претставници се менаџер за деловни процеси на IBM и BPM Suite
на Bizagi. Голем дел од она што го опишавме во претходните делови на работното место се однесува
на оваа класа на BPMS. Работата се спроведува строго врз основа на експлицитно дефинираните
описи на процесите заробени во моделите на процеси. Управувањето со податоци, како што се
документи или поддршка за е-пошта, генерално не е понудено од овие системи. Општо, исто така е
невозможно или тешко да се отстапи од процесна логика ако тоа не е експлицитно зафатено во
моделот на процеси. Понекогаш се прави дополнителна разлика во рамките на производствената
работа административно и обработка на трансакција BPMS. Ова овозможува да се разликуваат
дополнителни нијанси во однос на степенот на автоматизација на работата што е координирана.
Административни BPMS, се користат во поставките каде што (голем) дел од работата сè уште ја
извршуваат луѓето; обработка на трансакција БПМС ги поддржуваат деловните процеси кои се (скоро)
целосно автоматизирани.
Системи за ракување со случаи: Идејата за системот за ракување со случаи (или Адап-
Систем за управување со случаи на деловна активност) е дека не се стреми кон тесна и целосна
спецификација на деловниот процес во модел. Наместо тоа, имплицитни
се користат модели на процеси, кои фаќаат конвенционален резултат од кој - освен ако тоа не е
експлицитно забрането - корисникот може да отстапи. Системот за постапување со случаи обично е
целосно запознаен со прецизните детали за податоците што припаѓаат на случајот (вклучувајќи
податоци за клиентот, финансиски и медицински податоци). Врз основа на таквата свесност, системот е
во состојба да им обезбеди на крајните корисници прецизен увид во статусот на случајот, како и на
најочигледните чекори за продолжување на процесот. Современи примери се софтверот за управување
со случаи i-Sight и BPMOne по перцептивен софтвер. Вториот, исто така, по желба, поддржува и
производство на деловно работење и во таа смисла е хибриден BPMS.
Постојат и други видови на систем што споделуваат карактеристики и функционалност со BPMS. Системи
за управување со документи ( ДМС) првенствено се грижат за складирање и вадење документи, како
скенови за документи и PDF датотеки, но тие често нудат и функции за автоматизација на работа.
Пример е пакетот Enterprise LiveCycle на Adobe. Сервери за оркестрирање на процеси се фокусираат на
автоматизација на процесите, но имаат посебен акцент на автоматизираните процеси за кои е потребна
интеграција на повеќе апликации во претпријатието. Пример е SOA Suite на Oracle.
9.2 Предности на воведување на BPMS 309
9.2 Предности на воведување на BPMS
Во овој дел размислуваме зошто би било привлечно за организациите да користат БПМС. Постојат четири широки
категории на предности за кои ќе разговараме овде: намалување на обемот на работа, ible извонредна интеграција на
системот, транспарентност во извршувањето и спроведување на правилата.
9.2.1 Намалување на обемот на работа
BPMS автоматизира дел од работата што ја прават луѓето во поставките каде што таков систем не е
воспоставен. Како прво, ќе се погрижи транспортна работа самото. Во организација на хартија, работата обично
се транспортира преку внатрешни поштенски услуги, честопати ја одложува обработката за еден работен ден на
секоја примопредавање, или од самите учесници на сметка на работното време. Сите такви одложувања се
целосно искоренети кога BPMS може да се искористи за испраќање на работилни работи по електронски пат. Во
некои ситуации, BPMS може да се грижи за целиот процес со повикување на целосно автоматизирани
апликации. Во вакви случаи, ние зборуваме Директно-преку-обработка ( STP). Особено во финансиските услуги,
многу деловни процеси што се однесувале на човековите операции сега се во режим СТП и координирани од
БПМС. Исто така, во други домени, размислете за пример на електронска виза, барем дел од случаите може да
се постапат на целосно автоматски начин.
Вториот вид работа што ја презема грижата за БПМС координација. BPMS го користи моделот на процеси
за да утврди кои активности треба да се извршат и по кој редослед. Значи, секој пат кога BPMS го користи
ова знаење за да трасира некоја работна ставка, потенцијално заштедува некого време дури и да размисли
што треба да се направи следно. Друга форма на заштедено време за координација е сигнализација на
завршена работа. Во организација врз основа на хартија, работата ќе се одвива подолго време во случај на
работа. Она што често се случува е дека некој ја презема работата, ја суспендира поради некоја причина, по
што работниот пакет се заглавува во друг куп работа. BPMS во секое време ќе може да го сигнализира
статусот на сите работни артикли и може да преземе активности за да се осигури дека е постигнат напредок.
Финалниот вид на намалување на обемот на работа со користење на BPMS е собирање на сите релевантни
информации да изврши одредена задача. Во ситуација без BPMS, работникот е тој што треба да ја направи оваа
колекција. Пронаоѓањето на правото, особено - никогаш не е таму каде што очекувавте - може да биде одзема
многу време. Забележете дека овој вид на предност зависи од претпоставката дека заедно со воведувањето на
BPMS се преземаат напори да се дигитализира протокот на документи во една организација. Имплементацијата
на ДМС е всушност она што често се забележува заедно со имплементацијата на БПМС. Одредени продавачи,
како IBM и перцептивен софтвер, нудат интегрирани пакети на функционалност на BPMS и DMS. Другите
продавачи на BPMS често имаат стратешка соработка со компании кои нудат DMS, така што е релативно лесно
да се интегрираат нивните заеднички системи.
9.2.2 Флексибилна интеграција на системот
Првично, споменатиот аргумент да се започне со BPMS е зголемената fl егзистентност што организациите ја

постигнуваат со оваа технологија. За да се објасни ова најдобро, се очекува краток преглед на историјата на
компјутерските апликации. Интересен тренд има, како што го идентификуваа Ван дер Алст и Ван Хе [ 95 ] таа
генеричка функционалност е поделена од апликации во одреден момент.
Приближно во текот на периодот 1965-1975 година, компјутерските апликации беа водени директно на оперативните системи
(ОС) на компјутер. Секоја апликација ќе се грижи за сопствено управување со податоците и ќе користи комерцијални техники за да
го направите ова поефикасно. Како резултат, се покажа дека е тешко да се споделат податоци меѓу апликациите и да се одржи
конзистентност. Јасно е дека програмерите од различни апликации би биле вклучени во развој на слични рутини за решавање на
слични проблеми. Од 1975 година наваму, се појавија ДБМС како нов вид стандарден софтвер што ја преземаа генеричката
задача за ефикасно управување со податоците. Како резултат, податоците би можеле да се споделат прилично лесно и
програмерите на нови апликации не би требало повеќе да се грижат за начините за чување, пребарување или преземање на
датумот. Околу 10 години подоцна, околу 1985 година, Системите за управување со кориснички интерфејс (UIMS) беа воведени за
да обезбедат многу генеричка компонента на интерфејс за многу апликации. Преку обезбедување на објекти како паѓачки кутии
или радио копчиња во достапни библиотеки, секој компјутерски програмер ќе може да ги искористи овие. До 1995 година, првите
комерцијални BPMS влегуваат на пазарот (значително време порано, прототипи за истражување беа достапни). Како DBMS и
UIMS во нивната област на фокусирање, BPMS-овите ќе обезбедат генеричка поддршка за областа на логиката на деловните
процеси. достапни се прототипови за истражување). Како DBMS и UIMS во нивната област на фокусирање, BPMS-овите ќе
обезбедат генеричка поддршка за областа на логиката на деловните процеси. достапни се прототипови за истражување). Како
DBMS и UIMS во нивната област на фокусирање, BPMS-овите ќе обезбедат генеричка поддршка за областа на логиката на
деловните процеси.
Воведувањето на BPMS е логично продолжение на раздвојувањето на генеричката функционалност на она

што беа едно монолитни компјутерски програми. Уште во 1990-тите, се проценуваше дека 40% од сите линии
на кодови што работат на главните компјутери на банките би биле поврзани со логиката на деловните процеси,
а не со самите пресметки или обработка на податоците. Типичен вид на обработка на информации во контекст
се однесува на идентификација на активности, нивниот редослед на извршување или на учесниците одговорни
за нивно спроведување. На пример, би било специфицирано дека по завршувањето на понудата за хипотека,
ова требаше да се сигнализира до директорот на одделот, предизвикувајќи сигнал на нејзиниот монитор.
Очигледната предност поврзана со овој развој е што стана полесно со БПМС сами да управуваат
со логиката на деловните процеси. Ова се должи на фактот дека е многу попогодно да се ажурира
описот на деловниот процес без да се изврши увид во кодот на апликацијата. Исто така, обратното би
станало полесно, т.е. модифицирање на апликација, додека не допирајте по редоследот за тоа како ќе
се одвиваат работите на ниво на деловниот процес. Накратко, BPMS ќе им овозможи на организациите
да станат посигурни во управувањето и ажурирањето на деловните процеси, како и нивните
апликации.
BPMS, исто така, обезбедуваат средства за лепење заедно одделни системи. Големите сервисни организации
обично распоредуваат огромен број ИТ системи, кои сите постојат повеќе или помалку независни едни од други.
Честопати, таквата состојба се нарекува островска автоматизација. BPMS може да се воведе во таква ситуација како
средство за нивно интегрирање
9.2 Предности на воведување на BPMS 311
системи. Willе се заштити дека сите одделни системи ќе ја играат својата должна улога во деловниот процес што го
поддржуваат.
Тука се должи збор за претпазливост. Самиот БПМС нема да понуди директно решение за проблемот дека
честопати има непотребно чување на информации во многу различни ИТ системи. Всушност, BPMS генерално
нема да знае за вистинските податоци што крајните корисници ќе манипулираат со употреба на различните ИТ
системи. Доколку БПМС работи како интегратор помеѓу сите постојни системи, ова ќе бара темелна анализа на
информации за да се мапираат кои податоци се користат и достапни.
9.2.3 Транспарентност во извршувањето
Предност што често се занемарува е дека БПМС може да работи како ризница во однос на начинот на кој
деловните процеси навистина се извршуваат. Веројатно е дека програмерите на првите BPMS не имаат
јасно предност во однос на обезбедување увид за извршување на некој процес на кој било друг, освен
луѓе што го извршуваат самиот процес. Сигурно, за да има БПМС воопшто да работи, мора да води точна
администрација на која се должни работните артикли, што може да се утврди само со активно следење и
снимање на кои работи кои се завршени со кои ресурси и во кое време влегуваат нови случаи процесот.
Сепак, за БПМС да функционира правилно, не е неопходно да се чуваат сите податоци достапни откако
ќе се завршат придружните случаи. Менаџментот кој го надгледува ваквиот процес, сепак, може да има
сосема поинаква перспектива за ова прашање. Постојат два вида на информации кои можат да бидат
корисни за да се генерираат интересни сознанија врз основа на администрацијата што ги одржува BPMS:
1 Оперативни информации, што се однесува на неодамнешните, тековни случаи и
2. Историски информации, што се однесува на завршени случаи
Оперативните информации се релевантни за управување со одделни случаи, учесници или специфични

делови од деловниот процес. Карактеристичен пример е следниот. Од анализите на различни владини
агенции вклучени во давањето дозволи во Холандија, стана јасно дека утврдувањето на точниот статус на
апликација за дозвола е една од најпотребните активности за време на вклучените државни службеници. Со
употреба на повеќето комерцијално достапни BPMS, преземањето на тој статус е залудност. Таквиот статус
може да биде, на пример, дека е примено барањето на г-дин Бендерс да ја прошири својата куќа со
дополнително градинарско крило, соодветно со плановите за развој на подрачјето во кое живее и дека
понатамошната обработка сега зависи од прием на совети од надворешен експерт. Друга употреба на
оперативни информации ќе се однесува на должината на редот во однос на работните артикли. На пример,
постојат 29 апликации за одобренија за градење кои чекаат совет од надворешен експерт. Од овие примери
може да стане јасно дека иницијативите за подобрување на услугата на клиентите, особено во однос на
одговарање на прашања во врска со нивните нарачки, честопати се потпираат на употреба на BPMS.
Историските информации, за разлика од информациите за работењето, честопати се од интерес на одредено ниво
на агрегација, на пример, опфаќајќи повеќе случаи во текот на продолжено

временски период. Овој вид на информации е од најголема важност за да се утврди извршувањето на

одреден процес или неговата усогласеност со одредени правила. Во однос на првото, можеби ќе сакате
да размислите за просечни времиња на циклус, за број на завршени случаи за одреден период или за
користење на ресурси. Последната категорија може да опфати прашања како вид исклучоци што се
создадени или бројот на случаи што прекршиле одреден рок.
Има смисла да се земат предвид видот на увид што треба да се преземе од BPMS пред тој да се спроведе во
една организација. Техничките прашања играат улога овде, како што е временскиот период кога треба да се
чуваат логовите на BPMS и, според тоа, колку простор за складирање треба да се посвети за тоа. Сметаат дека
станува малку проблематично ако историските информации се важни на агрегатното ниво на години, ако има
само простор за зачувување на настаните од најмногу месеци. Постојат и концептуални проблеми. Доколку е
важно да се следи одредена пресвртница во рамките на еден процес, од суштинско значење е да се направи дел
од моделот на процеси што се користи за извршување на сродните деловни процеси. Да се искористи
претходниот пример: Ако е важно да може да се препознае фазата во која случајот треба да почека совет од
надворешен експерт, тогаш таа пресвртница мора да биде дел од моделот на процеси. На овој начин,
автоматизацијата на процесите обезбедува основа за процесно разузнавање (види Поглавје). 10 )
9.2.4 Спроведување правила
Освен очигледната предност дека деловниот процес може поефикасно да се извршува со употреба на
BPMS, таков систем ќе се грижи и за тоа дека процесот се одвива точно на начинот на кој тој е
дизајниран. Кога правилата се експлицитно спроведени, ова може да се смета како квалитетна
придобивка: некој го прави тоа, што ветува. Во многу поставувања, вработените ќе имаат значителна
слобода да извршуваат деловен процес на начинот на кој им изгледа најдобро (или најзгодно). Оваа
индивидуална проценка не мора да се совпаѓа со најдобриот можен начин како се извршува деловниот
процес од целокупната перспектива на една организација. Во овој поглед, БПМС може да биде средство
за заштита на деловните процеси на претходен начин, без никакви отстапки.
Како илустрација, разгледајте го одвојување на должностите контрола што е добро позната во доменот на
финансиски услуги. Тоа значи дека регистрацијата и инспекцијата на финансиска трансакција ќе треба да бидат
извршени од различни лица. Овој вид на логика е прилично лесно имплементиран во BPMS и се применува од
такви системи. BPMS регистрира кои поединци ги спровеле работните артикли и кои можат да ги земат предвид
овие информации при алокација на нови работи. Забележете дека BPMS, генерално, е соодветно
софистициран, така што вработените можат алтернативно да ја завршат улогата на регистрирање и инспекција
за различни случаи.
Капацитетот на БПМС за спроведување правила во моментов е од интерес на организациите. До пред една

деценија, првенствено владините организации спроведуваа вакви системи чисто мотивирани од оваа
загриженост. На крајот на краиштата, постојат различни закони со кои треба да се усогласат таквите
организации. Деновиве, финансиски и друго
9.3 Предизвици за воведување на BPMS 313
професионални услуги за услуги станаа слично на enубени од BPMS. Важен развој во ова е зголемувањето на
различните рамки за управување, кои започнаа во 2002 година со Акт на Сарбанес - Оксли како реакција на
лошо однесување во Енрон и Ворлком. Законот им дава голема одговорност на директорите на компанијата
да инсталираат контроли и процедури за управување во рамките на организациите и да го видат нивното
правилно извршување. Очигледно, ова е доколку БПМС можат да играат важна улога.
Вежба 9.4 На кои категории би ги класифицирале следниве стимулации за воведување BPMS во

една организација?
• Агенцијата за ревизија утврди дека пишаните процедури и вистинското извршување на деловните

процеси не се усогласени. Раководството на таа организација сака да ги спроведе пишаните
процедури и да одлучи да воведе BPMS.
• Клиентите на една организација се жалат дека можат да добијат само многу плитки ажурирања за напредокот на
нарачките што ги прават. Управувачот со ИТ на таа организација разгледува употреба на БПМС за снимање и
обезбедување информации за статусот на сите овие нарачки.
• Организацијата за осигурување истакнува дека има голема потреба од брзо прилагодување на начинот на кој се
спроведува обработката на побарувањата на понудите што ги носат нејзините конкуренти на пазарот. Користењето на
BPMS се смета за решавање на ова барање.
9.3 Предизвици за воведување на BPMS
И покрај многуте предности на користењето на BPMS, постојат некои значајни пречки во однос на
воведување на овие во една организација. Тука ќе правиме разлика помеѓу технички и организациски
предизвици.
9.3.1 Технички предизвици
Она што треба да биде една од предностите на BPMS е исто така еден од стапиците. БПМС е
способен да интегрира во употреба на различни видови на информативен систем во нивна
поддршка на деловен процес. Предизвикот е што многу апликации никогаш не биле развиени со
оваа координирана употреба во предвид. Апликациите за главната рамка што сè уште можат да
се најдат во банките и осигурителните компании денес се познати во овој поглед. Во најповолен
случај, ваквите системи се технички документирани, но често се случува да нема веќе достапен
ниту еден оригинален тим за развој кој знае точно како се структурирани овие. Во вакви случаи,
тешко е да се утврди како БПМС може да активира вакви системи за да ги натера да го поддржат
извршувањето на одредена работна ставка, да разменуваат информации помеѓу BPMS и таков
систем (на пр. Податоци за случајот),
Техника што се користи за да се оствари интеракција со таквите наследни системи воопшто е можна стружење
на екранот. Интеракцијата помеѓу BPMS и апликацијата за главната рамка потоа се одвива на ниво на
корисничкиот интерфејс: клучните удари што треба да ги направи крајниот корисник се емулираат од BPMS и
сигналите испратени на дисплејот се следат за да се утврди напредокот во извршувањето активност. Comeе не
изненадува што ваквите решенија за интеграција на ниско ниво ќе претрпат многу ригидност на целокупното
решение и, всушност, ќе ги поткопаат предностите на егзибилитет, што вообичаено се поврзани со користење
на BPMS.
Посебен проблем што се јавува во однос на интеграција на постојните апликации со BPMS, е недостаток
на процесна свесност за традиционалните системи. Во системот за запознавање со процесите, засебните
случаи ќе се постапуваат одделно. Со други зборови, таков систем работи од случај до случај. Во многу
традиционални системи, обработка на серија е доминантна парадигма. Ова значи дека одредена задача е
извршена за потенцијално голем број случаи, што не секогаш оди добро со филозофијата на BPMS.
Забележете како ерехистичката работа заснована на случај споменати во Поглавје 8
експлицитно ја таргетира оваа состојба.
За среќа, во областа на системската интеграција е постигнат голем напредок во изминатата деценија. Многу
стари системи се постепено и нови, отворени системи со јасно дефинирани интерфејси ги заземаат своите
места. Технологии за кои се наведува како Middleware и Интеграција на апликации за претпријатија Сега се
достапни алатки кои силно ја олеснуваат комуникацијата и управувањето со податоците во дистрибуираните
апликации. Мајкрософт BizTalk и IBM's WebSphere се добро познати софтверски пакети што можат да се
користат во овој поглед и постојат достапни и технологии со отворен извор. Успехот на Веб услуги е уште еден
двигател на подобрената, координирана употреба на различни видови на информативен систем, вклучително и
BPMS. Веб-услугата е парче од функционалност, на пример идентификација на најдобрата можна цена за
одредено добро во рамките на опсегот на даватели на тоа добро, што може да се повика преку Интернет.
Повеќето BPMS обезбедуваат добра поддршка за интегрирање на специфични веб-услуги во извршни деловни
процеси. Овој вид поставување не би имало во рамките на популарната парадигма за архитектура на софтвер
за којашто обично се нарекува Сервисно-ориентирана архитектура.
Во однос на можностите за техничка интеграција, фер е да се каже дека неодамнешните случувања се

поволни за употреба на BPMS и дека техничките предизвици, барем во однос на овој аспект, веројатно ќе се
намалат во текот на следните години.
9.3.2 Организациски предизвици
Воведувањето оперативен BPMS често има влијание врз широките делови на една организација. Ова
подразбира дека воведувањето на BPMS може да биде предизвик од организациска перспектива.
Интересите на различни засегнати страни треба да бидат избалансирани, кои обично имаат различни
задачи во работењето и се борат со исти ресурси. Да се добие увид во тоа како се одвиваат постојните
процеси е огромен предизвик само по себе, понекогаш и со месеци работа. Тука, не само политичко
9.3 Предизвици за воведување на BPMS 315 година
мотивите може да играат улога - не секој ќе биде среќен да отстапи како се работи, особено ако воопшто не се
работи многу —, но и психолошки: луѓето имаат тенденција да се фокусираат на опишување на најлошите
можни исклучоци кога ќе побараат да опишат што нивната улога е во процес. Еден научник се осврна на оваа
тенденција како причина „зошто моденерите уништуваат работа - должат иновации“.
Фактор што додава на оваа комплексност е дека организациите се динамични ентитети. Прилично е
вообичаено дека при воведувањето на BPMS, што може да трае неколку месеци, се менуваат организациските
правила, одделенијата се расфрлани или комбинирани, учесниците добиваат други одговорности, нови
производи се воведуваат или тргнуваат на пазарот. Сите овие се примери на настани што може да бидат
важни за да се земат предвид кога целта е да се направи БПМС правилно да функционира во организациски
амбиент. Во пракса, ова опфаќа увид дека постепеното воведување на BPMS е обично поуспешно од
стратегијата за „голем тресок“, во која BPMS од еден ден од друг ден се очекува да го замени начинот на
управување со операциите.
Перспективата на корисниците за воведување на BPMS треба внимателно да се разгледа.

Повеќето експерти за прв пат нема да треба да искусат рацете на што е да се користи BPMS пред тие
навистина да ценат што значи тоа за нивната работа. Може да има и загриженост и страв. Прво,
може да има чувство „Голем брат ве гледа“. Навистина, БПМС ќе ги евидентира сите настани што се
вклучени во извршувањето на еден процес, вклучително и кој извршил какво дело и во кое време. Не
користи - и од гледна точка на управување со промените, всушност би можело да биде
самоуништувачко - да се игнорира оваа загриженост. Наместо тоа, организациите треба да разјаснат
како ќе се користат овие информации и дека има позитивни ефекти што може да се очекуваат и од
користењето на овие информации. Друг страв што е вообичаен кај крајните корисници на БПМС е
дека нивната работа ќе заземе механистичка особина, скоро како да работат на ланец. Овој страв е
делумно оригинален. Точно е дека БПМС ќе се грижи за распределбата и рутирањето на работата.
Она што може да се расправа е дека овие не се највозбудливите или вредните делови од работата
што треба да се извршат (што е токму причината што тие би можеле да бидат автоматизирани на
првото место). Ако ја земете предвид ситуацијата кога вработениот треба да потроши голем дел од
своето време на создавање на соодветни информации за правилно извршување на работата, БПМС
може да биде поволен механизам за тоа време да му го врати на работникот. Друга линија на
расудување е дека зависи многу од влијанието на БПМС дали ефектот на механизација всушност ќе
се појави. Споредете, на пример, ситуацијата кога БПМС турка единечна работна точка во исто
време на работникот што треба да се изврши или поточно низа работни артикли што некој би можел
да ги избере според сопствените преференци.
Да се сумира, воведувањето на BPMS е особено сложено, токму затоа што поддржува цели
деловни процеси. Не е за ништо што од многу истражувачки проекти во ИТ проекти „силната
управување со заложбите“ е секогаш на врвот на факторите што објаснуваат успешна
имплементација. Воведувањето на BPMS е, можеби дури и повеќе отколку за другите типови на
технологија, а не за слабо срце.
Вежба 9.5 Разгледајте ги следниве проблеми што се појавуваат при воведување на БПМС во болница за
поддршка на предоперативна нега, односно подготовка и управување со пациент пред операцијата.
Класифицирајте ги на технички или организациски проблеми, или и двете.
1. Кога слушнале за плановите за воведување на BPMS, хирурзите целосно одбиваат да соработуваат во врска со
овој зафат. Нивното тврдење е дека секој пациент е индивидуа на која не може да му се верува во грижата за
системот со една големина.
2. Анестезиолозите во болницата користат систем за поддршка на одлуки кој ја следи соодветната доза на
анестетици кај пациентите. Системот е развиен како самостоен систем кој е тежок за синхронизирање со
BPMS, кој треба да го напојува системот за поддршка на одлуките со податоци за пациентите.
3. На медицинските сестри им се обезбедени мобилни уреди, кои можат да ги користат за да пристапат до
управувачите на нивните работни списоци. Сепак, тешко е да се следат автоматските нотификации што им се
сигнализираат како нежни вибрации на уредот.
9.4 Извршни модели на процеси на вртење
Во овој дел ќе покажеме како да се автоматизира деловно ориентиран модел на процеси со цел да се
изврши на BPMS. Особено, ќе го разгледаме случајот со BPMS за производство.
Мапирањето на процесите за автоматизација бара пристап кон моделирање на процеси што е доста различно
од она што е потребно за комуникација или аналитички фокусирани модели на процеси. Всушност, заради нивната
намера, деловните ориентирани модели на процеси не се нужно прецизни и затоа можат да содржат нејаснотии.
Спротивно на тоа, извршни модели на процеси мора да бидат прецизни спецификации за да бидат толкувани од
BPMS.
Ние предлагаме еден чекор-метод за постепено трансформирање на бизнис-ориентиран модел на процес

во извршна, како што следува:
1. Идентификувајте ги границите за автоматизација
2. Прегледајте рачни задачи
3. Завршете го моделот на процеси
4. Доведете го моделот на процеси до соодветно ниво на грануларност
5. Наведете својства за извршување
Преку овие чекори, бизнис-ориентиран модел ќе стане помалку апстрактен и повеќе ориентиран кон ИТ.
Овие чекори треба да се спроведат врз моделот на процеси што е точен и во однос на структурата и
однесувањето. На пример, ако моделот содржи грешки во однесувањето како ќор-сокак, БПМС може да се
заглави при извршување на пример на овој модел на процеси, со потенцијално влијание врз работењето на
организацијата. Веќе разговаравме за проверка на моделот на процеси во секцијата. 5,4 . Отсега
претпоставуваме дека моделот на процеси е точен.
9.4 Извршни модели на процеси на вртење 317
9.4.1 Идентификувајте ги границите за автоматизација
Прво, треба да идентификуваме кои делови од нашиот процес можат да бидат координирани од страна на BPMS, а
кои делови не можат. Во еден процес има автоматски, рачен и корисник задачи. Автоматизираните задачи ги
извршува самиот BPMS или надворешна услуга додека рачните задачи ги вршат учесниците во процесот без помош
на кој било софтвер. Корисничка задача се вклопува помеѓу автоматизирана и рачна задача. Тоа е задача што ја
извршува учесник со помош на управувачот на работните списоци на BPMS или на надворешен менаџер на списоци
со задачи.
Оваа разлика помеѓу автоматски, рачни и кориснички задачи е релевантна: автоматизираните и задачите на
корисниците лесно можат да бидат координирани со BPMS, додека рачните задачи не можат. Така, во овој прв чекор
треба да го идентификуваме типот на секоја задача. Потоа, во следниот чекор, ќе ги разгледаме прирачните задачи
и ќе процениме дали можеме да најдеме начин да ги поврземе овие задачи до BPMS. Ако тоа не е можно, ќе мора
да размислиме дали е погодно да се автоматизира остатокот од процесот без овие рачни задачи.
Да разгледаме, повторно, моделот на постапката за целосна нарачка што го создадовме во Поглавје. 3 , што е
прикажано на сл. 9,6 за погодност (за момент, отфрлете ги маркерите на активност). Да претпоставиме дека го
добиваме овој модел од деловен аналитичар и наша задача е да го автоматизираме од гледна точка на
продавачот. Ова значи дека треба да се фокусираме на процесот во базенот на Продавачот и да го исфрлиме
остатокот. Првата активност, „Проверете ја достапноста на резервите“, се наоѓа во лентата ERP. Ова значи дека
веќе на концептуално ниво беше идентификувано како автоматска задача. ERP системите обезбедуваат модули за
управување со залихите кои автоматски ги проверуваат нивоата на залихи на производот против базата на
податоци на складиштата. Оваа активност е многу повторувачка, бидејќи се извршува за секоја примена нарачка.
Изведувањето на тоа рачно би било многу неефикасно и скапо, бидејќи тоа би вработувало учесник во процесот,
иако не бара посебна човечка вештина. Слични размислувања имаат и за „Проверете ја достапноста на
суровините“, што е исто така автоматска задача. Друг пример е активност „Производствен производ“. Ова го
изведува опрема (фабрика за производство) која ја изложува својата функционалност преку сервисен интерфејс.
Значи, од гледна точка на BPMS, ова е исто така автоматизирана активност.
Продолжувајќи со нашиот пример, има и други задачи како „Барање суровини од снабдувачот 1 (2)“ и „Добиј
адреса за испорака“ кои се посветени на испраќање и примање пораки. Овие се исто така примери на автоматски
задачи. Тие можат да бидат имплементирани преку автоматска размена на е-пошта или повика за веб-услуги (и
BPMS-те обично ги обезбедуваат овие можности), и покрај тоа што тие не се експлицитно моделирани во
системска лента. Потсетете се дека разгледуваме модел ориентиран кон деловните процеси, каде можеби нема да
биде релевантно да се моделираат преку ленти на сите постојни системи (во овој случај е-пошта или веб-услуга).
Другите задачи како „Враќање на производ од магацин“, „Добијте суровини од снабдувачот 1 (2)“ и
„Бродски производ“ се упатства. На пример, „Враќање на производ од магацин“ е потребно еден работник во
магацин физички да го собере производот од полицата за испорака. Во присуство на мануелна задача,
имаме две опции: (i) ја изолираме задачата и се фокусираме на автоматизирање на процесот пред и по
него, или (ii) ние изработивме начин БПМС да биде обележана кога мануелната задача започна или
Сл. 9.6 Цел модел за нарачка што сакаме да го автоматизираме

завршено. Willе се вратиме на оваа точка во вториот чекор. Засега, сè што треба да направиме е да ги
идентификуваме овие рачни задачи.
„Усогласена нарачка“ е пример за задача на корисник: бара некој во продажба (на пр. Службеник за нарачка) да
ја провери нарачката и потоа да потврди дека нарачката е точна. Кориснички задачи обично се закажани преку
управувачот со работната листа на BPMS. Во нашиот пример, електронска форма на нарачката ќе биде дадена на
екранот за службеникот за нарачки, кој ќе потврди дека нарачката е во добра состојба, потврдете ја нарачката и на тој
начин го доставувате образецот назад до моторот за извршување.
Разликата помеѓу автоматски, рачни и кориснички задачи се снима во BPMN преку специфични маркери на
горниот лев агол од полето за задачи. Рачните задачи се означени со рака додека корисничките задачи се означени
со икона за корисникот. Автоматските задачи дополнително се класифицираат во следниве подтипови во BPMN:
• скрипта ( маркер за скрипти), ако задачата изврши некој код (скриптата) внатрешно на BPMS. Оваа задача
може да се користи кога функционалноста е едноставна и не бара пристап до надворешна апликација, на
пр. Отворање на список или избор на најдобар понуда од голем број добавувачи.
• Сервис ( маркер на тркала), ако задачата ја извршува надворешна апликација, која ја изложува неговата функционалност
преку сервисен интерфејс, на пр. „Проверете ја достапноста на залихите“ во нашиот пример.
• испрати ( mark маркер на плик), ако задачата испраќа порака до надворешна услуга,
на пр. „Барајте суровини од снабдувачот 1“.
• прима ( маркер за празен плик), ако задачата чека порака од надворешна услуга, на пр. „Земете
адреса за испорака“.
Овие маркери се однесуваат само на задачи. Тие не можат да се користат во под-процеси, бидејќи под-процес
може да содржи задачи од различни типови. Релевантните маркери за нашиот пример се прикажани на сл. 9,6 .
Вежба 9.6 Да претпоставиме дека треба да го автоматизирате моделот на Решение за процесот на проценка на заемот 3,7
за давателот на заем. Започнете со класифицирање на задачите на овој процес во рачни, автоматски и кориснички и
застапете ги со соодветни маркери за задачи.
9.4.2 Рачни задачи на преглед
Откако ќе го идентификуваме типот на секоја задача, треба да провериме дали можеме да ги поврземе мануелните
задачи со BPMS, за да можеме да ја максимизираме вредноста добиена од BPMS. Алтернативно, треба да ги изолираме
овие задачи за да можеме да го автоматизираме остатокот од нашиот процес. Постојат два начина за поврзување на
рачна задача со BPMS: или ја спроведуваме преку корисничка задача или преку автоматска задача.
Ако учесникот вклучен во мануелната задача може да го извести BPMS за завршување на задачата користејќи го
управувачот на работната листа на BPMS, мануелната задача може да се претвори во корисничка задача. На пример,
работникот на магацин кој ја извршува задачата „Враќање на производот од магацин“ може да провери дали е дел од оваа
задача од нивната работна листа до

индицирајте дека тие се подготвени да ја извршат работата, рачно да го повратат производот од полицата, а потоа да
ја проверите работната ставка назад во моторот BPMS. Алтернативно, одјавувањето и одјавување може да се
комбинираат во еден чекор при што работникот едноставно го известува управувачот со работната листа дека
работата е завршена.
Во некои случаи, учесник може да користи помош од технологија интегрирана со BPMS за да го извести моторот
за завршување на работната ставка. На пример, работникот на магацин може да користи скенер за бар-код за
скенирање на бар-код на добиените суровини. Скенерот ќе биде поврзан со BPMS, така што скенирањето на
баркодот автоматски ќе сигнализира завршување на „Добивање суровини од снабдувачот 1 (2)“. Во овој случај,
мануелната задача може да се спроведе како задача за примање, која чека на известувањето од скенерот, или од
задача на корисникот управувана од управувачот на работната листа, која пак е поврзана со скенерот. Ако користиме
задача за примање, BPMS ќе биде свесен само за завршувањето на работната ставка, во тој случај информирањето
на работникот во магацин дека е достапна нова работна ставка ќе биде надвор од опсегот на BPMS. Ако користиме
задача за корисници, работникот ќе биде нотифициран за новиот предмет од страна на BPMS и ќе го користи
скенерот за да го сигнализира завршувањето на работната ставка до моторот BPMS. Слични размислувања се
однесуваат на задачата „наредба за испраќање“. Бидејќи секоја рачна задача од нашиот пример може да биде
поврзана со BPMS, овој процес може да се автоматизира како целина.
Вежба 9.7 Разгледајте го моделот за проценка на заемот што го стекнавте во вежбање 9,6 . Прегледајте ги
прирачните задачи на овој модел за да ги поврзете со BPMS.
Постојат случаи во кои не е погодно да се поврзат рачните задачи со BPMS.
Пример 9.1 Да го разгледаме процесот на прием во универзитет опишан во вежба 1.1 , со подобрувањата
дискутирани во решението 1.5 . Процесот до точката каде што апликацијата ќе се справи за комисијата за
прием (прикажана на Сл. 9,7 а) може да се автоматизира. Откако сите апликации ќе се редат, комисијата
ќе се состане и ќе ги испита сите одеднаш. Сепак, овој дел од процесот (прикажано на Сл. 9,7 б) е надвор
од опсегот на BPMS. Задачите потребни за проценка на апликациите не можат да бидат автоматизирани
затоа што вклучуваат различни човечки учесници кои комуницираат на ад-хок основа и не би било
погодно да ги синхронизирате сите овие задачи со BPMS. Конечно, комитетот ќе состави список на
прифатени кандидати, ќе го пренесе на приемот на канцеларијата, а службеникот на приемот на
канцеларијата ќе ги ажурира различните студентски записи, во кое време остатокот од процесот може да
продолжи во рамките на BPMS ( прикажано на сл. 9,7 в)
Во овој пример, не можеме да го автоматизираме целиот процес. Затоа, треба да ја изолираме активноста
„Процена на апликација“, ад-хок активност што содржи разни рачни задачи и да се автоматизира процесот пред и по
оваа активност. Опција е моделот да се подели на три фрагменти како што е прикажано на сл. 9,7 и само
автоматизирајте го првиот и третиот фрагмент. Друга опција е да се задржи еден модел и едноставно да се отстрани
ад-хок активност. Некои BPMS-ови се толерантни на присуство на рачни задачи и ад-хок активности во извршни
модели и ќе ги отфрлат за време на распоредување (како коментари на програмски јазик). Ако тоа е случај, можеме
да ги задржиме овие елементи внатре. Набудувајте ја употребата на нетипичен настан за да се започне третиот
фрагмент на моделот на процеси на Сл. 9,7 . Во
Сл. 9.7 Процес на прием: почетниот ( а) и финале ( в) проценките може да се автоматизираат во BPMS; проценка од
комитетот ( б) е прирачник процес надвор од опсегот на BPMS
BPMN, процес кој започнува со нетипичен настан, укажува дека случаите на овој процес се експлицитно започнати
од корисник на BPMS, во нашиот случај службеник на приеми на одделот. Оваа иницијација на процесот се нарекува експлицитна
иницијатива наспроти имплицитна инстантција каде што инстантните процеси се активираат автоматски од типот на
настанот што е наведен во почетниот настан, на пр. дојдовна порака или тајмер.
Конечно, кога процесот е главно или во целост составен од неправилни рачни задачи,
автоматизацијата не дава никаква корист и често е дури и неизводлива. Да го земеме за пример
пост-производниот процес во индустријата на екран. Активности како „Одржување на седницата“, каде
режисерот и композиторот ја гледаат сликата за да одлучат за музичките знаци, „Спроведете негативно
сечење“, каде негативната камера е рачно отсечена и сплетена за да одговара на финалното
уредување, специфицирано од страна на уредникот, и „Составување саундтракот “, тешко може да биде
координиран од BPMS, бидејќи не постои строга наредба за нивно извршување и секоја од нив може да
се повтори повеќе пати. Како по правило, процес чии што задачи се извршуваат на ад-хок начин, без
предвидлив редослед, не е погоден за автоматизација преку BPMS за производство. Во овој случај,
Вежба 9.8 Размислете за финалниот дел од процесот на комплетирање на рецепти опишано во вежба 1.6 :
Откако рецептот ќе ја помине проверката за осигурување, таа му се доделува на техничар, кој ги собира лековите
од полиците и ги става во торба со рецепт, дополнет до него. Откако техничарот ќе назначи одреден рецепт,
торбата му се предава на фармацевтот кој двојно проверува дали рецептот е правилно проверен. По оваа проверка
на квалитетот, фармацевтот ја запечатува торбата и ја става во областа за пикање. Кога клиентот пристигнува да ја
собере својата рецепт, техничар ја повлекува рецептата и го прашува клиентот за нивна партиципација или за
целосна исплата во случај лековите во рецептот да не бидат опфатени со полисата за осигурување на клиентот.
Еден начин за моделирање на овој фрагмент е да ги дефинирате следниве задачи: „Проверете го осигурувањето“,
„Соберете лекови од полиците“, „Проверете го квалитетот“, „соберете плаќање“ (поттикнато од пристигнување на
клиентот) и официјално „Преземете торба со рецепти " Да претпоставиме дека аптекарскиот систем го автоматизира
процесот на завршување на рецептите. Идентификувајте го типот на секоја задача и ако има рачни задачи, наведете
како тие можат да се поврзат со аптечниот систем.
Постојат и други елементи за моделирање, покрај рачните задачи, кои се релевантни на концептуално ниво, но не
можат да бидат толкувани од страна на БПМС. Овие се објекти за физички податоци и продавници за податоци, пораки
со физички предмети и прибелешки за текст. Базените и лентите исто така се користат само на концептуално ниво.
Всушност, како што видовме, базените и лентите честопати се користат за фаќање на груби резерви на ресурси, на пр.
Активност „Уредување на налог“ се врши во одделот за продажба. Кога станува збор за извршување, треба да
дефинираме задачи за ресурси за секоја задача и снимањето на овие информации преку посветени ленти (потенцијално
една за секоја задача), само ќе го направи дијаграмот премногу натрупан. Продавниците за електронски податоци исто
така не се директно толкувани од BPMS, бидејќи БПМС претпоставува постоење на посветени услуги што можат да
пристапат до овие податоци.

продавници, на пр. услуга за информации за инвентар што може да пристапи до склад ДБ. Значи, BPMS ќе интерфејсра со
овие услуги отколку директно со продавниците со податоци. Исто така, состојбата на објектот со податоци што е наведена
во етикетата на предметот, на пр. „Нарачка за набавка [потврдена]“, не може да се толкува како таква од BPMS. Подоцна
ќе покажеме како експлицитно да ги претставуваме предметите на објекти, за да може да се толкуваат со BPMS.
Некои BPMSs толерираат присуство на овие неизвршни елементи исто така. Ако е случај, ние предлагаме да ги
оставиме овие елементи внатре. Особено базените, лентите, должниците за електронски пораки, електронските
продавници за податоци и прибелешките, ќе нè водат во спецификацијата на некои својства за извршување. На
пример, продажната лента во согласност со моделот за нарачка ни кажува дека на учесникот на кој му е доделена
задача „Конкретен налог“ треба да биде од одделот за продажба. Другите алатки за моделирање на BPMS не ги
поддржуваат овие елементи, па затоа не е можно дури и да се претстават во дијаграмот.
Вежба 9.9 Разгледајте го моделот за проценка на заемот што го стекнавте во вежбање 9,7 . Идентификувајте ги елементите
за моделирање кои не можат да бидат толкувани од BPMS.
9.4.3 Дополнете го моделот на процеси
Откако ќе ги утврдиме границите за автоматизација на процесот и ќе ги разгледаме рачните задачи, треба да провериме
дали е нашиот процес на процеси заврши. Честопати, моделираните модели на процеси занемаруваат одредени
информации затоа што моденерите сметаат дека не се релевантни за специфичната цел на моделирање, тие
претпоставуваат дека е вообичаено знаење или едноставно, тие не се свесни за тоа. Можеби е можеби да не се запостават
овие информации во деловно ориентиран модел, во зависност од сценариото за апликација. Како и да е, информациите
што не се релевантни во моделот ориентиран кон деловно работење може да бидат многу важни за да се спроведе
моделот на процеси.
Типичен пример е кога процесниот модел се фокусира на сценарио „сончев ден“ и ги занемарува сите
негативни ситуации што можат да се појават при извршувањето на процесот, работејќи под претпоставка дека сè
ќе работи добро. Како што видовме во Поглавје. 4 , процесот на исполнување на нарачките навистина е подложен
на голем број исклучоци. На пример, може да се прекине доколку материјалите потребни за производство на
производот не се достапни кај добавувачите или ако клиентот испрати откажување од нарачката. Затоа, треба
да бидеме сигурни дека сите исклучоци се постапуваат со соодветни управувачи на исклучоци. На пример, ако
откажувањето на нарачката е примено откако производот е испратен или по приемот на плаќањето, ние исто
така треба да ги надоместиме овие активности со враќање на производот и надоместување на клиентот. Друг
исклучок што обично се занемарува е тоа што претставува активност што не може да се заврши. Што се случува
ако адресата на клиентот никогаш не била примена? Или ако ERP модулот за проверка на достапноста на
берзата не реагира? Не можеме да претпоставиме дека другата страна секогаш ќе одговори или дека системот
секогаш ќе биде функционален. Слично на тоа, не можеме да претпоставиме дека активностите секогаш водат
кон позитивен исход. На пример, нарачката не може секогаш да се потврди.
Можеби ќе ве изненадите колку ретко исклучоците се моделираат во деловно ориентиран

процес во пракса. Така, во повеќето случаи, таков модел ќе бара да се заврши со овие аспекти
пред да се изврши.
Во овој чекор, исто така, треба да ги наведеме сите предмети за електронски податоци кои се потребни како влез и
излез од задачите на нашиот процес. На пример, на сл. 9,6 нема предлог за влезни податоци за задача „Барајте суровини
од снабдувачот 1 (2)“, иако за оваа задача е потребен список на суровини што треба да се нарачаат. Друг пример е задача
„Проверете ја достапноста на акциите“. Оваа задача ја користи нарачката за набавка како влез (за да се добие кодот на
производот што треба да се разгледува во складиштето ДБ), но не произведува излезни податоци за чување на
резултатите од пребарувањето. Сепак, без овие информации, последователното поделување на XOR не може да утврди
која гранка да се земе (сега можеме да видиме зошто се нарекува ова податоци засновани на XOR-сплит). Ако досега не
сте забележале отсуство на овие објекти за податоци, тоа е веројатно затоа што го претпоставивте нивното постоење.
Ова е in ne во деловно ориентиран модел, каде што се документирани само аспектите релевантни за специфичната цел за
моделирање, но не во извршен модел, каде што моторот треба да работи со моделот. Значи, проверете дали секоја
активност ги има потребните објекти за влез и излез за електронски податоци. Принципот е дека секој предмет на
податоци што му е потребен на моторот BPMS за да помине контрола помеѓу активности и да донесува одлуки, мора да
биде моделиран.
Примерот за завршен налог за завршен налог, вклучувајќи ги ракувачите со исклучок и предметите на податоци што се
релевантни за извршување, е прикажано на сл. 9,8 . 1
Вежба 9.10 Земете го моделот за проценка на заемот што го стекнавте во вежбање 9,6 по вклучувањето
на ревизиите од вежба 9,7 . Завршете го овој модел со контролни и аспекти на податоци и важни за
автоматизација. За едноставност, може да ги занемарите елементите за моделирање кои не се толкуваат
со BPMS.
9.4.4 Доведете го моделот на процеси до соодветно ниво на грануларност
Не мора да е мапирање еден-на-еден помеѓу задачите во моделот на деловно работење и оние во соодветниот
извршен модел. Навистина, треба да имаме во предвид дека БПМС има за цел да ги координира и управува со
предавањето на работата помеѓу повеќе ресурси (човечки или нечовечки). Според тоа, две или повеќе
последователни задачи доделени на ист ресурс се кандидати за агрегација. Ако тоа беше случај, BPMS нема да
додаде вредност помеѓу овие две задачи затоа што нема да управува со ниту еден примопредавање. Сè што
би направиле е да се меша во работата на даден ресурс. На пример, низата задачи на корисниците „Внесете го
името на клиентот“, „Внесете го бројот на политиката на клиентите“ и „Внесете детали за оштетување“, така
што сите три задачи ќе ги извршува истиот управувач со побарувања, треба да се агрегираат во една задача за
еден корисник “ Внесете барање “
1 Содржината на под-процесите и некои елементи што не можат да се толкуваат со БПМС се изоставени за
едноставност.
Сл. 9.8 Модел за целосна нарачка на Сл. 9,6 , завршени со контролни и аспекти на податоци што се релевантни за
автоматизација
Постојат некои случаи, каде што можеби ќе треба да ги задржиме последователните задачи, и
покрај тоа што тие ги извршуваат истиот ресурс. На пример, во
Сл.9.9 Процесот на продажба на давателот на услугата B2B услуга
Сл. 9,7 в имаме три задачи на корисниците во рамките на под-процесот „Потврдете ја валидноста на степени“:
„Испраќајте документи до агенција“, „Добивајте резултати од агенција“ и „Ажурирај го записот на студентите“.
Додека овие може да ги изврши истиот службеник, ние сакаме да следиме кога е завршена секоја задача, за да го
следиме напредокот во апликацијата и да управуваме со потенцијални исклучоци. На пример, ако резултатите не
се примени во дадена временска рамка, можеме да го решиме ова одложување со додавање на управувач со
исклучок за задачата „Прими резултати од агенција“.
Вежба 9.11 Дали има активности што можат да се збираат во моделот добиен во вежба 9,10 ? Совет: задачите на
кандидатите за агрегација не мора да бидат последователни заради суб-оптималниот редослед на задачите во
моделот ориентиран кон деловно работење. Во овој случај, треба да ги преиспитате првите задачи (види Секција. 8.2.3
)
Во слична насока, ако некоја активност бара да се извршат повеќе од еден ресурс, исто така е груб, затоа
треба да го разделиме во повеќе не-гранулирани задачи така што тие можат да бидат доделени на различни
ресурси. На пример, активност „Внесете и одобрете го трансферот на пари“, најверојатно, ќе ја извршат двајца
различни учесници дури и ако тие имаат иста улога, за да се спроведе одвојување на должностите: првото
финансиско лице влегува во нарачката, потоа различно финансиско значење го одобрува.
Вежба 9.12 Слика 9,9 го покажува моделот за процесот на продажба на давателот на услугата
деловен-тутун (B2B). Процесот започнува кога апликацијата е примена од потенцијален клиент.
Потоа, на клиентот му се испраќаат информации за достапните услуги и се чека одговор или преку
е-пошта или пошта. Кога ќе се добие одговорот, ќе се донесе одлука за следната акција. Или може
да се закаже состанок со клиентот за да разговараат за опциите за услугата лично, или
апликацијата веднаш е прифатена или одбиена. Ако апликацијата е прифатена, понудата се
испраќа до клиентот и во исто време се спроведува апликација. Ако тоа биде одбиено, на клиентот
му се испраќа благодарница и се пушта. Доколку треба да се закаже состанок, тоа се прави и во
моментот на закажувањето, апликацијата се разговара за клиентот.
1. Идентификувајте го типот на секоја задача и вторите начини на поврзување на мануелните задачи со BPMS.
2. Отстранете ги елементите што не можат да се толкуваат со BPMS.
3. Дополнете го моделот со контролен и аспект на податоци потребни за извршување.

4. Доведете го добиениот модел до ниво на грануларност што е соодветно за извршување.
Признание Оваа вежба е прилагодена од слична вежба развиена од Ремко Дијкман, Универзитет
за технологија на Ајндховен.
9.4.5 Наведете карактеристики на извршување
Во последниот чекор, треба да го одредиме како секој елемент на моделот е ефикасно имплементиран од страна на
BPMS. На пример, преземете ја првата задача за услугата на нашиот ревидиран пополнет пример за ревидираната
нарачка: „Проверете ја достапноста на берзата“. Да се каже оваа задача бара нарачка за купување бидејќи влез за
контакт со магацинот ERP систем не е доволен. Треба да ја наведеме услугата обезбедена од системот ERP за да ги
провериме нивоата на залихи и нејзината локација во мрежата, информациите за производот во нарачката што ја
бараат оваа услуга (т.е. форматот на влезниот предмет) и информациите произведени од услуга (т.е. форматот на
излезниот предмет). Овие детали за имплементацијата се нарекуваат својства за извршување. Повеќе, поточно, ова
се:
• Процесирајте ги променливите, пораките, сигналите и грешките
• Променливи на задачи и настани и нивни пресметки за обработка на варијабли
• Детали за услугата за услугата, испраќање и примање задачи и настани за пораки и сигнали
• Шифри за код за задачи со скрипти
• Правила за задача на учесниците и структура на кориснички интерфејс за кориснички задачи
• Задачи, настани и низа изрази

• Специфични карактеристики на BPMS
Овие својства немаат графичко претставување во дијаграмот BPMN, но се чуваат во формат за размена
на BPMN 2.0. Форматот за размена на BPMN е текстуална претстава на моделот BPMN во формат XML.
Наменет е да го поддржи размената на модели BPMN помеѓу алатите и исто така да служи како влез во
моторот за извршување BPMN. Алатките за моделирање BPMN обезбедуваат визуелен интерфејс за да ги
уредувате повеќето од овие не-графички својства, така што повеќето пати нема да ви треба директно да ја
напишете XML. Сепак, ќе треба да ја разберете стандардната веб-технологија, особено XML, XML шемата
(XSD) и да бидете запознаени со поимот (веб) услуга, за да можете да имплементирате модел на процеси.
Овој дел претпоставува дека имате основно познавање на овие технологии. Ние нудиме индикатори за
понатамошно читање на овие технологии во секцијата. 9,8 . Слика 9,10 ја покажува структурата на формат
BPMN. Се состои од список на елементи, каде што некои по избор (оние со испрекината граница), а други се
задолжителни (оние со цврсти граници). Процесот е задолжителен и ги чува информациите за моделот на
процеси. Ова се состои од предмети за електронски податоци, настани, задачи и долгови. Елементите надвор
од процесот се потребни компоненти за еднократно користење
Сл. 9.10 Структура на формат

BPMN
од страна на различните процесни елементи, како што се дефиниции за пораки и интерфејси за услуги што се користат
од услугата, испраќаат и примаат задачи, како и преку настани и пораки и сигнали. Во врска со оваа структура,
дозволете ни да поминеме низ сите својства за извршување погоре.
Променливи на променливи, пораки, сигнали и грешки Променливите со процесите се управуваат со моторот
BPMS за да овозможат размена на податоци помеѓу елементите на процесите. Секој предмет за електронски
податоци, на пр. Нарачката во процесот на нарачка, претставува променлива на процесот. Theивотниот век на
променливата на процесите е утврден за животниот век на процесниот процес во кој се креира променливата и е
видлива само за нивото на процесите во коешто е дефинирана и за сите нејзини под-процеси. Ова значи дека
променлива дефинирана во под-процес не е видлива во родителскиот процес.
Треба да доделиме а тип на податоци до секоја променлива во процесите со цел БПМС да може да ги толкува и
манипулира овие променливи. Во BPMN, типот на секоја променлива во процесот е специфициран како тип XSD. Типот
на променливата може да биде едноставна или
сложено. Едноставни типови се жици, цели броеви, двојки (броеви што содржат децимални броеви), булевари,
датуми, времиња, итн., И веќе се дефинирани во спецификацијата XSD. На пример, достапноста на објектот
може да биде претставена како процесна променлива од цел број на типот (претставува број на достапни
единици на производот). Комплексни типови се хиерархиски композиции од други видови. Сложениот вид може
да се користи на пример за да претставува деловен документ, како нарачка или фактура. Слика 9.11 а го
покажува комплексниот вид на нарачката, наречен купувањеПоследно време, додека
Сл.9.11 XSD го опишува нарачката за купување ( а) и една од нејзините примери ( б)
Сл. 9.11 б е застапеност на XML на одреден пример за нарачка за нарачка на време на траење. Од типот на
дефиниција можеме да видиме дека нарачката за купување содржи низа од два елементи:
• Нарачај, за чување на информации за нарачката (број на нарачка, датум на нарачка, статус, валута, код на производ
и количина) и
• Клиент, за чување на информации за клиентот (име, презиме, адреса, телефон и факс)
Редоследот, клиентот и адресата на податоците се комплексни типови за да можат да содржат

под-елементи. Исто така, почитувајте го и стариот статус: ова се користи за снимање на состојбата на
нарачката, на пр. „Потврдено“.
Слично на променливите за процесирање, исто така треба да доделиме типови на податоци на секоја порака, сигнал
и грешка што се користи во моделот на процеси. За пораките, можеме да ги погледнеме постојните долгови на пораките
во дијаграмот и да дефинираме еден тип на податоци за секоја единствено обележана порака. Така на пример, ако
имаме нарачка со две пораки означени со нарачка, тие очигледно ќе земат ист вид нарачка за купувањеОрдерТип. Ако
порака
Долгите не се моделирани, можеме да ги разгледаме задачите за испраќање, примање и сервисирање и на настаните за
пораки присутни во дијаграмот за да разбереме какви пораки да се дефинираат. За сигнали и грешки, треба да ги
разгледаме настаните во сигналот и грешките што ги имаме дефинирано во дијаграмот. Додека за сигнал, типот на
податоци ја опишува содржината на сигналот што се емитува или се слуша, за грешка, типот на податоци утврдува какви
информации се носат со грешката. На пример, ако станува збор за системска грешка, можеме да го искористиме ова за да
ја одредиме пораката за грешка вратена од системот. Покрај тоа, треба да назначиме код за грешка на секоја грешка. Овој
код уникатно идентификува грешка во рамките на моделот на процес, така што настанот за грешка при фаќање може да
биде поврзан со настан за грешка при фрлање.
Променливи на задачи и настани Покрај горенаведените елементи на податоци, треба да ги дефинираме и

внатрешните променливи на секоја задача, наречена влезови на податоци и излезни податоци во БПМН.
Влезовите и излезите на податоци делуваат како интерфејси помеѓу задачата и објектите за влез и излез на
податоци. Тие исто така треба да се однесуваат на типот XSD што ја одредува нивната структура, но различни
од процесните променливи, тие се видливи само во рамките на задачата (или под-процес) во која тие се
дефинираат. Внесување на податоци фаќа податоци што се потребни со задачата што треба да се изврши;
излезни податоци ги снимаат податоците што ги создава задачата по завршувањето. Така, влезовите на
податоци се населени со содржината на предметите за влезни податоци, додека излезните податоци се
користат за да се насели содржината на објектите за излезни податоци. На пример, потребен ни е внес на
податоци за задачата „Проверете ја достапноста на акциите“ за да ја зачуваме содржината на нарачката. Така,
типот на овој внес на податоци мора да одговара на оној на влезниот предмет, т.е. купувањетоОрдерТип.
Слично на тоа,
Мапирањето помеѓу предметите на податоци и влезовите / излезите за податоци од задачите се дефинира преку
задачата здруженија на податоци. Здруженијата на податоци исто така може да се користат за дефинирање на сложени
задачи на податоците над мапирањето еден до еден. На пример, разгледајте ја задачата „Производство на производ“.
Услугата повикана од оваа задача бара само код и количина на производ за нарачка со цел да се започне со
производство на производот. Така, можеме да користиме здружение за податоци за да ги извадиме производот и
количината на производот од нарачката за набавка на купување и да дополниме внесување податоци што содржат два
под-елементи на низата, соодветно, цел број. Во повеќето случаи, BPMS автоматски ќе ги создаде сите досадни
картирања на податоците помеѓу предметите на податоците и задачите. На пример, за случајот пред сè што треба да
направиме е да ги избереме под-елементите на нарачката што сакаме да ги користиме како влез во „Производство
производ“, а BPMS ќе ги создаде потребните влезови на податоци и нивните мапи за оваа задача . BPMN се потпира на
XPATH 1. 0 како основен јазик за изразување на задачи на податоци како оној погоре. Како и да е, другите јазици можат
да се користат како Јава Универзален јазик за изразување (UEL) или Groovy. Изборот зависи од усвоениот BPMS. На
пример, Активити го поддржува UEL, Bonita Open Solution и Camunda Fox го поддржуваат Groovy, додека BPM Suite на
BizAgi поддржува свој јазик на изразување.
Слично на задачите, настаните што пренесуваат или примаат податоци, т.е. настани за пораки, сигнали и грешки,
имаат и внатрешни променливи. Поточно, фаќањето верзија на овие настани има само еден излез на податоци, за да ја
сочува содржината на настанот што е фатен (на пр.

дојдовна порака), додека верзијата за фрлање има само еден внес на податоци, за да ја сочува содржината на
настанот што се фрла (на пр. грешка). Така, треба да ги назначиме овие влезови и излези за податоци што
треба да одговараат на пораката, сигналот или грешката поврзана со настанот. На пример, почетниот настан за
порака за порака „Нарачка за набавка примена“ во целосниот пример за нарачка користи излез на податоци за
да ја зачува пораката за нарачката за купување откако ќе се прими ова. Така, овој излез на податоци мора да
одговара на видот на дојдовната порака, што е точно купувањеОрдерТип. За возврат, излезниот предмет мора
да има ист тип како и излезните податоци, за да го содржи нарачката.
Сложените типови за сите елементи на процесот можат да се дефинираат директно во моделот BPMN или
да се увезуваат од надворешен документ (види Сл. 9,10 )
Задачи за услуги Откако ќе ги утврдиме типовите на сите елементи на податоците и мапираните влезни
податоци и задачи и настани за овие типови, треба да наведеме како треба да се спроведат задачите и
настаните. За услужни задачи, треба да наведеме како да комуницираме со надворешната апликација што
ќе ја изврши задачата. Било да е тоа сложен систем или едноставна апликација, од гледна точка на BPMS,
се што бара е е дека надворешната апликација обезбедува услужен интерфејс што услужната задача може
да ја користи. Сервисен интерфејс содржи еден или повеќе услужни работи, секој опишува одреден начин на
интеракција со дадена услуга. На пример, услуга за прибирање информации за инвентар обезбедува две
операции: една за проверка на тековните нивоа на залиха и една за проверка на прогнозата на акции за
даден производ (врз основа на код или име на производ). Операција или може да биде во-надвор или само- Во
интер-операција (исто така наречена синхрон операција), услугата очекува порака за барање и одговара со
порака за одговор откако ќе заврши операцијата, или по избор со порака за грешка ако нешто тргне наопаку.
На пример, услугата повикана од задачата „Проверете ја достапноста на суровините“, добива информации
за достапноста на акциите како влезна порака и одговара со список на суровини што ќе се нарачаат како
излезна порака. Алтернативно, ако услугата доживее исклучок (на пр. Каталогот на добавувачи е
недостапен), тој одговара со порака за грешка што го активира настанот за гранична грешка на оваа задача,
така што може да се изврши релативниот управувач со исклучоци. 2 Спротивно на тоа, во единствена
операција (исто така наречена асинхрон операција), услугата очекува порака за барање, но нема да
одговори со порака за одговор. На пример, задачата „Архивска наредба“ означува архивска услуга за
нарачката што треба да се архивира, сепак, процесот не чека архивска потврда.
Секоја порака за услужна операција треба да упати порака во моделот BPMN, за да може да му се
додели тип на податоци. На пример, барањето и пораките за одговор за да комуницирате со услугата за
инвентар имаат купување на типот на податоциОрдерТип, соодветно, XSD цел број. За секој интерфејс,
исто така, треба да одредиме како конкретно се спроведува, т.е. со кои комуникациски протоколи се
користат
2 Забележете дека нема настан за грешка при фрлање во „Проверете ја достапноста на суровините“ бидејќи настанот за грешка при фаќање се
активира со приемот на порака за грешка од страна на услугата задача. Способноста да се поврзат пораките за грешки со настани за грешки е
честа карактеристика на BPMS.

услугата и каде услугата се наоѓа во мрежата. Стандардно, BPMN користи технологија за веб-услуги за
спроведување на интерфејси за услуги и се потпира на WSDL 2.0 за да ги специфицира овие информации. Во
пракса, ова одговара на утврдување на еден или повеќе надворешни документи за WSDL и внесување на нив во
нашиот BPMN модел. Уште еднаш, можни се други имплементации, на пр. Може да се имплементира сервисен
интерфејс преку повик за далечинска постапка со Java или обична XML преку HTTP.
Откако ќе ги дефинираме интерфејсите за услуги за нашиот процес, треба да ја поврземе секоја услужна задача
со услужна операција дефинирана во услужен интерфејс. Врз основа на видот на операцијата (внатре или само),
тогаш треба да дефинираме единствен внес на податоци што мора да одговара на видот на пораката за барање во
референцираната услужна услуга и по избор на единечен излез на податоци што мора да одговара типот на пораката
за одговор во работењето. Моторот BPMS ќе го копира внесувањето на податоците за задачите во пораката за
барање и ќе го испрати до услугата, а штом ќе добие порака за одговор, ќе ја копира содржината на оваа порака во
излезот на податоците за задачите.
Испратете и примајте задачи, пораки и настани од сигналот Испратете и примајте задачи на сличен начин.
Задача за испраќање е посебен случај на услугата задача: испраќа порака до надворешна услуга со помош на
внес на податоци, но нема одговор. Пример е задача „Известете ја недостапноста на клиентот“. Задача за
примање чека влезна порака и го користи резултатот за чување на содржината на пораката. Задачата „Добиј
адреса за испорака“ е пример за ова. Двата типа на задачи треба да упатуваат на единствена услуга за
услугата каде што пораката е дефинирана. Сепак, за приемот, пораката што се прима се смета за барање што
доаѓа од барател на надворешна услуга. Така, во овој случај самиот процес дејствува како давател на услуги.
Задача за примање исто така може да се искористи за да добиете одговор на асинхрона услуга која
претходно била повикана со задача за испраќање. Ова е случај на задачи „Барај адреса за испорака“ и
„Добиј адреса за испорака“. Асинхроната услуга ја обезбедува клиентот. Соодветно на тоа, во задачата за
испраќање, постапката на продавачот делува како барател на услугата што испраќа порака за барање до
клиентот. Во задачата за примање, улогите се менуваат: продавачот делува како давател на услуга за да ја
добие пораката за одговор од клиентот. Оваа шема се користи за долготрајни интеракции, каде одговорот
може да пристигне по некое време. Недостаток на употреба на синхрона услужна задача наместо
испраќање е дека оваа задача ќе го блокира процесот за да ја чека пораката за одговор. Ова не е случај на
Сл. 9,8 , кога задачите за испраќање и примање се паралелно со „Испуштате фактура“ што може да се
изврши меѓу другото.
Настаните за пораки и сигнали работат точно како задачи за испраќање и примање. За настани со сигнали, се
претпоставува дека услугата со која се контактира има можности за објавување-претплата, на пр. Веб-услуга за
претплата на RSS доводи.
Задачи за сценарио За задачите со скрипта, треба да обезбедиме дел од кодот што ќе го изврши BPMS.
Овој код може да се напише на програмски јазик како JavaScript или Groovy. BPMN не пропишува
употреба на специфичен програмски јазик, така што изборот зависи од користениот BPMS. Влезовите за
задачи ги чуваат параметрите за повикување на скриптата додека излезите со податоци ги чуваат
резултатите
на извршување на сценариото. На пример, за задачата „Одреди казна за откажување“, можеме да дефинираме скрипта со која
се извлечени датумот на нарачката и датумот на барањето за откажување од два влезни податоци, мапирани во нарачката за
набавка на влезните објекти и барањето за откажување, ги користи овие информации за да пресмета казна од € 15 за секој ден
минатиот датум на нарачката и ја копира оваа вредност на излез на податоците.
Задачи за корисници За секоја задача на корисникот треба да ги определиме правилата за доделување работни елементи од
оваа задача за да ги процесираме учесниците на време на траење, технологијата за комуникација со учесниците и деталите за
корисничкиот интерфејс што треба да се користи. Освен тоа, како и за секоја друга задача, треба да разработиме влезни податоци
за да пренесеме информации до учесникот и излези за да ги добиеме резултатите.
Се повикуваат учесници во процесот на кои може да им бидат доделени задачи на корисници потенцијални сопственици
во БПМН. Потенцијален сопственик е член на класа на ресурси. Во контекст на задачите на корисниците, класата на
ресурси идентификува статички список на учесници споделување на одредени карактеристики, на пр. има иста улога
или припаѓа на истиот оддел или единица. Пример за класа на ресурси за процесот на нарачка во однос на нарачката е
службеникот за нарачки, кој ги групира сите учесници кои ја имаат оваа улога во одделот за продажба на
организацијата на продавачот. Забележете дека овие класи на ресурси не се поврзани со базени и ленти, кои се само
номинални елементи во деловно ориентиран модел на процеси. Класа на ресурси може дополнително да се
карактеризира со еден или повеќе ресурси параметри, каде параметар има име и тип на податок. На пример, можеме да
дефинираме два параметрални производи и регион од типот на низа за да ги означиме конкретните производи со кои
работи службеникот за нарачки и регионот во кој работат.
Откако ќе ги деактивираме сите потребни класи на ресурси и по избор на нивните параметри, можеме да ја
доделиме секоја задача на корисниците на една или повеќе класи на ресурси засновани на израз. На пример, можеме
да изразиме дека работните артикли од задачата „Усогласена нарачка“ треба да бидат распоредени на сите учесници
од службеникот за нарачки од типот кои се занимаваат со конкретниот производ што го нарачува и работат во истиот
регион како клиентот. За ова, можеме да дефинираме XPATH израз кој ги избира сите членови на службеникот во
редот, чии својства производот и регионот се еднакви на кодот на производот, соодветно, земјата содржана во
нарачката.
Исто така, треба да ја специфицираме технологијата за спроведување што се користи за понуда на работната ставка
на избраниот учесник (и) (и) (и) (и). Ова подразбира аспекти, како на пример, како да се дојде до учесник (на пр. Преку
е-пошта или известување за списокот со работни списоци), како да се направи содржината на влезовите на податоците за
задачите на екранот (на пр. Преку една или повеќе веб-форми организирани преку одреден екран) и стратегијата доделете
ја работната ставка на еден учесник од оние што го задоволуваат изразот за доделување задача (на пр., доделете му на
службеникот за нарачки со најкраткиот ред или случајно). Уверувањето на овие аспекти, како и поврзаноста на учесниците
на часовите за ресурси зависи од специфичниот BPMS што се користи.
Изразувања на задачи, настани и секвенци Конечно, треба да напишеме изрази за различните

атрибути на задачи и настани и за низата услови коишто ги носат. На пример, во една задача за јамка
треба да напишеме булен израз кој го спроведува текстот со прибелешката што укажува на состојбата
на јамката (на пр. „Додека не се добие одговор“) Овој булен израз ќе утврди кога ќе биде задачата на
јамката
да се повтори. Овој израз може да се дефинира преку елементите на податоците, на пр. Може да биде израз
XPATH што ја извлекува вредноста на бугарскиот елемент „одобрен“ од објект за одговор. Ние исто така можеме да
користиме пример атрибути во овие изрази. Овие се променливи што се разликуваат по пример при извршувањето.
Пример е броење на јамка,
што брои број на повторувања за задача на јамка. За тајмерниот настан, треба да наведеме израз за да се
фати временски настан што неформално е искажан со неговата етикета (на пр. „Петок попладне“). Тука
имаме три опции: можеме да обезбедиме временски израз во форма на прецизен датум или време,
релативно траење или повторувачки интервал. Уште еднаш, овие изрази можат да се поврзат со елементите
на податоците и со својствата на пример за да се решат динамично при извршување. На пример, можеме да
поставиме временски рок за потврда на нарачката, врз основа на бројот на артикли во редот. Конечно, треба
да напишеме булен израз за да ја доловиме состојбата прикачена на секоја секвенца - должејќи по (X) ИЛИ
поделбата. На пример, состојбата „производ на залиха“ по првото прво поделување XOR во целосниот
пример за нарачка може да се примени како израз XPATH кој проверува дали вредноста на достапноста на
променливата залиха е барем еднаква на количината на производот содржана во нарачката. Нема потреба
да се назначи израз на зададена секвенца, бидејќи овој лак ќе го преземе моторот BPMS ако изразите
доделени на сите други лаци кои произлегуваат од истата (X) Или поделеност ги оценуваат неточни.
Специфични карактеристики на BPMS Строго кажано, единствените специфични својства на БПМС што треба да ги
конструираме за да можеме да извршиме извршен модел на процеси се оние на корисничките задачи. Во пракса, сепак,
најверојатно ќе треба да го поврземе нашиот процес на извршување со системот на претпријатие на нашата организација.
Ова се нарекува врзување на системот. За среќа, BPMS-овите нудат опсег на претпочитани наставни задачи за услуги,
наречени адаптери за услуги адаптер за услуги (или услужни конектори), да се имплементираат функции за врзување на
заеднички систем на пригоден начин. Примери за вакви обврзувачки функции вклучуваат: вршење пребарување на база на
податоци, испраќање на е-пошта за известување, објавување порака на Твитер или поставување настан во Календарот на
Google, читање или пишување напис и додавање на клиент во CRM систем. Секој адаптер доаѓа со список на параметри што
треба да ги конструираме. Сепак, BPMS-овите им овозможуваат на волшебниците со можност за авто-откривање на некои
од вредностите на параметарот. На пример, за да користите пребарување за база на податоци, треба да го обезбедиме
типот на серверот за бази на податоци (на пр. MySQL, Oracle DB) и URL-то до каде може да се стигне до серверот, шемата
до која треба да се пристапи, барањето SQL да се изврши и акредитивите на корисникот овластен да работи на барањето.
Враќајќи се на нашиот пример, наместо да ја спроведеме задачата „Проверете ја достапноста на акциите“ како
услужна задача, што претпоставува постоење на услуга за информации за инвентар кај продавачот, оваа задача би
можеле да ја спроведеме со генерички адаптер за пребарување на бази на податоци, под услов да знаеме што да
пребарување и каде. Слично на тоа, би можеле да ги реализираме задачите за комуникација со клиентот, како
„Известете за достапноста до клиентот“ и „Барање адреса за испорака“ како адаптери за е-пошта, за да не треба да
спроведуваме посветен е-пошта во нашата организација. Бројот и разновидноста на адаптери што ги обезбедува
BPMS во голема мерка придонесуваат за зголемување на вредноста на производот во однос на конкурентните
решенија.
Вежба 9.13 Разгледајте го моделот на процена на заемот што го стекнавте во вежбање 9.11 .
Апликацијата за заем ги содржи овие податоци:
• Информации за апликантот:
- Информации за идентитет (име, презиме,..)

- Информации за контакт (домашен телефон, мобилен телефон, ...)
- Тековна адреса (име на улица и број, град,..)

- Претходна адреса (како погоре плус времетраење на престојот)
- Финансиски информации (детали за работа, детали за банка)
• Референтни информации (идентитет, контакт, адреса, врска со барателот)

• Информации за имот (тип на имот, адреса, куповна цена)
• Информации за заем (износ, број на години, датум на започнување, вид на камата: променлива / fi xed)
• Идентификација на апликација
• Датум и време на поднесување
• Датум на ревизија и време
• Информации за администрација (дел што треба да го собере давателот на заем):

- Статус (стринг за да се следи состојбата на апликацијата, со преддефинирани вредности:
„нецелосни“, „целосни“, „оценети“, „отфрлени“, „откажано“, „одобрено“)
- Коментари за статусот (по избор, на пр. Се користат за да се објаснат причините за одбивањето)
- Подобност (булеран за чување дали апликантот има право на заем)

- Зајмување за повеќе информации
- Потребна е понуда за осигурување (потребен е булан за чување дали се бара понуда за домашно осигурување)
Извештајот за кредитна историја ги содржи овие податоци:
• Идентификација на извештајот
• Финансиски за идентичен карактер
• Упатување на барање за заем

• Кредитни информации на апликантот:
- Апликации за заем направени во последните неколку години (тип на заем: домаќинство / лична / домашна, износ,
времетраење, каматна стапка)
- Заостанати кредитни сметки (тип на кредит, основен износ, времетраење, каматна стапка)
- Тековни информации за кредитни картички (снабдувач: Виза, Мастеркард, ...., Датум на започнување, датум на
завршување, каматна стапка)
- Информации за јавни записи (по избор, доколку има):
• Информации за судски пресуди

• Информации за стечај
• Кредитна проценка (низа со претходно утврдени вредности: ААА, АА, А, БББ, ББ, Б неценети).
Проценката на ризикот ги содржи следниве податоци:
• Идентификација за проценка

• Упатување на извештај за кредитна историја
• Тежина на ризикот (цел број од 0 до 100)
Проценката на имотот ги содржи следниве годишни податоци:
• Идентификација на проценка

• Идентификација на проценител на имот
• Информации за имот (тип на имот, адреса)

• Вредност на три околни својства со слични карактеристики
• Проценета вредност на пазарот за недвижнини
• Коментари за имот (по избор, за да се напомене сериозно - со оглед на тоа што имотот може да го има)
Резимето на договорот ги содржи следниве податоци:

• Услови што се договорени (булевац што укажува дали апликантот се согласил со условите за заем)
• Отплатата е договорена (булестар што укажува дали апликантот се согласил со распоредот за отплата)
• Врска до дигитализирана копија на договорот за отплата
Давателот на заем нуди веб-страница на која апликантите можат да доставуваат и ревидираат апликации за заем
преку Интернет, да го следат напредокот на нивните апликации и доколку е потребно, да ги откажат апликациите што
се во тек. Оваа веб-страница имплементира основна веб-услуга со која комуницира процесот на проценка на заемот.
Во пракса, оваа услуга делува како апликант од гледна точка на процесот на проценка на заемот. На пример, доколку
подносителот на апликацијата поднесува нова апликација за заем преку веб-страницата, оваа услуга ја обвиткува
оваа апликација во порака и ја испраќа до моторот BPMS на давателот на заемот, што пак започнува нов пример за
процесот на проценка на заемот. Ако процесот на проценка на заемот испраќа апликација за преглед до оваа услуга,
услугата ги доставува овие информации на апликантот преку веб-страницата на давателот на заем.
Понатаму, процесот на проценка на заемот комуницира со внатрешна услуга за проценка на ризиците од

заемот. Оваа услуга одредува тежина на ризик што е пропорционална со кредитната проценка содржана во
извештајот за кредитна историја, врз основа на важечките правила за ризик прочитани од базата на податоци
(интеракцијата помеѓу услугата и базата на податоци е транспарентна за BPMS). Услугата за проценка на ризикот
враќа проценка на ризикот што содржи идентификација (свежо генерирана), упатување на апликацијата за заем и
извештај за извештајот за историја на кредит (истите извлечени од извештајот за кредитна историја) и тежината на
ризикот.
Врз основа на горенаведените информации, наведете ги својствата за извршување за елементите на овој процес на
модел. Од вас не се бара да го дефинирате вистинскиот XSD тип на секој елемент на податоци, ниту да ги наведете
вистинските скрипти за Groovy или изразите XPATH. Сè што треба да направите е да идентификувате кои својства треба да
се специфицираат, т.е. кои влезни податоци и излези, потребни се интерфејси за услуги, операции, пораки и грешки и да се
утврди нивниот тип на податоци во однос на оние на променливите на процесите. На пример, внесот на податоци може да се
мапира до променливата на процесите или на податоците во рамките на ова. За скриптите, треба да се дефинираат преку
влезови за податоци за задачи и излези кои податоци се потребни со скриптата, какви податоци се произведуваат и како
влезните податоци се трансформираат во излез

еден. На пример, врз основа на вредноста на податоците во процесната променлива, скриптата може да напише
одредена вредност во претходната варијабла за податоци. Слично на тоа, за секоја задача на корисникот, треба да
идентификувате какви информации се презентираат на изведувачот на задачите и како се добива излезот на податоци.
Конечно, треба да објасните како секој израз може да се процени врз основа на податоци на податоци во рамките на
променливите во процесот (на пр. Да се спроведе состојбата на секвенцата), или постојаните вредности како датумот (на
пр. Да се спроведе тајмер настан).
9.4.6 Последната милја
Сега кога сте запознале со она што е потребно за да се изврши извршен процесен модел, последен чекор за
вас е да преземете процесен модел и да го имплементирате користејќи BPMS по ваш избор (на пр. Активити,
Бонита Отворено решение, Бизнис пакет на Bizagi, YAWL ) Пејзажот на БПМС и нивните специфични градови
постојано се развива. Можеме да идентификуваме три категории на BPMS во однос на нивната поддршка за
BPMN:
1 Чиста BPMN Овие алатки се дизајнирани од земја па се до поддршка

BPMN природно. Тие ја следат спецификацијата „до писмото“, иако можеби нема да го поддржат
целосно. Примери се Активити и Камунда Фокс.
2. Адаптиран BPMN Овие алатки користат BPMN кожа, но се потпираат на внатрешен одговор
огорченост за извршување на моделот на процеси. Тие можат да увезуваат, а понекогаш и да извезуваат во формат
BPMN 2.0. Тие вообичаено предлагаат БПМН и еволуирале од претходните верзии за да ја поддржат
спецификацијата. Примери се Бизгавиот пакет на Бизгаги и Отвореното решение на Бонита.
3. Не BPMN Основно постои општа категорија на BPMS кои ги користат своите

комерцијален јазик и семантика. Овие алатки не го поддржуваат BPMN. Примери се BPMOne
од перцептивен софтвер и YAWL.
За време на пишувањето, повеќето од BPMS-те кои го поддржуваат BPMN на овој или друг начин, сè уште не
ги опфаќаат сите аспекти на спецификациите што се релевантни за извршување. На пример, елементи како
настани за границата со пораки, настани за компензација и настани што не се прекинуваат, не се поддржани.
Значи, конкретно, треба да се откажеме од еден или повеќе од овие елементи во зависност од БПМС што ги
усвојуваме. Очекува дека иако таа поддршка за извршна БПМН ќе се зголеми со тек на време.
Овој дел илустрираше како да се дизајнираат извршни модели BPMN на начин кој зависи од
продавачот. Веб-страница на книгата ( http://fundamentals-of-bpm.org ) дава упатства за упатства што
покажуваат како да се обезбеди извршен модел на процес за бетонски BPMS.
Вежба 9.14 Врз основа на својствата за извршување што сте ги навеле во вежба 9.13 , спроведување на процесот
на проценка на заемот користејќи BPMS по ваш избор.

9.5 Докажи
Во ова поглавје се фокусиравме на специфичниот тип на информативен систем за знаење на процеси, имено Системи
за управување со деловните процеси (BPMSs). Разговаравме за архитектурата на BPMS и нејзините главни
компоненти: моторот за извршување, алатката за моделирање на процесите и складиштето на моделот на процесите,
алатките за администрација и мониторинг и дневниците за извршување, како и надворешните услуги што можат да се
повикуваат.
Постојат многу причини за разгледување на процесите за автоматизација. Прво, тоа обезбедува намалување на обемот на
работа во однос на координацијата: работата е доделена на учесниците во процесирање или софтверски услуги веднаш штом е
достапна. Второ, тој нуди интегритет - егзистентност. Процесите можат да се променат со значително помалку напор во
споредба со наследните системи, под услов тие да бидат експлицитно претставени преку модели на процеси. Трето,
извршувањето во BPMS генерира вредни податоци за тоа како се извршуваат процесите, вклучително и податоци за
релевантни перформанси. Конечно, БПМС го подобруваат квалитетот на извршувањето на процесите бидејќи тие директно
спроведуваат правила, како што се раздвојување на должностите.
Воведувањето на BPMS претставува различни предизвици. Техничките предизвици произлегуваат од фактот дека
многу апликации што треба да се интегрираат обично не се дизајнирани како отворени системи со транспарентни
интерфејси. Покрај тоа, организациските предизвици се вкоренети во фактот дека БПМС директно се мешаат во тоа како
луѓето ја завршуваат својата работа. Овој факт повикува на управување со чувствителни промени.
Конечно, презентиравме метод за трансформација на деловните ориентирани модели на процеси во извршни
спецификации, за да може да се толкуваат преку БПМС. Прво, треба да го идентификуваме типот на секоја процесна
задача (автоматизирана, мануелна или корисничка) и да ги разгледаме прирачните задачи за да ги идентификуваме, кога е
можно, начин како да ги поврземе овие со BPMS. Следно, треба да го комплетираме моделот на процеси со наведување на
сите контролни и аспекти на податоците што се релевантни за извршување и да го премостиме различното ниво на
грануларност помеѓу деловно ориентиран модел на процеси и неговиот извршен колега. Конечно, треба да наведеме голем
број на својства за извршување за секој елемент на моделот. Некои од овие својства, како за задачите на корисниците, се
специфични за продавачите и така ќе варираат во зависност од специфичниот BPMS што ќе одлучиме да го донесеме.
9,6 решенија за вежби
Решение 9.1 Постојат три тековни работи:
1. Случај # 1.220: Одредете соодветно парче опрема

2. Случај # 1.230: Одредете соодветно парче опрема
3. Случај # 1.240: Барање за изнајмување на целосна опрема
Решение 9.2
• Моторот за извршување не би можел да утврди дека ќе распредели работни артикли на ресурси само врз
основа на процесен модел, кога само ќе ги покрие информациите за контролата.
9,6 решенија за вежби 339
• Една вообичаена ситуација ќе биде дека засегнатиот процес процес е специфичен дека по одредена активност
има паралелно разделување, што овозможува извршување на разни активности што следат.
• Други примери на услуги што можат да бидат корисни за да бидат повикани: услуги за пресметување (на пр. Да се утврди
стапка на хипотека или да се процени вкупните трошоци на услугата), услуги за чување информации и пребарување (на пр.
Да се регистрира исходот од завршената работна ставка или побарајте информации за клиентот), услуги за закажување (на
пр. да планирате работа што треба да се изврши во последователни активности или да се процени датумот на испорака),
комуникациски услуги (на пр. да стапите во контакт со клиентот или деловниот партнер), итн.
• Описите на деловните процеси и расположливите видови ресурси треба да бидат исти за да се овозможи
пренесување на работни артикли меѓу различните BPMS. Во спротивно, може да стане невозможно да се
мапира достапноста на работната ставка во рамките на еден процес во одредена временска зона до
одредена состојба на тој процес во друга временска зона.
• Имено, битно е да се определи за кои работни денови се достапни одредени ресурси и за кои
часови, на пр. Г-ѓа Отаген работи само во понеделник и петок од 9 до 16 часот. На овој начин,
станува возможно моторот за извршување да распредели работи на ефикасен начин.
Решение 9.3
1. Треба да стане можно новиот систем за поддршка на одлуките да се повика како надворешна
услуга.
2. Ако г-ѓа Отаген се пензионира, тоа мора да биде снимено со алатката за администрација.
3. Новото правило за алокација на работните ставки на ресурсите мора да биде зафатено во ажуриран модел на процеси.
4. Службата за набудување мора да се спроведе во алатка за набудување.
Решение 9.4
• Квалитет
• Транспарентност
• Флексибилност
Решение 9.5
1. Организациско прашање: BPMS може да биде прилагодено за да ги земе предвид специфичните податоци за пациентот.
2. Технички проблем: Интеграција на системот за поддршка на одлуки може да бара дополнителен,

прилагодено развој на софтвер.
3. Организациско / техничко: Медицинските сестри се едни од други можат да се навикнат да користат БПМС
воопшто и ракувачи со специфични листи. Од друга страна, можеби не е добро техничко решение да се
користат сигнали за вибрации - алтернатива би била, на пример, да се користат звучни сигнали.
Решение 9,6
Решение 9,7 Сите рачни задачи на овој процес, имено „Проценка на имотот“, „Подгответе пакет за прифаќање“,
„Испратете прифатен пакет“, „Испратете понуда за домашно осигурување“ и „Потврди договор за отплата“ можат
да се спроведат како задачи на корисникот. Во „Проценка на имотот“, проценителот на имотот се забележува
преку нивната работна листа дека треба да проценат нов имот. Информациите за имотот ги носи работната ставка
од оваа задача (на пр. Тип на имот и адреса). Проценувачот на имотот физички оди на адреса на имот за преглед
и ја проверува вредноста на околните својства. Откако ќе заврши, тој ја подготвува процената на електронска
форма и ја доставува до моторот BPMS преку управувачот со работната листа. „Подготви пакет за прифаќање“,
„Испрати пакет за прифаќање“, „Испрати понуда за домашно осигурување“ може да се имплементираат како
кориснички задачи на сличен начин.
„Потврди го договорот за отплата“ се појавува во заемот на работната листа на клиентот веднаш штом
пакетот за прифаќање и по избор на понудата за осигурување ќе бидат испратени до апликантот. Надзорот ја
проверува оваа работна ставка откако ќе го примат договорот за отплата од апликантот по пошта. Тие рачно го
потврдуваат договорот, го дигитализираат и го прикачуваат како дел од резимето на договорот - електронска
форма поврзана со оваа работна ставка и пренаселени со информации извлечени од апликацијата за заем. Ако
подносителот на барањето ги прифатил сите услови за заем и се согласил со распоредот за отплата,
доставувачот ги означува соодветните полиња за избор во резимето на договорот и ги доставува до моторот
BPMS.
Решение 9,8 Задачата „Проверете го осигурувањето“ може да се автоматизира преку услуга што го одредува
износот на партиципацијата врз основа на деталите за рецептот и полисата за осигурување на клиентот.
Задачи „Соберете лекови од полиците“ и „Проверете го квалитетот“ се рачни задачи. Овие задачи можат да
се спроведат како кориснички задачи во автоматизиран процес. За да го стори тоа, фармацевтскиот техничар
што ги собира лековите и фармацевтот кој квалитетно го проверува рецептот и ја запечати торбата, треба да
имаат удобен механизам за да сигнализираат завршување на овие активности на БПМС. Ова може да се
постигне со воспоставување на систем базиран на скенирани со баркодови за да се следат рецептите. На
пример, техничарот ќе види список на рецепти што треба да се извлечат од нивната работна листа. Потоа би
собрале еден од рецептите и системот би го поврзал рецептот на нов бар-код, кој е отпечатен на етикетата за
лепило. Техничарот тогаш ќе ја закачи етикетата во торба, ќе ги собере лековите и ќе ги стави во торба, а кога ќе
заврши, тие би го скенирале бар-кодот од етикетата за да забележат дека рецептот е исполнет. Ова сигнализира
завршување на задачата „Собери лекови од полиците“ до системот за аптеки. За возврат, тоа создава нова
работна ставка од задачата „Проверете го квалитетот“ во работната листа на фармацевтот. Фармацевтот потоа
може квалитетно да го провери рецептот и повторно да го скенира бар-кодот.
Задачата „Собери плаќање“ е исто така рачна задача. Оваа задача може да се спроведе како
услужна задача со која аптекарскиот систем би ја наметнал задачата за собирање на уплатата за
рецепт во системот за продажба (ПОС) и очекуваат ПОС системот да укаже дека плаќањето е собрано.
Фармацевтскиот техничар би комуницирал со ПОС системот откако ќе пристигне клиентот, но оваа
интеракција е надвор од опсегот на аптекарскиот систем. Фармацевтскиот систем само ја наметнува
работата кон ПОС системот и чека за завршување.
Сл. 9.12 Автоматизиран процес на комплетирање на рецепти
Описот на процесот имплицитно се однесува на рачна задача со која фармацевтот ја запечати торбата и ја
става во областа за пикање. Сепак, оваа задача „вреќа со печат“ не е вклучена во моделот на извршна постапка.
Наместо тоа, оваа задача е интегрирана во задачата „Проверете го квалитетот“. Со други зборови, на крајот на
проверката на квалитетот, фармацевтот се очекува да ја запечати торбата ако рецептот е подготвен и ќе ја испушти
торбата во областа за пикање.
Задачата „Враќање на вреќата на рецепт“ е исто така рачна, но нема никаква вредност за автоматизирање на кој
било начин. Значи, оваа задача е изоставена од моделот на извршна постапка, кој завршува откако ќе се изврши
плаќањето.
Извршниот модел на целиот процес на рецепт е прикажан на Сл. 9.12 .
Решение 9,9
• Предмети за физички податоци: Пакет за прифаќање (ова е понуда за заем на хартија), договор за
отплата (ова го потпишува апликантот на хартија и е заменет со резимето на Договорот, електронски
документ кој содржи линк до дигитализирана копија на договорот за отплата плус повикување на
апликацијата за заем). Претпоставуваме дека сите други комуникации помеѓу апликантот и давателот на
заем се случуваат преку е-пошта
• Пораки со физички предмети: Пакет за прифаќање, договор за отплата, понуда за домашно осигурување
(понудата се испраќа на хартија)
• Продавници за податоци: Правила за ризик ДБ
• Состојби на објекти на податоци
• Базени и ленти
Решение 9,10
Забележете дека работната ставка од задачата „Потврдете го договорот за отплата“ автоматски исчезнува од заемот
на работната листа на овластениот работник доколку службеникот не го започне тоа во рок од две недели. Ова се случува
ако нарачателот не го прими договорот за отплата по пошта во тој рок.
Решение 9.11 Има смисла за задачите „Подготви пакет за прифаќање“ и „Испрати пакет за прифаќање“ што треба
да ги извршуваат со истиот кредит. Меѓутоа, задачата „Проверете дали е побарана понуда од дома за осигурување“
треба да се изврши помеѓу овие две задачи. Бидејќи не постои временска зависност помеѓу „Проверете дали е
побарано домашно осигурување“ и другите две задачи, можеме да го одложиме првото на „Праќање пакет за
прифаќање“ или да го парализираме со другите две задачи. На овој начин можеме да ги агрегираме двете
последователни задачи во „Подготви и испрати пакет за прифаќање“.
Решение 9.12 Решението е прикажано на сл. 9.13 .
1. Видови задачи: мануелната задача на овој процес е „Дискутирај за апликација“. Ова може да се примени како
корисничка задача што ја комплетира со производство на препорака.
2. Неизвршни елементи: сите елементи можат да бидат толкувани со BPMS. Забележете дека настанот за
примање пораки „Одговор добиен преку пошта“ претпоставува постоење на внатрешна услуга кај
давателот на услугата што го известува процесот кога одговорот е примена по пошта.
3.1. Недостасува контрола на долгови: Задачата „Креирај електронски одговор“ е потребна за да се претвори одговорот
добиен по пошта во електронска верзија што може да ја консумира BPMS. Задачата „Одговори за проценка“
може да биде прекината со барање за откажување на апликацијата, за што процесот е прекинат. Ова барање
исто така може да биде примено за време на приемот на приемот, во кој случај задачите „Испратете понуда“ и
„Апликација за датотека“ треба да бидат компензирани. Додаден е седмичен рок за добивање на одговорот.
3.2. Недостигаат податоци: сите предмети за електронски податоци недостасуваат во концептуалниот модел.
4. Ниво на грануларност: задачата „закажете состанок“ е разделена за да ја моделира експлицитно задачата за
известување на клиентот за резултатот. Слично на тоа, „Испратете понуда“ и „Испратете одбивање“ се
расчленети за моделирање на подготовката на понудата, соодветно на писмото за одбивање. Со оглед на тоа
што „Испрати понуда“ е поделена на две активности („Направете понуда“ и „Испратете понуда“) секоја треба да
се компензира доколку се добие барање за откажување.
Решение 9.13 Потребни ни се две интерфејси за услуги за да комуницирате со веб услугата зад веб-страницата
на давателот на заем. Едниот интерфејс каде давателот на заем делува како давател на услуга, а другиот каде
што веб-услугата дејствува како давател на услуга. Поранешниот интерфејс содржи единствена операција за
давателот на заем да ја добие првичната апликација за заем. Вториот интерфејс ги содржи следниве четири
операции за услугата на веб-страницата:
• интер-операција за примање на проценетата апликација за заем (содржи барања за промена) и да

одговори со ревидираната апликација за заем (каде се направени промени)
Сл. 9.13 Моделот за процес на продажба на давателот на услугата B2B, комплетиран со контролата на исчезнатите и податоците
релевантни за извршување
• единствена операција за примање на одбиената апликација за заем
• единствена операција за добивање на одобрено или откажано барање за заем
Четирите операции погоре бараат вкупно пораки, сите со ист тип на податоци како и апликацијата за заем. Овие
операции се доделени на настанот за почетна порака, четирите задачи за испраќање и задачата за примање на
процесот, кои треба да имаат соодветни влезови и излезни податоци за да ја содржат апликацијата за заем.
Мапирањето на овие влезови и излези со податоци до објекти за податоци е јасна, освен задачата за испраќање
„Одбијте апликација“, која треба да го измени статусот на апликацијата за заем на „отфрлена“ при копирање на овој
предмет за податочен податок во внесувањето на податоците за задачите.
Потребен е трет интерфејс за услуга за да комуницирате со услугата за проценка на ризиците на заемот во
задачата „Оценете го ризикот на заемот“. Овој интерфејс има внатрешна операција со две пораки: влезна порака
што содржи извештај за кредитна историја и излезна порака за проценка на ризик.
Сценариото за задачата „Проверете ја комплетноста на формуларот за аплицирање“, зема заем за
апликација како влез и проверува дали се присутни сите потребни информации. Во зависност од исходот од
проверката, тој го менува статусот на апликацијата во „целосен“ или „нецелосен“, му доделува идентификација на
пријавата на апликацијата ако е празна, го пишува датумот и времето на поднесување или ревизија и, доколку е
применливо, ќе го објави статусот делот за коментари со покажувачи за нецелосни податоци fi стари лица.
Задачата за скриптата „Проверете дали е потребен понуда за домашно осигурување“ всушност не е потребна.
Додека во деловно ориентиран модел важно е експлицитно да се фати секоја одлука со активност како што
илустриравме во Поглавје. 3 , во извршна манекенка, тоа може директно да се вгради во услови на појдовни лаци
на (X) ИЛИ-Сплит, ако исходот од решението може лесно да се провери. Всушност, нашиот пример бара само да
ја провериме вредноста на еден човек во апликацијата, што може да се постигне со израз XPATH директно на
лакот со ознака „баран понуда“.
Сите задачи на корисниците на овој процес се спроведуваат преку управувачот со работната листа на давателот
на заем и им се нудат на учесниците кои ја имаат потребната улога (на пр. Задачата „Оцена за подобност“ се нуди на
учесник со квалификуван заем). Оваа имплементација зависи од усвоениот BPMS. Мапирањето помеѓу предметите на
податоци и влезните податоци и излезите за овие задачи е директна. Во случај на задача „Оцени подобност“, на време
на траење на заемот на овластениот персонал ќе се види електронска форма за апликација за заем (може да се
уредува), и уште два форма за проценка на ризик и проценка на имот (не може да се уредува). Од службеникот се
бара да ја уредат апликацијата за заем со внесување на нивните идентификатори, наведувајќи дали апликантот има
право на заем и додава коментари за статусот во случај на неподобност. Другите задачи на корисниците работат
слично.
Веќе разговаравме како да се имплементира состојбата на „бараниот понуда на лакот“ од лакот.

Условите од другите секвенци задачи може да се применат со израз кој извлекува податоци од податочен
предмет на сличен начин. Изразот за лакот означен како „секогаш“ е едноставно „вистински“ затоа што овој
лак се зема секогаш. Временскиот израз за двата настани на тајмер е едноставно релативно траење (5
дена и 2 недели).
Решение 9.14 Ова е практична вежба, не се дава решение. Извори поврзани со процесите на
спроведување, над специфичните BPMS, може да се најдат на веб-страницата за придружници http://fundamentals-of-bpm.org
.
9.7 Понатамошни вежби
Вежба 9.15 Нацртајте ја архитектурата на BPMS и идентификувајте ги сите нејзини компоненти.
Вежба 9.16 Објаснете ги сличностите и разликите помеѓу системите за производство и adhoc работа. Вклучете во
вашето образложение образложение за видот на поддршката што тие ја даваат од една страна и нивната
ориентација во спектарот на податоци наспроти процесот од друга страна.
Вежба 9.17 Класифицирајте ги следниве цели на различните организации опишани кои користат
БПМС и користете ги категориите објаснети во секцијата. 9.2 .
• Правна компанија сака да ги следи сите учесници што ги вклучила во својот официјализиран процес за
подготовка на предмети за парница.
• Владина агенција сака да ги намали казните што мора да ги плати за задоцнети плаќања на фактури.
• Банката сака да му покаже на својот надворешен ревизор дека строго го применува принципот дека секој
голем заем е одобрен од два одделни службеници.
Вежба 9.18 Во објавувањето во 2009 година на „LinkedIn“, директорот на Волгринс, аптека преку Интернет, прашува
кои се честите стапици при спроведувањето на системот за управување со работата. Консултант на Мајкрософт
одговара на следниов начин:
Навистина е за луѓето што купуваат во системот. Општата тенденција на луѓето е дека не сакаат промени, дури и ако
велат дека прават. Дури и ако нивните тековни процеси се многу несоодветни, тие знаат како функционира. Значи, кога ќе
воведете нешто што го менува нивниот свет (со работен систем мгт), тие ќе бидат многу внимателни. Исто така, колку
повеќе системот го менува начинот на кој ја вршат својата работа, толку поголем отпор ќе добиете. Тогаш станува
проблем за тоа како ги собравте вашите деловни барања. Шансите се дека поради недоразбирањата, барањата ќе бидат
различни од очекувањата за тоа како треба да се завршат работите. Објаснете дали мислите дека ова објаснување се
однесува на технички или организациски предизвик.
Вежба 9.19 Идентификувајте го типот на задачите на Сл. 4,15 и ги претставуваат со користење на соодветни маркери
BPMN.
Вежба 9.20 Разгледајте ги следниве деловни процеси. Идентификувајте кој од овие модели може да биде автоматизиран
и да го оправдате вашиот избор.
1. Вработување нов војник.

2. Организирање на судско рочиште.
3. Купување на ставка на аукција на еБај.

Сл. 9.14 Процесниот модел на FixComp за постапување со поплаки
4. Управување со расположливоста на средствата за залихи.
5. Резервација патување преку Интернет.
6. Ракување со работа за одржување на ИТ-системот.
7. Сервисирање на користен автомобил кај механичар.
8. Изработка на царински декларации за трговија преку Интернет.
9. Обработка на плати на вработените.
10. Синхронизирање на серверите за податоци во дистрибуирана околина.
Вежба 9.21 Слика 9.14 го покажува моделот на процеси што го следи FixComp кога клиентот поднесува
тужба. По приемот на нова поплака од клиент, процесот започнува со испраќање на автоматски одговор
на клиентот, со цел да ги увери дека фикс-компаксот следи по нивно барање. Претставник на
претставки потоа ја разгледува жалбата на дискусија со луѓе во одделот за кој се однесува жалбата.
Следно, претставникот на жалбите испраќа лично писмо со извинување до клиентот и им предлага
решение. Клиентот може да го прифати или одбие решението. Доколку клиентот го прифати решението,
решението го извршува релевантниот оддел. Ако клиентот го одбие решението, клиентот се повикува
на телефон да разговара за можните алтернативи од страна на претставникот на жалбите. Ако ветува
една од овие алтернативи, се дискутира со одделот и процесот продолжува. Ако не може да се постигне
договор, случајот е изведен пред суд.
Компанијата сака да го автоматизира овој процес за да се справи со поплаките на поефикасен начин. Ваша
задача е да го подготвите овој модел за извршување.
Признание Оваа вежба е прилагодена од слична вежба развиена од Ремко Дијкман, Универзитет
за технологија на Ајндховен.
Вежба 9.22 Размислете за постапката за постапување побарувања моделирана на сл. 9.15 . Спроведување на овој
деловен процес користејќи BPMS по ваш избор.
Процесот започнува кога клиентот поднесува ново побарување за осигурување. Секое побарување за осигурување
поминува низ двофазен процес на проценка. Како прво, се утврдува одговорноста на клиентот. Второ, побарувањето се
проценува со цел да се утврди дали друштвото за осигурување треба да ја покрие оваа одговорност и во која мерка. Ако
побарувањето е прифатено, се започнува плаќањето и му се советува на клиентот за износот што треба да се плати.
Сите активности, освен „Иницирање на исплата“, ги извршуваат сопственици на побарувања. Постојат три ракувачи на
побарувања. Активноста „Иницирање на исплата“ се извршува со финансиски овластувања. Постојат две финансиски
трошоци.
Сл.9.15 Модел на постапување со побарувања
Како што е прикажано во моделот, во овој процес се вклучени два објекти со податоци: Одлука за побарување и побарување.
Побарувањето ги вклучува следниве главни податоци:
• Име на тужител
• Политички број (низа со алфанумерички знаци)
• Опис на побарувањето
• Износот тврден
Одлуката за побарување се состои од следниве податоци:
• Упатување на побарување
• Одлука (позитивна или негативна)

• Објаснување
• Износот што треба да се надомести (поголема од нула ако одлуката е позитивна) Може да додадете други податоци s
стари лица во горенаведените предмети, доколку сметате дека е потребно.
Вежба 9.23 Разгледајте го следниот процес на изнајмување опрема, што е варијанта од оној опишан во
Пример 1.1 . Спроведување на овој деловен процес користејќи BPMS по ваш избор.
Процесот на изнајмување започнува кога еден инженер на страници ќе побара барање за изнајмување опрема што ги содржи
следниве детали:
• Име или идентификација на инженерот на страницата што го иницира барањето
• Побара датум и време на започнување на изнајмување на опрема
• Очекуван датум на завршување и време на изнајмување на опрема
• Проект за кој се изнајмува опремата

• Градежно место каде ќе се користи опремата
• Опис на потребната опрема
• Очекувани трошоци за изнајмување на ден (по избор)
• Претпочитан добавувач (по избор)
• Референтен број на опрема на добавувачот (по избор)

• Коментари до добавувачот (по избор)
Барањето за изнајмување го презема еден службеник во складиштето на компанијата. Службеникот се
консултира со каталозите на добавувачи на опрема и повикува или испраќа електронска пошта до добавувачот (а) со
цел да се обезбеди најисплатлива достапна опрема што е во согласност со барањето. Откако службеникот ќе најде
соодветно парче опрема достапен за изнајмување, тие препорачуваат да се изнајми. Во оваа фаза службеникот мора
да ги додаде следниве податоци на барањето за изнајмување на опрема:
• Избран добавувач
• Референтен број на избраната опрема
• Цена на ден
Барањата за изнајмување опрема треба да бидат одобрени од инженер за работи (кој исто така работи во
складиште). Во некои случаи, инженерот за работи го отфрла барањето за изнајмување опрема, што значи дека
нема да се ангажира опрема. Се разбира, пред да одбиете барање на овој начин, инженерот за работи најпрво
треба да разговара за нивната одлука со инженерот на страницата и, исто така, да додаде објаснување до
барањето за изнајмување на опрема. Во други случаи, инженерот за работа ја отфрла препорачаната опрема (но
не и целото барање) и бара од службеникот да најде алтернативна опрема. Повторно, во овој случај работничкиот
инженер треба да ја достави својата одлука до службеникот и да додаде објаснување.
Барањата за изнајмување каде цената на ден е под 100 се автоматски одобрени, без да поминувате
низ инженер за работи.
Откако ќе биде одобрено барање, нарачката за набавка автоматски се генерира од податоците содржани во
одобреното барање за изнајмување. Нарачката за набавка вклучува:
• Идентификација на опрема на добавувачот
• Цена на ден
• Градежно место каде ќе се испорача фабриката
• Датум и време на испорака
• Датум и време на подигнување
• Коментари до добавувачот (по избор)
Добавувачот ја доставува опремата до градилиштето на потребниот датум. Инженерот на страницата

ја прегледува опремата. Ако сè е во ред, тие ја прифаќаат опремата, додајте го датумот на испорака на
нарачката и по избор на белешка за да ги наведете сите проблеми откриени за време на инспекцијата.
Слично на тоа, кога опремата ќе ја собере снабдувачот на крајот на периодот на изнајмување, се
извршува друг увид, а добавувачот го означува датумот за подигнување во нарачката (можеби со
белешка за пик).
Понекогаш, инженерот на страницата бара продолжување на периодот на изнајмување. Во овој случај, инженерот на
страницата го запишува продолженото време за подигнување во нарачката, а ревидираната нарачка за нарачка
автоматски се нанесува на добавувачот. Пред да се направи оваа промена, инженерот на страницата се очекува да го
повика добавувачот за да се согласи за промена на датумот за подигнување.
Неколку дена по прибирањето на опремата, снабдувачот испраќа фактура до службеникот преку е-пошта.
Службеникот ги запишува следниве детали:
9.8 Понатамошно читање 351
• Детали за добавувачот
• Број на фактура
• Број за нарачка
• Референтен број на опрема
• Датум и време на испорака
• Датум и време на подигнување
• Вкупен износ што треба да се плати
Внесувајќи ги овие детали за фактурата, службеникот ги верификува деталите за фактурата против нарачката и
ја означува фактурата како прифатена или одбиена. Во случај на одбивање, службеничката додава објаснувачка
белешка (на пр. Барање од добавувачот да испрати ревидирана фактура). Конечно, снабдувачот може да испрати
ревидирана фактура ако е потребно.
Прифатената фактура е доставена до одделот за финансии за плаќање, но овој дел од

процесот се постапува одделно и не е дел од оваа вежба.
Вежба 9.24 Деновидни соодветни типови на податоци за процесот на продажба прикажани на сл. 9.13 и спроведете
го со користење на BPMS по ваш избор.
Вежба 9.25 Детални соодветни типови на податоци за процесот прикажан на сл. 4,32 -
4,34 и спроведете го од гледна точка на BestLoans користејќи BPMS по ваш избор.
9.8 Понатамошно читање
Книгата на Ван дер Алст и Ван Хе [ 95 ] нуди вовед во технологијата на управување со работењето, од
раните 2000-ти. Во тек е еволуцијата од системите за управување со работата до BPMS, што се случи во
текот на 2000-тите, во должина дискутирана од Веске [ 106 ] Како што е наведено во ова поглавје,
референтниот модел WfMC беше инструментален во обликувањето на архитектурите на системите за
управување со работата и подоцна на BPMS. Детали за референтниот модел WfMC можете да ги најдете
на
http://wfmc.org/reference-model.html додека Холингсворт [ 34 ] дава преглед на развојот и насоките
на овој референтен модел.
Честа критика на БПМС е дека тие следат фордистичка парадигма, што значи дека БПМС ги
присилува учесниците да дејствуваат во одредена насока, т.е. точно во начинот на кој се заробени во
процесниот модел. Во контекст на процесите каде што неочекуваните исклучоци се вообичаени и кога не
постои предвидлив начин за изведување на процесот, БПМС често завршува со попречување на работата
на учесниците во процесот, наместо да ги поддржува. Пристапи за поддршка на нестандардизирани или
непредвидливи процеси се опишани од страна на Reichert et al. [ 69 ] Еден од тие пристапи е постапување
по случаи, како што беше дискутирано во Поле „Видови на БПМС“. Вовед во оваа тема дава Ван дер Алст
и сор. [ 96 ], додека посеопфатниот третман на оваа тема го дава Свинсон [ 91 ]
Дискусија за извршна БПМН 2.0 е дадена во книгата Сребрена [ 87 ], како и во книгата на Френд и
Ракер [ 19 ] Длабоко покривање на автоматизацијата на процесите користејќи го YAWL јазикот, дава
тер Хофстеде и др. [ 92 ]
Нежен вовед во XML, XML шемата и XPath може да се најде во книгата на Милер и Шварцбах [ 56
] Во меѓувреме, темата за веб-услугите е детално опфатена од Ерл и сор. [ 17 ] Последната книга
исто така вклучува и дискусија за WSDL
2.0 — стандардната технологија за спроведување на интерфејси за услуги во BPMN 2.0.
Поглавје 10
Процесна интелигенција
Ако не можете да измерите нешто, не можете да го разберете. Ако не можете да го

разберете, не можете да го контролирате. Ако не можете да го контролирате, не можете да го
подобрите.
Х. ејмс Харингтон (1929–)
Тоа е централна идеја на БПМ дека процесите се експлицитно дефинирани, потоа извршени, и дека информациите за
извршувањето на процесите се подготвени и анализираат. На овој начин, оваа информација обезбедува јамка за
повратна информација за тоа како може да се редизајнира процесот. Податоците за извршување на процесите можат да
произлезат од BPMS, во кои специфичните процеси се специфични, но исто така и од системи што не работат со
експлицитен модел на процеси, на пример, ERP системи или системи за билети. Податоците од тие системи треба да се
трансформираат за да се исполнат барањата за интелигентна анализа за извршување на процесите. Ова обично се
нарекува рударство на процеси.
Ова поглавје се однесува на интелигентно користење на податоците генерирани од извршувањето на процесот. Ние
се повикуваат на таквите податоци како дневници за настани, кои опфаќаат што е направено кога од кого во врска со кој
пример на постапката. Прво, ја испитуваме структурата на дневниците на настани, нивната поврзаност со моделите на
процеси и нивната корисност за следење и контролирање на процесите. Потоа, разговараме за три главни цели на
интелигентна анализа на процесите, имено транспарентност, перформанси и сообразност. Разговараме за автоматско
откривање на процесите како технички чекор за да се постигне транспарентност за тоа како процесот се извршува во
реалноста. Потоа, проучуваме како анализата на дневниците за настани може да обезбеди увид во перформансите на
процесите. Конечно, разговараме за тоа како може да се провери сообразноста помеѓу дневниците на настани и моделот
на процеси.
10.1 Извршување процеси и дневник на настани
Во претходното поглавје, проучувавме како може да се специфицира процесниот модел на начин што BPMS може да го поддржи
неговото извршување. И учесниците во процесот и сопствениците на процесите се вклучени во извршувањето на деловните
процеси. Сепак, нивната перспектива е сосема поинаква. Учесниците во процесот работат на задачи, кои произведуваат податоци
за извршување како страничен производ. Ги повикуваме овие податоци логови на настани. Сопствениците на процеси се особено
заинтересирани за извлекување заклучоци од дневниците на ваквите настани. Во овој дел, разговараме за тоа
М. Думас и др., Основи на управување со деловните процеси, 353

ДОИ 10.1007 / 978-3-642-33143-5_10 , © Springer-Verlag Berlin Heidelberg 2013
354 10 интелигенција на процеси
на прашањата може да се одговори со употреба на податоци за настани и како логовите на настани и моделите на процеси се
поврзани едни со други.
10.1.1 Перспектива на учесниците за извршување на процесите
Кога еден процес се извршува на BPMS или на друг дел од софтверот, постои јасна поделба помеѓу
координацијата и извршувањето на задачите. Системот обично се грижи за координирање на одделни
случаи, информирајќи ги учесниците за кои задачи треба да работат. Според тоа, учесниците често ги
гледаат само оние задачи за кои тие се директно одговорни, додека системот ја крие комплексноста на
целокупниот процес. Секој учесник обично има лична личност работна листа што го покажува множеството
на
работни артикли на кои сè уште треба да се работи. Доколку постои експлицитен модел на процеси, секоја од овие
работни задачи одговара на задача во моделот на процеси. Како и да е, може да постојат повеќе работни артикли што
одговараат на единствена задача ако во моментот се работи на неколку случаи. На пример, во одредена временска
точка, Чак како учесник во процесот може да види дека четири работни артикли се во неговата работна листа, сите што
се однесуваат на задачата „Усогласен ред“ на постапката за завршување на нарачката: една работна ставка се
однесува на нарачка од клиент А, еден од клиентот Б, и двајца од клиентот Ц.
Структурата на работната ставка е дефинирана во моделот на извршна постапка или директно

имплементиран во софтверот. Ова значи дека учесниците ги гледаат старите податоци што се декларирани
како влез за некоја задача. За секоја работна ставка на која работат, тие треба да го документираат барем
завршувањето. На овој начин, системот може да ја следи состојбата на процесот во кој било момент. Меѓу
другите, лесно е да се снима во кој момент на време некој започнал да работи на работна ставка, кои
влезни податоци биле достапни, какви излезни податоци биле создадени и кој бил учесник што работи на
тоа. На пример, кога Чак го потврдил редоследот на клиентот
Б, тој го внесува резултатот во системот и системот може автоматски да одлучи дали следната фактура треба
да се испушти или потврдата за нарачката да биде ескалирана на некој над Чак. Повеќето BPMS и други
информативни системи снимаат такви податоци за тоа што е направено во кој момент. Функцијата во која се
чуваат овие податоци се нарекува a лог, а податоците во него се нарекуваат логови на настани. Секој пат кога
ќе заврши друга задача, се додава нов запис во дневникот. Односно, откако Чак ги внел своите податоци,
системот додава линија во дневникот, во кој се наведува дека Чак извршил налог со соодветна временска
ознака.
10.1.2 Перспектива на сопственикот на постапката за извршување на процесите
Дневниците за настани имаат потенцијал да откриваат важен увид во управувањето со тоа како функционира еден процес во
реалноста. Затоа, сопственикот на процесот е најзаинтересиран да го анализира на систематски начин. Во суштина,
разликуваме три главни сценарија за апликација за користење на дневник на настани: автоматско откривање на процесите,
анализа на перформанси и проверка на сообразност, сите поврзани со прашања што може да ги постави сопственикот на
процесот.
10.1 Извршување процеси и дневник на настани 355
Кој е вистински модел на процеси? Автоматското откритие на процесот е загрижено

со прашањето како еден процес всушност работи во реалноста. Во погл. 5 , споменавме дека трупците за настани може
да се користат како влез за откривање на процеси засновани врз докази. Автоматското откритие на процесите ги
користи дневниците за настани за генерирање на соодветниот модел на процеси. На овој начин, дневниците за настани
се вредни за да се воспостави процес на модел каде што претходно не постоел модел и да се прилагоди постојниот
модел според тоа како навистина функционира тој процес.
Која е изведбата на процесот? Во погл. 7 , дискутиравме дека анализите на процесите, како што се анализата,
страдаат од фактот дека просечното време на циклус за секоја задача во моделот на процеси треба да се
процени. Исто така, честопати се потребни силни претпоставки така што однесувањето на процесот не е
засегнато од товарот. Користејќи дневници за настани, ние сме во состојба да го провериме вистинското
однесување на еден процес и да го споредиме со увид од анализата на процесите. Понатаму, историските
информации за извршувањето на процесите можат да се искористат за донесување оперативни одлуки.
Во која мерка се следат правилата на моделот на процеси? Сообразност

проверка е збирка техники кои споредуваат збир на дневник на настани со збир на ограничувања или
постоечки модел на процеси. Постојат ситуации кога моделите на процеси се дефинирани, но не се
спроведуваат строго од соодветниот БПМС. Во овие ситуации, проверката на сообразност може да се
искористи за да се утврди колку често процесот се извршува како што се очекуваше и, ако не, во кои фази
може да се најдат отстапувања. Еве, дневниците за настани помагаат да се разбере или каде моделот
треба да се коригира или каде треба да се прилагоди однесувањето на учесниците кои работат во
процесот.
Овозможувајќи одговори на овие три типа на прашања, можеме да добиеме увид во процесот, што може да помогне
да се репозиционираат во Adаволски четириаголник. Поточно, димензијата на времето се зголемува во транспарентноста
со испитување на дневник на настани: временските ознаки покажуваат кога се извршуваат задачите и колку време трае.
Исто така, постои силна поврзаност со трошоците ако работното време на учесниците кои работат во процесот може да се
додели на одреден процес на пример. Флексибилноста може да се анализира врз основа на различните патеки што ги
презема процесот. Историскиот сет на всушност користени патеки и нивната разновидност дава индикација за оваа
димензија. Конечно, исто така, може да се идентификуваат квалитетни проблеми од дневниците на настани, на пример
кога ќе се провери бројот на повторувања и повторувања што се потребни за специфична задача.
Сопственикот на процесот може да користи записи на настани како влез во два различни механизми за
контрола: на агрегирано ниво и на пример. Механизмите се нарекуваат
контролирање на процесите и следење на процесите, соодветно.
Контрола на процеси се занимава со анализа на извршување на историски процеси. Во-

ставени за контрола на процесите се дневници за настани што се однесуваат на одреден временски
период, на пример четвртина или цела година. Контролата на процесите обезбедува увид дали се
исполнети општите цели на еден процес и дали КПИ се во согласност. Обично, контролата на процесите е од
fl ине активност, која вклучува дневници за завршени егзекуции на процеси.
Следење на процесите е загрижен за квалитетот на тековно водење на процесот

ставови Влез за мониторинг на процесите се дневниците на настани на поединечни случаи или случаи на
процеси. Мониторингот на процесите работи со цели и правила што се формулирани за овие поединечни
случаи и предизвикува спротивности кога се кршат овие правила, на пример, кога барањето на клиентот не
одговара на време. Обично, следењето на процесите е континуирано на Интернет активност која вклучува
настани во моментите кои работат во моментот.
И мониторингот на процесот и контролирањето на процесите играат важна улога во усогласувањето на процесот
со целокупните деловни цели. Во тој поглед, тие се тесно поврзани со идеи за управување со квалитетот и циклусот
план-да-провери (PDCA). PDCA може да се смета како инспирација за концептот на животниот циклус за управување
со деловните процеси, како што е дискутирано во првото поглавје на оваа книга. Следење и контролирање на
процесите (проверка) ги испитува податоците од извршните процеси (не) така што може да се преземат мерки за
редизајн (акт) за пренасочување на извршувањето со целите (планот). Сите овие концепти ја инспирираа идејата за
а процес на кокпит како софтверска алатка каде што податоците за извршувањето на процесите се обезбедуваат
преку Интернет со помош на графикони и соодветна визуелизација (види Сл. 9,4 на пример). Честопати, овие алатки
се нарекуваат и алатки за деловна активност за мониторинг (БАМ) или алатки за мерење на ефикасноста на
процесот (ППМ).
10.1.3 Структура на дневник
Следењето и контролата на процесите силно се потпираат на податоците за настаните што треба да се

евидентираат за време на извршувањето на процесите. Дневници за настани содржи збир на настани. Според
тоа, можеме да разбереме дневник на настани како список на снимки од настани. Слика 10.1 дава илустрација за
тоа што податоците обично се чуваат во дневници за настани. Можеме да видиме дека еден настан има
единствена лична карта за настани. Понатаму, се однесува на еден поединечен случај, има одреден рок, и
покажува кои ресурси се извршени кои задачи. Овие можат да бидат учесници (на пр. Чак и Сузи) или софтверски
системи (SYS1, SYS2, DMS). За неколку техники за анализа што ќе ги разгледаме во ова поглавје, тоа е
минимален услов настаните во дневникот да се однесуваат на (i) еден случај, (ii) една задача и (iii) точка на
време. Имајќи ги овие три парчиња информации, можеме на пример да откриеме процес на моделот од
дневниците. Во пракса, честопати има дополнителни информации зачувани за секој настан, како што се
трошоците, системот што се користи или податоци за случајот со кој се постапува. Овие можат да се користат за
групирање,
Дневникот на настани на Сл. 10.1 е заробен како список во табеларен формат. 1 Проблемот со дневниците на настани е
што секој продавач и софтверски систем креира индивидуални формати на дневник. Со цел да се искористи донесувањето на
алатки за анализи на дневник, како што се отворено
1 За едноставност, ние сметаме само еден снабдувач во овој пример.

Сл. 10.1 Пример за дневник на настани за завршување на нарачката
изворна алатка ProM, 2 на IEEE Task Force за рударство на процеси промовира употреба на eXtensible тек на настани
(XES) формат. Неколку алатки работат со логови на настани XES или нудат карактеристики за да ги претворат
дневниците на настани во овој формат. Метамоделот на XES е прикажан на Сл. 10.2 . Секој XES represents претставува
лог. Содржи повеќе траги и секоја трага може да содржи повеќе настани. Сите тие можат да содржат различни атрибути.
Атрибутот треба да биде или низа, датум, инт, овес или булен елемент како пар за клучна вредност. Атрибутите треба
да се однесуваат на глобалното определување. Постојат два глобални елементи во XES, le, еден за утврдување на
атрибути во трагови, а другиот за атрибути за утврдување настани. Неколку класични класи може да се дефинираат во
XES. Класификацијата мапира еден од повеќе атрибути на настанот на етикетата што се користи во излезот на алатката
за анализа. На овој начин, на пример, настаните можат да бидат поврзани со активности.
2 Софтверот е достапен на http://www.promtools.org .

Сл. 10.2 Метамодел со формат

XES
Сл. 10.3 Пример за in le во

форматот XES
Слика 10.3 покажува како делови од информациите за пример на дневник на настани од Сл. 10.1 може да
се чува во XES fi ле. Од првиот „глобален“ елемент (опсег = „трага“), гледаме дека во секој елемент во трагови
се очекува да има атрибут „концепт: име“. За трагата дефинирана подолу, овој атрибут има вредност 1. Покрај
тоа, постојат три различни атрибути што се очекуваат за некој настан („глобален“ елемент со обем = „настан“):
„концепт: име“, „време: временска ознака“ и „Ресурс“. Во трагата, прикажана подолу, забележуваме два
настани. Првиот се однесува на „Проверете ја достапноста на акциите“,
која беше комплетирана од SYS1 на 30 јули 2012 година во 11:14 часот. Вториот настан го доловува „Извлечи
производ од магацин“ што го спроведе Рик во 14:20 часот.
10.1.4 Предизвици во извлекувањето на дневник на настани
Податоци за настани што се достапни во некој табеларен формат како што се визуелизирани на сл. 10.1
може лесно да се претворат во XES, а потоа да се анализираат со употреба на соодветни алатки. Во многу случаи, сепак,
податоците што се релевантни за најавите на настани не се директно достапни во потребниот формат, но мора да бидат
извлечени од различни извори и да бидат интегрирани. Затоа, можеме да идентификуваме огромни предизвици за
екстракција на податоци од дневник, потенцијално бараат значителен напор во еден проект. Овие предизвици се:
1 Предизвик за корелација: Ова се однесува на проблемот со идентификување на случајот
настанот припаѓа на. Многу информациски системи немаат експлицитен поим за дефиниран процес. Затоа, ние
треба да испитаме кој атрибут на обработените субјекти може да послужи како идентификација на случајот.
Честопати, можно е да се користат идентификатори на ентитетите, како што се бројот на нарачката, бројот на
фактурата или бројот на пратката.
2. Предизвик на временските ознаки: Предизвикот да се работи правилно со временските ознаки произлегува
од фактот дека многу информациски системи не сметаат дека сечата е примарна задача. Ова значи дека
одјавувањето честопати се одложува додека системот нема време или нема оптоварување. Затоа, можеме да
направиме последователни настани со ист временски знак во дневникот. Овој проблем се влошува кога треба да се
интегрираат логови од различни информациони системи кои потенцијално работат во различни временски зони.
Делумно, ваквите проблеми можат да се решат со знаење за доменот, на пример кога се знае дека настаните
секогаш се случуваат во специфичен редослед.
3. Снимки на слики: Оваа точка се однесува на прашањето за достапност на податоците за најавите
за одреден временски период. За долготрајни процеси, можеби нема да можеме да ги набудуваме сите случаи на
дневникот со нивното целосно траење на крајот до крај во разгледуваниот период. Добра идеја е да се исклучат
вакви нецелосни случаи со глава или опашка што недостасуваат. Како и да е, треба да се има предвид дека таквото
влијание може да воведе пристрасност, на пример дека се разгледуваат само кратки случаи. Затоа, временскиот
распон што го прикажува дневникот треба да биде значително подолг од просечното времетраење на случајот.
4. Главен предизвик: Опсегот на спектарот на настани е предизвик кога

достапниот информативен систем не произведува директно дневници за настани. Информациските системи како
што се ERP системите бележат голема количина на настани поврзани со процесите во бројни табели. Дневниците за
настани треба да бидат генерирани од записите во овие табели, за што е потребно детално разбирање на
семантиката на податоците. Таквата експертиза во системот не може да биде достапна.
5. Предизвик за грануларност: Обично, ние сме заинтересирани за спроведување на дневник на настани
анализа на концептуално ниво за кое имаме дефинирани процесни модели. Во принцип, грануларноста на
снимањето на дневник на настани е многу пореална, така што секоја активност на моделот на процеси
може да мапира до низа настани. На пример, активност како „Враќање на производ од магацин“ на ниво на
апстракција на еден процес
мапи на мапи на серија настани како што се „Назначено за работна точка # 1.211 доделено“, „Работна ставка
# 1.211 започнаа “,„ Отворен образец за нарачка “,„ Пронајден производ “и„ Завршена работа број 1.211 “.
Честопати, не-грануларните настани можат да се појавуваат постојано во дневниците, додека на апстрактно
ниво се извршува само една задача. Затоа, тешко е да се дефинира прецизно мапирање помеѓу двете
нивоа на апстракција.
Вежба 10.1 Размислете за финалниот процес на склопување на „Ербас“ за нивната серија А380. Финалното
собрание на оваа серија на авиони се наоѓа на местото на производство во Тулуз, Франција. Големи делови се
носат со брод до Бордо и се носат во Тулуз со воден пат и патен транспорт. Кој е предизвикот кога податоците за
логирање на процесот на производство A380 треба да се интегрираат?
10.2 Автоматско откривање процеси
Автоматското откривање на процесите е специфична техника за рударство на процеси. Целта на автоматското откритие
на процесите е да се конструира процесен модел кој го фаќа однесувањето на настанот, на репрезентативен начин.
Конструкцијата е наменета да работи автоматски и генерички, користејќи алгоритам што треба да направи минимални
претпоставки за својствата на дневникот и резултатот од моделот на процеси. Да се биде репрезентативен во овој
контекст лабаво значи дека конструираниот модел на процеси треба да може да ги репродуцира случаите на дневникот
на настани и да забрани однесување што не се наоѓа во логовите. Во продолжение, ние прво ќе разговараме за
претпоставки за податоци за најавите, а потоа ќе ги презентираме а- алгоритмот како основен алгоритам за откритие и
подетално свртете кон поимот за репрезентативност.
10.2.1 Претпоставки на а- Алгоритам
На а- алгоритам е основен алгоритам за откривање на модели на процеси од дневници за настани. Основно е

бидејќи е помалку сложено од другите, понапредни алгоритми. Покрај тоа, прави одредени претпоставки за
дадените дневници за настани за кои подоцна ќе разговараме како делумно проблематични. Овие
претпоставки се следниве:
• Ред на настани: Настаните во дневникот се хронолошки нарачани. Таквиот хронолошки редослед може да се
дефинира врз основа на временските ознаки.
• Референца за случајот: Секој настан се однесува на еден случај.
• Референца за активност: Секој настан се однесува на специфична активност на процесот.
• Комплетност на активност: Секоја активност на процесот е вклучена во дневникот.
• Однесувањето комплетност: Дневникот е однесен полн со тоа што има активност а може директно
да се следи активност б, тогаш има најмалку еден случај во дневникот каде што набудуваме аб
10.2 Автоматско откривање процеси 361
Сл. 10.4 Дефинирање на дневник за работа
Првите три претпоставки се однесуваат на содржината на информации за еден настан во дневниците. Овие
претпоставки се прилично општи и неограничувачки. Критериум за комплетност на активност се однесува на фактот
дека можеме да ги вклучиме само овие активности во генерираниот процес на моделот што го набудуваме во трупците.
Комплетноста во однесувањето има најсилни импликации. Во пракса, тешко можеме да претпоставиме дека во
дневникот го наоѓаме комплетниот пакет опции за однесување. Напредните техники се обидуваат да направат послаби
претпоставки за оваа точка.
Во согласност со овие претпоставки, ние користиме т.н. работа ow log лог како почетна точка за користење на а- алгоритам.
Слика 10.4 покажува како евиденција за работа може да се конструира од дневник на настани. Во продолжение, ќе
работиме со писма како упатување на задачите. Дневникот за работа е збирка од сите уникатни секвенци на
извршување, забележани во дневникот. На а- алгоритмот не разликува колку често е забележана специфична секвенца
за извршување во дневникот за работа.
Вежба 10.2 Погледнете на Сл. 10.1 и преведете го во дневник за работа според истите правила за мапирање
како на Сл. 10.4 .
10.2.2 Односи со редот на а- Алгоритам
На а- алгоритмот работи во две фази со цел да се конструира процесен модел. Во првата фаза, различни
врски со редот се извлечени од дневникот за работа Л. Во втората фаза, процесниот модел е конструиран на
чекор по чекор од овие идентификувани односи. На со цел односите се однесуваат на задачи кои директно
се следат едни со други во дневникот. Таа дава основа за дефинирање на уште три специфични односи што
се однесуваат каузалност, до потенцијал паралелизам и до неследно. Ние се однесуваме на овој сет на
односи како а односи.
Сл. 10.5 Едноставна контрола -
должни обрасци
• Односот со основниот поредок а> б држи дали можеме да набудуваме во дневникот за работа Л тоа задача а директно е
проследено со б.
• Одредување каузалност а → б е изведен од основниот однос. Смета ако се забележиме Л тоа а>
б и тоа б > а.
• Односот на потенцијалниот паралелизам а ‖ б држи ако и двете а> б и б> а е забележано во дневникот за
работа Л.
• Односот без директна сукцесија а # б држи ако а ≯ б и б ≯ а.
Причината зошто се користат овие односи е прикажана на Сл. 10.5 . Има

Има карактеристични комбинации на односи помеѓу задачите во работата, дневник што може да се
прикаже на едноставни контроли.
Модел (а) прикажува низа задачи а и б. Ако ги моделираме на овој начин,

треба да се гарантира дека во дневникот за работа ќе го сториме а следен од б,
т.е. а> б, но никогаш б следен од а, т.е. б > а. Ова значи дека причинско-последична врска а → б треба да се одржи
Модел (б) исто така се однесува на карактеристична комбинација на односи. Работата е должна
дневникот треба да го покаже тоа а → б и а → в држете, и тоа б и в не би биле меѓусебни наследници т.е. б # в.
Модел (в) исто така го бара тоа б и в не би биле меѓусебни наследници т.е. б # в,
додека обајцата б → г. и в → г. треба да се одржи.
Модел (г) тоа го бара а → б и а → в држете, и тоа б и в покажуваат потенцијал

паралелизам, т.е. б ‖ в.
Модел (д) се однесува на б → г. и в → г. додека б и в покаже потенцијален паралелизам,
т.е. б ‖ в.
Идејата за а- алгоритмот е да се идентификуваат односите помеѓу сите парови на задачи од

дневникот за работа со цел да се реконструира модел на процеси заснован на Модели (а) до (д). Затоа,
пред примена на а- алгоритм, ние најпрво мораме
Сл. 10.6 Отпечаток

претставен како матрица на дневникот за
работа
L = [ < a, b, g, h, j, k, i, l 〉, 〈 a, c, d,
e, f, g, j, h, i, k, l 〉]
извлечете ги сите врски со основниот ред од дневникот за работа Л. Разгледајте го дневникот за работа
прикажан на сл. 10.4 ги содржат двата случаи < a, b, g, h, j, k, i, l > и
< a, c, d, e, f, g, j, h, i, k, l >. Од овој дневник на работата, можеме да ги извлечеме следниве односи.
• Односи со основниот поредок> се однесуваат на секој пар задачи што директно следат еден на друг. Може директно
да се прочита од дневникот:
а> бх> ј јас> л г> пр. j и> к

б> г> ка> в е> ѓ j> hk> l
g> hk> i c> df> gh> i
• Причинско-последичните односи можат да се најдат кога проверуваме за секој однос на редот дали не е
во спротивна насока. Ова се однесува на сите парови освен ( ч, ј)
и ( јас, к), соодветно. Добиваме:
а → бј → ка → ЦД → еф → дух → иб → г
јас → л в → де → fg → ј к→л
г→ч
• Потенцијалниот однос на паралелизам важи за ч ‖ ј како и за к ‖ јас ( и соодветните симетрични

случаи).
• Останатиот однос без сукцесија на правец може да се најде за сите парови кои не припаѓаат → и ‖.
Може лесно да се изведе кога ќе ги запишеме односите во матрица како што е прикажано на сл. 10.6
. Оваа матрица се нарекува и
матрица на стапало на дневникот.
Вежба 10.3 Погледнете во дневникот за работа што сте го конструирале во Вежба 10.2 . Деј ни ги односите>, →,
‖, # и матрицата за отпечатоци од оваа работа - дневник.
10.2.3 а- Алгоритам
На а- алгоритмот е основен алгоритм за автоматско откривање на процесите што се одвива во дневник на

настани Л и е а односите како појдовна точка. Основната идеја на алгоритмот е дека задачите што директно
следат еден на друг во дневникот треба да бидат директно поврзани во моделот на процеси. Покрај тоа, ако
има повеќе од една задача што може да следи по друга, треба да утврдиме дали збирот на последователни
задачи е делумно ексклузивен или истовремен. Исклучок од принципот дека задачите треба да бидат
поврзани во моделот на процеси, се оние кои се потенцијално паралелни, т.е. оние парови вклучени во ‖. Деталите
за а- алгоритмот се дефинира според следниве осум чекори. 3
1. Идентификувајте ги множествата на сите задачи во дневникот како Т Л.
2. Идентификувајте го сетот на сите задачи што се наб asудувани како прва задача во одреден случај, како што е Т Јас
3. Идентификувајте го сетот на сите задачи што се набудувани како последна задача во одреден случај како Т О.
4. Идентификувајте го збирот на сите врски што можат да бидат потенцијално застапени во процесот на модел како збир X Л. Додадете
ги следниве елементи на X Л:
а. Модел (а): сите парови за кои се одржи а → б.

б. Модел (б): сите тројки за кои држат а → ( б # в).
в. Модел (в): сите тројки за кои се одржи ( б # в) → г.
Забележете дека тројки за кои Модел (г) а → ( б ‖ в) или Модел (д) ( б ‖ в) → г.
држи не се вклучени X Л.
5. Конструирајте го сетот Ј Л како подмножество на X Л од:
а. Елиминирање а → б и а → в ако постои некои а → ( б # в).

б. Елиминирање б → в и б → г. ако има некои ( б # в) → г.
6. Поврзете ги почетните и крајните настани на следниов начин:
а. Ако има повеќе задачи во собата Т Јас од првите задачи, а потоа нацртајте почетен настан
што доведува до разделување (XOR или AND во зависност од односот помеѓу задачите), што се поврзува со секоја
задача во Т Јас Во спротивно, директно поврзете го почетниот настан со единствената прва задача.
б. За секоја задача во собата Т О од последните задачи, додадете завршен настан и нацртајте лак
од задачата до крајниот настан.

7. Конструирајте ги лаковите на следниов начин:
а. Модел (а): За секој а → б во Ј Л, нацртајте лак а до б.
б. Модел (б): За секој а → ( б # в) во Ј Л, нацртајте лак од а до поделба XOR,
и од таму до б и в.
в. Модел (в): За секој ( б # в) → г. во Ј Л, нацртајте лак од б и в до XOR-
придружи се, и од таму до г.
3 Забележете дека а- алгоритмот првично беше дезинфициран за изградба на мрежни мрежни мрежи. Верзијата што е прикажана овде е
поедноставување засновано врз patternsè едноставните контролни patterns обрасци на Сл. 10.5 со цел да се конструираат модели BPMN.
Сл. 10.7 Процес модел изработен од а- алгоритм од работа log ow log L = [ < a, b, g, h, j,
к, јас, л 〉, 〈 a, c, d, e, f, g, j, h, i, k, l 〉]
г. Модел (г) и (д): Ако некоја задача во така конструираниот процесен модел има повеќекратни влезни или
повеќекратни појдовни лаци, спакувајте ги овие лаци со AND-split или AND-join, соодветно.
8. Вратете го новоизградениот модел на процеси. Дозволете ни да зачекориме низ а- алгоритам со дневникот за
работа L = [ < a, b, g, h, j,
к, јас, л 〉, 〈 a, c, d, e, f, g, j, h, i, k, l 〉] како пример за влез. Чекорите 1–3 се идентификуваат
Т L = { a, b, c, d, e, f, g, h, i, j, k, l}, T Јас = { а}, и Т О = { }. Во Чекор 4а се додаваат сите причинско-последични односи X Л вклучително
и а → б и а → в, итн. Во Чекор 4б, работиме ред по ред низ матрицата за подножје на Сл. 10.6 и проверете дали
има клетки кои споделуваат a → однос додека се однесува на задачи што се во пар во #. Во редот а, ги
набудуваме и двете а → б и а → в. Исто така, б # в држи Затоа, додаваме а → ( б # в) до X Л. Ние, исто така, сметаме
дека ред г и нејзината поврзаност со ч и ј. Сепак, како ч ‖ ј држи, не ги додаваме. Во Чекор 4ц, напредуваме
колона по колона низ матрицата за подножје и гледаме дали има клетки кои делат a → однос додека се однесува
на задачи што се взаемно во #. Во колона г, набудуваме две → односи со б и ѓ. Исто така, б # ѓ држи Според тоа,
додаваме ( б # ѓ) → г до X Л. Ние исто така проверуваме јас и к кои ја делат истата врска л. Сепак, како јас ‖ к држи,
не ги додаваме. Нема дополнителни комплексни комбинации пронајдени во Чекор 4д.
Во чекор 5, ги елиминираме основните елементи во X Л кои се опфатени со сложените обрасци пронајдени во

чекорите 4б и 4ц. Според тоа, ние бришеме а → б, а → в, б → г,
и ѓ → г Во Чекор 6а воведуваме почетен настан и го поврзуваме а; во 6б, задача л е поврзан со завршен
настан. Во чекор 7, лаковите и портите се додаваат за елементите на Ј Л. Конечно, во Чекор 8 се враќа
процесот на моделот. Како резултат на моделот е прикажано на сл. 10,7 .
Сл. 10.8 Примери на две кратки јамки, кои се проблематични за а- алгоритам
Вежба 10.4 Погледнете во дневникот за работа и стапалото што сте го конструирале во вежби 10.2 и 10.3
. Документот напредува низ чекорите на а- алгоритм со овој влез и исцртување на добиениот процес на
модел.
10.2.4 Робусно откривање на процесите
Јасно е дека а- алгоритмот има свои заслуги. Може да го реконструира моделот на процеси од целокупниот
дневник на настани, ако тој дневник е генериран од структурен модел на процеси. Постојат и ограничувања
што треба да се забележат. На а- алгоритмот не е во состојба да разликува т.н. кратки јамки од вистински
паралелизам. Како што може да се види на сл. 10,8 , сите три модели можат да произведат логови на работа
што даваат б ‖ в во соодветниот подножје. Неколку екстензии на а- предложен е алгоритам. Идејата за α + - алгоритмот
е да се дефинира релацијата ‖ на построг начин таков
б ‖ в се вклучува само ако нема низа коцка во логовите. На овој начин, моделите (а) и (б) на Сл. 10,8 можат да се
разликуваат едни од други во нивните генерирани логови. Покрај тоа, можеме да користиме преработка, за да
извлечеме директно повторување како аа или бб
од дневниците, забележете ги соодветните задачи и продолжете со дневник од кој таквото повторено
однесување се мапира на едно извршување.
Понатамошни проблеми за а- алгоритми се нецелосност и бучава Поим за комплетност претпоставен од а- алгоритмот
се однесува на> однос од кој се изведени другите односи. Бројот на потребни различни случаи се зголемува со
факторот на бројот на потенцијално истовремени задачи. Честопати, овој број е мал. Но, веќе за 10 истовремени
задачи, потребни се 10! = 3, 628, 800 случаи. Затоа, пожелно е да се користат алгоритми кои можат експлицитно да
разликуваат веројатни и неверојатно однесување со цел да се генерализира кога логовите не се целосни. Оваа
насока помага и во решавањето на проблемите со бучава. Дневниците за настани често вклучуваат случаи со глава
што недостасуваат, опашка што недостасува или средно епизода што недостасува. Покрај тоа, може да има грешки
во логирање со настани што се менуваат или снимаат двапати. Ваквите неверојатно однесување не треба да го
нарушуваат резултатот од откривањето на процесот.
Разработени се неколку пристапи за решавање на проблемите со комплетноста и бучавата. Општо, тие се обидуваат да
балансираат четири основни критериуми за квалитет, имено, едноставност, едноставност, прецизност и генерализација. Фитнес
се однесува на степенот на однесување на дневниците што процесниот модел е во состојба да го повтори. Може да се
дефинира врз основа на дел од моделите на настани претставени од моделот или врз основа на дел од случаите што може
да се репризираат во моделот. Едноставност значи дека добиениот процес на модел треба да биде лесно разбирлив. Може
да се мери со употреба на различни метрика на сложеност за модели на процеси, како што се големината на моделот или
степенот на структуралност. Прецизност се однесува

10.3 Анализа на перформансите 367
до степенот на однесување што го дозволува моделот, но не е забележано во логовите. Можеме лесно да создадеме
процес на моделот кој овозможува извршување на сите задачи по кој било произволен редослед со потенцијално
повторување. Сепак, тешко можеме да научиме какви било специфики на процесот од таков модел. Генерализација се
однесува на можноста на процесниот модел да се апстрахира од однесувањето што е документирано во дневниците.
Техниката за откривање која е во состојба да генерализира, помага да се работи со нецелосно однесување.
Вежба 10.5 Нацртајте модел во BPMN со кој можете да ја репродуцирате секоја секвенца за извршување што
вклучува задачи a, b, c, d, e. Покрај тоа, разговарајте за сигурноста, едноставноста, прецизноста и генерализацијата
на таков модел за трага < a, b, c, d, e >.
10.3 Анализа на перформансите
Во секта. 7.1 ги воведовме четирите димензии на изведба на време, цена, квалитет и fl егзистентност. За
возврат, погл. 8 покажаа дека овие четири димензии формираат четириаголник на ѓаволот кога се
обидуваме да го подобриме процесот. Овие мерки за изведба обично се сметаат за генерално
релевантни за секаков вид деловно работење. Надвор од овој генерален пакет, една компанија исто така
треба да идентификува специфични мерки. Честопати, мерките се специфични за индустријата, како што
е проток на метар квадратен во гастрономијата, стапката на поврат во купувањето преку Интернет или
потрошувачот разбудувачки во маркетингот. Секоја специфична мерка што треба да ја дефинира
компанијата треба да биде точна, економична и лесно разбирлива. Овде, ние се фокусираме на четирите
општи мерки за изведба на време, трошоци, квалитет и. Егзистентност. Прашањето на овој дел е како
можеме да забележиме дека еден процес не функционира добро според една од овие димензии.
Дневниците за настани ни даваат детални податоци што се релевантни за перформансите.
10.3.1 Мерење на времето
Времето и неговите поконкретни мерки време на циклус и време за чекање се важни општи мерки за изведба. Дневниците
за настани обично покажуваат временски ознаки така што може да се користат за временска анализа. Анализата на времето
се однесува на временската појава и веројатноста за различни видови на настани. Дневниците на настани на еден процес,
генерално, се однесуваат на секој настан до моментот на неговото појавување. Затоа, директно е да се закажат настани на
временската оска. Покрај тоа, можеме да ги искористиме класификациите во групни настани од втора оска. Класификација
обично се однесува на еден од атрибутите на настанот, како лична карта или лична карта за учесник. Постојат два нивоа на
детали за зацртување настани во дијаграм: испреплетени графикони користење на временската ознака за да закажете
настан и временска рамка прикажување на времетраењето на една задача и времето на чекање.
Точката на графиконот е едноставна, но моќна алатка за визуелизација за дневник на настани. Секој настан е
исцртан на дводимензионално платно со првата оска што ја претставува својата

Сл. 10.9 Искористена табела со податоци за дневник
појава на време и втора оска како нејзина поврзаност со класификацијата како лична карта. Постојат различни опции
за организирање на првата оска. Времето може да биде претставено или релативна така што првиот настан се брои
како нула, или апсолутно така што подоцнежните случаи со подоцнежен настан се подолу во споредба со случаите
што започнале порано. Втората оска може да се подреди според различни критериуми. На пример, случаите можат
да бидат прикажани според нивниот историски редослед или целокупното време на циклусот.
Слика 10.9 ја покажува точката на графиконот на дневниците на процесот на здравствена заштита. Настаните се
исцртуваат според нивното релативно време и се сортираат според целокупното време на циклусот. Може да се види
дека постои значителна варијација во однос на времето на циклусот. Понатаму, графиконот сугерира дека може да
има три различни класи на случаи: оние што не траат повеќе од 60 дена, оние што одземаат од 60 до 210 дена и мала
класа на случаи кои траат подолго од 210 дена. Таквата истражувачка инспекција може да обезбеди добра основа за
подетална анализа на факторите во влијанието на времето на циклусот.
Вежба 10.6 Нацртајте исцртана шема на дневникот на настани на Сл. 10.1 покажува релативно време на циклусот и се подредува
според времето на циклусот.
Временската анализа на дневниците за настани може да се подобри со дополнителни детали ако е достапен
соодветниот модел на процеси и задачите можат да бидат поврзани со почеток и крај на настанот. Идејата е да се
искористи концептот на репродукција на токени за да се идентификува точката во времето кога задачата ќе се
активира. За задачи во низа, времето за активирање е точката во времето кога заврши претходната задача. За
задачите по AND-приклучување, ова е моментот кога ќе завршат сите претходни задачи. За XOR-приклучува и
разделува е точката кога ќе заврши една од претходните задачи.
Користејќи ги овие информации, можеме да нацртаме задача не како точка, туку како лента во временска рамка
(види Сл. 10.10 ) Временска рамка покажува време на чекање (од активирање до започнување) и време на обработка
(од почеток до завршување) за секоја задача. Временските рамки на секоја задача може да се визуелизираат на
сличен начин како точка во означена табела. Временската рамка е поинформативна од означената шема бидејќи го
покажува времетраењето на задачите. Покрај тоа, корисно е да се видат времето на чекање. И двајцата
Сл. 10.10 Временска рамка на податоци за дневник, како премиерот 232
дел од информациите се вреден придонес за квантитативна анализа на процеси. Кога илјадници случаи се достапни како
дневник, може да се процени распределбата на времето на чекање и времето за обработка на секоја задача. На овој
начин, може да се забележат тесните грла со долго време на чекање и, на сличен начин, задачи за кои најмногу ветуваат
дека ќе се фокусираат напорите за редизајн. Понатаму, овие информации може да се користат и за предвидување на
време на извршување на примероци на водење на процеси, што е корисно за следење на процесите.
Вежба 10.7 Пресметајте ги времето на чекање што е потребно со временска рамка за дневникот на настани на Сл. 10.1 користејќи
го процесниот модел на Сл. 10,7 .
10.3.2 Мерење на трошоците
Во контекст на процесите, мерењето на трошоците главно е поврзано со проблемот на доделување индиректни трошоци на
случаи. На крајот на краиштата, директно може да се утврдат директните трошоци, како што се трошоците за купување на четири
тркала, кои се собрани на автомобил. Индиректната работна сила или амортизацијата на машините се потешки. Во
сметководството, концептот на Трошоци засновани врз активност
( АБЦ) беше развиена за попрецизно доделување индиректни трошоци на производи и услуги и на

индивидуални клиенти. Мотивацијата на АБЦ е дека човечките ресурси и машини честопати се споделени од
различни производи и услуги, и тие се користат за да им служат на различни клиенти. На пример,
складиштето на BuildIT изнајмува скапи машини, како што се булдожери на различни градилишта. Од една
страна, тоа вклучува трошоци во однос на работното време на лицата кои работат во депо. Од друга страна,
машините како булдожери губат во вредност со текот на времето и бараат одржување. Идејата на АБЦ е да
се користат активности за дистрибуција на индиректните трошоци, на пр. Поврзани со депо.
Пример 10.1
Според сл. 1.6 во погл. 1 , процесот на изнајмување на BuildIT содржи огромни активности. Следниве траење ги
набудуваме во дневниците за настани за случајот за изнајмување булдожер побарано на 21 август:
• „Поднесете барање за изнајмување опрема“ го спроведува инженер за веб-страница. Потребно е инженерот 20 минути до
формата на хартија. Производството на секоја хартиена форма чини € 1. Инженерот на страницата добива годишна плата од € 60.000.
• Службеникот ја добива формата и избира соодветна опрема и ја проверува достапноста. Двете активности заедно
трае 15 минути. Службеникот работи со годишна стапка од € 40.000.
• Инженерот за работи го разгледува барањето за изнајмување (годишна плата од € 50.000). Овој преглед трае 10 минути.
• Службеникот е исто така одговорен за испраќање на договор, вклучувајќи нарачка за наем за изнајмување на
опрема, која трае 30 минути.
За да работиме со овие бројки, мора да направиме одредени претпоставки. Прво, во BuildIT вистинската работна
година содржи 250 работни дена од 8 часа. Покрај тоа, сите вработени добиваат здравствено осигурување и
пензиски придонеси од 20% над платата. Конечно, луѓето се во просек 10 дена на боледување годишно. Имајќи го
ова предвид, можеме да ја пресметаме цената на трудот на секој учесник во минута како плата × 120%
( 250 - 10) × 8 × 60. Ова е за страницата

инженер € 0,63 во минута, за службеникот € 0,42 во минута, а за инженер за дела
€ 0,52 во минута. Севкупно, овој случај создаде трошоци од 20 минути × € 0,63 во минута + (15 + 30) минути ×
€ 0,42 во минута + 10 минути × € 0,52 во минута, што е сума до € 36,70.
Сега разгледајте случај на процес на градење на улица. Ние ги набудуваме следниве траење од дневниците за настани за
овие две активности:
• „Подгответе ја фондацијата“ ја водат четворица работници. Помина една недела во специфичен случај за изградба.
Користените багери трошоци € 100.000. Тој е отпишан за неколку години и има годишни трошоци за одржување од € 5.000.
Работник добива годишна плата од € 35.000.
• „Трча патот“ го водат шестмина работници. Поминаа два дена во овој случај. Тарсинг машината чини € 200.000, исто
така, се отпишуваат за неколку години и трошоци € 10.000 годишно одржување.
За овој случај, можеме да ги земеме предвид и трошоците на машинеријата. Трошоците за работна сила
дневно е € 175 за еден работник. Багерот чини € 20.000 + 5.000 годишно за отпис и одржување, што е € 104,17
по работен ден. За подготовка на фондацијата, ова изнесува 4 × 5 × € 175 + 5 × € 104.17 = € 4.020.85. За
застојот на патот, трошоците се 6 × 2 × € 175 + 2 × € 208,34 = € 2.516.68.
Вежба 10.8 Размислете дека формуларот за хартија го печати инженерот на страницата во процесот на
изнајмување, дека печатачот чини € 300 отпишани за три години, и дека еден куп хартија чини 500 парчиња € 10.
Зошто може да има смисла да се вклучат овие трошоци во пресметката, зошто да не?
Својствен проблем на ABC е дета theот на податоците што се потребни за следење на времетраењето на
активностите, како изнајмување опрема или одобрување на барања за изнајмување. Податоците за настанот што се
зачувани во информатичките системи запознаени со процесите можат да помогнат во обезбедувањето на вакви
податоци. Исто така, технологиите како идентификација на радиофреквенцијата (РФИД), кои помагаат да се следат
физичките предмети врз основа на малку РФИД чипови, прикачени на тоа, ветуваат дека ќе го надминат проблемот со
следење на ABC. Некои системи водат сметка за завршување на активноста. Како и да е, АБЦ исто така бара почеток
на активности да се чуваат. Ова може да се постигне со следење на временските ознаки на точката во времето кога
ресурсот ќе започне да работи на одредена задача. Она што е важно да се земе предвид овде е цената за
постигнување дополнителна транспарентност. Постои размена и откако ќе стане прескапо за да се добие поголема
транспарентност,
10.3.3 Мерење на квалитетот
Квалитетот на производот создаден во еден процес често не е директно видлив од дневниците за извршување.
Сепак, добра индикација е да проверите дали има повторувања во
дневници за извршување, бидејќи тие обично се случуваат кога некоја задача не е завршена успешно.
Повторувањата може да се најдат во низа задачи. Во погл. 7 , видовме дека јамката на образецот на rework го
зголемува времето на циклус на задачата КТ = Т
1-р
во споредба со Т да биде време да се изврши задачата само еднаш. Сега е прашањето како можеме да ја
утврдиме веројатноста за повторување р од серија логови на настани?
Првиот дел од одговорот на ова прашање може да се даде со реформулирање на равенката таква
за која е решено р Со множење со 1 - р добиваме КТ - р ×
КТ = Т Одземање на КТ приноси - р × КТ = Т - КТ, што може да се подели по
- КТ резултираше во
r=1-Т
КТ.
И двајцата КТ и Т сега може да се утврди со помош на податоците од дневниците за настани. Размислете за неколку случаи во
кои ги набудуваме следните времиња на извршување за задача а:
1. 5 минути, 10 минути.
2. 10 минути.
3. 20 минути, 6 минути, 10 минути.
4. 5 минути.
5. 10 минути, 10 минути. Време на циклус КТ од а сега може да се пресмета како просечно време на извршување
на а
по случај, додека просечното време на извршување Т е просечното време на извршување на а по инстант. И
двете можат да се утврдат врз основа на збирот на сите егзекуции на а, што е тука 86 минути. Имаме неколку
случаи, такви КТ = 86/5 = 17.2. Целосно, а
егзекутиран девет пати попуст Т = 86/9 = 9.56. Оттука, добиваме r = 1 - 86/9 86/5 =
1 - 5 9 = 0,44. Се разбира, оваа пресметка е само приближување на реалната вредност за р Таа се заснова на
претпоставката дека времетраењето на една задача секогаш следи иста дистрибуција, без оглед дали е тоа
првото, второто или друго повторување.
Вежба 10.9 Одредете ја веројатноста за повторување р за следните време на извршување на задачата б:
2. 30 минути.
4. 20 минути.
6. 25 минути.
Исто така, објаснете зошто вредноста е погрешна за овие логови.
Во некои информациски системи можеби е полесно да се следи повторувањето врз основа на

доделување на задачи на ресурси. Еден пример се системи за билети тој запис кој ресурс работи на
случајот. Исто така, логовите на овие системи нудат увид
во повторување. Типичен процес поддржан со системите за билети е решавање на инциденти. На пример,

инцидент може да биде повик од клиент кој се жали дека системот за онлајн банкарство не работи.
Таквиот инцидент е снимен од страна на посветен учесник, на пр. Агент на центар за повици. Потоа, тој се
доставува до тим за поддршка на прво ниво, кој се обидува да го реши проблемот. Во случај проблемот да
биде премногу специфичен, тој се проследува до тим за поддршка од втор степен со специјализирано
знаење во доменот на проблемот. Во најдобар случај, проблемот е решен и клиентот ќе го забележи. Во
непожелниот случај, тимот идентификува дека проблемот е во надлежност на друг тим. Ова има
последица дека проблемот е вкоренет во тимот на првото ниво. Слично како повторување на задачите,
сега гледаме дека има повторено доделување на проблемот на истиот тим. Според информациите за
дневникот, може да се користат за да се утврди колку е веројатно дека проблемот е вратен назад.
10.3.4 Мерење на флексибилноста
Флексибилноста се однесува на степенот на варијација што еден процес го дозволува. Оваа ibility егзибилност може
да се дискутира во врска со дневниците за настани што ги создава процесот. За компанијата што е сопственик на
овој процес, ова е важна информација со цел да се спореди посакуваното ниво на ibility егзибилност со вистинската.
Егзибилност. Може да испадне дека процесот е поизразен, отколку што се бара од деловна перспектива. Ова е
случај кога fl егзибилноста може да се изедначи со недостаток на стандардизација. Честопати, перформансите на
процесите страдаат кога се дозволени премногу опции. Разгледајте го повторно процесот за изнајмување опрема во
BuildIT. Процесот бара формулар за барање за изнајмување опрема да се испрати преку е-пошта. Сепак, некои
инженери претпочитаат да го нарекуваат складиштето наместо да ја полнат формата. Бидејќи овие инженери
честопати се многу одлични, не е лесно службеникот да ги одбива овие повици. Како резултат, службеникот ја
објавува формата додека е на телефон. Не само што оваа постапка трае повеќе време, туку и, поради бучава на
градилиштето, ја зголемува веројатноста за појава на грешки. Во пракса, ова значи дека процесот на изнајмување
има две опции за поднесување на барање: по формулар (стандардна постапка) и преку телефон.
Делумно, таквата видливост како што е опишано погоре може директно да се забележи во дневниците за
настани. Видовме дека работниот дневник на еден процес игра важна улога за автоматско откривање на
процесите. Може да се искористи за да се процени веродостојноста на процесот. Дневникот за работа го сумира
суштинското однесување на процесот. Бидејќи ја определува секоја извршување како секвенца на задачи, се
апстрахира од временското растојание меѓу нив. На овој начин, дневникот за работа содржи збир на траги кои
имаат единствена секвенца. Ова значи дека ако две егзекуции содржат иста секвенца на задачи, тогаш тие
резултираат само во една трага да биде вклучена во дневникот за работа. Оваа апстракција на егзекуциите на
процесите во смисла на дневник за работа го прави добра почетна точка за дискутирање за егзибилноста. Според
тоа, бројот на посебни егзекуции ДЕ
може да се разреди врз основа на дневник за работа Л како
DE = | L |.
10.4 Проверка на сообразноста 373
Вежба 10.10 Разгледајте ги дневниците за настани во врска со процесот на нарачка за нарачка во Сл. 10.1 . Колкав е
бројот на изразени егзекуции ДЕ?
Се поставува прашањето дали бројот на различни егзекуции секогаш дава добар показател за fl егзибилност.
На моменти, бројот на различни егзекуции може да даде претерано голема количина на i егзибилност. Ова може
да биде случај за процеси со истовременост. Ваквите процеси можат да бидат високо структурирани, но имајќи
само мал пакет на истовремени задачи резултира во богат сет на потенцијални секвенци на извршување.
Разгледајте го моделот на процеси изработен од а- алгоритам на сл. 10,7 . Задачи јас и ч се истовремени на ј и к. Навистина,
постојат шест опции за нивно извршување:
1 јас, ч,,, к
2. ј, к, јас, ч
3. јас,,, к, ч
4. ј, јас, ч, к
5. јас,,, ч, к и
6. ј, јас, к, ч
Додека наредбата не е строга, сите мора да бидат погубени. Затоа, можеби е добра идеја дополнително да
размислиме дали задачата е по избор. Ако Т се однесува на бројот на задачи што се појавуваат во дневникот
за работа, потоа на множеството Т се одлучат ги содржи оние задачи кои не се изборни. Опционалноста според
дневникот значи дека за одредена задача постои барем една трага во која не се јавува. За логовите на сл. 10.1
, забележуваме дека задачите б до ѓ зависи од достапноста на суровините. Можеме да го измериме степенот
на опција ОПТ како
ОПТ = Т се одлучат
Т
Исто така, можеме да пристапиме кон прашањето за ibility егзистентност од гледна точка на автоматски
откриениот модел на процес. Ова има некои предности бидејќи степенот на изборност не открива колку
решенија треба да се донесат. Ако го земеме предвид процесниот модел изработен од а- алгоритам на сл. 10,7
, гледаме дека е вклучен еден јазол на решенија (XOR-split). Ја разликува ситуацијата дали производот е
во залиха или не. Ова набудување може да се измери како број на откриени точки на одлучување (ДДП). На
пример, на а- алгоритмот може да се користи за таа цел.
10.4 Проверка на сообразноста
Додека анализата на перформансите се занимава со мерење на индикаторите за перформанси, проверката на
сообразност е загрижена за прашањето дали извршувањето на еден процес следи преовладени правила или
ограничувања. На ова прашање може да се одговори со преглед на дневниците на настанот. Ако одредено
ограничување не се задржува, ние зборуваме за а
повреда. Проверката на сообразност е загрижена за идентификување на овие повреди и давање

изјави за обемот на нив заедно. Овие информации даваат важни увид за сопственикот на процесот.
Очигледно, кога не се следат правилата,
треба да се преземат корективни активности. Прекршувањата може да се однесуваат на една од трите процесни перспективи на
контролата, податоците и ресурсите во изолација или во комбинација. Во продолжение, ние опишуваме како тие можат да бидат
специфицирани.
10.4.1 Сообразност на протокот на контрола
Сообразноста на контролата може да се изучува на два начина, или врз основа на тоа експлицитни ограничувања или
засновано на а модел на нормативен процес. Двете можат да бидат поврзани едни со други, бидејќи многу ограничувања
можат автоматски да се извлечат од моделот на процеси. Прво, ќе го разгледаме пристапот претпоставувајќи експлицитни
ограничувања, по што ќе разговараме за употреба на нормативен модел на процеси.
Ние се фокусираме на три вида ограничувања поврзани со контролата: задолжителност, ексклузивност и нарачка.
Сите овие три ограничувања дефинираат како е дозволено да се поврзани две активности во еден процес. Една
компанија можеби ќе сака да утврди дека постојат одредени активности задолжително затоа што се бараат од
контролна перспектива. Разгледајте го повторно случајот со BuildIT и процесот на изнајмување на опрема. Инженер за
работи треба да го разгледа барањето за изнајмување. Оваа активност служи како контрола за обезбедување дека се
изнајмува само соодветна опрема. Оваа мерка може да помогне да се следат трошоците за изнајмување во
согласност. Ваквата контролна активност е веројатно кандидат за задолжителна активност. На ниво на дневниците,
задолжителни повреди на активност може да се најдат со пребарување на траги во кои тие се изоставени. Ексклузивност
може да биде специфициран за активности што се однесуваат на одлука. Ако, на пример, барање за изнајмување е
одбиено, BuildIT сака да се осигура дека не постои начин да се преиначи оваа одлука. На ниво на дневник, ова значи
дека никогаш нема да биде можно одбивање на барање да биде проследено со одобрение. Оваа ексклузивност може
да се провери со пребарување на траги во кои се појавуваат и двете ексклузивни активности. На со цел на активности
може да биде од специфично значење за балансирање на перформансите на процесот. Во процесот на изнајмување
на опрема, првото постоење на потребната опрема се проверува пред да се разгледа барањето. Ова ограничување на
нарачката помага во олеснување на обемот на работа на инженерот за работи кој треба да го разгледа барањето.
Очигледно, тоа е губење напори да ги разгледаме барањата што не можат да бидат исполнети, бидејќи опремата не е
достапна. Прекршувања на ограничувањата во нарачките може да се најдат со пребарување траги со активности што
се појавуваат по погрешен редослед.
Вежба 10.11 Разгледајте ги дневниците за настани во врска со процесот на нарачка за нарачка во Сл. 10.1 . Кои активности
можат да се сметаат за задолжителни и ексклузивни едни за други?
Сообразноста на контролата може исто така да се провери со споредување на однесувањето забележано во

дневниците со нормативен модел на процеси. Идејата е да се повтори секоја трага во дневникот за работа и да се
забележи на секој чекор дали некоја активност е дозволено да се извршува според правилата на моделот. Обично,
ова бара повторување на логовите во моделот на процеси. Врз основа на правилата за транзиција на БПМН,
можеме да го повториме случајот < a, b, g, i, j, k, l > на моделот прикажан на сл. 10.11 . Во почетната
10.4 Проверка на сообразноста 375 година
Сл. 10.11 BPMN модел со знак на почетен настан за повторување на случајот < a, b, g, i, j, k, l >
држава, процесот има знак на почетокот на настанот. Откако ќе се започне случајот, овој токен се префрла на
излезниот лак на почетниот настан. Овој лак доведува до активност а ( „Проверете ја достапноста на акциите“),
што значи дека токенот овозможува да се изврши оваа активност. Токенот се префрла на оваа активност додека
е извршен и истиот се пренесува на излезниот лак откако ќе заврши активност. Сега, XOR-split е активиран, што
значи дека треба да се донесе одлука или да се продолжи со тоа б ( „Внесете производ од магацин“) или со ѓ ( "Производство
производ"). За разгледуваниот случај, продолжуваме со б. На ист начин, можеме да продолжиме. После g ( „Усогласена
нарачка“) е завршена, пристигнуваме во СД-поделба. Поделбата AND троши знак од влезниот лак и создава еден
токен на секој од неговите излезни лаци. Како резултат, имаме два тока после тоа: еден што овозможува јас ( „Бродски
производ“) и еден овозможувачки ј ( „Испуштате фактура“). Во оваа состојба можеме да продолжиме или јас или ј. Овие
активности се истовремени. За да го повториме случајот, ние најпрво егзекутираме јас и ј потоа. Еднаш јас а
подоцна к е завршено, AND-приклучувањето е дозволено да се продолжи. За тоа е потребен еден токен на секој
влезен лак. Двете овие токени се трошат и се создава еден токен на неговиот излезен лак. Како резултат, л ( „Архивска
наредба“) може да се изврши.
Врз основа на концептот на повторување на токени, можеме да ја процениме и усогласеноста на трагата

во процесниот модел. Разгледајте го случајот < a, b, i, j, k, l > во која е изоставена потврдата за нарачката.
Идејата е да се спореди на секој чекор бројот на токени што се потребни за репродукција на активност со
токени што се всушност достапни. На секој чекор, можеме да забележиме две ситуации на сообразност и две
на неусогласеност. Во случај на сообразност, за токените можеме да ги броиме следниве четири факти:
• стр: бројот на токени што се правилно произведени

• в: бројот на токени што се правилно потрошени
• м: бројот на токени што недостасуваат за извршување на следната активност во дневникот, и
• р: бројот на токени што остануваат неиздржани по извршувањето на финалната активност во дневникот Слика 10.12 Прво
ја прикажува состојбата пред да се репродуцира б на случајот < a, b, i, j, k, l >.
По повторното репродукција б, достапен е токен за извршување г, но не се троши. Наместо тоа,

недостасува знак за fiвонење на AND-split, што би се активирал
јас и ј. Името го прикажува и бројот на правилно произведени и потрошени токени за секој чекор до
завршувањето. Користење на четири мерки в, стр, м и r,
можеме да ја пресметаме мерката на сигурност како индикатор за сообразност. Дефициран е
Сл. 10.12 Повторно повторување на случајот што не е во согласност < a, b, i, j, k, l >

10.4 Проверка на сообразноста 377
Сл. 10.13 Резултат на случаи со повторување во моделот на процеси
врз основа на дел од токените што недостасуваат во правилно потрошените токени ( м

в) и
дел од преостанатите токени до произведени токени ( р
стр како
( ) ( )
1
ness tness = 1 1-м + 1-р .
2 в 2 стр
За нашите вредности в = 12, стр = 12, м = 1 и r = 1, добиваме сигурност од 1 2 ( 1 -

1
1-1
12) + 1 2 ( 12) = 0,8333. Кога разгледаме низа случаи, не само сингл
случај, можеме лесно да ја пресметаме моќта на ист начин. Идејата е едноставно да продолжиме со броењето в, стр, м и
р со повторување на следниот случај во моделот на процеси. Откако ќе ги повториме сите случаи, ќе добиеме како
резултат на севкупната важност на овој пакет случаи.
Резултатите од таквата анализа на сообразноста може да се толкуваат на два начина. Прво, можеме да ја
искористиме целокупната мерка на сигурност за да добиеме идеја колку точно моделот на процеси одговара на
всушност набудуваното однесување како што е прикажано од пакетот случаи. Иако ефикасноста како целокупна
мерка е корисна за оваа цел, не ни помага да ги анализираме подеталностите на отстапувањата. Затоа, и второ,
можеме да провериме на кои лаци од моделот на процеси сме наиле на исчезнати или преостанати токени. Слика 10.13
ги прикажува соодветните броеви од репродукција на неколку случаи во моделот на процеси. Може да се види
дека очигледно повеќето отстапувања се однесуваат на активност г а некои на активност л. Оваа информација може
да се искористи за да се интервјуираат учесниците во процесот зошто г е изоставен за некои случаи. Целта на
ваквото испитување ќе биде да се утврди дали овој пропуст е пожелен. Прашањето е дали учесниците во процесот
пронашле поефикасен начин да се справат со кондицијата, или дали пропустот треба да се смета за лоша
практика што треба дополнително да се обесхрабри. За случајот со архивата (активност ј), пропустот веројатно ќе
биде лоша практика.
10.4.2 Сообразност на податоците и ресурсите
Надвор од ограничувањата на контролата, често има дополнителни ограничувања на податоците и

ресурсите. Размислете за состојбата дека се бара скап гасеница за градилиштето на „Бритит“. Многу
компании имаат дополнителни правила за високи трошоци
или ризични обврски. Во случај на BuildIT, изнајмувањето на гасеницата бара дополнителен потпис на
менаџер. Слични случаи може да се најдат во банки каде заем од повеќе од € 1.000.000 можеби ќе бараат
дополнителен најавување од директорот. Исто така, може да има ограничувања дека давањето заем на
апликантот со црна листа, воопшто не е дозволено. Ваквите ограничувања може да се проверат со
пребарување на случаи во дневникот, кога одреден податок има забранета вредност.
Примерот на дополнително потребниот потпис веќе укажува на комбинација на ограничувања на

податоци и ресурси. Ако одредена сума е надмината, тогаш постои посветен ресурс кој треба да го
одобри. Сепак, постојат и ограничувања кои чисто се однесуваат на перспективата на ресурсите.
Учесниците обично бараат дозволи
за извршување на одредени активности. На пример, лицето што ја потпишува гасата на гасеница треба да биде
управител и не е дозволено ова лице да работи како градежен работник. Обично, дозволите се врзани за
спецификации улоги. На пример, ова може да се направи со експлицитно наведување на она што им е дозволено
на управителот и на градежниот работник. Прекршувањата на дозволите може да се проверат со пребарување на
секоја активност спроведена од учесник, дали постоела соодветна улога или дозвола. Се нарекуваат посебни
правила за контрола на кои се бара две различни лица да одобрат деловна трансакција одвојување на
должностите ограничувања. Овие правила не мора да вклучуваат супервизори. На пример, може да биде добро
со одредена банка ако е заем од € 100.000 ги потпишува двајца службеници во банка, додека а € За заем од
1.000.000 е потребен потпис на службеник и директор. Ваквата поделба на ограничувањата на должностите може
да се провери со пребарување на случаи во дневникот каде истиот учесник или двајца учесници со иста улога ја
одобриле истата трансакција.
Вежба 10.12 Разгледајте го процесот на внесувањето по редизајнирањето на медицината, што е прикажано на сл. 8.3 . Кое
одделување на ограничувањата на должностите би го дефинирале за овој процес?
10.5 повтори
Во ова поглавје разговаравме за темата процесна интелигенција. Појдовна точка за процесна интелигенција е
достапноста на дневници за настани и, генерално, податоци за извршување на процесите. Овие податоци даваат
основа за следење на процесите и контролирање на процесите. Таквите дневници за настани треба да се однесуваат
на специфичен случај, задача и точка во времето со цел да се олесни анализата поврзана со процесите. Во многу
случаи, предизвик е да се извлечат податоци на таков начин што тие можат лесно да ја поддржат интелигенцијата на
процесите.
Важна област на процесна интелигенција е автоматско откривање на процесите. Соодветни техники како а- модели
на процесни приноси на алгоритми кои опишуваат како процесот се одвива во реалноста според податоците на
дневникот. На а- алгоритмот е добар пример за тоа како работи автоматското откривање на процесите. Како и да
е, има ограничувања во однос на стабилноста, за коишто се опфатени неодамнешните алгоритми за рударство.
10.6 Решенија за вежби 379 година
Дневниците за настани исто така ја поддржуваат проценката на успешноста на еден процес. Разговаравме за
четирите димензии на четириаголникот на ѓаволот. Временската димензија на еден процес може да се визуелизира како
исцртана шема и дополнително да се провери со користење на временска рамка. Потоа, демонстриравме дека
пресметката на трошоците за еден процес во голема мерка зависи од нивото на детали со кое се фаќаат времето на
извршување на задачите. Се свртевме кон квалитетот и го поврзавме со бројот на повторувања што се среќаваат во
дневникот. Конечно, разговаравме за начините за квантифицирање на веројатноста на еден процес заснован на бројот на
изразени егзекуции, опционалност и откриени точки на одлучување.
Областа на проверка на сообразноста може да биде поврзана со разни видови ограничувања. Постојат различни
видови на ограничувања што можат да се проверат за контрола на контролата, вклучувајќи задолжителност,
ексклузивност и нарачка на активности. Поим за доверливост може да се пресмета врз основа на репризирање на
логовите во модерен нормативен процес. Конечно, разговаравме за важни видови на ограничување за перспективите на
податоците и ресурсите. Честопати, овие се испреплетени. Тие вообичаено се однесуваат на дополнителни барања за
одобрување над одреден монетарен праг или да се спроведе одвојување на давачките со цел да се контролираат
ризиците од деловна трансакција.
10.6 Решенија за вежби
Решение 10.1 Може да биде случај дека делови од процесот на производство се администрираат со употреба на
различни информативни системи. Според тоа, дневниците за настани треба да бидат интегрирани. Во однос на
корелацијата, ова значи дека идентификаторите на случаи од различни системи треба да се совпаѓаат. Ако
временските ознаки на настаните се снимени во различни временски зони, тие треба да бидат усогласени. Пратката
не може да ја организира „Ербас“. Затоа, може да биде случај дека не може да се достапни различни слики од
транспортот. Исто така, информациските системи не можат директно да произведуваат дневници за настани поврзани
со случаи. Податоците ќе треба да бидат извлечени од базата на податоци на овие системи. Конечно, настаните може
да се забележат на различни нивоа на грануларност, почнувајќи од детален запис на чекорите на производство, до
грубо-грануларна евиденција за фазите на транспорт.
Решение 10.2 The workflow log considers the order of events for each case. We use letters a to l for
referring to the tasks. The workflow log L containing three elements as the first and the fourth execution
sequence are the same. Therefore, we get L= [ 〈 a, b, g, h, j, k, i, l 〉, 〈 a, c, d, e, f, g, j, h, i, k, l 〉, 〈 a, c,
f, g, j, h, i, k, l 〉].
Solution 10.3 The following basic relations can be observed:
a>bh>j i>l d>eg>j i>k

b>gj>ka>c e>f j>hk>l
g>hk>i c>df>gh>i c>f
The matrix shows the resulting relations.

380 10 Process Intelligence
Fig. 10.14 Process model constructed by the α- algorithm
Solution 10.4 The α- algorithm stepwise yields the following sets:
1. T L = { a, b, c, d, e, f, g, h, i, j, k, l}.
2. T I = { a}.
3. T O = { l}.
4. X L = Z 1 ∪ Z 2 with Z 1 = { a → b, a → c, b → g, c → d, c → f, d → e, e → f, f → g, g → h, g → j, h → i, i → l, j → k, k → l} and
Z 2 = { a → ( b#c), c →( d#f ), (c#e) → f, (b#f ) → g}
5. Y L = Z 2 ∪ { d → e, g → h, g → j, h → i, j → k, i → l, k → l}.
6. Add start event pointing to a and end event following after l.
7. Construct process model based on Y L with XOR- and AND-gateways.
8. Return process model, see Fig. 10.14 .
10.6 Solutions to Exercises 381
Solution 10.5 Include a, b, c, d, e in an XOR-block and put this XOR-block in an XOR-loop. This model
shows a perfect fitness to the execution sequence as it is able to replay any occurrence of a to e at any
stage. The model is not completely simple as it includes four gateways for characterizing the behavior of
five activities. Also, the model is not very precise in this sense that it does not introduce specific
constraints on the behavior: any occurrence of a to e is allowed at any stage. Generalization refers to the
ability of the model to abstract. As the model does not constrain the behavior, there is hardly any general
insight that we can learn from it.
Solution 10.6 First, we have to determine the cycle time. Case 1 takes roughly two hours less than seven
days, case 2 one hour less than six days, case 3 takes four days and 20 minutes, and case 4 takes four
days and six hours. Therefore, the relative order must be case 3, case 4, case 2 and case 1. Each event
has to be visualized according to the time elapsed since the first event of the case.
Solution 10.7 The timeline diagram follows the same principle as the dotted chart. Additionally, it shows
waiting times as soon as an activity becomes enabled in the process model.
Solution 10.8 In general, it is a good idea to include all expenses in the cost calculation as it provides
transparency on what is spent where. In this case, however, it might not be a good idea since the cost
per paper is relatively low with € 0.02. It has to be kept in mind though that the decision whether to record
certain costs should not be governed by the unit piece, but by the relative impact on cost calculation. A
cost of paper of € 0.02 is small as compared to overall process costs of several thousand Euros.
However, it can be relatively high if the overall process produces
€ 0.30 costs per instance and millions of instances are processed per day. Think of the situation of
processing bank transactions using paper forms versus using online banking. The high amount of
transactions per day might result in considerable costs per year.
Solution 10.9 The formula yields r = 1 − T CT = 1 − 18.3 27.5 = 0.333. Apparently, this
result is misleading for the figures because every second task required rework. However, the rework time
was in general much smaller as the first try duration. This has the effect that T appears to be relatively
small in comparison to CT, which results in a low value for r.
Solution 10.10 We have to consider four different cases. However, as the first and the fourth case show
the same sequence of tasks, there are three distinct executions.
Solution 10.11 There are several activities that can be observed in all cases. These mandatory activities
are a, g, h, i, j, k, l. The other activities b, c, d, e, f are not mandatory. Exclusiveness relationships hold
between b and c, d, e, f pairwise.
Solution 10.12 The intake process demands meeting two intakers. The persons conducting “Meet with
first intaker” and “Meet with second intaker” should be mutually
382 10 Process Intelligence
exclusive. Therefore, we can identify a separation of duty constraint that the participant conducting “Meet
with first intaker” should be another one as the participant conducting “Meet with second intaker”.
10.7 Further Exercises
Exercise 10.13 Download the process mining tool ProM, write down the workflow log L in XES, and run
the α- algorithm.
Exercise 10.14 Apply the α- algorithm and document the different steps for the workflow log L containing four
cases L = [ 〈 a, b, c, d 〉, 〈 a, b, d, c 〉, 〈 a, b, d, c, e 〉, 〈 a, c, d, e 〉].
Exercise 10.15 Apply the α- algorithm and document the different steps for the workflow log L containing
four cases L= [ 〈 a, b, c, d, e, f 〉, 〈 a, b, d, c, e 〉, 〈 a, b, d,
c, e, f 〉, 〈 a, b, c, d 〉].
Exercise 10.16 Consider there is an AND-split in a process model with two subsequent activities a and b.
Which kind of pattern do these activities show on the timeline chart?
Exercise 10.17 Consider the workflow log, which you created for Exercise 10.2
from the cases shown in Fig. 10.1 . Replay these logs in the process model of Fig. 10.13 . Note down
consumed, produced, missing and remaining tokens for each arc, and calculate the fitness measure.
Assume that activities not shown in the process model do not change the distribution of tokens in the
replay.
10.8 Further Reading
Process intelligence relates to various streams of current research. The workflow resource patterns give
an extensive account of strategies that can be used for effectively assigning work items to participants at
the time of execution. Process mining has been a very influential area of research in the recent years,
offering various tools and techniques for process intelligence. An excellent overview of this research
area is provided in the book by van der Aalst on process mining [ 94 ]. Among others, it summarizes work
on leveraging shortcomings of the α- algorithm, namely the heuristic miner, the fuzzy miner, and the
genetic miner. The idea of the heuristic miner is to generate so-called heuristic nets in which the arc
probabilities are included. Using appropriate threshold values, the user can eliminate unlikely behavior.
The fuzzy miner takes correlations between events and behavior into account. In this way, tasks can be
clustered and inspected at different levels of abstraction. The
genetic miner generates a population of potential models and stepwise manipulates

10.8 Further Reading 383
these models using change operations and quality metrics in order to improve the approximation of the
log. This process is repeated until a model with a predefined quality level is found.
Various guiding principles and research challenges for process mining have been formulated by the
IEEE Task Force on Process Mining in the Process mining manifesto [ 37 ]. There are dedicated tools that
help with putting process mining into practice (see http://www.processmining.org ). Process mining tools
usually cover automatic process discovery and techniques for conformance checking.
A good summary of current research on process performance analysis is provided by the

BPMHandbook [ 102 , 103 ] and, most notably, its chapters on process performance management and on
business process analytics [ 33 , 111 ]. A good overview on process controlling and its relationship to
process automation is the book by zur Muehlen [ 110 ]. More generally, the book by Harmon provides a
good perspective on how to define process measures within a process governance framework [ 32 ]. A
good book on foundations on performance from an operations management point of view is the book by
Anupindi et al. [ 4 ]. Various metrics for event logs are discussed in the Ph.D. thesis of Günther [ 25 ].
Conformance checking is also nicely covered in the book by van der Aalst on process mining [ 94 ].
Research with a focus on generating constraints from process models for conformance checking is
conducted by Weidlich et al. [ 104 , 105 ]. Case studies on process mining and conformance checking are,
among others, reported in [ 13 , 22 , 97 ]. Separation of duties is traditionally discussed as a topic within the
research area of role-based access control (RBAC). A summary of essential RBAC concepts and their
relationship to process-centered concepts is provided in [ 90 ].
References
1. I. Adan, J. Resing, Queueing Theory ( Eindhoven University of Technology, Eindhoven,

2002)
2. T. Allweyer, BPMN 2.0. Books on Demands (2010)
3. A. Alves, A. Arkin, S. Askary, C. Barreto, B. Bloch, F. Curbera, M. Ford, Y. Goland, A. Guizar, N. Kartha, C.K. Liu,
R. Khalaf, D. Koenig, M. Marin, V. Mehta, S. Thatte, D. van der Rijn, P. Yendluri, A. Yiu, Web services business
process execution language version 2.0. Committee specification, 31 January 2007, OASIS (2007)
4. R. Anupindi, S. Chopra, S.D. Deshmukh, J.A. van Mieghem, E. Zemel, Managing Business
Process Flows ( Prentice Hall, New York, 1999)
5. J. Becker, M. Rosemann, C. von Uthmann, Guidelines of business process modeling, in
Business Process Management. Models, Techniques, and Empirical Studies, ed. by W.M.P. van der Aalst, J. Desel,
A. Oberweis (Springer, Berlin, 2000), pp. 30–49
6. J. Becker, M. Kugeler, M. Rosemann, Process Management: a Guide for the Design of Busi-
ness Processes ( Springer, Berlin, 2011)
7. B.L. Berg, H. Lune, Qualitative Research Methods for the Social Sciences ( Pearson, Boston,
2004)
8. S. Conger, Six sigma and business process management, in Handbook of Business Process
Management, vol. 1, ed. by J. vom Brocke, M. Rosemann (Springer, Berlin, 2010), pp. 127– 148
9. T. Curran, G. Keller, SAP R/3 Business Blueprint: Understanding the Business Process Ref-
erence Model ( Prentice Hall, Upper Saddle River, 1997)
10. T.H. Davenport, Process Innovation: Reengineering Work Through Information Technology
(Harvard Business School Press, Boston, 1993)
11. T.H. Davenport, J.E. Short, The new industrial engineering: information technology and business process redesign.
Sloan Manag. Rev. 31( 4), 11–27 (1990)
12. R.B. Davis, E. Brabander, ARIS Design Platform: Getting Started with BPM ( Springer,
Berlin, 2007)
13. J. De Weerdt, M. De Backer, J. Vanthienen, B. Baesens, A multi-dimensional quality assessment of
state-of-the-art process discovery algorithms using real-life event logs. Inf. Syst.
37( 7), 654–676 (2012)
14. R. Dijkman, I. Vanderfeesten, H.A. Reijers, The road to a business process architecture: an overview of
approaches and their use. BETA Working Paper Series, WP 350. Eindhoven University of Technology,
Eindhoven (2011)
15. D.J. Elzinga, T. Horak, C.Y. Lee, C. Bruner, Business process management: survey and methodology. IEEE
Trans. Eng. Manag. 42( 2), 119–128 (1995)
M. Dumas et al., Fundamentals of Business Process Management, 385

DOI 10.1007/978-3-642-33143-5 , © Springer-Verlag Berlin Heidelberg 2013
386 References
16. G. Engels, A. Förster, R. Heckel, S. Thöne, Process modeling using UML, in Process-Aware
Information Systems, ed. by M. Dumas, W.M.P. van der Aalst, A.H.M. ter Hofstede (Wiley, New York, 2005).
Chapter 5
17. T. Erl, A. Karmarkar, P. Walmsley, H. Haas, Web Service Contract Design and Versioning
for SOA ( Prentice Hall, New York, 2008)
18. P.J.M. Frederiks, T.P. van der Weide, Information modeling: the process and the required competencies of its
participants. Data Knowl. Eng. 58( 1), 4–20 (2006)
19. J. Freund, B. Rücker, Real-Life BPMN: Using BPMN 2.0 to Analyze, Improve, and Automate
Processes in Your Company. CreateSpace Independent Publishing Platform (2012)
20. V. Frolov, D. Megel, W. Bandara, Y. Sun, L. Ma, Building an ontology and process architecture for engineering
asset management, in Proceedings of the 4th World Congress on Engineering Asset Management (WCEAM), Athens,
Greece, September 2009 (Springer, Berlin,
2009)
21. D. Fürstenau, Process Performance Measurement ( GRIN, Santa Cruz, 2008)
22. S. Goedertier, J. De Weerdt, D. Martens, J. Vanthienen, B. Baesens, Process discovery in event logs: an
application in the telecom industry. Appl. Soft Comput. 11( 2), 1697–1710 (2011)
23. E.M. Goldratt, The Goal: A Process of Ongoing Improvement ( North River Press, Great
Barrington, 1992)
24. A. Greasley, A redesign of a road traffic accident reporting system using business process simulation. Bus. Process.
Manag. J. 10( 6), 635–644 (2004)
25. C. Günther, Process mining in flexible environments. PhD thesis, Technische Universiteit Eindhoven (2009)
26. M. Hammer, Reengineering work: don’t automate, obliterate. Harv. Bus. Rev. 68( 4), 104– 112 (1990)
27. M. Hammer, Beyond Reengineering: How the Process-Centered Organization Is Changing

Our Work and Our Lives ( HarperBusiness, New York, 1997)
28. M. Hammer, What is business process management, in Handbook of Business Process Man-
agement, vol. 1, ed. by M. Rosemann, J. vom Brocke (Springer, Berlin, 2010)
29. M. Hammer, J. Champy, Reengineering the Corporation: A Manifesto for Business Revolu-
tion ( HarperCollins, New York, 1993)
30. P. Hanafizadeh, M. Moosakhani, J. Bakhshi, Selecting the best strategic practices for business process redesign. Bus.
Process. Manag. J. 15( 4), 609–627 (2009)
31. P. Harmon, Business Process Change: A Guide for Business Managers and BPM and Six
Sigma Professionals, 2nd edn. (Morgan Kaufmann, San Mateo, 2007)
32. P. Harmon, Analyzing activities. BPTrends Newsletter 1( 4), April 2003. http://www.
bptrends.com
33. D. Heckl, J. Moormann, Process performance management, in Handbook on Business Pro-
cess Management 2 ( Springer, Berlin, 2010), pp. 115–135
34. D. Hollingsworth, in The Workflow Reference Model: 10 Years on the Workflow Handbook
2004 ( Workflow Management Coalition, Cohasset, 2004), pp. 295–312
35. D. Hollingsworth, The Workflow Reference Model. TC00-1003 Issue 1.1, Workflow Management Coalition, 24
November 1994
36. R. Hull, Artifact-centric business process models: brief survey of research results and challenges, in On the Move to
Meaningful Internet Systems: OTM 2008 ( 2008), pp. 1152–1163
37. IEEE TaskForce on Process Mining. Process mining manifesto. http://www.win.tue.nl/
ieeetfpm/doku.php?id=shared:process_mining_manifesto . Accessed: November 2012
38. F. Johannsen, S. Leist, G. Zellner, Implementing six sigma for improving business processes at an automotive bank,
in Handbook of Business Process Management, vol. 1, ed. by J. vom Brocke, M. Rosemann (Springer, Berlin, 2010),
pp. 361–382
39. R.S. Kaplan, D.P. Norton, The balanced scorecard—measures that drive performance. Harv. Bus. Rev. 70( 1), 71–79
(1992)
40. W.D. Kelton, R.P. Sadowski, N.B. Swets, Simulation with Arena, 5th edn. (McGraw-Hill,
New York, 2009)
References 387
41. W.J. Kettinger, J.T.C. Teng, S. Guha, Business process change: a study of methodologies, techniques, and tools.
Manag. Inf. Syst. Q. 21, 55–80 (1997)
42. J. Krogstie, G. Sindre, H.D. Jørgensen, Process models representing knowledge for action: a revised quality
framework. Eur. J. Inf. Syst. 15( 1), 91–102 (2006)
43. M. Laguna, J. Marklund, Business Process Modeling, Simulation and Design ( Prentice Hall,
New York, 2004)
44. S. Limam Mansar, H.A. Reijers, F. Ounnar, Development of a decision-making strategy to improve the efficiency of
bpr. Expert Syst. Appl. 36( 2), 3248–3262 (2009)
45. O.I. Lindland, G. Sindre, A. Sølvberg, Understanding quality in conceptual modeling. IEEE Softw. 11( 2), 42–49
(1994)
46. R.L. Manganelli, M.M. Klein, The Reengineering Handbook: A Step-by-Step Guide to Busi-
ness Transformation ( Amacom, New York, 1994)
47. S.L. Mansar, H.A. Reijers, Best practices in business process redesign: validation of a redesign framework.
Comput. Ind. 56( 5), 457–471 (2005)
48. S.L. Mansar, H.A. Reijers, Best practices in business process redesign: use and impact. Bus. Process. Manag. J. 13( 2),
193–213 (2007)
49. K. McCormack, The development of a measure of business process orientation and its relationship to
organizational performance, April 1999. Online tutorial available at
http://www.prosci.com/mccormack.htm
50. J. Mendling, Metrics for Process Models: Empirical Foundations of Verification, Error Pre-
diction, and Guidelines for Correctness. Lecture Notes in Business Information Processing, vol. 6 (Springer, Berlin,
2008)
51. J. Mendling, Empirical studies in process model verification, in Transactions on Petri Nets
and Other Models of Concurrency II, Special Issue on Concurrency in Process-Aware Information Systems, vol.
5460 (2009), pp. 208–224
52. J. Mendling, H.A. Reijers, J. Recker, Activity labeling in process modeling: empirical insights and
recommendations. Inf. Syst. 35( 4), 467–482 (2010)
53. J. Mendling, H.A. Reijers, W.M.P. van der Aalst, Seven process modeling guidelines (7PMG). Inf. Softw.
Technol. 52( 2), 127–136 (2010)
54. J. Mendling, L. Sánchez-González, F. García, M. La Rosa, Thresholds for error probability measures of business
process models. J. Syst. Softw. 85( 5), 1188–1197 (2012)
55. J. Mendling, M. Strembeck, J. Recker, Factors of process model comprehension—findings from a series of
experiments. Decis. Support Syst. 53( 1), 195–206 (2012)
56. A. Møller, M.I. Schwartzbach, An Introduction to XML and Web Technologies ( Addison-
Wesley, Reading, 2006)
57. D. Müller, M. Reichert, J. Herbst, A new paradigm for the enactment and dynamic adaptation of data-driven process
structures, in Advanced Information Systems Engineering ( Springer, Berlin, 2008), pp. 48–63
58. M. Netjes, R.S. Mans, H.A. Reijers, W.M.P. Aalst, R.J.B. Vanwersch, Bpr best practices for the healthcare domain, in Business
Process Management Workshops ( Springer, Berlin, 2010), pp. 605–616
59. A. Nigam, N.S. Caswell, Business artifacts: an approach to operational specification. IBM Syst. J. 42( 3), 428–445
(2003)
60. Object Management Group, Unified Modeling Language (UML) Version 2.4.1 (2011)
61. Object Management Group, Business Process Model and Notation (BPMN), Version 2.0, January 2011. http://www.omg.org/spec/BPM
62. P. O’Neill, A.S. Sohal, Business process reengineering a review of recent literature. Technovation 19( 9), 571–581
(1999)
63. A. Ottensooser, A. Fekete, H.A. Reijers, J. Mendling, C. Menictas, Making sense of business process descriptions: an
experimental comparison of graphical and textual notations. J. Syst. Softw. 85( 3), 596–606 (2012)
64. M.A. Ould, Business Process Management: A Rigorous Approach. British Informatics Soci-
ety Ltd (2005)
388 References
65. C. Ouyang, W.M.P. van der Aalst, M. Dumas, A.H.M. ter Hofstede, M. La Rosa, Semantic web services: theory,
tools and applications, in Service-Oriented Processes: An Introduction to BPEL, ed. by J. Cardoso (IGI Publishing,
Hershey, 2007), pp. 155–188
66. M. Petre, Why looking isn’t always seeing: readership skills and graphical programming. Commun. ACM 38( 6),
33–44 (1995)
67. M.E. Porter, Competitive Advantage: Creating and Sustaining Superior Performance ( Free
Press, New York, 1985)
68. G. Redding, M. Dumas, A.H.M. ter Hofstede, A. Iordachescu, A flexible, object-centric approach for business
process modelling. Serv. Oriented Comput. Appl. 4( 3), 191–201 (2010)
69. M. Reichert, B. Weber, Enabling Flexibility in Process-Aware Information Systems
(Springer, Berlin, 2012)
70. H.A. Reijers, Product-based design of business processes applied within the financial services. J. Res. Pract. Inf.
Technol. 34( 2), 110–122 (2002)
71. H.A. Reijers, Design and Control of Workflow Processes: Business Process Management for
the Service Industry ( Springer, Berlin, 2003)
72. H.A. Reijers, S. Liman Mansar, Best practices in business process redesign: an overview and qualitative evaluation of
successful redesign heuristics. Omega 33( 4), 283–306 (2005)
73. H.A. Reijers, J. Mendling, A study into the factors that influence the understandability of business process models.
IEEE Trans. Syst. Man Cybern., Part A, Syst. Hum. 41( 3), 449– 462 (2011)
74. H.A. Reijers, T. Freytag, J. Mendling, A. Eckleder, Syntax highlighting in business process models. Decis. Support
Syst. 51( 3), 339–349 (2011)
75. H.A. Reijers, J. Mendling, R.M. Dijkman, Human and automatic modularizations of process models to enhance their
comprehension. Inf. Syst. 36( 5), 881–897 (2011)
76. S.-H. Rhee, N.W. Cho, H. Bae, Increasing the efficiency of business processes using a theory of constraints. Inf. Syst.
Front. 12( 4), 443–455 (2010)
77. J.J. Rooney, L.N. vanden Heuvel, Root cause analysis for beginners. Qual. Prog. 37( 7), 45– 53 (2004)
78. M. Rosemann, Potential pitfalls of process modeling: Part A. Bus. Process. Manag. J. 12( 2), 249–254 (2006)
79. M. Rosemann, Potential pitfalls of process modeling: Part B. Bus. Process. Manag. J. 12( 3), 377–384 (2006)
80. G.A. Rummler, A.P. Brache, Improving Performance: Managing the White Space on the
Organizational Chart ( Jossey-Bass, San Francisco, 1990)
81. G.A. Rummler, A.J. Ramias, A framework for defining and designing the structure of work, in Handbook of Business
Process Management, vol. 1, ed. by M. Rosemann, J. vom Brocke (Springer, Berlin, 2010)
82. A.-W. Scheer, ARIS Business Process Modelling ( Springer, New York, 2000)
83. K.D. Schenk, N.P. Vitalari, K.S. Davis, Differences between novice and expert systems analysts: what do we know
and what do we do? J. Manag. Inf. Syst. 15( 1), 9–50 (1998)
84. A. Schwegmann, M. Laske, As-is modeling and process analysis, in Process Management:
A Guide for the Design of Business Processes ( Springer, Berlin, 2011), pp. 133–156
85. I. Seidman, Interviewing as Qualitative Research: A Guide for Researchers in Education and
the Social Sciences ( Teachers College Press, New York, 2006)
86. A. Sharp, P. McDermott, Workflow Modeling: Tools for Process Improvement and Applica-
tion Development, 2nd edn. (Artech House, Norwood, 2008)
87. B. Silver, BPMN Method and Style, 2nd edn. (Cody-Cassidy Press, Aptos, 2011)
88. J. Stirna, A. Persson, K. Sandkuhl, Participative enterprise modeling: experiences and recommendations, in Proceedings
of the 19th Conference on Advanced Information Systems Engineering (CAiSE 2007), Trondheim, Norway, ed. by
J. Krogstie, A.L. Opdahl, G. Sindre. Lecture Notes in Computer Science, vol. 4495 (Springer, Berlin, 2007), pp.
546–560
89. D. Straker, A Toolbook for Quality Improvement and Problem Solving ( Prentice Hall, New
York, 1995)
References 389
90. M. Strembeck, J. Mendling, Modeling process-related rbac models with extended uml activity models. Inf. Softw.
Technol. 53( 5), 456–483 (2011)
91. K.D. Swenson, Mastering the Unpredictable: How Adaptive Case Management Will Revo-
lutionize the Way That Knowledge Workers Get Things Done ( Meghan-Kiffer Press, Tampa,
2010)
92. A.H.M. ter Hofstede, W.M.P. van der Aalst, M. Adams, N. Russell (eds.), Modern Business
Process Automation: YAWL and Its Support Environment ( Springer, Berlin, 2010)
93. W.M.P. van der Aalst, Verification of workflow nets, in Application and Theory of Petri Nets
1997, ed. by P. Azéma, G. Balbo. Lecture Notes in Computer Science, vol. 1248 (Springer, Berlin, 1997), pp.
407–426
94. W.M.P. van der Aalst, Process Mining—Discovery, Conformance and Enhancement of Busi-
ness Processes ( Springer, Berlin, 2011)
95. W.M.P. van der Aalst, K. van Hee, Workflow Management: Models, Methods, and Systems
(MIT Press, Cambridge, 2004)
96. W.M.P. van der Aalst, M. Weske, D. Grünbauer, Case handling: a new paradigm for business process support. Data
Knowl. Eng. 53( 2), 129–162 (2005)
97. W.M.P. van der Aalst, H.A. Reijers, A.J.M.M. Weijters, B.F. van Dongen, A.K. Alves de Medeiros, M. Song,
H.M.W.(E.) Verbeek, Business process mining: an industrial application. Inf. Syst. 32( 5), 713–732 (2007)
98. W.M.P. van der Aalst, M. Rosemann, M. Dumas, Deadline-based escalation in process-aware information systems.
Decis. Support Syst. 43( 2), 492–511 (2007)
99. W.M.P. van der Aalst, J. Nakatumba, A. Rozinat, N. Russell, Business process simulation, in Handbook of Business
Process Management, vol. 1, ed. by J. vom Brocke, M. Rosemann (Springer, Berlin, 2010), pp. 313–338
100. I. Vanderfeesten, H.A. Reijers, W.M.P. van der Aalst, Product-based workflow support. Inf. Sci. 36( 2), 517–535
(2011)
101. L. Verner, The challenge of process discovery. BPM Trends, May 2004
102. J. vom Brocke, M. Rosemann, Handbook on Business Process Management 1: Introduction,
Methods, and Information Systems, vol. 1 (Springer, Berlin, 2010)
103. J. vom Brocke, M. Rosemann, Handbook on Business Process Management 2: Strategic
Alignment, Governance, People and Culture, vol. 2 (Springer, Berlin, 2010)
104. M. Weidlich, A. Polyvyanyy, N. Desai, J. Mendling, M. Weske, Process compliance analysis based on behavioural
profiles. Inf. Syst. 36( 7), 1009–1025 (2011)
105. M. Weidlich, H. Ziekow, J. Mendling, O. Günther, M. Weske, N. Desai, Event-based monitoring of process
execution violations, in Business Process Management—9th International Conference, BPM 2011, Proceedings, Clermont-Ferrand,
France, August 30–September 2,
2011, ed. by S. Rinderle-Ma, F. Toumani, K. Wolf. Lecture Notes in Computer Science, vol. 6896 (Springer,
Berlin, 2011), pp. 182–198
106. M. Weske, Business Process Management: Concepts, Languages, Architectures, 2nd edn.
(Springer, Berlin, 2012)
107. S.A. White, D. Miers, BPMN Modeling and Reference Guide ( Future Strategies Inc., Light-
house Point, 2008)
108. Workflow Patterns Initiative, Workflow Patterns home page (2001). http://www.
workflowpatterns.com
109. Y. Yang, M. Dumas, L. García-Bañuelos, A. Polyvyanyy, L. Zhang, Generalized aggregate quality of service
computation for composite services. J. Syst. Softw. 85( 8), 1818–1830 (2012)
110. M. zur Muehlen, Workflow-Based Process Controlling. Foundation, Design, and Implemen-
tation of Workflow-Driven Process Information Systems. Advances in Information Systems and Management
Science, vol. 6 (Logos, Berlin, 2004)
111. M. zur Muehlen, R. Shapiro, Business process analytics, in Handbook on Business Process
Management 2 ( 2010), pp. 137–157
112. M. zur Muehlen, D.E. Wisnosky, J. Kindrick, Primitives: design guidelines and architecture for BPMN models, in ACIS
2010 Proceedings ( 2010)
Index
Symbols Artifact-centric modeling, 183 Artifact, 94, 169, 183

7PMG, 176, 184 As-is, 16, 155, 172 Assessing credit risks process, 93
α- Algorithm, 360, 364,362, 366, 373, 378, 382 Association, 82, 169 ATAMO procedure, 260
Automated business process, 298 Automated task,
A 171, 237, see Task Automatic process discovery, see
Active branch, 74 Process
Activity, 3, 64, 67, 155, 156, 158, 162, 163,
172, 174, 230, 337, 360, 369, 374, 377
call, 101
compensation, 123 discovery Automation
concurrent, 67 boundary, 316, 317
decision, 68, 103, 111, 112, 124 loop,
103, 104, 147, 334 multi-instance, 104,
B
105, 124 mutually exclusive, 67 timeout,
Balanced scorecard, 217, 250 Behavioral anomaly,
118
112 Behavioral correctness, 163, 172, 181
Bill-of-material, 278, 279 Billing process, 111, 148
Activity label, 64, 159, 177, 182 Activity timeout,
Bizagi BPM Suite, 308, 330, 337 Black box, see Pool
118 Activity-based costing, 369 Activity-based
Block-structured, 95, see Process model BOM, see Bill-of-material
modeling, 183 Ad-hoc, see Sub-process Ad-hoc
Bonita Open Solution, 330, 337 BPM Centre of
workflow system, see Business
Excellence, 25 BPM Group, 25 BPM lifecycle, 14,
63 BPMN, see Business Process Model and
Process Management System Adaptive

case management system, see
Business Process Management System
Addressing ministerial correspondence
process, 103
Administration tool, 302, 304 Aggregation, 324,
326 AND gateway, see Gateway Application, see Product-Based Notation BPMN 1.2, 96 BPMN format, 327
Design Application system design, 66 BPMS, see Business Process Management
Approval, 2, 158, 162, 163, 166, 174, 180, System Branching probability, 220,
188, 190, 374, 379 237 Business fault, 114 Business function, 43
Arc, see Flow Business party, 83, 85, 113, 169, 171
Army recruitment process, 107 Arrival
rate, 225, 230, 242
M. Dumas et al., Fundamentals of Business Process Management, 391

DOI 10.1007/978-3-642-33143-5 , © Springer-Verlag Berlin Heidelberg 2013
392 Index
Business process behavior heuristic, see Clean slate approach, 261 CMMI framework, see Capability
Redesign heuristic Maturity
Business Process Management System, Model Integrated framework Code
297–302, 304, 309–317, 319, 320, 322, snippet, 327 Collaboration, see Diagram
324, 326, 328, 330–334, 336, 337, 351, 353–355 Collection, 105 Colored Petri Net, 251
ad-hoc, 307 Comalatech Ad-hoc Workflows, 307
Communication, 86, 112 Compensation, 122
adapted BPMN, 337
architecture, 299, 302–304, 306 case
handling, 308
document management system, 308 engine, 299, association, 123 handler, 122, 169 Completeness,
301, 320, 324, 327, 328, 332, 163, 173, 359, 360, 366 Component, see Business
334, 336, 341 process modeling
groupware, 307 non
BPMN, 337 language
orchestration, 308 Concurrency, 160, 169, 364, 366, 373, 375
production, 308 Consumer-produce relationship, 55 Contributing factor,
property, 327 pure 191 Control step, 188 Control-flow perspective, see Perspective
BPMN, 337 user, 322 Conversation, see Diagram Coordination, 309 Core
process, 61 Correctness, see Product-Based Design Cost,
worklist handler, 317, 319, 320, 341, 344, 171, 213, 227, 355, 356, 367, 369, 370,
346
Business Process Model and Notation, 63, 64,
79, 83, 86, 88, 97, 101, 104, 116, 125,
152, 322, 327, 328, 330–333, 337, 352
Business process modeling language, 78, 157, 374, 379
158, 163 CPN Tools, 251 Critical path, 221, 251 CRM, see Customer
component, 78 Business process model, see Process Relationship Management Customer, 4, 161, 162, 164, 167,
model Business process operation heuristic, see 177, 184,
Redesign heuristic Business rule, 124, 230, 354, 356, 367, 369, 372
300 Business value-adding step, 187 Customers heuristic, see Redesign heuristic Customer
Business-oriented, see Process model Relationship Management, 298, 334 Customer-centered, see
Organization Cycle, 103
C unstructured, 104
Camunda Fox, 330, 337 Cycle time, 15, 214, 219, 225, 239, 302, 355,
Capability Maturity Model Integrated 367, 368, 371
framework, 40 Cycle time efficiency, 224
Case, 158, 161, 163, 172, 178, 302, 354, 356,
359, 360, 363, 366, 367, 369, 371, 374, D
377, 379 Damage compensation process, 93 Data,
Case data, 313 Case handling, see Business 353, 356, 367, 370, 377 Data collection, 105
Process Data association, 79, 330 Data input, 300,
Management System Case 330
type, 43
Causal factor chart, 210 Causal factor, 191 Data object, 79, 81, 94, 162, 169, 173, 324
Cause-and-effect diagram, see Diagram electronic, 323, 324, 327, 328 physical,
Certification, 171, 174, 179 Check-in, see Work item 322 state, 81 Data output, 300, 330, 332
Check-out, see Work item Choreography, see Diagram, Data perspective, see Perspective Data
171 Claim handling process, 67 store, 81
electronic, 322, 323

Index 393
physical, 322 Data Evaluation phase, 34

type, 328, 330 Event, 3, 64, 67, 164, 167, 176, 327, 330, 333
complex, 328, 329, 331 boundary, 116, 118, 119, 169
simple, 328 catching, 109, 148 compensate, 122
Data-flow diagram, 17, see Diagram Database conditional, 124 end, 64, 115, 176,
Management System, 298, 379 DBMS, see Database 181, 364 error, 116, 117, 124, 328
Management System DCOR, see Design Chain external, 117–119 intermediate, 108,
Operations 168, 179 interrupting, 116 link, 141,
Reference model DDP, see Discovered 152
decision points DE, see Distinct execution
Deadlock, 75, 112–114, 116, 172, 181 Decision

activity, see Activity Decision point, 4, 158, 169, message, 88, 108, 109, 112, 119, 171, 327,
373 Default flow, see Flow Deployment, 300 332 multiple, 152 non-interrupting,
119, 120 signal, 120, 171, 327, 328, 332
start, 64, 176, 364, 375 terminate, 115,
Design Chain Operations Reference model, 116 throwing, 110, 148 timer, 110, 112
218 typed, 109 untyped, 109 Event label, 65
Designation phase, 34
Devil’s Quadrangle, 253, 258, 355, 367, 379 Diagram
cause-and-effect, 191
choreography, 125–128, 150, 151 collaboration, 86,
125, 128, 150, 151, 171 conversation, 153, 166
data-flow, 17 fishbone, 194 Ishikawa, 194 tree, 196 Event log, 162, 166, 174, 180, 183, 302, 353,
why–why, 191 354, 356, 360, 361, 364, 366, 367, 369,
372, 379, 383
Event variable, 327 Event-based gateway, see Gateway
Event-driven Process Chains, 17, 95
Evidence-based discovery, see Process
Disbursing home loans precess, 100 Discovered
decision points, 373, 379 Discovery, see Process discovery
discovery Distinct execution, 372, 373, 379 DMS, see Document Exception, 114, 164, 169, 171, 173, 364
Management System Document analysis, 161, 166 complex, 119 external, 117, 123 internal, 116,
117, 123 unsolicited, 117 Exception flow, see Flow
Executable, see Process model Execution engine,
Document Management System, 302, 308 Domain see Business Process
expert, 156, 157, 159, 161, 162, 164,
166, 171, 178
E Management System Execution

Electronic form, 297, 300, 301, 305, 319 Enhanced property, 316, 323, 327
Telecom Operations Map, 218 Enterprise Application BPMS-specific, 334 Explicit
Integration, 314 Enterprise Resource Planning, 297, 298, constraint, 374 Exponential
317, distribution, 230 Expression, 333
327 EPCs, see Event-driven Process
Chains Equipment, 82, 369, 372, 374 ERP, see Enterprise boolean, 333 sequence flow, 327, 333 temporal, 334
Resource Planning Error, 327, 328 Error code, 330 XPATH, 333, 334, 336, 352 Expression language, 330
EXtensible Event Stream, 357 External environment
heuristic, see Redesign
Error rate, 176, 184, 219 eTOM, see Enhanced

Telecom Operations
Map heuristic
394 Index
External quality, see Quality External I

service, 301 IBM, 41
IBM Business Process Manager, 308 IBM
F Lotus Domino Workflow, 307 IBM Lotus
Facilitator, 164 Factor, 191, 192 Fishbone Notes, 307 IDEF3, 17 Identified, 103
diagram, 194, see Diagram Fitness, 366, 375,
377 Five factor model, 159
IEEE Task Force on Process Mining, 357, 383 Implicit

termination, see Termination Inbox, 300 InConcert, 307
Flexibility, 214, 355, 367, 372, 379 Flow,
Information heuristic, see Redesign heuristic Initiator, 125
167, 327
Inner lane, see Lane Input data, 300 Input object, 327
branching, 67 default, 69,
Instantiation
124, 334 exception, 116,
169 merging, 67
message, 85, 86, 107, 114, 169, 176, 323 sequence,

64, 168, 169, 334 Flowchart, 16
Footprint matrix, 363, 365 Fraction analysis, see Product-Based explicit, 322 implicit, 322 Insurance claims
Design Functional organization, 9 Functional perspective, see process, 93 Intensity, 260 Inter-arrival time, 230,
Perspective 242 Interaction, 125, 162, 165 Interface, 303
Interface structure, 327 Internal quality, see Quality
Interview-based discovery, see Process
G
Gateway, 67–69, 70, 72, 74, 75, 76, 78, 94, 95,
164, 181, 219, 365, see also Split and join
AND, 69, 104, 116, 126, 169, 177, 380

data-based, 112, 324 event-based, 111, 114
discovery Inventory information
exclusive, 67 inclusive, 73, 74 OR, 74, 177
service, 323 Invoice checking process, 68
parallel, 69
Ishikawa diagram, see Diagram Island
automation, 310 Issue register, 198
XOR, 67, 111, 112, 160, 177, 334, 380

IT Infrastructure Library, 37, 95, 218, 261 IT-oriented, see
Generalization, 366, 367, 381 Glossary, 176
Process model ITIL, see IT Infrastructure Library
Granularity level, 316, 324 Graph-oriented, 95, 172, see Process

model Groovy, 330, 332 Groupware system, see Business
Process J
Java Universal Expression Language, 330 JavaScript,
Management System 332 Join, 67, 93, 176
H AND, 69–71, 74–76, 78, 116, 181, 221,

Handling downpayments process, 93 365, 368, 375
Handover, 167, 171, 178
OR, 74–76, 78, 95, 96 XOR, 67, 69, 71–76, 78, 181,
Helicopter pilot product data model, 279, 281,
220, 364, 368
282, 285, 287, 288
Heuristic Process Redesign, 253, 262, 276,
278, 279 K
Historic information, 311, 355, 368 Horizontal Key Performance Indicator, 214, 355, 373 Knowledge
lane, see Lane HTTP, 332 Management System, 283 KPI, see Key Performance
Indicator
Index 395
L Nested lane, see Lane Nobel prize laureates selection

Label, 64, 65 process, 147 Non-executable element, 323 Normal
Lane, 83, 85, 88, 94, 168, 171, 176, 317, 322, distribution, 238 Normative process model, 174, 374,
323, 333 379 Notation, 79
horizontal, 85 inner,
83 nested, 83 outer, 83
vertical, 85 Lean Six
Sigma, 7 Learning, 174 O
Legacy system, 314 OASIS, 95
Little’s law, 226 Observation, 161, 162, 166, 180 OMG,
95, 153 One-way, 125
Operation, 157, 161, 166, 172, 280, 383, see

Loan application assessment process, 69, 71, Product-Based Design
76, 85, 88, 119 Operational cost, 215 Operational
Log, see Event log Log file, see Event information, 311 Optionality, 373, 379
log Loop, 169, 181, 366, 371, 381 OR, 177, 334 OR gateway, see Gateway
Oracle DB, 334
count, 334 Loopback
branch, 78
Order, 1, 10, 163–165, 168, 169, 233, 359,
M 360, 373, 374, 379
M/M/1 queue, 231, 232 M/M/c, 231 Order distribution process, 72 Order fulfillment process,
M/M/c queue, 232 Maintainability, 64, 65, 71, 76, 79,
174 Mandatory, 374, 379 Manual 83, 86, 98, 99, 105, 107, 297, 317, 323,
task, see Task Manufacturing, see Process 324, 327, 328, 331, 333, 334
Manufacturing domain, 257 Merging, Organic nature, see Organization
see Token Message, 322, 327, 328 Organization
Message flow, see Flow customer-centered, 254 organic nature of, 254
Methodology, 260 Middleware, 314 process-centered, 254 Organization heuristic, see Redesign
Model heuristic Organizational change management, 20
Organizational design, 66 Organizational perspective, 82
Outcome, 4, 167
abstraction, 66 negative, 4 positive, 4,

mapping, 66 186 Outer lane, see Lane
purpose, 66, 171, 174 target Output data, 300
audience, 66
Modeling convention, 171, 175, 184
naming, 65, 176 P
Modeling guideline, 171, 175, 178, 184 Modeling Parallel repetition, see Repetition Pareto
language, see Business process analysis, 201 Pareto chart, 202 Participant, see
modeling language Modeling Process participant Participant assignment
theory, 66 Monitoring tool, 302 rule, 327 Passthrough, 69
Multi-instance, 106 Mutually exclusive, see
Activity MySQL, 334
Pattern, 160, 362, 364, 366, 371, 382 PBD, see Product-Based
Design PCF, see Process Classification Framework
Perceptive Software’s BPMOne, 302, 337 Performance, see
N Product-Based Design Performance Framework, 37
Naming convention, see Modeling convention Negative
effect, 191
396 Index
Performance measure, see Process Process hierarchy, 100 Process

performance measure identification, 15, 33
Performance objective, 216, 217 designation phase, 34 evaluation phase, 34, 38
Permission, 378 Perspective Process implementation, 20 Process instance, 64, 116,
238, 242, 299, 353,
control-flow, 79, 93, 159, 374 data,
79, 374 functional, 79 355, 369
attribute, 334 state, 64, 354, 375 Process
resource, 82, 374, 378 PICK landscape model, 42, 43, 53 Process map,
chart, 203 56, 57
Pool, 83, 86, 88, 94, 106, 112–114, 168, 169,
171, 176, 317, 322, 323, 333 Process mining, 162, 183, 353, 360, 378, 383 Process
black box, 86, 88 collapsed, 86 model, 63, 156, 171, 174, 184, 298,
white box, 86, 88 Potential owner, 316, 323, 327
333 Pragmatic quality, see Quality block-structured, 176, 228, 381 business-oriented,
Precision, 366 66, 297, 316, 317, 323,
324, 326, 333
connectivity, 152
Prescription fulfillment process, 146, 322 Primary deployment, 300
factor, 194 Private process, see Process Process diameter, 152
executable, 297, 299, 314, 316, 320, 324,
334, 337
downstream, 37 graph-oriented, 95, 172 IT-oriented, 66, 316 size,
manufacturing, 258 152, 174 structuredness, 152, 176 unstructured, 176
private, 86 public, 86 Process model repository, 300 Process model
up-stream, 37 Process structuredness, 366, 373 Process modeling tool, 300
abortion, 115 Process monitoring, 21, 302, 355, 369, 378 Process
Orchestration Server, 308 Process owner, 14, 24,
Process analysis, 19, 191, 355, 369, 383 Process 156, 163, 164, 174,
analyst, 24, 156, 157, 159, 164, 178,
183, 190
Process architecture, 15, 21, 33, 38, 43, 44, 55
business function, 45 case
type, 43, 44 180, 198, 353, 355, 373
case/function matrix, 49, 50, 53 Process participant, 24, 63, 82, 156, 160, 164,
decomposition, 45, 46, 48, 49 Process 168, 186, 243, 298–302, 304–306, 309–311, 315,
automation, 20, 383 Process capacity, 250 317, 319, 320, 323, 326,
Process case, see Process instance Process 333, 351, 353, 354, 356, 367, 370, 372,
choreography, see Diagram Process 377, 378, 382
Classification Framework, 37 Process cockpit, Process performance dimension, 213, 367 Process
356 performance measure, 214, 244, 300,
356, 367
Process controlling, 355, 378, 383 Process decomposition, Process redesign, 20, 190, 215, 255, 256
97 Process design, 22, see also Process redesign Process technical challenge, 260 Process
discovery, 16, 155, 161, 162, 165, 166, reuse, 100 Process scope, 118
Process simulation, 174, 235
178, 183, 355, 360, 366, 372, 378, 383
automated process discovery, 162 evidence-based input analysis, 237 Process variable, 327, 328
discovery, 161, 165, 166, Process-centered, see Organization Processing time, 158,
178 162, 214, 224, 231, 235,
interview-based discovery, 161, 162, 165,
166, 178, 183 368 Procure-to-pay
workshop-based discovery, 161, 164–166, process, 147 Procurement process,
178, 183 102
Index 397
Product data model, 278, 279, 281, 282 non-human, 324 Resource
Product-Based Design, 253, 261, 278 assignment, 322 Resource class, 83,
application, 281 correctness, 285, 286 fraction 106, 333 Resource classification,
analysis, 285 operation, 280 performance, 288 305 Resource contention, 229
production analysis, 284 production logic, 282 Resource parameter, 333 Resource
production rule, 280, 282, 283 source analysis, pool, 236, 242 Resource utilization,
284 source completeness, 287 top information 236 Restriction, 176
element, 281 Production workflow system, see Business
Rework, 18, 77, 102, 163, 169, 222, 371 Rework

probability, 223, 371 Role, 157, 164, 378, 383 Root
cause, 158, 196 RSS feed, 332
Process Management System Public

process, see Process Pyramid, 42 S
Sarbanes–Oxley Act, 313 Scientific
management, 9 SCOR, see Supply Chain
Q Operations
Quality, 156, 171, 172, 174, 178, 184, 213, Reference Model Screen scraping, 314
257, 356, 366, 370, 379, 383 Script task, see Task Secondary factor, 194
external, 215 Semantic quality, see Quality Semantics, 79, 171,
internal, 215 172, 174, 184 Send task, see Task Separation of
pragmatic, 171, 174, 184, 215 duties, 312, 378, 382, 383 Sequence, 64, 172, 366,
semantic, 171, 172, 179 syntactic, 171, 368, 371, 381 Sequence flow, see Flow Service,
176 Queueing system, 229 Queueing 301, 322, 327, 331, 369 Service adapter, 334
theory, 229 Queueing time, 214 Queue, Service connector, 334 Service interface, 331, 352
229 Service operation, 331
R
Race condition, 112 Racing
event, 111 Receive task, see Task
Recipient, 125 asynchronous, 331 in-only, 332 in-out, 332
synchronous, 331 Service provider, 326, 332 Service
Redesign heuristic, 259, 263 task, see Task Service time, see Processing time
business process behavior, 266 business Service-Oriented Architecture, 314 Services domain,
process operation, 264 customers, 263 257 Signal, 327, 328 Simplicity, 366 Simulation, see Process
simulation Six Sigma, 7, 214 Small claims tribunal
external environment, 271 process, 110 SOA, see Service-Oriented Architecture
information, 270 organization, 263 Software system, 82 Soundness, 172, 181, 184 Source
technology, 271, 275 Reference analysis, see Product-Based Design Source
model, 261 Repetition, 77, 102 completeness, see Product-Based
parallel, 104
uncontrolled, 107, 108
Repetition block, 77, 169
Resource, 82, 94, 106, 168, 171, 235, 300, 304,
311, 312, 324–326, 356, 371, 377, 382
active, 82
passive, 82
human, 324 Design
398 Index
Split, 67, 93, 176 Text annotation, 82, 171, 179, 322, 323 Throughput time, see
AND, 69–72, 74–76, 85, 96, 181, 221, 365 data-based, Cycle time TIBCO Business Works, 307 Ticketing system,
112, 324 event-based, 111, 114 OR, 74, 76, 85, 126, 353, 371 Time, 155, 162, 165, 166, 213, 355, 359, 367,
181
XOR, 67–69, 71–77, 85, 126, 181, 220, 371 Timeout, see Activity
334, 364, 368, 373, 375 To-be, 20, 172
SQL query, 334 Standardization, 372 State, see
Process instance Step, 162, 185, 374, 379 Token, 64, 105, 110, 181, 368, 375, 377 Token flow, 81
Straight-Through-Processing, 309 Strategic Token synchronization, 70 Tool, 260 Tool operator, 164
process, 41 Structural correctness, 172 Top information element, see Product-Based
Sub-choreography, 128
Design Tree diagram, see Diagram

Sub-process, 97, 98, 100, 105, 116, 147, 168, Two-way, 125
177
ad-hoc, 99, 102, 107, 108
collapsed, 98 embedded, 101 U
event, 121 expanded, 98 global, UEL, see Java Universal Expression Language UIMS, see User
101 Interface Management System UML Activity Diagram, 17, 95
UML AD, see UML Activity Diagram Uncontrolled repetition, see
Repetition Understandability, 162, 174, 184, 366
Supply Chain Operations Reference Model, Unstructured, see Process model Unstructured cycle, see Cycle
37, 95 Unstructured process model, 228 URL, 334 User interface,
Support process, 61 Synchronization, see Token 314
synchronization Synchronizing merge, 75 Syntactic
quality, see Quality Syntax, 78
System binding, 334 User Interface Management System, 310 User task, see
System engineer, 25 Task
T V
Target audience, see Model Validation, 171, 173, 174, 184 Validity, 173,
Task, 3, 97, 156, 158, 161, 164, 176, 235, 327, 174 Value Reference Model, 37
330, 331, 333, 354, 356, 359, 364, 367, Value-adding step, 186 Verification, 171,
368, 372, 373, 382 184 Vertical lane, see Lane Violation, 356,
automated, 317 373, 378 VRM, see Value Reference Model
loop, 333
manual, 316, 317, 319 receive, 88, 171,
319, 327, 332 script, 319, 327, 332
send, 88, 171, 319, 332 service, 319,
331 W
Waiting time, 18, 214, 224, 229, 236, 239, 367 Web
user, 317, 319, 320, 324, 326, 327, 333, technology, 327 Web service, 297, 304, 314, 317, 327,
334, 337 332,
Task variable, 327 Technical challenge, see Process 336, 352
redesign Technique, 260 Technology fault, 114 Web Services Business Process Execution
Technology heuristic, see Redesign heuristic Termination Language, 95
Web Services Description Language, 332, 352 WfMC, see Workflow
Management Coalition WfMS, see Workflow Management
System White box, see Pool
implicit, 71
Index 399
Why–why diagram, see Diagram WS-BPEL, see Web Services Business Process
Work item, 235, 299–304, 306, 309, 311–313, Execution Language WSDL, see Web
315, 319, 320, 333, 354, 360, 382 Services Description
check-in, 301, 320 check-out, 301, 319, 320 Language
Work-in-Progress, 225, 232 Workflow, 183, 184,

298 Workflow log, see Event log Workflow X
XES, see EXtensible Event Stream XML,
Management Coalition, 303
327, 329, 332, 352, 358 XML Schema,
327–329, 352
type, 328, 330, 331, 336 XOR
reference model, 351
gateway, see Gateway XPATH, see Expression
Workflow Management System, 299, 302 Workflow
XSD, see XML Schema
net, 96 Workflow pattern, 96 Worklist, see Worklist
handler Worklist handler, 300, 306, 354
Workshop-based discovery, see Process Y
YAWL, see Yet Another Workflow Language Yet Another
Workflow Language, 96 Yet Another Workflow System,
discovery 337, 352

Fundamentals of Business Process Managem-301-414.en - MK

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Fundamentals of Business Process Managem-301-414.en - MK

Uploaded by

Copyright:

Available Formats

284 8 Редизајн на процеси

Изворна анализа Изворната анализа е насочена кон идентификување на изворите на сите

Анализа на производството Анализата на производството се фокусира на идентификуваното производство

правила со цел да се проценат вмешаните трошоци, брзина и квалитет на производство на нови

сигурност на проценките за квалитет на дизајнот на процесот.

Анализа на фракции Анализата на фракциите вклучува студија за распределбата на ин-

8.4.2 Дизајн: Добивање процес од модел на податоци на производот

го опишува дизајнот на процесот.

на краиштата, тие не бараат влезови.

Слика 8.6 Правилен дизајн процес за модел на податоци за пилотски хеликоптери

активности ( Ц, А) Дизајнот во оваа насока е, според тоа,

Сл. 8.7 Алтернативен дизајн процес за модел на податоци за пилотски хеликоптери

Мотивирајте го вашиот одговор.

избор. Во таков случај, напуштање Д го инхибира потенцијалното определување на вредност за А користејќи го

Во ова поглавје, разговаравме за мотивацијата за редизајн на процесите. Adаволот четириаголник ни помогна да

регрутација на хеуристички процеси и дизајн базиран на производи.

Методологијата на редизајн на хеуристички процеси вклучува фази на иницирање, дизајн и

8.6 Решенија за вежби

е иницијатива за редизајн, нема врска за процесирање.

1. Справување со жалби од клиент: Соодветно.

3. Производство на машина за засилување на нафора: Не е многу погоден, високо физички процес.

4. Транспортирање на пакет: Нежно погоден, тука се вклучени физички ограничувања.

5. Давање финансиски совети за составување на портфолио: Погоден.

во зависност од видот на повратните информации што ги создава оваа интеракција.

се помалку запознаени со работењето.

елементи е како што следува:

Слика 8.8 Решение за предлогот за заем

Решение 8,8 Правило за производство 1. Да се ​утврди вредноста за А врз основа на Б

Правило за производство 2. Да се ​утврди вредноста за А врз основа на Д: „Ако претходниот резултат на

поминал претходен тест за соодветност.

Сл. 8.10 Ефикасен дизајн на трошоците за модел на податоци за пилотски хеликоптери

8.7 Понатамошни вежби

б) Која димензија на adаволот четириаголник би била доминантна за редизајн? Дадете точна

работат заедно како тим.

Подобрувањето на перформансите постигнато со редизајнот е извонредно. ИБМ Кредит го намали седумдневниот

редизајнирање на новиот процес?

Вежба 8.15 Разгледајте го процесот на изнајмување опрема опишан во Пример 1.1

цел решавање на проблемите документирани во Испитот-

б Фатете го како резултат моделот во BPMN.

тензии на четириаголникот на ѓаволот.

Вежба 8.16 Разгледајте го процесот на прием во универзитет опишан во вежба 1.1

цел решавање на проблемите документирани во Ексер-

тензии на четириаголникот на ѓаволот.

а Применете ја редизајнската хеуристика со цел решавање на проблемите документирани во Испитот-

б Фатете го како резултат моделот во BPMN.

тензии на четириаголникот на ѓаволот.

б Фатете го како резултат моделот во BPMN.

тензии на четириаголникот на ѓаволот.

8.8 Понатамошно читање

Редизајнската хеуристика за која се дискутираше во ова поглавје е опишано во неколку детали. По

Дизајн заснован на производи е развиен на Универзитетот за технологија во Ајндховен во соработка со

и структурите на процесот управувано од податоците развиени од Универзитетот во Улм [ 57 ] се споредливи

начин за спроведување на процеси.

Покрај црната уметност, постои само автоматизација и механизација.

9.1 Автоматизирање на деловните процеси

На пример, земете го процесот на целосна нарачка што го моделиравме во Поглавје. 3 . Ау-

гледаше нарачката електронски и ја потврдуваше со притискање на копче и слично.

М. Думас и др., Основи на управување со деловните процеси, 297

Во овој пример, испраќањето на нарачката, автоматската проверка на достапноста на производот или

9.1.1 Системи за управување со деловните процеси

Сл. 9.1 Архитектурата на BPMS

причина, тие нема да бидат во фокусот на ова поглавје.

9.1.2 Архитектура на БПМС

Решение 8,8 Правило за производство 1. Да се утврди вредноста за А врз основа на Б

Правило за производство 2. Да се утврди вредноста за А врз основа на Д: „Ако претходниот резултат на