Формулируем требования. 
Как создать оптимальную OSS/BSS

Формулируем требования. Как создать оптимальную OSS/BSS

М.С. САМСОНОВ, заместитель генерального директора ОАО «Петер-Сервис».

В стремлении к идеалу

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

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

Конфигурируемость ПО можно условно разделить на четыре уровня:

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

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

Например, модуль тарификации биллинговой системы может поддерживать предопределенный набор услуг. С каждой услугой связана параметризованная ставка стоимости единицы потребления.

Конфигурируемость на основе предопределенного набора базовых объектов (framework constrained configurability) подходит для организаций, бизнес-процессы которых могут меняться, оставаясь в заранее известных границах. В этом случае комплект поставки информационной системы включает в себя предопределенный набор процессов, сущностей и служебных процедур, которые могут компоноваться произвольным образом, так, чтобы обеспечить поддержку различных бизнес-процессов. При этом для каждой конфигурации будет существовать собственный набор параметров, позволяющий «подстраивать» реализованные бизнес-процессы. Например, модуль тарификации биллинговой системы может поддерживать определение новых услуг, каждой из которых приписываются атрибуты из заранее определенного, нерасширяемого набора. С каждой услугой связана параметризованная ставка стоимости единицы потребления.

Конфигурируемость путем реализации новых базовых объектов (basis reimplementation). Иногда бизнес-процессы организации могут меняться так сильно, что информационная система предприятия должна будет поддерживать сущности, не предусмотренные в первоначальной поставке. В этом случае возможности настройки системы должны обеспечивать расширение набора процессов и сущностей. Например, биллинговая система изначально может не поддерживать Quality of Service, однако возможности системы позволят определить в ней эту сущность, правила ее использования в процессе тарификации и обслуживания абонентов и интерфейсы для редактирования соответствующих параметров. Не у всех операторов потребности в наличии различных компонентов OSS одинаковы даже на начальной фазе функционирования. Требования к составу системы операционного обеспечения появляются на стадии позиционирования компании, при формировании бизнес-планов и растут вместе с развитием компании.

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

Отсюда вывод — с универсальной системой не связано динамическое требование универсальной конфигурируемости. Речь идет только о статической возможности поддерживать бизнес-процессы конкретного оператора. В то же время универсальная OSS, которая должна быть адаптируема, в стандартной поставке может не поддерживать все бизнес-процессы конкретного оператора.

Вокруг биллинга

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

О конвергенции

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

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

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

Для примера можно сравнить разные требования к системе.

1. Система должна поддерживать расчеты за услугу передачи данных с тарификацией по объему.

Такое требование неявно подразумевает настраиваемость на основе предопределенного набора параметров и создаст проблему при внедрении, например услуги VoD с фиксированной стоимостью каждого фильма.

2.1. Система должна поддерживать модифицируемый набор услуг.

2.2. Система должна поддерживать модифицируемый набор мер потребления услуг (время, штуки, объем).

2.3. Система должна поддерживать назначение каждой услуги одной или нескольких мер потребления.

2.4. Алгоритм тарификации для услуги должен определяться назначенными ей мерами потребления.

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

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

Помимо технических требований к продукту и техническому сопровождению, заметно повысилось внимание со стороны заказчиков к самой компании-поставщику — ее надежности, позиции на рынке, опыту реализации сложных проектов, системе управления качеством, участию в ассоциациях связи и т. д. Конечно, в первую очередь это связано с огромными изменениями в масштабах и качестве бизнеса операторов связи. Клиентами «Петер-Сервиса» сегодня являются лидеры рынка, совместными проектами с каждым из них мы можем гордиться. В их числе «Дельта Телеком» (сеть «Скай Линк»), «ПетерСтар», «Ростелеком», «МегаФон», «КиевСтар», филиал JITC ОАО «Северо-Западный Телеком» — наш самый крупный клиент в области фиксированной связи.

Реализация OSS/BSS может осуществляться тремя способами. Первый подход — оператор связи разрабатывает информационные системы самостоятельно. Несомненным достоинством этого подхода является возможность добиться полного соответствия своим потребностям и глубокой интеграции с техническими средствами сети. К сожалению, мировая практика показывает, что расходы на подобное решение (с учетом последующего сопровождения и модификации) в 2,5−5 раз превышают расходы на покупку и внедрение тиражируемого решения.

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

Компания становится заложником «главного» поставщика информационной системы: развиваясь, она не имеет возможности использовать лучшие в своем классе решения. В случае локальных проблем менять придется всю информационную систему. Кроме того, как показывают результаты исследования и анализа, проведенных компанией Logan Orvis International, даже наиболее оптимальная биллипговая система сможет в лучшем случае удовлетворять не более 70% запросов и потребностей оператора, ее выбравшего.

Третий подход заключается в использовании метода бизнес-компонентов для построения системы операционного обеспечения предприятия. Под бизнес-компонентом понимается программный модуль, который имеет хорошо определенные применение и сетевые интерфейсы и позволяет взаимодействовать с распределенными информационными системами. Бизнес-компоненты ориентированы на решение определенных задач в масштабе предприятия (изоморфно соответствуют бизнес-категориям) и обладают необходимыми свойствами, связанными с параллельностью исполнения, контролем доступа и управлением транзакциями. Следует отметить, что подобный подход широко распространен при внедрении сложных информационных систем за счет трех важных преимуществ:

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

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

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

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

Список литературы

Журнал ИнформКУРЬЕРсвязь № 9, 2005 г.