Почему буксует трансформация процессов эксплуатации российских телеком-сетей к data-driven network operations

Введение о причинах этой статьи

Хорошо известно, что сегодня у всех без исключения российских телеком-провайдеров в штате находится солидный отдел, или даже целый департамент со многими отделами и командами, посвященный исключительно «(Биг) Дате». В пресс-релизах наши операторы соревнуются за звание самой дата-дривен компании — читаешь и радуешься, как все хорошо у людей. Сегодня, например, я прочел, что C[X]O одного нашего уважаемого телеком-гиганта объявил об огромном экономическом эффекте от внедрения своей собственной дата-платформы в технологические процессы предприятия. И все бы хорошо, но параллельно окну браузера с этой новостью у меня открыто окно мессенджера, в котором я как раз обсуждаю с руководителем задач эксплуатации сетей одноименного оператора тему дата-дривен юзкейсов для эксплуатации его сетей. И о ужас, не верю своим глазам — далее цитирую, чтобы не добавлять своего предвзятого мнения (я только докинул наиболее эпических цитат из аналогичной переписки с коллегами того же уровня у всех наших операторов, которую я веду по профессиональным причинам уже квартал):

• нет, про дата-дривен OSS пока не слышал, нам бы с обычным сейчас разобраться…

• боюсь, что до таких высот наш мониторинг еще не дорос — мы как-то пока далеко от таких высоких материй…

• реальные задачи сейчас попрозаичнее — гармонизация бизнес процессов и систем oss/bss и сокращение издержек эксплуатации и развития.. как и 10 лет назад…

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

• в моем департаменте сейчас нет проектов, в которых предполагается использование дата аналитики, хотя в целом направление аналитики данных действительно перспективно и востребовано…

• ну, лет 5 назад по этой теме была большая активность — мы провели несколько встреч с нашей биг-датой: они нам рассказали, что они могут предсказывать, потом мы их спросили, ну и что нам делать с этими предсказаниями? А они нам говорят, вам лучше знать — предсказания наши, бизнес-кейс ваш! На том все и «рассосалось» — сейчас тема не развивается…

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

Сбывшиеся и обманутые надежды

После бурного старта развития прикладной практики Data Science серьезные ожидания возлагались в телекоме на интеграцию операционной деятельности и аналитических систем поддержки принятия оптимальных для бизнеса решений на базе оперативного статистического анализа больших объемов данных и машинного обучения с его предсказательными моделями раннего детектирования важных для бизнеса трендов (оттока, критического уровня неисправностей сети, прогноза перегрузки, замены детерминированной корреляции статистической – и еще нескольких десятков быстро выдуманных вендорами ПО аналитики многообещающих бизнес-кейсов).

Однако, при уверенной успешности внедрения аналитики для целей маркетинга, CRM и продуктового менеджмента, результаты интеграции с OSS приложениями для целей Эксплуатации оказались ниже и медленнее ожиданий.  И дело здесь не только в известном хайп-цикле новых технологий, сколько в отсутствии e2e подхода к проработке интеграционного решения, и в постоянной необходимости работы DA и DS в роли оператора внедренного решения, что обещает сохраниться пока не преуспеет следующий шаг Data Science, который обеспечит большую самостоятельность аналитической части решения от ее оператора в лице квалифицированного специалиста по данным.

Препятствия на пути

Подводя резюме встреченным препятствиям на пути к data-driven network operations, можно выделить следующие три группы:

1) Кадры и бюджет

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

Теперь посмотрим на ситуацию глазами Блока БигДаты: все считают что, в отличие от полезных дата-инженеров, штат аналитиков раздут и что они делают – никому не понятно.  Любая компания сокращения расходов в первую очередь грозит специалистам по дате, если убедительно с цифрами не подтверждать окупаемость аналитиков.  Поэтому в первую очередь аналитические работы ведутся по направлениям с ясным и быстрым RoI, чем,
как известно, не отличается OSS в телекоме. 

Кроме того, в отличие от интуитивно ясной индустриальной специфики аналитики маркетинга и продуктовой, сетевым технологиям еще «10 лет учиться надо».  В результате имеем само-воспроизводящуюся систему кадров Блока БигДаты с отличной подготовкой и опытом в DA/DS/ML, но абсолютно далеких от понимания Сетевой эксплуатации.  Набор новых аналитиков осуществляется этими же людьми по их же «цеховым» критериям – дают решать задачки на институтскую математику и программирование (!).

