Курсова робота: Розробка моделі підприємства тепличного господарства, використовуючи методологію проектування IDEF0, DFD та IDEF3. Створення моделі IDEF0 Методологія idef0 на прикладі тестування з

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

Щоб увійти в DEMOпроект використовуйте Ім'я користувача — MANAGER, пароль - MANAGER

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

Після створення нового проекту ви також можете використовувати для входу Ім'я користувача — MANAGER та пароль - MANAGER

Створення моделі

Для створення моделі IDEF0 увімкніть Панель проектута перейдіть до розділу моделювання Essential Domain

Примітка : аналогічно можна створювати моделі у розділі моделювання Implementation Domain, а також у будь-якому розділі, налаштованому користувачем. Розділ моделювання — це власне простір імен, у якого можна повторно використовувати потоки.

Щоб створити контекстну модель IDEF0, клацніть правою кнопкою миші по розділу IDEF0 і виберіть пункти меню Новий->Елемент

Зверніть увагу, що це найменування всієї моделі в цілому, а не багатофункціонального блоку на A0.

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

Створення функціонального блоку

Для цього виберіть символ функціонального блоку на панелі

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

З'явиться діалогове вікно, в якому необхідно ввести назву функціонального блоку, після чого натиснути ОК.

В результаті буде створено функціональний блок із заданим вами ім'ям

Ви можете виділити межу блоку та змінити його масштаб

Створення потоків

Щоб створити потоки, виберіть на панелі символ потоку (без тунелювання або тунелювання)

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

після цього з'явиться діалогове вікно для введення назви потоку. Введіть коротку назву потоку та натисніть OK

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

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

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

Після збереження моделі ви зможете побачити створені специфікації на панелі проекту в тому ж розділі, де ви створювали модель. Будуть створені специфікації двох типів – Function та Flow.

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

у діалозі, що з'явився, залиште налаштування за замовчуванням і натисніть OK

Після чого буде створено дочірню діаграму A1 і на неї перенесено всі потоки з діаграми A0.

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

Щоб перейменувати заготівлю функціонального блоку, виділіть його та в контекстному меню виберіть Перейменувати

та введіть потрібне найменування

За аналогією створіть інші функціональні блоки, що відповідають цьому рівню декомпозиції

Щоб створити потоки між даними функціональними блоками необхідно клацнути спочатку джерело, потім в проміжну точку для створення вигину і потім приймач, наприклад, так:

В результаті ви отримаєте потік із двома вигинами

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

Перегляньте відеофрагмент для того, щоб побачити це в динаміці

Щоб видалити (або додати) точку вигину, натисніть клавішу SHIFT на клавіатурі і клацніть точку, яку необхідно видалити або в те місце потоку, де її потрібно створити

Збережіть діаграму та переконайтеся, що створено відповідні специфікації

За аналогією можна провести декомпозицію функціональних блоків A1.

Відома сьогодні вже не лише у вузьких колах абревіатура 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 практично єдина на сьогодні нотація, яка дозволяє зробити це змістовно та акуратно.

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

Навчіться бачити та розуміти функціональну структурусвого бізнесу!

