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

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

PC Week: Как бизнес отнесся к идее трансформации и переходу на принципы agile и кто был инициатором этих изменений?

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

PC Week: Затем трансформация началась и в бизнес-подразделениях, так?

С. К.: Да, в блоке продаж и в рисковом блоке.

PC Week: Это был какой-то проект или инициатива? Вы именно таким словом его и называли — «трансформация»?

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

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

PC Week: Значит, люди из бизнес-подразделений этого слова и не слышали, но в трансформацию включились?

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

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

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

PC Week: А в чем заключается новизна?

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

PC Week: Но все-таки контроль необходим?

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

PC Week: Какими инструментами трансформация подкреплена технологически? Ведь новая культура воплощается в новых способах коммуникаций, не так ли?

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

PC Week: Выглядит красиво, но как это удалось сделать? Ведь люди привыкли к контролю.

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

PC Week: Если у них убрать контроль, они просто ничего не будут делать.

С. К.: Да-да. Плюс, наверное, тут очень важную роль играет атмосфера коллективной работы в маленьких группах — пять-семь, максимум девять человек. Потому что тогда каждый член команды на виду — команда видит, что он сделал за день и что он планирует сделать завтра. Это обсуждается ежедневно в течение 10–15 мин, не больше, но этого достаточно для того, чтобы команда почувствовала себя, во-первых, ответственной, а во-вторых, чтобы команда смотрела внутрь себя и понимала, кто насколько вовлечен. И тогда становится просто стыдно, находясь в команде, что-то делать не в полную силу.

PC Week: Вы всё-таки провели какие-то организационные изменения? Ведь откуда-то появились эти команды — это же не был стихийный процесс развития в коллективе эмпатии, ответственного отношения к делу?

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

PC Week: Как отнеслись к этому руководители, привыкшие к контролю, как им удалось «отпустить вожжи»?

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

PC Week: Можете привести какой-то конкретный пример? Какие случались у вас зигзаги на пути к цели? Что попробовали сделать, но не сработало?

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

PC Week: Почему все же собственная разработка? Интеграторы слишком дорого берут или неспособны работать в таком темпе, который вам нужен?

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

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

PC Week: Если бы это была, допустим, виртуальная модель «Боинга», то с таким подходом можно было бы согласиться. Рисуем в 3D сначала кресло, потом иллюминатор и в очках виртуальной реальности смотрим. Но физически мы не можем так построить самолет — начиная с кресла.

С. К.: Да, конечно...

PC Week: Нет здесь конфликта? Большая система все равно проектируется сверху вниз, должна быть выстроена единая архитектура. Если собирать из разрозненных кусочков, то мозаика может не сложиться.

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

PC Week: Эти переделки архитектуры разве не удорожают проект в целом?

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

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

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

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

С. К.: Да, возможно.

PC Week: Как вы оцениваете стоимость владения продуктом на горизонте, допустим, пять-семь лет? Написать по-быстрому — это одно, здесь agile позволяет сэкономить. Но основные косты возникают на этапе развития, поддержки, обновления. И вам придется содержать команду, которая его писала, фиксить баги и т. д. Не будет ли это дороже, чем заказные вещи?

С. К.: Мы очень внимательно все подсчитываем. И видим, что стоимость у нас в десятки, а в некоторых случаях даже в сотни раз меньше, чем если бы мы, например, работали с интеграторами. Что особенно интересно: наша система все время соответствует конфигурации компании примерно на 99%. Если у нас происходят организационные изменения или мы меняем нашу стратегию работы на рынках, мы стараемся адаптировать наши продукты, информационные системы, бизнес-процессы. Это происходит в тот же самый момент, очень быстро. Без огромных технических заданий. Без каких-то жестких требований к заказчику. Например, в рамках функционала нашей платформы нам удавалось запустить страховой продукт за две недели. У нас нет такого, чтобы заказчик «расписывался кровью» под техническим заданием. Заказчик имеет право на ошибку, заказчик имеет право на текущее понимание ситуации. Заказчик сам входит в кросс-функциональную группу. И эта микрокоманда начинает мелкими итерациями приближать процессы, функционал информационной системы к обновленной конфигурации компании.

PC Week: Нет ли здесь риска, что вы получите недокументированный продукт? Когда изменения вносятся вот так, практически с голоса?

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

PC Week: Вы считаете, что внутренняя разработка и сопровождение в итоге получается дешевле?

С. К.: В целом — да.

PC Week: Можно ли сказать, перефразируя Германа Грефа, что вы теперь ИТ-компания со страховой лицензией? Насколько ИТ стали драйвером вашего бизнеса?

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

PC Week: Вы используете какие-то формализованные agile-методологии или просто как подход? Идея красивая, а как научиться жить в agile?

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

PC Week: Вы где-то учили людей? Или просто так взяли и начали работать по Scrum?

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

PC Week: То есть вы учились на каких-то небольших своих реальных проектах, да?

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

PC Week: Получается, что Scrum вы освоили, так сказать, методом самоподготовки, не приглашая учителей, которые говорили бы что и как делать...

С. К.: Да, примерно так.

PC Week: Плюс ко всему, у нас сейчас эпоха мобильности. Стал ли принцип Mobile First для вас основополагающим или пока еще нет?

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

PC Week: Не кажется, что это немного с опозданием? Ведь мобильность уже вроде бы пришла.

С. К.: Нет, отставания у нас пока не происходит. Мы наблюдаем за рынком мобильных сервисов в страховании. При том что вопрос мобильности очень сложный, мы движемся в этом направлении. Например, у нас вышло недавно мобильное приложение на Android-платформе, через которое можно купить e-ОСАГО, и скоро оно появится и в App Store.

PC Week: Вы говорили, что при работе над проектом много внимания уделяли проработке пользовательского взаимодействия (UX). Как на практике реализовывался этот подход?

С. К.: Для нашей единой фронт-офисной системы мы очень эффективно использовали принципы оптимизации UX. Например, мы работали с фокус-группами, изучали лучшие практики и старались применить их в своей работе, обращая особое внимание на процесс взаимодействия нашего продавца с клиентом. Поэтому разработанная нами единая фронт-офисная система «Югория-Про» позволила сделать их работу более комфортной. К слову, мне кажется, что, благодаря как раз широкому подходу, а мы учитывали всё — и бизнес-процессы, и интерфейс, и опыт взаимодействия — в конкурсе «Проект года 2016» мы получили приз от сообщества ИТ-директоров GlobalCIO за «Лучшее отраслевое решение» в номинации «Самостоятельная разработка». Считаю, что это — коллективная победа ИТ- и бизнес-подразделений.

PC Week: Есть у вас в команде отдельная роль UX-дизайнера?

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

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

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

PC Week: Значит, это ваше конкурентное преимущество?

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

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

PC Week: Спасибо за беседу.