Центры глобальных компетенций (GCCs) в Индии, которые ранее функционировали как подразделения транснациональных корпораций, занимающиеся всем спектром задач — от финансов до инженерии и поддержки клиентов — долгое время рассматривались преимущественно как центры затрат, а не как структуры, формирующие технологии. Однако эта концепция перестает быть актуальной.
Кьюин Джордж, руководитель в области ИИ и GCC, отметил на конференции DevSparks Chennai 2026, что GCCs в Индии трансформируются в узловые центры для разработки продуктов, платформ и инноваций, а не только для выполнения заказов. Его доклад, озаглавленный «От кода к бизнес-эффекту: Что на самом деле создают GCCs в Индии?», сосредоточился на роли разработчиков как движущей силы этих преобразований и на требованиях, предъявляемых к ним.
Джордж выделил три основных тенденции, наблюдаемые в GCCs. Во-первых, это автоматизация: по его оценкам, 50–60% GCCs внедряют автоматизацию для рутинных, высокообъемных операций, таких как обработка заявок в службах поддержки, которые раньше требовали постоянного участия человека. Во-вторых, это переход к полной ответственности. Вместо создания небольшой части глобального продукта, некоторые GCCs теперь разрабатывают целые системы от начала до конца, приводя в пример GCC, который полностью отвечает за разработку системы управления кредитами для банковского клиента. В-третьих, наблюдается ускоренный набор специалистов по инженерии ИИ, хотя Джордж признал, что для многих организаций остается неясным, какие именно продукты следует создавать с помощью этих новых команд.
Значительная часть этой активности мотивирована страхом упустить возможности (FOMO) — как со стороны транснациональных компаний, конкурирующих за создание GCCs в Индии, так и со стороны самих GCCs, стремящихся не отстать в сфере ИИ. Эта срочность привела к ощутимым результатам: Джордж указал на компании, использующие два типа сценариев применения ИИ — те, которые напрямую влияют на выручку и дают видимый возврат инвестиций, и те, которые направлены на повышение внутренней производительности.
Главное предостережение Джорджа касалось явления, которое он назвал «кладбищем пилотов» — ситуаций, когда победы на хакатонах и концепции, доказавшие работоспособность, отмечаются один раз, после чего больше не проверяются. Он подчеркнул, что крайне важно, чтобы сотрудники GCCs при переходе от идеи к готовому решению задумывались о долгосрочной устойчивости. По его мнению, это является самым большим пробелом.
Он утверждал, что идея, выглядящая убедительно в контролируемом пилотном режиме, все равно должна пройти проверку на реальной, текущей эксплуатации, а также на способность адаптироваться к меняющимся потребностям бизнеса и сохранять интерес пользователей после того, как новизна пройдет. Сильный пилот не гарантирует успеха в долгосрочной перспективе.
Джордж связал эту проблему с распространенной практикой в GCCs: команды сначала разрабатывают продукт, который, по их мнению, является правильным, а затем пытаются продать его бизнесу. Он считает, что этот подход обратный. Вместо этого, инженеры должны напрямую взаимодействовать с бизнес- и клиентскими командами, самостоятельно выявляя проблемы, вместо того чтобы ждать формального технического задания.
Изменение в том, что создают GCCs, влияет на требования к разработчикам. Джордж отметил, что эти разработчики не имеют единой отправной точки и делятся на три поколения. Первое поколение обучено на устаревших системах, таких как мейнфреймы; второе — прошло обучение на Java и аналогичных языках; а третье — более новое поколение, которое осваивает кодирование непосредственно с помощью инструментов ИИ. Именно это третье поколение вызывает у него беспокойство, поскольку, по его словам, эти люди могут полностью утратить логическое и системное мышление.
Он возразил, что тем, что передается от одного технологического сдвига к другому, является не владение каким-либо конкретным инструментом, а фундаментальная способность решать задачи. Поэтому, по мнению Джорджа, просто умение правильно ставить запросы (промпты) системе ИИ недостаточно. Он проиллюстрировал это примером собеседования на должность архитектора ИИ: после уверенного выполнения сложного промпта кандидат не смог объяснить, что происходит «за кулисами» системы. Для Джорджа разрыв между управлением инструментом и пониманием его принципов отличает настоящего инженера ИИ от разработчика, который просто научился хорошо пользоваться ИИ. Знание кодирования или умение создавать приложение с помощью ИИ не равносильно тому, чтобы быть инженером ИИ.
В отношении конкретных навыков Джордж определил пять областей, которые, по его прогнозам, будут наиболее важны. Первая — сама инженерия ИИ, которая требует совместного знания продуктовых, процессных, бизнес- и технических аспектов, а не только технических навыков. Вторая — инженерия конфигурации ИИ, заключающаяся в адаптации больших языковых моделей под специфические нужды организации. Третья — инфраструктура ИИ, то есть системы, на которых работают эти модели. Помимо этого, он добавил, что управление, риски и соответствие требованиям (governance, risk, and compliance), а также кибербезопасность быстро набирают обороты по мере расширения использования ИИ в GCCs и будут занимать растущую долю в найме.
В заключение Джордж предупредил о найме начального уровня. Поскольку рутинные задачи становятся все более автоматизированными, он подсчитал, что лишь около 30% выпускников инженерных специальностей, вероятно, получат сильные позиции в GCCs в ближайшее время, а остальным потребуется значительно более тщательная подготовка, которая должна начаться задолго до первой работы, чтобы они могли конкурировать.
