Тяжела и неказиста жизнь простого RnD. Часть первая: как работают с новыми технологиями в крупных компаниях

в 7:10, , рубрики: Nvidia, RND, жизненный цикл технологий, импортозамещение, коммодитизация, корпоративные процессы, пилотирование технологий

«Папа, ну почему Солнце каждый день всходит на Востоке, а садится на Западе?» — «Главное — ничего не трогай!». Все вполне логично. Зачем менять технологию, инструмент, подход, если он и так хорошо работает. А инициатива, как известно, наказуема — рядового сотрудника за успешное внедрение чего-то нового максимум похвалят, а вот выпроводить за неудачу могут легко. Поэтому и существуют отделы RnD. Их задача — вовремя найти, оценить и предложить бизнесу то, что в будущем может принести деньги. Или же вовремя понять бесперспективность технологии.

Тяжела и неказиста жизнь простого RnD. Часть первая: как работают с новыми технологиями в крупных компаниях - 1

Привет! Меня зовут Александр Сапронов, я руковожу лабораторией ИТ-инфраструктуры в центре компетенций RnD МТС. Мы с коллегами щупаем, перегружаем, перегреваем и всячески издеваемся над разным компьютерным «железом» (например, опускаем в бочку со специальной жидкостью), чтобы через пару лет не пришлось менять его во всех продуктах, потому что оно не соответствует требованиям или превратилось в кирпич. В этом цикле постов я расскажу, как в крупных компаниях внедряют новые технологии, на какие этапы делят их жизненный цикл и почему в современном мире без RnD нельзя.

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

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

RnD-отделы в корпоративной структуре

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

Так мы говорим о продуктовой (бизнесовой) вертикали организационной структуры. Но есть еще и функциональная горизонталь — подразделения, выполняющие отдельные функции: ИТ, финансы, юристы, закупки и так далее. На пересечении горизонтали и вертикали появляются люди с двойным подчинением.

Руководитель RnD-подразделения обычно подчиняется профильным (близким по тематике исследований) бизнес-руководителям — например, директор лаборатории кибербезопасности может подчиняться директору департамента безопасности; директор блокчейн-лаборатории — финансовому директору; директор инфраструктурной лаборатории — директору департамента ИТ-инфраструктуры.

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

Идеальное предложение: ожидание и реальность

Двадцать лет назад Александр Буйдов, мой руководитель в системном интеграторе, говорил:

«На подготовку идеального предложения нужен один миллион долларов. Именно поэтому мы их не делаем :-)»

В этом случае речь идет о проработке всех аспектов задачи заказчика. Сбор бизнес-кейсов, проведение Due Diligence, расчет рисков, независимая оценка объекта инвестирования и так далее — получение всей доступной информации. Результатом станет некое «идеальное предложение», выраженное в деньгах.

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

Этапы внедрения технологий

В одной крупной международной компании с восьмидесятилетней историей моя должность Engagement Lead предполагала запуск и ведение крупных (от 5 миллионов долларов) инфраструктурных проектов, подготовку бюджета, формирование команды, работу с заказчиком. В этих проектах со стороны компании участвовали технические, финансовые, юридические, кадровые, кредитные эксперты. Проработав 11 лет на этой должности, я отметил экспоненциальный рост стоимости затрат для каждого этапа проработки решения.

Условно, если расчет стартового бюджета на пилотирование технологии может обойтись в 1 000 $ и занимает несколько дней, то подготовка же чернового технического предложения (blueprint) с учетом основных аспектов заказчика стоит уже 10 000 $ и занимает пару месяцев. Для того чтобы продумать и просчитать все юридические нюансы, например условия предоставления услуг, шансы возникновения налоговых и кредитных сложностей, может понадобиться 100 000 $, причем пресейл-команда будет работать уже 3–4 месяца.

