Методът на компанията, наречен Structured Process Analysis (SPA), използва принципи, извлечени от теорията за моделиране на данни. Основава се на принципа на йерархията на процесите. Както вече стана ясно, един процес може да бъде разделен на съставните му подпроцеси. Ако процесът, който се изследва, обхваща няколко отдела, тогава самите подпроцеси вероятно ще бъдат доста сложни и могат да включват типове работа, извършвана от повече от един отдел. Можем допълнително да разделим всеки подпроцес на основните типове работа, извършвана в него, и всеки тип, от своя страна, на отделни работи. Например процесът по наемане на нов служител включва работа по обявяване на съществуваща свободна позиция, работа по описание на работата и изискванията към кандидата. Това от своя страна включва индивидуална работа като изисквания за писане на кандидата в текстов редактор.

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

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

Начини за описание на бизнес процеси

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

В момента има три основни метода за описание:

1. Текст: „Отделът по продажбите изготвя споразумение и го съгласува с правния отдел.“

2. Табличен.

3. Графичен.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ориз. 9.1. V

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

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

Първичните клиенти са тези, които получават първична продукция;

Вторични клиенти, които са извън процеса и получават вторични изходи;

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

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

Външни непреки клиенти, потребители.

Няма твърди и бързи правила за това колко широко или тясно да се опишат процесите и фирмите могат да опишат дори подобни процеси по различен начин. Основните категории могат да бъдат разширени с допълнителни. Класификацията на бизнес процесите на предприятието според основните характеристики е представена в табл. 9.1.

Таблица 9.1. КЛАСИФИКАЦИЯ НА БИЗНЕС ПРОЦЕСИТЕ НА ПРЕДПРИЯТИЕТО

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

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

Курсов проект

по дисциплина: “Проектиране на информационни системи”

Проектиране на АИС "Център за развитие на децата"

Изпълнил: студент 4 курс

Тихонова К.В.

Въведение

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

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

Целта на този курсов проект е да се разработи АИС „Център за развитие на децата“. За постигането на тази цел трябва да бъдат изпълнени няколко задачи:

1. Анализирайте тази предметна област;

2. Разработване на модели на бизнес процеси;

3. Въз основа на резултатите от анализите да се създаде информационна система.

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

Глава 1. Анализ на обекта на изследване и разработване на модели на неговото функциониране

Описание на предметната област

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

Основните задачи на Центъра за развитие на децата:

1) привличане на клиенти;

2) регистрация на деца в детския център;

3) провеждане на образователни и развиващи занятия, както и лечебни и рехабилитационни процедури;

4) обобщаване на дейностите на детето;

5) освобождаване на детето от детския център.

Насоки на работа на Центъра за развитие на децата:

Курсове за възрастово развитие, а именно:

*Курсове за деца от 9 месеца до 1,5 години

*Курсове за деца от 1,5 до 2,5 години

*Курсове за деца от 2,5 до 4 години

*Курсове за деца в подготовка за училище от 4 до 7 години, включващи английски език, детско творчество, математика и логика, околна среда, четене и писане.

*Занимания с психолог

*Занимания с логопед

*Развиващи клубове, като: гимнастика, изобразително изкуство, театрална дейност, музика, танци. Организационната структура на Центъра за развитие на децата е показана на фигура 1.1.

ориз. 1.1. Организационна структура на детския център

1.2 Структурен анализ на бизнес процесите

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

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

Етапи на описание на бизнес процесите:

Определяне целта на описанието.

Описание на средата, определяне на входове и изходи на бизнес процес, изграждане на IDEF0 диаграми.

Описание на функционалната структура (действия на процеса), изграждане на IDEF3 диаграми.

Описание на процесните потоци (материални, информационни, финансови), изграждане на DFD диаграми.

Изграждане на организационната структура на процеса (отдели, участници, отговорници). Фигура 1.2 показва контекстна диаграма на информационната система „Център за развитие на децата“, изградена с помощта на BPwin:

Фиг.1.2. Контекстна диаграма

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

За да се гарантира функционирането на процеса, са необходими персонал по поддръжката и оборудване за обучение. Има и такива входни документи като „Закони на Руската федерация“, „Нормативна документация“ и „Лиценз“, което показва легитимността на работата на Центъра за развитие на децата. Резултатът от работата на цялата система е „Обобщаване на резултатите от учебния процес” и „Отписване на детето от детския център”.

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

