Наверх

Заметка о workflow

Время чтения: 3 минуты
5
Заметка о workflow

Интересную трансформацию проходит традиционный workflow… Многие, если не сказать все, «первые» СЭД не имели «редактора» workflow как такового...

Интересную трансформацию проходит традиционный workflow…

История вопроса
Многие, если не сказать все, «первые» СЭД не имели «редактора» workflow как такового. Сначала появился «стандартный список согласующих», потом уж графический редактор. Причина проста – был спрос на «бизнес-процессы», и BPM, как представляется, хорошо «пристегивался» к СЭД.

Если помните, некоторые строили весь свой маркетинг на конструкции – «мы есть делопроизводство + workflow». Посмотрите архивы Docflow, например, за 2006 год – примерно в 50% названий докладов встречается словосочетание «бизнес-процесс».

Кстати тогда термин workflow и «редактор схем» как-то объединились в умах. И если сейчас клиенту сказать «наш workflow», то он представит себе именно редактор графа, а не тип ПО или «поток работ» как управленческую концепцию.

Апогея эта история достигла в попытках интеграции с CASE-инструментами, например, ARIS или Business Studio. Идея то светлая – бизнес-аналитик проектирует процесс, а потом раз – и все работает. Ну и еще данные статистики обратно отдает.

Текущий день
Часто ли вы сейчас слышите про workflow в СЭД? Не часто... На недавнем Docflow словосочетание «бизнес-процесс» в названии докладов встречается лишь один раз! Может просто это так банально, у всех есть – чего об этом говорить? Может и так... Но есть еще одна причина – очень часто он не востребован.

Есть мнение, что на «делопроизводство» и «договора» приходится порядка 75% выручки вендоров и интеграторов. Посмотрим, нужен ли там workflow?

В делопроизводстве мы имеем несколько задач: рассмотрение входящего документа (1-4 участника), исполнение резолюций (вообще не процесс, а рекурсивная функция) и еще по мелочи. Редактор и мощный workflow-движок как бы и не нужен.

Но в договорах то точно нужен, скажете обыватель. Увы... В классическом виде и там не особо надо. Процесс согласования договоров, в подавляющем числе случаев, описывается матрицей, где измерениями является «вид договора», «юр. лицо. инициатор», может быть еще сумма контракта. И вот для каждой комбинации указывается список согласующих, утверждающий и т.д. В итоге консультанты используют редактор workflow весьма своеобразно, скорее не как редактор графического языка бизнес-процессов, а как визуальный конструктор алгоритма.

Утверждать, что wokrflow совсем бесполезен нельзя, но стало понятно, что его роль была переоценена и раздута маркетингом. В применении к СЭД, конечно.

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

Такие дела. Увы.

[Репост]

Чтобы прочитать эту статью до конца,
или зарегистрируйтесь

Комментарии 5

Если для вас worflow - это только согласование (официальных) документов, то все верно.
Если для вас worflow - это только согласование

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

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

И упомянул, но еще раз скажу, что я почти не встречал потребителей СЭД, которые воспринимают workflow как тип программ (стартующих по событию, имеющих схему исполнения и т.д.), поскольку они не программисты. Так же мало кто в курсе что есть еще конечный автомат, который также реализуется workflow и в таком случае не имеет никакого отношения к классическому бизнес-процессу... 

Позвольте уточнить, а кто по вашему должен использовать workflow в качестве инструмента для описания бизнес-процессов? На каком этапе интегрирования СЭД он будет использован? Просто по опыту внедрения СЭД могу сказать, что за частую сначала внедряют на основе типовых маршрутов, а потом уже допиливают - это по мнению руководства компании дешевле, чем исследовать и оптимизировать.

Большинство потребителей СЭД очень далеки от идеи того, что можно нарисовать в программе маршрут, который будет визуально читаемый и хорошо интегрированный в бизнес-логику компании. 

Виктор, можно привести пример для иллюстрации списка согласующих по этапам? Или это просто таблица с триггерами для описания бизнес-процесса?

Позвольте уточнить, а кто по вашему должен использовать workflow в качестве инструмента для описания бизнес-процессов? На каком этапе интегрирования СЭД он будет использован? Просто по опыту внедрения СЭД могу сказать, что за частую сначала внедряют на основе типовых маршрутов, а потом уже допиливают - это по мнению руководства компании дешевле, чем исследовать и оптимизировать.

Не совсем понял... и все равно отвечу ).

Кто должен использовать WF для описания БП?
Бог весть, кому захочется. Но я бы не рекомендовал ).

На каком этапе WF будет использоваться?
Имеется в виду "При внедрении какого решения..."? Если так, то любом, где есть автоматизация бизнес-процесса(ов). Не столько будет сколько может. Ибо WF в ECM позиционируется как BPM (ну точнее считается что "у нас вот есть BPM").

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

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

"можно привести пример для иллюстрации списка согласующих по этапам"
Не вопрос, дам ссылку на один зеленый сайт: http://www.docsvision.com/kupit/dv-catalog/dv-catalog-new_81.html 

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

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

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

Чтобы прокомментировать, или зарегистрируйтесь