К импортозамещению и задачам по интеграции нужно подходить грамотно и взвешенно, как к серьезным стратегическим проектам, охватывающим все бизнес-процессы в компании или на предприятии.
Сегодня российским ИТ-специалистам приходится решать целый спектр задач, связанных с переходом на отечественные решения с зарубежных продуктов. Еще год назад большинство западных разработчиков ушли с российского рынка, громко хлопнув дверью. Заказчикам пришлось срочно искать альтернативу, и часто это были не самые лучшие продукты, а те, что оказались в данный момент на рынке и ими можно было воспользоваться без лицензионных рисков. Прошло несколько месяцев, и пользователям стали очевидны недостатки тех продуктов, которые они приняли на вооружение взамен западных. Многие поняли, что к импортозамещению и задачам по интеграции нужно подходить грамотно и взвешенно, как к серьезным стратегическим проектам, охватывающим все бизнес-процессы в компании или на предприятии. И здесь приходится решать практические задачи. Помочь в этом могут эксперты ИТ-рынка, которые досконально разбираются как в зарубежных платформах, так и в особенностях российских продуктов. Мы уже начали разговор о сложностях перехода на российские ИТ-решения в одном из предыдущих номеров нашего журнала. Сегодня хотелось бы продолжить тему.
Александр Галинский, директор департамента маркетинга компании DCLogic, советует для подготовки к миграции с зарубежного ПО на российское прежде всего провести оценку текущей ИТ-инфраструктуры предприятия, тем самым выявив возможные проблемные места. Далее эксперт рекомендует разработать план миграции, определив последовательность действий, таким образом снизив риски и обеспечив бесперебойность работы систем. Третьим этапом, по мнению Александра, должно стать обучение персонала, например, на курсах или семинарах, посвященных внедряемому решению. В заключение стоит провести пилотное тестирование, чтобы проверить и выполнить отладку или доработку решения. В конце следует убедиться, что нормы безопасности соблюдены, а поддержка и обслуживание работают исправно.
«При реализации крупных проектов по импортзамещению необходимо учесть такие факторы, как совместимость новых ИТ-решений с существующими системами и программным обеспечением, возможность интеграции новых решений в ИТ-инфраструктуру компании, обеспечить защиту от внешних угроз и безопасность обработки и хранения данных, доступную и квалифицированную техническую поддержку и обслуживание, оценку подготовленности собственного персонала к работе с новым решением, оценку финансовой эффективности в долгосрочной перспективе, устойчивость и надежность решений, соответствие регуляторам», — добавляет он.
Александр Галинский (DCLogic): «Чтобы грамотно организовать и провести пилотный проект по импортозамещению, лучше всего выбирать процессы, которые имеют низкую степень зависимости от существующего зарубежного ПО. Это позволит выявить преимущества и недостатки нового решения за короткий период времени».
Николай Молчанов, директор технологического консалтинга компании «Мобиус Технологии», рекомендует всегда следовать наработанной методологии по подготовке к миграции и начинать с проектирования возможных вариантов технологического стека и архитектуры будущего решения. «Основная задача — сохранение функциональности и обеспечение цифровой независимости, при этом компоненты могут быть как с открытым исходным кодом, так и коммерческие решения из реестра отечественного ПО», — отмечает он.
О важности аудита предупреждает Леонид Перминов, руководитель направления контактных центров компании CTI. «Основные риски, которые возникают при проведении миграции, — это потеря наработанных данных, некорректная работа интеграций с внешними системами, невозможность воспроизвести отлаженные бизнес-процессы в новом продукте. Чтобы избежать столь неприятных последствий, мы рекомендуем проводить полноценный аудит. «Это позволит определить объем реально используемой функциональности и список актуальных интеграций с внешними системами», — говорит он. — Там, где сильна in-house-разработка, часто встречающаяся проблема — отсутствие документации и потеря экспертизы по интеграционным компонентам, разработанным собственными сотрудниками».
Для аудита и составления детального ТЗ Леонид Перминов (CTI) советует приглашать интегратора. Плюсы привлечения внешней компании заключаются, по его словам, в способности взглянуть на процессы свежим взглядом, не ориентируясь на традиционно сложившиеся модели, и рассматривать весь проект в комплексе.
«Недостаточное планирование на подготовительном этапе может обернуться существенным увеличением трудозатрат и ростом бюджета проекта», — замечает эксперт.
Сергей Чуканов, генеральный директор компании SimpleOne, предупреждает, что при планировании миграции не нужно повторять «как было», а стоит задуматься и оценить «как должно быть». «В обычных условиях, даже если система устаревает и к ней накапливаются замечания, компании могут годами не решаться на миграцию из-за высоких рисков, сложности проекта, бюджетных ограничений. Неочевидный плюс вынужденной миграции — она снимает много лишних сомнений. Поэтому перед сменой ПО важно оценить, все ли функции, которые были в прежней системе, действительно использовались? Каких возможностей не хватало? Этот анализ поможет подобрать систему, которая будет отвечать вашим требованиям. Необходимо решить, будете ли вы переносить реализованную логику процессов «как есть» или в рамках проекта необходимо провести аудит и реинжиниринг бизнес-процессов. Если сроки реализации проекта достаточно сжатые, можно ограничиться только автоматизацией и повторением процессов в новой системе. Все изменения перенести в следующий проект», — говорит он. Второе предостережение Сергея Чуканова (SimpleOne) касается важности пользовательского опыта. Вместо повторения «как было» должна быть оценка «как должно быть».
Сергей Чуканов (SimpleOne): «Убежден, что только технически сильный продукт имеет шансы на большой успех. Возросший интерес к российским ИТ-решениям подстегивает нас больше инвестировать в развитие и непрерывное улучшение своих продуктов».
«Миграция — это возможность избавиться от ненужного и добавить нужное. В вопросе интерфейса системы и удобства его использования при миграции может быть два варианта. Первый — необходимо максимально сохранить в новом решении привычные способы взаимодействия с системой. В особенности это касается различных дополнительных кнопок и пунктов меню, упрощающих доступ к нужным блокам и функциональности. Для того чтобы избежать инерции, переучивания и даже сопротивления пользователей, некоторые клиенты просят повторить внешний вид интерфейса в точном соответствии с тем, что было в прежней системе.
Второй вариант — показать более современный и продуманный интерфейс. Формы без множества «лишних» полей, загромождающих экран, удобная навигация, правильная компоновка, легко считываемая информация, контекстная логика, упрощающая заполнение информации, современные стили — как в лучших мобильных приложениях, доступных всем пользователям смартфонов», — объясняет эксперт. Что касается переноса данных, здесь Сергей советует не переносить «все и сразу», а выбрать прежде всего те данные, которые представляют наибольшую ценность для компании. Наконец, наш собеседник советует задуматься, стоит ли переносить исторические данные. «Во многих случаях хорошей практикой считается отказ от миграции исторических данных, — говорит он. — Перенос большого массива данных предполагает множество операций, которые увеличивают сроки реализации проекта, но на практике оказывается, что большая часть данных часто бывает невостребована. При наличии возможности следует сохранить экземпляр прежней системы в режиме «только для чтения», чтобы обращаться к историческим данным».
Если в процессе поиска альтернативы не найдется стопроцентного соответствия функциональности заменяемому решению, то у заказчиков часто возникает вопрос: что лучше, написание с нуля собственной системы или доработка какого-нибудь типового коробочного продукта, либо реинжиниринг процессов без доработки нового ПО? «Под сложные комплексные системы практически никогда не находится 100% соответствия требованиям. Именно поэтому большие российские корпорации разрабатывают собственное ПО под свои уникальные требования», — утверждает Олег Орлов, управляющий партнер сегмента «Аналитические решения» компании IBS.
Олег Орлов (IBS): «В процессе импортозамещения «монолита» не всегда есть возможность найти аналогичный «монолит», поэтому требуется заменить только одно из решений или перейти на комплекс решений от различных поставщиков ПО, не всегда совместимых между собой. В таком случае возникают дополнительные интеграционные связи и потребность в их автоматизации. Однако и стоимость интеграции в сравнении с заменой всей инфраструктуры, как правило, значительно ниже».
«Это все очень индивидуальная история, которая сильно зависит от сложности решения и наличия соответствующих ресурсов. Надо оценивать каждый подход и выстраивать road map. Если процесс получается долгим, то на каком-то этапе может банально не хватить ресурсов либо целесообразность исчезнет, когда на рынке появится готовый продукт с максимально приближенным функционалом», — добавляет Сергей Назаров, заместитель генерального директора по сервису компании CTI.
Сергей Назаров (CTI): «Поскольку замена платформы со всей экосистемой совместимых решений вопрос не быстрый, очень важно обращать внимание на возможности сервисного сопровождения как платформы, так и всех решений. Как правило, после внедрения новых продуктов не только на этапе опытной эксплуатации, но и в течение первого года после перевода решения в «прод» наблюдается значительное количество необходимых доработок, влияющих на стабильность работы. Соответственно, перевод всей экосистемы будет длительным и в определенной степени болезненным в течение некоторого времени».
Если решения «старой» экосистемы не имеют качественного сервисного сопровождения, то интеграция их с новой платформой может усугубить ситуацию.
На некоторое время вариантом может стать параллельное существование двух платформ с постепенной миграцией функционала и поэтапной оценкой целесообразности переноса каждого решения.
О сложности универсального подхода говорит и Дмитрий Шкодырев, руководитель группы консалтинга по инфраструктуре рабочих мест ICL Services. «Сложно давать оценку трудоемкости написания с нуля собственной системы, применительно к области инфраструктуры рабочих мест. Такой подход скорее оправдан при замене бизнес-приложений. Логичным сценарием будет формирование запроса к вендору для оценки возможности реализации конкретного функционала, а в случае невозможности или неприемлемости сроков реализации придется трансформировать бизнес-процессы», — комментирует он. «Важно понимать, что кардинальная смена привычного окружения вызовет стресс и увеличение времени выполнения привычных операций для пользователя. Таким образом, пилотный проект или развертывание тестового стенда, настроенного для выполнения конкретных бизнес-функций представителей заказчика, поможет адаптироваться и изучить новое решение до его полноценного внедрения в корпоративную среду», - добавляет Дмитрий.
Нередко в качестве замены нативного приложения или системы эксперты рекомендуют выбрать облачное решение, при условии, конечно, что оно предоставляется российским облачным провайдером, соответствует всем требованиям законодательства и размещено на серверах, физически находящихся на территории нашей страны. «В своей практике мы неоднократно прибегали к использованию облачных ресурсов для частичной или даже полной миграции инфраструктуры. Из преимуществ — это мгновенный доступ к вычислительным мощностям, управляемость, безопасность и прозрачность, что в условиях сложностей с поставками нового оборудования является очень хорошим решением. Традиционный минус — стоимость облачных ресурсов, которая была выше в сравнении с закупной собственного оборудования. Учитывая текущие сложности с поставками оборудования, это уже не дает такого значительного перевеса и, безусловно, потребление локальных облачных ресурсов получило новый импульс», — отмечает Николай Молчанов («Мобиус Технологии»).
Николай Молчанов («Мобиус Технологии»): «В проектах обеспечения цифровой независимости мы рекомендуем классифицировать системы по уровню критичности и определять взаимосвязи. Почему именно эти две плоскости, потому что крайне важно понимать влияние изменений одной системы на работу других, чтобы не нарушишь интеграционную целостность».
«Сегодня PaaS- и SaaS-системы коммуникаций становятся хорошей альтернативой для замещения как облачных провайдеров услуг, в том числе Zoom, Webex, Teams, так и решений, размещенных в собственной инфраструктуре, — говорит Альберт Исламов, директор департамента коммуникационных сервисов компании CTI. — Системы западных производителей утратили возможность модернизации, расширения абонентской емкости, нет и обеспечения технической поддержки. Они функционируют на излете своего жизненного цикла, по инерции, и мы видим, как все больше компаний начинает искать для себя альтернативы. PaaS- и SaaS-модели представляют собой комплексные предложения, где в состав решения входят и услуги по развертыванию, и сами лицензии или подписки на ПО, и сопровождение, и аренда вычислительных ресурсов, каналов связи и т. д. PaaS и SaaS предоставляют большую гибкость при использовании сервиса, позволяют легко и быстро увеличить абонентскую емкость, сделать дополнительные интеграции».
По словам эксперта, такой сервис может быть развернут быстро, что немаловажно при экстренной необходимости перехода с сохранением непрерывности коммуникаций сотрудников и партнеров компании. К минусам, по его словам, можно отнести некоторые сомнения в безопасности таких решений, но при должном подходе к построению и сопряжению систем все сомнения удается развеять.
«На самом деле отечественное ПО для инфраструктуры рабочих мест уже предлагается, как в варианте SaaS и PaaS, так что выбор конкретной реализации существенно зависит от предпочтений заказчика. Плюсы и минусы в каждом случае, скорее всего, будут индивидуальны. Например, кто-то предпочитает больше затрат относить на OPEX с последующим возвратом НДС, а кому-то важнее капитализация», — утверждает Дмитрий Шкодырев (ICL Services). Важно понимать, что кардинальная смена привычного окружения вызовет стресс и увеличение времени выполнения привычных операций для пользователя. Таким образом, пилотный проект или развертывание тестового стенда, настроенного для выполнения конкретных бизнес-функций представителей заказчика, поможет адаптироваться и изучить новое решение до его полноценного внедрения в корпоративную среду.