Цифровая трансформация для директоров и собственников. Часть 2. Системный подход

Джимшер Бухутьевич Челидзе

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

Глава 4. Проектное управление

Введение

Вообще, цифровизация и цифровая трансформация — уже сами по себе проект. Когда вы хотите сделать что-то, чего не делали раньше, когда вы ограничены во времени и в ресурсах — это проект. Хотите написать книгу, купить машину, съездить в отпуск в новое место — это проект. Запускаете новый бизнес, решили изменить работу отдела — это проект.

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

Любой проект состоит из этапов инициации, планирования, реализации (контроля) и закрытия. А для каждой стадии есть свои задачи. Плюс нужно выбрать верную методологию реализации проекта и помнить, что проект — это треугольник.

Проектный треугольник — невозможно изменить один пункт и не изменить остальные

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

Вот об этом и поговорим.

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

По моим личным наблюдениям из-за некачественного управления страдает абсолютное большинство проектов. Допустим, вы верно определили, куда надо внедрять IT, саму технологию, ключевые эффекты, но вот начинается внедрение и…

Если быть откровенным, то именно с проектного управления начинался мой путь в цифровизации, и именно это направление менеджмента я осваивал наиболее глубоко. В итоге у меня есть опыт работы как со стартапами, так и с гигантами: ЛУКОЙЛ, Газпром, Минэнерго, Mazda-Sollers. И я могу с уверенностью сказать, что в промышленности проектами у нас управлять не умеют: выбирают неверные орг. структуры, методологии, фокусируются на формальных инструментах, не прорабатывают цели, задачи, доступность ресурсов, риски… Но не думайте, что мы такие одни. Вот к каким выводам о причинах неудач в проектах пришла Standish Group после изучения более 50 000 проектов во всем мире:

— Недостаток ресурсов.

Это вообще типовая история — давайте инициируем проект, а как реализовать, разберемся потом. Так, у меня был проект в одной корпорации, где участвовало 7500 человек, который мы сопровождали с помощью Exсel. Нужно ли рассказывать об этом веселом приключении, и о том, какого качества данные там были?

— Нереальные сроки.

Думаю, всем знакомо «надо было вчера». Нереальные сроки — не так уж и плохо, если мы держим в голове, что они будут сорваны, и пытаемся стать лучше. Но как показывает практика, такого подхода почти не придерживаются.

— Ошибки формулирования целей.

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

— Недостаточно детальное планирование.

Если подумать, то это является первопричиной для всех остальных пунктов.

— Низкое качество взаимодействия внутри команды.

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

— Изменение целей в ходе проекта.

Опять же, при нормальной проработке стадий инициации и планирования этого можно избежать. Ведь люди крайне плохо переносят хаос и неопределенность.

Статистика проектного управления

Прежде всего хочу привести диаграмму со статистикой проектного управления.

Статистика управления проектами

Причем, если глубже погрузиться в исследования, то с 1990-х по начало 2000-х динамика была положительной, а потом все застопорилось. Даже по отраслям ситуация не отличается значительно.

Статистика по отраслям

Ну, и на закуску — зависимость успешности от масштаба и методологии.

Зависимость успешности от масштаба и методологии

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

Еще интереснее выглядит статистика превышения сроков и перерасходов.

Статистика превышения сроков и перерасходов

То есть в среднем бюджет превышается наполовину, а сроки — почти вдвое. И это полностью совпадает с тем, что говорят руководители проектов неформально.

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

При этом компетенция проектного управления становится все более обязательной, игнорировать ее нельзя, и вот почему:

— доля проектов в ВВП, например, Великобритании, за 100 лет увеличилась с 5 до 35%;

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

— по некоторым прогнозам, к 2030 году до 60% рабочего времени руководителя топ-уровня будет уходить на проекты;

— при этом, согласно рекомендациям стандартов и по моим наблюдениям, ошибки, допущенные и не устраненные в начале проекта, могут его гарантированно похоронить. Я проходил и через мертвые проекты, и вытаскивал «проблемные». Стоимость одинаковых изменений растет с 10 условных рублей на стадии инициации и планирования до 10000 при запуске в эксплуатацию. При этом возможности по исправлению ошибок уменьшаются. Поэтому современные методики предусматривают до 30—40% времени от всего проекта на его планирование и проработку рисков.

