Статьи

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

- Действительно ли российским компаниям требуются директора по данным (Chief Data Officer, CDO) или обсуждение CDO — лишь дань моде?

Многие вещи, приходя в нашу жизнь, сначала являются данью моде, но постепенно обретают больше смысла. Пока у всех разное понимание того, что должен уметь и делать CDO. Кто-то, называя себя так, фактически выполняет работу главного исследователя данных CDS (Chief Data Scientist). Кто-то считает, что CDO не должен быть исследователем данных, а должен думать о том, какие данные компании следует собирать, хранить и использовать и каким образом. Еще одна популярная точка зрения: CDO должен уметь смотреть на данные с позиции бизнеса. В моем представлении CDO отвечает за все, что касается сбора данных и извлечения из них пользы для бизнеса, а значит, должен разбираться и в аналитике, и в инфраструктуре, и в бизнесе.

- Нужна ли отдельная должность CDO или его функции может выполнять директор информационной службы либо директор по цифровизации (Chief Digital Officer)?

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

- Из каких специалистов можно вырастить CDO? Какие для этой должности требуются специфические знания и навыки?

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

- Как правильно организовать работу с данными? Зачем выделять в структуре компании подразделение data science? Не эффективнее ли будут распределенные команды специалистов по данным?

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

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

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

Как построить эффективное подразделение data science в условиях дефицита опытных специалистов?

В условиях нехватки высококвалифицированных кадров я бы рекомендовал инвестировать в перспективных молодых сотрудников.

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

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

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

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

«Мы сами не сразу поняли, чего в реальности можем добиться, пока не начали всерьез копаться в имеющихся данных, пытаясь получить новые знания о своих клиентах», — признает Леонид Ткаченко, директор департамента Big Data МТС. Очень быстро выяснилось, что возможности мобильного оператора действительно очень велики. В компании с легкостью способны видеть, даже кто с кем живет, причем не только среди собственных абонентов.

Проекту Big Data в МТС недавно исполнилось три года. Сначала команда проекта состояла из 20 сотрудников, сейчас же в ней насчитывается 250 опытных экспертов, а чистый экономический эффект за время ее существования составляет 3,5 млрд руб. Оказалось, что накопленные оператором данные действительно могут быть полезными, и эту пользу вполне получается извлечь.

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

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

«К концу 2020 года мы планируем охватить все возможные источники и агрегировать их в нашем озере данных. К тому времени знания о клиентах станут максимально полными», — продолжает Ткаченко. Когда проект начинался, объем полезных данных об абонентах составлял около 100 Тбайт — ничтожно мало по нынешним меркам. Сейчас данных более 1,5 Пбайт. В ближайший год в хранилище поступит еще 4 Пбайт данных.

«В начале проекта сведения о каждом абоненте включали примерно 1 тыс. метрик, начиная с базовых и заканчивая сложными, моделируемыми: профессия, место работы, наличие домашних животных. Сейчас их около 2 тыс., через год будет 3,5 тыс., а в принципе, мы видим возможность собрать 5 тыс. метрик по каждому клиенту», — говорит Ткаченко. Сейчас клиентские данные в системах обновляются раз в день, и в компании хотят добиться того, чтобы все данные, которые важно иметь в реальном времени, были максимально к нему приближены.

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

За время работы подразделение Big Data успело реализовать достаточно много проектов, но три из них хотелось бы отметить особо. Это автоматическое вычисление индекса NPS, психотипирование абонентской базы и оптимизация работы персонала в розничных магазинах.

Промоутеры и критики

Индекс потребительской лояльности (Net Promoter Score, NPS), который вычисляют исходя из соотношения выявленных лояльных и недовольных клиентов (соответственно промоутеров и критиков), до сих пор остается ключевым показателем практически для любой компании. В той или иной степени его используют все, определяя с помощью прямого опроса клиентов. Этот индекс действительно важен: опыт показывает, что он сильно связан с оттоком клиентов. Однако качество проводимой оценки (ответы не всегда правдивы) и стоимость этого процесса вызывают вопросы.

«Многие компании занимаются вычислением NPS в попытках понять, насколько довольны их клиенты. Можно констатировать, что работа эта крайне дорогостоящая. К тому же по результатам выборочных опросов остается неясным, кто именно из абонентской базы лоялен, а кто является критиком», — говорит Ткаченко. В МТС создали модель, с помощью которой автоматически в любую секунду можно рассчитать лояльность каждого из 60 млн абонентов с точностью 70–80%. По итогам проекта компании удалось выявить 3,5 млн критиков из московской базы абонентов, а проведенный кластерный анализ позволил выделить 15 их профилей. С точки зрения бизнеса — это 15 видов «болезней» клиентов, которые можно лечить.

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

Психотипы и геолокация

Еще один интересный проект, предпринятый МТС с целью оптимизации маркетинговых акций, — психотипирование абонентов на основе их поведения. Идея состояла в том, чтобы дифференцировать коммуникации с каждым из абонентов. Возможностей для этого традиционно не хватало. Ведь даже в Интернете при показе контекстной рекламы баннер демонстрируется хоть и не всем подряд, но один и тот же, а реакция на него не всегда будет желаемой. «Мы решили провести сегментирование клиентов и интегрировать его во все каналы — SMS, почту, мобильное приложение. Даже в контакт-центре автоответчик может разговаривать с клиентом по-разному», — рассказывает Ткаченко. У компании имелись обучающие выборки, и поэтому без особых проблем удалось разметить всю абонентскую базу по методологии Big Five.

