Опис стандарту IDEF0, CASE-засоби (моделювання), Програмування, статті

В даний час в Росії різко зріс інтерес до загальноприйнятих на Заході стандартам менеджменту, проте, в реальній практиці управління існує один дуже показовий момент. Багатьох керівників до сих пір можна поставити в глухий кут прямим питанням про організаційну структуру компанії або про схему існуючих бізнес-процесів. Найбільш просунуті і регулярно читають економічну періодику менеджери, як правило, починають креслити зрозумілі тільки їм одним ієрархічні діаграми, але і в цьому процесі звичайно швидко заходять в глухий кут. Те ж саме стосується співробітників і керівників різних служб і функціональних підрозділів. У більшості випадків, єдиним набором викладених правил, відповідно до яких має функціонувати підприємство, є набір окремих положень і посадових інструкцій. Найчастіше ці документи складалися не один рік тому, слабо структуровані і невзаємопов’язаних між собою і, внаслідок цього, просто порошаться на полицях. До пори до часу подібний підхід був виправданий, так як під час становлення російської ринкової економіки поняття конкуренції практично було відсутнє, та й витрати рахувати не було особливої ​​потреби – прибуток був гігантською. В результаті цього, ми бачимо протягом останніх двох років цілком зрозумілу картину: великі компанії, які виросли на початку 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. C 1981 стандарт IDEF0 зазнав декілька незначних змін, в основному обмежує характеру, і остання його редакція була випущена в грудні 1993 року Національним Інститутом За стандартів і технологій США (NIST).


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


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


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


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


  • Верхня сторона має значення “Управління” (Control);

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

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

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

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



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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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

    Схожі статті:


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

    Коментарів поки що немає.

    Ваш отзыв

    Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

    *

    *