Product Lifecycle Management. Популярно о процессах управления жизненным циклом телекоммуникационных услуг

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

Наверное, следует начать с терминологии. Под услугой мы понимаем коммерческий продукт (product), который предоставляется конечному пользователю, имеет стоимость и условия обслуживания, подразумевает наличие договора на его предоставление. Вы можете видеть, что на рынке представлено множество телекоммуникационных услуг по самым разным ценам и на самых разных условиях, но все они обеспечиваются узким спектром телекоммуникационных сервисов (service). Сервисы могут быть базовыми и дополнительными, и все они обеспечиваются стеком информационных систем и телекоммуникационного оборудования. Чтобы лучше понять различия между продуктом и сервисом можно привести пример: доступ в интернет является сервисом, а доступ в интернет со скоростью 10Mbps по цене 600р в месяц является продуктом.

Так как сервисы являются основой бизнеса предприятий связи, обеспечение процессов управления их жизненным циклом является очень важной функцией. Построение PLM (product lifecycle management) процессов всегда начинается с разработки модели сервисов. Существует множество методологий, но самой распространенной является модель TMForum SID (Shared Information Data). Я хочу на примере этой модели рассказать как появляются сервисы. Начать следует с метамодели, которая в упрощенном виде выглядит следующим образом:

В модели представлены три класса сущностей. Сущность класса Customer Facing Service (CFS) это сервис, который непосредственно использует конечный пользователь, например пресловутый доступ в интернет. Сервис CFS является минимальной атомарной единицей для создания коммерческого продукта. Сущность класса Resource Facing Service (RFS) это сервис, который предоставляется телекоммуникационным оборудованием или информационной системой и обспечивает существование сервиса CFS, например одним из таких сервисов для обеспечения доступа в интернет является авторизационный сервис AAA сервера. Как правило, конечный пользователь ничего не знает о сервисе RFS. Сущность класса Resource это спецификаци телекоммуникационного оборудования или информационной системы, обеспечивающей сервис RFS. Важно отметить, что структура сервисов может быть иерархичной и иметь множественную вложенность.

Управление моделью сревисов и их жизненным циклом осуществляется в информационной системе с неожиданным названием сервисный каталог (service catalogue), так же её называют технологический каталог. Сервисный каталог, неспроста, занимает центральное место в стеке систем сервисного уровня информационных систем предприятия по TMForum TAM (Telecomm Application Map), так как он является именно тем стыком между технологиями и коммерцией. На базе моделей и спецификаций сервисов, заложенных в каталоге, работают такие информационные системы сервсиного стека, как Service Order Management, Service Inventory, Service Provisioning, Service Assurance и другие. Важно понимать, что когда я говорю о системах, я подразумеваю роли. Зачастую, одна промышленная информационныя система может исполнять сразу несколько ролей. Такие системы предлагают многие производители решений для телекоммуникаций, как Oracle, Amdocs, Comptel, HP и другие.

На этом закончим с теорией и перейдем к практике – попробуем построить модель сервисов. Давайте представим, что мы установили новый сетевой элемент и опубликовали его спецификацию. Для примера я выбрал SIP сервер, который может быть, как отдельностоящей системой, так и частью, например, IMS. SIP сервер предоставляет голосовую связь по IP каналам. SIP телефония имеет огромные преимущества перед аналоговой или цифровой, т.к. может полноценно использоваться в облаках. Другими словами, мы можем позволить абоненту воспользоваться сервисом из дома (имея нашу локальную сеть), мобильного телефона (по локальной сети мобильного оператора или с использованием GPRS/LTE), из любой точки мира по IP каналу (например, WiFi в Starbucks где-нибудь в Лондоне). В общем и целом сервис сугубо облачный и конвергентный.

Получив спецификацию SIP сервера мы, в первую очередь, должны выяснить какие сервисы RFS он предоставляет, чаще всего это:

• Подписка на голосовую связь (subscription) – данный сервис является базовым и от него зависят все остальные сервисы.

• Внешний телефонный номер (phone number) – допольнительный сервис для приемы звонком с мобильных или городских номеров.

• Переадресация вызова (call forwarding) – дополнительный сервис.

• Удержание вызова (call waiting) – дополнительный сервис.

• Авто-определитель номера (calling line identification) –дополнительный сервис.

Как правило, SIP сервера предоставляют огромный спекрт различных дополнительных сервисов, но я предлагаю ограничиться этими пятью. Предлагаю отрисовать модель сервисов RFS:

На модели представлен ресурс, и ресурсные сервисы (RFS), которые он предоставляет. Четыре дополнительных сервиса (supplementary service) зависят от базового (basic service). Однако, данный сервис нельзя предоставлять клиенту без IP линии, поэтому в модели можно дополнительно указывать зависимости от сервисов, которые описывают линии, как мобильный доступ, широкополосный доступ, беспроводный широкополосный доступ и другие.

Далее следует определить сервис CFS, который потом ляжет в основу множества коммерческих продуктов с различными опциями и условиями предоставления. В качестве примера, можно все пять сервисов RFS объединить в один сервис CFS с опциями:

Важно понимать, что не только сервис CFS может иметь опции, но и сервисы RFS также.
Все опции и параметры сервиса составляют его спецификацию. В спецификации также описываются зависимости, взаимоисключения, кардинальность и функции по управлению сервисом (как правило по CRUD – create, read, update, delete). В результате мы построили полноценную сервисную модель с определенными упрощениями.

Теперь стоит остановиться на функциях управления, которые на общепринятом языке называются Fulfillment Functions. Для сервиса каждая функция описывает, как минимум правила его дизайна, активации на сети, сохранения в системе инвентаризации и постановку на мониторинг. За последовательность и корректность исполнения всех функций отвечает система Service Order Management, а непосредственно сущность, которой она управляет это сервисный заказ или Service Order. Существует базовая методология описания функций управления: design, assign, activate.

• Дизайн (design) подразумевает под собой процесс проектирования сервиса для конкретного конечного пользователя, резервирование или построение сетевых ресурсов. За процесс дизайна отвечают такие системы как Network Planning, Network Resource Inventory и непосредственно Service Order Management (это одна из функций данной системы, помимо управления всем процессом в целом).

• Подписка (assign) подразумевает процесс сохранения сервиса в системе инвентаризации и постановку его на мониторинг. За подписку отвечает системы Service Inventory и Service Assurance.

• Активация (activate) подразумевает процесс конфигурации сетевых элементов, обеспечивающих предоставления сервиса. За активацию отвечает системы Service Provisioning или Service Activation.

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

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