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

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


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


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



  1. стандарт проектування бізнес-процесів;
  2. галузеві стандарти бізнес-процесів;
  3. раніше прийняті стандарти проектування бізнес-процесів підприємства;
  4. настановні концепції.

Прикладом стандартів проектування бізнес-процесів може служити сімейство стандартів IDEF (Держдепартамент і BBC США), RUP (компанія Rational Software), Catalysis (компанія Computer Associates). Галузевими стандартами є моделі, що розробляються державними та міжнародними громадськими організаціями (рекомендації ISA, APICS, ISO, TM Forum та ін.) Стандарти підприємства зазвичай становлять підмножину стандартів (1) і (2), збагачене процедурними правилами розробки та узгодження моделей бізнес-процесів, прийнятих на підприємстві.


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



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


Не станемо обмежуватися розглядом однієї з цілей моделювання, а спробуємо зосередитися на аспектах моделювання бізнес-процесів, що мають загальну значимість. Вихідний контекст статті – це абстрактний проект, метою якого є розробка моделі бізнес-процесів, а предмет обговорення – завдання «настройки» обмежень (3-4) на цей проект. Фактично мова йде про процес пристосування стандарту (Tailoring process) і точок зору проектувальника, який, як правило, містить величезні можливості для привнесення суб’єктивних рішень, як з волі проектувальника, так і з волі замовника. Тому необхідні додаткові методичні рекомендації, які звузили б область творчого «свавілля» при модифікації стандартів проектування бізнес-процесів.


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


Функціональна модель бізнес-процесів


Будь стандарт проектування бізнес-процесів базується на вихідних поняттях – смислових примітивах. Так, стандарт IDEF0 використовує поняття «Робота» (Activity) для позначення дії, а також позначення інтерфейсів «Вхід» (Input), «Вихід» (Output), «Управління» (Control) і «Механізм» (Mechanism), які складають графічну конструкцію (A), зображену на рис. 1.

рис.1


На жаль, в IDEF0 ці примітиви визначаються в загальному вигляді, тому користувачі стандарту зазвичай вдаються до інтерпретацій примітивів. Наприклад, тільки на перший погляд конструкція з рис. 1 виглядає логічною, а формування додаткових концептуальних установок – непотрібним. Як правило, у початківця користувача виникає здивування, куди йому необхідно віднести поняття «Розпорядження»: до інтерфейсу «Управління» або до інтерфейсу «Вхід»? Або куди віднести поняття «витратні матеріали» при моделюванні роботи канцелярії: до «Входу» або «Механізму»? Далі – більше. Стандарт IDEF0 виконавців «Робіт» (Морського і неживих) відносить до інтерфейсу «Механізм». На рівні побутового свідомості це не викликає питань, проте, якщо вдуматися в суть поняття «виконання», то стає зрозумілим, що виконавець «Робіт» є активатором «Робіт», що складають дану «Роботу» і призводять до її виконання. Між тим, активатором «Робіт» згідно IDEF0 є «Вхід».


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


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


Всі «Роботи» належать одному класу – мають однаковим набором властивостей і поведінкою.


Усі зв’язки між «Роботами» належать класу «Ресурс». Наприклад, електронне видання «Податкового кодексу РФ» є реалізацією (чи примірником) загальнодоступного інформаційного ресурсу, а прибиральниця Іванова І.І. є екземпляром ресурсу «Прибиральниця офісу 202».


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


1. Ознака мінливості примірників ресурсів при виконанні «Роботи»:



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


2. Ознака блокування примірника ресурсу «Роботою», що виключає можливість використання примірника ресурсу іншими «Роботами»:



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


Події та ресурси


