Технологии проектирования: разработка и применение

  • Алексей Сёмин
    методолог
  • Сергей Макаров
    директор по технологии
  • Оксана Бондарь
    ведущий специалист по коммуникациям
1. ТХПР 1.0: повышение качества планирования

Алексей Сёмин, автор идеи Инициатора и ТХПР, методолог компании СибТехПроект:
«В СибТехПроекте нет и никогда не было планового отдела. Мы уверены, что хорошо запланировать проект может только тот, кто сам проектирует. Функции планового отдела распределены между всеми сотрудниками, план не задается сверху, а формируется и корректируется на основании актуальных данных. Это называется низовым планированием, и чтобы оно стало возможным, нам нужен был инструмент для сбора актуальных данных и преобразования их в удобный для анализа вид. Мы не нашли программу, которая в полной мере учитывала бы специфику нашей работы, и поэтому решили разработать свою. Так появился Инициатор».

1.1. ТХПР как основа для автоматизации управления

Разработка технологий проектирования в СибТехПроекте началась в 2014 году с целью повышения эффективности работы ERP-системы Инициатор, созданной для управления сроками и трудозатратами проекта.
Для полноценного планирования и управления с помощью Инициатора было необходимо понимание содержания работ — последовательности разделов, блоков и задач — и единое представление о процессе проектирования.
Рис. 1. Планирование работ и управление сроками в СибТехПроекте выполняется при помощи ТХПР, сетевого планирования и отчетов программы Инициатор
Роман Петрушкевич, руководитель проекта, участник разработки ТХПР 1.0:
«У нас уже был опыт работы в одной команде, мы представляли, какие работы и в какой последовательности мы выполняем, какие существуют связи между отделами и на какие нюансы следует обратить внимание. Мы составили схемы, описывающие нашу работу на примере конкретного объекта, который тогда начали проектировать».
1.2. Достижения: единый порядок работ, синхронность действий отделов, допустимые сроки задач
Работа над первой версией ТХПР продолжалась примерно полгода, в ней приняли участие восемь человек (руководитель проекта, начальники отделов и собственник компании).

В процессе разработки ТХПР мы составили полное видение процесса проектирования, выделили его ключевые элементы (разделы) и определили содержание работ (блоки и задачи).
Результатом стал атлас технологических карт, включающий технологические схемы нескольких альбомов — АР, КР, ОВ, ВК. Каждый альбом (раздел) состоял из набора блоков, где была представлена последовательность выполняемых задач.
В процессе разработки ТХПР мы синхронизировали содержание работ и получили согласованный набор блоков в разделах и задач в этих блоках, что решило проблему разного способа выполнения задач в разные сроки. Теперь стало возможным планировать сроки с достаточной степенью точности.

Роман Петрушкевич: «Мы отказались от идеи сделать несколько универсальных шаблонов для разных проектов. Наиболее практичным оказался принцип Лего — мы создавали схемы блоков, которые составляли раздел. При необходимости эти схемы можно было выстраивать в нужной комплектации и последовательности, формируя технологию проектирования конкретного объекта в зависимости от имеющихся ресурсов».

Ведущие проектировщики стали использовать ТХПР для определения сроков задач, что существенно повысило качество планирования сроков на малых операциях.

Рис. 2. Часть блоков расположена параллельно — значит, их могут выполнять одновременно несколько исполнителей. Если раздел выполняет один человек — блоки можно делать последовательно. Ведущий проектировщик выбирает наилучший вариант, исходя из конкретной ситуации.
Атлас ТХПР оказался отличным инструментом для обучения новых сотрудников, которые, изучая схемы, сразу видели содержание работ, связи между разделами и весь комплекс работ компании в целом.

