Вложения в ИТ: как не ошибаться в расчетах ROI при цифровизации компании

Опубликовано От Sergey

Цифровизация ради цифровизации — это не про бизнес. Любое решение должно иметь управленческое и финансовое обоснование. Как рассчитать To-goROI ИТ-интеграции — коэффициент, который показывает предполагаемый возврат инвестиций, — рассказывает Андрей Путин, управляющий партнёр ИТ-интегратора kt.team.

Вложения в ИТ: как не ошибаться в расчетах ROI при цифровизации компании

Евгения Хрисанфова

В проекте Dig(IT)al рассказываем о технологиях, которые помогут вам заработать. Переходите на цифровую сторону бизнеса.

Как посчитать ROI

Обычно программное обеспечение обладает большим мультипликатором. Оптимизируя бизнес-процессы, оно позволяет в разы сократить потери, увеличить объём продаж, сократить период time to market (время от начала проектирования продукта до старта продаж) и так далее.

Но «большой мультипликатор» — это не основа для управленческого решения. Бизнесу нужны конкретные цифры: как именно окупится и скоро ли это случится. Для расчёта возврата инвестиций используется формула ROI.

В базовом варианте для простого ПО без разработки формула проста:

(Экономический эффект от инновации − Затраты) / Затраты

Эффект от внедрения легко прогнозировать: ускорение процесса или снижение потерь на столько-то процентов и так далее. Стоимость лицензии прозрачна и понятна, скрытых платежей нет, разработка если и требуется, то в небольших объёмах. Подставляем значения в формулу — и ROI готов.

 

Формула для гибридных ПО

С гибридным ПО не всё так прозрачно. Это не готовый законченный продукт с предсказуемым эффектом: оно решает несколько связанных задач и оптимизирует несколько процессов. Внедрение гибридного ПО предполагает множество изменений, в том числе на уровне программного кода. В результате вы не можете опираться на предсказуемые проценты и человеко-часы. Соответственно, вычислить экономический эффект до внедрения уже сложнее.

Близкие к достоверным цифры можно получить, опираясь на метрики и гипотезы. Например, с начала производства до старта продаж новой модели дивана без PIM-системы проходит месяц, с PIM-системой гипотетически срок сократится до полутора недель. Соответственно, экономическим эффектом от внедрения PIM-системы будет предполагаемый объём продаж за предполагаемые 2,5 недели, которые вы выигрываете. Более точные цифры для расчётов подскажет ИТ-консалтинг.

Затраты тоже становятся не столь очевидными. Помимо стоимости лицензий, в них нужно включать затраты на интеграцию и кастомизацию, а также стоимость владения ПО — самый «непрозрачный» фактор.

После всех поправок формула расчёта ROI при цифровизации выглядит примерно так:

(Экономический эффект, рассчитанный на основании гипотез и статистики − (Затраты на лицензии + Затраты на интеграцию и кастомизацию + Стоимость владения)) / (Затраты на лицензии + Затраты на интеграцию и кастомизацию + Стоимость владения)

Рассмотрим подробнее каждый из компонентов формулы.

 

Фото: wutzkohphoto / Shutterstock

 

Лицензии

Нет, учитывать их стоимость при расчётах можно и нужно. Более того, стоимость лицензий на близкие по функционалу ИТ-продукты может отличаться в десятки раз. Например, для решения пула задач можно выбрать «Битрикс» и платить 300 тыс. руб. в год, а можно выбрать SAP и отдать 16,5 млн.

Но стоимость лицензий — это самая простая часть. У неё примитивный мультипликатор, например, по количеству рабочих мест, и нет «подводных камней», которые нуждаются в дополнительных пояснениях.

Затраты на интеграцию и кастомизацию

Обычно клиенты «приносят» ИТ-подрядчику на оценку весь объём задач и фич, которые хотят реализовать на проекте. В ответ получают коммерческое предложение со стоимостью внедрения, которая не всегда детализирована. У разных интеграторов и по разным системам оценка может отличаться в разы, и для бизнеса это никак не упрощает принятие решения.

«Быстрее» — признак недостаточной проработки задач или реальное преимущество? «Дольше» — показатель низкой квалификации разработчиков или высокого уровня бизнес-экспертизы интегратора?

Более того, фактическая стоимость интеграции, скорее всего, будет сильно отличаться от предварительной.

Мы рекомендуем расчёт, основанный на статистическом анализе. Давайте подрядчику на оценку не ТЗ на тысячу задач, а одну конкретную фичу.

