Планирование стратегических изменений

~ 40 минут
Изменения в архитектуре бизнеса и IT выявили — теперь нужно их спланировать. Определение действий и сроков реализации — последний этап подготовки стратегии изменений. Предыдущие шаги ни к чему не приведут без плана и назначенных за его реализацию ответственных.
Можно использовать разные подходы к планированию и управлению. В этом уроке разбираемся, как планировать изменения.

Планирование изменений

Изменения в подразделениях, бизнес-возможностях и IT-системах — определили. Теперь нужно:
  1. Спланировать этапы реализации и общие задачи.
  2. Определить сроки этапов.
  3. Определить ответственные подразделения компании.
  4. Оценить предварительную стоимость трансформации на стратегическом горизонте планирования.
Для этого подходит дорожная карта — roadmap, или роадмап. Это универсальный инструмент для планирования любых активностей. На уровне стратегии это ещё неточный план — лишь общие направления реализации.

Сергей

Можно ли создать роадмап трансформации?

Дорожная карта цифровой трансформации

Да, для визуализации изменений можно создать дорожную карту цифровой трансформации — Digital Transformation Roadmap.
На ней указывают шаги и сроки реализации — без детализации работ. План можно включить в презентацию стратегии для топ-менеджмента, а уже после использовать для детального планирования и контроля трансформации.
Подготовка стратегии в крупных компаниях тоже может требовать роадмапа — тогда он сразу становится частью общей карты цифровой трансформации.
Роадмап поможет наглядно представить шаги преобразования, оценить ресурсы, сроки и скорректировать подходы. Если окажется, что стоимость и сроки не подходят, лучше рассмотреть другой план развития. Ещё, например, можно скорректировать цели и сделать новую итерацию стратегии.
Пример
Таким может быть вариант роадмапа трансформации компании на ближайшие годы по кварталам:
  • 2024-й: 1. Создание бизнес-подразделений на основе новой бизнес-архитектуры, в том числе наём IT-команд.
  • 2025-й: 1. Создание бизнес-подразделений на основе новой бизнес-архитектуры, в том числе найм IT-команд. 2. Разработка первой версии платформы и определение дальнейшей стратегии развития продукта после её запуска. 3. Модернизация системы производства контента для совместной работы с библиотекой к моменту запуска платформы.
  • 2026-й: 1. Масштабирование платформы для пользователей и работа над монетизацией. 2. Модернизация системы производства контента для быстрого привлечения партнёров.

Проектный подход

Подходов несколько. Для реализации плана стратегического роадмапа можно использовать, например, проектный или продуктовый подходы. Для начала разберёмся с проектным.
Проект — это временное предприятие, предназначенное для создания уникальных продуктов, услуг или результатов. В частности, IT-проект — это проект в сфере создания, внедрения или применения информационных технологий.
У проекта несколько характеристик — он:
  • Ограничен во времени.
  • Приводит к заранее определённому результату по изначально определённым требованиям.
  • Состоит из последовательных шагов.
  • Требует ограниченных ресурсов — например, людей и денег на реализацию. Центральным ресурсом проекта является бюджет.
  • Состоит из трёх этапов — планирования, исполнения и управления.
Проектное управление и проектный подход отвечают на вопрос: «Как реализовать заданный результат к определённой дате в рамках доступного бюджета и ресурсов?».

Кто занимается проектом

Проектом управляет менеджер проекта — Project Manager, PM. Он отвечает за достижение результатов проекта. Кроме PM обычно есть другие ключевые участники:
  • Команда проекта. Люди, которые будут реализовывать проект.
  • Спонсор. Подразделение или человек, которые предоставляют ресурсы для проекта.
  • Заказчик. Подразделение или человек, которые будут использовать результат проекта.
  • Заинтересованные стороны. Люди и организации, прямо или косвенно оказывающие влияние на ход проекта и его результаты. Их часто называют стейкхолдерами.
В крупных организациях ведут много проектов, поэтому в них есть проектный офис. Это подразделение вырабатывает единые правила по управлению проектами и отвечает за их реализацию. В проектный офис часто попадают инициативы от бизнеса, которые требуют изменений в технологиях. Там их оценивают, планируют, а затем бизнес принимает решение о необходимости реализации: если проект нужен — его реализовывают.
Для реализации стратегических изменений обычно недостаточно одного — нужно сделать много проектов. Они объединяются в программу проектов.
Проекты программы не приведут к глобальному результату сами по себе — только в комплексе. На каждый проект выделяют бюджет — так что программа помогает оптимизировать управление финансами.
Для управления проектами есть стандарты — например, PRINCE2 и PmBook.
Пример
Компания N решила, что для реализации стратегии цифровой трансформации понадобится новая бизнес-возможность — «Управление проектами». Для этого планируется изменить оргструктуру и создать новое управление с проектным офисом и стратегией:
  • Топ-менеджмент (CEO):
    • Управление цифровой трансформации:
      • Проектный офис.
      • Стратегия.
