Методичні положення моделювання бізнес-процесів
Модель процесу - це системне уявлення способу виконання діяльності з використанням спеціалізованої мови. Реінжиніринг бізнес-процесів є одною з цілей моделювання процесів.
Поняття «моделювання бізнес-процесів» прийшло одночасно з появою на ринку складних програмних продуктів, призначених для комплексної автоматизації управління підприємством. Подібні системи завжди розуміють проведення глибокого передпроектного обстеження діяльності компанії. Результатом цього обстеження є експертний висновок, в якому окремими пунктами виносяться рекомендації щодо усунення «вузьких місць» в управлінні діяльністю.
На підставі цього висновку, безпосередньо перед проектом впровадження системи автоматизації, проводиться так звана реорганізація бізнес-процесів, іноді досить серйозна і болюча для компанії. Це і природно, що склався роками колектив завжди складно змусити «думати по-новому». Подібні комплексні обстеження підприємств завжди є складними і істотно відрізняються від випадку до випадку завданнями. Для вирішення подібних завдань моделювання складних систем існують добре обкатані методології і стандарти.
До таких стандартів відносяться методології сімейства IDEF. З їх допомогою можна ефективно відображати і аналізувати моделі діяльності широкого спектру складних систем в різних розрізах. При цьому широта і глибина обстеження процесів в системі визначається самим розробником, що дозволяє не перевантажувати створювану модель зайвими даними. В даний час широко використовуються CASE технології (Computer Aided Software System Engineering), які надають ряд нотацій для розробки описових моделей. Одними з найбільш популярних програмних продуктів, що забезпечують повний цикл аналізу, проектування і кодогенераціі, є автоматизовані інструменти серії Platinum technology (Logic Works): BPWin, ERWin, ModelMart, Paradigm Plus, RPTWin.
Застосування універсальних графічних мов бізнес-моделювання IDEF0, IDEF3 і DFD забезпечує логічну цілісність і повноту опису, необхідну для досягнення точних і несуперечливих результатів. За допомогою набору графічних інструментів для відображення дій і об'єктів, BPwin дозволяє легко побудувати схему процесу, на якій показані вихідні дані, результати операцій, ресурси, необхідні для їх виконання, управляючі дії, взаємні зв'язки між окремими роботами. Інтерактивне виділення об'єктів забезпечує постійну візуальну зворотний зв'язок при побудові моделі.
BРwin підтримує посилальну цілісність, не допускаючи визначення некоректних зв'язків і гарантуючи несуперечність відносин між об'єктами при моделюванні. Для того щоб почати моделювати БП треба визначити та систематизувати інформацію про даний БП, використовувати таку форму опису БП, яка була б універсальною для опису всіх БП існуючих в організації. Такою формою є опис паспортів БП. Згідно зі стандартом ISO 9001:2001 саме паспортизація БП є найкращим способом опису БП. В паспорті БП повинна бути вказана вичерпна інформація про БП. Паспорти БП розроблюється для таких рівнів опису БП як рівень опису БП, рівень моделювання БП, рівень виконання.
Паспорт БП для кожного рівня опису мають відповідно різний набір параметрів. Однозначного регламенту щодо складу параметрів, які повинні бути включені до паспорту БП нема. Вибір складу показників БП є важливим завданням щодо ефективного управління підприємством в умовах використання процесного підходу та визначає рівень керованості ним. В табл.2 наведений зразок формату паспорту БП.
Таблиця 2
Приклад формату паспорту БП
| N | Зміст | Рівень 1 | Рівень 2 |
| Найменування процесу | Розробка нового Закону України (ЗУ) Міністерства | ||
| Індекс | 1.1.2 | ||
| Призначення | Удосконалення правового поля підвідомчій сфери; Визначення цілей і завдань Міністерства на ринку як суб'єкта державного регулювання і в системі органів влади як відповідального за підвідомчу сферу регулювання | ||
| Результати | 1. Текст законопроекту, проекту Указу Президента або Уряду України і супровідні матеріали; 2. Проект офіційного відкликання, укладання Уряду України, поправок до розробляє мого Указу | ||
| Власник | Міністерство | ||
| Учасники | 1. Міністерство 2. Уряд та Держслужби 3. Органи державної влади суб'єктів України 4. Інші установи | Вимоги до кваліфікації | |
| Попередній процес | Підготовка та корегування плану уряду | Комісія Уряду з законопроектної діяльності | |
| Наступний процес | Підготовка та корегування плану на поточний рік | Міністерство | |
| Засоби реалізації | 1. Програмні засоби / Персональні комп’ютери | ||
| Об'єкти на вході | Аналітичні матеріали, пакет документів для розробки концепцій та ТЗ | ||
| Об'єкти на виході | |||
| Документи на вході | План законопроектної діяльності Міністерства на поточний рік | ||
| Документи на виході | План міністерства | ||
| Записи в ході процесу | Регламент проекту | ||
| Застосовувані внутрішні регламенти | Регламент проекту «Розробка законопроекту та його корегування за результатами його розгляду та узгодження» |
Складові паспорту різні і залежать від специфіки БП та мають бути визначені власником БП.
Таким чином, опис БП заснований на специфікації BPEL, допомагає їх власникові розгортати автоматизовані БП, якими можна управляти. BPEL надає цілісний підхід до опису БП і чітко зафіксовані конструкції, які при цьому використовуються. З цього випливає, що набір засобів для деталізації опису БП обмежений специфікацією BPEL. Якщо за допомогою специфікації не можна описати складну логіку, то цю логіку треба винести за рамки опису БП і реалізувати у вигляді сервісу, до якого буде звертатися БП. Ця властивість дозволяє обмежити складність опису БП тим самим провести межу між діями, які повинен робити власник процесу і розробник. Завдяки цьому власник БП зосереджується на бізнес-стороні завдання. Розробник не створює опис БП «з нуля», а лише уточнює існуючий опис, отриманий від власника БП, а потім викладає його у відповідності до специфікації BPEL. Отже, опис виконуваного БП залишається зрозумілим його власнику.
Таким чином, в порівнянні з традиційним підходом до управління, де контролюється діяльність структурних підрозділів, процесний підхід є більш ефективним за рахунок управління виконанням процесів, що відбуваються на підприємстві.
Поняття сервіс-орієнтованої архітектури є новим підходом до розробки ІС організацій, що дозволяє уникнути довгої та коштовної доробки або модернізації програмного забезпечення, дозволяє керівництву організацій керувати та брати участь у розробці необхідного інформаційного забезпечення. Сервіс-орієнтований підхід, заснований на web-технологіях дозволяє об’єднати територіально віддалених користувачів, об’єднати старі та нові інформаційні системи, дозволяє швидко доповнювати функціонал систем.
Вибір IBM WebSphere Business Process Modeler пояснюється тим, що саме ця система надає широкі можливості по імітаційному моделюванню та аналізу БП, також вибір обумовлений наявністю великої кількості навчальних матеріалів, посібників по розробці БП в даній системі, а також наявність дистрибутиву даної системи; визначено найкращу методику опису процесів - паспортизація – опис повної інформації про процес у вигляді паспорту процесу певного формату, проведено порівняльний аналіз нотацій моделювання БП. Для розробки моделі БП в умовах сервіс-орієнтованої архітектури доцільно використовувати нотацію BPMN, яка підтримується системами класу BPM.
Розроблення моделі процесу в даній нотації дозволяє легко перетворювати
графічне представлення процесу у виконуваний код на мові BPEL, що розміщується на сервері додатків та після доробок програмістами виконується BPM-системою.