iscrafmубрали из структуры предприятия юридический департамент, а запущенные на подпись договоры продолжают стучаться в закрытые двери. Оригинально! Garya, Вы сами лично это проделывали или просто размашляете на тему версионности и пытаетесь себе доказать, что это круто.Зачем же утрировать? Убирается не обязательно департамент (хотя и такое бывает, но гораздо режже). Убирается ОПЕРАЦИЯ БП . Например, согласование лицом, которое по сути никак не влияет на достижение цели БП, а лишь увеличивает время его выполнения. А теперь представьте, что на подпись этому лицу направлено 100 документов. Из схемы БП операция согласования этим лицом исключена . Что будет с электронными документами, которые направлены на согласование, если отсутствует поддержка версионности схемы БП? Вопрос, в общем, риторический, потому что толком ответить на него никто не сможет - всё зависит от особенностей конкретной реализации.

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

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

В третьих произойдет фатальная ошибка с выпадением системы в осадок.

В четвертых... в сто сорок четвертых... уууу, спать захотелось... :)

iscrafm WJВерсионность нужна, и тут спорить бессысленно.
Ну раз Вы сказали, значит конечно нужна! Пример привести только никто не может :)Я привел, жду возражений... :)

WJСистема оперирует "карточкой документа", в которой собирается вся информация по документу. Тут у меня непонятки. Если, как Вы предлагаете, на каждый чих создавать документ, карточку этого документа, хранить это все в базе - через какое-то время больша-а-ая помойка получится.:)
"Карточка документа" - это и есть набор его атрибутов, систематизированное описание, шаблон документа. Все документы одного вида сохраняются с масивом атрибутов, соответствующих отдельно взятому экземпляру. У каждого экземпляра имеется история модификации - так что даже у одного экземпляра могут быть разные значения одного и того же документа на разных фазах его "истории". Шаблонов может быть множество, под каждый из них множество экземпляров, под каждый экземпляр множество версий. Да, получается "больша-а-ая помойка". Она называется "хранилище". :)
В некоторых ECM еще и у собственно шаблона документа поддерживается версионность (то есть, может изменяться не толлко содержание, но и структура документа одного и того же вида).

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

WJДальше: для того, чтобы обратиться к внешним данным, нужно настраивать специальные шлюзы и совершать еще какие-то магические действия (я не придираюсь, т.к. в принципе возможность есть - работайте, товарищи). Вопрос вот в чем: в одну таблицу из разных систем данные можно вывести? А потом модифицировать и разложить в разные (возможно другие) места? Так, чтобы для пользователя это выглядело так, как он работал бы с одной таблицей.Я не являюсь уж очень большим специалистом в этой области. Я просто делюсь своими впечатлениями, только и всего... :) Если документ составлен в MS Word, например, то его можно внедрить (как embeded object) в систему, а можно сделать тривиальную гиперссылку (linked object) на файл, расположенный, например, на файловом сервере, или на WEB-ресурсе... Ну, это стандартная фича, которая существует во многих продуктах, в том числе продуктах MS Office. Можно сделать нетривиальную ссылку, "выцепляющую" документ из некоторого приложения, где он хранится в некотором внутреннем формате, но для таких вещей уже действительно требуется привлечение IT-специалиста.

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

WJВы действительно считаете, что ECM-система - это лучшее место для хранения справочников? И потом к этим справочникам лазить из всех "заинтересованных" в нем систем? ПМСМ, это изврат. Или имеется в виду, что ECM заменит собой все?Подумал над этим вопросом... Пожалуй, однозначно на него ответить сложно. Обычно в учетных или производственных системах имеется своя система справочников/словарей. Лишние конфликты репликации, наверное, никому не нужны. И при интеграции с подобными системами, соглашусь с Вами, лучше, скорее всего, пользоваться справочниками этих систем.

