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

Материалът е изготвен от специалистите на фирма "Абис Софт"

Как да направите избор

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

1. Какво трябва да се опише?

2. До каква степен трябва да опишете?

3. Как ще се следи изпълнението?

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

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

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

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

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

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

1. Ако компанията вече е разработила стратегия и тя трябва да бъде контролирана, тогава от чуждестранните продукти, обсъдени в статията, решението е най -подходящо за това Hyperion Performance Scorecardпредставен от Oracle.

2. Ако основният акцент е върху бизнес процесите в компанията, тогава продуктът на компанията е оптимален. IBM - IBM WebSphere Business Modeler.

(Трябва да се изясни, че изборът на софтуер от производители като IBM, Oracle, SAP,определено от избора ERP-системи на съответния производител. Техният софтуер за бизнес моделиране е подсистема от сложни продукти.)

3. От руските продукти е най -препоръчително да се използват ИНТАЛЕВ: Корпоративен навигаторако искате да направите описание на цялата компания (холдинг) като цяло, а не само на една бизнес единица (подразделение или клон).

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

ARIS Business Performance Edition.

Изпълнява се посредством системата IBM Rational ClearCase

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

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

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

Много съвременни методологии за моделиране на бизнес процеси се основават на методологията SADT (Structured Analysis and Design Technique), семейството на стандартите IDEF (Icam DEFinition, където Icam означава Интегрирано компютърно подпомагано производство) и алгоритмични езици.

Основните видове методологии за моделиране и анализ на бизнес процеси:

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

Описание на работните потоци ( Моделиране на работния поток). Стандартът IDEF3 е предназначен за описване на работни потоци и е близък до алгоритмичните методи за изграждане на блокови диаграми.

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

Други методологии.

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

Ключови бизнес процеси (например маркетинг, производство, доставка и обслужване на продукти).

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

Управляващи бизнес процеси.

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

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

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

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

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

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

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

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

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

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

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

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

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

Изграждане на организационната структура на процеса (отдели, участници, отговорни).

IDEF0

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

Връзката между дъгата и блока определя типа интерфейс:

Контролната информация влиза в блока в горната част.

Входната информация влиза в блока вляво.

Резултатите излизат от блока вдясно.

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

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

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

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

IDEF3

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

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

Всички връзки в IDEF3 са еднопосочни и са организирани отляво надясно.

Типове връзки IDEF3:

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

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

Размита връзка, пунктирана стрелка.

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

Разклоняването на процеса се отразява с помощта на специални блокове:

- „И“, блокирайте със знака &.

- „Изключителен ИЛИ“ („един от“), блок със знака Х.

- "ИЛИ", блок със знак О.

Ако действията „И“, „ИЛИ“ трябва да се извършват синхронно, това се обозначава с две двойни вертикални линии вътре в блока, асинхронно - с една.
Методът IDEF3 ви позволява да разлагате дейност няколко пъти, като по този начин документирате алтернативни потоци от процеси в един модел.

DFD

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

Основните компоненти на диаграмите на потока от данни са:

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

Системи и подсистеми (например подсистема за работа с физически лица);

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

Устройства за съхранение на данни (абстрактни устройства за съхранение на информация);

Потоци от данни (стрелки на диаграмата).

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

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

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

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

ARIS

В момента има тенденция за интегриране на различни методи за моделиране, което се проявява под формата на създаване на интегрирани инструменти за моделиране. Един от тези инструменти е софтуерен продукт, наречен ARIS (Архитектура на интегрирани информационни системи), разработен от немската компания IDS Scheer.

ARIS поддържа четири типа модели (и много видове модели във всеки тип), отразяващи различни аспекти на изследваната система:

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

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

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

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

За изграждането на изброените типове модели се използват както собствени методи за моделиране на ARIS, така и различни добре познати модели и езици за моделиране, по-специално UML. Можете да започнете процеса на моделиране с всеки от типовете модели.

