Побудова idef0 діаграми онлайн. Методологія IDEF0

Одна картинка коштує тисячі слів

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

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

Декілька слів про переваги графіки

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

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

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

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

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

Чому це важливо для моєї роботи

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

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

Типові помилки

Використання різних кольорів

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

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

Занадто велика кількість блоків

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

Порушення структури при внесенні коригувань

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

Правила назви керуючих елементів та блоків

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

Вигоди використання IDEF0

• Найперша вигода очевидна – це наочність.Ви самі починаєте розуміти, як працює та чи інша система, і можете наочно пояснити, де в цій системі «тонкі місця» і як ваші рішення допоможуть позбутися їх.
• Взаєморозуміння та відсутність різночитань.При обговоренні роботи компанії з використанням функціональної моделі у вас є наочні та зрозумілі інтуїтивно блоки завдань із керуючими елементами. Крім того, функціональне моделювання передбачає створення у разі потреби глосарію, в якому розкриваються умовні позначеннята терміни. В результаті ви з клієнтом, керівником, іншими співробітниками під час обговорення проблеми розмовляєте однією мовою.
• Простота та висока швидкість створення моделі.Звичайно, навчитися моделювання не так просто, як здається. Адже схема - це, по суті, надщільне подання інформації, що дуже добре для розуміння, але для реалізації такої подачі потрібен особливий підхід. Мозок аналітика виступає в даному випадкуяк дуже потужний прес з одного боку, і фільтр з іншого. Але з досвідом цей процес стає дуже швидким. В результаті ви отримуєте інструмент, який допоможе і самому розібратися, що відбувається в тій чи іншій системі, і за допомогою створеного в стислі терміни наочного посібникапроілюструвати важливі моментиколегам чи замовникам.
• Дисципліна та відсутність помилок.Стандарт IDEF0 передбачає строгі рамкита правила. Такий підхід дисциплінує, а звичка діяти в рамках стандарту допомагає уникнути помилок через неуважність. Будь-які порушення стандарту стають відразу помітними.

У чому складність застосування IDEF0

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

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

Ще статті на цю тему.

Побудова моделі IDEF0

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

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

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

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

Мета моделювання

Мета моделювання визначається з відповідей на такі питання:

• Чому цей процес має бути змодельований?
• Що має показувати модель?
• Що може отримати клієнт?

Погляд (Viewpoint).

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

IDEF0-модель передбачає наявність чітко сформульованої мети, єдиного суб'єкта моделювання та однієї точки зору. Для внесення області, мети та погляду в моделі IDEF0 в BPwin слід вибрати пункт меню Model/Model Properties, що викликає діалог Model Properties (рис. П2.3). В закладці Purpose слід внести мету та точку зору, а в закладку Definition - визначення моделі та опис області.

Рис. П2.3.Діалог завдання властивостей моделі

В закладці Status того ж діалогу можна описати статус моделі (чорновий варіант, робочий, остаточний тощо), час створення та останнього редагування (відстежується надалі автоматично за системною датою). У закладці Source описуються джерела інформації для побудови моделі (наприклад, "Опитування експертів предметної галузі та аналіз документації"). Закладка General служить для внесення імені проекту та моделі, імені та ініціалів автора та тимчасових рамок моделі – AS-IS та ТО-ВЕ.

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

Технологія проектування ІВ має на увазі спочатку створення моделі AS-IS, її аналіз та поліпшення бізнес-процесів, тобто створення моделі ТО-ВЕ, і тільки на основі моделі ТО-ВЕ будується модель даних, прототип і потім остаточний варіант ІВ.

Іноді поточна AS-IS та майбутня ТО-ВЕ моделі різняться дуже сильно, так що перехід від початкового до кінцевого стану стає неочевидним. У цьому випадку необхідна третя модель, що описує процес переходу від початкового до кінцевого стану системи, оскільки такий перехід – це також бізнес-процес.

Результат опису моделі можна отримати у звіті Model Report. Діалог налаштування звіту за моделлю викликається з пункту меню Tools/Reports/Model Report.

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

Рис. П2.4.Діалогове вікно для формування звіту за моделлю

На рис. П2.5 представлений звіт, сформований за вищевказаними полями.

