Как сочетать «свое» и «чужое» ПО
Февраль 2022 года разделил ситуацию с программным обеспечением в России на до и после. Больше остальных пострадали компании, находящиеся под санкциями. Многие крупные зарубежные вендоры отказались от поставок продуктов в Россию. В статье речь пойдет о том, как в сложившейся ситуации можно уменьшить риски для технологических департаментов и в перспективе обеспечить ИТ-независимость страны и ее предприятий.
Для всех компаний, столкнувшихся с необходимостью экстренного импортозамещения ПО, важно использовать несколько простых принципов, которые в краткосрочной перспективе позволят снизить риски и стабилизировать работу. В первую очередь применение этих принципов ляжет на плечи технологических подразделений.
Отказ от обновлений
Важно отказаться от обновления, остановившись на последней рабочей версии используемых продуктов. Уже купленные продукты никто не сможет отобрать, не будет обновления и поддержки. Нередко речь может идти о сильно кастомизированных программных продуктах, поддержку которых осуществляет не только вендор, но и сам ИТ-департамент.
Некоторые компании годами не обновляли программные решения, и старые версии успешно работали без лицензионной поддержки, новых функций и т. п. Например, Oracle, решения от IBM Microsoft. Между тем ПО выполняло свои задачи на уровне конкретного бизнеса, нужд конкретного предприятия. От обновлений следует воздержаться не только тем предприятиям, которые уже находятся под санкциями, но и тем, кто даже гипотетически может под них попасть. При возможности неработающие обновления нужно убрать.
Наиболее остро встанет проблема для тех компаний, для которых критичны регулярные обновления и поддержка решений со стороны вендоров. Особенно если эти компании попали под непосредственные санкции. Им необходимо максимально быстрое импортозамещение, которое произойдет только с привлечением опытных специалистов по внедрению новых продуктов и приложением больших усилий при переподготовке персонала. Задача ИТ-департаментов — нанять таких специалистов или оценить компетенции и опыт сторонних компаний, способных провести миграцию и внедрение под ключ.
Отказ и переход в порядке иерархии критических функций
Для того чтобы бизнес, производство и другую деятельность компании минимально затронула миграция, необходимо создать иерархический (по степени значимости для компании) список используемых зарубежных программных продуктов и функций. Исходя из иерархии, следует максимально быстро ипортозамещать те решения, что содержат наиболее значимые критические функции, нарушение которых способно максимально повлиять на работу компании.
Если точных аналогов найти не удастся, что можно прогнозировать с высокой вероятностью, следует использовать несколько российских продуктов. Сохраняя старые версии и отказываясь от обновлений вендоров, стоит создать минимально жизнеспособную альтернативу из российских программ и разработать план по их ускоренному внедрению в случае отказа необновляемых иностранных продуктов. Здесь также критична роль ИТ-департаментов, которые должны правильно расставить приоритеты импортозамещения и определить, какой состав функций в российских аналогах будет минимально жизнеспособным.
Не писать «на коленке»
При наличии коммерческого решения и собственного корпоративного кастомного продукта» ИТ-департамент должен убедить руководство компании в том, что коммерческий продукт предпочтительнее. В России часто происходит иначе. Небольшие ИТ-подразделения пишут «на коленке» узкопрофильное сырое решение, компания использует его пару лет, после чего продукт умирает и проблема появляется вновь. Это связано с желанием подразделений получить дополнительное финансирование. В действительности невозможность масштабирования продуктов, созданных силами небольшого ИТ-подразделения, нивелирует любые преимущества внутриотраслевой кастомной разработки. Качество поддержки таких продуктов также страдает.
Проблема времени и работа на результат
Для того чтобы написать собственный софт, необходимо время, часть продуктов можно заместить сразу, но существуют корпоративные решения, а ними все происходит не так быстро. На время разработки их заменит необновляемый импортный софт, и основные ресурсы должны направляться на заказ новых решений у отечественных аутсорсеров, так как именно эти компании обладают достаточными компетенциями и возможностями для создания качественных продуктов в относительно короткие сроки. ИТ-подразделения заинтересованных организаций должны в свою очередь четко сформулировать требования к новым продуктам, чтобы те отвечали отраслевым потребностям. ИТ-отделам необходимо работать на конкретный результат, а не фиксироваться на процессе перехода.
Параллельная работа старых и новых продуктов
В период внедрения и адаптации сотрудников компаний к новым продуктам и системам ИТ-подразделения должны обеспечить параллельную работу старых и новых продуктов, особенно это касается критической ИТ-инфраструктуры. Например, при замене SAP на «1С: Предприятие» мы некоторое время работали одновременно в двух системах. Такой подход нужен, чтобы гарантировать постепенный процесс адаптации, минимизировать ошибки и не допустить остановки бизнеса.
Выводы
Процесс перехода на отечественный софт потребует времени. В этот период ИТ-подразделениям следует обеспечить полноценное использование, стабильную работу и собственную поддержку уже купленных версий без обновления. Запретить обновления импортного ПО для обеспечения ее минимально достаточной работоспособности. Подготовить списки ПО для замены существующих иностранных решений и требования к новым продуктам, которых пока нет рынке. Кроме того, необходимо исключить лоббизм разработки «на коленке», подготовить лиц, принимающих решения о приобретении полноценных коммерческих продуктов отечественных разработчиков.
Опубликовано 31.05.2022