С внедрением новых технологий ситуация точно такая же: на ранних этапах стоимость работы с ними гораздо ниже. Это позволяет выделить три основные стадии внедрения:

  • Disrupt. Здесь, как понятно из названия, происходит проверка технологии «на вшивость». Могут ли быть внедрены ИИ-инструменты для решения конкретных задач (например, программные роботы), сможет ли компания поменять CRM-систему, корпоративный мессенджер или сервис для видеоконференций на собственное решение. RnD отвечает именно за эти задачи. Привычный результат этого этапа — проверенная гипотеза (отпилотированная технология), Proof of Concept (PoC).

  • Change/Product. На этом этапе перспективная технология передается в продуктовое подразделение, которое будет использовать ее для запуска нового или совершенствования существующего продукта. Обычный результат этого этапа — минимально жизнеспособный продукт, или Minimum Viable Product (MVP). Происходит его пилотирование в ограниченном сегменте, и принимается решение о возможности его дальнейшего масштабирования.

  • Run/Production/Delivery. Новый или доработанный продукт внедряется в привычные рабочие процессы сотрудников, применяется для оказания услуг внутренним и внешним заказчикам. Обратная связь, полученная на этом этапе, дальше используется для доработки продукта. Может быть запрошена новая технология, востребованная заказчиками. Результатом этого этапа будет отчет об исполнении соглашения об уровне обслуживания — Service Level Agreement (SLA).

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

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

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

Откуда берутся пот, кровь и слезы при внедрении новых технологий

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

Нехватка бюджета на RnD

Собственный RnD — весьма дорогое удовольствие, и не все компании могут себе его позволить. Тем более, что вероятность получения на выходе готового продукта менее 70% (существует даже понятие «право на ошибку», которое может специально оговариваться с руководством). Тем не менее технологические компании активно инвестируют в RnD значительную часть своего дохода.

Вот цифры за 2022 год для нескольких крупнейших иностранных компаний (в процентах от годового дохода):

  • Amazon: 73,2 млрд $ (14% );

  • Alphabet: 39,5 млрд $ (14%);

  • Microsoft: 26,63 млрд $ (13%);

  • Huawei: 24 млрд $ (25%);

  • NVIDIA: 7,34 млрд $ (28%).

Российские компании догоняют западных конкурентов в доле инвестиций от дохода в RnD. Понятно, что абсолютные суммы гораздо скромнее.

Конфликты интересов

Чем больше компания, тем сильнее в ней могут различаться интересы разных отделов и сотрудников в них. Я это описал чуть выше: если задача исследования упадет человеку, который работает на этапе Run, то, скорее всего, он будет долго ругаться матом и ответит примерно так:

«Если я внедрю этот новый инструмент и с ним возникнет проблема, то у меня “ляжет” важный сервис, в итоге я останусь без работы. Если я не внедрю этот инструмент, меня даже никто и ругать-то не станет»

Разделение на этапы как раз позволяет избежать этой проблемы.

Завышенные ожидания внутренних заказчиков

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

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

Отсутствие единой терминологии

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

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

Какие задачи решает RnD в российских компаниях

Импортозамещение

Представьте себе треугольник прибыли:

Тяжела и неказиста жизнь простого RnD. Часть первая: как работают с новыми технологиями в крупных компаниях - 2

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

Уход зарубежных вендоров подстегнул рост количества RnD-отделов у российских компаний и объем их задач. Хороший пример — VMware. Сейчас бывшие крупные клиенты этого вендора стали самостоятельно разрабатывать аналоги его софта, чаще всего на основе Open Source. Для этого им потребовались внутренние команды, затраты на которые не превышали бы стоимость продукта ушедшего вендора. Хотя такая схема устойчивее, она однозначно дороже. Плюс развитие собственной уникальной функциональности под большим вопросом — повторить бы возможности вендора, уже хорошо.

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

Я пять лет работал в очень крупной американской корпорации, чья продукция есть в супермаркетах во всех странах мира. Ключевая система для ее бизнеса — CRM. В компании использовали качественное и эффективное ПО внешнего вендора. Но руководство решило, что надо создать свою CRM, ведь у нее есть целый штат из замечательных разработчиков и, что очень важно, лучшее (!) понимание специфики собственного же бизнеса.

Через три года разработки в компанию пришел новый ИТ-директор и потребовал ответы на три вопроса:

  • Сколько денег потратили за эти три года на проект?

  • Какой объем функциональности был разработан?

  • Какое соотношение между затратами на внутреннюю разработку и покупку аналогичных лицензий?

