Смертные грехи поставщиков и покупателей автоматизации
Автоматизация давно стала мейнстримом. Большинство компаний уже сформировали цели и бюджеты по цифровой трансформации на 2025 год. Будут ли все эти проекты успешными, уложатся ли в бюджет и график внедрения?
Расскажу подробнее о наиболее частотных негативных паттернах, приводящих к лишним затратам, потере времени и провалу ожиданий от проектов по автоматизации на основании опыта работы с клиентами компании «Автоматика».
Слишком общее планирование
Исследование, охватившее 1471 ИТ-проект, показало, что в среднем превышение бюджета составляет 27%, а в одном из шести случаев перерасход достигает 200%, с задержками по срокам до 70%. Подобные риски особенно актуальны для сложных внедрений, таких как SFA-системы (платформы для управления полевым персоналом). Очень часто от компаний, которые запускали проекты по автоматизации, можно услышать: «Мы начали проект с вендором год назад, рассчитывали завершить за шесть месяцев, но до сих пор находимся «в процессе»».
Причина таких задержек зачастую в том, что вендор на этапе согласования ТЗ не подсвечивает риски и нюансы в силу нежелания спугнуть потенциального клиента или из-за недостатка опыта реализованных проектов. При этом заказчик осознает важные детали только на этапе первых результатов, что приводит к многочисленным изменениям уже в ходе работы.
Чтобы максимально детализировать ожидания от результатов проекта по автоматизации, нужно:
- Проанализировать примеры решений из аналогичных кейсов. Для этого вендор должен подробно объяснить, как обычно выполняется интеграция с данными заказчика, какие пользовательские сценарии востребованы, и как выглядит типичная отчетность.
- Создать кликабельный прототип интерфейса. До финального согласования ТЗ заказчик должен увидеть, как будет выглядеть результат для конечного пользователя. Это помогает заранее получить и отработать обратную связь до начала реализации проекта.
Такой подход помогает не только детально спланировать проект, но и способствует установлению доверия между вендором и заказчиком еще до старта работ.
Подмена бизнес-задач технологической возможностью
В корпоративной среде руководители часто получают KPI, связанные с внедрением новых технологий. Например, пять лет назад популярными были проекты с чатботами, сейчас аналогичная ситуация наблюдается с генеративным ИИ.
Такой подход имеет как плюсы, так и минусы. В ряде случаев идея рассыпается под вопросами «какую проблему мы хотим в итоге решить, как часто она встречается и сколько будет стоить, если оставить все, как есть». С одной стороны, цели по инновациям демонстрируют готовность заказчиков экспериментировать, что создает возможности для развития. А с другой, когда речь идет о действительно экспериментальных проектах, важно минимизировать риски и найти оптимальное решение самым коротким путем. Для этого нужно разделить проект на две части: реалистичные задачи, решаемые стандартными инструментами, и экспериментальные. Для последних создается микро-пилот, который в случае успеха переносится на стадию масштабной реализации.
Например, чтобы быть на шаг впереди, в нашей компании мы инвестируем в собственную лабораторию, где тестируем новые технологии за свой счет. Так раз в месяц мы организуем встречи ИИ-клуба для директоров по продажам FMCG. Участники приносят свои кейсы, мы обсуждаем их и выбираем один для разработки прототипа, который внедряем в компании инициатора в качестве бесплатного пилота. С мая 2024 года мы протестировали более 10 идей, из которых три были успешно коммерциализированы: сопоставление разрозненных данных, голосовой терминал данных и голосовая CRM.
Вера на слово в доступность и качество данных
Данные — ключевой ресурс для успешной цифровой трансформации, но часто именно они становятся основным вызовом. Проблема заключается в неполноте, недостоверности и разноформатности данных, а также в том, что заказчики нередко переоценивают их качество.
Причины могут быть разными. Например, в компаниях часто отсутствует единая роль, ответственная за именно консолидацию данных (штатные аналитики — не в счет, им как правило, приходится работать «с тем что есть»). В некоторых случаях данные формально существуют, но их использование в новых сценариях выявляет скрытые проблемы. Например, в Дубае официальные данные об объектах недвижимости доступны через API, но их качество сомнительно из-за занижения цен в некоторых договорах для оптимизации налога на продажу.
При обсуждении проекта важно обсуждать пользовательские сценарии не абстрактно, а на конкретных примерах данных компании. Это позволяет заранее выявить потенциальные проблемы. Например, при разработке голосового терминала для полевых сотрудников выяснилось, что внешний поставщик данных перезаписывает все строки без маркеров обновлений, что приводит к непозволительным затратам времени на обновление информации. Решением в таком случае станет переделка старой интеграции перед реализацией основного проекта.
Еще один пример: заказчику требовалось отобразить бизнес-показатели из хранилища данных и дашбордов для руководства в приложении для полевых сотрудников. Внутренний ИТ-отдел настаивал на дублировании расчетов в приложении, поскольку перенос показателей из BI на сторону хранилища представлял для них внеплановую. задачу. Однако важно было донести, что такой подход неизбежно приведет к расхождениям при изменении методов расчета и создаст дополнительные затраты на их исправление в будущем. Чтобы проект в данном случае стал успешным, нужно убедить заказчика инвестировать больше ресурсов на раннем этапе, чтобы обеспечить целостность данных и избежать двойной работы в дальнейшем.
Отсутствие контроля за управлением изменениями
Иногда даже при согласованном техническом задании и выполненных работах проект оказывается «в подвешенном состоянии»: заказчик не начинает полноценное использование, а вендор не может официально закрыть проект. Такое часто происходит, если автоматизация требует изменения устоявшихся процессов, и компании сложно адаптироваться к этим изменениям.
Например, торговая компания обращается с задачей ускорить цикл закрытия финансовой отчетности. Одним из решений стала автоматизация обработки первичных документов: вместо того, чтобы бухгалтеры накапливали счета и загружали их в 1С большими партиями, был внедрен бот, который с помощью технологий компьютерного зрения распознавал счета и создавал черновики записей для ежедневной проверки и проведения. Несмотря на успешное тестирование, срок закрытия отчетности не сократился, так как ботом пользовались лишь некоторые сотрудники, в то время как остальные продолжали загружать счета в папку по старинке.
Чтобы избежать подобных ситуаций у проекта по автоматизации должен быть ответственный за внедрение нового процесса, определен конкретный срок запуска и выбрана ключевая метрика (в данном случае это был «возраст» счета — время от его выпуска до проведения в 1С). Дополнительно стоит организовать ежедневный мониторинг метрики, а также собирать обратную связь от пользователей раз в неделю. На основе их отзывов уже можно вносить изменения в работу бота, которые повысят удобство использования и точность распознавания документов. В результате такой процесс можно запустить в течение двух недель.
Список проблем при внедрении проектов по автоматизации можно продолжать. Ключ к успеху — опыт и квалификация вендора и понимание заказчика на что обратить внимание при составлении ТЗ и на этапах реализации проекта.
Какие ожидания от проектов по автоматизации у вас не оправдались?