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

Виктор Парахин родился в 1972 году в Москве.
В 1995-м закончил Военно-Воздушную инженерную академию им. Н. Е. Жуковского по специальности "радиоинженер-исследователь", а в 1999-м - аспирантуру Санкт-Петербургского государственного технического университета.
В 2006 году прошел программу МВА "Управление инновационными проектами, инвестициями и рисками" Академии народного хозяйства.
До прихода в ОАО "Центральный Телеграф" Виктор Парахин занимал ряд руководящих должностей в компаниях "ТрансТелеком" и "Пазес".
В "Центральном Телеграфе" начал работать в 2005 году.
Женат, воспитывает двух детей.

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

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

С другой стороны, что означает подобный рост абонентской базы? Он означает, что за день к нам будет поступать несколько сотен заявок на подключение той или иной услуги и несколько тысяч — на изменение параметров уже подключенных, что нашему контакт­центру ежедневно придётся принимать несколько десятков тысяч звонков и т. д. И без автоматизации приема заявок от клиентов, их учета и обеспечения быстрой реакции на запрос абонента мы не сможем обеспечить подобный рост.
Как правило, внедрение автоматизированных систем преследует две основные цели — снижение издержек и повышение конкурентоспособности компании. У менеджмента «Центрального Телеграфа» есть однозначное понимание, что ИТ являются средством повышения конкурентоспособности. И это очень важно. Однако здесь есть нюанс — дает ли информационная система конкурентное преимущество сразу после внедрения? Cомневаюсь. Думаю, что для сложных производственных и учетных систем должно пройти как минимум полгода. Ведь само по себе владение информационными технологиями не приводит к повышению конкурентоспособности. Их главная функция — помощь в принятии решений и стремлении к лидерству по качеству предоставления услуг. Поэтому говоря о повышении конкурентоспособности, мы обязательно должны подразумевать отношение к информации как к ценному активу.

Что в вашей компании понимается под ИТ­стратегией? Каким образом она формируется и насколько стабильна?

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

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

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

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

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

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

Вы упомянули об анализе бизнес­процессов, а ваша должность называется «директор по бизнес­инжинирингу и ИТ». То есть вы совмещаете функции директора по процессам и ИТ­директора? Насколько оправданно такое совмещение?

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

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

Является ли такое объединение функций в одном департаменте следствием изменения роли ИТ в компании?

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

И здесь залог успеха в том, чтобы ИТ­менеджеры понимали бизнес компании — понимали именно как продукт, который в том числе предоставляют и ИТ. Если раньше, когда мультисервисные сети только начинали развиваться, ИТ по сути рассматривались как ресурс, то сейчас пришло понимание, что они необходимы именно для формирования продукта. У нас есть продукты, например в области конвергенции мобильной и фиксированной связи, в развитии и поддержке которых доля ИТ достигает 20%. То есть фактически мы во многом формируем этот продукт. Другой пример — набор мультисервисных услуг под брендом QWERTY, где использованы не просто сетевые ресурсные технологии, а CRM­система, интеграционная платформа, сложный биллинг, портал самообслуживания и т. д. Новые возможности ИТ в немалой степени определили облик этих продуктов.

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

Здесь уместно спросить о вашем опыте налаживания взаимодейст­вия между ИТ и бизнесом. Используете ли вы для этого какие­то методики или единые модели?

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

Главный инструмент, помогающий наладить взаимодействие здесь, — это модель eTOM, которая представляет собой структурную модель бизнес­процессов поставщика услуг связи, разработанную и совершенствуемую TMF (TeleManagement Forum). eTOM является наиболее распространенным и используемым стандартом в отрасли телекоммуникаций, описывает все ключевые элементы инфраструктуры и их взаимодействие и формулирует общую терминологию, что очень важно при общении с менеджментом. Мы решили не изобретать велосипед, а следовать мировому опыту, аккумулированному TeleManagement Forum, лишь немного его адаптируя. В этой модели определены требования к информационной системе: должна быть модель данных оператора связи, и мы будем ее строить, должны быть независимые справочники и мастер­данные, и мы реализуем это требование в архитектуре, интеграция приложений должна проводиться на основе интеграционной платформы и т. д. И все эти компоненты определяют архитектуру как бизнес­процессов, так и ИТ. Кстати, объединение в одном отделе бизнес­процессов и собственно ИТ — это прямое следствие рекомендаций TeleManagement Forum.

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

