Самое интересное

Выступление Антона Исанина, руководителя центра качества «Альфа-Банка», набрало максимальное число позитивных отзывов участников конференции «Agile, DevOps и ITIL – инструменты цифровизации», проведенной издательством «Открытые системы». Сокращение вывода новых продуктов на рынок до пяти дней с помощью подходов DevOps – результат, заслуживающий уважения.

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

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

Успеть за возможностями

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

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

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

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

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

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

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

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

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

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

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

Необходимо создать цельные независимые продуктовые команды с полноценным сопровождением. Это важный вопрос: DevOps подразумевает не только совместную работу различных администраторов в agile-командах; вместе со специалистом в команду «переезжает» и ответственность, а за стабильность продукта отвечает его владелец. Кроме того, в команду уходят второй и третий уровни поддержки.

Мельче, но быстрее

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

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

В «Альфа-Банке» автоматизация процессов разработки была начата с процессов тестирования.

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

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

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

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

Если вы полагаете, что 2017 год был весьма неблагоприятным с точки зрения появления брешей в системах защиты данных, дождитесь наступления 2018-го. Information Security Forum (ISF), глобальная независимая ассоциация информационной безопасности, нацеленная на обеспечение кибербезопасности и управление информационными рисками, прогнозирует увеличение числа таких брешей. И связано это будет главным образом с пятью глобальными угрозами системам безопасности, с которыми организациям предстоит столкнуться в 2018 году.

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

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

Усиление наметившихся тенденций будет сопровождаться ростом пяти основных глобальных угроз системам безопасности, с которыми компаниям предстоит столкнуться в 2018 году:

• преступления, предлагаемые в качестве сервиса (crime-as-a-service, CaaS), расширят набор доступных криминалу инструментов и сервисов;
• Интернет вещей добавит неуправляемые риски;
• цепочки поставок останутся слабейшим местом в управлении рисками;
• дополнительное регулирование усложнит управление критически важными активами;
• неоправдавшиеся ожидания руководства будут подкрепляться многочисленными инцидентами.

Преступление как сервис

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

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

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

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

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

Интернет вещей

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

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

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

Цепочки поставок

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

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

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

Регулирование

Регулирование добавляет сложностей, и принятие Европейским союзом в начале 2018 года закона о защите данных General Data Protection Regulation (GDPR) приведет к появлению еще одного уровня сложности в управлении критически важными активами.

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

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

Неоправдавшиеся ожидания руководства

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

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

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

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

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

– Thor Olavsrud. 5 information security threats that will dominate 2018. CIO. NOV 20, 2017

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

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

1. Переход в облако при отсутствии стратегии руководства и планирования

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

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

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

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

2. Вера в то, что в облако можно перенести любые системы

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

Определитесь, чего вы хотите добиться переносом тех или иных систем в облако, и оцените, реально ли это.

3. Отношение к облаку как к своему центру обработки данных

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

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

4. Уверенность в том, что весь груз ответственности лежит на провайдере

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

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

5. Уверенность, что любые приложения можно перенести в облако без изменений

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

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

6. Отказ от мониторинга производительности сервисов

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

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

7. Предположение, что персонал ИТ-службы легко справится с переходом в облако

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

Незнание особенностей облака может легко привести к катастрофе с точки зрения безопасности.

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

8. Слепое доверие скриптам автоматизации

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

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

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

9. Вера в то, что безопасность – больше не ваша проблема

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

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

10. Пренебрежение планированием обеспечения непрерывности бизнеса и аварийного восстановления

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

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

***

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

– John Edwards. 10 cloud mistakes that can sink your business. CIO. NOV 14, 2017

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

Значительному числу организаций не удается провести преобразования правильно из-за фундаментального непонимания того, что на самом деле представляет собой цифровая трансформация.

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

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

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

1. Цифровая трансформация – это на самом деле трансформация человека

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

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

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

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

Этот сдвиг мышления помог компании совершить рывок вперед. «За прошедшие 10 лет мы сделали 80 приобретений, смогли укрепить связи, сформировать новые взаимоотношения и добиться того, чтобы сотрудники получше узнали друг друга», – отметил Фейруэзер.

2. Придерживайтесь ориентированного на клиентов подхода

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

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

