Эксперты Staq определили пять ключевых ошибок российских компаний при выборе платформенных решений в 2026 году

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

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

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

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

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

Четвертая ошибка — выбирать платформу ради ИИ, не оценив готовность собственных данных. Интеллектуальный помощник может классифицировать обращения, находить похожие инциденты и предлагать дальнейшие действия. Для этого ему нужны корректные сведения об объектах, история заявок и результаты работ. Если информация неполна или противоречива, сотрудники будут тратить время на исправление маршрутизации и проверку рекомендаций. До выбора решения следует определить задачу для ИИ и проверить её выполнение на данных компании. Оценивать нужно правильность обработки обращений, число ручных исправлений и изменение сроков работы.

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

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

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

Следующий этап — пилот на одном объекте. До запуска фиксируют исходные показатели, потом оценивают изменения при сопоставимой нагрузке: время обработки задач, соблюдение сроков, объём ручной работы и затраты.

«Я бы предложил заказчику проверить, как платформа поведёт себя, когда привычный порядок работы изменится: сменится подрядчик, появится новая площадка или потребуется пересмотреть правила обслуживания. В этот момент станет понятно, насколько компания свободна в развитии своего решения и сколько ей будет стоить следующий шаг. Задача вендора — заранее объяснить эти условия, включая ограничения продукта. Заказчик должен понимать, какие изменения он сможет провести своими силами и где ему потребуется наша помощь», — Евгений Гусев, генеральный директор Staq.