Статьи

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

«Социальная аналитика (social intelligence) – это просто использование тех возможностей, которые вам уже предоставляют средства аналитической обработки данных социальных СМИ, – поясняет Дженни Сассин, вице-президент по исследованиям Gartner. – Это может быть базовая аналитика или более сложная, но ею почему-то не пользуются, хотя, казалось бы, сейчас это уже должно происходить».

Сассин приводит в пример производителя йогуртов, которому нужно найти рынок сбыта для продукта с новым вкусом: «Основные потребители йогуртов – женщины, но возможно, в компании хотели бы знать, что, к примеру, мужчины в определенном регионе, играющие в футбол, были бы не против попробовать “энергетический йогурт”». Это можно было бы выяснить с помощью серии запросов, сделанных посредством инструментов социальной аналитики, таких как Brandwatch, Crimson Hexagon, Synthesio или Talkwaker.

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

Социальная аналитика невозможна без человека

Брайан Лонг, старший менеджер Nissan North America по работе с клиентами в социальных СМИ, признает: несмотря на то что технологии играют большую роль в его деятельности, в компании все же не хватает средств автоматизации социальной аналитики – анализ постов, твитов и упоминаний бренда, которых могут быть миллионы за год, проводится вручную.

«Нужно, чтобы эту информацию читал человек, способный понять потребности клиента и спланировать реакцию компании», – подчеркивает Лонг. В Nissan шесть-восемь аналитиков просматривают данные, накапливаемые системой управления социальными СМИ Sprinklr, которая позволяет следить за корпоративными аккаунтами Twitter, страницами Facebook, Instagram и Google Plus. Именно аналитики, по словам Лонга, в конечном счете принимают решение о необходимости отреагировать: «Не обязательно обращать внимание на чьи-то одиночные жалобы, но вот если проблема достаточно распространенная, ответить придется».

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

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

Практическое мастерство и наука

Салли-Энн Камински, менеджер по стратегии социальных СМИ Zebra Technologies, – единственный сотрудник компании, обязанности которого целиком связаны с социальными сетями. Она считает своей задачей пропагандировать преимущества социальной аналитики в компании – производителе ноутбуков, сканеров, меток RFID и принтеров штрихкодов.

Когда в отделе обеспечения продаж просят сведения о потенциальных клиентах, Камински заходит в Oracle Social Cloud, инструмент управления взаимоотношениями с клиентами в социальных сетях, и создает информационную панель для специалиста по продажам. В Social Cloud выполняется поиск по ключевым словам и фразам, позволяющий обнаруживать тематическую переписку в Facebook, Twitter, LinkedIn, на форумах и в блогах.

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

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

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

Интеграция социальной аналитики с информационной инфраструктурой компании

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

Тем не менее в компаниях нередко просто «запихивают» данные социальных СМИ, например сведения о числе отметок «нравится», в BI-системы наподобие Tableau, вместо того чтобы использовать специализированные модули обработки такой информации, доступные в бизнес-приложениях Oracle, Salesforce, Microsoft Dynamics и других. В результате вся ценность информации социальных СМИ упускается.

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

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

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

Выход социальной аналитики из-под крыла маркетинга

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

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

– Sandra Gittlen. Social intelligence: How to mine social media for business results. CIO. July 26, 2017

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

«Не надо суетиться с импортозамещением, оно может произойти естественным образом», – рекомендовал Олег Капитулов, директор департамента ИТ компании «Транснефть», на конференции «IT в ТЭК».

Незаменимых нет?

Главное преимущество «тяжелых» западных решений заключается в том, что единой платформой можно закрыть все потребности крупной компании. А значит, тогда имеет смысл внедрять эти продукты – например, альтернатив для SAP во многих отраслях нет. Если же внедряемый функционал относительно невелик, то преимущества SAP уже не столь очевидны: это дорогая во внедрении, сложная в эксплуатации платформа, а ее ежегодная поддержка обойдется в 22% стоимости лицензий. Зачем это нужно, если «1С» или собственная разработка может справиться с теми же самыми задачами? Проблема в том, что зачастую компании начинают заниматься тематикой SAP, не имея четких планов или просто отдавая дань моде.

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

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

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

«За два года потратили много средств на пилотный проект ТОРО. Я на протяжении месяца обсуждал функционал реализованного решения с бизнес-заказчиком и видел своими глазами, что люди не получили тот продукт, который им обещали», – признает Капитулов. Чуда не произошло: по большому счету, получилась заказная разработка, которая полного удовлетворения пользователям не принесла. И было понятно, что они должны будут сидеть до 10 вечера на работе, занося информацию в систему, а возможно – даже выходить на работу в выходные.

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

Игра платформ

«Мы часто говорим, что импортозамещение возможно далеко не везде. Я сам полагал, что в случае SAP в нефтегазовой отрасли это нереально. Но мы случайно нашли аналог того, что искали, – паспортизацию оборудования – в функционале «Галактики»», – говорит Капитулов. Оказалось, что за последние два года компания создала продукт «Галактика EAM» на базе разработки для «Роснефти». При этом отечественное решение по определению имеет ряд преимуществ: потребности и менталитет рабочих другие, а их образование в ряде случаев выше. То, чего от SAP дождаться не удалось, у «Галактики» оказалось наполовину готовым, и уже к концу лета будет дописан продукт, позволяющий реализовать задачи «Транснефти».

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

