Изпратете добрата си работа в базата знания е лесно. Използвайте формата по-долу

Студенти, докторанти, млади учени, които използват базата от знания в обучението и работата си, ще ви бъдат много благодарни.

публикувано на http://www.allbest.ru

публикувано на http://www.allbest.ru

Въведение

Моделирането на бизнес процесите в контекста на модернизацията на икономиката и управлението е важна област, която помага за оптимизиране на процесите на организацията и подобряване на бизнес ефективността. Говорейки за моделиране на бизнес процеси, ще използваме терминологията на няколко области на знанието, свързани с икономиката, компютърните науки, моделирането сложни системи. Затова ще дефинираме основните определения и понятия.

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

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

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

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

Проблемът на тази курсова работа звучи така: колко практично да се използват (опростени, визуални и информативни) диаграми, проектирани в MS Visio.

Обектът е бизнес моделиране.

Нека обозначим като предмет: моделиране на бизнес процеси на предприятие, което се занимава с предоставяне на услуги в автомобилния транспорт, в MS Visio.

Въз основа на проблема, нека да определим целта: да определим колко практични са диаграмите, проектирани в MS Visio, като използвате пример транспортна компания(TK) EcoTrans LLC.

За постигането на тази цел е необходимо да се решат следните задачи:

Намерете и проучете методологии за моделиране на бизнес процеси;

Запознайте се с бизнес графиките в MS Visio;

Анализирайте бизнес процесите на TC "EcoTrans" LLC

Опишете бизнес процесите на TC LLC "EcoTrans", използвайки бизнес моделиране в Microsoft Visio

За да моделирате бизнес процеси, можете да използвате различни методи. Методът или методологията на моделиране включва последователността от действия, които трябва да бъдат извършени, за да се изгради моделът, т.е. процедурата за моделиране и приложената нотация (език). В това срочна писмена работаМетодологиите , IDEF0, IDEF3 ще бъдат използвани за моделиране на бизнес процеси.

1. Методика за описание на предметната област

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

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

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

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

1.1 Разбиране на фамилията стандарти IDEF

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

Методологията IDEF е създадена като част от програмата за индустриална компютъризация ICAM (Integrated Computer Aided Manufacturing) в Съединените щати, по време на която беше разкрита необходимостта от разработване на методи за анализ на процесите на взаимодействие в производствени системи. Оттук и името на това семейство стандарти - Icam DEFinition - IDEF.

Понастоящем следните стандарти могат да бъдат приписани на семейството IDEF:

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

IDEF1 - методология за моделиране на информационни потоци в рамките на система, която ви позволява да показвате и анализирате тяхната структура и връзки;

IDEF1X (IDEF1 Extended) – методология за изграждане на релационни структури. IDEF1X принадлежи към типа методологии за връзка между обекти (ER) и обикновено се използва за моделиране на релационни бази данни, подходящи за разглежданата система;

IDEF2 е методология за динамично моделиране на еволюцията на системите. Във връзка с много сериозните трудности при анализа на динамични системи, този стандарт беше практически изоставен и неговото развитие беше спряно в най-началния етап.

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

IDEF4 е методология за изграждане на обектно-ориентирани системи. Инструментите IDEF4 ви позволяват визуално да показвате структурата на обектите и основните принципи на тяхното взаимодействие, като по този начин ви позволяват да анализирате и оптимизирате сложни обектно-ориентирани системи;

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

Нека разгледаме по-подробно стандартите, които ще се изискват при описване на бизнес процеси в тази курсова работа, това са: IDEF0, IDEF3.

Функционална методология IDEF0.

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

Методологията се основава на четири основни понятия: функционален блок, интерфейсна дъга, декомпозиция, речник.

а) Кутия за дейности е някакъв вид специфична функцияв рамките на разглежданата система. Съгласно изискванията на стандарта името на всеки функционален блок трябва да бъде формулирано в устно настроение (например „да произвежда услуги“). На диаграмата функционалният блок е представен с правоъгълник (Фигура 1.1). Всяка от четирите страни на функционалния блок има свое специфично значение (роля), като:

Горната страна е "Контрол";

Лявата страна е "Вход";

Дясната страна е настроена на "Изход";

Долната страна има стойността "Механизъм" (Механизъм).

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

Всяка функционална единица в разглежданата единна система трябва да има свой собствен уникален идентификационен номер.

Фигура 1.1 - Функционален блок

b) Интерфейсна дъга (стрелка) представлява системен елемент, който се обработва от функционален блок или по друг начин засяга функцията, представена от този функционален блок. Интерфейсните дъги често се наричат ​​потоци или стрелки.

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

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

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

Задължителното присъствие на контролни интерфейсни дъги е една от основните разлики между стандарта IDEF0 и другите методологии на класовете DFD (Диаграма на потока от данни) и WFD (Диаграма на работния поток).

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

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

Моделът IDEF0 винаги започва с оглед на системата като цяло - единичен функционален блок с интерфейсни дъги, простиращи се извън разглежданата област. Такава диаграма с един функционален блок се нарича контекстна диаграма и се обозначава с идентификатора "A-0" (Фигура 1.2).

Фигура 1.2 - Пример за контекстна диаграма

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

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

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

В процеса на декомпозиция функционалният блок, който в контекстната диаграма показва системата като цяло, е детайлизиран в друга диаграма. Получената диаграма от второ ниво съдържа функционални блокове, които показват основните подфункции на функционалния блок на контекстната диаграма и се нарича дъщерна диаграма (Дете диаграма) по отношение на нея (всеки от функционалните блокове, принадлежащи към дъщерната диаграма, е съответно наречен дъщерен блок - Child Box). От своя страна функционалният блок - предшественикът се нарича родителски блок по отношение на дъщерната диаграма (Parent Box), а диаграмата, към която принадлежи - родителска диаграма (Parent Diagram). Всяка от подфункциите на дъщерната диаграма може да бъде допълнително детайлизирана чрез подобно разлагане на съответния й функционален блок. Важно е да се отбележи, че във всеки случай на разлагане на функционален блок, всички интерфейсни дъги, включени в този блок или изходящи от него, се фиксират върху дъщерната диаграма. Това постига структурната цялост на модела IDEF0. Принципът на разлагане е ясно показан на фигура 1.3. Трябва да обърнете внимание на връзката между номерацията на функционалните блокове и диаграмите - всеки блок има свой уникален сериен номер на диаграмата (номерът в долния десен ъгъл на правоъгълника), а обозначението в десния ъгъл показва номера на дъщерната диаграма за този блок. Липсата на това обозначение показва, че няма разлагане за този блок.