Нині у Росії різко зріс інтерес до загальноприйнятим у країнах стандартам менеджменту, проте, у реальної практиці управління існує дуже показовий момент. Багатьох керівників досі можна поставити в безвихідь прямим питанням про організаційної структурикомпанії або про схему існуючих бізнес-процесів. Найбільш просунуті і регулярно читають економічну періодику менеджери, зазвичай, починають креслити зрозумілі лише їм одним ієрархічні діаграми, а й у процесі зазвичай швидко заходять у глухий кут. Те саме стосується співробітників та керівників різних служб та функціональних підрозділів. У більшості випадків, єдиним набором викладених правил, відповідно до яких має функціонувати підприємство, є набір окремих положень та посадових інструкцій. Найчастіше ці документи складалися не один рік тому, слабо структуровані і невзаємопов'язані між собою і, внаслідок цього, просто припадають пилом на полицях. До певного часу подібний підхід був виправданий, оскільки під час становлення російської ринкової економіки поняття конкуренції практично не було, та й витрати вважати не було особливої ​​необхідності - прибуток був гігантським. В результаті цього, ми бачимо протягом останніх двох років цілком зрозумілу картину: великі компанії, що виросли на початку 90-х років, поступово здають свої позиції, аж до повного виходу з ринку. Частково це зумовлено тим, що на підприємстві не було впроваджено стандарти управління, повністю не було поняття функціональної моделі діяльності та місії. За допомогою моделювання різних областейдіяльності можна досить ефективно аналізувати "вузькі місця" в управлінні та оптимізувати загальну схему бізнесу. Але, як відомо, на будь-якому підприємстві вищий пріоритет мають лише ті проекти, які безпосередньо приносять прибуток, тому про обстеження діяльності та її реорганізацію зазвичай йде лише під час відчутної кризи в управлінні компанією.

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

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

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

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

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

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

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

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

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

Історія виникнення стандарту IDEF0

Методологію IDEF0 можна вважати наступним етапом розвитку добре відомої графічної мови опису функціональних систем SADT (Structured Analysis and Design Teqnique). Кілька років тому у Росії невеликим тиражем вийшла однойменна книга, присвячена опису основних принципів побудови SADT-діаграм. Історично, IDEF0 як стандарт був розроблений в 1981 році в рамках великої програми автоматизації промислових підприємств, яка мала позначення ICAM (Integrated Computer Aided Manufacturing) і була запропонована департаментом Військово-Повітряних Сил США. Власне, сімейство стандартів IDEF успадкувало своє позначення від назви цієї програми (IDEF=ICAM DEFinition). В процесі практичної реалізації, учасники програми ICAM зіткнулися з необхідністю розробки нових методів аналізу процесів взаємодії у промислових системах. При цьому крім удосконаленого набору функцій для опису бізнес-процесів однією з вимог до нового стандарту була наявність ефективної методології взаємодії в рамках “аналітик-фахівець”. Іншими словами, новий метод повинен був забезпечити групову роботу над створенням моделі, за участю всіх аналітиків і фахівців, зайнятих у рамках проекту.

Внаслідок пошуку відповідних рішень народилася методологія функціонального моделювання IDEF0. З 1981 року стандарт IDEF0 зазнав кілька незначних змін, в основному обмежуючого характеру, і остання його редакція була випущена в грудні 1993 року Національним Інститутом Стандарів і Технологій США (NIST).

Основні елементи та поняття IDEF0

Графічна мова IDEF0 напрочуд проста і гармонійна. В основі методології лежать чотири основні поняття.

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

Кожна із чотирьох сторін функціонального блоку має своє певне значення (роль), при цьому:

Верхня сторона має значення "Керування" (Control);

Ліва сторона має значення "Вхід" (Input);

Права сторона має значення "Вихід" (Output);

Нижня сторона має значення "Механізм" (Mechanism).

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

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

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

Графічним відображенням інтерфейсної дуги є спрямована однонаправлена ​​стрілка. Кожна інтерфейсна дуга повинна мати своє унікальне найменування (Arrow Label). На вимогу стандарту, найменування має бути оборотом іменника.

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

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

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

При побудові IDEF0 – діаграм важливо правильно відокремлювати вхідні інтерфейсні дуги від керівників, що буває непросто. Наприклад, малюнку 2 зображено функціональний блок “Обробити заготівлю”.

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

Рисунок 2.

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

Рисунок 3.

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

Обов'язкове наявність управляючих інтерфейсних дуг одна із головних відмінностей стандарту IDEF0 з інших методологій класів DFD (Data Flow Diagram) і WFD (Work Flow Diagram).

Третім основним поняттям стандарту IDEF0 є декомпозиція (Decomposition). Принцип декомпозиції застосовується під час розбиття. складного процесуна складові його функції. У цьому рівень деталізації процесу визначається безпосередньо розробником моделі.

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

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

