Не отобразилась форма расчета стоимости? Переходи по ссылке

Не отобразилась форма расчета стоимости? Переходи по ссылке

Отчет по практике в ООО ИК «Рога и копыта»

Пример отчета по производственной практике студента 3 курса специальности «Информационные системы и технологии» Воронежского института высоких технологий АНОО ВПО.

Содержание

Введение
Глава 1. Обзор существующих решений call-центров для малых и средних предприятий
1.1 История становления российского рынка Call-центров
1.2 Состояние и перспективы рынка Call-центров
1.3 Обзор основных представителей российского рынка Call-центров
1.3.1 ПРОТЕЙ-РВ
1.3.2 Naumen Phone
1.3.3 Call-центр фирмы «Светец»
1.3.4 Oktell
1.3.5 Рубин
1.4 Постановка задачи
Глава 2. Управление микроcall-центрами
2.1 Серверы на основе миниАТС
2.1.1 Управление коммутацией
2.1.2 Сбор статистики
2.2 Серверы на основе IP-PBX
2.2.1 Управление коммутацией
2.2.2 Сбор статистики
Заключение
Список использованных источников

Введение

Первый центр по обслуживанию телефонных вызовов появился лишь в начале 70-х годов прошлого века,  то есть всего чуть больше 30 лет назад. Каким же образом происходила обработка звонков между этими двумя событиями? Разве многочисленные коммутаторные службы нельзя считать Call-центром?  Чтобы быть таковыми им не хватало самого главного — автоматически осуществляемого равномерного распределения вызовов между операторами (Automatic Call Distribution, ACD). Именно ACD является основой, краеугольным камнем любого операторского центра, поэтому можно дать такое определение: Call-центр представляет собой структуру для обслуживания входящих и исходящих вызовов на основе их равномерного распределения между операторами.

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

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

Около 30 лет назад американская компания Rockwell внедрила в одной из авиакомпаний первую систему на базе ACD. Это событие и положило начало  возникновению операторских центров. Что же обусловило их появление? Ответ один: конкуренция, выжить в условиях которой можно было только за счет неуклонного повышения качества обслуживания и производительности труда [1].

Развертывание классического Call-центра — весьма дорогостоящее удовольствие.

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

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

Задачей производственной практики в ООО ИК «Рога и копыта» был анализ и выработка предложений по  проектированию системы сбора статистики о звонках в службу по работе с клиентами.

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

Глава 1. Обзор существующих решений call-центров для малых и средних предприятий

1.1 История становления российского рынка Call-центров

В России первыми на рынок Call-центров обратили внимание телекоммуникационные компании — в частности, “Вымпелком” и МТС, открывшие свои центры телефонного обслуживания абонентов в середине 1990-х. Эти Call-центры были мало похожи на современные — скорее, они представляли собой “телефонную справку”. В конце 1990-х сектор связи пошел в гору. По данным агентства Gartner, в 1998 — 2002 годы абонентская база ведущих сотовых операторов росла со скоростью более 100% в год. Для того чтобы обработать все обращения абонентов, компаниям пришлось быстро осваивать современные технологии общения с клиентами. Впрочем, быстрый рост абонентской базы был не единственной причиной, объясняющей, почему именно операторы связи первыми открыли для себя возможности Call-центров. Вторым не менее важным фактором была конкуренция — страна с интересом наблюдала борьбу операторов “большой тройки” — МТС, “Вымпелкома” и “МегаФона” за каждого абонента, при этом каждый из операторов отдавал себе отчет в том, что без Call-центров его позиции на рынке были бы куда слабее.

Наконец, в-третьих, технологические компании <генетически> предрасположены к использованию продвинутых информационно-маркетинговых инструментов.

В начале нового тысячелетия спрос на операторские центры возник и в финансовом секторе. Связано это с тем, что крупные банки начали выходить на рынок розницы, где без современного Call-центра не обойтись. Сбербанк РФ, Альфа-банк, МДМ, Внешторгбанк, а также российские филиалы иностранных банков эмитировали по состоянию на сегодня около 30 млн. пластиковых карт. В связи с возросшими объемами розничных услуг в банковской сфере появилась необходимость предоставления полноценной информации о деятельности банков (условиях открытия и закрытия счетов, условиями обслуживания, состоянию счетов и многим другим). Стало очевидно, что отсутствие Call-центра отрицательно влияет на эффективность бизнеса.

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

1.2 Состояние и перспективы рынка Call-центров

Хотя, как уже говорилось выше, родиной операторских центров является Америка (в которой уже насчитывается, по разным оценкам, от 100 000 до 250 000 ЦОВ, а общее число операторов превышает 3 миллиона), все же интереснее взглянуть на европейский рынок, который ближе к российскому и по размеру, и по менталитету, на рынок региона ЕМЕА, который образуют страны Европы, Ближнего Востока и Африки, а также проанализировать рынок операторских центров в России (входящей в Восточную Европу).

В конце 2008 года в ЕМЕА насчитывалось 36 000 Центров обслуживания вызовов. Ожидается, что в 2010 году их количество достигнет 45 000, со среднегодовым приростом 8,9% (CAGR2). Число рабочих мест операторов (или, иными словами, операторских позиций) в конце 2008 года составляло 1,8 миллиона, а в 2010 году должно возрасти до 2,1 миллиона, со среднегодовым приростом 6,3% (CAGR).