Возможные подходы и стандарты к управлению проектами

В мире и, в частности, в России существует несколько стандартов и подходов к управлению проектами:

1. Стандарты про компетенции руководителя:

— стандарт ICB от IPMA (Международная ассоциация управления проектами);

— стандарт НТК от СОВНЕТ, который является переводом ICB;

2. Стандарты, выстраивающие процессы:

— PMBOK от PMI

— ISO 21500 от ISO является конспектом PMBOK (100 страниц вместо 500+)

— P2M от PMAJ — и про проекты, и про программы. Ориентирован на ценности, которые должны получить по итогам реализации.

— Prince2, разработанный авторами ITIL, стандарта по управлению ИТ услугами.

— наш ГОСТ Р — короткая версия PMBOK. Отвечает на вопрос «что надо сделать?».

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

Если упростить, то подходы к реализации проектов можно разделить на:

— каскадные;

Каскадный подход к реализации проектов — поставка продукта проекта в конце реализации

— гибридные;

Пример гибридного подхода с работой итерациями на стадии сбора требований / инициации и проектирования / планирования проекта

— гибкие.

Пример гибкого подхода в реализации проектов

В свою очередь гибкие подходы тоже можно разложить также на 3 типа: итеративные, инкрементальные, итеративно-инкрементальные.

3 подтипа гибкого подхода к реализации проектов

При этом, согласно различным исследованиям, в жизни в основном (60—70%) применяют гибридные методики. Чистого подхода очень мало, и это нормально, ведь невозможно создать универсальный инструмент на все случаи жизни.

Как выбрать правильный подход?

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

Это модель Кеневин (Cynefin framework), которая выделяет пять типов систем: Простые (Simple), Сложные (Complicated), Запутанные (Complex), Хаотические (Chaotic) и Беспорядочные (Disorder).

Модель Киневин

1. Простая система

Характеристика: причинно-следственные связи ясны и однозначны.

Что делаем: берём лучшие практики.

Порядок действий: Осознай — Классифицируй — Реагируй.

Примеры: повторяющиеся и относительно простые проекты, такие как укладка тротуара во дворе, проведение вебинара.

Использовать можно любой «каскадный» стандарт. Главное — не обольщаться простотой и не пренебрегать планированием и точками контроля.

2. Сложная система

Характеристика: причинно-следственные связи существуют, но не всегда очевидны.

Что делаем: используем хорошие практики и стандарты. Здесь не существует единственной «лучшей практики», но есть множество «хороших практик».

Порядок действий: Осознай — Проанализируй — Реагируй.

Примеры: внедрение ERP-системы, реконструкция производственной линии.

Здесь необходимо соблюдать требования PMBOK, Prince2, P2M, работать с заинтересованными сторонами и рисками.

«Гибкие» методологии здесь могут привести к необоснованному перерасходу бюджета и срыву срока. Но они могут применяться как элемент «гибридного» подхода.

3. Запутанная система

Характеристика: причинно-следственные связи не ясны. Схожие действия приводят к разным результатам из-за внешних факторов.

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

Порядок действий в такой среде: Исследуй — Осознай — Реагируй.

Примеры: разработка нового мобильного приложения, выход на новый зарубежный рынок, создание законопроекта в области искусственного интеллекта.

Это территория Agile и Scrum. Здесь не подходят четкие технические задания. Необходима гибкость и осознание рисков, отступление от жестких требований.

Придется много общаться с заказчиком. Как правило, он сам не до конца понимает, что ему надо. Итоговый продукт может значительно отличаться от изначального плана.

Это одна из причин проблемности внедрения ИТ в крупных компаниях. Все делается по бумаге, с ограничениями бюджетов. В итоге приходят к неудобным и дорогим в содержании системам и отсутствию бюджета на доработку, что объясняется следующими тезисами:

— Сделано в соответствии с изначальными требованиями, а значит, проект можно считать успешным. Какие могут быть еще вложения?

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

