Последние несколько лет (и особенно в этом году) мы много занимались переездом крупных ритейлеров на открытые сервисные IT-решения, на которых компании могут строить собственную независимую ни от кого e-commerce платформу. В этой статье мы систематизировали наш опыт и описали возможные стратегии ухода с коробочных решений.
{«id»:568299,»type»:»num»,»link»:»https://vc.ru/trade/568299-pereezd-na-servisnye-it-resheniya-v-elektronnoy-kommercii»,»gtm»:»»,»prevCount»:null,»count»:0,»isAuthorized»:false}
{«id»:568299,»type»:1,»typeStr»:»content»,»showTitle»:false,»initialState»:{«isActive»:false},»gtm»:»»}
{«id»:568299,»gtm»:null}
Как комплексные enterprise-решения появились в e-commerce
В девяностые и двухтысячные российский рынок корпоративных IT-решении был без боя занят западными вендорами. Из отечественных продуктов существенную долю удалось занять только 1С и Касперскому.
Электронная коммерция — молодая отрасль, но в ней происходили те же самые процессы. Большинство компании рано или поздно приходили к решению внедрить продукты enterprise-вендоров по различным причинам:
- Маркетинг и репутация западных вендоров;
- Использование внедрения, как способа подняться по карьерной лестнице, или с целью привлечения внимания акционеров;
- Давление штаб-квартир зарубежных ритейлеров;
- IPO и привлечение инвестиций: внедренное комплексное enterprise-решение — положительныи фактор при выходе на биржу.
Одна из главных причин господства комплексных enterprise-продуктов — высокий уровень требований к внедрению.
Компании, выбирая западные решения, ожидали получить инъекцию практик высокого уровня. Бизнес в нашей стране молодой, поэтому такои способ компенсировать десятки лет развития был весьма популярен.
Особенности продуктов enterprise-вендоров в e-commerce
В открытых источниках нет развернутых отзывов о внедрении в екоме комплексных enterprise-решении. Можно найти либо официальные пресс-релизы, либо комплиментарные статьи от pr-подразделений ритейлеров.
О реальных результатах внедрений можно судить только по той информации, которую компании дают на тендерах по замещению комплексных enterprise-платформ.
Многие компании, внедрившие такие платформы, думают о замене. Чаще всего это вызвано слишком высокими OpEx и time-to-value.
Развивать комплексные enteprise-платформы дорого, при этом даже небольшие изменения делаются долго по ряду причин:
- Монолитная архитектура;
- Сложность кастомизации под нестандартные бизнес-процессы;
- Технологический стэк, под которыи сложно и дорого искать специалистов.
В электроннои коммерции высокая скорость изменений. Бизнесу необходимо уметь быстро внедрять новые решения, а исходный потенциал любой платформы не так важен: большая часть функциональности все равно разрабатывается с нуля под конкретный бизнес.
Критерии решений с пониженным риском
После введения санкций, большинство западных вендоров покинули российский рынок. Ритейлеры перестали рассматривать их решения в качестве целевых. Те, кто уже внедрил западные entreprise-платформы, разрабатывают стратегии перехода на независимые решения. Такие решения должны обладать следующими своиствами:
- Распределение бизнес-функций по разным приложениям. Каждое можно развивать независимо от других, например, за счет сервисной архитектуры.
- Разные приложения могут поддерживаться разными командами. Большое количество подходящих специалистов и компаний на рынке.
- Отсутствие лицензионных рисков. Например, Open Source или On-premise с разовой оплатой.
Стратегии переезда с платформ ушедших вендоров
Переезд — замещение функциональности одних решении функциями других. Определяясь со стратегией, компании отвечают на несколько вопросов:
- Новое решение — полный аналог, или функциональность замещаемой платформы размазывается по нескольким системам?
- Функции в новых решениях воссоздаются as is или реализуются по-новому?
- Переезд происходит одномоментно или в несколько этапов?
- Готова ли компания жертвовать бизнес-функциями во время переезда?
В зависимости от ответов, компания может выбрать ту или иную стратегию переезда. Все они сводятся к двум вариантам: постепенныи переезд или единовременныи переезд.
Постепенныи переезд
Стратегия постепенного переезда (Ice cream scoop strategy) предлагает выделять один или несколько бизнес-доменов, которые будут вырезаны из текущего решения и реализованы на вновь создаваемых сервисах. Эта стратегия предполагает, что старая платформа работает параллельно с новой.
Резервирование критических процессов
Перенос происходит поэтапно, начиная с наиболее критической функциональности, например, сервисов оплаты. После того, как основные риски купированы, можно сменить стратегию.
Поэтапный перенос, начиная с наиболее критической функциональности
Сценарий актуален, если существует риск внезапной остановки бизнеса из-за IT. Например, ожидается повышенная нагрузка перед новогодними праздниками, которую гарантировано не выдержит платформа. Другая распространненная причина — отключение сервисов вендором.
Частичный перенос фронта
Полныи перенос фронта — это трудоемкая задача, требующая много времени. Как правило, гораздо больше допустимого срока избавления от рисков или заморозки развития.
Задачу по переносу фронта на сайте или в мобильном приложении можно разбить на этапы и замещать по кусочкам. Например, сначала процесс оформления заказа, затем каталог, а потом главная страница.
[{«title»:»<p><span>u0427u0430u0441u0442u0438u0447u043du044bu0438 u043fu0435u0440u0435u043du043eu0441 u0444u0440u043eu043du0442u0430 u0441 APIu0437u0430u0446u0438u0435u0438 u0431u044du043au0430 u0431u0435u0437 u043fu0435u0440u0435u043du043eu0441u0430 u0432 u0441u0435u0440u0432u0438u0441u044b</span></p>»,»image»:{«type»:»image»,»data»:{«uuid»:»0c350c92-ec36-572a-8d85-5e83c37f7821″,»width»:1256,»height»:710,»size»:56044,»type»:»jpg»,»color»:»fbebdc»,»hash»:»»,»external_service»:[]}}},{«title»:»<span>u0427u0430u0441u0442u0438u0447u043du044bu0438 u043fu0435u0440u0435u043du043eu0441 u0444u0440u043eu043du0442u0430 u0441 u043fu0435u0440u0435u043du043eu0441u043eu043c u0432 u0441u0435u0440u0432u0438u0441u044b</span>»,»image»:{«type»:»image»,»data»:{«uuid»:»35c60c12-9b2a-5b4e-91ea-bdb761ec4a69″,»width»:1256,»height»:710,»size»:62401,»type»:»jpg»,»color»:»fbebdc»,»hash»:»»,»external_service»:[]}}}]
Полный перенос фронта
В электронной коммерции сайт и мобильное приложение — подверженные наиболее частым изменениям компоненты платформы. Наибольшая пользовательская нагрузка также падает на сервисы, связанные с фронтом. Поэтому перенос сайта и мобильного приложения — часто встречающаяся задача. В этой стратегии рядом с уже работающим фронтом создается новый.
[{«title»:»<p><span>u041fu043eu043bu043du044bu0438 u043fu0435u0440u0435u043du043eu0441 u0444u0440u043eu043du0442u0430 u0442u043eu043bu044cu043au043e u0441 APIu0437u0430u0446u0438u0435u0438 u0431u044du043au0430, u0431u0435u0437 u043fu0435u0440u0435u043du043eu0441u0430 u0432 u0441u0435u0440u0432u0438u0441u044b</span></p>»,»image»:{«type»:»image»,»data»:{«uuid»:»26d88ff2-2b0f-5220-9668-8d457a52dd1f»,»width»:956,»height»:908,»size»:43509,»type»:»jpg»,»color»:»fbebdc»,»hash»:»»,»external_service»:[]}}},{«title»:»<span>u041fu043eu043bu043du044bu0438 u043fu0435u0440u0435u043du043eu0441 u0444u0440u043eu043du0442u0430 u0441 u043fu0435u0440u0435u043du043eu0441u043eu043c u0432 u0441u0435u0440u0432u0438u0441u044b</span>»,»image»:{«type»:»image»,»data»:{«uuid»:»2934c54a-53ea-5a88-be9c-e60b54cec889″,»width»:956,»height»:908,»size»:23591,»type»:»jpg»,»color»:»fbebdc»,»hash»:»»,»external_service»:[]}}}]
Технические особенности постепенного переезда
Частичный переезд фронта
Пользователь, перемещаясь по сайту, не должен замечать, что перед ним не единый фронт, а разные приложения. Для этого нужно настраивать маршрутизацию между разными частями фронта, а это нетривиальная задача.
Поэтапный перенос элементов витрины
Нередко переезд фронта совмещен с редизайном, во время которого меняются сквозные элементы: хедер, футер, формы и т. д. Можно ничего с этим не делать, но тогда пользователь будет работать с витриной, на которой стандартные элементы выглядят по-разному. Чтобы избежать этого, придется включить в план приведение всех частей витрины к единому виду.
Если у компании нет возможности как-либо дорабатывать старое решение, и в нем не реализовано API достаточно высокого уровня, от стратегии постепенного переезда придется отказаться.
API-изация старого решения
При постепенном переносе функциональности нужно решить вопрос, как старое решение будет взаимодеиствовать с новым. Старое решение не обязательно имеет хорошее API, а значит нужно заложить трудозатраты на его доработкуили разработку с нуля.
Единовременный переезд
В некоторых ситуациях постепенный переезд невозможен или затруднен. Например, текущее монолитное решение нужно API-изировать, чтобы появилась возможность строить рядом заменяющие его функциональность сервисы. Такая доработка старого решения может быть сравнима по трудоемкости с единовременным переездом на новую платформу.
Если развитие старого решения не заморожено, то с единовременным переездом могут возникнуть сложности. Переезд будет все время откладываться, так как новое решение будет постоянно отставать от старого.
С деградацией функциональности
Есть две основных причины, когда бизнес жертвует частью функциональности во время переезда:
- Есть необходимость переехать как можно быстрее;
- Часть функций старой платформы больше не нужны.
Единовременный переезд с деградацией функциональности
Самое сложное в этой стратегии — сформулировать и защитить то, в каком виде будет запущено новое решение. С момента фиксации требований конечного продукта разные бизнес-подразделения будут стараться протолкнуть нужные им функции, не вошедшие в финальный скоуп.
С полным сохранением функциональности
Эта наиболее трудозатратная стратегия. К ней прибегают, когда бизнес готов на большие инвестиции и значительные сроки. Ожидаемый результат — технологическое обновление и снижение time-to-value.
Единовременный переезд с полным сохранением функциональности
Последовательность деиствий при переезде
- Определить список процессов (любым удобным способом: story, feature и т. д.) , которые затронет переезд.
- Определить, как процессы распределяются между внедряемыми сервисами и старым решением. Решить, в каких сервисах будут реализованы те или иные stories/features.
- Описать потоки данных между старым решением и новыми сервисами. Выставить методы для команды, дорабатывающеи старое решение.
- Разработать и запустить.
Материал основан на большом опыте разрезания монолитов и переезда с enterprise-решений на сервисную платформу электронной коммерции Ensi. tech.
