«Росгосстрах» — одна из самых сложных с точки зрения ИТ российских компаний,
существующая уже 75 лет.
Это филиальная сеть по всей стране, 2700 агентств, страховых отделов и центров,
почти 100 тысяч сотрудников и огромное количество операций — здесь продается
четыре полиса в секунду. О принципиальных подходах к построению информационных
систем ассказывает вице-президент, руководитель Департамента информационных
технологий «Росгосстраха» Алексей Телятников.
|
Алексей Телятников в 1987 году закончил факультет радиотехники и кибернетики Московского
физико-технического института. С 1987-го по 1993-й занимался научной деятельностью
в области лазерных технологий, имеет более 20 научных работ. |
Intelligent Enterprise: Как в «Росгосстрахе» относятся к ИТ? В какой мере они являются средством сокращения издержек компании, а в какой — инструментом повышения конкурентоспособности? И от чего, на ваш взгляд, это зависит?
Алексей Телятников: В ИТ-стратегии обязательно присутствуют оба эти направления. Потому что когда мы говорим про сокращение издержек, то имеется в виду стратегия поддержки, и без ИТ-стратегии в этой области не обойдется ни одна компания. ИТ-директор должен снижать стоимость поддержки, уменьшать расходы. Вторая сторона — стратегия развития, которая также должна учитывать задачу сокращения издержек, но при этом в большей степени ориентируется на развитие бизнеса.
Это классическое разделение. Нельзя говорить, что ИТ-стратегия должна быть только стратегией снижения издержек или стратегией развития. Важно и то и другое. Если ИТ-директор начинает говорить, что ИТ — единственный движитель развития компании, значит, компания неминуемо идет на большие расходы. Как правило, это ситуация, когда непонятно, сколько тратить на ИТ и как потом внедренные системы поддерживать. Если же у ИТ-директора другая стратегия — любой ценой минимизировать стоимость операций, это будет означать, что компания остановилась в своем развитии.
Но баланс между направлениями зависит от конкретной ситуации в бизнесе и от стратегии бизнеса. У компании с устоявшимся бизнесом стратегия скорее всего будет ориентирована на снижение издержек, у компании с развивающимся бизнесом — на его развитие. И отсюда основная проблема ИТ-директора: нужно четко понимать, какова стратегия бизнеса.
Каким образом и в какой форме вы предпочитаете налаживать профессиональное взаимопонимание с руководством компании?
Путем постоянных коммуникаций, разъяснения своей позиции и даже некоего обучения. Это всегда непросто. Ведь тут идет взаимное объяснение: каждая сторона обучает другую тому, чего та не знает Например, совсем недавно я объяснял своим коллегам — топ-менеджерам, как работают сети. Ведь просто выйти с предложением потратить на сеть такую-то сумму неправильно. И мы подготовили для руководства компании очень серьезный документ с разъяснениями того, как работают сети, чем пакетная коммутация отличается от коммутации каналов и т. д.
На таком высоком уровне, как правление, и должны обсуждаться подобные вещи?
Да. Ведь у каждого есть какие-то знания в области информационных технологий, кто-то что-то слышал и так далее... При этом под одними и теми же терминами может пониматься разное.
Если не объяснить, почему нельзя использовать интернет-каналы, скажем, для корпоративной кадровой системы, то руководство компании будет принимать решение об инвестициях вслепую. Этого допустить нельзя. Конечно, нет смысла рассказывать топ-менеджерам о таких вещах, как технические основы или протоколы. Это никого не интересует. Волнует другой момент: какая у нас проблема и почему мы именно таким образом хотим ее решить? Нам необходимо, чтобы сотрудник отдела кадров, например, имел доступ к данным по всем сотрудникам компании (а у нас их около 100 тысяч). Бизнес понимает, зачем это надо. Но — как это сделать? Нам необходима центральная база наших сотрудников. Хорошо, а какие есть альтернативные решения? Достаточно ли пересылать данные, скажем, раз в месяц? А если это будут публичные интернет-каналы? И мы доказываем, что в публичном Интернете скорость работы кадровика с системой будет ниже. Если нужно, проводим эксперимент. Как бы того ни хотелось, но дешевый вариант, увы, не пройдет. Какие еще есть варианты?
Надо рассмотреть все варианты, и для этого необходимо понимание основ. Процесс очень сложен, но таковы последовательные этапы, которые приходится проходить, принимая стратегические решения в области ИТ. Причем это могут быть и не столь крупные инвестиции, но принципиальные решения, которые могут повлечь за собой другие важные действия.
Большинство компаний подобные принципиальные решения в области ИТ оформляет в виде ИТ-стратегии...
Да,
она необходима. Когда я формулировал ИТ-стратегию, я подошел к этому вопросу
так. Понятно, что есть стратегия работы компании, но не все ответы на важные
для меня вопросы она дает. Поэтому я сформулировал полтора десятка вопросов
по ключевым темам стратегии развития на пять лет. Причем вопросы самые простые,
например: «Как часто мы хотим выплачивать комиссионные вознаграждения?» Варианты
ответов: раз в год, раз в месяц, раз в день. Почему важен этот вопрос? Если
раз в год, то к выбранному сроку можно собрать воедино все данные и спокойно
рассчитать комиссионные. Это один подход и соответственно одна технология, один
набор программного обеспечения, определенные требования к каналам связи и т.
д. Если раз в месяц — то подход и требования будут совершенно другими.
И такую анкету я попросил заполнить всех ключевых руководителей компании. Не
обязательно это должны быть только руководители блока. На самом деле это были
менеджеры, которые, по моему мнению, в той или иной степени влияют на стратегию
развития компании. Здесь очень важно правильно поставить вопросы. Спросить,
хотим ли мы работать онлайн — значит ни о чем не спросить. Ну что такое онлайн
для топ-менеджера? А вот платить ли раз в месяц или раз в год — это уже вопрос,
на который топ-менеджер быстро даст ответ.
Когда мы получили ответы, по ряду положений мнения были прямо противоположные.
А нужно было получить консолидированное мнение руководства компании. Вот с этим
документом я и вышел на правление и предложил рассмотреть его и все-таки выбрать
из нескольких вариантов ответов один —наиболее точно отражающий нашу стратегию.
Когда все решения были обсуждены и зафиксированы, мы приступили к написанию
ИТ-стратегии и построению ИТ-архитектуры.
Две трети всего времени ушло именно на разработку ИТ-стратегии. Избранный подход был использован руководством компании в более широком плане, в том числе при разработке стратегии развития компании на пять лет.
Почему вы не привлекали консультантов для создания ИТ-стратегии?
Вряд ли в крупной компании такой документ может быть написан внешним консультантом. По собственному опыту и по опыту своих коллег я знаю, что так скорее могут быть написаны базовые принципы, но не ИТ-стратегия. Здесь есть принципиально важный момент. Безусловно, самый сложный этап ее создания — осознание стратегии бизнеса. Очень хорошо, если она формализована и написана в четких и, следовательно, однозначных терминах. Однако я видел стратегии развития других компаний и могу сказать, что многие ответы в них не давались. Эти вопросы обходились стороной, им давалось двойное или тройное толкование, потому что так проще сформулировать стратегию, дабы не создавать конфликты между различными блоками компании. Здесь важно не просто взять формализованную стратегию, а суметь задать эти дополнительные вопросы, чтобы обрисовать единую картину. Только тогда можно получить непротиворечивый взгляд на стратегические задачи ИТ и соответственно управлять ожиданиями пользователей.
Как часто должна пересматриваться ИТ-стратегия, какова степень ее гибкости?
Понятно, что стратегия не может быть постоянной в течение, скажем, пяти лет, меняются и технологии, и бизнес-задачи. Но тем не менее сама стратегия меняется редко. ИТ-стратегия «Росгосстраха» базируется всего на нескольких принципах. Очень важно договориться по этим принципам, и один из них — архитектура ИТ. Мы долго спорили, хотим ли мы иметь единую информационную систему от одного поставщика, как предлагали консультанты, или для компании такого масштаба возможен только компонентный подход. Наш стратегический подход — это компонентная архитектура. Сейчас уже многие компании переходят на такую идеологию. Но три года назад, когда мы подошли к такому решению, это был весьма сложный вопрос. Я очень порадовался, когда услышал слова о компонентной архитектуре от представителя SAP.
Очень важно, что только такой подход позволял нам управлять процессом автоматизации направлений с разной скоростью развития. Ведь компания такого масштаба не может одновременно с одинаковой скоростью развиваться по всем направлениям бизнеса. А менять надо очень многое. Но тем не менее при наличии ИТ-стратегии такое развитие становится более-менее управляемым процессом. На мой взгляд, ИТ-стратегия — это прежде всего способ управления ожиданиями руководства и планирования задач, которые должен выполнять ИТ-департамент. И как раз стратегия сводит эти вещи в одну точку.
Какова степень детализации ИТ-стратегии? Должны ли в ней быть зафиксированы приоритетные направления автоматизации и инвестиций в ИТ или важнейшие ИТ-проекты?
Это уже способ реализации. После того как ИТ-стратегия фиксируется на бумаге, начинается обсуждение приоритетов. В ИТ-стратегии «Росгосстраха» присутствует около тридцати различных задач и компонентов, например кадровая система. Понятно, что тридцать проектов одновременно вести нельзя, на это не хватит ни ресурсов, ни денег. Определить приоритеты в реализации — это следующий шаг, который должен сделать ИТ-директор.
Причем задача расстановки приоритетов связана с примерной оценкой стоимости каждого ИТ-проекта и срока, необходимого для создания того или иного компонента. Ведь, может быть, ИТ-проект не столь приоритетный, но стоит копейки. Тогда его имеет смысл запускать сейчас. А может быть — приоритет его очень высок, но стоит он очень дорого.
Обсуждение приоритетов реализации ИТ-стратегии — это прерогатива правления компании. У нас эти приоритеты обсуждались на правлении как минимум пять раз. ИТ-директор должен описать все компоненты в целом, чтобы сложилось общее понимание. А далее начинают сталкиваться интересы основных бизнес-подразделений. Руководитель каждого блока понимает, какие возможности даст ему тот или иной компонент, но при этом все члены правления должны суметь расставить единые приоритеты.
Не по всем вопросам складывается единое мнение. Например, бухгалтерская система — это приоритет первого уровня, но и кадровая система — тоже. Это очевидно. Но что раньше нужно поставить, HR-систему или бухгалтерскую? Стандартный ответ таков: конечно же бухгалтерскую. Но на самом деле это зависит от конкретной ситуации в компании. Бухгалтерская отчетность как-то сдается, а если в компании нет правильного учета кадров, то она наверняка теряет очень много на том, что в ней работают недостаточно квалифицированные сотрудники, получающие неадекватную зарплату, и т. д. А когда нужна система автоматизации медицинского страхования — сейчас или позже? Когда нужна CRM-система? Каковы компоненты и как они связаны между собой? И насколько четко эти взаимосвязи должны быть выдержаны? Начинаются споры, в ходе которых и складывается приоритизация.
Следующий этап — формализация приоритетов и превращение их в ИТ-проекты — это, по сути дела, уже не ИТ-стратегия, а план ИТ-проектов. У нас в «Росгосстрахе» есть четыре приоритета по компонентам информационной системы, примерно такого вида: обязательно должен быть, должен быть при наличии денег, хотелось бы иметь и неплохо было бы иметь. Только после этого мы смогли сформировать ИТ-бюджет в части развития, то есть посчитать, сколько будет стоить данная ИТ-стратегия.
Каковы компоненты в ИТ-системе «Росгосстраха»? По какому принципу вы их выделяете?
Самый простой компонент — это финансовая система. У нее есть владелец и заказчик,
у нее понятный функционал, в ней четко прописано, что именно система должна
принимать и выдавать. Дальше — сложнее: встает вопрос о том, какие системы должны
быть. Вести ли договора по страхованию жизни и ОСАГО в одной системе или в разных?
Здесь начинается спор, потому что тут речь о разных направлениях. Страхование
жизни — это скорее инвестиционная деятельность, а ОСАГО — стандартное рисковое
страхование. А какова должна быть система для медицинского страхования — та
же, что и по страхованию жизни или рисковому страхованию, или иная?
Причем поскольку мы реализуем принцип компонентной архитектуры, то из него сразу
следует много выводов. Например, что не нужно со всеми согласовывать выбор системы
бухгалтерского учета, достаточно согласовать с несколькими менеджерами — бухгалтерами,
экономистами, управленцами и сотрудниками, которые ведут операционный учет и
готовят первичные данные. Выбор системы по страхованию жизни не надо согласовывать
с теми, кто занимается ОСАГО. То есть из принципа компонентной архитектуры следует
совершенно другой механизм принятия решений.
А проблем с интеграцией вы не боитесь?..
Действительно,
обратная сторона компонентной архитектуры — это проблема интеграции. Но здесь
есть два фактора. Во-первых, для промышленности существует достаточно большое
количество ERP-систем, разработанных под определенные направления индустрии.
Там не так быстро всё меняется, процессы стандартны. Однако страхование отличается
от финансовых и промышленных систем тем, что оно находится где-то между этими
двумя областями. Например, страхование автомобиля включает в себя страхование
определенных рисков, связанных со страхованием здоровья. Страхуя по ОСАГО, мы
должны знать не только мощность двигателя и марку автомобиля, но и его «болезни».
На учетном объекте «полис по страхованию» завязывается много предметных областей.
В справочниках объектов страхования тысячи позиций. А каждый объект может характеризоваться
огромным количеством параметров, причем совершенно разных. Скажем, у дома одни
параметры: из какого материала сделан, где находится, какой этаж, какая плита
— электрическая или газовая, потому что от этого существенно зависит тариф.
При страховании жизни параметры другие: употребляет ли человек алкоголь, какие
болезни были у его родственников и т. п. При страховании выезжающих за рубеж
важно, если вы, например, едете на лыжах кататься, то в какую страну, как там
подготовлены горы. И в том, чтобы все учесть, как раз и состоит наш бизнес.
В этом плане страхование намного сложнее, скажем, банковского бизнеса, и поэтому рынок готовых страховых систем более фрагментарен по сравнению с рынком банковских систем. Задачи у нас намного сложнее. Многие менеджеры, которые пришли в страховую компанию из других направлений инвестиционного или банковского бизнеса, представляли себе стратегию развития информационных систем похожей на развитие, например, банковской системы. Но степень стандартизации и формализации информационных систем и развитие готовых решений в области страхования отстает от банковской сферы, по моему ощущению, лет на пять. Мы сейчас активно выбираем компоненты для наших основных направлений, и могу сказать, что это очень сложная задача. Таким образом, в страховании компонентная архитектура более естественна. Компонентный подход позволяет нам, инвестируя информационные технологии, одновременно сохранять определенную гибкость — она необходима, чтобы учесть изменения, которые произойдут на рынке информационных систем для страхования в ближайшие годы.
А во-вторых — за последние пять лет идеи интеграции и компонентных приложений
продвинулись намного дальше не только в теоретическом, но и в практическом плане.
То же самое, наверное, произошло лет пятнадцать назад с реляционными базами
данных. Мы просто постепенно переходим на другой уровень мышления. Раньше мы
мыслили записями, потом стали мыслить связями, а сейчас мыслим интерфейсами.
И в эту сторону двигаются все производители программного обеспечения. В интеграции
проблемой становится не сама интеграционная платформа как таковая. Это лишь
малая часть. В интеграции важно продумать стандарты — насколько они открыты,
насколько взаимозаменяемы их компоненты. Это очень сложный процесс, но крайне
необходимый.
И для этого на определенном уровне нужно видеть результирующую картину. В деталях
это сложно, потому что, например, мы начинаем искать какой-то компонент, а его
нет. Мы думали, что он такой, а он, оказывается, другой. Естественно, детали
картины меняются, но важно, чтобы она все время была целостной.
Насколько крупными должны быть компоненты? Ведь их можно искать и под каждую мелкую задачу. Как достичь баланса между количеством компонентов и их размером?
Да, баланса достигнуть очень важно, но тяжело. Ведь когда говорят о «лоскутном одеяле», то здесь другая ситуация. Под маленькую задачу сделали маленькое решение, потом другое маленькое решение, вот и получается «лоскутное одеяло». Если для урегулирования убытков КАСКО сделать одну систему, для ОСАГО — другую, а потом еще одну, то тогда единую систему уже не соберешь. Но если есть комплексная задача, например урегулирование убытков, и вы ее закрываете, то тогда у вас остается мало интерфейсов. Вы понимаете, что нужно интегрироваться с системой, где ведется учет полисов, но у нее вполне понятный интерфейс: она дает информацию о полисах, а получает данные об урегулированных убытках.
Как достичь баланса? Главный принцип — делить системы по заказчикам. Причем не обязательно это должны быть направления бизнеса. Например, у нас нет такого направления, как инвестиционная деятельность, но это часть нашей работы. Соответственно в компании есть подразделение, отвечающее за управление инвестициями, и нужна система, которая может эти задачи решать. Сможет ли решать их финансовая система? Давайте попробуем. И когда становится ясно, чем не устраивает финансовая система и как отдельная система автоматизации инвестиционной деятельности должна взаимодействовать с финансовой, мы понимаем задачу и начинаем искать.
Но есть и другой пример — HR-cистема. Здесь заказчик не очевиден. Дело в том, что эта система используется двумя подразделениями: бухгалтерией (в части зарплаты и налогов) и отделом кадров. Но не бывает так, чтобы одна кадровая система использовалась для бухгалтерии, а другая — для HR-отдела. Тогда мы должны найти компромисс, ведь нужен один заказчик. Между руководителями этих подразделений происходит определенная борьба за лидерство. Решение таких вопросов — это и есть искусство управления.
Какие еще факторы влияют на реализацию ИТ-стратегии?
В «Росгосстрахе» еще довольно много ограничений на реализацию выбранной ИТ-стратегии. В силу нашей географической распределенности и отсутствия каналов связи мы весьма ограничены в выборе архитектуры приложений, которые можем использовать. Или мы должны вкладывать большие деньги в инфраструктуру, чтобы можно было использовать централизованные приложения. Кроме того, у нас невелик штат ИТ-сотрудников: в ИТ-отделе «Росгосстраха» работает чуть больше трехсот человек.
Вы пришли в «Росгосстрах» более трех лет назад. И сразу приступили к разработке ИТ-стратегии?
Нет, первые три года у нас была простая задача — решать насущные проблемы. Четыре года назад, после приватизации компании, в «Росгосстрах» пришла новая команда менеджеров. Прежде всего им предстояло понять, как же развивать компанию, в том числе и в области ИТ. К сожалению, уровень автоматизации, доставшийся нам в наследство, был ниже необходимого. Мы получили практически отсутствующую инфраструктуру. Например, на тот момент пять миллионов договоров было только на бумаге. А ведь страхование — это очень серьезная математика, это расчеты, на основании которых принимаются серьезные управленческие решения, в частности по резервированию средств. И всё это нужно было считать, чтобы управлять компанией.
Поэтому первая моя задача состояла в том, чтобы за два месяца бумажные договора перевести в электронный вид. Затем — в каждом отделе агентства завести электронную почту (ведь даже ее не было). Необходимо было создать команду, набрать людей, выстроить систему управления. На это ушло много сил и времени.
Вторая задача — это инвентаризация. Чтобы управлять, вы должны видеть картину в целом. Первый месяц работы в компании был посвящен инвентаризации, причем пришлось разбираться даже не в том, какие есть компьютеры, — а просто сколько их, какие адреса электронной почты и т. д. Сейчас мы такую инвентаризацию проводим регулярно два раза в год.
Следующий вопрос — стандартизация. «Росгострах» того времени — это 79 компаний, существовавших по сути отдельно. И выстроить единую систему управления в компании, в том числе в ИТ, очень сложно. Я горячий поклонник методологии ITIL, но уверен, что она должна внедряться в ограниченном объеме, потому что полномасштабное внедрение возможно только в компаниях достаточно установившихся и зрелых. Мы разработали и внедрили стандарты на инфраструктуру, оборудование, офисы. На это ушло много времени, почти год, но документ был готов значительно раньше, чем полная ИТ-стратегия компании.
Мы принимали практически очевидные решения, которые слабо зависели от будущей
ИТ-стратегии: создание системы управления, стандартизация, централизация закупок...
То, чем мы занимались почти три года, — это стратегия эксплуатации. Она была
включена в общую ИТ-стратегию компании, но это просто констатация факта. А создание
стратегии развития — это длительный процесс. Формулировать долгосрочные планы
развития (лет на пять) мы смогли через два года после того, как начали наводить
порядок. Понятно, что некоторые ИТ-проекты в это время делались, но как временные
решения, и это нормально.
Сейчас мы планируем завершить проекты первого приоритета, связанные с внедрением систем кадрового и бухгалтерского учета, с тем чтобы получить основу для развития такого, например, решения, как аналитическое хранилище данных. Эти стратегические проекты идут вполне успешно. Мы практически за девять месяцев сумели перейти с нескольких сотен точек на единый центр расчета заработной платы. И это стало возможно только потому, что мы четко могли объяснить руководству, как данный компонент вписывается в другие системы и почему даже отсутствие интеграции с бухгалтерской системой не нарушает нашу ИТ-стратегию, а позволяет нам достичь поставленных целей.
Давайте теперь перейдем к организационной структуре ИТ-отдела. Как она должна отражать ИТ-стратегию компании?
Поскольку есть две части ИТ-стратегии — поддержка и развитие, — ИТ-отдел должен выдерживать это деление. Соответственно есть подразделение, которое обеспечивает реализацию стратегии поддержки, управление эксплуатации; в общем-то оно отвечает за инфраструктуру. А другая часть — это сотрудники, отвечающие за развитие.
Но мы выделяем еще и третью группу, и причин для этого несколько. Во-первых, какая-то часть функций находится на границе эксплуатации и развития — это helpdesk и тестирование. Во-вторых, необходим независимый арбитр. Допустим, что-то сделало подразделение развития, что-то делает эксплуатация, и должен быть кто-то, кто посмотрит на всё это со стороны. Это будет означать, что у ИТ-директора есть независимый арбитр, контролирующий качество работы подразделений развития и эксплуатации. Конечно, есть еще и службы, которые выполняют функции закупок и бюджетирования, но это стандартные выделенные функции для любого ИТ-департамента.
Самый сложный момент — подразделение развития. Дело в том, что у него есть два способа организации. Первый — создать некий единый пул ресурсов, который будут использовать все. Это означает, что мы обслуживаем заказчика из бизнеса через одну точку входа, получаем задание, выделяем ресурсы и т. д. А второй способ — структуру подразделения развития связать с крупными направлениями автоматизации. Это в принципе правильно. Я недавно был в одной западной компании и видел, как там это сделано. Потому что тогда получается, что в ИТ-отделе есть менеджер, который отвечает, например, за все, что касается финансовых систем, в широком смысле — включая HR и бухгалтерию. То есть менеджер, профессионально разбирающийся в предметной области. Ведь в финансах нужно знать и российский бухгалтерский учет, и кадровый учет, и тонкости инвестиционной деятельности. Соответственно у такого менеджера один или несколько заказчиков. Лучше один, но так не всегда получается. А другой менеджер отвечает за область регулирования выплат при страховании.
Сейчас у нас реализован первый подход — единая точка входа. Но перейдя к компонентной архитектуре, мы стали постепенно двигаться во втором направлении. Сейчас четкого разделения на направления пока нет, но мы к этому идем. Поскольку именно в такой структуре можно вместе с бизнесом точно понять, как должна строиться система, каковы требования, приоритеты и т. д. Хотя это, конечно, не все 29 направлений, которые обозначены в ИТ-стратегии, а только три-четыре. И понятно, что надо всем этим должна быть общая управляющая структура.
Еще один сложный организационный момент, связанный с подразделением развития, — четкое понимание проектного управления бизнесом. В «Росгосстрахе» вообще все развитие компании построено по проектному принципу. И я всегда настаиваю, чтобы руководителем ИТ-проекта по построению какого-либо компонента был кто-то со стороны бизнеса. Хотя в некоторых случаях и ИТ-менеджер может взять на себя функцию руководства. Это зависит от конкретного человека, от того, насколько он специалист в данной области, насколько силен как менеджер проекта. Важно, что проект — это коллективная деятельность. Если возникает серьезный конфликт между представителем бизнеса и представителем ИТ-отдела, то проект не получается.
Всегда ли можно четко отделить развитие системы от эксплуатации? Ведь есть моменты, скажем, опытной эксплуатации системы. Кроме того, развитие функциональной системы не прекращается, и в некоторых компаниях развитием и эксплуатацией бизнес-приложения занимаются одни и те же сотрудники…
Безусловно, на этапе передачи системы необходимо очень тесное взаимодействие подразделений эксплуатации и развития. Поэтому сложно определить, чем занимается сотрудник — скажем, сегодня развитием, завтра эксплуатацией. Или увидеть порог перехода системы в эксплуатацию. Тем не менее развитие всегда нужно четко отделять от эксплуатации.
Потому что в этих двух областях совершенно разные риски. Если в компании работает 100 сотрудников, то систему часто может поддерживать и тот, кто ее написал. А если 95 тысяч? Представьте себе, что будет, если база данных, которая содержит зарплату и всю кадровую информацию на 95 тысяч сотрудников, вдруг исчезнет. Это крах для компании. Соответственно нужна процедура, должны быть сотрудники, которые на постоянной основе будут делать резервные копии, проверять настройки таблиц и т. д.
На мой взгляд, всегда нужно четко понимать, где мы сейчас находимся. Если в режиме промышленной эксплуатации системы — это одни правила игры. В режиме внедрения — другие. В режиме опытной эксплуатации — третьи. И соответственно бизнес должен понимать, что если некая система сейчас находится в режиме опытной эксплуатации, то он может остаться без этого сервиса на день, а то и два или три. А если система находится в промышленной эксплуатации, то бизнес вправе ожидать непрерывной работы.
Самое печальное, когда эти понятия смешивают. Но чтобы сдать в эксплуатацию, надо написать документы и регламенты. И это не формализм, а необходимость. Такая проблема есть, но она лежит в другой области. Она как раз высвечивает необходимость четкого подхода именно к эксплуатации.
А какова структура ИТ-отдела с точки зрения географии?
Управление развитием, а также подразделение, которое обеспечивает функции тестирования и helpdesk, сосредоточены в центральном офисе. Там же есть и отдел эксплуатации, отвечающий за работу офиса. Надо учитывать, что если внутри компании существует определенная организационная структура, то таким же образом должен строиться и ИТ-департамент. Его структура не должна противоречить структуре компании. Поэтому все функции стандартизации и развития сосредоточены в центральном офисе.
В регионах ИТ-отделы в основном обеспечивают функции эксплуатации системы. Там есть свои особенности развития, например инфраструктура развивается уже на основании разработанных стандартов. И соответственно в каждом филиале имеется ИТ-отдел, начальник которого отвечает за эксплуатацию системы и подчиняется директору данного филиала. А тот, в свою очередь, определяет, насколько он удовлетворен эксплуатацией. ИТ-отдел центрального офиса дает стандарты и подбирает кадры. Это матричная структура, когда начальники региональных ИТ-отделов напрямую подчинены своему директору и функционально — управлению эксплуатации центрального офиса.
Вы привлекаете многих ИТ-подрядчиков, но при этом не идете по пути выбора генерального подрядчика или генерального поставщика. Почему?
Я считаю, что конкуренция — основной двигатель прогресса. Как только у ИТ-директора появляются два поставщика одной и той же услуги, он начинает диктовать условия. Когда поставщик один — возникает другая ситуация. Это коммерческие отношения: наша задача — заплатить как можно меньше, задача подрядчика — получить как можно больше. И у поставщика нет желания предложить минимальную цену. Рыночный механизм позволяет найти компромисс.
Например, у нас не менее двух поставщиков телекоммуникационных услуг — «Транстелеком» и Equant. Оборудуя новую точку, мы даем запрос двум текущим телекоммуникационным провайдерам. И правило следующее: если кто-то из них определенное количество раз не даст нам подключения в нужных точках, то будет третий провайдер. Но в любом случае время от времени мы на этой же точке запрашиваем предложения других провайдеров и при этом следим за рынком. Можно было бы следить и при одном поставщике, но тогда у нас не будет возможности завтра сказать «нет».
Другой пример. В «Росгосстрах» компьютеры поставляет компания «Крок», принтеры — «Дилайн», а копиры — третья фирма. Казалось бы, почему не поручить все это одной компании? Но ведь я провел конкурс, они победили, а для меня три поставщика — не проблема. Проблема — когда их тридцать. Зато в такой ситуации я могу сравнивать их работу. На такую компанию, как «Росгосстрах», каждый поставщик выделит менеджера, и если он будет работать плохо, его поменяют. Здесь я управляю ситуацией. Это не требует от меня больших усилий, но очень важно, что ситуация управляемая. Поэтому несколько поставщиков — самый эффективный подход.
Это пример из закупочной деятельности. А если говорить о проектах?
Для разработки мы стараемся либо покупать готовые системы, либо привлекать внешних подрядчиков. У нас работают TopS BI, IBS, «АйТи», «Диасофт» и другие. TopS BI помогала при создании «АРМ Страховщика» и автоматизированной системы ведения классификаторов и справочников. IBS занимается системой бухгалтерского учета, «АйТи» — кадровой системой, а «Диасофт» — системой перестрахования.
Однако генподряд на создание всей системы «Росгосстраха» требует очень высокой квалификации сотрудников подрядчика и немалых ресурсов. Я разговаривал с крупнейшими западными страховыми компаниями, у которых тоже несколько миллионов клиентов, которые ведут похожие проекты и имеют похожие проблемы. У них такая же ситуация: под разные задачи привлекаются ресурсы разных поставщиков. Потому что главная проблема — ресурсная.
Например, мы с руководством IBS долго искали правильный набор ресурсов для решения задач бухгалтерского учета. Конечно, я мог бы поручить IBS и автоматизацию кадрового учета, но не думаю, что это было бы эффективно, потому что скорее всего IBS предложила бы для HR-системы другое решение. Здесь вступит в силу конкурентная борьба, но ведь HR-систему выбирают функциональные руководители. У них есть определенное видение организации HR-функции в компании, они сравнивают разные системы и говорят: мне нравится эта система, и я готов ее использовать. А если генеральный подрядчик утверждает, что нам нужна другая? Тогда бизнес-заказчик сразу теряет интерес к проекту. То есть кроме ИТ-директора и бизнес-заказчика появляется еще третья сила, усложняющая принятие решений.
Кроме того, чтобы снизить риски проекта, необходимы поставщики ИТ-услуг, имеющие серьезный опыт работы в страховании. А таких в России нет.
Наконец, последний вопрос — он касается ИТ-аутсорсинга...
Мы передаем на аутсорсинг довольно много. Сейчас — в основном инфраструктуру. Например, мы не строим собственный вычислительный центр, это дорого, требуются специальные высокооплачиваемые сотрудники, обладающие специальными знаниями. Мы с самого начала арендуем ВЦ у компании DataFort. И я считаю, что экономия тут огромная, нам это обходится в десятки раз дешевле, чем собственный вычислительный центр.
Более того, аренда ВЦ — только первый шаг, мы будем развивать эту практику. Если какая-то компания предложит мне обслуживание всех моих персональных компьютеров по всей стране, я с радостью приму это предложение. Понятно, что мы не ремонтируем технику, но замена программного обеспечения и установка новых систем — это функции внутренних сотрудников. Хотя их тоже хотелось бы передать на аутсорсинг. Но такое предложение должно быть конкурентоспособным по отношению к текущей стоимости обслуживания — как минимум не дороже и не хуже. Пока таких предложений, увы, не поступает.
