Бізнес-процеси: Як все запущено і заплутано. Глава Третя. Загальна класифікація BPM і філософія BPMS


BPM «Як є» і «як не є»


Продовжуємо міркувати «що таке BPM», це який «Business Process Management» і які вони бувають. Парадокс: про нього стільки вже десятиліттями понаписувано — книжок, статей, дискусій, але що це таке – сьогодні так і залишається загадкою, причому: чим більше пишуть – тим більше загадковіше стає.

Не допомагають ні книжки із серії «Для чайників», ні заповіти CBOK, ні магічні квадрати Гартнера (BPM: BPA, BPMS, iBPMS тощо), в яких, як і в чорних квадрати Малевича (а у нього тільки чорних було кілька різних варіантів) – кожен норовить побачити щось велике і таємниче, ведене тільки йому.

У розділі пропонується варіант класифікації BPM-подібних сутностей. В інформаційній війні з «алхімією 21 століття» продовжуємо розвінчувати популярні міфи про Business Process Management, Enterprise Architecture (ЕА) та іже з ними. Робимо черговий крок на шляху становлення BPM як звичайної (повсякденного, повсюдною, тривіальною) інженерної дисципліни: process technology, «процес-техніка».



Рекогносцировка

У першій главі «Бізнес-процеси: Як все запущено і заплутано» ми подивилися на «BPM» очима маркетингу і показали його ключові міфи. На станицях cnews (див. коментарі до статті) подискутували на тему «BPM – EA – Alchemy».

У другій главі спробували відділити «мух від котлет» і показали крайнощі (голови і хвости): BPM це не про бізнес-менеджмент (там швидше щось «з опер» BIZBOK-ів, BABOK-ів тощо) і не про «ІТ-фішки» (SOA, ESB і іже з ними). BPM навіть не про автоматизацію, що на класичних мовах програмування (від «сі», до «яви» під контролем SWEBOK-і), що на «новомодних» інструментах, — заснованих на BPMN або навіть на «нічого» («no code», де нібито кодити не потрібно). Обговорення другий голови за участю «Алхіміка 80-го рівня» на bpmsoft.org

Коли половина «розумної книжки про BPM» присвячена SOA, ESB і т. п., думаєш: якщо їх немає в компанії, то і BPM в компанії теж неможливий? Або: «жити BPM» в компанії, де немає (мало) автоматизації? На цю тему фрагмент з книжки Управління бізнес-процесами. Практичне керівництво щодо успішної реалізації проектів

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


Послання «Чайникам» від IBM.
Які ж одкровення нам повідав блакитний гігант у своїй Business Process Management For Dummies, IBM Limited Edition?

Введення і перша глава: написані в стилі: «Щасливі володарі BPM», «Тільки BPM може допомогти вашій організації стати ...» (далі, вище, сильніше і т. п.)… супер-пупер і т. п. Причому в рекламній стилістиці книжки так і напрошується підміна співзвучного терміна «BPM» на «IBM», без будь-якої зміни смислового змісту (точніше реклами): «Якщо ви дочитали главу до цього моменту, то вам тепер ясно, що BPM (точніше IBM) — це круто».

Власне цього підходу була присвячена ціла глава «Бізнес-процеси: Як все запущено і заплутано. Глава перша». Одним словом, всім «чайникам» після прочитання «BPM для чайників» повинно стати ясно, що їм дуже потрібен BPM (це ж «круто»), але що це таке знати їм не обов'язково (в книжці я не знайшов відповіді). Інші глави повторюють те ж саме і, звичайно, далі дається «геніальний» висновок, що «IBM пропонує найширший спектр рішень BPM». Не дивно, що «правильний BPM» = IBM BPM. По секрету скажу, що цього BPM у IBM взагалі немає.

Послання «Чайникам» від нового господаря ARIS. Продавати BPM потрібно, тому не тільки вендори, але і продавці роблять книжки для «Чайників»: BPM Basics
For Dummies Software AG Special Edition

У зазначених «основи» зібрано все: адаптивні, гнучкі процеси, візуалізація та управління наскрізними процесами в реальному часі (навіть оркестровка і хореографія процесів в real-time і крос-функціональна видимість), «автоматизація — симуляція — оптимізація», зв'язок за формулою {люди, інформація, послуги, системи, процеси}.
Звичайно не забуті Безперервне вдосконалення процесу (CPI), Real-time monitoring (BAM), KPI-BSC і т. п., а також нещодавно «пришиті» до BPM: WYMIWYR і DMAIC.

