Пресейл в мобильном телекоме

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

Компании третьего типа — это, как правило, самые молодые и амбициозные, четко сфокусированные на том, что делают. Они даже не пытаются охватить всё, инфраструктурные вещи для них — 3rd party.

Для компаний третьего типа самая большая трудность — показаться у операторов. Дело в том, что порог входа в отрасли очень высокий: чтобы создать работающее решение, которое способно делать что-либо как минимум не хуже, чем уже существующие, необходимо потратить миллионы долларов на R&D. Далее начинается борьба за референсы. Мало кто из операторов готов внедрить у себя систему, которая еще не имеет других успешных коммерческих внедрений. 

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

О конкурсах

Конкурсы у нас идут годами. Среднее время проведения конкурса на более-менее сложную систему — около года. Некоторые конкурсы могут идти два года. Количество итераций (подач предложений) — в среднем от пяти до семи. При этом распределены они крайне неравномерно. Казалось бы, за год можно подготовить хорошее предложение. Но обычно процесс построен таким образом, что каждая подача ограничена временем подготовки предложения, и чаще всего это период от одной до двух недель. После подачи может пройти месяц или даже два, когда внутри компании-оператора идет работа с поданными предложениями и принимаются решения об изменении вводных или формата подачи. А дальше все происходит по новой. Для участников конкурса режим недельного цейтнота сменяется паузами длиной в месяцы. В периоды затишья внутри компании-оператора может вестись работа по другим конкурсам, так как, как правило, одни и те же люди ведут сразу несколько конкурсных активностей. Поставщики тоже не тратят время даром: параллельно могут идти другие конкурсы этого оператора или других.

О совокупной стоимости владения

Для того чтобы понимать, насколько сильным должно быть предложение, нужно рассмотреть такое понятие, как совокупная стоимость владения (Total Cost of Ownership, TCO), которой оперируют наши операторы при рассмотрении предложений о закупке. Модели построения TCO у нашей большой четверки сильно отличаются, методики расчета стоимости зависят от принятых в той или иной компании-операторе закупочных процедур и традиций. 

Рассмотрим несколько примеров.

Оператор 1. Сложная TCO. Пожалуй, самая сложная из всех существующих в РФ и СНГ. Ее заполнение иногда даже выглядит как издевательство над поставщиками, особенно если после заполнения оператор рассылает новую версию TCO-модели, которую нужно заполнить заново с чистого листа. И так несколько раз. Однако с точки зрения процедуры закупки и уровня проработки структуры и декомпозиции решения это самое совершенное, что существует у нас в стране. Можно предположить, что такой опыт был принят на вооружение под влиянием иностранного менеджмента, и тогда это тот самый случай, когда лучшие международные практики внедрены весьма успешно. В какой-то период TCO даже учитывала стоимость денег, но в последнее время те модели, что я встречал, этого не делают. Хотя это, безусловно, полезно и интересно на больших проектах. Самый главный плюс такого подхода — возможность проведения настоящих онлайн-торгов, ведь цифра в TCO отражает действительно реальную и полную стоимость без каких-либо дополнительных костов. Результат торгов и победитель определяются уже через несколько часов, а не в течение нескольких итераций длиной от недели до двух каждая, как в других примерах ниже. Из минусов: из-за высокой сложности TCO-модели в ней самой встречаются ошибки, опечатки, а также порой применяются различные подходы к формированию итоговой стоимости в различных разрезах. Что, например, приводит к разнице двух итоговых цифр, вычисляемых по разным методикам, которые в идеале должны быть эквивалентны. Когда получается разница в 5 тыс. на масштабе 100 млн, то ошибку в Excel-документе из 30 вкладок с 5000 строк на каждой вкладке можно искать очень и очень долго.

Оператор 2. TCO выглядит запутанной, но она довольно гибкая. Причем настолько, что порой отдел закупок оператора соглашается на разумные предложения внести в неё изменения. Подход к построению TCO не такой формальный, как в первом случае, да и сами торги происходят в довольно гибком режиме. Ценовые раунды могут длиться месяцами. Скорее всего, это обусловлено тем, что из-за нежесткой ценовой политики, проводимой отделом закупок в ручном режиме, с предложениями участников должны проводиться дополнительные манипуляции с целью выравнивания структуры поданных предложений, а также формирования итоговой стоимости (которая никогда не бывает известна участникам, но об этом ниже).

