Базовые допущения BPMN:

1. Вся информация сохраняется
2. У организации есть механизм назначения и передачи поручений
3. К каждой задаче прилагается инструкция
4. У задач есть нормативные сроки, а у организации - механизм их контроля

4. У задач есть нормативные сроки, а у организации - механизм их контроля

Стандартный вопрос: как показать на диаграмме, что задача должна быть выполнена за 2 часа?

Ответ: обычно это никак не надо изображать. Просто договоримся раз и навсегда, что:

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

Если процесс реализован в BPMS, то можно ожидать, что для контроля в нашем распоряжении будет, во-первых, динамическая отчетность BAM (Business Activity Monitoring), показывающая состояние дел в процессной системе сначала «с высоты птичьего полета», потом, через механизм drill-down, детализированное хоть до отдельного экземпляра процесса. Во-вторых, система предоставит возможность настроить автоматические напоминания о том, что задача назначена, просрочена или снята с исполнителя, которые будут отправляться по email исполнителю или его непосредственному руководителю (а скорее – обоим).

Если процесс исполняется без поддержки BPMS, то на контроль придется расходовать интеллектуальные ресурсы менеджмента – планерки, звонки, устные напоминания… К слову, избавление от этой нервотрепки – один из эффектов использования BPMS, который часто недооценивается.

Но и в том, и в другом случае контроль сроков – это не уровень процессного управления. Это уровень task management – управления поручениями. В конце концов, задачи могут приходить из процессов, из проектов, из процедур, реализованных в корпоративных системах, из кейсов или просто назначаться разово – вариантов много, но во всех у задачи должен быть нормативный срок и способы его контроля.

В принципе, смоделировать в BPMN стандартный контроль сроков исполнения задач достаточно легко –

Но если быть последовательными, мы должны к каждой содержательной задаче прицепить таймер и задачу «Разобраться с просрочкой». Вас такая перспектива радует? Меня – нет. Поэтому я и предлагаю считать, что это уровень управления задачами, а не процессами.

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

Заметим кстати, что в обычной ситуации превышения фактического срока над нормативным – это не криминал. Если в качестве нормативного срока мы установили среднее время выполнения задачи, то (при условии близости распределения времени выполнения к нормальному) он будет превышаться приблизительно в 50% случаев. И это не будет свидетельством недисциплинированности исполнителя. Просто мы установили напряженный норматив, и это лучше, чем завышать норматив для того, чтобы с комфортом в него укладываться.

Использовать таймеры надо только тогда, когда нам надо показать какие-то действия, отличные от рутинного контроля сроков.

Пример 1: подготовка коммерческого предложения. Если в запросе покупателя установлен жесткий срок подачи предложения, и мы в него не уложились, то продолжать работу над предложением смысла нет:

Пример 2: ожидание доставки. Если груз не пришел в установленный срок, надо связаться с транспортной компанией: