Яке значення інструментів робочого процесу? [зачинено]

Я новачок у розробці Workflow, і не думаю, що я справді отримую "велику картину". А може бути, інакше кажучи, ці інструменти наразі не «клацають» у моїй голові.

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

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

Якщо ви збираєтеся піти так далеко, чому б просто не використовувати якусь мову сценаріїв? Чи люди на цьому викинули дитину разом з водою? Чи було зроблено рядки з рядками та полями на абсурдному рівні, чи я просто не розумію значення у всьому цьому?

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

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

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

Поточний стан програмного забезпечення робочого процесу не є виною бізнесу. Вони просто хочуть полегшити своє життя, і робочі процеси для цього чудово підходять. Я б здебільшого звинувачував нас, відділ ІТ:

1. Бо не бути більш прозорим у бізнесі щодо того, наскільки складною та крихкою є система. Ми приховуємо всю складність.
2. Бо не в змозі "почухати наш свербіж" за допомогою інтуїтивних, простих рішень для робочого процесу. Це, мабуть, скоріше скарга проти великих корпоративних пакетів, таких як SharePoint та SAP, але вони кращі, ніж спеціальні рішення там

Є лише одна реальна користь, і все ж її величезна: Розмежування проблем .

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

Історично концепція SoC вигравала багато разів - починаючи з принципу Unix "зроби одне, але зроби це добре", і застосовується знову і знову - як, наприклад, з виділеними серверними компонентами, такими як ESB, різні системи стійкості, кешування, балансування навантаження , моніторинг, як поділ CSS від HTML тощо

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

З того часу було створено багато інструментів та мов для підтримки цієї концепції, найбільш відомим є BPMN - графічна мова для створення "блок-схем", які безпосередньо відображають процеси. Хоча люди скаржаться на те, що його великий і негромадний (маючи понад 100 символів у словниковому запасі), і виступає за такі сучасні підходи, як S-BPM (має лише 5 базових символів), нинішня галузева практика полягає в дотриманні BPMN або його похідних, підмножин або побратимів.

Ви не виглядаєте задоволеними BPMN:

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

Але це не так вже й погано) За цим стоїть теорія. І версія 2.0 продемонструвала гарне уявлення про 1,0 недоліки.

Якщо ви збираєтеся піти так далеко, чому б просто не використовувати якусь мову сценаріїв?

Імперативна парадигма та мови сценаріїв - не завжди найкраща відповідь. Як ви, напевно, бачили в декларативних мовах (наприклад, HTML, CSS, SQL, Drools або внутрішніх Nginx, Graddle та Maven, Puppet тощо), отриманий код може бути набагато меншим та чистішим, ніж версія, написана " гідною мовою" як-от Java або C ++ ".

Щодо вашого іншого пункту:

Наскільки я можу сказати, є візуальними мовами програмування на даний момент, доповненими умовними умовами та циклами.

Ви подивилися на події та тригери ? BPMN - це мова, і ви повинні її вивчити перед використанням, або принаймні ознайомитись з нею.

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

На щастя, на ринку вже є інструменти, які це роблять.

Activiti є безкоштовним і досить популярним як серед розробників, так і власників бізнесу, через свою початкову ціну ( нуль ), доступність інформації та скромність. Останній пункт справді унікальний, оскільки Activi зосереджена лише на управлінні своїми бізнес-процесами, не намагаючись зв’язати вас із рішеннями цілих пакетів. Крім того, його відкрито - значить, вам потрібно знати лише Java та REST, щоб розпочати роботу та працювати. Недолік полягає в тому, що клієнтська інтеграція, інтеграція та логіка застосувань / бізнес та вся архітектура залишаються розробнику, тому якщо ваша команда розвитку слабка - готуйтеся до відмови. Загальна вартість власності може бути напрочуд високою для безкоштовного інструменту;)

З іншого боку спектру - Пега (Pega PRPC), правлячий король систем БПМ (за даними Gartner та Forester), який виглядає напрочуд добре для свого віку. Цей бегемот з кухонної раковиною навіть здатний керувати CRM, OCR та (якщо я не помиляюся) розпізнаванням мови, прогнозною аналітикою, керуванням бізнес-правилами та редактором інтерфейсу WYSIWYG. Однак він поставляється з серйозною ціною. Це не тільки коштує цілий капітал, але все розробляється в рамках веб-додатку, а це означає, що ви повинні використовувати браузер, який є IE8 (плюс деякі додатки, плюс некрасиві хаки, як, наприклад, використання Excel для редагування таблиць даних). Крім того, редагування Java, Javascript або HTML / CSS також проводиться за допомогою веб-браузера - тому попрощайтеся з одиничними тестами, виділенням коду IDE, рефакторингом та всіма вашими іграшками програмування, яких ви любили.

