Мова моделювання бізнес-процесів ММТ
Віталій Тупкало,
доктор технічних наук, професор
...стандартів повинно бути багато, чудових і різних...
Дивимося в корінь...
При впровадженні на підприємствах процесного менеджменту описування бізнес-процесів є ключовим завданням. Не зробивши коректного описування бізнес-процесів, немає сенсу переходити до наступних стадій аналізу діяльності підприємства, зокрема, вдосконалення організаційної і фінансової структур, піраміди менеджменту, впровадження ефективної автоматизованої інформаційної системи (рис. 1).
Що таке «коректне» описування? Це, перш за все, вибір мови (нотації) графічного подання, який забезпечив би максимальне візуальне сприйняття і розуміння суті (логістики) бізнес-процесів від прибиральниці до генерального директора підприємства і максимальну інформативність про його компоненти (функції посадових осіб, матеріальні ресурси, документообіг, входи і виходи тощо). Пропонуємо семінари в Києві, та корпоративні тренінги в компанії.
Як багато різних мов...
На сьогодні найвідомішими мовами (нотаціями) графічного моделювання бізнес-процесів є UML, ARIS, IDEF (IDEF0, IDEF3 у програмній інтерпретації BPwin). Порівняльному аналізу цих нотацій у частині недоліків присвячено багато публікацій (у т.ч. в Internet [1-4]). Тому автор статті не ставить перед собою завдання внести свою лепту в цей аналіз, а зі свого практичного досвіду моделювання з використанням згаданих мов повністю приєднується до думки авторів [1-4] і, зокрема: «...як показав наш досвід, моделі процесів, побудовані у BPwin, викликають труднощі при розумінні їхніми експертами предметної галузі. Це призводить до того, що експерти стають пасивними слухачами при обговоренні описування бізнес-процесів і їм, по суті, нав’язується розуміння бізнес-процесів аналітиками. Помилки неправильного описування бізнес-процесів з’ясовуються потім, на жаль, на пізніших етапах розробки...» [2]. Це ж стосується і UML та ARIS. До цього слід додати і той факт, що, розробляючи ці мови багато років тому, їхні автори не припускали необхідність такого важливого етапу синтезу бізнес-процесної моделі «Як повинно бути», як аудит моделі бізнес-процесів «Як є». Тут знову на перший план виходять вимоги до високої інформативності і візуального сприйняття графічного подання бізнес-процесів, які (бізнес-процеси) повинні відповідати певним правилам їхньої композиції.
І досвід – син помилок важких...
Багаторічний досвід використання графічного подання процесів функціонування різноманітних об’єктів управління (автор займається графічним описуванням процесів із середини 70-х, брав участь в описуванні сценаріїв роботи автоматизованої системи управління наземними пунктами стеження за польотами космічних апаратів колишнього СРСР АСУ «Скат») і критичний аналіз практичного використання мов UML, IDEF, ARIS зайвий раз підтвердили актуальність народної мудрості «Нове – це добре забуте старе» і привели до формування і використання з 2000 року мови графічного моделювання бізнес-процесів ММТ (мова моделювання Тупкало). Означена мова моделювання пройшла успішну апробацію в десяти проектах (Харківський КМЗ, Чугуївський РЕС АК «Харківобленерго», ВАТ «Кіровоградобленерго», ПЗЗ, ТОВ «ЕнТехЕко», Харківський інститут управління, ВАТ «Центренерго», Київський КБК, ТОВ «Астра», ПП з ІІ «Унітех БАУ», ЗАТ «РАКС»). З 2000 р. методика моделювання бізнес-процесів на основі ММТ стала предметом вивчення на відкритих і корпоративних семінарах-тренінгах автора з впровадження процесного менеджменту (зокрема, у 2004 -2005 рр. проведено семінари: ТОВ «Ді Стар» (м. Полтава), Павлоградський хімічний завод, ТОВ «Зв’язокінформсервіс» (м. Київ), ТОВ «Астра» (м. Верхнєдніпровськ), промислова група «КМТ» (м. Вінница), ТОВ «Платан» (м. Сімферополь), Львівський банківський інститут, ТОВ «Українські новітні технології» (м. Київ); 24 відкритих семінари в м. Києві).
Покажемо свою мову...
Семантичною основою ММТ є так зване правило «чотирьох сторін», яке продекларовано у методиці структурного аналізу і проектування SADT [3]. Слід зазначити, що першість використання цього правила у стандарті США сумнівна, бо воно використовувалося до появи SADT у згаданому вище проекті АСУ «Скат» колишнього СРСР у 70-х роках. ММТ дозволяє описувати бізнес-процеси різного ступеня докладності, але, як показала практика її використання в інтересах наших замовників (підприємств, які впроваджують процесний менеджмент), найціннішим для них є тільки максимальний ступінь докладності описування бізнес-процесів (одна функція (операція) процесу – конкретна посадова особа). Лише у цьому випадку можливе успішне вирішення відомого завдання організаційного програмування при реорганізації діяльності підприємства (рис. 2). Дана реальність змусила нас розробити і застосувати на практиці відповідну методику попереднього обстеження підприємства, створення моделей «як є» і «як потрібно» (ця методика є предметом окремої статті). Крім того, ґрунтуючись на твердженні: «Аудит бізнес-процесів – це оцінка відповідності їхнього сприйняття встановленим правилам композиції», ММТ-діаграми дозволяють оцінювати якість моделі бізнес-процесів за 18-ма базовими правилами (методика аудиту є предметом окремої статті).
При накресленні діаграм бізнес-процесів із застосуванням ММТ використовуються такі базові погодження та елементи:
- Функціональні дії (роботи) зображуються прямокутником.
- Стрілки ліворуч (входи) відображають вхідні інформаційні і/або матеріальні потоки, необхідні для здійснення функціональних дій.
- Стрілки праворуч (виходи) відображають результати виконання функціональних дій.
- Стрілки знизу відображають необхідні для виконання функціональних дій ресурси (наприклад: оператор, робітник, верстат тощо).
- Стрілки зверху відображають об’єкти, що є підставою для виконання функціональних дій. Це можуть бути Держстандарти і/або робочі інструкції, а також інші документи — підстави.
- Стрілки можуть розгалужуватися і зливатися, тим самим, утворюючи ієрархію даних.
- ММТ-діаграми бізнес-процесів повинні починатися і закінчуватися графічним зображенням інформаційних і/або матеріальних сутностей.
Елементи зв’язку (тунелювання)
|
|
Стрілки тунелювания, що позначають початок і кінець бізнес-процесу; |
|
|
Точка кінця життєвого циклу інформаційної або матеріальної суті (наприклад, архів документів; матеріальний засіб, що перебуває у певному спокої); |
|
|
Стрілки прямих (вперед) внутрішніх переходів ММТ-діаграми даного бізнес-процесу; |
|
|
Стрілки зворотних (назад) внутрішніх переходів ММТ-діаграми даного бізнес-процесу; |
|
|
Вхід/Вихід суміжного (що не розкривається) бізнес-процесу даної (своєї) організації (підприємства); |
|
|
Вхід/Вихід суміжного (що не розкривається) бізнес-процесу сторонньої (чужої) організації (підприємства); |
|
|
Точка з’єднання суміжних аркушів ММТ-діаграми даного бізнес-процесу. |
Базові функціональні елементи
|
|
Функціональна дія; F3 — третя функція бізнес-процесу; |
|
|
Документ на вході (виході) функціональної дії (функції); D3.1 — перший документ на виході третьої функції (F3) даного бізнес-процесу; |
|
|
Документ на вході (виході) функціональної дії (функції); D3.1 — перший документ на виході третьої функції (F3) даного бізнес-процесу; |
|
|
Електронна форма документа D3.1 і/або База Даних (БД); |
|
|
Центр посадової відповідальності за виконання даної функції даного бізнес-процесу; |
|
|
Коментар; |
|
|
Центр посадової відповідальності при виконанні даної функції даного бізнес-процесу використовує комп’ютер; |
|
|
Програмний модуль АРМа виконавця (ресурс), що підтримує виконання четвертої функції даного бізнес-процесу. |
На відміну від відомої нотації описування бізнес-процесів IDEF 0 в ММТ-нотації для відображення логіки взаємодії потоків даних (інформації) використовується п’ять базових логічних елементів:
|
|
Галуження процесу за умовою; |
|
|
Наступна дія можлива за умови одночасної наявності на входах усіх результатів попередніх робіт; |
|
|
Наступна дія на виході можлива за умови наявності на входах будь-якого поєднання результатів попередніх робіт; |
|
|
Результат однієї попередньої дії передається на входи наступних дій (розмноження одного входу на декілька виходів за логікою АБО); |
|
|
Результат однієї попередньої дії обов’язково (одночасно) передається на входи всіх наступних дій. |
Приклад використання елементів ММТ при створенні моделі бізнес-процесу наведено на рис. 3 (цей же бізнес-процес у нотації IDEF0 BPwin наведено на рис. 4 [5]). З порівняння рис. 3 і рис. 4 випливає, що на відміну від IDEF0 BPwin у ММТ передбачено:
- використання символів логіки виконання процесу;
- візуальний розподіл паперових і електронних носіїв інформації і, як наслідок, обов’язкове введення графічного символу «комп’ютер»;
- використання (за необхідності) пояснювальних коментарів;
- символ «центр відповідальності» (посадова особа) доповнювати символами принципово значимих (для оцінки затрат) матеріальних ресурсів;
- відсутність довгих (прямих і тих, що повертаються) і ліній, які пересікаються.
ММТ-діаграми бізнес-процесів мають стрічкову структуру подання одного рівня у вигляді набору окремих аркушів (рис. 5-1, 5-3 ), що дає змогу її композувати власне як стрічку з нанесенням тимчасової осі (за необхідності).
Досвід роботи з ММТ-діаграмами показав, що відома рекомендація [3]: «...для ведення невеликих за масштабами (дрібні й середні підприємства, 2-5 осіб у групі консультантів (2-3 місяці) проектів раціонально використовувати BPwin. Для крупних і/або тривалих проектів (наприклад, впровадження системи безперервного поліпшення бізнес-процесів, ISO, TQM) більше підходить ARIS...» не є обмеженням для використання ММТ. Крім того, ясність і простота бізнес-процесів з використанням ММТ дозволяє нашим бізнес-консультантам відмовитися від традиційної текстової (проміжної) форми запису інтерв’ю з виконавцями бізнес-процесів з наступним «переведенням» тексту в графічну форму діаграм бізнес-процесів з використанням CASE-засобу, але вже без участі самих виконавців. Це інтерв’ю після невеликого пояснення правила «чотирьох сторін» і суті логістики бізнес-процесів відразу записується у вигляді ММТ-діаграм з активною участю й інтересом з боку інтерв’ювованих.
І ще про одне відоме судження [3]: «...Раціональний вибір системи (CASE-системи описування — прим. автора) можливий при розумінні керівництвом компанії та її спеціалістами деяких аспектів:
- Мети проекту.
- Вимог до інформації, що характеризує бізнес-процеси і необхідна для аналізу і прийняття рішення в рамках конкретного проекту.
Можливостей CASE-систем з описування процесів з урахуванням вимог п.2.». На нашу думку, ця теза спірна. Керівник компанії для того і наймає сторонніх консультантів, щоб не займатися лікбезом у галузі мов описування бізнес-процесів, а одержати рекомендації щодо ефективного вирішення проблеми у зрозумілій та сприйнятній формі для себе і своїх співробітників.
Насамкінець хотілося б відзначити, що ми не нав’язуємо своєї думки стосовно вибору мови моделювання бізнес-процесів. На наш погляд, поки що ні з чого вибирати і, тим більше, говорити про прийняття якоїсь із відомих мов за стандарт. Крім того, проблему вибору мови моделювання не може бути вирішено без чіткого розуміння поняття «аудит бізнес-процесів».
Цитовані джерела інформації
1. Сахаров П. «Rational Rose, BPwin та інші — аспекти аналізу бізнес-процесів»;
2. Золотухіна Е.Б., Алфімов Р.В. «Приклад описування предметної галузі з використанням Unified Modeling Language (UML) при розробці програмних систем»;
3. Репін В.В. «Порівняльний огляд нотацій. Частина 1. Вступ. Типові завдання описування бізнес-процесів. Вимоги до описування бізнес-процесів підприємств»;
4. Репін В.В. «Проблеми застосування IDEF0 (і не лише) для описування процесів»; w
5. Розробка документа "А", модель в IDEF0-IDEF3»;
Статьи этой же рубрики