Но могут быть особые случаи... Например, в подобной системе можно попытаться реализовать БП системы бюджетирования, либо имитировать (даже смоделировать) CRM-систему. Для функционирования БП в таком случае нужны классификаторы, которые появились именно в связи с появлением нового описания БП. Например, мы регистрируем поступающий заказ, а наш маркетолог по каким-то собственным известным лишь ему соображениям попросил нас решистрировать пристрастия обратившегося, задав ему определенный перечень вопросов. Где хранить этот перечень? "Прикручивать" к учетной системе? Зачем?

WJВерсионность нужна, и тут спорить бессысленно. Во-первых, это тот случай, о котором писал Garya: шаблон процесса меняется. Что происходит с уже запущенными экземплярами процесса? Они продолжают работать по старому шаблону или уже по новому? В разных BPMS разное поведение. В одних уже запущенные процессы выполняются по старому шаблону, а вновь запущенные - по новому. В других можно менять правила и для уже запущенных процессов. Я не понимаю только, из чего сделан вывод, что в BPM этого нет? У Software AG на конференции в Открытых системах этому целый доклад был посвящен.В полноценных BPM-системах она как раз не просто есть, а, я считаю, обязана быть. Именно поэтому EAI я считаю не совсем полноценными BPM, потому как в них версионность схемы не поддерживается.

iscrafmок, Garya. Правда не вижу разницы между исключением из схемы БД департамента и человека :)
Я в таком случае просто делаю FORWARD с исключаемого адреса на следующий. Т.е. все что было назначено указанной личности переходит на следующий этап. Но не в новой версии, а и в тех, что уже запущены. Иначе какой смысл такого исключения. Новые документы пойдут ускоренным темпом, а запущенная сотня так и будет висеть.Гхм... Дело в том, что изменение БП может быть очень разным. Могут измениться маршуты, может измениться степень детализации, исключена может быть не одна операция, а множество (целые цепочки), могут быть изменены условия... А Вы как-то просто свели всё к "сделаю вот это". Нужно проанализировать, какие документы где могут "подвиснуть", в каких могут измениться условия их прохождения в каких еще бог весть что... Не нужно также забывать, что новая редакция схемы БП запускается в реальную работу не после каждой элементарной правки (в таком случае схема БП может оказаться в отдельные моменты времени утратившей целостность), а после коплекса правок , приводящих схему в некоторый законченный вид. Пока бизнес-аналитик этим занимается, он сосредоточен на оптимальности и полноте новой версии схемы. Когда новая схема получена, не всегда однозначно можно понять, какова процедура "плавного перехода" со старой схемы на новую. Может статься, что придумать таковую окажется очень непросто. И у меня есть большие сомнения, что разбираться в этом вопросе захочет именно бизнес-аналитик. А каждый раз дергать IT-шника тоже не есть хорошо.
Да, в каждой конкретной ситуации без поддержки версионности схемы БП каким-нибудь способом непременно возможно выкрутиться... Но спрашивается, зачем выкручиваться , если можно обойтись без выкручивания. Не из любви же к самоистязанию? :)

Сахават Юсифов Garya Именно поэтому EAI я считаю не совсем полноценными BPM, потому как в них версионность схемы не поддерживается.

А Вы случайно не знаете почему???
Почему вообще с версионностью туго везде?Извините, далеко не "везде", а как раз лиш местами... :) Основная масса "исконных" BPM-систем и все (целые две штуки! :) ) известные мне ECM версионность схемы БП поддерживают.

Почему не поддерживают EAI? Потому что придумывались они в те времена, когда BPM-систем как класса еще не существовало. И ставилась в них задача просто иметь возможность быстро и удобно один раз нарисовать алгоритм прохождения информации в расчете на то, что этот алгоритм особо часто изменяться не будет.

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

iscrafmGarya, обратите внимание, что у меня не вызывает сомнений необходимость разработки нескольких версий БП. Я сейчас говорю только об необходимости и оправданности одновременной работы нескольких версий.Необходимость требуется дабы обеспечитб непрерывность бизнеса.

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

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

