Формулируем требования. Как создать оптимальную 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 ОАО «Северо-Западный Телеком» - наш самый крупный клиент в области фиксированной связи.

Рекомендуем скачать другие рефераты по теме: ответы, мировая экономика.





1  2 | Следующая страница реферата