TMN – техническая регламентация
Рынок средств OSS уже прошел значительный путь и претерпел некоторые трансформации. Поэтому его сегодняшнее состояние и тенденции будут лучше понятны, если заглянуть в недалекое прошлое. В ответ на появившиеся в конце прошлого столетия проблемы управления сетями ведущие международные организации в области стандартизации, такие как ISO (International Organization for Standardization), ITU (International Telecommunication Union), ETSI и др., разработали ряд стандартов для систем управления (СУ) сетями связи. В результате в рекомендациях ITU были изложены общие принципы планирования, функционирования и технического обслуживания системы управления электросвязью TMN (Telecommunications Management Network) с использованием стандартных протоколов и интерфейсов. Предложенная в рекомендациях пирамидальная модель СУ охватывала пять уровней (рассматривая сверху):
- управление бизнесом (Business Management, BM);
- управление сервисами (Service Management, SM);
- управление сетью (Network Management, NM);
- управление элементами (Element Management, EM);
- элементы сети (Network Element, NE).
В свою очередь для прикладных функций управления сетью в TMN выделены пять функциональных областей (т. н. модель FCAPS):
- управление устранением отказов (Fault Management, FM);
- управление конфигурацией сети (Confi guration Management, CM);
- управление расчетами с пользователями и поставщиками услуг (Accounting Management, AM);
- контроль производительности сети (Performance Management, PM);
- обеспечение безопасности работы сети (Security Management, SM).
Оказалось, что представленная модель FCAPS и пирамида TMN взаимно дополняют друг друга. Такая модель в определенный период времени способствовала значительному развитию
OSS, которые соответствовали требованиям своего времени. При этом большое число OSS-систем были самописными или заказными, и каждая из них была настроена на «свои» архитектуру сети, используемое оборудование и предоставляемые услуги. Но со временем требования клиентов к услугам связи значительно возросли и оказалось, что системы OSS периода технологического роста слабо соответствуют новым бизнес условиям, а именно:
имеют, с одной стороны, дублирование, с другой – фрагментарное покрытие функций и, кроме того, их сложно и дорого модернизировать. Эти недостатки были следствием того, что основной целью концепции TMN было повышение эффективности работы сети, а не операторской компании как предприятия в целом [бизнес-цели пока не принимаются в расчет – Ред.].
TOM – типовая структура бизнес-процессов
Разрешению возникших сложностей в развитии телекоммуникационного бизнеса вообще и OSS-систем в частности поспособствовала начатая в 1995 году работа международной неправительственной организации TeleManagement Forum (TM Forum) по разработке способов управления телекоммуникациями по принципу от бизнес-задач предоставления услуг до управления оборудованием [теперь бизнес-требования выходят на первый план – Ред.]. Развивая идеи управления сетями, заложенные в документах ISO, ITU, и основываясь на обобщении опыта многих телекоммуникационныхкомпаний, TM Forum разработал для оператора связи типовую структуру бизнес-процессов по управлению предоставлением услуг – TOМ (Telecommunication Operations Map). Согласно TM Forum, для эффективного внедрения системы OSS необходимо прежде всего использовать соответствующую современным требованиям модель бизнес-процессов оператора связи, в создании которой операторам должна помочь
типовая структура бизнес-процессов TOM. Решения для OSS должны строиться в соответствии с общей структурой бизнес-процессов оператора. Модель бизнес-процессов позволяет правильно определить требования к OSS-системе, отвечающие за достижение бизнес-целей.
Поэтому структура процессов TOM стала для многих поставщиков OSS-решений, телекоммуникационных компаний и системных интеграторов отправной точкой при внедрении OSS-систем и позволила в большей мере согласовать технологический и бизнес-подход.
Термины и определения
Библиотека ITIL (Information Technology Infrastructure Library) – лучшая мировая практика, позволяющая организовать эффективное функционирование ИТ-служб организации для стабильного и прогнозируемого развития ее информационной системы.
eTOM – карта процессов инвариантная к технологиям
В дальнейшем TM Forum, анализируя фактическое развитие и тенденции телекоммуникационного рынка, постоянно совершенствует расширенную карту процессов телекоммуникационного оператора eTOM (enhanced Telecommunications Operations Map), которая пришла на смену TOM и разрабатывает рекомендации по ее практическому использованию. Структурная модель бизнес-процессов eTOM нацелена на создание общего представления о бизнес-процессах оказания услуг связи и ориентирована на полное удовлетворение запросов клиентов с высокой эффективностью для оператора. Основное отличие eTOM от TOM – это более полная и детальная структурная модель бизнес-процессов, имеющая четыре уровня детализации. Фактически в ней описаны типовые бизнес-процессы оператора связи, декомпозированные до 4-го уровня, не требующие для их рассмотрения учета технологических особенностей оператора связи [бизнес-модель инвариантна технологии ее реализации – Ред.]. Ответственности OSS-решений на структуре бизнес-процессов eTOM соответствуют бизнес-процессы в области «Операционные процессы» для горизонтальных уровней «Управление сервисами» и «Управление ресурсами». С 2004 года структура процессов eTOM как типовая структура бизнес-процессов оператора связи, получила статус официального стандарта ITU.
Национальные особенности процессного мышления
Для Украины в этот период более характерно экстенсивное развитие рынка телекоммуникаций, когда практически единственным аргументом в борьбе за клиента были «ценовые войны», поэтому понимание необходимости построения моделей бизнес-процессов для управления бизнесом, т. е. применение процессного управления в дополнение к структурно-функциональному, не получило в нашей стране достойного внимания.
Рис. 1. OSS-системы: процессная логика стандартов и их взаимосвязь
Это период осторожного знакомства с eTOM и другими рекомендациями TM Forum. На наш взгляд, недостаточное внимание к процессному подходу не позволило операторам достичь ожидаемых результатов при внедрении OSS. Ведь, по мнению экспертов, именно бизнес-логика является при внедрении OSS той основой, которая позволяет правильно определить последовательность внедрения ключевых приложений и, как следствие, требуемый объем инвестиций и прогнозируемую отдачу от них.
Централизованные решения
В связи с тем, что в период экстенсивного развития сети операторов достигают масштабов всей страны и для предоставления услуг все больше используется сетевое оборудование и системы управления (NMS – Network Management System, EMS – Element Management System) различных производителей, возрастает роль централизованных OSS-решений, позволяющих создавать и использовать единые взаимодействующие между собой информационные
модели ресурсов сети (IMS-Inventory Management System), ее производительности (PMS-Performance Management System) и происходящих в ней событий (FMS-Fault Management System).
Такие OSS-системы становятся одним из важнейших элементов централизованных систем эксплуатации и позволяют операторам значительно повысить эффективность использования
ресурсов сети, отслеживать производительность сети, существенно упростить и сделать более эффективной обработку множества событий сети для сокращения времени на выявление аварийных ситуаций и их отработку. Эти системы требуют серьезных капиталовложений, к тому же при их создании все больше отдается предпочтение использованию готовых и проверенных решений вместо самописных и заказных.
Ориентация на клиента
Значительно исчерпав возможности экстенсивного развития, операторы связи для сохранения или завоевания рыночных позиций в конкурентной борьбе вынуждены выводить на рынок новые услуги в наиболее короткие сроки и уделять большое внимание качеству услуг в соответствии с все возрастающими запросами клиентов. Рынок телекоммуникаций становится все более клиент-ориентированным [OSS включается в борьбу за клиента – Ред.]. Для того чтобы соответствовать новым вызовам рынка, операторам потребовалось усовершенствовать свои подходы к управлению телекоммуникационными сетями, что, в свою очередь, привело к необходимости значительного расширения функциональной ответственности OSS-решений. Таким образом, к вышеупомянутым компонентам OSS (IMS, FMS, PMS) следует добавить следующие:
- TT (Trouble Ticketing) – контроль за устранением неисправности;
- WOM (Work Order Management) – управление выполнением работ на сети;
- SC (Service Catalog) – каталог услуг;
- AS (Activation System) – активация ресурсов и сервисов;
- SLM (Service Level Monitoring) – мониторинг уровня сервиса;
- SLA (Service Level Agreement) – управление уровнем обслуживания клиентов.
Потребность управления полным циклом предоставления услуги потребовала более тесной интеграции с системами бизнес-поддержки (BSS – Business Support System).
Услуги в виде ИТ-сервисов
Другой важной особенностью этого периода является то, что для предоставления услуг все больше используются ИT-сервисы, обуславливающие при внедрении OSS следующее:
- необходимость интеграции OSS с ИT-ресурсами, используемыми для предоставления услуг (централизованный мониторинг и инвентаризация ИT-ресурсов со стороны OSS, обмен данными с ИT-приложениями и др.);
- необходимость комбинированного использования подходов, определяемых различными стандартами (например, обеспечение взаимодействия eTOM-процессов и ITIL-процессов, т. е. бизнес-процессов, относящихся в службе эксплуатации сети и ИT-процессов). Эта особенность нашла свое отображение и в решениях TM Forum. В eTOM версии 8.0 предложена карта процессов, включающая в себя и ITIL-процессы.
Новому поколению сетей - новые системы OSS
На подходе новое поколение сетей – NGN (New Generation Network), поддерживающее неограниченный набор услуг с гибкими возможностями по их управлению. Для этих сетей нужны новые системы OSS.
Термины и определения
Европейский институт по стандартам в области телекоммуникаций (ETSI) определил OSS (Operations Support Systems – система эксплуатационной поддержки) как базовое понятие для обозначения набора функций управления, которые применяются предприятием связи для мониторинга, анализа и управления системами, ресурсами и услугами.
Новому поколению сетей - новые системы OSS
Телекоммуникационное сообщество вступило в период очередных масштабных трансформаций, без которых теперь уже сложно ответить на вызовы рынка. Речь идет о технологиях сетей нового поколения (NGN – New Generation Network), которые призваны обеспечить широкий ассортимент и высокое качество предоставляемых услуг, и при этом сократить затраты оператора и повысить доходность предоставления услуг.
Главная цель - ориентация на клиента
Концепция NGN предусматривает поддержку неограниченного набора услуг с гибкими возможностями по их управлению, реализацию универсальной транспортной мультипротокольной сети с распределенной коммутацией, интеграцию с традиционными сетями связи. Базовым же принципом NGN является разделение функций переноса и коммутации, управления вызовом и управления услугами. Вместо принятого в традиционных сетях управления каналами для соединения между абонентами по принципу «точка-точка», в NGN реализуется переход к идеологии виртуальных частных сетей (VPN), осуществляющих доставку сервисов конечному пользователю поверх протокола IP. Технологии NGN предъявляют к OSS новые требования, которые изменяются вместе с развитием NGN и только сейчас начинают приобретать конкретные очертания. Главное отличие заключается в том, что OSS в сетях нового поколения отвечает не только за управление сетью, но и должна обеспечить качественное функционирование пользовательских услуг и технологических служб (сервисов). Т. е. акценты все больше смещаются в сторону обслуживания абонентов, а поэтому OSS должна уметь использовать информацию о пользователях, классифицировать ее, обогащать и интеллектуально обрабатывать. Поэтому решения, обеспечивающие заданный уровень услуги клиента (SLA -Service Level Agreement) и ее качество (QoS – Quality of Service), должны стать неотъемлемой частью OSS-систем. Все более востребованными становятся также решения для управления восприятием услуги пользователем (CEM-Customer Experience Management).
Проактивное управление
Сети следующего поколения и предоставляемые посредством их услуги на порядок сложнее и динамичнее, чем существующая сетевая среда, и реагировать на любые, в том числе
и возможные негативные изменения необходимо будет очень быстро, и поэтому в большинстве случаев придется использовать «проактивное (превентивное)» управление вместо «реактивного». Услуги в этих сетях непрерывно активизируются и дезактивируются. Это сопровождается активным добавлением, удалением и конфигурированием устройств, что приводит к значительному увеличению количества генерируемых при этом событий. Более того,
конвергентная природа NGN означает, что каждое событие может быть связано с затрагивающей какую-то услугу ошибкой, не воздействуя на нее самостоятельно. При этом оператор должен в режиме реального времени идентифицировать, какое событие, связаное с ошибкой в работе оборудования, влияет на предоставление услуг, например:
- события, свидетельствующие об отказе предоставления услуги;
- события, свидетельствующие о возможном отказе предоставления услуги в скором времени;
- события, свидетельствующие об отклонениях от ожидаемых конфигураций сети, которые могут воздействовать на SLA.
Уровень обработки входящих событий
NGN-сети более критичны к возможным простоям, поэтому недостаточно развитые технологии управления проблемами приведут к большим эксплуатационным затратам или даже к невозможности предоставления услуг. Из этого вытекает необходимость доработать или заменить соответствующие средства OSS на новые, чтобы они смогли обеспечить необходимый
уровень обработки входящих событий, а именно:
- автоматическое фильтрование, дедупликация и агрегация, чтобы показывать только связанные с первопричиной события; выявление критических событий;
- высокий уровень автоматизации изоляции проблемы путем применения сложного корреляционного анализа и эффективных правил поиска событий, связанных с первопричиной проблемы (Root Cause Analysis – RCA);
- обогащение событий, связанных с первопричиной проблемы, для автоматизированного / автоматического выявления их воздействия на пользователей и используемые ими услуги (Impact Analysis – IA);
- автоматизированная корреляция сетевых проблем и проблем пользователей;
- автоматический поиск на основе моделей первопричины проблемы (RCA) и выявление воздействия (IA), что будет очень актуально для сетей следующего поколения, так как методы на основе правил не всегда позволят эффективно решать указанные задачи в NGN-сетях.
Управление проблемами
Для быстрого устранения возникших проблем очень важна скорейшая мобилизация всех необходимых ресурсов и эфективное управление ими. Поэтому OSS должна иметь в своем составе средства для своевременного и гарантированного автоматического оповещения всех заинтересованных и привлекаемых к устранению возможной проблемы лиц при обнаружении критических событий еще до передачи события в систему контроля за устранением неисправности (Trouble Ticketing System). К томе же система контроля за устранением неисправности должна обладать для применения в NGN некоторыми отличиями, например, всей полной и детальной информацией о возникшей проблеме, а также содержать не только данные о статусе карточки контроля, но и данные о текущем состоянии решаемой проблемы в требуемой детализации.
Новый подход к планированию
Для предоставления услуг в гибко конфигурируемых сетях следующего поколения крайне важной является гарантия того, что необходимые для предоставления услуг ресурсы находятся в правильном месте и в нужное время. Кроме того, потребность отделения услуги от технологии вызывает необходимость понимания не только того, где, когда и какой ресурс необходим, но также и того, как развернуть его самым эффективным способом. NGN – это непрерывно изменяющаяся сеть, которая предназначена для предоставления многих различных видов услуг, с использованием разнообразных различных технологий и механизмов. Поэтому для NGN необходима интегрированная система планирования, способная непрерывно выполнять в едином замкнутом цикле долговременное, тактическое и текущее планирование сети для потребностей управления ресурсами (Inventory Management), предоставления услуг (Fulfi llment) и обеспечения (Assurance).
Методология NGOSS
В этих условиях для операторов особенно важным становится правильно предусмотреть внедрение соответствующих компонентов OSS уже на этапе закладки концепции построения сети с использованием технологий NGN. Европейский институт по стандартизации в области телекоммуникаций (ETSI) в своих стандартах для сетей NGN определил деловые и операционные, а также функциональные и архитектурные требования к OSS и ее компонентам, тем самым описав основные проблемы, стоящие на пути внедрения OSS для NGN, и заложив основу для их разрешения. Очень важным является то, что внедрение новых NGN услуг требует не только новых телекоммуникационных технологий, а и серьезного реинжиниринга эксплуатационных процессов. Исходя из этого, ETSI рассматривает методологию TM Forum NGOSS (New Generation Operations System and Soft ware) в качестве наиболее вероятной основы, которая может обеспечить успешную реализацию OSS для NGN. TM Forum с 2001 года в рамках методологии NGOSS разрабатывает для сетей нового поколения NGN много рекомендаций по эффективному управлению сетями в процессе предоставления услуг, тем самым определяя технологические направления и подходы развития OSS / BSS. В основе методологии NGOSS лежит перекрестное использование двух подходов, которые лежат в основе управления жизненным циклом NGOSS.
- «Рlug and play» компонентная архитектура является специфической формой SOA (Service-oriented architecture), и в итоге позволяет очень быстро создавать новые сервисы путем динамического комбинирования повторно используемых компонентов. Это должно обеспечить уменьшение времени на разработку, а также снижение затрат на внедрение и тестирование новых услуг.
- Управляемая моделью архитектура MDA (Model Driven Architecture), позволяющая специфицировать решение в виде абстрактной модели с возможностью последующей автоматизации генерации программного кода.
Компоненты методологии
Данная методология реализована в виде пакета общепринятых в телекоммуникационной индустрии спецификаций и рекомендаций и опирается на четыре взаимосвязанные между собою компонента:
- eTOM (enhanced Telecommunications Operations Map) – карта бизнес-процессов;
- SID (Shared Information Data Model) – связанная с eTOM бизнес-процессами корпоративная информационная модель;
- TAM (Telecommunications Applications Map) – связанная с eTOM бизнес-процессами карта приложений;
- Набор решений по интеграции и внедрению сетевых решений – TNA (Technology Neutral Architecture), SOA (Service-Oriented Architecture) и др.
Ключевой элемент этой методологии – eTOM, так как он является стартовой точкой для оператора связи при проведении работ по реинжинирингу его бизнес-процессов и созданию структурной модели бизнес-процессов. Создание, а затем и внимательный анализ этой модели позволят оператору определить наиболее критичные зоны, с которых нужно начинать строить собственную систему OSS. Созданная структурная модель будет использована и для определения бизнес-требований к строящейся системе OSS.
Золотая середина в трансформации процессов
В большинстве случаев операторы рассматривают и оценивают только функциональную часть OSS-приложений. При этом упускается из виду, что программное обеспечение поставщика OSS-приложений, как правило, в значительной мере не соответствует модели бизнес-процессов конкретного оператора. Кроме того, возможности инструментария предлагаемых поставщиками OSS-приложений по простой настройке на конкретные бизнес-процессы часто довольно ограничены. Поэтому в конечном счете все может свестись к требованию серьезно изменить
бизнес-процессы конкретного оператора для возможности внедрения определенного приложения или к требованию реализации на поставляемом приложении фактически заказной системы. Оба варианта очень дорогие и имеют очень сомнительные перспективы. Ведь для создания полнофункционального OSS-решения оператору придется внедрять несколько приложений от разных поставщиков. И понятно, что требования к реинжинирингу бизнес-процессов могут оказаться довольно противоречивыми. К тому же бизнес-процессы оператора не являются статичными и изменяются во времени. Поэтому именно внедряемое приложение должно обладать серьезными возможностями по адаптации к бизнес-процессам заказчика. При этом необходимо избежать и другой крайности, когда реализованная в приложении модель бизнес-процессов должна быть полностью изменена в соответствии с требованиями заказчика.
Сходимость процессов по еТОМ
Разрешению этих противоречий помогает то, что сейчас большинство ведущих производителей систем OSS / BSS участвуют в разработках TMF и в любом случае хотя бы декларируют соответствие своего программного обеспечения еТОМ. Но часто также декларируется одновременное соответствие и другим моделям процессов, например, ITIL. И разобраться, что чему сответствует и в какой мере, непросто. Можно понести неоправданные расходы и не получить результата. Поэтому в дальнейшем при выборе программного обеспечения для OSS оператору связи необходимо учитывать степень приверженности производителя программного обеспечения стандартам модели еТОМ как типовой структурной модели бизнес-процессов предоставления услуг телекоммуникационного оператора, а также хотя бы видеть сходимость своих бизнес-процессов с бизнес-процессами по еТОМ. В противном случае компании грозят полная зависимость от выбранного поставщика приложения и сложность интеграции с информационными системами других производителей.
Роль общей информационной модели
Аналогичные аргументы можно привести и в пользу использования общей информационной модели SID, которая имеет непосредственную связь со структурной моделью еТОМ. Использование модели SID, позволит более легко и правильно определить функциональные и интеграционные требования к создаваемому решению и на этой основе создать необходимые модели данных для внедряемых приложений. Учитывая наши отечественные реалии и то, что поставщики приложений пока не все полностью придерживаются какой-либо стандартной
схемы данных, модель SID пока играет не столько роль общей схемы данных, сколько позволяет задать базис основных сущностей, которые связаны со структурой процессов eTOM или с другими бизнес-моделями.
Стандарт определяет развитие OSS
Появившись как средство повышения эффективности управления телекоммуникационными ресурсами, современные OSS становятся средством, без которого в сетях нового поколения невозможно предоставление услуг. Вместе с тем технологические направления и подходы развития OSS, как видно из вышеприведенного, определяют стандарты, в частности, такие как методология NGOSS для сетей нового поколения NGN. Как раз для эффективного управления такими сетями в процессе предоставления услуг в NGOSS и приведено много рекомендаций.
SOA на службе операторов связи
Широкий ассортимент и высокое качество предоставляемых услуг необходимы операторам связи, чтобы удовлетворить растущие потребности бизнес- и частных клиентов. Для решения этих задач разработаны сети нового поколения NGN (New Generation Network). Чтобы управлять этими сложными сетями требуются системы эксплуатационной поддержки OSS (Operations Support Systems) с новыми функциями, обеспечивающими качественное функционирование пользовательских услуг и технологических служб. Реализация современных решений OSS в NGN требует стандартизации, которая была предложена в отраслевой методологии NGOSS (New Generation Operations System and Software). В ее основе лежит использование «Plug and play» компонентной архитектуры, являющейся формой SOA, которая позволяет создавать сервисы путем динамического комбинирования повторно-используемых компонент. В рамках такого подхода разработаны, в частности, рекомендации по картам бизнес-процессов (eTOM, enhanced Telecommunications Operations Map) и корпоративная информационная модель (SID, Shared Information Data Model), связанная с еТОМ бизнес-процессами.
Технологии архитектуры SOA
Рекомендации NGOSS очень важны для интеграции приложений, используемых для построения OSS-решения, а также для управления взаимодействием этих приложений для автоматизации конкретных бизнес-процессов, поскольку стандартизируют создание соответствующей архитектуры OSS-решения. Наиболее перспективным подходом в рамках NGOSS признано использование архитектуры SOA. Эта архитектура основана на нескольких технологиях (интеграционная шина, шина сообщений, сервисная шина, шина данных и др.) и позволяет выполнять обмен сообщениями, преобразование данных, маршрутизацию и согласование («оркестровку») сервисов. При этом появляется возможность гибкого управления пользовательскими услугами за счет повторного использования сервисов и изменения бизнес-процессов их предоставления преимущественно путем конфигурирования, вместо программирования.
Интеграция мультивендорных продуктов
После того как на смену интеграционной шине EAI (Enterprise Application Integration) пришла технология сервисной шины ESB (Enterprise Service Bus) архитектура SOA получила на рынке OSS-решений значительное признание. SOA на основе интеграционного программного обеспечения с однородной интеграционной средой (на базе сервера приложений) уже используется ведущими поставщиками (вендорами) для объединения своих OSS-приложений в единое OSS-решение. Но операторам приходится при построении своих OSS использовать по тем или иным причинам OSS-продукты различных поставщиков, а также интегрировать уже работающие приложения с новыми. Поэтому приходится строить архитектуру SOA для интеграции разнородных интегрированных приложений с использованием уже другого интеграционного программного обеспечения.
Гибкость работы с данными
Кроме того, оказалось, что чисто синтаксической совместимости данных (совместимость форматов) для успешного использования преимуществ архитектуры SOA не достаточно, что также необходима совместимость на семантическом уровне, т. е. одинаковое понимание всеми сторонами элементов данных, которыми они обмениваются. Так появилось понятие сервисов данных и шины данных EDB (Enterprise Data Bus), через которую они взаимодействуют.
Для преобразования потоков данных EDB может импортировать и использовать общую информационную модель, например SID. Развитию EDB сейчас уделяется первостепенное внимание. Считается, что EDB поможет SOA стать высокоэффективной и общедоступной технологией. На самом деле еще нет программного обеспечения полностью соответствующего EDB. Но некоторые поставщики интеграционных приложений уже предложили программное обеспечение, которое можно интегрировать с ESB для решения вопросов обмена данными в средах, основанных на использовании сервисно-ориентированных архитектур (SOA), и обеспечить такую же гибкость работы с данными, какую SOA дает для сервисов. Это позволяет снизить затраты времени и средств, необходимых для обеспечения интеграции систем OSS/BSS обеспечивая, таким образом, более быстрое предоставление новых сервисов.
Выбор сценария
Сервисно-ориентированная архитектура может быть использована для реализации как простых, так и сложных бизнес-сценариев, например:
- интеграция приложений;
- интеграция с базами данных;
- использование сервисов различных приложений;
- автоматизация процессов посредством оркестровки сервисов;
- сервисно-ориентированный бизнес.
Выбор необходимых для реализации сценариев технологий SOA (напр, типа шины) определяется выполняемыми задачами и конкретными условия развития OSS-решения оператора телекоммуникационных услуг. Что касается СНГ, и Украины в частности, то проекты с использованием элементов SOA носят пока интеграционный характер, который не стоит путать с изначально выбранной архитектурой SOA. Стремление заказчиков сохранить реально работающие приложения вполне понятно, и выбрасывать их ради SOA никто пока не имеет желания. Но для реализации OSS, соответствующих сетям NGN, без технологий SOA обойтись будет очень сложно или, скорее всего, вообще невозможно.
Многофакторность условий
Появившись как средство повышения эффективности управления телекоммуникационными ресурсами, современные OSS становятся средством, без которого в сетях нового поколения невозможно предоставление услуг. В итоге для реализации полнофункциональной OSS необходим значительный набор компонент от разных производителей и выполнение большого объема интеграционных работ. На рынке достаточно много предложений класса OSS, в той или иной степени обеспечивающих конкурентные преимущества и стабильность в управлении телекоммуникационным бизнесом. С чего начать и в какой последовательности вести наращивание функционала - вот те вопросы, которые волнуют оператора, решившегося на внедрение OSS. Несмотря на то, что до последнего времени наиболее востребованными были своего рода зонтичные OSS-решения (Umbrella Management System), которые решали задачи технического учета сетевых ресурсов (IMS) и обработки событий сети (FMS), к сожалению, единых ответов на эти вопросы сегодня дать нельзя. Кроме того, OSS-решение конкретного оператора не может быть неизменным, прежде всего, в силу изменчивости его бизнес-процессов и необходимости соответствовать вызовам рынка.
Гладко было на бумаге
Применение любых методологий для реализации новых сложных технических решений без соответствующего опыта похоже на пользование крупномасштабными географическими картами: гладко было на бумаге, да ухабы подвели. Многовариантность архитектуры, мультивендорность, многофакторность условий при реализации OSS-проектов в парадигме NGOSS - все это требует знаний и практики в реализации. Поэтому в таких проектах особенно велика роль системного интегратора, способного помочь оператору в выборе адекватных его требованиям приложений для создания и поддержки в эксплуатации эффективного OSS-решения. Выбранный оператором системный интегратор должен быть способен выполнить весь комплекс работ по проектированию, поставке, монтажу, интеграции и пуску в эксплуатацию всех элементов поставляемого решения, обучению персонала, а также обеспечить требуемые виды обслуживания и поддержки установленного оборудования и программного обеспечения. Учитывая практические для текущего момента требования мультивендорности поставляемых решений, а также необходимость создания комплексного OSS-решения и его интеграции с существующими компонентами OSS и другими автоматизированными системами - это является непростой задачей. При этом интегратор должен удовлетворить не только текущие требования, но и представить концепцию перспективного развития (roadmap) OSS-оператора с учетом перспектив развития телекоммуникационных технологий и операторского бизнеса. Для успешного решения этих задач интегратор должен опираться на стандарты, рекомендации и методологии в области создания, управления и поддержки эксплуатации телекоммуникационных сетей (TMF, ITU-T, TISPAN и др.); с самого начала закладывать возможности интеграции, отдавая предпочтение решениям, соответствующим международным стандартам и поддерживающим открытые интерфейсы. Такой подход также должен быть основой для создания прединтегрированных решений или их составных частей, поскольку это напрямую влияет на длительность проекта и связанные с ним издержки.
Методология для «индпошива»
Но вместе с тем основой взаимодействия с заказчиком для построения OSS-оператора должен быть индивидуальный подход к каждому заказчику, гарантирующий построение OSS-решения, удобного в работе, учитывающего все нюансы эксплуатационной деятельности оператора и направленного на достижение его конечных бизнес целей. Реализация целей
должна достигаться отображением целей заказчика на приемлемые для него модели бизнес-процессов, информационную и функциональную модель и, в конечном счете на программно-техническую инфраструктуру системы операционной поддержки - OSS. Такой подход к созданию OSS-решения, особенно для сетей NGN, будет затруднительным без практического использования интегратором методологии TMF NGOSS. Эта методология является также основополагающей для постепенного пошагового внедрения интегратором компонент OSS, с обеспечением практического использования каждой из внедренных компонент и получения экономического эффекта после каждой фазы внедрения.
Факторы успеха
Успех проекта внедрения OSS во многом определяется также степенью взаимопонимания между заказчиком и исполнителем. Здесь особенно важным является желание и умение интегратора своевременно привлечь заказчика к совместному выполнению ряда работ в рамках проекта внедрения OSS. Для интегратора - это способ своевременно понять, насколько адекватно и четко сформулированы требования к проекту, и минимизировать риски. Для заказчика такой подход является эффективным способом снижения стоимости проекта, уменьшения рисков и скорейшего получение его специалистами знаний для последующей эксплуатации и поддержки.
И наконец, предоставления новых услуг посредством сетей нового поколения могут потребовать серьезных изменений организационно-функциональной среды и процессов оператора связи. Как минимум интегратор должен обладать соответствующими знаниями и навыками, чтобы инициировать и поддержать правильное и своевременное проведение изменений, необходимых для внедрения предлагаемых OSS-решений.
Александр Куник