Как работать российским компаниям в условиях ухода зарубежных вендоров
Замена на российское ПО
Многие компании в России, ранее использовавшие зарубежные платформы, вынуждены срочно перестраивать процессы сразу по всему контуру. Для решения многих задач есть отечественные аналоги, среди наиболее популярных – ИТ-продукты “1С”, “Битрикс24”, ELMA, “Контура” и многих других. Это один из наиболее популярных способов решения проблемы.
Однако не все из них могут стать полноценной заменой в каждом конкретном случае. Основная сложность – в наличии развитой функциональности, которая закрывала часто специфические потребности бизнеса. Чтобы понять это, необходимо:
составить подробную карту всех систем, сервисов и приложений;
провести инвентаризацию функциональности;
проанализировать объём данных и то, как эта информация хранится;
составить список альтернативных российских платформ и приоритизировать его;
сравнить возможности текущей и выбранных систем: какие задачи новое решение закрывает, нужна ли доработка функциональности.
Как только компания определилась с решениями для замещения, наступает сложный этап миграции данных из приложений уходящих вендоров на российские аналоги. Этот процесс достаточно сложный, особенно, когда перенести надо несколько систем. Крупные компании даже создают отдельные команды для “переезда” из платформ Oracle, Microsoft и SAP на российские решения или приложения с открытым исходным кодом. Чтобы заменить функциональные возможности и производительность, перенести данные без потерь, нужна слаженная работа большого количества технических специалистов. Однако такие затраты окупаются сохранением критически важной информации и надежностью эксплуатации.
В сложных случаях или при отсутствии собственной ИТ-команды миграцию можно передать на аутсорсинг российским ИТ-интеграторам. Как правило, у них не только большой опыт реализации подобных проектов, но и более гибкие инструменты, часто недоступные российскому бизнесу.
При смене ПО компаниям нужно быть готовыми к тому, что некоторые бизнес-процессы могут пострадать или их нужно будет изменить. Вырастет бюджет на закупку софта и переобучение ИТ-отдела. Не исключено, что на время упадёт производительность.
Как показывает практика, после переезда на новый софт у пользователей возникает недовольство. Чаще всего оно связано с неправильной настройкой системы и отсутствием опыта эксплуатации конкретного ПО (при условии, что это качественный ИТ-продукт). К этому нужно быть готовыми и набраться терпения, ведь после миграции бизнес получит техническую поддержку на всех уровнях и гарантию обновлений.
Также не стоит сбрасывать со счетов low code платформы, которые работают по принципу конструктора. Такие решения позволяют пользователям самостоятельно создавать нужный ИТ-продукты из готовых модулей и с минимальным привлечением разработчиков, без написания кода и за очень короткий срок. Такие продукты обычно имеют ограниченную функциональность, но помогают быстро протестировать новое решение и закрыть “дыру” в бизнес-процессе.
Среди наиболее востребованных low code платформ – BPMS, которые позволяют автоматизировать целые бизнес-процессы с несколькими ответственными за согласование. Такие системы имеют собственную логику и поддерживают обработку заявок в отделе кадров и бухгалтерии, предоставление справок для сотрудников и многое другое. Более того, на российском рынке есть функциональные альтернативы международным BPM-решениям. Среди наиболее популярных – Comindware и ELMA с low code платформами, интеграциями с ЭДО и прочими внешними системами, а также поддерживающие BPMN для описания бизнес-процессов.
Переход на микросервисную архитектуру и OpenSource
Может ли российское ПО стать полноценной заменой глобальных вендоров? Иногда да, но чаще – нет. И здесь бизнес – особенно компаний с ограниченным набором критичных функций, специфичными и узкими задачами – выбирают выбирают кастомизированную разработку. Они расширяют и развивают функциональность уже внедрённых зарубежных платформ новыми модулями на базе OpenSource. Такой подход позволяет быстро внедрять нужные возможности без изменений в существующем проекте.
Помимо этого, у микросервисной архитектуры много других преимуществ в текущих условиях. Среди них:
Масштабируемость. Благодаря децентрализации микросервисов такую архитектуру легко масштабировать: поднимать дополнительные экземпляры решения легко, и при этом сама база не перегружена запросами от всей системы.
Гибкость к изменениям. Даже если монолит хорошо спроектирован, при разрастании системы его всё тяжелее поддерживать, и в какой-то момент код нужно будет рефакторить. Микросервисы удобнее: можно легко пересобрать решение и дополнить проект новыми экземплярами.
Надёжность. Изолированность микросервисовповышает отказоустойчивость системы в целом.
Быстрые релизы. Отдельный микросервис проще дорабатывать, тестировать и выпускать в продуктив, чем сложный монолит.
Широкий технологический стек. Каждый микросервис может построить на любых технологиях, используя разные языки программирования и фреймворки.
Аналитики и раньше отмечали рост доверия к микросервисной архитектуре в бизнес-среде. Например, по данным прошлогоднего исследования CNews Analyticsи «Инфосистемы джет», 45% компаний, у которых есть внутренняя ИТ-команда, используют технологию в продуктиве, 23% – в тестовой среде. Вероятно, новые ограничения этого года подстегнут рост сразу обоих показателей.