Примеры, когда топ‑менеджер руководит не только ИТ‑департаментом, но и операционным либо каким‑то еще бизнес-блоком, в российских компаниях редки. Такого «единого в двух лицах» руководителя особенно интересно расспросить о взаимодействии бизнеса и ИТ. Своим опытом делится Мария Вожегова, вице-президент по ИТ и операциям компании «Росгосстрах».

Intelligent Enterprise: Какие стратегические инициативы компании наиболее существенно влияют на развитие ИТ?

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

Законодательные ограничения наиболее заметны в страховании автогражданской. ответственности. В этой сфере все страховщики очень зависят от региональных тарифов. И надо максимально и оперативно использовать все возможности.

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

Портал служит и для продвижения нашего нового направления: НПФ (негосударственный пенсионный фонд). ИТ‑стратегия постоянно отслеживает такие вещи, и сейчас идет внедрение ПО для поддержки функций НПФ.

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

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

Какими организационными мерами, какими регламентами задачи бизнеса транслируются в задачи ИТ-подразделения?

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

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

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

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

Проекты в области сканирования и распознавания документов по страховым случаям, урегулирования убытков у нас давно воплощены в жизнь. С 2007 г. мы используем американский софт Guidеware для этих целей. Это специализированный софт для сканирования страховой доку­ментации и дальнейшего управления потоками работ. Теперь же планируется освоить сканирование и распознавание заполненных от руки страховых полисов. Пока эти данные вводят операционисты. Планируется распознавать до 80% документов. Для принятия окончательного решения проводим пилотный проект.

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

Как происходит взаимодействие с бизнесом на операционном уровне?

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

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

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

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

Как в компании ведется управление проектами?

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

У каждого нашего проекта есть заказчик в бизнес-подразделении. Если такого нет, проект просто не запускается. В первую очередь заказчик обеспечивает выделение ресурсов и собственного, и других подразделений. Проектный офис занимается всеми проектами, а не только ИТ. Например, идут комплексный проект по реализации закона № 152‑ФЗ.

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

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

Каким образом оценивается экономическая эффективность проекта?

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

Лучшие практики всегда копируются. Хороший пример родственных процессов — управление заявками пользователей сервисов ИТ и управление заявками административно-хозяйственных служб. Процесс управления на основе заявок — это тема, которая сейчас встречается во многих областях бизнеса, от продаж до клиентского обслуживания. Именно это явление и привело к бурному развитию Business Process Management. В Росгосстрахе управлением бизнес-процессами занимается отдельное подразделение.

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

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

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

Чаще всего требования к автоматизации, потребности в изменениях процессов формулирует бизнес. Бывает ли наоборот?

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