Типова помилка в книжці, де сказано, що «BPM є широкою дисципліною». BPM має бути «вузька», конкретна і зрозуміла дисципліна. Тільки це дозволить зробити її практичної і повсюдно застосовується інженерною дисципліною. Винесіть суміжні області, придумайте до BPM «горища» і «підвали», складіть чіткий стек BPM (за аналогією мережевим протоколам), але не потрібно під вивіскою «broad discipline» заважати все в одну купу.
Поки ж нам підносять «занадто великий BPM, що б його можна було зрозуміти» (надто великий, що б його з'їсти).

Якщо спершу сказали, що BPM — це «інфраструктура бізнесу» (це правильно), то мабуть цього і потрібно слідувати, а не змішувати інфраструктуру з бізнесовими сутностями і не розглядати в BPM «The BPM Business Architecture».

3 Загальна класифікація BPM

3.1 Популярні погляди на класифікацію BPM

Одні кажуть, що BPM — це просто філософія менеджменту, що дозволяє сфокусувати увагу на процесах або стратегія керівництва для успішної трансформації бізнесу, інші, що це якась багатолика дисципліна: документування, то чи розробки, то впровадження, чи то ще чого, але під універсальним терміном «дисципліна управління». Треті (артисти мабуть) запевняють, що це щось, що лежить поруч з SOA і Web 2.0 і люблять згадувати про оркестровку і хореографію.

Найчастіше: BPM підноситься в «трьох особах», де бізнес-процес:
— задокументували та проаналізували (design & analysis tools);
— зімітували і промоделювали (simulation engine);
— розгорнули і виконали (execution engine).
Поруч стоїть «прислуга»: dashboard, repository і т. п., а у VIP-ложі: CPI, BSC-KPI і т. п.

Популярні, але «розкосі» погляди профі на класи BPM (напрямки і відповідні інструменти) припускають кольорову картинку з набору численних і відомих маркетингових термінів.
Показовий приклад заплутаності і не «простого і зрозумілого» BPM наведено на рис. 3.1. Погляд на BPM з KPMG
Подібних архітектур і уявлень про BPM багато, як і цій: яскравою, красивою картинці (дизайнерам – презентаторам п'ятірка), але незрозумілою.



Рис. 3.1 Погляд на BPM з KPMG

На Рис. 3.2 показана картинка з www.what-is-bpm.com, де відображено більш зрозумілий (хоч і менш «художньо») підхід до класифікації BPM — інструментарію.



Рис. 3.2 Погляд на BPM – інструментарій з what-is-bpm.com

Картинка читається приблизно так (трохи з іронією, щоб краще донести її суть):

1) від Understanding — розуміння своїх процесів («знай свій процес»), що підтримуються складанням карт процесів (Process Mapping) та інструментами документування;

2) до вдосконалення процесів — через Analysis (куди ж без аналізів?) та імітаційне моделювання (не плутати з просто «моделювання» = «документування» в контексті Understanding);

3) до автоматизації \ модернізації (так їх майже синонімами зробили) через BPMS різновиди, з інтеграцією через SOA і розробкою «прикладних гібридів і композитів»;

4) і неодмінно, — все це «постійно оптимізуючи» і реинжинеря, знову оптимизиря і знову «переосмысливавшая докорінно», тобто зациклюючись процес на безперервне – «вічне» удосконалення. Не розумію, навіщо так треба – мабуть в такому BPM «гальм немає» (забули передбачити), але в багатьох книжках саме так написано.
До того ж, у чому відмінність п. №4 від п. №2?

Невелика добавка: якщо ВСЕ ЦЕ потрібно для «невеликий тусовки» (workgroup), – то всього вищевказаного «висип потроху», а якщо для «крутого» Enterprise-Wide «багато» (вектор «Scope» показує «Масштаб»), плюс ще потрібен репозита(о)рій процесів і якесь «взаємодія процесів» (сама верхня «плюшка»).

3.2 Спрощена класифікація BPM-систем

Враховуючи різноманітність BPM-напрямків виключимо з розгляду BPM складові, які безпосередньо не відносяться до опису процесів, такі як: удосконалення (CPI), оптимізація, всіляке не чітко формалізований «управління» і т. п., а зосередимося лише на описі процесів і найпростішому їх аналізі (без «бізнес-складової»).
Тобто BPM в термінах «процесний рівень», «процес-техніка», показаними у Другій главі цього циклу.

Виділимо три напрямки:
— базовий BPM, «BPbase», в основі якого лежать:
— — формалізація БЖ, «BPdoc» та
— — вторинна обробка і аналіз формалізованих сутностей, BPana;
— симуляція БЖ, «BPsim»;
— виконання БП, «BPexe».

