Как с минимальными потерями заменить весь зарубежный ИТ-ландшафт

Несмотря на явные риски, связанные с уходом западных вендоров, зависимость российского бизнеса от зарубежного ПО остается высокой. Более трети (36%) компаний признают, что доля зарубежных решений в их ИТ-ландшафте составляет не меньше половины, 33% организаций говорят об уровне зависимости от 20 до 50%, показало исследование Naumen, проведенное в период с июня по август 2022 года. При этом предприятия, занимающие выжидательную позицию, рискуют оказаться в ситуации, когда из-за окончательного решения об уходе того или иного западного производителя ПО замещение ИТ-продуктов может понадобиться «вчера».

Прежде всего под удар попадают российские представительства крупных предприятий со сложным производственным циклом. Это компании, которые производят какой-либо товар, а также сами отвечают за цепочки поставок и собирают заявки от клиентов. Для таких компаний большинство элементов ИТ-ландшафта критические: прекращение работы даже одной системы может привести к остановке всего бизнеса. 

Частично или полностью с российского рынка ушли Microsoft, SAP, Oracle, Manhattan Associates и другие бренды. Найти готовые продукты для полноценной замены решений международных вендоров смогут не все. При этом малый и средний бизнес вполне способен обойтись функциональностью имеющихся отечественных аналогов.

Крупным же компаниям, особенно тем, которые пользовались специализированным зарубежным ПО, коробочных решений будет недостаточно. Сейчас остро не хватает узкоспециализированных продуктов, которые создавались и модифицировались на западных платформах, к примеру систем производственного планирования (как часть ERP) или управления жизненным циклом продукции (PLM).

Вариантов у компаний всего три:

• попытаться подстроить процессы под готовые отечественные продукты;
• кастомизировать отечественные решения под свои задачи;
• разрабатывать нужное ПО на заказ.

Для предприятий со сложными производственными процессами и комплексной ИТ-архитектурой подойдет комбинация этих вариантов.

При любом сценарии первое, с чего стоит начать, — продумать целевой ИТ-ландшафт и план перехода от модели «как есть» (as is) к модели «как должно быть» (to be). Очевидно, что одномоментно реализовать все изменения в ИТ невозможно не только технически, но и организационно. 

Помимо этого, стоит обратить пристальное внимание на готовность внутреннего персонала к параллельным проектам — есть ли необходимое число людей нужной квалификации и возможности тратить время на изменения. Наконец, надо согласовать критерии принятия решения при приоритизации самих проектов. Очевидно, что в условиях ограниченности ресурсов заинтересованным лицам внутри компании придется договариваться между собой, а это отнимает ценное время, требуемое для самих изменений и технических решений.

Нужно проанализировать, где временно и безопасно можно перейти на «бумажно-ручной» формат и таким образом расставить приоритеты по ИТ-проектам. Например, если в компании небольшой поток договоров, то можно отложить замену СЭД и перейти на бумажный документооборот. Или взять дополнительно несколько человек на склад, чтобы сохранить скорость работы при отсутствии WMS-решения. Так вы выиграете время и сможете вернуться к замене ПО на этом участке позже.

Однако этот вариант подходит не всем: если речь идет о большой компании и сложных процессах, работать в таком режиме не получится. Если же ждать нельзя и нужно менять «все и сразу», то вот несколько советов, которые помогут избежать критических ошибок при комплексном обновлении ИТ-ландшафта.

Видя необходимость импортозамещения сразу по нескольким направлениям, компании обращаются к подрядчикам и пытаются в сжатые сроки запустить независимые друг от друга проекты. В этом случае слишком высоки риски: никто не видит общей картины — какой должна быть целевая архитектура, все ли решения смогут в нее встроиться, и как они будут работать в комплексе. При большом количестве одновременных проектов компании все равно придется выделять внешнюю роль «генерального подрядчика» или же брать ее на себя.

При этом найти одного ИТ-партнера на все проекты не так просто: на российском рынке есть всего несколько ИТ-компаний, которые в состоянии одновременно работать над проектами в разных функциональных областях. Это связано с тем, что исторически ИТ-рынок формировался либо вокруг продукта (SAP, Microsoft, 1С), либо вокруг одной бизнес-отрасли, например автоматизации склада.