Оператор 3. Структура ТСО по композиции похожа на вариант первого оператора, но в значительно более упрощенной форме. TCO в целом более структурированная в сравнении с таковой у оператора № 2, что дает более ясное понимание структуры предложения для закупочной комиссии и в конечном счете позволяет проводить торги в режиме онлайн. Так как в TCO должны быть включены все элементы инфраструктуры, то нередки случаи, когда для конкурса, к примеру, на довольно простой Interconnect SBC требуется заложить всю инфраструктуру NFVI, включая платформу оркестрации (SDN опционально, по желанию).

Оператор 4. Лайт-вариант, похожий на предыдущий. ТСО, кажущаяся на первый взгляд простой, порождает неоднородность моделей среди разных участников, а свобода ее наполнения, как в случае оператора № 2, затрудняет сравнение решений и исключает возможность проведения онлайн-торгов. При этом в компании существует калькулятор виртуальных ресурсов, который теоретически позволяет быстро получить оценку стоимости ресурсов и добавить ее к предложению участника. На практике информация о стоимости инфраструктуры скрыта от участников, и манипуляции с конечной совокупной стоимостью предложения проводятся закупочной комиссией самостоятельно по схеме, непрозрачной для поставщиков.

Что мы имеем в итоге: у двух операторов из большой четверки возможно проведение аукциона в онлайн-режиме, и именно так практикуется закупка. У двух других торги фактически проводятся в режиме ручной подачи и ручного анализа предложений, что затягивает закупочную процедуру порой на несколько месяцев. Справедливости ради необходимо отметить, что победа в конкурсе вовсе не означает закупку в заявленном в прогнозе объеме, а иногда даже не гарантирует заключения контракта. Иногда ТСО — это всего лишь TCO, и оператор по итогам конкурса может предложить к закупке лишь 1/150 часть того, что было объявлено в конкурсе. К сожалению, такая ситуация не зависит от технологической продвинутости закупочной процедуры и встречается у всех операторов. 

Как обычно проходят конкурс и торги 

У нас среди операторов приняты две модели:

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

1.  В ходе технической квалификации решений оператор вычисляет рейтинги для каждого из поставщиков, отражающие степень соответствия решения требованиям. В результате те решения, что прошли квалификацию, могут иметь разброс рейтингов соответствия, скажем, от 70 до 98%. Далее при подаче предложений к ценовой составляющей применяется повышающий коэффициент, отражающий степень соответствия, для того чтобы сделать дороже менее технически совершенные решения. Таким образом, при одинаковой стоимости подачи предложений двух вариантов с разным рейтингом (у одного 70%, а у другого 90%) побеждает, конечно же, решение с бо́льшими функциональными возможностями. Альтернативному решению необходимо будет предоставить скидку минимум на 20%, чтобы таким образом компенсировать свой уровень технической оценки.

Цифры, приведенные здесь, весьма условны и показывают лишь верхнеуровневый подход. На самом деле все устроено гораздо сложнее. 

Как происходит техническая квалификация решений

Единого стандарта оценки решений не существует, каждый оператор проводит ее в соответствии с собственными представлениями о прекрасном. Здесь стоит отметить, что похожая картина наблюдается также и в других странах, например в государствах СНГ.

Обычно операторы формируют очень большие списки так называемых SoC — заявлений о соответствии (statement of compliance). Величина такого списка может варьироваться приблизительно от ста строк до нескольких тысяч. Одна строка — один вопрос по соответствию поддержки того или иного алгоритма работы, либо архитектуры, либо какой-нибудь фичи. Разумеется, ответы не должны быть голословными — их нужно подтверждать ссылками на документацию по продукту либо какими-то иными официальными источниками. Даже здесь, в технической части, некоторые из наших операторов научились применять штрафы. Схема работает следующим образом. Если вендор в ходе ответа на SoC подтвердил наличие какой-либо фичи, затем был признан победителем в конкурсе и с ним заключили контракт, но в ходе внедрения решения оказалось, что один из специфических сценариев для заказчика не может быть реализован в том виде, в котором заказчик хочет его получить, то оператор достает заполненный вендором SoC, поданный на конкурс, и обязательно найдет такой пункт требований. Если вендор ответил, что поддерживает данную фичу, а по факту выяснилось, что нет (либо трактовка допускала двоякое толкование), оператор выпишет такому вендору штраф, причем размер штрафа будет весьма существенным, измеряемым в единицах процентов (если не десятков процентов) от всей стоимости контракта. Крайне опасная и порочная практика, а еще и потенциально коррупционная.