2) Демотивация молодых аналитиков сложностью индустриальных юзкейсов

Ни один 25-30-летний специалист по Data Science не планирует похоронить себя в каких-то OSS юзкейсах – они хотят либо научной славы (AI, Deep Learning), либо хороших денег (развернули аналитику по оптимизации дохода, посчитали экономический эффект — раздали премии).

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

В результате, несмотря на засилие DA/DS специалистов на рынке труда, таковых с глубоким пониманием telecom network operations практически нет.  Есть бывшие TMF-консультанты по процессам операторов, понабравшиеся на конференциях модных терминов вокруг БигДаты, но без базового образования в DA/DS/ML – и как следствие, толкущих воду в ступе.  Обычно именно к ним толпятся операторы на всех конференциях в тщетной надежде услышать что-то свежее про AI/ML для телекома.

3) Поверхностность технического пресейла в телекоме от вендоров аналитики

За исключением нескольких нишевых e2e решений с интегрированными network operations и аналитикой – например, work force management или управление ЗИПом – большая часть вендоров работает только на одном конце решения: только OSS или только аналитика.

Для первых OSS-часть их решения является 20-летним ПО с богатым TMF-функционалом и огромным RnD, куда затесалась в последние 5 лет небольшая команда специалистов по Hadoop и Spark, которых они ошибочно рассматривают как DA/DS.

Для вторых индустрия телеком является периферийной в балансе продаж их ПО – телеком обгоняют на 2 порядка продажи в финтех, ритейлу, биг-фарме, интернет проектам. И даже когда очередь доходит до телекома, впереди идут юзкейсы от целевого и продуктового маркетинга и CRM. В итоге разовые решения для data-driven-OSS у многих существуют либо только на слайдах единственного на весь регион (а то и на всю компанию) BDM по телекому, либо как обещания на будущее второй-третьей фазы внедряемого ПО аналитики. В результате их юзкейсы поверхностно проработаны в OSS-части, и большая часть встреч с операторами заканчивается отсутствием понимания у последних практической пользы применения аналитических предсказаний.

Что делать?

(данная глава является в большей степени приглашением к дискуссии, а не ставящим точку вердиктом автора)

Мнение, что все аналитики данных должны работать в Блоке БигДаты, похоже на древнее мнение, что все программисты должны работать в Блоке RnD, а другие блоки только ставить им задачи через бизнес-аналитиков.

Так же как ТехБлоку не обойтись сегодня без своих программистов, так же ему в ближайшем будущем не обойтись без своих DA с техническим пониманием DS. ТехБлоку не нужны бэкэнд программисты разработки, аналогично ТехБлоку не нужны DS/ML c глубоким бэкграундом в матстатистике и нейросетях. Но нужны роли знающих предмет технических адвокатов дата-дривен юзкейсов, которые бы:

• хорошо представляли, чем конкретно заняты DA/DS/ML (а не просто использовали в бытовом значении новые термины AI/ML),

• могли бы самостоятельно проводить исследовательский анализ данных и заниматься целеполаганием для перспективного применения ML в ТехБлоке,

• привлекать Блок Биг Даты к уже корректно сформулированным индустриальным юзкейсам на основе своего глубокого понимания и опыта в network operations.

Также только такие свои DA ТехБлока смогут:

• дать верную интерпретацию предсказаний аналитики в виде практических рекомендаций ТехБлоку и

• обеспечат постоянство регулярного обслуживания внедренных аналитических решений – не только в смысле их ТП, а и на прикладном уровне: контроля изменения данных, корректности анализа и предсказаний, (пере)обучения развернутых моделей ML в изменившихся условиях на сети.

Это более трудная цель для ТехБлока, чем обзаведение своими ИТ-шниками, так как если без дополнительного проф-обучения ИТ-шник еще может самообразоваться в хорошего Дата-инженера, то чтобы стать DA/DS от него потребуется получение дополнительного образования и личные склонности к математическим дисциплинам.

Вряд ли это радостная новость для ТехБлока, однако, примеры успешных применений БигДаты для сложно-технологических индустрий (например, фармацевтической) показывают, что в них наибольших практических результатов применения БигДаты добились индустриальные специалисты, которым образование и личные качества позволили освоить инструментарий DA/DS и применить в своей работе.