Третий проект связан с геопозиционированием — это то, в чем мобильному оператору не может быть равных. В прошлом году МТС купила два портала по продаже билетов на развлекательные мероприятия — Ticketland и «Пономиналу». Вполне естественной стала попытка на основе информации об абонентах повысить продажи билетов. «Это действительно неплохо получается, потому что мы прекрасно знаем, на какие мероприятия ходил человек», — констатирует Ткаченко. В результате произошел значимый рост коэффициента кликабельности (click-through rate, CTR) — от 4 до 10% людей реагируют на сообщения о мероприятиях, подобранные специально с учетом их интересов.

Сколько человек нужно, чтобы закрыть магазин?

Не менее интересен проект из категории Workforce Management по управлению графиками работы сотрудников Русской телефонной компании — «дочки», управляющей монобрендовой розничной сетью МТС. Справедливости ради следует отметить, что данная задача не совсем вписывается в проекты департамента Big Data, однако лишь у данного подразделения существует хранилище такого размера, в котором возможно собрать и обработать детальнейшие данные об операциях из 6 тыс. салонов МТС, где работают 30 тыс. сотрудников. У каждого из офисов есть начальник, который на глазок определял, когда и сколько людей должны работать. Идея состояла в том, чтобы математически обосновать необходимость наличия в магазине определенного количества людей.

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

Интересной находкой оказалось изменение регламента открытия и закрытия магазинов. Традиционно служба безопасности требовала, чтобы магазины открывались и закрывались двумя сотрудниками. Однако собранные данные показали, что во многих случаях в начале и конце рабочего дня операций настолько мало, что второй человек оказывается ненужным, да и правонарушений в отношении сотрудников во время этой «зоны риска» также немного. Двукратное сокращение числа работников, занятых в эти часы, дало огромный экономический эффект: удалось снизить затраты на ФОТ на 10%. Что немаловажно, при этом не произошло оттока персонала (судя по всему, работа в утренние и вечерние часы радовала далеко не всех) и даже несколько возросли продажи.

Нынешний год становится поворотным для технологий роботизации процессов (Robotic Process Automation, RPA). Во многих компаниях заканчиваются пилотные проекты, по результатам которых рынок и будет оценивать возможности роботизации. Валентина Кулагина, руководитель отдела развития продуктов компании ICL Services, рассказала о том, какое место занимают RPA в процессе цифровой трансформации компаний, и о своих наблюдениях за этим рынком.

— Насколько актуален тренд цифровой трансформации для российских компаний? В чем он выражается для вас?

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

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

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

— Трендом нынешнего года становится роботизация бизнес-процессов. Какие направления ей наиболее подвержены?

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

Наши клиенты заинтересованы в роботах, если высвобождается хотя бы часть рабочего времени сотрудников. Например, 15 минут в час при восьмичасовом рабочем дне — это отличный результат. Эффект рассчитывается просто: сравнивается стоимость часа работы робота и человека в конкретном процессе. Если видна экономия, это является основанием для запуска пилотного проекта. Пока такие проекты как правило запускаются в простейших процессах: в бухгалтерии, в кадровом документообороте, при подготовке регуляторной отчетности. Однако мы считаем, что технологии RPA на таких процессах тестировать не совсем верно: обосновать их внедрение по результатам такого проекта будет очень сложно. Например, в компании есть бухгалтер, получающий небольшую зарплату, и робот, аренда которого обходится в меньшие, но вполне сопоставимые деньги. Экономия в таких случаях несущественна, и часто выбор делается в пользу человека, потому что его «функционал» гораздо шире. Поэтому мы ориентируемся на RPA с элементами искусственного интеллекта и предлагаем их использовать в тех процессах, где необходима поддержка принятия решений — то есть в процессах более высокого уровня.

Гораздо полезнее оптимизировать ту часть бизнеса, которая действительно «болит». Это вовсе не сверка дебиторской задолженности или обработка кадровых документов. Совсем другое дело — процессы, связанные с обслуживанием клиентов, формированием программ лояльности; сюда руководители готовы вкладывать. Конечно, выстроить поддержку внутренних процессов намного проще, но эффект от этого будет гораздо ниже.

— А готовы ли заказчики к тому, что услуги им будут предоставлять роботы?

Они готовы, никакой «психологической обработки» не требуется. Мы общаемся с клиентами по теме RPA и не слышим от них подобных вопросов. Достаточно дать сравнение, сколько их сотрудники тратят на бизнес-процесс сейчас, сколько у них времени высвободится в результате роботизации и — главное — куда это время можно будет направить.

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

В первую очередь, это цена и, во вторую очередь, — показатель time-to-market (время от начала внедрения RPA до получения результата). Компаниям важно получить результат за достаточно короткий срок, а на внедрение одного робота, сопровождающего несколько бизнес-процессов, может потребоваться всего несколько недель или даже дней. В то же время, серьезным сдерживающим фактором для таких проектов все еще является низкая стоимость труда в нашей стране. Именно поэтому мы и говорим о необходимости применения роботизации в более «дорогих» и ценных для бизнеса процессах.

— Что должно произойти, чтобы проекты RPA из диковинки превратились в мейнстрим?

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

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

Директор по рациональному природопользованию (chief sustainability officer)

К природопользованию необходимо подходить ответственно — спору нет, но, по мнению экспертов, эта должность не «верхнеуровневая», а вспомогательная, как и посты директора по данным, инновациям, закупкам, работе с клиентами и соблюдению нормативных требований.

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

