В поисках теории, или Некоторые аспекты планирования проектных работ

Александр Коноваленко, старший инженер по САПР, ООО «Забайкалзолотопроект»

На нашем предприятии уже шесть лет активно и достаточно успешно эксплуатируется система управления проектными работами ЛОЦМАН:ПГС. За годы эксплуатации система помогла реализовать десятки проектов, с ее помощью выполнялись задачи по организации архива электронной документации, файлового архива, системы выдачи заданий. Естественно, когда на рынке появились модули планирования (Rubius Project Manager) и учета трудозатрат, они не могли не вызвать у нас интереса, тем более что задача автоматизации управления проектным процессом стоит давно и остро. Возник большой соблазн объединить в одном информационном пространстве не только проектную документацию и рабочие материалы, как было ранее, но и процессы их обработки в ходе проектной деятельности.

Сказано — сделано. Программные продукты были приобретены, при помощи наших давних друзей — ООО «АСКОН­Енисей» — выполнена первичная настройка системы, проведено экспресс­обучение специалистов, которым предстояло работать с новыми модулями, а дальше… Дальше пришлось сесть и серьезно поразмыслить.

Для начала мы озаботились поиском теоретических исследований в области автоматизации управления проектными работами. И тут нас ждал сюрприз: таковых практически не оказалось. Единственная, действительно серьезная работа, посвященная этому вопросу, — «Автоматизация управления разработкой проектной документацией» (В.В. Бучацкий, И.В. Бучацкий, С.В. Жучков, В.Х. Отман. М.: МГСУ, 2008) была нами прочитана буквально с карандашом в руках. Что­то оттуда мы приняли к сведению, что­то нам не подошло, во всяком случае, наши теоретические изыскания на этом пришлось закончить. Время шло, и, с теорией или без теории, необходимо было действовать.

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

Рис. 1. Схема взаимодействия участников процесса проектирования

Модель максимально расширили, включив в нее стадии, напрямую с принятием проектных решений не связанные, однако серьезно влияющие на конечный результат проектирования: подготовку заданий, договоров, различные согласования, экспертизу и т.п.

Следующим этапом стало рассмотрение процесса проектирования с точки зрения взаимодействия его участников в системе управления проектными данными (СУПД). Соответственно, заказчик, эксперт и управляющая компания в этой модели не рассматривались, а модель строилась таким образом, чтобы в едином производственном процессе были связаны как принятие проектных решений, так и подготовка, планирование и осмечивание проектных работ (рис. 2).

Рис. 2. Модель процесса разработки и согласования проектно-сметной документации

Модель позволила определить основные ролевые функции участников процесса и связать их с функционалом СУПД. Так, в соответствии с ней, главный инженер проекта выполняет регистрацию ТЗ, создает план­график работ, выдает задания проектным бюро, согласовывает проектные решения и электронные документы и т.п.; начальник бюро — получает задания от ГИПа, при необходимости выполняет декомпозицию задач плана до уровня исполнителей, выдает задания и контролирует их выполнение проектировщиками; специалист планово­экономического отдела отвечает за подготовку договора и сметы на проектные работы.

Итогом анализа модели стал пакет нормативной документации, утвержденный приказом директора и, с момента принятия, определивший порядок прохождения как проектной, так и организационной документации:

• регламент разработки, согласования, утверждения и выпуска проектно­сметной документации;
• ролевая инструкция главного инженера проекта;
• ролевая инструкция начальника бюро;
• ролевая инструкция главного специалиста бюро технического контроля;
• ролевая инструкция специалиста планово­экономического отдела;
• ролевая инструкция инженера­проектировщика;
• ролевая инструкция специалиста по оформлению и выдаче проектной документации.

Дальнейшая работа развивалась по двум направлениям: изменения в конфигурации ЛОЦМАН:ПГС для обеспечения требований Регламента и разработка отчетов, позволяющих участникам проектного процесса получать информацию о состоянии работ, выполнении заданий, отдельные виды организационной документации.

Так, поскольку Регламент требовал хранить в главном дереве проекта не только проектную, но и организационную документацию, была проведена дополнительная настройка ЛОЦМАН:ПГС. В частности, для хранения организационных документов были созданы новые объекты: тип — Папка организационной документации и документ Организационный документ (рис. 3).

Рис. 3. Новые объекты в окне конфигуратора ЛОЦМАН

Папка организационной документации входит в состав проекта и может хранить только объекты типа Организационный документ.

Специальный атрибут Вид организационного документа, помогает отнести организационные документы к определенным типам: договор, смета, план­график и т.п. (рис. 4).

Рис. 4. Атрибут Вид организационного документа

Доступ к организационной документации регулируется администратором системы с помощью Конфигуратора ЛОЦМАН:ПГС.

В ходе работ по второму направлению был разработан пакет отчетов (пока весьма скромный, в будущем мы надеемся его значительно расширить). Так, отчет Планы по проекту позволяет получить укрупненную информацию о планах, связанных с выбранным проектом, об их статусе и сроках работ (рис. 5).

Рис. 5. Отчет Планы по проекту

Рис. 6. Сводка по активным планам

Отчет Активные планы также содержит укрупненную информацию, но исключительно по планам, не имеющим статус Завершен или В архиве (рис. 6).

С помощью отчета Сопоставление плановых и фактических показателей можно оценивать и контролировать выполнение уже не планов в целом, а отдельных задач (рис. 7).

Отчет Смета (рис. 8) — один из самых важных отчетов в системе, поскольку позволяет оценить как трудозатраты на проектные работы, так и стоимость проекта с учетом накладных расходов.

Рис. 7. Сопоставление плановых и фактических показателей

Рис. 8. Смета на проектные работы

Здесь хотелось бы выразить благодарность сотрудникам компании «АСКОН­Енисей», превратившимся за почти десятилетие сотрудничества из деловых партнеров в наших добрых друзей. Мы чувствовали их поддержку и в тот период, когда, практически вслепую, приступили к выработке концепции системы управления, и на стадии методической проработки, не говоря уж о помощи в решении технических проблем, неизбежно возникавших по ходу реализации проекта.

Конечно, вряд ли можно считать идеальными описанные выше модели и собственно пути решения проблемы управляемости проектного процесса. Все­таки, прорабатывая их, мы основывались на реалиях нашего собственного предприятия и ни в коем случае не претендовали на какие­то глобальные обобщения. Но мы будем рады, если изложенный материал окажется полезным и поможет кому­то снять часть проблем, с которыми мы столкнулись в ходе работы. Тем более что сворачивать работы по развитию системы проектного документооборота мы, в ближайшей перспективе, не собираемся, и, думаю, в дальнейшем у нас будет возможность информировать читателей о наших новых шагах по этому нелегкому пути.