Как снизить риски в ситуации с отказом от зарубежного ПО

главные задачи:
Оценить степень этих рисков
Определить пути максимального нивелирования этих рисков
Насколько решение этих задач очевидно?

ряда взаимосвязанных, интегрированных друг с другом систем
Связь систем(ы) со внешними системами, находящимися не на стороне заказчика
Фактор времени
Критичность системы для предприятия
Правильность выбранного пути решения задач впрямую влияет на результат и бюджет

необходимо понять с какого рода проблемой имеет дело конкретное предприятие. Поэтому первичным этапом необходимо провести АУДИТ системы и ее окружения.
На какие же вопросы нам должен ответит аудит?

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

выбором того, кто сможет ее осуществлять
(например, важно определить, нужна ли будет работа с исходным кодом или нет)
4. Определить риски, связанные с лицензированием текущего ПО.
(например, если лицензия, изначально, продлеваемая, то возникнет проблема по истечение лицензии. Если лицензия perpetuum, то продуктом можно продолжать пользоваться, однако, возникнет проблема с организацией технической поддержки. Если же есть доступ к исходному коду, можно начать работать с ним.)
5. Последний результирующий этап аудита- Построение плана решения задач локализации с детализацией до конкретных технических задач

что мы делаем с ПО
Заменяем на уже существующее отечественное ПО, если…..
Пишем свое кастомное ПО, если…
Модифицируем текущее ПО, если есть доступ к гибкой настройке или коду
ПРИМЕР.

Миграция с облака на облако
(например, с Azure или AWS на YandexCloud или SberCloud)
ПРИМЕР. С2С –просто показываем особенности процесса. Что входит, каких процессов и затрат можно ожидать)
Миграция с облака на локальные сервера (локальное облако)
Важно помнить, что решение разработанное в облаке - разрабатывалось с учетом функционала облака. Если вы захотите мигрировать его в локальное облако (on-premise) или разработать заново, то вам нужно будет реализовывать и весь тот функционал, который облако давало по дефолту. А это уже совсем другие бюджеты
При миграции облачных решений- необходимо сравнить функционал исходного и нового облаков. Необходимо сравнить архитектуру облаков и функционал. При сильно несовпадающей архитектуре и функционале, по факту, нужно будет переписывать все заново (а не мигрировать). Это должно влиять на принятие решения

отношению к бизнес процессам
Для оценки возможности забрать данные из текущих систем и миграции их в новые системы
Для создания механизма для переиспользования данных для других целей при переориентации производств
Аудит данных помогает решить задачи
перестройки производств для производства другого товара
анализа электронных продуктов, на пригодность для переиспользования и т.п.
группировки данных для дальнейшей работы с ними
по оценке стоимости переориентации производств
интеграции с новыми поставщиками и системами
ПРИМЕР:
Помимо замены одной системы на другую, у нас могут возникнуть задачи по изменению процессов производства. Например, слишком "ручные" операции приводят к дополнительному искажению данных- как случайному, так и намеренному ( возникшему как попытка упрощения работы с данными конкретным индивидуумом)

системы к техподдержке
Это может быть
Либо подготовка документации для дальнейшей самостоятельной поддержки предприятием
Либо подготовка для передачи стороннему провайдеру
ПРИМЕР