Андрей Харитонов
Директор по информационным технологиям
компании «Ингосстрах»

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

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

Возможным выходом был переход на использование тиражного ПО, тем более что ситуация на рынке ИТ­решений значительно улучшилась по сравнению с серединой 90­х годов, когда мы начинали работать. Появились программные продукты, которые, как мы считали, можно было бы — разумеется, при некотором упорстве — успешно внедрить в нашей компании. Поэтому когда встал вопрос о построении CRM­системы, мы стали рассматривать возможность применения готовой платформы.
В 2004 году в компании была разработана ИТ­стратегия, где наряду с расширением вспомогательного функционала предусматривалось развитие компонентов, касающихся нашей основной деятельности: бюджетирования, отчетности на базе хранилища, учетной системы. Среди них присутствовал и данный проект: поскольку «Ингосстрах» — страховая (а не, к примеру, производственная) компания, CRM для нас — не вспомогательный, а основной модуль, пронизывающий практически всю нашу деятельность. Проект тогда назывался «контакт­центр плюс CRM», поскольку мы не разделяли два этих функционала, считая, что хороший контакт­центр сам по себе послужит достаточно мощной платформой для взаимодействия с клиентами — позволит их обслуживать, собирать данные о них, делиться с ними информацией о новых продуктах. При этом первоначально мы не замахивались на услуги для массового пользователя, а собирались — как, наверное, мечтают все, — ограничиться корпоративным блоком, потренироваться на нем и отработать технологию. Это казалось правильным подходом, тем более что в нашей АИС сравнительно слабо развиты функции, относящиеся к предпродажной работе.

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

Три варианта построения CRM-системы

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

Каким образом мы могли «втянуть» учетную систему в CRM? Очень просто: взять, например, модуль Siebel Insurance (или аналогичный в другой CRM­системе) и настроить его. Но удастся ли наложить эти настройки на уже устоявшиеся бизнес­процессы компании? Насколько существенно придется менять процессы и готов ли бизнес к кардинальным изменениям? Что произойдет с персоналом и, соответственно, с клиентами (не будем забывать, что цель проекта — улучшение их обслуживания)? Ответов на все эти вопросы ни у кого из нас не было. Вероятно, подобное решение подошло бы для фирмы, не имеющей развитой информационной системы, которой, так сказать, нечего терять. Но для нас прежние наработки были весьма ценны, и мы не хотели от них отказываться ради очень неясных перспектив.
Встраивание функций CRM в АИС в качестве взаимодействующего с ней самостоятельного модуля представлялось более реальным. В действительности у нас уже был такой опыт, хотя и не в области CRM (подключался модуль, который покрывал одну специфическую область страхования — страхование жизни). Но это фактически означало собственную разработку. Тиражный продукт пришлось бы адаптировать, в результате он быстро превратился бы из тиражного в уникальный и дальнейшее его развитие лежало бы целиком на нас. А это было нежелательно — ведь мы приняли решение собственных программистов задействовать только для развития основной страховой системы.

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

Разделение функций

Функционалы нашей АИС и любой CRM­системы — в том числе и выбранной нами Siebel — довольно сильно пересекаются. В частности, в АИС хорошо развиты управление продажами, электронная торговля через Интернет, система аналитической отчетности; несколько слабее, но все же отнюдь не на нулевом уровне — управление предпродажной деятельностью, торговля через мобильные устройства и поддержка обслуживания клиентов. Понятно, что мы были заинтересованы в первую очередь в тех возможностях, которых у АИС нет или почти нет: календарь и планирование времени, маркетинг, телемаркетинг (прямые продажи по телефону).
Теоретически всё это выглядит довольно просто и изящно, но стоит углубиться в детали, как мы начинаем натыкаться на подводные камни. Один из главных — это первичный ввод информации. Всем компаниям, предлагавшим нам решения на основе разных CRM­продуктов, я задавал один и тот же вопрос: кто будет отвечать за полноту и достоверность данных, заносимых в систему? Ясно, что без корректных данных система «не поедет». Автоматический контроль, такой, как проверка полей, обязательных для заполнения, необходим, но его недостаточно: как известно, голь на выдумки хитра, и сотрудники научились обманывать систему. Простой пример — ввод почтового индекса. Оператор должен занести в поле шесть цифр — иначе не сможет продолжить работу, — и вот он преспокойно набивает шесть единиц. Система это принимает — формально никаких препятствий нет, а чтобы организовать автоматическую проверку на содержательном уровне, не всегда имеются средства.
Если говорить о карточке клиента, то с ней, очевидно, должны были работать и АИС, и CRM, причем мы исходили из того, что нужно четко провести водораздел и определить, какую информацию в ней обрабатывать с помощью Siebel, а какую — с помощью АИС. Для расчета страховой премии клиента, например, решение было однозначным, так как мы вычисляем котировки по очень сложному алгоритму, который не представлялось возможным «перетащить» в Siebel. В самой CRM­системе ничего подобного нет — там никак не учитываются наши реалии, составляющие российскую специфику. Наверное, если бы механизм расчета был проще (а сейчас мы пытаемся перейти на некую линейную модель), нам удалось бы извлечь соответствующий функционал из учетной системы и реализовать его в Siebel, но в существующих условиях это немыслимо.

Фактически мы оставили в АИС все основные функции работы с договорами — их заключение, пролонгацию, прекращение, изменение, выплату премий и т. д. На предпродажной стадии обработка всей информации, начиная от регистрации контактов с клиентом и заканчивая формированием проекта договора, выполняется в Siebel, и на определенных участках есть возможность там же корректировать данные. Для передачи информации из CRM в АИС служит специальная опция «вызов функционала основной учетной системы».

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

***

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