Директор по консалтингу ADVANTA Павел Гаращенко и cofounder Edtech Startup PROУправление Ольга Романова провели вебинар, где обсудили особенности управления проектами в крупных корпорациях. В беседе затронули тему, как методология проектного управления помогает бизнесу, как появляется бюрократия и почему ИСУП — не панацея в этом вопросе. Рассмотрели на примере ADVANTA связь проектного управления со стратегическим планированием. Получилось захватывающе, делимся основными моментами в этом материале.
Цифровая трансформация, декомпозиция стратегии и организация проектного офиса
Павел: Сегодня поговорим о проектном управлении, развитии крупных корпораций и стратегии цифровой трансформации. Как это связано, связано ли вообще. Предлагаю начать с того, чтобы определиться с понятием крупной корпорации. Задам вопрос с ракурса проектного управления: «Как по сложившемуся в компании проектному управлению определить — это крупная компания или маленькая?»
Ольга: Я в проектах больше 10 лет. Работала в компаниях разных сфер: консалтинг, производство. Последнее место — «Газпром Нефть». Это вертикально интегрированный холдинг. Если классифицировать, то вертикально интегрированная компания — это та, что занимается всем циклом производства: добыча ресурсов, переработка, логистика, реализация. Я думаю, что сегодня поговорим о них. А вот вводить границы на тему размера компании, мне не хотелось бы.
Павел: Когда мы говорим о крупном предприятии, то предполагаем, что у него большой ассортимент продукции, огромный поток проектов. Конечно, это вертикально интегрированное предприятие. Сеть цветочных салонов — это тоже вертикаль, но там, как правило, нет проектного управления. Я задал такой вопрос, чтобы подчеркнуть, что мы говорим о крупных корпорациях. И мы предполагаем, что в них есть проектное управление, а если нет, то потребность уже возникла.
Ольга: Можно ли судить о размере компании по наличию проектного управления — это немного перевернутая история. У каждой компании есть свой жизненный цикл. В какой-то момент инициатив внутри становится больше, все они ведутся по-разному. А руководству компании нужно быстро, качественно, непрерывно, чтобы зарабатывать максимально. Все это нужно синхронизировать, уместить в единую цепочку, задать правила. Тогда зарождается идея об унифицированном проектном управлении. Это естественный процесс, когда компания масштабируется и уже не может работать по-старому. Проекты — это изменение состояния из одного в другое. Когда мы понимаем, что нам нужен скачок, необходимо что-то делать по-другому, производить новое и уникальное. Проектное управление — это один из таких инструментов.
Павел: Замечала ли ты какие-то особенности, которые присущи проектному управлению только в крупных корпорациях?
Ольга: Честно скажу, что видела совершенно разные модели. Есть концептуально две разных истории. Первая, когда люди не очень понимают, для чего им нужно проектное управление, просто пытаются следовать тенденциям. Спускают задачу внедрить цифровую трансформацию, создают подразделение, рисуют стратегию. Но проектных практик в компании еще нет.
Вторая история, когда идет естественное развитие, появляется много активности. Это еще не проекты, а разрозненная деятельность по созданию чего-то нового. В этих локальных блоках происходят локальные проектные инициативы. Возможно, даже создаются проектные офисы. В какой-то момент возникает понимание, что все «расползаются», нет коллективной ответственности, каждый работает в рамках своей функции, и это нужно синхронизировать. Тогда появляется идея централизации. Постепенно эти локальные проектные офисы начинаются перетягиваться вверх оргструктуры в виде людей, инициатив, практик. Есть три вида проектных офисов: консультирующий, контролирующий и самый продвинутый — управляющий, когда он уже делает проекты для всей компании.
Если говорить о дальнейшем развитии предприятия, я заметила тенденцию: третья стадия — снова децентрализация. В какой-то момент инициатив становится так много, что проектный офис не успевать делать все. Поэтому он возвращается к контролирующей функции, а локальные офисы продолжают делать проекты для бизнеса. Я вижу такие тенденции. Павел, поделись, как у тебя.
Павел: Я тоже стал замечать, как на крупных предприятиях централизованные проектные офисы начинают откатываться, разрушать старое и создавать новое. Такое предприятие обречено на повторение истории. Децентрализация закончится через 3-5 лет, в зависимости от скорости развития компании, и снова вернется к централизации. Это будет очередной виток развития. То, что я замечал в развитии централизованных проектных офисов: следующий шаг — это делегирование. Когда из большого реестра инициатив выделяют какие-то более локальные, не требующие управления сверху. Централизованный проектный офис выступает как наставник: дает методологию, контролирует, но не управляет. На мой взгляд, за этим будущее, потому что такая модель выглядит эффективно.
Ольга: Централизованный проектный офис начинает разрабатывать шаблоны и практики проектного управления, внедряет методологию, по которой будет работать вся компания. И это приводит к росту бюрократии, что загоняет проекты в определенные рамки. А если посмотреть на весь цикл, это может приводить к излишним временным и финансовым тратам. Некоторые проекты и проектные инициативы не такие масштабные, чтобы проходить через все стадии жизненного цикла. Поэтому их реализуют отдельно в дочерних компаниях.
На практике я вижу примеры, когда создаются локальные проектные офисы. Основная их задача — это реализация проекта, а для центральных — разработка методологии, поддержка и реализация части проекта корпоративного уровня.
Еще хочу отметить, что когда провожу обучение, мне часто задают вопрос: «Чем операционная деятельность отличается от проектной, в чем разница?». На мой взгляд, отнесение деятельности к проектной должно быть именно на уровне компании. Компания сама выбирает критерии: по деньгам, количеству людей, внедренным технологиям. Если же критериев нет, то начинается полная неразбериха в процессах.
Методологии и системы управления проектами, используемые в больших компаниях
Ольга: Давай еще поговорим о методологии. Что ты видишь, какие тенденции есть? Разрабатывают ли корпорации свои или используют существующие, какие системы проектного управления применяют?
Павел: Я склонен считать, что все методологии об одном и том же — о порядке действий, выравнивании терминологии. Выбор методологии облегчает лишь язык, на котором общается проектная команда. Некоторые методологии упрощают программное управление. Когда программ немного, то компания может позволить себе выбор методологии. И это один из симптомов, по которым можно измерить, крупная это корпорация или нет, и оценить уровень ее зрелости. Если компания утверждает, что они все проекты делают по Agile — это одна история. Второй вариант, когда методология зависит от проекта или вообще в проекте методологию не выбирают, а руководитель с пониманием разных методов организует работу команды под цель проекта. И это более зрелый выбор. Первый вариант, словно от неопытности. Выбор методологии упрощает последующие действия, но неизбежно приводит к тому, что приходится согласовывать отклонения внутри проектных комитетов, потому что нужно делать проект, а не исследовать методологии. Так я отличаю зрелость проектного управления в разных компаниях, на первых вопросах можно понять, на каком языке с ней разговаривать.
Ты упомянула бюрократию, согласен, что это явление растет в крупных компаниях. Я это также связываю с тем, что в компании не первый год внедрено проектное управление, ведутся значимые проекты. И ориентируясь на успешные проекты, компания вырабатывает контрольные процедуры, которые распространяются на весь портфель. Процедуры множатся, начинают зависеть друг от друг, контрольная функция переходит в отдельный проектный офис. Иногда это приводит к децентрализации. И тут есть два варианта. Если, например, создается проектный офис в филиале, чтобы туда не приходилось ездить команде из главного офиса — это позитивное решение. Если же децентрализация проводится как способ борьбы с бюрократией, это неверное решение, потому что бороться надо с корнем проблемы. В этом плане может помочь автоматизация контрольных процедур. По твоему опыту, при помощи каких инструментов можно вылечить бюрократию?
Ольга: У меня к этому, скорее, бизнесовый подход. Есть бизнес, есть хорошие идеи, которые могут принести эффект. Но когда сталкиваешься с корпоративной централизованный глыбой, понимаешь, что за этим эффектом придется идти минимум год. Я встречала компании, где методология разработана так, чтобы на выполнение проектов отводилось не менее 6 месяцев. А бизнес быстрый. Если выйти за пределы корпорации и посмотреть на примеры коммерческих компаний, там все делается быстро: сегодня идея, завтра реализация, послезавтра уже три миллиарда прибыли. Я бы сказала, чем гибче компания в этом плане, тем лучше.
Про методологию с тобой согласна. Часто ее выбирают, опираясь на тренды, хотя на самом деле каждый проект — это серьезная комбинация задач, действий, подходов, практик. Сейчас все стремятся к адаптивности, гибкости, совмещению подходов. Я наблюдаю, что компании нередко создают симбиоз из методологий. Когда подходы из практики вырастают и используются как реальная помощь в реализации проектов. И здесь нельзя не сказать о бюрократии. Есть объективные причины, почему это происходит. например, в какой-то момент появились требования к безопасности — «Закон о защите персональных данных». Поэтому в компаниях стали создаваться отдельные проекты для выполнения этих требований. Да, это увеличивает бюрократию, но это закон, и мы должны его соблюдать.
Еще хочу добавить, что крупные корпорации — это и определенные правила по выделению бюджета. И каждая такая история добавляет в проект процедур. А когда проектные офисы создаются непосредственно ради контроля и увеличивают количество регламентов, это неправильный путь развития.
Павел: Согласен. Когда та или иная процедура вводится исключительно ради контроля, а не для и того, чтобы помочь проектам — это действительно неправильно.
Мне еще пришла мысль: у крупных предприятий с большим опытом реализации со временем проекты затягиваются, потому что это не проекты, а продукты. Некоторые проекты слишком дорого организовывать, и иногда достаточно Scrum подхода, чтобы выполнить сотни работ. Конечно, ни о каком управлении рисками или изменениями в этом случае речи не идет. Запускать для такой задачи проектное управление — это как стрелять из пушки по мухам. И тогда проектный офис оформляет это в виде продуктовой истории, так появляется продуктовое управление: выделяется владелец, стратегия развития продукта. Все это позволяет объединять проекты, являющиеся продуктами, в отдельную сущность. Проектное управление становится рядом с продуктовым, а компания продолжает развитие. Я не уверен, правильна ли эта последовательность. Потому что видел и обратную историю. Какой твой опыт?
Ольга: Думаю, что управлением продуктом занимались всегда. Я работала в финансовом блоке, где каждый главный бухгалтер отвечал за внедрение 1C и являлся владельцем продукта.
Павел: Если финансовый учет является продуктом, тогда бухучет — это процесс. При такой логике главбух — владелец процесса.
Ольга: Да. Главный бухгалтер выстраивает стратегию своих продуктов. Мне кажется, все это существует очень давно. Просто сейчас компании ищут более эффективные способы управления. На старые процессы натягивают фреймворки, которые позволяют эту деятельность сделать прозрачной, управляемой, эффективной. Я к этому отношусь философски: сегодня управляем продуктом, через 10 лет это будет называться по-другому, и будем играть по новым правилам.
У меня часто спрашивают, что такой продакт и кто такой проджект? Отвечу так: если вы адекватный человек, то вам, скорее всего, посчастливится поучаствовать во всех процессах, которые есть в компании. Возможно, как проджект, вы не будете участвовать в продаже продукта на международном рынке, но вы будете считать юнит-экономику внутри компании, PNL, сроки окупаемости, делать технико-экономическое обоснование, проводить организационные мероприятия. Чем хороши большие корпорации, так это тем, что у вас открываются очень большие возможности для реализации и продуктовых, и проектных, и исследовательских инициатив. И здесь вопрос только в открытости и гибкости человека, насколько он готов играть по установленным правилам.
Павел: С точки зрения развития методологии управления, мы выходим на такую последовательность: сначала в компании появляется типовая методология, которая внедряется своими или привлеченными ресурсами, затем другие подразделения ее перенимают. Так появляется собственная методология, принятая в компании, гибрид разных знаний и опытов, которые накопились и успешно применялись. Дальше неизбежна автоматизация процессов. Мы приходим к инвентаризации проектов, продуктов, инициатив, целей. Сколько из них нужно достичь на горизонте 3-5 лет, а сколько из них декомпозировать на задачи в ближайшие полгода. И это все должно быть на экране, управляться с компьютера. Есть такое мнение, что можно весь этот путь сократить до последнего шага. Внедрить методологию в компанию в виде готовой автоматизированной системы управления проектами с уже настроенными процессами. Слышала о таком? Что думаешь?
Ольга: Слышала и даже знаю компании, которые купили ПО, но не пользуются им. По моему опыту, проекты и проектное управление всегда имеют под собой естественную историю возникновения. У компании есть свои проекты и практики управления ими, но не получится найти готовое решение, которое будет полностью им соответствовать. Безусловно, существуют ИТ-решения, где эталонные бизнес-процессы обкатаны на миллионах компаний. Но все равно при внедрении приходится делать адаптацию под специфику конкретного бизнеса. Системы управления проектами тоже бывают разными. Это внешняя оболочка, но она не может научить управлять проектами. Это надо делать руками на основе существующих проектов и лучших практик управления. Если этого нет, нет смысла что-то внедрять.
Павел: Я в таком же ключе стараюсь говорить с менеджерами наших клиентов. И привожу аналогию с шуруповертом. Нельзя просто купить шуруповерт. Шурупы не станут от этого закручиваться сами. Сначала придется придумать, кто их будет закручивать. Нужен человек, который хотя бы умеет работать отверткой. Вот тогда можно рассчитывать на повышение эффективности. ИТ-система сама по себе не управляет проектами, за этим стоит человек. И если он использует хороший инструмент, это получается гораздо лучше.
Демонстрация возможностей системы ADVANTA
Павел: Сегодня с нами Александр — эксперт по управлению проектами ADVANTA. Предлагаю взглянуть на функционал системы, который помогает топ-менеджерам крупных компаний следить и получать информацию о большом реестре проектов. Что может система предложить в этой области.
Александр: Хочу показать, как связано проектное управление со стратегическим планированием и мониторингом показателей на примере ADVANTA.
С помощью системы можно эффективно управлять проектами, программами и портфелями в единой информационной среде. Помимо проектной деятельности можно посмотреть, как проекты влияют на развитие компании и как отслеживаются качественные показатели. Планирование организовано на различных уровнях, начиная со стратегии и далее декомпозируется до целей департаментов. Сами цели делятся по уровням.
Внутри системы у каждой цели и задачи есть свои ответственные: куратор и лидер цели. В карточке доступна информация по бюджетам и достижению цели в процентах. Видно, из чего складываются эти цифры. По задачам тоже есть ответственный и план-факт. Факт фиксируют ответственные вручную или он автоматически подтягивает данные из отчетных систем.
Стратегия разбита по целям отдельных подразделений. Для каждого подразделения зафиксирован куратор и ответственный. Ответственным может выступать руководитель подразделения. Структура такая же, как на уровне выше: задачи, организация связки с запущенными проектами в системе.
В самих задачах также свои ответственные. Фиксируются сроки, рассчитывается процент выполнения задачи. Процент выполнения цели считается снизу вверх.
В карточках фиксируется целевое значение, оно может быть разбито в динамике достижения (квартал, год). Факт собирается на основании отчетности. У целей департамента могут быть связанные с ней проекты. Эта связка тоже отображается в системе.
Для понимания общей картины реализации стратегии доступна инфографика. На дашбордах можно вывести комплекс различных данных: KPI, диаграммы, план-факт и различные представления для детализации информации.
Например, этот дашборд наглядно демонстрирует, на какой департамент идет больше финансов. Отдельно в таблицах представлены реестры стратегических целей компании и целей департаментов.
Павел: Здорово, если топ-менеджеры крупных предприятий, которые придумывают стратегии, имели бы такую же прозрачность в части декомпозиции стратегических целей. К сожалению, на практике в крупных компаниях часто все выглядит не так.
Ольга: Тема соответствия стратегии — моя любимая. Я считаю, что не надо делать «вакуумные» проекты, которые ничему не соответствуют. Наличие стратегии — это показатель зрелости компании. Если мы понимаем, как каждый проект влияет на достижение целей компании, это уже хорошо. Но проблема в том, что многие руководители не понимают важности соответствия проектов целям компании.
Зачастую компании даже не транслируют цели на персонал. Поэтому я всегда рекомендую книгу «Стратегия голубого океана», чтобы научиться создавать стратегию, ставить точные цели и правильно доносить смысл этого до сотрудников.