TBPD: Tasks-based Business-Processes Definition

Ну, в общем, тут, видимо, этой штуке и место.
Общая идея в том, чтобы автоматизировать бизнес-процессы не на базе Activities, а на базе Задач.
Итак:

Суть:

• Все бизнес-процессы (т.е. последовательности действий) есть последовательности Задач: одно действие - один тип Задач;
• Задача может зависеть от других Задач - как начало Задачи, так и её завершение;
• Задача не может быть удалена или изменена - только завершена с тем или иным исходом;
• Задача может "включать" другие Задачи путем установления зависимостей. Вариант "включения" - когда подзадача активируется при активации надзадачи, а надзадача может быть завершена при завершении подзадачи.

Особенности:

• Любая Задача имеет как минимум автора, дату/время создания, исполнителя, дату/время прочтения задачи исполнителем; дату/время завершения (для завершенных);
• Задача может быть только в четырех состояниях: неактивная, активная непрочитанная, активная прочитанная (автомат), выполненная (с тем или иным исходом);
• Состояние задачи может зависеть от состояния других Задач:
• Задача может быть неактивной до тех пор, пока не будут завершены с нужным исходом другие Задачи, от которых зависит эта задача;
• Активная задача не может быть завершена с определенным исходом, если не завершены с нужным исходом Задачи, от которых она зависит;
• Выполнение задачи может создавать другие задачи (какие - может зависеть от исхода);
• Самая первая задача в бизнес-процессе может быть создана Событием - специальный тип Задачи без задачи-родителя;
• Завершение Задачи может породить другую Задачу того же типа; тогда в работе участвует только последняя задача в такой цепочке - получается "история выполнения задачи";
• С Задачами можно работать в любом ПИМе; некоторые можно там же завершать, если ПИМ поддерживает нужные исходы.

Примеры:

• Зависимость неактивности: "Оплатить счет" неактивна, пока не выполнено "Получить счет";
• Зависимость завершения: "Оплатить счет" не может быть завершена успешно, пока не выполнена задача "Получить выписку из банка" - тоже успешно;
• Группировка: "Купить товар" не может быть завершена, пока не завершены "Оплатить товар" и "Получить товар"; "Оплатить товар" не появляется, пока не появится "Купить товар".
• Зависимость следующих задач от исхода предыдущей: завершение "Оплатить счет" создает "Получить товар" (если счет оплачен успешно) - или же "Купить за нал", если не оплачен по причине денег на счету ёк;
• Задача порождает задачу того же типа: изменение сроков выполнения задачи, замена исполнителя.

Отличия от классики:

• Нет "состояния" процесса или его части (начал выполнять, выполнил наполовину и т.д.) - есть только Задачи - выполненные и не выполненные. Т.е. "состояние" процесса - это суперпозиция состояний всех его задач.
• Нет многих состояний Задачи (начал выполнять, почти закончил выполнять и т.д.) - только выполнена или нет (неактивна/активна, прочитана/не прочитана - это уже просто техника, юзер оперирует только "открыта" и "закрыта").
• Самое главное: контролируется не процесс, а результат.

Ключевые преимущества:

• динамическое планирование проекта - схема выполнения проекта может меняться на лету без дополнительных усилий - просто в силу внешних обстоятельств и результатов решения промежуточных задач;
• внятное визуальное представление хода выполнения проекта - для руководства (цветной граф задач и их связей - цвет задачи/связи зависит от успешности и сроков её выполнения);
• простое и удобное представление для исполнителей (простой список задач с возможностью группировки/сортировки/фильтров);

Идеи:

• задачи обеспечивают/требуют (Requires/Provides) некие "сервисы" (на самом деле - события). Триггеры вешаются на эти сервисы. Задачи включают/выключают сервисы. Это более удобно, чем вешать триггеры пачки задач на пачки друггих задач (которые сегодня есть - завтра нет).
• Задачи завершаются всегда - или исполнителем, или системой по дедлайну (с генерацией следующих задач - для принятия решения).
• Возможно, если задача не меняется в течении всего своего цикла жизни (а это уже не задача, а бизнес-процесс) - то хранить только один экземпляр и вести историю изменений.