Завдання BPdoc — формалізувати процеси (показати образи реальних процесів у вигляді схем). BPsim — «оживити» процеси через динамічну модель процесу або відобразити характеристики процесу на статичних моделях (не опис і регламентація).

BPexe — потрібен щоб отримати виконуваний програмний код, тобто «зробити процес програмою». «Світла мрія» будь автоматизації (мрія №1), включаючи BPexe «зробити казку бувальщиною», — це коли ВСЯ логіка «зашита» у виконуваному коді і вся робота оператора ЕОМ (участь у бізнес-процесі виконавця) зведена до одного натиснення «великої червоної кнопки».



Рис. 3.3 Спрощена класифікація BPM-систем
У вихідній якості

Класифікацію пояснює наступна «танкова» аналогія:
BPdoc — зображення танка як малюнка чи креслення. У разі ескізу або начерку, виконаного мазками (імпресіонізм), зрозумілого тільки при погляді «здалеку» (з висоти пташиного польоту, high-level). У разі робочого креслення (тобто по якому можна працювати) — як комплект конструкторської документації (танк в AutoCAD): можлива будь-яка деталізація, аж до всіх розмірів і розрізів (розрізів процесу), «поворот процесу» (можна «крутити» процеси) і т. п., картинка процесу в 3D (точніше в n — мірному, площинах) і т. п. Це «конструкторська документація» на процес (в термінах ЕСКД), процесна документація «на папері», робочий проект на виріб «процес», специфікація процесу і т. п.

BPsim — зменшена модель танка з дистанційним керуванням: начебто іграшка, але «рухається і стріляє пластмасовими кульками». Такий танк схожий на справжній — всі деталі точнісінько (репліка), можна навіть масогабаритний макет виконати, але на фронт його не відправиш (тільки як помилкову мету). Інший приклад – це іграшки з «крутий фізикою» типу World of Tanks або професійні авіа\авто\танкові-симулятори. Теж — все майже як справжнє, але вхідні дані (висота, швидкість) — вигадані (розрахункові) і здоров'ю (реального процесу) не нашкодити «якщо щось піде не так».

BPexe — це вже справжній танк, отриманий з креслень (BPMN 2.0), завантажених в 3D-принтер (BPMS). Завантажуй креслення, друкуй виріб (публікуй процеси в середовищі виконання) і «на передову» (развертывай програму в промислову середовище). Друк реальних танків поки ще в майбутньому (вже недалекому), але реальне стрілецька зброя вже друкують: Еволюція 3D-друкованого зброї

Приблизно, як і в сьогоднішньому BPMS: прості речі виготовляються у виконуваних BPMS-ках (і впроваджуються), а для складних – використовують традиційні технології (класичні системи програмування, готові ERP/ECM тощо). Можливості сучасних BPMS – поки сильно обмежені, прогрес не стоїть на місці.

Термін «BPMN» можна відносити до інших «виконуваним» нотациям, включаючи оригінальні набори значків (фігур) від наших «се один» буржуйських «се два» (1С K2). Не важливо, як багато вони взяли з накреслень стандарту BPMN 2.0, як правило, суть та ж сама: «друк процесів на 3D-принтері BPMS» (якийсь Process Blueprint).

3.3 Подробиці «BPbase — Bpsim — Bpexe»

BPdoc заснований на графічному поданні формалізованих процесів (моделювання в графічних нотацій). Процес на схемах зазвичай представляється у термінах потоку робіт (workflow), правил логіки розгалуження) і потоку інформації (dataflow) та документів (docflow).

Зазвичай інструменти BPdoc визначають як Business Process Modeling (теж BPM) Tool. Але в розумінні що «modeling» це не «simulation», тобто «модель» – просто як схема зі зв'язками об'єктів що входять в неї об'єктів і зберігаються в загальному репозитарії (архіві). Зв'язність як з іншими схемами, довідниками об'єктів (процесами та іншими сутностями).

BPdoc не включає:
а) всю нормативну базу компанії або навіть повний комплект текстових регламентів, оскільки маються на увазі лише текстові та графічні «процесні вкраплення» (процесні регламенти);
б) структури, у складі (страшно вимовити) Enterprise Architecture безпосередньо не пов'язані з процесами.

У граничному випадку BPdoc є «великий» Processes Map, хоча не розумію, як без текстових описів можливо повний опис процесу. Більш точно, BPdoc — це операційна модель компанії, під якою будемо розуміти пов'язане опис процесів (функцій), посад (ролей), документів (оброблюваної інформації) та інструментів (інформаційних систем, ІВ).

