Студопедия
Случайная страница | ТОМ-1 | ТОМ-2 | ТОМ-3
АвтомобилиАстрономияБиологияГеографияДом и садДругие языкиДругоеИнформатика
ИсторияКультураЛитератураЛогикаМатематикаМедицинаМеталлургияМеханика
ОбразованиеОхрана трудаПедагогикаПолитикаПравоПсихологияРелигияРиторика
СоциологияСпортСтроительствоТехнологияТуризмФизикаФилософияФинансы
ХимияЧерчениеЭкологияЭкономикаЭлектроника

Подсистема Контакт-центр

Читайте также:
  1. Автоматизация расчетов. Подсистема TelBill
  2. Областная территориальная подсистема РСЧС
  3. Подсистема прерываний микроконтроллера
  4. Подсистема сбора данных и их биллинговой предобработки TelCharge

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

Контакт-центр обеспечивает следующие виды интерфейсов с пользователями:

• личное посещение (TelPOS);

• телефонные обращения (Cal Center, TCCS);

• факсимильные обращения;

• электронную почту;. сеть INTERNET;

• почтовые обращения;

• другие виды и способы обращений.

Общая структура Контакт-центра представлена на рис. 27.14.

 

Рис. 27.14. Общая структура Контакт-центра

 

Входящий в состав Контакт-центра пункт комплексного обслужива­ния и предоставления услуг связи - TelPos - является информаци­онно-технологической подсистемой Foris OSS, обеспечивающей ком­плексное обслуживание и предоставление всего спектра услуг связи абонентам при их личном обращении.

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

Общая структура пункта комплексного обслуживания и предостав­ления услуг связи (TelPos) представлена на рис. 27.15.

Операторский центр (Call Center) обеспечивает оператору связи быстрый и эффективный прием и обслуживание заявок клиентов по телефону. Для реализации этой функции Call Center, с одной сторо­ны, интегрирован с оборудованием связи, обеспечивающим автома­тическое распределение вызовов (MEDIO ACD), а с другой - исполь­зует все возможности TCCS по доступу к хранилищам данных, функ­циям документооборота (подсистема документооборота Workflow).

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

 

Рис. 27.15. Общая структура TelPos

 

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

Контрольные вопросы

 

1. Перечислите задачи, решаемые продуктами Foris OSS на различных уровнях пирамиды TMN.

2. Перечислите функциональные модули и платформы, которые входят в состав системы Foris OSS.

3. Сформулируйте основные достоинства системы Foris OSS.

4. Каковы функции подсистемы TelBili?

5. Из каких модулей состоит подсистема TelBili?

6. Какие задачи позволяет решить подсистема TelMD?

7. Какие возможности обеспечивают функциональные модули подсистемы TelMD?

8. Перечислите достоинства подсистемы TelCharge.

9. Из каких модулей состоит подсистема TelRC и каковы их функции?

10. С какими подсистемами TelRC осуществляет информационное и функ­циональное взаимодействие?

11. Кем может формироваться запрос на ограничение исходящей связи?

12. Перечислите варианты применения системы «Электронный замок».

13. Сформулируйте задачи, решаемые подсистемой поддержки клиентов.

14. Какие виды обращений поддерживает подсистема TCCS?

15. Для чего предназначена подсистема Контакт-центр?

16. Изобразите структуру Контакт-центра.

17. Какие виды интерфейсов обеспечивает Контакт-центр с пользователями?

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

1. http://www.strom.cz.


Заключение к IV части. Тенденции развития систем управления

 

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

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

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

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

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

Современные технологии программирования, используемые в ар­хитектуре платформ управления, стремятся обеспечить следующие свойства платформы:

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

• использование технологии объектно-ориентированного про­граммирования;

• программирование в рамках архитектуры менеджер-агент;

• использование распределенной системы сервисов управления, организованных по трехуровневому принципу менеджеров -менеджер-агент;

• интеллектуальность;

• организация единой системы данных;

• создание широкого набора клиентских компонент с помощью языка вызова интерфейсов серверных компонент;