Директор по хлопотам (chief worry officer)

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

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

Директор по счастью (chief happiness officer)

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

Директор по инклюзивности (chief inclusion officer)

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

Главный рассказчик (chief storyteller)

Должность с таким названием появилась в 2010 году в Microsoft. В обязанности занявшего ее Стива Клейтона входили публичные уточнения и разъяснения клиентам действий корпорации. Это может быть значимым для компании, но не совсем ясно, какие именно руководящие обязанности выполняет такой топ-менеджер. Подобные должности обычно появляются в компании, когда некая функция приобретает особую важность для ее выживания. Примеры: в Wells Fargo и Uber был введен пост директора по этике после ряда скандалов, чтобы продемонстрировать рынку, акционерам, широкой публике и правлению, что в компании работают над решением проблемы.

Директор по корпоративной атмосфере (chief experience officer)

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

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

Директор по вечеринкам (chief party officer)

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

Главный чародей

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

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

Директор по вкусам (chief flavor officer)

И наконец, есть должности со словом «chief», которые не обозначают никакой роли в высшем руководстве, да и какой-либо вообще конкретной роли в организации. Такие должности — что-то вроде почетных университетских степеней.

Пример: компания — производитель напитков Bai наградила Джастина Тимберлейка за его инвестиции должностью «директора по вкусам». Тратит ли он свое время на то, чтобы контролировать, какие вкусоароматические добавки используются в продукции Bai? Журнал Fortune цитирует главу компании Бена Вейсса: «Джастин обладает колоссальным творческим потенциалом. Его действительно волнует качество наших напитков, и в вопросах маркетинга и обновления вкусов у него есть мнение, к которому стоит прислушаться». Другими словами, Джастин Тимберлейк не курирует вкусы напитков Bai.

— Josh Fruhlinger. 9 chiefs you don't need in the C-suite. CIO. October 26, 2018

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

Ориентироваться можно на передовые организации, которые уже осуществляют соответствующие инициативы. Как свидетельствует опрос, недавно проведенный Deloitte Consulting, 82% организаций-первопроходцев получают полезную финансовую отдачу от инвестиций в когнитивные технологии — средняя рентабельность вложений составляет 17%.

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

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

Сосредоточьтесь на конкретных проблемах

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

Придерживаться этого принципа крайне необходимо, подчеркивают в GE. Например, если система ИИ выдает прогнозы относительно потребностей оборудования в ремонте, их необходимо интегрировать в соответствующий рабочий процесс, то есть организовать своевременную отправку на объект инженера соответствующей специализации. Возможно, также понадобится интеграция с системой управления запасами или даже с самим обслуживаемым оборудованием. Допустим, если ИИ способен понять, что в оборудовании требуется оперативно увеличить давление или температуру, то понадобится соединить ИИ с его системами управления.

Учитывайте пределы возможностей ИИ

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

Понять, подходит ли конкретная аналитическая модель для определенного набора данных, сможет только специалист в области data science. Нужно знать, какие допущения делались при создании модели и попробовать нагрузить ее — возможно, данными другого рода, чтобы понять, насколько она эффективна, объясняют в GE.

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

Прислушивайтесь к пользователям и заказчикам

Чтобы создать системы ИИ, выдающие полезные результаты, требуется участие не только разработчиков. В идеале проект нужно начинать с совещания с участием всех основных заинтересованных лиц, которые обсуждают все подробности и документируют все требования к системе, отмечают в Healthy Nevada Project.

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

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

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

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

Используйте знания в области своей специализации

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

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

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

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

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

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

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

С недавнего времени в компании начали использовать ИИ для классификации и очистки данных, благодаря чему часть ученых удалось освободить для более сложной работы. Но даже в ходе реализации простой системы распознавания текста нужны знания в предметной области, добавляют в CAS. Например, «nmol» означает наномолярную концентрацию, а «mmol» — миллимолярную, на шесть порядков больше. Если система перепутает два этих обозначения, реакция может превратиться в разрушительную.

Поэтому CAS нужны специалисты как в области ИИ, так и в области химии — это затрудняет поиск кандидатов и иногда делает невозможным наем сторонних подрядчиков.

Тестирование в реальных условиях — необходимость

Как «ни один план не переживает встречи с противником», так никакая система ИИ не переживает встречи с реальным миром. Если упустить это из виду, ваш проект ИИ обречен с самого начала, уверены в Credit Suisse Group.

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

Не забывайте, что ИИ — это «черный ящик»

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

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

В Beacon решили разработать систему на базе ИИ, которая бы выявляла проблему на ранней стадии, до того, как пациенту может потребоваться госпитализация. При этом в компании не только обучали будущих пользователей системы процедурам работы с ней, но и разъясняли принцип действия алгоритмов. А перед вводом в рабочую эксплуатацию был проведен пробный запуск с использованием данных по прежним пациентам. Как объясняют в компании, те пациенты, для кого прогнозировался высокий риск, были действительно подвержены высокому риску обострения, поскольку их позднее поместили в стационар. Таким образом, врачи Beacon могли наблюдать, как именно действует система, и это помогло уменьшить недоверие.

Затем, когда ИИ начали использовать для выявления риска у новых пациентов, за первые 12 недель система выявила почти 300 человек с высоким риском, больше половины из которых прежде таковыми не считались, согласно результатам традиционных диагностических методов. С выявленными пациентами была начата работа — телефонные собеседования, предоставление контактной информации о медицинских учреждениях, контроль приема лекарств. Через один-два месяца появилось достаточно данных, чтобы далее совершенствовать созданную систему.

