Когда компания начинает импортозамещение, со стороны все выглядит достаточно просто: подобрать российские аналоги, перенести данные и продолжить работу. Но на практике с заменой ИТ-инфраструктуры почти никогда не бывает все просто.
Разбираемся, почему даже обычная смена почтового клиента может неожиданно затронуть критичные бизнес-процессы.
С чего начать?
Самая распространенная ошибка – начинать миграцию с выбора нового ПО. На практике все начинается с обследования текущей инфраструктуры.
Важно выяснить:
- какие системы реально используются;
- какие функции они выполняют;
- насколько они критичны для бизнеса;
- есть ли скрытые зависимости;
- что уже давно можно отключить.
Очень часто бывает, что системы используются не так, как предполагалось изначально.
Например, компания планирует заменить почтовый клиент. На первый взгляд – простая задача. Но в процессе выясняется, что через него работает специализированный документооборот или автоматически формируются отчеты.
Если такие нюансы не обнаружить заранее, после миграции бизнес может столкнуться с неожиданными сбоями.
Почему важно проверять совместимость заранее?
В крупных инфраструктурах редко меняется только один компонент. Обычно приходится подбирать целый набор решений: операционные системы, почтовые сервисы, средства виртуализации, системы безопасности и так далее.
И здесь важно смотреть не только на функциональность каждого продукта по отдельности, но и на их совместимость между собой. Иначе можно столкнуться с неприятной ситуацией, когда уже после внедрения производитель сообщает: «Это не поддерживается. Так нельзя».
Именно поэтому компании часто работают через интеграторов. Они знают ограничения разных решений, взаимодействуют с вендорами и помогают выстроить архитектуру, в которой все компоненты смогут нормально работать вместе.
Как сделать переход незаметным?
В большинстве случаев инфраструктуру меняют поэтапно. Полностью заменить все сразу – слишком рискованно.
Для большинства сотрудников достаточны базовые инструменты: браузер, почта, мессенджеры, офисные приложения. Если компания уже использует веб-версии сервисов и стандартные форматы документов, смена операционной системы может пройти почти незаметно.
Столкнутся с трудностями в основном те, кто работает со сложными формульными моделями, например, отчеты о прибылях и убытках (PnL-отчеты), напрямую связанные с базами данных, или те, кто готовит внешние презентации, требующие точного сохранения фирменных шаблонов.
Отдельные риски кроятся в старых программах, самописных информационных системах, особенно если автора или знающего разработчика уже нет в компании. После различных слияний, поглощений и реорганизаций накапливаются программы, о которых знают только, «как» они работают, но знания «почему так» уже утеряны. Проблемы возникают, когда эту устоявшуюся систему начинают «шатать».
Почему тестировать должны не только ИТ-специалисты?
Еще одна распространенная ошибка – поручать проверку новой системы исключительно ИТ-отделу.
Технически приложение может запускаться корректно. Но это не означает, что бизнес-функции работают как раньше. Например, открыть «1С» несложно. А вот проверить корректность сложной производственной отчетности способен только профильный специалист.
Поэтому в тестировании обязательно должны участвовать владельцы сервисов и бизнес-пользователи – именно они понимают прикладную сторону процессов.
Почему пользователей нужно готовить заранее?
Даже успешная миграция вызывает стресс у сотрудников, если их резко лишают привычных инструментов.
Поэтому важно минимизировать количество изменений, не менять рабочую среду слишком часто, заранее обучать пользователей. Практика показывает, что длинные текстовые инструкции теперь почти не читают. Эффективнее выглядят короткие видеоролики, которые наглядно отвечают на главные вопросы: «Где вот эта привычная мне функция?», «Как этот инструмент работает?». Такой формат снимает огромный пласт обращений в техподдержку.
С чего начинать изменения?
Если в компании нет четкого понимания, как двигаться дальше, стартовая точка почти всегда одна – обследование инфраструктуры.
На этом этапе специалисты:
- анализируют текущие системы;
- выявляют зависимости;
- оценивают риски;
- рассчитывают примерные бюджеты;
- определяют сроки и сложность миграции.
Результатом становится отчет, на основе которого уже можно принимать управленческие решения.
Что с безопасностью?
Важный нюанс – в процессе любых изменений нельзя забывать про инструменты безопасности.
При замене одного компонента на другой всегда нужно проверять: остаются ли ваши средства защиты актуальными и совместимыми? Это может стать как точкой старта для изменений, так и ограничивающим фактором. Универсального решения здесь нет – каждый случай требует отдельного анализа и продуманного подхода.
Поэтому вопросы информационной безопасности должны учитываться еще на этапе проектирования миграции, а не после внедрения.
Какие выводы?
Импортозамещение – это не просто смена программного обеспечения. Это глубокая трансформация всей ИТ-среды компании.
Успешный переход зависит не столько от выбора конкретного продукта, сколько от качества подготовки:
- насколько подробно обследована инфраструктура;
- выявлены ли скрытые зависимости;
- учтены ли бизнес-процессы;
- подготовлены ли пользователи;
- продуманы ли риски и этапы миграции.
Например, в системе Колибри-АРМ, которая используется в том числе в проектах замены одной операционной системы на другую, имеются шаблоны конфигурации для миграции с Windows на Linux. При этом потребуется донастроить их информацией, например, какие файлы сохранять и где хранить пользовательские данные на время миграции.