Як правило, докладний опис орг-структури та ІС для цього не потрібно, а достатньо лише ієрархія (ієрархічний довідник) з об'єктами, задіяними на схемах класу «полегшений EPC». У «полегшеному EPC» з усього різноманіття EPC (Подієва ланцюжок процесів) крім «функції» і «події» обмежуються 5-6 типами об'єктів: роль, документ, інформаційна система.

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

BPM «виконуваний» (BPexe) містить як мінімум дизайнер (модуль розробки додатків) і «середовище виконання» (движок, BPM-Engine) і фактично являє собою різновид систем програмування. А саме, — напрямок «програмування без програмування» засобами візуального конструктора програм (хоча часто в BPMS потрібно додавати багато коду). Такий процес хоч і стосується BPM, але ближче до середовища програмування з графічним мовою у вигляді BPM-нотації (BPMN) і з «попередником» у вигляді схеми процесу та екранних форм. Сьогодні вендори BPMS нас переконують, що це «справжній» BPM", але це була крадіжка бренду «BPM» («лже-BPM» див. рис. 3.4).



Рис. 3.4 Підробка терміна BPM

Розробники та продажники «компіляторів нової хвилі» (BPMS, де — «графіка в код») відібрали у системотехніків (SE) бренд «BPM», а натомість кинули «кістку» — BPA.Business Process Analysis

Підміна проведена за сценарієм: «дадуть палець, руку откусим». «Здача» (без бою бренду BPM на «милість кодерам» (SWE) супроводжувалася компрометацією вихідних ідей BPM — як управлінської методології та високорівневих компонентів «Архітектури підприємства», які в програмної інженерії або взагалі не потрібні або незначні (точніше у переможців «своя EA»).
Це була ремарка до історії і філософії BPMS в контексті протиріччя «as is» vs «really is as».

В результаті вийшов «лже-BPM» з сумнівними орієнтирами на класичний BPM, т. к. BPMN 2.0, like BPMN та інші виконувані нотації поки що:

а) малоефективні для бізнес-аналізу (в порівнянні з BPA),
б) сумнівні для програмування силами бізнес-користувачів.

Часто звичайна автоматизація процесів «незвичайними» засобами розробки ЗА — «виконуваними BPMS», позиціонується як «вдалий проект BPM» (лаври «чужої перемоги»). Вже підкреслювалося: прямого зв'язку «BPM» і автоматизації — ні. Впровадження «виконується BPMS» і побудова з допомогою програми — це «типу BPM», а побудова у вбудованому BPM-редакторі (дизайнера) CRM, ECM, ERP такої ж схеми процесу в схожій або такий же нотації — не вважається впровадженням BPM. Чому? Це просто Embedded BPM. Практично всі сучасні CRM, ECM, ERP мають конструктори workflow, як мінімум «схожі на BPM». Бізнес-процеси компанії: ECM, CRM, BPM – яка різниця?

Впровадження нового додатка, зібраного в дизайнері BPMS і запущеного на BPM-движку, мало чим відрізняється від класичної автоматизації. Існує безліч систем візуального програмування і конструкторів програм (включаючи майстер інтернет-сайту і дитячий Scratch), де «програміст» може не бачити ні строчки коду, що формально теж BPMS — «no code».

Основні принципи автоматизації сучасних BPexe (BPMS) являють собою двадцятирічної давності аналог SCADA систем, використовуваних при автоматизації технологічних процесів (BPexe — адміністративних, управлінських процесів). Такий же візуальний конструктор програм, з різницею, що замість документів – електричні сигнали, а «живі виконавці» (ролі) – це засувки (виконавчі механізми в АСУТП) або датчики.

У багатьох сьогодні «вже давно немолодих» SСADA, включаючи вітчизняний TraceMode, спочатку був подібний BPMS візуальний редактор [для «програміста», який не знав програмування], графічна схема технологічного процесу, свій Business Activity Monitoring (BAM) — моніторинг, що показує в реальному часі граничні (контрольні) і реальні значення температури, тиску, швидкості, обсягу і т. п.:

Система дозволяє створювати складні АСУТП взагалі без програмування — в спеціальних графічних редакторах, використовують термінологію, звичну для інженера-технолога.

Десь вже чули щось подібне, але про «бізнес-технолога»? Візуальне проектування робочого процесу компанії (BPM) аналогічно візуального проектування технологічного процесу (АСУ ТП).

