Сахават ЮсифовWWF поддерживается MS. :)Это, конечно, хорошо. Если бы еще WWF поддерживал версионность схем бизнес-процессов, было бы совсем здорово... :)

WJтраектория документооборота не совпадает с траекторией бизнес-процесса.Возможно, я чего-то не понимаю... Я давно пытаюсь вникнуть в различия систем автоматизированного документооборота и автоматизированного управления бизнес-процессами. Но пока еще не понял. Приведенная здесь цитата, возможно, скрывает в себе ключ к этой загадке (для меня), поэтому я на нее обратил внимание.
WJ, объясните пожалуйста Вашу позицию в этом вопросе. Да, в общем случае траектория бизнес-процесса не совпадает с траекторией движения какого-либо конкретного документа. Точно так же, как и траектории движения конкретных людей (участников бизнес-процесса) также совпадают с траеторией бизнес-процесса лишь отчасти. Но что из этого следует? Траектория движения документа может быть частью бизнес-процесса, а не всем бизнес-процессом. Либо даже пронизывать множество бизнес-процессов. Ну и что? Системы автоматизации документооборота уже давно выросли из штанишек задачи ослеживания траектории движения одного какого-то документа. Между разными документами могут возникать точки соприкосновения (причем, между одними и теми же их может быть несколько на разных фазах бизнес-процесса), одни документы могут "порождать" другие... Все эти вещи отслеживаются в современных системах документооборота. Объясните пожалуйста, в чем Вы видите принципиальное различие, которое можно было бы интерпретировать в пользу BPM-системы? Одно отличие я вижу, но оно... гхм... в противоположную пользу. :) Насколько я себе представляю, у Docflow систем есть всё, что требуется иметь BPM-системе, ПЛЮС еще один маленький пустячок - упорядоченное хранилище документов со специализированным инструментарием для поиска этих документов, встроенная поддержка версионности документа (т.е. редакций документа - то, чего нет в традиционной BPMS). Я задам вопрос более четко. Что есть в BPMS такое, чего нет в Docflow-системе?

WJПредвижу второй вопрос: ценность. Если конечная цель состоит в том, чтобы разложить бумажки (документы) по нужным правильным папкам, то тогда документооборота вполне достаточно. Если же цель - стать ближе к клиенту, то клиенту до ваших папочек с бумагами фиолетово.Если рассматривать BPM-системы с позиций поддержки ими методов процессного управления, то, ПМСМ, ничего плохого в том, что система "умеет" раскладывать документы по полочкам/ящичкам нет. Более того, одна из составных частей JIT (то есть, концепции процессного управления), именуемая для кратости "5S" преследует именно такую цель. На русский язык 5S обычно переводят как "упорядочивание". ПМСМ, Docflow-система справляется с подобными задачами несколько более эффективно. Задача упорядочивания - иметь возможность быстро найти нужную информацию. То есть, приложить изначально некоторые усилия для упорядочивания, дабы вдальнейшем сэкономить на усилиях по поиску и анализу этой информации. Это, конечно же, только небольшая часть управленческой концепции, основанной на процессном подходе. Но ее нельзя считать несущественной. Как говорил ВИЛ, "лучше больше, да лучше"... Или нет? :)

WJА что такого делает DocFlow, что не делает BPM?На этот вопрос ответил я чуть выше.
1. Ведет контроль версий документа.
2. Производит поиск документа по его систематизированным атрибутам.

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

Небольшое замечание. ПМСМ, противопоставление BPM-систем и Docflow-систем не совсем корректно. Сейчас границы между ними настолько размылись, что просто перестали существовать. Более того, наиболее "красиво" реализованные идеи именно процессного подхода я обнаружил именно в Docflow-системах, в известных мне EAI-системах или BPM-системах таких средств мне обнаружить не удалось.

Поясню конкретно, о чем идет речь.