Используйте понятные показатели

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

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

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

Развивайте сотрудников

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

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

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

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

По словам представителей GE, это только начало процесса, направленного на изменение корпоративной культуры, принципов организации работы и системы поощрений.

— Maria Korolov. 8 secrets of successful AI projects. CIO. November 8, 2018

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

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

Шаг № 1. Почистить ИТ-организм — провести входной аудит

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

Серия интервью, проведенных в ходе аудита с сотрудниками компании, топ-менеджерами и внутренней ИТ-службой, позволяет выяснить главное: контекст возникновения и «жизни» инцидентов и проблем. И найти оптимальные способы их устранения.

Отличие ИТ-аудита, проходящего как «нулевой этап» цифровой трансформации, от обычного анализа состоит в том, что команда, отвечающая за такой ИТ-аудит, изначально выясняет у бизнеса (генеральных, коммерческих, финансовых директоров, директоров по продажам, производству, логистике), какого эффекта бизнес ждет от намеченных цифровых трансформаций, какие именно информационные системы будут меняться в ходе этого процесса. И на что заказчик возлагает наибольшие надежды на данном этапе. Если, например, на модернизацию системы управления работой с клиентами и партнерами, то как именно он рассчитывает это делать? Если, скажем, на базе этой системы предполагается разработать личный кабинет для пяти-семи тысяч внешних пользователей с гарантированным приростом в 30–40% в течение следующего года, то ИТ-аудиторы будут, помимо прочего, тщательно проверять, выдержит ли ИТ-инфраструктура внедрение и работу такого решения. Правильно ли она спроектирована под него (от архитектуры СУБД до сервера приложений, веб-сервисов и терминальных сервисов)? Сможет ли она быстро и просто масштабироваться, отвечая запланированному притоку пользователей?

Шаг № 2. Обеспечить простую и недорогую масштабируемость ИТ-инфраструктуры: гибридные схемы и сайзинг ресурсов в IaaS

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

Более выгодным для среднего и даже крупного заказчика способом обеспечить простую и недорогую отказоустойчивость (в режиме «теплого» или «горячего» резерва ресурсов) является «гибридная» ИТ-инфраструктура. Если все нормально, работу предприятия обеспечивает инфраструктура традиционного типа, которая у него уже есть. И только если возникает нештатная ситуация, пользователи до момента ее устранения автоматически переводятся на работу с сервисами из облака. Причем за счет поддерживаемого гибридной инфраструктурой резервирования данных пользователи продолжают прерванную работу. При этом компания платит не за абстрактную надежность и отказоустойчивость (что может ни разу не потребоваться на практике), а за потребление ресурсов облака в периоды конкретных ИТ-инцидентов и «обрушений». И только если они действительно происходят. К тому же, если потребуется докупить у IaaS-провайдера ресурсы (скажем, под крупный проект), то делается это максимально быстро и просто — «в один клик».

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

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

Шаг № 3. Поддержать высокую изменчивость — начать непрерывный ИТ-аудит

Любые технологические изменения порождают если не рост, то почти всегда — перераспределение нагрузки на ИТ-инфраструктуру. Например, компания решила объединить два сервера баз данных в один отказоустойчивый экземпляр и слить в него все базы. Но, сделав это, организация должна быть уверена в том, что ее веб-сервисы и другие ИТ-системы, работающие с этими базами, справляются с нагрузкой и что сервер приложений при этом «чувствует себя» совершенно нормально. Кроме того, предприятию нужно детально знать, как в результате такого изменения поменялась нагрузка на дисковую подсистему, сети, сопутствующие компоненты. Если поменялась, то на каком участке и как именно. От этих знаний зависит сама возможность своевременно выявить «бутылочные горлышки», которые будут ограничивать производительность тех или иных информационных систем и бизнес-приложений, и перегрузка которых почти наверняка будет чревата целой цепочкой ИТ-инцидентов и проблем!

Непрерывный ИТ-аудит призван отслеживать именно такие вещи в режиме реального времени. Это, конечно, не делается вручную. Здесь нужна автоматизация — в данном случае дополнительный аналитический модуль, на оперативность, надежность и компетентность которого организация может положиться.

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

Шаг № 4 (дополнительный). Обеспечить постоянное взаимодействие команд на проектах по цифровой трансформации

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

Сегодня наилучшим способом преодолеть этот давний «камень преткновения» является выстраивание горизонтальных связей между командами в виде системы процессов, дополненной современными средствами коммуникации «для данного случая» (ad hoc). Если организация решает внедрить технологии управления Agile, нужно тщательно выбрать конкретную методику, настроить соответствующие процессы (чемпион здесь — Scrum) и уделить большое внимание компетенциям участников. В любом случае (даже если перехода на Agile нет) помогает формирование небольших рабочих DevOps-групп под проекты (в том числе и по цифровой трансформации). В эти группы входят представители каждой из вышеперечисленных команд. Однако всем им нужна общая информационная среда и доступ к постоянно обновляющейся информации в ней — о состоянии всего проекта и его составных частей. Чтобы каждый мог наблюдать и анализировать одни и те же тренды, осуществлять правильные и своевременные корректирующие действия. И не каждая команда — только по своему участку, а совместно, по общему ходу проекта. DevOps-группы в проектах цифровой трансформации должны стать потребителями объективных данных об информационных системах и инфраструктуре, чтобы своевременно принимать взвешенные и правильные для компании решения.