Сергей Макаров, директор по технологии:
«В один прекрасный день мы обнаружили, что проектировщики выполняют абсолютно ненужную операцию только потому, что она включена в технологическую схему. Схема составлялась под требования определенного заказчика, а в дальнейшем использовалась без адаптации. Эта ненужная операция занимала немало времени, и ее исключение из технологической схемы позволило сократить общие трудозатраты».
1.3. Недостатки ТХПР 1.0: привязка к одному объекту и сила привычки
Основным недостатком ТХПР 1.0 стала привязка к конкретному объекту. При расширении пула заказчиков и изменении требований к проекту оказалось, что часть операций, включенных в ТХПР, — избыточна, а каких-то, наоборот, не хватает. Эта проблема усугублялась отношением некоторых ведущих проектировщиков к ТХПР как к прямому руководству к действию, в то время как технологические схемы в большей степени являются эскизом, требующим доработки в соответствии с требованиями конкретного заказчика.

Рис. 3. На диаграмме Ганта показаны трудозатраты задачи, которая выполнялась по инерции. Анализ схем ТХПР перед началом работы позволил отсеять лишние задачи. Кроме того, внедрение новой системы оплаты труда (ЭСОТ) в СибТехПроекте мотивирует сотрудников сокращать трудозатраты и не выполнять ненужную работу.
Первый вариант ТХПР не был универсальным, и то, что он был создан на примере конкретного объекта, впоследствии показало свои минусы. Однако на то время это было серьезное достижение — мы добились прозрачности процесса проектирования, определили содержание работ и с помощью Инициатора начали планировать работу, контролировать сроки и трудозатраты на основании реальных данных.

2. От тхпр к сетевому планированию
Разработав ТХПР как основу для планирования в Инициаторе, мы мечтали о том, как легко будем составлять планы и быстро корректировать их. Однако все оказалось не так просто. При работе в диаграмме Ганта установление связей задач и перепланирование занимало много времени. Высокая трудоемкость практически сводила к нулю идею оперативного планирования и прозрачности рабочего процесса — изменения не вносились в Инициатор или вносились с большим опозданием. Ведущие проектировщики стали понемногу игнорировать работы по планированию — из-за больших трудозатрат на составление графиков не хватало времени на остальные задачи.
Планирование рисковало превратиться из инструмента управления в самоцель, а вместо сокращения трудозатрат могло кратно увеличить их. Необходимо было разработать другой, более эффективный, инструмент для планирования.

Рис. 4. Диаграмма Ганта хороша для контроля сроков, но для связей задач и вариантного планирования она недостаточно удобна. Наибольшие неудобства доставляла сложность корректировки линейного графика при изменениях в проекте.
Оказалось, что решение уже было давно найдено — в конце 1960-х – начале 1970-х годов в СССР был всплеск публикаций, посвященных планированию в проектных организациях, где в качестве наиболее оптимального метода рассматривалось сетевое планирование. Авторы называли этот метод наиболее соответствующим специфике работы проектной организации — сетевой план позволяет определить набор необходимых задач, установить связи между отделами и управлять сроками благодаря гибкому планированию — изменению связей между задачами и отделами при изменении условий. Сетевой график прекрасно решает задачу рационального распределения задач, устанавливая последовательность их выполнения.
Однако на тот момент эти идеи не получили дальнейшего развития — их практическое воплощение оказалось невозможным из-за недостаточного уровня развития вычислительной техники. Работа с сетевым графиком предполагает постоянные изменения, рассчитать и отобразить которые при тогдашних мощностях ЭВМ было невозможно. Перспективное направление тогда было остановлено из-за технических причин.

Рис. 5. Книги из фонда Российской Государственной библиотеки, посвященные применению методов сетевого планирования в проектировании

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

Имеющиеся в СибТехПроекте технологические карты стали основой для внедрения сетевого планирования. В апреле 2019 года в программе Инициатор появился модуль Сетевой план. С помощью сетевого плана мы связали блоки и разделы ТХПР, получив полную картину проекта, всех его задач и связей.

Рис. 6. Пример фрагмента сетевого графика в Инициаторе. На графике обозначены связи задач, продолжительность работ по задаче и статус задачи. Значок задачи интерактивен — по клику открывается карточка задачи, и ведущий проектировщик получает всю информацию для планирования.

