Моделювання бізнес-процесів- це ефективний засіб пошуку шляхів оптимізації діяльності компанії, що дозволяє визначити, як компанія працює в цілому і як організована діяльність на кожному робочому місці. Під методологією (нотацією) створення моделі (опису) бізнес-процесу розуміється сукупність способів, за допомогою яких об'єкти реального світу і зв'язку між ними представляються у вигляді моделі. Для кожного об'єкта і зв'язків характерні ряд параметрів, або атрибутів, що відображають опредёленние характеристики реального об'єкта (номер об'єкта, назва, опис, тривалість виконання (для функцій), вартість і ін.).

Опис бізнес-процесів проводиться з метою їх подальшого аналізу і реорганізації. Метою реорганізації може бути впровадження інформаційної системи, скорочення витрат, підвищення якості обслуговування клієнтів, створення посадових і робочих інструкцій і т.п., а детальний опис процесів саме по собі не представляє цінності.

реінжинірингбізнес-процесів (англ. Business process reengineering) - це фундаментальне переосмислення і радикальне перепроектування бізнес-процесів для досягнення максимальної ефективності виробничо-господарської і фінансово-економічної діяльності, оформлене відповідними організаційно-розпорядчими та нормативними документами. Бізнес-інжиніринг складається з моделювання бізнес-процесів (розробка моделі "як є", її аналіз, розробка моделі "як треба") і розробки та реалізації плану переходу до стану "як треба".

Основу багатьох сучасних методологій моделювання бізнес-процесів склали методологія SADT (Structured Analysis and Design Technique - метод структурного аналізу і проектування), сімейство стандартів IDEF (Icam DEFinition, де Icam - це Integrated Computer-Aided Manufacturing) і алгоритмічні мови.

Основні типи методологій моделювання і аналізу бізнес-процесів:

Моделювання бізнес-процесів ( Business Process Modeling). Найбільш широко використовувана методологія опису бізнес-процесів - стандарт IDEF0. Моделі в нотації IDEF0 призначені для високорівневого опису бізнесу компанії в функціональному аспекті.

Опис потоків робіт ( Work Flow Modeling). Стандарт IDEF3 призначений для опису робочих процесів і близький до алгоритмическим методам побудови блок-схем.

Опис потоків даних ( Data Flow Modeling). Нотація DFD ( Data Flow Diagramming), Дає змогу побачити послідовність робіт, що виконуються по ходу процесу, і потоки інформації, що циркулюють між цими роботами.

Інші методології.

По відношенню до отримання доданої цінності продукту або послуги можна виділити наступні класи процесів:

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

Забезпечують бізнес-процеси не додають цінність продукту, але збільшують його вартість (наприклад фінансове забезпечення діяльності, забезпечення кадрами, юридичне забезпечення, адміністрування, забезпечення безпеки, постачання комплектуючих матеріалів, ремонт та технічне обслуговування і т.д.).

Бізнес-процеси управління.

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

Цілі моделювання бізнес-процесів зазвичай формулюються наступним чином:

Забезпечити розуміння структури організації та динаміки відбуваються в ній процесів;

Забезпечити розуміння поточних проблем організації та можливостей їх вирішення;

Переконатися, що замовники, користувачі і розробники однаково розуміють цілі і завдання організації;

Створити базу для формування вимог до ПЗ, автоматизує бізнес-процеси організації (вимоги до ПО формуються на основі бізнес-моделі).

Важливим елементом моделі бізнес-процесів є бізнес-правилаабо правила предметної області. Типовими бізнес-правилами є корпоративна політика і державні закони. Бізнес-правила зазвичай формулюються в спеціальному документі і можуть відображатися в моделях.

декомпозиціяв загальному сенсі - це метод, що дозволяє замінити рішення однієї великої задачі рішенням серії менших завдань, розщеплення об'єкта на складові частини за встановленим критерієм. Практично декомпозиція застосовується для деталізації бізнес-моделей.

Етапи опису бізнес-процесів:

Визначення цілей опису.

Опис оточення, визначення входів і виходів бізнес-процесу, побудова IDEF0-діаграм.

Опис функціональної структури (дії процесу), побудова IDEF3-діаграм.

Опис потоків (матеріальних, інформаційних, фінансових) процесу, побудова DFD-діаграм.

Побудова організаційної структури процесу (відділи, учасники, відповідальні).

IDEF0

Модель складається з діаграм, фрагментів текстів і глосарію, що мають посилання один на одного. Діаграми - головні компоненти моделі, всі функції і інтерфейси на них представлені як блоки і дуги.

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

Керуюча інформація входить в блок зверху.

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

Результати виходять з блоку справа.

Механізм (людина або автоматизована система), який здійснює операцію, входить в блок знизу.

Кожен компонент моделі може бути декомпозирован (розшифрований більш детально) на іншій діаграмі. Рекомендується припиняти моделювання, коли рівень деталізації моделі задовольняє її мета. Загальна кількість рівнів в моделі не повинно перевищувати 5-6.

Побудова діаграм починається з отримання всієї системи у вигляді одного блоку і дуг, що зображують інтерфейси з функціями поза системою. Потім блок, який представляє систему в якості єдиного модуля, деталізується на іншій діаграмі за допомогою декількох блоків, з'єднаних інтерфейсними дугами. Кожна детальна діаграма є декомпозицією блоку з діаграми попереднього рівня. На кожному кроці декомпозиції діаграма попереднього рівня називається батьківської ще детальної діаграми.

На таких діаграмах не вказані явно ні послідовність, ні час. Метод має ряд недоліків: складність сприйняття (велика кількість дуг на діаграмах і велика кількість рівнів декомпозиції), труднощі ув'язки декількох процесів.

IDEF3

Цей метод призначений для моделювання послідовності виконання дійі взаємозалежності між ними в рамках процесів. Моделі IDEF3 можуть використовуватися для деталізації функціональних блоків IDEF0, що не мають діаграм декомпозиції.

Діаграми IDEF3 відображають діяу вигляді прямокутника. Дії іменуються з використанням дієслів або віддієслівних іменників, кожному з дій присвоюється унікальний ідентифікаційний номер (номер дії зазвичай передує номером його батька, наприклад, 1.1.).

Все зв'язку в IDEF3 є односпрямованим і організовуються зліва направо.

Типи зв'язків IDEF3:

Тимчасове передування (Temporal precedence), проста стрілка. Початкове дія повинна завершитися, перш ніж кінцеве дію зможе початися.

Об'єктний потік (Object flow), стрілка з подвійним наконечником. Вихід вихідного дії є входом кінцевого дії. Початкове дія повинна завершитися, перш ніж кінцеве дію зможе початися. Найменування потокових зв'язків повинні чітко ідентифікувати об'єкт, який передається з їх допомогою.

Нечітке відношення (Relationship), пунктирна стрілка.

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

Розгалуження процесу відбивається за допомогою спеціальних блоків:

- "І", блок зі знаком &.

- "Що виключає АБО" ( "одне з"), блок зі знаком Х.

- "АБО", блок зі знаком О.

Якщо дії "І", "АБО" повинні виконуватися синхронно, це позначається двома подвійними вертикальними лініями всередині блоку, асинхронно - однієї.
Метод IDEF3 дозволяє декомпозировать дію кілька разів, що забезпечує документування альтернативних потоків процесу в одній моделі.

DFD

Мета такого уявлення - продемонструвати, як кожен процес перетворюєсвої вхідні даніу вихідні. Може відображати не тільки інформаційні, але й матеріальні потоки. Також, як і в інших моделях, підтримується декомпозиція.

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