Прежде всего они ориентируются на клиентское восприятие.

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

3. Формируйте новые команды

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

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

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

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

Аналогичного подхода придерживаются и в компании – поставщике сельскохозяйственного оборудования John Deere, где руководство составило план реализации перспективного проекта умного подключенного предприятия. На одной из фабрик компании было организовано пространство Foundry площадью 650 квадратных метров с более низкими, чем обычно, столами, с тем чтобы людям удобнее было общаться. Там предполагалось собирать новые команды и изучать agile-методологии при содействии экспертов, которые проводили бы сотрудников через полный цикл разработки.

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

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

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

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

4. В процессе внедрения технологий укрепляйте взаимодействие

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

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

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

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

5. Когда дело касается изменений, будьте непримиримы

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

«Конечно, у нас были скептики, – заметила вице-президент GE Commercial и подключенной цифровой экосистемы digitalTHREAD Кейт Гутовски. – Но, если мы нацелились провести какие-то преобразования, равняться на таких людей не стоит».

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

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

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

6. Вырабатывайте менталитет стартапа

В 2014 году к купленному AT&T оператору добавилась вновь приобретенная компания Cricket Wireless. Две конкурировавшие друг с другом организации требовалось преобразовать в единого крупного игрока национального масштаба.

Подобно John Deere и CarMax, Cricket Wireless взяла на вооружение модель Agile. Все силы были приложены к тому, чтобы действовать быстро и добросовестно.

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

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

7. Добивайтесь от руководства дополнительных полномочий

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

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

После этого Джаярам пошел к руководству и представил план интеллектуального подключения и agile-методологии.

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

– Esther Shein. 7 habits of highly effective digital transformations. CIO. November 6, 2017

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

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

Зачем «Росэнергоатому» понадобились изменения?

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

Сергей Мигалин Послужной список: 2015 – настоящее время  Заместитель генерального директора, директор по экономике и финансам АО «Концерн “Росэнергоатом”» 2014 – 2015 Финансовый директор ОАО «Атомредметзолото» 2013 Первый заместитель генерального директора ФГУП «Федеральный центр ядерной и радиационной безопасности» 2008 – 2013 Работа в ТВЭЛ, должности от заместителя главного бухгалтера до вице-президента по экономике и финансам Образование: 1994 – Московский государственный технический университет им. Н.Э. Баумана, специальность «радиоэлектронные устройства и системы» 2001 – Финансовая академия при Правительстве Российской Федерации, специальность «бухгалтерский учет и аудит» Фото: «Росэнергоатом»

Почему вы говорите именно о цифровой трансформации, что подразумеваете под ней?

Сейчас цифровой трансформацией многие называют все, что связано с ИТ и автоматизацией. Возможно, в какой-то степени это и оправданно, но мы четко выделяем в этом процессе три направления.

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

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

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

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

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

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

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

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

«В “Росэнергоатоме” простой только одного крупного энергоблока последнего поколения обходится более чем в 1 млн долл. в сутки. Цена вопроса – критическая»

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

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

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

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

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

В чем роль SAP? Это просто платформа или нечто большее?

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

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

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

Наконец, приходилось думать об интеграции с системами других подразделений «Росатома», поскольку уже есть несколько крупных решений, построенных на платформе SAP, – в самой госкорпорации, в топливном дивизионе и не только.

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

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

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

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

Сергей Мигалин, заместитель генерального директора, директор по экономике и финансам АО «Концерн “Росэнергоатом”»: «Культурная трансформация коллектива, его взглядов на то, что такое электронное управление бизнесом, зачем это надо и что в результате будет получено, – самая большая сложность» Фото: «Росэнергоатом»

Что оказалось самым сложным?

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

Чего проект уже позволил добиться и какие эффекты ожидаются в будущем?

Многие, внедряя ERP, говорят вполне понятные и очевидные вещи – например, касающиеся сокращения запасов и повышения их оборачиваемости. У нас это тоже было так.

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

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

Крайне важно еще и то, что удалось обойтись без административного давления сверху и вовлечь сами станции в процесс обмена опытом. Благодаря этому только за 2016 год мы сэкономили более 3 млрд руб. Эта сумма несопоставима с затратами на внедрение ERP – за один год система окупилась несколько раз.

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

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

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

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

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

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

