KNOW INTUIT, Лекция, Моделиране на бизнес процеси с помощта на BPwin

Моделирането на бизнес процеси обикновено се извършва с помощта на инструменти за казуси. Тези инструменти включват BPwin (технология PLATINUM), Silverrun (технология Silverrun), Oracle Designer (Oracle), Rational Rose (Rational Software) и др. Функционалността на инструментите за моделиране на структурни бизнес процеси ще бъде разгледана с помощта на инструмента за казуси BPwin като пример.

BPwin поддържа три методологии за моделиране: функционално моделиране ( IDEF0 ); описание на бизнес процеси ( > диаграми на потока от данни ( DFD ).

BPwin Workbench

BPwin има доста прост и интуитивен потребителски интерфейс. Когато стартирате BPwin, по подразбиране се появява основната лента с инструменти, палитра с инструменти (чийто външен вид зависи от избраната нотация) и от лявата страна навигаторът на модела - Model Explorer (фиг. 7.1).

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

Както бе споменато по-горе, BPwin поддържа три методологии - IDEF0 , >DFD , всяка от които решава свои специфични задачи. В BPwin е възможно да се изграждат смесени модели, т.е. един модел може да съдържа едновременно IDEF0 и >DFD диаграми. Съставът на палитрата с инструменти се променя автоматично при превключване от една нотация към друга.

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

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

Процесът на моделиране на система в IDEF0 започва със създаването на контекстна диаграма - диаграма на най-абстрактното ниво на описание на системата като цяло, съдържаща дефиницията на обекта на моделиране, целта и гледната точка върху модела.

Субектът се разбира като самата система, докато е необходимо да се установи точно какво е включено в системата и какво е извън нея, с други думи, да се определи какво ще се разглежда по-нататък като компоненти на системата и какво като външно влияние. Определянето на предмета на системата ще бъде значително повлияно от позицията, от която се разглежда системата, и целта на моделирането - въпроси, на които конструираният модел трябва да отговори. С други думи, в началото е необходимо да се определи областта на моделиране. Описанието на площта както на системата като цяло, така и на нейните компоненти е основата за изграждане на модела. Въпреки че се предполага, че зоната може да бъде коригирана по време на симулацията, тя обикновено трябва да бъде формулирана първоначално, тъй като областта е тази, която определя посоката на симулацията. ПриПри формулирането на площ трябва да се вземат предвид два компонента - ширина и дълбочина. Ширината предполага определяне на границите на модела – какво ще се разглежда вътре в системата и какво ще бъде извън нея. Дълбочината определя на какво ниво на детайлност е завършен моделът. При определяне на дълбочината на системата е необходимо да се имат предвид ограниченията във времето - сложността на изграждане на модел нараства експоненциално с увеличаване на дълбочината на декомпозиция. След определяне на границите на модела се приема, че не трябва да се въвеждат нови обекти в моделираната система.

Целта на симулацията

Целта на моделирането се определя от отговорите на следните въпроси:

Защо трябва да се моделира този процес?
Какво трябва да показва моделът?
Какво може да получи един клиент?

Гледна точка (Viewpoint).

Гледната точка се разбира като перспективата, от която е наблюдавана системата при изграждането на модела. Въпреки че гледните точки на различни хора се вземат предвид при изграждането на модел, всички те трябва да се придържат към една и съща гледна точка по отношение на модела. Гледната точка трябва да съответства на целта и границите на симулацията. По правило се избира гледната точка на лицето, отговорно за моделираната работа като цяло.

Моделът IDEF0 предполага наличието на ясно дефинирана цел, един обект на моделиране и една гледна точка. За да въведете областта, целта и гледната точка в модела IDEF0 в BPwin, изберете елемента от менюто Модел / Свойства на модела, който извиква диалоговия прозорец Свойства на модела (фиг. 7.3). В раздела Purpose въведете целта и гледната точка, а в раздела Definition дефинирайте модела и опишете областта.

Модели AS-IS и TO-BE. Обикновено първо се изгражда модел на съществуващата организация на работа – AS-IS (както е). Анализът на функционалния модел позволяваразберете къде са най-слабите места, какви ще бъдат предимствата на новите бизнес процеси и колко дълбоки промени ще бъдат направени в съществуващата структура на бизнес организацията. Детайлизирането на бизнес процесите ви позволява да идентифицирате недостатъците на организацията, дори когато функционалността на пръв поглед изглежда очевидна. Недостатъците, открити в модела AS-IS, могат да бъдат коригирани при създаването на модела TO-BE (както ще бъде) - модел на нова организация на бизнес процесите.

Технологията за проектиране на IS предполага първо създаване на модел AS-IS, неговия анализ и подобряване на бизнес процесите, тоест създаване на модел TO-BE, и само на базата на модела TO-BE се изгражда модел на данни, прототип и след това окончателната версия на IS.

Понякога настоящите AS-IS и бъдещите TO-BE модели са много различни, така че преходът от първоначалното към крайното състояние става неочевиден. В този случай е необходим трети модел, който описва процеса на преход от първоначалното към крайното състояние на системата, тъй като такъв преход също е бизнес процес.

Резултатът от описанието на модела може да бъде получен в Доклада за модела. Диалоговият прозорец за настройки на отчета на модела се извиква от елемента от менюто Инструменти/Отчети/Отчет на модела.

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

На фиг. 7.5 показва отчет, генериран от горните полета.