Основният бизнес модел на ARIS е eEPC (разширена верига от процеси, управлявана от събития). Нотация ARIS eEPC е разширение на нотация IDEF3. Бизнес процес в нотация на eEPC е поток от последователно извършена работа (процедури, функции), подредени в реда на тяхното изпълнение. Действителната продължителност на процедурата не се отразява визуално в eEPC.

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

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

Основните обекти на нотация на eEPC:

Функция. Служи за описване на функциите (процедури, работи), изпълнявани от отдели / служители на предприятието. Всяка функция трябва да се задейства от събитие и трябва да завършва със събитие; всяка функция не може да съдържа повече от една стрелка, "стартираща" изпълнението на функцията, и от повече от една стрелка, описваща завършването на изпълнението на функцията.

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

Организационна единица. Например мениджмънт или отдел.

Документ. Отразява реални носители, като хартиени документи.

Приложна система.

Група информация. Характеризира набор от обекти и взаимоотношения между тях.

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

Логически оператор. Операторът „И“, „ИЛИ“ или изключителен „ИЛИ“ ви позволява да опишете разклонението на процес.

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

За съхраняване на модели в ARIS се използва обектна СУБД и се създава нова база данни за всеки проект. Предлагат се различни функции за администриране на база данни, като например контрол на достъпа. Базата данни е йерархично хранилище на модели.

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

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

В по-нататъшния анализ ще се вземат предвид само характеристиките на програмите ARIS ToolSet (по-долу ARIS), BP-Win-Erwin (по-долу BP-Win) и ORG-Master (по-нататък ORG-Master). Програмата Rational Rose е в най -голяма степен фокусирана върху изграждането на чисто софтуер, а не на организационни системи, за да опростим представянето, ще изключим от разглеждане, особено след като основната методология на UML сега е внедрена в ARIS).

Функционалност на инструментите за моделиране на бизнес системи

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

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

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

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

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

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

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

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

Имайки това предвид, втората от разглежданите възможности за анализ на модела: анализ на разпределението на отговорността за изпълнение на отделни функции и използване на системни ресурси, се оказва автоматично внедрен в процеса на изграждане на модел на бизнес процес в системата ORG-Master. Всъщност прогнозите на организационната връзка - Функции и функции - Ресурси, посочени при изграждането на модели на бизнес процеси в ORG -Master, показват директно отговорните за определена работна област или ресурс (и позволяват да се анализира всяка тяхна комбинация). В допълнение, ORG-Master ви позволява да експортирате матрични проекции в MS Excel, където на тяхна база се формират диаграми за организационен анализ.

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

Въпрос относно зареждането на изпълнители и инструментални ресурси в системата, както и получаване на оценки за основните параметри на времето на симулираната система,могат да бъдат решени въз основа на количествени данни за сложността (или просто продължителността) на функциите, които изпълняват. За да се реши този проблем, е необходимо да се въведат такива данни в системата по един или друг начин, както и да се осигурят средства за получаване на обобщени оценки. Поддръжката на методологията IDEF3 (в BP-Win), ABC методите в ARIS и BP-Win, както и инструментите за симулация в ARIS (и отчасти в BP-Win) предвижда известна обработка на тези оценки. Що се отнася до действителните първоначални данни, те се задават от потребителя, който следователно е отговорен за крайния резултат.

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

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

Можете да опитате да получите по -адекватни резултати, като симулирате поведението на системата. Въпреки това, за времето на забавяне на обслужването, трябва да се вземат много груби предположения относно закона за тяхното разпределение във времето, или да се извършат доста скъпи и трудоемки процедури за определяне на времето и последваща статистическа обработка. В същото време надеждността на получените резултати няма да бъде твърде висока или ще изисква значителни допълнителни разходи. Следователно изглежда разумно да се подходи, че „цената на разходите за моделиране за получаване на каквато и да е информация не трябва да надвишава стойността (цената) на резултатите от нейното използване. Освен това винаги трябва да се помни за закона на Парето, от който във връзка с разглеждания проблем следва, че 20% от усилията за моделиране осигуряват 80% от ефекта.

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

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

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

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

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

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

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

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

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

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

