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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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