Автор — Дмитрий Бессольцев, директор департамента ИТ-аутсорсинга ALP Group.

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

Многие компании — достаточно вспомнить хотя бы General Electric — при реализации проектов цифровой трансформации в масштабе всего предприятия потерпели неудачу. По словам аналитика Forrester Research Аллена Бонда, сложившаяся тенденция сохранится и в 2019 году. Будучи убежденным в том, что цифровая трансформация потребует очередных сдвигов в технологиях, навыках и культуре, способствующих построению новых бизнес-моделей, Бонд считает, что подход Большого взрыва, несмотря на развернувшуюся вокруг него шумиху, не даст ответов на накопившиеся вопросы.

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

В интервью для CIO.com Бонд высказал пять основных прогнозов в отношении цифровой трансформации в 2019 году и указал, каким образом ИТ-директорам следует адаптироваться к происходящим изменениям.

1. Превращение цифровой трансформации в специализированные инновации

Компании и дальше будут трансформироваться, но более итерационными, умеренными темпами. Полутора- или двухлетние инновационные циклы придут на смену 5–7-летнему долгострою. В качестве примера Бонд привел компанию Adidas, экспериментирующую с обувью, распечатываемой на 3D-принтере, и Office Depot, тестирующую в своих магазинах сервисы цифрового маркетинга. Можно вспомнить также внедрение Metlife программного обеспечения искусственного интеллекта и развертывание Synchrony чат-бота. Оба эти проекта были призваны улучшить обслуживание технически подкованных потребителей.

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

Бонд рекомендует: Ищите быстрые победы, накладывайте их друг на друга и дайте цифровым лидерам возможность выстраивать новые конструкции поверх уже имеющихся. Этот способ предполагает последовательное выполнение отдельных этапов, каждый из которых должен окупаться.

2. Окупаемость операционной эффективности

«Более пристальное внимание к рационализации операций дополняется ослабеванием энергичности цифровой трансформации и связанной с ней риторики, — заметил Бонд. — В 2019 году компании ускорят ориентацию на цифровые операции, улучшающие конечный результат для клиентов и обеспечивающие эффективность».

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

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

3. Время управлять продуктами

В 2018 году ИТ-директора все чаще говорят о переходе от управления проектами к управлению продуктами с поддержкой концепции «всё в качестве услуги» (everything-as-a-service, XaaS) и с растущей ориентацией на поддержку и упрощение схем клиентского перехода.

С учетом продолжающейся ориентации ИТ-директоров на клиентов в 2019 году можно ждать появления должностей, ориентированных на продукты, в том числе цифровых дизайнеров, менеджеров по продуктам и «менеджеров по восприятию». Компании должны нанимать менеджеров по продуктам, которые поддерживали бы связь между службами маркетинга и ИТ, занимались бы урегулированием споров и поиском новых путей выхода на рынки.

Бонд рекомендует: Главное, чтобы менеджер по продуктам не слишком увлекался инженерными вопросами в ущерб маркетингу, с тем чтобы «глас клиента» не был утерян, поскольку это может навредить компании. Если управление продуктами очень тесно связано с инженерными вопросами, установить на рынке партнерские отношения будет значительно сложнее.

4. Развитие платформ B2B и электронной коммерции

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

Бонд рекомендует: Разрабатывая стратегию платформы, прекратите относиться к данным как к «государственным секретам», вместо того чтобы делиться ими с дистрибьюторами и поставщиками. Ведь они могут стать для вас отличными партнерами в части обмена данными. Если же такого партнерства не получается, продолжайте работать с ними, проявляя гибкость.

5. Интеграция в цифровой стек искусственного интеллекта

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

В качестве примера Бонд привел технологию искусственного интеллекта Adobe Sensei, упрощающую проведение маркетинговых кампаний, а также систему IBM Watson, находящую применение в самых разных областях, начиная от здравоохранения и заканчивая прогнозированием погоды. «Повлиять на назойливую рекламу мы не можем, но она исчезнет сама собой по мере ужесточения финансирования, — заметил Бонд. — А средства искусственного интеллекта будут все активнее интегрироваться в цифровые процессы и инструменты». В качестве примеров можно привести выдачу рекомендаций с помощью искусственного интеллекта, управление контентом и системы планирования цепочек поставок.

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

Призыв к ускорению и итерационным инновациям полностью согласуется с идеей Бонда уменьшать масштабы цифровой трансформации.

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

— Clint Boulton. 5 digital transformation trends for 2019. CIO. NOV 7, 2018

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

«У нас постоянно идут новые проекты, и в компании до сих пор существует дух стартапа. По моему мнению, нашего взрывного роста никогда не произошло бы, если бы мы не пришли к заветам, заложенным в Agile», — рассказал Андрей Ревяшко, ИТ-директор интернет-магазина Wildberries, на конференции «Agile, DevOps, ITSM 2018», организованной издательством «Открытые системы». Масштабы роста магазина впечатляют: сейчас Wildberries обрабатывает в среднем 240 тыс. заказов в день, то есть более одного заказа в секунду.

«Период полураспада» и «задачи-пустышки»

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

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

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

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

«У нас такую проблему удалось решить с помощью тюнинга подхода Agile. Руководителю — генератору идей в подчинение выделяются все необходимые для реализации проекта специалисты, и ответственность за результат лежит на нем», — говорит Ревяшко. И эта практика начала приживаться, попутно стало убавляться число задач-пустышек. В конечном итоге это привело к тому, что в каждом департаменте появился свой небольшой ИТ-отдел. И вопрос о приоритетности решаемых им задач ложится на плечи главы этого департамента — того, кто понимает, в каком направлении ведется работа, и отвечает за нее. Фактически он становится владельцем создаваемых продуктов.

