Главное, что должен понимать ИТ-директор: нельзя просто тратить деньги.

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

Сергей Асланян родился в 1973 году. Окончил Московский государственный университет им. М. В. Ломоносова, факультет вычислительной математики и кибернетики, по специальности «Прикладная математика». C 1997 по 2001 годы работал в компании PricewaterhouseCoopers (до 1999-го — Coopers&Lybrand). В 2001-м перешёл в ОАО «ТНК-BP Менеджмент» (ранее — ОАО «Тюменская Нефтяная Компания») на должность заместителя руководителя блока информационных технологий. В МТС работает с декабря 2003 года. Сейчас — вице-президент по технике и информационным технологиям ОАО «Мобильные ТелеСистемы».

Intelligent Enterprise: Каково отношение к ИТ в вашей компании? ИТ для МТС — это прежде всего средство сокращения издержек?

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

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

Важно, что интеллектуальный заказчик должен четко видеть цели проекта. Допустим, мы ведем внедрение ERP-системы. Для чего? Для того, чтобы сокращать операционные издержки, улучшить производство и т. д. Но это всё общие слова. Интеллектуальный заказчик должен потребовать: «Через полгода я хочу иметь полностью настроенную, работающую и готовую к запуску систему; через год мне нужно, чтобы отчетность выдавалась не в течение 45 дней по окончании периода, а за десять дней; через два года я хочу сократить издержки на столько-то процентов». А через три года он, может быть, пересмотрит процессы в ERP-системе, потому что изменится рынок, появятся новые возможности предоставления услуг клиентам. Но говорить, что мы хотим внедрить ERP-систему, чтобы в соответствии с best practice сократить запасы на 20%, — это, как говорит один из моих уважаемых коллег, придумали «айтишники», чтобы больше денег потратить.

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

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

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

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

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

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

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

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

Другая проблема, которая здесь кроется, — это стандартизация и централизация ИТ. Ясно, что информационные технологии дают наибольшую отдачу при централизации и унификации. В масштабе компании использование, например, ноутбуков только одного поставщика явно выгоднее, даже если в каком-то регионе было бы дешевле купить ноутбуки другого поставщика. Если мы ориентируемся, скажем, на серверное оборудование Sun, то этот стандарт для нас должен выполняться в 99,9% случаев. Мы, как любая серьезная распределенная компания, стремимся к тому, чтобы стандартизировать, унифицировать и централизовать эту инфраструктуру. Например, инсталляция Oracle е-Business Suite у нас централизована, и все пользователи от Владивостока до Калининграда, а их до конца 2006 года будет пять тысяч, физически работают на одном сервере, который стоит в Москве. При этом у пользователя есть терминал, мышка — и всё. Другие наши приложения менее централизованы, но мы в любом случае стремимся к централизации.

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

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

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

Безусловно. Не только руководитель ИТ, но и менеджеры подразделения ИТ вовлечены в стратегическое планирование развития компании. CIO — член нашего управляющего комитета и обязательный участник ключевых встреч с руководством всех дочерних компаний. В комитете по продуктам и тарифным услугам, который разрабатывает новые решения, сотрудники ИТ-подразделения составляют 20 — 30 %. Но, к сожалению, мы зачастую выступаем сдерживающим фактором, говорим о существующих технологических ограничениях. Как правило, это принимает форму моделирования рисков. Маркетинг — креативное подразделение, которое обязано вести компанию вперед. Но если маркетологи предложат завтра перейти на новый тариф, я или другой менеджер подразделения ИТ должен сказать: «Мы не можем сделать это за один день, потому что встанет определённая часть биллинговой системы. Она просто физически не справится с таким количеством запросов». Так что идея может быть и правильной, но нереализуемой. Участие ИТ в комитете по продуктам и тарифным услугам, наверное, добавляет мало креатива, но точно помогает сводить к минимуму технологические риски.

Подобное вовлечение в бизнес компании ведет к расширению традиционных границ ответственности и требует от ИТ-директора других, далеких от технических, навыков и компетенций...

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

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

Поэтому, мне кажется, нужно немного приземлить амбиции CIO и, четко поставив цели перед подразделением ИТ, контролировать их достижение.

Один из возможных противовесов росту затрат — аутсорсинг. Как вы относитесь к такой форме работы? Расскажите о своем опыте передачи на аутсорсинг ИТ-функций — с каких, по вашему мнению, надо начинать?

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

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

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

Мы строим управление ИТ следующим образом. Работы, связанные с эксплуатацией оборудования, поддержкой пользователей и всех приложений, включая биллинговые системы, отданы на уровень бизнес-единиц. Этим занимается почти 80% ИТ-персонала. Всё, что связано с планированием развития ИТ, бюджетированием, управлением проектами и ИТ-архитектурой, вынесено на уровень корпоративного центра. То есть на уровне центра задается стратегия, внедряются ИТ-системы, а местные ИТ-подразделения занимаются эксплуатацией.

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

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

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

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

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

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

Логика планирования такова: сначала стратегия бизнеса, затем ИТ-стратегия, функциональный план и наконец проекты. При этом далеко не все ИТ-проекты заканчиваются одним годом.

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

Каковы основные направления ИТ-поддержки бизнеса? Какие ИТ-проекты приоритетны для вашей компании?

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

Затем — проект внедрения Oracle е-Business Suite, он также выходит на финишную прямую. Это не простой проект, у нас самая большая скорость внедрения с точки зрения количества пользователей, и через год он будет завершен.

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

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

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