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

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

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

Мета роботи:

• вивчення основних принципів методології IDEF0,
• створення нового проекту в BPWin,
• формування контекстної діаграми,
• проведення зв'язків.

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

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

Кожна IDEF0-діаграма містить блоки та дуги. Блоки зображують функції системи, що моделюється. Дуги зв'язують блоки разом і відображають взаємодії та взаємозв'язки між ними.

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

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

Кожна сторона блоку має особливе, цілком певне призначення. Ліва сторона блоку призначена для входів, верхня – для керування, права – для виходів, нижня – для механізмів. Таке позначення відбиває певні системні принципи: входи перетворюються на виходи управління обмежує чи приписує умови виконання перетворень, механізми показують, як і виконує функція.

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

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

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

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

Типи стрілок

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

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

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

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

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

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

Мал. 2.1Типи стрілок

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

Мал. 2.2.Зв'язок по виходу

Мал. 2.3. Зв'язок з управління

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

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

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

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

Мал. 2.4.Зворотній зв'язок по входу

Мал. 2.5.Зворотній зв'язок з управління

Зв'язки «вихід-механізм» притаманні розподілу джерел ресурсів (наприклад, необхідні інструменти, навчений персонал, фізичний простір, обладнання, фінансування, матеріали).

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

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

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

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

Мал. 2.6.Зв'язок вихід-механізм

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

Кількісний аналіз діаграм

Для проведення кількісного аналізу діаграм перерахуємо показники моделі:

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

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

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

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

Мал. 2.7.Приклад незбалансованої діаграми

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

Необхідно прагнути, щоб Кьбув мінімальним для діаграми.

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

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

Інструментарій BPWin

При запуску BPWin за промовчанням з'являється основна панель інструментів, панель інструментів та Model Explorer.

При створенні нової моделі виникає діалог, в якому слід зазначити, чи буде створено модель заново, чи вона буде відкрита з репозитарію ModelMart, внести ім'я моделі та вибрати методологію, в якій буде побудовано модель (рис. 2.8).

Рис.2.8Діалог створення моделі

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

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

приклад

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

Після вивчення вихідних документів та опитування замовників та користувачів системи необхідно сформулювати мету моделювання та визначити точку зору на модель. Розглянемо технологію її побудови на прикладі системи "Служба зайнятості в рамках ВНЗ", основні можливості якої були описані у лабораторній роботі №1.

Сформулюємо мету моделювання: описати функціонування системи, яке було б зрозуміле її користувачу, не вдаючись у подробиці, пов'язані з реалізацією. Модель будуватимемо з погляду користувачів (студент, викладач, адміністратор, деканат, фірма).

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

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

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

Отже, визначимо контекстну діаграму системи (рис. 2.9).

Рис. 2.9.Контекстна діаграма системи

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

• Визначення рівня доступу до системи.
• Вибір підсистеми.
• Звернення до підсистеми.
• Зміна БД (за потреби).

Отримаємо діаграму, зображену на рис. 2.10.

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

Мал. 2.10.Декомпозиція роботи "Обслуговування, клієнта системи"

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

Мал. 2.11.Декомпозиція роботи «Визначення рівня доступу до системи»

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

Декомпозуємо роботу «Обробка запиту клієнта», що виконується підсистемою обробки запитів, визначення категорій та повноважень користувачів. Перед пошуком відповіді на запит необхідно відкрити БД (підключитися до неї). У загальному випадку БД може перебувати на віддаленому сервері, тому може знадобитися встановлення з'єднання з нею. Визначимо послідовність робіт:

• Відкриття БД.
• Виконання запиту.
• генерація звітів.

Після відкриття БД необхідно повідомити систему встановлення з'єднання з БД, після чого виконати запит і згенерувати звіти для користувача (рис. 2.12).

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

Мал. 2.12.

Коригування діаграми

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

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

Зміна діаграми потягне за собою коригування всіх батьківських діаграм (рис. 2.13 – 2.15).

Декомпозицію роботи «Виконання запиту» доцільно провести з допомогою діаграми DFD (лабораторна робота № 3), оскільки методологія IDEF0 розглядає систему як сукупність взаємозалежних робіт, що негативно відбиває процеси обробки інформації.

Мал. 2.13.Декомпозиція роботи "Обробка запиту клієнта"

Мал. 2.14.Декомпозиція роботи «Обслуговування клієнта системи» (варіант 2)

Мал. 2.15.Контекстна діаграма системи (варіант 2)

Перейдемо до декомпозиції останнього блоку «Зміна БД». З погляду клієнта, ці системи розташовуються в одній БД. Реально в системі присутні шість БД:

• БД користувачів,
• БД студентів, (варіант 2)
• БД вакансій
• БД успішності,
• БД тестів,
• БД експертних оцінок,
• БД резюме.

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

• Визначається БД, у якій змінюватиметься інформація.
• Оператором формується тимчасовий набір даних та надається адміністратору.
• Адміністратор здійснює контроль даних та вносить їх до БД.

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

Мал. 2.16.Декомпозиція роботи «Зміна БД»

Мал. 2.17.Декомпозиція роботи "Зміна БД" (варіант 2) Для першого варіанту, зображеного нарис. 2.12

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

