Журнал о системах электронного документооборота (СЭД)
Workflow и управление бизнес-процессами

Конструктивный Workflow

  16 комментариев Добавить в закладки

 

Глядя на текущее состояние дел в области подходов к автоматизации потоков работ (Workflow) не могу избавиться от ощущения, что здесь есть нечто, до сих пор ускользающее от внимания и практиков, и исследователей.

С одной стороны, есть BPM, эффективно действующий там, где есть процессы с устоявшимся и четко определенным порядком действий.

С другой – ACM, который отказывается от фиксации последовательности действий в пользу фиксации требований, предъявляемых к результату.

С третьей – есть машины бизнес-правил (BRMS), которые занимают промежуточную позицию: даже если нельзя полностью охватить последовательность действий от начала до конца бизнес-процесса, то можно автоматизировать хотя бы ту часть правил, которую удалось строго зафиксировать.

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

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

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

Известно, что для автоматизации обязательно должен быть повторяющийся устойчивый компонент. А что если в качестве такого компонента взять элементарные «строительные блоки» бизнес-процессов – операции? Одной из таких попыток является сервисно-ориентированная архитектура (SOA). Хотя и тут для организации сервисов в потоки работ почти всегда скатываются в итоге к классическому представлению - Workflow.

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

Если сравнивать с упомянутыми выше моделями, то отличия будут такими:

●    В BPM схемы задаются статически, а здесь – динамически;

●    В ACM гибкость обеспечивается решением пользователя, а здесь – системой;

●    Правила BRMS не дают представления о порядке действий, хотя и задают его неявно, а здесь – у каждого экземпляра процесса есть явно заданная схема.

●    В PM планирует пользователь, а здесь – система.

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

Во-первых, таких систем еще нет.

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

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

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


Изображение взято с сайта http://www.wannalearn.com/

Ещё материалы автора
Похожие записи
Комментарии (16)
Михаил Романов 01 октября 2011 г. 17:22  
существуют ли модели, подходящие для автоматизации потоков работ там, где нет ни повторяющихся конкретных целей, ни фиксированного порядка работ, ни ресурсов, чтобы тщательно планировать работы для каждого экземпляра бизнес-процесса?
Жень, а можешь привести конкретный пример?
По тому как в такой обобщенной постановке ответ напрашивается: "нет, не имеет смысла, т.к. это уникальные, разовые процессы анализ и автоматизация которых не возможна в принципе".
 
Хотя и тут для организации сервисов в потоки работ почти всегда скатываются в итоге к классическому представлению - Workflow
И думаю, что будет и далее.
Описание в виде последовательности работ легко понимаема, верифицируема (т.е. проверить правильность описанной модели можно просто "методом пристального взгляда"), не требует особых знаний и навыков для чтения и фиксации, и т.д. Ну и конечно, это легко (относительно) программируется.
Если посмотреть на более-менее реальный процесс (т.е. не облегченный учебный, который приводят при описании методики, а такой, какой реально приходится задавать), то обнаружится, процесс понимаем пока используется только последовательная передача управления и ветвление (и то не всегда). Но стоит даже добавить цикл (а еще хуже - вложенный цикл), то обнаружится, что понимание процесса упало чуть не до 0, а если появляется распараллеливание - вникнуть становится практически невозможной задачей.
В общем, я бы сказал, что даже "простой" workflow довольно сложен в использовании, а остальные методы и вовсе неподъемны.
 
операции объединяются в потоки работ не на основе фиксированных статичных схем, а на основе конструктивных правил, задающих способ динамического построения схемы, подходящей для данного места и времени

Т.е. появляются метаправила? Думаю, слишком сложно, просто неподъемно сложно.

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

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

Кстати, косвенно могу подтвердить свою мысль тем, что разработчики Workflow Foundation вынуждены были (уверен, что это результат давления пользователей) отказаться от чисто структрных схем процессов - иначе просто не возможно было пользоваться.

Евгений Кочуров 01 октября 2011 г. 18:09  
Думаю, слишком сложно, просто неподъемно сложно.

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

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

Евгений Кочуров 01 октября 2011 г. 18:22  
можешь привести конкретный пример?