Често има случаи, когато няма смисъл да продължаваме да разглеждаме отделни интерфейсни дъги в дъщерни диаграми под определено ниво в йерархията, или обратното – отделните дъги нямат практически смисъл над определено ниво. Например интерфейсна дъга, изобразяваща „детайл“ на входа на „Процес на струг” няма смисъл да отразявате диаграми от по-високи нива - това само ще претовари диаграмите и ще ги направи трудни за четене. От друга страна, има нужда да се отървем от отделните "концептуални" интерфейсни дъги и да не ги детайлизираме по-дълбоко от определено ниво. За разрешаване на подобни проблеми стандартът IDEF0 предвижда концепцията за тунелиране. Обозначението на „тунела“ (Arrow Tunnel) под формата на две скоби около началото на интерфейсната дъга означава, че тази дъга не е наследена от функционалния родителски блок и се появява (от „тунела“) само на тази диаграма. На свой ред същото обозначение около края (стрелка) на дъгата на интерфейса в непосредствена близост до приемния блок означава, че тази дъга няма да бъде показана и няма да бъде взета предвид в дъщерната диаграма на този блок. Най-често се случва отделни обекти и съответните им интерфейсни дъги да не се разглеждат на някои междинни нива на йерархията - в този случай те първо се „потапят в тунела“ и след това, ако е необходимо, „се връщат от тунела“.

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

Стандарт за документация на процеса IDEF3.

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

Документацията и инструментите за моделиране на IDEF3 ви позволяват да изпълнявате следните задачи:

Документирайте наличните данни за технологията на процеса, идентифицирани, да речем, в процеса на интервюиране на компетентни служители, отговорни за организирането на съответния процес;

Определяне и анализ на точките на влияние на потоците на съпътстващия работен процес върху сценария на технологичните процеси;

Идентифицирайте ситуации, в които е необходимо решение, което засяга кръговат на животапроцес, например, промяна в дизайна, технологичните или експлоатационните свойства на крайния продукт;

Съдейства за приемането на оптимални решения при реорганизацията на технологичните процеси.

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

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

На следващ пример, ще опишем как графичните инструменти IDEF3 ни позволяват да документираме горното производствен процесдетайлно оцветяване. Като цяло този процес се състои директно от самото боядисване, което се извършва на специално оборудване, и етапа на неговия качествен контрол, който определя дали частта трябва да бъде пребоядисана (в случай на несъответствие със стандартите и се открие брак ) или изпратени за допълнителна обработка.

Фигура 1.4 показва диаграмата на PFDD, която е графично представяне на сценария за обработка на част. Правоъгълниците в PFDD диаграмата се наричат ​​функционални елементи или поведенчески елементи (Unit of Behavior, UOB) и представляват събитие, стъпка на процес или решение. Всеки UOB има собствено име, показано в словесното настроение, и уникален номер. Стрелките или линиите представляват движението на детайла между UOB блоковете по време на процеса.

Фигура 1.4 - Диаграма PFDD на сценария за обработка на част

Обектът, отбелязан с J1, се нарича кръстовище. Crossroads се използват за показване на логиката на взаимодействието на стрелките (потоците) при сливане и разклоняване или за показване на набор от събития, които могат или трябва да бъдат завършени преди започване на следващата работа. Има кръстовища за сливане (Fan-in Junction) и разклонения (Fan-out Junction) стрелки. Пресечната точка не може да се използва едновременно за сливане и разклонение. Когато добавяте пресечна точка към диаграма, трябва да укажете типа на пресечната точка. Класификацията на възможните типове кръстовища е дадена в таблица 1.

Таблица 1 - Класификация на видовете кръстовища

Име	Значение в случай на сливане на стрелки (Входен вентилатор)	Значение в случай на ветрилообразно кръстовище
Асинхронно И	Всички предходни процеси трябва да бъдат завършени	Всички процеси по-долу трябва да се изпълняват
	Всички предходни процеси са завършени по едно и също време	Всички от следните процеси се изпълняват едновременно
	Един или повече предходни процеси трябва да бъдат прекратени	Един или повече от следните процеси трябва да се изпълняват
	Един или повече предшестващи процеси се прекратяват по едно и също време	Един или повече от следните процеси се изпълняват едновременно
XOR (изключително ИЛИ)	Завършен е само един предходен процес	Само един следващ процес започва

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

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

Всеки UOB функционален блок може да има последователност от декомпозиции и следователно може да бъде детайлизиран до желаната точност. Под декомпозиция имаме предвид представяне на всеки UOB с отделна IDEF3 диаграма. Например, можем да разложим UOB на частта за боядисване, като я представим като отделен процес и изградим наша собствена PFDD диаграма за нея. В този случай тази диаграма ще се нарича дъщерна диаграма във връзка с тази, показана на Фигура 1.4, и тази, съответно, родителска. Номерата на UOB на дъщерните диаграми са последователно номерирани, т.е. ако родителският UOB има номер "1", тогава UOB блоковете при неговото разлагане ще имат съответно номерата "1.1", "1.2" и т.н. Прилагането на принципа на декомпозиция в IDEF3 ви позволява да описвате процесите по структуриран начин с всяко необходимо ниво на детайлност.

Ако PFDD диаграми технологичен процес„От гледна точка на наблюдателя“, тогава друг клас на диаграма IDEF3 – OSTN ви позволява да разгледате същия процес „От гледна точка на обекта“. Фигура 1.5 показва дисплея на процеса на оцветяване от гледна точка на OSTN диаграмата. „Състояния на обекта“ (в нашия случай подробности) и „Промяна на състоянието“ са ключовите понятия на OSTN диаграмата. Състоянията на обекта се показват като кръгове, а промените им като насочени линии. Всеки ред има връзка към съответния функционален блок UOB, което е довело до промяна в състоянието на обекта, който представлява.

