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

На первый взгляд, автоматизировать процессы реализации проекта не сложно, ведь каждый из этих этапов – инициация, планирование, выполнение, мониторинг и управление и завершение – не сложно. Но есть два «но», реализовать которые не так просто, как это кажется на первый взгляд.

Первое «но» — это выполнение. Как правило, проект (его содержательная часть) разбит на несколько этапов. И каждый этап, в свою очередь, может быть разделен на этапы и работы. Такое деление может быть неравномерным, где-то на два уровня, где-то на три, и, соответственно, описать такую детализацию напрямую в виде процесса невозможно.

Второе «но» — это мониторинг и управление. Если от мониторинга мы ожидаем только его непрерывности и возможности получать данные в любое время, то управление не так «безобидно», как может показаться на первый взгляд. Управление подразумевает, что в проект могут в любой момент добавляться этапы и работы. Или наоборот, некоторые этаны могут быть отменены или изменены. И эти изменения должны «подхватываться» процессом на лету.

Если бы речь шла о регламенте без автоматизации процесса, то достаточно было бы ограничиться множественным процессом и заданием «Выполните все задачи этапа». Контроль выполнения задач и сроков оставался бы на исполнителе. Когда же речь идет об автоматизированном процессе, то закономерным становится ожидание того, что все сроки и статусы на всех уровнях контролируются системой. И тут простого множественного процесса недостаточно.

Мы смогли решить обе эти проблемы, реализовав рекурсивный запуск этапов и работ, что позволило создавать уровни и подуровни любой глубины, добавлять этапы и работы и вносить изменения в уже запущенные. И речь идет не о кодировании, а о схеме процесса. Мы сделали это средствами BPMN. Второй секрет успеха – в модели данных, которая позволяет реализовать такой процесс. Таким образом уникальной в нашем решении является модель процесса (схема+модель данных). Ниже приведена схема общего процесса управления проектом и схема выполнения этапов и работ.

Общая схема управления проектом

Выполнение этапа/под-этапа/работы

Наш проект реализован в Bizagi Digital Platform, но при наличии поддержки BPMN модель можно реализовать в других системах, оставляя в них разработку интерфейсов и прочие детали.