Биография
Родился в 1969 году в Москве. Закончил в 1992 году Московский институт радиотехники, электроники и автоматики по специальности «Электронные вычислительные машины».
8 лет занимался разработкой и внедрением западных банковских систем в России, Словакии, Венгрии, Бельгии и Англии, пройдя путь от разработчика до руководителя проектов.
В 2001-2003 году работал в Управлении банковских технологий Банка Москвы.
В 2003-2004 годах возглавлял Управление информационных технологий, а затем Департамент информационных и банковских технологий КМБ-Банка .
В 2004 году успешно сдал экзамен на звание Certified Information System Auditor.
С 2004 года по октябрь 2010 - директор Департамента информационных технологий группы Русфинанс . За время его работы в группе проведено развертывание контакт-центра, насчитывающего более 750 рабочих мест и обеспечивающего обслуживание более 2,5 миллионов телефонных звонков в месяц. Разработана и внедрена инфраструктура, поддерживающая функционирование 60 региональных представительств и более 10 тысяч точек продаж. Успешно проведена инфраструктурная, технологическая и организационная интеграция в рамках группы Русфинанс ООО Русфинанс, Промэк-Банка и банка СКТ. Осуществлено внедрение прикладной архитектуры, обеспечивающей на данный момент обработку более 1,5 миллионов кредитов.
2011 - 2013 гг - заместитель генерального директора R-Style Softlab по стратегическому развитию.
В мае 2013 г. перешел в банк «Траст» на должность управляющего директора по информационным технологиям и бизнес-методологии. В начале 2014 года вошел в состав правления банка «Траст».
Является председателем Клуба делового общения банковских ИТ-директоров (СIOBANK Club).
Семья
Женат. Воспитывает дочь.
Награды
Лауреат национальной ежегодной премии IT Лидер 2007 «За выдающийся вклад в развитие информационных технологий в России».
Подобно герою феллиниевского фильма «Амаркорд» (по итал. amarcord - я вспоминаю), Олег Подкопаев вспоминает себя. С помощью кисти и мастихина на пространстве холста рассматривает свои воспоминания об ощущениях, выбирая наиболее сильные отклики внутри себя.
Что его вдохновляет?
Как мы видим – любимые вещи. Вещи, на которые можно не только смотреть, но и трогать их, погружаться в них, вкушать их, думать о них: Море... Долины... Цветы... Близкие люди... Неизвестные страны... Таинственные отношения... Простая радость бытия... Еда и Музыка... Женщина...
И материя, и дух – сама жизнь интересует и вдохновляет художника.
В процессе подготовки выставки у нас были размышления – как точнее ее назвать, как не испортить впечатления, навязывая слишком модное, или громкое, или интригующее название. И как в работах, так и в названии проекта, нам удалось совпасть с автором и уйти от напускной значимости.
«Я Выбираю…»
Именно так строится наша жизнь и, тем более, жизнь художника. Олег Подкопаев не так давно встал на этот Путь-к-себе и он выбирает – что писать. Как это писать? Он слушает свой внутренний камертон, чтобы остаться честным с самим собой: осталось ли волнение после завершения работы, будет ли его самого «бить искра» после проникновения в суть оттенков, после часов создания формы перед мольбертом, после проживания заново моментов встречи с Чужими, или с самим собой в часы написания Автопортрета. Или со своими фантазиями о Музыке, Женщине… Бьёт ли ИСКРА?
Мы видим – бьёт!
Мощность цвета, смелость колористики и уже узнаваемый выбор оттенков, сформировавшаяся характерная подкопаевская сила мазка. Да? Осознанный выбор не-реалистичности, склонность к витализации (оживлению) – посмотрите на харАктерные цветы Подкопаева, на их хищные зазывные позы, на соблазняющую «фигуру» курицы «Съешь меня», на «пришедшие» на сеанс Ботинки («Подражая Ван Гогу »). Пейзажи, люди, цветы – все живет полной жизнью, таит в себе обе части нашего мира - Свет и Тьму.
Каждый из нас каждый день выбирает. Олег Подкопаев, вслед за многими именитыми художниками и пользуясь их маяками и ориентирами, тоже выбирает. И заодно показывает нам свою дорогу, приглашая и нас - смотреть и принимать это многообразие мира и чувствовать биение Вселенной в каждом мгновении жизни.
И намек для зрителя: во многих зреет талант, но дать ему выход может только наше внутреннее решение: найти время, учителя, купить краски. И спросить Художника – с чего начать?
И еще: Олег Подкопаев серьезно стал заниматься живописью недавно, будучи уже взрослым человеком, признанным в не-художественной профессии. Вторая выставка – и сильный результат.
Выставочный проект реализован при поддержке замечательных надежных людей – компании ЮНИТ-Оргтехника , которые знают цену творческой энергии и ее влиянию на «бизнес без остановок».
Проект осуществлен Продюсерской группой «Щука» , одной из миссий которой является поддержание и развитие личного творчества в рамках проекта «Второе призвание». Помните, «с детства я мечтал стать...»? Если это касается творчества - ПГ «Щука» за то, чтобы сбывались мечты!
Выставка «Я Выбираю…» продлится с 19 по 28 сентября 2013 года.
Галерея «Коносьеръ» открыта для зрителей пн-пт 11.00 – 19.00 , сб 12.00 – 18.00, вход - свободный
Наша справка.
Олег Подкопаев. родился в 1969 году в Москве.
Закончил в 1992 году Московский институт радиотехники, электроники и автоматики по специальности «Электронные вычислительные машины». В 2004 году успешно сдал экзамен на звание Certified Information System Auditor. Лауреат национальной ежегодной премии IT Лидер 2007 «За выдающийся вклад в развитие информационных технологий в России».
Более 15 лет работает в сфере информационных технологий, из них 8 лет занимался разработкой и внедрением западных банковских систем в России, Словакии, Венгрии, Бельгии и Англии, пройдя путь от разработчика до руководителя проектов. В 2001-2003 году работал в Управлении банковских технологий Банка Москвы. В 2003-2004 годах возглавлял Управление информационных технологий, а затем Департамент информационных и банковских технологий КМБ-Банка.
С 2004 года и по настоящее время - директор Департамента информационных технологий группы Русфинанс. За время его работы в группе проведено развертывание контакт-центра, насчитывающего более 750 рабочих мест и обеспечивающего обслуживание более 2,5 миллионов телефонных звонков в месяц. Разработана и внедрена инфраструктура, поддерживающая функционирование 60 региональных представительств и более 10 тысяч точек продаж. Успешно проведена инфраструктурная, технологическая и организационная интеграция в рамках группы Русфинанс ООО Русфинанс, Промэк-Банка и банка СКТ. Осуществлено внедрение прикладной архитектуры, обеспечивающей на данный момент обработку более 1,5 миллионов кредитов.
- - Не так давно произошла очередная история с мошенничествами вокруг банкоматов. Естественно, подобная информации всегда вызывает определенный всплеск панических настроений. И вопрос «А безопасна ли моя банковская карта?» Что сегодня происходит на рынке в этом плане, какие тенденции?
Что вообще происходит в этой области? Все просто - идет гонка технологий, совершенно осознанная, понятная. С одной стороны, существуют системы безопасности, существуют банковские подразделения, которые обеспечивают эту безопасность, с другой - существуют люди, которые корысти или даже просто интереса ради занимаются взламыванием банковских систем.
То есть это не гонка конкурентов, а гонка банков и мошенников, этакие «казаки-разбойники» в компьютерном пространстве?
Да. Я очень далек от мысли, что в этой сфере банки пытаются подложить какую-то «бяку» друг другу. В недавнем случае с Росбанком это были явно мошенники, которые запустили вирус, который «крал» пин-коды. О реальном снятии денег со счета там разговора не было, он просто считывал номера карточек и пин-кодов.
Профилактика тут известна - существуют различные варианты, начиная от технических мероприятий и заканчивая чисто организационными. Например, та же VISA отслеживает компрометацию данных по всему миру и периодически целенаправленно информирует банки, которые по сообщению той же самой VISA блокируют определенные карты.
Как вы полагаете, эта «война» хакеров и банков теперь стала постоянной парадигмой? Так и будет процесс дальше двигаться: одни написали, другие ответили?
Думаю, да. И это в общем-то нормально. Ну, вы знаете, наверное, как работает, например, Мicrosoft. Они выпускают какую-то версию программного обеспечения и отдают хакерам. Те начинают ее бить, публикуется большое количество различных статей, различных комментариев по этому поводу, где описаны слабые места. И Мicrosoft, базируясь на этом, начинают усиливать программу, делать ее менее доступной хакерам. Абсолютная недоступность невозможно априори, предусмотреть все возможные варианты просто невозможно.
А в целом тема IT-безопасности банкинга в каком сегодня состоянии на россйиском рынке? Не секрет, что на заре рождения коммерческого банкинга в России концепция безопасности, если упрощать, в общем-то сводилась к мужичкам в форме с пистолетами или с пустой кобурой, которые сидели в офисах. Ну, еще к инкассаторам и телохранителям владельца. Последние годы понимание, что часто более главным становится безопасность информационная, IT-безопасность, стало как-то проявляться. Как сегодня обстоят дела глазами IT-шника?
Здесь нужно смотреть на различные аспекты. Серьезные, крупные банки по сути своей изначально очень серьезно были заточены на безопасность. Действительно, изначально это были прежде всего «люди в погонах», которые, грубо говоря, шмонали всех и вся на входе, гоняли людей по всевозможным «стаканам» или размагничивающим «рамкам».
Но надо отметить, что классические спецы по безопасности довольно быстро поняли значение безопасности информационной. А банковские IT-шники опять-таки в силу понимания специфики своей работы всегда старались обеспечивать безопасность своих систем. Пусть это было достаточно хаотично, до последнего времени не существовало никаких регламентирующих документов на этот счет, но процесс шел.
Сейчас существует стандарт Банка России в отношении информационной безопасности. Пока он носит рекомендательный характер, он не обязателен к использованию, но, думаю, это некий предварительный шаг для «обкатки». Потому что давать сейчас какой-то стандарт, который будет обязателен к исполнению, было бы наивно, учитывая, что до недавнего времени вообще ничего не было и каждый банк строил систему информационной безопасности по своему.
А на Западе такие стандарты существуют?
Но на российском рынке банки только начинают к нему примериваться. Например, у нас в группе Sosiete General есть свои внутренние стандарты информационной безопасности, начиная от организационной и заканчивая технической реализацией. Они строго контролируются, у нас есть регулярные аудиты, проверки и т.д.
Они по всей группе единообразны?
Да, единообразны по всей группе, есть совершенно четкие условия, по которым мы должны работать, начиная от возможности доступа в интернет и заканчивая конкретными техниками коммуникаций.
Плюс, естественно, мы смотрим на какую-то страновую специфику. Например, в отношении трансграничной передачи данных в той же самой Украине особые, очень жесткие требования. Или в процессе защиты персональных данных в некоторых странах требования доходят вплоть до экранирования серверных комнат. Естественно, мы работаем с учетом требования тех стран, где расположены подразделения группы.
С появлением в России закона № 152-ФЗ о персональных данных возникают свои требования и на нашем рынке.
То есть вы как практик в принципе довольны тем направлением, в котором движется ЦБ?
На самом деле здесь вопрос очень сложный. Было проведено некоторое исследование, которое показало, что 95% банков не то чтобы не готовы, но не понимают, как именно они должны реализовать требования закона № 152-ФЗ. При этом надо осознавать, что ЦБ в этом процессе не является регулятором. Регуляторами являются Роскомсвязьнадзор совместно с ФСТЭК, которые устанавливают правила игры. При этом часть документов, регламентирующих исполнение закона, в принципе недоступны широкой публике, они под грифом «ДСП». То есть возник определенный вакуум - не существует единой методики по оценке соответствия банков требованиям закона 152-ФЗ. И роль ЦБ в этом деле пока не очень понятна, его регулирующая роль не обозначена.
Если ЦБ вместе с Роскомсвязьнадзором разработают четкую систему требований, но вопросы, которые сейчас непонятны, думаю, будут разрешены.
В последнее время все чаще и чаще звучит тема развития интернет-банкинга. Думаю, многие пользователя банковских услуг, как и я, уже проделали эволюцию от обслуживания в офисе до работы через банковский сайт. Эта эволюция накладывает на банковский IT какую-то принципиально новую нагрузку? Работа меняется?
Непринципиально. IT в любом случае для любого банка является базой всех процессов, без IT в принципе невозможно представить себе банк. Поэтому фокус на IT всегда был и останется большой, даже если не учитывать интернет-банкинг. В любом случае, даже если вы зашли не на сайт, а в офисе, клерк будет работать через компьютерную систему. Иных вариантов уже нет. Так что развитие интернет-банкинга ничего нового не привносит, разве что поддержку и развитие самих сайтов, которые раньше были просто «визитными карточками» банков, а теперь становятся «офисами номер один». Плюс с развитием интернет-банкинга возникает дополнительный момент, связанный как раз с безопасностью, о которой мы говорили. Это дополнительный канал входа в банк, который должен быть надежно защищен.
Вот в связи с этим - вопрос «чайника». Помните, в «Крепком орешке-4» разыгран сюжет с так называемым обрушением? Если рассуждать теоретически - можно ли сегодня банк обрушить?
С внешней стороны - едва ли. Я помню разговор с одним военным, который смеялся над информацией из США, мол, там периодически сообщают, что взломали сайт Пентагона, ЦРУ и т.п. Он сказал: у нас такого быть не может просто потому, что у нас система закрытая и замкнутая. В нее просто нет входа, нет «двери». В банках в принципе тоже самое. Если мы говорим про операционную систему банков, то она практически полностью изолирована от внешнего мира. А доступный всем интернет-банкинг - это совершенно изолированная от операционной система. То есть можно положить интернет, но через него вы не доберетесь до операционной системы. Конечно, отдельные проблемы возможны.
Недавний пример Банка Москвы, одного из клиентов которого недавно осудили. Он скачал деньги, совершенно случайно получив через интернет-банк доступ к внутрибанковским счетам. Честно скажу: я до сих не представляю, как это возможно. Но ведь его и вычислили и блокировали.
Если же посмотреть на более реальные угрозы, то сегодня основной угрозой для банка является инсайдер. Вот инсайдер - какой-нибудь обидевшийся сотрудник определенного уровня - «положить банк» может достаточно легко.
А насколько сегодняшний среднестатистический банковский персонал вообще «компьютерно» подготовлен?
А нет такого понятия - «среднестатистический банковский персонал». Он очень разный. Если вы посмотрите на персонал центрального офиса любого банка, то эти люди достаточно хорошо подкованы. Человек, работающий в центральном офисе, обычно очень хорошо владеет компьютерными премудростями на уровне пользователя и тут проблем больших не возникает. Если же мы посмотрим на отделения, то там ситуация кардинально другая. Там, разумеется, совершено другие люди, другой квалификации. Вот с ними, действительно, проблема. Обычно на компьютер они смотрят с ужасом. В лучшем случае они хорошо знают банковский продукт, с которым работают, и с компьютером общаются в рамках тех процедур, которые оговорены, не допуская шаг влево, шаг вправо.
И не думаю, что скоро будет какое-то принципиальное улучшение. Оно будет тогда, когда по всей стране всерьез повысится компьютерная грамотность.
Вообще человеческий фактор в IT-процесса банкинга как сказывается?
Человеческий фактор очень важен, Если вы посмотрите на большие банки, то в таких банках IT - это производство, здесь все очень серьезно зарегулировано, люди становятся в хорошем смысле винтиками некой операционной машины. В маленьких банках, где каждый практически работник IT-службы является эникейщиком - там очень большая зависимость от конкретного человека, который и создает программное обеспечение, и ставит его на машины, он же является администратором и т.д. Так что если у этого человека завтра плохое настроение или похмелье, то он, в общем-то, «убить банк» может легким движением руки.
Стало быть, от подобного «универсализма» банки уходят???
Конечно. В тех банках, которые серьезно строят свое IT-подразделение, есть автономное операционное подразделение, которое занимается эксплуатацией. Отдельно работают разработчики продукта, отдельно - администраторы. То есть IT-служба современного банка уже не единое целое, а состоит из различных, вполне самостоятельных подразделений.
А людей где берете? Известно ведь, что с точки зрения кадров IT в России - тяжелый случай. И как с учетом этой общей «разгильдяйско-творческой атмосферы» отечественных компьютерщиков находите людей, которые годны к работе в банке?
Да, традиционно «IT-человек» - это человек творческий, сродни художнику, этакий человек не от мира сего в рванных джинсах и с хвостиком на голове. Понятно, что с таким типажом строить промышленные системы очень сложно
Как правило, здесь есть два варианта.
Например, человек вырастает, эволюционирует, принимает корпоративные правила игры. Скажу честно, ко мне приходили такие ребята в рваных джинсах и с немытыми волосами, но, работая в коллективе, многие изменились и сейчас это люди совершенно нормальные, адекватные. Если при этом это люди, воспринявшие корпоративную культуру, достаточно широкого кругозора, то многие из них, пройдя определенный тренинг, переходят на уровень менеджера, руководителя и т.п.
Некоторые остаются на определенным уровне, но и, соответственно, остается на таком уровне область их деятельности. Нельзя действительно требовать от каждого человека, чтобы он приходил на работу в костюме и галстуке, иногда это невозможно по сути самой работы, когда приходится лазить под столами, прокладывая кабель, или менять тонер в принтере. Но если человек хочет расти, он даже в таком случае, приняв правила игры и корпоративной культуры, сможет себя показать.
Другой вариант, - это консультанты. Сейчас достаточно активно формируется именно такой пласт специалистов. Это изначально «бизнес ориентированные» ИТшники, причем не важно какой специализации (программисты, инфраструктурщики, аналитики). У них совершенно другое мировоззрение: они уже менее художники и более прагматики.
Конечно, еще все зависит от того, какую вы планку ставите. То есть мы сначала выставляем планочку достаточно высоко, потому что у нас, в общем, это позволяет и уровень оплаты и интересная работа. Если мы видим, что под эту планку народ не находится, можем ее начать снижать потихонечку. Тогда начинает работать принцип: «Если на рынке нет подходящих нам кадров, возьмем менее подходящих и сами воспитаем».
Есть еще вариант аутсорсинга. Мы часто на определенные проекты либо привлекаем временный персонал, либо отдаем на подряд сторонней компании.
Насколько я слышал, вы именно так ухитрились реализовать проект по запуску револьверных карт на базе TietoEnator Card Suite в качестве бэк-офисной системы? Привлекли сторонне компании и при этом в какие-то рекордно короткие сроки…
Да, на самом деле, у нас два таких очень запоминающихся проекта, на которых мы отработали очень интересную технологию.
Первый проект - это был проект с компанией TietoEnator по внедрению карточного бэк-офиса. Основная проблема этого проекта была в том, что нам нужно было вложиться в совершенно немыслимые сроки - пять месяцев. А делали все «с нуля» и в проекте было огромное количество участников и поставщиков - фронтальная система, бухгалтерская система, хранилище, отчетность, процессинговый центр, центр по выпуску карт, масс-мейлинг и т.д. и т.п.
Когда мы попытались это как-то спланировать, то пришли к так называемой «СОА-организации проекта». Понятно, что СОА концепция и раньше применялась, но в основном с точки зрения технической, интеграционной оплетки проекта. Мы же применили те же принципы на более высоком уровне. Для начала мы четко обозначили и расписали те бизнес-сервисы, которые должны были быть в рамках проекта внедрены. На внешнем уровне это - выдача кредитов, оформление карт. На внутреннем - непосредственно выпуск самой карты. На операционном - осуществление транзакций, обслуживание кредита и т.д.
Было понятно, что все эти сервисы единомоментно не нужны, между оформлением карты и первой транзакцией проходит, как правило, месяц: пока карта выпустится, пока будет отослана клиенту, пока он ее активирует и т.д.
И это позволяло сделать такой маневр - запускать все составляющие части проекта не единомоментно, а по очереди. То есть запустить первый сервис - выдачу карт, а затем поэтапно все остальное. Получилось, что реально выдача карт должна заработать через пять месяцев, а остальное - чуть позже. И это дало нам необходимое время.
Тут есть, естественно, большой риск, что, запустив первый сервис, вы следующий можете не успеть. Поэтому важно адекватно оценивать свои собственные силы и четко расписать календарный план по всем сервисам, чтобы видеть, не намечается ли где отставание.
Второй принципиальный момент. Из-за сжатых сроков мы понимали, что, если отдадим весь этот проект на откуп одному поставщику, то он его точно не успеет сделать. И в общем-то влиять на него будет сложно, поскольку это будет один поставщик, полная зависимость. И мы решили реализовывать всю работу как СОА проект, нанимая подрядчиков на отдельные его части.
Причем части абсолютно автономные, не пересекающие. Был один интегратор, который их связывал по мере готовности. Это успешно работало на проекте с револьверными картами на базе TietoEnator Card Suite, и это сработало на следующем проекте - внедрении системы Misys Equation в качестве бэк-офисной системы для сопровождения потребительских кредитов.
Тут у нас опять таки были очень сжатые сроки, и мы пригласили к участию две компании, которые на рынке являются жесткими конкурентами. Когда мы это планировали, ко мне приходили умные люди и говорили: «Не делай этого, они не будут работать вместе, они просто станут собачиться и перекидывать друг на друга проблемы. Ничего хорошего не выйдет и проект развалится».
Однако мы очень строго определили зоны ответственности обеих компаний. Они попросту не могли залезть на «территорию» друг друга. Попытались было, но потом увидели, что нет места для конфликта и все очень четко сделали.
А даты этих проектов?
TietoEnator Card Suite мы начали внедрять в марте 2007 года, первый кредит был выдан уже в июле 2007 года. А Misys Equation начался осенью 2007 года, в апреле 2008 года система уже работала, сейчас в ней обслуживаются более 700 тысяч кредитов.
Логичный вопрос: вы в эти месяцы как спали?
Абсолютно нормально. У нас принцип такой: народ с работы уходит вовремя. Чтобы задерживались позже семи часов - такое очень редко бывает.
То есть, конечно, были авралы перед самым запуском. Ну, это как всегда бывает. Но вообще я считаю так: если мои сотрудники работают больше чем положенные восемь часов, значит, я просто неправильно планирую.
Хотя иногда довольно сложно понять, почему у тебя сотрудник сидит до 8-9 часов вечера. Возникает вопрос: он сидит почему, потому что у него работы много или потому что производительность маленькая? И вот здесь важно не ошибиться, потому что иначе можно стимулировать плохого сотрудника или наказать хорошего.
Расскажите о создании контакт-центра «Русфинанса». Он ведь тоже строился в довольно короткие сроки?
Изначально да, но само развитие, и функциональное, и объемное, происходит до сих пор. Первые рабочие места контакт-центра заработали еще в 2004 году в Москве. Затем, в рамках интеграции с Промэк-Банком, контакт-центр был разделен на две примерно одинаковые части между Москвой и Самарой. При этом обе части контакт-центра полностью технически совместимы и взаимозаменяемы, и базируются на единой телекоммуникационной инфраструктуре, покрывающей 60 регионов России. На данный момент в контакт-центре функционирует более 750 рабочих мест в режиме 24х7, обслуживающих более 2,5 миллионов контактов ежемесячно, включая функционал обработки входящих и исходящих звонков, автоматический обзвон, IVR, SMS и т.д.
Поскольку контакт-центр для нас в первую очередь бизнес-инструмент, с помощью которого мы стремимся повысить лояльность наших клиентов, а, следовательно, и доход компании, проекты по модернизации идут постоянно. Совсем недавно компания КРОК установила для нас систему записи и контроля качества ZOOM, которая позволяет не только повысить качество работы операторов, но и может быть использована для разрешения возможных конфликтных ситуаций. Кстати, это первый подобный проект в России.
Можно как-то обобщенно сформулировать, в чем вообще измеряется эффективность IT в банке? Вот вы внедрили два проекта, они интересны технологически, они иновационны с точки зрения организации. Вам и вашим коллегам это понятно и вызывает удовольствие. А вот, допустим, тут прихожу я, совладелец вашего банка, и говорю: «Клево, конечно, тиетенатор там и все такое, но что мне-то это дает?» Как вы ответите на подобный вопрос?
Да, это важный момент. Как известно, у IT-директора всегда есть большая проблема при создании ИТ-стратегии и этого самого IT-бюджета. Причем, для самого ИТ-директора в составлении и понимании проблем нет, основная задача адекватно донести это до бизнеса, до руководства.
Естественно, любая ИТ-стратегия базируется на бизнес-стратегии, на тех задачах, которые бизнес ставит перед ИТ. Чтобы показать четкую зависимость этих задач и ИТ решений, мы используем понятие бизнес-сервисов, их характеристик и KPI, их стоимости, и на основании именно этих данных мы говорим с бизнесом.
Для той или иной реализации бизнес-сервиса необходима соответствующая работа ИТ-сервисов, прикладных и инфраструктурных. Построив такие зависимости, мы получаем дерево ИТ-сервисов, где у каждой вершины (сервиса) есть свои качественные и стоимостные характеристики. Таким образом, зная KPI на бизнес уровне, пройдя по дереву сервисов сверху вниз, можно проставить KPI по ИТ сервисам, а затем, пройдя снизу вверх, понять какие проекты и задачи мы должны выполнить, чтобы достигнуть заданных величин, и сколько это будет стоить. Соответственно, стратегия и бюджет формируются из трех составляющих: baseline - это то, что требуется для поддержания текущего статус-кво; growth - поддержка объемного роста бизнеса; development - качественная поддержка бизнес задач (ввод новых сервисов, либо изменение характеристик существующих)
У нас есть институты аккаунт-менеджеров IT-службы, то есть каждому направлению (сейчас их 12) работы банка есть специальный человек, в задачи которого входит коммуникация со своим направлениям - нашим «внутренним клиентом», То есть, с одной стороны, его задача - правильно «продать IT-услуги» тому или иному направлению, а с другой - видеть потребности «своего направления», быть глашатаем его интересов в ITслужбе. Соответственно, эти люди и формируют ИТ-стратегию по каждому направлению, и потом это собирается воедино.
То есть это своего рода модератор в коммуникациях бизнеса и IT-службы?
Да. Это позволяет находить общий язык и ясно представлять, что нужно тому или иному банковскому подразделению.
Этот подход он классический для банков?
Не вполне. Это наше ноу-хау, мы это строили два года, и он сейчас реально работает. В нашей ситуации он особенно актуален: наш IT-департамент один обслуживает на данный момент шесть юридических лиц.
Кризис как-то сказался на банковских IT-службах?
С точки зрения принципов работы не изменилось ничего. Основная задача IT - соответствовать бизнес-стратегии. Поменялась бизнес-стратегия, значит, просто ставятся иные задачи. Скажем, на рынке тормозится кредитование, в этом направлении ресурсов надо меньше, вы переключаетесь на работу с просроченной задолженностью.
По сути, просто тумблером щелкнули.
А если возникает тема пресловутого урезания бюджетов. Например, приходит IT-директор некоего банка в правление и говорит: пока рынок стоит, самое время воспользоваться моментом и модернизировать нашу систему, готовясь к новому старту. А ему в ответ: «Уйди отсюда, сейчас вообще не до тебя». Возможно такое?
Вот здесь возникает важный вопрос - в чем различие между «просто» IT-директором и CIO. IT-директор - это еще технарь, он имеет право мыслить в технологических понятиях. А CIO это право не имеет, он должен мыслить с точки зрения бизнеса. И выходить с предложениями, адекватными бизнесу. И здесь опять на первое место выходит качество коммуникаций. Основная задача CIO - это коммуницировать с руководством банка. И если вы, рассматривая тот или иной проект с точки зрения интересов бизнеса и придя к выводу, что его все-таки надо реализовать, не сумели убедить в этом правление банка, то как CIO грош вам цена.
Хороший CIO сродни классному дипломату, политику и продавцу в одном лице, он должен четко и понятно объяснять бизнесу, что нужно сделать для того, чтобы этот бизнес развивался с точки зрения IT. Проблемы возникают, если у вас изначально не было построено такой коммуникации. А если у вас коммуникация изначально была, то вам достаточно легко находить общий язык.
Вопрос «для проверки». У вас есть сейчас в работе IT-проект в необходимости которого вы убедили банк несмотря на кризис и стагнацию рынка?
У нас есть такой проект. Сейчас идет проект построения BСP (обеспечение непрерывности бизнеса), в рамках которого внедряются системы хранения для основного и резервного дата-центров банка.
Мы рассматривали этот проект именно в конце прошлого года, когда уже понятно было, что кризис на дворе, пришли к тому, что имеет смысл его делать. А вот, например, проект замены фронтальной системы по выдаче кредитов мы осознанно отложили, поскольку при тех объемах кредитования, которые российский рынок ожидают в этом году, смысла в нем нет.
В целом же надо сказать, что кризис - не повод отказываться от IT-продвижения и как-то замирать в испуге. Наоборот, это в определенном смысле шанс сработать на опережение, подготовив новые решения, проекты и идеи. Если все они будут грамотны, то, в конечном счете, все окупится сторицей.
Взаимодействие ИТ-департамента и бизнес-подразделений, переход к сервисной модели, участие в оптимизации бизнес-процессов — задачи актуальные для большинства крупных и средних российских компаний. О том, как их решают в группе «Русфинанс», рассказывает её CIO Олег Подкопаев.
Родился в 1969 году в Москве, в 1992-м закончил Московский институт радиотехники, электроники и автоматики по специальности «Электронные вычислительные машины».
В 2004-м успешно сдал экзамен на звание Certified Information System Auditor.
В сфере информационных технологий работает более 15 лет, восемь из которых занимался созданием и внедрением западных банковских систем в России, Словакии, Венгрии, Бельгии и Англии, пройдя путь от разработчика до руководителя проектов.
В 2001-2003 годах работал в Управлении банковских технологий Банка Москвы.
В 2003-2004-м возглавлял Управление информационных технологий, а затем Департамент информационных и банковских технологий КМБ-Банка.
С 2004-го по настоящее время является CIO группы «Русфинанс».
Лауреат национальной ежегодной премии IT Лидер 2007 «За выдающийся вклад в развитие информационных технологий в России».
Intelligent Enterprise: Каким образом вы планируете развитие ИТ-систем, на что опираетесь при разработке ИТ-стратегии?
Олег Подкопаев: Наша ИТ-стратегия состоит из трех основных блоков. Первый - базовый уровень. Тут мы определяем, что необходимо для поддержания бизнеса в его нынешнем состоянии. С точки зрения бюджета это не инвестиции, а затраты, причем те, поступаться которыми крайне нежелательно. Второй - поддержка планов бизнеса по развитию. Здесь мы говорим о том, каким образом можно поддержать намерения бизнес-подразделений и их проекты, т. е. бизнес-стратегию. Сюда относятся новые продуктовые линейки, новые продукты и модификации существующих. Основой для планирования являются соответствующие планы бизнес-подразделений с цифрами и списками продуктов, а также планы по персоналу и точкам присутствия. Этот раздел стратегии в свою очередь состоит из двух частей - объемной и проектной. Объемная часть в основном направлена на прямую поддержку увеличения объемов продаж, количества точек и персонала, и расчет здесь довольно простой, арифметический. Зная стандартные конфигурации и нормативы, мы соотносим их с объемом бизнеса и определяем, что надо сделать и сколько это будет стоить. С проектами сложнее, поскольку здесь продуктовые параметры нужно перевести в функционал бизнес-систем, в необходимые изменения прикладной и системной архитектур, в модификации инфраструктуры и все это скомпоновать в проекты, логичные с точки зрения передовых ИТ.
Наконец третий блок - «экстра». Это суперпроекты, экстраразвитие - нечто такое, что на наш взгляд позволит бизнесу развиваться быстрее, или повысит его эффективность, или даст какие-то дополнительные преимущества.
Эти три блока формируют стратегию, которую мы затем защищаем. Бизнес должен понять, что и почему мы собираемся делать, и расставить приоритеты. Дискуссии бывают весьма бурными, поскольку ви’дение проблем и решений у ИТ-департамента и у бизнес-подразделений зачастую заметно различается. И тут свою роль играет деление на три упомянутых блока. В отношении первого блока мы готовы спорить и отстаивать свою точку зрения очень жестко, так как по нашему мнению в него входит то, что совершенно необходимо и без чего обойтись нельзя, и урезанию он практически не подлежит. Второму блоку мы уделяем самое пристальное внимание, поскольку должны показать и доказать бизнесу, что если он хочет заниматься тем, что намечено с точки зрения развития, то предлагаемое нами ИТ-обеспечение совершенно необходимо. Тут бизнес-менеджерам нужно хорошо разобраться и понять эту связь, и наша задача - правильно всё объяснить. Третий блок обычно представляется совместно с конкретными бизнес-заказчиками, но, к сожалению, это не всегда помогает, поскольку речь здесь всегда идет о чем-то очень «продвинутом» и зачастую дорогом, и, как правило, именно эта часть и подвергается урезанию.
После того как стратегия принимается, нужно тщательно следить за тем, чтобы ей соответствовали реальные шаги, оперативное планирование. Ведь бывает так, что по результатам проекта эффект получается не такой, как ожидалось или задумывалось. Для этого чрезвычайно важно управлять коммуникациями, наладить обратную связь с бизнес-подразделениями.
Как вы этого добиваетесь?
Мы стараемся работать на основе сервисно-ориентированной модели, выступая как некий «поставщик», предоставляющий сервисы своему «заказчику» - бизнесу. Соответственно чтобы успешно работать с заказчиком, необходимо выстроить коммуникации с ним, и для этой цели у нас внедрен институт эккаунт-менеджеров (account manager). Это сотрудники ИТ-департамента, постоянно работающие с определенными бизнес-направлениями. Они опеспечивают связь ИТ-службы с заказчиком - скажем, с департаментом автокредитования или каким-то другим отделом. Именно эккаунт-менеджеры согласуют состав и уровень сервисов, которые мы предоставляем бизнесу, контролируют исполнение проектов, представляют заказчику всю необходимую информацию. Очень важно, что эти люди говорят на языке бизнеса. Например, совершенно бессмысленно говорить бизнесу о «доступности каналов связи до офиса продаж в течение 99,9% времени» - в любом случае там поймут это по-своему. Но фраза типа «вы сможете в этой точке выдавать кредиты по схеме 24×7 с одним часом простоя в две недели в среднем» для функциональных заказчиков вполне ясна и приемлема. Все вопросы о работоспособности приложений мы проговариваем и объясняем в таком же ключе, и это позволяет достичь ясности и однозначного понимания.
Когда мы стали внедрять понятие сервисов, конечно же мы начали с ИТ-сервисов, говорили о доступности линий, приложений и проч. Это вводный этап, когда бизнес приучается к понятиям сервисов, SLA (service level agreement) и учится взаимодействовать с ИТ, а ИТ, в свою очередь, - с бизнесом. С бизнес-подразделениями организуются регулярные встречи, где представляются численные параметры (KPI) качества ИТ-сервисов, обсуждаются отклонения от желаемых значений, планируются корректирующие действия, устанавливаются целевые показатели.
Этот технический язык в принципе работает, для бизнеса понятна техническая нотация (т. е. ее можно объяснить), термины ИТ вполне доступны, но далеко не комфортны. Поэтому сейчас мы переходим на трехуровневую модель сервисов. Самый верхний уровень - бизнес-сервисы. Они показывают бизнесу, что’ он будет иметь от ИТ и сколько это может стоить. Например, сервис выдачи кредитов. У него есть характеристики: время выдачи, режим работы (24×7, 8×5), непрерывность, срок восстановления после сбоя и другие KPI. Такую систему KPI мы уже внедрили для департамента автокредитования, этот подход у нас активно развивается и в других сферах деятельности и новостью ни для кого в компании не является.
Нижележащий уровень - собственно ИТ-сервисы. Сейчас мы перешли к этапу, на котором на этом языке эккаунт-менеджеры, договорившись с бизнесом, разговаривают уже внутри ИТ-службы. Согласовав уровни сервиса с бизнесом, эккаунт-менеджер транслирует их на этот уровень. Скажем, чтобы выдавать кредиты, должно быть доступно определенное приложение, нужно, чтобы функционировала телефония и были рабочие места. Это минимальный набор, с которым действуют менеджеры приложений (application manager), отвечающие за работоспособность определенного ПО. Здесь возникают ограничения. Например, менеджер приложений говорит: «Я не могу обеспечить доступность 24×7, поскольку мне ежедневно нужно часовое технологическое окно, чтобы сделать бэкап». Если же тем не менее нужно 24×7, то на время этих технологических перерывов мы должны предусмотреть онлайновую синхронизацию.
На следующем уровне - менеджеры по инфраструктуре (infrastructure manager), которые отвечают непосредственно за работоспособность серверов, сетей и телефонии. С ними доступность сервисов также согласовывается, и на уровень бизнеса вновь отправляются согласованные предложения ИТ-службы о реальном уровне доступности сервисов и о мерах, необходимых для их обеспечения. Принципиально важно, что при этом для бизнеса есть один контакт, одна точка входа - его эккаунт-менеджер. Он строит дерево сервисов и их показателей как сверху вниз, так и в обратном направлении - вначале согласовав с бизнесом KPI, дальше транслирует их на уровни приложений и инфраструктуры. Затем мы измеряем реальные уровни сервиса и говорим: KPI на данном уровне такие-то. Для расчёта у нас есть экспертные оценки, цифры сторонних провайдеров и наши собственные системы мониторинга. Эккаунт-менеджер передаёт собранные сведения бизнесу и сообщает, какие реальные значения KPI возможны. Ну а дальше начинаются переговоры. Если требуются существенные улучшения по сравнению с текущим положением, обсуждаются соответствующие изменения бюджета.
Бюджетирование ведется тоже с опорой на сервисы?
При нашем подходе практически реализуется схема «заказчик - подрядчик - субпорядчики». Этим можно было бы ограничиться, если бы речь шла о полном аутсорсинге, полном разделении компании и ее ИТ-службы. Но обычно этого не бывает. Руководству недостаточно знать, что на обеспечение таких-то сервисов будет потрачено столько-то денег. Они хотят точных данных, на что конкретно будут потрачены средства. Поэтому возникает вторая задача: не ограничиваясь сервисным подходом, обосновать необходимость ИТ-проектов и тех затрат, которые они повлекут. Например, мы должны сказать четко: мы собираемся провести проект по внедрению такой-то системы, поскольку она необходима для таких-то бизнес-целей, и нужно определить бюджет и сроки. Так что ограничиться сервисным подходом на данном этапе невозможно, а говорить лишь о проектах тоже нельзя. Поэтому при обсуждении стратегии и вытекающего из нее бюджета необходимо соблюдать своеобразный дуализм, опираться и на сервисный, и на проектный подход. Бюджет тоже рассматривается в двух направлениях. Во-первых, по конкретному проекту. Во-вторых, он проецируется на бизнес-направление, и мы видим, сколько мы тратим на поддержку этого направления. Таким образом, у нас есть как минимум два взгляда на общую картину.
Определяя бюджет для первого блока стратегии (базовый уровень), мы опираемся на статистику прошлогоднего бюджета. Дальше (для двух последующих блоков) следует важный момент: как транслировать бизнес-требования в айтишные проекты. Для этих разъяснений мы выбираем куски ИТ-стратегии, которые транслируются более-менее логично. Например, для выдачи кредитов нужно ускорить время их рассмотрения, сделать более доступную систему, нужны определенные возможности по демонстрации продуктов; поэтому мы переходим на новое приложение для выдачи кредитов. И бизнесу это понятно.
А дальше мы видим: чтобы такая новая система нормально работала, нужны подходящие серверы, она должна быть интегрирована в существующую структуру, все это следует расположить в приемлемом датацентре с резервным копированием и так далее - так и выстраивается цепочка. Мы открыто кладем карты на стол и объясняем руководству и бизнесу (нашим спонсорам и заказчикам), зачем в этой цепочке нужен каждый элемент. И так по всем пунктам, по всем планам бизнес-подразделений.
В частности, поэтому мы ушли от исключительно постатейного бюджета на оборудование, ПО, зарплату и т. д. и включили компоновку бюджета с привязкой к отдельным проектам. Только в первом блоке бюджетирование постатейное, поскольку каждая статья показывает конкретное направление деятельности - скажем, не просто телефонные линии, а линии подключения к определенному офису. А все остальное финансирование идет по проектам. После защиты бюджета мы, конечно, разделяем его по статьям, удобным для бухгалтерии, но это уже чисто техническая процедура. Но защищаем мы бюджет и потом отчитываемся на проектной основе.
Сложно ли объяснить функциональным заказчикам преимущества сервисного подхода к ИТ? С какими проблемами вы сталкиваетесь, переводя взаимодействие на сервисную модель?
Объяснить бизнесу, зачем нужен сервисный подход в области ИТ, по моему опыту проще, чем объяснить это сотрудникам ИТ-службы. Казалось бы, должно быть наоборот, айтишники должны иметь представление об ITIL и связанных с этим подходах, но это не вполне так.
Несмотря на свое несколько потребительское отношение к ИТ бизнес все же тянется к общению. Его представителям нравится, когда есть менеджер, который постоянно в курсе их проблем и заботится о них. Есть кто-то, кому можно позвонить и он решит вопросы, а если надо, объяснит, что к чему и как лучше сделать. Это напоминает обычные и привычные взаимоотношения в деловой среде между заказчиками и подрядчиками. С другой стороны, KPI, SLA упрощают контроль, делают его более прозрачным. Контроль на понятийном уровне, качественные оценки «хорошо - плохо» не дают такого эффекта, скорее приводят к шантажу со стороны бизнеса. При сервисном подходе мы сами приходим и предлагаем параметры, по которым нас можно контролировать. Важно, что эккаунт-менеджеры - это сотрудники, выделенные исключительно для общения с бизнесом. Никаких других обязанностей, совмещения функций внутри ИТ-службы у них нет. Их и подбирали специально для этого.
А вот ИТ-сотрудники переходят на сервисную модель совсем иначе. От человека, который блестяще знает свое любимое «железо» или софт и полностью погружен в собственные «колдовские» действия с ними, требуют каких-то показателей, по сути просят описать, что он делает, причем не на понятийном уровне, а на уровне численных параметров. Это воспринимается как тяжелая дополнительная сверхобязанность, фискальный контроль за своими действиями.
Какими могут быть аргументы «за»?
Прежде всего профессиональный рост. Людей, действительно умеющих управлять ИТ-сервисами, на российском рынке пока немного. Хотя мы уже очень давно говорим про ITIL, до сих пор всё остается в основном на уровне деклараций, красивых слов. Те компании, которые заявляют, что способны провести аудит по CoBIT, на самом деле хотя бы приблизительно не умеют этого делать. И опыт, компетенции, накопленные при работе в сервисной среде, - это весомый плюс.
Второе. Сервисный подход дает реальный инструмент для измерения производительности труда. Ведь обычно каждый сотрудник все же сильно зависит от личного к себе отношения непосредственного начальника, как бы даже тот ни старался этого избежать. Есть симпатия, понимание - идут премии и бонусы, нет - даже если он хороший работник, сладкой жизни ему не видать. Но и в том случае, если премии выплачиваются объективно, объяснить обиженному сотруднику, что он работал хуже коллег, невозможно. У него есть собственное мнение на этот счет. Поэтому крайне желательно иметь объективные и измеримые параметры. Когда они согласованы с персоналом и всем понятны - любые вопросы снимаются.
Третий момент - взаимопонимание, коммуникации. Часто люди работают на смежных направлениях, влияющих друг на друга. И совершенно не понимают, что происходит вокруг. Каждый пытается справиться с проблемой изолированно, тратит массу усилий, но ничего не получается. Если бы они попробовали решать задачу сообща, дело пошло бы совсем иначе и продвигалось бы быстрей. При сервисном подходе любой сотрудник видит своих смежников, понимает, «на кого он работает», кто и как пользуется его услугами. Мы регулярно, обычно раз в неделю, проводим встречи на каждом уровне сервиса. Их проводят эккаунт-менеджеры. Согласовав какие-то новые требования с бизнесом, расставив приоритеты, они обсуждают изменения и текущее положение дел с инженерами, специалистами, ответственными за инфраструктуру и приложения (infrastructure manager и application manager). Люди начинают общаться, рассказывать о своей работе, и в результате они лучше понимают, что происходит. Такого целостного ви’дения в компаниях обычно нет, и привнести его сложно. А при регулярном общении люди уясняют себе, что в организации кроме них еще кто-то работает и даже делает что-то полезное.
Так что в сервисном подходе есть как минимум три плюса: квалификация, объективная оценка, коммуникации. Эти три вещи каждый айтишник должен понять, и они должны стимулировать работу с ИТ-сервисами.
Как вы оцениваете качество ИТ-сервисов? Ведется ли у вас непрерывный мониторинг их предоставления?
Экспертные оценки дают вполне достоверные результаты, так как каждый сотрудник, подавая собственные сведения смежникам, попадает под их кросс-проверку. Кроме того, у нас используется сервис-деск. Начав переход к сервисному походу, мы быстро поняли, что без такого инструмента обойтись нельзя. Мы используем его уже более года. Сервис-деск дает много информации о том, какова реакция на те или иные задачи, с какой скоростью решаются определенные проблемы. Вся инфраструктура контролируется, ведётся мониторинг ее состояния и полученные данные протоколируются. Связанные с нею метрики мы получаем из систем мониторинга.
Теперь наша цель - интеграция этих сведений в единую картину. Мы планируем на базе HP OpenView создать единую CMDB (Configuration Management Data Base), где будет учитываться состояние любого подключенного к сети устройства, приложения, сервиса. Затем на её основе можно сконструировать единое дерево сервисов. Под каждый сервис расписываются определенные приложения, серверы и пр., и все они имеют агентов, отслеживающих их состояние. Тогда в любой момент можно поднять дерево и выяснить, с чем связана недоступность того или иного глобального сервиса. Это мы планируем сделать в нынешнем году.
Но просто так, на ровном месте, заниматься этим нет никакого смысла. Прежде чем что-то автоматизировать, нужно отладить методологию, и это принципиальный вопрос. Когда айтишники общаются с бизнесом, они всегда стараются использовать этот тезис: «Нельзя автоматизировать хаос». Вначале нужно формализовать бизнес-требования, а потом уж автоматизировать. Но почему-то относительно себя они тем же принципам не спешат следовать, и первое, что автоматизируют, - собственную деятельность вне зависимости от ее упорядоченности. По моему же глубокому убеждению, сначала должны устояться процессы, их нужно отладить, и лишь после этого можно что-то автоматизировать.
Вы говорили о значении проектного взгляда на ИТ-затраты. Как у вас организовано проектное управление?
Проектное управление у нас устроено классически: для каждого проекта известны цели, задачи, бюджет, ведется проектная документация, работают сертифицированные менеджеры проектов. Что должно быть на выходе, а что не должно, - зафиксировано, и разночтений тут не возникает. Если по ходу проекта вносятся изменения - это нормальное управление изменениями, все документируется. И при подведении итогов мы говорим: вот список корректировок начальных задач, а вот потребовавшийся на их реализацию бюджет, сроки, ресурсы.
Вообще-то существует два подхода к организации и внедрению проектной деятельности в компании. Первый - сверху вниз, когда разрабатываются некие общие документы, которые спускаются от начальства к подчинённым, их официально делают обязательными для всеобщего исполнения, затем разрабатываются процедуры более низкого уровня и т. д., и вся организация вдруг начинает работать на основе проектного подхода. Я в успех этой схемы не верю и считаю, что так действовать нельзя. Здесь, как правило, вся проектная документация и все действия, необходимые для управления, выглядят и действительно оказываются лишь дополнительной нагрузкой, лишней работой. Люди заполняют какие-то бумажки, проводят совещания, но всё делается формально.
Отвертеться они не могут: руководство захотело, значит придется, ничего не попишешь. Но чтобы давать результат, проектный подход должен быть реально поддержан на всех уровнях. Люди должны созреть профессионально и ментально быть готовыми к принципиальному изменению в подходах к их ежедневной деятельности. Поэтому я исповедую другой подход - снизу вверх: сотрудники должны почувствовать, зачем нужны какие-то действия, убедиться на практике, что это и вправду помогает. Мы так и делаем, вводим какие-то практики де-факто. Например, начинаем нормально планировать. У проекта есть план, при этом регулярно проводятся встречи. И люди видят: да, план выполняется, проект продвигается, у нас получается! Пишем отчеты. Зачем? Чтобы понять, что было в каждый момент времени, что произошло и что нам мешало двигаться дальше. Наконец доходит до итогов. И тут самое время сказать: а вот если бы у нас был паспорт проекта, то сейчас гораздо лучше было бы видно, добились мы того, чего хотели, или нет. Когда всё это вводится, возникает и необходимая структура.
Мне нужно лишь подталкивать людей, вовремя предлагать им небольшие готовые документы и еще что-то в этом же духе. У меня на компьютере множество шаблонов проектных документов, но без особой необходимости я никому их не даю, не заставляю применять их. Но постепенно сотрудники проходят обучение - то одни, то другие. Идет нарастание опыта и привыкание к проектной методологии. Проходит какое-то время, и они уже не мыслят работы по-другому: «Зачем, мы всегда так делали, и получаются приличные результаты». И выходит, что к формальным документам люди относятся не формально, а как к инструменту: да, тут описано то, чем мы на самом деле занимаемся. Проводятся разные встречи, организуются проектные комитеты, презентации становятся качественно другими; начинают заниматься управлением изменениями. При этом весь процесс идёт довольно быстро, поскольку в ИТ много проектов.
Пока мы говорили лишь о проектном управлении в ИТ-департаменте. Но наши функциональные заказчики, сотрудники других отделов, задействованные в проектах, тоже начинают в этом вариться и этим проникаться. И приходит ощущение, что если всё нормально спланировано, нормально управляется, то и результат будет. Тогда и люди начинают этому следовать, применять такой же подход. А если такого понимания, на собственном опыте, у них нет, то максимум, чего от них можно добиться, - это формального соблюдения правил и формального отчета, хотя на самом деле пользоваться этими методами никто не собирается и никому они не нужны.
Кто на ваш взгляд должен выполнять функции по описанию бизнес-процессов. Существуют разные мнения на этот счет, в том числе и такое, что этим должен заниматься ИТ-департамент. Как это организовано у вас в компании?
Работа с бизнес-процессами очень логично связана с ИТ. ИТ-отдел - это подразделение, которое наиболее органично, по сути своей деятельности умеет формализовать процессы. Профессиональный айтишник де-факто обладает аналитическим складом ума. Для него любое действие связано с последовательностью каких-то шагов и условий, с алгоритмами. В отличие от многих других специальностей нас этому учат. Блок-схемы нигде больше не рисуют, алгоритмы не разрабатывают. А это ведь фактически и есть бизнес-процессы, и чтобы грамотно описать работу какой-то системы, сначала нужно их описать.
Впервые я этим занялся в Банке Москвы, в отделе банковских технологий. Все технические задания у нас сопровождались описанием бизнес-процессов в графическом виде. Текстовые описания воспринимаются с трудом, графические - намного легче. В «Русфинансе» мы стали это делать практически сразу в рамках ИТ-департамента. У нас в ИТ-департаменте есть особое подразделение, которое этим занимается, - управление перспективных технологий, где работают эккаунт-менеджеры, проджект-менеджеры и бизнес-аналитики. И вот эти люди снабжают любые проекты описанием бизнес-процессов и следят за ними.
Но тут важна зрелость. Бизнес-процесс должен устояться, затем его следует описать и только потом автоматизировать, и никак иначе. Кроме того, не надо забывать, что описать бизнес-процесс «навсегда» невозможно. Вы делаете снимок - описываете бизнес-процесс на момент времени. Самая сложная задача - поддерживать его описание в динамике. Именно поэтому многие проекты, связанные с автоматизацией процессов, оканчиваются неудачей: мы приглашаем кого-то, описываем процесс, автоматизируем. А за прошедшее время полученная картина уже не соответствует практике.
И второй важный момент: прежде чем приступать к описанию, нужно создать инфраструктуру поддержи и управления бизнес-процессами. Должна быть команда людей и разработанные процедуры, как им контролировать бизнес-процесс. Иначе сколько бы вы ни рисовали схем, вы все равно не поймете, что происходит. А чтобы сформировать правила, люди должны понимать, что они делают. Поэтому, между прочим, когда приглашают внешнюю компанию и просят описать, как мы должны действовать, то это не работает.
Мне кажется, надо поступать иначе: двигаться эволюционно. Про бизнес-процессы на время вообще забыть. Поставить задачу просто описать, что мы делаем в каждом подразделении. Потом попытаться все эти описания собрать вместе. Так мы построим некий методологический комплекс, описывающий процедуры, которые идут в компании. Затем начинать их контролировать. Таким образом мы научимся составлять из всего этого цепочки, описывать взаимодействия между подразделениями. Если это понятно, зафиксировано в документах и методология ясна, то можно начинать описывать бизнес-процессы, рисовать их в схематическом виде, поддерживать. В ходе этой постепенной работы как раз и формируется инфраструктура поддержки бизнес-процессов и управления ими, воспитываются люди, возникают практики.
На мой взгляд, продвижение идет снизу вверх, эволюционный процесс - самый продуктивный способ развития. Из всех способов руководства наставничество и делегирование, которые мы и практикуем, оказываются самыми эффективными. До любых методологий люди должны дорасти, иначе они будут навязаны и неработоспособны. Главная задача руководителя - задать направление и потом следить, как оно выдерживается. Стратегия развития - некий направляющий туннель, в рамках которого должна вестись вся деятельность. Как только появляются заметные отклонения - на них должен реагировать ИТ-директор. Но основная задача - создать этот «туннель», это направление и следить, чтобы деятельность за его рамки не выходила.
/ Олег Подкопаев: «Они плакали и кололись, но продолжали есть кактус»
Вконтакте
Одноклассники
«Они плакали и кололись, но продолжали есть кактус»
На вопросы «Системного администратора» отвечает председатель Клуба делового общения банковских ИТ-директоров (CIOBANK Club), заместитель генерального директора компании R-Style Softlab
| родился в 1969 году в Москве. Окончил в 1992 году Московский институт радиотехники, электроники и автоматики по специальности «Электронные вычислительные машины». В 2004 году успешно сдал экзамен на звание Certified Information System Auditor. Много лет работает в сфере информационных технологий. В течение 10 лет осуществлял разработку и внедрение комплексных автоматизированных банковских систем в России, Бельгии, Англии, Венгрии и Словакии, пройдя путь от разработчика до руководителя проектов. Работал в Управлении банковских технологий Банка Москвы. Возглавлял Управление информационных технологий, а затем Департамент информационных и банковских технологий КМБ-Банка. Был директором Департамента информационных технологий группы Русфинанс. Лауреат премии ИТ-Лидер 2007 и 2009. Возглавляет Банковский CIO Клуб, который создан в декабре 2008 года как индустриально ориентированное сообщество руководителей ИТ-подразделений финансово-кредитных институтов. Его задачи – выработка экспертных мнений и решений по предметным направлениям ИТ в банковской индустрии. |
– Олег Юрьевич, кризис 2008-2009 годов миновал, однако эксперты не исключают возможности повторения финансового кризиса, даже еще более масштабного. Как изменились требования к ИТ после кризиса?
– Основным уроком кризиса является то, что банки, грубо говоря, научились деньги считать, с точки зрения ИТ, по-настоящему. До кризиса практически все банки серьезно вкладывались в развитие ИТ, не слишком ограничивая расходы. Соотношение бюджетов – инвестиционного к операционному – часто достигало 2:1 или даже 3:1. Но в процессе кризиса, когда денег не было и бизнес ставил перед ИТ-директорами соответствующие оптимизационные задачи, выяснилось, что многие вещи можно делать гораздо дешевле. Сейчас, когда кризис миновал, ИТ-директора продолжают вести эту политику. Они четко знают, где можно сэкономить. Потому я считаю, что кризис в этом смысле был достаточно полезным.
Второй важный момент?– банки отказались от масштабных долгосрочных проектов в пользу целевых, которые дают быстрый бизнес-результат. Дело в том, что долгоиграющие проекты, как и длинные инвестиции, в нестабильное время достаточно опасны – непонятно, что с ними делать. Поэтому проекты длиной в два-три-пять лет сегодня неактуальны. Банки, у которых они были, в кризис их тормознули. А банки, которые их не начинали, и не пытаются начинать.
Сегодня все предпочитают точечные проекты, которые реализуются в течение года и дают конкретный результат. Это соответственно повлияло на ИТ-архитектуру. Она постепенно, по крайней мере в крупных банках, переходит от использования монолитной, большой централизованной АБС к внедрению компонентных решений. В ВТБ24, в Сбербанке это закреплено на уровне стратегии, в других банках переход от монолитной к компонентной АБС только начинается. Но это уже тенденция, потому что, как я говорил, монолитная система?– это долгий проект, высокие риски, большая стоимость и неопределенный результат в итоге.
Учитывая изменившуюся ситуацию, поставщики ИТ-систем тоже начали дробить свои монолиты и предлагать их на рынке в виде некоего компонентного решения. Кроме того, инфраструктурные поставщики, понимая, что инвестиционные затраты банков во время кризиса снизились, попытались перепозиционировать свои решения как решения для снижения затрат. Они стали активно продвигать решения по виртуализации, облачные технологии?– те продукты, которые позволяют оптимизировать ИТ-инфраструктуру в будущем.
Я считаю, что хотя в кризис это не сработало, потому что подобные решения все равно требуют инвестиций и время их возврата достаточно долгое, тем не менее предлагаемые решения по виртуализации заставили банки обратить больше внимания на данный сегмент. Например, для тестовых, для бэкапных площадок стали использоваться аутсорсинговые и облачные технологии.
Если резюмировать, то кризис для банков был очень полезен. Он позволил более четко понимать, что такое ИТ, каким образом ИТ зависит от бизнеса, и сопоставлять ИТ-расходы с задачами бизнеса. Гораздо больше стали задумываться о бюджетировании ИТ, четко привязывать объемы бизнеса к объемам ИТ, выстраивать SLA в зависимости от объемов бизнеса и других количественных и качественных характеристик.
– Кстати, о виртуализации. В прошлом году компания Gartner провела опрос ИТ-директоров. Оказалось, что многие организации предпочитают не использовать публичные облака из-за проблем безопасности и производительности. Банкиры, полагаю, тоже настороженно относятся к облачным средам?
– Облака бывают разные. Если говорить о приватных облаках, то я считаю, что большинство крупных банков давно их имеет. История развития ИТ идет по спирали. И если задуматься о прошлом, то когда были мейнфреймы, только все начиналось, работала одна большая машина, люди приходили с пачкой перфокарт, отдавали их куда-то и дальше получали результат?– это облако в полном объеме.
Сегодня, даже если забыть про облака, любой большой банк использует достаточно серьезно принципы виртуализации на собственной ИТ- инфраструктуре. Это удобно, в частности, при управлении своими мощностями, для снижения издержек. Поэтому приватные облака, может быть, еще не отвечают в полном объеме формальным признакам, но они есть. Если говорить про внешние, публичные облака или аутсорсинг, то здесь существуют различные технологии и подходы. Например, скажи банку лет пять назад, что он будет использовать внешний ЦОД, об этом не могло быть и речи. Сейчас же есть банки, которые используют исключительно внешние ЦОДы, как основные, так и резервные. Это еще не облачная часть, но уже определенно аутсорсинг.
Следующий шаг?– это аутсорсинг инфраструктуры и платформы. Чем держать дополнительные серверы для тестирования, для разработки, проще использовать внешний сервис. Крупные банки, как более продвинутые, где работают высокопрофессиональные ИТ-директора, тяготеют к облачным технологиям. В малых банках ИТ-директора все еще предпочитают собственную инфраструктуру. Они привыкли все делать сами. Хотя облака им выгодны, потому что малый банк гораздо более стеснен в средствах, нежели большой. Покупка любого сервера является для него серьезной задачей, когда как снять на время платформу в каком-то внешнем облаке можно достаточно легко.
– Почему же они это не делают?
– В силу привычки и определенного консерватизма. Представьте маленький региональный банк. У него есть свои задачи, есть небольшой ИТ-отдел, который все делает самостоятельно. Но если посчитать расходы, которые при этом несет банк, и сопоставить с возможностью получения сервисов извне, причем в соответствии с объемом собственного бизнеса, то можно увидеть совершенно конкретные выгоды от использования облака.
Например, мелкий банк хочет пойти в розницу. Все розничные системы, хорошие и серьезные, сегодня очень дороги, как фронтальная, так и бэк-офисная. Что делает малый банк? Он либо создает собственную систему «на коленке», либо покупает что-то совсем дешевое, либо все делает практически вручную, когда объемы операций небольшие.
Но если существует какое-то решение в облаке, например, по выдаче кредитов, то для банка совершенно естественно подключиться к нему. Почему? Потому что плата за пользование облачным сервисом идет в зависимости от объема выданных кредитов. Ты выдал десять кредитов, за десять заплатил, не выдал ничего?– у тебя не будет никаких дополнительных затрат. Попробовал, пошло?– замечательно. Попробовал, не пошло?– тоже нормально.
С точки зрения компрометации информации, опасения по поводу использования облака совершенно наивны, потому что самый страшный человек – это инсайдер. Информационные базы всегда уходят изнутри организации. А для внешнего аутсорсера защита информации?– часть бизнеса: потерял информацию, потерял репутацию, потерял бизнес.
Поэтому в банке нужно просто на уровне бизнеса посчитать, насколько выгодно применение облака. Ведь чем хороши облачные решения? Там нулевые инвестиционные затраты. Ты платишь только за получение сервиса. ИТ из розетки?– это совершенно нормальная вещь. Крупные российские банки уже используют облачные CRM, какие-то другие системы. Это факт.
– А на Западе насколько продвинулись по этому пути?
– Я еще в 2004 году, работая в КМБ-Банке, рассматривал как раз фронт-офисную кредитную систему для розничного бизнеса. И была немецкая компания, которая на территории Германии уже тогда стандартным образом предоставляла такой сервис. Это скорее всего было не облако, а application hosting, потому что для каждого конкретного банка держалась своя копия приложения, но она разворачивалась на серверах самой компании. Компания не устанавливала его непосредственно в банке.
Потому на Западе использование облаков?– это совершенно нормальная, устоявшаяся вещь. Может быть, бэк-офисные системы они и не используют в облаке, слишком тяжеловесно, но фронтальные системы, системы оценки заемщиков, CRM давно находятся в облаках либо на площадке поставщика и совершенно нормально работают.
У нас же тормозит развитие облачных технологий, во-первых, определенный консерватизм. Ведь любое изменение?– вещь достаточно серьезная. Вторая причина может быть связана с определенной закрытостью российского бизнеса?– не всегда хочется показывать, что у тебя творится в банке. Как только банки становятся публичными, этот вопрос перестает быть актуальным.
С другой стороны, представьте, что где-то в банке, скажем, в Новосибирске на серверах крутится ваша банковская система. Кто-то приходит и снимает локально с этой системы всю информацию либо опечатывает сервер. Но, если у вас серверы находятся в облаке, прийти в офис и опечатать их никто не сможет, потому что система неизвестно где. И нет никакой возможности забрать информацию или остановить бизнес.
– Стратегические задачи российских банков и задачи ИТ в ближайшие годы? В связи с этим, каковы приоритетные задачи CIO?
– Общие задачи ИТ-директоров, с моей точки зрения, особенно не меняются. В зависимости от ситуации меняются местами только приоритеты в общем списке задач. В кризисное время основные приоритеты?– это оптимизация расходов, повышение эффективности, сохранение и поддержка существующей ИТ-инфраструктуры. Во время развития основные задачи?– как раз поддержка развития бизнеса, его расширение, объемное и географическое, быстрая реакция на бизнес-требования.
Если мы говорим про технологии, то, думаю, сейчас на первом месте развитие разнообразных электронных каналов. Практически все банки сегодня идут в розницу, а для розницы?– это вещь принципиальная. На втором месте?– развитие хранилищ аналитических систем в направлении онлайновой оценки бизнеса, неструктурированных данных, выходов в социальные сети, оценки видеоаудиоинформации…
И как всегда это вопросы производительности в любом виде. Производительность для банков сейчас очень важна, в том числе из-за роста объемов розницы. Изначально российские системы строились без оглядки на объемы информации, потому что они были низкими. Сегодня объемы выросли на порядки. Банк, у которого открыто несколько миллионов счетов,?– совершенно типичен.
ИТ-системы оказались не готовы к этому. Да, российские поставщики пытаются свои системы модифицировать таким образом, чтобы они соответствовали возросшим требованиям, но вопрос, насколько это реально работает. Как правило, происходит следующее: ставится АБС, и потом в конкретном банке она очень серьезно докручивается, чтобы оптимизировать производительность. В результате АБС превращается фактически в домашнюю доработку.
Западные системы, к сожалению, внедрять у нас не научились. Западные системы, которые изначально обладают хорошей производительностью, за счет локализации эту производительность мгновенно теряют. Сейчас в банках стараются уходить от внедрения крупноформатных западных систем, использовать компонентный подход best-of-breed для локальных функциональных применений. Есть немало примеров успешного внедрения модулей и компонент западных систем в разных банках. Они берут из них только часть, либо для бэк-офиса, либо для фронт-офиса, а локализацию стараются вынести в российскую систему или в какой-то промежуточный слой.
Сегодня это существенное изменение в ИТ-архитектуре, особенно характерное для крупных банков, которое помогает решать проблему производительности.
Все, как я говорил, развивается по спирали. Если вначале в банках была АБС, потом стали ставить специализированные системы, потом решили, что это зоопарк, плохо, и вновь начали переходить на универсальные АБС, то сейчас опять вернулись к специализированным системам. Это нормальная историческая спираль.
– Правда ли, что многие АБС уже устарели, да и сам класс этих систем концептуально не соответствует современным требованиям банковских организаций?
– Посмотрите, какая ситуация сейчас на рынке? Все ругают Диасофт, ЦФТ, R-Style, Инверсию… Но когда приходит время выбирать, все выбирают решения Диасофт, ЦФТ, R-Style, Инверсии. Почему? Потому что ничего другого на рынке нет, к сожалению.
Да, западные системы лучше российских, по большому счету, они даже внедряются лучше, если знать как. Но западные ИТ-компании на российский рынок так и не вышли, они побоялись инвестировать в нашу экономику. Западники просто приходят сюда, ждут, когда будет какая-то покупка, пытаются внедрить то, что у них есть. Однако они не создают продукт для российского рынка.
Соответственно на российском рынке нет настоящей конкуренции. Поэтому российский поставщик ИТ-решений не склонен существенно улучшать свои продукты. Нет стимулов, тратить деньги на серьезные изменения просто нет смысла. Есть клиенты, которые и так покупают,? – значит, все нормально.
Моя задача в R-Style Softlab, да и моя личная задача?– попытаться сделать принципиально новое решение для российского рынка. Идея в чем? Банку важна быстрота, гибкость, управляемость процесса, контроль рисков и стоимости внедрения и эксплуатации. Банку важен учет бизнес-специфики на каждом участке работы, что невозможно достичь универсальной системой.
Понятно, что на данном этапе развития технологий надо исходить из компонентной архитектуры, но не просто взять монолитную универсальную систему, разодрать ее на части и назвать это компонентной архитектурой. Подход другой?– вы берете системы, которые изначально специализировались, и функционально, и архитектурно, под задачи фронт-офиса, бэк-офиса, хранилища, и дальше интегрируете их в сквозной бизнес-процесс. При этом интеграция должна быть достаточно свободная и отторгаемая, поскольку жесткая интеграция с неоправданным переносом бизнес-логики в интеграционный слой опять-таки превращает решение в монолит. Кроме того, необходима вариативность на уровне каждой компоненты, потому что у разных банков неодинаковые требования и задачи. Наше решение должно учитывать их и предлагать разные варианты собственных компонент и компонент наших партнеров. Важные моменты?– это производительность, надежность, доступность. Мы должны понимать, какие бизнес-требования на какую компоненту накладывать, и оптимизировать ее под эти бизнес-требования. Фактически каждая компонента решения имеет свой собственный SLA.
Мы уже достигли определенного результата: первая бизнес-связка (направление?– розничное кредитование) оттестирована. В третьем квартале 2012 планируем выводить свое решение на продажу.
Чем оно будет принципиально отличаться? Бизнес-ориентированностью, хотя это понятие, в общем-то, достаточно заезжено. Наше решение рассчитано на все банки, на все бизнес-направления, на получение быстрого бизнес-результата. Это решение позволяет быстро, независимо и параллельно в рамках единой архитектуры реализовывать и, что важно, затем также эффективно и независимо эксплуатировать и развивать все бизнес- направления банка. Внедрив его, каждый бизнес будет четко видеть, за что он платит, легко управлять системой, именно в рамках своего направления, и при необходимости быстро вносить изменения в разные части своих бизнес-процессов и банка в целом.
А сейчас наши банки все чаще и чаще смотрят на западные решения, потому что российских нет?– за державу обидно!
– Ваша позиция по поводу вечной проблемы: как превратить ИТ из центра затрат в центр прибыли?
– Я сейчас в это уже не верю. Объясню, почему. Прежде всего у меня есть понимание разницы между начальником ИТ-отдела и CIO. CIO решает бизнес-задачи. И ему не важно, является ли ИТ центром прибыли или центром затрат. Почему? Смотрите, если я приду к финансовому директору или председателю правления и скажу: «Я хочу купить новый сервер за миллион долларов». Скорее всего я не буду услышан. Потому что я покупаю айти-игрушку, а не занимаюсь бизнесом банка.
Всегда подход должен быть другой. Любой CIO должен исходить из потребностей и задач бизнеса и предлагать бизнес-решения на базе информационных технологий. Он должен хорошо знать и понимать бизнес. Не только операционную деятельность или бухгалтерию, а именно что и как продается и почему продается. CIO должен приходить к руководителю банка и говорить: «Нужно вот такое-то решение, чтобы выросла прибыль или повысилась эффективность, или снизились затраты или риски». Задача CIO – показать варианты, еще лучше посчитать.
Нельзя ни в коем случае просить о покупке понравившейся айти-фишки, даже если это выглядит сходу как «только для ИТ» (например, система Сервис Деска или мониторинга)! Должно быть бизнес-обоснование любого предложения. И тогда вы из пожирателя денег сразу превращаетесь в генератора прибыли банка.
– На что, на ваш взгляд, необходимо сегодня направить свои усилия разработчикам банковского ПО?
– Сейчас на российском рынке происходит подсаживание на иглу разработчика, который считает (и справедливо), что раз банк внедрил его систему, все?– он никуда не денется. Банки это раздражает. Поэтому они пытаются найти максимально гибкие решения для своих задач за счет нескольких поставщиков.
Компании не решают бизнес-задачи своих клиентов, они просто продают (если не сказать жестче) свои продукты. Очень часто возникает ситуация, когда банк покупает разрекламированное ИТ-решение: поставили, а это не то либо то, но не работает.
Пока это в определенной мере сходит с рук. Все «плачут, колются, но продолжают есть кактус». Но ситуация может измениться, я надеюсь. Появится прогрессивный российский разработчик или кто-то из западников выйдет нормально на российский рынок. Тогда ситуация будет совершенно другая. Пока же крупные российские банки потихонечку переходят на западные компонентные решения.
Что необходимо нашим компаниям-разработчикам? Инвестировать в новые продукты. Компании этого не делают. Они стараются развивать продукты у клиента. Теряется целостность и стабильность решения. Не думаю, что это стратегически правильный подход.
Кроме того, крайне необходимо улучшить качество сопровождения внедренных решений. Оно очень низкое! Все это знают, но, самое удивительное, разработчики этого особо и не стесняются.
Отсутствие стратегии развития и самого развития продуктов, недостаточная ответственность разработчиков за результат, их недостаточная гибкость, низкий уровень сопровождения, вызванные недостаточным уровнем конкуренции на рынке,?– это основные проблемы отечественного рынка банковского ПО.
Беседовала Галина Положевец
Вконтакте