Гайки в космосе

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

Можно ли утверждать, что какие-то технологии завтрашнего дня используются сегодня?

Про технологии говорить сложно. Они появляются, затем исчезают. То, что мы вчера внедряли, считая технологией завтрашнего дня, назавтра может быть попросту забыто. В этом смысле разумнее говорить о трендах.

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

Можно пример?

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

Начнем с того, что Achmea разрабатывает страховые продукты и выпускает их в виде «коробочных» решений без бренда, то есть как т.н. “white label”, но с полной поддержкой не только программного продукта, но и всех бизнес-процессов — от операционного учета до урегулирования убытков. Соответственно, любой сторонний страховщик может продавать услуги от Achmea как свои собственные, не вкладываясь серьезно ни в техническую, ни в операционную составляющую. С технической стороны это стало возможно потому, что голландцы научились быстро формировать актуальный продукт для рынка. Решение буквально в присутствии заказчика составляют из «кубиков».

С точки зрения бизнеса «космос» заключается в ином отношении к клиенту и к управлению рисками. Поясню на примере страхования жилья.

Первое, на что смотрит страховой оценщик при определении стоимости страховки квартиры, — это стиральная машина. У современных моделей есть такая штука, которая называется «aquastop». При пропадании электричества данная технология запирает трубу, подводящую воду. Так вот первое, что проверит оценщик, — есть у машины aquastop, или нет. Если нет, то вероятность залива соседей и своей квартиры выше. Традиционно европейские и российские страховщики при отсутствии aquastop’а повышают цену страховки.

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

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

И как же голландский «космос» приживается в России?

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

В 2009 году у нас шел большой проект по объединению операционного учета. Для этого в Орле строили специализированный центр, где сейчас трудится около 300 человек. Требовалась система документооборота и отчетный модуль, чтобы решать вопросы операционного контроля и попутно — проблемы BI. Мы искали подходящий вариант.

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

В итоге совместно с операционным блоком мы провели тендер, победителю которого предстояло сложное задание. Мы предложили конкурсантам три источника данных, наши реальные базы — Oracle, Sybase и DBF. Задача участников — построить конкретный отчет, соединив для этого данные воедино. Наш операционный директор Евгения Гришина предложила провести конкурс «бесплатно», то есть не оплатив участникам проделанную предварительную работу. Я к такому предложению отнесся скептически и сказал, что это нереально. Никто не придет.

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

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

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

И вот, когда до подведения итогов оставалось две недели и определилась тройка лидеров, к нам обратилась столичная компания АТК. Не то чтобы совсем незнакомая, незадолго до конкурса мы встречались. Специалисты из АТК рассказывали о технологии “in memory calculation” и BI-решении фирмы QlikTech под названием QlikView. Мне тогда показалось, что все эти «вычисления в памяти» — полная чушь. Либо память должна быть огромной, либо такого не может быть.

Ничуть не смутившись тем, что тендер почти закончен, АТК попросила разрешения поучаствовать. Получив задание, ребята пропали на две недели. А затем вернулись с ноутбуком. И оказались единственными, кто смог составить правильный отчет, причем не с одной, как у всех, а с двумя базами данных. Это, повторюсь, за две недели.

Вот так и получилось, что проект, который мы готовы были отдать одной компании, достался фирме АТК. А нам, в свою очередь, досталось решение QlikView. Благодаря ему мы осознали, что решение класса Datawarehouse как хранилище информации нам не так уж и нужно, а технологии “in memory calculation” — необходимы.

Если я правильно понимаю, то с внедрения QlikView и началась эра передачи айтишных функций бизнесу?

Можно сказать и так. Отказавшись от идеи использования решения класса Datawarehouse в пользу технологии “in memory calculation”, мы отдавали отчет, что единственной важной функцией, которой не обладает QlikView по сравнению с Datawarehouse, является неизменность исторических данных. В Datawarehouse всегда сохраняется аудиторский след, в QlikView ничего подобного нет, поскольку система каждый раз работает с текущими данными. Но именно за счет этого можно быстро перестраивать модели, что для Datawarehouse остается проблемой — менять базы данных порой означает двое суток пересчета.

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

Это был первый шаг переноса компетенций по разработке из ИТ в бизнес. В итоге у меня сейчас пять центров компетенции по QlikView, и только один из них в ИТ-подразделении. Поскольку бизнес буквально «вцепился» в удобную для себя технологию QlikView со временем стал де-факто и де-юре нашим корпораивным стандартом по отчетности. В прошлом году мы вместе с АТК реализовали на базе QlikView систему отчетности для внешних органов —страхового надзора и налоговых органов.

Вы считаете себя первопроходцами?

Мы стали первой компанией в финансовой отрасли, которая начала использовать технологии “in memory calculation” и продукт QlikView, но я не теряю надежду, что АТК сможет когда-нибудь начать распространять этот продукт как некий отраслевой стандарт.

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

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

Второй наш флагманский продукт, который, также как и QlikView, частично передан в руки бизнеса, — IBM ILOG. Это решение класса BRMS (business rules management system), позволяющее простым языком, понятным непрограммисту, описывать различные правила и алгоритмы. С помощью этой системы нам удалось, в частности, реализовать систему калькуляторов для расчета страховых тарифов.

Поясню актуальность данной проблемы на примере страхового полиса КАСКО. Тариф этого полиса рассчитывается по 10–12 коэффициентам, каждый из которых зависит от своих параметров — марки и модели автомобиля, года выпуска, стажа и возраста водителя, количества водителей, территории использования транспортного средства и т. д. Всего в каждом страховом договоре приходится учитывать около 120 параметров.

Для математика расчет тарифа — тривиальная задача, где задействован 120-мерный гиперкуб. Куб, в каждая ячейка которого характеризуется 120 числами. Если заполнить нужную матрицу, задав требуемый набор значений, которые определяют 120 измерений куба, вы легко определите искомый тариф. Как говорят на мехмате МГУ: «Задача имеет точное решение и будет не очень интересна мехматянину».

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

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

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

Преимущества такого подхода заметны внешним партнерам страховой компании?

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

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

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

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

Отдавая что-то свое бизнесу, айтишники избавляются от старых проблем, но наверняка получают какие-то новые?

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

Все понимают, что сервис должен работать в режиме «24×7». Но что делать, если кто-то обнаружил ошибку? Если, к примеру, тариф у кого-то из партнеров не считается или считается неверно?

Если мы обнаруживаем, что проблема в том самом «черном ящике» под названием ILOG, то поднимаем договор SLA и начинаем трясти тех, кто обслуживает систему. Иногда выясняется, что один в отпуске, другой не в курсе текущих проблем. Иными словами, встраивание бизнес-подразделений в SLA — сложный процесс, по сути, целая проблема, которую мы сейчас решаем.

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

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

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

Айтишники, передав свои функции бизнесу, исчезнут как класс?

ИТ, полагаю, в обозримом будущем никуда из компаний не денется. Останется самим собой. Там, где вообще останется.

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

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

В противном случае может статься, что придет одно большое социалистическое ИТ-счастье. В страховании появится один большой Росгосстрах. В других отраслях — свои собственные «страхи».

Что скажете, по поводу идеологии Bring Your Own Device (BYOD)? За ней действительно будущее? И не напрягает ли она вас как ИТ-руководителя?

Меня лично не напрягает. Я корпоративную почту, к примеру, давно читаю с экрана iPad. Просто потому, что на этом устройстве удобный, продуманный почтовый клиент. В этом и есть основное преимущество подхода BYOD — использование устройства, к которому человек привык, которое он сам для себя считает наиболее комфортным.

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