• собственный метод (протокол) для организации взаимодейст­вия всех упомянутых компонентов;

• инструментарий для гибкого и широкомасштабного моделиро­вания объектов управления;

• собственная система защиты информации;

• регламентация взаимодействия с транспортными протоколами.

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

Нельзя не остановиться на таком важном вопросе, как появление осенью 1997 г. новой группы продуктов, которая в настоящее время преобразовалась в инструментарий по разработке средств управле­ния телекоммуникационными сетями на основе технологии Corba (Common object request broker architecture). Сейчас эта группа продук­тов называется HP OpenView Telecom Corba Products. Использование Corba в качестве транспортной составляющей при разработке управ­ляющих приложений становится все более популярным подходом. К тому же с помощью Corba реализуются все 4 уровня управления, охватываемые TMN.

Внедрение Corba вместо (или вместе) SNMP и СМ!Р обусловлено как коммерческими факторами, так и особенностями технологий про­граммирования. По мнению западных экспертов, Corba предоставля­ет более мощные средства для реализации распределенности при построении систем управления крупными сетями по сравнению с воз­можностями SNMP. Одновременно с этим реализация TMN с исполь­зованием Corba более современная и менее сложная технология, не­жели аналогичная реализация, ориентированная исключительно для создания управляющих приложений и управляемых агентов, обеспе­чивая при этом сосуществование с другими технологиями (например, CMIP-агентом может управлять Corba-менеджер). На технологии Corba организуется «прозрачный» транспорт для разнородных аген­тов и приложений. Но и здесь есть несколько проблем. Основная из них связана с клиентом. В данном случае встает вопрос о том, как можно использовать Corba для обеспечения доступа к агенту Corba стороны управляющего приложения (использование Corba для созда­ния самих агентов или менеджеров - проблема более простая). Для решения этой задачи предлагаются статистический и динамический подходы.

Технология Corba применима в любой области, CMIP изначально ориентирован на управление в телекоммуникационных сетях. Поэто­му, внедрение Corba для реализации транспорта не требует обяза­тельной ориентации на соединение, что необходимо в CMIP. Кроме того, приложения в Corba могут быть на разных языках (Java, С ++, С, COBOL, Smalltalk), в CMIP только на С ++. Использование, например, Java и специального встроенного ORB в Netscape Browser изначально вводит Corba в среду Web-технологий, что недоступно для CMIP. В обеих технологиях поддержка процессов может быть осуществлена в реальном времени. Что касается возможностей моделирования и реализации специальных управленческих функций, то в CMIP эта ра­бота сделана, в Corba это находится в процессе разработки.

Сегодня для разных задач используются три различные техноло­гии, поддерживающие концепцию распределенных объектных систем. Это технологии RMI (Remote Method Invocation, т.е. вызов удаленного метода), Corba (Common object request broker architecture) и DCOM (Distributed Component Object Model). Имеются многочисленные пуб­ликации, описывающие и сравнивающие эти технологии. Каждая имеет ряд уникальных свойств и преимуществ, но с точки зрения по­строения систем управления Corba предпочтительнее, и именно она многими избрана базовой.

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

Князев К.Г., Гурдус А.О. Новые ресурсы сетевого управления // Тр. Междунар. Акад. Связи № 2 (18) (прилож. к журналу «Электросвязь»). 2001 г. с. 20-24.


Приложение 1. Язык обмена «человек - машина»

Область применения и возможности. Язык обмена «ЧЕЛОВЕК-МАШИНА» (ЯЧМ), или MACHINE LANGUAGE (MML), может использо­ваться для упрощения и унификации следующих процессов в систе­мах коммутации с программным управлением [1]:

- административного управления;

- технической эксплуатации (ТЭ);

- технического обслуживания (ТО);

- монтажа и испытаний.

На рис. П1.1 показаны те интерфейсы, где рекомендуется исполь­зовать ЯЧМ.