Найважливіший компонент моделювання бізнес-процесів – оцінка матеріальних, вартісних і часових ресурсів, необхідних для виконання всього безлічі процесів. В сучасних інструментах проектування, підтримують IDEF0, для цих цілей використовується функціонально-вартісний аналіз, а розрахунки проводяться методом безпосередньої імітації виконання «Робіт». Можна зустріти думку, що одним з недоліків IDEF0-моделей, в яких з тих чи інших причин не визначаються моменти активації робіт, є помилка функціонально-вартісного аналізу, викликана фактором порушення послідовності «Робіт». Ця помилка вважається допустимою для наближених розрахунків. Для більш точних розрахунків пропонується використовувати інші інструменти; так, в BPwin наявна можливість експорту даних в систему EasyABC. Однак це занадто дороге рішення для такої простої задачі. Що заважає нам більш чітко визначити моменти активації «Робіт» на IDEF0-діаграмах?


Вважається, що основною відмінністю стандартів, націлених на функціональне або процесне моделювання, є їх можливості щодо опису подій та послідовності виконання «Робіт» в часі. В відомому керівництві [4] користувачам стандартів IDEF0 і IDEF3 наполегливо нав’язується ідея про різний їх призначення, йдеться про відмінності інтерпретації стрілок в IDEF0 і в моделях потоку робіт [5]. Покажемо, що це твердження далеко від дійсності.


В якості базової посилки приймемо положення про те, «що не заборонено стандартом, то дозволено». Покажемо, що IDEF0 не забороняє зображувати події та визначати послідовність «Робіт» за допомогою стрілок. Будемо виходити з того, що в IDEF0 активаторами робіт визначено стрілки [5]. На жаль, сутність такої активації в стандарті не пояснюється. Логічно припустити, що активація – це примус до виконання «Роботи» або, як мінімум, зміна стану «Роботи», яке теж можна тлумачити як початок виконання. При цьому активація може тлумачитися широко. Наприклад, відсутність інформації на вході «Роботи» теж може розглядатися як активація.


Однак у стандарті, як це не дивно, синтаксично не розрізняються «Роботи», що знаходяться на різних рівнях декомпозиції. Відмінності ж між ними істотні. Згідно з положенням стандарту про те, що активаторами «Робіт» є стрілки, а на нижньому рівні декомпозиції бізнес-процесів стрілки описують послідовність виконання «Робіт» [5], можна стверджувати, що кожна «Робота» на нижньому рівні декомпозиції моделі активується тільки при активації всіх її входів. На жаль, з тексту стандарту не випливає, що вважати умовами активації «Роботи» більш високого рівня. Стандарт рекомендує проектувальнику, по можливості, не замислюватися над цією проблемою, проте не наполягає на цьому виразно [5]. Читач стандарту може в цьому самостійно переконатися, якщо не виривати фрази з контексту.


Існує ще аспект часу, який стандартом замовчується, – момент завершення «Роботи». Без його знання функціонально-вартісний аналіз, заснований на моделюванні, не буде завершено. Можна ховати голову в пісок і не визначати умова активації «Роботи», але момент її завершення ми бачити зобов’язані. На щастя, відповідь на питання про момент завершення «Роботи» тривіальний: «Робота» не може бути завершена, поки всі її входи не будуть активовані. Тепер і нематематика повинно бути ясним, що відомі умови активації «Робіт» на діаграмах нижнього рівня і відомі умови закінчення «Робіт» на верхніх рівнях дозволяють однозначно відновити інформацію про умови активації «Робіт» на всіх рівнях. Інакше кажучи, умови активації «Робіт» в IDEF0 є зумовленими.


Розглянемо тепер один з можливих варіантів конкретизації опису подій в IDEF0.


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


Це обумовлено тим, що ми має справу не з самими подіями, а з інформацією про явища, що сприймається як подія. Інформація про явище – це інформаційний ресурс. Бізнес-процеси обмінюються друг з одним тільки ресурсами і нічим іншим, тому ясно, що клас «Подія» є виродженим, і в «життя» бізнес-процесів існує тільки один підклас подій – «Надходження Ресурсу», а самі «Події» розрізняються видом ресурсу. Наприклад, нормативні документи, які відповідно до рекомендацій IDEF0 розглядаються як «Управління», є неізнашіваемим інформаційним ресурсом загального користування. Іншими словами, стрілки на IDEF0-діаграмах відповідають «Подіям», а включення примітиву «Подія» у будь-стандарт проектування бізнес-процесів нічим не виправдане і є надлишковим – по крайней мірі, якщо дотримуватися ресурсної концепції управління організацією. Цей же висновок поширюється і на об’єкти, звані «перехрестями» в стандарті IDEF3.