Фигура 1.5 - Процес на оцветяване по отношение на OSTN диаграма

2. Инструменти за моделиране на бизнес процеси

За да опишем бизнес процесите, има много инструменти BPWin, ERWin, PowerDesigner, Business Studio, ELMA BPM, Visual Paradigm и др.

В горния списък можете да добавите Microsoft Visio, който принадлежи към водещата фамилия офис продукти, произведени от лидера в софтуерната индустрия. Разбира се, той не е толкова функционален по отношение на моделирането на бизнес процеси, но е много популярен и масов поради относително ниската си цена.

2.1 Технически характеристики. Хранилище за данни

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

Ако е необходимо, наборът от символи, включен в продукта, може да бъде разширен със символи, създадени от потребителя. Няма глобални ограничения за правилата и възможността за създаване на връзки между определени типове символи в продукта, но в него е наличен механизмът на така наречените диаграмни шаблони, чието използване ви позволява да ограничите набора от символи, достъпни директно в съответната лента с инструменти по време на процеса на моделиране. Шаблоните могат да се създават от потребителите, а продуктовият пакет включва набор от готови шаблони (Фигура 2.1).

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

Фигура 2.1 - Набор от готови шаблони на MS Visio

2.2 Поддържани методологии и нотации

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

3. Анализ на предметната област LLC "EcoTrans"

Транспортна фирма ЕкоТранс ООД е основана през 2008г. Първите транспортни услуги са предоставени на потребители, които правят бизнес в района на Орлов. много най-големите предприятиярегиони подписаха дългосрочни договори с компанията за превоз на товари и пътници. За EcoTrans LLC услугите за превоз на товари (регион Орлов) в региона се превърнаха в успешен старт за по-нататъшно развитие. Днес географията на транспортните услуги стъпи далеч отвъд родния регион. Разширяването на географията на дейността му изисква увеличаване на броя на съвременните камиони, поради което за доставка на стоки вече се използва не само собственият му богат автопарк, но и превозните средства на партньори.

EcoTrans LLC не само осигурява превоз на товари в Русия, но също така предоставя на клиентите свързани услуги, като спедиция и застраховка на товари.

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

Декор задължителни документи. Товарителни листове, митнически декларации, документи на застрахователни компании и др. документите, както и тяхното подписване, вече не засягат клиента;

Избор на превозно средство. Вземат се предвид теглото на товара, неговите размери и маршрут;

Планиране на маршрута. Избира се най-бързият и безопасен модел на движение;

Решаване на други проблеми, които възникват по пътя.

б) Застраховка на товари. Всичко може да се случи с товара по пътя. Може да бъде повреден, развален, откраднат и т.н. За да елиминирате тези рискове Застрахователни компаниизастраховате товара, транспортните разходи за доставката му и дори част от очакваната печалба.

Мисията на ЕкоТранс ООД е да предоставя висококачествени, високопрофесионални транспортни услуги на клиентите с цел установяване на дългосрочни партньорства със съществуващи потребители и привличане на нови.

3.1 Организационна структураЕкоТранс ООД

В ЕкоТранс ООД генералният директор докладва на: Главен счетоводител, Главен инженер, Електроинженер, Системен администратор. Счетоводителят докладва на главния счетоводител. Складодържателят докладва на счетоводителя. Подчинен на главния инженер: складовик, механик, медицински работник, диспечер. На диспечер са подчинени: механик, шофьори на автомобили, шофьори на автобуси, шофьори на товарач. На механиците подлежат: шофьори на автомобили, шофьори на автобуси, водачи на мотокари.

3.2 Бизнес процес „Превоз на товари“

Бизнес процесът "Превоз на товари" включва:

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

2 Сключване на договора. Между клиента и директора се сключва договор, въз основа на който се извършва превозът.

3 Проверка за наличие на договор. Диспечерът ще провери наличието на договора.

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

5 Издаване на пътен лист. Диспечерът се обажда на водача, информира го за предстоящия полет и маршрут и издава пътен лист.

6 Преминаване на медицински преглед. Водачът е на медицински преглед.

7 Маркирайте за преминаването на медицински преглед. Здравният работник определя алкохолното съдържание и психотропни веществав тялото, здравословно състояние: измерва пулс, кръвно налягане, температура, установява степента на умора и качеството на съня. При успешно преминаване на медицинския преглед медицинският работник поставя отметка в пътния лист.

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

9 Забележка за изправността на автомобила в пътния лист. Водачът отбелязва проверката на превозното средство в пътния лист.

10 Проверка на МПС. Водачът предоставя автомобила за преглед от механик. Механикът оглежда автомобила. Проверява: херметичност и работа на спирачни системи, захранващи системи, охладителни системи, системи за отработени газове; изправност на кормилно управление, външни светлинни устройства, чистачки; закрепване на колелата; наличие на комплект за първа помощ, пожарогасител, знак за аварийно спиране.

11 Отбележете изправността на автомобила в пътния лист. Механикът поставя отметка за изправността на автомобила в пътния лист.

12 Доставка. Шофьорът тръгва на линията, взима товара на определеното място, доставя товара на получателя.

13 Приемане на документи. Шофьорът получава товарителницата от клиента.

14 Връщане от линията. Шофьорът от линията се връща в гаража.

15 Проверка на МПС. При връщане от линия водачът предоставя автомобила за преглед от механика.

16 Отбелязване на състоянието на автомобила в пътния лист. Механикът поставя отметка за състоянието на автомобила в пътния лист.

17 Предаване на документи в счетоводството. Шофьорът изпраща товарителницата в счетоводството.

18 Издаване на документи от счетоводния отдел. Счетоводният отдел изписва документи: акт за извършена работа, фактура, фактура за плащане.

19 Заплащане на услугата от клиента. Счетоводният отдел изпраща издадените документи за плащане на клиента. Клиентът заплаща за извършената услуга.

