От вендорских «коробок» к цифровому партнерству. Почему и как эволюционирует digital-рынок Казахстана

За последние годы многие крупные компании в Казахстане увеличили собственные ИТ-подразделения с нескольких сотрудников до сотен разработчиков. Чем объяснить этот стремительный рост? Почему бизнесы решили сократить или даже прекратить работу с внешними вендорами – в том числе международными брендами – в пользу инхаус-команд. И самое главное – что дальше? Смогут ли банки, телеком-операторы, крупные девелоперы, ритейлеры, e-commerce площадки закрыть все свои потребности в разработке? Особенно с учетом растущей конкуренции за ИТ-кадры на рынке. Когда перекупаются не только отдельные специалисты, но и целые команды… Будет ли потребность у крупного бизнеса в ИТ-ауторсинге? И как будет меняться сам аутсорсинг?

Своим видением – ретроспективой за последние 5 лет, анализом того, что происходит прямо сейчас, и прогнозом развития рынка – делится Агиис Конкабаева, соучредитель и СЕО digital-компании red_mad_robot central asia.

• Рынок вчера от вендорского ПО – к инхаус-решениям
• Рынок сегодня: инхаус + аутстаф/аутсорс
• Рынок завтра: от «инхаус + аутсорс» к цифровому партнерству

Рынок вчера: от вендорского ПО – к инхаус-решениям

В марте 2022 года, когда я еще руководила digital-стратегией блока «Малый бизнес» в «Альфа-Банк Казахстан», под моим управлением было около 160 инхаус-разработчиков. Они были распределены на 15 agile-команд. Примерно такое же количество штатных разработчиков было и в розничном блоке банка. Также внутри «Альфы» работали ИТ-специалисты в инфраструктурном подразделении и в техподдержке блока информационных технологий. То есть на момент, когда банк из-за санкций вынужден был завершить самостоятельную работу на казахстанском рынке, в нем были сотни своих айтишников.

А начинали мы в 2017 году в блоке «Малый бизнес» с совсем небольшой командой разработчиков – до десяти человек. Серьезный рост инхаус-разработки произошел в результате смены бизнес-парадигмы.

В банке до середины 2017 года не было в целом продуктового подхода в ИТ. Айтишники работали в ИТ-департаменте. Их ключевой задачей была поддержка коробочного ПО, которое предоставляли вендоры. Собственных разработок практически не было. По сути, ИТ-департамент представлял собой внутреннюю сервисную службу. Эта служба получала задачи от разных бизнес-подразделений. Отрабатывала их, исходя из приоритетов по срочности/важности и наличия человеко-часов.

Когда бизнес-парадигма стала меняться, стало ясно: айтишников лучше внедрять в продуктовые команды. Чтобы они напрямую взаимодействовали с бизнесом, руководителями продуктов, маркетологами, аналитиками, и так же думали о клиенте. Смотрели на разработку глазами клиента. А еще стало важным быстрее выводить продукты на рынок, повысить time to market.

Понадобилось определенное время, чтобы поменять мышление. Сформировать в банке agile-культуру, внедрить scrum, практику спринтов. Также стало понятно, что бизнесу с айтишниками нужно серьезно работать. Растить их, развивать и удерживать внутри компании.

В офисе red_mad_robot central asia

Можно ли было продолжать работать в парадигме клиентоцентричности только с вендорским ПО? По моему опыту в Альфа-Банке, ответ скорее отрицательный.

Когда мы исследовали CJM и прописывали бизнес-требования вендору, что должно измениться в продукте для клиента – вендор не всегда мог сделать именно то, что нужно. А в случаях, когда мог, возникали вопросы по срокам и бюджетам. 

Кроме того, в работе с подрядчиками нередко появлялись какие-то загвоздки, связанные с лицензиями на ПО, передачей исходного кода. Приведу пример.

Тренд на развитие инхаус-разработки в последние несколько лет был характерен не только для банков в Казахстане. Но и для телекома, крупного ритейла, е-commerce и для компаний из других секторов, у которых сотни тысяч, миллионы клиентов.

 В то же время, подходы в ИТ-аутсорсинге также начали меняться.

Рынок сегодня: инхаус + аутстаф/аутсорс

Сейчас наблюдая за банками и крупными бизнесами в Казахстане из других индустрий, я вижу, как рынок разделился. Часть компаний продолжают растить свои инхаус-команды. Другая часть остановила бурный рост штата разработчиков и больше смотрит в сторону внешних подрядчиков и партнеров.

При всех своих плюсах (контроль над продуктами и глубокое погружение в них) cтавка только на инхаус-разработку имеет и уязвимые места.

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

Чтобы удерживать разработчиков не только зарплатами, но и перспективами профессионального развития, нужно выстраивать целую инфраструктуру внутри компании, которая это развитие будет поддерживать и сопровождать. Речь про менторство, матрицы компетенций, индивидуальные планы развития и т.д. В международной группе red_mad_robot мы занимаемся этим системно уже много лет, как результат, средний цикл жизни разработчика в компании – больше 3 лет. Это при том, что зарплаты сотрудников достаточно конкурентные, но не самые высокие на рынке.

В банках же, в условиях бурного роста и изменений, часто некому и некогда системно заниматься развитием ИТ-сотрудников. Поэтому даже те банки в Казахстане, которые делают ставку на инхаус-разработку, все равно вынуждены 20-30% разработчиков добирать за счет внешних ресурсов. Речь идет о сотрудничестве с аутстаф-компаниями, которые предоставляют своих сотрудников заказчику в пользование. 

Другая часть банков – не ставит себе цель по максимуму закрывать все задачи инхаус-ресурсами. Ищет на рынке надежных, клиентоориентированных аутсорс-партнеров (здесь уточню: практически ни одна крупная корпорация в мире не закрывает свои потребности в разработке на 100% внутренними ресурсами. Даже Google c его огромным штатом ИТ-талантов пользуется услугами внешних партнеров).