Одна из масштабных задач — реализация медиаплатформы. Она потребует изменений в разных частях компании. Реализовать это можно с помощью программы проектов, а вести всё будет проектный офис. Отдел стратегии же будет отвечать за общий роадмап цифровой трансформации и его связь с программой проектов.
Для реализации проекта или программы нужно подготовить план. План проекта включает требования, сроки, риски, бюджет, ресурсы, работы и заинтересованные стороны. План программы проектов содержит ту же информацию, но учитывает несколько проектов.
Для визуализации и контроля проекта или программы можно также использовать дорожную карту проекта — Project Roadmap. В отличие от карты трансформации, проектная карта содержит более детализированный план с конкретными работами и ответственными.
Пример
Простой роадмап программы проектов для компании N может выглядеть так:
Управление медиаплатформы займётся разработкой её первой версии в рамках проекта в 2025 году. Параллельно IT-отдел модернизирует библиотеку контента, а в 2026 он же занимается созданием личного кабинета партнёра.
На схеме нет планов по дальнейшему развитию платформы — дальше она будет развиваться как продукт со своим жизненным циклом. Проектный формат используется только для первого запуска. После этого в компании могут запускаться новые IT-проекты, если этого потребуют обстоятельства.

Продуктовый подход

Достичь цели трансформации с помощью программы проектов, конечно, можно. Но в случае компании N нужно создать медиаплатформу для продвижения контента и привлечения новых клиентов — это продукт для пользователей. Платформу можно разработать и проверить на пользователях, изменить под влиянием обратной связи от них — а можно закрыть, если она окажется невыгодной для бизнеса. У неё свой жизненный цикл, как и у любого продукта.
Продукт — это результат деятельности компании, который предназначен для удовлетворения потребностей пользователей или рынка. Он может быть материальным или нематериальным и имеет свой жизненный цикл.
Для создания продукта применяют продуктовый подход.
Продуктовый подход рассчитан на улучшение продукта в течение всего жизненного цикла. Проектный подход сосредоточен на бюджете и выполнении проекта в установленные сроки — с фиксированными целями и результатами. В продуктовом подходе важна адаптивность и постоянное развитие, в проектном — завершение конкретной задачи.
Продуктовый подход предполагает создание в компании структуры, которая сможет относительно автономно развивать продукт, — например, команда. Она развивается параллельно с продуктом и зависит от его жизненного цикла — с организационной точки зрения команда равнозначна самому продукту.
Пример
Разработку медиаплатформы в компании N выделили в отдельное управление в прямом подчинении CEO, чтобы добиться автономности. Бизнес-эксперты и разработчики будут автономно работать над продуктом. Проекты же живут ограниченное время — пока будут выполнены или не выполнены, если появятся неустранимые риски.
Итак, компания может реализовать проект и создать некоторую версию медиаплатформы. Продукт потребует развития — и его можно добиться с помощью продуктового подхода.
Хотя развивать продукт и как последовательность небольших проектов тоже можно. Чтобы лучше понять, как это может работать, рассмотрим подразделение медиаплатформы в компании:
  • Управление развития медиаплатформы:
    • Отдел продуктового развития и сопровождения.
    • Отдел технологического развития и сопровождения платформы.
Отдел продуктового развития и сопровождения отвечает за развитие продукта, добавление функций, проектирование интерфейса, определение эффективности и стратегии развития. По сути, менеджеры этого отдела создают задачи на развитие продукта.
Допустим, отдел технологического развития и сопровождения состоит из нескольких групп разработки со своими техлидами. У отдела есть руководитель — он управляет всей разработкой и реальной эксплуатацией платформы:
  • Отдел технологического развития и сопровождения платформы:
    • Группа системной аналитики.
    • Группа frontend-разработки.
    • Группа backend-разработки.
    • Группа тестирования.
    • Группа администрирования.
