Стандарти моделювання бізнес-процесів 1. Головні цілі моделювання бізнес-процесів 2. Перелік популярних стандартів моделювання 3. Стандарт IDEF3 4. Стандарт. - презентация

1 Стандарти моделювання бізнес-процесів 1. Головні цілі моделювання бізнес-процесів 2. Перелік популярних стандартів моделювання 3. Стандарт IDEF3 4. Стандарт IDEF0 (коротко) 5. Принципи проектування інформаційних систем 6. Життєвий цикл розробки інформаційної системи 1

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

3 Головні цілі моделювання бізнес-процесів Розробку бізнес моделей починають із створення структури підприємства із зазначенням центрів відповідальності. Важливими складовими для сучасного управління бізнес процесами є узгодження трьох повязаних між собою аспектів: адміністративного; фінансового; матеріального (товарного). Використання сучасних технологій додає іще два аспекти: інформаційний; комунікаційний. 3 1

4 Головні цілі моделювання бізнес-процесів Найбільш суттєвими для бізнесу є питання організації трьох процесів фінансової взаємодії: фінансового планування (бюджетування); фінансування (виконання бюджетів); фінансової звітності. 4 1

5 Головні цілі моделювання бізнес-процесів Звичайно, що взаємодія різних процесів у компанії відбувається із застосуванням паперообігу – документообігу. Як правило найбільш якісно формалізовано документообіг фінансової частини – цьому сприяють і контролюючі органи (податкова, статистика, банк…). Адміністративна та матеріальна складова опрацьована тільки у частині взаємодії із фінансовою складовою. 5 1

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

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

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

9 Перелік популярних стандартів моделювання При намаганні формалізувати взаємодію між бізнес-процесами без застосування стандартів моделювання, візуальних засобів та Case-засобів у більшості випадків виникає густий туман. Суттєво може допомогти добре розроблене сімейство методологій IDEF, яке є державним стандартом США. 9 2

10 Перелік популярних стандартів моделювання Сімейство IDEF складається із методології функціонального моделювання IDEF0 і методології інформаційного моделювання IDEF1X. IDEF - методології створювалися в рамках запропонованої у США програми компютеризації промисловості - ICAM, в ході реалізації якої виявилася потреба у розробці методів аналізу процесів взаємодії у виробничих (промислових) системах. Принциповою вимогою під час розробки сімейства методологій була можливість ефективного обміну інформацією між УСІМА спеціалістами - учасниками програми ICAM (звідси назва: Icam DEFinition - IDEF). 10 2

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

12 До стандарту IDEF належать такі стандарти ІDEF1 – методологія моделювання інформаційних потоків всередині системи, яка дає можливість відображати і аналізувати їх структуру та взаємозвязки. Ця методологія дозволяє відповісти на питання Як повинно бути – вона вирішує такі задачі: Зясовує структуру и склад існуючих потоків інформації Визначає які проблеми, виявлені у результаті аналізу, повязані із недоліками управління відповідною інформацією. Виявляє інформаційні потоки, які потребують додаткового управління для ефективної реалізації моделі. 12 2

13 Перелік популярних стандартів моделювання IDEF1X (IDEF1 Extended) – методологія побудови реляційних структур. IDEF1X належить до типу методологій Сутність-звязок. (ER – Entity-Relationship) Як правило, використовується для моделювання реляційних баз даних, які мають відношення до системи, що досліджується. - повний текст стандарту англійською мовою - опис стандарту російською мовою 13 2

14 Перелік популярних стандартів моделювання IDEF2 – методологія динамічного моделювання розвитку систем. У звязку із значною складністю аналізу динамічних систем від цього стандарту практично відмовились, і його розвиток призупинено на початковому етапі. Проте сьогодні існують алгоритми і їх компютерні реалізації, які дають можливість перетворювати розроблені статичні діаграми IDEF0 у динамічні моделі, побудовані на основі розфарбованих мереж Петрі (CPN – Color Petri Nets). 14 2