1. Бизнес-процесс - штука весьма жесткая. В частности, в ISO 9000 шаг влево/вправо за пределы БП недопустим. Изначально мне это казалось благом - когда энтропия равна нулю, предсказуемость, прозрачность, управляемость и т.д. и т.п. равны бесконечности, есть также массив информации, изначально пригодный для статистической обработки. Но нравилось мне всё это лишь до тех пор, пока на собственной шкуре не вкусил этой жесткости. Наткнулся также на БП, формализовать которые можно лишь до некоторой степени... И понял, что нельзя впадать в крайности. Конечно же, формализация БП должна производиться, но должны также иметься удобные возможности контролируемого отклонения от схемы БП. Разумеется, с регистрацией того факта, что отклонение произошло - и всех обстоятельств этого отклонения. С одной стороны, такая схема работы позволяет исполнителям находить выход из сиюминутной ситуации, когда клиент здесь и сейчас стоит над душой и ждет, когда ему вот прямо сейчас сделают то, что мы никогда не делали и делать не собирались... Но мы ведь "ориентированы на клиента", почем мы должны его огорчать? Разве является достаточным основанием для того, чтобы его расстроить, тот факт, что аналитик, производящий корректировку схемы БП в отпуске или в командировке, или он занят срочным заданием и не может отвлечься? В некоторых Docflow-системах я обнаружил приятную возможность производить действия в обход схемы бизнес-процесса с регистрацией этих отклонений. Пределы "обхода" задаются правами тех или иных пользователей. Фактография подобных отклонений очень полезна и для бизнес-аналитика, который может выявить причины наиболее частых и критичных отклонений и внести изменения в схему бизнес-процесса, но сделать это в спокойной обстановке, постфактум. Не подскажете, есть ли в какой-либо BPM-системе подобный инструментарий? Собственно, возможность обхода схемы БП сводится к возможности принудительного направления рабочего документа любому адресату или группе адресатов (механизм, похожий на email) в обход жестко заданных траекторий движения.

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

3. В BPM-системе есть лишь вход и выход операции, внутри - "черный ящик". В некоторых Docflow-системах можно "заглядывать" внутрь этого "черного ящика" и видеть статус документа, переданного в некоторый центр обработки. Для некоторых групп пользователей может быть весьма интересна не только "черно/белая" (бинарная) информация вроде "вошел" документ или "вышел", но и "градации серого"... :) Конечно, можно, и в BPM-системе несколько раз отправлять документ самому себе по мере того, как он будет проходить, скажем, 10 фаз "градаций серого" в обработке у одного человека. Но, во-первых, это просто неудобно. Во-вторых, такая информация, открыл ли некий Иванов И.И. интересующий документ в настоящий момент и изучает ли его на своем экране (по этой информации можно прикинуть, как долго можно ожидать решения, например, от руководителя; либо напротив - проверить руководителю, занимается ли подчиненный той работой, которая считается срочной с точки зрения именно руководителя) - встроить в BPMS, тоже конечно, можно, но это уже совсем нужно быть "садомазохистом"... :) ПМСМ, проще взять продукт, в котором такие возможности уже встроены.

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

***

Если же говорить об использовании EAI, BPM или Docflow-систем в качестве инструментария реализации именно процессного подхода (а этот вопрос меня интересует наиболее всего), то постепенно я прихожу к выводу, что в достаточной степени продвинутых инструментариев для достижении именно этих целей на рынке ПО просто нет (либо они мне неизвестны, готов это допустить). Очень многие вещи должны быть встроены в такие системы, а их там просто нет. В частности, инструментарии статистического анализа - очень-очень важная компонента, и даже колоссальной важности компонента для реализации принципов процессного управления... Так ведь никто ее не встраивает! Нужно "городить огород" с внешними аналитическими статистическими пакетами... Спрашивается, зачем его городить, если проукты изначально должны просто "не уметь без него жить" и иметь ориентированные на конкретный продукт удобные средства , помогающие в том числе плохо ориентирующемуся в математической статистике менеджеру сориентироваться в нужную сторону и даже, может быть, в некоторой степени побудить его воспользоваться статистическими методами качества... А на сегодняшний день получается прелюбопытная картина... Для того, чтобы воспользоваться всем комплексом современных достижений, нужно:

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

б) хорошо разбираться в современных технологиях менеджмента (то есть, быть не просто менеджером-практиком, но и менеджером, хорошо знающим теорию)

в) хорошо разбираться в информационных технологиях

г) великолепно разбираться в высшей математике (то есть, быть еще и математиком)

д) иметь административный потенциал, дабы кроме "хочу" могло возникнуть еще и "могу"...

Не много ли для простого смертного? :)

А в общем, не обращайте внимания... Просто настроение слегка паршивое... Понял, что соединить всё это в себе у меня как-то не получается. Хотя бы одного пунктика (а обычно больше) всегда не хватает. :(

ConceptВопрос (признаюсь, возможно, полемически заостряю:): чем отличается BPM от автоматизации документооборота? Почему все-таки нельзя управлять бизнес-процессами средствами автоматизированного документооборота? Был интересный пост:

.... BPMS=рисовалка (средство моделирования БП) + движок + аналитика.... [/quot]

Может быть тут как раз и есть главное отличие: предоставляют ли системы документооборота возможность моделировать процесс документооборота?[/quot] Да, предоставляют. Признаться, я тоже серьезных отличий между BPM и современными системами автоматизации документооборота не наблюдаю. Может быть, в прошлом они и были...

blindedВот как, теперь оказывается интеграция это не самое важное в BPMS. Так что Oracle, IBM, MS, продвигающие свои BPMS системы в первую очередь как средства обеспечивающие интеграцию систем, оказываются ничего в в BPMS системах не понимают? Договорились....Я выскажу свое мнение, то есть, IMHO по этому поводу. И заранее предупреждаю, что не претендую на знание истины в конечной инстанции.

Ситуация с этими вендорами в секторе BPMS выглядит несколько забавно. Начали там рисовать собаку, потом огляделись, посмотрели в какую сторону ветер дует, и рядом с уже нарисованной собакой, танцующей на задних лапках с аппортом в зубах, сделали надпись "це волк, а не собака"... :)

