Отличительной чертой предлагаемой методологии является практико-ориентированный подход к организации системы проектного управления. СТИФО является логической связкой международных и национальных стандартов проектного управления (IPMA, PMBOK, P2M) и информационных систем, призванных реализовывать цифровое проектное управление. Методология позволяет применять инновационные подходы к проектному управлению «здесь и сейчас», без долгой подготовки и оптимизации управленческих бизнес-процессов. При этом неважно, какой сферой деятельности занимается компания: проектирование, строительство, производство или разработка ИТ-продукта. Неважно, какая модель проектного управления в ней используется: функционально-ориентированная, проектно-ориентированная или матричная. Это не концепция и не верхнеуровневый стандарт, это инструкция к действию. Но почему же «СТИФО» — такое странное название? Сохраним интригу и расскажем об этом в середине статьи.
Управление проектами отличается по уровням ответственности и видам деятельности
Не следует искать унифицированные форматы и интерфейсы проектного управления, подходящие для всех предметных областей и уровней руководства. Данные, которые нужны для обеспечения обоснованности управленческих решений для директора и прораба, имеют значительное отличие. Попытка создать унифицированный формат для проектного управления (например, диаграмма Ганта) приводит к искажению необходимой руководителю информации, делает её менее ценной и провоцирует искать другие источники данных, часто находящихся вне информационной системы и, как следствие, неточных и неактуальных. Например, график с десятком тысяч строительных операций не несёт в себе ценной информации для совета директоров холдинга, а этапы реализации стратегической программы никак не помогут прорабу распределить бригады по объектам. Ещё один пример: график проектирования имеет свою уникальную структуру декомпозиции работ и их детализацию, в нём уникальный атрибутивный состав и ресурсное наполнение, своя периодичность актуализации данных, в отличие от графика выполнения монтажных работ, который строится совсем по другим принципам.
Предлагаемое решение: разделить сущности графика и проекта, в отличие от классических систем проектного управления, где эти понятия являются синонимами. В проекте может использоваться любое количество графиков, отличающихся как по уровням управления, так и по функциональным областям деятельности. Для каждого уровня управления и вида деятельности необходимо использовать свой уникальный набор данных и интерфейсы, максимально подходящие для работы с ними.
Степени свободы руководителей должны быть регламентированы
В сложных многоуровневых проектах, реализующих большой спектр видов деятельности, существует проблема установления зон ответственности при принятии управленческих решений. При делегировании управленческих полномочий в условиях неоднозначности происходит процесс сползания решений на уровень руководителя проекта, а иногда и руководителя компании. При этом вопрос мог быть решён на оперативном уровне, без привлечения топ-менеджмента. Такая ситуация влечёт за собой перегруз верхнего руководства, которое под давлением массы задач, требующих оперативного решения, может недостаточно глубоко погрузиться в проблему и принять не самое рациональное решение вопроса. Кроме того, это влечёт за собой значительные потери рабочего времени управленцев, связанные с продолжительными совещаниями на уровне руководства, и, как следствие, остаётся меньше времени на решение реальных задач.
Это возникает потому, что линейные руководители реально не наделены полномочиями, либо эти полномочия однозначно не закреплены в регламентирующей документации. Часто должностные инструкции составляются в общем виде и не включают в себя детального описания зон ответственности и перечня решаемых задач.
Предлагаемое решение: при формировании проектной команды официально закреплять перечень принимаемых решений для всего руководящего состава проекта. Для снижения трудоёмкости, неоднозначностей и «слепых зон» при закреплении управленческих решений за руководителями целесообразно применять цифровую функционально-ролевую матрицу (ФРМ) управления проекта, которая автоматически верифицирует данные по ответственности руководителей, сигнализирует о размытии ответственности или, напротив, о наличии «белых пятен», когда управленческая функция никому не делегирована. Цифровая ФРМ позволяет мгновенно реагировать на изменяющиеся условия проекта и корректировать зоны ответственности руководителей без переработки десятков регламентов и должностных инструкций.
Ключевая проблема этого метода заключается в непредвиденных ситуациях, которые не регламентированы. Такой сбой мы видели на реальном примере во время аварии на АЭС «Фукусима», когда нестандартная ситуация не позволила персоналу своевременно отработать проблемы из-за отсутствия регламентов реагирования. Подобные ситуации могут быть решены добавлением гибкости в структуру регламентов ФРМ. Непредвиденная ситуация идентифицируется по масштабу и, в зависимости от него, определяется лицо, ответственное за её решение в ручном режиме. В нашем примере при нестандартной ситуации на АЭС решение принимает директор станции и только он. И это тоже регламент. Казалось бы, это очевидно, но, как видите, не всегда работает. Поэтому нестандартные ситуации тоже нужно регламентировать, но регламентировать гибко.
Обеспечивающая деятельность на проекте крайне важна
При развитии автоматизации и цифровизации основных производственных процессов большую роль в проектах начинают играть обеспечивающие и организационные виды деятельности. Эти процессы требуют специальных подходов к планированию и контролю. В классических системах проектного управления часто игнорируются такие обеспечивающие виды деятельности, как контрактация, авансирование, получение разрешительной документации, подготовка и мобилизация персонала проекта, наладка оборудования, сдача исполнительной документации. В лучшем случае в график проекта будет добавлено несколько обеспечивающих работ, которые как-то актуализируются в ходе реализации проекта. Однако при развитии средств механизации и роботизации основных производственных процессов влияние на проект обеспечивающих видов деятельности приобретает все большее значение. В проектах становится все меньше рабочих основных специальностей (землекопов, каменщиков, монтажников) — их заменяет техника, а процентное соотношение сотрудников инженерных специальностей (договорников, закупщиков, инженеров ПТО, наладчиков и бухгалтеров) кратно возрастает. В обеспечивающей деятельности сосредотачивается наибольшее количество рисков проекта, что требует большого внимания к построению эффективной системы её управления.
Предлагаемое решение: при построении современной модели проектного управления на сложных проектах учитывать все виды деятельности, разрабатывать и актуализировать графики по ним. При этом рекомендуется для каждого вида основной и обеспечивающей деятельности реализовывать отдельный график, который разрабатывает и сопровождает ответственный за этот вид деятельности функциональный блок или центр компетенции.
Горизонтальная интеграция: синхронизация видов деятельности на проекте
При построении модели распределённого планирования и контроля на проекте создаются различные центры принятия управленческих решений по уровням ответственности и видам деятельности, которые слабо взаимодействуют между собой. Следствием такого положения вещей является отсутствие синхронизации видов деятельности на проекте, которые реально связаны друг с другом сложными технологическими и организационными зависимостями. Отсутствие интеграции видов деятельности приводит к неуправляемости проектов по принципам распределённого управления.
Предлагаемое решение: для реализации распределённой схемы управления проектом по уровням ответственности и видам деятельности необходима служба горизонтальной интеграции, к зоне ответственности которой относится установление логических и аналитических зависимостей обособленных областей планирования и контроля всех видов деятельности на проекте.
С целью обеспечения необходимых уровней свободы в принятии управленческих решений по отдельным видам деятельности на проекте и снижения уровней ответственности и трудозатрат службы интеграции рекомендуется применять программируемые связи работ и индикативные аналитические показатели, призванные автоматически выявлять коллизии по времени между планируемыми видами деятельности. Служба интеграции не должна быть наделена полномочиями в принятии управленческих решений, в её задачи входит только обеспечение логической взаимосвязи функциональных блоков управления и поддержание системы автоматического выявления коллизий планирования. В такой модели управления руководитель каждого функционального направления на проекте свободен в принятии управленческих решений ровно в том диапазоне, в котором он не выходит за рамки целевых сроков проекта и индикаторов, определяющих «рассинхрон» с другими видами деятельности.
Вертикальная интеграция: непротиворечивость информации на разных уровнях управления
При реализации сложных проектов, связанных с большим количеством видов деятельности, контрагентов, высокой стоимостью и длительными сроками, необходимо построение многоуровневых организационных структур управления. В классических системах управления проектами обычно реализуются схемы разработки графиков различных уровней. Таких уровней традиционно от трёх до пяти. Проблема заключается в обеспечении непротиворечивости уровней графиков, описывающих одну и ту же деятельность. Обычно компании не справляются с этой задачей, что влечёт за собой искажение реального состояния дел на проекте. Проблемы замалчиваются и не отображаются на графике первого уровня, руководство их не видит. Появляется несколько «правд» на проекте, и дело не в умышленном замалчивании проблем (хотя такие факты тоже имеют место), а в отсутствии инструментов обеспечения такой непротиворечивости.
Предлагаемое решение: в качестве целевой схемы на проекте использовать один график по каждому виду деятельности на среднем уровне управления, на том, где оптимально построение календарно-сетевой модели с логическими зависимостями между работами и функцией расчёта расписания. Остальные уровни планирования и контроля являются производными от главного графика. На более высоких уровнях управления это сводная аналитика и контроль ключевых событий. На более низких уровнях управления — это дискретные недельно-суточные планы производства работ без использования сложных алгоритмов расчёта расписания и прогнозной аналитики. При этом сбор фактической информации целесообразно производить на максимально глубоком уровне детализации (нижнем уровне управления), а на более высокие уровни собирать их в различные агрегированные показатели. Такой подход позволяет, во-первых, обеспечить безусловную непротиворечивость и актуальность данных по проекту, а во-вторых, в разы снизить трудозатраты инженерно-технического персонала на планирование и отчётность, так как план и факт вносятся в систему на одном уровне управления, а актуальную информацию получают сразу все уровни проекта.
Однако такая схема построения системы проектного управления не исключает построения многоуровневых графиков. Это часто обусловлено спецификой проектной деятельности, контрактными обязательствами и устоявшимися бизнес-процессами. В этом случае работают те же принципы, что используются при горизонтальной интеграции видов деятельности на проекте. Применяются инструменты программируемых связей работ графиков разных уровней с настройкой автоматических индикаторов, сигнализирующих при возникновении расхождений уровневых графиков по срокам, стоимостям и ресурсам.
Живой проект всегда имеет отклонения от плана, это нормально
В классической системе календарно-сетевого планирования график реализуемого проекта всегда отличается от действительности. В подавляющем большинстве случаев это отставание. Несоответствие реальности и графика вызывает нигилизм. Проект выходит из-под контроля, наступает «вечное отставание». Это стресс для управленцев, они пытаются устранить несоответствия, это не получается, в итоге они отказываются от раздражающей их информационной системы и переходят на ручное управление. Но отставать — это нормально. Отставать — не значит не двигаться вперёд. Просто поставлены повышенные требования, они должны мотивировать, а не парализовать.
Не всегда работает оптимистичный прогноз. Если информационная модель проекта не подразумевает отклонений по срокам и стоимости, то любое неизбежное отставание или удорожание влечёт за собой неактуальность модели и тем самым аннулирует управленческую функцию системы управления в целом, поскольку она оперирует невалидной информацией.
Предлагается устанавливать диапазоны нормальных отставаний, которые допустимы при реализации проекта, и системно ими управлять на основе простых аналитических показателей.
Современное проектное управление должно быть цифровым
Принципы распределённого управления по уровням и функциональным областям подразумевают большой объём используемых данных. Все эти данные должны быть интегрированы между собой и не противоречить друг другу. Ручная синхронизация данных при их высокой детализации практически невозможна. В рамках реализации методов распределённого проектного управления используются данные на разных уровнях детализации и по неограниченному перечню функциональных областей. Детализация данных на нижних уровнях управления может составлять миллионы записей. Структура данных по каждой предметной области содержит уникальный набор характеристик и атрибутов работ, использовать собственный набор нормативно-справочной информации. Это обуславливает необходимость создания гибко настраиваемой и производительной информационной модели проекта с функцией автоматического контроля непротиворечивости данных. В идеале система не должна позволять вводить противоречивую информацию в принципе.
Кроме того, в существующих системах проектного управления есть масса рутинных функций, которые выполняются пользователями в ручном режиме. К ним относится подготовка отчётности разных видов и детализации, формирование актов и протоколов, технических решений, писем и запросов. На все это уходит драгоценное время квалифицированных сотрудников, тем самым снижая их производительность при решении реальных производственных задач. Как следствие: завышенная численность персонала, повышение себестоимости проекта за счёт фонда оплаты труда.
Предлагаемое решение: полная автоматизация отчётности и подготовки документов. Команда проекта занимается только «сутевыми» задачами.
Основной ресурс любого проекта — человек
Управление — это воздействия на объект с целью изменения его свойств и процессов. Важным вопросом построения цифровых систем проектного управления является определение границ автоматизации управленческих функций. Какие полномочия мы готовы делегировать компьютеру? Только рутинные действия, не влияющие на свойства проекта? Может ли система сама выбирать оптимальную технологию производства работ и наиболее эффективную последовательность операций? Существует экспертное мнение, что информационная система управления должна обеспечивать только информационную поддержку, а выбор всегда остаётся за человеком. Современное развитие цифровых технологий, появление нейросетей в повседневной жизни позволяет утверждать, что в ряде случаев передача компьютеру простейших функций управления и принятия неключевых управленческих решений может быть более оптимальной, чем выбор человека. Например: автомобиль автоматически паркуется на свободном месте вдоль дороги, но само место парковки выбирает человек. При этом мы делегируем автомобилю ограниченные управленческие полномочия, сохранив за собой выбор ключевых решений. Таким образом, исключить человека из процессов управления нельзя, но уровень его ответственности повышается кратно уровням автоматизации управления. Ошибка человека становится более значимой, цена ошибки растёт.
Предлагаемое решение: курс на малые команды профессионалов с опытом и навыками цифрового управления взамен крупных и слабо управляемых организационных структур.
Говоря о подходах к формированию команды управления проектом, в условиях высокой автоматизации и цифровизации управленческих процессов наибольшую значимость приобретают такие качества команды как внутренняя мотивация, коллективная эффективность, готовность к быстрым изменениям и способность к непрерывному обучению.
Предлагаемое решение: для формирования эффективных проектных команд использовать методы автоматического подбора сотрудников на основе цифровых карт компетенций с учётом жёстких и гибких навыков (Hard & Soft skills), а также применять гибкие организационные структуры, непрерывно меняющиеся по мере исполнения проекта и переходов между этапами его реализации.
Для дальнейшего погружения в методологию определимся с терминологией и предметной областью распределённого проектного управления и организации работ.
Типовые уровни управления по методологии СТИФО
Выделяется пять типовых уровней принятия управленческих решений. Данное количество слоёв обеспечивает эффективное управление любыми, самыми сложными инженерными и организационными проектами.
Уровень 1: стратегический. Обеспечивает функции программно-портфельного управления для топ-менеджмента компании. Оперирует аналитической отчётностью различных видов и форматов.
Уровень 2: тактический. Инструментарий руководителя проекта. Основан на глубоком и долгосрочном управлении ключевыми событиями проекта.
Уровень 3: интеграционный. Уровень синхронизации различных сфер деятельности на проекте. Основной инструмент команды управления проектом, проектного офиса или офиса управления проектом. Область коллективной работы.
Уровень 4: функциональный. Уровень создания календарно-сетевых графиков проекта. Основной инструментарий функциональных руководителей и планировщиков по каждому виду деятельности на проекте.
Уровень 5: операционный. Предельно простой и максимально детальный инструментарий управления для линейных руководителей с разнообразным интерфейсным набором.
Первые буквы названий уровней управления проектами и определили термин «СТИФО» (рис. 1). Наличие пяти регламентированных уровней не означает, что на каждом реализуемом проекте и каждом предприятии необходимо выстраивать именно такую многоуровневую систему управления. Данный подход является гибким и адаптируется к специфике конкретного проекта, программы или портфеля. Любой из описываемых уровней может быть исключён без ущерба функциональности других уровней проектного управления, если это обосновано спецификой организационной структуры или особенностями решаемых задач.
Этапы построения системы распределённого проектного управления: правило «ИДКС»
При построении проектного управления предприятия по принципам распределённого управления выделяется четыре этапа создания системы:
1. Идентификация. На этом этапе производится обследование проектно-ориентированной организации на предмет выявления управленческих процессов и функций на каждом уровне и по всем областям проектной деятельности. Функции группируются по этапам реализации проекта и предметным областям.
2. Делегирование. Разрабатывается организационная структура проектов с идентификацией всех ролей участников проекта. Каждая управленческая функция привязывается к конкретной роли на проекте. Коллективная ответственность исключается. Выделяются следующие зоны ответственности проектных ролей на управленческих функциях: ответственный, инициатор, источник исходных данных, согласующий, утверждающий, потребитель управленческой функции (он информируется о результатах).
3. Кастомизация. Для каждой управленческой функции определяются интерфейсы информационной системы управления проектами, в рамках которых она реализуется. Для покрытия цифровыми инструментами всех управленческих функций на проекте возможно параллельное применение различных информационных систем (ИС). В этом случае целесообразна разработка функционально-ролевой матрицы информационных систем проектного управления, которая даёт наглядное и однозначное понимание, в каких ИС необходимо реализовывать ту или иную управленческую функцию.
4. Синхронизация. На этом уровне построения систем распределённого управления проектами выполняется последняя и самая важная задача — обеспечение единой и непротиворечивой модели данных по функциям проектного управления. Для её реализации необходима разработка единой параметрической схемы проекта, описывающей все информационные потоки с описанием всех информационных систем, проектных ролей и интерфейсов. Принципы, закладываемые в логическую схему: однократный ввод данных, версионность, ограничение прав доступа по ролям.
Планируемая структура прикладного стандарта построения системы управления проектами на базе методологии СТИФО
Предлагаемая структура прикладного стандарта построения системы управления проектами на базе многоуровневой методологии СТИФО приведена на врезке «Приложение А» на следующей странице журнала.
Данная приведённая на врезке структура прикладного стандарта построения системы управления проектами на базе методологии СТИФО является предварительной и требует тщательной и всесторонней проработки в проектном сообществе.
Автор статьи приглашает заинтересованных экспертов проектного управления, сотрудников проектно-ориентированных компаний, а также коллективы российских и зарубежных вузов для сотрудничества в части развития, дополнения и практического применения изложенных в статье принципов с целью построения эффективных систем цифрового проектного управления.