3.3 ИТ инфраструктура

моделиране на информационни мрежи

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

LAN - локална мрежа (LAN, локална мрежа).

В организацията EcoTrans LLC, LAN е направена според звездната топология.

ИС на обекта на проучването използва директорийната услуга на Microsoft Corporation - Active Directory. Тази услуга се използва за регулиране на групови политики на домейн. Домейните имат йерархична структура.

В хардуерната част на обект ИС: 2 сървъра; 16 работни станции.

Софтуер на EcoTrans LLC: операционна система Windows XP Servise Pack 2/3, MS Office 2007, антивирусен софтуер - Panda Antivirus Platinum, Юридическо лице на данъкоплатеца, 1C: Счетоводство, 1C: Заплата и човешки ресурси, PP "Директория на сертификати", CIPF Crypto Pro CSP, PP " СТЕК-Тръст" ". Работна станция "TRUST-Client", Система "STEK-Trust". Застрахована работна станция, FSS Utility, Documents PU 5, CheckXML, Canon Solution Menu, ABBYY FineReader Professional Edition, Total Commander, WinDjView, Adobe Acrobat Professional, WinRAR и др.

4. Описание на бизнес процесите на TC LLC "EcoTrans" с помощта на бизнес моделиране в Microsoft Visio

4.1 Изграждане на модел в нотация IDEF0 и неговата декомпозиция

Нека създадем модел на търговски център LLC "EcoTrans" според методологията IDEF0. Първо, нека изградим контекстна диаграма на бизнес процеса „Превоз на товари“ (Фигура 4.1). Съгласно нотацията IDEF0, нека наречем този функционален блок "Транспортни товари".

Фигура 4.1 - Контекстна диаграма на процеса "Превоз на товари".

След това ще разделим бизнес процеса „Превоз на товари“ на компоненти: „Обработка на заявки“, „Сключване на договор“, „Подготовка за превоз на товари“, „Плащане на документи, необходими за превоз на товари“, „Превоз на товари“. И съответно разлагаме функционалния блок „Транспортни товари“ (Фигура 4.2).

Фигура 4.2 - Декомпозиционна диаграма на процеса "Превоз на товари".

Нека разгледаме по-подробно бизнес процесите: „Обработка на приложения“ (Фигура 4.3); „Подготовка за транспортиране на стоки“ (Фигура 4.4); „Оформяне на документи, необходими за превоз на стоки“ (Фигура 4.5); „Изпълнение на превоз на товари“ (Фигура 4.6).

Фигура 4.3 - Декомпозиционна диаграма на процеса "Обработка на приложение".

Фигура 4.4 - Диаграма на разлагане на процеса "Подготовка за транспортиране на стоки"

Фигура 4.5 - Декомпозиционна диаграма на процеса "Изпълнение на документи, необходими за превоз на стоки"

Фигура 4.6 - Декомпозиционна диаграма на процеса "Изпълнение на превоз на товари"

4.2 Изграждане на модел в нотация IDEF3

Сега нека изградим модел на TC LLC "EcoTrans", използвайки методологията IDEF3. Декомпозицията на процеса „Превоз на товари“ е показана на Фигура 4.7

Фигура 4.7 - PFDD диаграма на декомпозицията на процеса "Превоз на товари".

Символът "", означава "Изключително ИЛИ", той също е "XOR" (Изключително ИЛИ).

Заключение

В хода на изучаването на темата „Описание на бизнес процесите на предприятие, занимаващо се с предоставяне на услуги за автомобилен транспорт в MS Visio“, беше определено значението на описанието на бизнес процесите за оптимизиране на процесите на предприятието.

Възможно е описание на бизнес процеси различни начини: текстови, таблични, графични. За да ги опишем, има много методологии (IDEF0, IDEF3, DFD, WORKFLOW, UML, ARIS и други) и инструменти (BPWin, ERWin, PowerDesigner и други).

За да се опишат бизнес процесите на TC LLC "EcoTrans" в графична форма, бяха избрани методологиите за моделиране на бизнес процеси IDEF0, IDEF3. Моделирането е извършено с помощта на продукта на Microsoft - Visio. Тази програма има готов шаблон за моделиране в нотацията IDEF0, а за IDEF3 трябваше да създам собствен набор от елементи. Това потвърждава ниската функционалност, но в същото време липсата на глобални ограничения в процеса на проектиране.

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

Ако вземем предвид наличието на програмата Microsoft Visio за руския потребител, нейната лекота на използване и вземем предвид нововъзникващите предимства на графичното моделиране на бизнес процеси, може да се твърди, че диаграмите, проектирани в MS Visio, имат достатъчна практичност за голям брой потребители.

Литература

1 Голичев В.Д., Голичева Н.Д., Гусарова О.М. Актуални въпроси на икономиката и управлението в условията на модернизация. Колективна монография. - Смоленск: Smolgortipografiya, 2014. - 212с.

2 Гусарова О.М. Моделиране на бизнес резултати в управлението на организация // Перспективи за развитие на науката и образованието. - Тамбов: Business-Science-Society, 2014. - p. 42-43.

Хоствано на Allbest.ru

...

Подобни документи

Задържане предпроектно проучванепредприятия. Изграждане на модел на организационно-функционалната структура на фирмата. Създаване на организационна схема в MS Visio. Списък и структура на документите, които се генерират от информационната система.

практическа работа, добавена на 14.02.2012 г


Моделирането на бизнес процесите като средство за намиране на начини за оптимизиране на дейността на компанията. SADT методология (структурен анализ и дизайн), IDEF семейството от стандарти и алгоритмични езици в сърцето на методологиите за моделиране на бизнес процеси.

резюме, добавено на 14.12.2011 г


Архитектура на интегрирани информационни системи ARIS като методология за моделиране на бизнес процеси, предимства и недостатъци на използване. Избор на бизнес процес за моделиране и неговото съдържателно описание, табличен формат за неговото описание.

курсова работа, добавена на 19.06.2015 г