Перечисленные вендоры изначально разрабатывали системы класса Enterprice Applications Integration (EAI), то есть системы (или сервера) интеграции приложений. В первых версиях BizTalk, например, Orchestration не было как класса - были порты, каналы и XSLT-преобразовашки... и всё! Потом возникло понимание, что такие системы располагаются не просто между приложениями, а в некотором информационном пространстве, в котором в подвисшем состоянии оставлены целые куски бизнес-логики. Приложение A занимается взаимодействием с банковской платежной системой, приложение B ведет бухгалтерский учет, необходимо наладить их взаимодействие, но между ними осталась часть бизнес-логики, которая не реализована ни в приложении A, ни в приложении B. Есть бизнес-процесс подачи заявок на платеж, визирования, утверждения, в нем могут быть задействованы еще какие-то приложения или люди... Оказывается, что не получается так просто бац - и связать между собой приложения. Вот тогда и появляется Orchestration - и в нем появляются схемы исполняемых бизнес-процессов. Сначала на XLANG (формат описания БП, разработанный MS для использования только в продуктах MS), потом от него отказываются в пользу BPEL... Но по своей сути BizTalk как был, так и остался EAI, как и вебсфера или Oracle BPEL. Но разработчики "почуяли" серьезное дуновение ветра в сторону BPM-систем, обнаружили, что их продукты имеют с такими системами много общего, и стали называть их "BPMS", хотя изначально именно как BPM-систему они свои продукты делать и не думали.

Скажу больше. В частности, для автоматизации документооборота, требующего преимущественно взаимодействия с людьми, эти системы очень плохо подходят. Придется потратить немалые усилия для создания пользовательского интерфейса. Если бизнес-процессы часто меняются, то "на ходу" и безболезненно изменять их схему в этих системах тоже не всегда получится, потому что ни одна из этих систем не поддерживает версионность схемы бизнес-процессов. Может понадобиться останавливать бизнес-процесс (а вместе с ним и безнес) на длительный срок, может понадоиться сплясать джигу с бубном, чтобы не останавливая выполнение уже запущенных экземпляров бизнес-процесса ("длинных транзакций"), создать новую измененную схему бизнес-процесса. Сказать, что это НЕ BPM-системы, я, конечно же, не могу. Но те производители, которые изначально закладывались на разработку именно системы автоматизации бизнес-процессов, не имеют таких ограничений, которые имеют эти системы. С другой стороны, эти системы существенно лучше других справляются с задачами интергарции большого числа разных приложений. Поэтому лично я пришел к выводу, что относительно полноценная совокупность задач как интеграции множества приложений, так и обеспечения гибкости бизнес-процессов при взаимодействии за пределами используемых приложений с большим числом людей, лучше использовать совокупность из BPM-систем разной направленности: нацеленной на human-to-human взаимодейтсвие (или Docflow-систему, которая тоже может считаться подобной BPM-системой) и EAI, которые еще относят к BPM класса system-to-system.

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

АБ2) BPM используют стандартные языки программирования и методы интеграции, а ECM проприетарные языки и адаптерыЭто отчасти так, но не совсем. Потому что жестких правил, требующих использовать в ECM именно проприетарные языки, нет. Просто так сложилось, что они опирались на собственный язык изначально. Хочу лишь напомнить, что BizTalk тоже изначально опирался на проприетарный XLANG (произносится "слэнг", что примечательно в контексте обсуждения :) ). Возможно, существуют ECM, которые опираются также на стандартные языки. С интеграцией тоже не всё так однозначно. На самом деле многие ECM позволяют задействовать очень многие интерфейсы, хотя следует признать, что решать задачи интеграции с помощью ECM несколько менее удобно, нежели с помощью EAI. Как, кстати, и для некоторых human-to-human "исконных" BPM-систем :)

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

АБНо главное, с точки зрения методологии бизнес-процесс намного шире, чем документооборот. Типичный пример (упрощая): там, где специалист по документообороту видит "заключение договора", специалист по BPM видит процесс, начинающийся с обращения клиента и заканчивающийся расчетами с ним.Я видел реализованный в ECM реально работающий бизнес-процесс, который тоже начинается с обращения клиента.

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

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

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

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