Десятка мифов о модернизации технологий в страховании

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

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

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

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

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

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

Миф против реальности: как ориентироваться в модернизации технологий

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

Миф 1: влияние модернизации технологий на бизнес не впечатляет

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

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

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

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

Например, одна страховая группа использовала стандартизированные ключевые показатели эффективности бизнеса (KPI) на ранних этапах планирования программ модернизации технологий в своих бизнес-единицах. В этих показателях указана целевая частота внедрения цифровых технологий, увеличение срока хранения, уровень производительности операций, количество заявок на сотрудника, полностью занятого полный рабочий день, и коэффициент прямой обработки заявок, что позволяет организации составить свое экономическое обоснование и прогнозируемое влияние при достижении этих целей. В этом случае достижение этих ключевых показателей эффективности позволит повысить удержание клиентов на 5 % и обеспечить 20%-ное снижение производительности.

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

Миф 2: модернизация просто означает замену базовой платформы лучшей в своем классе опцией

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

Одной из основных причин высоких затрат на модернизацию является возраст и качество данных и правил полиса - плохо обслуживаемые полисы дорого обновляют и модернизируются для работы в новой системе. Типы продуктов и географический контекст также являются сдерживающими факторами. Например, полис в США в отношении личной собственности и несчастных случаев (P & C), как правило, выпускается ежегодно и, таким образом, содержит обновленные данные и правила полиса, это делает миграцию более простой. Напротив, в таких странах, как Австрия или Германия, полисы обновляются ежегодно для корректировки премий к инфляции, но данные, правила и условия полиса меняются только тогда, когда клиент переключается на новый полис, что может не произойти в течение многих лет. Следовательно, правила полиса должны быть перенесены на целевую систему, или клиенты должны переключиться на новый полис во время модернизации, что отнимает много времени.

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

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

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

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

Миф 3: использование платформы вендора гарантирует доступ к новейшим облачным технологиям

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

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

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

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

Миф 4: пакет услуг поставщиков даст нам директивные указания о том, как модернизировать наши бизнес-процессы

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

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

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

Миф 5: простое универсальное технологическое решение для нашей задачи «интеграции спагетти» уже существует

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

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

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

Миф 6: современные автоматизированные инструменты обеспечивают плавное преобразование данных

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

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

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

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

Миф 7: всегда лучше использовать стандартную схему данных

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

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

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

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

Миф 8: Переход от устаревших к облачным платформам снизит затраты на ИТ

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

Зрелая облачная система предоставляет два основных источника ценности: мгновенный доступ к бесконечной масштабируемости и скорость изменений с помощью программного обеспечения (например, быстрое внедрение новых функций). Основываясь на этих источниках стоимости, мы оцениваем, что на каждый $1 млн ИТ-бюджета общая потенциальная ценность от облачной модернизации составляет $250 000, которая складывается из ускорения бизнеса (около 25%), разработки приложений и производительности обслуживания (около 50%) и эффективности инфраструктуры (около 25 %).

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

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

Миф 9: избавление от мейнфреймов автоматически повысит производительность

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

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

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

Миф 10: микросервисы сделают архитектуру гибкой и подкованной в цифровом отношении

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

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

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

Авторы: Марк Гу, ассоциированный партнер в нью-йоркском офисе McKinsey, Санджай Канияр, партнер в бостонском офисе, Криш Кришкантан, старший партнер в офисе Стэмфорда, Йенс Лансинг, партнер в офисе в Дюссельдорфе.

Перевод с англ. подготовлен порталом Allinsurance.kz