Симулятори BPM (BPsim) — у більшості випадків, — це якась проміжна категорія між BPdoc (регламентом реального БП) і BPexe (реальної програми, тобто автоматизованого БП і документованого, наприклад, через BPMN). Симулятори дозволяють «відчути» динаміку процесу (динамічне моделювання), запустити «спрощені» екземпляри процесу.

На жаль для BPsim також як і для BPdoc використовують термін «моделювання» (simulation — як імітаційне моделювання), причому моделювання бізнес-процесів» можливо як у «справжніх» BPA-BPMS (ARIS Simulation, PBexe), так і в універсальних (класичних) системах моделювання. Моделювання можливо як за допомогою графічних нотацій, визнаних BPM-спільнотою, так і у «невизнаних» або взагалі засобами неграфічних абстракцій, включаючи мови моделювання, наприклад, GPSS: Імітаційне моделювання бізнес — процесів
BPmon — засоби «моніторингу процесів».

3.4 Причини популярності BPMS або «на шляху до великої мети людства»: створення програм без програмістів
При описі процесів засобами BPdoc, BPsim, BPexe ключове слово — «графічна схема процесу». Хоча процес можна описувати не тільки квадратиками або могутністю російської мови: опис процесу літерами — він же текстовий процесний регламент.
Для формалізації процесів і подій існують спеціалізовані мови, особливо поширені в системах імітаційного моделювання, але вони скоріше придумані для програмістів, а не для аналітиків, методологів і інших «фіксаторів і хірургів бізнес-логіки від бізнесу». Навіть незважаючи на те, що деякі мови містять у своїй назві заповітне слово «бізнес-процес», наприклад, Business Process Execution Language (BPEL).

Це відноситься і до «самим-самим великим» BPM-нотациям: Абревіатура BPMN швидше розшифровується не як Business Process Execution Language, а як «Business People May Not understand», тобто«люди бізнесу можуть і не розуміти» цю нотацію (Джим Синур)

Протягом довгих років не згасає прагнення (мрія №2) — знайти простий шлях моделювання процесів безпосередньо їхніми учасниками (задіяними в процесі) без залучення BPM-фахівців «по візуалізації квадратиків і гуртків, а також виконання побудованих таким чином процесів. Звідси і сильна тяга (надія) до формату BPMS (BPexe).
На жаль, поки це залишається мрією, хоча періодично про неї згадують, наприклад, саме під цією ідеєю стартував BPMN. Але BPMN сильно програє того ж EPC для цілей фіксації та аналізу алгоритмів на рівні бізнес-користувачів (критерій інтуїтивно-зрозумілості) і «топів» і не досяг поставлених цілей.

На важко-читаність BPMN також впливає вимушена висока деталізація описуваного процесу: якщо в EPC можна за деталями відсилати в текстовий регламент, то у випадку з виконуваним BPMN доводиться «все нести з собою».
Черговий виток робиться «новим сучасним викликом BPM»: S-BPM, парадигма «subject-oriented BPM» від чергового мавра (теж німецького професора).

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

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

Більше того, є бажання забезпечити роботу отриманої програми (виконання) без участі ІТ-служби («публікувати» в «prod» по кнопці самим юзером). Як ми бачимо, реалізація концепції ще далека від ідеалу, але і прогрес також не можна заперечувати цього досить стародавньому напрямку «Програмування БЕЗ програмування»

Зазначені вище сподівання укладені в «тренди»: BPMS, «low-code», no-code" (програми з нульовим обсягом коду, можливо з'являться навіть «з негативним кодом»). В реальності все набагато простіше: «Нічого особистого, Просто маркетинг». Наприклад, не беруть нас в ряди «справжніх BPMS», т. к. наприклад, не підтримується BPMN-нотація, значить, назвемо це «low-code» (включаючи, «один сэ» і «се два»). Чи хочемо відкрити новий ринок збуту (фактично того ж самого), то першими «стрибаємо» тапки «code.net».
Та ж «один форма» (1forma.ru) і позиціонується як BPMS і як система керування класу Workflow, так і від «low-code» не відхрещується — якщо покупцеві так більше подобається.

Часто продажу робляться приблизно так:
— Купіть цього чудового щеня! (soft)
— А яких розмірів він виросте?
— А Вам потрібна велика собака? Так? Звичайно, наш щеня виросте і стане величезним псом! (BPMS)
— Ах, Немає? Вам потрібна крихітна собачка? Так Ви нас неправильно зрозуміли: наш щеня рости більше не буде — таким і залишиться («low-code» & «no-code»)! Тільки купіть його у нас!


Ключова «фішка» систем «low-code» — створення програми, шляхом перетягування потрібних функцій бібліотек функцій і побудова логіки додатка без необхідності кодування з допомогою візуального конфігуратора.