У наших операторов в основном принято так: чем крупнее конкурс с точки зрения важности закупаемой системы и ее влияния на бизнес, тем, как правило, больше требований формируется в техническом SoC. К сожалению, требования эти обычно общего характера (на соответствие 3GPP TS) и имеют малое отношение к реальности. Действительно специфических требований для сети заказчика и требований, описывающих реальные юз-кейсы, очень мало. Но, видимо, если выпустить на серьезный конкурс SoC с 20 требованиями для юз-кейсов, то руководство этого не оценит. Поэтому требований должно быть 1000+, чтобы задание выглядело более весомым. В этом смысле главное отличие наших операторов от европейских в том, что вторые в основном фокусируются на юз-кейсах, требующих реализации, а не на прямом копировании требований 3GPP TS в свои формы SoC для заполнения.

Еще один интересный аспект, на который я бы хотел обратить внимание, — это возрастающая с каждым годом сложность сети операторов. С одной стороны, накапливается багаж старых систем, чаще всего собственной разработки, либо очень редких (заказной разработки), либо глубоко кастомизированных (особенно в BSS- и OSS-доменах). Сегодня широко распространена практика работы по принципу «кто внедряет, тот и подстраивается», то есть при внедрении какой-либо новой системы с нуля (такое еще встречается у некоторых операторов) или при замене старой требуется обеспечить режим внедрения и интеграции, позволяющий избежать каких-либо изменений в смежных системах. Разве что допускается изменение небольших настроек вроде IP-адресов для соединений. Получается, что с течением времени каждая следующая внедряемая система должна взять на себя ответственность за интеграцию со всеми ранее внедренными смежными системами, в направлении которых должна передаваться информация от внедряемой системы. Такого рода интерфейсы интеграции обычно не являются стандартными и используются для передачи информации о событиях (в том числе безопасности) мониторинга, включая мониторинг производительности, а также CDR различных видов с разнообразными полями, включая довольно специфичные для конкретного оператора и конкретного решения. Поэтому, когда я слышу фразу: «А как это работает у другого оператора?» или «Ну это же стандартная интеграция» либо «...типовая конфигурация», то она лишь вызывает улыбку. Не бывает в мире двух одинаковых операторов, не бывает в мире двух одинаковых инсталляций одного и того же продукта, все очень специфично.

Отдельного внимания заслуживают требования по безопасности. Некоторые операторы формируют большой набор SoC по различным видам на соответствие решения внутренним требованиям ИБ. Необходимо отметить, что глубина проработки требований очень серьезная, чувствуется, что это как правила пожарной безопасности и СНИПы — выработаны в прямом смысле кровью и потом. Вместе с тем количество вопросов по части ИБ порой сравнимо с количеством вопросов основного SoC в функциональной части, а с учетом их детализации ответить на них возможно лишь с привлечением экспертов R&D вендора. У многих вендоров такие вопросы вызывают удивление: «Мы же не поставляем систему, обеспечивающую ИБ. Почему к ней предъявляются такие серьезные требования? И почему это происходит на самой первоначальной стадии общения?» В ИБ-часть также могут вноситься требования нашего регулятора по соблюдению различных правил блокировки, хранения персональных данных, по соответствию различным нормам и правилам, о которых в другой части света даже и не слышали. В общем, такой подход также повышает сложность систем и в конечном счете затягивает процесс выбора решения, усложняет техническую оценку и повышает стоимость.

Инфраструктура