«Если будет бухгалтерия на SAP, а ремонты на «Галактике», возникнет более 2 тыс. интеграционных точек, следить за которыми очень сложно. Получится крайне дорогое решение. Вспомнив, что в 80% дочерних структур прежде уже использовались решения «Галактики», поняли, что при добавлении к ним функционала ремонтов получится полноценный российский продукт», – отмечает Капитулов. Именно поэтому у компании возникла идея все же ориентироваться на российского производителя.

Разумеется, у «Галактики» есть серьезный минус: ее пока невозможно сделать централизованной. Системы будут локальными и будут между собой синхронизироваться. Тем не менее идут тесты на различных СУБД, и через несколько лет вполне возможной станет централизованная инсталляция «Галактики» даже в очень крупных компаниях.

Первый этап функционала ТОРО планируется запустить в январе 2018 года, а более развернутая функциональность ожидается к 2019 году. Если эти наработки войдут в стандартный функционал, то многие крупные и средние компании начнут воспринимать «Галактику» как очень серьезного игрока и реальную альтернативу SAP.

Создание российского конкурента

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

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

«Будучи ИТ-директором, я делал много проектов впервые в России и иногда даже впервые в мире. Должен сказать, что не боги горшки обжигают: даже у лидеров рынка новый продукт – сырой», – делится Капитулов. Успех проектов всегда зависел только от команды и активного взаимодействия с исполнителем. Это возможно только тогда, когда заказчик четко понимает, что ему нужно, имеет железную хватку и готовность добиваться от разработчиков результата. То же самое сейчас нужно при работе с российскими партнерами.

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

Куда движется отрасль? Почему в компании заговорили о необходимости цифровой трансформации?

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

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

Как вы определяете для себя цифровую трансформацию? Какой должна стать компания, чтобы соответствовать требованиям рынка?

Для нас трансформация в первую очередь заключается в выводе на новый этап развития модели управления оперативным производством. С точки зрения ежедневной работы это более стандартизированные процессы, максимально автоматизированные, при этом не имеющие слишком жесткой логики, дающие возможность быстро адаптироваться. Что я имею в виду? Сама по себе способность производить и отгружать быстрее, выпускать все более сложные продукты – это относительно просто. Гораздо сложнее работать с минимально возможными объемами продукции. Здесь все упирается в себестоимость: если раньше небольшая партия при определенной цене была невыгодной и от ее производства могли отказаться, то сейчас надо сделать так, чтобы выполнять такой заказ стало экономически эффективно. Поэтому очень важным для нас стало решение о внедрении единой системы оперативного управления производством – MES-системы, которая заменит существующие сегодня цеховые системы. Единая платформа как раз и позволит нам производить продукцию, ориентируясь на индивидуальные потребности клиента, и  отслеживать всю цепочку – от запроса до отгрузки. Всё это в комплексе даст тот самый новый виток в развитии компании.

Фото: ОМК

Расскажите подробнее о технологиях, которые легли в основу цифровой трансформации ОМК.

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

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

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

Еще одна лаборатория занимается методиками Agile. Эти гибкие методы мы активно продвигаем не только в разработке ПО и управлении проектами, но и в повседневной операционной работе.

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

А как вообще пришло понимание того, что изменения нужны?

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

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

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

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

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

Какими способами вы «раскачиваете» специалистов предприятия, повышаете их информированность?

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

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

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

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

Фото: ОМК

Ваша дирекция уже давно издает собственный журнал – «Импульс», который недавно был переименован в «#Цифру». Какую роль он выполняет?

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

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

В чем вы видите свою роль в развитии бизнеса компании, как ее для себя определяете?

Я часто вспоминаю известный девиз Microsoft: «Меняйся, чтобы побеждать». На мой взгляд, он четко отражает суть того, что мы делаем. Меняем бизнес, меняем себя. Роль не только в поддержке бизнеса, но и в проведении изменений. Приходится играть гибридную роль, управляя не только ИТ, но и изменениями, и бизнес-процессами. Да, иногда сталкиваемся с противодействием, но в балансировке подобных конфликтов часто и заключается работа управленца.

Существенная часть аgile-трансформации – изменение культуры. Гибкой следует делать всю организацию целиком. Николай Кныш, директор по развитию ИТ-продуктов «Райффайзенбанка», рекомендует руководителям, которые хотят построить гибкую организацию, запастись терпением и быть аgile, а не внедрять его. Таков был главный посыл его выступления на форуме ITMF 2017, организованном издательством «Открытые системы».

– Зачем вы хотите стать agile?

Чтобы быстро запускать новые идеи и делать так, чтобы клиентам это очень нравилось.

– С чего у вас все началось?

Все началось с дирекции ИТ, которой предъявляли две классические претензии: долго и дорого. Если все делать быстро, нужно минимум шесть месяцев, чтобы установить минорную задачу в продуктив. И то, если вложиться всей душой. Сегодня это малоинтересно бизнесу.

Agile, DevOps и Scrum – это зачастую дорого. Но на уровне правления мы решили, что нам важнее скорость запуска продуктов и уровень удовлетворенности клиентов.

– Почему дорого, если вы экономите время. Ведь время стоит денег?

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

– Рост штата не компенсируется повышением скорости?

Затраты растут, но мы ожидаем, что и прибыль вырастет – благодаря тому, что мы делаем быстрее и больше, фокусируемся на удовлетворении потребностей клиентов. Когда целями являются time-to-market, клиентский опыт (customer experience) и повышение индекса потребительской лояльности (net promoter score, NPS), то аргумент «дорого» отходит на второй план.

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

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

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