Сетевой план, основанный на технологических схемах ТХПР, повысил точность планирования и синхронизацию работ в СибТехПроекте, а также помог найти возможности для сокращения трудозатрат. Мы отметили следующие достоинства сетевого плана в практике низового планирования:
  1. Простота: внесение и обновление данных и установление связей задач стало более простым.
  2. Информативность: вся важная информация о задаче видна сразу, не требуется дополнительных переходов.
  3. Вариативность: изменение сетевого плана и создание кратчайших путей позволяет сокращать трудозатраты.
  4. Внимание к деталям: можно детализировать определенный этап работ.
  5. Широта охвата: на одном экране виден весь проект со всеми связями и задачами.
Для повышения скорости планирования на основе ТХПР в Инициаторе был создан шаблон сетевого плана проекта. Перед началом работы ведущим проектировщикам не нужно создавать план с нуля — нужно просто внести необходимые изменения в шаблон.
3. Тхпр 4.0: управление рисками и контроль качества
За время существования ТХПР технологические карты не раз редактировались для актуализации и детализации описанных процессов. Версии ТХПР 2.0 и 3.0 принципиально не отличались от версии 1.0, изменения касались непосредственно производственных задач — в схему вносились коррективы, связанные с тем, какие задачи и в какой последовательности составляют блок.
В мае 2022 года началась работа над версией ТХПР 4.0. В этот раз изменения предполагалось достаточно серьезные — помимо актуализации последовательности и набора задач, в технологические карты нужно было внести дополнения для организации системы контроля качества. Мы видели ресурс повышения производительности труда и сокращения трудозатрат в существенном повышении качества работ.
Идея «каждый сотрудник отвечает за качество» должна была стать не просто словами, а частью технологического процесса. В ТХПР 4.0 особое внимание уделено описанию результата работ блока и контролю качества результата. В схемах появились чек-листы отдельных задач и ссылки на чек-листы результата в Инициатор.
При создании новой версии ТХПР мы отошли от принципа фиксирования ситуации и занялись моделированием процесса, закладывая в схемы ТХПР работы, которые не относятся непосредственно к созданию моделей и чертежей, но которые необходимы для контроля качества. Так, у ведущих проектировщиков появился новый тип задач — задача проверки. Также появились совершенно новые задачи — задачи защиты проектных решений.

Рис. 7. Пример схемы. Задача защиты внесена в ТХПР для того, чтобы исключить ошибки и коллизии еще на этапе планирования, при совместном обсуждении решения

Новая версия существенно расширила функции ТХПР — теперь технологические карты используются не только в планировании и реализации производственного процесса, но и в организации процесса управления качеством и рисками по срокам.
На основе ТХПР в СибТехПроекте разработана система контроля качества и управления рисками. В технологические карты внесены дополнения, позволяющие организовать процесс непрерывного контроля качества, в который вовлечены все участники проектной команды.
4. советы по разработке тхпр
На наш взгляд, разработать свои технологии проектирования может любая проектная компания. Как правило, вопрос о необходимости разработки технологии проектирования возникает, когда число сотрудников достигает 40-50 человек (в СибТехПроекте к началу разработки ТХПР было чуть более 40 сотрудников) — компания такого масштаба уже выходит из условной «ремесленной» или «мануфактурной» стадии развития и «ручного» управления. Переход на BIM становится решающим фактором — огромное количество технологических деталей требует точных технологических норм, рациональной организации производственного процесса и синхронизации действий его участников.

Рис. 8. Экспресс-тест на определение потребности компании в технологиях проектирования

Вам нужны технологии проектирования, если:
  • в компании больше 40 человек,
  • работаете в BIM,
  • стремитесь к прозрачности процессов,
  • намерены всерьез заняться планированием.
