Все мы пользуемся услугами связи для самых разных целей: заходим на любимые сайты и блоги, общаемся с близкими, друзьями и коллегами, ведем переговоры, смотрим любимые телепередачи или онлайн-трансляции, отправляем сообщения электронной почты.
Эпоха телекоммуникаций подарила нам невообразимые возможности и огромный спектр новых продуктов и услуг.
Одной из ключевых услуг являются непосредственно телекоммуникации: доступ в Интернет, голосовая связь, телевидение и многие другие.
Я работаю в сфере телекоммуникаций и хотел бы рассказать вам, как рождаются телекоммуникационные услуги, как они развиваются и поддерживаются и как они умирают. Наверное, стоит начать с терминологии.
Под услугой мы понимаем коммерческий продукт, который предоставляется конечному пользователю, имеет стоимость и условия обслуживания и предполагает наличие договора на его предоставление.
Вы видите, что на рынке существует множество телекоммуникационных услуг по очень разным ценам и на очень разных условиях, но все они предоставляются узким спектром телекоммуникационных услуг.
Услуги могут быть базовыми или дополнительными, и все они предоставляются комплексом информационных систем и телекоммуникационного оборудования.
Чтобы лучше понять различия между продуктом и услугой, можно привести пример: доступ в Интернет — это услуга, а доступ в Интернет на скорости 10 Мбит/с по цене 600 рублей в месяц — это продукт. Поскольку услуги являются основным видом деятельности предприятий связи, обеспечение процессов управления их жизненным циклом является очень важной функцией.
Построение процессов PLM (управление жизненным циклом продукта) всегда начинается с разработки модели обслуживания.
Существует множество методологий, но наиболее распространенной является модель TMForum SID (Shared Information Data).
На примере этой модели я хочу рассказать, как появляются сервисы.
Начать следует с метамодели, которая в упрощенном виде выглядит так: 
Модель представляет три класса сущностей.
Сущность класса службы взаимодействия с клиентами (CFS) — это услуга, которая напрямую используется конечным пользователем, например пресловутый доступ в Интернет. Сервис CFS — это минимальная атомарная единица для создания коммерческого продукта.
Сущность класса Resource Facing Service (RFS) — это услуга, которая предоставляется телекоммуникационным оборудованием или информационной системой и обеспечивает существование службы CFS, например, одной из таких служб предоставления доступа в Интернет является служба авторизации сервера AAA. .
Обычно конечный пользователь не знает о службе RFS. Объект класса Resource — это спецификация телекоммуникационного оборудования или информационной системы, предоставляющей службу RFS. Важно отметить, что структура сервисов может быть иерархической и иметь множественную вложенность.
Модель услуг и их жизненный цикл управляются в информационной системе с помощью каталога служб неожиданных имен, также называемого каталогом технологий.
Каталог услуг не зря занимает центральное место в стеке систем уровня обслуживания информационных систем предприятия по версии TMForum TAM (Карта приложений телекоммуникаций), поскольку именно он является интерфейсом между технологией и коммерцией.
На основе моделей и спецификаций услуг, содержащихся в каталоге, функционируют информационные системы стека услуг, такие как Управление заказами на обслуживание, Инвентаризация услуг, Предоставление услуг, Обеспечение обслуживания и другие.
Важно понимать, что когда я говорю о системах, я имею в виду роли.
Зачастую одна промышленная информационная система может выполнять сразу несколько ролей.
Такие системы предлагают многие производители телекоммуникационных решений, такие как Oracle, Amdocs, Comptel, HP и другие.
Закончим с теорией и перейдем к практике — попробуем построить модель сервиса.
Представим, что мы установили новый сетевой элемент и опубликовали его спецификацию.
Для примера я выбрал SIP-сервер, который может быть как автономной системой, так и частью, например, IMS. SIP-сервер обеспечивает голосовую связь по IP-каналам.
SIP-телефония имеет огромные преимущества перед аналоговой или цифровой, поскольку может полностью использоваться в облаках.
Другими словами, мы можем позволить абоненту пользоваться услугой из дома (имея свою локальную сеть), с мобильного телефона (через локальную сеть мобильного оператора или с помощью GPRS/LTE), из любой точки мира по IP-каналу ( например, Wi-Fi в Starbucks где-нибудь в Лондоне).
В целом сервис чисто облачный и конвергентный.
Получив спецификацию SIP-сервера, нам в первую очередь необходимо узнать, какие услуги RFS он предоставляет, чаще всего это:
- Голосовая подписка – эта услуга является базовой и от нее зависят все остальные услуги.
- Внешний телефонный номер (телефонный номер) – это дополнительная услуга для приема звонков с мобильных или городских номеров.
- Переадресация звонков является дополнительной услугой.
- Ожидание вызова – это дополнительная услуга.
- Определение номера вызывающего абонента является дополнительной услугой.
Предлагаю нарисовать модель сервиса RFS: 
Модель представляет ресурс и предоставляемые им ресурсные услуги (RFS).
Четыре дополнительные услуги зависят от базовой услуги.
Однако эта услуга не может быть предоставлена клиенту без IP-линии, поэтому в модели можно дополнительно указать зависимости от сервисов, описывающих линии, таких как мобильный доступ, широкополосный доступ, беспроводной широкополосный доступ и другие.
Следующим шагом является определение службы CFS, которая затем ляжет в основу многих коммерческих продуктов с различными вариантами и условиями доставки.
Например, вы можете объединить все пять служб RFS в одну службу CFS с помощью следующих опций: 
Важно понимать, что не только служба CFS может иметь опции, но и службы RFS.
Все опции и параметры услуги составляют ее спецификацию.
В спецификации также описаны зависимости, взаимоисключения, кардинальность и функции управления сервисом (обычно CRUD — создание, чтение, обновление, удаление).
В результате мы построили полноценную модель сервиса с некоторыми упрощениями.
Теперь стоит сосредоточиться на функциях управления, которые в просторечии называются Fulfillment Functions. Для сервиса каждая функция описывает, как минимум, правила ее оформления, активации в сети, сохранения в системе инвентаризации и настройки для мониторинга.
Система управления заказами на обслуживание отвечает за согласованность и корректность выполнения всех функций, а субъектом, которым она непосредственно управляет, является заказ на обслуживание или Сервисный заказ.
Существует базовая методология описания функций управления: спроектировать, назначить, активировать.
- Под проектированием понимается процесс разработки услуги для конкретного конечного пользователя, резервирования или создания сетевых ресурсов.
За процесс проектирования отвечают такие системы, как Network Planning, Network Resource Inventory и Service Order Management (это одна из функций данной системы, помимо управления всем процессом в целом).
- Подписка (назначение) подразумевает процесс сохранения услуги в системе инвентаризации и постановки ее на мониторинг.
За подписку отвечают системы Service Inventory и Service Assurance.
- Активация относится к процессу настройки сетевых элементов, предоставляющих услугу.
За активацию отвечают системы предоставления услуг или активации услуг.
Важно понимать, что правильно построенная сервисная модель напрямую влияет на процессы управления, корректность которой дает огромное преимущество предприятиям связи и телекоммуникаций при построении облачных конвергентных сервисов и позволяет в кратчайшие сроки вывести на рынок новые коммерческие продукты и технологии.
времени, что крайне важно в эпоху быстрого развития коммуникаций и растущих потребностей.
В следующей статье я также постараюсь кратко осветить процесс создания коммерческих продуктов на основе созданной сервисной модели.
Теги: #plm #услуги #продукты #управление продуктом #управление жизненным циклом продукта #телеком #телекоммуникации #активация услуг #ИТ-стандарты #Разработка систем связи
-
Удобный Bdd: Specflow+Tfs
19 Oct, 24 -
Спутниковый Мониторинг. Часть 1
19 Oct, 24 -
Арт Заменяет Далвик
19 Oct, 24
