За последний год на пресейлах я всё чаще слышу одни и те же фразы: «Дорого!», «За что такие деньги?», «С такой автоматизацией мы без штанов останемся». И это не торг за бюджет. За этими фразами стоит жесткий вопрос: какой экономический эффект покупает заказчик?
На фоне кризиса и тотального сокращения инвестиций я наблюдаю один и тот же парадокс: оценка бизнес-эффекта перед стартом проекта становится критически важной, даже если на предыдущих проектах эффективность спокойно оценивали «на глазок».
Сейчас заказчик покупает не цифровую занятость для операционщиков. Ему нужна польза в цифрах: снижение трудозатрат, экономия ресурсов, сокращение сроков.
Хотя еще пару лет назад почти повсеместно говорили, что после автоматизации не будет сокращения человеческих ресурсов, будет перераспределение нагрузки, рост прозрачности данных и снижение количества ошибок. И эффект там тоже был, и ROI тоже был, только он был другим.
После старта проекты чаще управлялись по «железному» треугольнику: сроки – стоимость – содержание, и редко когда по эффекту. Возврат к окупаемости решения после старта никто не делал.
Встречи иду, требования реализуются, код пишется, задачи в трекере обновляются. Формально все в рамках договоренностей, но на этапе приемки или даже уже при первом запуске появляются вопросы: почему процесс не стал быстрее, почему нужен еще один человек для ввода данных, почему трудоемкость процесса не снизилась и где же обещанная выгода?
В этот момент становится видно главное: автоматизация без эффекта превращается в цифровую занятость.
Под этим термином я понимаю ситуации, когда компания переносим операции в цифру, увеличивается объем данных и контроля, но не получает ощутимой пользы в деньгах, а только улучшает качество, прозрачность и снижает ошибки.
Но проблема не только в том, что ROI плохо считают. Проблема в том, что участники проекта по-разному понимают, что такое хороший результат.
Эксперт защищает качество. РП защищает сроки, стоимость и скоуп. Заказчик защищает эффект. И если эти три логики не дружить вместе, проект может быть формально успешным, но по эффекту проваленным.
Сейчас особенно заметно, что выигрывать проекты становиться крайне сложно, бюджеты защищаются труднее, а заказчик внимательно следит за возвратом инвестиций. Сейчас показать, что операционная команда будет обрабатывать весь пул операций автоматизировано, все процессы будут описаны, а система внедрена – уже недостаточно. Нужно показывать какую экономическую проблему решает проект и какой финансовый эффект достигнут после окончания проекта.
Если после проекта процесс не стал дешевле или быстрее, то чаще всего в глазах заказчика можете увидит вопрос: за что я платил?
Как проект теряет эффект
Я видела несколько похожих ситуаций, когда проект выглядит разумным, но эффект начинает теряться еще до разработки.
1. Автоматизировать фактически нечего
Однажды меня как эксперта позвали на усиление в проект: нужно было разобрать сложный процесс и определить границы автоматизации. Было заложено порядка 3х недель фул-тайм работы только на этапе «Обследования». Но на первой же встрече выяснилось, что процесса как такового нет, он не формализован, не стабилен и держится на «ручном» управлении отдельного человека. Нет устойчивой алгоритмики: вход процесса, правила принятия решений, исключения, выход и результат процесса.
В таких ситуациях коллеги любят говорить: «Если автоматизировать хаос, то получится автоматизированный хаос за много денег».
2. Проект автоматизирует старую реальность
Вторая ситуация: на длинных проектах по Waterfall (с жестким каскадом управления проектом) требования фиксируются на старте, и архитектура прорабатывается под эти требования, но дальше «операционка» компании продолжает жить и адаптироваться под окружающую нестабильную действительность.
Команда делает так, как было согласовано и если управление изменениями слабое, то результаты проекта не будет соответствовать реальности и может стать не нужной для компании.
Такие ситуации для РП могут выглядеть как защита границ проекта (согласованный бюджет и сроки), для эксперта - как защита качества (глобальные изменения влияют на архитектуру и нужно пересогласовывать модели, это РП не разрешит), а для владельца эффекта нужна автоматизация текущей реальности, а не памятник начальных требований.
Пересчитывать эффект чаще всего мало кому интересно, даже самому заказчику, если есть KPI на завершение проекта.
3. Боль процесса принимают за экономический эффект
Для одного пресейла недавно рассматривали необходимости повышения уровня автоматизации учета командировок. Исходная точка: 5 специалистов обслуживают в 3х системах учет командировок, много ручной работы по интеграции данных, ручные согласования и звонки/письма с напоминаниями и контроля исполнения по каждому шагу маршрута процесса. Кажется этот бизнес-процесс очевидный кандидат для реинжиниринга автоматизации. Но…
При защите бюджета выясняется, что инвестиции будут окупаться более 5 лет, если сравнивать их с оплатой трудозатрат 5х специалистов.
Сам процесс действительно болел, было много провалов из-за человеческого «фактора», но эта боль еще не бизнес-кейс для автоматизации.
Три логики одного проекта
В проектах автоматизации, да и в любых других видах проектах, кажется, что спор ведется вокруг «железного» треугольника и мы оперируем требованиями и их изменениями.
Но глубже обычно лежит другой конфликт: мы все по-разному понимаем, что такое хороший результат.
Логика | Главный вопрос | Сильная сторона | Перекос |
Эксперт | Как сделать правильно? | Качество, надежность | Раздувание скоупа, избыточное качество |
РП | Как довести до конца с меньшими потерями? | Сроки, бюджет | Защита исходного скоупа без проверки пользы |
Владелец эффекта | Где будет польза? | ROI, экономия | Скачущие приоритеты |
Эксперт защищает качество: ему важно в архитектуру заложить сильное решение под изменения большинства требований. РП защищает границы проекта: договоренности, сроки и бюджет. Заказчик защищает эффект: экономия ресурсов, максимизация пользы.
Но как же сложно попадать в ожидания, когда логика эффекта живет за границами проектной команды заказчика, когда для команды коммерческой автоматизации не кому сформулировать критерии эффекта. Эту логику должен удерживать кто-то внутри управленческого контура: аккаунт со стороны исполнителя, РМО или сам РП.
В каких разных компания я не работала по уровню или размеру, а за эффектом на стороне исполнителя следить практически не кому.
Где ROI исчезает из проекта
По своим наблюдениям и неформальному опросу среди коллег могу сказать что результат очень показательный: ROI либо не считают вообще, либо считают один раз на старте при защите бюджета.
Дальше проект начинает жить своей проектной жизнью.
На обследовании появляются новые процессы, ограничения и требования. Скоуп меняется, но расчет эффекта чаще всего остается прежним.
На проектировании эксперт усиливает решение: добавляет надежность, расширяемость, защиту от будущих изменений. Это может быть правильно с точки зрения архитектуры, но решение становится дороже, а вопрос «окупится ли это?» часто остается за кадром.
На согласованиях бизнес приносит новые «очень нужные» требования. Команда спорит о сроках, бюджете и трудоемкости, но редко возвращается к вопросу: это увеличивает эффект или просто расширяет объем работ?
На приемке проверяют соответствие ТЗ. Работают ли функции? Закрыты ли требования? Можно ли подписывать акт? А вот вопрос, стал ли процесс дешевле, быстрее или надежнее для управленческого решения, часто звучит слишком поздно.
Так ROI постепенно выпадает из поля зрения. Проект продолжает управляться сроками, стоимостью и содержанием, но эффект начинает жить отдельно – замирая и умирая в стартовых презентациях.
В итоге проект может быть формально успешным: система внедрена, акт подписан, команда отработала, пользователи получили новый инструмент. Но по эффекту проект может быть провален.
И это один из самых неприятных моментов для РП. Я проживала это на своей «шкуре»: ближе к концу проекта становится почти невозможно «дотянуть» ROI до ожидаемого значения, если на протяжении всего проекта его никто не пересчитывал и не защищал.
Формально это можно назвать управлением ожиданиями. Но по сути это вопрос честности проекта: мы все еще делаем то, ради чего заказчик выделил деньги, или просто тащим согласованный объем работ?
Когда автоматизация действительно работает
Обратный пример – на старте проекта определен ROI и сформирована цель сократить сроки подготовки отчетности МСФО с 15 до 3 дней. И здесь боль не в том, что хочется автоматизацию как таковую (ранее отчетность готовилась в Excel), а конкретные показатели по качеству данных (ручные расчеты корректировок использовали укрупненные данные, которые сложно было доказать и по срокам подготовки отчетности, иначе управленческие решения зависают.
В таком случае автоматизация работает не как цифровая занятость, она реально сокращает цикл, ручной труд и повышает надежность данных для принятия решений.
Разница огромная: деньги связаны с задачей, сроками и качеством.
Как проверить эффект до включения в скоуп
Минимальная алгоритмика простая: если эффект нельзя хотя бы приблизительно пересчитать в деньги, трудозатраты, сроки или стоимость ошибок, задача требует дополнительного обоснования. Это не значит, что ее точно не нужно делать, но и не значит, что ее автоматически можно считать инвестиционно оправданной.
Для грубой оценки достаточно формулы:
Срок окупаемости = стоимость реализации / ежемесячный денежный эффект
Здесь денежный эффект – это сокращение трудозатрат (ФОТ одной FTE), снижения количества ошибок и/или штрафных санкций, уменьшение переделок из-за «человеческого фактора» или сокращение сроков управленческих решений, а как следствие операционных потерь (сложный показатель, но экономисты умеют считать и его).
Это не глобальная инвестиционная формула или модель, но отличный фильтр для задач, которые «болят», но экономически не рентабельны для автоматизации.
Как пример можно привести такую ситуацию: автоматизация стоит 3 млн. руб., а ожидаемая экономия на ручном труде 300 тыс./мес., тогда окупаемость будет 10 мес.
Так же для первичной диагностики можно использовать простые вопросы:
Как часто выполняется процесс или операция?
Сколько людей или подразделений затронуто?
Сколько времени сейчас уходит на процесс?
Приводят ли ошибки к потерям, штрафам, переделкам или искажению управленческих решений?
Есть ли понятная алгоритмика процесса до автоматизации?
Можно ли посчитать эффект в деньгах?
Влияет ли задача на деньги, сроки или качество решений?
Если ответы нет/редко/единицы/мало – смело присваивайте этому вопросу 1 балл. Если - регулярно/иногда/заметно/возможно, то 2 балла. А если – часто/ значимо/существенно/да, то 3 балла.
Если сумма баллов на все вопросы оказалась больше 12, то это отличный кандидат на автоматизацию, можно включать в приоритет к автоматизации и считать реальный ROI.
Если сумма баллов на все вопросы оказалась больше 8, но меньше 12, то нужно тщательнее проверить эффект и готовность процесса к автоматизации.
Если сумма баллов 8 и меньше, то высок риск цифровой занятости.
Задача этих вопросов – это быстро отделить задачи, которые действительно могут дать эффект, от требований, которые попали в пул работ потому, что кто-то хочет, чтобы было красиво или чуть правильнее (нет предела совершенству) или кто-то громче всех кричит.
Эти вопросы близки к валидации бизнес-требований по BoBOK и их можно использовать еще перед стартом всех работ.
Как балансировать решения?
Сама по себе диагностика эффекта до старта работ хороша, но этого мало, чтобы в течении проекта не потерять хороший ROI. Проект может терять эффект с колоссальной скоростью если одна из логик проекта будет превалировать.
Если будет доминировать экспертная логика, то проект рискует получить избыточное качество. Если доминирует логика РП, то – проект может слабо реагировать на изменения, но удержаться в изначальных рамках «железного» треугольника. Если будет доминировать логика эффекта, то – проект может потеряет управляемость, а команда потеряет стабильность из-за перегруза и изменений приоритетов.
На практике чаще всего встречаются споры по запросам на изменения, где все участникам нужно договориться и принять взвешенное решение:
Запрос | Проверка логикой эксперта | Проверка логикой РП | Проверка логикой эффекта |
Делаем строго по ТЗ | ТЗ отражает реальные бизнес-процессы? | Можно ли управляемо внести изменения? | Сохраняется ли ROI при изменении бизнеса? |
Нужно автоматизировать весь процесс | Процесс стабилизирован? | Как разбить процесс на этапы с отделяемой пользой? | Где в процессе находится основной источник потерь? |
Нужны быстрые результаты | Упрощение снизит качество? | Какой результат можно зафиксировать как отдельный этап? | Какой результат даст максимальную отдачу? |
Давайте добавим еще вот это… | Это снижает риск? | Как изменятся сроки и стоимость? | Это увеличит ROI или просто расширит объем работ? |
Бизнес очень просит вот это | Это стандартный сценарий работы? | Какие задачи нужно убрать, если берем эту функцию сейчас? | Какое влияние это оказывает на общий эффект проекта? |
Когда запрос прогоняют по трем логиками, то спор выходит за рамки личных и необъективных дискуссий, тогда легче найти баланс в решениях. А до такой проверки у команды я чаще всего наблюдаю самообман и самолюбование авторитета, чье решение превалирует над другими.
Вместо вывода
Если участники проекта защищают только свою часть успеха проекта, то результат может быть провальным. Эксперт хочет сделать качественно, РП – управляемо, а владелец эффекта – увидеть максимальную отдачу.
Если хотя бы одна логика превалирует, то даже самый хороший проект на старте теряет баланс. Экспертная логика без логики РП может раздуть скоуп. Логика РП без оглядки на отдачу будет работать только на план ради плана. А фокус на логику эффекта без управления превратит управление с перегруз команды и «дерготню» приоритетов.
Хорошая автоматизация — это не просто «сделали по ТЗ». Это качественное, управляемое решение, достаточно полезно, чтобы заказчик увидел эффект, а не просто еще одну систему с новыми полями, ручными корректировками и отчетами, которые не меняют управленческое решение.
А в ваших проектах ROI остается в наблюдаемом контуре после защиты бюджета — или тоже исчезает после старта?