В чем разница между аутстаффингом (аутстафом) и аутсорсингом (аутсорсом)? Поскольку эти два понятия на рынке иногда путают – кратко поясню.

Аутстаф – это когда компания подрядчик предоставляет заказчику людей, а заказчик сам с этим ресурсом работает. Ты их внедряешь в свою команду, свою культуру. При этом, исходя из своего опыта и наблюдений, думаю, не ошибусь, если скажу: 80-90% ребят в аутстафе не очень заинтересованы в конечном результате своей работы. Для них главное – получить зарплату за отработанное на проекте заказчика время. Если же говорить про ауторс, то здесь у компании-подрядчика есть конкретные обязательства по конечному результату – продукту, срокам, количеству релизов в спринте и др.

Выгодно ли компаниям обращаться к подрядчикам-аутсорсерам? Если сравнивать стоимость человеко-часа инхаус-разработчика со стоимостью аутсорс-разработчика, то у последнего она, как правило, выше. Но когда компания-заказчик считает не только чистые затраты на ФОТ штатных айтишников, но и сопутствующие накладные расходы (аренда офиса, закупка компьютерной техники, мебели, работа обслуживающих подразделений: бухгалтерии, юристов, HR-ов и т.д.), то реальная стоимость человеко-часа оказывается весьма сопоставимой.

Во взаимодействии с хорошей аутсорс-командой есть еще один плюс – возможность спрашивать за сроки проекта. Понятно, что у инхаус-команд тоже есть дедлайны по разработке. Но на практике они могут плавно переноситься. Потому что есть какие-то «внутренние причины», «взаимосвязанные вещи». И если свои разработчики что-то не успели выкатить на рынок, ты же не уволишь всю команду. Скорее сделаешь замечание и продолжишь работать с этими людьми. А когда у тебя ауторс-команда срывает сроки, то здесь уже могут быть конкретные претензии. Либо даже смена исполнителя.

Таким образом, у модели «инхаус + качественный аутсорс» на сегодня есть серьезные плюсы. Но эволюция рынка на этой формуле не заканчивается. Сейчас начинается новый этап в его развитии.

Рынок завтра: от «инхаус + аутсорс» к цифровому партнерству

Что я подразумеваю под «цифровым партнерством»? Это некий более продвинутый уровень по сравнению с привычным аутосорсингом. Когда компания-партнер не просто разрабатывает продукт. А предлагает заказчику конкретные идеи, исследует рынок, совместно с заказчиком тестирует гипотезы, помогает сделать бизнес-стратегию для новых продуктов и отвечает, в том числе, за успех продукта на рынке, ключевые бизнес-метрики.

То есть речь идет об ответственности не только за результаты разработки, но и за бизнес-результаты в целом.

Проиллюстрирую, как работает эта модель на примере кейса red_mad_robot central asia c Jusan Bank. Кейс еще в развитии и подробнее про него можно будет рассказать позже. Сейчас обозначу только ключевые моменты.

Команда Jusan задумалась о разработке собственного нефинансового сервиса для бизнес-клиентов – онлайн-бухгалтерии.

У команды red_mad_robot уже был опыт разработки и реализации такого продукта. Мы актуализировали наши исследования. Показали коллегам из Jusan, чего сегодня ждет рынок от онлайн-бухгалтерии и что можно сделать. Поскольку мы понимали, как именно это сделать, с какими сервисами нужно интегрироваться, то от идеи до первого релиза у нас прошло всего 2,5 месяца. В конце декабря 2022 прошло тестирование – сервис уже позволяет сформировать налоговую отчетность 910 внутри приложения банка и выгрузить ее в один клик – на выделенной группе малого и среднего бизнеса. А в январе 2023 сервис стал доступным для всех МСБ клиентов Jusan.

Cейчас команда «роботов» совместно с командой Jusan отвечает за то, чтобы новый сервис имел успех в реализации, в продажах. Наш project manager на проекте временно принял на себя роль product owner (поскольку сервис для банка новый и инхаус-команда, которая будет его развивать, сейчас формируется). Cегодня он внутри команды Jusan помогает реализовать бизнес-стратегию по новому продукту, правильно скоммуницировать его на рынок, отслеживает ключевые метрики.

При этом у нас есть четкий план передачи созданного совместно продукта в инхаус-команду Jusan. Ориентировочно за полгода мы завершим второй и третий этап в развитии онлайн-бухгалтерии и после этого передадим продукт заказчику. С исходным кодом, с доступом к репозиторию – чего не делали вендоры в отношениях с банками несколько лет назад. Также наша задача –  выделить новые роли в команде Jusan и помочь обучить людей, которые будут отвечать за поддержку и дальнейшее развитие нового продукта.

В этом смысле цифровые партнеры чем-то похожи на серийных ИТ-предпринимателей.

И модель отношений с заказчиком в новой парадигме становится более предпринимательской. Cейчас на рынке Казахстана финансовые отношения между компанией и digital-партнером строятся, в основном, по time&material (оплата за время, потраченное на выполнение задач проекта). В Казахстане у нас пока еще не было кейсов по модели success fee (когда вознаграждение идет не за человеко-часы, а от достигнутого бизнес-результата) или revenue sharing (когда стороны распределяют между собой доходы от совместно разработанного продукта или сервиса). Но в международной практике группы red_mad_robot такие проекты были. И я вижу, что наиболее продвинутые компании-заказчики на рынке Казахстана проявляют интерес к этим предпринимательским моделям. К совместному разделению достигнутого результата, вместо привычного «фикса». Думаю, в ближайшие годы интересные кейсы появятся и в Казахстане.

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