У пояснювальному тексті до контекстної діаграми має бути зазначена мета (Purpose) побудови діаграми як короткого описуі зафіксована думка (Viewpoint).

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

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

У процесі декомпозиції, функціональний блок, який у контекстній діаграмі відображає систему як єдине ціле, деталізується на іншій діаграмі. Діаграма другого рівня, що вийшла, містить функціональні блоки, що відображають головні підфункції функціонального блоку контекстної діаграми і називається дочірньою (Child diagram) по відношенню до нього (кожен з функціональних блоків, що належать дочірній діаграмі відповідно називається дочірнім блоком - Child Box). У свою чергу, функціональний блок - предок називається батьківським блоком по відношенню до дочірньої діаграми (Parent Box), а діаграма, до якої він належить – батьківською діаграмою (Parent Diagram). Кожна з підфункцій дочірньої діаграми може бути деталізована далі шляхом аналогічної декомпозиції відповідного їй функціонального блоку. Важливо відзначити, що в кожному випадку декомпозиції функціонального блоку всі інтерфейсні дуги, що входять до цього блоку, або вихідні з нього фіксуються на дочірній діаграмі. Цим досягається структурна цілісність IDEF0 – моделі. Наочно принцип декомпозиції представлений малюнку 4. Слід звернути увагу до взаємозв'язок нумерації функціональних блоків і діаграм - кожен блок має свій унікальний порядковий номер на діаграмі (цифра у нижньому правому куті прямокутника), а позначення під правим кутом вказує на номер дочірньої при цьому блока діаграми . Відсутність цього позначення свідчить, що декомпозиції для цього блоку немає.

Часто бувають випадки, коли окремі інтерфейсні дуги не мають сенсу продовжувати розглядати в дочірніх діаграмах нижче за якийсь певний рівень в ієрархії, або навпаки - окремі дуги не мають практичного сенсу вище за якийсь рівень. Наприклад, інтерфейсну дугу, що зображує "деталь" на вході в функціональний блок "Обробити на токарному верстаті" не має сенсу відбивати на діаграмах більше високих рівнів– це буде лише перевантажувати діаграми та робити їх складними для сприйняття. З іншого боку, трапляється необхідність позбутися окремих "концептуальних" інтерфейсних дуг і не деталізувати їх глибше за певний рівень. Для вирішення подібних завдань у стандарті IDEF0 передбачено поняття тунелювання. Позначення "тунелю" (Arrow Tunnel) у вигляді двох круглих дужок навколо початку інтерфейсної дуги позначає, що ця дуга не була успадкована від функціонального батьківського блоку і з'явилася (з "тунелю") лише на цій діаграмі. У свою чергу, таке ж позначення навколо кінця (стрілки) інтерфейсної дуги в безпосередній близькості від блоку - приймача означає той факт, що в дочірній по відношенню до цього блоку діаграмі ця дуга не відображатиметься і не розглядатиметься. Найчастіше буває, що окремі об'єкти та відповідні їм інтерфейсні дуги не розглядаються на деяких проміжних рівнях ієрархії – у такому разі вони спочатку “занурюються у тунель”, а потім, за необхідності “повертаються з тунелю”.

Останнім із понять IDEF0 є глосарій (Glossary). Для кожного з елементів IDEF0: діаграм, функціональних блоків, інтерфейсних дуг існуючий стандарт має на увазі створення та підтримання набору відповідних визначень, ключових слів, оповідних викладів і т.д., які характеризують об'єкт, відображений цим елементом. Цей набір називається глосарієм та є описом сутності даного елемента. Наприклад, для керуючої інтерфейсної дуги "розпорядження про оплату" глосарій може містити перелік полів відповідного дуги документа, необхідний набір віз і т.д. Глосарій гармонійно доповнює наочну графічну мову, забезпечуючи діаграми необхідною додатковою інформацією.

4. Декомпозиція функціональних блоків.