– Сколько у вас команд сейчас и сколько предполагается в будущем?

Раньше у нас была одна команда из 50 человек и псевдогибкость – релизы мы выдавали не чаще раза в месяц. Теперь ее разбили на 10 команд поменьше, убрали очередь заказчиков. Сервисных команд сейчас 25, а продуктовых будет не менее 50.

– Внедрить гибкий подход вы пытались неоднократно. Когда наступил переломный момент?

До 2013 года предпринимались попытки внедрить аgile «снизу вверх», а в 2014-2015 годах – привнести его извне. В 2016 году председатель правления банка вышел на совет директоров и сказал, что хочет построить agile-организацию. C тех пор все изменилось, agile-команда стала не айтишной, а полнофункциональной, в нее вошли управляющие директора, которые отвечают за кредитные и некредитные продукты в ретейле. Они почувствовали все преимущества гибкости и теперь сами ее хотят. Поменялось и то, как мы внедряем agile. Мы внедряем его не по плану, а по Scrum.

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

В связи с этим возникает множество вопросов. Как работают проекты? Какие нужны метрики? Как меняется роль топ-менеджеров?

– На каких проектах происходило внедрение agile?

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

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

Когда CPO (Chief Product Owner) это попробовал, то стал самым главным поборником всей этой истории, потому что понимает, чем заняты его сотрудники каждый день, почему это столько стоит, и отдачу начинает получать через месяц. Мы быстро тестируем идеи и начинаем зарабатывать сразу. А если это не нужно, то понимаем это не через три года, а через месяц и перестаем тратить деньги.

– В перспективе вы откажетесь от проектного управления или будете комбинировать его с agile? Какие ограничения agile вы видите?

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

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

– Банк по сути жесткая структура, как он может быть agile? Как можно сочетать жесткость и гибкость?

Сочетать можно и нужно. Да, мы зарегулированы, однако регуляторные требования и групповые стандарты, которые нельзя нарушать для процессов планирования, бюджетирования, практически не имеют отношения к разработке продуктов, если мы не нарушаем базовых правил, типа обработки персональных данных. Поэтому Scrum тут вполне применим. Однако Scrum, родившийся в стартапах, где возможно все, в нашем случае, образно говоря, помещается в «контейнер» из стандартов, и градус свободы для Product Owner’a (ответственного за продукт) снижается.

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

– Помимо поддержки руководителя компании, какие еще условия должны выполняться, чтобы agile был эффективен?

Без поддержки руководства трансформация просто невозможна. И вся корпоративная бюрократия должна ее поддерживать. Корпоративные ценности должны соответствовать agile, а если не соответствуют, то их надо менять.

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

Cистема корпоративного обучения также подвергается изменениям, особенно если она была построена на таких вещах как ITSM или PMBOK.

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

– Что вы посоветуете ИТ-руководителям, которые хотят внедрить agile?

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

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

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

Но, как рассказал технический директор компании Pyramid Analytics по бизнес-анализу Ави Перес, у многих его клиентов озера данных очень быстро превращались в болота – масштабную свалку, совершенно непригодную для конечных пользователей.

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

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

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

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

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

1. Собирайте поменьше данных, по крайней мере на начальном этапе

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

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

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

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

2. Внедряйте машинное обучение

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

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

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

3. Составляйте список задач

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

Допустим, вы представляете крупную розничную сеть и хотите понять, какие покупатели приходят в ваши магазины. Фотографии клиентов можно делать на входе, после чего использовать для обработки полученных изображений сложную нейронную сеть (convoluted neural network, CNN) – разновидность нейронной сети глубинного обучения, прекрасно справляющейся с решением задач компьютерного зрения. CNN способна определять, мужчина изображен на снимке или женщина, ребенок или взрослый, регистрировать одновременно ребенка и взрослого, молодого человека и пожилого и т. д.

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

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

– Thor Olavsrud. 3 keys to keep your data lake from becoming a data swamp. CIO. JUN 8, 2017

Регулирующий акт Евросоюза «Общие положения о защите данных» (General Data Protection Regulation, GDPR) стал одним из самых строгих законов, касающихся защиты персональных данных. Директива вступит в силу 25 мая 2018 года и кардинально изменит способы сбора и использования персональных данных, поэтому европейские (и не только) компании должны полностью пересмотреть свои механизмы обработки клиентской информации. Старый подход «лучше заплатить штраф, чем выполнять требования закона» здесь не работает, поскольку регулирующие органы получат право накладывать крупные штрафы за серьезное нарушение акта — вплоть до 20 млн евро (примерно 1,5 млрд руб.) или 4% годового дохода компании.

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

Как повлияет GDPR на российский бизнес

В связи с экстерриториальностью, акт GDPR создает риск крупных штрафов и для российских компаний. Даже если граждане ЕС не являются клиентами или партнерами бизнеса, автоматический сбор данных (например, cookies) уже считается мониторингом персональной активности. По сути, под регулирование GDPR попадают любые интернет-компании. Сырьевые, крупные промышленные и финансовые компании должны соблюдать GDPR, поскольку имеют филиалы в странах ЕС. Отдельной строкой проходят транспортные компании: РЖД, «Аэрофлот», S7 Airlines и другие, реализующие онлайн-продажи билетов. Такие компании хранят и обрабатывают данные граждан ЕС. Кроме того, регламентированная GDPR обязанность раскрывать информацию о нарушении конфиденциальности может нанести репутации компании не меньший ущерб, чем штрафы.