Получается, большая задача по продукту, например создание функции авторизации и регистрации, требует двух действий. Первое — постановка задачи менеджментом. Второе — её планирование разработкой: каждой группе нужно наметить свою часть работы и реализовать с учётом других задач. Всё это можно делать в рамках небольшого проекта со сроками, рисками и менеджером проектов. Из последовательности таких проектов сложится реализация платформы.
Часто вместо проектной модели изменений в продуктах используют Agile-подходы к разработке. С ними команда продукта постоянно проверяет гипотезы и разрабатывает новые функции — а бюджет выделяется не по проектам, а постепенно. Это удобно, поскольку проектный подход требует детального планирования, но часто не удаётся учесть все риски и точно следовать планам разработки. К тому же проверка очередной гипотезы может показать, что часть запланированного не так важна, — так что нужно поменять приоритеты. Более детально особенности работы продуктовых команд рассмотрим в следующей теме.
Эта таблица поможет понять разницу между проектным и продуктовым подходами:
Для развития продукта важно понимать, как организовано управление продуктом, или Product Management. Это процесс планирования, разработки, маркетинга и поддержки продукта на всех этапах жизненного цикла. Он включает разработку стратегии, анализ рынка, выявление потребностей пользователей и координацию команд. Цель — создать продукт, который удовлетворит потребности пользователей и компании.
Чтобы менять продукт на этапах жизненного цикла, можно создавать новые проекты с чёткими сроками и бюджетами — или использовать Agile-методы, тестировать гипотезы с постоянной командой и постепенным выделением бюджетов.

Кто управляет продуктом

За управление продуктом отвечает менеджер продукта — Product Manager, PM. Это специалист, который отвечает за стратегию, планирование и развитие продукта в компании.
Основные функции PM:
  • Определение видения продукта.
  • Анализ рынка и пользователей.
  • Разработка стратегии.
  • Работа с командами развития продукта — маркетингом, разработкой, поддержкой и другими.
  • Определение приоритетов работы над продуктом.
  • Анализ результатов и обратной связи.
  • Управление бюджетом продукта — не всегда.
Часто можно встретить и владельца продукта — Product Owner. Так обозначают роль менеджера продукта в разных Agile-методологиях разработки — например, в SCRUM. У него могут быть разные функции — всё зависит от компании. В некоторых случаях оунер выполняет все функции менеджера продукта, в других — отвечает за бюджет и расходы, в третьих — проводит согласование со стейкхолдерами для запуска функций и получения финансирования. Ещё владельцем может быть просто представитель бизнеса, который управляет бюджетом и приоритетами — параллельно менеджер продукта работает с командой разработки.

Сергей

Как определить, нужен ли продукт клиенту?

Обычно перед запуском разработки нужно понять, кто клиент, какие у него потребности и как продукт может их удовлетворить. Это важно для целеполагания и определения приоритетов при разработке.
Чтобы ответить на эти вопросы, нужны продуктовые исследования. Это может быть анализ рынка или продуктов конкурентов — так выявляют незакрытые потребности клиента. В этом поможет CustDev, или Customer Development, — процесс выявления потребностей с помощью интервью у потенциальных пользователей приложения. Подробнее об этом — в дополнительных материалах.
Допустим, исследования показали — продукт будет полезен. Теперь нужно выявить, как им пользоваться на концептуальном уровне и как организовать привлечение пользователей. Для этого строят карту клиентского пути — Customer Journey Map, CJM. Она воспроизводит путь клиента от осознания потребности до покупки продукта, а иногда и после неё. О CJM тоже можно почитать в дополнительных материалах.
Чтобы оценить целесообразность создания продукта, можно применить Lean-модель, оформленную в Lean Canvas. Это аналог Business Model Canvas, но для нового бизнеса, для которого только предстоит определить место на рынке. Примеры использования Lean-модели — в дополнительных материалах.
Для компании полезно подготовить первую версию продукта — запустить её и проверить гипотезу о потребности на рынке. Для этого не нужно инвестировать много денег. Такую версию называют MVP — Most Valuable Product.
Пример
Компания N с медиаплатформой может реализовать MVP с помощью программы проектов, определив основные функции и требования к продукту вместе с продуктовым менеджером. Затем целесообразно развивать продукт самостоятельно с отдельным бюджетом — этим займётся управление развития медиаплатформы. Оно будет работать по модели внутреннего стартапа, поэтому lean-анализ может быть очень полезен перед началом разработки.
Если компания разрабатывает взаимосвязанные продукты, можно использовать проектный подход для или Agile-методологии для кросс-продуктовой разработки — например, SAFe.
Чаще всего проектные и продуктовые подходы комбинируются. Всё зависит от зрелости компании и готовности менять процессы под гибкие методологии разработки. Например, менеджер продукта может работать как менеджер проекта и отчитываться о запуске новых функций. И всё потому, что руководство считает их необходимыми, даже если исследований не было. А проектный менеджер может использовать гибкие подходы в планировании, меняя по ходу приоритеты, — всякое бывает.
Итак, продуктовые исследования позволяют компании оценить целесообразность разработки на раннем этапе. Но это не всё. Продукт на разных этапах жизненного цикла должен соответствовать метрикам. Метрики помогают оценивать успех продукта, принимать обоснованные решения и управлять ожиданиями стейкхолдеров. Так что важно рассмотреть запуск продукта с точки зрения метрик и влияние их на метрики всей компании.

