Конструктивный Workflow
Глядя на текущее состояние дел в области подходов к автоматизации потоков работ (Workflow) не могу избавиться от ощущения, что здесь есть нечто, до сих пор ускользающее от внимания и практиков, и исследователей.
Глядя на текущее состояние дел в области подходов к автоматизации потоков работ (Workflow) не могу избавиться от ощущения, что здесь есть нечто, до сих пор ускользающее от внимания и практиков, и исследователей.
С одной стороны, есть BPM, эффективно действующий там, где есть процессы с устоявшимся и четко определенным порядком действий.
С другой – ACM, который отказывается от фиксации последовательности действий в пользу фиксации требований, предъявляемых к результату.
С третьей – есть машины бизнес-правил (BRMS), которые занимают промежуточную позицию: даже если нельзя полностью охватить последовательность действий от начала до конца бизнес-процесса, то можно автоматизировать хотя бы ту часть правил, которую удалось строго зафиксировать.
С четвертой – есть управление проектами (PM), когда с уникальностью процессов борются на этапах планирования и проектирования, предваряющих работы по каждому вновь начинаемому проекту.
Каждый из этих подходов имеет свои достоинства и недостатки. Но даже взятые вместе, они еще не охватывают достаточно эффективно всех условий, в которых могут существовать бизнес-процессы.
По-прежнему остается открытым вопрос: существуют ли модели, подходящие для автоматизации потоков работ там, где нет ни повторяющихся конкретных целей, ни фиксированного порядка работ, ни ресурсов, чтобы тщательно планировать работы для каждого экземпляра бизнес-процесса?
Известно, что для автоматизации обязательно должен быть повторяющийся устойчивый компонент. А что если в качестве такого компонента взять элементарные «строительные блоки» бизнес-процессов – операции? Одной из таких попыток является сервисно-ориентированная архитектура (SOA). Хотя и тут для организации сервисов в потоки работ почти всегда скатываются в итоге к классическому представлению - Workflow.
Но есть ведь и другие варианты. Например, если позаимствовать идеи из конструктивизма, то можно предложить такое направление: операции объединяются в потоки работ не на основе фиксированных статичных схем, а на основе конструктивных правил, задающих способ динамического построения схемы, подходящей для данного места и времени.
Если сравнивать с упомянутыми выше моделями, то отличия будут такими:
● В BPM схемы задаются статически, а здесь – динамически;
● В ACM гибкость обеспечивается решением пользователя, а здесь – системой;
● Правила BRMS не дают представления о порядке действий, хотя и задают его неявно, а здесь – у каждого экземпляра процесса есть явно заданная схема.
● В PM планирует пользователь, а здесь – система.
Выглядит слишком хорошо, чтобы быть правдой. Чем же за это придется заплатить?
Во-первых, таких систем еще нет.
Во-вторых, существующие в теории модели конструктивного построения схем на данный момент слишком сложны для того, чтобы выносить их на уровень бизнес-аналитика.
В-третьих, для таких систем затруднен статический анализ системы бизнес-процессов, поскольку схемы возникают лишь на этапе исполнения, а на этапе проектирования их еще нет.
На мой взгляд, все перечисленные проблемы – разрешимы. Правда, затрудняюсь с оценками: насколько полно и за какой период времени? А может быть есть и еще какие-то интересные альтернативы?
Изображение взято с сайта http://www.wannalearn.com/
Комментарии 15
Т.е. появляются метаправила? Думаю, слишком сложно, просто неподъемно сложно.
Это как с метапрограммированием - все здорово, просто и очевидно в некоторых простейших (если не вырожденных случаях). А стоит лишь начать использовать метапрограммирование в сложных ситуациях, и все, сложность просто зашкаливает - т.к. разработчику нужно анализировать не только как работает код на тех или иных входных данных, но и какой в принципе код сгенерирует макрос (или метаправило) в данном случае!
А вообще, вопрос - чем не устривает обычный Workflow? Например, меня в первую тем, что большие процессы (от нескольких десятков шагов) просто не воспринимаются мозгом, а разбивать большой процесс на независимые части с одним входом и выходом (т.е. структурировать) получается плохо (т.е. формально-то это возможно, это еще Дийкстра показал, но переформировнные в структурные процессы становятся еще объемнее и перестают восприниматься вообще). -
Кстати, косвенно могу подтвердить свою мысль тем, что разработчики Workflow Foundation вынуждены были (уверен, что это результат давления пользователей) отказаться от чисто структрных схем процессов - иначе просто не возможно было пользоваться.
Основное преимущество конструктивных схем - схема каждого экземпляра процесса будет содержать только то, что необходимо текущему экземпляру, и не более того. Поэтому схемы стандартного Workflow, пухнущие от желания обработать ими побольше различных ситуаций, при переходе к конструктивным определениям начнут упрощаться, а не усложняться.
Другое дело, что на практике это неосуществимо, если в основе будут лежать классические конечные автоматы - для них нет естественного и одновременно выразительного определения композиции автоматов.
Поясню связь между определением композиции и конструктивными построениями.
Основной конструктивной операцией над схемами является композиция схем. Единственная естественная реализация композиции автоматов - это выстраивание автоматов в линейную цепочку. Выразительность таких цепочек стремится к нулю. Все ухищрения, направленные на увеличение выразительности (например, неявная передача значений параметров из схемы в схему), будут снижать понимаемость и сопровождаемость.
Жень, нужен пример.
На слух не воспринимается совсем.
В качестве примера приведу достаточно умозрительную, но типичную ситуацию (надеюсь, по словесному описанию нетрудно будет построить пример схемы).
Предположим, есть процесс, в котором результаты половины шагов (расположенных в разных местах схемы) согласуются с руководителем подразделения. Для этого каждый такой шаг оборачивается в цикл.
Но при этом схема допускает, что исполнителем может быть сам руководитель подразделения и в этом случае с самим собой ему не нужно согласовывать результаты. Для этого из цикла сделано два условия выхода: если исполнитель руководитель или если руководитель согласовал результат. Эти условия находятся в разных местах цикла. И таких циклов на одну схему - несколько штук.
В конструктивном варианте задается правило, что цикл добавляется только в том случае, если исполнитель - не руководитель. При этом условие выхода из цикла - всего одно. А когда исполнитель руководитель - схема вообще окажется линейной.
Таким образом, конструктивно заданная схема будет в любом случае проще, а иногда - на порядок.
Было бы здорово познакомиться с Вашими соображениями на этот счет. Или, может быть, Вы видите, как этого достичь иными путями?
Миша, у меня по недосмотру выскользнула одна деталь, исправляюсь: должно быть "Предположим, есть линейный по своей сути процесс ..."
Нарисовал фрагмент процесса с циклом:
Возможно, я недопонимаю, но верно ли, что для
Евгений писал:
В технологии процессного управления, на самом деле - регулирования, аналитик неотемлемая часть реализации конкретного процесса. Это ясно проявляется в организации работ, например, ситуационных центров. В состав СЦ специально включаются специалисты по разработке процессов в реальном времени. Само планирование выполняется на очень низком уровне (операции, группы операций). Для таких работ нет необходимости использовать системных аналитиков, например, способных разработать новый язык в дополнение к Колмогорову, а нужно использовать специалистов по тушению пожаров, медицинской помощи, эвакуации людей и т.д.
На примере СЦ можно заметить наличие минимум двух уровней управления: лиц принимающих решения и специалистов по направлениям работ. Третий уровень - реализация планов, процессов является уровнем регулирования, когда исполнители работ обеспечивают выполнение поставленных задач в указанные сроки с использованием выделенных ресурсов.
В качестве вывода можно сказать, что разработчики "бизнес-процессов" на самом деле аналитиками не являются, потому что выполняют техническую работу.
Можно привести еще один пример формирования связанного плана (потока) работ, где аналитики не участвуют, а формируют планы операторы или диспетчеры - работники завода по механической обработке деталей. MES системы проектируют аналитики, а применяют их ежедневно операторы. Результатом работы оператора является текущий план работ (1000 - 10 000 работ, не предел). В случае необходимости план пересчитывается в режиме реального времени.
Так чем же должны заниматься аналитики, какое их главное предназначение? Правильно, нужно придумать язык! Еще один язык описания процессов? Очень сомнительно, потому что автоматизируется на самом деле не процесс, а поведение, деятельность человека. Мы знаем, что сложность предмета и модели должны быть адекватными. Отсюда следует, что модель поведения человека должна описываться человеческим языком, поэтому нет необходимости придумывать еще один, пусть даже "конструктивный" язык, потому что очень простой.
Пример с ситуационным центром хороший, спасибо. Про MES системы это уже уход в сторону, т.к. планирование в производстве - это совсем другая кухня, со своей спецификой. Остальное без комментариев.