Фигура 1.3 показва по-подробно описание на процесите. Целият процес е разделен на 4 етапа. На първия етап детето се регистрира в центъра за развитие, след което се съставя дневник за посещаемостта на ученика. На втория етап квалифицирани специалисти изготвят индивидуална учебна програма за всяко дете, след което се изготвя съответен график за тези часове. На третия етап се провеждат образователни и развиващи класове и терапевтични процедури, след което учители и лекари. от персонала се изисква да извърши окончателен одит на дейността си. И на последния етап се обобщават резултатите както от работата на персонала, така и от придобитите умения и знания на детето като цяло, след което се организира освобождаването на детето от центъра за развитие.

За получаване на по-подробна информация беше извършено разлагане с трето ниво на детайлност. Фигура 1.4 показва декомпозиционна диаграма на процеса „Изготвяне на индивидуална учебна програма“.

Фиг. 1.4 Декомпозиционна диаграма „Изготвяне на индивидуална учебна програма“.

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

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

Фиг. 1.5 Диаграма на разлагане на DFD „Провеждане на класове“

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

След това, използвайки IDEF3, процесът „Регистрация на дете в детски център“ беше декомпозиран. IDEF3 показва причинно-следствени връзки между ситуации и събития в разбираема за експерт форма, използвайки структуриран метод за изразяване на знания за това как функционира система, процес или предприятие.

Фиг. 1.6 IDEF3 декомпозиционна диаграма „Регистриране на дете“

При разработването на организационната структура на предприятието въз основа на методологията за реинженеринг на бизнес процеси, една от първите и най-важни стъпки е да се анализира дейността на предприятието. Анализът започва с идентифициране и описание на бизнес процесите, протичащи в предприятието.
Разработването на модел за реинженеринг на бизнес процеси (BP) за една организация е сложна задача, чието решаване изисква използването на специални техники и инструменти, базирани на методите на структурния анализ.
Структурният анализ обикновено се нарича метод за изследване на система, който започва с общ преглед на нея и след това преминава в детайли, придобивайки йерархична структура с нарастващ брой нива. Тези методи се характеризират с:
- разделяне на нива на абстракция с ограничение на броя на елементите на всяко ниво (обикновено от 3 до 7, като горната граница съответства на способността на човешкия мозък да възприема определен брой
взаимосвързани обекти, а долният е избран от съображения за здрав разум);
ограничен контекст, включващ само подходящи подробности на всяко ниво;
използване на строги формални правила за запис;
последователен подход към крайния резултат. Методите за структурен анализ позволяват да се преодолее сложността на големите системи чрез тяхното разделяне на части („черни кутии“) и йерархично организиране на тези „черни кутии“. Предимството на използването на черни кутии е, че потребителят не трябва да знае как работят. Трябва само да знаете неговите входове и изходи, както и неговата цел (т.е. функцията, която изпълнява). В света около нас „черните кутии“ се срещат в големи количества: магнетофон и телевизор на битово ниво, предприятие от гледна точка на клиента и т.н.
По този начин, първата стъпка в опростяването на сложна система е да се раздели на „черни кутии“ (принципът „разделяй и владей“ - принципът за решаване на трудни проблеми чрез разделянето им на много независими задачи, които са лесни за разбиране и решаване ), и такова разделение трябва да отговаря на следните критерии:
всяка „черна кутия” трябва да изпълнява една единствена функция на системата;
функцията на всяка „черна кутия“ трябва да бъде лесно разбрана, независимо от сложността на нейното внедряване (например система за управление на ракета може да има черна кутия за изчисляване на нейното място за кацане: въпреки сложността на алгоритъма, функцията на черната кутия е очевидна - изчисляване на точката на кацане);
връзка между "черни кутии" трябва да се въведе само ако има връзка между съответните функции на системата (например в счетоводството една черна кутия е необходима за изчисляване на общата заплата на служител, а друга - за изчисляване на данъци .Необходимата връзка между тези "черни кутии" е размерът на таксите за печалба, необходими за изчисляване на данъците);
- връзките между черните кутии трябва да са възможно най-прости, за да се осигури независимост между тях.
Втората важна идея в основата на структурните методи е идеята за йерархията. За да разберете една сложна система, не е достатъчно да я разделите на части, необходимо е тези части да се организират по определен начин, а именно под формата на йерархични структури. Всички сложни системи на Вселената са организирани в йерархии. А самата тя включва галактики, звездни системи, планети, молекули, атоми и елементарни частици. Така вторият принцип на структурния анализ (принципът на йерархичното подреждане), в допълнение към факта, че е по-лесно да се разбере даден проблем, ако той е разбит на части, заявява, че подреждането на тези части също е от съществено значение за разбирането. Разбираемостта на даден проблем нараства драстично, когато неговите части са организирани в дървовидни йерархични структури, тоест системата може да бъде разбрана и изградена на нива, всяко от които добавя нови детайли.
Трети принцип: структурните методи използват широко графични обозначения, които също служат за улесняване на разбирането на сложни системи. Известно е, че „една снимка струва колкото хиляда думи“.
За целите на структурния анализ традиционно се използват три групи инструменти, илюстриращи:
функции, които системата трябва да изпълнява;
връзки между данни;
¦ зависимо от времето поведение на системата (аспекти в реално време).
Сред разнообразието от графични обозначения, използвани за решаване на изброените проблеми, следните са най-често и ефективно използвани в методологиите за структурен анализ:
DFD (Data Flow Diagrams) - диаграми на потока от данни заедно с речници на данни и спецификации на процеси (мини-спецификации);
ERD (Entity-Relationship Diagrams) - диаграми entity-relationship;
STD (State Transition Diagrams) - диаграми за преход на състояния.
Всички те съдържат инструменти за графично и текстово моделиране: първият - за удобство на показване на основните компоненти на модела, вторият - за осигуряване на точна дефиниция на неговите компоненти и връзки.


