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://consulting.psi.ru), де коротко описані основні принципи цих стандартів. При цьому інтерес до таких стандартів, як IDEF3-5, я б назвав теоретичним, а до IDEF0 цілком практично обґрунтованим. Власне кажучи, перші Case-кошти, що дозволяють будувати DFD і IDEF0 діаграми з'явилися на російському ринку ще в 1996 році, одночасно з виходом популярної книги за принципами моделювання в стандартах SADT.

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

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

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

Що надходить у підрозділ "на вході"?
Які функції і в якій послідовності виконуються в рамках підрозділу?
Хто є відповідальним за виконання кожної функції?
Чим керується виконавець у виконанні кожної з функцій?
Що результат роботи підрозділу (на виході)?

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

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

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

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

1. Визначення ділових процесів як IDEF0-модели

1.1. Визначення ділового процесу.

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

Примітки:

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

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

2 Загальною метою моделей у рамках цього документа є створення системи менеджменту якості, що відповідає вимогам СТБ ISO 9000-2001, СТБ ISO 9001-2001 та СТБ ISO 9004-2001.

Для того, щоб виявити ділові процеси, необхідно визначити таке:

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

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

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

Фабрика є закритим акціонерним товариством. Мета побудови моделі – створення системи менеджменту якості. На підставі цієї інформації в діяльності швейної фабрики можна виділити один діловий процес-«Виробляти жіночі пальта». Входами цього процесу є: а) зовнішня інформація, включаючи вимоги споживачів (магазинів та компаній); б) сировину та матеріали; в) ресурси. Виходами процесу є: а) партії готової продукції, що призначені для споживачів; б) інформація зовнішніх споживачів. Управління процесом складає підставі нормативних документів, що регламентують виробничі процеси на фабриці. Враховуючи, що нас цікавить процес з погляду менеджменту якості, то як зовнішнього управліннярозглядатимемо нормативні документи, що регламентують цю сферу, у тому числі вимоги СТБ ISO 9000. Карта ділового процесу на швейній фабриці представлена на рис. 3.

Рис. 3 Діловий процес на швейній фабриці

1.2. Опис структури ділового процесу

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

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

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

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

Розглянемо декомпозицію ділового процесу "Виробляти жіночі пальта" (рис.3).

З огляду на мету моделювання - відповідність ділового процесу вимогам СТБ ІСО 9001 - 2001 декомпозиція ділового процесу включає 4 блоки процесів, представлених на рис. 4.

Відповідно до вимог СТБ ІСО 9000 діловий процес «Виробляти жіночі пальта» включає такі процеси:

– реалізувати відповідальність найвищого керівництва з менеджменту якості;

- Здійснювати менеджмент ресурсів;

– реалізувати процеси життєвого циклу;

– здійснювати вимірювання, аналіз та поліпшення СУЯ.

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

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

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

керування;
вихід – вхід;
зворотний зв'язок з управління;
зворотний зв'язок із входу;
вихід – механізм.

Таблиця 1

	Взаємозв'язок з управління: вихід одного процесу впливає виконання іншого процесу, тобто. вихідна дуга блоку 1 є керуючою для блоку 2. У СТБ ІСО 9001 така взаємодія визначає функцію управління «відповідальність керівництва» по відношенню до інших процесів
	Взаємозв'язок по входу: вихід одного процесу є входом іншого, тобто. вихідна дуга блоку 1 є вхідний для блоку 2. Ця взаємодія характерна для будь-яких процесів в організації, наприклад, для процесів життєвого циклу
	Зворотній зв'язок з управління: виходи з одного процесу впливають виконання інших процесів, виконання яких у свою чергу впливає виконання вихідного процесу. Вихідна дуга блоку 1 є керуючої блоку 2, а вихідна дуга блоку 2 є керуючої для блоку 1. У СТБ ІСО 9001 така взаємодія може визначати: - функцію управління "відповідальність керівництва"; – функцію управління «управління процесами життєвого циклу»; – функцію управління «вимірювання, аналіз та покращення»
	Зворотний зв'язок по входу: вихід із процесу є входом іншого процесу, вихід якого є йому входом, тобто. вихідна дуга блоку 2 є вхідний блоку 1, вихід якого є для нього входом. У СТБ ІСО 9001-2001 така взаємодія може визначати функцію управління «управління процесами життєвого циклу»
	Взаємозв'язок «вихід - механізм»: вихід одного процесу є механізмом іншого, тобто. вихідна дуга блоку 1 є дугою механізму блоку 2. Такий тип зв'язку відноситься найчастіше до процесів забезпечення ресурсами. У СТБ ІСО 9001 така взаємодія може визначати функцію управління "менеджмент ресурсів"

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

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

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

Розглянемо взаємодії між процесами, що становлять діловий процес «Виробляти жіночі пальта» (рис. 5).

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

Процес «Здійснювати менеджмент ресурсів» має зв'язок «вихід - механізм» з процесами «Реалізувати процеси життєвого циклу» та «Здійснювати вимірювання, аналіз та покращення СУЯ».

На діаграмі представлений контур зворотного зв'язку: вихід процесу «Здійснювати вимірювання, аналіз та покращення СМЯ» з входом процесу «Реалізувати відповідальність вищого керівництва з менеджменту якості»

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

Рис.5 – Взаємодія між процесами

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

На діаграмі А0 (рис.5) діловий процес "Виробляти жіночі пальта" представлений у вигляді 4 процесів. Діаграма А0 є першим рівнем декомпозиції (деталізації) цього процесу. Кожен із чотирьох представлених процесів у свою чергу може бути декомпозований. На рис. 6 представлена декомпозиція процесу "Реалізувати процеси життєвого циклу".

На діаграмі А3 (рис. 6) процес «Реалізувати процеси життєвого циклу» представлений у вигляді шести процесів, включаючи «Здійснювати закупівлі», який також може бути декомпозований (рис. 7).

Рис. 6.- Декомпозиція процесу «Реалізувати процеси життєвого циклу»

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

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

Наприклад, для діаграми А34 (рис. 7) фрагмент глосарію виглядатиме так.

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

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

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

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

Класифікація входів та виходів робіт

Стандарт пропонує наступну типізацію входів робіт:

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

Основні елементи діаграми:

Основу графічної мови IDEF0, синтаксис і семантика якого визначені з абсолютною строгістю, складають блоки і стрілки, що з'єднують їх, які формують ієрархію деталізованих діаграм.

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

IDEF0 - модель:

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

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

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

Принцип декомпозиції при побудові моделі бізнес-процесів

1. Контекстна діаграма: мета та думка

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

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

2. Деталізація

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

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

Для досягнення структурної цілісності моделі використовуються такі правила:

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

Принцип тунелювання

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

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

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

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

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

Кількісний аналіз діаграм: коефіцієнт збалансованості та оцінка імен

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

кількість блоків на діаграмі N;
рівень декомпозиції діаграми L;
збалансованість діаграми В;
число стрілок, що з'єднуються з блоком, - А.

Коефіцієнт збалансованості

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

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

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

Введемо коефіцієнт збалансованості діаграми:

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

Оцінка імен

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

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

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

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

L*C

— твір рівня моделі на кількість збігів імен блоків зі словами зі словника. Чим нижчий рівень моделі (більше L), тим цінніші збіги.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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