Спасибо за ответы.

На самом деле, моделей в этой схеме на одну больше — потому что работающий код это ведь тоже модель. Меня интересует, как современные BPM-системы преодолевают семантический разрыв между графической моделью и той, что исполняется. Понятия, которыми оперирует программист, очень отличаются от понятий, заложенных в любую нотацию. Это правильно, потому что каждый должен работать с теми понятиями, которые адекватны его задачам. Но разрыв никуда не девается.

Самый простой способ - посадить программиста, чтоб он сам преодолел эту семантическую разницу, вник в тонкости предметной области и реализовал работающий код в силу своего понимания. Можно заранее определить семантику каких-то элементов, чтобы они автоматически исполнялись, но это лишает гибкости и подходит только очень узкоспециализированным областям с устоявшимися процессами. А хотелось бы преодолевать этот разрыв автоматически.

Не октаз от услуг программиста. А такая схема, где программист реализует то, в чём он специалист (функции, обращения, модули), а не сложную финансовую или иную логику, о которой он мало знает (только из схемы и разговоров с аналитиками, руководителями или специалистами других областей). А чтобы специалисты, в свою очередь, работали исключительно с теми понятиями, которые нужны им и могли не думать о том, что там есть переменная, которую надо хранить и передавать, например.

Цель BPM не в том, чтобы полностью избавиться от программиста. Это невозможно и не нужно. Цель в том, чтобы а) не автоматизировать не до конца понятые или заведомо неоптимальные процессы, б) иметь возможность вносить в процесс определенного вида изменения (не любые!) без участия программиста.

Системы, которые позволяют если не достичь, то приблизиться к этой цели, конечно есть. Но они очень сильно различаются по используемым технологиям, по сложности, по функциональности, по цене. Если Вас интересуют топовые системы, то я могу порекомендовать Oracle, Lombardi. Доступные по цене - Unify, ELMA. Условно-бесплатные JBPM, Runa WFE.

Для компании какого масштаба нужна система, для каких задач?

Есть ли на рынке продукты, которые позволяют автоматически получать работающий код на основе диаграммы без участия программиста? То есть, программсит работает на начальном этапе и реализует какие-то моудли, но чтоб дальше он уже не был нужен для создания нового процесса или модернизации уже существующего?

BPMN - это нотация, она не может предоставлять какие-то инструменты. Инструмент это BPMS - Business Process Management Suite, или BPM-система.

“Программист садится и начинает писать код” - это традиционный подход, существующий десятки лет. Можно при этом рисовать схему в BPMN вместо IDEF, но к BPM это не будет иметь отношения. Не будет быстрого замкнутого цикла моделирование-исполнение-анализ-усовершенствование.

В случае BPM/BPMS есть два варианта:
1) автоматическая генерация кода, например из BPMN в BPEL
2) непосредственно исполняемая диаграмма

Эти два подхода подробно разбирает Кейт Свенсон, настоятельно рекомендую его статью: http://bpms.ru/library/articles/preserving-vs-transforming/index.html Мне лично больше импонирует второй подход.

But I came to the conclusion some time ago that introducing process thinking is loosing your own time. BPM is a different paradigm really. And one would only switch his paradigm if he was looking for certain ideas himself.

So I make presentations on conferences and public seminars but never come to an existing customer to say “look, I want to share some new ideas with you, it’s about business processes”. I only meet with an organization if they alread got an interest in business processes and/or BPM. The good news is that more and more business people do become interested in process management every day.

I like your response.. definitely agree with you. I guess we are “on the same page”. But the challenge is to introduce
these perspectives and the relevant methodologies to organizations. Seems like the lack of “process orientation” or “process-thinking” is still a “global problem”.
It amazes me to encounter managers and decision makers that still don’t know what is really a “business process”.
BPM is also considered a “UFO”…
I have just uploaded to Slideshare a relevant presentation with guidelines by Alec Sharp which I find to be very helpful and practical..
http://www.slideshare.net/dafnal/alec-sharp-process-traction-presentation/

Thanks,

Dafna

Thank you for your input.

You raised an interesting set of questions: does an organization have an architecture if they even don’t have an idea about what is it? Is it correct to say that every organization has business processes - even if what they have are only chaotic, ad-hoc, non-repeatable and non-documented ones? Should we call “level 0″ processes (according to the process maturity model) - processes?

It reminds me the old Russian army joke:
Soldier: sergeant, are crocodiles able to fly?
Sergeant: of course no!
Soldier: but our colonel has said they are?
Sergeant: really? OK, crocodiles can fly but only at very-very low altitude!

“Naturally-grown” architectures and business processes are like “low-flying crocodiles” for me.

As for uniquieness and standartization, the ultimate (and ideal) goal of process management probably should be:
1) we identify and divide all our processes to those we want to excel on and those we don’t
2) we utilize BPM on the former to develop unique processes that will outperform our competitors and use best practices and packaged solutions for the latter
3) at the end, we outsource the processes we don’t care much about and become outsourcesers for the processes that we execute better than others