Л
Класическият DFD показва източници на данни и приемници (дестинация) извън системата, идентифицира логически функции (процеси) и групи от елементи на данни, които свързват една функция с друга (нишки), а също така идентифицира хранилища на данни (устройства), до които има достъп. Структурите на потока от данни и дефинициите на техните компоненти се съхраняват и анализират в речник на данни. Всяка логическа функция (процес) може да бъде детайлизирана с помощта на DFD от по-ниско ниво; когато допълнителните подробности вече не са полезни, преминете към изразяване на логиката на функцията с помощта на спецификация на процеса (мини-спецификация). Съдържанието на всяко хранилище също се съхранява в речник на данни, моделът на данните на хранилището се излага с помощта на ERD. В случай на реално време, DFD се допълва чрез описание на зависимото от времето поведение на системата, разкрито с помощта на STD. Тези взаимоотношения са показани на фигура 2.3.
Изброените по-горе графични обозначения се използват (в един или друг набор) в почти всички съвременни методологии за анализ на структурни системи. Ролята на тези методологии е да регулират основите на разработването на сложни системи. Те описват последователността от стъпки, модели и подходи.
Понастоящем почти всички известни методологии за структурен анализ се използват успешно, но най-разпространените са:
SADT (Structured Analysis and Design Technique) методологии;
анализ на структурни системи от Gane-Sarson;
структурен анализ и проектиране Йодана-Де Марко (Yourdon-DcMarko);
Jackson Systems Development;
разработване на структурни системи Warnier-Oppa (Warmer-Orr);
анализ и проектиране на системи в реално време от Ward-Mellor и Hatley;
информационно моделиране Мартин (Мартин).
Изброените структурни методологии стриктно регулират фазите на анализ на изискванията и проектиране на спецификация и отразяват подхода на „готварска книга“ към разработката на системата.
Основните символи и термини на DFD (в нотация на Jodane) са представени на фигура 2.4.
Потоците от данни са механизми, използвани за моделиране на трансфера на информация (или физически компоненти) от една част на система към друга. Потоците в диаграмите обикновено се представят с именувани стрелки, чиято ориентация показва посоката, в която тече информацията. Понякога поток може да се движи в една посока, да бъде обработен и да се върне обратно към същия източник. Тази ситуация може да се моделира или от два различни потока, или от един двупосочен.
Целта на процеса е да произвежда изходни потоци от входни потоци в съответствие с действието, указано от името на процеса. Това име трябва да съдържа глагол в неопределена форма, последван от обект. Освен това всеки процес трябва да има уникален номер за справка в диаграмата. Този номер може да се използва заедно с номера на диаграмата, за да се осигури уникален индекс на процеса за целия модел. Обозначение на компонент Обозначение на компонент Име на поток от данни > Име на поток на управление Процес ^Име^ Процес на управление > \ t ъ
f Име j
* /
4 U
^ t y Име на хранилището Име на съхранението на контрола Име на външния обект Име на възела за промяна на името Възел на групата Възел за промяна на типа име Фигура 2.4 - Основни символи на диаграма на потока от данни
Съхранението (устройство) на данни (материали) ви позволява да дефинирате данни в определени области, които ще се съхраняват в паметта между процесите. На практика складът представлява „резени“ от потоци от данни във времето. Информацията (суровини, полуготови продукти), която съдържа, може да се използва по всяко време след дефинирането й, а данните (обектите) могат да бъдат избрани в произволен ред. Името на хранилището трябва
идентифицирайте съдържанието му и бъдете съществително. В случай, че поток от данни влиза или излиза от склад и неговата структура съвпада със структурата на склада, той трябва да има същото име, което не е необходимо да се показва на диаграмата.
Външен обект (или терминатор) представлява обект извън системния контекст, който е източник или приемник на системни данни. Името му трябва да съдържа съществително име, например склад за стоки. Обектите, представени от такива възли, не се очаква да участват в никаква обработка.
Декомпозицията на DFD се основава на декомпозиция на процеса - всеки процес може да бъде разширен с помощта на DFD от по-ниско ниво.
Важна специфична роля в модела играе специален тип DFD - контекстна диаграма, която моделира системата по най-общ начин. Контекстната диаграма отразява интерфейса на системата с външния свят, а именно информационните потоци между системата и външните обекти, с които тя трябва да бъде свързана, както и обикновено един процес, който отразява основната цел или естеството на системата, що се отнася до нея Може би. И въпреки че контекстната диаграма изглежда тривиална, нейната несъмнена полезност се крие във факта, че тя установява границите на анализираната система. Всеки проект трябва да има точно една контекстна диаграма и няма нужда да номерирате единствения му процес.
Първото ниво DFD е изградено като декомпозиция на процеса, който присъства в контекстната диаграма.
Изградената диаграма от първо ниво също има много процеси, които от своя страна могат да бъдат декомпозирани в DFD от по-ниско ниво. Това изгражда DFD йерархия с контекстна диаграма в основата на дървото. Този процес на декомпозиция продължава, докато процесите могат да бъдат ефикасно описани с помощта на кратки (до една страница) спецификации за минипроцесиране (спецификации на процеса).
С тази конструкция на йерархията на DFD всеки процес от по-ниско ниво трябва да бъде свързан с процес от по-високо ниво.
Индивидуалните данни в една система често са независими. Понякога обаче е необходимо да се работи с няколко независими данни едновременно. Например, системата има потоци „ябълки“, „портокали“ и „круши“. Тези нишки могат да бъдат групирани чрез въвеждане на нова нишка "плод". За да направите това, е необходимо формално да дефинирате потока „плод“ като състоящ се от няколко наследствени елемента. Такива потоци, съчетаващи няколко потока, се наричат ​​групови потоци. Обратната операция, разделяне на потоци на подпотоци, се извършва с помощта на групов възел, който ви позволява да разделите поток на произволен брой подпотоци.
Декомпозицията на потоците през границите на диаграмата се извършва по подобен начин, което прави възможно опростяването на подробния DFD. Нека има поток FRUIT, включен в детайлизирания процес. В диаграма на потока, описваща подробно този процес, може изобщо да няма „плодове“, но вместо това може да има потоци „ябълки“ и „портокали“ (като че ли са прехвърлени от детайлизирания процес). В този случай трябва да има BNF дефиниция на потока FRUIT, състоящ се от подпотоци "ябълки" и "портокали", за целите на балансирането.
Използването на тези операции върху данни позволява структуриране на данните и увеличава видимостта и четливостта на диаграмите.
За да се осигури декомпозиция на данни и някои други възможности за услуга, към DFD се добавят следните типове обекти:
групов възел. Проектиран за разделяне и сливане на потоци. В някои случаи може да отсъства (т.е. действително да се изроди в точка на сливане/разделяне на потоци на диаграмата);
възел за промяна на името. Позволява ви да наименувате двусмислено потоци, докато съдържанието им е еквивалентно. Например, ако по време на проектирането на различни части на системата една и съща част от данните получи различни имена, тогава еквивалентността на съответните потоци от данни се осигурява от възела за промяна на името. В този случай един от потоците от данни е вход за този възел, а другият е изход;
контролен процес. Той представлява интерфейса между DFD и контролните спецификации, които всъщност моделират и документират аспекти в реално време. Неговото име показва вида на контролната дейност, произведена от спецификацията. Всъщност контролният процес е преобразувател на входни контролни потоци в изходни контролни потоци; в този случай точното описание на тази трансформация трябва да бъде посочено в контролната спецификация;
контролирайте съхранението. Представлява „отрез“ от контролния поток във времето. Съдържащата се контролна информация може да се използва по всяко време след въвеждането й в хранилището, като съответните данни могат да се използват в произволен ред. Името на контролното хранилище трябва да идентифицира неговото съдържание и да бъде съществително. Контролното съхранение се различава от традиционното съхранение по това, че може да съдържа само контролни нишки; всички останали характеристики са идентични;
контролният поток е "тръба", през която протича контролна информация. Името му не трябва да съдържа глаголи, а само съществителни и прилагателни. Обикновено контролният поток е по-скоро дискретен, отколкото непрекъснат. Това може да бъде например сигнал, представящ състоянието или вида на операцията.
Логично, контролният процес е вид команден пункт, който реагира на промените във външните условия, предадени към него, използвайки контролни потоци, и произвежда команди, изпълнявани от процеси в съответствие с неговата вътрешна логика;
възел за промяна на типа - потокът от данни е входът за този възел, а контролният поток е изходът. Например, потокът от данни за „скорост на машината“ в някои случаи може да се използва като контрол за контрол на критичната стойност.
По този начин разработчиците на BP модели стигнаха до извода, че най-простият начин за стандартизиране на такава работа е да се въведат правила за графичното представяне на BP и интерпретацията на тези
графични изображения. Тези правила, естествено, трябва да бъдат признати от една или друга авторитетна общност. Този метод стана най-ефективен с появата на първите софтуерни инструменти, които автоматизират дейността на екипи от модни дизайнери, обединяващи усилията си в рамките на един проект. Има доста реализации на разглеждания метод и те са свързани главно с конкретен CASE инструмент. Все пак вече можем да говорим за някои исторически потвърдени метатенденции.
Сравняването на съществуващи инструменти е изключително труден процес поради сложността на инструментите и идеите, изискващи много знания, вградени в тях. Обективната слабост на сравнителните мотивации, дадени от специалистите в областта на реинженеринга на бизнес процесите, се дължи на трудността или нецелесъобразността да се овладеят до съвършенство повече от един инструмент за организационен дизайн. По същата причина мнението на такъв специалист е само отражение на степента на съвместимост на неговия мироглед, формиран от опита на нито една година работа.
Сега можем да говорим за две основни направления в развитието на средствата за организационен дизайн. Единият се изразява в създаване на условия, които намаляват степента на свобода на проектанта. Това е дефиницията на строги стандарти за изготвяне на изводи, които гарантират приемливо взаимно разбиране между разработчиците и потребителите на инструменти, които поддържат целия цикъл на проекта, но не ни позволяват да „създаваме“ начина, по който искаме. Другата обхваща само отделни фрагменти от проектния цикъл и е насочена към представяне на услуга за изразяване на „творчески” възгледи за дизайна на организационните процеси. С други думи, двата подхода се различават по броя на стандартните връзки, които софтуерната среда представлява за описание на организационните процеси.
Опитът да се сравнят някои характеристики и характеристики на описанието на бизнес процесите, внедрени в софтуерния продукт Rational Rose от Rational Software и продукти, базирани на методологията IDEF0, най-разпространеният от които на руския пазар е BPwin от Computer Associates Corporation, ни позволява за да заключим, че първата система принадлежи към категорията „творчески“, а втората е „твърда“.
Тъй като характерните компоненти на „твърдите“ системи, базирани на IDEF и DFD, бяха обсъдени подробно по-горе, нека се спрем по-подробно на характерните характеристики на „творческата“ Rational Rose. Rational Rose не поддържа известни методологии за моделиране и анализ на бизнес процеси. Методологията за конструиране на така наречените „бизнес модели“, съдържаща се в допълнителния набор от препоръки или RUP методология, която придружава пакета Rational Rose, предлага диаграми на случаи на използване и дейности за описание на бизнес процеси. Въпреки това, авторът е убеден, че тези диаграми ни позволяват да опишем само малка част от информацията, която е необходима за моделиране на бизнес процеси и която е представена от инструментите IDEF0. В допълнение дъгите на случая на използване и дейността на диаграмите нямат същите семантични типове, които са били посочени за дъгите IDEF0. Синтактичните конвенции, продиктувани от системата при разработването на диаграми за случаи на употреба и дейности, не се комбинират в цялостна система; не се дава интерпретация на тези диаграми, за да се обясни как трябва да се използват при моделиране.
Поради тези причини потребителите на Rational Rose, когато разработват диаграми за случаи на използване и дейности, трябва да измислят свои собствени оригинални синтактични конвенции и да дадат своя собствена интерпретация на съществуващите, за да отразят цялата информация, която е от съществено значение за анализирания процес.
С други думи, потребителят на Rational Rose е принуден да развие свои собствени „формализми“, за да получи методология за изграждане на модели и анализ на бизнес процеси.
Има и руски софтуерни инструменти, базирани на използването на CASE технологии, например вътрешния пакет - CASE.analyst.
CASE.Analyst е графична система от клас CASE (Computer Aided Software/System Engineering), работеща под Microsoft Windows 9.X. CASE.Analyst предоставя следните възможности;
инструменти за функционално моделиране на системата чрез диаграми на потока от данни;
автоматична поддръжка на проектната база данни;
автоматична проверка на проекта, контрол на целостта и пълнотата;
модерен графичен интерфейс;
ясно и строго описание на системата (системни спецификации);
инструменти за представяне на проекти, например диаграми 2x2m (на всеки принтер);
автоматично генериране на проектна документация в съответствие с GOST 19.XXX и 34.XXX;
повече от 40 вида отчети и протоколи.
Прозорецът на диаграмата е основният работен прозорец на програмата в смисъл, че определя текущата диаграма на проекта и не може да бъде затворен. Прозорецът Графики ви позволява да създавате и редактирате диаграми. Нова диаграма може да бъде създадена само чрез детайлизиране (декомпозиране) на всеки възел в текущата диаграма. Така всички диаграми автоматично образуват йерархично дърво на проекта.
Всяка диаграма на проекта може да бъде един от следните типове:
CD - контекстна диаграма;
DPD - диаграма на потока от данни;
DPU - схема на управление.
Най-горната диаграма на проект винаги е контекстната диаграма.
Всеки тип диаграма има своя собствена палитра с обекти от дясната страна
прозорци.
Изброените подходи, въпреки цялото им разнообразие, в организационния дизайн на предприятията се основават на принципите на интегритета, тоест външната среда в тези модели присъства само като външен субект, който формира входни сигнали (материални потоци) и затваря обратна връзка линии.
По-рано обаче беше показано, че една от характерните тенденции в организационното развитие на съвременните компании е размиването на границите на организацията, загубата на разликата между вътрешната и външната среда на корпорацията поради многобройни кооперативни връзки,
диверсификация, консултиране и финансово взаимно участие на компаниите в дейността на другата.
Най-яркото проявление на „организационното взаимопроникване” стана аутсорсингът. Спецификата на този икономически феномен и възможността за използване на анализ на степента на „приемливост на аутсорсинга“ в структурния дизайн на организациите ще бъдат обсъдени в следващия раздел.