Возможно, сами по себе эти цифры мало о чем говорят. Например, 2 миллиона рабочих мест операторов — это много или мало? Одним из самых значимых свидетельств того, насколько прочно вошли операторские центры в повседневную жизнь, являются данные о занятости рабочего населения в этой сфере деятельности. В странах Европейского союза, обладающих наиболее развитым рынком Call-центров в ЕМЕА, 1,4% всего рабочего населения работает в Центрах обслуживания вызовов. А в 2010 году этот показатель возрастет до 1,6%.

Средний операторский центр в регионе ЕМЕА, по данным Datamonitor, к концу 2008 года насчитывал 50 рабочих мест оператора. При этом ожидается, что к 2010 году это число уменьшится до 48. Вообще, для ЕМЕА характерно преобладание небольших Call-центров, размер которых составляет 10-30 операторских позиций. К 2010 году самый большой прирост операторских центров даст именно этот сегмент (а следующий — 31 – 100 операторских позиций).

Рассмотрим российскую специфику. В настоящее время в России действует около 3200 Call-центров, в которых трудятся до 165 000 операторов. Это весьма низкий показатель. В США работает порядка 300 000 Call-центров, в них занято более 3 млн. операторов. В ЕС — около 45 000 таких центров с числом операторов более 1,8 млн. Российский рынок Call-центров развивается достаточно бурно: по оценкам Datamonitor, среднегодовой прирост составляет 16%, что почти в два раза превышает показатели региона ЕМЕА. Труднее оценить объем рынка. Datamonitor считает, что в 2010 году в России будет примерно 4000 Call-центров с числом рабочих мест порядка 180 000. Средний размер такого центра у нас составляет около 50 операторских мест. Как и в ЕМЕА, наиболее интенсивный рост заметен в сегменте небольших Call-центров с числом мест 20 — 30. При этом налицо явное повышение интереса к полнофункциональным, профессиональным Call-центрам.

1.3 Обзор основных представителей российского рынка Call-центров

Признанными мировыми лидерами в области производства Call-центров являются Avaya, Nortel, Cisco Systems, Alcatel, Cayo Communications, Genesys и др. Практически все они представлены и в России. У некоторых из них есть предложение на оборудование и ПО для небольших Call-центров, но, как правило, это усеченные по функциональности версии. Несомненным преимуществом этих компаний является большой опыт.

Call-центры Avaya установлены, например, в «Вымпелкоме», «МегаФоне» и Сбербанке РФ, решения Cisco используются в ФК «УралСиб», оборудование Nortel установлено в «Росгосстрахе» и Golden Telecom, а Alcatel помогает в организации Call-центра МТС. С точки зрения операционных систем, интерфейсов и серверных платформ все промышленные решения Call-центров базируются на системах Microsoft, Unix, Solaris, Linux, IBM, HP, SUN.

Из российских компаний это НТЦ «Протей», «Светец», «Вулкан», «Беркут», «Инкап», CBOSS, Forte IT и др. У каждой есть своя специфика, свои преимущества и недостатки.

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

Основное преимущество российских компаний заключается в стоимости их решений, которые в 1,5-2 раза дешевле зарубежных аналогов [3]. Более того, близость российских разработчиков к конечному клиенту позволяет существенно быстрее и качественнее производить интеграционные работы и запускать Call-центр в коммерческую эксплуатацию.

1.3.1 ПРОТЕЙ-РВ

Call-центр ПРОТЕЙ-РВ является собственной разработкой НТЦ «Протей».

ПРОТЕЙ-РВ предназначен для оснащения справочных, заказных и экстренных служб различного вида и назначения. Call-центр ПРОТЕЙ-РВ на базе интеллектуальной платформы ПРОТЕЙ представляет собой многофункциональный центр обслуживания вызовов, реализованный с использованием современных технологий, включая IP и WEB.

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

Применение технологий IP-телефонии при организации рабочих мест операторов позволяет использовать в Call-центре ПРОТЕЙ-РВ только компьютерную сеть, а также предоставляют широкий спектр возможностей по интеграции средств доступа к информации баз данных СРВ в клиентские программы АРМ оператора, повышению удобства работы операторов. Кроме того, обеспечивается возможность обработки запросов, поступающих из сети Internet по электронной почте и с использованием технологии VoIP.

Технологии пакетной коммутации, используемые в Call-центре ПРОТЕЙ-РВ, позволяют в принципе отказаться от сложного коммутационного ядра, обеспечивающего функции коммутации (каналов), возложив функции коммутации на собственно сеть, за счет использования возможностей протокола IP как универсального транспортного уровня.

Все функциональные возможности ПРОТЕЙ-РВ реализуются компьютерными серверами приложений, работающими с управляющей информацией, медиа-потоками (если необходимо) и взаимодействующими в процессе обслуживания вызова с информационными и технологическими базами данных. Этих серверов может быть несколько, каждый из них может отвечать за свой набор услуг (сервер ACD, сервер IVR и т.п.). Таким образом, решаются вопросы надежности, масштабирования, внедрения новых функций, резко упрощается технология создания распределенных систем.

Рассмотрим архитектуру.

Call-центр ПРОТЕЙ-РВ представляет собой аппаратно-программный комплекс, состоящий из следующих компонент:

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

— Подсистема хранения данных (DBS) хранит информацию о конфигурации системы, статистические данные о функционировании системы и т.д. ПО подсистемы DBS функционирует в среде ОС Linux.