На что нужно обратить внимание, принимаясь за разработку ТХПР:
  1. Технология и команда. В первой версии ТХПР вы будете описывать процесс «как есть». Скорее всего, в ходе описания вы обнаружите лишние элементы, дублирования, пропавшие связи — вы это выясните, проводя обсуждения в команде, имеющей опыт совместной работы.
  2. Квалификация ведущих проектировщиков (начальников отделов). Именно они владеют всей информацией о деталях процесса проектирования в рамках раздела.
  3. Квалификация проектировщиков. От квалификации проектировщиков зависит степень детализации технологических схем — нужно ли расписывать процесс до мелочей или достаточно обозначить самые основные задачи. Мы решили вопрос так: в схему вошли ключевые задачи, а необходимые пояснения к ним составили инструкцию. При необходимости пояснения к задаче в схеме дается ссылка на соответствующий раздел в инструкции. Схема выглядит более простой и понятной, опытный сотрудник не отвлекается на детали, менее опытный — может получить пояснения в инструкции.

Рис. 9. Пример схемы: задачи с прямыми ссылками на инструкцию

Процесс разработки ТХПР:
  1. Составляем технологические карты разделов (предварительных). Ведущий проектировщик (начальник отдела) описывает работу своего отдела: определяет блоки, определяет задачи внутри блоков, определяет связи задач, конечные и промежуточные результаты, условия начала работы, получаемые и передаваемые задания. Составлять схемы удобнее с помощью онлайн сервисов для рисования графиков, мы использовали drawio.io.
  2. Разрабатываем условные обозначения схемы. Можно использовать условные обозначения схем ТХПР СибТехПроекта, можно разработать собственные. Для этого нужно провести совместное обсуждение и составить легенду к схемам, описывающую все условные обозначения.
  3. Устанавливаем связи между разделами и корректируем технологические карты. На совещании ведущих проектировщиков (начальников отделов) с участием руководителей проектов (ГИПов) анализируются технологические карты разделов, выявляются дублирующие блоки/задачи, устанавливаются связи между разделами.
  4. Составляем единый атлас схем ТХПР/Составляем сетевой план. Скорректированные технологические карты разделов сводятся в единую схему, на которой обозначены связи между разделами. Параллельно возможно составление сетевого плана. Для этой цели можно использовать сервисы, позволяющие нарисовать схему, например, можно использовать сервисы типа Miro или других аналогичных. Мы составляем сетевой план в модуле Сетевой план программы Инициатор, формируя таким образом шаблон сетевого плана проекта, который используется при планировании работ по другим проектам.
  5. Описываем результаты блоков и составляем чек-листы. Ведущие проектировщики описывают результаты конечных и промежуточных результатов в каждом блоке и формируют чек-листы проверки результатов.

Рис. 10. Возможная схема разработки ТХПР компании. Но, скорее всего, у каждой компании есть свои нюансы, которые необходимо учесть.

По нашему опыту, разработка ТХПР потребует 1,5-2 недели работы каждого ведущего проектировщика — обычно в течение 2-3 месяцев. Как для любого проекта, нужен руководитель этих работ, а также администратор (для экономии времени ведущих проектировщиков, он оформляет и редактирует схемы, ведет сопутствующие документы).
После того как ТХПР разработана, схемы составлены и размещены там, где всем сотрудникам удобно ими пользоваться, необходимо провести обучение команды. Также нужно понимать, что ТХПР требует периодической актуализации, — определите, кто и как будет заниматься обновлением и внесением дополнений в технологические схемы.
Составление технологических схем дает понимание процесса проектирования и позволяет решить многие проблемы, связанные с организацией труда. Сделав первый шаг на пути повышения управляемости компании, можно идти дальше, постоянно улучшая и развивая компанию.
о компании сибирские технологии проектирования
Сибирские Технологии Проектирования — проектная компания, специализирующаяся на разработке проектной документации объектов гражданского строительства (жилые дома повышенной комфортности). Основана в 2008 году. Все разделы проектной документации в СибТехПроекте с 2010 года выполняются с использованием BIM-технологии проектирования. Успехи компании в применении BIM-технологии и ее вклад в развитие BIM-технологий в стране подтверждены статусом «BIM-компания года» по версии Autodesk (2014-2020 гг.).