Освен това би трябвало да е възможно създаването на специални формуляри за отчитане за създаване на документи в различни функционални области: Техническо заданиеотносно информационната система за управление на предприятието, Ръководство за качество (виж, например, Приложение 3) и други специални документи съгласно стандарт ISO9000 и др.

Цялата информация, която ви позволява да генерирате тези документи, трябва да се съдържа под формата на съгласувана и последователна система в цялостния бизнес модел на предприятието (компанията). Нещо повече, много от създадените документи трябва да отговарят максимално на общоприетите руски стандарти (Очевидно системите ARIS и BP-Win отговарят на последното изискване в най-малка степен).

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

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

В BP-Win не е предвидена пряката възможност за получаване на различни разпоредби.

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

По отношение на документацията за развитието на информационна система най-традиционните възможности се предоставят от средата BP-Win / ERwin, която всъщност е създадена за това.

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

Възможностите на ORG -Master ви позволяват да представите напълно структурите от данни, необходими за организиране на информационна поддръжка за моделирани бизнес процеси, използвайки свои универсални инструменти - класификатори и прогнози. Няма формализми като ER диаграми, въпреки че най -новите версиивъзможна е визуализация в стандарта DFD. Освен това стана възможно да се отрази върху диаграмите IDEF0 взаимодействието между функционалните блокове не само чрез директно прехвърляне на документи и файлове, но и чрез споделени бази данни!

Подкрепа за разработване на модели на бази данни и софтуерни инструменти обикновено се отнася до възможностите на инструменти като CASE или подобни инструменти за конфигуриране на информационни системи за управление на предприятието (например системи от клас ERP). Такава поддръжка може да осигури следната функционалност:

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

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

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

В средата ARIS такава възможност е предоставена в пакета ARIS Toolset на нивото на спецификацията на проекта и дефиницията на параметрите на базата данни.

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

Генериране на програмни кодове за приложни или системни инструментиСистемите ARIS и ORG-Master не се предоставят, тъй като те са инструменти за проектиране на бизнес системи, а не софтуер. До известна степен тази функция се прилага само в BP-Win.

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

Функции управление на проектисъздаването на бази данни и софтуерни инструменти са специфични специално за разработването на софтуерни продукти. Те са внедрени в тази форма в BP-Win. Управлението на проекти в семейството на ORG-Master напълно поддържа софтуерния пакет Time-Master. (Въпреки че, строго погледнато, тези функции не са необходими за въпросния клас инструменти).

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

Интеграцията със софтуерни продукти на трети страни се извършва за една от следните цели:

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

От гледна точка на функционалния фокус, интеграцията с:

• СЛУЧАЙ означава,
• ERP системи,
• приложни програми.

ARIS има интерфейси с някои инструменти на CASE и също така е инструмент за изграждане на модели за директно персонализиране на такива системи за управление на предприятието, предимно SAP R / 3. Както бе отбелязано по-горе, системата разчита на собствена нотация за представяне на бизнес процеси, поради което използва вградени инструменти за симулация и инструмент анализ на разходите, резултатите от които обаче могат да бъдат експортирани във формати MS Excel.

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

BP-Win поддържа методологии IDEF0, DFDи IDEF3и се интегрира със следните софтуерни продукти (предимно от същия производител):

• Инструмент за моделиране на данни ERwin (Platinum Technology),
• система за управление и съхранение на проекти ModelMart (Platinum Technology),
• специализиран генератор на отчети за модела RPTwin (Platinum Technology),
• симулационна система BPSimulator (System Modeling Corporation),
• инструмент за анализ на разходите EasyABC (ABC Technologies).

(* Platinum Technology - от 1999 г. влезе в Computer Associates)

ORG-Master първоначално е позициониран като система от организационен клас, фокусирана върху решаване на проблеми с моделирането и проектирането на бизнес процеси и структури и подпомагане на организационни решения. Той предоставя възможност за интегриране със собствени пакети за разработчици („BIG-SPB софтуер“), фокусирани върху решаването на различни функционални задачи. В системата ORG-Master, ако е необходимо, в средата на MS Office автоматично се създават прости изпълнителни информационни системи:

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

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