Сахават ЮсифовЗато Андрей теперь полностью разобрался и не делает рекламу. :)Сахават, я никогда не делал рекламу. Я всегда говорю то, что думаю, хотя в разные моменты времени думать могу немного по-разному. Но говорю, как правило, искренне. :)
В отличие от вендоров или их представителей, я не расчитываю ни на какие преференции за высказывание того или иного мнения... :)

WJВот-вот, давайте тут уточним: ECM оперирует атрибутами документа ? Т.е. структурируется информация относительно документа? В BPM есть атрибуты процесса .Действительно, давайте разберемся с этим подробнее. Что такое, по-сути, БП? Грубо говоря, это "алгоритм действий". Что такое "экземпляр БП"? Это уникальный процесс, как правило, идентифицируемый (отличающийся уникальными атрибутами) от других аналогичных процессов, фактически исполняющийся или уже выполненный. Когда возникает экземпляр БП? Или, говоря другими словами, что его порождает ? Как правило, некоторое внешнее воздействие, которое во всех приходящих мне в голову ситуациях можно интерпретировать как "электронный документ". Фактически схема БП превращается в обработчик события "появление нового документа вида NNN". Если Вы сможете привести пример, когда такая интерпретация не подходит, с интересом его изучу (я такой пример придумать не смог). Таким образом, экземпляр БП привязывается к некоторому "порождающему документу". Именно такая концепция используется в ECM.
Далее, что с мониторингом? В обеих ECM-системах, с которыми я разбирался, он есть. На этом месте хочу остановиться особо. В разных системах эта "фича" решается обычно одним из двух способов. В одних мониторить выполнение БП можно просматривая экземпляр БП в графическом виде, непосредственно наблюдая схему БП и выделенную цветом трассу фактического прохождения операций БП. Это очень удобно для зрительного восприятия. В других системах мониторинг ведется с помощью разнообразных табличных форм. Это гораздо менее удобно для зрительного возмприятия, но более удобно для анализа (можно накладывать фильтры по многим экземплярам, сортировки анализировать статистику и т.д. и т.п.). В системах с визуальным отображениям схемы тоже можно анализировать статистику, но возможности обычно несколько беднее. Разумеется, и к тем и к этим системам можно "прикрутить" внешние OLAP-анализаторы, статистические пакеты (Minitab, Statistica и т.п.)... Но хочу сразу поделиться впечатлениями. Если внешний OLAP еще более-менее удобен, то внешний пакет статистического анализа - это самоубийство. Ни один здравомыслящий человек не будет возиться и разбираться во всех нюансах их взаимодействия. Про это я еще скажу отдельно, если интересно (а то малость отклонился всторону от вопроса).
Так вот, мониторинг в известных мне ECM-системах имеется в графическом виде. По крайней мере в одной из них он однорвеменно имеется и в табличном. В графическом виде мониторинг всегда производится в разрезе бизнес-процесса, и всегда лишь в рамках одного конкретного экземпляра. В табличном можно вести мониторинг по множеству экземпляров одновременно, накладывая фильтры по исполнителям, по фазам (операциям) процесса и даже по множеству разных видов (шаблонов) БП. Какой-либо ущербности в этом плане по сравнению с другими продуктами в ECM я не обнаружил.

