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

Андрей Харитонов родился 27 декабря 1962 года в Москве.
В 1986-м окончил Московский авиационный институт, инженер-системотехник.
В 2000 году окончил курс «Управление проектами в области ИT» Академии информационных систем.
В 2004 году получил степень MBA в Открытом Британском университете/LINK.
В период 1999 — 2004 работал директором Центра решений ЗАО «Стинс Коман».
С 2004-го по настоящее время является директором по информационным технологиям ОСАО «Ингосстрах».
Увлекается спортом, путешествиями.
Лауреат национальной премии

Intelligent Enterprise: Крупные страховые компании по определению имеют развитую филиальную структуру. В связи с этим какого подхода к автоматизации в целом вы придерживатесь — распределенного или централизованного? Каковы ваши приоритеты в решении этой дилеммы?

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

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

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

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

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

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

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

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

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

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

На мой взгляд, заказчику прежде всего необходимо сосредоточиться не на технологических, а на содержательных моментах, касающихся взаимодействия различных систем. Мы, например, внедряя какую-либо из них, смотрим, насколько полно использовать ее функции целесообразно в нашей ситуации. Если она будет использоваться на 90 % или более, мы строим так называемые интерфейсные таблицы; определяем, какие параметры должны быть в двух или нескольких интегрируемых системах и как они соответствуют друг другу. Бывает и так, что функционал вновь внедряемой системы используется фрагментарно, и в той или иной ситуации это безусловно может быть более целесообразно. Скажем, из системы Oracle Siebel CRM, которую мы сейчас будем внедрять, имеет смысл вызывать функции по автоматизированному расчету тарифов, которые уже имеются в составе АИС «Ингосстрах», а не пытаться реализовать ее непосредственно в самом Siebel. Если здесь идти по пути создания интерфейсной таблицы, то мы можем столкнуться с необходимостью дублировать не только данные, но и целые системы — допустим, параллельно с центральным создать еще одно хранилище информации в CRM-системе, что абсолютно нецелесообразно. Здесь мы имеем дело с прямыми вызовами функций или, иными словами, с заимствованием логики других систем. Все это можно описать, и по сути то, о чем я говорю, представляет собой методическую работу, которая может выполняться совместно с консультантом.

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

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

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

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

Приведу в пример первую линию поддержки пользователей. На экране оператора call-центра по факту звонка должна появляться информация о клиенте. Это бесспорно, но вопрос — какая именно информация? Если выдавать самые необходимые данные — о договоре, статусе клиента, о том, относится ли он к категории VIP или нет, это будет правильно. Более подробная информация подойдет менеджеру, который будет разговаривать с ним детально. Если же на оператора call-цента обрушить всю имеющуюся информацию о клиенте, то тут уж будет иметь место то самое снижение эффективности бизнеса, о котором я говорил выше.
Далее — скажем, проблема сбора информации в CRM-систему. С технической точки зрения вопрос тривиальный, и тонкости здесь лежат совсем в иной плоскости. Предположим, человек зашел к нам в компанию застраховать автомобиль. Если начать выпытывать у него все данные о нем и его семье на этом этапе, есть большая вероятность, что он повернется и уйдет и никогда более возвращаться к нам не захочет. Если же попытаться корректно сделать это на этапе, когда наступил страховой случай, то в ситуации, когда клиент напрямую заинтересован в услугах компании, будет совсем другой результат. Понятно, что если мы внедрили CRM-систему, неправильно зафиксировав процессы сбора и обработки информации, и тем самым просто лишили сотрудников возможности работать в соответствии со здравым смыслом, будет не улучшение, а деградация деятельности компании.

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

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

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

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

Да, такие продукты на рынке существуют, и направление аналитического CRM здесь как раз служит характерным примером. Их появление имеет, я думаю, объективные причины. С одной стороны, это, наверное, можно объяснить стремлением к прогрессу (в данном случае в сфере технологии программной поддержки), который, как известно, не остановить. С другой — даже безотносительно к определенной категории ИТ-инструментов рынок конечно же идет по пути предложения программных систем со все более комплексной и одновременно специализированной поддержкой. Когда-то давно бухгалтер, которого я принимал на работу, недоумевал, зачем вести бухгалтерию в «1С», ежели в Excel делать все проще, привычнее и дешевле. Потом с бухгалтерскими программами стали ассоциировать не только более мощный функционал, но и методическую поддержку, возможность динамично реагировать на изменения законодательства и пр. То есть вокруг самих программ возникла предлагаемая вместе с ними экспертиза, и, конечно, в подобной ситуации они постепенно полностью захватили рынок. Опытный бухгалтер в то же время остался тем, кем и был, — опытным бухгалтером, чья личная экспертиза не вытесняется экспертизой системы.

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

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

Внедрение CRM-систем опять-таки является весьма характерным примером правильности известного тезиса о необходимости экспертизы в области бизнеса. Общие задачи здесь, как я уже сказал, ставит бизнес, с которым мы должны взаимодействовать, а значит, должны его хорошо понимать. Но и на этапе реализации ИТ-департаменту остается решение многих задач, требующих знания не только бизнес-процессов компании, но и, в известной мере, психологии бизнеса. Выше, говоря о сall-центре, о различиях в культуре работы компаний, ориентированных на розничный или на корпоративный рынок, я приводил, пожалуй, только наиболее понятные и характерные примеры. Помимо них существует еще масса нюансов, которые надо учитывать и которые объективно требуют от CIO знания бизнеса. Я пришел в «Ингосттрах» со стороны бизнеса, и мой предшествующий опыт, надо сказать, очень существенно помогает мне в решении стоящих предо мной задач.

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