— Подсистема медиа-ресурсов (MRS) предназначена для хранения записей переговоров операторов в цифровом виде и организации возможности прослушивания с компьютера администратора системы.

— Автоинформационный сервер (IVR) служит для выдачи абоненту автоинформационных сообщений. Система IVR может быть интегрирована с сервером ACD или представлять собой отдельный модуль.

Основные функциональные возможности

— организация очередей;

— маршрутизация вызовов;

— 3 алгоритма распределения вызовов по операторам (циклическое распределение вызовов, выбор наиболее свободного оператора, выбор наименее занятого оператора);

— 2 режима обслуживания вызовов (предответный, ответный);

— переадресация вызовов;

— сбор статистической информации и учет вызовов;

— администрирование;

— наблюдение за вызовом (подключение к переговорам, запись) [4].

1.3.2 Naumen Phone

Call-центр Naumen Phone является полнофункциональным центром обработки вызовов, построенным на базе технологии VoIP. Naumen Phone позволяет автоматизировать обработку телефонных обращений в компанию и предоставить пользователям принципиально новые возможности для приема и совершения вызовов.

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

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

Серверное программное обеспечение работает на базе свободно распространяемой ОС Linux RedHat 9.0 (Fedora Core 3.0/5.0), для хранения статистики используется свободно распространяемая СУБД Interbase Firebird.

Рабочие места операторов могут быть расположены за пределами офиса, все вызовы от Call-центра распределяются к операторам по IP-сети. Таким образом, достигается пространственная независимость операторов, супервизора и администратора.

Веб-интерфейс для настроек и консольный доступ к серверу по SSH-протоколу позволяют администратору удаленно управлять системой даже через слабый Интернет-канал (модем, GPRS).

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

Рассмотрим архитектуру [5].

В состав решения входят:

— IP-PBX,

— программный телефон,

— IVR (программируемый голосовой автоответчик),

— голосовая почта,

— утилиты управления,

— факс-сервер и др.

Рассмотрим схемы подключения [5].

1. Применение в пределах одного офиса. Для реализации этой схемы в локальную сеть офиса подключается сервер NauPhone и ПК операторов и абонентов. Номерная емкость (связь с ТФОП) может подаваться в нескольких вариантах:

— E1 PRI поток и VoIP-шлюз.

— От оператора связи, который, обычно является и провайдером Интернета получить многоканальный номер по IP в потоке H.323.

— От оператора связи по E1 PRI или IP H.323 и делать через оператора связи неограниченное количество исходящих вызовов.

2. Интеграция с существующей АТС. Существующие телефонные станции интегрируются с NauPhone. Пользователи ATC получают голосовую почту, все правила внешних вызовов прописываются на сервере NauPhone, статистика ведется по всем вызовам. Можно разрешать/запрещать различным группам/абонентам вызовы на междугородние и мобильные телефоны.

Основные функциональные возможности

— Интеллектуальная маршрутизация вызовов возможна на основе информации, полученной от клиента или информационной системы.

— Распределение вызовов на основе данных об уровне обслуживания реализовано с помощью специальных групп операторов. Алгоритм распределения вызова использует данные о необходимом уровне обслуживания конкретного вызова, наличии и занятости операторов, прогнозе времени ожидания обслуживания в очередях.

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

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

— Универсальность рабочих мест операторов. Решение обеспечивает централизованную авторизацию и аутентификацию пользователей, что позволяет легко менять местоположение рабочих мест операторов.

— Наблюдение за вызовом (подключение к переговорам).

— Система отчетности. В комплект поставки входит 20 базовых отчетов, разработанных для реализации наиболее частых требований (отчеты реального времени, хронологические отчеты и т.п.).

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

— Организация интеллектуального голосового меню (IVR) автоматически предоставляет информацию клиентам и позволяет обслужить часть вызовов в автоматическом режиме. В случае интеграции модуля IVR с информационной системой возможно контекстно-зависимое информирование основании данных, введенных клиентом и/или полученных от АОН.

— Запись разговоров. Решение обеспечивает тотальную централизованную запись телефонных разговоров, их накопление, промежуточное хранение и архивацию на жестком диске в формате WAV GSM. Супервизоры и администратор системы имеют возможность удаленно прослушивать сохраненные записи, делая выборки по направлению вызова, оператору, номеру абонента ТфОП.

— Интеллектуальная голосовая почта позволяет оставить персональное голосовое сообщение с возможностью отправки на e-mail адрес пользователя. Также возможно удаленное прослушиванием сообщений путем набора номера и авторизации по ПИН-коду.

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

1.3.3 Call-центр фирмы «Светец»

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

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

Рассмотрим архитектуру [7].

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

Особенности.

Взаимодействие с клиентом осуществляется по различным каналам — ТфОП, веб-интерфейс, SMS, e-mail, что позволяет существенно расширить круг клиентов.

Комплекс может масштабироваться до нескольких тысяч каналов и сотен операторских мест в локальном варианте и неограниченно — в территориально-распределенном.

Основные функциональные возможности.

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

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

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

— Рабочее место оператора (РМО) предоставляет оператору необходимый инструментарий для качественного и оперативного обслуживания вызова (контексные справочные подсказки, всплывающие транспаранты, средства коммуникации, информация об очередях абонентов).

— Услуги «Обратный вызов», «Универсальный номер доступа». Услуги записи и регистрации речевых сообщений абонентов.

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

