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

Родился в 1958 году. В 1980-м окончил Московский лесотехнический институт по специальности инженер-системотехник. Карьеру в страховом бизнесе начал с 1991-го, придя в компанию «Ингосстрах», где с 1993-го по 1997-й руководил отделом программных систем управления автоматизации. В РОСНО работает с 1997 года, в настоящий момент возглавляет департамент информационных технологий компании. В 2006-м закончил школу ИТ-менеджмента АНХ при правительстве РФ по программе «MBA CIO». По итогам совместного проекта Ассоциации менеджеров в России и издательского дома «Коммерсантъ» вошел в рейтинг «100 самых профессиональных ИТ-директоров России» за 2005 и 2007 годы. Лауреат ежегодной национальной премии IT-Лидер 2008.

Intelligent Enterprise: Пользуясь случаем, хотелось бы поговорить об особенностях автоматизации страховой отрасли, речь о которой, надо признать, заходит не так уж часто. Бытует, например, мнение, что автоматизация страхования сопряжена с большим количеством собственных или заказных разработок. При этом упоминается целый спектр развиваемых в каждой страховой компании систем поддержки ключевых бизнес-процессов. Что вы могли бы сказать по этому поводу?

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

Прежде всего хотелось бы определиться с типом страховых систем: учетные системы и системы поддерж­ки бизнеса. Первые из них, предназначенные для ввода информации с документов, очень долгое время доминировали в нашем бизнесе (да во многом продолжают существовать и по сей день). В моем понимании речь здесь идет о системах, эксплуатация которых предполагает тем не менее выполнение большого количества оперативной работы вручную. То есть мы оформляем договоры, выписываем полисы, считаем страховую премию и т. д. Какие-то данные мы впоследствии вводим в систему опять-таки вручную или загружаем через те или иные интерфейсы. Эти данные хранятся в электронном виде, что, собственно, и составляет суть автоматизации, когда рутинные операции, такие как расчет страховых резервов, формирование отчетности и т. д., выполняются системой в полном объеме. Происходит ли это в силу какой-либо патологической косности ИТ-специалистов страховых компаний? Отнюдь нет, всё зависит от модели бизнеса: корпоратив или ритейл, обслуживание в офисе или «в поле». Например, одна компания исторически строит свой бизнес на небольшом количестве выездных специалистов для работы с крупными предприятиями, а другая — на разветвленной сети страховых агентов по работе с корпоративными клиентами и ритейлом. Работа страхового агента, как известно, действительно разъездная, и в этом принципиальный момент. Находясь, условно говоря, где-то в полях, он скорее всего не имеет ни электричества, ни Интернета, но при этом должен оформлять полисы страхования, квитанции на оплату страховой премии и осуществлять другую «офисную» работу. Делает он это конечно же вручную. И только по прошествии некоторого времени приносит результаты в офис, где соответствующая информация и вводится в систему. Обычно работает правило «80/20», когда 80% информации (страхование физических лиц) обеспечивает 20% поступлений, и совершенно обратная картина при страховании корпоративных клиентов: 20% информации даёт 80% поступлений от общего объема. А дальше на основании этой статистики принимайте управленческое решение — какой тип информационной системы вам нужен; при этом учитывайте, что затраты на создание и внедрение учетных систем в разы меньше по сравнению с системами поддержки бизнеса. Таким образом, определенная специфика страховой деятельности, можно сказать, продлевает учетным системам жизнь.

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

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

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

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

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

В данной связи скажу несколько слов о развитии нашей компании, что можно отнести к целому ряду и других страховых фирм. В 2001—2002 годах у нас были выделены три уровня: фронт-офис — центры продаж, мидл-офис — центры прибыли и бэк-офис — центры затрат. Соответственно внутри этих центров было разделение на корпоративное страхование и страхование физических лиц. ИТ-департамент, естественно, попал в категорию центров затрат. Управление и бизнес-процессы компании строились исходя из такого деления. Совсем недавно, начиная с 2007 года, организационная модель стала изменяться. Теперь у нас более явно выделены блоки — операционный, финансовый, блок продаж, маркетинга, блоки, связанные с андеррайтингом (то есть реализацией нестандартных условий страхования), с разработкой страховых продуктов, и некоторые другие. В результате всех этих преобразований разделение бизнеса на центры прибыли и затрат отошло на второй план. Подобное воплощение организационных идей предполагает изменения и в управлении, и в бизнес-процессах компании. В частности, возникает острая необходимость в аналитических системах. Если при существовании центров затрат и прибыли имеется потребность, скажем, в оценке прибыли в разрезе каждого продукта, то при функциональном разделении мы уже приходим к тому, чтобы развертывать полноценные решения класса business intelligence — BI. Они, в свою очередь, позволяют работать, ориентируясь на набор интегрированных (в смысле согласованности действий различных подразделений) показателей, и принимать грамотные управленческие решения.

