Про цифровое предприятие или цифровой бизнес много говорят, но как только дело доходит до конкретики, обычно задор сразу исчезает. Слишком большая дистанция между нынешним и желаемым уровнями как в области сбора и обработки данных, так и в автоматизации процессов. Есть предприятия, которые начальный этап этого большого пути уже прошли и пусть небольшими шагами, но движутся по нему и дальше. О том, как это происходит в страховой отрасли, заместителю главного редактора PC Week Ольге Мельник рассказывает Андрей Педоренко, ИТ-директор компании «АльфаСтрахование».
PC Week: Какова нынешняя ситуация в страховой отрасли? Насколько быстро она идет в Интернет?
Андрей Педоренко: В страховании в настоящее время действуют две противоположные тенденции. С одной стороны — общий кризис, который на отрасли сказывается очень сильно. Страхование воспринимается как одна из сервисных функций, которыми в первую очередь и склонны жертвовать люди и компании в тяжелые времена. Когда встает дилемма — либо сокращать персонал, либо уменьшать соцпакет, — медицинское страхование персонала с большой вероятностью будет прекращено. Да и физические лица в меньшей степени стремятся страховать риски.
С другой стороны, растет спрос на некоторые виды страхования, причем очень заметно. Например, на страхование жизни. Одно из объяснений этому заключается в том, что в последние месяцы серьезно изменилась ситуация на банковском рынке, снижены ставки по депозитам и пошел отток, в том числе физических лиц. При этом люди, которые привыкли иметь доход со своих сбережений, задумались, где же теперь они могут получать его. Вложения в накопительное страхование в этой ситуации выглядят довольно интересно. И основными нашими партнерами по продаже таких услуг стали банки.
Падает КАСКО, так как резко снизились продажи новых автомобилей, сокращается страхование юридических лиц, но выросло ОСАГО — не по числу застрахованных, а в общем объеме страховых сборов, поскольку были увеличены тарифы. Эти два разнонаправленных потока создают заметные проблемы, но и обещают большие возможности.
На таком фоне наша компания за последние годы существенно нарастила обороты, несмотря на все возникшие сложности. В некоторой степени это связано с укрупнением игроков страхового рынка: многие компании, особенно мелкие и средние, в последние годы были закрыты, а некоторые — весьма крупные, как «Альянс» (РОСНО), — просто свернули часть страховых операции. Только за прошлый год ЦБ отозвал 44 лицензии. Увеличилась концентрация рынка: на десять крупнейших страховых компаний приходится более 75% оборота.
В какой-то степени это — проблема: укрупнение рынка всегда означает снижение конкуренции. Небольшие компании дают рынку новые проекты, могут опробовать новые подходы. В России заметен только один такой проект — «Тинькофф страхование», полностью позиционирующий себя как онлайн-страховщика. Надо сказать, что если онлайн-банк «Тинькофф» безусловно стал в России проектом знаковым и финансово успешным, то страховой компании с этим брендом до такого положения пока далеко.
Есть и еще одно знаковое обстоятельство: за последние два года резко возросла активность ЦБ России, нашего «мегарегулятора». Самое интересное, что его инициативы направлены на то, чтобы сделать нашу деятельность более технологичной, сокращать затраты, удешевлять услуги. Центробанк пытается подтолкнуть нас в новую цифровую эру. Множество активностей и инициатив связано именно с автоматизацией страховых процессов. Нас это очень радует.
Мы уже более восьми лет активно занимаемся электронным страхованием и всегда страдали от несовершенства законодательной базы, регулирующей эту область. Совместно с другими страховщиками мы много сил положили на то, чтобы на государственном уровне эта проблема была решена, и теперь ситуация вполне прояснилась. Электронное страхование стало абсолютно легитимным, причем именно в том виде, в каком мы его продвигали: без бумаги и без «тяжелой» электронной подписи клиента. Сфера этой формы услуг расширяется, теперь уже мы предлагаем и КАСКО в электронном виде, правда, с оговорками: например, мы не продаём таким образом КАСКО на неизвестные нам автомобили, потому что существует риск, что машина уже побывала в ДТП. Но пролонгация полисов КАСКО в онлайне имеет существенно меньше рисков и клиенты уже оценили удобство такой покупки. Некоторые услуги мы уже продаем в режиме онлайн и юридическим лицам. Знаковым было включение в закон об ОСАГО возможности продаж этих полисов через сайт в виде электронного полиса. По сути это была инициатива ЦБ, которую поддержало все страховое сообщество.
В свое время появление ОСАГО очень сильно подняло страховую культуру людей. Они активнее стали покупать КАСКО, начали думать о страховании имущества и жизни, это был заметный сдвиг. Думаю, онлайн-страхование ОСАГО будет иметь сходный эффект: люди поймут, что очень многие вещи можно страховать в электронном виде.
Но чтобы полноценно и действительно широко внедрять онлайн-страхование, нам необходима адекватная интеграция с сервисами госуслуг. Нужно иметь возможность проверить достоверность данных, которые клиент представляет нам онлайн. Паспорт, права, машина, недвижимость и многое другое: требуется доступ к этим государственным базам. Сейчас мы активно пытаемся подвигнуть к этому государство, в том числе через рабочие группы ЦБ.
Я без пиетета отношусь к госорганам, но эта работа ЦБ действительно радует: они на самом деле нацелены на то, чтобы оптимизировать процессы в отрасли. Видно, что пришли новые люди, которые понимают, что нужно делать и что сделать реально можно.
К сайту госуслуг тоже сначала все отнеслись как к очередному каналу для «распила» госбюджетных денег. Но работает же! Появляются новые сервисы, и мы постепенно подключаемся к ним. Если человек идентифицирован через госуслуги, мы можем получить информацию о нем, правда пока что — очень незначительную. В рамках закона об ОСАГО мы уже имеем право так делать. Вопрос в том, чтобы расширять эти возможности для страховщиков.
Надо сказать, что и банки, и страховые компании, и финтех сейчас поддерживают ЦБ, и все вместе мы стараемся продвигаться в онлайн. Цифровая трансформация бизнеса здесь не лозунг, а вопрос рабочей повестки дня.
PC Week: К каким изменениям в вашем бизнесе привел переход на онлайн-страхование?
А. П.: В настоящем страховом онлайне мы считаем себя лидерами. Есть компании, которые и заявку с сайта с просьбой оформить полис считают онлайн-страхованием. В нашем же представлении полис является онлайн-проданным в том случае, если клиент в ходе оформления вообще не притронулся к бумаге и заплатил электронным способом. Весь обмен данными и транзакции идут в онлайне. А при желании клиент может распечатать PDF-файл своего полиса, но это уже — опция, а не обязательный элемент процесса.
В области онлайн-страхования выезжающих за рубеж, которым мы занялись несколько лет назад, к настоящему времени мы значительно выросли, но и конкуренты нас догоняют. Другой знаковый для нас сегмент — онлайн-страхование авиапассажиров. Здесь мы номер один, потому что являемся партнерами всех крупнейших российских авиаперевозчиков. Нас тоже пытаются догнать конкуренты, но пока безуспешно, потому что мы предоставляем авиакомпаниям действительно хороший сервис.
Однако не надо думать, что всё так уж безоблачно. Есть серьезнейшие проблемы, связанные с безопасностью, прежде всего в ОСАГО. Это вообще удивительно убыточный бизнес. Сейчас, наверное, нет ни одного страховщика, который зарабатывал бы на ОСАГО. После повышения лимита выплат резко возрос поток мошенников. Если бы речь шла о продаже фиктивных полисов или о страховании несуществующих машин — это бы еще ничего, с этим вполне можно бороться. Наибольший вред наносят мошенники вполне «законные». Называется это «автоюризм», и о нём сейчас много говорят.
PC Week: Каким образом вы поддерживаете решение этих разнообразных задач ИТ-инструментами?
А. П.: У нас в компании урегулирование убытков поддерживается единой централизованной системой, по всей стране. Это сделано на страховом модуле SAP ERP. Мы не стали, как большинство страховщиков, использующих SAP, внедрять финансовые модули, а сразу взяли именно это отраслевое решение. Получилось весьма эффективно. SAP помогла нам решить множество вопросов, связанных с урегулированием убытков. Сейчас данный модуль уже интегрирован с мобильным приложением, из которого можно заявить об убытке.
В модуле SAP обрабатываются все убытки, связанные с моторными видами страхования, а недавно мы добавили туда страхование гаджетов. Это тоже массовый вид страхования, и так как много продаж, то и убытков по нему очень много.
Внедрение модуля урегулирования убытков заняло одиннадцать месяцев. Но функционал так называемого «Прямого возмещения убытков» (ПВУ) по ОСАГО пришлось делать отдельно. Процесс ПВУ поддерживает клиринговая система в РСА, позволяющая осуществлять все взаиморасчеты между компаниями. Этот процесс уникален для нашей страны, в других странах такого нет. Поэтому нам пришлось вместе с нашим партнером-интегратором автоматизировать его в SAP отдельно. И в результате все классические процессы мы делали одиннадцать месяцев, а этот один уникальный — в течение следующего года. ПВУ — непростой процесс, в нем много интеграционных сервисов, прежде всего — взаимодействие с PCA, да к тому же методология ПВУ за время внедрения изменилась. Поэтому мы и не включали его в основной проект внедрения. Но теперь наши «убытчики» уже просто забыли, как все это можно делать на бумаге.
PC Week: Насколько сильно вы меняли свои процессы в ходе этого внедрения?
А. П.: Не было смысла автоматизировать процесс урегулирования убытков «как есть». Когда мы выбирали специализированный модуль SAP, нам представляли его специалисты из Германии. Среди них был сотрудник, который не просто внедрял этот модуль раньше, но использовал его в одной из крупнейших страховых групп, в Allianz. И мы пригласили его работать над проектом. Именно он рассказывал нашим «убытчикам», как нужно изменить процессы.
А они, когда начался проект, честно, «по классике», нарисовали блок-схемы процесса «как есть» и «как должно быть». Эти схемы занимали целую пятиметровую стену. Немецкий специалист за работу их похвалил, а потом сказал: «Теперь мы всё это отложим в сторонку, и я расскажу, что нужно сделать». Вот следующие одиннадцать месяцев и ушли на эти изменения.
Была жесткая воля руководства, инициатором и спонсором этого проекта являлся заместитель генерального директора по рознице, который очертил ситуацию для всех сотрудников вполне однозначно: у каждого есть два выхода — принять SAP или на улицу. Это был один из ключевых факторов успеха проекта.
PC Week: А как же гибкость? Кругом твердят, что время таких «монстров», как SAP, ушло, потому что очень уж трудно и дорого менять эти системы в соответствии с потребностями дня.
А. П.: По завершении проекта вендор, конечно, постоянно поднимал вопрос, не пойти ли дальше. Да и мы сами, правда, все меньше и меньше, задумывались: а не накрыть ли нам всю компанию этой бетонной плитой? В России таких примеров нет, а в мире есть, и очень даже успешные.
И все же мы приходим к мысли, что сейчас нет необходимости в таких тяжелых платформенных решениях. Мы всегда жили в парадигме «best of breed» — лучших в своем классе. И именно поэтому выбрали для автоматизации конкретного функционала (урегулирование убытков) специализированный продукт, который считается одним из лучших на рынке. То есть мы пока не рассматриваем SAP как ERP-платформу.
Конечно, они все время что-то нам предлагают. Недавно предложили антифрод-систему. Показывали действительно работающий модуль на основе SAPовской базы данных HANA. Над ней — аналитика, блок принятия решений, многое другое. Всё хорошо, но у нас почти все это уже есть. То есть HANA, конечно, нет, а есть аналитическая платформа, которое отлично справляется с текущими задачами и вполне может быть применена для антифрода. У нас достаточно своих моделей, в том числе в области безопасности, работают свои специалисты, которые постоянно эти модели обновляют и развивают. И блок принятия решений по сути у нас тоже есть.
PC Week: Как вы создаете свои решения?
А. П.: Когда SAP-проект закончился, мы стали думать, куда двигаться дальше. Отмечу такой важный момент: нас не очень устраивает наша текущая корневая система. И мы начали искать готовое решение, настолько гибкое, чтобы позволяло нам быстро создавать и выводить на рынок новые продукты. Мы даже нашли такой продукт, американский — Guideware. В России у них пока два клиента. Но одно нехорошо — цена.
Поводом для изменений являлось то, что у нас был плохой фронт-энд: система для партнеров, продающих наши ритейловые продукты, была недостаточно удобна. И мы стали искать пути решения этой конкретной проблемы, а уж она обусловила и многие другие. Guideware утверждает, что у них хорошее фронтальное веб-приложение, но его внедрение сразу тянет за собой и другие изменения.
Долго думали, как быть, и в итоге решили написать новый фронт-энд сами, с нуля, на Java. И написали. Мы обещали, что за шесть месяцев сделаем решение для КАСКО, здесь ситуация была самой критической, а еще через три — для ОСАГО. Планировалось, что это будут делать семь разработчиков, но вышло так, что писали всё это четверо плюс тестировщик и руководитель проекта. Эта команда из шести человек в заявленные сроки всё и сделала.
PC Week: Как вам это удалось?
А. П.: Одна из важнейших задач в моей деятельности — донести разработку туда, где должны приниматься решения о ней, к тем головам, которые говорят, что должно быть сделано. Это опасная для айтишников схема, потому что она размывает ИТ-департамент. Но мы идем этим путем, внедряя в том числе парадигму agile, так как видим в этом возможность повысить эффективность нашей работы.
Мы используем одну из разновидностей agile — SCRAM. В ней весь процесс разработки разбивается на небольшие по времени спринты, и в конце каждого из которых заказчик получает какую-то ценность, функциональность, которой уже можно пользоваться. Процесс внедрения как таковой исключается вообще, и за счет этого достигается основная экономия времени. Спринты у нас были по две недели, и в конце каждого пользователи получали какую-то значимую для их работы новую функцию. Чтобы такую работающую «цепочку ценностей» построить, нужно выполнить очень серьезную предварительную работу, планирование, ну и конечно — чтобы повезло.
Когда был выпущен блок ОСАГО, все пользователи уже давно работали в приложении, их не надо было ничему специально учить, не надо было заменять одно приложение на другое. В большинстве своём они непосредственно участвовали в разработке. Каждые две недели приходила новая демоверсия, все ее обсуждали и говорили, что уже хорошо, а что еще нужно довести до ума. По этим предложениям команда решала, как расставить приоритеты, что важно для окончательного решения, что нет и что в какой последовательности делать. Проектирование шло вначале крупноблочно, но видение это все время обновлялось. В таком процессе критична роль владельца продукта, который и держит в голове конечную цель.
PC Week: Насколько органично приживаются у вас гибкие методологии?
А. П.: Agile — это прежде всего психология, поэтому перейти на нее не просто. Сейчас у нас работает шесть скрам-команд в разных направлениях. Многие процессы разработки мы переводим на эти рельсы. Не всё здесь гладко, например, в одном таком проекте мы потерпели неудачу.
Речь идёт о проекте модернизации нашей интеграционной шины, у нас всё взаимодействие между приложениями выполняется через нее. Это шина на продукте Red Hat, и мы попытались в том коллективе, который ее развивает и поддерживает, внедрить SCRAM. Не пошло.
Причина — менталитет. Разработчики так и говорили: «Мы не хотим так работать. Мы хорошие программисты, вы скажите нам, что делать, — мы сделаем. Но только так». И бесполезно пытаться «внедрять в них agile». Надо либо расставаться, либо оставить все как было. И в данном случае мы не стали упираться и вернулись к старой системе управления разработкой. А в других проектах идет медленное, очень трудное воспитание людей в новой парадигме. И это дает плоды.
В agile-SCRAM мы работаем уже два года. Один из процессов, которые мы решили так автоматизировать, — это процесс выплаты комиссионного вознаграждения партнерам. Там большая расчетная часть, но и процессная весьма сложная, связанная с агентскими договорами. Алгоритмы расчета комиссионного вознаграждения оказались сложнее, чем расчеты страховых тарифов.
Для таких сложных расчетных вещей нам удалось ввести специальный «движок». Это я тоже считаю нашим достижением. Когда мы его делали, то были одними из первых, теперь же такой подход стал довольно распространенным. Это BRMS-пакет (Businnes Rules Management System), подвид BPM-инструментов, но ориентированный исключительно на работу с бизнес-правилами. Он позволяет либо принимать решения на основе каких-то данных согласно установленному набору правил, либо просто вести расчеты.
Первое, что мы сделали на этом движке, — алгоритмизировали тарификацию КАСКО. Сложный процесс. Мы это сделали с помощью коллег из компании КРОК, потом подняли эту компетенцию у себя, после чего я эту компетенцию практически вынес из ИТ-департамента. Разработкой этих тарифов занимаются специальные люди, андеррайтеры. Тарифы меняются очень быстро и зависят от множества параметров, в том числе от цен на запчасти и от частоты угонов машин определенной марки. Раньше такие тарификаторы писались программистами, но алгоритмы постоянно нужно было менять. И в определенный момент мы пришли к ситуации, когда цикл модернизации оказался слишком долгим — требовалось менять алгоритмы быстрее, чем можно переписать приложение. Срок изменения тарифов стал существенно меньше минимального цикла разработки.
Мы взяли за основу продукт IBM ILog JRules (ныне IBM WODM), и он функционирует у нас уже три года. У него есть графический интерфейс, который позволяет андеррайтерам без написания программного кода менять алгоритмы расчета тарифа, делать это на понятном им языке блок-схем и таблиц. Срок ввода в действие нового тарифа сократился до нескольких дней. При этом ILog для нас, для ИТ — некий черный ящик, элемент общей инфраструктуры, к которому мы через интеграционную шину подсоединили все, что потребляет эти тарифы, в том числе сайты, старый и новый фронт-энды и многие другие приложения.
Но в таком подходе есть и опасности. У нас же действуют SLA на сайт и на работу пользовательских приложений. И вдруг в давно отлаженных блоках — ошибки тарификации. Кто разработчик? Андеррайтер. А где он? В командировке... И вообще он из другого подразделения, и его эти SLA не касаются... Таков «побочный» результат выведения разработки из ИТ-службы.
Но это — частности, намного важнее, что именно этот BRMS-движок мы собираемся использовать для борьбы с фродом, так что нам не нужно «готовое» решение SAP, тем более что готовым его считать можно с очень большой натяжкой. Это к вопросу о гибкости, которую обеспечивают или не обеспечивают определенные ИТ-инструменты и подходы.
PC Week: Что кроме Agile для вас важно в развитии ИТ-систем?
А. П.: Реальная клиенториентированность. Наша мечта — перейти на индивидуальную тарификацию. Однако это возможно только в том случае, если мы будем знать о клиенте очень много. Мы уже говорили о межведомственном взаимодействии, о доступе к государственным базам данных. Но у нас есть и другие работающие примеры. Наш ILog уже запрашивает внешние базы данных, если это необходимо, выясняет подробности о наших клиентах.
Например одним из таких источников данных является система компании Audatex — централизованная система, в которой многие страховщики ведут расчет стоимости ремонта автомобилей. С ней мы начинаем работать. Мы хотели бы использовать также данные судов, судебных приставов. Это важно для оценки убыточности клиента и, соответственно, влияет на тариф, который мы готовы ему дать. Таким образом, аналитика начинает играть все более серьезную роль в наших процессах, и чем более точной и актуальной она будет, тем ближе мы подойдем к индивидуальной работе с клиентом. «Будущее в настоящем» — таким стал слоган «АльфаСтрахования». Именно это мы и стараемся делать с помощью ИТ.
PC Week: Спасибо за беседу.