Вы смирились с тем, что пока не получается?

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

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

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

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

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

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

Андрей Заварзин Возраст: 39 лет Послужной список: 2016 – настоящее время Сбербанк, директор дивизиона «Массовая персонализация» 2012 – 2016 Сбербанк, СТО/CIO различных направлений 2010 – 2012 «Альфа-Банк», директор дирекции Business Intelligence 2008 – 2010 Авиахолдинг «Волга-Днепр», директор по ИТ 2004 – 2008 «ЛУКОЙЛ-Информ», советник генерального директора 1999 – 2004 Академия ФСБ, преподаватель факультета прикладной математики Образование: Академия ФСБ, ИКСИ («прикладная математика») РЭА им. Плеханова («стратегический менеджмент») Финансовая академия при Правительстве РФ. Бизнес-школа

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

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

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

В дальнейшем я был назначен CIO всех обеспечивающих блоков – к операционному блоку прибавились безопасность, управление кадрами, стратегия. Мы выстраивали процессы не только развития, но и сопровождения, заключали соглашения об уровне обслуживания (SLA). Эта модель тоже «взлетела», и мы пошли дальше – ввели должность Chief Technology Officer. Произошло создание блока «Технологии» на базе блока ИТ и операционного блока, а СТО стал отвечать не только за ИТ, но и за операционную деятельность, одновременно накапливая ресурсы и экспертизу по сквозным бизнес-процессам. Так я стал СТО розничного бизнеса. Чтобы решать задачи, я мог внедрять ИТ или ручные процессы, балансируя скорость, стоимость и качество. По задумке, СТО должен был стать чуть ли не вторым человеком в бизнесе, так как глубоко понимал процессную составляющую всех направлений.

И здесь пришел Agile – пришел весьма стремительно. В январе 2016-го мы первый раз съездили с референс-визитом в голландский финансовый конгломерат ING, а уже в сентябре 2016 года Герман Оскарович дал старт Agile в новом офисе на Кутузовском (мы этот офис называем Agile home). Идея, что бизнес на самом деле и есть ИТ (и наоборот), означала, что все действующие лица должны перемешаться. И в такой модели роли CIO или CТO уже не требовалось. Для меня это стало не угрозой для карьеры, а новой возможностью. Я получил новое назначение – возглавил дивизион «Массовая персонализация», который отвечает за розничные данные, моделирование, персональные предложения во всех каналах, вторичные продажи и телемаркетинг. На мой взгляд, это самая интересная область бизнеса.

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

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

Правомерно ли говорить о цифровой трансформации организации без изменения ее бизнес-модели?

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

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

Что касается мобильных приложений, то они, я считаю, в традиционном виде будут постепенно умирать. Клиенты все больше предпочитают взаимодействовать с виртуальным ассистентом, а не самостоятельно вносить данные. Если раньше у нас был лозунг Mobile first, то теперь – Artificial Intelligence first, и все, что мы делаем, должно восприниматься через призму анализа данных. Тенденция очевидна: все большая доля поисковых запросов в Google происходит посредством голоса, и дальше она будет расти как снежный ком. Пока виртуальные помощники, конечно, «сырые», но развиваются очень быстро.

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

Скорее, речь нужно вести о результате. Этот подход позволяет добиться того, что нужно. Заметьте, не «того, что хотели», а «того, что на самом деле нужно», так как изначальная цель вполне может в ходе проекта поменяться. Однако не менее важны культурные изменения в работе.

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

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

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

Неужели всё так просто – сели вместе и начали «получать удовольствие»? Не все к этому бывают готовы. И как быть с раздуванием штата? Для организации такого масштаба это критично...

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

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

Если говорить о более низком уровне, то где-то получилось перестроиться сразу, где-то нет. Я уже полгода пытаюсь решить задачу, как подружить в рамках единой команды исследователей данных, CRM-менеджеров и людей, занимающихся маркетинговыми кампаниями. Они не очень-то доверяют друг другу. Готовлю их, чтобы избежать потрясений, показываю плюсы и минусы. Для этого я использую институт agile-коучей, часто работающих как психологи. Они следят за климатом и помогают правильно скомбинировать людей.

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