15 До стандарту IDEF належать такі стандарти IDEF3 – методологія документування процесів, які відбуваються у системі, наприклад, при дослідженні технологічних процесів на підприємствах. З використанням IDEF3 виконується опис сценарію і послідовності операцій для кожного процесу. IDEF3 має прямий звязок із методологією IDEF0 – кожна функція (функціональний блок) може бути представлений у вигляді окремого процесу засобами IDEF стандарт англійською - огляд стандарту російською 15 2

16 До стандарту IDEF належать такі стандарти IDEF4 – методологія побудови обєктно-орієнтованих систем. Засоби IDEF4 дозволяють наочно відображати структуру обєктів і закладені принципи їх взаємодії, тим самим надаючи можливість аналізувати і оптимізувати складні обєктно-орієнтовані системи. - стандарт англійською - огляд стандарту (також англійською) 16 2

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

18 Поняття онтології (інформація із Вікіпедії) Онтоло́гия (новолат. ontologia от др.-греч. ν род. п. ντος сущее, то, что существует и λόγος учение, наука) раздел философии, изучающий бытие.новолат.др.-греч. философиибытие Типы онтологий Мета-онтологии описывают наиболее общие понятия, которые не зависят от предметных областей.Мета-онтологии Онтология предметной области формальное описание предметной области, обычно применяется для того, чтобы уточнить понятия определённые в мета-онтологии (если используется) и/или определить общую терминологическую базу предметной области.Онтология предметной области Онтология конкретной задачи онтология, определяющая общую терминологическую базу задачи, проблемы.Онтология конкретной задачи Сетевые онтологии часто используют для описания конечных результатов действий, выполняемых объектами предметной области или задачи.Сетевые онтологии - вікіпедія RU - вікіпедія UA 18 2