Зовнішні сутності (матеріальний об'єкт або фізична особа, що є джерелом або приймачем інформації, наприклад, замовники, персонал, постачальники, клієнти, склад);

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

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

Накопичувачі даних (абстрактні пристрої для зберігання інформації);

Потоки даних (на діаграмі - стрілки).

Необхідно розміщувати на кожній діаграмі від 3 (менше немає сенсу) до 7 (більше - НЕ сприймаються) процесів, не захаращуючи діаграми несуттєвими на даному рівні деталями.

Першим кроком при побудові ієрархії DFD є побудова контекстних діаграм. Зазвичай при проектуванні щодо простих систем будується єдина контекстна діаграма із зіркоподібною топологією, в центрі якої знаходиться так званий головний процес, сполучений з приймачами і джерелами інформації. Для складних систем (десять і більше зовнішніх сутностей, розподілена природа і багатофункціональність системи) будується ієрархія контекстних діаграм. При цьому контекстна діаграма верхнього рівня містить не єдиний головний процес, а набір підсистем, з'єднаних потоками даних.

Кожен процес на DFD може бути деталізований за допомогою DFD або (якщо процес елементарний) специфікації. Специфікації є описами алгоритмів задач, які виконуються процесами. Мови специфікацій можуть варіюватися від структурованого природної мови або псевдокоду до візуальних мов моделювання.

При моделюванні бізнес-процесів діаграми потоків даних (DFD) використовуються для побудови моделей "AS-IS" і "AS-TO-BE", відображаючи, таким чином, існуючу і пропоновану структуру бізнес-процесів організації.

ARIS

В даний час спостерігається тенденція інтеграції різноманітних методів моделювання, що виявляється у формі створення інтегрованих засобів моделювання. Одним з таких засобів є програмний продукт, що носить назву ARIS (Architecture of Integrated Information Systems), розроблений німецькою фірмою IDS Scheer.

ARIS підтримує чотири типи моделей (і безліч видів моделей в кожному типі), що відображають різні аспекти досліджуваної системи:

Організаційні моделі, що представляють структуру системи - ієрархію організаційних підрозділів, посад і конкретних осіб, зв'язку між ними, а також територіальну прив'язку структурних підрозділів;

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

Інформаційні моделі, що відображають структуру інформації, необхідної для реалізації всієї сукупності функцій системи;

Моделі управління, що представляють комплексний погляд на реалізацію бізнес-процесів в рамках системи.

Для побудови перерахованих типів моделей використовуються як власні методи моделювання ARIS, так і різні відомі методи і мови моделювання, зокрема, UML. Процес моделювання можна починати з будь-якого з типів моделей.

Основна бізнес-модель ARIS - eEPC (extended Event-driven Process Chain, розширена модель ланцюжка процесів, керованих подіями). Нотація ARIS eEPC є розширенням нотації IDEF3. Бізнес-процес в нотації eEPC є потік послідовно виконуваних робіт (процедур, функцій), розташованих в порядку їх виконання. Реальна тривалість виконання процедур в eEPC візуально не відбивається.

Для отримання інформації про реальну тривалість процесів необхідно використовувати інші інструменти опису, наприклад, MS Project.

Моделі в ARIS являють собою діаграми, елементами яких є різноманітні об'єкти- "функції", "події", "структурні підрозділи", "документи" і т.д. Між об'єктами певних видів можуть бути встановлені зв'язкупевних видів ( "виконує", "приймає рішення", "повинен бути сроінформірован про результати" і т.д.). Кожному об'єкту відповідає певний набір атрибутів, які дозволяють ввести додаткову інформацію про конкретний об'єкт.

Основні об'єкти нотації eEPC:

Функція. Служить для опису функцій (процедур, робіт), які виконуються підрозділами / співробітниками підприємства. Кожна функція повинна бути ініційована подією і має завершуватися подією; в кожну функцію не може входити більше однієї стрілки, "запускає" виконання функції, і виходити більше однієї стрілки, яка описує завершення виконання функції.

Подія. Служить для опису реальних подій, що впливають на виконання функцій.

Організаційна одиниця. Наприклад, управління або відділ.

Документ. Відображає реальні носії інформації, наприклад, паперові документи.

Прикладна система.

Кластер інформації. Характеризує набір сутностей і зв'язків між ними.

Зв'язок між об'єктами. Тип відносин між об'єктами, наприклад, активація виконання функції деяким подією.

Логічний оператор. Оператор "І", "АБО" або виключає "АБО", дозволяє описати розгалуження процесу.

Якщо при створенні моделі в eEPC вказувати тільки послідовність виконання процедур, не піклуючись про відображення керуючих документів та інформації, отримані моделі будуть мати низьку цінність з точки зору аналізу та подальшого використання.

Для зберігання моделей в ARIS використовується об'єктна СУБД, і під кожен проект створюється нова база даних. Передбачено різні функції з адміністрування бази даних, наприклад, управління доступом. База даних являє собою ієрархічне сховище моделей.

Робота зі створення моделі повинна регламентуватися жорсткими і об'ємними угодами з моделювання (стандартами), ARIS підтримує механізм методологічних фільтрів, що дозволяють користувачеві використовувати тільки певний набір схем і об'єктів. Розробка таких угод вимагає значного часу і висококваліфікованих фахівців. Якщо проект з використанням ARIS починається без детального опрацювання таких угод, то ймовірність створення моделей бізнес-процесів, які не відповідають на поставлені питання, дуже висока.

Для моделювання бізнес-процесів використовується кілька різних методів, основою яких є як структурний, так і об'єктно-орієнтований підходи до моделювання. Однак поділ самих методів на структурні і об'єктні є досить умовним, оскільки найбільш розвинені методи використовують елементи обох підходів. До числа найбільш поширених методів відносяться:

метод функціонального моделювання SADT (IDEF0);

метод моделювання процесів IDEF3;

моделювання потоків даних DFD;

метод ARIS;

метод Ericsson-Penker;

метод моделювання, який використовується в технології Rational Unified Process

1. Метод SADT (Structured Analysis and Design Technique) вважається класичним методом процесного підходу до управління. Основний принцип процесного підходу полягає в структуруванні діяльності організації відповідно до її бізнес-процесами, а не організаційно-штатною структурою.

Метод SADT може використовуватися для моделювання найрізноманітніших процесів і систем. В існуючих системах метод SADT може бути використаний для аналізу функцій, виконуваних системою, і вказівки механізмів, за допомогою яких вони здійснюються.

Метод SADT являє собою сукупність правил і процедур, призначених дляпостроенія функціональної моделі об'єкта будь-якої предметної області. Функціональна модель SADT відображає функціональну структуру об'єкта, тобто вироблені їм дії і зв'язку між цими діями.

Результатом застосування методу SADT є модель, яка складається з діаграм, фрагментів текстів і глосарію, що мають посилання один на одного.

Однією з найбільш важливих особливостей методу SADT є поступове введення все більших рівнів деталізації у міру створення діаграм, що відображають модель.

Мал. 2.

2. Метод моделювання процесів IDEF3

Метод моделювання IDEF3 призначений для моделювання послідовності виконання дій і взаємозалежності між ними в рамках процесів.

Як і в методі IDEF0, основною одиницею моделі IDEF3 є діаграма. Інший важливий компонент моделі - дія, або в термінах IDEF3 «одиниця роботи» (Unit of Work). Діаграми IDEF3 відображають дію у вигляді прямокутника. Дії іменуються з використанням дієслів або віддієслівних іменників, кожному з дій присвоюється унікальний ідентифікаційний номер. Цей номер не використовується знову навіть в тому випадку, якщо в процесі побудови моделі дію видаляється. У діаграмах IDEF3 номер дії зазвичай передує номером його батька (рис. 3).

Мал. 3.

Істотні взаємини між діями зображуються за допомогою зв'язків. Все зв'язку в IDEF3 є односпрямованим, і хоча стрілка може починатися або закінчуватися на будь-якій стороні блоку, що позначає дію, діаграми IDEF3 зазвичай організовуються зліва направо таким чином, що стрілки починаються на правій і закінчуються на лівій стороні блоків. У табл. 1 наведені три можливих типи зв'язків.

Таблиця 1. Типи зв'язків IDEF3

3. Діаграми потоків даних DFD

Діаграми потоків даних (Data Flow Diagrams- DFD) є ієрархію функціональних процесів, пов'язаних потоками даних. Мета такого уявлення - продемонструвати, як кожен процес перетворює свої вхідні дані у вихідні, а також виявити відносини між цими процесами.

В Відповідно до даного методу модель системи визначається як ієрархія діаграм потоків даних, що описують асинхронний процес перетворення інформації від її введення в систему до видачі споживачеві. Джерела інформації (зовнішні сутності) породжують інформаційні потоки (потоки даних), які переносять інформацію до підсистем або процесів. Ті, в свою чергу, перетворюють інформацію і породжують нові потоки, які переносять інформацію до інших процесів або підсистем, накопичувачів даних або зовнішнім сутностей - споживачам інформації.

Діаграми верхніх рівнів ієрархії (контекстні діаграми) визначають основні процеси або підсистеми з зовнішніми входами і виходами. Вони деталізуються за допомогою діаграм нижнього рівня. Така декомпозиція триває, створюючи багаторівневу ієрархію діаграм, до тих пір, поки не буде досягнутий рівень декомпозиції, на якому деталізувати процеси далі втрачає сенс.

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

• * Зовнішні сутності;
• * Системи і підсистеми;
• * Процеси;
• * Накопичувачі даних;
• * Потоки даних.
• 4. Метод ARIS

Система ARIS (Architecture of Integrated Information System), розроблений німецькою фірмою IDS Scheer, являє собою комплекс засобів аналізу і моделювання діяльності підприємства. Її методичну основу складає сукупність різних методів моделювання, що відображають різні погляди на досліджувану систему. Одна і та ж модель може розроблятися з використанням декількох методів, що дозволяє використовувати ARIS фахівцям з різними теоретичними знаннями і налаштовувати його на роботу з системами, що мають свою специфіку.

ARIS підтримує чотири типи моделей, що відображають різні аспекти досліджуваної системи:

• * Організаційні моделі, що представляють структуру системи - ієрархію організаційних підрозділів, посад і конкретних осіб, зв'язку між ними, а також територіальну прив'язку структурних підрозділів;
• * Функціональні моделі, що містять ієрархію цілей, що стоять перед апаратом управління, з сукупністю дерев функцій, необхідних для досягнення поставлених цілей;
• * Інформаційні моделі, що відображають структуру інформації, необхідної для реалізації всієї сукупності функцій системи;
• * Моделі управління, що представляють комплексний погляд на реалізацію бізнес-процесів в рамках системи.

Для побудови перерахованих типів моделей використовуються як власні методи моделювання ARIS, так і різні відомі методи і мови моделювання, зокрема, UML.

Моделі в ARIS являють собою діаграми, елементами яких є різноманітні об'єкти - «функція», «подія», «структурний підрозділ», «документ» і т.п. Між об'єктами встановлюються різноманітні зв'язки. Так, між об'єктами «функція» і «структурний підрозділ» можуть бути встановлені зв'язки наступних видів:

• * Виконує;
• * приймає рішення;
• * Бере участь у виконанні;
• * Повинен бути проінформований про результати;
• * Консультує виконавців;
• * Приймає результати.

Основна бізнес-модель ARIS - eEPC (extended Eventdriven Process Chain - розширена модель ланцюжка процесів, керованих подіями). У табл. 2 наводяться основні об'єкти, що використовуються в даній нотації.

Таблиця 2. Об'єкти моделі eEPC

Мал. 4.

Основна перевага методу ARIS полягає в його комплексності, яка проявляється у взаємозв'язку між моделями різних типів. Метод ARIS дозволяє описувати діяльність організації з різних точок зору і встановлювати зв'язки між різними моделями. Однак такий підхід важко реалізувати на практиці, оскільки тягне за собою велику витрату ресурсів (людських і фінансових) протягом тривалого часу. Крім того, інструментальне середовище ARIS досить дорога і складна в використанні.

5. Метод Ericsson-Penker представляє інтерес перш за все у зв'язку зі спробою застосування мови об'єктного моделювання UML (спочатку призначеного для моделювання архітектури систем ПО) для моделювання бізнес-процесів. Це стало можливим завдяки наявності в UML механізмів розширення.

Механізми розширення UML призначені для того, щоб розробники могли адаптувати мову моделювання до своїх конкретних потреб, не змінюючи при цьому його метамодель.

Мал. 5.

Наявність механізмів розширення принципово відрізняє UML від таких засобів моделювання, як IDEF0, IDEF1X, IDEF3, DFD та ін. Перераховані мови моделювання можна визначити як сильно типізовані (по аналогії з мовами програмування), оскільки вони не допускають довільній інтерпретації семантики елементів моделей. UML, допускаючи таку інтерпретацію (в основному за рахунок стереотипів), є слабо універсальна мова. До його механізмам розширення відносяться:

• * Стереотипи;
• * Тегованих (іменовані) значення;
• * Обмеження.

Стереотип - це новий тип елемента моделі, який визначається на основі вже існуючого елемента. Стереотипи розширюють нотацію моделі, можуть застосовуватися до будь-яких елементів моделі і представляються у вигляді текстової мітки або піктограми.

Іменоване значення - це пара рядків «тег = значення» або «ім'я = вміст», в яких зберігається додаткова інформація про будь-якому елементі системи, наприклад, час створення, статус розробки або тестування, час закінчення роботи над ним і т.п.

Обмеження - це семантичне обмеження, що має вигляд текстового вираження на природному або формальній мові (OCL - Object Constraint Language), яке неможливо виразити за допомогою графічної нотації UML.

Автори методу Ericsson-Penker створили свій профіль UML для моделювання бізнес-процесів під назвою Ericsson-Penker Business Extensions, ввівши набір стереотипів, що описують процеси, ресурси, правила і цілі діяльності організації.

Метод використовує чотири основні категорії бізнес-моделі:

• * Ресурси - різні об'єкти, що використовуються або беруть участь в бізнес-процесах (люди, матеріали, інформація або продукти). Ресурси структуровані, взаємопов'язані і підрозділяються на фізичні, абстрактні, інформаційні та людські.
• * Процеси - види діяльності, які змінюють стан ресурсів відповідно до бізнес-правилами.
• * Цілі - призначення бізнес-процесів. Цілі можуть бути розбиті на підцілі і співвіднесені з окремими процесами. Цілі досягаються в процесах і висловлюють необхідний стан ресурсів. Цілі можуть бути виражені у вигляді одного або більше правил.
• * Бізнес-правила - умови або обмеження виконання процесів (функціональні, поведінкові або структурні). Правила можуть диктуватися зовнішнім середовищем (інструкціями або законами) або можуть бути визначені в межах бізнес-процесів. Правила можуть бути визначені з використанням мови OCL, який є частиною стандарту UML.

Всі ці категорії пов'язані між собою: правило може визначати спосіб структурування ресурсів, ресурс призначається конкретному процесу, мета пов'язана з виконанням конкретного процесу.

Основний діаграмою UML, використовуваної в даному методі, є діаграма діяльності. Основним елементом діаграми є діяльність (activity). Діяльність зображується у вигляді закругленого прямокутника з текстовим описом. Будь-яка діаграма діяльності повинна мати початкову точку, що визначає початок потоку подій. Кінцева точка необов'язкова. На діаграмі може бути кілька кінцевих точок, але тільки одна початкова.

6. Метод моделювання, який використовується в технології Rational Unified Process

Мова UML використовується також в методі моделювання бізнес-процесів, що є частиною технології Rational Unified Process компанії IBM Rational Software. Цей метод, спрямований перш за все на створення основи для формування вимог до ПЗ, передбачає побудову двох базових моделей:

• * Моделі бізнес-процесів (Business Use Case Model);
• * Моделі бізнес-аналізу (Business Analysis Model).

Модель бізнес-процесів - модель, що описує бізнес-процеси організації в термінах ролей і їх потреб. Вона являє собою розширення моделі варіантів використання (use case) UML за рахунок введення набору стереотипів - Business Actor (стереотип дійової особи) та Business Use Case (стереотип варіанти використання).

Business Actor (дійова особа бізнес-процесів) - це деяка роль, зовнішня по відношенню до бізнес-процесів організації. Потенційними кандидатами в дійові особи бізнес-процесів є: акціонери, замовники, постачальники, партнери, потенційні клієнти, місцеві органи влади, співробітники підрозділів організації, діяльність яких не охоплена моделлю, зовнішні системи.

Список дійових осіб складається шляхом відповіді на наступні питання:

• * Хто отримує користь з існування організації?
• * Хто допомагає організації здійснювати свою діяльність?
• * Кому організація передає інформацію і від кого отримує?

Business Use Case (варіант використання з точки зору бізнес-процесів) визначається як опис послідовності дій (потоку подій) в рамках деякого бізнес-процесу, що приносить відчутний результат конкретного дійової особи. Це визначення подібно загальним визначенням бізнес-процесу, але має більш точний зміст. У термінах об'єктної моделі Business Use Case представляє собою клас, об'єктами якого є конкретні потоки подій в рамках описуваного бізнес-процесу.

Даний метод концентрує увагу в першу чергу на елементарних бізнес-процесах. Такий процес можна визначити як завдання, що виконується однією людиною в одному місці в один час у відповідь на деяку подію, яка приносить конкретний результат і переводить дані в якийсь стійкий стан (наприклад, підтвердження платежу по кредитній картці). Виконання такого завдання зазвичай включає від п'яти до десяти кроків і може займати від декількох хвилин до декількох днів, але розглядається як один сеанс взаємодії дійової особи з виконавцями.

Кожен Business Use Case відображає мету або потреба деякого дійової особи.

Опис Business Use Case представляє собою специфікацію (текстовий документ), яка, подібно до звичайного варіанту використання, складається з наступних пунктів:

• * Найменування;
• * короткий опис;
• * Мети і результати (з точки зору чинного особи);
• * Опис сценаріїв (основного і альтернативних);
• * Спеціальні вимоги (обмеження за часом виконання або інших ресурсів);
• * Розширення (виняткові ситуації);
• * Язку з іншими Business Use Case;
• * Діаграми діяльності (для наочного опису сценаріїв - при необхідності).

Опис Business Use Case може супроводжуватися метою процесу, яка так само, як і в методі ErikssonPenker, моделюється за допомогою класу зі стереотипом «goal», а дерево цілей зображується у вигляді діаграми класів.

Для кожного Business Use Case будується модель бізнес-аналізу - об'єктна модель, що описує реалізацію бізнес-процесу в термінах взаємодіючих об'єктів (бізнес-об'єктів - Business Object), що належать до двох класів - Business Worker і Business Entity.

Business Worker (виконавець) - активний клас, що представляє собою абстракцію виконавця, що виконує деякі дії в рамках бізнес-процесу. Виконавці взаємодіють між собою і маніпулюють різними сутностями, беручи участь в реалізаціях сценаріїв Business Use Case. На діаграмі класів UML виконавець представляється у вигляді класу зі стереотипом «business worker».

Поняття Business Entity аналогічно поняттю сутності в моделі «сутність-зв'язок», за винятком того, що в даній моделі не визначається поведінка суті, а в об'єктної моделі сутність може мати набір обов'язків. На діаграмі класів UML сутність представляється у вигляді класу зі стереотипом «business entity».

Бізнес-процес - це логічний, послідовний, взаємозалежний набір заходів, який споживає ресурси, створює цінність і видає результат. У міжнародному стандарті ISO 9000: 2000 прийнятий термін "процес", проте в даний час ці терміни можна вважати синонімами. Моделювання бізнес-процесів - це ефективний засіб пошуку шляхів оптимізації діяльності компанії, що дозволяє визначити, як компанія працює в цілому і як організована діяльність на кожному робочому місці. Під методологією (нотацією) створення моделі (опису) бізнес-процесу розуміється сукупність способів, за допомогою яких об'єкти реального світу і зв'язку між ними представляються у вигляді моделі. Для кожного об'єкта і зв'язків характерні ряд параметрів, або атрибутів, що відображають опредёленние характеристики реального об'єкта (номер об'єкта, назва, опис, тривалість виконання (для функцій), вартість і ін.).

Основу багатьох сучасних методологій моделювання бізнес-процесів склали методологія SADT (Structured Analysis and Design Technique - метод структурного аналізу і проектування), сімейство стандартів IDEF (Icam DEFinition, де Icam - це Integrated Computer-Aided Manufacturing) і алгоритмічні мови.

Основні типи методологій моделювання і аналізу бізнес-процесів:

• Моделювання бізнес-процесів (Business Process Modeling). Найбільш широко використовувана методологія опису бізнес-процесів - стандарт IDEF0. Моделі в нотації IDEF0 призначені для високорівневого опису бізнесу компанії в функціональному аспекті.
• Опис потоків робіт (Work Flow Modeling). Стандарт IDEF3 призначений для опису робочих процесів і близький до алгоритмическим методам побудови блок-схем.
• Опис потоків даних (Data Flow Modeling). Нотація DFD (Data Flow Diagramming), дає змогу побачити послідовність робіт, що виконуються по ходу процесу, і потоки інформації, що циркулюють між цими роботами.
• Інші методології.

IDEF0

Модель складається з діаграм, фрагментів текстів і глосарію, що мають посилання один на одного. Діаграми - головні компоненти моделі, всі функції і інтерфейси на них представлені як блоки і дуги. Місце з'єднання дуги з блоком визначає тип інтерфейсу:

Тип інтерфейсу:

• Керуюча інформація входить в блок зверху.
• Вхідна інформація входить в блок зліва.
• Результати виходять з блоку справа.
• Механізм (людина або автоматизована система), який здійснює операцію, входить в блок знизу.

Кожен компонент моделі може бути декомпозирован (розшифрований більш детально) на іншій діаграмі. Рекомендується припиняти моделювання, коли рівень деталізації моделі задовольняє її мета. Загальна кількість рівнів в моделі не повинно перевищувати 5-6.

Побудова діаграм починається з отримання всієї системи у вигляді одного блоку і дуг, що зображують інтерфейси з функціями поза системою. Потім блок, який представляє систему в якості єдиного модуля, деталізується на іншій діаграмі за допомогою декількох блоків, з'єднаних інтерфейсними дугами. Кожна детальна діаграма є декомпозицією блоку з діаграми попереднього рівня. На кожному кроці декомпозиції діаграма попереднього рівня називається батьківської ще детальної діаграми.

На таких діаграмах не вказані явно ні послідовність, ні час. Метод має ряд недоліків: складність сприйняття (велика кількість дуг на діаграмах і велика кількість рівнів декомпозиції), труднощі ув'язки декількох процесів.

IDEF3

Цей метод призначений для моделювання послідовності виконання дій і взаємозалежності між ними в рамках процесів. Моделі IDEF3 можуть використовуватися для деталізації функціональних блоків IDEF0, що не мають діаграм декомпозиції.

Діаграми IDEF3 відображають дію у вигляді прямокутника. Дії іменуються з використанням дієслів або віддієслівних іменників, кожному з дій присвоюється унікальний ідентифікаційний номер (номер дії зазвичай передує номером його батька, наприклад, 1.1.). Все зв'язку в IDEF3 є односпрямованим і організовуються зліва направо.

Типи зв'язків IDEF3:

• Тимчасове передування (Temporal precedence), проста стрілка. Початкове дія повинна завершитися, перш ніж кінцеве дію зможе початися.
• Об'єктний потік (Object flow), стрілка з подвійним наконечником. Вихід вихідного дії є входом кінцевого дії. Початкове дія повинна завершитися, перш ніж кінцеве дію зможе початися. Найменування потокових зв'язків повинні чітко ідентифікувати об'єкт, який передається з їх допомогою.
• Нечітке відношення (Relationship), пунктирна стрілка.

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

Розгалуження процесу відбивається за допомогою спеціальних блоків:

• "І", блок зі знаком &.
• "Що виключає АБО" ( "одне з"), блок зі знаком Х.
• "АБО", блок зі знаком О.

Якщо дії "І", "АБО" повинні виконуватися синхронно, це позначається двома подвійними вертикальними лініями всередині блоку, асинхронно - однієї.

Метод IDEF3 дозволяє декомпозировать дію кілька разів, що забезпечує документування альтернативних потоків процесу в одній моделі.

DFD

Мета такого уявлення - продемонструвати, як кожен процес перетворює свої вхідні дані у вихідні. Може відображати не тільки інформаційні, але й матеріальні потоки.

Також, як і в інших моделях, підтримується декомпозиція.

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

• Зовнішні сутності (матеріальний об'єкт або фізична особа, що є джерелом або приймачем інформації, наприклад, замовники, персонал, постачальники, клієнти, склад).
• Системи і підсистеми (наприклад, підсистема по роботі з фізичними особами).
• Процеси (перетворення вхідних потоків даних у вихідні відповідно до певного алгоритму; фізично це може бути, наприклад, підрозділ організації (відділ), яке виконує обробку вхідних документів і випуск звітів, програма, апаратно реалізоване логічне пристрій і т.д.).
• Накопичувачі даних (абстрактні пристрої для зберігання інформації).
• Потоки даних (на діаграмі - стрілки).

Необхідно розміщувати на кожній діаграмі від 3 (менше немає сенсу) до 7 (більше - НЕ сприймаються) процесів, не захаращуючи діаграми несуттєвими на даному рівні деталями. Першим кроком при побудові ієрархії DFD є побудова контекстних діаграм. Зазвичай при проектуванні щодо простих систем будується єдина контекстна діаграма із зіркоподібною топологією, в центрі якої знаходиться так званий головний процес, сполучений з приймачами і джерелами інформації. Для складних систем (десять і більше зовнішніх сутностей, розподілена природа і багатофункціональність системи) будується ієрархія контекстних діаграм. При цьому контекстна діаграма верхнього рівня містить не єдиний головний процес, а набір підсистем, з'єднаних потоками даних.

Кожен процес на DFD може бути деталізований за допомогою DFD або (якщо процес елементарний) специфікації. Специфікації є описами алгоритмів задач, які виконуються процесами. Мови специфікацій можуть варіюватися від структурованого природної мови або псевдокоду до візуальних мов моделювання.

При моделюванні бізнес-процесів діаграми потоків даних (DFD) використовуються для побудови моделей "AS-IS" і "AS-TO-BE", відображаючи, таким чином, існуючу і пропоновану структуру бізнес-процесів організації.

ARIS

В даний час спостерігається тенденція інтеграції різноманітних методів моделювання, що виявляється у формі створення інтегрованих засобів моделювання. Одним з таких засобів є програмний продукт, що носить назву ARIS (Architecture of Integrated Information Systems), розроблений німецькою фірмою IDS Scheer.

ARIS підтримує чотири типи моделей (і безліч видів моделей в кожному типі), що відображають різні аспекти досліджуваної системи.

Підтримувані типи моделей в ARIS:

• Організаційні моделі, що представляють структуру системи - ієрархію організаційних підрозділів, посад і конкретних осіб, зв'язку між ними, а також територіальну прив'язку структурних підрозділів.
• Функціональні моделі, що містять ієрархію цілей, що стоять перед апаратом управління, з сукупністю дерев функцій, необхідних для досягнення поставлених цілей.
• Інформаційні моделі, що відображають структуру інформації, необхідної для реалізації всієї сукупності функцій системи.
• Моделі управління, що представляють комплексний погляд на реалізацію бізнес-процесів в рамках системи.

Для побудови перерахованих типів моделей використовуються як власні методи моделювання ARIS, так і різні відомі методи і мови моделювання, зокрема, UML. Процес моделювання можна починати з будь-якого з типів моделей.

Основна бізнес-модель ARIS - eEPC (extended Event-driven Process Chain, розширена модель ланцюжка процесів, керованих подіями). Нотація ARIS eEPC є розширенням нотації IDEF3. Бізнес-процес в нотації eEPC є потік послідовно виконуваних робіт (процедур, функцій), розташованих в порядку їх виконання. Реальна тривалість виконання процедур в eEPC візуально не відбивається. Для отримання інформації про реальну тривалість процесів необхідно використовувати інші інструменти опису, наприклад, MS Project.

Моделі в ARIS являють собою діаграми, елементами яких є різноманітні об'єкти - "функції", "події", "структурні підрозділи", "документи" і т.д. Між об'єктами певних видів можуть бути встановлені зв'язки певних видів ( "виконує", "приймає рішення", "повинен бути проінформований про результати" і т.д.). Кожному об'єкту відповідає певний набір атрибутів, які дозволяють ввести додаткову інформацію про конкретний об'єкт.

Основні об'єкти нотації eEPC:

• Функція.Служить для опису функцій (процедур, робіт), які виконуються підрозділами / співробітниками підприємства. Кожна функція повинна бути ініційована подією і має завершуватися подією; в кожну функцію не може входити більше однієї стрілки, "запускає" виконання функції, і виходити більше однієї стрілки, яка описує завершення виконання функції.
• Подія.Служить для опису реальних подій, що впливають на виконання функцій.
• Організаційна одиниця.Наприклад, управління або відділ.
• Документ.Відображає реальні носії інформації, наприклад, паперові документи.
• Прикладна система.
• Кластер інформації.Характеризує набір сутностей і зв'язків між ними.
• Зв'язок між об'єктами.Тип відносин між об'єктами, наприклад, активація виконання функції деяким подією.
• Логічний оператор.Оператор "І", "АБО" або виключає "АБО", дозволяє описати розгалуження процесу.

Якщо при створенні моделі в eEPC вказувати тільки послідовність виконання процедур, не піклуючись про відображення керуючих документів та інформації, отримані моделі будуть мати низьку цінність з точки зору аналізу та подальшого використання.

Володимир Рєпін, Віталій ЕліферовГлава з книги «Процесний підхід до управління. Моделювання бізнес-процесів »
Видавництво "Манн, Іванов і Фербер"

Аналіз процесів слід розуміти в широкому сенсі: в нього включається не тільки робота з графічними схемами, а й аналіз всієї доступної інформації щодо процесів, вимірювання їх показників, порівняльний аналіз і т. Д.

Класифікація видів аналізу процесів наводиться на рис. 1.

Мал. 1.Класифікація видів аналізу бізнес-процесів

Можна виділити кілька методик суб'єктивної оцінки процесів. Багато в чому такі методики були розроблені в працях основоположників і послідовників методології реінжинірингу бізнес-процесів, наприклад у Хаммера і Чампі, Робсона і Уллах і т. Д. Крім того, для якісного аналізу процесів можуть бути використані загальновідомі методи аналізу: SWOT-аналіз, аналіз за допомогою Бостонської матриці та інші.

Методи графічного аналізу процесів менш опрацьовані. У відомій нам літературі їх класифікація не зустрічається. У зв'язку з цим ми пропонуємо і розглядаємо власну найпростішу класифікацію методів графічного аналізу процесів.

Додатково до зазначених методів ми пропонуємо ще один метод кількісної оцінки процесів, заснований на аналізі відповідності процесу типових вимог по його організації. Пропонована структура типових вимог до процесу заснована на вимогах стандартів ISO серії 9000. Крім того, процес може бути підданий аналізу на відповідність законодавчим і нормативним актам.

Методи кількісного аналізу процесів більш детально розроблені у світовій практиці. Більша їх частина заснована на зборі, обробці та аналізі статистичної інформації про процеси. Фактично методи статистичного аналізу процесів розроблялися як інструменти, використовувані при впровадженні систем менеджменту якості.

В даний час широкого поширення набули такі методи кількісного аналізу, як імітаційне моделювання процесів і АВС-аналіз процесів (операційний аналіз витрат). Вони в рамках книги розглядатися не будуть, так як їх використання на практиці передбачає великі витрати і тривалий час виконання проектів в організаціях. На наш погляд, використання даних методів в організаціях, які мають чіткої регламентації процесів і засобів вимірювання їх показників, є недоцільним. Оскільки більшість російських підприємств знаходиться саме в такому стані, то застосування імітаційного моделювання та АВС-аналізу для них передчасно.

SWOT-аналіз процесу

SWOT-аналіз процесу передбачає виявлення його сильних і слабких сторін, можливостей поліпшення і загроз погіршення. У табл. 3.15 наводиться приклад SWOT-аналізу процесу.

Табл. 1.Приклад SWOT-аналізу процесу

Сильні сторони	Слабкі сторони
1. Є керівник - лідер. 2. Висока якість продукції процесу. 3. Наявність кваліфікованих кадрів. 4. Високий ступінь автоматизації	1. Клієнти не задоволені термінами поставки продукції. 2. Часткове дублювання функцій. 3. Ні системи вимірювання показників ефективності процесу. 4. Немає посадових інструкцій на ряд виконавців
можливості	загрози
1. Підвищення ефективності за рахунок впровадження системи CRM. 2. Зниження накладних витрат. 3. Скорочення термінів виконання замовлень за рахунок подальшої автоматизації	1. Втрата клієнтів внаслідок тривалих термінів поставки. 2. Зниження якості продукції. 3. Велика залежність від особистостей виконавців процесу

SWOT-аналіз процесу можна проводити наступним чином:

• провести анкетування керівників і фахівців організації;
• обробити результати анкетування, оцінюючи кількість схожих за змістом відповідей і формуючи рейтинг відповідей;
• побудувати таблицю SWOT-аналізу процесу.

SWOT-аналіз - це інструмент для якісної попередньої оцінки процесу. Отримані на його основі дані можуть бути використані в подальшому для з'ясування причин низької ефективності процесу і визначення характеризують його показників.

Аналіз проблем процесу: виділення проблемних областей

Виділення проблемних областей - найпростіший засіб якісного аналізу процесу. Основне призначення цього методу аналізу полягає в тому, щоб визначити напрямки подальшого більш поглибленого аналізу. Для виявлення проблемних областей слід сформувати укрупнену схему процесу, відобразивши на ній основні групи виконуваних функцій і їх виконавців. Після цього на схемі потрібно вказати проблемні області і дати їх коротку характеристику. На рис. 2 наводиться приклад такої схеми процесу.

Виявлення проблемних областей здійснюється шляхом інтерв'ювання керівників і співробітників, що беруть участь в даному процесі. Так, на прикладі рис. 2 проводилося анкетування співробітників РСУ - ремонтно-будівельного управління підприємства. Отриманий процес ремонтів обладнання на верхньому рівні складається з семи груп функцій. Кожну з них виконують певні підрозділи.

На рис. 2 показані чотири проблемні області. Перша з них пов'язана із закупівлею обладнання, друга - з залученням підрядників, третя - з виконанням ремонтів, четверта - з здійсненням розрахунків за виконані роботи та обладнання. Наводяться короткі формулювання проблем для кожної проблемної області.

Мал. 2.Проблемні області процесу

Отримана таким чином схема процесу може служити предметом для обговорення і аналізу при виконанні проекту реорганізації процесів. Так, наприклад, інформація про наявність проблем з виконання ремонтних робіт може бути розглянута більш детально: який порядок виконання ремонтів, як і ким відпускаються матеріали і запасні частини, як ведеться облік, хто відповідає за контроль кошторисів, хто оперативно керує процесом і т. Д . Виділення проблемних областей, таким чином, є засобом акцентування уваги керівників і експертів на певних фрагментах процесу.

Ранжування процесів на основі суб'єктивної оцінки

Ранжування процесів виконується на підготовчій стадії проекту, коли необхідно дати характеристику кожному крупному процесу організації і прийняти рішення, які з них слід покращувати в першу чергу. Детально про цю методику можна прочитати в.

Існує кілька підходів до ранжирування процесів. Ми розглянемо найпростішу методику. На першому етапі необхідно скласти перелік основних процесів організації. Потім формується таблиця наступного вигляду (табл. 2):

Табл. 2.Ранжування процесів організації

Важливість процесу / стан процесу	висока ефективність	Середня ефективність	низька ефективність
Дуже важливий процес	процес 1	-	процес 2
важливий процес	процес 6	процес 3	-
другорядний процес	процес 5	процес 7	процес 4

Аналіз табл. 2 показує, що процес 2 дуже важливий для діяльності організації і в той же час найменш ефективний. Таким чином, в першу чергу необхідно спрямувати зусилля на аналіз і реорганізацію процесу 2. Для кожної організації табл. 2 буде заповнена по-різному. Більш того, з плином часу розташування процесів в елементах таблиці змінюється.

Слід зазначити, що ранжування процесів за допомогою такої таблиці вельми суб'єктивно. Довгострокові проекти по поліпшенню діяльності організації не можуть базуватися на використанні подібних методів аналізу. Зазначений метод зазвичай застосовується при проведенні семінарів-тренінгів для керівників, нарад, мозкових штурмів і подібних заходів, мета яких полягає в здійсненні швидкого аналізу ситуації з процесами підприємства на основі якісних показників.

Аналіз процесу по відношенню до типових вимог

Будь-який процес організації можна аналізувати з точки зору задоволення деяким вимогам. В даний час в світі немає спеціалізованих стандартів, що регламентують вимоги до процесів бізнесу (ISO / IEC 15504-2: 2003). Пропонована нижче структура вимог до організації процесу розроблена нами з урахуванням вимог стандарту ISO 9001.

Стандарти ISO серії 9000 рекомендують використовувати цикл PDCA (Plan-Do-Check-Act) для створення системи постійного поліпшення процесу. Ми вважаємо, що застосування даного циклу також є обов'язковою вимогою, яке необхідно пред'являти до процесів.

Крім зазначених вище вимог, процес повинен включати відому схему управління за відхиленнями: «планування процесу - виконання процесу - облік - контроль - прийняття рішень».

Отже, типовий процес повинен, на наш погляд, відповідати таким групам вимог:

• регламентація всіх складових процесу;
• використання циклу постійного поліпшення процесу PDCA.

Вимоги до організації процесу, що враховують рекомендації стандарту ІСО 9001, представлені в табл. 3.

Табл. 3.Запитальник для аналізу процесу по відношенню до типових вимог

При проведенні аналізу процесу повинна бути зібрана інформація відповідно до вимог табл. 3. Виконання такої роботи може бути доцільним при здійсненні проекту реорганізації процесів на підприємстві. Процес піддається аналізу на наявність циклу PDCA. Нагадаємо, що цикл PDCA створюється навколо процесу, як показано на рис. 3. Призначення функцій циклу постійного поліпшення процесу показано в табл. 4.

Мал. 3.цикл PDCA

Табл. 4.Цикл PDCA для процесу

Процес повинен бути підданий аналізу з точки зору наявності циклу управління за відхиленнями. Цей цикл включає п'ять груп функцій процесу, призначення яких показано в табл. 5.

Табл. 5.Функції циклу управління

№	Функція циклу управління	опис
1	планування	Група функцій по техніко-економічного та фінансового планування виконання робіт по процесу
2	виконання	Група функцій щодо виконання процесу (приклади: підготовка документа, виробництво продукції і т. Д.)
3	облік	Група функцій по реєстрації фактичної інформації щодо виконання процесу
4	контроль	Група функцій з контролю виконання планових показників діяльності в порівнянні з фактичними
5	Прийняття рішень	Група функцій з підготовки та прийняття управлінських рішень на підставі даних за відхиленнями від планових показників діяльності

Схема циклу управління за відхиленнями показана на рис. 4.

Мал. 4.Цикл управління за відхиленнями

Якщо в результаті аналізу з'ясовується, що процес задовольняє всім зазначеним вище трьох груп вимог, то організацію процесу можна вважати задовільною. Подальша робота щодо поліпшення такого процесу буде полягати в аналізі та поліпшення його показників.

Візуальний аналіз графічних схем процесу

Візуальний аналіз графічних схем процесів має ряд істотних обмежень. Справа в тому, що процес являє собою складний об'єкт, описати який у вигляді однієї графічної схеми неможливо. Будь-яка графічна схема процесу буде відображати інформацію відповідно до обраним засобом опису (нотацією). Будь-які помилки або недоробки при формуванні графічної схеми призводять до неможливості ефективного аналізу. Наприклад, при описі процесу аналітик забув вказати кілька вхідних і вихідних документів. Візуальний аналіз може, звичайно, вказати на їх відсутність, але ця інформація нічого не дає для подальшого поліпшення процесу, так як ці документи існують.

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

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

В першу чергу схему процесу можна піддати аналізу з точки зору входів і виходів. Аналіз входів / виходів складається з двох частин:

1. Аналіз потреби у входах / аналіз потреби в ви ходах.
2. Аналіз невикористовуваних виходів.

Аналіз потреби у входах виконується наступним чином. Послідовно розглядається кожна функція процесу, виконується її змістовний аналіз. Визначається склад необхідної для цього інформації. Проводиться перевірка, чи є дана інформація у вхідних документах. Якщо потрібні відомості не містяться в жодному документі, це може означати відсутність необхідного для виконання функції документа. Ілюстрація до зазначеного алгоритму показана на рис. 5.

Мал. 5.Виявлення потреби у входах

Аналогічно виконується аналіз по матеріальним входів, персоналу, інфраструктурі.

Очевидно, що якщо в якійсь частині процесу ми виявили недолік вхідного документа, необхідно визначити функцію, для якої він є виходом. Пошук таких функцій (процесів) за схемами моделей навряд чи можливий. Простіше опитати відповідних виконавців і знайти постачальників потрібної інформації. Далі з'ясувати, чому дана інформація не оформлюється документально і не передається зацікавленій в її отриманні посадовій особі. Сказане ілюструє рис. 6.

Мал. 6.Виявлення потреби в виходах

Аналіз невикористовуваних виходів означає пошук тих виходів процесу (функції), які не використовуються в інших процесах (функціях). Практика показує, що на підприємствах існує досить багато документів, які формуються, але в подальшому або не використовуються, або використовуються формально. Останній випадок означає, що документ може підготовлятися, передаватися за призначенням, а далі просто потрапляє в відповідну папку і припадає пилом там роками. Такі документи можна сміливо відносити до невживаних. По крайней мере, на них слід звернути увагу і по можливості від них позбавлятися.

Для пошуку невикористовуваних виходів слід скласти таку таблицю:

Табл. 6.Пошук невикористовуваних виходів процесу

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

Розглянемо можливості графічного аналізу функцій процесу. Він дозволяє виявити:

• відсутність необхідних функцій;
• наявність зайвих функцій;
• дублювання функцій.

Аналіз відсутності необхідних функцій проводиться на основі знань експерта про те, як повинен бути організований процес для забезпечення його ефективного функціонування. Приклад такого аналізу показаний на рис. 7.

Мал. 7.Відсутність необхідної функції в моделі процесу

Можна дати кілька рекомендацій про те, які функції повинні бути обов'язково присутніми в процесі. Для моделей верхнього рівня, підготовлених в нотації IDEF0, це функції планування, обліку, контролю і прийняття рішень. Для моделей нижнього рівня, підготовлених у форматі IDEF3 (ARIS eEPC), можна виділити кілька важливих функцій, про які не слід забувати при побудові моделі:

• функції контролю: вхідний контроль, статистичний контроль процесу;
• функції, що їх в позаштатних ситуаціях;
• функції по обробці невідповідної продукції;
• функції з обліку фактичної інформації по процесу.

Розглянемо функції контролю. На рис. 8 наведено приклад процесу, в який додатково внесено дві такі функції. Перша здійснює вибірковий вхідний контроль, при цьому його результати фіксуються документально - на рис. 8 показаний документ «Результати вхідного контролю». За підсумками виконання функції можуть наступити два альтернативних події: «Вхід не відповідає вимогам» і «Вхід відповідає вимогам». У першому випадку відбувається перехід на виконання функції «Ухвалення рішення власником процесу». Вона повинна бути описана у вигляді окремого процесу управління. (Можливий, звичайно, варіант, коли рішення приймає виконавець процесу.)

Мал. 8.Відсутність функцій контролю

Друга функція контролю носить статистичний характер. Здійснюється вибіркова перевірка виходів процесу. Результати перевірки фіксуються в документі «Результати статистичного контролю» і надалі повинні використовуватися для управління процесом.

Як правило, при описі процесів часто забувають про різні позаштатних ситуаціях і діях у разі їх настання. Цінність таких схем процесів істотно знижується. Приклад відображення позаштатної ситуації показаний на рис. 9.

Мал. 9.Відсутність функції по обробці позаштатної ситуації

На рис. 9 передбачається, що після виконання першої функції процесу можлива позаштатна ситуація. Вона повинні бути оброблена. Для цього в процес включається функція «Обробка позаштатної ситуації», два нових події і символи логіки виключає і звичайного «АБО».

На схемах процесів може бракувати функцій по роботі з невідповідною продукцією (послугами, документами). На рис. 10 наводиться приклад такого процесу. Функції з обліку фактичної інформації є дуже важливими, оскільки дозволяють накопичувати управлінську інформацію по параметрам виконання процесу, яку можна використовувати для його аналізу і поліпшення. З точки зору теорії необхідно фіксувати результати виконання кожної функції. На практиці слід збирати ту фактичну інформацію, використання якої доцільно в подальшому.

Мал. 10.Відсутність функції по обробці невідповідної продукції

Наведемо простий приклад відсутньої функції з реєстрації параметрів виконання процесу (див. Рис. 11).

Мал. 11.Відсутність функції з реєстрації фактичної інформації про процес

Графічна схема процесу повинна бути перевірена на наявність зайвих функцій. Такий аналіз проводиться за наступним алгоритмом. Послідовно розглядаються всі функції процесу, аналізується кожна з них. Задається питання: «Що буде, якщо виключити дану функцію з процесу?» Можливі ситуації, коли в ньому існують функції, які не потрібні. Від них необхідно позбавлятися.

На закінчення підрозділу з аналізу графічних схем процесів зупинимося на аналізі дублювання функцій. Приклад такого аналізу наведено на рис. 12.

Мал. 12. Аналіз дублювання функцій процесу

На рис. 12 представлено два різних процесу. Вони можуть виконуватися в різних підрозділах. Розглядається дві функції: «функція процесу 1» і «функція процесу 2». Їх назви можуть істотно відрізнятися. Виходи цих функцій також різні: «документ 1» і «документ 2». Яким чином виявити дублювання? Слід провести аналіз виходів цих двох функцій за наступними напрямками:

• аналіз інформації, що міститься в кожному документі;
• аналіз споживачів кожного документа;
• рішення, що приймаються на основі інформації, що міститься в документах.

На рис. 12 показано, що в обох документах міститься одна і та ж «інформація А». Це може означати, що розглядаються функції повністю або частково дублюють один одного. По крайней мере, варто звернути на них увагу. Як виявити дублювання функцій на практиці? Очевидно, що порівнювати між собою функції процесів неможливо. В першу чергу необхідно скласти список функцій, «підозрюваних» в дублюванні. Такого роду інформація може бути отримана на основі інтерв'ю зі співробітниками та керівниками підрозділів.

Крім того, аналітик, який працює з процесами досить довгий час, повинен мати попередню інформацію про можливе дублювання функцій.

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

Вимірювання і аналіз показників процесу

Вимірювання і аналіз показників процесу є найважливішими засобами, що дозволяють знаходити шляхи поліпшення процесів. Як вже говорилося вище, процес можуть характеризувати кілька груп показників:

• показники процесу;
• показники продукту процесу;
• показники задоволеності клієнтів процесу.

Показники процесу можуть бути визначені як числові величини, що характеризують перебіг самого процесу і витрати на нього (тимчасові, фінансові, ресурсні, людські і т. Д.). Показники можуть бути абсолютними і відносними (приведеними до обсягу послуг, сезонних коливань, тарифним змін і інших зовнішніх факторів, які залежать від управління підприємством, що перевіряється процесом).

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

Показники задоволеності клієнтів процесу - числові величини, що характеризують ступінь задоволеності споживача результатами процесу (виходом, послугою і т. Д.). При цьому слід розрізняти задоволеність споживача (внутрішнього і зовнішнього) виходом процесу і задоволеність кінцевого споживача отриманої продукцією або послугою.

На рис. 13 наводиться найпростіша класифікація показників процесів.

Мал. 13.Класифікація показників процесу

Якісні оцінки процесу, наприклад оцінка керівника «процес погано управляється», ми розглядати не будемо, так як на основі даних показників неможливо приймати обґрунтовані управлінські рішення.

Кількісні показники процесу ми розбили на дві групи: абсолютні і відносні. До абсолютних відносяться показники: часу виконання процесу, технічні показники, показники вартості та якості. Відносні показники можуть розраховуватися на основі абсолютних шляхом формування різних відносин між ними.

Розглянемо більш докладно абсолютні показники виконання процесу.

Показники часу виконання процесу

До першої групи показників відносяться показники часу виконання процесу:

• середній час виконання процесу в цілому;
• середній час простоїв;
• середній час виконання окремих функцій процесу;
• інші.

На першому етапі впровадження процесного підходу повинні розглядатися найпростіші показники, наприклад час виконання процесу в цілому. При більш детальному аналізі можна розглядати такі показники, як час простоїв, час виконання окремих функцій процесу і т. Д. Як вимірювати такі показники? Для цього необхідно розробити і впровадити систему обліку часу виконання окремих функцій процесу. На тих робочих місцях, де це доцільно, слід фіксувати інформацію про момент початку виконання функції і моменті її завершення. Для цього можуть бути використані різні форми реєстрації, наприклад журнали надходження вхідних документів і т. П. Для інших робочих місць можна скористатися нормативними оцінками середнього часу виконання. Найпростіший спосіб такої оцінки наступний.

Розраховується обсяг вироблених функцією продуктів (послуг, оброблених документів). Далі сумарне робочий час ділиться на розраховану кількість продуктів. Отримуємо середній час виконання функції. Складніше йде справа, якщо один виконавець здійснює кілька функцій. В цьому випадку можна використовувати різні вагові коефіцієнти, що визначають структуру розподілу робочого часу виконавця по різних завдань.

Звичайно, розрахунок часових показників процесу, як і інших, не самоціль. Він повинен давати інформацію, що дозволяє приймати рішення щодо покращення процесу. Найпростішим, але дуже важливим прикладом є розрахунок часу обробки заявки клієнта.

Якщо клієнти не задоволені тривалістю цього процесу, то організація, швидше за все, буде їх втрачати.

На рис. 14 показана схема розрахунку показника часу виконання найпростішого лінійного процесу.

Мал. 14.Приклад розрахунку часу процесу

Технічні показники процесу

До технічних слід віднести ті показники, які характеризують технологію виконання процесу, використовуване обладнання, програмне забезпечення, середу і т. Д. Очевидно, що технічні показники будуть різні для процесів підприємств різних галузей. У той же час можна виділити кілька показників, які вимірні для будь-якого процесу:

• кількість функцій процесу, які виконуються на робочих місцях;
• чисельність персоналу процесу, в тому числі керівників і фахівців;
• кількість транзакцій за період;
• кількість автоматизованих робочих місць;
• - інші.

Технічні показники багато в чому відображають ефективність організації та можуть бути використані при проведенні порівняльного аналізу процесу з процесами організацій-конкурентів. Як правило, особливо яскраво виглядає порівняння вітчизняних і зарубіжних підприємств однієї галузі. Наприклад, таке зіставлення за чисельністю персоналу показує, що для виконання аналогічних процесів організації в розвинених країнах використовують в три-п'ять разів менше співробітників, ніж вітчизняні. Слід зазначити, що порівняння технічних показників процесів по абсолютній величині найчастіше не інформативно. Більш цікаві дані для аналізу дає розрахунок відносних показників декількох процесів. Про це буде сказано далі.

Технічні показники служать основою для розрахунку безлічі питомих показників процесу, таких як вироблення на одного співробітника, ступінь автоматизації процесу і т. Д. Потрібно пам'ятати, що важливий не набір показників сам по собі, а можливість прийняття на його основі рішень щодо поліпшення процесу.

Показники вартості процесу

Показники вартості процесу є однією з найважливіших груп показників. Показники вартості можна розділити на кілька груп:

• вартість процесу в цілому;
• показники вартості процесу:
  • витрати на оплату праці виконавців;
  • амортизація обладнання і нематеріальних активів;
  • витрати на тепло- і енергоносії;
  • витрати на зв'язок;
  • витрати на отримання інформації;
  • витрати на підвищення кваліфікації виконавців;
  • інші;
• показники вартості продуктів процесу:
  • вартість сировини і матеріалів;
  • витрати на оплату праці;
  • амортизація обладнання;
  • Інші витрати.

Треба сказати, що коректний розрахунок і аналіз сукупної вартості процесу вимагає застосування відповідних методик. На сьогоднішній день найбільш адекватною з точки зору процесного підходу є методика АВС-аналізу вартості. Вона заснована на:

• визначенні ресурсів, використовуваних в процесах організації;
• визначення операцій процесів;
• визначенні об'єктів віднесення витрат - виходів процесів (продукції, послуг, інформації);
• визначенні та розрахунку показників кількісної зв'язку «ресурси - операції» і «операції - готові вироби»;
• перенесення вартості ресурсів на вартість операцій процесу;
• перенесення вартості операцій на вартість готових виробів.

На основі АВС-методу можна розрахувати вартість процесу. Практичне використання цього методу - технічно складний, тривалий і дорогий проект. Перш ніж його виконувати, кожна організація повинна проаналізувати доцільність застосування АВС-методу. На наш погляд, на першому етапі впровадження процесного підходу в організації застосовувати цей метод недоцільно.

Практично величина вартості процесу в цілому важко піддається визначенню. Однак для поліпшення процесу важливі не абсолютні, а питомі і відносні показники і динаміка їх зміни, що відображає хід поліпшень. На рис. 15 показаний приклад зміни вартісних показників при поліпшенні процесу.

Мал. 15.Зміна вартісних показників при поліпшенні процесу

При аналізі кожного процесу слід визначити обмежений набір вартісних показників, які будуть служити індикаторами його поліпшення / погіршення. Наприклад, до числа таких показників можна віднести:

• фонд заробітної плати (при поліпшенні процесу може відбуватися скорочення персоналу і / або збільшення продуктивності праці);
• витрати на енергоносії (НЕ технологічна енергія, економія енергоресурсів);
• витрати на ремонт і технічне обслуговування (більш якісне і своєчасне обслуговування обладнання призводить до скорочення загальної вартості ремонтів);
• втрати від шлюбу;
• інші.

Як систематизувати завдання підбору вартісних показників процесу? Ми рекомендуємо уважно проаналізувати його складові та витрати, пов'язані з кожної складової. Мал. 16 ілюструє даний підхід.

Мал. 16.Виявлення вартісних показників процесу

Для вимірювання показників повинні бути розроблені відповідні методики, що включають описи робіт зі збору фактичної інформації про витрати на процес, її обробки та використання.

Показники якості процесу

Показники якості є найважливішою групою показників, що характеризують процес. Що слід розуміти під якістю процесу? На наш погляд, це його здатність в заданій ступеня задовольняти потреби своїх клієнтів при мінімальних витратах ресурсів. Звернемо увагу, що ключовим аспектом визначення якості процесу є орієнтація на споживача. Штучно створені, відірвані від потреб клієнта показники якості процесу не можуть служити інструментом для реальних поліпшень.

До показників якості процесу можна віднести наступні:

1. Ступінь дефектності продукції процесу.
2. Кількість повернень і рекламацій на продукцію про процесу.
3. Кількість скарг і рекламацій на якість обслуговування, що надійшли від клієнтів.
4. Кількість некомплектних (які не відповідають специфікаціям) відвантажень.
5. Збереження готової продукції.
6. Кількість позаштатних ситуацій, які зажадали оперативного втручання керівництва верхнього рівня.
7. Здатність процесу швидко адаптуватися до мінливих вимог замовника.
8. Здатність процесу зберігати свої параметри при зміні зовнішніх умов (стабільність процесу, мінімальні варіації).
9. Незалежність процесу від змін в частині персоналу.
10. Керованість процесу.
11. Здатність процесу до поліпшень.

Показники 1-6 досить просто виміряти. Необхідно розробити методики збору і обробки відповідної інформації. Показники 7-10 інтуїтивно зрозумілі, проте їх практичний вимір виконати важко. Можна відстежувати зміну даних показників, аналізуючи збої в роботі процесу, які відбуваються при різних зовнішніх і внутрішніх позаштатних ситуаціях. Виявлення причин таких збоїв допоможе виявити напрямки поліпшення процесу.

Побудова ефективно працюючої системи показників процесу вимагає багато часу і зусиль. Кожне підприємство повинне створювати таку систему з урахуванням специфіки своїх процесів. Слід зазначити, що система показників процесу повинна розвиватися разом з процесом: у міру його поліпшення слід використовувати все більш складні показники.

Розглянемо відносні показники виконання процесу. Ця група розраховується на основі абсолютних показників процесу. З точки зору використання для цілей поліпшення процесу ці показники дуже важливі.

тимчасові

До числа відносних показників часу виконання можна віднести:

• показники «план / факт»:
  • планове час виконання процесу / фактичний час виконання процесу;
  • планове час виконання функції / фактичний час виконання функції;
• • середній час виконання процесу / середній час виконання процесу у конкурента;
  • час обслуговування, необхідну клієнтом / фактичний час обслуговування клієнта;
• питомі:
  • час виконання процесу / чисельність персоналу процесу;
  • час виконання процесу / кількість функцій про процесу.

вартісні

До числа відносних вартісних показників можна від нести:

• показники «план / факт»:
  • планова вартість процесу / фактична вартість процесу;
  • планові витрати на ресурс / фактичні витрати на ресурс;
  • плановане скорочення витрат на процес / фактичне скорочення витрат на процес;
  • планові витрати на ремонт / фактичні витрати на ремонт.
• порівняння з іншим процесом:
  • вартість процесу / вартість процесу конкурента;
  • величина оплати персоналу процесу / величина оплати персоналу процесу конкурента;
• питомі:
  • рентабельність процесу = прибуток по процесу / вартість процесу;
  • рентабельність оборотних активів процесу = прибуток по процесу / обсяг використовуваних оборотних активів;
  • вироблення на одного співробітника = обсяг продукції процесу / чисельність співробітників;
  • фондовіддача процесу = обсяг продукції / величина основних фондів;
  • оборотність оборотних активів процесу = величина виручки / середні залишки оборотних активів процесу;
  • частка накладних витрат = величина накладних витрат / вартість процесу.

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

Технічні

До числа відносних технічних показників можна від нести:

• показники «план / факт»:
  • планова кількість простоїв / фактична кількість простоїв;
  • планова кількість транзакцій / фактична кількість транзакцій;
• порівняння з іншим процесом:
  • чисельність персоналу процесу / чисельність персоналу процесу конкурента;
  • кількість автоматизованих робочих місць процесу / кількість автоматизованих робочих місць процесу конкурента;
• питомі:
  • ступінь завантаження персоналу = загальний час роботи по виконанню функцій процесу / загальне робочий час всіх співробітників;
  • ступінь автоматизації = кількість автоматизованих функцій процесу / загальна кількість функцій процесу;
  • величина офісної площі на одного співробітника;
  • кількість персональних комп'ютерів на одного співробітника.

Показники якості

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

• показники «план / факт»:
  • планова ступінь дефектності / фактична ступінь дефектності;
  • планова кількість скарг / фактична кількість скарг клієнтів процесу;
  • планова кількість повернень продукції / фактична кількість повернень продукції;
  • кількість позаштатних ситуацій за звітний період / кількість позаштатних ситуацій за попередній період;
• порівняння з іншим процесом:
  • ступінь дефектності продукції процесу / ступінь дефектності продукції процесу конкурента;
  • наявність рекламацій процесу / наявність рекламацій процесу конкурента;
• питомі:
  • кількість скарг / загальна кількість клієнтів.

Надіслати свою хорошу роботу в базу знань просто. Використовуйте форму, розташовану нижче

Студенти, аспіранти, молоді вчені, які використовують базу знань в своє навчання і роботи, будуть вам дуже вдячні.

Розміщено на http:// www. allbest. ru/

Вступ

1. Теоретична частина

1.2 Методологія ARIS

2. Практична частина

висновок

Список літератури

Вступ

В умовах ринку все більше число компаній усвідомлюють переваги використання інформаційних систем (ІС). У деяких випадках ІС - це не тільки набір послуг, але і найважливіший компонент бізнесу, як, наприклад, система резервування квитків або засоби надання фінансової інформації. Щоб отримати вигоду від використання інформаційної системи, її слід створювати в короткі терміни і з зменшеними витратами. Інформаційна система повинна бути легко супроводжуваної і керованою.

Створення інформаційної системи підприємства - досить складний і багатоступінчастий процес, який, досить часто, містить фазу інформаційного моделювання. Інформаційна модель - це специфікація структури даних і бізнес правил (правил предметної області).

Моделювання бізнес-процесу - процес відображення суб'єктивного бачення потоку робіт у вигляді формальної моделі, що складається з взаємозв'язаних операцій.

Метою моделювання є систематизація знань про компанію і її бізнес-процесах в наочній графічній формі більш зручною для аналітичної обробки отриманої інформації.

В даний час на ринку комп'ютерних технологій представлено декілька спеціальних програм, що дозволяють обстежувати підприємство і побудувати модель. Вибір методології та інструментів, за допомогою яких проводиться моделювання бізнес-процесів, основоположного значення не має. Існують стандартизовані, випробувані часом методології та інструментальні засоби, за допомогою яких можна обстежити підприємство і побудувати його модель. Ключове їх перевага - простота і доступність до оволодіння.

Основу багатьох сучасних методологій моделювання бізнес-процесів склала методологія SADT. В даний час найбільш широко використовувана методологія опису бізнес-процесів - стандарт США IDEF.

Головне достоїнство ідеї аналізу бізнес-процесів підприємства за допомогою створення його моделі - її універсальність. По-перше, моделювання бізнес-процесів це відповідь практично на всі питання, що стосуються вдосконалення діяльності підприємства і підвищення його конкурентоспроможності. По-друге, керівник або керівництво підприємства, що впровадили у себе конкретну методологію, матиме інформацію, яка дозволить самостійно вдосконалювати своє підприємство і прогнозувати його майбутнє.

Актуальність даного дослідження визначається тим, що сучасні підприємства змушені постійно займатися поліпшенням своєї діяльності. Це вимагає розробки нових технологій і прийомів ведення бізнесу і, звичайно, впровадження нових, більш ефективних методів управління і організації діяльності підприємств.

1. Теоретична частина

1.1 Erwin Process Modeler (BPwin)

ERwin - засіб розробки структури бази даних (БД). ERwin поєднує графічний інтерфейс Windows, інструменти для побудови ER-діаграм, редактори для створення логічного та фізичного опису моделі даних і прозору підтримку провідних реляційних СУБД і настільних баз даних. За допомогою ERwin можна створювати або проводити зворотне проектування (реінжиніринг) баз даних.

Крім цього, Erwin Process Modeler дозволяє створювати, документувати і супроводжувати бази даних, сховища і вітрини даних. Моделі даних допомагають візуалізувати структуру даних, забезпечуючи ефективний процес організації, управління і адміністрування таких аспектів діяльності підприємства, як рівень складності даних, технологій баз даних та середовища розгортання.

Case-засіб ERWinподдержівает методології IDEF1x і IE і призначене для виконання логічних моделей баз даних, які представляють собою суті, описані атрибутами і зв'язку між ними по ключових полях. ERwin дозволяє автоматично згенерувати фізичну модель даних на основі побудованої логічної моделі шляхом перетворення сутностей в таблиці, стовпцями яких є їх атрибути. Кожне поле таблиці має мати чітко визначений тип зберігання даних і розмір поля.

Метод функціонального моделювання (IDEF0)

IDEF0, відноситься до сімейства IDEF, яке з'явилося в кінці шістдесятих років під назвою SADT (Structured Analysis and Design Technique). IDEF0 може бути використана для моделювання широкого класу систем. Для нових систем застосування IDEF0 має на меті визначення вимог і вказівку функцій для подальшої розробки системи, що відповідає поставленим вимогам і реалізує виділені функції. Стосовно до вже існуючих систем IDEF0 може бути використана для аналізу функцій, виконуваних системою і відображення механізмів, за допомогою яких ці функції виконуються. Результатом застосування IDEF0 до деякої системи є модель цієї системи, що складається з ієрархічно упорядкованого набору діаграм, тексту документації та словників, пов'язаних один з одним за допомогою перехресних посилань. Двома найбільш важливими компонентами, з яких будуються діаграми IDEF0, є роботи (представлені на діаграмах у вигляді прямокутників), дані і об'єкти (зображувані у вигляді стрілок), що зв'язують між собою роботи. При цьому стрілки, в залежності від того в яку грань прямокутника роботи вони входять або з якої межі виходять, діляться на п'ять видів:

Ш стрілки входу (входять в ліву грань роботи) - зображують дані або об'єкти, що змінюються в ході виконання роботи;

Ш стрілки управління (входять у верхню грань роботи) - зображують правила і обмеження, згідно з якими виконується робота;

Ш стрілки виходу (виходять з правої межі роботи) - зображують дані або об'єкти, що з'являються в результаті виконання роботи;

Ш стрілки механізму (входять в нижню межу роботи) - зображують ресурси, необхідні для виконання роботи, але не змінюються в процесі роботи (наприклад, обладнання, людські ресурси і т.д.);

Ш стрілки виклику (виходять з нижньої межі роботи) - зображують зв'язку між різними діаграмами або моделями, вказуючи на деяку діаграму, де дана робота розглянута більш докладно.

Всі роботи і стрілки названі. Перша діаграма в ієрархії діаграм IDEF0 завжди зображує функціонування системи в цілому.

Така діаграма називається контекстної. У контекст входить опис мети моделювання області (опису того, що буде розглядатися як компонент системи, а що як зовнішній вплив) і точки зору (позиції, з якої буде будуватися модель). Зазвичай в якості точки зору вибирається точка зору особи або об'єкта, відповідального за роботу системи, що моделюється в цілому.

Метод моделювання бізнес-процесів (IDEF3)

Для опису логіки взаємодії інформаційних потоків підходить методологія IDEF3, звана також workflow diagramming - методологією моделювання, що використовує графічний опис інформаційних потоків, взаємин між процесами обробки інформації та об'єктів, що є частиною цих процесів. Діаграми Workflow можуть бути використані в моделюванні бізнес-процесів для аналізу завершеності процедур обробки інформації. З їх допомогою можна описувати сценарії дій співробітників організації, наприклад послідовність обробки замовлення або події, які необхідно обробити за кінцевий час, кожен сценарій супроводжується описом процесу і може бути використаний для документування кожної функції.

IDEF3 - це метод, який має основною метою дати можливість аналітикам описати ситуацію, коли процеси виконуються в певній послідовності, а також описати об'єкти, які беруть участь спільно в одному процесі.

IDEF3 може бути також використаний як метод створення процесів. IDEF3 доповнює IDEF0 і містить все необхідне для побудови моделей, які в подальшому можуть бути використані для імітаційного аналізу.

IDEF3 є технологією, добре пристосованої для збору даних, необхідних для проведення структурного аналізу системи. Це хороший спосіб опису процесів з використанням структурованого методу, що дозволяє експерту в предметної області уявити стан речей як упорядковану послідовність подій з одночасним описом об'єктів, що мають безпосереднє відношення до процесу.

На відміну від більшості технологій моделювання бізнес-процесів, IDEF3 не має жорстких синтаксичних або семантичних обмежень, які роблять незручним опис неповних або нецілісність систем. Крім того, автор моделі (системний аналітик) позбавлений необхідності змішувати свої власні припущення про функціонування системи з експертними твердженнями з метою заповнення прогалин в описі предметної області.

IDEF3 також може бути використаний як метод проектування бізнес-процесів. IDEF3-моделювання органічно доповнює традиційне моделювання з використанням стандарту методології IDEF0. Деякий час назад, воно набуло великого поширення як цілком життєздатний шлях побудови моделей проектованих систем для подальшого аналізу імітаційними методами. Імітаційне тестування часто використовують для оцінки експлуатаційних якостей системи, що розробляється.

Моделювання потоків даних (DFD)

Data Flow Diagram (діаграма потоків даних) використовується для опису процесів верхнього рівня і для опису реально існуючих в організації потоків даних.

В основі даної методології (Gane / Sarson) лежить побудова моделі аналізованої ІС - проектованої або реально існуючої. Відповідно до методології модель системи визначається як ієрархія діаграм потоків даних DFD, що описують асинхронний процес перетворення інформації від її введення в систему до видачі користувачеві. Діаграми верхніх рівнів ієрархії (контекстні діаграми) визначають основні процеси або підсистеми ІС із зовнішніми входами і виходами. Вони деталізуються за допомогою діаграм нижнього рівня. Така декомпозиція триває, створюючи багаторівневу ієрархію діаграм, до тих пір, поки не буде досягнутий такий рівень декомпозиції, на якому процес стають елементарними і деталізувати їх далі неможливо.

Джерела інформації (зовнішні сутності) породжують інформаційні потоки (потоки даних), які переносять інформацію до підсистем або процесів. Ті в свою чергу перетворюють інформацію і породжують нові потоки, які переносять інформацію до інших процесів або підсистем, накопичувачів даних або зовнішнім сутностей - споживачам інформації. Таким чином, основними компонентами діаграм потоків даних є:

- зовнішні сутності;

- системи / підсистеми;

- процеси;

- накопичувачі даних;

- потоки даних.

роботи. Роботи зображуються прямокутниками з закругленими кутами, сенс їх збігається зі змістом робіт IDEF0 і IDEF3. Так само як роботи IDEF3, вони мають входи і виходи, але не підтримують управління та механізми, як IDEF0. Всі сторони роботи рівнозначні. У кожну роботу може входити і виходити по кілька стрілок.

зовнішні сутності. Зовнішні сутності зображують входи в систему і / або виходи з неї. Одна зовнішня сутність може одночасно надавати входи (функціонуючи як постачальник) та приймати виходи (функціонуючи як одержувач). Зовнішня сутність є матеріальним об'єктом, наприклад замовники, персонал, постачальники, клієнти, склад. Визначення деякого об'єкту або системи в якості зовнішньої суті вказує на те, що вони знаходяться за межами кордонів аналізованої системи. Зовнішні сутності зображуються у вигляді прямокутника з тінню і зазвичай розташовуються по краях діаграми.

стрілки(Потоки даних). Стрілки описують рух об'єктів з однієї частини системи в іншу (це означає, що діаграма DFD не може мати граничних стрілок). Оскільки всі сторони роботи в DFD рівнозначні, стрілки можуть можуть починатися і закінчуватися на будь-якій стороні прямокутника. Стрілки можуть бути двонаправлено.

Сховище даних. На відміну від стрілок, що описують об'єкти в русі, сховища даних зображують об'єкти в спокої. Сховище даних - це абстрактне пристрій для зберігання інформації, яку можна в будь-який момент помістити в накопичувач і через деякий час витягнути, причому способи приміщення і вилучення можуть бути будь-якими. Воно в загальному випадку є прообразом майбутньої бази даних, і опис зберігаються в ньому даних має відповідати інформаційної моделі (Entity-Relationship Diagram).

1.2 Методологія ARIS

Система ARIS є комплексом засобів аналізу і моделювання діяльності підприємства, а також розробки автоматизованих інформаційних систем. В її основу покладена велика методологія, яка ввібрала в себе особливості різних методів моделювання, що відображають різні погляди на досліджувану систему. Одна і та ж модель може розроблятися з використанням декількох методологій, що дозволяє використовувати ARIS користувачам з різними теоретичними знаннями і налаштовувати його на роботу з системами мають свою специфіку.

ARIS являє собою інтегроване середовище аналізу і проектування. Крім основної середовища розробки - ARIS Toolset - вона включає безліч модулів, які є як додатковими компонентами ARIS Toolset, розширюють основну середу, так і самостійними модулями. Така структура ARIS дозволяє говорити про сімейство продуктів даного напрямку, в рамках якого можна скомпонувати оптимальний склад системи, що повністю забезпечує реалізацію конкретних завдань.

Огляд програмних модулів, що входять в сімейство ARIS показує, що розглянута система призначена не тільки і не стільки для моделювання, але являє собою потужний інструментарій аналізу. Однією з відмінних характеристик системи є потужна методологія, підтримувана програмними засобами.

Методологія, яка використовується ARIS, являє собою безліч різних методологій, інтегрованих в рамках системного підходу. Це дозволяє говорити про єдину архітектурі розглянутої методології. ARIS підтримує чотири типи моделей, що відображають різні аспекти досліджуваної системи:

- організаційні моделі, що представляють структуру системи - ієрархію організаційних підрозділів, посад і конкретних осіб, різноманіття зв'язків між ними, а також територіальну прив'язку структурних підрозділів;

- функціональні моделі, що містять ієрархію цілей, що стоять перед апаратом управління, з сукупністю дерев функцій, необхідних для досягнення поставлених цілей;

-інформаційні моделі, що відображають структуру інформації, необхідної для реалізації всієї сукупності функцій системи;

-моделі управління, що представляють комплексний погляд на реалізацію ділових процесів в рамках системи.

Методологія ARIS включає в себе велику кількість різних нотацій, що допускають гнучке створення різних моделей організації. До числа найбільш значущих і практично використовуваних нотацій ARIS відносяться:

- нотація Value-added chain diagram (діаграма ланцюжка процесу, додає вартість);

- нотації extended Event-driven Process Chain - eEPC (розширена нотація ланцюжка процесу, керованого подіями) і PCD (діаграма ланцюжка процесу);

- нотація Organizational chart (організаційна діаграма);

- нотація Function tree (дерево функцій);

- нотація Product tree (дерево продуктів).

VAD (аналог класичного стандарту DFD)

Основним об'єктом нотації VAD є об'єкт «Value added chain».

Ланцюжка доданої вартості (Value added chain diagram, VAD) - діаграма, що описує взаємозв'язок бізнес-процесів верхнього рівня. У ній відображаються два типи зв'язків між процесами:

- зв'язок «попередник-послідовник» - зображуються горизонтальними лініями;

- зв'язок «складається з» - зображуються вертикальними лініями, що відображають деталізацію процесу іншими підпроцесами.

Принципи побудови діаграми процесу верхнього рівня в VAD істотно відрізняються від IDEF0. Істотною відмінністю нотації ARIS VAD і IDEF0 є те, що в VAD стрілки можуть входити в будь-яку сторону об'єкта «Value-added chain». (Нагадаємо, що в IDEF0 кожна сторона об'єкта «Activity» (функція) має певне призначення.)

Зазначений недолік нотації VAD можна обійти, заздалегідь обумовивши можливість спеціального використання зворотних зв'язків.

Закінчуючи огляд нотації ARIS VAD, ще раз акцентуємо увагу на тому, що зазначена нотація більшою мірою носить ілюстративний характер і не призначена для створення комплексних моделей процесів верхнього рівня організації.

2. Практична частина

2.1 Побудова бізнес-моделі підприємства за допомогою середовища ERwin

Метою даної роботи є моделювання діяльності обраного підприємства. Для цього будуть застосовуватися методології:

IDEF0 - методологія функціонального моделювання

IDEF3 - методологія опису процесів

DFD - методологія моделювання потоків даних

VAD - діаграма, що описує взаємозв'язок бізнес-процесів верхнього рівня.

Діаграми в перших трьох методологиях будуть створюватися за допомогою CASE-засобу AllFusion Process Modeler, VAD - за допомогою AllFusion ERwin Data Modeler. база даний моделювання автоматизований

Кожна діаграма в нотації IDEF0, IDEF3, DFD призначена для опису одного або декількох бізнес-процесів. Бізнес-процес - це стійка, цілеспрямована сукупність взаємопов'язаних видів діяльності (послідовність робіт), яка за певною технологією перетворює входи на виходи, що представляють цінність для споживача.

Результатом моделювання бізнес-процесів є модель бізнес-процесів, яка відноситься до одного з трьох типів:

- модель AS-IS (як є) - модель поточної організації бізнес-процесів підприємства

- модель TO-BE (як буде) - модель ідеальної організації бізнес-процесів

- модель SHOULD-BE (як мало б бути) - ідеалізована модель, яка не відображає реальну організацію бізнес-процесів підприємства

Для того, щоб створити базу для виявлення вузьких місць на підприємстві, в даній роботі буде створювати модель AS-IS.

Перед початком побудови діаграм необхідно вивчити обрану предметну область. У цій та наступних роботах в якості предметної області виступатиме вигадане підприємство по будівництву перевізних лазень. Компанія не виробляє будівельні матеріали самостійно, а тільки збирає лазні і займається їх обробкою. Основні процедури в компанії:

продавці приймають замовлення клієнтів;

співробітники групують замовлення за типами бань;

співробітники збирають баню;

співробітники упаковують лазні відповідно до замовлень;

логістичний відділ відвантажує клієнтам замовлення;

постачальники замовляють і доставляють комплектуючі, необхідні для збірки.

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

Побудова моделі будь-якої системи в методології IDEF0 починається з визначення контексту моделювання, який включає в себе суб'єкта моделювання, мета моделювання і точку зору на модель.

Під суб'єктом розуміється сама система, при цьому необхідно точно встановити, що входить в систему, а що лежить за її межами, іншими словами, необхідно визначити, що в подальшому буде розглядати як компоненти системи, а що як зовнішній вплив.

Мета моделювання. Модель не може бути побудована без чітко сформульованої мети. Мета повинна відповідати на питання чому цей процес повинен бути змодельований, що повинна показувати модель і що може отримати читач?

Точка зору. Не дивлячись на те, що при побудові моделі враховуються думки різних людей, модель повинна будуватися з єдиної точки зору. Точку зору можна представити як погляд людини, яка бачить систему в потрібному для моделювання аспекті. Точка зору повинна відповідати меті моделювання. Протягом моделювання важливо залишатися на потрібній точці зору.

У даній роботі суб'єктом буде виступати не саме підприємство, а саме процеси, що відбуваються всередині нього; мета моделювання - відтворити бізнес-процеси, що відбуваються на підприємстві (модель AS-IS); точка зору - з позиції директора як особи, яка знає структуру підприємства в цілому.

Після визначення контексту моделювання можна приступати до побудови контекстної діаграми (її називають іще "чорним ящиком"). Даний тип діаграми дозволяє показати, що подається на вхід роботи і що є результатом роботи, без деталізації її складових. Дана діаграма містить тільки одну роботу, яка буде представляти всю діяльність підприємства в цілому (рис.1).

декомпозиціяIDEF0. Модель предметної області будівельної компанії побудована з використанням методології IDEF0, так як саме IDEF0 є найбільш зручним мовою опису існуючих в системі бізнес-процесів.

Моделювання в IDEF0 починається з побудови контекстної діаграми. Дана діаграма представляє систему у вигляді найпростішої компоненти - одного блоку (мета моделювання предметної області) з інтерфейсними дугами, що відображають зв'язок системи із зовнішніми елементами.

Таким чином, виявлена ​​основна мета моделювання - «Діяльність підприємства з будівництва перевізних лазень». З контекстної діаграми також видно, що вхідний інформацією для даної предметної області є: замовлення клієнтів і будівельні матеріали від постачальників. А вихідною інформацією є: оплата за будівельні матеріали, замовлення постачальникам, маркетингові матеріали, готова продукція. Організовується діяльність підприємства персоналом та бухгалтерією під управлінням законодавства РФ, правил і процедур, необхідних для ведення даного виду діяльності.

Мал. 1 Контекстна діаграма

Для виявлення процесів, що становлять «Діяльність підприємства з будівництва перевізних лазень» проводиться декомпозиція контекстної діаграми (рис. 2).

Мал. 2 Діаграма декомпозиції контексту «Діяльність підприємства з будівництва перевізних лазень»

Оскільки робота "Управління" включає в себе загальне керівництво підприємством, то одним з її результатів буде "Керуюча інформація", що надходить на вхід управління всіх інших робіт.

Робота "Продажі і маркетинг" отримує на вході замовлення клієнтів (тобто кількість бань і їх моделі), інформацію про яких вона передає роботі "Складання лазень" в якості керуючої інформації.

Роботі "Збірка бань" для свого функціонування необхідні будівельні матеріали, які вона замовляє у роботи "Відвантаження та постачання" (вихідна стрілка "Замовлення постачальникам"). Зібрані лазні вона також передає роботі "Відвантаження та постачання" (вихідна стрілка "Готова продукція"). Інформація про результати збирання необхідна роботі "Продажі і маркетинг" (вихідна стрілка "Результати складання").

Результатом роботи "Відвантаження та постачання" будуть необхідні матеріали, які надходять на вхід роботи "Складання лазень".

Управління будь-якого підприємства має знати, що відбувається на підприємстві, чим займається кожен підрозділ і які результати їх роботи, тобто будь-яка робота в ідеалі повинна звітувати про результати своєї діяльності перед управлінням.

На малюнку 3 представлені процеси, що існують в роботі «Збірка Бань».

Мал. 3 Діаграма декомпозиції контексту «Збірка лазень»

Вступники замовлення на збірку упорядковано менеджером, після чого вони надходять на вхід управління робіт "Збірка малогабаритних бань" і "Збірка великогабаритних бань" (стрілка Замовлення на складання). Коли лазні зібрані, менеджер дає вказівку на їх відвантаження.

Зібрані лазні (виходи робіт "Збірка малогабаритних бань" і "Збірка великогабаритних бань") направляються менеджеру, який дає вказівку відвантажити готові лазні.

декомпозиціяIDEF3. При декомпозиції роботи IDEF0 (і DFD) потрібно враховувати, що стрілки на діаграмах IDEF0 або DFD означають потоки інформації або об'єктів, переданих від однієї роботи до іншої. На діаграмах IDEF3 стрілки можуть показувати тільки послідовність виконання робіт, тобто вони мають інший зміст, ніж стрілки IDEF0 або DFD. Тому при декомпозиції роботи IDEF0 або DFD в діаграму IDEF3 стрілки не мігрують на нижній рівень. Якщо необхідно показати на дочірньої діаграмі IDEF3 ті ж об'єкти, що і на батьківських діаграмах IDEF0 або DFD, необхідно використовувати об'єкти посилання.

Проведемо декомпозицію роботи «Збірка великогабаритних лазень» діаграми А3 "Збірка лазень". Дана робота починає виконуватися, коли надходять замовлення на збірку. Першою дією перевіряється наявність необхідних для складання матеріалів і замовлення зі складу відсутніх. Далі матеріали готуються для подальшого складання. Наступним кроком починається безпосередньо сам процес збирання: установка ребер жорсткості конструкції, установка банної печі, утеплення, оббивка та декорування. Дані дії виконуються завжди, незалежно від виду лазні. Далі за бажанням клієнта можуть бути проведені деякі додаткові роботи - шліфування поверхні, конопатка і оздоблення. На цьому складання великогабаритної лазні завершується. Останньою дією складається звіт про виконану роботу.

Мал. 4 Діаграма декомпозиції «Збірка великогабаритних лазень»

Як видно з малюнка 4, описаний алгоритм роботи відображений на діаграмі декомпозиції «Збірка великогабаритних лазень». Складається з 14 дій, а також 4 перехресть.

декомпозиціяDFD. Діаграми потоків даних (Data flow diagram, DFD) використовуються для опису документообігу та обробки інформації. Подібно IDEF0, DFD представляє моделируемую систему як мережу пов'язаних між собою робіт. Їх можна використовувати як доповнення до моделі IDEF0 для більш наочного відображення поточних операцій документообігу в корпоративних системах обробки інформації. Головна мета DFD - показати, як кожна робота перетворює свої вхідні дані у вихідні, а також виявити відносини між цими роботами.

У розглянутому нами прикладі, центральною є робота "Зберігання матеріалів і готових лазень". На її вхід надходять зібрані лазні та отримані від постачальників матеріали, а також список необхідних для складання бань матеріали. Виходом цієї роботи будуть необхідні матеріали (якщо вони є в наявності), список відсутніх матеріалів, що передається на вхід роботи "Постачання необхідними матеріалами" і готові лазні, що передаються на відвантаження. Виходами робіт "Постачання необхідними матеріалами" і "Відвантаження готових лазень" будуть, відповідно, замовлення постачальникам і готова продукція.

Мал. 5 Діаграма декомпозиції «Відвантаження та постачання»

Робота "Постачання необхідними матеріалами" працює з інформацією про постачальників і з інформацією про замовлення, зроблених у цих постачальників. Стрілка, що з'єднує роботу і сховище даних "Список постачальників" двунаправленная, тому що робота може як отримувати інформацію про наявних постачальників, так і вносити дані про нових постачальників. Стрілка, що з'єднує роботу зі сховищем даних "Список замовлень" односпрямована, тому що робота тільки вносить інформацію про зроблені замовленнях.

Робота "Зберігання матеріалів і готових лазень" працює з інформацією про одержуваних і видаються матеріалах і побудованих лазнях, тому стрілки, що з'єднує роботу зі сховищами даних "Список матеріалів" і "Список зібраних бань" двонаправлені. Також ця робота при отриманні матеріалів повинна робити позначку про те, що замовлення постачальникам виконаний. Для цього вона пов'язана зі сховищем даних "Список замовлень" односпрямованої стрілкою.

Нарешті, робота "Відвантаження готових лазень" повинна зберігати інформацію по виконаним відвантаженнях. Для цього вводиться відповідне сховище даних - "Дані по відвантаженню".

висновок

Моделювання бізнес-процесів дозволяє проаналізувати не тільки, як працює підприємство в цілому, як воно взаємодіє із зовнішніми організаціями, замовниками та постачальниками, а й як організована діяльність на кожному окремо взятому робочому місці.

Моделювання бізнес-процесів організації включає два етапи структурний і детальне.

Під методологією (нотацією) створення моделі (опису) бізнес-процесу розуміється сукупність способів, за допомогою яких об'єкти реального світу і зв'язку між ними представляються у вигляді моделі.

Основу багатьох сучасних методологій моделювання бізнес-процесів склала методологія SADT (Structured Analysis and Design Technique - метод структурного аналізу і проектування) та алгоритмічні мови, що застосовуються для розробки програмного забезпечення. За допомогою методології сімейства IDEF можна ефективно представляти і аналізувати моделі діяльності широкого спектру складних систем в різних розрізах. Система ARIS є комплексом засобів аналізу і моделювання діяльності підприємства. Її методичну основу складає сукупність різних методів моделювання, що відображають різні погляди на досліджувану систему.

Необхідно враховувати важливі характеристики моделювання бізнес-процесів. Зокрема, до переваг моделювання бізнес-процесів відносять: підвищення якості та швидкості виробництва продукції з одночасним зниженням витрат; зростання професіоналізму співробітників; підвищення конкурентоспроможності компанії. Недоліки, в свою чергу: посилення експлуатації співробітників і пов'язані з цим проблеми соціально-психологічного характеру; необхідність проведення цілеспрямованої роботи по зміні корпоративної культури.

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

Маючи модель роботи підприємства, усіх його бізнес-процесів, зорієнтованих на конкретну мету, ми можемо відкрити можливість його вдосконалення. Аналіз підприємства як моделі - це зручний спосіб відповіді на питання, що необхідно і достатньо для досягнення конкретної поставленої мети.

Список літератури

1 Еліферов В.Г. Бізнес-процеси: регламентація і управління: навчальний посібник [для студентів вузів] / В. Г. Еліферов, В. В. Рєпін; Ін-т економіки і фінансів "Синергія". - М.: ИНФРА-М, 2011. - 319 с.

2 Андерсен Б. Бізнес-процеси. Інструменти вдосконалення / Б. Андерсен; [Пер. з англ. С. В. Арінічева; під наук. ред. Ю.П. Адлера]. - 5-е изд. - М.: Стандарти та якість, 2008. - 272 с. : Ил. - (Практичний менеджмент).

3 Рєпін В.В. Бізнес-процеси компанії: побудова, аналіз, регламентація / В. В. Рєпін. - М.: Стандарти та якість, 2007. - 240 с. : Ил. - (Ділова досконалість).

4 Реінжиніринг бізнес-процесів: підручник [для студ. екон. вузів магістерського рівня] / Н. М. Абдікеев, Т. П. Данько, С. В. Ільдеменов, А. Д. Кисельов; під ред. Н. М. Абдікеева, Т. П. Данько; Вища. Школа МВА; РЕА ім. Г. В. Плеханова. - 2-е изд., Испр. - М.: Ексмо, 2009. - 592 с. - (Повний курс МВА).

5 Калянов, Г.Н. Моделювання, аналіз, реорганізація та автоматизація бізнес-процесів: вчене посібник для студ. вузів, що навч. по спец. 080801 "Прикладна інформатика" та ін. Екон. спец. / Г. Н. Калянов. - М.: Фінанси і статистика, 2009. - 240с.

6 Калянов Г.Н. Моделювання та автоматизація бізнес-процесів: вчене посібник для студ. вузів, що навч. по спец. 080801 "Прикладна інформатика" та ін. Екон. спец. / Г. Н. Калянов. - М.: Фінанси і статистика, 2008. - 240с.

7 Логістика. Інтеграція і оптимізація логістичних бізнес-процесів в ланцюгах поставок: [підручник для студ. вузів] / В. В. Дибська, Е. І. Зайцев, В. І. Сергєєв, А. Н. Стерлигова; Під ред. В. І. Сергєєва. - М.: Ексмо, 2008. - 944 с. - (Повний курс МВА).

Розміщено на Allbest.ru

...

подібні документи

Створення моделей процесу в BPwin, Aris Express, MS Visio, IBM Rational Rose і відповідно до вимог ГОСТ 19.701-90. Створення даних в Erwin та бази даних в MS Access. Розрахунок економічної ефективності реінжинірингу даного процесу в BPwin.

курсова робота, доданий 12.07.2015


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

курсова робота, доданий 19.06.2015


Створення функціональної структури фірми. Методології проектування інформаційних систем. Склад стандарту IDEF. Засоби структурного системного аналізу. Метод функціонального моделювання SADT. Стратегії декомпозиції. Діаграма потоків даних DFD.

презентація, доданий 27.12.2013


Аналіз етапів і особливостей розробки оптимальної і функціональної ARIS-моделі - програмного продукту компанії IDS Scheer для моделювання бізнес-процесів компанії. Вивчення основних концепцій, методологій і підходів екстремального програмування.

контрольна робота, доданий 04.06.2011


Використання CASE-засобів для моделювання ділових процесів; вдосконалення проектування інформаційних систем за допомогою програмного пакету CA ERwin Modeling Suite: характеристики, можливості візуалізації структури даних і середовища розгортання.

реферат, доданий 20.03.2012


Визначення автоматизованих інформаційних систем. Обгрунтування вибору середовища розробки інформаційної системи. Створення запитів для вибору інформації. Логічна і фізична структура реляційної бази даних. Розробка інтерфейсу користувача.

курсова робота, доданий 16.04.2017


Еволюція технічного забезпечення. Основні вимоги, застосування і характеристики сучасних технічних засобів автоматизованих інформаційних систем. Комплексні технології обробки та зберігання інформації. Створення бази даних обліку і продажу.

курсова робота, доданий 01.12.2010


Методи організації процесу обробки інформації; основні напрямки реалізації внутримашинного інформаційного забезпечення. Принципи побудови і ефективного застосування технологій баз і банків даних як основних компонентів автоматизованих систем.

дипломна робота, доданий 30.05.2013


Створення логічної моделі даних. Призначення кнопок Erwin Toolbox. Створення БД в СУБД InterBase. Використання утиліти WISQL. Створення Script-файлу. Перенесення структури даних з одного сервера на інший. Синхронізація каталогу БД і поточної моделі.

курсова робота, доданий 26.11.2011


Завдання і стадії розробки автоматизованої інформаційної системи художньої школи. Опис предметної області за допомогою бізнес-моделювання, використання діаграм потоків даних DFD. Специфікація системи, логічна структура бази даних.