Этот язык позволяет реализовать ввод команд (данных), вывод ре­зультатов обработки, управление запуском действий и процедур. Ввод команд и данных и управление запуском действий и процедур выполняется человеком, а реализация процедур и вывод результатов реализуются управляющей системой электросвязи (УСЭ). Процедуры в процессе ТЭ, ТО и администрирования могут запускаться как чело­веком, так и машиной. Язык обмена «человек-машина» состоит из двух частей - входящей и исходящей. Входящая часть используется при вводе символов в УСЭ, а исходящая - при выводе сообщений из УСЭ. Основное понятие входящей части языка - директива. Дирек­тива - это запрос оператора в форме, понятной УСЭ.

 

Рис. П1.1. Цели использования ЯЧМ

 

ОСНОВНЫМИ СВОЙСТВАМИ ЯЗЫКА «ЧЕЛОВЕК-МАШИНА» ЯВ­ЛЯЮТСЯ:

а) простота изучения и использования;

б) допускает применение как прямого режима, когда директива со­держит одну параметрическую часть, так и режима продолжений, ко­гда параметрические части одной команды вводятся и обрабатыва­ются по частям;

в) допускает как сокращенную, так и полную формы предостав­ления информации при вводе и выводе;

г) пригоден для различных национальных языков, категорий пер­сонала и организационных требований.

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

Ввод директив может выполняться любым устройством, исполь­зующим код № 5 ITU-T (см. п. «Знаковый алфавит»). Как правило, та­ким устройством является клавиатура.

Вывод может выполняться любым устройством, воспринимающим информацию кодом № 5 ITU-T (печатающим устройством, дисплеем и др.). Рекомендуется два основных формата печати - F1 (соответству­ет стандартному размеру листа А4) и F2 (соответствует бумажному рулону шириной 278 мм).

Знаковый алфавит. Подмножество знаков, выделяемых для ЯЧМ. Набор знаков ЯЧМ - некоторое подмножество международного алфа­вита № 5 (табл. П1.1). В этом наборе рекомендуется использовать раз­ные графические символы для цифры 0 (ноль) и заглавной буквы О. Для ЯЧМ выделены знаки, приведенные в табл. П1.1. Позиции со зна­ком а резервируются для национального использования. Незаполнен­ные места в табл. П1.1 могут быть использованы в соответствии с пра­вилами, приведенными в Рекомендации Z.100 [2]. Каждой позиции (pos) таблицы соответствует свой двоичный семиразрядный код.

Классификация знаков:

1. Буквы латинского алфавита.

2. Цифры (арабские).

3. Разделители: запятая, точка, двоеточие, знак равенства, дефис (-), апостроф ('), &, /, больше чем [>], левая скобка [(], правая скобка [)].

4. Индикаторы: меньше чем [<], *,?, точка с запятой [;].

5. Управляющие знаки:

5.1. Знаки спецификации формата: перевод строки [LF], возврат каретки [CR], пробел [SP];

5.2. Операторы в арифметических выражениях: +, -, *, /;

5.3. Знаки, используемые в символических именах: знак числа [#], +, %;

5.4. Неспецифицированные знаки:!, подстрочная черта [_], $, ан­нулирование [CAN], кавычки ["].

 

Табл. П1.1. Международный алфавит № 5 ITU-T


Дата добавления: 2015-07-20; просмотров: 104 | Нарушение авторских прав


Читайте в этой же книге: Интеграция АСР с системами управления TMN | Основные технические требования для АСР | Обзор автоматизированных систем расчетов | Архитектура систем управления сетями и сетевыми элементами | Системы управления первичными и вторичными сетями | Взаимоувязанной сетью связи Российской Федерации | Общая характеристика семейства продуктов Foris OSS | Автоматизация расчетов. Подсистема TelBill | Многофункциональные подсистемы сбора данных и взаимодействия с АТС | Подсистема сбора данных и их биллинговой предобработки TelCharge |
<== предыдущая страница | следующая страница ==>
Подсистемы TelRes, TelTE, TelRC| Метаязык для описания синтаксиса и процедур

mybiblioteka.su - 2015-2024 год. (0.012 сек.)