Възможно е (и е тествано в проекти) взаимодействие на данни чрез файлове за обмен в рамките на изграждането на интегрирани информационни системи с изпълнителни и аналитични програми на фирми партньори: 1C, A&T: Soft, Intalev, Comtech +, INEK и др., Като както и със сложни системи за управление на корпоративни ресурси (например производство на IPS).

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

Обобщение на раздела:

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

Както може да се види от таблица 2, директното сумиране на оценките дава разсейване от около ± 4%. Такова разпространение се крие в грешката на самите оценки. Освен това самите средства, различни по функционалната си ориентация, са получили подобни оценки поради факта, че различните силни страни и Слабостиразлични средства, когато се изчисляват директно, се компенсират взаимно.

Въпреки това, по време на обсъждането на функционалните възможности, беше подчертано, че директно за решаване на проблеми на бизнес инженеринга отделните групи функционални способности имат различно значение. Този факт се отразява от коефициентите, записани в колона „Тегло”, таблица 2. Като се вземе предвид този фактор, се вижда, че цялостна оценкасложният ORG-Master леко надминава ARIS.

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

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

Освен това справка в Приложение 2 предоставя преглед на стандартите за формализация и инструменти за конструиране и / или анализ на определени модели, които се използват в разглежданите системи.

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

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

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

Кой има нужда

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

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

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

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

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

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

● Намерението е да се въведе автоматизирана система за управление.Факт е, че придобиването и инсталирането на автоматизирана система за управление не винаги води до положителни резултати. Специалистите по внедряването на такива системи, независимо от продуктовата им ориентация, са съгласни в едно: „невъзможно е да се автоматизира бъркотията“. Най -съвършената система за управление няма да работи без ясно разпределение на отговорността между служителите, работещи в нея. И дори ако има ясна система за управление, струва си да се обмисли, преди да се инвестират значителни ресурси в придобиването и внедряването на автоматизирана система за управление, дали съществуващата система съдържа някакви недостатъци, които не трябва да бъдат отстранявани в твърдата компютърна логика.

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