«У бизнеса появился в руках ИТ-инструмент, позволяющий адекватно реагировать на вызовы времени. Важно, чтобы дух стартаперства продолжал сохраняться в департаментах и бизнес не был скован по рукам и ногам. На своем опыте мы убедились, что выделение каждому департаменту своего ИТ-отдела действительно работает», — считает Ревяшко.

Логика, воля и эмоции

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

«Мы решили присмотреться к опыту NASA, в свое время заказавшего исследование, призванное помочь собрать группу астронавтов, неконфликтных по отношению друг к другу. Согласно данной методологии, в каждом человеке заложено примерно 16 функций. Их соотношение четко говорит о поведении людей и их совместимости», — утверждает Ревяшко. Подобный подход можно применять и в обычных компаниях при подборе сотрудников, чтобы собрать крепкую команду, которая не подводит бизнес, имеет взаимопонимание с ним, а ее участники не конфликтуют между собой. Однако выделение в человеке 16 функций приводит к появлению более 700 психотипов. Это тяжело: при всей мощи этой методологии, порог вхождения в нее очень высок.

Однако существует модель психолога Александра Афанасьева, более простая в применении. Его работа «Синтаксис любви» была направлена на выяснение причин конфликтов внутри семей. Созданная модель подразумевает выделение в человеке всего четырех функций, которые определяют, как человек смотрит на мир и реагирует на окружающие его вызовы. И она подразумевает всего 24 психотипа. Ее-то и взяли на вооружение, чтобы вывести эффективность команд разработки на качественно новый уровень.

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

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

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

«Исследование, проведенное в команде Wildberries, показало, что подавляющее большинство ИТ-специалистов можно отнести к категории ЛВФЭ и ЛВЭФ, и мы ориентируемся именно на них», — подчеркивает Ревяшко. Конечно, людей, не соответствующих этому портрету, уже не переделать, но зато можно более эффективно их использовать с учетом сильных и слабых сторон. Кроме того, когда происходит набор новых сотрудников, а тем более молодежи с целью дальнейшего взращивания, есть хорошая возможность определить, состоится ли человек как айтишник или нет.

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

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

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

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

«Искусственный интеллект и машинное обучение охватывают DevOps в полной мере, – подчеркнул Спандан Махапатра, возглавляющий в компании Tata Consultancy Services направление бизнес-решений. – Многие компании так или иначе уже опираются в своих проектах цифровой трансформации на DevOps и добиваются благодаря этому более высоких результатов. Искусственный интеллект и машинное обучение открывают путь к оптимизации процессов DevOps».

«Большинству команд DevOps делать ставку на искусственный интеллект еще рановато, но мы видим, что все больше клиентов намерены использовать искусственный интеллекта и связанный с ним анализ данных, – добавил Стивен Эллиот, вице-президент International Data Corp. по вопросам DevOps, управления облачными конфигурациями, ITSM и программно-конфигурируемых архитектур. – Наиболее заметные области применения искусственного интеллекта в DevOps связаны с непрерывной интеграцией (continuous integration, CI) и непрерывной разработкой (continuous development, CD), выявлением и разрешением возникающих проблем, а также с углублением обработки и понимания собранных клиентских данных. Мы отмечаем, что инфраструктурные и операционные команды испытывают тягу к аналитике. Многие уже внедряют сервисы управления производительностью приложений и анализа данных в реальном времени, дающие возможность оперативно выявлять и решать возникающие проблемы. Командам DevOps следует подумать об использовании аналитики, которая помогает диагностировать и устранять неисправности, способствует повышению эффективности процессов и улучшению клиентского восприятия, а также достижению более высоких бизнес-результатов в целом».

В русле тенденций

Компания Power Home Remodeling использует искусственный интеллект в сочетании с DevOps при создании решений, предназначенных для перестройки внешних элементов зданий. Она разработала собственную технологическую платформу NITRO, выполняющую самые разные задачи, начиная от управления отношениями с клиентами (customer relationship management, CRM) и заканчивая функциями внутренней социальной сети.

«Мы являемся центром разработки и у нас сформирована полноценная команда DevOps», – сообщил директор Power Home Remodeling по инновациям Тим Уэнхолд. С помощью NITRO компания выстраивает всеобъемлющую инфраструктуру искусственного интеллекта, используя накопленное богатство данных для машинного обучения, что способствует улучшению обслуживания клиентов, более высокой эффективности и расширению возможностей персонала.

«Команда DevOps выясняет, как лучше использовать инфраструктуру искусственного интеллекта на практике, – отметил Уэнхолд. – Искусственный интеллект и машинное обучение призваны повысить эффективность труда разработчиков, осваивающих новые инструменты. Искусственный интеллект помогает прогнозировать развитие процессов DevOps. Анализируя, например, процессы непрерывной интеграции, средства искусственного интеллекта подсказывают, какие моменты следует скорректировать, чтобы улучшить конвейер CI».

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