Рис. П2.5.Попередній перегляд звіту

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

Модель може містити чотири типи діаграм:

• контекстну діаграму (у кожній моделі може бути лише одна контекстна діаграма);
• діаграми декомпозиції;
• діаграми дерева вузлів;
• діаграми лише для експозиції (FEO).

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

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

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

Роботи (Activity)позначають пойменовані процеси, функції або завдання, які відбуваються протягом певного часу і мають результати, що розпізнаються. Роботи зображуються як прямокутників. Усі роботи мають бути названі та визначені. Ім'я роботи має бути виражене віддієслівним іменником, що позначає дію (наприклад, "Діяльність компанії", "Прийом замовлення" і т.д.). Робота "Діяльність компанії" може мати, наприклад, наступне визначення: "Це навчальна модель, що описує діяльність компанії". Під час створення нової моделі (меню File/New) автоматично створюється контекстна діаграма з єдиною роботою, що зображує систему загалом (рис. П2.6).

Рис. П2.6.Приклад контекстної діаграми

Для внесення імені роботи слід клацнути по роботі правою кнопкою миші, вибрати в меню Name Editor і в діалозі внести ім'я роботи. Для опису інших властивостей роботи є діалог Activity Properties (рис. П2.7).

Рис. П2.П2.Редактор завдання властивостей роботи

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

Виникає діалог Activity Box Count (рис. П2.8), у якому слід зазначити нотацію нової діаграми та кількість робіт на ній. Зупинимося поки що на нотації IDEF0 і натисніть на ОК. З'являється діаграма декомпозиції (рис. 2.9). Допустимий інтервал числа робіт - 2-8. Декомпозувати роботу на одну роботу не має сенсу: діаграми з кількістю робіт більше восьми виходять перенасиченими та погано читаються. Для забезпечення наочності та кращого розуміннямоделюються процесів рекомендується використовувати від трьох до шести блоків на одній діаграмі.

Рис. П2.8.Діалог Activity Box Count

Рис. П2.9.Приклад діаграми декомпозиції

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

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

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

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

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

У IDEF0 розрізняють п'ять типів стрілок:

Вхід(Input) - матеріал або інформація, які використовуються або перетворюються на роботу для отримання результату (виходу). Допускається, що робота може мати жодної стрілки входу. Кожен тип стрілок підходить до певної сторони прямокутника, що зображує роботу, або виходить із неї. Стрілка входу малюється як входить у ліву грань роботи. При описі технологічних процесів(Для цього і був придуманий IDEF0) не виникає проблем визначення входів. Дійсно, "Дзвінки клієнтів" на рис. П2.6 - це щось, що переробляється в процесі діяльності компанії для отримання результату. При моделюванні ІС, коли стрілками є не фізичні об'єкти, А дані не все так очевидно. Наприклад, при "Прийомі пацієнта" карта пацієнта може бути і на вході і на виході, тим часом якість цих даних змінюється. Іншими словами, у нашому прикладі для того, щоб виправдати своє призначення, стрілки входу та виходу повинні бути точно визначені для того, щоб вказати на те, що дані дійсно були перероблені (наприклад, на виході - "Заповнена карта пацієнта"). Дуже часто складно визначити, чи є дані входом чи керуванням. У цьому випадку підказкою може бути інформація про те, чи переробляються/змінюються дані в роботі чи ні. Якщо змінюються, то, швидше за все, це вхід, якщо ні – керування.

Управління(Control) - правила, стратегії, процедури чи стандарти, якими керується робота. Кожна робота повинна мати хоча б одну стрілку керування. Стрілка управління малюється як входить у верхню грань роботи. На рис. П2.6 стрілка "Правила та процедури" - управління для роботи "Діяльність компанії". Управління впливає роботу, але з перетворюється роботою. Якщо мета роботи – змінити процедуру чи стратегію, то така процедура чи стратегія буде для роботи входом. У разі виникнення невизначеності у статусі стрілки (управління чи вхід) рекомендується малювати стрілку управління.

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