Какие эффекты и последствия имело слияние ИТ с бизнесом?

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

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

ITSM – это именно про надежность и стабильность работы. Сейчас часть функций, отвечающих за это, перенесена в agile-команды. Мы, проверяя себя, задавали вопрос, кто пойдет «на ковер» в голландский парламент (у ING, как и у Сбербанка, около 50% доли местного рынка), если случится простой системы, – ИТ-директор или кто-то другой. Как выяснилось, ответственность лежит на руководителе, контролирующем продукт, – это product owner, central product owner или лидер трайба (трайбы – названия подразделений в методологии Agile. – Прим. ред.). Это особенность культуры – больше нет конфликта между развитием и сопровождением систем, жестких границ и непримиримых позиций. Есть команда, которая сама решает свои проблемы и, естественно, проблемы клиентов.

Фото: Сбербанк

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

Agile и ITSM вовсе не являются конкурентами. Совершенно не нужно их противопоставлять, надо брать из каждой модели лучшее и комбинировать, важно уйти от поклонения какой-либо одной методологии. Да, ITSM изначально фокусируется на эксплуатации систем (Run), а Agile – на изменениях (Change), но в современном мире Run становится частью Change.

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

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

Я пришел в «Альфа-Банк» руководить дирекцией Business Intelligence – это была очередная попытка уйти из ИТ. Весь банк с недоверием относился к той информации и отчетности, которую выпускала наша дирекция. Финансовые директора блоков говорили, что не могут управлять бизнесом. Например, невозможно мотивировать клиентских менеджеров на продажи, если результат не соответствует реальности. Такие недоверие и недовольство отражали объективное положение дел, но в каждом случае были очень субъективными. Претензии к отчетности предъявляли телефонными звонками, гневными письмами и т. д. Я перевел все претензии к отчетности в службу поддержки и создал соответствующую группу разбора. Через пару месяцев мы точно знали, в каких строках отчетности содержатся ошибки, каковы причины этих ошибок, кто из людей находит реальные ошибки, а кто «спамит» и перекладывает на других ответственность за свои плохие продажи. Я с удивлением увидел, что самые большие ошибки дают не технологии, а сбои на стыках процессов. Через полгода ситуацию удалось полностью выправить. Я не слышал до этого, чтобы кто-то применил ITSM для выпуска управленческой отчетности.

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

Про agile-трансформацию, начатую в 2016 году, слышали все. А с марта 2017 года наступила ее вторая, менее разрекламированная стадия – переход на DevOps. Что реально изменилось?

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

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

Андрей Заварзин, директор дивизиона «Массовая персонализация» Сбербанка: «У меня на протяжении долгих лет был личный кабинет, а сейчас я сижу в открытом пространстве в шумоподавляющих наушниках»

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

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

Итак, ITSM в бизнесе – уже пройденный этап, его эффективность доказана. А DevOps в бизнесе?

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

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

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

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

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

Предприятия общественного питания, розничная торговля и авиакомпании внедряют чатботов, способных общаться с клиентами так, как это делают живые сотрудники. По заявлениям IBM, платформа искусственного интеллекта Watson поможет вылечить рак (пока, впрочем, особых успехов нет, если судить по сообщениям в СМИ). Гигант сельскохозяйственного машиностроения Deere & Company приобрел за 305 млн долл. стартап Blue River Technologies, выпускающий оборудование для «умной» мелиорации, в котором задействовано машинное обучение. В Uber, невзирая на все юридические скандалы последнего времени, рассказывают о Michelangelo – внутренней платформе искусственного интеллекта в виде сервиса, которая, как заявляют в компании, «демократизирует машинное обучение, делая масштабирование искусственного интеллекта в зависимости от потребностей бизнеса столь же простым, как заказ такси».

Но, как это часто бывает, шумиха так и остается шумихой. В большинстве компаний ожидания очень сильно отличаются от реальности, и это подтверждают свежие данные MIT Sloan Management Review и The Boston Consulting Group, полученные по результатам опроса свыше 3 тыс. руководителей в различных странах мира. Лишь 20% топ-менеджеров сообщили, что в их компаниях внедрили какие-либо средства искусственного интеллекта, и меньше чем у 39% есть конкретная соответствующая стратегия. При этом 85% руководителей убеждены в том, что искусственный интеллект поможет их компаниям приобрести или сохранить конкурентное преимущество.

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