Независимо от того, какой объем работ вы отдадите подрядчику, вам понадобятся люди в штате, ответственные за модернизацию ИТ.

Выстроить планомерную работу с внешними компаниями помогут ИТ-архитектор и руководитель проектного офиса. Важно, чтобы у этих сотрудников были опыт проектирования сложных систем, способность оценить необходимые характеристики ПО и «приземлить» их на конкретные решения, исходя из бизнес-задач компании, а также опыт координации внешних и внутренних ИТ-команд.

• ИТ-архитектор сможет проработать целевую комплексную архитектуру и нивелировать возможные риски при одновременной работе сразу с несколькими проектами.
• Руководитель проектного офиса будет контролировать своевременный обмен информацией между командами, сроки и бюджет проектов.

Некоторым компаниям придется действовать в режиме скорой помощи: заменить максимум ИТ-систем за два-три месяца и запустить их с минимальной функциональностью. В этом случае необходимо оставить временной задел и заложить дополнительные затраты на последующую доработку каждого элемента. К примеру, если вы запустили систему без глубокой проработки пользовательского интерфейса или с временными схемами интеграции, не забудьте собрать все «долги» в отдельный проект и обязательно закройте их, как только это станет возможным. Кладбище неудачных ИТ-проектов часто складывается из временных решений, которые становятся постоянной головной болью пользователей.

Внедряйте только те сервисы и системы, которые можно оперативно менять.

• С одной стороны, российский рынок нишевых решений растет, появляется много «импортозамещающих» продуктов.
• С другой — такие решения часто не подразумевают доступа к исходным кодам. При внедрении узкоспециализированного ИТ-продукта нужно продумать, как в дальнейшем не зависеть от разработчика — иметь возможность вносить изменения в систему или передавать право доступа к ней партнерам для поддержки и т.д. В противном случае внедрить дополнительную функциональность или самостоятельно масштабировать решение будет проблематично.

Идеально, если замена ПО проходит максимально незаметно как для клиентов, так и для внутренних пользователей. Начните модернизацию с критически важных для бизнеса платформ, при этом заложите больше времени на опытно-промышленную эксплуатацию, чтобы выявить ошибки в процессе тестирования. Во время опытнопромышленной эксплуатации обеспечьте клиентам, партнерам и персоналу максимальную поддержку, выделите отдельную команду технического сопровождения, которая оперативно исправит недочеты, не отвлекаясь на другие задачи. Для этого нужно явно разделить ресурсы, которые вы выделяете на развитие и на проекты от команд технической поддержки.

Если на рынке нет полноценного аналога для замены зарубежного решения, можно заказать разработку собственного. Принимайте во внимание, что большинство компаний-разработчиков работают по детальным спецификациям.

• Чтобы минимизировать риски, сформулируйте подробные функциональные требования к целевой системе, составьте сценарий использования системы (use case) — это позволит избежать разрыва в ожиданиях при заказной разработке.
• Продумайте архитектурный стек так, чтобы внутри компании были требуемые ресурсы для будущей поддержки решения.
• И, конечно, постарайтесь разбить проект на этапы, чтобы быстро получить первый промежуточный результат.

Наличие минимально жизнеспособного продукта (MVP, minimum valuable product) и ежемесячные спринты существенно сократят риски получить неприятный сюрприз в конце проекта.

Итак, если вам необходимо в короткие сроки реализовать несколько крупных ИТ-проектов на базе отечественного ПО:

1. Четко распределите роли между своей командой и подрядчиками и определите ответственных внутри компании.
2. Выбирая нишевые решения, продумайте, как быть максимально независимыми от вендора (даже российского) в дальнейшем.
3. Предусмотрите бюджет на доведение временных решений до ума — нет ничего более постоянного, чем временное.
4. Если вы создаете свой продукт с нуля, обязательно делайте короткие итерации и сверяйтесь с целями по итогам каждого спринта.