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


Полнотекстовый поиск по базе:

Главная >> Реферат >> Информатика, программирование


Формулируем требования. Как создать оптимальную 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 г.

Похожие работы:

  • Распределенные алгоритмы

    Реферат >> Информатика, программирование
    ... Модель OSI 24 1.2.3 OSI Модель ... возможным создать ... это формулируется как «Утверждение ... следовательно, оптимальный V-путь также оптимальный путь. ... анализом его пространственных требований. Как и раньше, depth ... Gi. Буферный граф определяется как BGa = (B, ), где ...
  • Разработка автоматизированной системы управления торговым предприятием

    Дипломная работа >> Информатика, программирование
    ... KPI), а-ля BSC, то есть ... проводимые сегодня, формулируют требования таким образом, что ... определить как достижение оптимального соотношения ... был написан Oak-компилятор и Oak-браузер «WebRunner» ... Правильно организованное освещение создает благоприятные условия ...
  • Internet

    Реферат >> Коммуникации и связь
    ... современным научно-техническим требованиям с учетом ... ISO OSI предписывает очень ... как домены связаны между собой и как создаются имена ... легче, чем формулировать их на ... gopher на box.micro.umn ... 6). Видеоконференции - оптимальный выбор Как сделать правильный выбор ...
  • Билеты на государственный аттестационный экзамен по специальности Информационные Системы

    Реферат >> Информатика, программирование
    ... Universal Serial Bus) разработана ... можно создать несколько ... ПО) Oci.dll Базовый ... Как правило, заказчик не сразу формирует требования к системе в целом, а формулирует требования ... оптимального размещения и концентрации производства; составления оптимального ...
  • Обучение чтению детей на начальном этапе

    Курсовая работа >> Педагогика
    ... сочетаний, как -tion, -sion, -ous, - ... самостоятельно делают вывод (формулируют правило) и сравнивают ... выбрать оптимальный путь ... Необходимо создать атмосферу ... как выбрать наиболее удачные учебные материалы. Для этого нужно сформулировать требования ... bag. It is big. ...
  • Организация работы центра закупки компьютерной техники (на примере ООО "Аверс")

    Курсовая работа >> Маркетинг
    ... требованиям. Разработка и получение необходимых услуг, сопровождающих закупку товара (таких как ... организация создает закупочный ... Создание оптимального ассортимента, ... первоначально формулируют желаемые ... OCZ PC6400, 800Mhz, OCZ ... влагоустойчивая, color box (3) ** ...
  • Информационные технологии в строительстве

    Дипломная работа >> Информатика, программирование
    ... OSI Протоколы, примерно соответствующие уровню OSI ... формулируют следующие приоритетные требования к АППЗ при пожаре: • Как ... пределах наиболее оптимальных для человеческого ... (European Installation Bus), как это ясно из ... 485, позволяющий создать сеть, включающую ...
  • Химия, элементы таблицы Менделеева

    Реферат >> Химия
    ... с требованиями кинетической теории как при ... синтеза NO формулировалась следующим образом ... структуру (из групп BSH и атомов S). ... из цепей типа [–OSi(O2)–]n, в промежутках ... от скисания (оптимальное содержание SO2 ... атмосферы кислородом создало предпосылки для ...
  • Теория языкознания

    Реферат >> Культурология
    ... пониматься как требование вывести за ... пространства поможет создать приводимое здесь ... соб-ою /oju/). Тест на ... Pa bordet (опред.) ligger en bok (неопред). B o k ... диалогическом взаимодействии коммуникантов формулирует в виде четырёх ... поиски оптимальных средств для ...
  • Категоризация и информативный спектр картины мира

    Дипломная работа >> Иностранный язык
    ... и предмет, формулируются цели и задачи ... как правило, имеет несколько социальных ролей, и поскольку их требования ... Wortverbindungen bzw. Wortgruppen ... обычно создает у ... которые оптимально соответствуют имеющимся ... -Munchen, Verlag C.H.Beck oHG, 3. Auflage, 2002. ...