— Возможность взаимодействия с внешними системами и базами данных.

— Прием и немедленная или отложенная обработка запросов клиентов, поступивших через веб-интерфейс, SMS, e-mail (например, заказ услуги «Обратный вызов» с последующим соединением с оператором).

— Организация исходящих звонков по заданным номерам, факс, SMS и e-mail рассылок.

— Тарификация коммерческих услуг.

— Абонентские интерфейсы для редактирования профиля услуг и полное удаленное администрирование системы для обслуживающего персонала.

— Формирование отчетов по необходимым параметрам и сбор статистической информации.

1.3.4 Oktell

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

Рассмотрим архитектуру [9].

Oktell — система компьютерной телефонии, реализованная на базе телекоммуникационного сервера с установленной аппаратной платформой и интеллектуальной программной оболочкой.

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

Основные функциональные возможности

— прием и распределение вызовов;

— интерактивное голосовое меню;

— интеллектуальная маршрутизация;

— сценарии диалога оператора;

— управление ресурсами; контрольные события;

— мониторинг параметров производительности;

— входящие и исходящие задачи, интеграция с пользовательскими базами данных;

— интеграция с CRM и сторонними программными приложениями;

— запись разговоров;

— перевод звонка на внешний номер;

— переключение вызова на автоматическую обработку;

— фильтр исходящих вызовов;

— организации очереди ожидания;

— контроль оператора в режиме реального времени;

— межофисная связь по IP каналу;

— распределенный номерной план;

— индивидуальное управление переадресацией;

— статистика по задачам, операторам и операторским группам;

— общая статистика по Call-центру;

— история взаимодействия с абонентами и другие функции.

Oktell работает на аналоговых телефонных линиях (FXO/FXS), цифровых потоках Е1 (ISDN PRI), а также поддерживает технологию передачи голоса по сетям передачи данных (VoIP), что позволяет создавать удаленные рабочие места, объединять офисы и филиалы в единый номерной план [10].

1.3.5 Рубин

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

Ниже рассмотрены варианты подключений оборудования Рубин. Операторские места во всех вариантах могут быть подключены как на основе IP-технологий, так и с помощью классической телефонии. Целесообразность того или иного способа определяется сетевой инфраструктурой и задачами, для решения которых используется Call-центр Рубин. В частности, использование VoIP позволяет организовывать вынесенные рабочие места операторов или строить распределенный Call-центр.

  1. Подключение без АТС. Этот вариант интересен в том случае, когда не установлена офисная АТС. Оборудование Рубин выполняет функции небольшой АТС.
  2. Подключение перед АТС. В этом варианте дополнительные возможности, предоставляемые Call-центром Рубин, распространяются на всю компанию. Таким образом, развитое интерактивное голосовое меню может встречать абонентов, позвонивших на любой телефонный номер компании, а не только в Call-центр. Кроме этого контроль переговоров с внешними абонентами, а также запрет исходящей связи на определенные номера или зоны, поддержка черных списков, callback — эти возможности также доступны всей компании в целом.
  3. Подключение после АТС. Если уже существует налаженная инфраструктура и АТС достаточно велика, то наиболее мягким и щадящим для обеспечения непрерывности бизнес-процессов способом будет построение Call-центра после АТС. В этом случае все дополнительные функциональные возможности будут распространяться только на те вызовы, которые прошли непосредственно через оборудование Рубин (напрямуюили в переадресованном виде).

Работа Call-центра Рубин может быть организована в виде самых разнообразных алгоритмов. В общем виде она выглядит следующим образом.

Абонента, позвонившего в Call-центр, встречает голосовое меню (IVR), по которому он может передвигаться, выбирая интересующие его рубрики. Кроме этого, клиентом могут быть получены разнообразные справки на основании информации, извлеченной из БД Call-центра.

В случаях отсутствия необходимости в голосовом меню (IVR) абонент сразу переключается на оператора.

Алгоритмов работы существует неограниченное количество. Они формируются Администратором Call-центра при помощи редактора сценариев.

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

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

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

1.4 Постановка задачи

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

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

Задачей проекта является создание системы статистической обработки результатов работы микроCall-центра, который изначально был направлен на небольшие и средние предприятия, при этом микроCall-центр содержит только востребованные функции, такие как IVR, CRM.

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

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

— интеграция с существующей телефонной инфраструктурой. Этот способ целесообразно использовать, когда уже есть функциональная телефонная станция, и нет необходимости в ее замене. Достаточно организовать отдельный сервер микроCall-центра и подключить его к миниАТС;

— микроCall-центр на базе существующей миниАТС и VoIP-технологии. Отличие этого варианта интеграции от предыдущего заключается в способе организации транспортной среды внутри микроCall-центра. В этом случае вызов принимает миниАТС, далее на специальном шлюзе происходит его конвертация из аналогового сигнала в цифровой, и на рабочее место оператора звонок доставляется уже посредством VoIP-технологии. Основное преимущество данного способа — повышение гибкости микроCall-центра с точки зрения обслуживания, местоположения и размера;

— микроCall-центр на основе IP-АТС. Основное отличие от предыдущего состоит в том, что конвертация вызова может происходить внутри телефонной станции, а не на шлюзе. А также в том, что в силу особенностей, присущих IP-АТС, ведение статистики о звонках можно поднять на более высокий уровень.

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