Принципи обмеження складності IDEF0-діаграм

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

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

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

Дисципліна групової роботи над розробкою IDEF0-моделі

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

Створення моделі групою спеціалістів, що належать до різних сфер діяльності підприємства. Ця група у термінах IDEF0 називається авторами (Authors). Побудова початкової моделі є динамічним процесом, протягом якого автори опитують компетентних осіб про структуру різних процесів. На основі наявних положень, документів та результатів опитувань створюється чернетка (Model Draft) моделі.

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

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

Особливості національної практики застосування функціонального моделювання засобами IDEF0

Останніми роками інтерес у Росії до методологій сімейства IDEF неухильно зростає. Це я постійно спостерігаю, переглядаючи статистику звернень до своєї персональної веб-сторінки (http://www.vernikov.ru), де коротко описані основні принципи цих стандартів. При цьому інтерес до таких стандартів, як IDEF3-5, я б назвав теоретичним, а до IDEF0 цілком практично обґрунтованим. Власне кажучи, перші Case-кошти, що дозволяють будувати DFD і IDEF0 діаграми з'явилися на російському ринку ще в 1996 році, одночасно з виходом популярної книги за принципами моделювання в стандартах SADT.

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

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

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

Що надходить у підрозділ "на вході"?

Які функції і в якій послідовності виконуються в рамках підрозділу?

Хто є відповідальним за виконання кожної функції?

Чим керується виконавець у виконанні кожної з функцій?

Що результат роботи підрозділу (на виході)?

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

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

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

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

Народна мудрість

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

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

Як відомо, функціональні моделі IDEF0 – це завжди графічні схеми. Вони мають свої особливості та правила складання. Про це ми поговоримо трохи згодом. А зараз я хотів би навести кілька прикладів ефективності графіки. Чому я на цьому акцентую? Швидше за все, після мого твердження про необхідність функціональної моделі роботи компанії, багато хто подумав, що це все необов'язково, можна і на словах пояснити як працює та чи інша функція в компанії. Ось про це я хочу поговорити.

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

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

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

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

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

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

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

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

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

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

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

Але для початку, давайте розберемося з основними поняттями, що таке нотації, навіщо вони потрібні, що таке IDEF0, у чому особливості та переваги цього методу

Що таке нотація опису бізнес-процесів

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

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

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

Що таке IDEF0?

IDEF0 – методологія функціонального моделювання (англ. function modeling) та графічна нотація, призначена для формалізації та опису бізнес-процесів. Відмінною особливістю IDEF0 є її акцентом на підпорядкованість об'єктів. У IDEF0 розглядаються логічні відносини між роботами, а не їх тимчасова послідовність (потік робіт). Вікіпедія

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

Функціональна модель компанії

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

Стрілки можуть бути:

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

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

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

IDEF0 – це дуже проста і водночас наочна мова опису бізнес-процесів. За допомогою цього стандарту можлива передача інформації між розробниками, консультантами та користувачами. Стандарт дуже ретельно розроблявся, він зручний проектування, універсальний. Для роботи з ним існує безліч інструментів, наприклад VISIO, BPWIN, ERWIN, Bussines studio і т.д.

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

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

Приклад створення функціональної моделі IDEF0

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

Основний блок - "Написати статтю".

Вхідні стрілки – «Досвід», «Інформація із сторонніх джерел». Це ті вступні, які необхідні для початку роботи.

Керівники для написання статті – це План публікації, Вимоги видавця, Правила російської мови.

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

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

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

У нашому випадку робота поділяється на 4 основні етапи:

1. Підготувати аудіо.
2. Підготувати текст
3. Підготувати текст для публікації.
4. Розмістити статтю у виданні.

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

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

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

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

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

Без такого наочного інструменту було б складніше визначити, які блоки можна видалити і, таким чином, оптимізувати роботу.

Як створювати нотації IDEF0

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

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

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

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

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

Вимоги стандарту IDEF0

Базові вимоги стандарту IDEF0, в принципі, я описав вище та показав на прикладі.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Геннадій Верніков

Нині у Росії різко зріс інтерес до загальноприйнятим у країнах стандартам менеджменту, проте, у реальної практиці управління існує дуже показовий момент. Багатьох керівників досі можна поставити в безвихідь прямим питанням про організаційну структуру компанії або про схему існуючих бізнес-процесів. Найбільш просунуті і регулярно читають економічну періодику менеджери, зазвичай, починають креслити зрозумілі лише їм одним ієрархічні діаграми, а й у процесі зазвичай швидко заходять у глухий кут. Те саме стосується співробітників та керівників різних служб та функціональних підрозділів. У більшості випадків єдиним набором викладених правил, відповідно до яких має функціонувати підприємство, є набір окремих положень та посадових інструкцій. Найчастіше ці документи складалися не один рік тому, слабо структуровані і невзаємопов'язані між собою і, внаслідок цього, просто припадають пилом на полицях. До певного часу подібний підхід був виправданий, оскільки під час становлення російської ринкової економіки поняття конкуренції практично не було, та й витрати вважати не було особливої ​​необхідності - прибуток був гігантським. В результаті цього, ми бачимо протягом останніх двох років цілком зрозумілу картину: великі компанії, що виросли на початку 90-х років, поступово здають свої позиції, аж до повного відходу з ринку. Частково це зумовлено тим, що на підприємстві не було впроваджено стандарти управління, повністю не було поняття функціональної моделі діяльності та місії. За допомогою моделювання різних сфер діяльності можна досить ефективно аналізувати "вузькі місця" в управлінні та оптимізувати загальну схему бізнесу. Але, як відомо, на будь-якому підприємстві вищий пріоритет мають лише ті проекти, які безпосередньо приносять прибуток, тому про обстеження діяльності та її реорганізацію зазвичай йде лише під час відчутної кризи в управлінні компанією.

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

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

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

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

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

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

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

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

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

Історія виникнення стандарту IDEF0

Методологію IDEF0 можна вважати наступним етапом розвитку добре відомої графічної мови опису функціональних систем SADT (Structured Analysis and Design Teqnique). Кілька років тому у Росії невеликим тиражем вийшла однойменна книга, присвячена опису основних принципів побудови SADT-діаграм. Історично, IDEF0, як стандарт був розроблений в 1981 році в рамках великої програми автоматизації промислових підприємств, яка мала позначення ICAM (Integrated Computer Aided Manufacturing) і була запропонована департаментом Військово-Повітряних Сил США. Власне, сімейство стандартів IDEF успадкувало своє позначення від назви цієї програми (IDEF=ICAM DEFinition). У процесі практичної реалізації учасники програми ICAM зіткнулися з необхідністю розробки нових методів аналізу процесів взаємодії у промислових системах. При цьому крім удосконаленого набору функцій для опису бізнес-процесів однією з вимог до нового стандарту була наявність ефективної методології взаємодії в рамках "аналітик-спеціаліст". Іншими словами, новий метод повинен був забезпечити групову роботу над створенням моделі, за участю всіх аналітиків і фахівців, зайнятих у рамках проекту.

Внаслідок пошуку відповідних рішень народилася методологія функціонального моделювання IDEF0. З 1981 року стандарт IDEF0 зазнав кілька незначних змін, в основному обмежуючого характеру, і остання його редакція була випущена в грудні 1993 року Національним Інститутом Стандарів і Технологій США (NIST).

Основні елементи та поняття IDEF0

Графічна мова IDEF0 напрочуд проста і гармонійна. В основі методології лежать чотири основні поняття.

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

Кожна із чотирьох сторін функціонального блоку має своє певне значення (роль), при цьому:

Верхня сторона має значення "Керування" (Control);

Ліва сторона має значення "Вхід" (Input);

Права сторона має значення "Вихід" (Output);

Нижня сторона має значення "Механізм" (Mechanism).

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

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

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

Графічним відображенням інтерфейсної дуги є спрямована однонаправлена ​​стрілка. Кожна інтерфейсна дуга повинна мати своє унікальне найменування (Arrow Label). На вимогу стандарту, найменування має бути оборотом іменника.

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

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

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

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

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

Рисунок 2.

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

Рисунок 3.

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

Обов'язкове наявність управляючих інтерфейсних дуг одна із головних відмінностей стандарту IDEF0 з інших методологій класів DFD (Data Flow Diagram) і WFD (Work Flow Diagram).

Третім основним поняттям стандарту IDEF0 є декомпозиція (Decomposition). Принцип декомпозиції застосовується при розбитті складного процесу складові його функції. У цьому рівень деталізації процесу визначається безпосередньо розробником моделі.

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

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

У пояснювальному тексті до контекстної діаграми має бути зазначена мета (Purpose) побудови діаграми як короткого описи і зафіксована точка зору (Viewpoint).

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

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

У процесі декомпозиції, функціональний блок, який у контекстній діаграмі відображає систему як єдине ціле, деталізується на іншій діаграмі. Діаграма другого рівня, що вийшла, містить функціональні блоки, що відображають головні підфункції функціонального блоку контекстної діаграми і називається дочірньою (Child diagram) по відношенню до нього (кожен з функціональних блоків, що належать дочірній діаграмі відповідно називається дочірнім блоком - Child Box). У свою чергу, функціональний блок – предок називається батьківським блоком по відношенню до дочірньої діаграми (Parent Box), а діаграма, до якої він належить – батьківської діаграми (Parent Diagram). Кожна з підфункцій дочірньої діаграми може бути деталізована далі шляхом аналогічної декомпозиції відповідного їй функціонального блоку. Важливо відзначити, що в кожному випадку декомпозиції функціонального блоку всі інтерфейсні дуги, що входять до цього блоку, або вихідні з нього фіксуються на дочірній діаграмі. Цим досягається структурна цілісність IDEF0 – моделі. Наочно принцип декомпозиції представлений малюнку 4. Слід звернути увагу до взаємозв'язок нумерації функціональних блоків і діаграм - кожен блок має свій унікальний порядковий номер на діаграмі (цифра у нижньому правому куті прямокутника), а позначення під правим кутом вказує на номер дочірньої при цьому блока діаграми . Відсутність цього позначення свідчить, що декомпозиції для цього блоку немає.

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

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

4. Декомпозиція функціональних блоків.

Принципи обмеження складності IDEF0-діаграм

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

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

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

Дисципліна групової роботи над розробкою IDEF0-моделі

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

Створення моделі групою спеціалістів, що належать до різних сфер діяльності підприємства. Ця група у термінах IDEF0 називається авторами (Authors). Побудова початкової моделі є динамічним процесом, протягом якого автори опитують компетентних осіб про структуру різних процесів. На основі наявних положень, документів та результатів опитувань створюється чернетка (Model Draft) моделі.

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

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

Особливості національної практики застосування функціонального моделювання засобами IDEF0

Останніми роками інтерес у Росії до методологій сімейства IDEF неухильно зростає. Це я постійно спостерігаю, переглядаючи статистику звернень до своєї персональної веб-сторінки (http://www.vernikov.ru), де коротко описані основні принципи цих стандартів. При цьому інтерес до таких стандартів, як IDEF3-5, я б назвав теоретичним, а до IDEF0 цілком практично обґрунтованим. Власне кажучи, перші Case-кошти, що дозволяють будувати DFD і IDEF0 діаграми з'явилися на російському ринку ще в 1996 році, одночасно з виходом популярної книги за принципами моделювання в стандартах SADT.

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

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

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

Що надходить у підрозділ "на вході"?

Які функції і в якій послідовності виконуються в рамках підрозділу?

Хто є відповідальним за виконання кожної функції?

Чим керується виконавець у виконанні кожної з функцій?

Що результат роботи підрозділу (на виході)?

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

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

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