Что не так с российским импортозамещением ПО? Инструкция, как делать нестыдные аналоги софта

Это Атвинта. Мы импортозамещаем софт для промышленности с 2019 года и знаем, как вдохновиться зарубежными сервисами, но в результате сделать круче. В этой статье рассказываем, как вендорам и крупным компаниям создавать достойные аналоги зарубежных продуктов под свои процессы.

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

К тому же, ключевые корпорации просто обязаны импортозаместиться — этого требует закон. Так, госорганам и госкомпаниям запрещается использовать иностранное ПО на объектах КИИ с 1 января 2025 года.

Эксперты отмечают следующие проблемы, которые не позволяют компаниям полноценно перейти на отечественные продукты:

Так что переезд на аналоги остается болью для всех лидеров рынка. Мы занимаемся разработкой импортозамещающего ПО с 2019 года. Тогда один из наших клиентов попросил нас создать аналог на замену продукту зарубежного вендора.

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

Читайте наш флагманский кейс импортозамещения:

При импортозамещении ПО можно выбрать 3 пути:

У всех подходов есть плюсы и минусы. Мы рассказали о них в нашей свежей статье:

Подробности, как сделать выбор, читайте в материале выше. А если коротко:

У нашего клиента был опыт перехода от американского вендора к разработке собственной экосистемы с Атвинтой.

Причины перехода:

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

При этом сотрудничество с Атвинтой в долгосрочной перспективе ему обошлось дешевле, чем коробочное решение иностранного вендора.

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

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

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

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

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

Выявить реальные потребности пользователей помогут:

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

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

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

Разработка интерфейса будет зависеть от успеха и растиражированности импортозамещаемого продукта.

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

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

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

Так что если стоит цель заменить популярный продукт — отдавайте предпочтение устоявшимся практикам и паттернам.

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

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

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

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

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

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

В своих проектах импортозамещения ПО мы придерживаемся схемы с запуском MVP и поэтапных доработок из бэклога. Этот подход актуален как для вендоров, так и для разработки внутренних корпоративных сервисов.

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

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

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

Читайте подробнее кейсе разработки цифровой фабрики идей:

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

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

В импортозамещении софта мы придерживаемся гибких методологий разработки: Agile и Scrum. Они позволяют адаптироваться к изменяющимся требованиям и сохранять высокую скорость реагирования на запросы клиентов.

Мы разбиваем проект на спринты — небольшие управляемые части — что позволяет эффективно управлять изменениями и улучшать продукт на каждом этапе.

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

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

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

Поэтому основная задача — помочь пользователям как можно быстрее адаптироваться к новому ПО.

В одном из наших проектов мы применили гибкий подход, чтобы минимизировать сопротивление и сделать комфортный переход на импортозамещенное ПО.

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

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

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

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

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

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

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

Подведем итоги статьи чек-листом по импортозамещению ПО:

✅ Планирование бюджета и сроков — изучите рынок и составьте смету на импортозамещение. Возьмите консультации у вендоров и аутсорс-разработчиков, чтобы узнать сроки внедрения и примерную оценку бюджета. Учитывайте не только стоимость лицензии/разработки, но и расходы на интеграцию, обучение и техническую поддержку.

✅ Подбор исполнителей — найдите надежных партнёров или команду разработчиков с опытом в импортозамещении ПО, чтобы обеспечить качественное выполнение проекта, например, такой опыт есть у Атвинты

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

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

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

✅ Интеграция с существующими системами — обеспечьте совместимость и корректную интеграцию с уже действующими внутренними и внешними системами и сервисами

✅ Соответствие требованиям закона — убедитесь, что новое ПО отвечает местным законодательным нормам и стандартам, включая требования по безопасности данных

✅ Тестирование и качество — проводите тестирование на всех этапах разработки, чтобы выявить и устранить ошибки до запуска

✅ Анализ рисков — составьте карту рисков, связанных с переходом на новое ПО, и разработайте план по их минимизации

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

✅ Техническая поддержка и обновления — выделите специалистов для службы поддержки и выпуска обновлений

✅ Обратная связь от пользователей — вовлекайте конечных пользователей в процесс разработки, собирайте их отзывы и адаптируйте продукт в соответствии с их потребностями