Эксплуатация сетей связи: эволюция стандартизации систем OSS/BSS и применение карты TAM

В последние годы рынок программного обеспечения OSS/BSS (Operations Support Systems/Business Support Systems) демонстрирует постоянный и довольно быстрый рост. И сегодня уже можно говорить о том, что он вышел на новый уровень. Связано это в первую очередь с изменением подхода к внедрению решений OSS/BSS. До недавнего времени, закупая ту или иную систему поддержки своей деятельности, оператор, как правило, решал лишь отдельные разрозненные задачи, не ставя перед собой цели комплексной автоматизации. Это было обусловлено рядом факторов, в частности незрелостью технологий, высокими затратами, отсутствием единых стандартов, позволяющих проводить быструю интеграцию модулей. Как следствие, в эксплуатации находились слабо интегрированные системы, зачастую реализующие практически идентичные функции и не позволяющие наладить централизованное сквозное управление бизнес-процессами.

Роль систем OSS/BSS в автоматизации

При эксплуатации и обслуживании сложной сетевой инфраструктуры перед оператором связи традиционно встают следующие проблемы:

—       слабая и неоперативная информационная поддержка специалистов, обслуживающих сеть;

—       противоречивые интерпретации проблемных ситуаций и недостаточная информированность сотрудников на всех уровнях организации в процессе принятия решений;

—       несовершенство механизмов сбора, хранения и обновления информации о функционировании сети;

—       необходимость вручную осуществлять множество рутинных операций.

Системы поддержки бизнеса и операционной деятельности OSS/BSS направлены на решение подобных задач. Говоря о системах OSS/BSS, к бизнес-деятельности относят прежде всего процессы, «выходящие» на клиента, такие как обработка и выставление счетов, сбор платежей, оформление заказа, предложение новых продуктов и т. п. Однако наиболее удобной представляется общая классификация систем поддержки, основанная на модели eTOM (enhanced Telecom Operations Map). Помимо систем OSS/BSS для процессов управления предприятием вводится понятие соответствующей системы поддержки – ESS (Enterprise Support System), примером которой может служить система класса ERP. Иногда вместо OSS/BSS употребляют термин OSS, подразумевая под ним весь комплекс ПО, информационных систем и соответствующих процессов. Таким образом, в понятии OSS объединяют функции как собственно OSS, так и систем BSS и ESS.

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

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

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

Решения OSS/BSS способствуют выполнению широкого круга задач, среди которых можно указать следующие:

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

Практика показала, что при разработке и внедрении решений OSS/BSS важно придерживаться ряда правил:

• построение системы OSS/BSS целесообразно осуществлять снизу вверх: от контроля и управления физическими ресурсами к решению бизнес-задач;
• повышенное внимание следует уделять управлению инфраструктурой ресурсов и услуг компании;
• необходимо выявлять и устранять функциональные и семантические пробелы в системе;
• в качестве основы для объединения подсистем в единый комплекс необходимо рассматривать не интеграционную платформу или промежуточное программное обеспечение, а сквозные бизнес-процессы предприятия.

Эффективность работы программного комплекса OSS/BSS напрямую зависит от его способности контролировать и управлять так называемым физическим уровнем – собственно элементами сети связи, которые могут быть разделены на несколько технологических сегментов (доменов). Указанные функции включают в себя следующие компоненты: отслеживание физических ресурсов и их состояния, инвентаризация сети на основе информации о физических ресурсах и построение логического каталога ресурсов.

Процессный подход положен в основу работы большинства современных систем OSS/BSS. Это позволяет отслеживать и оценивать работу всех подразделений компании на всех уровнях – от ресурсов до конечного продукта, что дает оператору возможность видеть не только сеть связи, но и бизнес в целом. С технологической точки зрения все более значимую роль в построении систем OSS/BSS играют SOA и BPMS.

Отражается на развитии систем OSS/BSS и происходящая в отрасли конвергенция телекоммуникационных и информационных технологий, а также фиксированной и мобильной связи. К универсальному OSS/BSS-решению, с одной стороны, идут разработчики традиционных систем OSS, с другой – производители ИТ-ориентированных платформ управления предоставлением контента, с третьей – разработчики, специализирующиеся в области управления сетями сотовой подвижной связи и IMS (IP Multimedia Subsystem).