Механізм(Механізм) - ресурси, які виконують роботу, наприклад персонал підприємства, верстати, пристрої тощо. буд. Стрілка механізму малюється як входить у нижню грань роботи. На рис. П2.6 стрілка "Бухгалтерська система" є механізмом для роботи "Діяльність компанії". На розсуд аналітика стрілки механізму можуть не зображуватися в моделі.

Виклик(Call) - Спеціальна стрілка, що вказує на іншу модель роботи. Стрілка виклику малюється як вихідна з нижньої граніроботи. На рис. П2.10 стрілка "Інша модель роботи" є викликом для роботи "Виготовлення виробу". Стрілка виклику використовується для вказівки того, що деяка робота виконується за межами системи, що моделюється. У BPwin стрілки виклику використовуються в механізмі злиття та поділу моделей.

Рис. П2.10.Стрілка виклику, що з'являється під час розщеплення моделі

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

Для внесення граничної стрілки входу слід:

Стрілки управління, входу, механізму та виходу зображуються аналогічно. Імена нововнесених стрілок (рис. П2.11) автоматично заносяться до словника Arrow Dictionary.

Рис. П2.11.Діалог IDEF0 Arrow Properties

ICOM-коди. Діаграма декомпозиції варта деталізації роботи. На відміну від моделей, що відображають структуру організації, робота на діаграмі верхнього рівня IDEF0 - це не елемент управління нижчестоящими роботами. Роботи нижнього рівня - це те саме, що роботи верхнього рівня, але в більш детальному викладі. Як наслідок цього межі роботи верхнього рівня - це те саме, що межі діаграми декомпозиції. ICOM (абревіатура від Input, Control, Output та Mechanism) – коди, призначені для ідентифікації граничних стрілок. Код ICOM містить префікс, що відповідає типу стрілки (I, С, Про або М), та порядковий номер.

BPwin вносить ICOM-коди автоматично. Для відображення ICOM-кодів слід увімкнути опцію ICOM codes на закладці Display діалогу Model Properties (Меню Model/Model Properties) (рис.П2.12).

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

Рис. П2.12.Увімкнення опції ICOM codes на закладці Display

Рис. П2.13.Редагування словника стрілок

Вміст словника стрілок можна роздрукувати як звіт (меню Tools/ Report /Arrow Report...) і отримати тлумачний словниктермінів предметної області, які у моделі.

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

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

Рис. П2.14.Приклад незв'язаних стрілок

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

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

Зв'язок по входу(output-input), коли стрілка виходу вищої роботи (далі - просто вихід) прямує на вхід нижчестоящої (наприклад, на рис. П2.15 стрілка "Зібрані комп'ютери"пов'язує роботи та "Відвантаження та отримання").

Рис. П2.15.Зв'язок по входу

Зв'язок з управління(output-control), коли вихід вищої роботи направляється управління нижчестоящей. Зв'язок управління показує домінування вищої роботи. Дані або об'єкти виходу вищестоящої роботи не змінюються нижче. На рис. П2.16 стрілка "Замовлення клієнтів"пов'язує роботи "Продажі та маркетинг"і "Складання та тестування комп'ютерів".

Рис. П2.16.Зв'язок з управління

Зворотній зв'язокпо входу(output-input feedback), коли вихід нижчестоящої роботи прямує на вхід вищестоящої. Такий зв'язок зазвичай використовується для опису циклів. На рис. П2.17 стрілка "Результати тестування" пов'язує роботи "Тестування комп'ютерів"і "Відстеження розкладу та управління складанням та тестуванням".

Рис. П2.1П2.Зворотній зв'язок по входу

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

Рис. П2.18.Зворотній зв'язок з управління

Зв'язок вихід-механізм(output-mechanism), коли вихід однієї роботи прямує на механізм іншої. Цей взаємозв'язок використовується рідше інших і показує, що одна робота готує ресурси, необхідних проведення іншої роботи (рис. П2.19).

Рис. П2.19.Зв'язок вихід-механізм

Явністрілки. Явна стрілка має джерелом одну-єдину роботу та призначенням теж одну-єдину роботу.

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