WJНе думаю, что поиск документов - это основная задача управления. Такое мы встречали как раз ДО появления BPMS. Когда самым сложным в работе было именно НАЙТИ документ. Но эту проблему мы решили именно при помощи BPMS. Мне кажется, что основная цель, которую преследует бизнес-владелец - это УПРАВЛЕНИЕ. НЕ поиск, НЕ хранение - именно УПРАВЛЕНИЕ. И H2H-BPM, на мой взгляд, под это гораздо более заточены.Да, конечно, тут Вы совершенно правы. Но такая задача, будучи даже не самой главной, все-таки существует. В BPM-системах обычно принято сохранять инорфмацию об уже выполнившихся (полностью завершенных) экземплярах БП. Спрашивается, зачем (если управление как таковое уже состоялось)? Анализ тенденций - это одна из главных задач, для которой такая информация аккумулируется. Вторая задача - это "архивное дело". Возможность просто найти информацию по тем событиям, которые ранее произошли. Для того, чтобы решать подобную задачу, нужно иметь удобные инструменты поиска. В ECM они есть просто потому, что ECM изначально акцентировался на этой задаче.

Есть еще один весьма не самый второстепенный нюанс. Это поддержка версионности документов. Во многих BPM имеется поддержка версионности схемы БП, но поддержка версионности документов отсутствует. Давайте рассмотрим конкретный пример. Допустим, некоторая часть БП содержит согласования текста договора разными инстанциями с правом внесения правок в текст договора. На случай если впоследствии выяснится, что организация "лопухнулась" из-за корявой формулировки, хотелось бы иметь представление о том, кто эту формулировку предложил, по каким причинам, как выглядела редакция данного пункта в первой, второй, третьей и т.д. редакциях. Если договор представлен, например, файлом формата MS Word и хранится на файловом сервере, то внесение каждой правки в него должно, по идее, приводить к появлению нового файла. Хранить три десятка файлов разных редакций одного договора на файловом сервере, согласитесь, затея не самая удачная. Кроме того, нужно еще не забыть после внесения изменений в текст документа сохранить его под новым именем, а не под старым. В BPM-системах решение подобной задачи может потребовать приложения дополнительных усилий и появления нового источника ошибок (а вдруг все-таки неопытный пользователь возьмет, да и сохранит под старым именем новую редакцию?). В ECM над всеми этими вещами даже не нужно задумываться - поддержка такой функциональности встроена в систему.

И еще раз хочу подчеркнуть, что не считаю эту функциональность главной задачей управления. Но современные BPM-системы по иделолгии их использования и их возможностям лучше всего "ложатся" именно на те части бизнеса, где имеется запутанный документооборот, сложные регламенты и т.п. В этом плане их ниша почти сливается с нишей ECM. Было бы здорово, если бы BPM были бы способны на нечто большее, например, на имплементацию частей не только управленческих бюрократических процедур, но и технологических процессов (тогда бизнес-процесс мог бы иметь более детальное описание и иметь завершенное неразравное представление). Однако, современные BPM-системы не годятся для автоматизации производственных технологических процессов преимущественно по той причине, что не обладают достаточной реактивностью. Упраление технологическими процессами требует синхронизации операции на уровне долей секунды, на что BPM-системы пока не способны (так же как и ECM). А вот ежели бы BPM это могли бы, они бы действительно существенно расширили бы свою область применения по сравнению с ECM.

WJЯ не о том. Не о документах. О данных из разных систем. Вам несимпатичны S2S BPMS. Признаюсь, я тоже тяготею к H2H, хотя предпочитаю, чтобы было и то, и другое. Но в ECM интеграция корявая. Докажите мне, что я ошибаюсь;-)Гхм, ну и вопросики Вы задаете... :) Можно, конечно, в ответ попросить доказать обратное, но я этого делать не стану. :)
ПМСМ, возможности интеграции H2H BPMS несколько уступают возможностям EAI. Примерно на столько же, на сколько эти возможности уступают у ECM по сравнению с EAI. Но это в большей степени субъективное ощущение, доказать я тут ничего не могу. Я допускаю, что могут быть нюансы, которые склоняют чашу весов между H2H BPMS и ECM в одну из сторон, но детально в таких нюансах я не разбирался.