Какие меры следует предпринять бизнесу

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

Казалось бы, с точки зрения выполнения требований GDPR легче управлять структурированными данными приложений, однако быстрое увеличение числа приложений на крупных предприятиях резко усложняет управление этими данными. К тому же крупные предприятия должны обеспечить соблюдение требований GDPR и для неструктурированных данных, хранящихся на серверах, в системах электронной почты и на клиентских устройствах. Это крайне сложная задача, поскольку почти 80% всех используемых в бизнесе данных приходится на неструктурированные. Возможно ли обеспечить соответствие требованиям GDPR в типичной современной компании, где для управления данными применяются различные, никак не интегрированные между собой продукты? Это трудная задача, но вполне осуществимая.

Единая платформа управления данными – эффективное решение проблемы

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

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

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

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

Использование существующих ИТ-процессов для консолидации данных

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

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

До первого прецедентного случая трудно прогнозировать применение GDPR по отношению к российским компаниям. Ясно одно: защита и менеджмент данных в этом году снова станут ключевым вопросом для ИТ-директоров крупнейших российских компаний.

– Андрей Вышлов, глава представительства Commvault в России

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

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

Рекрутмент – благодатная сфера такого комплексного применения цифрового инструментария. О том, как машинное обучение помогает решать простые, но крайне трудоемкие задачи рекрутинга, директор по развитию компании HeadHunter Борис Вольфсон рассказал на VI Российском форуме Big Data 2017, организованном издательством «Открытые системы». По его словам, математические модели сегодня помогают рекрутерам и заменяют их, а в перспективе будут работать лучше людей.

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

Технология, сберегающая время

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

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

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

Для обучения системы в компании использовали выборку, насчитывающую около 200 млн соискателей и вакансий. На основе уже имеющихся данных о том, каких кандидатов в итоге пригласили на собеседование, система машинного обучения строит «лес» из сотен тысяч «деревьев» решений и с минимальной погрешностью вычисляет среднюю оценку кандидата. Для этого используется градиентный бустинг (gradient boosting) – простой стандартный подход, позволяющий за несколько недель сделать модель, работающую в промышленном масштабе. Полученные модели «весят» около 100 Гбайт, так что, строго говоря, эту работу нельзя назвать анализом Больших Данных, отметил Вольфсон, но при этом данные для рекрутмента требуют быстрой обработки и выдачи результатов в режиме онлайн или близком к нему.

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

Машинным обучением и поиском в HeadHunter занимается команда из десяти человек. Технологически в компании предпочитают опираться на решения open source, используя Linux-системы c веб-интерфейсом и базы данных PostgreSQL. Бэк-офисные системы написаны на языке Java, а функционал фронт-энд-систем – на Python. В качестве основы машинного обучения применяется набор библиотек Boost.

Прескрининг и модерация: вкалывают роботы

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

Чтобы научить систему подтверждать наиболее качественно заполненные резюме, использовалась выборка, включающая почти 40 млн отмодерированных резюме, в том числе отклоненных. Теперь система способна повторять действия модераторов на основании полей в резюме. Например, проверять соответствие должности, на которую претендует кандидат, профессиональным областям, указанным в его резюме. «Чтобы качество базы не упало с запуском сервиса, мы выбрали пороговые уровни полноты и точности контроля, которые соответствуют действиям человека», – сообщил Вольфсон.

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

Машина ищет работу

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

Еще один вариант применения машинного обучения в HeadHunter связан с нуждами тех, кто ищет работу. «Стратегически мы стараемся балансировать интересы соискателя и работодателя», – отметил Вольфсон.

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

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

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

На горизонте – «умный» поиск

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

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

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

Научившись ранжировать отклики, модерировать резюме и строить рекомендательные системы, HeadHunter готовится перейти к следующему этапу – к «умному» поиску на основе машинного обучения и созданию «своего маленького “Яндекса”». «Мы хотим, чтобы наш поиск тоже использовал машинное обучение, и в ближайшее время планируем запустить несколько проектов, ориентированных на эту задачу, – сообщил Вольфсон. – Это наша ключевая компетенция, ее нельзя отдавать на аутсорсинг».

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

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

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

«С начала века это самый масштабный проект информатизации в налоговой сфере, который затрагивает всех участников процесса, включая потребителей, – подчеркнул Владимир Ионкин, заместитель главы Ассоциации компаний розничной торговли (АКОРТ). – Очевидно, что такие масштабные проекты не могут стартовать абсолютно гладко и “приятно” для всех сторон».

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

Прощай, ЭКЛЗ! Здравствуй, дефицит!

С 1 июля 2017 года все кассы вместо электронной контрольной ленты защищенной (ЭКЛЗ) должны содержать фискальный накопитель (ФН) и передавать чеки в ФНС в электронном виде через оператора фискальных данных (ОФД). Однако к середине мая в ФНС было зарегистрировано лишь порядка 420 тыс. кассовых аппаратов, работающих по новым требованиям, – это примерно треть действующей в стране контрольно-кассовой техники (ККТ). По мнению Евы Сызрайской, эксперта компании «СКБ Контур», темпы реформы задерживаются по двум причинам. Во-первых, это привычка малого бизнеса откладывать подготовку к законодательным изменениям до последнего и ждать отсрочек и послаблений. «Такая стратегия предпринимателей объяснима: когда требования законодательства еще четко не обозначены, нет разъяснений ФНС и Минфина к частным случаям применения касс по новому порядку, изымать из оборота деньги на переоснащение ККТ невыгодно, – говорит Сызрайская. – С другой стороны, это создает ажиотаж и приводит к ценовым спекуляциям на рынке».

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

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

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

