ViPRosно у меня базовые процессы типизированы (не только по способу коннекта, но и имеют числовую семантику), их не так много что бы покрыть многообразие процессов (ну, допустим предприятия)Можно задать много разных вопросов по этому поводу "где", "как" и т.д., но самый главный вопрос "зачем?". Зачем они типизированы, если по жизни с трудом поддаются типизации? Поскольку в BPM-системах процессы НЕ типизированы, а являются просто процессами, можно подразумевать под ними всё что угодно и настраивать любые виды взаимодействий.

Ну, по поводу "не типизированы" это я немного утрировал, они там тоже типизированы, но типизация в них не жесткая, а произвольно настраиваемая. Например, в BizAgi есть так называемые "категории". Категории бизнес-процессов имеют иерархическую структуру, которая по умолчанию выстраивается в соответствии с названиями процессов/подпроцессов и их структурой вложенности друг в друга. Однако, дерево категорий можно настроить и вручную. Можно иметь, например, обобщенную категорию "заказ", в которую входит два совершенно разных процесса (с разными схемами) "заказ продукции" и "заказ на субподрядные работы" (например, для производственного предприятия это заказ на выполнение производственным предприятием некоторых производственных операций для другого предприятия из давальческого сырья). Однако же, в BizAgi тот, кто настраивает бизнес-процессы, сам выбирает структуру категорий и процессов. Можно пытаться жестко типизировать процессы по своему собственному усмотрению, но этим самым вы обрекаете потенциальных клиентов на получение "железобетонного" ИТ-инструмента, который заставляет бизнес прогибаться под себя, и не умеет сам прогибаться под бизнес.

ViPRosесть среда моделирования процессов из типовых-базовых процессовСейчас в инете вы можете найти массу шаблонов БП в нотации BPMN. Многие BPM-системы включают в комплект поставки шаблонные бизнес-процессы. Но это не более чем БД "Борей" в поставке MS Access. Вы имеете возможность разработать все процессы с нуля. И лучше всего их разрабатывать с нуля, потому что в разных бизнесах разные части процессов имеют разный ритм. Где-то какие-то операции выполняются в ритме базового процесса, и поэтому могут быть включены непосредственно в него, а где-то выполняются асинхронно, и поэтому должны быть выделены в отдельный процесс, при этом между базовым и вспомогательным процессом настраивается нечто вроде "слабого взаимодействия". Но каждый из них получает независимость в плане свое ритма. Почитайте вот статью Анатолия Белайчука "Вульгарное представление о кросс-функциональных бизнес-процессах" , в ней более детально раскрывается смысл того, о чем я говорю. Даже такая, казалось бы, примитивная вещь как сбор кадровой службой резюме кандидатов на вакансии обычно делается асинхронно другой операции - их рассмотрению, оценке и принятию решения о том, кого нужно пригласить (обычно решение принимается после того как накоплено некоторое количество резюме, а не по каждому отдельно). Поэтому даже внутри одной только кадровой службы могут жить несколько процессов с разными ритмами, а не один сквозной.

ViPRosесть движок создающий оптимальный граф процессов
есть движок запускалака
есть отслеживание и онлайн корректировка графа запущщенногоПохоже, ты творишь BPMS... :)

ViPRosно визулизация на топорном уровне, моделирование нормативных процесс топорная (автомоделирование нормальное, но опять же визуализация на ганте не есть гуд)Смотри в сторону BPMN. Диаграммы ганта - производные.

ViPRosвощем я испугался что именно БизАги дополнил нотацию дополнительной процессной количественной семантикой.
А ты (еще раз спасибо) успокоил меня.А ведь он дополнил. Так что ты рано успокоился. :)

ViPRosв БПМН нет понятие моделиПонятие модели - есть. Есть модель бизнес-процессов. К сожалению, только потока управления. Однако, с помощью свойств и модели данных выстраиваются и другие аспекты.

ViPRosцелостности моделиВ BizAgi отслеживается целостность модели следующим образом:
1) Если поток управления в модели где-либо обрывается, то вы получите предупреждение6 при попытке сохранить шаблон БП или при нажатии на кнопку Validation.
2) Если User Task не имеет настроенной WEB-формы или Script Task не имеет скрипта, то вы получите предупреждение при сохранении проекта. А еще на них будут визуализированы восклицательные знаки на соответсвтующих шагах визарда.
3) Если не настроены бизнес-правила для участков схемы, для которых они в обязательном порядке должны быть настроены, то BizAgi отобразит эти участки и вытрясет из вас душу, пока вы их не заведете.

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

ViPRosмодельных ограничений (если я правильно помню)Ппппереведи... :)
Не уверен, что правильно понял. Я полагаю, что модельные ограничения имеют значение на фазе выбора, пользоваться ею или нет. Когда же решение использовать модель принято и модель де-факто используется, то они уже не имеют значения. Модельные ограничения не могут быть включены в саму модель.