Операторы по-разному подходят к составу требуемых решений. В основном их можно разделить также на два вида:

1. Те, кто уже построил виртуальную инфраструктуру, рассматривают предложения в виде поставки только SW для развертывания в виртуальных средах VMWare либо OpenStack, а теперь еще и K8S, OpenShift.
2. Те, кто не имеет целостной виртуальной инфраструктуры, требуют поставки SW плюс HW плюс всех сопутствующих компонентов для VIM, VNFM плюс VNFO.

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

Второй вариант является наиболее комфортным для вендоров первого типа. Как правило, в их портфеле решений есть все необходимые компоненты для построения решения и инфраструктуры для него по схеме full turn key solution. Но порой даже у вендоров второго типа вариант № 2 вызывает трудности. Для компаний третьего типа данный вариант наиболее сложен и может являться даже заградительным. 

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

В технической плоскости для вендоров решений второго и третьего типа, которые по-настоящему hardware agnostic и умеют работать в различных средах, это по большому счету не является проблемой.

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

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

Состав решений и тенденции

С точки зрения структуры решений конкурсы можно условно разделить на простые и сложные. К простым относятся решения, которые выполняют одну задачу в единственной предметной области. Например: SBC, Load Balancer, DPI и т.п. — то есть все то, что можно изобразить на схеме одним функциональным элементом.

Сложные системы строятся из нескольких элементов как 3GPP, так и non-3GPP. Примеры: MVNO, Private LTE и т.п. Порой даже более мелкие части сети требуют синтетической структуры.

Тенденция, наблюдаемая сегодня, состоит в том, что простые структуры усложняются, а сложные становятся еще более сложными. Как это происходит?

По моим субъективным оценкам, только один оператор из четырех по-настоящему отделяет конкурс на функциональную часть от конкурса на инфраструктуру. Для остальных операторов, как правило, в конкурсах требуется закладывать помимо основного решения также и всю сопутствующую инфраструктуру. Вендоры первого типа с радостью предложат решение end-to-end, состоящее из серверов, коммутаторов и собственно решения под управлением своей версии OpenStack под единой системой управления (EMS). В противовес им вендоры третьего типа могут предложить лишь свое функциональное решение с системой управления EMS, сфокусированной только на собственном решении, а для всех остальных компонентов потребуется привлечение других производителей в количестве от двух до пяти, причем каждого со своей системой EMS. Так выглядит усложнение и укрупнение простых конкурсов.

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

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

Также стоит вспомнить о применении так называемых ваучеров и кросс-проектных скидок. У некоторых операторов применение вендором таких схем категорически запрещается, и об этом сразу заявляется в конкурсных документах. Для других операторов такая практика является нормальной и применимой. Для тех, кто не знает: ваучер — это такой вид бонуса определенного денежного эквивалента, который можно применить при покупке решения, тем самым получив дополнительную скидку. Ваучеры раздают вендоры, уже имеющие выполненные проекты по другим тематикам на сети оператора, с целью сделать свое предложение в текущем конкурсе более привлекательным. На первый взгляд, для оператора это выглядит привлекательно, но в действительности данная схема использует нерыночные механизмы конкуренции, а схема работы такого ваучера близка к бонусным схемам за покупки в ритейле, когда покупателю на виртуальный счет возвращается 5 или 10% от стоимости покупки в виде бонусов и ими можно оплатить часть следующей покупки. Нюансы всплывают во время оплаты: применять их можно не для всех товаров, платить можно не более определенного процента общей стоимости и т.д. и т.п. 

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

Как строится TCO: hidden cost vs онлайн-торги

Используя в данной статье уже сложившийся дихотомический подход, можно выделить два вида ТСО для варианта № 1 состава решения (построение на виртуальной среде оператора):