Все современные OSS/BSS можно разделить на две основные группы. К первой относятся системы, построенные по принципу сборки на базе некоторой интегрирующей платформы единого решения из отдельных модулей – программных продуктов от разных производителей. Ко второй группе относят комплексные коробочные решения от одного поставщика, объединяющие в себе несколько типовых компонентов.

Выбор типа системы OSS/BSS зависит от множества факторов: времени и средств, выделяемых на ее внедрение, наличия уже существующих систем, требований к функциональности.

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

На рис. 1 представлен типовой набор модулей OSS/BSS, используемых для автоматизации деятельности поставщика услуг связи. Голубым цветом показаны модули, которые принято относить к системам OSS, красным – к BSS.

Приведенная классификация является условной. В зависимости от функциональности разрабатываемых компонентов производители программного обеспечения могут давать им названия, отличные от указанных, и объединять или разделять их функции по своему усмотрению.

Устранить подобные расхождения в классификации модулей OSS/BSS и обеспечить взаимопонимание между поставщиком программного обеспечения и его потребителем – поставщиком инфокоммуникационных услуг призвана разработанная TM Forum (Tele Management Forum) карта приложений TAM.

Назначение и принципы построения TAM

В условиях растущей конкуренции эффективная работа системы OSS/BSS становится критически важной для построения оптимальной модели бизнеса компании связи. Поэтому упорядочивание уже работающих приложений, а также продуманная политика по развертыванию новых модулей OSS/BSS приобретают все большее значение.

Карта приложений телекоммуникационной компании – TAM (Telecom Applications Map), которую также называют средой приложений (Application Framework), входит в концепцию Frameworx и содержит классификацию функций программных приложений и информационных систем, задача которых – автоматизация деятельности инфокоммуникационной компании. Являясь одним из компонентов Frameworx, карта приложений TAM связывает процессы eTOM и элементы информационной модели SID (Shared Information and Data Model), с одной стороны, с функциями программных приложений и модулей системы OSS/BSS – с другой. Таким образом, TAM обеспечивает основу для установления соответствия между бизнес-процессами поставщика услуг связи и функциями существующих или разрабатываемых модулей OSS/BSS.

Разработка карты TAM основана на принципах максимальной универсальности и уровневой иерархии. При этом уровень обобщения функций, входящих в блоки карты TAM, выбран таким образом, чтобы сохранять связь с реалиями отрасли и соответствовать принятым в ней представлениям и нормам, касающимся систем и технологий управления и автоматизации. В основу иерархии уровней карты TAM легли как уровни eTOM и домены SID, так и уровневая структура модели TMN (Telecommunications Management Network), дополненная задачами управления не только сетью связи в целом, но и отдельными ресурсами.

Центральным элементом карты приложений TAM является программное приложение. Под приложением TAM понимают абстрактную совокупность логически связанных между собой функций или других приложений, которая может быть реализована в виде программного продукта. Функции, которые объединяет в себе приложение, называют функциональными требованиями к его реализации. Функциональное требование представляет собой словесное описание функциональных возможностей, которые необходимы для выполнения конкретной задачи.

Как правило, при формировании функциональных требований приложения TAM объединяют функции, связанные с выполнением некоторой задачи (например, «Управление решением проблем с услугами») или работой с некоторой сущностью (например, «Управление жизненным циклом продукта»). Кроме того, в отдельные приложения могут быть выделены функции, повторяющиеся в разнообразных процессах, или между которыми прослеживается явная связь (например, «Подготовка писем»).

Существуют четыре фактора, которые могут послужить поводом для объединения низкоуровневых приложений:

• наличие общих функций или предоставление сервисов общему набору приложений;
• удобство использования с точки зрения конечного пользователя, который предпочитает обращаться к необходимым в повседневной работе функциям из одного приложения;
• общее предназначение и близость решаемых задач;
• работа с одними и теми же информационными сущностями SID.

Приложения TAM функционируют в сервисно-ориентированной среде и взаимодействуют посредством бизнес-сервисов Frameworx, являющихся разновидностью сервисов SOA. Бизнес-сервис позволяет предоставлять функциональные возможности одного приложения другому. При этом в отличие от «классической» SOA каждое приложение TAM объявляет набор не только предоставляемых, но и потребляемых сервисов. Предполагается, что каждый объявленный бизнес-сервис используется хотя бы одним приложением, и желательно, чтобы только одно приложение карты осуществляло предоставление того или иного сервиса.