Декомпозицію роботи «Виконання запиту» буде проведено у наступній лабораторній роботі, ілюструючи застосування діаграм DFD для опису процесів обробки інформації.

Проведемо кількісний аналіз моделей, зображених на рис. 2.12 та 2.13, згідно з вищеописаною методикою. Розглянемо поведінку коефіцієнта у цих моделей. У батьківської діаграми «Обробка запиту клієнта» коефіцієнт дорівнює 4/2 = 2, а діаграми декомпозиції 3/3 = 1. Значення коефіцієнта зменшується, що свідчить про спрощення описи функцій зі зниженням рівня моделі.

Розглянемо зміну коефіцієнта До bу двох варіантів моделей.

для другого варіанта

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

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

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

Контрольні питання

перелік Контрольних питань:

1. Що таке модель в нотації IDEF0?
2. Що означають роботи в IDEF0?
3. Назвіть порядок найменування робіт?
4. Яка кількість робіт має бути присутня на одній діаграмі?
5. Що називається порядком домінування?
6. Як розташовуються роботи за принципом домінування?
7. Яким є призначення сторін прямокутників робіт на діаграмах?
8. Перелічіть типи стрілок.
9. Назвіть види взаємозв'язків.
10. Що називається граничними стрілками?
11. Поясніть принцип іменування стрілок, що розгалужуються і зливаються.
12. Які методології підтримуються BPWin?
13. Наведіть основні елементи головного вікна BPWin.
14. Опишіть процес створення нової моделі у BPWin.
15. Як провести зв'язок між роботами?
16. Як встановити ім'я роботи.
17. Опишіть декомпозицію роботи.
18. Як додати роботу на діаграму?
19. Як дозволити тунельовані стрілки?
20. Чи може BPWin містити діаграми кількох методологій?

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

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

Це ми бачимо на прикладі СТО та ОТО, які перетворилися на своєрідний вид релігії, керуючої наукою та громадською думкою. Жодна кількість фактів, що суперечать їм, не може подолати формулу Ейнштейна: "Якщо факт не відповідає теорії - змініть факт" (В іншому варіанті "- Факт не відповідає теорії? - Тим гірше для факту").

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

Експеримент на те й експеримент, що він є не витончення думки, а перевірка думки. Несуперечлива в собі думка не може сама себе перевірити. Це доведено Куртом Геделем.

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

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

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

Перевага графіки

Що таке моделі IDEF0? Графічні схеми зі своїми особливостями та правила їх побудови. Чому саме графіка? Тому що вона ефективна. У цьому вся можна переконатися кількох прикладах.

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

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

Переваги IDEF0 дляIT-Фахівців

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

То як же доступно донести суть, не вдаючись до об'ємних текстів? Графік! Саме вона дає змогу скоротити написане, наочно демонструючи потрібну інформацію. Адже одне зображення здатне замінити сотні слів. І стосовно використання графіки при описі бізнес-процесів - це на 100% правильно.

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

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

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

IDEF0 – це…

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

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

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

Типи стрілок

Вхіднимиставляться завдання.

Вихіднимививодять результат діяльності.

Керівники(Стрілки зверху вниз) – це механізми керування.

Механізми(стрілки знизу нагору) використовуються для проведення необхідних робіт.

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

IDEF0 дозволяє обмінюватися інформацією, при цьому завдяки універсальності та наочності учасники обміну легко зрозуміють один одного. IDEF0 ретельно розроблявся і вдосконалювався, працювати з IDEF0 можна з допомогою різних інструментів, наприклад, ERWIN, VISIO, Bussines studio.

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

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

Як створюється функціональна модель

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

Основний блоктак і називатиметься «Написання статті».

Те, що необхідно для написання статті, відбивається на вхідних стрілок- "Досвід", "Додаткова література".

Керуючі стрілкидля написання статті - "План статті", "Вимоги до оформлення", "Правила російської мови".

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

Все вищеописане – лише загальна схема роботи, тому її необхідно деталізувати.

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

Так, весь процес написання статті можна поділити на 4 етапи:

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

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

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

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

Процес створення нотаціїIDEF0

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

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

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

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

Стандарт IDEF0 та його вимоги

Про базові вимоги IDEF0 ми говорили трохи вище.

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

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

Помилки під час роботи з IDEF0

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

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

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

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

Велика кількість блоків

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

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

Зміна структури під час виправлення помилок

p align="justify"> При створенні схеми важливо, щоб не один процес не залишився без вхідних, вихідних або інших важливих елементів. Наприклад, якщо потрібно видалити зі схеми автора, потрібно видаляти всі елементи і стрілки, які безпосередньо до нього належать. Якщо ж вони залишаться у схемі, то виникне непорозуміння і плутанина, бо при деталізації вестимуть невідомо куди.

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

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

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

Переваги використання IDEF0

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

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

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

Мінімальна ймовірність помилки.Робота за стандартом IDEF0 вимагає строгого дотримання його правил. Це дисциплінує виконавця та виключає можливість виникнення помилки. До того ж будь-яка невідповідність стандарту відразу стає помітною.

І на останок

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

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