В дальнейшем будут использованы две схемы интеграции, основанные на использовании миниАТС и IP-АТС. Оставшиеся две схемы не подлежат рассмотрению в связи с тем, что вариант микроCall-центра на базе существующей миниАТС и VoIP-технологии является разновидностью микроCall-центра, построенного только на базе миниАТС, и его применение не приведет к конструктивным изменениям в разработанном программном обеспечении. А вариант использования виртуального Call-центра связан с арендой ресурсов провайдера и выходит за рамки темы практики.

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

Глава 2. Управление микроcall-центрами

Существует несколько способов организации Call-центров, обобщенно, существует два типа конфигураций:

— Call-центр, в котором вся функциональность реализуется внутри коммутационного оборудования. В качестве коммутационного оборудования в этом случае может выступать миниАТС с поддержкой функции Call-центра;

— Call-центр, в котором функциональность реализуется вне телефонной станции, на отдельном сервере.

При выборе конфигурации следует руководствоваться следующими принципами. Если организация, в которой происходит внедрение Call-центра, еще не имеет современной телефонной станции (или, иными словами, УПАТС — учрежденческо-производственной АТС, в английской версии — PBX, Private Brunch Exchange), то целесообразно было бы остановиться на решении, в котором функциональность Call-центра реализуется внутри телефонной станции. Во-первых, это надежно, ведь таким образом уменьшаются возможные точки возникновения отказа (а это сам сервер и соединительная линия между ним и PBX). Во-вторых, такое решение проще в управлении и администрировании.

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

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

Исходя из этих соображений, было принято решение о создании сервера микроCall-центра, функциональность которого реализуется за пределами АТС.

Для взаимодействия микроCall-центра с внешним миром и внутренними абонентами применяются сети двух типов — с коммутацией каналов и с коммутацией пакетов. Преимущество первых — их широкая распространенность в телефонном мире. Наиболее ярким примером таких сетей, работающих по TDM-технологии — сети с интеграцией услуг ТфОП (телефонная сеть общего пользования).

Сети с коммутацией пакетов были разработаны с целью объединения удаленных компьютеров и сегодня являются основой глобальной сети Интернет. Наиболее близкой к пользователю и доминирующей транспортной технологией на рынке пакетной передачи голоса является TCP/IP с протоколами верхнего уровня SIP, H.323, RTP [12].

2.1 Серверы на основе миниАТС

2.1.1 Управление коммутацией

Схема микроCall-центра, построенного по принципу коммутации голосовых каналов, приведена на рисунке 2.1. МикроCall-центр принимает телефонные звонки от абонентов из сети ТфОП. Внутри микроCall-центра вызовы распределяются на терминалы операторов, систему голосового меню (IVR). Весь голосовой трафик (на рис. 2.1 обозначен прерывистой линией) от коммутатора (миниАТС) к внутренним ресурсам микроCall-центра передается по технологии коммутации каналов. Для управления маршрутизацией вызовов между ресурсами, а также передачи данных используется сеть с коммутацией пакетов (на рис. 2.2 обозначена сплошной линией).

Созданная архитектура микроCall-центра не накладывает явных технологических ограничений на расширение узла и организацию распределенного микроCall-центра. Однако построение многозонового микроCall-центра, коммутаторы которого взаимодействует по технологии TDM, приводит к необходимости организации связи каждого узла с каждым.

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

Тип коммутации в ядре миниАТС оказывает существенное влияние на уровень универсальности архитектуры микроCall-центра. Принципиально важно, что именно коммутирует внутри себя операционная система процессора станции — пакеты или каналы. Большинство традиционных миниАТС коммутирует каналы, тем самым они идеально подходят для построения микроCall-центра по классической TDM-технологии.

Взаимодействие миниАТС и сервера микроCall-центра может осуществляться двумя способами:

— по управляющему каналу, который предусмотрен в большинстве миниАТС (т.е. управление через так называемый CTI link). Существует международный стандарт для передачи управляющих команд по CTI link, который носит название CSTA (Computer Supported Telephony Application), предложенный организацией European Computer Manufacturers Association (ECMA). Тем не менее, многие производители миниАТС используют свои протоколы. В связи с этим необходимо предусмотреть различное программное обеспечения для плат компьютерной телефонии. А это  многократное может повысить стоимость решения. Из-за направленности проекта на малые и средние предприятия такое решение неприемлемо;

— управление миниАТС, используя тональные сигналы. В этом случае при поступлении звонка происходит его автоматическая переадресация на внутреннюю линию (например, на IVR). Далее по этой линии могут подаваться команды для миниАТС с помощью тональных сигналов.

Взаимодействие микроCall-центра с компьютером оператора осуществляется по SOAP-протоколу (см. приложение А).

Сервер микроCall-центра производит постоянный опрос миниАТС на предмет поступления нового звонка. При появлении такового сервер микроCall-центра запускает метод newCall() класса CManageSystem, который делает запись в БД микроCall-центра о поступлении нового звонка. Такой SQL-запрос к БД выглядит следующим образом:

INSERT INTO calls (Dial_port, Number, Status) VALUES (‘» .

$dial_port . «‘, ‘» . $number . «‘, ‘wait’);

В качестве параметров передается номер порта, на который пришел звонок, телефонный номер позвонившего, статус позвонившего абонента (устанавливается значение «wait», т.е. абонент ожидает соединения с оператором).

В это время абоненту может проигрываться заранее записанное приветствие.