Ставка на углубленный анализ клиентуры

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

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

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

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

Машинное обучение избавляет от рутины

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

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

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

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

Искусственный интеллект как фактор развития продуктов и бизнеса

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

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

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

– Clint Boulton. 3 machine learning success stories: An inside look. CIO. SEP 19, 2017

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

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

Кстати, в IBM открещиваются от использования общепризнанного термина Artificial Intelligence («искусственный интеллект») для расшифровки аббревиатуры AI и предпочитают использовать формулировку Augmented Intelligence («расширенный интеллект»), а еще чаще – «когнитивные системы». Дело в том, что искусственный интеллект имеет некоторые (но не все) характеристики когнитивных систем. Когнитивные системы стали шире, так как появились технологии, позволяющие придать им характеристики, которыми человек никогда не обладал.

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

Показателен срез бизнес-сообщества по отношению к когнитивным системам, приведенный Олегом Бяховым, директором по государственным программам и развитию IBM в России и СНГ. Исследование, проведенное IBM Institute of Business Value, выявило четыре архетипа руководителей в зависимости от их отношения к когнитивным системам. Больше трети составляют категорию «наблюдателей», по той или иной причине игнорирующих возможности когнитивных систем и не планирующих инвестиции в них.

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

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

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

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

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

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

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

Переход на SaaS

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

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

Четыре вопроса, которыми нужно задаться при оценке поставщиков SaaS

1. Действительно ли это SaaS?

Загляните «под капот» и выясните, является ли предлагаемое решение платформой, разработанной на единой кодовой базе, или это набор локальных систем, которые разместили в облаке и снабдили общим пользовательским интерфейсом.

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

2. Как компания развивает свое решение?

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

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

3. Как осуществляются доставка обновлений и техническая поддержка?

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

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

4. Налажено ли взаимодействие с высшим руководством компании?

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

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

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

– Martha Heller. How to select a SaaS vendor. CIO. OCT 18, 2017

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

«Мы рассматриваем все возможности, но используем те, которые считаем реализуемыми – желательно быстро, недорого и с нужной степенью эффективности», – говорит Павел Гурин, советник председателя правления «Почта Банка».

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

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

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

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

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

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

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

Дисциплинирующий эффект

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

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

Павел Гурин, советник председателя правления «Почта Банка»: «Технологии распознавания лиц за последние несколько лет прошли достаточно большой путь с точки зрения качества работы. Стало возможным надежное распознавание женщин с “боевым” макияжем, а также людей, меняющихся с возрастом, полнеющих или, наоборот, худеющих»

«Когда мы провели первый анализ своей базы клиентов, которых фотографировали на протяжении нескольких лет, обнаружили там фотографии Бреда Питта и прочих знаменитостей, животных, пальм и стульев», – рассказывает Гурин. Поскольку у банка 4,5 млн клиентов, а за время работы обрабатывались заявки гораздо большего числа людей, это неудивительно. Очевидно, что в отсутствие эффективного контроля правила оформления кредитных заявок грубо нарушались. Сейчас с подобной недобросовестностью сотрудников удается бороться.

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

«На пилотном этапе, в первое время после запуска процедуры распознавания, было очень много случаев, когда обнаруживались похожие лица у разных клиентов, – говорит Гурин. – Когда банк официально объявил о наличии системы биометрической идентификации, инцидентов стало намного меньше, и сейчас можно сказать, что число пойманных за руку людей относительно невелико». За 2016 год система обнаружила 4,5 тыс. повторно используемых фотографий, и выдача по ним новых кредитов не была допущена. Было отловлено 9,2 тыс. явно мошеннических заявок, когда за кредитом приходил неизвестный банку человек и предъявлял паспорт, уже имевшийся в банковской базе. Предотвращено сомнительных операций на общую сумму 1,5 млрд руб. Хотя справедливости ради следует отметить, что наверняка не все из них в итоге закончились бы потерей денег.

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

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

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