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

В Lamoda Tech приходят самые разные инициативы: одни коллеги просят внедрить электронный документооборот, другие — оптимизировать доставку товаров на склад. Как без погружения в их процессы понять, на что распределить ресурс?  

Самый очевидный ответ — измерить пользу для компании. Чтобы унифицировать процесс принятия подобных решений, мы обратились к показателю ROI для сравнения всех входящих инициатив. 

Меня зовут Андрей Печенев, я руковожу командой внутренней автоматизации в Lamoda Tech. Вместе с Максимом Молодовским, который занимается развитием корпоративных бизнес-приложений, я расскажу, как мы научились сравнивать несравнимое и приоритизировать проекты без боли. 

Немного контекста

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

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

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

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

Проекты могут иметь разные профиты в абсолютных значениях. Проект Х может приносить 100 миллионов, но стоить 50 миллионов. Проект Y —  приносить 10 миллионов, а стоить миллион. Более того, проект Х потребует десять месяцев на реализацию, а проект Y — один месяц. Так просто их не сравнить.

Почему в качестве метрики выбрали ROI

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

Плюсы ROI:

  • Универсальный коэффициент, который подходит для любого внутреннего проекта: у каждой инициативы есть потенциальный профит и кост реализации.

  • Качественный показатель, который содержит сравниваемые между собой числа.

  • Основан на деньгах, но при этом чувствителен к длительности и стоимости проекта.

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

Почему не подошли другие показатели: например, продуктовые? 

Продуктовый подход — это история про масштабирование одного продукта. Она не дает уверенности, что мы купировали все источники боли бизнеса.

Вообразим, что мы внедряем фичу: новый способ доставки — дроном. Как товар дойдет до клиента? Закинем в окно. А есть ли окна у всех наших клиентов? Прозрачные ли они, закрытые ли? Не испачкаем ли мы шторы? Далее начинается А/В-тестирование, создается фокус-группа, в процессе delivery фича дорабатывается. 

Но это точно не будет самый удобный и дешевый способ доставки — а значит, нам такое не подходит.

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

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

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

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

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

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

Мы используем микс из всех доступных способов: 

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

  2.  Заходим к команде внутренней разработки. Они подсчитывают, сколько будет стоить разработать такой функционал внутри компании. Так появляется верхнеуровневая оценка ресурсов. 

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

Чтобы все эксперты оценивали один объем задач, мы создали внутренний документ под названием «Описание инициативы». Мы включаем туда верхнеуровневое описание задач и границ — без лишней детализации, чтобы не закопаться в этом слишком сильно. Документ отвечает на четыре вопроса. 

  1. В чем цель изменений?

  2. Какой бизнес-процесс сейчас?

  3. Каким мы хотим его видеть?

  4. В чем недостатки текущего процесса?

Логично, что все эти пункты связаны между собой. 

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

Из кого состоит команда, которая этим занимается

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

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

У нас был реальный проект по оптимизации IP-телефонии для рекрутеров. Стоимость сильно зависит от количества звонков и минут соответственно. Мы спрашивали: на какое количество минут в месяц вы рассчитываете? Менеджмент полагал, что это 1 500 - 2 000. Мы позвонили мобильному оператору и запросили статистику: оказалось, что длительность звонков в месяц не превышала 300 минут. Обнаружили проблему: руководство полагало, что сотрудники звонят в несколько раз больше, чем на самом деле. После этого отдел запустил оптимизацию внутренних процессов.

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

Что является итогом расчетов

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

Чтобы оценить его результативность после запуска, мы внедрили метрики. Это ключевые параметры, которые характерны для бизнес-процессов заказчика. 

Помните пример про рекрутеров и IP-телефонию? Здесь такой метрикой будет не количество минут, потраченных на звонки, а количество закрываемых в течение месяца вакансий. Мы можем посчитать, сколько вакансий закрывали рекрутеры до внедрения проекта, а после отслеживаем, изменились ли показатели. Контрольное снятие проводим спустя некоторое время — это нужно, чтобы процесс устоялся. 

Больше конкретики

Дисклеймер.
Чтобы показать вам, как мы работаем с коэффициентом ROI, несем скрины из нашей таблицы на примере кейса рекрутеров и чат-бота для найма операционного персонала. Мы замазали некоторые данные в соответствии с NDA, но оставшейся информации будет достаточно для понимания контекста. 

Основные финансовые профиты по проекту.
Основные финансовые профиты по проекту.
Учет затратной части по проекту.
Учет затратной части по проекту.
Итоги расчета ROI. Эти цифры считаются автоматически, исходя из данных, прописанных выше.
Итоги расчета ROI. Эти цифры считаются автоматически, исходя из данных, прописанных выше.

Вместо заключения

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

Метрики бизнес-процессов — отдельная большая тема, к которой мы вернемся в одном из следующих материалов. А пока остановимся на приоритизации: как ранжируете проекты вы? Какие показатели и коэффициенты используете? 

Будем рады обсудить опыт в комментариях.  

Комментарии (6)


  1. Atorian
    20.08.2024 08:41

    Спасибо за статью. Очень люблю приоритизировать в деньгах. То что вы предлагаете очень похоже на WSJF вроде. В чем разница на ваш взгляд?


    1. pechenkameister Автор
      20.08.2024 08:41

      Привет и спасибо за вопрос, он действительно интересный!

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


  1. Aquahawk
    20.08.2024 08:41

    А вы сравнивали, насколько прогнозные показатели стоимости производства, сроков, итогового профита отличаются от факта, когда внедроение произведено и реальные метрики собраны?


    1. pechenkameister Автор
      20.08.2024 08:41

      Да, буквально недавно делали отчетную презентацию на команду.

      Приведу верхнеуровневую статистику:

      • в выборке из 10 внедренных сервисов 7 из них показали целевые значения по достижению заявленных метрик;

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


    1. MikECOM
      20.08.2024 08:41

      И главное, есть ли последствия для заказчиков, которые не обеспечили соответствие плана и факта?


      1. pechenkameister Автор
        20.08.2024 08:41

        Да, если можно так выразиться :)

        В случае недостижения метрик:

        а) принимается решение о продолжении или прекращении использования текущего решения;

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