Сенс стрілок, що розгалужуються і зливаються, передається ім'ям кожної гілки стрілок. Існують певні правилаіменування таких стрілок. Розглянемо їх на прикладі стрілок, що розгалужуються. Якщо стрілка іменована до розгалуження, а після розгалуження жодна з гілок не іменована, то мається на увазі, що кожна гілка моделює ті ж дані або об'єкти, що й галузь до розгалуження (мал. П2.20).

Рис. П2.20.

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

Рис. П2.21.Приклад іменування стрілки, що розгалужується.

Неприпустима ситуація, коли стрілка до розгалуження не іменована, а після розгалуження не іменована якась із гілок. BPwin визначає таку стрілку як синтаксичну помилку.

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

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

Рис. П2.22.Нерозв'язана (unresolved) стрілка

Для їх "перетягування" нагору потрібно клацнути правою кнопкою миші квадратними дужками граничної стрілки і в контекстному меню вибрати команду Arrow Tunnel (рис. П2.23).

Рис. П2.23.Вибір команди з контекстного меню

З'являється діалог Border Arrow Editor (мал. 2.24).

Якщо натиснути кнопку Resolve Border Arrow, стрілка мігрує на діаграму верхнього рівня, якщо по кнопці Change To Tunnel - стрілка буде тунельована і не потрапить на іншу діаграму. Тунельна стрілка зображується із круглими дужками на кінці (рис. П2.25).

Рис. П2.24.Діалог Border Arrow

Рис. П2.25.Типи тунелювання стрілок

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

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

Нумерація робіт та діаграм. Усі роботи моделі нумеруються. Номер складається з префікса та числа. Може бути використаний префікс будь-якої довжини, але зазвичай використовують префікс А. Контекстна робота дерева має номер А0. Роботи i декомпозиції А0 мають номери А1, А2, A3 тощо. ієрархію, де кожна робота може мати одну батьківську та кілька дочірніх робіт, утворюючи дерево. Таке дерево називають деревом вузлів, а вищеописану нумерацію – нумерацією по вузлах. Діаграми IDEF0 мають подвійну нумерацію. По-перше, діаграми мають номери за вузлом. Контекстна діаграма має номер А-0, декомпозиція контекстної діаграми - номер А0, інші діаграми декомпозиції - номери за відповідним вузлом (наприклад, A1, A2, А21, А213 тощо. буд.). BPwin автоматично підтримує нумерацію по вузлах, т. е. під час проведення декомпозиції створюється нова діаграма і автоматично присвоюється відповідний номер. В результаті проведення експертизи діаграми можуть уточнюватись та змінюватися, отже, можуть бути створені різні версіїоднієї і тієї ж (з точки зору її розташування у дереві вузлів) діаграми декомпозиції. BPwin дозволяє мати в моделі лише одну діаграму декомпозиції у цьому вузлі. Попередні версії діаграми можна зберігати як паперової копії чи як FEO-диаграмму. (На жаль, при створенні FEO-діаграм відсутня можливість відкату, тобто з діаграми можна отримати декомпозиції FEO, але не навпаки.) У будь-якому випадку слід відрізняти різні версії однієї і тієї ж діаграми. Для цього існує спеціальний номер – C-number, який має присвоюватися автором моделі вручну. C-number - це довільний рядок, але рекомендується дотримуватися стандарту, коли номер складається з буквеного префікса та порядкового номера, причому як префікс використовуються ініціали автора діаграми, а порядковий номер відстежується автором вручну, наприклад, МСВ00021.

IDEF0-моделі складаються з трьох типів документів: графічних діаграм, тексту та глосарію. Ці документи мають перехресні посилання один на одного.

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

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

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

Кожна модель повинна мати контекстну діаграму верхнього рівня, де об'єкт моделювання представлений єдиним блоком з граничними стрілками. Ця діаграма називається A-0 (А мінус нуль). Стрілки на цій діаграмі відображають зв'язки об'єкта моделювання з довкіллям. Оскільки єдиний блок представляє весь об'єкт, його загальне ім'я для всього проекту. Це справедливо і всім стрілок діаграми, оскільки вони представляють повний комплект зовнішніх інтерфейсів об'єкта. Діаграма A–0 встановлює область моделювання та її межу. Приклад діаграми A-0 показано на рис. 3.10., Мал. 3.11., Мал. 3.12.

