Производители CTI по-прежнему игнорируют стандарты Microsoft и Novell, предпочитая более гибкие частные решения
Как ни стараются компании Novell и Microsoft создать стандартные интерфейсы для работы с различными офисными телефонными станциями, большинство производителей приложений компьютерно-телефонной интеграции (CTI) продолжают игнорировать их стандарты - TSAPI и TAPI соответственно.
“Несмотря на то что предлагаемые Novell и Microsoft API существуют уже около двух лет, многие производители средств компьютерной телефонии продолжают работать с интерфейсами PBX напрямую”, - сказал Арт Шуллер, директор компании Gartner Group по ресурсам для обработки голосовых вызовов (Стамфорд, шт. Коннектикут).
Одна из причин такого положения кроется в слишком общем характере стандартов TAPI (Telephony API) и TSAPI (Telephony Services API). Если производитель хочет получить развитые функции отслеживания звонков, жизненно важные для многих приложений CTI, ему приходится создавать собственные решения. Другой причиной является ограниченный список аппаратуры, поддерживаемой стандартными API.
Хорошо информированный оператор
Частные решения CTI наиболее распространены в отношении приложений центров обработки вызовов (call center), которые компании применяют для улучшения работы отделов телемаркетинга и обслуживания потребителей. Компьютерно-телефонные центры обработки вызовов автоматизируют сбор информации за счет совместного использования функции ANI (Automatic Number Identification - автоматическое определение номера), предоставляемой телефонной компанией, и сведений о потребителе из базы данных центра обработки вызовов.
При поступлении звонка PBX (Private Branch eXchange - учрежденческая АТС) с помощью ANI определяет, с какого номера он поступил. Затем центр вызовов связывает полученный номер с личными сведениями клиента и отображает их на экране сотрудника компании, тем самым избавляя его от работы по извлечению этих данных.
Поскольку центры обработки вызовов могут повысить производительность труда, эта область является одной из немногих, где средства CTI процветают. По данным компании Dataquest (Сан-Хосе, шт. Калифорния), в 1996 г. в США такие центры обеспечили производителям доход в 795 млн. долл., и к 2001 г. этот рынок должен достичь 1,5 млрд. долл.
Однако производители центров обработки вызовов почти полностью пренебрегли протоколами TAPI и TSAPI. Одна из причин этого в том, что оба интерфейса поддерживаются только серверами PC LAN. Для поддержки, скажем, сервера Unix центр должен использовать другой API.
Например, международный оператор обработки вызовов компания Prestige International USA (Нью-Йорк) предлагает такие услуги, как прием заказов по каталогам для крупных универсальных магазинов. Компания имеет 17 центров обработки заказов по всему миру, в ее нью-норкском центре работает около 50 агентов.
Шарон Барнетт, вице-президент Prestige по продажам и маркетингу, сообщила, что с целью увеличения эффективности работы агентов осенью 1996 г. в компании было принято решение о переходе к использованию средств CTI.
В качестве основных серверов Prestige использовала системы UltraSPARC производства Sun Microsystems и хотела оставить их для дальнейшей работы, поэтому Барнетт не изучала вариант с использованием TAPI или TSAPI, а просто выбрала систему Genesys производства компании Genesys Telecommunications Laboratories.
Об еще одном случае с проблемой аппаратной совместимости рассказал Грег Стюарт, менеджер проекта в Canadian Pacific по обслуживанию потребителей и службам Интернет. В начале 1996 г. компания решила организовать рабочее место по обслуживанию клиентов с целью ускорения приема заявок и лучшего удовлетворения потребителей.
По словам Стюарта, компания искала систему CTI типа “клиент-сервер”, способную работать с системой IVR (Interactive Voice Response - интерактивный голосовой ответ), автоматизирующей работу с различными запросами потребителей, и с ACD (Automatic Call Distributor - автоматический распределитель вызовов), отправляющей вызовы группам пользователей системы.
И TAPI, и TSAPI оказались неспособными к работе с системами IVR и ACD, они не поддерживают обычные функции, используемые в таких системах. Например, интерфейсы Microsoft и Novell не позволяют пользователям перенаправлять вызов и сведения о клиенте от одного сотрудника компании к другому. Кроме того, эти интерфейсы не имеют функций сбора сведений о звонке, таких, как время его поступления и маршрут передачи.
Как следствие, Canadian Pacific пыталась использовать ПО прочих производителей, работающее напрямую с интерфейсом PBX, чтобы обеспечить таким образом взаимодействие систем IVR и ACD. По мнению Стюарта, такое связывание систем затруднительно. “Поначалу устройства совсем отказались перенаправлять вызовы по нужному адресу”, - поделился он.
В итоге в августе 1996 г. компания решила проблему, установив ПО Genesys на Unix-сервер HP 9000 производства Hewlett-Packard. Сейчас руководство железнодорожной компании удовлетворено этим выбором, но хотело бы улучшить функции отчетов по вызовам. “Мы хотим достичь большей интеграции базы данных центра вызовов и его средств создания отчетов”, - сказал Стюарт.
TAPI и TSAPI: это слишком примитивно
Но есть еще одна причина, почему производители средств CTI избегают TAPI и TSAPI. “Эти интерфейсы созданы для простых приложений и не предлагают разработчикам такой гибкости, как работа с PBX напрямую”, - сказал Гэри Барнетт, президент компании Prospect Software (Сан-Хосе, шт. Калифорния), поставляющей межплатформное ПО для CTI.
Обобщенные интерфейсы
Брайан Шерман, главный специалист по технологиям и исполнительный вице-президент по исследованиям и разработкам компании Nabnasset (Эктон, шт. Массачусетс), поставляющей средства CTI, утверждает, что TAPI и TSAPI являются обобщенными интерфейсами, предназначенными для работы с различными PBX, и поэтому они не имеют таких изощренных функций, как отслеживание звонков, необходимое в приложениях центров обработки вызовов.
Шюллер из Gartner Group отметил, что интерфейсы TAPI и TSAPI недостаточно хорошо отслеживают состояние вызова. “Если кто-нибудь пытается перенаправить вызов, а он не проходит, PBX не уведомляет приложение CTI и вызов может на несколько мгновений зависнуть”, - объяснил он.
“Проблема усугубляется тем, что PBX может ошибочно распознать перевод как успешный, а пользователь при этом даже не догадается, что есть проблема”, - добавил Шюллер.
Шерман из компании Nabnasset не склонен ставить в вину компаниям Novell и Microsoft ограничения их API. Он считает, что проблема кроется в конструкции PBX. “Каждая офисная станция распознает и собирает сведения о поступившем вызове по-своему, все они имеют мало общего с той базой, на которой Microsoft и Novell могли бы построить свои API”, - говорит он.
Приукрашивание стандартов
Для преодоления этих проблем существует два пути. Первый - поддержка всеми PBX общего набора стандартных интерфейсов.
Европейская ассоциация производителей компьютеров (The European Computer Manufacturers Association, ECMA) в Женеве разрабатывает такую спецификацию под названием Computer Supported Telecommunications Applications (CSTA), и несколько поставщиков, в том числе Lucent Technologies и Nothern Telecom, уже встроили ее в свои продукты.
Поскольку работа над CSTA началась в 1990 г., ECMA запросила материалы о прототипе в Американском национальном институте стандартов (American National Standards Institute). Две группы закончили работу над первым вариантом стандарта в 1992 г., вторая версия была завершена в 1995 г.
Стандарты CSTA учитывают специфические для центров обработки звонков проблемы, например маршрутизацию вызовов. Они выделяют способы сбора информации о состоянии агентов, включая даты их регистрации для работы в сети.
Кроме того, стандарт содержит такие функции для телемаркетинга, как выполнение внешних упреждающих звонков, снижающее для сотрудников центров обработки вызовов риск набора одного и того же номера более одного раза, и автоматическое обнаружение работы автоответчиков.
Вторым решением Novell и Microsoft в интеграции PBX и CTI будет усовершенствование своих API. Однако Барнетт из компании Prospect Software сомневается, что интерфейсы когда-нибудь действительно нивелируют различия PBX.
На сегодняшний день поставщики средств CTI предпочитают непосредственную работу с интерфейсами PBX, а не с TAPI или TSAPI.
“API компаний Novell и Microsoft отлично работают тогда, когда какой-нибудь производитель хочет реализовать простые функции CTI, например отображение сообщения голосовой почты на экране пользователя, - сказал Шерман из компании Nabnasset. - Но если приложение должно выполнять более сложные функции, у разработчика нет иного варианта, кроме обращения непосредственно к интерфейсу PBX”.
Пол Корженевски
Пол Корженевски - независимый автор из Садбери (шт. Массачусетс). Он специализируется на работе сетей. Его адрес E-mail: paulkorzen@aol.com.
