Применение электронного контроля выполнения работ

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

Рис.1. Схема взаимодействия рабочих мест в режиме «Электронный контроль».

В организациях, которые далеко продвинулись в создании систем электронного технического документооборота, эта проблема решалась путем определения маршрута тех или иных проектных документов. Однако в основе этих маршрутов так или иначе лежал график. И если он создавался в комплексе ПЛАН-Про, то создавалась возможность сравнительно легким путем получить маршрут заданий. Для этого график импортировался в систему документооборота, и на его основе маршрут строился автоматически. Соответственно и отслеживание состояния выполнения событий графика существенно упрощалось. Такого рода информационный обмен был реализован в организации, которая использовала систему документооборота Lotsia PDM.

Рис.2. Режим «Выдача»

Но в организациях, которые не создали у себя систему электронного технического документооборота или находились только на старте этого пути, возникала необходимость документировать обмен заданиями на уровне бумажных или электронных форм. Такими формами когда-то были журналы учета выдачи заданий, которые были в каждом подразделении. Но диспетчеру было трудно их использовать, поэтому вводились бумажные формы – вроде квитанций, в которых при соответствующем заполнении расписывались руководители отдела, выдающего задание, и  отделов, это задание принимающих, а также, при необходимости, ГИП. Такая «квитанция» в конечном счете поступала к диспетчеру, и на ее основе он отмечал, что то или иное событие состоялось. Чтобы избавиться от такой неудобной технологии учета, в версии 2.6 (февраль 2011 г.) появились режимы «электронного контроля», которые в версии 2.7 (декабрь 2011 г.) были усовершенствованы. Этих режимов четыре. Два из них («Выдача» и «Прием») принадлежат начальникам подразделений; ГИП располагает режимом «Контроль», а диспетчер – режимом, который так и называется «Диспетчер». Схема взаимодействия этих режимов приведена на рисунке 1. Начальник подразделения, входя в режим «Выдача», видит в открывшейся таблице   список своих событий из разных графиков, у которых все предшествующие события (если они есть) уже состоялись. Иначе говоря, он имеет все необходимое, чтобы продвинуть свою работу до выпуска этих событий. Когда данные того или иного события его подразделение подготовило и может выдать (причем природа эти данных – бумажный или электронный чертеж, файл  и т.д. – совершенно безразлична), он делает отметку в таблице в графе «выдача» (рис.2). При этом автоматически генерируется электронное письмо, адресованное ГИПу и содержащее текст о том, что такое-то задание готово к выдаче.

Рис. 3. Режим «Контроль».

Теперь ГИП, во-первых, проинформирован, что это задание выдается, и, во-вторых, может с ним ознакомиться и вынести свое суждение о его полноте и качестве.  В этой же таблице ГИП видит и те задания, которые должен выдать он сам, а также те, которые должен выдать или принять субподрядчик – имеется в виду, что обмен заданиями с субподрядчиком осуществляется через ГИПа. У ГИПа в его таблице для каждого события есть возможность поставить одну из двух отметок: «Контроль» — если он согласен с содержанием задания (или выдает свое или субподрядное), или «Возврат» — если он не согласен. Если он отметил «Контроль», то получателям этого задания автоматически высылается электронное письмо о возможности принять задание. При этом соответствующее событие становится видимым руководителям принимающих это задание подразделений в таблице режима «Прием».  (рис.4). Таких подразделений может быть несколько. У каждого из них в таблице приема также есть возможность поставить одну из двух отметок – «Прием» или «Возврат». Если все принимающие подразделения отметили «Прием», то в момент, когда эту отметку поставил руководитель последнего принимающего подразделения, в график автоматически заносится  текущая дата, означающая, что событие выполнено.

Рис.4. Режим «Прием».

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

Рис. 5. Режим «Диспетчер».

Причем каждая отметка ему видна с датой и временем, когда она проставлена. Более того, он может и вмешаться в процесс – снять или поставить любую такую отметку, если это необходимо. Такие права возлагают на него ответственность за свои действия, но он, конечно, будет вмешиваться в процесс только в исключительных случаях. Что в результате? Функции диспетчера существенно сократились. Теперь нет нужды выделять сотрудника, который бы целыми днями был озабочен контролем за ходом процесса. У него еще остались некоторые обязанности, но они значительно проще. Появилась возможность возложить функции диспетчера на сотрудника, который совмещает их с другими обязанностями. Так, например, уже в двух организациях функции диспетчера возложили  на секретаря директора… По сути дела эта система из четырех режимов моделирует функции развитого электронного технического документооборота и оказывается удобной для организаций, где такой документооборот еще не организован. Еще одна деталь. Все события, на которые оформлен возврат, сопровождаются записью в специальной таблице. Эта таблица позволяет проанализировать причины возвратов за определенный период и сделать необходимые выводы, как того требуют стандарты систем менеджмента качества. Например, провести дополнительное обучение, изменить «стандартную» форму тех или иных заданий… Мы надеемся, что усилия последних лет, вложенные разработчиками ПЛАН-Про в развитие блока «Диспетчеризация» , помогут организациям-пользователям ПЛАН-Про эффективно решить одну из труднейших проблем управления разработкой проектной документации.