19 Стандарт IDEF3 IDEF3 - технологія збору даних, які потрібні для проведення структурного аналізу системи. Із застосуванням цієї технології є можливість уточнити картину процесу, привертаючи увагу аналітика до послідовності виконання функцій і бізнес-процесів в цілому. Логіка цієї технології дає можливість будувати і аналізувати альтернативні сценарії розвитку бізнес-процесів (тобто моделі типу Що буде якщо"?); 19 3

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

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

22 Стандарт IDEF3 Опис процесу у методології IDEF3 22 3

23 Синтаксис і семантика моделей IDEF3 - моделі Основою моделі IDEF3 є так званий сценарій бізнес-процесу, який надає послідовність дій або підпроцесів системи, яка вивчається. Оскільки сценарій визначає призначення і межі моделі, досить важливим є підбір найменування для позначення дій. Наприклад: "Опрацювати замовлення клієнта" або Перевірити баланс на рахунку" цілком можливі назви сценаріїв. 23 3

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

25 Синтаксис і семантика моделей IDEF3 - діаграми Головною організаційною одиницею моделі IDEF3 є діаграма. Взаємна організація діаграм всередині моделі IDEF3 є важливим у випадку, коли модель створюється з метою публікації або рецензування, що є звичайною практикою при проектуванні нових систем. У цьому випадку системний аналітик повинен подбати про таке інформаційне наповнення діаграм, щоб кожна з них була самодостатньою і у той же час зрозумілою читачу. 25 3

26 Синтаксис і семантика моделей IDEF3 – одиниця роботи, дія Дія, або в термінах IDEF3 одиниця роботи" (Unit of Work UOW) наступний важливий компонент моделі. Діаграми IDEF3 показують дію у вигляді прямокутника. Дії надаються імена і привласнюється унікальний ідентифікаційний номер. Цей номер не використовується знову навіть у тому випадку, якщо у процесі побудови моделі дія видаляється. У діаграмах IDEF3 перед номером дії зазвичай ставиться номер батьківської дії. 26 3

27 Синтаксис і семантика моделей IDEF3 – звязки Звязки показують суттєві взаємовідношення між діями. Усі звязки у IDEF3 є односпрямованими, і, зазвичай діаграми IDEF3 організуються зліва направо таким чином, що стрілки починаються на правому і закінчуються на лівому боці блоків. 27 3

28 Синтаксис і семантика моделей IDEF3 – типи звязків 28 3 Зображення НазваПризначення Часове передування (temporal precedence) Поточна дія повинна завершитися раніше, ніж кінцева дія зможе розпочатися Обєктний потік (Object flow) Вихід поточної дії є входом кінцевої дії. Тобто поточна дія повинна завершитися раніше, ніж кінцева дія зможе розпочатися. Нечітке відношення (Relationship) Вид взаємодії між поточною і кінцевою діями задається аналітиком окремо для кожного випадку використання такого відношення

29 Синтаксис і семантика моделей IDEF3 – звязок часове передування Як видно з назви, звязки цього типу показують, що поточна дія повинна повністю завершитися, перед тим як розпочнеться виконання кінцевої дії. 29 3

30 Синтаксис і семантика моделей IDEF3 – звязок Обєктний потік Найбільш часто зустрічається причина використання звязку типу "обєктний потік" коли деякий обєкт, який є результатом виконання поточної дії, потрібен для виконання кінцевої дії. 30 3

31 Синтаксис і семантика моделей IDEF3 – звязок Нечітке відношення Звязки цього типу використовують для показу відношень між діями, коли їх не можна описати з використанням попередніх або обєктних звязків. Приклад: запуск бензопили із водяним охолодженням: 31 3

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

33 Синтаксис і семантика моделей IDEF3 – Типи зєднань 33 3 Графічне позначення НазваВидПравила ініціації &Зєднання І Розгортаюче Кожна кінцева дія обовязково ініціюється Згортаюче Кожна поточна дія обовязково повинна завершитися XЗєднання Ексклюз ивне АБО Розгортаюче Одна і тільки одна кінцева дія ініціюється Згортаюче Одна і тільки одна поточна дія повинна завершитися OЗєднання АБО Розгортаюче Одна (або більше) кінцевих дій ініціюється Згортаюче Одна (або більше) поточних дій повинно завершитися

34 Синтаксис і семантика моделей IDEF3 – І зєднання Зєднання цього типу ініціюють виконання усіх своїх кінцевих дій. Усі дії, які приєднані до згортаючого І"-зєднання, повинні завершитися, до того як почне виконуватися наступна дія. 34 3

35 Синтаксис і семантика моделей IDEF3 – ексклюзивне АБО зєднання Незалежно від кількості дій, які приєднані до згортаючого або розгортаючого зєднання «Ексклюзивне АБО", буде ініційована тільки одна з них, і тому тільки одна з них буде завершена перед тим, як будь-яка дія, що слідує за згортаючим зєднанням «Ексклюзивне АБО", зможе розпочатися. 35 3

36 Синтаксис і семантика моделей IDEF3 – зєднання АБО Зєднання «АБО". Зєднання цього типу призначені для опису ситуацій, які не можуть бути описані двома попередніми типами зєднань. На рисунку перевірка чека ініціюється, якщо покупець бажає розрахуватися чеком, перевірка суми готівки при оплаті готівкою. И перша і друга дії можуть ініціюватися у випадку часткової оплати чеком та готівкою. 36 3

37 Синтаксис і семантика моделей IDEF3 – синхронні зєднання Інколи час початку або кінця паралельно виконуваних дій повинні бути однаковими, тобто дії повинні виконуватися синхронно Графічне позначення ТипВид Правила ініціювання І Розгортаюче Усі дії почнуться одночасно Згортаюче Усі дії завершаться одночасно АБО Розгортаюче Може бути декілька дій – почнуться одночасно Згортаюче Може бути декілька дій – завершаться одночасно Ексклюзив не АБО Розгортаюче Одночасний початок дій неможливий Згортаюче Одночасний завершення дій неможливе

38 Синтаксис і семантика моделей IDEF3 – синхронні зєднання - приклад 38 3

39 Синтаксис і семантика моделей IDEF3 – комбінація двох типів зєднань Зєднання J2 інтерпретується так: після включення пожежної сигналізації і (або) виклику пожежних і (або) початку гасіння виконується запис в журнал. 39 3

40 Синтаксис і семантика моделей IDEF3 – комбінація зєднань Зєднання можуть бути комбінованими. Такі зєднання слід застосовувати обережно – перевантажені розгалуженнями діаграми можуть бути складними для сприйняття. 40 3

41 Синтаксис і семантика моделей IDEF3 – покажчики (pointers) Покажчики це спеціальні символи, які посилаються на інші розділи опису процесу. Вони виносяться на діаграму для привернення уваги читача до деяких важливих аспектів моделі. Покажчик зображується на діаграмі у вигляді прямокутника, схожого на зображення дії. Імя покажчика зазвичай вміщує його тип (наприклад, ОБЄКТ, РОБІТНИК та ін.) і ідентифікатор. 41 3

42 Синтаксис і семантика моделей IDEF3 – покажчики (pointers) - приклад Показано приклад зображення важливого з точки зору моделі відношення між дією і обєктом: 42 3

43 Синтаксис і семантика моделей IDEF3 – декомпозиція дій Для показу дій у IDEF3 можна застосувати декомпозицію, тобто дії розбити на складові, для більш детального аналізу. Декомпозицію дій можна застосувати декілька раз. Це дозволяє документувати альтернативні потоки процесу у одній моделі. Для коректної ідентифікації дій у моделі із множинними декомпозиціями схема нумерації дій розширюється і разом із номерами дії і його предка вміщує в собі порядковий номер декомпозиції. Наприклад, у номері дії 1.3.7: 1 номер батьківської дії, 3 номер декомпозиції, 7 номер дії. 43 3

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

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

46 Стандарт IDEF0 Кожна з чотирьох сторін функціонального блоку має своє певне значення (роль), при цьому: верхня сторона має значення "Управління" (Control); ліва сторона має значення "Вхід" (Input); права сторона має значення "Вихід" (Output); нижня сторона має значення "Механізм" (Mechanism). 46 4

47 Стандарт IDEF0 На рівні функціонального блоку звязок IDEFx- моделей базується на трьох принципах: функція характеризується числом, що являє собою вартість або час виконання цієї функції; вартість або час функції, що не має декомпозиції, визначається розроблювачем моделі; вартість або час функції, що має декомпозицію, визначається як сумарна вартість (загальна тривалість) усіх підфункцій на даному рівні декомпозиції. 47 4

48 Модель технологічного процесу за методологією IDEFx 48 4

49 Стандарт IDEF0 У загальному випадку моделювання технології роботи будь-якого підприємства мається на меті розвязати наступне коло задач: формалізувати технології виконання бізнес- процесів і роботи кожного структурного підрозділу й посадової особи підприємства; виділити основні, допоміжні та керуючі бізнес- процеси і функції підрозділів та посадових осіб підприємства; провести порівняльний аналіз й оцінювання ефективності виконання бізнес-процесів, технологій роботи структурних підрозділів і посадових осіб; 49 4

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

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

52 Стандарт IDEF

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

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

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

56 Принципи проектування інформаційних систем Історично склалося так, що деякі системи розроблялися по методу "від низу до верху": спочатку створювалися окремі автоматизовані робочі місця (АРМи), потім робилися спроби об'єднання їх в єдину інформаційну систему. Подібні розробки для великих систем (до яких часто належать КІС) не можуть бути успішними

57 Принципи проектування інформаційних систем При створенні проекту інформаційної системи для проектування її бази даних слід визначити: об'єкти інформаційної системи (суть в концептуальній моделі); властивості обєктів (атрибути); взаємодію об'єктів (зв'язки) і інформаційні потоки усередині і між ними

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

59 Схема формування інформаційної системи 59 5 Концептуальні вимоги користувачів Нормативні документи Сучасна практика представлення інформаціїі Аналіз прототипів (аналогів) Концептуальна модель Фізична модель (схема бази даних) Внутрішня модель (база даних) Зовнішня модель (апаратно-програмний комплекс)

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

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

62 Життєвий цикл розробки інформаційної системи Створення інформаційної системи проводиться у декілька етапів, на кожному з яких конкретизуються і уточнюються елементи системи, що розробляється. Існують різні типи схем, що ілюструють життєвий цикл розробки ІС. На рисунку показано каскадну схему із зворотним зв'язком. 62 6

63 Каскадна схема життєвого циклу інформаційної системи 63 6

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

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