На карте TAM приложения объединены в домены, структура которых представлена на рис. 2. Карта приложений построена в виде матрицы, столбцы которой соответствуют вертикальным группировкам бизнес-процессов eTOM, а строки – доменам SID. Вертикальные группировки представляют собой второстепенную классификацию приложений ТАМ, не являющуюся частью таксономии, так что одно приложение может одновременно относиться к нескольким из них. Перечень вертикальных группировок TAM имеет вид, показанный в верхней части рис. 2.

Горизонтальные группировки – домены – составляют верхний уровень основной классификации (таксономии) приложений. Каждое приложение TAM принадлежит одному и только одному домену. В отдельные домены, не являющиеся частью показанной на рис. 2 матрицы, выделены общие для нескольких доменов (кросс-доменные) приложения, а также функции интеграционной инфраструктуры.

В текущей версии карты TAM максимальная глубина декомпозиции доменов составляет четыре уровня: 0-й уровень – домены; 1-й уровень – приложения; 2-й и 3-й уровни – детализация функциональных требований приложений (детализация до 3-го уровня выполнена не для всех из них). Для упорядочивания элементов карты TAM им присвоены уникальные цифровые идентификаторы. Подобный идентификатор имеет иерархическую структуру «D.a.b.c.d», где «D» указывает на домен (они пронумерованы от 3 до 9), «a» – номер приложения внутри домена (1-й уровень), «b», «c», и «d» указывают на детализацию функций приложения на последующих уровнях.

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

Важным преимуществом карты TAM является ее совместимость с другими компонентами Frameworx. Функциональные требования приложений могут быть увязаны с бизнес-процессами карты eTOM, их интерфейсы – с бизнес-сервисами среды интеграции Frameworx, а используемые данные – с информационной моделью SID. Все это упрощает последующую интеграцию модулей в систему OSS/BSS и их эксплуатацию. Однако соответствие между приложениями TAM и процессами-элементами eTOM далеко не всегда является взаимно однозначным. Необходимо также подчеркнуть, что карта приложений ТАМ рассматривает в деятельности компании связи только автоматизированные функции в отличие от карты бизнес-процессов eTOM, элементы которой могут соответствовать задачам, выполняемым вручную.

Карта TAM предназначена для использования поставщиками инфокоммуникационных услуг, разработчиками программного обеспечения, системными интеграторами и другими участниками отрасли. Она предлагает единый, содержащий одинаково трактуемые понятия язык для определения и описания функций решений OSS/BSS. Операторы связи могут применять карту TAM для инвентаризации и упорядочения имеющейся инфраструктуры ПО, использовать ее как системообразующую основу при трансформации инфраструктуры или формулировании требований к приложениям и набору модулей. Все более широкое применение карта TAM находит в компаниях – поставщиках решений OSS/BSS, становясь универсальным средством описания их возможностей, облегчая продвижение таких систем на рынке и предоставляя базу для их сравнения и совместной эксплуатации. В таблице приведен пример подхода к использованию карты TAM для описания функциональных требований и сопоставления решений OSS/BSS, предлагаемых различными разработчиками.

Таблица. Использование TAM для сопоставления решений OSS/BSS

В вопросах инвентаризации, анализа избыточности и возможностей многократного использования функций эксплуатируемых и предполагаемых к внедрению модулей OSS/BSS карта TAM как эталонная модель играет ту же роль, что и карта eTOM по отношению к бизнес-процессам компании связи. Ориентируясь на TAM, компания может построить структуру функций уже установленных модулей OSS/BSS, выявить те из них, которые можно было бы использовать для поддержки нескольких бизнес-процессов, а также сформировать перечень функций, которыми систему OSS/BSS необходимо дополнить. Общая схема шагов такого процесса структуризации и анализа функций модулей OSS/BSS представлена на рис. 3.

Как единый стандарт классификации функций компонентов OSS/BSS карта TAM создает основу для их соотнесения с бизнес-процессами оператора связи, что упрощает решение задачи автоматизации и позволяет повысить ее уровень и уровень управляемости бизнеса в целом. Важным свойством карты TAM является поддержка концепции многократного использования различных функций компонентов системы OSS/BSS. Фактически карта предлагает стандартный набор требований к этим функциям.

В совокупности с принципами интеграции компонентов, также определенными в рамках концепции Frameworx, карта TAM позволяет гибко настраивать конфигурацию модулей управляющих приложений.