Такие организационные изменения и развитие в этом направлении характерны не только для компании РОСНО, но и для других страховых групп. Хотя если задаться вопросом, что собственно мы можем подразумевать под понятием business intelligence, то выясняется, что потенциально можно говорить об очень широком спектре технологий. Если говорить в самых общих терминах, то все компании клиенториентированного бизнеса роднит развитие технологий BI, и по большому счёту это верно. Однако в смысле практической автоматизации всё может складываться по-разному. Это зависит от многих факторов, таких, например, как финансовые возможности или зрелость компании, понимание руководством возможностей автоматизации и т. д. Дело в том, что для любого направления автоматизации необходима бизнес-модель, и если таковая в случае транзакционных систем поддерж­ки основных бизнес-процессов для менеджмента, как правило, очевидна (поскольку это по сути и есть сам бизнес), то в случае с аналитикой модель может быть куда менее ясной и формализованной. И здесь между бизнесом и ИТ должны идти двусторонние интенсивные консультации.

А в результате тех предусловий, о которых я только что сказал, акценты в применении BI в российском страховом бизнесе, еще раз повторю, складываются различным образом. Так, например, небезызвестные решения класса data mining (DM) сегодня практически не используются. Они дороги, и кроме того, здесь как раз необходима разработка модели. Вместе с тем выделение функциональных блоков, о которых я сказал выше, и по маркетинговому направлению (потенциально очень емкому для применения «продвинутых» аналитических решений), в будущем может послужить неким катализатором внедрения DM. Зато такие области BI, как хранилища данных или OLAP, значительно более востребованы на практике.

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

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

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

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

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

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

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

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

Практика методической работы тоже, как известно, весьма разнообразна. Некоторые более склонны глубоко уходить в сторону формализации процесса создания ПО, благо соответствующие методики на рынке широко представлены. А кто-то, наоборот, является сторонником как можно менее формальных процедур. Мой подход, условно говоря, лежит где-то посередине. Безусловно, процесс необходимо формализовать на уровне поддержки основных этапов жизненного цикла разработки; конечно, желательно выработать ключевые SLA процесса и в дальнейшем их придерживаться. Однако излишняя формализация по моему опыту часто приводит к дополнительным затратам на организацию процесса, а не к скорейшему получению результата. Разумеется, это может и не быть совсем уж надуманной проблемой, но процесс разработки в реальной бизнес-ситуации это точно сильно тормозит. Достаточно формализованных стандартов по архитектуре и разработке, правил проведения тестирования, документирования и передачи в продуктивную эксплуатацию.

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

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

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

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

Аутсорсингом ИТ-инфраструктуры мы действительно занимались значительное время и можем утверждать, что накопили определенный опыт в этой области. Отмечу, что первичным стимулом был уже отмеченный мной в начале нашей беседы переход к новой организационной структуре в 2002 году. Соответственно одним из стратегических приоритетов компании стало снижение косвенных затрат и количества штатного персонала, не занятого в основном бизнесе. Это коснулось прежде всего центров затрат и, разумеется, ИТ-департамента в том числе. Надо сказать, что тут тоже пришлось проактивно потрудиться над разработкой разного рода тех регламентов и процедур, по которым в дальнейшем должно было осуществляться взаимодействие с нашими партнерами. Причем по сути надо было проработать сразу несколько вариантов, чтобы впоследствии выбрать наиболее оптимальный. Речь идёт, например, о таком тонком моменте, как перевод части ИТ-персонала нашего департамента в штат аутсорсинговой компании.

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

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

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

Все эти тенденции, конечно же, касаются и деятельности компании РОСНО, что подталкивает нас к более акцентированной политике централизации информационных ресурсов. Подобную политику мы планомерно проводим начиная с 2005 года. Благо уже на протяжении трёх лет у нас есть возможность приобретать на рынке достаточно дешевые каналы связи.

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