Метрики бизнеса и продуктов

Метрики бывают разными.
  • Для определения целесообразности на уровне всего бизнеса и его стратегии важны инвестиционные метрики.
  • Для определения целесообразности конкретных продуктов или проектов — бизнес-метрики.
  • В управлении продуктом важны продуктовые метрики — они помогают выявить приоритеты в развитии продукта и оценить его текущее состояние.
Планирование изменений тоже может опираться на метрики: они помогают понять, какие изменения действительно важны. К тому же с их помощью можно скорректировать ожидания стейкхолдеров, если их требования не совпадают с реальными возможностями реализации изменений. Понять, что некоторые цели могут быть недостижимы, поможет выявление изначальной метрики.
Рассмотрим несколько метрик каждой категории — инвестиционных, бизнес-метрик и продуктовых.

Инвестиционные метрики

Это метрики, отражающие объём вложений в бизнес и эффективность использования средств. С ними работают акционеры, финансовые менеджеры или IT-директора — топ-менеджмент компании. Вот парочка:
  • CAPEX, или Capital Expenditure. Это затраты предприятия на приобретение крупных активов на срок больше года и их модернизацию — капитальные инвестиции. Это может быть покупка здания, вложение в производство и прочие траты. Они нужны для наращивания прибыли и могут влиять на оценку компании.
    Для цифровой трансформации могут потребоваться инвестиции в создание IT-инфраструктуры, покупку серверов, организацию сети или строительство центров обработки данных — ЦОД. Объём инвестиций в процессе оценки может оказаться слишком большим — тогда планы стоит изменить. Например, компания может рассмотреть создание медиаплатформы на облачной инфраструктуре. Это исключит необходимость капитальных вложений.
  • OPEX, или Operational Expenditure. Это операционные расходы — затраты на обеспечение текущей деятельности, а не инвестиции в будущее. Например, себестоимость продукции, управленческие и прочие расходы. Обычно они учитываются в прибыли в том периоде, в котором возникают, — в отличие от капитальных инвестиций. Поэтому с точки зрения финансового управления это может быть удобнее для компании.
Для цифровой трансформации важно знать, какие затраты будут операционными, а какие — капитальными. Например, затраты на команду разработки медиаплатформы могут попасть в операционные затраты.

Бизнес-метрики

Это метрики, которые могут быть важны для роста бизнеса и его продуктов. С ними работают руководители бизнес-направлений, проектные и продуктовые менеджеры.
Первая подгруппа — финансовые метрики. Любой бизнес работает для их улучшения — и проекты цифровой трансформации тоже должны на них влиять. К ним относятся:
  • Выручка — Revenue. Поток денег, который получает компания ещё до налогообложения и издержек.
  • Прибыль — Profit. Деньги, которые остаются из выручки после всех издержек. Их можно инвестировать в бизнес или выплачивать акционерам. Прибыль делится на чистую и валовую — Net Profit и Gross Profit.

Метрики продаж

Вторая подгруппа — метрики продаж. Они помогают оценить объёмы продаж и могут быть актуальными для жизненного цикла продукта.
Например:
  • Количество лидов, или Leads, и стоимость привлечения лида, или CPL — Cost per Lead.
    Лид — это факт заинтересованности потенциального клиента в продукте или услуге. Лид может превратиться в клиента, который сделает покупку. Например, компания привлекает пользователей на рекламный лендинг продукта. Пользователь заинтересовался и оставил свой номер телефона — он стал лидом. Менеджер связался с пользователем и купил товар — значит, лид привёл к продаже.
    Эти метрики могут быть определяющими для некоторых IT-проектов. Например, если мы разрабатываем систему по запуску маркетинговых кампаний через интернет и другие каналы привлечения клиентов.
  • Конверсия — Conversion. Это число клиентов, совершивших целевое действие на каком-то этапе продажи или использования продукта. Обычно процессы продаж оформляются в виде последовательности этапов — её называют воронкой продаж.