«До февраля у нас не было возможности подготовиться к переходу и протестировать онлайн-кассы», – отметил Роберт Сардарян, директор по ИТ компании “Кораблик-Р”. – Не было доработанного кассового софта, оборудования и внятных сроков от поставщика кассового решения».

До недавнего времени на рынке был всего один производитель ККТ, затем добавилось несколько аффилированных компаний, но и они не успевают полностью обеспечить потребности в новом оборудовании.

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

«Поставщики не справляются, – подтвердил Ионкин. – Но члены АКОРТ давно уже законтрактовались и планово переходят на новый порядок использования ККТ».

Тем не менее заменить все кассы с ЭКЛЗ, которые c 1 июля налоговая служба снимет с учета, получается не у всех. Cроки поставки фискальных накопителей достигают двух месяцев с момента заказа, и производители ККТ уже продают оборудование без ФН, говорит Сызрайская. Между тем за применение ККТ, не соответствующей требованиям закона, Кодексом об административных правонарушениях РФ предусмотрены предупреждения или штрафы от 5 до 10 тыс. руб., за ненаправление электронного чека – 10 тыс. руб. А штрафы за неприменение ККТ составят 75-100% от суммы расчета для организаций и 25-50% – для должностных лиц. При повторном нарушении компании грозит приостановка деятельности на срок до полутора месяцев.

Учитывая сложившуюся ситуацию, в конце мая Минфин и ФНС выступили с разъяснениями о том, что налоговая не будет штрафовать компании, которые не успеют установить онлайн-кассы в срок при наличии у них договора на поставку фискального накопителя или ККТ нового образца.

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

Плата за онлайн

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

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

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

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

Серьезные расходы понесла и сеть магазинов «Кораблик-Р»: половину кассовых аппаратов пришлось заменить на новые, остальные проходят апгрейд. Как рассказал Сардарян, при этом необходимо было учитывать множество факторов (расположение магазина и налоговой, сроки действия ЭКЛЗ, даты снятия их с учета, логистика накопителей), составлять и контролировать сложный график перехода. «До сих пор не решена проблема, как регистрировать телефон или e-mail в кассовой программе. Думаем над этим», – сообщил он.

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

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

Надежды на прозрачность

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

Вадим Горбунов, ИТ-директор аптечной сети «Ригла»: «Основные трудности перехода: позднее предоставление оборудования, стандартов и тестовых серверов производителями и ОФД»

«В какой-то мере сократился объем требований по физическим визитам в ФНС, и требования по ведению кассовых документов упростились. Да и иметь централизованную копию всех фискальных документов надежнее, чем хранить ЭКЛЗ», – заметил Горбунов.

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

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

«Сейчас в основном преимущества ощущает лишь бизнес, поставляющий решения для новых касс, – полагает Кургузов. – В будущем, когда головная боль закончится, “всплывут” и плюсы – например, отсутствие кассовой книги. Но пока они незаметны».

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

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

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

В ситуации, когда все организации, ведущие расчеты с населением, неизбежно постепенно перейдут на онлайн-кассы, нужно искать дополнительные выгоды для бизнеса, считает Сызрайская. Например, ФЗ-54 требует печатать в чеке наименования всех проданных товаров. Это дает возможность отражать продажи в разрезе каждой товарной позиции в режиме онлайн, что упростит организацию товарного учета. А при своевременном вводе поступлений товаров выстроится система учета товарных остатков, что облегчит инвентаризацию. Сервисы операторов фискальных данных включают новые инструменты для бизнес-аналитики. Например, в «Контур.ОФД» реализован онлайн-мониторинг поступлений и возвратов как в целом по организации, так и в разрезе торговых точек и касс. Можно формировать отчеты за любой произвольный период с наглядными графиками и выгружать их в формате xls.

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

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

Вероятно, это звучит знакомо: облачной инфраструктурой в виде сервиса конечным пользователям тоже управлять не требуется, этим занимаются провайдеры – Amazon Web Services, Microsoft Azure и др. Так называемые бессерверные вычисления развивают эту концепцию: облачные сервисы выполняют код, написанный разработчиками, расходуя ровно столько ресурсов, сколько для этого нужно – ни больше ни меньше. Как только наступает заранее заданное событие, запускающее код, бессерверная платформа выполняет задачу. Конечному пользователю не нужно уведомлять провайдера о том, как часто будут происходить события-триггеры. Каждый раз, когда выполняется функция, заказчик платит доли цента. Некоторые считают, что данную концепцию лучше было бы назвать «функциями в виде сервиса» (functions as a service, FaaS) или «событийно-зависимыми вычислениями».

«Существуют различные уровни абстрагирования инфраструктуры, доступные разработчикам, – объясняет Дэмион Эредиа, вице-президент по управлению облачными продуктами IBM, отвечающий за управление платформой бессерверверных вычислений OpenWhisk. – Это могут быть прямой доступ к аппаратным ресурсам, работа с виртуальными машинами и работа с контейнерами. Для определенных задач мы считаем необходимым полностью абстрагировать функции администрирования, чтобы заказчик мог выполнять свой код, не беспокоясь об инфраструктуре и управлении серверами. В этом и состоит суть «бессерверных» вычислений».

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