5.1.Същност на методологията на функционалното моделиране
бизнес процеси (методологии SADT)

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

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

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

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

SADT методология(Structured Analysis and Design Technics) стана толкова широко разпространена поради факта, че се фокусира върху цялостно представяне на структурата на материалните, информационните, финансовите и управленските потоци, показвайки организационната структура.
Поради това методологията SADT е по-насочена към реорганизиране на цялата система за управление, отколкото други методологии за функционално моделиране, базирани на използването на диаграми на потока от данни, чиято основна цел е проектирането на информационни процеси.

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

Предимството на функционалния модел е неговата графична простота, която използва само два структурни елемента:

Функционален блок – описание на функция, операция, действие, работа;

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

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

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

ориз. 10. Контекстна диаграма

Следните диаграми на нива описват подробно функциите на процеса на всяко предишно ниво. По този начин функционалният блок A0 се разлага на набор от взаимосвързани подфункции A1, A2, A3, ... (фиг. 11). На свой ред всеки функционален блок от 1-во ниво може да бъде разложен на набор от подфункции, например A2 на A21, A22, A23, A24 ... и така нататък, докато се получат елементарни действия на последното ниво. Препоръчително е да поставите не повече от 6 функционални блока на всяко ниво. Броят на нивата на разлагане не е ограничен. Обикновено 2-3 нива на декомпозиция са достатъчни за структурен анализ на бизнес процеси, необходими са последващи нива на декомпозиция за алгоритмизиране на информационни процеси и разработване на инструкции за изпълнители на бизнес процеси.