Разбира се, може да има други причини - или набор от причини, поради които проектирането на система за управление става необходимо. Най -важното е, че когато вземате решение, човек не трябва да забравя проста истина: "Ако работи, не го поправяйте!" (В хода на писането на статията авторите имаха някои разногласия при тълкуването на тази поговорка. Ние се спряхме на това пояснение: това, което работи чудесно днес, може да се превърне в проблем утре.

Някои примери от живота

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

ИТ компания е типично средно предприятие. Основни направления на дейност:

● Продажба на инструменти за автоматизация на бизнеса - от продажбата на счетоводен и офис софтуер до пълномащабни автоматизирани системи за управление

● Внедряване на инструменти за автоматизация на бизнеса

● Системна интеграция

● Услуги за обучение и сертифициране на специалистите на Клиента

● Производство и продажби на наш собствен софтуер.

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

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

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

Различни примери, различни цели и подходи за решаване на проблеми. Но всички предприятия имат едно общо нещо - необходимостта от проектиране и внедряване на система за управление на предприятието, базирана на бизнес процеси.

Откъде да започна?

Традиционният подход включва описание на определено състояние „такова, каквото е било“, търсене тесни местаи изменение на системата, която след това се квалифицира като „коригирано това, което беше“. Проста и ефективна техника за не съвсем пренебрегвани случаи. Липсата на фокус върху необходимото обаче е сериозен недостатък на този подход, особено когато настоящата цел на собственика е далеч от това, което предприятието прави. Разработването и формализирането на стратегията помага да се постигне правилната посока. Пример за стратегия, формализирана с помощта на стратегическа карта - Фигура 1.

Снимка 1.

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

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

Какви елементи се анализират? На първо място, гамата от стоки и услуги, предлагани от компанията. Съставя се регистър - пълен пакет от тези предложения - и се анализира. Дали всичко, което произвеждаме, е изгодно, полезно и допринася ли за постигането на основните цели? Трябва ли да разширим асортимента си? Трябва ли да го намаля по отношение на нерентабилни стоки или услуги? Могат ли нерентабилните стоки или услуги да бъдат направени печеливши (и рентабилни - свръхрентабилни?). Изготвя се обещаващ пакет от продукти и услуги, за които ще се извършва моделиране на бизнес процеси. За анализ на продуктите можете например да използвате матрицата на Boston Consulting Group (Фигура 2).

Фигура 2.

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

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

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

Екип от участници

"Кадрите са всичко!" Този лозунг, както никъде другаде, е актуален в процеса на подобряване на системата за управление. За да разрешите този проблем, е невъзможно просто да наемете професионални изпълнители, които ще направят всичко вместо вас. Ангажираното участие на ключови служители на компанията е незаменимо условие за решаването на този проблем. От друга страна, поканата на външни специалисти, макар и желана, не е необходима - ако вашите служители поемат всички необходими функции. Нека се опитаме да опишем тези функции и да наемем официален екип от изпълнители, както и да посочим значението на професионалните умения за всички.

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

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

Дизайнери на бизнес процеси на ниско ниво.За да разберем - кои са тези хора, нека разгледаме задачата от гледна точка на задачата. За малък бизнескато правило се разграничават 7-8 бизнес процеси от най-високо ниво (например производство, продажби, доставка, възпроизвеждане на персонал и др.). Всеки от тях е разделен на 7-8 по -малки подпроцеса - по -подробни (например „производството на продукти“ може да включва производство на части, сглобяване на продукти, контрол на качеството) - тоест в резултат имаме около петдесет бизнес процеси. В големите компании, като правило, е необходимо по -нататъшно разделяне - още едно или две нива. (Фигура 3)

Фигура 3. Пример за разделяне на бизнес процесите на средно предприятие. За големите просто добавете един или два етажа надолу ...

Например, един мениджър по човешки ресурси в средно голяма компания изпълнява функцията си в рамките на един бизнес процес, който просто се нарича „подбор на персонал“. Като се има предвид, че той върши почти цялата работа сам, няма нужда да пишете никакви разпоредби за тази работа. Друго нещо е отделът за персонал на голяма компания, където има разделение на различни функции между служителите. Процесът на „вербуване“ в този случай вече се състои от още десетки прости действияизвършвани от различни хора - и тяхното взаимодействие трябва да бъде описано от бизнес процесите на по -ниско ниво. Крайното ниво за разделяне на бизнес процесите е бизнес операция - процес, който е напълно изпълнен и контролиран от едно звено за персонал. А за много големи компании хиляди бизнес процеси са напълно реални. Сега нека направим въображаема проекция на картината на бизнес процесите върху диаграмата на подразделенията на предприятието. Очевидно някои бизнес процеси ще се поберат изцяло в един отдел. Ще има и процеси, за които отговарят два или повече отдела (в една или друга степен). А най -неприятните ситуации са тези, при които отговорността за изпълнението на бизнес процес многократно се прехвърля от един отдел в друг (гледайки напред, да кажем, че се препоръчва да се избягват такива бизнес процеси, ако е възможно). Фигура 4 схематично показва бизнес процесите на предприятие за производство на фиктивни продукти. Някои от бизнес процесите, показани с черни стрелки, се осъществяват в отделите. Другата част - сините стрелки - се премества от една единица в друга. И накрая, третата част е процес, в който участват няколко отдела. Червена пунктирана линия.

Ориз. 4. Принадлежност към бизнес процесите. Черните стрелки показват хода на вътрешните бизнес процеси на отделите, цветните стрелки - процесите от по -високо ниво.

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

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

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

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

Истинският дизайн ...

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

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

Концентрация на усилията за постигане на стратегически цели. Бизнес процеси, върху които няма въздействие ключови показателиса разработени последни или изобщо не са разработени. Нека направим най-простото изчисление: за предприятие, което има три нива на бизнес процеси (т.е. не много голямо унитарно предприятие), имаме 7-8 процеса от по-високо ниво, всеки от които е разделен на 7-8 BP от второ ниво, същият принцип на разделение остава отдолу ... В резултат на това вече на трето ниво имаме повече от 350 бизнес процеса. Средно всеки бизнес процес се състои от дузина операции, което дава четири хиляди операции като цяло за предприятието. И това е само за малко! Предлагам да изчислите сами геометричната прогресия до четвъртото и петото ниво. Разбира се, само такива чудовища като Gazprom или RAO UES изискват петото ниво на детайлност, но дори и за четвъртото ниво броят на операциите не е малък. В идеалния случай всеки процес, всяка операция трябва да се оптимизират, регулират и преразглеждат поне веднъж годишно или при промяна на външните условия. Като се има предвид броят на операциите, ние разбираме, че идеалът, както обикновено, е недостижим и преследването му ще доведе само до неоправдано преразход на ресурси. Трябва да вземете тъжно, но правилно решение - като сте взели стратегическа карта, проектирайте само тези бизнес процеси, които отговарят на целите, посочени в нея. И ако почистването на вътрешната територия не засяга нито една от целите или подцелите на стратегическата карта, не засяга нито един показател от BSC, тогава нека самите почистващи да го регулират. Поне докато най -накрая разбрахме производството, продажбите и предлагането ...

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

При проектирането не забравяйте да зададете основните параметри на бизнес процеса (Фигура 5).

Фигура 5. Основните параметри на бизнес процеса

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

Оценка на проблемния характер и значението на процеса. Той също така ви позволява да разберете кои процеси трябва да бъдат проектирани веднага и кои могат да изчакат. Сред основните критерии тук могат да бъдат разгледани: 1) критичност за бизнеса. Тоест колко неправилно изпълнение на процеса може да навреди на компанията - увеличаване на разходите, водене до загуба на клиент, забавяне на приемането на важно решение ... 2) Честотата на повторение на процеса (рядко, често , редовно). 3) Броят на прехвърлянията на отговорност в рамките на един процес, например от отдел на отдел. Такива процеси са потенциално опасни и водят до много проблеми.