Собственно, Миша, ты сам его и привел - если описание процесса содержит достаточно циклов, ветвлений и параллелизма, что фактическая последовательность действий перестает улавливаться, вряд ли порядок действий в таком процессе можно воспринимать, как фиксированный. Формализованный - да, но не фиксированный. Ведь тут меняется от раза к разу и число шагов, и состав действий, и исполнители...
Евгений Кочуров 01 октября 2011 г. 18:32  

Поясню связь между определением композиции и конструктивными построениями.

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

Александр Головко 02 октября 2011 г. 22:09  
И думаю, что будет и далее.
Михаилу. Если вспомнить про первичный бульон (когда только зарождалась жизнь), то по результатам эволюции бульона можно сказать, что "далее будет" только в историческом смысле. WF и другие с ним уйдут. Зачем ломать голову проектированием процессов, когда можно получать планы, процессы, операции автоматически. Работу по формированию конкретного мероприятия должен исполнять пользователь, а не аналитик. Пока мы шикарно живем.
Михаил Романов 03 октября 2011 г. 09:28  
Зачем ломать голову проектированием процессов, когда можно получать планы, процессы, операции автоматически.
Каким образом?
Т.е. наверное это возможно, но как это будет выглядеть я абсолютно не представляю.
Михаил Романов 03 октября 2011 г. 09:30  

Жень, нужен пример.
На слух не воспринимается совсем.

Евгений Кочуров 03 октября 2011 г. 11:12  

В качестве примера приведу достаточно умозрительную, но типичную ситуацию (надеюсь, по словесному описанию нетрудно будет построить пример схемы).

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

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

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

Таким образом, конструктивно заданная схема будет в любом случае проще, а иногда - на порядок.

Евгений Кочуров 03 октября 2011 г. 11:21  
Работу по формированию конкретного мероприятия должен исполнять пользователь, а не аналитик.

Кстати, Александр, Вы предложили тоже интересное направление: исключить аналитика, оставив лишь программиста и пользователя. Правда, пока я не вижу, как язык конструктивных правил сделать настолько общим, чтобы программист априорно смог на нем выразить все, что бы ни захотел пользователь; либо сделать этот язык настолько простым, чтобы дать его непосредственно пользователю.
Было бы здорово познакомиться с Вашими соображениями на этот счет. Или, может быть, Вы видите, как этого достичь иными путями?
Евгений Кочуров 03 октября 2011 г. 11:24  

Миша, у меня по недосмотру выскользнула одна деталь, исправляюсь: должно быть "Предположим, есть линейный по своей сути процесс ..."

Михаил Романов 03 октября 2011 г. 12:25  

Возможно, я недопонимаю, но верно ли, что для

В конструктивном варианте задается правило, что цикл добавляется только в том случае, если исполнитель - не руководитель.
- в случае Workflow-подхода у нас будет условие "если исполнитель - не руководитель, то выполнить цикл"?
Т.е. мы заранее размещаем в схеме все возможные ветки, просто указываем условия срабатывания.
 
Так?
Евгений Кочуров 03 октября 2011 г. 12:37  
Т.е. мы заранее размещаем в схеме все возможные ветки, просто указываем условия срабатывания.   Так?

Да, это один из возможных вариантов реализации, но не единственный. Чтобы обсуждение было нагляднее, предлагаю продолжить его в посте с картинками.
Александр Головко 03 октября 2011 г. 23:15  

Евгений писал:

интересное направление: исключить аналитика, оставив лишь программиста и пользователя

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

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

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

Можно привести еще один пример формирования связанного плана (потока) работ, где аналитики не участвуют, а формируют планы операторы или диспетчеры - работники завода по механической обработке деталей. MES системы проектируют аналитики, а применяют их ежедневно операторы. Результатом работы оператора является текущий план работ (1000 - 10 000 работ, не предел). В случае необходимости план пересчитывается в режиме реального времени.

Так чем же должны заниматься аналитики, какое их главное предназначение? Правильно, нужно придумать язык! Еще один язык описания процессов? Очень сомнительно, потому что автоматизируется на самом деле не процесс, а поведение, деятельность человека. Мы знаем, что сложность предмета и модели должны быть адекватными. Отсюда следует, что модель поведения человека должна описываться человеческим языком, поэтому нет необходимости придумывать еще один, пусть даже "конструктивный" язык, потому что очень простой.

Евгений Кочуров 03 октября 2011 г. 23:35  

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

Сейчас обсуждают
Больше комментариев