Оказалось, что за несколько лет было разработано всего 20% функциональности CRM-системы внешнего вендора, а затрачено на это в 10 раз больше стоимости базовой лицензии. Проект закрыли на следующий день.

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

Увеличение и удержание прибыли компании

Теперь давайте перевернем треугольник выше:

Тяжела и неказиста жизнь простого RnD. Часть первая: как работают с новыми технологиями в крупных компаниях - 3

Самая широкая часть — внизу, у производителя аппаратного обеспечения это уникальный случай, когда поставщик «железа» зарабатывает больше создателей софта и интеграторов. Сейчас на рынке компьютерного «железа» такое положение вещей создала и удерживает компания NVIDIA, разрабатывающая GPU для игрового и профессионального рынков, а также для систем искусственного интеллекта. Ее оборудование считается стандартом и эталоном в своем сегменте. Как же так вышло?

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

Именно это и сделали RnD NVIDIA: создали прорывную технологию, которая позволила компании оторваться от конкурентов и перевернуть треугольник в свою пользу.

По сути они сумели подхватить и адаптировать для своей сферы «закон Мура»:

«Закон Мура» в своей изначальной редакции Гордона Мура от 1965 года гласил, что количество транзисторов на кристалле интегральной схемы удваивается каждые 24 месяца. Впоследствии этот закон был переформулирован Давидом Хаусом из Intel в виде утверждения о том, что производительность процессоров должна удваиваться каждые 18 месяцев из-за сочетания роста количества транзисторов и увеличения тактовых частот. Он строго соблюдался примерно до 2000-х годов. А потом, несмотря не то, что стали появляться признаки его невыполнения, он неожиданно проявился уже в инфраструктуре нового типа — процессорах для задач искусственного интеллекта.

Да, когда конкуренты догонят, треугольник перевернется в обычное положение. Но NVIDIA вкладывается в разработку все более сложных решений, поддерживая выгодный для себя экстенсивный рост необходимых для их расчета мощностей.

Защита от вендорлока

Сейчас все используют дорогие GPU для обучения и исполнения моделей ИИ от NVIDIA. Да, эта ситуация не нова. Работающие в ИТ больше двадцати лет помнят рекламный слоган IBM: «Никого никогда не увольняли за покупку IBM».

Недавно была новость о том, что NVIDIA заблокировала возможность для россиян и белорусов скачивать драйверы, хотя компания заявляет о том, что любой покупатель видеокарты может рассчитывать на обновления. Всего через день скачивание опять открылось, возможно, это была просто ошибка на сайте, но подобная ситуация может повториться. Я вообще не удивлюсь, если NVIDIA начнет блокировать уже приобретенные и установленные карты в РФ. Пока люди не поймут, что надо использовать и другие решения, в том числе российские, ситуация не поменяется, и отечественный бизнес будет находиться под постоянным риском. С этой проблемой помогут справиться RnD-подразделения, если будут искать альтернативные варианты акселераторов ИИ вместо выплаты дани NVIDIA.

Резкий рост мощностей GPU, который подстегивает и удерживает NVIDIA, приводит к еще одному неприятному эффекту.

Адаптация к амортизации оборудования

Классический срок амортизации ИТ-оборудования с 2000-х годов составлял 4 года. Считается, что за это время его стоимость падает до нуля и дальнейшая поддержка и эксплуатация неэффективны. После этого оно оказывается на вторичном рынке или утилизируется.

С появлением у многих компаний стратегии AI First (ИИ в каждый утюг продукт) и взрывного роста потребности в вычислительных мощностях требуется все больше и больше «железа» и места под него в ЦОД. Так как строительство — долгий и сложный процесс, то остается возможность роста только за счет увеличения производительности оборудования. В результате реальный срок амортизации сейчас сократился до 1,5 лет. Из-за этого в крупных компаниях идет постоянное пилотирование, поиск новых решений и оборудования, чем и занимаются RnD-отделы.


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

Если у вас появились вопросы про RnD, пишите их в комментариях — постараюсь на них ответить.

Автор: Babuka

Источник

* - обязательные к заполнению поля


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js