Лидерите и в трите категории са ясни кандидати за проектиране и оптимизация.

Фигура 6. Илюстрация на подхода на процеса

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

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

Какво очакваме в крайна сметка

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

Регламенти на бизнес процесите (поне ключови), стандартни форми на документация, както външна, така и вътрешна, разпоредби за подразделенията, длъжностни характеристики, маса за персоналпредприятия - това е минималният му списък. Също толкова важно е прилагането на системата, прилагането на регулациите на практика. Едва тогава можем да кажем, че усилията и ресурсите за проектирането не са били пропилени напразно. Добре е, ако успеете да разделите внедряването на малки етапи и раздели (например първо отдел за покупки, след това складови помещенияи т.н.) В допълнение към факта, че това ще позволи да се поддържа уверен контрол върху процеса на въвеждане на иновации, всеки малък успех ще се превърне в добър стимул за продължаване на по -нататъшната работа. Вярно е, че далеч не винаги е възможно да се раздели изпълнението на отделни независими раздели. Дори ако новата система напълно избягва разпределението на отговорностите между отделите, ако структурата на новите бизнес процеси е строго линейна и проста, дори тогава необходимостта от прилагане на измервания „в движение“ (кой ще позволи спиране на рентабилно предприятие?) На новият процес засяга десетки стари, които от своя страна се заменят с десетки „нови“, всеки от които ... (и по -нататък, постепенно). Следователно, в повечето случаи, по време на внедряването, екипът е принуден да работи известно време според старата система, симулирайки паралелно нови дейности (повечето от вашите служители са грамотни хора и отлично разбират, че дълго време ще трябва да правят двойна работа, само за да може крайното натоварване върху тях да се увеличи в сравнение с оригинала - оттук и съпротивлението на иновациите). В най -пренебрегваните случаи се оказва по -лесно да се построи нов завод наблизо, за да се внедри система за управление (точно това трябва да направите например в АвтоВАЗ, където абсурдите, наследени от съветско време, умножени по тези придобити по време на процеса на преструктуриране, създаде среда, в която почти всеки служител се съпротивлява на иновациите.). И накрая, друг естествен резултат от дизайна е въвеждането на автоматизирана система за управление на предприятието. Отдавна е доказано, че автоматизацията подобрява ефективността на работата. Автоматизацията дава особено забележим ефект в предприятията, където има ясна и рационална система за управление, всички бизнес процеси са регулирани. И напротив, автоматизирането на управлението без предварително проектиране означава да обрече внедряването на ACS на провал (споменахме ли вече невъзможността за автоматизиране на случайно възникнали отношения по неопределен начин?). Наличието на строга система от бизнес процеси ще даде възможност да се подходи към внедряването на автоматизирани системи за управление от гледна точка на максимална ефективност. Сега вече е съвсем реалистично първо да се автоматизират най -критичните области на работа, като в резултат на това спечелените или спестени пари - следващата най -важна ... Можете да направите това с постепенността, която позволяват ресурсите или изисква външната ситуация.

