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