Рис. 3.10. Приклад контекстної діаграми

Рис. 3.11. Приклад контекстної діаграми

Рис. 3.12. Приклад контекстної діаграми

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

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

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

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

Одна картинка коштує тисячі слів

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

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

Декілька слів про переваги графіки

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

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

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

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

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

Чому це важливо для моєї роботи

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

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

Типові помилки

Використання різних кольорів

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

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

Занадто велика кількість блоків

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

Порушення структури при внесенні коригувань

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

Правила назви керуючих елементів та блоків

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

Вигоди використання IDEF0

• Найперша вигода очевидна – це наочність.Ви самі починаєте розуміти, як працює та чи інша система, і можете наочно пояснити, де в цій системі «тонкі місця» і як ваші рішення допоможуть позбутися їх.
• Взаєморозуміння та відсутність різночитань.При обговоренні роботи компанії з використанням функціональної моделі у вас є наочні та зрозумілі інтуїтивно блоки завдань із керуючими елементами. Крім того, функціональне моделювання передбачає створення у разі потреби глосарію, в якому розкриваються умовні позначення та терміни. В результаті ви з клієнтом, керівником, іншими співробітниками під час обговорення проблеми розмовляєте однією мовою.
• Простота та висока швидкість створення моделі.Звичайно, навчитися моделювання не так просто, як здається. Адже схема - це, по суті, надщільне подання інформації, що дуже добре для розуміння, але для реалізації такої подачі потрібен особливий підхід. Мозок аналітика виступає у разі як дуже потужний прес з одного боку, і фільтр – з іншого. Але з досвідом цей процес стає дуже швидким. В результаті ви отримуєте інструмент, який допоможе і самому розібратися, що відбувається в тій чи іншій системі, і за допомогою створеного в стислі терміни наочної допомоги проілюструвати важливі моменти колегам або замовникам.
• Дисципліна та відсутність помилок.Стандарт IDEF0 передбачає строгі рамки та правила. Такий підхід дисциплінує, а звичка діяти в рамках стандарту допомагає уникнути помилок через неуважність. Будь-які порушення стандарту стають відразу помітними.

У чому складність застосування IDEF0

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

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

Ще статті на цю тему.

Відома сьогодні вже не лише у вузьких колах абревіатура IDEF0 є першою методологією, яка стандартизує роботу над бізнес-процесами. Вона була розроблена в середині минулого століття в рамках аерокосмічного проекту в США і, показавши свою ефективність, стала федеральним стандартом. У нашій країні 2000 року підготовлено документ « Методологія функціонального моделювання IDEF0. Керівний документ Методологія функціонального моделювання IDEF0 Керівний документ. Видання офіційне. Держстандарт Росії РД IDEF0 - 2000. Розроблено Науково-дослідним Центром CALS - технологій "Прикладна Логістика". Прийнято та введено в дію Постановою Держстандарту Росії 2000 р. Москва», але як стандарт він так і не був затверджений. Хоча це не завадило даній методології стати в нашій країні одним із найпопулярніших інструментів графічного моделювання бізнес-процесів. У цій статті я пропоную вам розглянути модель IDEF0 та оцінити актуальність цього підходу.

Основні поняття та скорочення

Розберемося трохи із назвами ключових елементівметодології. Графічний стандарт IDEF0 є частиною методології SADT (Structured Analysis and Design Technique – метод структурного аналізута проектування). IDEF – це скорочення від ICAM Definition, а ICAM утворено від Integrated Computer Aided Manufacturing, що перекладається як інтегрована комп'ютеризація виробництва. Методологія SADT – це ціла родина з 15 різних моделей, які у комплексі мали дозволити дослідити структуру, параметри та характеристики виробничо-технічних та організаційно-економічних систем.

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

Нотація IDEF0 – це досить строга методика, яка спочатку була розроблена, як і стандарти технічного конструюваннядля ручного моделювання. Тому там містяться вимоги щодо розміщення стрілок, формату всіх елементів, змісту інформаційної рамки до IDEF0 діаграми та ін. Оскільки діяльність компанії – це складна багаторівнева система дій, то схем виходить завжди багато, і потрібна однозначна систематизація та навігація по всіх елементах моделі. Зараз це роблять здебільшого комп'ютерні системи, що підтримують моделювання у цій нотації. На території Росії найбільш відомими та доступними на сьогодні є системи AllFusion Process Modeler та Business Studio. Огляду цих систем планую присвятити окремі статті.

