Сбербанк: когда ИТ становятся бизнесом

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

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