1. Поставщик указывает ресурсы в виде требований к VM CPU / RAM / HDD / NIC и т.д., оператор пересчитывает их в количество серверов определенной конфигурации, добавляет сетевую часть, получает стоимость у выбранных ранее поставщиков (а это как раз таки могут быть те же самые компании первого типа) и далее самостоятельно добавляет эту сумму к стоимости поданного поставщиком предложения — это максимально непрозрачная схема.
   
   
2. Поставщик указывает ресурсы, как и в предыдущем случае, но затем оператор согласовывает спецификации серверной и сетевой части, озвучивает стоимость и в явном виде указывает ее в TCO. Данная стоимость автоматически повышает стоимость решения с учетом инфраструктуры, но стоимость инфраструктуры становится известна поставщику-вендору, он может ее верифицировать и оценить общую стоимость его решения для оператора — это максимально прозрачная схема.

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

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

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

Железные риски

Для компаний третьего типа очень важно наличие железа, на котором они должны разворачивать свое решение. Минимальный джентльменский набор в самом простом случае включает в себя серверы плюс коммутаторы, а в более масштабных проектах — полноценную фабрику. Особенность нашего российского телекома в том, что когда компания признается победителем и заключает контракт, все инвестиции в строительство решения она осуществляет самостоятельно. То есть закупка необходимой инфраструктуры в виде тех же серверов, коммутаторов и т.д. ложится на плечи внедряющего. Примерный объем инвестиций в железо для среднего проекта может доходить до 1–2 млн долларов. Для крупного проекта цифры будут в 10 раз больше. Срок развертывания такого проекта в среднем около года. Деньги от заказчика-оператора поступают после успешной сдачи и запуска решения. И это оптимистичный сценарий, когда все идет по плану. 

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

• Для компаний первого типа: железо их собственное, оно вполне может быть переиспользовано на других проектах, поэтому риски минимальны.
• Для компаний второго типа: железо, как правило, 3rd party от других именитых производителей, специализирующихся на этой части. Но вернуть его просто так и получить деньги не всегда возможно. Скорее всего, это железо будет перепродаваться позже с большим уровнем дисконта, что для компании, безусловно, станет убыточным.

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

Поэтому, когда мы говорим о совокупной стоимости решения, компаниям необходимо включать сюда не только часть решения SW, но и инфраструктурную часть HW. И в этот момент возникает огромная разница между компаниями первого типа и компаниями второго и третьего типа. Первые могут предлагать гибкий дисконт на целое решение в составе HW+SW, их риски минимальны. Вторые могут предлагать хороший дисконт на свою часть решения SW, но часть решения HW для них является 3rd party. Кроме того, поскольку они перепродают его от своего лица, то в цепочке возникает небольшая наценка, что делает часть решения HW менее гибким с точки зрения цены. Для компаний третьего типа HW-часть является наибольшей проблемой. Повлиять на нее практически невозможно, ее стоимость дисконтируется меньше, чем для компаний второго типа, имеющих глобальные контракты с мировыми производителями железа. Поэтому для компаний третьего типа скидка на SW должна учитывать как минимум такой же уровень стоимости SW, как у конкурентов — компаний первого и второго типа, а также включать в себя еще и скидку на HW. То есть компании третьего типа должны предоставлять гораздо большую скидку на SW, чтобы компенсировать стоимость 3rd party HW-части. 

Перспективы строительства сетей 5G на отечественных разработках

С учетом описанной схемы закупки появление новых отечественных компаний, разрабатывающих решения для 5GC и 5GNR, автоматически относит такие компании к вендорам третьего типа. Причем с крайне низким рейтингом из-за отсутствия большого опыта коммерческих внедрений и меньшего уровня функционального покрытия в сравнении с другими участниками рынка (а разве у новичков бывает иначе?). Поэтому в сложившихся условиях любые отечественные решения для сетей 5G будут априори проигрывать решениям матерых иностранных участников конкурсов при существующих сегодня схемах закупки. Обозначенные государством цели по строительству сетей 5G преимущественно на отечественных решениях потребуют значительных изменений в каждой из компаний-операторов вплоть до схем прямых закупок у единственного поставщика без проведения конкурсов. Иначе в текущих реалиях такая задача просто нерешаема. Относиться к этой схеме можно по-разному, но если задача поставлена, то решение будет найдено. Следовательно, будущие закупки в сфере 5GNR и OpenRAN, скорее всего, будут подпадать под все большее регулирование вплоть до директивных закупок, а для традиционных мировых вендоров данные темы перестанут быть доступными.

Заключение

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