Оценка на потребностите от ресурси

Ако преди това сте участвали в подобни дейности, тогава вече си представяте колко по-лесно ще направи проектирането на текущата ви сметка, колко служители ще загубите временно, като пълноценни бойни единици (и колко изобщо ще загубите). Мотивите по -долу са по -вероятни за тези, които планират да започнат такава работа за първи път - в края на краищата е опасно както да се надценят, така и да се подценят мащабите на бъдещите загуби. Надценяването на оценката на сложността може да доведе до пълно изоставяне на проекта (заедно с надеждите да стане лидер в индустрията) или до ненужно високи суми по договор с изпълнителя. Подценена оценка ще доведе до факта, че в един момент няма да има достатъчно ресурси и проектът ще бъде изоставен - което отново означава загуба на пари. Времето е също толкова важно - и по същите причини. Практиката показва, че средните компании - от 500 до 1000 души - разработват и внедряват нова система за управление за една година. Компаниите с 10 000 служители ще отнемат приблизително 2-3 години. Въпреки това, в зависимост от сложността на ситуацията, времето за изпълнение може да се увеличи два или три пъти.

От необходимостта от човешки ресурси може да се предположи за целия този период от постоянен екип от 3-4 души (стратег, анализатори) и необходимостта от включване на служители на предприятието, ако е необходимо, - ръководители на отдели и обикновени изпълнители. Шефовете ще участват за около един до два месеца нетно време през целия цикъл на проектиране и изпълнение, обикновените изпълнители - по -малко, от 2 седмици до месец. Разходите за вашите специалисти, дадени този път, могат да бъдат оценени. Външните консултанти са скъпи. Услугите на специалист могат да струват от 1,5 до 25 хиляди рубли на час работа.

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

Въпрос: Възможно ли е да се намалят разходите за проектиране на система за управление?

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

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

● Втората причина се корени в разбирането на основите на ефективността. Често повтарящите се процеси са от решаващо значение за цялостния ход на делото - в края на краищата, въпреки тяхната простота и рутина, техният принос към общите разходи за труд е много значителен. При проектирането на бизнес процеси има много шаблонни, повтарящи се действия, които, когато ръчно изработенще отнеме лъвския дял от цялото време за разработка. Разбира се, използването на методите CTRL-C-CTRL-V значително улеснява работата в WORD или Excel при въвеждането им, но специализираният софтуер осигурява още по-удобна среда за проектиране.

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

● Четвъртата причина е възможността за оптимизация. Дори и днес да няма програма, която да може самостоятелно да проектира оптималната версия на бизнес процес (в противен случай нуждата от мениджъри и бизнес анализатори би изчезнала сама, компютърът е по -евтин) - но симулира стотици цикли на всеки от хилядите бизнес процеси в десетки варианти на тяхното взаимодействие ... Опитайте с Excel! И в този случай не можете без статистическа обработка - в края на краищата системата ще работи в реалния свят, където всичко се случва.

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

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

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

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

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

Инструменти за бизнес моделиране и тяхната еволюция

