Публикация Школы траблшутеров

Как повысить эффективность проектного института?

Время чтения: 7 мин 5 сек
31 декабря 2022 г. Просмотров: 55

Процессная эффективность, Проекты | Яков Шмарин, Олег Брагинский

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

Работники интеллектуального труда скептически отнеслись к возможному повышению эффективности. Задуматься и изменить мнение их заставило соотношение трудозатрат к длительности проекта. Например, если на исполнение задачи теоретически требуется 16-20 человеко-часов, то реализовываться она может до нескольких недель.

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

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

Разработали реестр задач. В него вошли три основные зоны – по одной для ролей:

  1. постановщика задачи
  2. начальника отдела
  3. исполнителя.

Инициатор задачи указывает:

  1. наименование объекта
  2. имя главного инженера проекта (ГИП)
  3. задача – краткая формулировка идеи или конструкции
  4. дата постановки – момент, когда поручение внесли в таблицу
  5. постановщик – специалист или руководитель, который установил задачу.

В этом же разделе можно детализировать типы поручений, указывать индексы срочности, вставлять ссылки:

Далее – руководитель «звена» (группы конструкторов по направлению) указывает расчётную оценку ожидаемой трудоёмкости в часах, планируемую дату реализации и исполнителя. Для удобства прогнозирования загрузки инженеров по дате планируемой готовности вычисляли номер недели.

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

Исполнителю оставалось заполнить фактические данные по трудозатратам, дате реализации и своевременно корректировать статус:

Теперь задача не считалась поставленной, пока коллеги не внесли данные в таблицу. Система дисциплинировала и начальника звена – требовалось оценивать трудоёмкость. Совершенствуя правила прогнозирования сложности, решили дробить задачи на этапы блоками до 40 человеко-часов, чтобы любая задача могла уложиться в неделю.

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

На другой вкладке Excel ко всем строчкам одного из конструкторов добавили ячейки в соответствии с днями недели и возможность указывать комментарии в разрезе дня и по задаче. Каждые сутки необходимо в ячейке соответствующей задаче и дате указывать количество затраченных часов.

После суммирования затраченных часов получали ценную информацию о продвижении проекта. Если задача выходила за рамки недели – переносили, отмечая накопленные часы предыдущего периода:

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

  1. Ожидание внутри звена единственного специалиста способного выполнить расчёт.
  2. Ручная правка макетов, ограниченное использование шаблонов.
  3. Отвлечение на мессенджеры и неактуальные задачи.
  4. Отсутствие приоритета в задачах от разных ГИПов.
  5. Ожидание исходных данных для проектирования.
  6. Поиск документов по папкам на сетевом ресурсе.
  7. Неформализованная постановка задач.
  8. Ошибки в типовых решениях.

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

Использовали модель «плавательных дорожек»:

Для выполнения проекта обозначили 11 ролей и под сотню процессов. Большинство сложностей обнаружились на сопряжении функционала инженеров и руководителя проекта. Решения рождались уже в процессе построения карт:

  1. Нашли несколько точек в проекте, требующих обязательного присутствия специалистов по всем направлениям вместо «челночного» согласования. Закрепили в графике встреч по проекту.
  2. Согласовали чек-листы приёмки результатов работ между отделами.
  3. Разработали журнал изменений в проекте и систему оповещений.
  4. Утвердили процедуру установки приоритетов.
  5. Отменили сходные операции у разных специалистов. Закрепили ответственность за одним, проведя оперативное повышение квалификации.

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

  1. Внедрили форму учёта лучших практик. Большинство сотрудников имели в своём арсенале «лайфхаки» работы с ПО, расчётами или оформлением, но не распространяли знания.
  2. Сделали матрицу навыков внутри отдела и запланировали дни обмена опытом. Ряд задач всегда зависал на одном-двух специалистах, не давая развиваться новичкам.
  3. Регламентировали порядок ежедневных разборов полётов. Помогали инженерам формировать привычку анализировать проблемы и делиться результатами.
  4. Сформировали стандартную структуру расположения файлов и папок, чтобы не тратить время на поиски нужных объектов и актуальных версий.
  5. Провели сортировку документов на рабочих местах и в персональных компьютерах. За сотни проектов накопилось множество макулатуры.
  6. Разработали график проверки типовых решений на предмет ошибок, совершенствуя базу знаний. Рассчитывая на экономию времени, можно было наткнуться на несоответствие в заготовке и потратиться на исправление.

За пару месяцев удалось в три раза сократить непроизводительное время на пилотном участке. Эффект оказался равноценен приглашению в команду дополнительного специалиста:

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

  1. на треть увеличили выработку на сотрудника;
  2. на четверть сократили среднее время выполнения поручения;
  3. снизили число задач, одномоментно находящихся у сотрудника, повысив концентрацию исполнителя.

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