Управление договорами и контроль выполнения работ в системе управления проектной деятельностью ООО «Olimps» на базе Lotsia PDM PLUS

Руслан Анатольевич Рижко, заместитель директора департамента планово-экономической деятельности по вопросам САПР и СЭД

В предыдущей статье (№ 4’2015, стр. 36-41) было подробно рассказано о структуре разработанной в компании системы управления проектной деятельностью (далее — СУПД) на базе Lotsia PDM PLUS. В этой статье мы подробно остановимся на модуле управления договорами с учетом трудозатрат на основании заданий, выдаваемых в отделы для разработки разделов проекта.

Введение

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

Управление договорами

Одним из таких сложных процессов является управление договорной деятельностью компании, начиная от регистрации нового контракта и до отправки его в архив. Договор, согласно концепции СУПД компании, — это объект, создаваемый на основании тендера (при его наличии) или без него, который содержит полный пакет документов дела договора, включает некоторые экономические показатели и связан с заданиями в отделы для контроля трудозатрат всего контракта. Следовательно, созданный модуль при работе с договорами обеспечивает (рис. 1):

Рис. 1. Функциональная схема управления договором

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

Учет договоров (структура, связь с другими модулями)

По своему статусу договор может быть текущим или архивным. Это обусловливает их расположение в общей структуре модуля (в текущих договорах или архиве). Создавая новый договор, руководитель проекта наполняет его данными, доступными на начальном этапе работы. Это такие основные показатели, как сроки, бюджет, план выполнения, общее распределение средств между департаментами по договору (РД­1) и распределение средств между отделами департамента проектирования и инжиниринга (далее — ДПИ), состояние договорных документов в период заключения договора, права доступа к договору и пр. Регистрация дополнительных (при их наличии) объектов структуры (дополнительные соглашения, субподрядные договоры и акты) выполняется в момент их появления по ходу работы (рис. 2). Естественно, если объект может содержать образы документов, то они также размещаются в системе.

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

Рис. 2. Структура объекта дела договора

Что касается полного пакета документов договора, то он, безусловно, должен включать всю переписку — как с заказчиком, так и внутри организации. Поэтому с делом договора устанавливается связь документов организационно­распорядительного документооборота (далее — ОРД) и корреспонденции (внешней и внутренней, которая регистрируется секретариатом). Связь договора с документами ОРД и корреспонденцией является двунаправленной.

Дополнительной информацией служит связь договора с тендером, на основании которого он был создан. Эта связь также двунаправленная — она позволяет оперативно просмотреть материалы связанного тендера.

И пожалуй, наиболее важная и объемная (на данный момент реализации) связь — это связь договора и заданий в отделы, выданных для выполнения разделов проектной документации в рамках контракта. Для решения основной укрупненной задачи оперативного управления затратами — учета фактических трудозатрат договора в целом, такого уровня контроля достаточно. Дальнейшее развитие системы в части более «тонкого» управления — введение персональных заданий для контроля уже непосредственно на уровне исполнителей отдела, а также заданий между отделами для контроля плана­графика разработки проектной документации — относится к перспективным задачам и в данной публикации не рассматривается.

Контроль хода выполнения работ (сроки и трудозатраты)

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

Для этого на начальном этапе необходимо выполнить распределение средств договора между департаментами и далее — между отделами департамента проектирования (рис. 3), согласовав их с руководством. Нужно отметить, что все процессы подписания документов распределения средств по договору и распределения между отделами осуществляются в электронном виде с помощью средств документооборота Lotsia PDM PLUS (шаблонов работ). И снова возвратимся к избитому тезису о вовлечении руководства в работу системы. Первыми реальными пользователями функционала по работе с заданиями, наряду с руководителями проектов и ГИПами, стали руководители департаментов, которые согласовывают распределения. Причем нагрузка на руководство оказалась достаточно серьезной, поскольку указанные выше документы (общее по договору и распределение средств между отделами) больше не выполняются в бумажном виде. При окончательном согласовании бланки документов (с фамилиями и датами) генерируются и автоматически помещаются в систему, а каждое повторное согласование создает новую версию документа.