На основе расчётов по конкретной задаче вы сможете сформулировать и направить подрядчику вопросы, важные для принятия решения: какая логика будет задействована, почему выбраны такие технологии, какова будет стоимость владения выбранным ПО. Так вы получите возможность сравнивать не полуабстрактные цифры из КП, а конкретные подходы и технологии.

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

Стоимость владения

Существующая формула TCO (сокр. от англ. total cost of ownership, рус. «совокупная стоимость владения») для ПО учитывает 23 очевидных и неочевидных фактора: от стоимости лицензий до затрат на самообучение конечных пользователей. Она хороша для расчёта постфактум, но не работает на этапе принятия решения.

Для предварительной оценки стоимости владения предлагаем смотреть на стоимость изменений и на потенциальные риски из-за несвоевременной реализации этих изменений.

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

Мы разделяем аналитическую часть и разработку неслучайно. Любое изменение «пишется» не на пустом месте: в нём есть цель и логика. От выбора системы зависит, кто будет продумывать логику и кто займётся её реализацией на уровне кода (или иным способом).
Например, с такого-то числа вам нужно передавать маркетплейсу дополнительный параметр из характеристик товара. Сколько времени это займёт при реализации средствами традиционной разработки, а сколько — в low-code системеРазработка в low-code-системах максимально упрощена и визуализирована. Стандартизированный набор инструментов и коннекторов позволяет реализовывать интеграции без написания кода. Визуальные инструменты помогают понять даже не программисту, откуда информация берётся, куда поступает, в каком виде и объёме. Как правило, для работы с low-code-системами не нужен разработчик — достаточно бизнес-аналитика.?

Даже если вы получаете в обоих кейсах оценку 4 часа, это разные 4 часа с точки зрения управления процессом. В традиционной разработке это время написания кода. К нему надо прибавить разработку ТЗ: что, как, с какой целью менять и какой должен быть результат — а также более длительный цикл тестирования. С low-code системой 4 часа уже включают в себя аналитическую работу (и по большей части уходят на неё).

Стоимость согласований

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

 

Фото: Unsplash

На что еще нужно обратить внимание

Планируйте на годы, реализуйте короткими циклами

Скорость появления новых ИТ-продуктов и систем постоянно растёт. В результате предыдущие «поколения» ИТ-продуктов устаревают всё быстрее, а у бизнеса часто нет времени на разработку.

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

Период реализации для каждого изменения и инновации должен быть коротким. Не пытайтесь закончить огромный проект в одну итерацию — он устареет ещё на этапе планирования и составления ТЗ. Меняйтесь постепенно, короткими циклами — и при этом держите в голове общий вектор изменений. В этом случае колебания рынка и новые ИТ-решения не станут для вас настолько драматичными.

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

Так, замена прямых интеграций между ИТ-продуктами на централизованную интеграцию через ESB повышает скорость создания интеграций в 4–5 раз. Стоимость их поддержки — например в Talend, Mule, WSO2 — переносится в контур самой компании, а корректировка выполняется буквально в течение дня.

 

Низкий ROI не всегда плохо

Некоторые внедрения не сделают ваши бизнес-процессы быстрее и экономнее — у них другие задачи. Например, появление в компании BPMS (сокр. от англ. business process management system, рус. «система управления бизнес-процессами») часто замедляет работу, но при этом делает бизнес-процессы более прозрачными, чёткими, управляемыми. BPMS необходима в ситуациях, когда соблюдение и чистота всех этапов критичнее, чем скорость их исполнения, — как в банковской сфере или на производстве.

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

 

Чек-лист: что учитывать при расчёте ROI цифровизации

  • В расчётах ROI для простого ПО используется стоимость лицензий и эффект от внедрения продукта. Формула ROI для гибридного ПО учитывает больше переменных.
  • Стоимость лицензии на ПО важна, но не критична, так как у неё нет мультипликатора.
  • Оценка разработки по всему ТЗ даёт менее достоверный результат, чем оценка с применением статистического анализа.
  • Оценка одной задачи или фичи позволяет понять, какие методы, логику, подходы, ИТ-продукты будет использовать разработчик.
  • Стоимость владения более критична, чем стоимость лицензии. Учитывайте скорость интеграции новых фич, сценарий согласования изменений.
  • Низкий ROI — это не всегда плохо.
  • Не пытайтесь перестраивать «всё и сразу», действуйте короткими итерациями.

Фото на обложке: Nirat.pix / Shutterstock

Нашли опечатку? Выделите текст и нажмите Ctrl + Enter

Источник: https://rb.ru/

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *