Статьи

Если вы полагаете, что 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

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

А как обстоят дела по другую сторону баррикад? О тенденциях применения искусственного интеллекта в сфере информационной безопасности рассказывает Илья Медведовский, генеральный директор Digital Security.

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

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

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

– В чем вы видите наиболее критичные проблемы? Что может стать барьерами для использования ИИ в безопасности?

О чем сегодня точно стоит задуматься, так это о том, что ИИ на данный момент может быть крайне полезен именно для нападения. Искусственный интеллект практически идеально может быть применен злоумышленниками при использовании социальной инженерии. Когда дело касается информационной безопасности, никого не устроит точность обнаружения в 50% или даже 60%. А вот в социальной инженерии поднять вероятность успеха на несколько процентов – это прекрасный результат. Другое дело, что ИИ здесь имеет смысл применять только на «больших числах» – то есть не при целевых, а при массовых атаках, а значит, компании могут спать относительно спокойно.

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

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

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

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

В докладе 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

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

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

Что представляет собой DevOps?

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

Путь к DevOps

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

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

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

1. Подготовка к культурным переменам

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

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

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

2. Формирование процесса непрерывной интеграции, платформы непрерывного предоставления

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

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

Вот как это работает:

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

3. Создание среды непрерывного тестирования

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

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

К непрерывному тестированию применимы следующие рекомендации:

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

4. Внедрение системы непрерывного развертывания

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

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

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

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

5. Использование нового и старого развертывания

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

6. Непрерывный мониторинг производительности

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

1. Циклы разработки. Чтобы иметь представление о функционировании конвейера автоматического развертывания, следите за тем, как часто в код вносятся изменения, сколько новых функций реализовано, какое количество ошибок обнаружено и исправлено и т. д.
2. Развертывание. Если процедура автоматического развертывания завершается неудачей, нужен инструмент, который предупредит об этом соответствующих специалистов. Большинство серверов непрерывной интеграции автоматически пересылают сообщения на серверы чатов в случае сбоя процедур развертывания или сборки.
3. Уязвимости. После передачи кода в производство управление уязвимостями следует осуществлять автоматически. Неважно, идет ли речь об известных уязвимостях (присутствующих в National Vulnerability Database) или неизвестных (возникших в результате небезопасных действий), в любом случае система обязана их обнаруживать и минимизировать последствия.
4. Состояние серверов. Мониторинг серверов имеет важное значение практически для любого типа инфраструктуры, не только при использовании DevOps. Производительность и соглашения об уровне обслуживания (service-level agreements, SLA) системы зависят от состояния сервера. Есть несколько инструментов, помогающих решать эту задачу. Следует также осуществлять мониторинг инфраструктуры.
5. Производительность приложений. Для определения ключевых моментов производительности и регресса приложений необходимо следить за их функционированием и своевременно принимать необходимые решения. Поможет вам в этом целый ряд инструментов, в том числе AppDynamics и New Relic. Инструменты мониторинга производительности приложений (application performance monitoring, APM) предоставляют дополнительную информацию о характере использования приложений и их производительности.

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

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

Ключевые инструменты DevOps

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

• репозиторий исходного кода (Git, CloudForce, TFS, Subversion);
• сервер сборки (SonarQube, Jenkins, Artifactory);
• управление конфигурацией (Puppet, Ansible, Salt, Chef);
• автоматизация тестирования (Selenium, Water);
• виртуальная инфраструктура (Amazon Web Services, Microsoft Azure, VMware vCloud).

***

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

– Adam Bertram. 6 steps to devops success. CIO. OCT 18, 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» – интеллектуальный поиск по большому объему событий, технических документов, данных и параметров. Когда появляются сигналы от оборудования, а тем более об аварийных срабатываниях, важно научиться быстро находить корреляцию с аналогичными событиями в прошлом и документы, описывающие похожие события или решения. Этот имеющийся огромный опыт эксплуатации, выраженный в документации и базах данных, надо переложить в централизованное решение, платформу. Это по сути наш будущий цифровой продукт – опыт эксплуатации и инструмент управления таким опытом.

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

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

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

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

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

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

Поток компетенций: что это и зачем он нужен

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

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

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

Эволюция и революция одинаково опасны

Эволюционные изменения, через которые проходит практически любая ИС, тоже могут обернуться сложностями в ее работе. Например, автоматизированная система коммерческого учета на платформе «1С:Предприятие» может не справиться с объемом 1,3 Тбайт данных, хотя еще вчера с 1 Тбайт справлялась прекрасно. Или СУБД незаметно переходит критичный порог, и нехватка ресурсов становится причиной ее плохой работы. Наконец, у одного из серверов может закончиться память, и система, которая «крутилась» на нем, начинает работать очень плохо и медленно.

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

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

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

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

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

Изменчивость в квадрате

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

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

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

Как получить поток компетенций

Вариант №1 – инсорсинг. Компетенции накапливаются и поддерживаются внутри компании.

Минусы. Гарантированно получить компетенции по этой схеме очень сложно. Ставя знак равенства между людьми и компетенциями, компания приобретает всего лишь надежду на последние. Должно пройти как минимум полгода, чтобы стало понятно, «попала» она в точку со специалистом или нет. Если компания «не попала» – то насколько? Требуется ли человека уволить или достаточно будет его правильно дообучить? Однако уход обученного сотрудника (и отток компетенций) тоже частая ситуация. Иными словами, инсорсинг – не очень надежный способ приобретения компетенций. Их сложно оценить, получить, дотянуть до нужного уровня и удержать.

Плюсы. Модель не бесполезная: в госкомпаниях, например, есть класс систем (АСУ ТП, обсчет сложных математических моделей и др.), компетенции по которым просто невозможно найти на рынке. Единственный путь – наращивать их самостоятельно, начиная с вузов. Но и перспективной ее назвать трудно.

Вариант №2 – традиционный аутсорсинг. Компетенции привлекаются извне.

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

Плюсы. Найти тех, кто поможет с ИТ, можно, пусть и не без проблем. Однако надо помнить: любые изменения, например, законодательной базы или конъюнктуры рынка (такие как открытие ниши импортозамещения в ИТ), тут же приводят к тому, что нужных компетенций, скажем, по российскому ПО или решениям Open Source и их квалифицированной поддержке, снова нет. Они – пока штучный товар или слишком быстро исчезают с открытого рынка.

Вариант №3 – баланс между внутренним и внешними компетенциями плюс специализированные услуги.

Пресловутый баланс между внутренними и внешними компетенциями не должен существовать сам по себе. Его обязательно стоит дополнять специализированными компетенциями, ювелирно «упакованными» в сервисы: скажем, непрерывного мониторинга «здоровья» информационной системы, постоянного автоматизированного или автоматического сайзинга ресурсов, предотвращения просаживания приложений, самомониторинга систем. Отличительная черта таких услуг – возможность постоянно собирать и накапливать потоки информации, анализировать и сравнивать, как вела себя система вчера, год назад и т. п. А также прогнозировать, что с ней будет – завтра, через год, через три. Такие сервисы нельзя купить в виде «голых» технических инструментов. Они всегда опираются на накопленные и отшлифованные компетенции экспертов и специалистов, на применяемые ими инструменты и методологии. И решают, казалось бы, прежде нерешаемую задачу – например, позволяют практически любой крупной и средней организации очень точно покупать ресурсы в облаке, экономя до 50% бюджета на IaaS. Работа ключевых приложений (решений на базе «1С», CRM, СЭД, почты) при этом мгновенно «выравнивается», и пользователи перестают жаловаться. Машина при расчете не допускает ни недостатка, ни переизбытка ресурсов.

***

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

Автор – Дмитрий Бессольцев, директор департамента ИТ-аутсорсинга ALPGroup, dmitriy.bessoltsev@alp.ru

Когда год назад глава Сбербанка Герман Греф назвал одним из признаков технологических компаний отсутствие в их структуре ИТ-департаментов и призвал избавляться от них, это вызвало широкий резонанс и массу обсуждений. Но на самом деле речь шла лишь о том, что банк официально признал ИТ своим бизнесом и начал активные действия по его оптимизации. С объявлением курса на 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 языку безопасности, потребовалось больше года. За этот срок удалось создать встраиваемый в средства ИБ модуль, благодаря которому на сбор информации по инциденту уходит всего несколько минут. Для сравнения, хороший аналитик за рабочий день может обработать лишь несколько инцидентов.

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