Чому я не люблю нотацію IDEF0 - Блог розробників

"Чому я не люблю нотацію IDEF0"

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

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

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

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

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

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

чому

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

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

Отже, я спробував побудувати спрощену схему роботи свого підприємства у MS Visio, ось що в мене вийшло:

блог

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

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

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

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

"Чому я не люблю нотацію IDEF0"