Этот показатель часто зависит от состояния систем компании. Например, мы можем улучшить скорость работы сайта, чтобы клиенты охотнее заполняли заявки на продукты. Так что улучшение конверсии бывает важным импульсом изменений.

Метрики продукта

Наконец, метрики продукта. Позволяют оценивать продукт в ходе его жизненного цикла, могут косвенно или прямо влиять на метрики других категорий. Две важные подгруппы метрик:
  • Метрики активности пользователей — User Activity. Показывают, насколько активно пользователь работает в приложении. Чем активнее пользователи работают — тем вероятнее они будут совершать действия, которые влияют на бизнес-метрики. Например, прибыль.
    Обычно считают дневную, недельную и месячную активность — DAU, или Daily Activity Users, WAU, или Weekly Activity Users, и MAU, или Mouthly Activity Users. Эти метрики могут влиять на архитектуру продукта, потому что позволяют выявить нагрузку и всплески активности пользователей.
  • Метрики выручки на пользователя. Позволяют выявить траты пользователей и впоследствии управлять экономикой продукта. Например, ARPU, или Average Revenue per User, — показывает среднюю выручку на активного пользователя продукта. ARPPU, или Average Revenue per Paying User, — показывает среднюю выручку на платящего пользователя. LTV, или Lifetime Value, — валовая прибыль, которую средний пользователь принесёт за всё время использования продукта. Расчёт этих метрик и внедрение новых функций в продукт влияют на финансовые показатели компании.
Это только некоторые метрики. Какие-то важны на уровне стратегии и финансового управления, какие-то — для продаж или управления продуктом. В конечном итоге стремление бизнеса улучшить метрики приводит к изменениям, которые могут повлиять на архитектуру компании и потребовать доработок у команд продуктов или систем.
Для реализации локальных изменений в конкретном продукте или проекте нужно определить цели, сформулировать требования, выбрать архитектуру, спланировать и реализовать изменения. Как это реализовать — разберём в следующей теме.

Задание 1

Для компании определён роадмап цифровой трансформации.
Из каких элементов он состоит и верно ли они приведены на схеме?

Задание 2

Компания Y решила модернизировать свою ERP-систему для более эффективной работы сотрудников и уменьшения числа ошибок. Предполагается разработать рабочее место логиста и оператора склада. У бизнеса есть ожидание, что разработка займёт не более года при бюджете около пяти миллионов рублей, разработкой будет заниматься IT-отдел компании. Руководителю отдела необходимо запланировать изменения.
Какой подход целесообразно применить?

Дополнительные материалы

Итоги

  • Определение действий и сроков реализации — последний этап подготовки стратегии изменений. Предыдущие шаги ни к чему не приведут без плана и назначенных за его реализацию ответственных. Можно использовать разные подходы к планированию и управлению.
  • Для визуализации изменений можно создать дорожную роадмап — карту цифровой трансформации. На ней указывают общие шаги и сроки реализации — без детализации работ. Реализовать план можно с помощью проектного или продуктового подхода.
  • Проект — это временное предприятие, предназначенное для создания уникальных продуктов, услуг или результатов.
    Проектный подход сосредоточен на бюджете и выполнении проекта в установленные сроки — с фиксированными целями и результатами. Здесь важно завершение конкретной задачи.
  • Продукт — это результат деятельности компании, который предназначен для удовлетворения потребностей пользователей или рынка. Он может быть материальным или нематериальным и имеет свой жизненный цикл.
    Продуктовый подход предполагает создание в компании структуры, которая сможет относительно автономно развивать продукт. Он рассчитан на улучшение продукта в течение всего жизненного цикла. Здесь важна адаптивность и постоянное развитие.
  • Проектный и продуктовый подходы можно комбинировать.
  • Для оценки целесообразности разработки проводят исследования: изучают рынок, конкурентов и потребности — с помощью CustDev и CJM. Для проверки гипотезы о потребности создают MVP — минимальную версию продукта без лишних инвестиций.
  • Успех реализации оценивают по метрикам — они помогают принять решения и скорректировать ожидания стейкхолдеров.
  • Метрики бывают разными. Для определения целесообразности на уровне всего бизнеса и его стратегии могут важны инвестиционные метрики. Для определения целесообразности конкретных продуктов или проектов — бизнес-метрики. В управлении продуктом важны продуктовые метрики: они помогают выявить приоритеты в развитии продукта и оценить его текущее состояние.