Предназначение на Microsoft Visio. Набори от изображения на обекти от определени типове. Софтуерни изисквания. Характеристики на потребителския интерфейс. Функции, операции и методи на работа на Microsoft Visio. Взаимодействие на дизайнера с приложенията.

контролна работа, добавена на 19.12.2010 г


Същност, значение и методология на моделирането на бизнес процеси. История на развитието на методологиите за моделиране. Систематизиране на знанията за фирмата и нейните бизнес процеси във визуална графична форма за аналитична обработка на получената информация.

резюме, добавено на 29.04.2009 г


Основната цел на описанието на UML. Описание на основните компоненти, свързани с Microsoft Visio. Създаване на диаграми на класове в Microsoft Visio 2010 Структурата на системата, нейният клас, техните атрибути и оператори.

практическа работа, добавена на 07.05.2014 г


Проектиране на локална мрежа. Избор на мрежова топология, архитектура и структура на системата. Анализ на информационните потоци в разпределена система, избор на симулационна система. Определяне на разходите за създаване и развитие на системата.

дисертация, добавена на 21.05.2015 г


Управление на дистанционна конфигурация и инсталиране на софтуер. История на разработката на VMware ThinApp. Създаване на автоматичен инсталационен пакет за Microsoft Office Visio Professional 2007. Софтуерен анализ за него. Тестване на получения msi пакет.

курсова работа, добавена на 14.03.2013 г


Сравнителен анализхотелски информационни системи. Анализ и избор на CASE инструменти за моделиране на бизнес процеси. визуални и математически моделпредметна област, избор на архитектура и платформа на информационната система, изграждане на база данни.

дисертация, добавена на 20.07.2014 г


Microsoft Visio среда: концепция, основни функции. Функция AutoConnect в Office Visio 2007. Функция за лог-вероятност. Графика на вероятностите за грешка на версията на софтуера. Визуално моделиране в UML. Обща формакласови диаграми.

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

Проста блокова схема

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

Упражнение 1

Ориз. 3.3.Проста блокова диаграма (стъпка 3)

8. Въведете текст във формите на блок-схемата (вижте Фигура 3.4). За да въведете текст във фигура, изпълнете следните стъпки:

9. Таб У домав група Обслужванеизберете инструмент показалец.

• Щракнете върху формата, в която искате да въведете текст.
• Въведете желания текст.

Забележка:

1. За да увеличите мащаба на фигурата, натиснете клавишната комбинация + и щракнете с левия бутон върху формата, докато достигнете желания мащаб.
2. За да намалите мащаба на фигурата, натиснете клавишната комбинация на клавиатурата + и щракнете с десния бутон върху формата, докато достигнете желания мащаб.

Ориз. 3.4.Проста блокова диаграма (стъпка 4)

Номериране на фигури в блокова схема

Visio може да номерира формите в блок-схема. За да зададете опции за номериране, в раздела Прегледв група Макросищракнете върху бутона добавкии изберете в групата Допълнителни решения на Visioкоманда Номерация на фигури. В отворения прозорец Номерация на фигурипосочете желаните опции за номериране и щракнете върху бутона Добре.

Задача 2

1. В блок-схемата, изготвена по време на задача 1, добавете автоматично номериране на всички фигури (вижте Фиг. 3.6).

   За това:

   • В раздела Прегледв група Макросищракнете върху комбиниран бутон добавки, изберете група Допълнителни решения на Visio, а в него командата Номерация на фигури.
   • В отворения прозорец Номерация на фигурипосочете параметри
     • раздел Общ:
       • Операция - Автономерация;
       • Прилагане към - Всички фигури;
       • Започнете от - 1;
       • Интервал - 1;
       • Поставете отметка в квадратчето Продължаване на номерирането на фигури при плъзгане върху страницата.
     • В раздела Допълнително:
       • Номер на място - Преди текста на формата;
       • Ред на номериране - отляво надясно, отгоре надолу;
       • Поставете отметка в квадратчето Изключете свързващите линии.
     • Щракнете върху бутона Добре.
2. Запазете блоковата диаграма.

Ориз. 3.6.Проста блокова диаграма (стъпка 6)

Промяна на блок-схемата

Добавяне на форма между две други форми

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

Изтриване на форма

За да премахнете фигура от блок-схемата, изберете фигурата и щракнете на клавиатурата.

Преномериране на фигури

За да преномерирате формите на блок-схемата, направете следното:

1. В раздела Прегледв група Макросищракнете върху бутона добавкии изберете в групата Допълнителни решения на Visioкоманда Номерация на фигури.
2. В отворения прозорец Номерация на фигурираздел Общизберете радио бутон Преномерирайте в същия ред, посочете стартов номерза номериране и щракнете Добре.

Задача 3

1. Променете блок-схемата, изготвена в задача 2:
   • Изтриване на фигура Документ(Подаде заявление).
   • Между фигури Решение(Молбата е попълнена правилно) и Документ(Изпращане на отказ) поставете фигурата Процес(Напред към асистента на търговското изложение).
   • Добавяне на форма Процес(Обадете се на изложителя относно плащането) фигурата по-долу Документ(изпратете фактура).
   • Преномерирайте формите на блок-схемата в същия ред, като започнете с първоначалния номер - 1.
2. Запазете блоковата диаграма.

Ориз. 3.7.Проста блокова диаграма (стъпка 7)

Препозициониране на свързани форми

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

Ако промените оформлението на блок-схемата, тя може да не се побира на страницата на документа. В този случай променете размера на страницата (таб Конструктор, Група Настройки на страницата, комбинираното поле Размер) или неговата ориентация ( Конструктор, Група Настройки на страницата, комбиниран бутон Ориентация).

Задача 4

Функционална блокова схема

Цел на оформлението Функционална блокова диаграма

Оформление Функционална блокова схемае предназначен да показва връзката между бизнес процес и организационни или функционални единици, като например отдели, отговорни за изпълнението на стъпките на този процес.

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

Задача 5

Добавяне, преместване, изтриване на песен

За допълненияпроследява във функционална блокова диаграма, направете едно от следните неща:

