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

Хорошо известно, что сегодня у всех без исключения российских телеком‑провайдеров в штате находится солидный отдел, или даже целый департамент со многими отделами и командами, посвященный исключительно «(Биг) Дате». В пресс‑релизах наши операторы соревнуются за звание самой дата‑дривен компании — читаешь и радуешься, как все хорошо у людей. Сегодня, например, я прочел, что 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 и применить в своей работе.

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