Для всех ли ИТ­проектов считается обязательным экономическое обоснование и всегда ли его можно провести?

Я уверен, что неправильно оценивать эффективность одной информационной системы, это порочная практика. Нам нужно обеспечить целевые показатели эффективности бизнес­процессов. Каждая система по отдельности может и не покрывать весь процесс целиком. Например, наша компания планирует в ближайшее время запустить портал самообслуживания для абонентов, но ведь сам по себе он не будет подключать клиентов, как и CRM­система, а без них не принять заявку. То же самое можно сказать о системе активации сервисов — без неё при самостоятельном подключении услуги одному абоненту сети QWERTY понадобится порядка четырёх часов на разнообразные настройки.

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

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

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

Какие ИТ­проекты приоритетны для вашей компании?

В прошлом году основной нашей задачей было проектирование и построение единой мультисервисной сети на территории московского региона и запуск услуг под брендом QWERTY, то есть систем операционного блока. Для этого мы изменили свою корпоративную информационную систему, которая была разработана нашей дочерней компанией ЗАО «Центел» и выполняла функции CRM и учета технических ресурсов. Кроме того, ввод новых услуг изменил такие процессы, как управление заявками на подключение. Теперь клиент может это сделать самостоятельно через портал самообслуживания.

Как я уже говорил, нам нужно будет поддерживать высокие объемные показатели, которые старая биллинговая система просто не могла обеспечить. Мы провели анализ и решили использовать промышленную биллинговую систему. Свой выбор мы остановили на автоматизированной системе расчетов Fastcom 10, которую и внедрили вместе с компанией «Форс — Центр разработки». Особенность этого проекта в том, что биллинговая система должна обеспечить быстрый вывод новых услуг и сервисов. Нам требуется очень высокая степень гибкости сети, поскольку в скором времени «Центральный Телеграф» планирует предоставлять населению московского региона полный спектр сервисов Triple Play: домашнюю телефонию с расширенными функциональными возможностями, высокоскоростной доступ в Интернет и настоящее интерактивное телевидение. Эти задачи стоят перед нами уже в нынешнем году.

Проект по вводу новой системы биллинга был очень «быстрым», у нас были жесткие временные ограничения, и через пять месяцев после старта мы уже использовали биллинг для интернет­услуг. Методика внедрения биллинговых решений подразумевает параллельную работу старой и новой систем. И только когда мы понимаем, что все нормально, старый биллинг «выключается». В июле 2006 года наша компания запустила в опытную эксплуатацию биллинг для абонентов широкополосного доступа в Интернет, а еще через месяц — для услуги высокоскоростного интернет­доступа. Я бы выделил три основных фактора успеха этого проекта. Первый — опыт команды нашей дочерней компании ЗАО «Центел». Второй — приоритизация задач. Ну и третий фактор — это профессионализм разработчиков «Форс», их гибкость и готовность быстро реализовать все наши требования. Кроме того, сама архитектура системы Fastcom 10 устроена так, что многие вещи удается делать, не прибегая к дополнительным затратам ресурсов. Так, к примеру, простыми настройками можно добиться отличных результатов. Мы убедились в этом при создании тарифной модели, которая позволяет реализовать очень гибкий механизм скидок для различных услуг.

Еще одно важное направление нашего развития — организация деятельности ИТ­службы. Процессы оказания ИТ­услуг внутренним пользователям мы строим на основе ITSM. В этом году стартовал важный для нас проект по внедрению управления инцидентами и ServiceDesk. Это позволит стандартизировать деятельность ИТ, уменьшить стоимость разрешения инцидентов, и всё это тоже просчитывается экономически.

Вы говорили о том, что рекомендации TeleManagement Forum включают использование интеграционной платформы…

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

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

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

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

Есть мнение, что самая болевая точка в проекте внедрения интеграционных платформ — это создание НСИ и мастер­данных…

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