• Щракнете с десния бутон върху съществуваща писта на диаграмата и изберете елемента от контекстното меню. Поставете "Track" предиили Вмъкнете "Track" след.
• Задръжте курсора на мишката върху ъгъл на една от песните. Щракнете върху синята стрелка, която се появява Вмъкване на форма на път.
• В раздела Функционална блокова схемав група ПоставетеНатисни бутона Писта. Песента ще бъде добавена след избраната песен или в края на лентата, ако не е избрана песен.
• От набор от елементи Форми на функционална блокова диаграмаплъзнете пистата до желаното място на границата на лентата.

За денивелацияпесни:

1. Щракнете върху заглавието на записа, който искате да преместите, за да го изберете. Показалецът на мишката ще се промени на икона за движение.
2. Плъзнете песента до желаното място.

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

За отстраняванепесни:

1. Щракнете върху етикета на записа, който искате да премахнете.
2. Натиснете клавиш на клавиатурата.

Забележка. Изтриването на песен изтрива и всички форми, които съдържа.

Често ме питат - какво да чета за бизнес процесите?
Един от най-добрите сайтове в Runet е www.klubok.net. Аз самият "израснах" във форума и статиите в този сайт. Много статии не са загубили своята актуалност дори и сега. Препоръчвам да започнете с него.

Но ако говорим за книги, мога уверено да кажа най-добрата книгаза бизнес процесите е книга, написана от Репин и Елиферов: "Бизнес процеси на компанията. Изграждане, анализ, регулиране".

Описание на бизнес процесите: стремеж към простота.

Статията разглежда въпросите за избора на нотация за описване на процеси с цел последващо регулиране. Често използваните нотации на Work Flow се сравняват една с друга, като например: „Simple flowchart“ в MS Visio, „Procedure“ на Business Studio, ARIS eEPC нотация и други.

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

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

Въведение

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

Сравнение на означения

За сравнение бяха избрани следните обозначения за описание на процеса:

1. "Опростена блок-схема" (с показване на движението на документи, използвайки блока "Решение");
2. "Проста блокова схема" (без показване на движението на документи, без използване на блокове "Решение");
3. "Процедура" на системата Business Studio (една от настроикипредставителство);
4. ARIS eEPC.

За тестов случай беше избран прост и интуитивен процес. Резултатите от описанието на този процес са представени на фиг. 1-4.

Ориз. 1. Диаграма на процеса в нотацията "Проста блок-схема" в MS Visio (с движение на документи, използвайки блока "Решение").

На диаграмата на фиг. 1. Последователността на процесните операции във времето е показана с дебели стрелки, а движението на документите е показано с тънки пунктирани стрелки. Блокове "Разтвор" се използват по класически начин. Те показват информация (въпроси), от която „зависи“ последващият ход на процеса. Този подход към използването на "диаманти" е много разпространен. Но всъщност цялата логика на вземане на решения и формирането на определени резултати (документи) трябва да се съдържат в операциите на процеса. Ако се замислите, стойността (смисълът) на рисуването на тези "диаманти" не е очевидна. Кои са тези обекти: процесни операции, събития? Изглежда, че не е нито едното, нито другото. Това са по-скоро твърдения за вземане на решение при някакво условие. Но в крайна сметка ние разработваме диаграма на процеса за хората, а не пишем компютърна програма на специален език. AT компютърна програма"диамант" би била пълноценна операция за сравняване на условия и т.н. Но на диаграмата на процеса трябва да покажете реални обекти - процеси, извършвани от хора, документи, Информационни системии т.н. Помислете, правилно ли е да показвате "диаманти" отделно от операцията на процеса на диаграмата? Вместо това можете:

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

Нека формулираме „плюсовете“ и „минусите“ на горния (фиг. 1.) метод за използване на „диаманти“.

„Опростена блок-схема“ в MS Visio (с движение на документи, използвайки блока „Решение“)
"Професионалисти"	"Минуси"
Визуално показване на "логиката" на избора на определени изходи на процеса. Фокусиране на вниманието на изпълнителя върху точката на решение / разклоняването на процеса в зависимост от условията.	Премахване на логиката за вземане на решения „извън“ на операцията на процеса (неправилно от гледна точка на формалната декомпозиция на процесите). Неудобно е да документирате процеса (трябва да дублирате „диамантите“ с текст, когато формирате текстово описание на операцията). Диаграмата на процеса се претоварва с информация. „Диамантите“ често се използват твърде официално, без реална нужда.

На фиг. 2. показва пример за същия процес, само описан без използване на блокове и документи "Решение". Лесно се проверява, че в тази диаграма има 24 графични елемента по-малко, отколкото в диаграмата на фиг. 1. Схема фиг. 2. изглежда много по-просто. От графичните елементи не заслепява, но от гледна точка на информативността тази схема е доста разбираема и достъпна за крайния потребител. Ако за всяка операция на процеса изискванията за нейното изпълнение са описани в текст, тогава чрез комбиниране на табличните и графична формапредставителство, е възможно да се опише адекватно процедурата за изпълнение на процеса за служителите на компанията.

Ориз. 2. Диаграма на процеса в нотацията "Проста блок-схема" в MS Visio (без движение на документи, без използване на блока "Решение").

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

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

На фиг. 3. представена е диаграмата на процеса, формирана в нотацията "Процедура" на средата за моделиране Business Studio. Схемата има няколко характеристики. Първо, блоковете "Решение" не се използват по стандартен начин - не като графичен елемент за показване на въпрос и разклоняване, а като пълноценна операция на процеса на вземане на решение. В Business Studio „ромбът“ има почти всички атрибути на пълноценен процес, но не може да бъде разложен (може би разработчиците на системата ще направят това възможно след време). Използването на "ромб" (вместо четириъгълник) прави диаграмата по-ясна. В същото време всяка текстова информация: описание, начало, край, изискване за краен срок и др.