Преимущества бессерверных вычислений

Считается, что создателем нового рынка стала компания Amazon Web Services, представившая в 2014 году платформу бессерверных вычислений Lambda. По словам Мэтта Вуда, генерального менеджера AWS по стратегии, новшество было создано по образцу одного из самых популярных продуктов компании – Simple Storage Service, или S3.

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

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

В традиционной облачной среде IaaS пользователи готовят к работе виртуальные машины, хранилища, базы данных, а также инструменты обеспечения безопасности и администрирования. Затем на виртуальные машины загружаются приложения, а для масштабирования ресурсов используются балансировщики нагрузки и другие средства. С помощью административного ПО оптимизируется размер экземпляров и осуществляется поиск виртуальных машин, непреднамеренно оставленных во включенном состоянии. Lambda и другие платформы FaaS предлагают другую модель. Код предоставляется в форме функций. Когда происходит событие, вызывающее такую функцию, Lambda ее выполняет. Больше ничего не требуется – не нужны планирование мощности и балансировка нагрузки, только задания, которые надо выполнять.

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

Еще одна важная область применения – крупномасштабные среды Интернета вещей с мгновенным откликом. Недавно в AWS представили платформу Greengrass, позволяющую выполнять функции Lambda на устройствах без надежных средств связи, когда не всегда есть возможность передать данные в облако. Например, функция Lambda может выполняться непосредственно на камере видеонаблюдения, каждый раз при распознавании движения включая запись и отправляя съемку в базу. Отпадает нужда в виртуальной машине, круглосуточно работающей в ждущем режиме, – событийно-зависимый код выполняется автоматически всякий раз, когда наступает соответствующее событие. В компании FireEye, поставляющей средства сетевой безопасности, признаются, что, благодаря использованию Lambda вместо экземпляров EC2, удалось сократить затраты на виртуальные машины на 80%.

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

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

Недостатки

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

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

Существует и еще одна опасность – это привязка к оператору. Приложение, разработанное для какой-либо FaaS-платформы, не так-то просто перенести на другую – локальную или действующую в публичном облаке. Поскольку рынок еще очень молод, сегодня у каждой бессерверной платформы свой особый набор компонентов. AWS Lambda, в частности, тесно интегрирована со многими другими продуктами AWS. По словам Вуда, поскольку Lambda поддерживает популярные языки программирования, такие как Node.js, Python и Java, в принципе код приложений Lambda можно переносить. «Специального языка для работы с Lambda нет», – подчеркивает Вуд.

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

Рынок бессерверных платформ

После AWS, которая первой предложила платформу бессерверных вычислений, аналоги появились и у других крупных поставщиков инфраструктуры в виде сервиса. По словам Вуда, на самом деле многие сервисы AWS являются «бессерверными» – не только Lambda, но также S3, NoSQL-база DynamoDB и размещаемая реляционная СУБД Aurora. Все эти продукты не требуют от пользователя предварительного планирования расхода ресурсов и администрирования инфраструктуры.

Пользователи Lambda получают до миллиона бесплатно обрабатываемых запросов в месяц, а каждый последующий миллион стоит 20 центов. В AWS тоже взимают плату по тарифу, зависящему от затрат времени на вычисления, – по 0,00001667 долл. в расчете на гигабайт в секунду; время округляется до 0,001 мс.

Аналогичные расценки действуют для сервиса Microsoft Azure Functions, общедоступная версия которого была введена в действие в ноябре прошлого года. Google Functions, в свою очередь, сейчас находится в стадии бета-версии, предлагается до 2 млн бесплатных запросов в месяц. Стоимость выполнения одной транзакции в Google Functions чуть выше, а тарифы на время обработки ниже. В IBM не публикуют расценки на пользование OpenWhisk. По словам топ-менеджеров, отличительная особенность платформы бессерверных вычислений IBM – разработка в открытых кодах в качестве проекта Apache Software Foundation. Теоретически заказчикам дается возможность выполнять код OpenWhisk где угодно.

Еще есть ряд стартапов, предлагающих платформы бессерверных вычислений, а также их компоненты и административные инструменты. В качестве примера можно привести компанию Iron.io, которая предлагает соответствующий сервис на основе контейнеров Docker.

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

– Brandon Butler. Serverless explainer: The next generation of cloud infrastructure. Network World. April 3, 2017

Для поддержки полумиллиарда пользователей LinkedIn по всему миру требуются немалые вычислительные мощности, особенно если учесть, что каждому из них нужны персональные настройки с выдачей веб-страницы, на которой присутствуют только его контакты. Сегодня социальную сеть обслуживают свыше 100 тыс. серверов, распределенных между несколькими ЦОДами. Чтобы поближе познакомиться с тем, как LinkedIn справляется со всем этим, главный редактор журнала Network World Джон Дикс побеседовал с вице-президентом LinkedIn по производственным операциям и ИТ Сону Навьяром и старшим директором компании по проектированию инфраструктуры Саидом Али Каном.

Давайте начнем с общей картины того, что имеется в ваших ЦОДах, развернутых в разных странах.