По мере того как искусственный интеллект становится все более мощным, его влияние на DevOps растет. «В перспективе искусственный интеллект и машинное обучение помогут нам не только быстро выявлять аномалии, но и решать проблемы, о которых мы еще даже не подозреваем, – подчеркнул Уэнхолд. – У компании имеются журналы с миллионами записей. Сегодня мы действуем, как детективы: просматриваем журналы, ищем аномалии и принимаем меры. Искусственный интеллект самостоятельно будет выявлять аномалии. Затем он проинформирует о том, что может произойти, и предложит варианты устранения угрозы. Более того, искусственный интеллект известит нас о предпринятых для ликвидации аномалии мерах. Всё это весьма впечатляет».

Медицинская компания Molina Healthcare также возлагает на связку искусственного интеллекта и DevOps большие надежды. «Уже сейчас мы видим, какие преимущества перед нами открываются, – сообщил ИТ-директор Molina Healthcare Рик Хопфер, занимающийся применением средств искусственного интеллекта в DevOps с 2016 года. – Перед нами стоит проблема, как совладать с имеющимися в наших журналах транзакций горами данных, которые наши системы генерируют ежедневно. Одного лишь наличия системы, предназначенной для сбора данных, недостаточно. Необходимо еще и уметь отделять реальные проблемы от прочего белого шума».

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

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

Будущее уже сейчас

«Будущее видится нам в том, чтобы, исходя из своих аналитических возможностей, принимать необходимые меры с определенным прицелом: с точки зрения CI/CD, клиентского восприятия, управления проблемами и т.д., – указал Эллиот. – Автоматизация и анализ – это как джем и масло: гораздо лучше, когда они вместе. Дело будет сводиться к повышению производительности технологических и бизнес-процессов, к выполнению определенных действий в специфичных деловых и технологических ситуациях».

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

«DevOps может повысить скорость новых приложений, но в мире постцифровой трансформации DevOps нужно объединять c требованиями, предъявляемыми искусственным интеллектом, – указал Энди Граймс, главный технолог компании NetApp, специализирующейся на решениях для хранения данных и управления инфраструктурой. – Сочетание методов DevOps и современных требований к данным порождает новую парадигму — DataOps. Поскольку новые приложения искусственного интеллекта требуют агрегирования, а также значительно более высоких скоростей и масштабов подготовки данных, разработчики, использующие парадигму DataOps, должны взаимодействовать с ИТ-службой более тесно и понимать место приложений искусственного интеллекта в гибридной среде. Современная концепция DataOps объединяет периферийные наборы данных с агрегированными основными данными, размещаемыми локально, дополняет их облачными хранилищами и предлагает архитектуру, поддерживающую частое внесение изменений, подстегиваемое необходимостью внедрять инновационные инструменты и отвечать требованиям непрерывной эволюции бизнеса».

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

«Искусственному интеллекту присущи три свойства – самообучение, прогнозирование и автоматизация, – отметил Сумендра Моханти, руководитель направления анализа данных компании Larsen & Tourbo Infotech, являющейся глобальным поставщиком ИТ-решений и поддерживающей цифровую трансформацию своих корпоративных клиентов путем внедрения средств искусственного интеллекта. – Они позволяют улучшить такие практики DevOps, как CI и CD».

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

«Искусственный интеллект придает данным свойство самообучения. Вот почему искусственный интеллект и машинное обучение приносятьно весьма ощутимую пользу при их интеграции в процессы и задачи DevOps. Так, при разработке программного кода средства искусственного интеллекта, моделируя различные сценарии, могут отслеживать, в какой степени удовлетворяются потребности пользователей, – пояснил Моханти.– Конечному пользователю не отводится роль пассивного игрока. Искусственный интеллект и машинное обучение позволяют оторваться от разработки программного обеспечения исключительно на основе заранее установленных правил и во многом обеспечить дополнительную гибкость за счет изучения данных».

Искусственный интеллект и машинное обучение помогают отслеживать производственные показатели, устанавливать связь с прошлыми проблемами, изучать предложенные решения и оценивать, насколько эффективными они были. Некоторые негативные моменты можно прогнозировать заранее и устранять автоматически. «Соединение искусственного интеллекта и машинного обучения с DevOps не только сделает процедуры проектирования программного кода, его развертывания и выпуска готовой продукции более предсказуемыми, но и обеспечит непрерывность процесса инноваций», – добавил Моханти.

Команды DevOps сосредоточены на жизненном цикле проектирования, учитывая при этом меняющиеся требования. «Однако есть важные аспекты предсказуемости качества кода и управления данными, связанные с тем, на чем команды не акцентируют свое внимание, – указал Моханти. – Интегрируя искусственный интеллект и машинное обучение в свои процессы, команды DevOps могут проанализировать выполнение кода, понять, все ли пользовательские сценарии учтены, изучить возникавшие ранее проблемы и способы их решения».

Управление данными

Искусственный интеллект помогает организовать управление растущими объемами данных в средах DevOps.

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

«Сфера DevOps переполнена огромными объемами данных, – добавил Канал. – Эти данные часто используются непосредственно для тех целей, для которых они предназначены. Например, отчеты помогают понять, в чем заключается ошибка. Но средства машинного обучения и искусственного интеллекта позволяют почерпнуть из всего этого гораздо больше. Так, изучая типы ошибок, присутствующие в отчете, аналитики могут обнаружить много чего интересного: какие модули используются наиболее интенсивно, в каких чаще встречаются ошибки, какие ошибки обнаружить труднее всего, и прочие полезные факты. Используя систему отчетов об ошибках в качестве источника данных о среде разработки, можно почерпнуть массу дополнительных сведений о процессе разработки и повысить общую эффективность».

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

- Bob Violino. How AI will revolutionize DevOps. CIO. July 18, 2018