Втората характеристика на диаграмата на процеса, показана на фиг. 3., е използването на стрелки. За да покажете последователността от операции, можете да използвате стрелка с един връх - стрелката за "предимство". Можете да използвате стрелка с два върха, за да покажете движението на документите. Но в Business Studio можете да използвате само един вид стрелка - стрелките за "предимство". В същото време можете да се свържете с наименувани стрелки необходимо количестводокументи, които са определени в указателя на обектите на дейност. Този подход позволява:

• значително намаляване на броя на графичните елементи на диаграмата на процеса и в същото време:
• показване на необходимата информация за входящи и изходящи документи в правилника за процеса.

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

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

Ориз. 3. “Процедура” на системата Business Studio (вариант с нетрадиционно използване на блокове “Решение”).

В случай на използване на Business Studio, нотацията „Процедура“ може да се използва по малко по-различни начини. Авторът на статията клони към подхода, представен на фиг. 3.

На фиг. Фигура 4 показва диаграма на разглеждания процес, разработена в нотацията ARIS eEPC. Имайте предвид, че някои операции на процеса не се побират на диаграмата. Тази непълна диаграма на най-простия процес, направена в ARIS eEPC нотация, съдържа четири логически оператора и осем събития! Човекът, който чете диаграмата, трябва да може да интерпретира правилно всички тези логически оператори. Без специално обучение и някои умения за четене на такива диаграми, обикновеният служител едва ли ще може да разбере логиката на въпросния процес без подробно текстово описание или помощта на квалифициран бизнес анализатор.

Имайте предвид, че диаграмата на процеса в нотацията ARIS eEPC заема значително повече място от диаграмите, показани на фиг. 1-3. Сложността на формирането на такава схема също е значително по-висока.

Диаграма на процеса в нотация ARIS eEPC (вградена в Business Studio)
"Професионалисти"	"Минуси"
При формирането на схемата се поддържа строга формална логика на процеса. Всички събития, възникващи по време на процеса, са ясно дефинирани.	Трудност на възприятието. Значителна сложност на формирането на схемата. Служителите трябва да имат специални умения и опит в тълкуването на подобни схеми. излишък на информация. Заема твърде много място, което е неудобно за документация.

Като цяло, ако няма да купувате SAP R / 3, тогава изборът и използването на нотацията ARIS eEPC не е оптималното решение от гледна точка на автора на статията. Струва си да се обърне внимание на по-визуална и интуитивно разбираема нотация за описания на процеси. За някои обаче нотацията ARIS eEPC може да изглежда по-ясна и разбираема. До известна степен е въпрос на вкус.

Ориз. 4. Диаграма на процеса в ARIS eEPC нотация (изградена в Business Studio).

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

Интересно е да се разгледа въпросната диаграма на процеса, ако е описана в нотацията BPMN 2.0. Тази нотация има за цел да опише "изпълними" процеси, т.е. процеси, поддържани от BPM системата.

Вашето мнение относно използването на BPMN 2.0. дялове А.А. Белайчук - изпълнителен директорФирма "Бизнес Конзола":

На фиг. 5 показва същия процес в BPMN нотация. Както виждаме, тази фигура е подобна на фигура 1: в нотацията на BPMN задачите са представени с правоъгълници, вилиците - с диаманти, данните - с икона, подобна на документ. Контролните потоци са плътни линии, потоците от данни са пунктирани. Трябва да се отбележи, че само малка част от нотацията на BPMN е включена в тази диаграма: само един тип разклонение от 5 налични в палитрата, един тип задачи от 8. В допълнение към по-широката палитра, тази нотация е отличава се със способността да се моделира не само изолиран работен поток, но и няколко процеса, взаимодействащи един с друг чрез съобщения или данни. Освен това тази нотация е по-строга: тя определя не само иконите, но и правилата, по които те могат да се комбинират помежду си. Необходимостта от такива правила е продиктувана от факта, че BPMN нотацията е фокусирана не само върху факта, че хората ще я прочетат, но и върху директното изпълнение от специален софтуер- "двигател" BPM-система. В същото време, както показва този пример, когато се използва ограничено подмножество от палитрата, BPMN не е по-сложен от позната блок-схема. Е, за тези, които искат професионално да овладеят BPMN, препоръчваме специализирано обучение www.bpmntraining.ru.

Ориз. 5. Диаграма на процеса в нотация BPMN 2.0.

Житейска практика

На фиг. Фигура 6 показва фрагмент от диаграма на процес, разработена от бизнес анализатори на много специфична компания в обозначението, което те са измислили. Схемата е изградена на принципите на "Простата блокова схема" - блокът "Решение" се използва в класическия си вариант. Освен това диаграмата показва много други символи, използвани по нестандартен начин.

При формиране на схемата на фиг. 6, бизнес анализаторите очевидно са се "борили" за видимост и максимална яснота за средния потребител. Те се стремяха да сведат до минимум или дори да премахнат текстовите коментари върху диаграмите на процесите. Изпълнителите просто отпечатаха диаграма във формат А3, при четене на която всичко веднага стана ясно: какво да правите, как, какви документи да използвате и т.н.

Разглежданата схема, разбира се, не е пример за простота и яснота. Но той е създаден, за да предаде максимум полезна информация на изпълнителите на процеса.

заключения

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

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

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

В.В. Репин, д-р, доцент, Изпълнителен директор BPM Consulting Group LLC, ръководител. Отдел за управление на бизнес процеси NOU HPE "IEF "Synergy", основател на портала www.FineXpert.ru

Именно тези прости принципи се опитвам да предам на бизнес лидерите, които са очаровани от красивите презентации. софтуерни продуктичесто забравят, че един прост контролен списък често е по-добър от 10 страници наредби.

Лабораторна работа №1

организационен дизайн

Теоретична обосновка

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

За решаване на различни бизнес проблеми е необходимо процесите да се опишат подробно и визуално. Тоест да изграждат своите модели. Моделите са предназначени за Подробно описаниеоперации, извършвани последователно във времето по определена технология.

Фигура 1.1 - Модел на "процес"

Има различни възможности за графично, таблично, текстово описание на процесите. Нека да разгледаме как да създадем графична диаграма на бизнес процес с помощта на софтуерния инструмент Microsoft Visio. На първо място, струва си да се каже, че продуктът Visio не е включен в стандартния пакет на Microsoft Office.