Навьяр: Сайт LinkedIn.com в глобальном масштабе обслуживается тремя ЦОДами, которые расположены в США: в Ричардсоне (штат Техас), в Эшберне (Вирджиния) и в только что открытом ЦОДе в штате Орегон. Еще у нас есть небольшой ЦОД в Сингапуре, запущенный в эксплуатацию в начале нынешнего года. Главное его предназначение – улучшение обслуживания наших пользователей в Юго-Восточной Азии. Все четыре ЦОДа подключены к магистрали MPLS и к 13 глобальным точкам присутствия.

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

Сону Навьяр, вице-президент LinkedIn по производственным операциям и ИТ

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

Кан: Переход к оптовой модели начался с самого первого ЦОДа в Вирджинии. Вместо того чтобы обращаться к розничным поставщикам вычислительных мощностей наподобие Equinix, мы просто арендовали для ЦОДа пространство – большое пустое сооружение – и начали оборудовать его внутри самостоятельно, размещая там средства энергоснабжения, кабели, стойки и все прочее. Затем еще один ЦОД был построен в Техасе – развитие шло очень быстрыми темпами. Когда подошел черед строительства в Орегоне, мы проанализировали накопленный опыт и задумались, как будут выглядеть наши ЦОДы в будущем. Именно тогда и произошел переход к модели гипермасштабирования. Двигаясь дальше, мы намерены модифицировать все прочие ЦОДы в соответствии с новой моделью.

Значит, вы не собираетесь, подобно некоторым веб-гигантам, создавать свои собственные серверы?

Кан: Нет. Мы используем отдельные серверы, монтируемые в стойке. И поддерживаем тесные отношения с теми поставщиками OEM-оборудования, которые предлагают продукты, отвечающие нашим требованиям к производительности и т. д. Наша компания была одним из первых крупных пользователей систем Cisco UCS, но в последнее время мы больше склоняемся к стандартному оборудованию Supermicro.

А ваши собственные бизнес-потребности удовлетворяются тоже в этих ЦОДах?

Навьяр: У нас практикуется гибридный подход. Для хранения корпоративных ресурсов – службы персонала, финансовой службы, отделов разработки, предпродажной обработки и пр. – есть небольшой ЦОД в Санта-Кларе. Но после завершения строительства в Орегоне мы стали использовать зоны безопасности, позволяющие обслуживать корпоративные нужды в любом из имеющихся ЦОДов.

Как выглядит клиентское приложение LinkedIn?

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

Это впечатляет...

Навьяр: В нашем приложении все взаимосвязано. Естественно, некоторые части сайта разделены. Например, модуль Recruiter имеет другой интерфейс. Но для типичного потребителя в LinkedIn.com все взаимосвязано.

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

Каждый из ваших ЦОДов поддерживает одни и те же функции или же задачи распределены между ними?

Навьяр: Трафик может обслуживаться в любом месте. Если в каком-то ЦОДе происходит сбой, мы просто перенаправляем трафик на другую площадку. Между всеми ЦОДами осуществляется в реальном времени репликация по магистрали MPLS с пропускной способностью 100 Гбит/с. ЦОДы обслуживают одинаковые запросы – таким образом повышается уровень готовности. Если один из сайтов отключается (из-за ошибки в программе, сетевых проблем, сбоев питания и даже неправильно внесенных изменений), мы можем легко восстановить работоспособность в течение пяти минут. Все компоненты взаимодействуют друг с другом, обслуживая LinkedIn.com.

Пользователи обслуживаются по географическим регионам?

Саид Али Кан, старший директор LinkedIn по проектированию инфраструктуры

Кан: Да. Мы активно используем возможности Anycast, переходя к нужному IP-адресу кратчайшим путем. Таким образом наши пользователи соединяются с ближайшей точкой присутствия.

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

Кан: Положение точки присутствия выбирается с учетом пользовательского контекста. Мы знаем, из каких географических областей приходят запросы. Для упреждающего анализа мы используем модель, в которой применяем науку о данных. Она показывает, к примеру, что при выборе точки присутствия в Австралии время загрузки страницы сокращается на такой-то процент. С учетом полученной информации мы строим точку присутствия в указанной области и связываем ее с нашими ЦОДами. Запросы на загрузку страниц сначала обрабатываются в точке присутствия, а затем уже пересылаются в основные ЦОДы. Наличие точек присутствия помогает загружать страницы быстрее. А размещение точки присутствия в Азии помогло нам улучшить загрузку страниц на 25%.

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

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

Кан: Плотность размещения вычислительных мощностей здесь заметно выросла. Как правило, одна стойка потребляет 7-9 кВт. Но из-за ограниченного пространства нам пришлось размещать в каждой стойке гораздо больше серверов. В результате уровень энергопотребления стал превышать 14 кВт на стойку. При повышении плотности размещения оборудования растет и тепловыделение, поэтому понадобилось заново проектировать всю систему охлаждения ЦОДа. Отвод тепла теперь осуществляется через заднюю дверь. Одними из первых мы стали применять жидкостное охлаждение стойки. Конечно, на это нужны дополнительные капиталовложения, но со временем они окупаются вследствие сокращения энергопотребления.

Так вы прокачиваете через стойки воду?

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

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

Насколько надежна прокачка воды между всеми этими системами? Вас этот вопрос беспокоит?

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

Охлаждение воды с помощью внешнего воздуха должно быть достаточно эффективным. Какова эффективность энергопотребления (Power Usage Effectiveness, PUE) у ЦОДа в Орегоне?