Компания IDG Communications оценила затраты клиентов на облачные технологии, изучив мнение читателей CIO, Computerworld, CSO, InfoWorld, ITworld и Network World.

В рамках исследования 2018 Cloud Computing было опрошено 550 представителей корпоративного сектора, принимающих ключевые для своих организаций решения в области ИТ и безопасности в самых разных отраслях. Как показало исследование, организации наращивают инвестиции в облачные решения в стремлении стимулировать рост бизнеса.

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

Сложности для клиентов = возможности для партнеров

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

Рост трудностей у клиентов открывает дополнительные возможности перед партнерами, которые предлагают консультационные услуги, создают новые приложения и внедряют адаптированные решения.

В настоящее время 43% используют только гибридное облако, 12% – мультиоблачную среду и 30% – и то, и другое вместе.

К преимуществам мультиоблачной среды относятся: расширение облачных возможностей (59%), упрощение и ускорение восстановления после сбоев (40%), повышение гибкости за счет распределения рабочей нагрузки между множеством облаков (38%).

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

На крупных предприятиях (где работает более 1 тыс. сотрудников) давление ощущается сильнее, чем на предприятиях среднего звена (численностью менее 1 тыс. человек).

Если приводить точные цифры, то давление со стороны высшего руководства или отдельных направлений бизнеса испытывают 44% ИТ-служб крупных организаций и 31% ИТ-служб предприятий среднего звена.

Эволюция более сложных сред вызвала необходимость включения предприятиями в свой портфель активов поставщиков облачных сервисов. Об этом упомянул 51% опрошенных клиентов.

Погружаясь глубже, организации в технологически-зависимых отраслях склонны рассматривать поставщиков облачных сервисов в рамках портфельной стратегии. Наиболее отчетливо этот процесс протекает в сфере финансовых услуг (63%) и высоких технологий (63%). Зато в производственной сфере (43%) и образовании (41%) поставщиков облачных сервисов не так активно включают в портфельную стратегию.

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

Затраты как сервис

Следует отметить, что доля ИТ-бюджетов, выделяемая на облачные вычисления, остается относительно неизменной и составляет 30% против 28% в 2016 году.

С учетом того, что на облако приходится значительная часть затрат на технологии, не удивительно, что именно ИТ-директору отводится главная роль в процессе закупок облачных ресурсвов.

О значительном влиянии ИТ-директора упомянул 71% опрошенных, тогда как за следующего в этом списке технического директора свои голоса отдали 54% респондентов.

На предприятиях среднего звена не менее влиятельным оказывается генеральный директор (72%), на крупных же второе место занимают директор по безопасности и архитектор ИТ (у них обоих 87%).

Углубляясь в технические аспекты исследования, стоит отметить, что структура вычислительной среды организации – доля необлачных активов, SaaS, PaaS и IaaS – примерно поровну распределена между облачными и необлачными ресурсами, но ожидается, что ситуация здесь будет меняться.

В настоящее время у среднего предприятия 53% приходится на необлачные ресурсы, 23% на SaaS, 16% на IaaS и 9% на PaaS.

Ожидается, что через полтора года доля необлачных ресурсов составит 31%, SaaS – 33%, IaaS – 22% и PaaS – 14%.

Два главных преимущества SaaS для сотрудников ИТ-службы заключаются в сокращении числа операций технической поддержки и обновления, выполняемых вручную (62%), и повышении производительности труда / уменьшении затрачиваемого рабочего времени (55%).

Следующие два фактора – доступ и надежность, а также расширение возможностей для клиентов (по 55%) – самым непосредственным образом отражаются на конечных пользователях.

Главными преимуществами PaaS являются сокращение накладных расходов на серверы и системы хранения (56%), а также отсутствие необходимости управлять обновлениями и осуществлять техническую поддержку (51%). Преимущества IaaS связаны с масштабируемостью (68%) и гибкостью (53%).

Основными приложениями, которые организации используют в облаке (или перемещают туда) являются веб-сайты и веб-приложения (49%), а также решения для связи и взаимодействия (45%).

К приложениям, перенос которых находится на этапе планирования – и должен состояться в ближайшие 12 месяцев или в течение 1-3 лет – относятся средства восстановления после сбоев и обеспечения высокого уровня готовности (49%), а также системы бизнес-анализа и хранилища данных (45%).

Далее следуют средства хранения, резервного копирования, архивирования и файл-серверы (44%), а также средства управления системами и DevOps (42%).

Вызовы остаются

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

Вместе с тем результаты отражают устойчивое снижение опасений в области безопасности – с 67% в 2015 году до 34% сейчас.

Две другие проблемы, связанные с безопасностью и управлением, с течением времени также становятся менее острыми в связи с ростом зрелости облачных технологий, подкрепляемой ужесточением нормативных требований и обеспечением соответствия облачных решений корпоративным требованиям и отраслевым стандартам (если в 2015 году об этом упоминали 35%, то в 2018-м – уже 26%).

Обеспокоенность вопросами управления информацией (eDiscovery и другие требования к информационному управлению) находилась на наивысшем уровне в 2014 году (35%), а затем начала снижаться и сейчас уменьшилась до 23%.

«В условиях дальнейшего роста безопасности облачных решений не удивительно, что организации ищут дополнительные способы интеграции этих моделей в свой технологический стек, – добавила Экстром. – Роль стратегического руководства и управления поставщиками должна оставаться за ИТ-службой, в то время как внедрением облачных приложений могут заниматься и их коллеги по организации».