Отже, сформулюємо ще одну настановну концепцію.


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


2. Необхідною (але не достатньою) умовою завершення «Роботи» є звершення повного набору подій «Надходження Ресурсу», пов’язаних з інтерфейсами «Роботи».


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


Про уніфікації опису бізнес-процесів


У якості першої настановної концепції озвучувалася ідея про приналежність «Робіт» одному класу об’єктів, що володіють однаковим набором властивостей і поведінкою. Для чого це потрібно? Перш за все, для того щоб різні «Роботи» могли спілкуватися один з одним на одній мові. Тільки в цьому випадку бізнес-процес може бути відкритою системою. Про необхідність дотримуватися ідеології відкритих систем при проектуванні моделі бізнес-процесів як необхідну умову реалізації принципу послідовних модернізацій писалося не раз [1, 2]. Тільки відкритим системам властивий низький рівень витрат при супроводі і доробках.


На моделювання бізнес-процесів, згідно методології IDEF і першим її інтерпретацій, був орієнтований стандарт IDEF3. Основним його відмінністю від стандарту функціонального моделювання IDEF0 була можливість задавати послідовність «Робіт» за допомогою дуг і умови на послідовність виконання «Робіт» за допомогою логіки «перехресть» (синхронні і асинхронні іілі, що виключає АБО). Передбачалося, що проектувальник, не вдаючись в опис логіки взаємодії «Робіт», розробить функціональну IDEF0-модель до певного рівня декомпозиції «Робіт», а потім на нижніх рівнях перейде на моделювання бізнес-процесів у відповідності зі стандартом IDEF3, відображаючи вже логіку взаємодії «Робіт». Оскільки рівень декомпозиції IDEF0-моделі, на якому здійснюється перехід на стандарт IDEF3, визначається проектувальником суб’єктивно, то говорити про будь універсальності уявлень бізнес-процесів при такому підході не доводиться.


Як було показано, пропонована конкретизація положень IDEF0 в частині опису подій і, отже, логіки, не поступається за функціональністю стандарту IDEF3. Так, в рамках ресурсної концепції управління організацією дуги в стандарті IDEF0 також можуть показувати послідовність виконання «Робіт», а умови виконання «Робіт» задаються подіями «Надходження Ресурсу». Можливо, це стало однією з причин, чому в популярному інструментарії BPwin діаграми, що підтримують стандарт IDEF0, називаються Business Process Diagram. Одне можна сказати точно: одночасне використання стандартів IDEF0 і IDEF3 в рамках одного проектного процесу ніяк не сприяє однозначному розумінню поняття «бізнес-процес» в системі стандартів IDEF.


Що таке «Робота», інтуїтивно ясно. Складніше йде справа з бізнес-процесом, описуваних «Роботами». У статті [3] зібрано 10 різних визначень бізнес-процесу і показано, наскільки складний логіко-лінгвістичний аналіз визначень бізнес-процесу на смислове несуперечність; там же наводиться авторське визначення. Для більшої наочності дамо визначення бізнес-процесу, використовуючи графічну нотацію IDEF0 та рекомендації щодо адаптації мови, сформульовані раніше. При розробці загальної моделі автором використовувалися настановні концепції, запозичені з моделі взаємодії відкритих систем, методичних матеріалів асоціацій документарній електрозв’язку і телекомунікаційного співтовариства.


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


2. Всі бізнес-процеси в організації об’єднані одним завданням – наданням послуг один одному на основі аналізу запитів про постачання послуг. Зокрема, послугою може бути виготовлення та постачання продукту.