— Ограничения бюджетных правил. Кто сталкивался с этим, понимает, какая это проблема и сколько съедает времени.

4. Хаотичная среда (кризис, инновации)

Характеристика: причинно-следственные связи отсутствуют. Это переходное краткосрочное состояние либо к простой или сложной системам (при помощи жестких ограничений), либо к запутанной среде (при помощи точечных мер).

Порядок действий в такой среде: Действуй — Осознай — Реагируй.

Что делаем: первый шаг в условиях хаоса — это Действие. Цель — уменьшение хаоса. Затем необходимо ощутить результат этого действия и прореагировать для перевода системы из хаотического состояния в запутанное или упорядоченное. На проверку гипотез просто нет времени, в хаотических системах все происходит невероятно быстро.

Результат зависит от грамотности, смелости и инновационности мышления конкретных управленцев.

5. Беспорядочная среда

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

Типы организационных структур

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

— Слабая — проектов много, но они небольшие, без рутины, не критичны для компании. Или же всего один проект, который условно забирает 10—20% ресурсов компании. Если смотреть по модели Киневин, это подходит для простых систем. Такая структура особо требовательна к проработке плана коммуникаций между участниками и к получению обратной связи от менеджера проекта, который обычно не является высоким руководителем.

— Сбалансированная — средние проекты, которые могут забирать 20—50% ресурсов компании. Если смотреть по модели Киневин, то это сложные и запутанные системы. Можно применять и в хаотичных структурах, но надо оценивать проект. Например, внедрение ERP или отдельных цифровых проектов.

— Сильная — стратегические проекты, где цена ошибки высока для компании, и требуется большое количество ресурсов (более 50%). Это, например, программы по трансформации, комплексной автоматизации, внедрение систем бережливого производства и так далее. Здесь крайне важно прорабатывать этап инициации и планирования, делать короткие контрольные точки между этапами и сохранять гибкость.

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

Методологии реализации проектов

PMBOK

PMBOK (Project Management Body of Knowledge). По-русски, это «свод знаний о проектном управлении». Классификатор процессов (до 2021 года), который говорит, что и когда надо исполнить, чтобы проект достиг заявленных целей.

Этот свод — результат труда американцев в их желании создать универсальную инструкцию. Они хотели уйти от человеческого фактора в управлении и сделать так, чтобы любой, взяв эту инструкцию, мог реализовать проект. По этому своду проводит сертификацию PMI (Project Management Institute — Институт управления проектами).

PMI в том числе выдает сертификат о статусе PMP (Project Management Professional — профессионал в области управления проектами). И именно сертификаты от этой организации хотят видеть у руководителей проектов в больших корпорациях.

PMBOK — наиболее распространенная методология, которую можно использовать в большинстве проектов.

Этот подход первым ввел понятие «проектный треугольник», описывающий баланс между стоимостью, временем и качеством проекта.

Проектный треугольник

При этом, сейчас еще актуальна шестая версия PMBOK, но в 2021 вышла седьмая. В ней идет переход к более гибкому управлению. Стандарт больше не говорит, что делать и когда, а дает инструменты и подсказки, предлагая руководителям самостоятельно определять свои действия.

Это стало ответом на неопределенность и нестабильность современного так называемого VUCA-мира:

— Volatility (нестабильность) — постоянные изменения окружающей среды, запросов клиентов.

— Uncertainty (неопределённость) — практически невозможно что-то прогнозировать и планировать. Теперь стратегическое планирование охватывает не 3-5-10 лет, а 1—2 года. Это следствие политических конфликтов, войн, эпидемий.

— Complexity (сложность) — факторов, которых приходится учитывать, становится все больше. Отсюда, кстати, и такие надежды на системы поддержки и принятия решений на основе искусственного интеллекта.

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

Но в мировой повестке примерно с 2016 года появилась новая аббревиатура — BANI:

— Brittle (хрупкий) — любая система легко и быстро ломается.

— Anxious (тревожный) — постоянные изменения, которыми невозможно управлять и под которые необходимо постоянно подстраиваться, ломая свои планы.

Конец ознакомительного фрагмента.