Рис. 3. Распределение средств между отделами

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

Далее задание проходит ряд согласований (опять же в электронном виде) согласно стандартным процедурам в компании, а затем отправляется в отдел (рис. 4). Тут нужно сделать небольшое отступление. Следуя «классике жанра», начальник должен принять задание в работу или отказать в приеме и т.п. Очевидно, что любой начальник отдела заинтересован в отсутствии перегрузки отдела. Но в алгоритме с возможностью отказа можно было бы вместо работы получить бесконечную переписку согласования. Чтобы этого избежать, было принято решение убрать возможность отказа от задания руководителем подразделения в шаблоне работ. Дополнительно в помощь отделам была реализована возможность фиксирования переписки с ГИПом или руководителем проекта в истории задания. Теперь все замечания отделов фиксируются и сохраняются.

Рис. 4. Задания в отделы по договору

Далее в ходе работы над заданием начальник отдела отчитывается о фактических трудозатратах отдела (независимо от числа конкретных исполнителей) до момента его завершения. Затем задание передается на контроль ГИПу или руководителю проекта и, если нет замечаний, завершается. В противном случае — отправляется на доработку в отдел.

Тут может возникнуть логичный вопрос: что делать с доработками по заданию или его переделками, если мы его закрыли? Ответ прост. Если при выдаче задания в отдел был оставлен резерв времени для отдела, тогда формируется новое задание и добирается необходимое для доработок время из распределения средств отдела. Если же по какой­то причине такого резерва нет (не предусмотрели, или объективно трудозатраты превысили все возможные резервы), тогда формируется внебюджетное задание, в котором вручную задаются плановые трудозатраты. Учет фактических трудозатрат осуществляется суммарно по бюджетным и внебюджетным заданиям, поскольку нам важно знать общие затраты времени.

Анализ информации

Может показаться, что описанный выше алгоритм — длинный и забюрократизированный, но, как показала практика, плюсов в нем гораздо больше, чем минусов. Не буду говорить о единой среде и оперативном доступе к любому документу и информации по договору — это все очевидно. Отмечу другой, важный для нашей компании момент. На основании реализованного алгоритма стало возможным именно «управление» трудозатратами (рис. 5). Что имеется в виду? Раньше также создавались распределения и задания, документы выдавались на бумаге и подписывались. Но в дальнейшем они не поддавались корректировке, оставаясь в начальном виде независимо от хода работ. Дальнейшее управление сводилось к реагированию на перерасход трудозатрат по итогам месяца, а чаще всего — проекта, на основании ручных отчетов руководителей отделов. Система же позволяет оценивать весь проект в целом в режиме реального времени и реагировать на негативные моменты до их наступления. Если отдел перебирает часы, ему можно оперативно добавить их из резерва, а если и этого недостаточно, тогда возможна корректировка распределений средств между департаментами и т.д. То есть включаются механизмы именно «управления». Результаты действия этих механизмов отражаются в общем информационном пространстве договора, что немедленно становится доступным всем его участникам и руководству. Ну, а для руководства возможность анализа данных в едином пространстве договора и портфеля в целом в реальном времени выполнения работ является ключевым аспектом для принятия правильных управленческих решений.

Рис. 5. Статистика исполнения заданий договора

Заключение

Если коротко подвести итог всему вышесказанному, можно отметить одно — ручные методы управления, как бы они ни были проверены временем и хороши методологически, все равно будут уступать более современным подходам с использованием автоматизированных систем. Опыт сравнительно непродолжительного использования модуля управления договорами в нашей компании показал бесспорное его преимущество перед существующей ранее схемой работы, хотя он и требует более высокой исполнительской дисциплины и детальной регламентации.

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