Посредством метода getWaitCalls() класса CManageSystem (формируется XML-документ, содержащий телефонные номера абонентов, находящихся в ожидании. Этот SQL-запрос к БД имеет вид:

SELECT * FROM calls WHERE (Status=’wait’) or (Status=’post’

and Oper_port='» . $oper . «‘) or (Status=’talk’ and

Oper_port='» . $oper . «‘) ORDER BY Status DESC;

Сформированный XML-документ является ответом по SOAP-протоколу на запрос клиентского приложения, установленного на рабочем месте оператора микроCall-центра. Этот XML-документ имеет следующую структуру:

<?xml version=»1.0″ encoding=»UTF-8″ ?>

<Calls>

<new_call>

<Id_call>3008</Id_call>

<Number>555587</Number>

<Dial_port>23</Dial_port>

<Oper_port />

<Status>wait</Status>

<IDCust>405</IDCust>

<CustF>Иванов</CustF>

<CustI>Иван</CustI>

<CustO>Иванович</CustO>

<Company />

<Prior>VIP</Prior>

</new_call>

<new_call>

<Id_call>3009</Id_call>

<Number>555590</Number>

<Dial_port>24</Dial_port>

<Oper_port>16</Oper_port>

<Status>talk</Status>

<IDCust>312</IDCust>

<CustF>Петров</CustF>

<CustI>Петр</CustI>

<CustO>Петрович</CustO>

<Company />

<Prior>VIP</Prior>

</new_call>

</Calls>

В блоке Calls содержатся данные о вызовах. Новые вызовы представлены в блоках new_call, содержащих информацию о звонящем абоненте, полученную из БД.

Интерпретировать информацию, содержащуюся в тексте этого XML-документа можно следующим образом. На связи находятся два абонента. Абонент Иванов Иван Иванович (идентификатор в БД 405) позвонил с номера 555587, этому вызову присвоен уникальный идентификатор 3008, и он принят на порт 23. Абонент ожидает ответа оператора (статус вызова – «wait»). Второй абонент, Петров Петр Петрович (идентификатор в БД 312), позвонил с номера 555590, этому вызову присвоен уникальный идентификатор 3009, и он принят на порт 24. Абонент общается с оператором (статус вызова – «talk»), внутренний номер которого 16.

Если, получив эту информацию, оператор готов принять звонок, то сервер микроCall-центра методом startTalk() класса CManageSystem отдает команду миниАТС на переключение звонка на телефон оператора. В БД микроCall-центра меняется статус звонка с «wait» на «close». Это обращение к БД выглядит следующим образом:

UPDATE calls SET Status =’close’ WHERE Id_call= » . $id . «;

В качестве параметра используется идентификатор звонка.

Описанная архитектура микроCall-центра, основанная на TDM-технологии — оптимальное решение для малых и средних предприятий. Основные ее достоинства — это использование стабильной, проверенной временем технологии и хорошая масштабируемость как по коммутации телефонных соединений, так и по обслуживанию вызовов микроCall-центра.

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

2.1.2 Сбор статистики

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

В связи с этим о звонках можно узнать только следующие данные:

— номер звонящего (в случае поддержки миниАТС функции автоматического определения телефонного номера);

— дата и время поступления звонка;

— время нахождения звонка в очереди (до момента переключения звонка на телефон оператора);

— оператор, принявший этот звонок.

Сбор статистики о звонках ведется постоянно в процессе функционирования микроCall-центра:

— при поступлении нового звонка делается запись в БД о телефонном номере, дате и времени его поступления. Для этого создан метод addNewCall() класса CSQL. SQL-запрос к БД имеет вид:

INSERT INTO statis (id, DateTime1, DateTime2) VALUES (‘» .

$id_call . «‘, ‘» . $datetime . «‘, »);

— при направлении вызова на телефон оператора делается запись в БД о времени его переключения. SQL-запрос к БД имеет вид:

UPDATE statis SET DateTime2='» . $DateTime2 . «‘ WHERE id

='» . $id_call . «‘;

Особо стоит отметить, что важную роль при ведении статистики играет скорость записи в БД. Замедление процессов транзакции приводит к неоправданному увеличению времени обработки вызова. Существует два решения этой задачи:

— распараллеливание процессов обработки вызова и сбора статистики. Но это приведет к необходимости организации очереди записи в БД, что будет  связано с увеличением стоимости решения [13];

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

Второе решение нашло отражение в производственной практике.

2.2 Серверы на основе IP-PBX

2.2.1 Управление коммутацией

МикроCall-центр, построенный полностью на принципах коммутации пакетов, с технологической точки зрения является ярким антиподом решения на основе TDM-архитектуры.

Единственное устройство на схеме, поддерживающее TDM-коммутацию — это шлюз, который осуществляет преобразование поступающих из ТфОП вызовов в цифровой сигнал (этот шлюз также может быть встроен в IP-PBX, в этом случае она автоматически осуществляет упомянутое преобразование). После шлюза коммутация и обслуживание всех вызовов происходят исключительно в пакетном режиме. МикроCall-центр, построенный по технологии VoIP, как и TDM-решение, состоит из двух основных компонентов — коммутационного ядра (IP-PBX), реализующего сервисы пакетной телефонии, и приложений микроCall-центра, которые позволяют оптимальным образом распределять вызовы между операторами.

Сервер микроCall-центра осуществляет опрос IP-PBX на предмет поступления новых звонков посредством HTTP протокола методом GET. Этот запрос осуществляется методом getDialogicList() класса CCT. Вид такого запроса в рамках текста скрипта в PHP5 выглядит следующим образом:

$out = «GET http://» . $this->_host . «:» . $this->_port .

«/?COMMAND=SYS_LINE_INFO&PASSWORD=» . $this->_psw .

» HTTP/1.0\r\n»;

$out .= «Host:» . $this->_host . «\r\n»;

$out .= «Connection: Close\r\n

Указанные переменные имеют следующие значения:

— $this->_host — хост сервера IP-PBX;

— $this->_port — порт сервера IP-PBX;

— $this->_psw — пароль сервера IP-PBX.

В качестве ответа на запрос возвращается лист состояния каналов IP-PBX. Если на один из каналов пришел новый вызов, то сервер микроCall-центра, используя метод getScenario() класса CScenario, которому в качестве входного параметра передается номер телефона, получает сценарий обслуживания поступившего звонка, где могут быть указаны:

— дальнейшие действия для IP-PBX (например, запуск определенного приветствия);

— инструкции по маршрутизации вызова и т.п.

Далее сервер микроCall-центра запускает метод newCall() класса CManageSystem, который делает запись в БД микроCall-центра о поступлении нового звонка. Статусу звонка присваивается значение «wait».

Клиентское приложение, установленное на рабочем месте оператора, осуществляет запрос посредством SOAP-протокола к серверу микроCall-центра на предмет поступления новых звонков. В качестве ответа на запрос сервер, используя метод getWaitCalls() класса CManageSystem, формирует XML-документ, содержащий телефонные номера абонентов, находящихся в ожидании.

В случае если клиентское приложение делает SOAP-запрос на переключение звонка, т.е. оператор готов принять вызов, то сервер, используя метод startTalk() класса CManageSystem, посредством HTTP-протокола (метод GET) отдает команду IP-PBX на переключение звонка на VoIP-телефон оператора. Вид такого запроса в рамках текста скрипта в PHP5 выглядит следующим образом:

$out = «GET http://» . $this->_host . «:» . $this->_port .

«/?COMMAND=GOTO&PASSWORD=» . $this->_psw . «&URL=» .

$this->_url . «dial.php?COM=» . $command . «&VALUE=»

. $line . » HTTP/1.0\r\n»;

$out .= «Host:» . $this->_host . «\r\n»;

$out .= «Connection: Close\r\n\r\n»;

Указанные переменные имеют следующие значения:

— $command — номер для переадресации;

— $line — номер линии;

— $url — URL микроCall-центра.

Сервер микроCall-центра, используя метод startTalk() класса CManageSystem, меняет статус звонка в БД с «wait» на «talk» (начало разговора). Это обращение к БД выглядит следующим образом:

UPDATE calls SET Status =’talk’, Oper_port='» . $oper_port .

«‘ WHERE Id_call= » . $id . «;

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

При получении SOAP-запроса от клиентского приложения на завершение звонка и перевод его в стадию постобработки сервер выполняет метод StartPost() класса CManageSystem. Происходит освобождение линии методом resetLine() класса CCT, и статус звонка в БД меняется с «talk» на «post» (метод startPost() класса CSQL).

По завершении обработки звонка сервером выполняется метод closeCall() класса CManageSystem, который меняет статус звонка в БД с «post» на «close».

Последующие вызовы обрабатываются аналогично.

Обработка каждого пакетного вызова отнимает ресурсы процессора коммутационной платформы. Для проигрывания голосового приветствия или сообщения абонентам, находящимся в очереди, необходимо выделить соответствующее число VoIP-кодеков и каналов. Поскольку в IP-PBX пока еще не освоены технологии широковещательной рассылки данных, обеспечивающие централизованную передачу информации множеству абонентов одновременно, увеличение числа пользователей микроCall-центра ведет к необходимости повышения мощности ЦПУ коммутационной платформы, что вводит определенные ограничения на построение центров большой емкости.

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

2.2.2 Сбор статистики

В отличие от архитектуры микроCall-центра, использующей миниАТС, при использовании IP-PBX, сервер микроCall-центра является связующим звеном между клиентским приложением и IP-PBX. В связи с этим все поступающие звонки находятся под постоянным контролем сервера, т.е. ведение статистики о звонках ничем не ограничено.

При работе сервера происходит сбор следующей информации о звонках:

— телефонный номер абонента;

— дата и время поступления вызова;

— дата и время переадресации звонка на телефон оператора (время ожидания);

— идентификатор оператора, принявшего вызов;

— дата и время завершения разговора абонента и оператора (длительность разговора);

— продолжительность поствызывной обработки звонка оператором.

Сбор статистики о звонках ведется постоянно в процессе функционирования микроCall-центра:

— при поступлении нового звонка делается запись в БД о телефонном номере, дате и времени его поступления. Для этого создан метод addNewCall() класса CSQL. SQL-запрос к БД имеет вид:

INSERT INTO statis (id, DateTime1, DateTime2, DateTime3,

DateTime4) VALUES (‘» . $id_call . «‘, ‘» . $datetime1 . «‘, »,

», »);

— при переадресации звонка на телефон оператора выполняется метод startTalk() класса CManageSystem, в котором посредством метода startTalk() класса CSQL осуществляется запись в БД даты и времени переадресации. SQL-запрос имеет вид:

UPDATE statis SET DateTime2='» . $datetime2 . «‘ WHERE id =

» . $id_call . «;

— по завершении разговора оператора с абонентом выполняется метод  startPost() класса CManageSystem, в котором посредством метода startPost() класса CSQL осуществляется запись в БД даты и времени начала постобработки. SQL-запрос имеет вид:

UPDATE statis SET DateTime3='» . $datetime3 . «‘ WHERE id =

» . $id_call . «;

— по окончании поствызывной обработки звонка оператором выполняется метод closeCall() класса CManageSystem, в котором посредством метода closeCall() класса CSQL осуществляется запись в БД даты и времени окончания поствызывной обработки звонка (его закрытия). SQL-запрос имеет вид:

UPDATE statis SET DateTime3='» . $datetime3 . «‘ WHERE id =

» . $id_call . «;

Таким образом, с помощью описанных методов достигается сбор информации о звонках в полном объеме.

Заключение

В процессе исследований в рамках практики в компании «Рога и копыта» были рассмотрены различные схемы интеграции и архитектура Call-центров, разработанных основными производителями российского рынка Call-центров. На основании результатов исследований был сделан вывод о востребованности микроCall-центров.

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

Список использованных источников

1. Самолюбова А.Б. Call Center на 100%. Практическое руководство по организации Центра обслуживания вызовов — М.: Альпина Букс. 2004. — 309 с.
2. Call-центры отечественных производителей (часть I). А. Н. Новичков. Сети и системы связи, № 7, 2006.
3. Call-центры отечественных производителей (часть II). А. Н. Новичков. Сети и системы связи, № 8, 2006.
4. НТЦ Протей. Call-центр [Электронный ресурс]. — http://www.protei.ru/products.php?sid=2&id=2.
5. Naumen. Архитектура Call-центра [Электронный ресурс]. -http://www.naumen.ru/go/products/nauphone/naucc/.
6. Игорь Темкин. Назначение Naumen Phone [Электронный ресурс]. — http://www.crmonline.ru/callcentres/solutions/naumen/.
7. Внедрение многофункционального центра обработки вызовов, интеграция с имеющейся инфраструктурой [Электронный ресурс]. -http://www.svetets.ru/projects/proj06.html.
8. Игорь Темкин. Многофункциональный Центр Обработки Вызовов (МЦОВ) [Электронный ресурс]. — http://www.crmonline.ru/callcentres/ solutions/svetets/.
9. Oktell. Схемы подключения [Электронный ресурс]. — http://telsystems.ru/index.php?page=205.
10. Игорь Темкин. Сall-центр Oktell [Электронный ресурс]. -http://www.crmonline.ru/callcentres/solutions/oktell/.
11. Call-центр РУБИН. Варианты подключений [Электронный ресурс]. — http://www.vulkan.ru/p112/.
12. Тарасов В.Ю. Пакетные технологии в контакт-центрах // Сети и системы связи. — 2005. — №9. — С. 60-64.
13. Галичский К.В. Компьютерные системы в телефонии. — СПб.: БХВ-Петербург, 2002. — 400с.:ил.
14. Котеров Д.В. Самоучитель PHP 4. — СПб.: БХВ-Петербург, 2003. — 576 с.: ил.
15. Лебедев Д. Объектно-ориентированное программирование, классы [Электронный ресурс] — http://phpclub.ru/detail/article/2000-12-10.
16. Шапиро В. Объектно-ориентированное и процедурное программирование в PHP [Электронный ресурс] — http://phpclub.ru/detail/article/oop-vs-proc.
17. Печерский А. Язык XML. Практическое введение [Электронный ресурс]. — http://www.citforum.ru/internet/xml/index.shtml.
18. PHP Security, Part 1 [Электронный ресурс].- http://www.onlamp.com/pub/a/php/2003/07/31/php_foundations.html.
19. PHP Security, Part 2 [Электронный ресурс]. -http://www.onlamp.com/pub/a/php/2003/08/28/php_foundations.html.
20. PHP Security, Part 3 [Электронный ресурс]. http://www.onlamp.com/pub/a/php/2003/10/09/php_foundations.html.
21. Кейт Доунсон. Применение новых технологий в различных направлениях деятельности Call-центров // Сети и системы связи. — 2004. — №6. — С. 60-63.
22. Джо Флейшер. Перспективы развития технологий для Call-центров // Сети и системы связи. — 2005. — №6. — С. 62-64.
23. Джон Джейншигг. Контакт-центры на базе IP // Сети и системы связи. — 2004. — №4. — С. 75-77.
24. Арулази Десиасилан. Что нового в WSDL 2.0 [Электронный ресурс]. http://www.iso.ru/journal/articles/338.html.
25. Михаил Корнеев. Практическое использование SOAP в PHP 5 [Электронный ресурс]. — http://www.zend.com/php5/articles/php5-SOAP.php.
26. Руководство по языку программирования PHP 5 [Электронный ресурс]. — http://www.php.net/manual/en/function.php.

Средняя оценка 0 / 5. Количество оценок: 0

Поставьте оценку первым.

Сожалеем, что вы поставили низкую оценку!

Позвольте нам стать лучше!

Расскажите, как нам стать лучше?

3070

Закажите такую же работу

Не отобразилась форма расчета стоимости? Переходи по ссылке

Не отобразилась форма расчета стоимости? Переходи по ссылке