Как владельцам бизнесов балансировать в многополярном мире

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

Глобальные и локальные компромиссы для бизнеса и IT

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

Движущие силы глобальной стандартизации все еще будут продолжать держать вектор на сохранение единого подхода и включать в себя:

• Эффекты масштаба и экономическую эффективность. Бум цифровых «аборигенов» уже продемонстрировал, как предприятия, основанные на единой глобальной платформе, могут масштабироваться с минимальными предельными затратами. Несмотря на восходящий тренд деглобализации, IT-продукты все же будут стараться удерживаться на старых бизнес-экономических правилах.
• Упрощение. Неважно, в каком блоке ваш бизнес находится или взаимодействует в сетевом и прочих сценариях. Придерживаться стандартизации – значит помогать локальным организациям упростить или интегрировать процессы, продукты, связывающие внутренние операции в разных регионах.

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

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

К примеру, законы о конфиденциальности и безопасности данных, такие как Общий регламент ЕС по защите данных (GDPR) или закон Китая о безопасности данных, применяются ко всем отраслям и могут включать требования-ограничения, затрагивающие местную инфраструктуру, такую ​​как облачные провайдеры, механизмы управления потоками данных, изолированные средства контроля доступа и т.д.

• Ожидания и поведение клиентов. Для российских IT-провайдеров и владельцев решений потребуется адаптировать пользовательские интерфейсы, чтобы дать возможность выбора. К примеру, использование привычных местных платежных или коммуникационных решений (таких как AliPay или WeChat) или же предложить бесшовную интеграцию с местными экосистемами (такими как Grab в Сингапуре или Gojek в Индонезии), а также системами сторонних поставщиков услуг и другими поставщиками.
• Риск. Глобальные операционные модели в настоящее время будут еще более уязвимы не только с позиции крупномасштабных сбоев из-за единых точек отказа. Но и с позиции давления санкционной составляющей (вторичные санкции, финансовые ограничения/усиленный контроль) и регуляторов блоков. Для российского IT экспортного бизнеса уже «вчера» необходимо было принимать меры по расширению базы поставщиков из различных стран, не привязываясь к единой локации. Увеличивать число местных и региональных поставщиков, перепроектировать сетевое взаимодействие с ними из учета угроз вторичных санкций, а также увеличивать целевые и резервные запасы. Это поможет повысить устойчивость развития бизнеса и снизить риски.

Во времена геополитического «развода» и разделения систем вводить быстрые бизнес-изменения на локальном рынке могут в основном крупные IT-бизнесы с мощным GR как со стороны России, Китая, так и со стороны западного бизнеса. Российский экспортный IT здесь выглядит менее устойчивым и подвержен большим рискам. Стоит напомнить, что западный IT-бизнес будет более агрессивно вести себя не только напрямую, но и через «локальных друзей» и местное правительство даже в 100% дружественных для России странах.

• Различия в размере рынка и зрелости. Стоит напомнить, что глобальные системы и процессы могут быть не самым экономичным выбором для компаний, работающих на весьма несопоставимом наборе бизнес-атрибутов и ценовых моделях, присущих конкретному рынку. Меньшие по размеру и менее зрелые рынки могут лучше обслуживаться за счет местных альтернатив.

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

Как реорганизовать бизнес и IT-модель

Можно долго дискутировать о том, как далеко следует стандартизировать и насколько дифференцировать продукты, сервисы, решения компании, ведь в конечном итоге они могут легко затеряться в «процессных» сорняках или стать чрезмерно упрощенными и «несъедобными» на заявленном рынке.

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

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

Используйте локальную карту возможностей

Используйте карту возможностей того региона, в котором вы собираетесь зарабатывать для построения IT-архитектуры и операционной модели. К примеру, предлагаем интегрированную к текущему азиатскому локальному рынку e-gov, российскую цифровую платформу, построенную на гибкой архитектуре с заявкой на масштабирование в других странах и регионах. Платформа состоит из трех компонентов:

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

С помощью таких компонентов, например локальный IT-отдел или гибридный с российским продуктовым бэк-офисом может дать возможность локальным командам адаптировать свои технологические потребности и нивелировать отсутствие локального опыта и компетенций.

При этом стоит напомнить, что какими бы суперполезными не были эти возможности локализации, они не будут работать максимально эффективно, если местные команды не будут иметь достаточную автономию и компетенции.

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

Если хочется «откусить» у китайцев и у западных IT-вендоров ниши и рынки в ЮВА и прочих странах, то стоит уже заранее проработать и инвестироваться в создание самим или на локальной партнерской базы местных компетенций, предоставлять локальным командам определенные права, учить их быть ответственными за продуктовый функционал и принимать самостоятельные решения в соответствии с едиными инструкциями к проекту-продукту. Кроме того поддерживать их, предоставляя при этом необходимые возможности для расширения локального рынка в виде российских IT-специалистов и привлеченных специалистов из других стран через свои HR.

Базовые ключевые ошибки, которых стоит избегать

Если IT-компания решила выстраивать новую единую архитектуру и операционную модель для ЮВА рынков, ей необходимо изначально избегать общих проблем, которые просто не дадут реализовать экспортную стратегию по продвижению IT-продуктов и услуг. Ниже приведены некоторые важные элементы, о которых следует всегда помнить:

• Предоставьте местным командам четкие права принятия решений (учите, прививайте и интегрируйтесь с ними). Руководителям бизнес-подразделений, владельцам продукта или услуги, совету директоров необходимо обращаться к карте возможностей и «сверять часы» при принятии решений, предоставлять местным командам четкие и понятные полномочия, а также автономию для принятия решений. Наладьте двустороннюю ментальную связь между своей штаб-квартирой, странами и бизнес-подразделениями.

Помните, что, например, формальное во время ВКС соглашение с вами по принятию конкретного решения и кивание в одобрение головой не означает понимание единой задачи с вами. Банально это может оказаться только актом вежливости со стороны местного специалиста, а не принятия им ответственности. Увиливание от нее в принятии решения, особенно владельцем продукта на локальном рынке, это национальная черта многих стран в ЮВА и тем более в Африке.

• Подумайте о долгосрочной стратегии за пределами одного года, желательно пары тройки лет. Гибкость современных IT-архитектур, разумеется, позволяет компаниям вносить масштабные изменения в достаточно короткие сроки. Однако некоторые фундаментальные решения, особенно те, которые касаются моделей данных и организации доменов, должны оставаться стабильными в течение трех-пяти лет.
• Создайте карту возможностей, которая ломает исторические российские привычки и ограничения. Если новая карта возможностей для конкретной страны должна служить надежной основой для выявления критических компромиссов и формирования новой IT-модели, она не должна определяться вашими историческими решениями (российским опытом), существующими функциональными границами и ограничениями текущего релиза решения или используемых вами технологий.
• Сбалансируйте строгие стандарты с достаточной и необходимой гибкостью. Стандартизация — это не двоичная история про все или ничего; хитрость будет заключаться в том, чтобы принимать каждое решение на соответствующем уровне детализации и при этом в «чужой» стране, имеющей свою ментальность и местные привычки ведения бизнеса.

Читайте также: