Без заголовка

Спасибо за ответ. Я, конечно, подозревал, что пост не о том, просто не нашел "того", а спросить давно хотел. Я не специалист по реформам и пока не берусь решать подобные задачи - поэтмоу спрашиваю о своем, насущном :) Т.е. о проектировании процессов, когда их вообще возможно понять и совершенствовать - смотреть как на практике сформулированные процессы соответствуют действительности и адаптировать. Что Вы понимаете под планировщиком? Возможность увидеть как задачи располагаются на временной оси? Это у нас есть - зная вероятности течения процессов мы можем построить наиболее вероятное расписание (с учетом календарей, пересечений, доступности людей и ресурсов с нужными зарактеристиками) и сказать наиболее вероятную стоимость. Процессы все предпочитают описывать диаграммами процессов - BPEL, BPMN и еще 7 стандартов. Суть их всех - нарисовать действия, соединить входы и выходы, добавить логических конструкций. Существует хорошая научная работа о необходимых паттернах процессов. Но мы решили пойти несколько другим путем описания процессов. Мы не рисуем диаграммы. У нас есть список процессов (где каждый процесс может сам содержать процесс), в котором мы связываем события (сделано, не сделано, отменено, пользователь утвердил, итд - в зависимости от типа задачи) с методами процессов (тоже в зависимости от типов - начать, отменить, отложить, установить данные, послать уведомление итд). В результате вместо диаграм мы имеем 2х уровневый список (в котором процесс называется задача): Задача1 если Закончилась -> начать Задача2 если Отменена -> начать Послать Уведомление об Отмене Задача2 если Началась -> начать Послать Уведомление о начале Задачи 2 Послать Уведомление о начале Задачи2 Ну грубо говоря так. Задачи настраиваются. Второй вход в задачу это второе исполнение. И справа от списка у нас гант - на нем рисуется план выполнения. В результате можно менять последствия процесса в результате повторного вхождения. Связывать можно только на 1 уровне. Но можно "вытаскивать" события на верх - тогда те кто используют процесс могут знать что-то о нем, при этом по-прежнему работая как с черным ящиком. Можно делать свои события на задачах - срабатывающие по определенным условиям - время или условия данных. Есть задачи типа "Ожидание" - позволяют объединять процессы в 1 - когда, например, нужно дождаться нескольких событий. В результате у нас процессы описываются не диаграммами а событиями-методами вместе с планом. В отличие от диаграмм мы можем работать с множественными исполнениями задачи по-разному. На диаграммах это было бы третье измерение, что, очевидно, никуда не годится - даже 2х мерные диаграммы часто выглядят неочевидно. Как Вам такой подход к описанию процессов? В системе есть наборы структур - организационная структура компании, структура квалификаций, структура географических мест (с типами и ценообразованием), структуры материалов и оборудования(аналогично). Задачи имеют роли и оперируют ролями (на них указываются требования к квалификациям и в результате возможен побдор агентов по загруженности, месту, квалификации). Существуют и просто объекты. Можно создавать классы объектов, описывать их, создавать сущности и оперировать ими во время процессов. Планирование как таковое, в системе это всего-лишь определенная вероятность. Иначе быть вроде как и не может - если неочевидно, что задачу надо будет выполнять, то вероятность не 100% и мы это можем честно сказать. А зная историю, мы можем уточнять эту вероятность. Как Вам кажется - это покрывает насущные нужды? И вообще выглядит понятным, логичным, сбалансированным? Понятно, что там где процессов нет "by design", там вообще проблемы с автоматизацией. Но все-же процессы формадизовать как-то надо, иначе очень трудно что-либо делать с ростом.