3. Надання послуг один одному бізнес-процеси здійснюють згідно єдиної процедури.


На рис. 1. представлена ​​універсальна IDEF0-модель бізнес-процесу, що показує сутність інтерфейсів «Роботи»; як правило, проектувальники бізнес-процесів при їх моделюванні її не розкривають. Особливість цього графічного визначення – його акцентування на інтерфейсах бізнес-процесів, що описуються у вигляді окремих «Робіт». Часто усвідомлення необхідності інтерфейсів приходить до проектувальника з запізненням, змушуючи його переробляти модель або покладати функції інтерфейсів розглянутого бізнес-процесу на його контрагенти. В цьому випадку бажано «примусово» створювати спочатку проміжну IDEF0-діаграму, на якій зображені «Роботи»: вхідні та вихідні інтерфейси бізнес-процесу і «Робота», що відображає сутність бізнес-процесу (нею зазвичай обмежується недосвідчений проектувальник). Цього можна не робити тільки у випадку, якщо проектувальником усвідомлено відсутність необхідності розробляти інтерфейси бізнес-процесів. Структура запропонованої моделі бізнес-процесів відповідає сучасним уявленням про структуру систем, у тому числі і систем управління.


Перераховані концепції досить жорстко обмежують безліч можливих способів уніфікації бізнес-процесів. Один з них представляє бізнес-процеси у вигляді тріади «Робіт»: «Аналіз реакції зовнішнього середовища», «Моделювання», «Вплив на зовнішнє середовище». Дана ідея викладена в [1] і заснована на припущенні, що організація – це система процесів «рефлексії». Найважливішим елементом є «Моделювання». Вибір цього терміна диктується точкою зору автора на те, що бізнес-процеси обмінюються один з одним не об’єктами «реального» світу, а уявленнями про них. Така точка зору дозволяє адекватно переходити до задачі оцінки вартості послуг або продуктів.


Моделювання – «Робота», що відповідає за безпосереднє перетворення поставляються бізнес-процесом «Ресурсів» і формування нових «Ресурсів», що поставляються іншим бізнес-процесом. Іншою найважливішою функцією цієї «Роботи» є планування (або програмування) поставок «Ресурсів» іншим бізнес-процесом. План поставок будується для даного бізнес-процесу з використанням моделі його зовнішнього середовища (Скажімо, на основі заявок на поставку ресурсів). Вхідним інтерфейсом бізнес-процесу є «Аналіз реакції зовнішнього середовища» (тобто «Робота», що забезпечує на основі моделі зовнішнього середовища і правил спостереження «Фільтрацію» надходять «Ресурсів» і формування необхідних специфікацій «Ресурсів», необхідних для виконання «Моделювання»). Вихідним інтерфейсом бізнес-процесу є «Вплив на зовнішню середовище »(тобто« Робота », що здійснює поставку« Ресурсів »контрагентам на основі плану поставок, а також направляє звіти про постачання« Моделювання »).


Висновок


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


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


Література


  1. С. Рубцов, Який CASE-інструмент завдасть найменшої шкоди організації? / / Директор інформаційної служби, 2002, № 1.
  2. С. Рубцов, Взаємодія відкритих систем – стара концепція для нових ідей. / / Нові ринки, 2001, № 4.
  3. С. Рубцов, Уточнення поняття “бізнес-процес”. Менеджмент в Росії і за кордоном, 2001, № 6.
  4. R. J. Mayer, C. P. Menzel, M. K. Painter, P. S. deWitte, et al. Information Integration For Concurrent Engineering (IICE). IDEF3 Process Description Capture Method Report. – Wright-Patterson Air Force Base, Ohio: Air Force Materiel Command, 1995.
  5. National Institute of Standards and Technology. Integration Definition For Function Modeling (IDEF0). – Washington: Draft Federal Information, 1993.

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


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

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

Ваш отзыв

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

*

*