Поки сучасні BPMS не дуже дружать з «людиноподібними разрабами» (непрограмістами), тому подібно будь-яким іншим системам програмування (починаючи від Сі) вони ще потребують багато коду, а також з легкістю з «просто хаосу» роблять «автоматизований хаос». Останній ще небезпечніше.

Були й залишаються в моді (частіше мрією) «роблять код» системи (в тому числі, «no-code»), мови, нотації і інші абстракції (включаючи мови опису бізнесу, процесів і взагалі життя) для методологів бізнес-підрозділів компанії, тобто інструменти не для IT-служб і програмістів, а для пересічних «юзверя». Останні мають хоча б легко читати свої процеси з цим нотациям і абстракцій. Іноді це називається «формалізація мовою бізнесу», причому самим «Business user» (non-technical users).
Нотації і абстракції повинні бути практичними, стандартними та зрозумілими навіть непрограммистам (дитині), але дозволяти побудова моделей (опис), адекватних реально відбуваються.

Цікаво, що аналогічним шляхом розвивається напрям «програмування для дітей», наприклад, Мій досвід навчання дітей 8-10 років програмування на Scratch

BPexe (BPMN, «low code» та інше). Враховуючи, що BPexe підтримує як мінімум стадії: моделювання, імплементацію (фактичну реалізацію програми) та її розгортання, то моделі під «exe» (execution) – за фактом ЗАВЖДИ адекватні реальному процесу, причому автоматизованого. Огляд лідерів BPMS

BPana, аналіз процесів — «широке» напрямок для творчості. Прикладом тривіального аналізу може служити запит до БД: скільки і де зустрічається такий процес (об'єкт) або в яких процесах задіяно підрозділ «А» або документ «Б»? До речі, багато запити можна робити і в системах класу «рісовалка», наприклад, Visio (там також використані об'єкти і є система пошуку), а якщо до схеми процесу в Visio прив'язаний файл Excel або Access з даними процесу, то можливості по тривіального аналізу можуть бути порівнянні з «крутими» BPM, тобто BPA і BPMS (в усталеної класифікації).
У будь-якому випадку BPana є «вторинним» і вимагає «первинку» — BPdoc. При цьому, вдумливий погляд на карту процесів (BPdoc) — вже передбачає «аналіз» (BPana), тому грань іноді умовна.

3.5 Ліси, дерева, листя

Процеси мають різну деталізацію. Як мінімум: верхнього рівня і детального. Схеми (моделі) класу BPexe — все чітко, інакше програма не запрацює. Це «за визначенням», т. к. — «exe» = «execution».
Але і деталізація далеко не завжди доречна: «за деревами — лісу не видно», тому BPdoc можна розділити на два завдання (категорії): завдання опису «лісу» (процеси у «велику клітку», погляд з висоти «пташиного польоту») і досить детальних «процесів — дерев», але, як правило, ще не таких детальних, як у BPexe (BPMN), де формалізується кожна «гайка» (інакше «не злетить»). Засобами BPMN можна описувати не тільки «листя» (гайки), але і «дерева», але ніяк не «ліс».

З одного боку, за деталями (детальними процесами – «деревами» в EPC і «листям» в BPMN) втрачається загальна картина на весь процесний ландшафт підприємства (ліс). З іншого боку, описати всі процеси — дерева» (не кажучи про «листі») також складно, як і замалювати, хоча б схематично, всі дерева навіть в невеликому лісі.
На цю тему — аналогія Карти процесів з географічною картою:Скрупульозне опис бізнес-процесів — це добре чи погано?

Повний опис бізнес-процесів великої компанії — це утопія. У всякому разі, за допомогою сучасних технологій опису бізнес-процесів: що у вигляді багатосторінкових текстових регламентів, що у вигляді квадратиків і гуртків (моделей, нотацій).
У першому випадку, багатотомні талмуди будуть без зв'язків і наочного масштабування (від high-level до «відправити повідомлення по email»).
У другому, схеми EPC (BPMN, UML і т. п.) доведеться малювати дуже довго і великим складом малювальників (бізнес-моделістів\ модельєрів) і все-одно без гарантії отримати «як є в реальності» (див. фото в заголовку статті).