Хороша сторона? Ви можете впровадити складну систему ВІД ТИЖДЕННЯ [ PDF , див. сторінку 22]. І так, результат не гарантований.

IBM недавно (відповідно до часового темпу підприємства) придбала Ломбарді, і зараз пропонує дуже конкурентне рішення (але тоді вам доведеться купувати все , що ви знаєте). Appian - молодий продавець, який має цікаві уявлення та позитивні відгуки, але спосіб їх написання (дві додаткові мови DSL на додаток до візуальної) мені просто не подобається.

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

Примітка:

Система BPM однакова для процесів, що і Photoshop для зображень. Не бійтеся, що його візуально. Не змушуйте її робити роботу, яка не підходить для неї (пам’ятаєте веб-сайти, створені повністю у Photoshop, які було неможливо редагувати?). Нехай це буде просто і не робити помилок;)

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

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

В останні 10–15 років ІТ-відділи усвідомлюють, що логіка хореографування та / або упорядкування бізнес-процесів настільки поширена, що вона також повинна бути власною складовою, що призводить до різного роду різних інструментів робочого процесу.

Є три основні переваги інструменту робочого процесу:

1. Час, необхідний для внесення та розгортання змін : ви можете розробити та змінити логіку робочого процесу без тих же технічних ризиків, які ви маєте зі зміною фрагмента коду.
2. Прозорість : бізнес-логіка в системі, що базується на BPM, одразу доступна та читається бізнес-аналітиком, тоді як лише розробники зможуть читати бізнес-логіку в системах, що базуються на кодах.
3. Повторне використання технічних компонентів : засоби BPM часто використовуються разом із системами, що мають архітектуру, орієнтовану на сервіс. Відокремлюючи бізнес-логіку від технічних компонентів - особливо для корпоративних систем, які повинні впроваджувати сотні чи тисячі різних бізнес-процесів - ви зможете повторно використовувати технічні компоненти, витрачаючи порівняно мало часу на розробку бізнес-логіки (з робочим процесом інструмент).

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

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

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

Нижче викладені мої особистої роботи з використанням інструментів робочого процесу, зокрема Oracle BPM Suite (10,3G та 11G). Спочатку уточнюйте, що ваше питання зосереджується на інструментах робочого процесу, які дозволяють моделювати виконавчі моделі процесів, ці інструменти є частиною систем управління бізнес-процесами (BPMS). Це моделювання конкретного процесу, безумовно, розвивається, і ви можете позначати його як мову візуального програмування.

Основна перевага - спритність розуміння та зміни логіки процесу

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

Крім того, ви додали можливості звітування / моніторингу, що вам доведеться розробляти індивідуально для кожної програми, що охоплюється більшістю БПМС.

Крім того , в більшості адаптерів середовища розробки BPM послуг є прекомпілірованние (наприклад , JMS, Web Services, JDBCs і т.д.), що дозволяє швидше розробляти рішення проміжного в крок за кроком інтерактивної інтеграції, зменшуючи число людських помилок при кодуванні.

Наступна платформа робочого процесу дає багато переваг, згаданих вище - Підхід на основі платформи для автоматизації робочих процесів

Значення

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

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

Чому цінність може бути не реалізована

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

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

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

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

Програмування - це робочий процес

Правда полягає в тому, що програмування (принаймні в імперативних мовах) ВИРОБЛЯЄТЬСЯ. Можливо, у вас є код, який реалізує робочий процес, що стосується обробки системної технології; доступ до файлів та виконання SQL-запитів тощо. Ви можете мати код, який реалізує робочий процес у бізнесі; встановлення стану документа та передача його, наприклад, рецензенту.

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

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

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

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

Існує стандартний спосіб, який сьогодні використовують багато компаній, під назвою BPMN 2.0 (нотація моделювання бізнес-процесів). Я рекомендую вам зрозуміти це позначення, якщо ваш інструмент використовує його.

Орган знань з управління бізнес-процесами - відомий ресурс, який ви можете також розглянути.

Сказане стосується ділової сторони. Технічна сторона вимагає SOA та BPEL, але я не впевнений, що можу надати поради щодо тих, хто тут і зараз.

На простому прикладі з історії.

Кам'яний вік

Спочатку у вас були невеликі компанії, що займаються менширом, де люди просто де розповідали, що робити, і вони це зробили. Іноді речі стають неправильними, і особа X чи Y звинувачуються (ніколи не знаю, хто це зробив).

Наступний Інтернет та електронна пошта були винайдені

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

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