За създаване на бизнес модели се използват инструменти за проектиране на информационни системи и съответни езици за описание (най -известният сред тях е UML - Unified Modeling Language). С помощта на такива езици се изграждат графични модели и диаграми, които демонстрират структурата на бизнес процесите на организацията, организацията на взаимодействие между хората и необходимите промени за подобряване на работата на организацията като цяло. Инструментите за бизнес моделиране непрекъснато се развиват. Първоначално с помощта на такива инструменти беше възможно да се опишат само бизнес функциите (работата) на компанията и движението на данни в процеса на тяхното изпълнение. В същото време, ако една и съща бизнес функция беше използвана при извършване на различни видове работа, беше трудно да се разбере дали това означава една и съща бизнес функция или различна. Невъзможността да се дефинира изрично йерархията на бизнес процесите (например „верига на стойността“, „бизнес процес“, „подпроцес“, „работа“, „функция“) създава проблеми при използването на такива описания. Самите описания бяха просто колекция от снимки. По -късно започнаха да се появяват инструменти, които ви позволяват да опишете организацията не само от страна на бизнес функциите, но и от други страни. Така стана възможно създаването на отделни диаграми, които да отразяват организационна структуракомпании, потоци от данни в една организация, последователността на изпълнение на бизнес функции, които съставляват един бизнес процес, с възможност за използване на логически символи и т.н. Поради непрекъснато нарастващите изисквания към инструментите за бизнес моделиране, все повече диаграми са започнали да опише различни аспекти на дейностите на организациите, което направи създаването на модела все по -трудно. В тази връзка следващият важен етап от разработването на инструменти за бизнес моделиране е свързан с идеята за използване на единно хранилище (съхранение) на обекти и идеята за възможно повторно използване на обекти в различни диаграми. Който и инструмент да бъде избран, е необходимо да се осигури взаимодействието на местните информационни системи помежду си. Днес най -модерният и в същото време общоприет стандарт за организиране на управление на бизнес процеси е BPEL (Business Process Execution Language). Въз основа на този продукт можете да създадете единна интеграционна платформа за всички използвани приложения. След моделиране на процесите, един от инструментите за моделиране използва специални преводачи, за да пренесе модела в BPEL.

Примери за бизнес моделиране и неговите резултати

• Намаляване на разходите. Бизнес моделът ще даде представа къде могат да бъдат избегнати ненужните разходи и как да се оптимизира използването на ресурси. Въз основа на бизнес модела се извършва функционален анализ на разходите за изчисляване на цената на продукт или услуга и се изгражда система за управление на бюджета, която ви позволява да контролирате разходите на предприятието.
• Повишена ефективност. Възможност за намаляване на разходите за адаптация и обучение на персонала. Нормативната документация, базирана на подготвения бизнес модел, съответства на текущото състояние на организацията, разпределя отговорностите, изгражда йерархична система за кариерно израстване.
• Разширяване на сферата на влияние, разширяване на мрежата, организация на клонове. Наличието на бизнес модел ще намали разходите и ще даде възможност да се опише структурата на подреждането на нови клонове на предприятието.
• Адекватност на инвестицията. С помощта на бизнес моделирането е възможно да се определи размера на капиталовите инвестиции с достатъчна степен на точност, да се намалят рисковете и финансовите загуби на стартовия етап на нов проект.
• Въвеждане на СУРД. Бизнес моделът на предприятието стандартизира състава на документите на предприятието и установява маршрутите за движение на документи.
• Автоматизация и внедряване на ERP, SCM, CRM или други софтуерни системи. Въз основа на бизнес модела е възможно да се формулират по -високи изисквания за качество на системата и да се избере оптимално решение по отношение на разходите и функционалността.
• Сертифициране на системата за управление на качеството. Разработването на бизнес модел на предприятие може значително да намали времето и разходите за разработването, внедряването и сертифицирането на система за управление на качеството и да получи набор задължителни документиза успешно сертифициране, намалете разходите за поддържане на система за управление на качеството.

Характеристики на бизнес моделирането

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

Решения

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