ViPRosэто система коннектов, слабая одноаспектная сеть а аспектов многоОстальные аспекты привязываются к потоку управления посредством структуры данных, привязываемой к свойства процесса и отдельным действиям в этом процессе.

ViPRos90% процессов вычислимы и граф процессов можно сформировать автоматически из базовых примитивов с учетом модельных ограниченийНе уверен, что правильно понял. Но если речь идет об автоматической генерации потока управления в зависимости от задаваемых кнопочно-флажочных параметров, то мне такая идея не очень нравится. Тот, кто настраивает "как должно быть" в зависимости от кнопочек и флажочков, наверняка ошибется или что-нибудь забудет предусмотреть. Бизнес-процесс должен просто выкладываться из примитивов, наполнение которых тоже должно выкладываться из более элементарных действий. Я полагаю, что бизнес-заказчик имеет сам право решать, что ему нужно и в каком виде.

gust777Garya, могли бы посоветовать литературу, которая могла бы помочь при разработки приложения в BPMsuite кроме непосредственно мануалов этих систем?Литература на русском языке мне, к сожалению, не известна. Информация есть в интернете (например, на сайтах www.bpms.ru и www.mainthing.ru). Можно также пройти платные курсы на www.bpmntraining.ru

gust777А то я многие термины не понимаю, распаралеливание и прочее.Спрашивайте, постараюсь ответить. :)

Самое главное и первое в этой терминологии, что нужно понимать - это отличие "шаблона БП" от "экземпляра БП". Шаблон БП - это нарисованная схема (некоторая ее конкретная редакция). Шаблон может иметь название, например, "обработка заказов клиентов". А "экземпляр БП" - это уже конкретный заказ, который обрабатывается по данной схеме. По одной схеме может одновременно обрабатываться множество разных заказов, но каждый из них является отдельным экземпляром БП.

Экземпляр процесса создается при каждом старте этого процесса. Стартовать его можно по разному - по событию автоматически или вручную сотрудником, которому предоставлено право его стартовать через WEB-портал. Если процесс стартует вручную, то при старте процесса открывается заранее настроенная WEB-форма, которую инициатор заполняет некими начальными параметрами поступившего заказа.

В процессе обработки заказа управление передается от одного шага процесса к другому по линиям потока управления. Наиболее удобно представить, что по схеме (шаблону) БП двигается "фишка" или "токен". Каждый процесс стартует образованием в точке "Start" одного нового токена, который начинает двигаться по схеме процесса. Далее он может размножиться на несколько токенов (при распараллеливании), пойти по одним веткам или другим в зависимости от некоторых условий, пройти по нескольку раз через некоторые участки схемы (если в схеме присутствуют циклы). Но каждый токен, даже если их несколько движется одновременно, привязан к конкретному шаблону БП, к версии этого шаблона и к экземпляру процесса. Логикой БП может быть, например, определено "пристреливание" всех токенов одного экземпляра БП при достижении одним из них некоторых критических точек.

По поводу распараллеливания... Представьте, что вы имеете некий процесс согласования договора, в котором бумажный документ "проект договора" последовательно проходит через несколько подразделений с прикрепленным к нему листом согласования. Его согласовывает служба безопасности, юристы, финансисты(экономисты), бухгалтерия. Пока документ пройдет все подразделения и ляжет на подпись гендиру, проходит слишком много времени. Такой процесс можно "распараллелить". Это стандартный прием для систем автоматизации документооборота и BPMS. Если согласование осуществляется в электронной форме, а не в бумажной, его проще реализовать. Проект договора поступает одновременно во все подразделения (а не последовательно в одно за другим). Если никто не внес в документ никаких правок и все его согласовали, то на подпись гендиру он поступает сразу после того, как в одной точке сойдутся согласования всех этих подразделений. Если правки были, то логикой процесса может быть определено, что делать дальше. Может, например, сам автор правки определять, требуется ли ознакомить с его правкой других участников и кого именно. Либо в точке схождения потоков из разных подразделений некое ответственное лицо производит объединение всех правок, после чего скорректированный документ отправляется на повторное согласование всеми подразделениями, но уже без обязательного перечитывания всего текста, поскольку в его тексте правки и их авторы выделены (например, цветом). Когда работа над документом производится параллельно несколькими согласующими подразделениями, общий срок согласования договора может сократиться в несколько раз. Такой прием и называют "распараллеливанием" потока управления, когда одно управляющее воздействие, "токен" (маркер экземпляра бизнес-процесса) размножается на несколько "токенов", и эти несколько токенов движутся одновременно по разным веткам схемы БП. Впоследствии они опять могут слиться в один поток, или дойти до завершающей фазы каждый своим путем.

