Cистема электронного контроля

Контроль хода выполнения проектных работ является одной из важнейших функций управления проектами. В условиях проектных организаций, когда идет параллельная работа над проектной документацией для многих объектов, по множеству договоров, такой контроль является достаточно трудоемкой задачей. Если возложить этот контроль на руководителя команды проекта – т.е. ГИПа, то выполнение этой функции будет отнимать у него массу времени. При этом практически никакой возможности объективно оценить обстоятельства, затрудняющие ход его проекта, у него нет: производственные подразделения выполняют одновременно работы по множеству проектов, в том числе и руководимых другими ГИПами, и приоритет его работы над другими отсутствует или, во всяком случае, определяется не им. Отсюда следует необходимость централизации этой функции на уровень офиса управления портфелем проектов. Следовательно, в этом офисе должна быть группа или, по крайней мере, один сотрудник, повседневно отвечающий за этот контроль. Такого сотрудника мы и называем диспетчером. полномочиями контролировать состояние работ и (по поручению руководства) определять их приоритеты. При большом количестве одновременно выполняемых работ его загрузка достаточно велика, и вряд ли его можно существенно загрузить чем-либо еще. Между тем вопрос о выделении специального сотрудника для выполнения диспетчерских функций достаточно болезнен, особенно в небольших проектных организациях, где каждый человек на счету. понимают сложность этой проблемы. Мы многое делаем для того, чтобы снизить нагрузку на диспетчера. Самым первым принципиальным решением в этом направлении было решение не контролировать внутренние события подразделений – контролю подлежит только обмен информацией между подразделениями-участниками. Это решение оправдано еще и потому, что получить объективные данные о выполнении внутренних событий диспетчеру достаточно трудно. Даже если это ему удается, он не может принимать через голову начальника подразделения такие решения, которые касаются внутреннего документооборота подразделения. Поэтому отказ от такого контроля сокращает число событий в графике. Одновременно появляется возможность документально фиксировать выполнение события путем подписей его участников – выдающего информацию, принимающего ее и ГИПа. Это – тоже облегчение работы диспетчера, так как фиксация выполнения событий в базе данных на основе таких документов может производиться не секунда в секунду, а с некоторой периодичностью, например, один раз в день. система электронного технического документооборота, то обмен заданиями и, соответственно, фиксация выполнения событий может быть реализована в такой системе путем маршрутизации заданий. В этом случае фиксация выполнения идет вообще без диспетчера, однако получить общую картину состояния всего портфеля проектов на текущий момент ему достаточно трудно. Тем более трудно отразить это состояние в базе данных ПЛАН-Про. Поэтому разработка информационного «моста» между системой документооборота и ПЛАН-Про становится насущной задачей. У авторов есть положительный опыт построения такого «моста» с одной из систем документооборота – Lotsia. Правда, обмен был односторонний – созданный в ПЛАН-Про график служил основной для автоматической маршрутизации заданий; однако вполне реально построить и обратный обмен – передачу в ПЛАН-Про данных о факте выполнения событий. Но далеко не всем проектным организациям пока по силам обзавестись и тем более – адекватно настроить систему электронного документооборота. Поэтому авторы ПЛАН-Про в версии 2.6 реализовали набор режимов, который позволяет воспроизвести некоторые функции системы документооборота, одновременно снизив нагрузку на диспетчера. Идея этих режимов состоит в том, чтобы вместо подписей на бумажном документе предоставить возможность фиксировать процесс обмена информацией руководителям производственных отделов и ГИПам. Прежде всего отметим, что использование электронного контроля не является обязательным: она может быть включена или выключена в Настройке (закладка «Диспетчеризация»). Если электронный контроль включен, то для его использования совершенно необходимо, чтобы в работе с комплексом участвовали начальники подразделений и ГИПы. Рассмотрим, как происходит учет хода выполнения графика при электронной регистрации. Начальник отдела, имея на руках подготовленное задание смежным подразделениям (не имеет значения – в бумажном или электронном виде), входит в комплекс на закладку «Диспетчеризация» и видит на ней кнопку «Выдача».

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

Здесь ГИПу видны события по его графикам, которые помечены начальниками отделов как выдаваемые. Кроме того, он видит свои события, а также события субподрядчиков, у кото-рых предшествующие события отсутствуют или все они состоялись. Для этого он должен в поле «Исполнители» указать название подразделения, под которым он фигурирует в графике. Выполнив необходимые действия, ГИП установкой «птички» в соответствующем чек-боксе разрешает прием заданий подразделениями-получателями. У ГИПа есть еще один важный инструмент. Открыв соответствующий график, он может в последней графе, которая называется «Без контроля», поставить «птичку» в чек-боксе. Это означает, что соответствующее событие ГИП не будет контролировать: либо он считает его малозначительным и полностью доверяет начальникам соответствующих подразделений; возможно, он уезжает в командировку и не хочет, чтобы его отсутствие тормозило ход выполнения работ.

Теперь, когда содержание события проконтролировано ГИПом, руководители принимающих подразделений увидят их в режиме «Прием». Проверив содержание полученного задания, они делают отметку в соответствующем чек-боксе. Задание принято. Когда будет поставлена последняя отметка со стороны принимающих это задание подразделений, в графике будет автоматически поставлена текущая дата - фактическая дата выполнения этого события.

Таким образом, получается, что диспетчер при электронной регистрации вроде бы и не участвует в процессе. Однако это не совсем так. Действия довольно большого числа участников процесса чреваты ошибками и неточностями – человеческий фактор все-таки не всегда надежен. Кто-то забыл сделать отметку, кто-то случайно отметил не то событие, которое должен был… Поэтому сотрудник, выполняющий функции диспетчера, имеет в своем распоряжении режим, позволяющий видеть всю картину и исправить любую ошибку. Этот режим так и называется – «Диспетчер». Доступ к нему должен быть отмечен в распределении прав у сотрудника, выполняющего функцию диспетчера. Здесь можно вызвать любой график и видеть все отметки. Любую из них можно снять или установить заново. Фиксируется не только факт выдачи-контроля-приема, но и дата и время, когда это произошло. Двойной клик в графе «Прием» открывает окно, в котором видно, какие из принимающих подразделений уже приняли задание, а какие – не приняли. Таким образом, для диспетчера картина полностью прозрачна. Вместе с тем его загрузка в разы меньше, чем без электронной регистрации; его вмешательство требуется лишь эпизодически, и поэтому функции диспетчера могут быть поручены сотруднику, который имеет какие-либо другие обязанности и может их совмещать. В одной из московских организаций так и поступили (еще не дожидаясь выхода версии 2.6, но зная о ее разработке): функции диспетчера поручены секретарю генерального директора… Разработчики комплекса видят возможности дальнейшего развития этого направления. Например, фиксация дат позволяет контролировать соблюдение регламента; например, если на прием задания по регламенту установлен срок в 1 рабочий день, то по зафиксированным датам можно установить факт нарушения этого срока. Однако в данном случае фиксируется момент не передачи самой информации, а момент готовности к ее передаче. Поэтому авторы предполагают сделать следующий шаг – организовать формирование из базы данных ПЛАН-Про электронного письма или иного сигнала, извещающего участников процесса о наступлении того или иного события. Возможно, это потребует использования таких средств, как Outlook Express или Lotus Notes, которые распространены в проектных организациях в качестве средства внутренней коммуникации. Не исключено, что эти возможности будут реализованы еще в рамках версии 2.6 – по крайней мере, все необходимые для этого структурные изменения в базе ПЛАН-Про уже сделаны.