Методически указания за изпълнение на работата:

Стартираме програмата с помощта на бутона "Старт" или чрез пряк път на работния плот.

Фигура 1.2 - Основният прозорец на програмата MS Visio 2010

Фигура 1.3 - Основният прозорец на програмата MS Visio 2003

Първото нещо, което ще видим след стартиране на програмата, е прозорец, който ни подканва да изберем типа графична конструкция, от която се нуждаем, от предложените категории. За нашите цели избираме категорията „Бизнес процеси“. Тук ще видим различни варианти на диаграми, използвани за описание както на процеси, така и на диаграми на потоци. Например поток от данни или работа; междуфункционални диаграми.

От предложените опции за описание на процесите в менюто изберете опция EPC Diagramm.

Нов файл може да се създаде и в режим на работа с отворени други файлове, през главното меню. Изберете Файл - Нов (Нов) - Бизнес процес (Бизнес процес) - и типа, от който се нуждаем - ePC диаграма.
Менюто отляво съдържа обектите, които ще използваме при изграждането на диаграмата на процеса.

- Събитие

‒ Функция

‒ Изпълнител

И логически оператори: и, изключително или, неизключително или.

Фигура 1.4 - Обекти за изграждане на диаграма на процеса

Използването на софтуерния инструмент Microsoft Visio е удобно, лесно и достъпно за използване за изграждане на графични диаграми на бизнес процеси.

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

Упражнение 1. Правила за конструиране на диаграми на процеси в нотация epC

Ние сме в софтуерния пакет Visio и разглеждаме представяне на бизнес процес, наречен Event - driven Process Chain - или EPC. Схема от този типудобен, лесен за четене и активно използван в практиката. Нека анализираме подробно как правилно да изградим диаграма на процеса. Ще използваме обектите, които се намират в менюто вляво.

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

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

Нека се опитаме да изградим определена верига от действия. За да не задаваме свойствата на обекта всеки път, ще използваме функцията за копиране. За да направите това, изберете обекта с десния бутон на мишката, щракнете върху „копиране“ и след това върху „поставяне“. Допълнителните обекти могат да бъдат изтрити с помощта на бутона на лентата с инструменти или клавиша Delete на клавиатурата.

На практика всяко произведение се изпълнява от някакво лице, изпълнител. За да посочите изпълнителя, изберете обект. Например жълт овал. И го поставяме задължително вдясно от Функцията, като не забравяме да посочим организационната единица. Това може да бъде отдел, група, отдел или просто позицията на изпълнителя. Свързваме нашия обект с други чрез комуникационна линия. В този случай линията трябва да е права - без начални и крайни стрелки.

Настроики

1. Резервация на билети.

2. Покупка през онлайн магазин.

3. Закупуване на апартамент.

4. Банково кредитиране.

5. Свързване с кабелна телевизия.

6. Отдаване под наем на търговски площи.

7. Назначаване на лекар.

8. Поддръжка.

9. Хотел.

10. Застрахователна компания.

11. Библиотека.

12. Курсове за повишаване на квалификацията.

13. Товарен транспорт.

14. Коли под наем.

15. Инвестиране на свободни средства.

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

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

- настройвам външен видорганизационна схема.

Приложение 1

Проверка на коректността на диаграмата

ТП1 Правно изпълнение на договора

Правило 1:Функционалната диаграма на EPC трябва да започва с поне едно начално събитие (началното събитие може да следва интерфейса на процеса) и да завършва с поне едно крайно събитие (крайното събитие може да предхожда интерфейса на процеса).

Няма открити грешки.

Правило 2:С напредването на процеса събитията и функциите трябва да се редуват (събитие и функция могат да бъдат свързани чрез оператори).

Няма открити грешки.

Правило 3:Събитията и функциите трябва да съдържат точно една входяща и една изходяща връзка, които отразяват напредъка на процеса.

Няма открити грешки.

Правило 4:Диаграмата не трябва да съдържа неназовани връзки.

Няма открити грешки.

Правило 5:Едно събитие не трябва да бъде последвано от оператор "OR" или "XOR".

Няма открити грешки.

Правило 6:Всеки оператор за сливане трябва да има поне две входящи връзки и само една изходяща, операторът за разклоняване трябва да има само една входяща връзка и поне две изходящи. Операторите не могат да имат множество входящи и множество изходящи връзки едновременно.

Няма открити грешки.

Правило 7:Операторите могат да комбинират или разклоняват само елементи от един и същи тип. Обединяването или разклоняването на функции и събития по едно и също време не е възможно.

Няма открити грешки.

Правило 8:Всяка функция трябва да има връзка „изпълнява“ с поне един и до три субекта.

Няма открити грешки.

Правило 9:На диаграмата едно и също събитие трябва да присъства само веднъж.

Няма открити грешки.

Лаборатория №1

Задачата за описание на бизнес процеси с помощта на MS Visio.

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

За целите на моделирането в този пример ще разгледаме опростен процес за продажба на собствено произведен продукт.

Най-добре е да започнете директното моделиране, като посочите името и изясните границите на процеса. Границите могат да бъдат фиксирани веднага под формата на събития на диаграмата. В нашия пример граничните събития биха били „Идентифицирана нужда на клиента“ и „Потребност, подкрепена от взаимен ангажимент“ (вижте Фигура 3).

Ориз. 3. Наименование и граници на процеса

За по-лесно четене на диаграмите, описанието на процеса трябва да започва в горния ляв ъгъл (виж фиг. 4). Нарушаването на това правило е нежелателно, но е възможно, ако по някаква причина редът на изпълнителите / песните е първоначално зададен и първите задания в процеса принадлежат на песента, разположена в средата или в долната част.

Всяка работа/процедура в диаграмата на процеса трябва да бъде оформена като цялостен блок с логически граници под формата на събития и документи. Тези логически граници ви позволяват да разберете по-добре и по-добре да структурирате процеса.

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

Опростен пример за описание на процеса е показан на фиг. 5.

Ориз. 5. Опростен пример за описание на процеса

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