Обычное распараллеливание, приводящее к превращению одного токена в несколько токенов внутри одного экземпляра процесса производится развилкой (gate) вида "И", либо развилкой "включающее или". Такие развилки и предназначены для размножения токенов (распараллеливания), а также для соединения нескольких токенов одного экземпляра процесса в один токен. Для направления единственного токена по одному из нескольких путей используется развилка "исключающее или".

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

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

gust777По Bizagi нравится, но за пользователей все же придется платить? В частности если большое кол-во поставщиков (100шт) имеют доступ к ней, то получается 4000 $ в месяц как минимум... Или есть бесплатный вариант? :)Я давал информацию по Express Edition (до 100 пользователей). Там есть и Enterprice Edition. Сравнение Express Edition и двух вариантов Enterprice Edition приведено здесь .

Нужно не забывать, что каждый пользователь BPM-системы имеет индивидуальный вход в WEB-портал этой BPM-системы. Если Вы хотите каждому внешнему контрагенту предоставить возможность заходить непосредственно в WEB-портал BPM-системы и смотреть, какие подвижки происходят с их индивидуальными заказами или заявками, отдельно от заказов и заявок других контрагентов, тогда да, для каждого отдельно нужно приобретать лиценцию (ведь у каждого будет отдельный логин и отдельный вход в портал).

Однако, тут возможны и варианты. Можно предоставить вход в портал с правами только создания новых экземпляров процесса, но без возможности просмотра. Тогда можно дать один логин нескольким внешним контрагентам.

Возможен еще один вариант. Если WEB-доступ используется только для оформления заявки и более ни для чего, то можно реализовать WEB-службу, которая будет передавать BPM-системе с WEB-сайта уже сформированные заявки. Для входа на WEB-сайт используется одна авторизация, никак не связанная с авторизацией в BPM, а для связки WEB-сайта и BPM используется одна учетная запись, которой оказывается достаточно (то есть, может оказаться достаточно бесплатной версии, которая может работать с 10-ю пользователями).

iscrafm, если ты говоришь про реализацию WEB-интерфейса для связи с внешними контрагентами, то конкретно в случае с BizAgi за каждый новый логин нужно платить. В принципе, если взять Enterprice Edition на большое количество соединений, то можно попытаться договориться с вендором, чтобы лицензий дали ну очень много, с большим-большим запасом, но в какую копеечку это влетит, я предположить не берусь.

В общем-то, это не столько вопрос функциональности, сколько вопрос лицензирования и ценообразования на подобные продукты. Вполне возможно, что та же BizAgi, если к ней будут обращаться с подобными вопросами, разработает еще одну схему лицензирования "на сервер" с неограниченным числом пользователей.

Я еще не успел посмотреть бесплатную BPM-систему. Если там всё так же живописно как в BizAgi, то, может быть, имеет смысл использовать ее, чтобы сэкономить деньги.

iscrafm,

Я ведь и не претендую на роль авторитета, если что... :)

А вот буквально на днях завершился саммит , проводимый Gartner как раз по теме BPMS. Если кому интересно, можете посмотреть и послушать, что называется, из первых уст.

Garyagust777А не пробовали ли ВЫ processmaker ?Если это вопрос ко мне, то нет, не пробовал. Но с удовольствием попробую, спасибо за наводку.Поглядел на ютубе видеоролики, и чтой-то не сильно впечатлился...

Кроме того, в диаграмме Gartner processmaker отсутствует, что несколько настораживает.

АБBizAgi о вас уже позаботился: у них есть специальный пользователь "initiator". Он может участвовать только в процессах, инициированных им самим - как раз подходит для ситуации с внешними поставщиками.А можно подробнее?
Пошуршал поиском на wiki.bizagi.com по слову "initiator" - ничего не нашел. :(
Если внешних контрагентов - тысячи, а лицензий приобретено только на 100 пользователей, BizAgi даст ввести 10000 пользователей в список пользователей? Если даст ввести только 100, то как она определит, "who is who"?

АБПокупаешь две лицензии: одну, положим, на 50 полных пользователей ($5000) и одну на 1000 инициаторов ($4000). Ну или годовую подписку, соответственно за $2000 и $1600. Регистрируешь полученные ключи. При регистрации очередного пользователя указываешь кто он таков.Правильно ли я понял, что полная лицензия на одного инициатора стоит 4$, а годовая подписка 1.6$?

И еще можно подробнее рассказать, в чем отличие лицензии на инициатора от лицензии на полного пользователя? Догадываюсь, что инициатор не имеет права править шаблон БП. А есть еще какие-то ограничения? Я к тому клоню, может ли быть инициатором внутренний пользователь, а не внешний контрагент? И если да, то чего он не сможет?