В рубрику "Решения операторского класса" | К списку рубрик | К списку авторов | К списку публикаций
Ранее в своих публикациях авторы неоднократно обсуждали актуальность внедрения систем эксплуатационной поддержки OSS. За счет их внедрения снижаются издержки, повышается качество обслуживания абонентов, появляется возможность предоставления новых услуг: онлайн-управление услугами в личном кабинете, мгновенное предоставление услуг - турбо-кнопка, каналы IPTV и пр.
В настоящей статье мы решили взглянуть на два фундаментальных для своей технологической области решения. Система технического учета, или Inventory, является фундаментом для OSS-инфраструктуры оператора, поскольку она занимается информационным обеспечением и без нее функционирование других систем невозможно. Транспортная сеть оператора служит основой для всех его сервисов, и именно в этой части сети действуют наивысшие нормы на выполнение эксплуатационных процессов, которые непосредственно влияют на качество всех услуг, предоставляемых оператором. Таким образом, решение Inventory для транспортной сети - одна из важнейших составляющих инфраструктуры оператора.
Сейчас подобные решения есть у многих вендоров OSS и в портфелях системных интеграторов, и от оператора требуется не только сделать правильный выбор, но и грамотно составить спецификацию системы, чтобы она удовлетворяла его потребности как на текущий момент, так и в перспективе.
Конечная цель оператора связи при работе с требованиями - получить технические требования, чтобы можно было объявить тендер и/или передать их в разработку выбранному поставщику. То есть эти требования являются связующим звеном между оператором и разработчиком OSS.
Исходными данными для разработки технических требований являются требования бизнеса оператора связи, его потребности. Эти требования понятны менеджменту оператора и в начале работы должны быть утверждены и формализованы.
Однако переход от требований бизнеса (таких как "повысить качество обслуживания абонентов") к техническим требованиям (таких как "система должна запросить исходные данные для регистрации заказа на подключения новой услуги от абонента: список обязательных исходных данных") не является очевидным. Учитывая стоимость приобретения систем класса Inventory, появляются серьезные риски неэффективных капиталовложений из-за наличия противоречивых, дублирующих или избыточных технических требований.
Для снижения этих рисков используются аналитические бизнес-требования, которые обосновывают наличие технических требований, поэтапно детализируя требования бизнеса:
Источниками для аналитических требований являются бизнес-цели и бизнес-процессы оператора связи, телекоммуникационные технологии, используемые на его сети, отраслевые стандарты эксплуатационного управления.
Бизнес-процесс описывает последовательность действий и принятия решений для достижения бизнес-цели. Система Inventory обеспечивает для этих действий и решений информационную поддержку, поэтому должен быть составлен список характеристик транспортной сети, актуальные данные которых требуются в бизнес-процессах. В данной статье мы ограничимся анализом процессов из групп Fulfillment (проверка технической возможности, подготовка проекта предоставления услуги, бронирование ресурсов) и Assurance (диагностика инцидента, диагностика проблемы) модели еТОМ.
Технологии транспортной сети определяют перечень элементов и характеристик, которые будут учитываться в системе Inventory. Бизнес-процессы оператора сужают полный перечень этих характеристик до того уровня, который востребован для информационной поддержки процессов.
На транспортной сети обычно используются следующие технологии:
Стандарты позволяют организовать учет характеристик транспортной сети универсальным способом. Нужно это, чтобы не разрабатывать каждый раз новый список характеристик для каждой технологии индивидуально, а использовать апробированные шаблоны для целого класса технологий. 1 Э.ЮК6 поддержка стандартов облегчает и удешевляет последующие процессы интеграции систем.
В качестве хорошего примера для демонстрации моделирования конкретных технологий в этих понятиях можно обратиться к стандартам G.705 (PDH), G.783 (SDH), I.326 (ATM), G.8110 (MPLS), G.8110.1 (T-MPLS), однако необходимые для учета в системе Inventory характеристики там также перечислены не будут, так как целью стандартов является описать прохождение каналов, а не тех характеристик, которые участвуют в бизнес-процессах оператора.
Для формирования требований к системе Inventory транспортных сетей существует множество источников. Обозначив основные из них, следует отметить, что для организации модели учета Inventory в стандартах разработаны технологически нейтральные модели, которые дают большую свободу моделирования транспортных технологий, но готовых шаблонов для моделирования конкретных технологий нет. Каждый оператор должен индивидуально ограничить учет характеристик телекоммуникационных объектов теми, которые будут использоваться в его бизнес-процессах, поскольку принцип "пусть будет" здесь работает негативно: во-первых, увеличивает стоимость системы, а во-вторых, любая информация в Inventory - это не просто мертвый груз, а сущность, требующая актуализации, взаимодействия с другими элементами учета, передачи через интеграционные интерфейсы и т.п., соответственно увеличиваются трудозатраты персонала.
Далее мы приведем пример части аналитических требований к системе Inventory, составленный на основе вышеприведенных источников. В реальных проектах таких характеристик окажется намного больше, но приведенные нами не зависят от специфики оператора и могут быть использованы практически в любых вариациях бизнес-процессов Fulfillment и Assurance.
Автономная система - группа устройств, для которых нарушается выполнение бизнес-требования, поддержки актуальности данных. Внутри автономной системы актуальность характеристик полностью или частично не обеспечивается.
Понятие описывает группу устройств сети, которыми автоматически управляет система EMS. Для таких групп устройств подвергаются учету только внешние характеристики, описывающие коммуникацию этих устройств с внешним миром. Это пограничные устройства в группе и их внешние интерфейсы. Актуальность многих хранимых данных в таких доменах тяжело обеспечить, так как они, например, могут быть изменены системой EMS без согласования с Inventory.
Оценка ресурсов в процессах подключения новой услуги или поиска неисправностей производится на каждом из уровней, поэтому данные о них и о их связи должны храниться в системе Inventory.
Характеристики уровней сети описывает используемый стек телекоммуникационных технологий (например, IP - MPLS - VLAN).
Процессы Assurance и Fulfillment учитывают зоны административной ответственности для групп устройств. Объединение объектов транспортной сети в группы позволяет закрепить за ними ответственные эксплуатационные подразделения оператора.
Канальные технологии:
Пакетные технологии:
В данной статье мы рассмотрели процесс формирования базовых требований к системам Inventory транспортных сетей. Ключевым моментом здесь является использование аналитических требований, которые часто упускают в ходе формирования технического задания, делая его фрагментарным и неполным.
На данный момент существуют готовые модели, которые позволяют описывать характеристики сети очень детально, однако это избыточно усложнит процессы актуализации и увеличит стоимость системы. Следует ограничить степень детализации хранимых характеристик, чтобы их объема хватало для принятия всех решений в целевых бизнес-процессах. Мы постарались привести ограниченный пример процесса построения таких требований, но он показывает лишь начало пути, по которому оператор должен пройти сам, учитывая собственные особенности технологий и бизнес-процессов.
Опубликовано: Журнал "Технологии и средства связи" #2, 2013
Посещений: 11766
Статьи по теме
Автор
| |||
Автор
| |||
Автор
| |||
В рубрику "Решения операторского класса" | К списку рубрик | К списку авторов | К списку публикаций