WJ GaryaНапример, мы регистрируем поступающий заказ, а наш маркетолог по каким-то собственным известным лишь ему соображениям попросил нас решистрировать пристрастия обратившегося, задав ему определенный перечень вопросов. Где хранить этот перечень? "Прикручивать" к учетной системе? Зачем?Просто хранить? Да хоть в файле. Нормально - это подпроцесс "Пристрастия клиента" и вопросы - атрибуты подпроцесса.То, что операция БП на входе и на выходе получает или передает, ПМСМ, вполне можно трактовать как "электронный документ". Саму операцию вполне допустимо называть "подпроцессом" (один из классиков теории процессного управления именно так и делал :) ). Но ответы на вопросы врядли можно рассматривать как совокупность операций БП. Ответы вводит один человек и "за один присест". По сути, это документ типа "анкета". Для ее заполнения заданы некоторые правила. В частности, заполнение некоторых ее полей производится выобором одного (или нескольких) позиций из заранее подготовленного перечня. Если указанная анкета "вещь в себе", то можно эти перечни "зашить" в диалоговую форму. Но если они используются или могут использоваться в дальнейшем еще где-то и для чего-то, то лучше их хранить в доступном для других операций и БП месте. ПМСМ.


***

И еще небольшое пояснение, а то, боюсь, мою позицию некоторые посетители не совсем правильно поняли.
Ранее я много раз положительно высказывался в пользу, например, UNIFY NXJ (это H2H BPMS). Я не стал относиться к ней хуже. ПМСМ, это очень достойный продукт, и его использование наиболее оправдано, если ощутимая часть БП осществляется за пределами локальной сети предприятия, если имеется множество удаленных филиалов, если в БП задействованы многочисленные партнеры по бизнесу. Это недорогой продукт, соперничать с котороым в плане цены не может тот же Documentum (последний для реализации схожей функциональности оказывается существенно дороже). Directum премерно в той же ценовой нише, что и Unify, он в чем-то выигрывает, а в чем-то проигрывает. Поэтому нужно смотреть по месту. Универсальных ответов тут быть в принципе не может, ПМСМ.

iscrafmя так понял, что здесь все делятся мнениями, а не опытом работы с обсуждаемыми продуктами. А опыт есть у кого-нибудь? Более серьезный чем пилотный проект по управлению заданиями, что обычно называют гордым словом BPMS? Можно поделиться? Хотя бы названий клиентов, они не к чему. Что устанавливали, какой процесс автоматизировали, сколько задействовано пользователей, с чем интегрировались и т.п. Можно ссылки на уже готовые описания.Мы работали с Unify и ушли дальше пилотного проекта.

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

iscrafm GaryaМы работали с Unify и ушли дальше пилотного проекта.
куда дальше? или опять секретность? Кроме расслыки уведомлений и контроля ответов по ним, что система делает?Да какие там секреты...
Пилотный проект делается силами сотрудников российского представительства Unify. Бесплатно, кстати... Сотрудники представительства Unify делали пилотный проект только до момента запуска БП. Здесь можно посмотреть схему БП на момент запуска и через 3 месяца после него. Запуск произведен 01.10.2006. Далее мы его разрабатывали сами, каким он стал через 3 месяца, можно более детально рассмотреть здесь . БП "сторонний заказ" охватывает действия, связанные со второстепенным производством вот на этом заводе (выполнение субподрядных работ). То есть, заказы, направляемые на завод другими производственными предприятиями на выполнение отдельных производственных операций (чаще всего, литья). Номенклатура таких работ трудно систематизируется, поэтому БП такой "навороченный". Фактически он как бы "генерит" (синтезирует) бизнес-процесс производства под конкретный сторонний заказ. Фактически производственные операции под каждый подобный заказ уникальны.

WJПо поводу ECM в частности, я лично считаю, что этот класс ПО просто сольется в ближайшем будущем с BPM, как это произошло (и происходит) с EAI. И меня это даже не удивляет...По-моему, и с ECM это уже произошло... :)