Навіть якщо всі процеси автоматизовані за допомогою BPMS (PBexe) і є повний комплект схем (моделей) процесів в BPMN, то для розуміння «картини» в цілому (показати «ліс») їх доведеться узагальнювати, укрупнювати, систематизувати і т. п.
Крім того, оригінальні «робочі процеси» (гранично детальні процеси) у форматі BPMN, як вже зазначалося, будуть незрозумілі більшості співробітників бізнес-підрозділів. В цілому BPbase – це наука як по опису і аналізу лісу, так і дерев. І основна нотація для BPbase – це не BPMN, а швидше EPC (в минулому IDEF). В інеті багато порівнянь EPC vs BPMN.

В цілому якщо «ліс» — високорівневі процеси — описати досить нескладно (VAD, ЕРС, але не BPMN) і цінність такої роботи найбільш висока, то детальні — «дерева» (EPC, для BPMN — не як «виконання», а лише як «ілюстрація» — колосальний обсяг роботи з вже меншою цінністю (в задачах BPA), хоча б тому що ці схеми дублюють (повинні) текст інструкцій (регламентів).

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

Зовні у процесу моделювання BPdoc (EPC) та BPexe (BPMN) багато спільного: візуально відмінностей мало – майже такі ж квадратики і кружечки. Багато в чому це і дозволило запозичувати (прямим текстом — вкрасти) розкручений термін «BPM». Хоча BPexe частково вирішує ту ж задачу – документування процесу (на рис. 3.3 результат «побічний», BPdoc'), але все ж у них принципово різні призначення і «власна філософія».
Першим потрібно показати людині як працює приблизно управлінський процес («в цілому», а багато деталей – дивись у тексті регламенту, тому в ньому і «багато букф»).
Другим — дати чітку інструкцію компілятору (нехай навіть і через графічні образи) «що робити» (а багато деталей, все одно присутні тільки в коді).

З часом грань між BPexe (BPMS) і BPdoc (BPA) повинна поступово стиратися. Можливо, з сучасного BPexe, який поки все-таки «для програміста», виділено окремий клас систем, який буде для «людини»: для бізнес-аналітика, який не знає взагалі «страшних слів зі світу ІТ». Іншими словами: BPexe стане штатним інструментом бізнес-фахівця, а не програміста (ІТ-служби).
Сподіваюся, що така ж доля чекатиме і BPdoc: не потрібно буде мати штат «модельєрів» (або наймати EPC-консультантів), які малюють схеми процесів, а моделі процесів будуть генеруватися з штатних регламентів, можливо, навіть непомітно для користувача.

У зовсім далекому майбутньому: автоматично – прямо з самого процесу за аналогією: топокарти з супутниковим знімкам («аерофотозйомка» процесів компанії) або розкриття мереж (OpenView Network Node Manager тощо). Хоча б навчитися рахувати число процесів компанії, на кшталт — овець через супутники NASA, як у відомій притчі про консультантів («Близько стада овець приземляється вертоліт...»).

Формалізація процесів (BPdoc) має різні завдання: від тривіального регламентування окремих операцій в графічній формі до вибудовування Enterprise Processes Architecture. Іноді BPdoc проводиться під подальшу автоматизацію формалізованих процесів, тобто є першою стадією Business process automation (не плутати з «BPA», де «А» = analysis). Як підкреслювалося: опис процесів існує саме по собі, незалежно — «автоматизований процес» або ручний і «чи буде він автоматизований» чи ні.

При автоматизації за схемами» (BPdoc), підготовленим в EPC (IDEF тощо) цей підхід протиставляється підходу «одним пострілом двох зайців» (PBexe), коли схеми під автоматизацію розробляються вже споконвічно виконуваних нотаціях BPMN і подібних, тобто «execution». Вибір між BPA (EPC) або BPE (BP execution) на користь останнього (BPMN) — не настільки очевидний, як може здатися на перший погляд: складність сприйняття «бізнесами» (фахівцями не зі світу ІТ) виконуваної нотації (BPMN та подібних), недосконалість самої технології (інструментів BPMS).

BP-BP (Business Process — Best Practice) — це не книжки типу BPM CBOK, а практичні шаблони і прототипи (у т. ч. просто приклади для тиражування, типові набори процесів з детальним описом), референтні моделі з конкретної області, класифікатори процесів (наприклад, APQC PCF Process Classification Framework) і т. п. В цілому це основа, на якій може (має) бути побудовано ефективне виробництво товарів (послуг), а не конвеєр спекуляцій. Це окрема глобальна тема обговорень про майбутнє BPM (добре забутим минулому): Global BPM.

3.6 Близькі поняття

Стосовно до BPdoc, BPsim, BPexe можна віднести багато термінів «Process [X]», де Х=
— Model / Repository & Design / Documentation (як-то процеси ж потрібно формалізовивать і куди їх складати). Не так важливо розробляється процес на майбутнє (to be) або документується існуючий (as is). Іноді це обзивають Process Understanding з серії – «знай свій процес» (порівняй: «знай свого клієнта»);
— Portal / Publisher (публікація процесів, спільна робота, поділися своїми процесами» тощо);

Для BPdoc часто використовується «Process Map»/ «Process Mapping» (Картування виробничого процесу), виражений або ієрархічним деревом або графікою. Далі Process Map може бути використаний як підкладка з процесів», на яку наносять якісь метрики. Якщо на підкладку наносити дані ВАМ, то вийде мозаїка індикаторів на тлі «процесної карти». Близькі назви Process Dashboard, BI Dashboard, Process Measurement та інші.

BPana — до нього можуть «приєднатися» багато з Business Process \ Performance Improvement, усього «самого безперервного» улучшайзинга і просто реінжинірингу. Але це знаходиться вже за межами «чистої BPM».

3.7 За бортом «чистого BPM»

Щоб «не ламати списи»: «BPM це чи ні», виділяємо окремою категорією BPMextra (extraordinary, «незвичайні»), і «зіллємо» туди все, що не увійшло до розуміння «чистого BPM» (див. рисунок 3.3) і BPexe.
Перший набір претендентів — це більшість термінів (модних «фішок») з «Hype Cycle for BPM» («крива обману»)

Другий — все що «приклеїлося» до BPM(s) через ІТ («хвости»), включаючи різнорідні «BPM-интегрейшены» типу integration-centric BPM, орієнтовані на інтеграцію системи управління бізнес — процесами

У категорію BPextra включимо малозрозумілі і «зіркові» терміни та процеси під них: всі BPM-оточення, пов'язане зі «стратегією» (Business Strategy), «управління управлінням» («керівництво», Governance Mgmt., Process Governance), «відстеженням стратегічних цілей розвитку бізнесу», «общекорпоративными правилами управління», в тому числі, бізнес-процесами. Згідно термінології Другої глави цього циклу — це «Business-ацетон» («голови» при процесі дистиляції BPM).

Хто не може відірвати від BPM все «най-най» прогресивне і приймає це як BPM, може включати це в BPextra: Кайзены, загальне управління якістю (TQM, СМК), «самі» ощадливі виробництва Lean, «все сігми» (Six Sigma та сім сигма, т. е. які + Lean), та інші «досконалі» технології загального вдосконалення, в тому числі, вдосконалення бізнес-процесів, але які не засновані на документуванні, регламентації та стандартизації конкретних бізнес-процесів компанії.
Класифікацію методологій «трансформації», «вдосконалення» (найпередовішого «улучшайзинга»), «Тойота» і т. п. див. Методологія управління бізнес-процесами (BPM)

До «самого-самого» прогресивному і «like BPM» також домішують:
— Business-driven development, це така методологія, в якій розробляються ІТ-рішення, що безпосередньо відповідають вимогам бізнесу (мабуть всі інші програми, побудовані поза BDD, цього не відповідають і, отже, марні);

— x_BOK-і, особливо, де «х» включає заповітне слово «Business»:
— — BIZBOK (Guide to the Business Archіtecture Body of Knowledge)
Зверніть увагу, що там багато чого — як з BPM, так і EA;
— — REBOK (Requirements Engineering Body Of Knowledge), інженерія вимог, там такі ж Business Strategy, Business Case, Business Rule, Business Process і ін),
— — BABOK iiba.ru/category/babok (Business Analysis Body of Knowledge), теж інженерія вимог, але позиціонується як бізнес-аналіз «з метою виявлення вимог»), до речі, на зазначеному сайті пристойна бібліотека, в тому числі, по розділу BPM;

— Service-oriented modeling + «х», де
«x» = «and architecture», тоді це вже SOMA,
«x» = «framework», тоді SOMF, є service-oriented analysis and design (SOAD), є Service-oriented modeling sub-ontology (SOMsO) і звичайно BPM sub-ontology (BPMsO) і багато чого подібного в книжках подібних: «Service-Oriented Computing ICSOC/ServiceWave 2009 Workshops»;

— і багато-багато подібного: іноді створюється враження, що будь-яку технологію можна підвести під «багатогранний» (багатоликий) BPM. До BPextra («like BPM») віднесемо «архітектурні картинки» зі світу ЕА і все інше «правильне і схоже» на BPM, але що не увійшло до «pure BPM» (Natural BPM). Наводити порядок у самому BPextra будемо в інший раз і мабуть вже поза площиною (layer) BPM.

Ваш,
bipiem
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.