Функціональний блок

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

Обов'язкові елементи функціонального блоку IDEF0

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

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

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

Для побудови функціональної моделі методологія IDEF0 вимагає дотримуватися таких правил.

1. Входи – це ресурси, які переносять свою вартість у виходи повністю, тобто витрачаються створення результату повністю, а механізми – це ресурси, які переносять свою вартість лише частково (обладнання – через амортизацію, а люди – через зарплатню).
2. Управління – це необхідний елемент моделі, оскільки він прив'язує всі дії до системи регламентів компанії, чітко позначаючи, які правила та вимоги мають бути дотримані у процесі виконання функції. Часто до цього потоку ставляться формально, але при цьому схема втрачає строгість, інколи ж навіть сенс.
3. Кожен функціональний блок повинен мати як мінімум одну стрілку з кожної сторони (оскільки не може бути роботи без ресурсів або результатів, а також неповною буде інструкція без виконавця або інструкції).

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

Контекстна діаграма

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

1. Мета – конкретне формулювання призначення моделі, за якою можна звіряти в надалі точністьпобудови моделі.
2. Позиція – від чиєї особи будується модель, оскільки модель залежна завжди від її автора та фокусу уваги. Якщо ми будуємо загальну модель підприємства, зазвичай вона представляється з погляду його директора.
3. Тип моделі – це вказівка ​​те що, яка інформація відображена на схемах. Тут може бути 2 важливі варіанти: AS IS («як є») або TO BE («як буде»). Такий поділ необхідний, оскільки ми можемо будувати моделі як аналізу діяльності, так її трансформації. Ми повинні чітко усвідомлювати, що ми робимо, а також доносити цю інформацію до оточуючих.

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

Основні потоки

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

1. Матеріальний: матеріали та комплектуючі на вході та готова продукціяна виході.
2. Клієнтський: потенційний клієнт на вході та задоволений на виході.
3. Фінансовий: на вході це зазвичай інвестиції, платежі клієнтів (виторг), кредити та інші доходи; на виході - це платежі постачальникам, податки, платежі за кредитами та прибуток.
4. Інформаційний: на вході це всі потоки інформації про зовнішньому середовищі(Стан ринку, поведінка конкурентів, технологічні інновації та ін.), а на виході - це потік інформації, яку компанія повідомляє про себе світу (вся рекламна інформація, а також всі види звітності перед контролюючими органами).

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

(натисніть для збільшення)

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

Стрілки управління можуть бути представлені лише 1 видом потоку - інформаційним, який можна розбити на 2 підвиди. Перший – це документи, такі як:

• закони та норми;
• накази, розпорядження;
• інструкції та регламенти;
• плани;
• конструкторська документація та ін.

Другий – це недокументована інформація, до якої найчастіше належать вимоги власників.

І, нарешті, механізми – тут лише 2 види потоків: обладнання (матеріальний) та виконавці (підрозділи та люди). Тут не може бути документів, як і не може бути людей на стрілках керування!

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

Декомпозиція

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

(натисніть для збільшення)

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

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

1. Створення продукту (результату).
2. Просування та продаж – робота з клієнтським потоком.
3. Забезпечення діяльності щодо створення продукту – вторинні процеси, які необхідні для дотримання державних вимог чи зручності роботи (кадровий та бухгалтерський облік, транспортне обслуговування, прибирання приміщень та інше).
4. Створення потоків управління – діяльність з розробки управлінських рішень, які визначатимуть вимоги всім процесам компанії.

На малюнку нижче представлено діаграму декомпозиції нашого прикладу.

(натисніть для збільшення)

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

Подальша робота над моделлю аналогічна першому кроці – проводиться декомпозиція кожного функціонального блоку першого рівня. Нумерація блоків міститиме номер першого рівня: А1.1 … А1.n, A2.1 … A2.n тощо.

Висновки про актуальність нотації

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

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

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

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

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

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