Навьяр: Коэффициент PUE равен 1,06. И это стоит того, если учесть, что в перспективе наша цель заключается в полном переходе на экологически чистые источники энергии. Правда, пока цель эта не достигнута, но мы стремимся к ней и во многом поэтому выбрали в Орегоне технопарк Infomart, поскольку у них есть непосредственный доступ к возобновляемым источникам энергии. (Одним из преимуществ площадки, которая была выбрана для размещения нового ЦОДа, является то, что это место позволяет использовать технологию охлаждения серверов наружным воздухом большую часть года, тем самым снижая общее потребление электроэнергии.)

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

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

Кан: Да. Проект Altair – это одно большое коммутационное решение. Его можно представить в виде большой одноуровневой сети. Здесь нет ядра, нет шасси. Представьте, что вы объединяете более 100 тыс. серверов с использованием традиционной корпоративной модели. Пакет, проходящий от одного сервера до другого, преодолевает 25-30 чипсетов и достигает цели с задержкой, измеряемой в миллисекундах. Мы сократили число промежуточных чипсетов до пяти, используя пятиярусную архитектуру Клоза Leaf-Spine, и это позволило уменьшить задержки при коммутации двух серверов до нескольких микросекунд (см. рис. 1).

В топологии Leaf-Spine все разбивается на несколько ярусов. У каждого коммутатора, смонтированного сверху стойки, есть четыре маршрута к Spine-коммутаторам, а они, в свою очередь, связываются несколькими путями с коммутаторами, расположенными над ними. Таким образом, все Spine-коммутаторы образуют одну большую коммутирующую структуру. У каждого из коммутаторов, находящихся сверху стойки, имеется четыре и более равноудаленных маршрутов ECMP (equal-cost multi-path) (см. рис. 2).

В качестве коммутаторов в верхней части стойки и Spine-коммутаторов используются одинаковые устройства?

Кан: Да, они абсолютно одинаковы. Мы перешли на единую модель учетных единиц и покупаем коммутаторы только одного типа высотой 1U.

Вы получаете все коммутаторы от одного поставщика?

Кан: Нет. Речь идет об одной платформе. Все они имеют одинаковую архитектуру и одинаковый чипсет. Одна учетная единица. У вас может быть множество поставщиков, но при этом одна платформа. Мы используем чипсет Tomahawk и 32 порта 100 Gigabit с общей пропускной способностью 3,2 Тбит/с. Канал шириной 50 Гбит/с подключается к серверам, которые могут отличаться друг от друга. Мы стали первыми, кто подает на каждый сервер поток в 10, 25 или 50, а в перспективе даже в 100 Гбит/с. И этого должно быть вполне достаточно на ближайшие четыре года, а может быть, и больше.

Все Spine-коммутаторы являются неблокируемыми, а значит, при наличии входящего 100-гигабитного канала вы всегда получаете точно такой же исходящий канал. От коммутатора вниз спускаются 50-гигабитные каналы, соответствующие стандарту PSM4. Благодаря такому решению можно взять два 100-гигабитных порта и разделить их на четыре 50-гигабитных, обеспечив эффективную пропускную способность шкафа в 200 Гбит/с.

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

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

Правильно ли я понимаю, что на коммутаторах, смонтированных в верхней части стоек, выполняется ваш собственный программный код?

Кан: На некоторых из них. Мы используем как OEM-решения (Original Equipment Manufacturer – оборудование, продаваемое компанией под своим именем и брендом, но сделанное другими предприятиями), так и оборудование собственной разработки (ODM, Original Design Manufacturer). К OEM относятся поставщики наподобие Cisco. А на оборудовании ODM выполняется наш собственный код, и мы постепенно внедряем новые мощности, монтируя новые шкафы и развертывая новые наборы баз данных.

А почему вы разрабатываете свой собственный программный код?

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

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

Понятно. И вы поддерживаете IPv4 и v6, стремясь к повсеместному переходу на v6?

Кан: Да, на фронте v6 мы выступаем весьма активно. Несколько лет назад решено было запустить версию сайта www.linkedin.com на IPv6, с тем чтобы продолжать работу и после того, как неизбежно будут исчерпаны адреса IPv4. Мы начали с периферии и стремимся охватить рынки, оперирующие исключительно трафиком IPv6. Существенный рост использования IPv6 наблюдался в мобильном трафике. Кроме того, нам удалось добиться определенного увеличения производительности. По мере роста масштабов протокол IPv6 стал использоваться и внутри ЦОДов. В настоящее время стек v4 и v6 дублируется, но через пару лет мы планируем полностью перейти на v6.

Какова общая мощность ваших ЦОДов и как вы намерены развиваться дальше?

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

Ваша компания известна как крупный представитель сообщества open source. Какова ваша политика в этой области и в чем вы видите смысл участия в продвижении открытых платформ?

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

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

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

Помимо существенной экономии капитальных затрат, Open19 поможет интегрировать стойки в два-три раза быстрее. Если у вас имеются совместно используемые блоки питания и сетевые компоненты, прокладывать громоздкие кабели уже не потребуется. Мы поддерживаем отношения со многими поставщиками OEM и ODM. Для них это выгодно, поскольку, перейдя на новый стандарт и сохраняя при этом свою интеллектуальную собственность, они придают своей перспективной базе гораздо более высокую гибкость.

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

– John Dix. Network World. LinkedIn pumps water down to its server racks, uses an interesting spine and leaf network fabric January 24, 2017