Страховка в коробке. Страховая коробка в банке

Чтобы разобраться, почему отсутствуют «коробочные» решения в банковском секторе, попробуем собрать «коробку», из которой любой банк сможет достать… хранилище данных

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

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

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

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

Состав

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

Казалось бы, что может быть проще? Положим в нашу коробку все необходимые инструменты, разработаем модель данных, напишем «стандартное» решение для наполнения этой модели и стандартные же отчеты... Но все не так просто.

Вопросы и ответы

Первый вопрос, который возникает: какую СУБД выбрать? Обещает чудеса Sybase IQ, Teradata с легкостью ворочает огромными объемами данных и охотно рассказывает о технических решениях, обеспечивающих эту легкость, за DB2 - сорокалетний опыт создания реляционных баз и поддержка практически любого оборудования. Создатели Oracle в последних версиях сделали поистине
революционные шаги к поддержке хранилищ, здесь главный критерий выбора - простота поддержки, поэтому велика вероятность, что российские компании выберут Oracle. Однако не стоит сбрасывать со счетов тех, кто вложится в решение Teradata, и тех, кто поверит обещаниям Sybase. Пусть таких клиентов будет мало, зато они, по всей видимости, знают, чего хотят...

Рынок ETL-инструментов в России, в отличие от рынка СУБД, пока только формируется, и явных лидеров здесь нет. Согласно мнению аналитиков Gartner, в лидеры рынка попадают решения Transformation Extender (который раньше назывался Data Stage), IBM и Informatica PowerCenter. И с этим нельзя не согласиться. Но, к сожалению, далеко не всегда решение даже о выборе инструментария принимается техническими специалистами, огромную роль здесь также играет политика. И такие имена, как SAS или Oracle, звучат более привлекательно.

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

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

Миф об универсальной модели

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

Однажды, открыв учебник по философии, я был поражен названием первой главы: «Для чего нужна философия?» Почему-то ни один автор учебника по математическому анализу не начинал свой учебник с такого вопроса. Вряд ли кто-то из руководителей банка задает себе вопрос, для чего нужна АБС, но по отношению к хранилищу данных такой вопрос вполне уместен. Ответить, что хранилище необходимо, чтобы «строить отчетность» - все равно, что сказать про автомобиль, что он предназначен для того, «чтобы ездить», не уточнив, где именно.

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

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

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

Если процедура загрузки не легла в «коробку», то, может быть, туда можно поместить хотя бы модель данных, тем более что таких моделей уже немало?

Предположим, что у нас есть универсальная модель, в которую можно положить все, что так или иначе относится к банковской деятельности. Будем строить хранилище на ее основе, отсекая лишнее. Пусть, например, модель предусматривает наличие справочника марок автомобилей, которые клиенты банка покупают в кредит. Банк действительно выдает автокредиты, но как раз такого справочника в исходных системах нет. Что делать? Можно попытаться создать справочник по ходу дела. Но, во-первых, такую возможность должна предоставлять ETL-машина, а во-вторых, - бюджет проекта. Справочник, например, банковских продуктов - гораздо важнее, а время ограничено. Значит, в хранилище такого справочника не будет, причем изменение произошло из-за факторов, кажущихся малозначительными: сроков проекта и используемого инструментария.

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

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

Клиенто- ориентированность

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

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

Владимир Комаров - менеджер AT Consulting, [email protected]

В 2012 году право банков продавать страховые продукты было поставлено под вопрос. Государственная дума в первом чтении приняла было поправки к Закону «Об организации страхового дела в РФ», которые запрещают юридическим лицам выступать в роли страховых агентов, однако кредитным организациям удалось заблокировать эту законодательную инициативу и сохранить возможность реализовывать страховые полисы своим клиентам. Это, признают эксперты, пошло на пользу как банкам и страховщикам, так и конечным потребителям финансовых услуг.

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

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

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

1. Нужно заняться подготовкой самих страховых продуктов. Они должны быть понятными и простыми. Эти продукты специалисты банка и страховщики, как правило, создают совместно, используя лучшие наработки, а также с учетом клиентской базы конкретной кредитной организации. Продукт должен быть связан с банковскими услугами. Он должен быть простым, чтобы и сотрудники банка, и клиенты могли быстро понять его суть и оформить покупку. Кроме того, нужно устанавливать цену и наполнение продукта в зависимости от потенциальной целевой аудитории.
2. Правильная организация продаж, которая заключается в выработке общей стратегии, выстраивании договоренностей между банком и страховой компанией о распределении обязанностей по дальнейшему информационному сопровождению клиента.
3. Обучение персонала банка работе со страховыми продуктами.
4. ИТ-составляющая. В этой части важную роль играет наличие CRM-системы в банке, а также единой платформы коммуникации со страховой компанией.

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

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

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

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

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

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

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

Еще одно направление развития бизнеса, на которое стоит обратить внимание, - накопительное и инвестиционное страхование, а также подбор предложений для клиентов в зависимости от этапов их жизненного пути. Похоже, что рынку долгосрочного страхования жизни наконец-то поможет государство. В конце мая 2013 года газета «Ведомости» сообщила, что Минфин согласовал налоговые льготы для граждан, купивших полис долгосрочного страхования жизни. Покупатели полисов смогут получить налоговый вычет в сумме до 120 тыс рублей в год, страхователи в возрасте до 18 лет не будут платить налог (13%) с адресованных им выплат. Предложения могут быть внесены в Госдуму уже в весеннюю сессию, они должны заработать с 1 января 2014 года. Эксперты, опрошенные «Ведомостями», полагают, что в случае принятия льгот премия по новым договорам может вырасти в разы за несколько лет.

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

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

Преимущества:

• Не требуется предоставление пакета документов;
• Не требуется осмотра;
• Быстрая покупка;
• Фиксированная страховая сумма и страховая премия;
• Выбор размера страховой защиты;

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

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

Предлагаемые программы

Страховой коробочный продукт «Привет, сосед!»

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

Что страхуется:

• внутренняя отделка;
• инженерные сети и оборудование;
• движимое имущество;
• гражданская ответственность.

Территория страхования:
Находящиеся на территории РФ квартира или дом.

Оплата: единовременно.

Срок действия договора: 1 год.

Страховые риски :

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

		Вариант 1	Вариант 2	Вариант 3	Вариант 4	Вариант 5
Страховая сумма (руб.)		150 000	220 000	500 000	750 000	1 100 000
	Имущество	100 000	150 000	300 000	500 000	750 000
	Гражданская ответственность	50 000	70 000	200 000	250 000	350 000
Страховая премия (руб.)		549	799	1599	2 999	4 999

Внимание: на один жилой объект можно активировать только один полис.

Страховой коробочный продукт «Физкульт-привет!»

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

• Что страхуется:

  • имущественные интересы Застрахованного, связанные с его жизнью и здоровьем

  Страхователь:

  • Клиент, оплачивающий договор страхования (коробку).

  Застрахованный:

  • физическое лицо, в отношении которого заключен Договор страхования в возрасте от 5 до 55 лет.

  Внимание! На одного Застрахованного можно приобрести только один полис!

  Оплата: единовременно.

  Срок действия договора: 1 год.

  Территория страхования: Российская Федерация.

  Страховые риски:

  • телесное повреждение (травма)
  • смерть

  	Вариант 1	Вариант 2	Вариант 3	Вариант 4
  Страховая сумма (руб.)	100 000	200 000	300 000	500 000
  Страховая премия (руб.)	999