Планирование перехода на единую систему обмена сообщениями

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

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

Краткая история голосовой почты

Поскольку в действительности вы не можете планировать способ достижения конечного пункта, не зная, откуда ваше путешествие начинается, я хочу сделать шаг назад и дать краткий обзор систем голосовой почты — как того, откуда они появились, так и того, какова их архитектура. Существуют споры о том, кто первым изобрел систему голосовой почты. Однако, первая появившаяся в продаже система голосовой почты называлась VMX, что раскрывается как Voice Message Exchange (обмен голосовыми сообщениями).

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

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

Конечно, для обеспечения способа взаимодействия с системой голосовой почты необходимо было создать пользовательский интерфейс тонального набора (TUI). Интерфейсы TUI с годами менялись и, к сожалению, для голосовой почты не существует стандартного интерфейса. Если на вашем сотовом телефоне есть голосовая почта, вероятно вы часто слышали что-нибудь вроде «нажмите 1 для получения голосовой почты.» Но с распространением систем голосовой почты, управляемых речью, в которых используются голосовые пользовательские интерфейсы (VUI), интерфейс TUI уже не имеет такого важного значения, как когда-то. Однако не следует недооценивать то, что пользователи могут испытывать привязанность к конкретному интерфейсу.

Используемые в настоящее время корпоративные системы голосовой почты основываются на двух разных архитектурах: распределенной и централизованной. На рис. 1 показаны офисы в Сиэтле, Нью-Йорке и Остине, имеющие распределенную архитектуру голосовой почты, в которой системы голосовой почты существуют бок о бок в каждом из этих филиалов. В отличие от них, в офисах в Лондоне, Париже и Глазго используется централизованная модель, в которой инфраструктура УАТС объединена в сеть, и все вызовы направляются обратно в центральное местоположение в Лондоне. У каждой модели есть свои преимущества и недостатки. Но следует отметить, что даже в случае распределенной модели можно системы голосовой почты объединять в сеть для доставки сообщений между филиалами.

Рис. 1 Две распространенные модели архитектуры голосовой почты

Существуют три основные причины, по которым организация может предпочесть распределенную модель: необходимость в локальной доступности, наличие разнородных систем УАТС, которые невозможно объединить в сеть, и единообразные ограничения для абонентских групп.

Некоторым организациям требуется такая система голосовой почты, чтобы в случае сбоя в работе сети локальная УАТС и система голосовой почты продолжали нормально работать, обеспечивая филиалу полный набор функций системы. Системы интерактивного речевого ответа (IVR) продолжат работу, и звонящие извне смогут по-прежнему оставлять сообщения. В сущности, это никак не скажется на конечных пользователях, и работа будет продолжаться в нормальном режиме. Возможно, это покажется знакомым — именно по этой же причине многие организации предпочитают локализовать свои серверы, на которых работает Microsoft® Exchange Server. Вашей организации может потребоваться выполнить оценку рисков, чтобы определить, является ли необходимой локальная бесперебойность работы.

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

Для объединения в сеть нескольких УАТС требуется единообразная абонентская группа (или UDP). UDP предусматривает, что телефонные добавочные номера и добавочные номера голосовой почты не должны перекрываться. На рис. 1 можно заметить, что Сиэтл, Нью-Йорк и Остин имеют перекрывающиеся диапазоны добавочных номеров. Это объясняется тем, что для филиалов, находящихся в Соединенных Штатах, нет UDP. UDP можно создать, расширив диапазон добавочных номеров до 7 или 10 цирф, но при этом возникают другие проблемы.

Вам может потребоваться изменить шаблоны набора на всех телефонах, изменить все добавочные номера пользователей в УАТС и изменить все приложения, интегрированные в систему. Это может вызвать недовольство сотрудников, которым придется помнить 7- или 10-значные номера, чтобы позвонить в соседнее помещение.

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

Планирование перехода

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

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

Инфраструктура При проектировании инфраструктуры для единой системы обмена сообщениями потребуется принять решение относительно требований к сети, интеграции телефонии, размещения сервера и т.п. Если вы еще не знакомы с основными стратегиями развертывания, прочитайте мою предыдущую статью «Развертывание единой системы обмена сообщениями с использованием Exchange Server 2007» (см. веб-страницу technet.microsoft.com/magazine/cc137737).

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

Индикация ожидающих сообщений Вам, возможно, хотелось бы, чтобы ваше решение работало без индикаторов ожидающих сообщений, но ваши пользователя, вероятно, потребуют эту функцию. Поэтому не стоит недооценивать привязанность пользователей к этим уведомлениям в виде красных световых индикаторов. К счастью, существует несколько компаний, разработавших приложения для индикации сообщений для Exchange Server.

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

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

Администрирование Единая система обмена сообщениями Exchange основана на Active Directory® и роли сервера почтовых ящиков Exchange. Потребуется предусмотреть, каким образом развертывание единой системы обмена сообщениями скажется на администрировании, системных требованиях и т.п..

Пользовательский интерфейс При развертывании нового пользовательского интерфейса необходимо обеспечить обучение пользователей. В единой системе обмена сообщениями Exchange используется интерфейс, очень напоминающий тот, который используется большинством поставщиков сотовых телефонов, поэтому большая часть пользователей должна освоиться с ним на интуитивном уровне. В нем используется также распознавание речи, чтобы у пользователей не было необходимости пользоваться тональным набором. В Exchange Server он называется Outlook® Voice Access.

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

Практические стратегии перехода

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

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

1. Создайте план и разработайте проект решения.
2. Установите и настройте роль сервера единой системы обмена сообщениями.
3. Выполните перевод пробной группы.
4. Пересмотрите свой проект на основе информации, полученной от пробной группы.
5. Выполните перевод пользователей.

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

Планирование и проектирование решения является самостоятельным наиболее важным этапом процедуры перехода. Рекомендую создать для этого проекта группу единой системы обмена сообщениями. В эту группу должны входить представители из разных частей организации, имеющие опыт в области телекоммуникации, Active Directory, Exchange, сетей, безопасности, обучения и управления проектами. Получите также подробную схему архитектуры инфраструктур существующей УАТС вашей компании, голосовой почты и электронной почты.

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

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

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

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

При выборе постепенного перехода сообщества пользователей, происходящего в течение недель или месяцев, создаются «островки» голосовой почты среди пользователей, эксплуатирующих устаревшую и единую систему обмена сообщениями. Это препятствует перенаправлению сообщений между пользователями посредством голосовой почты. Если ваш проект не предусматривает создание сети обмена сообщениями, часть деловых связей будет нарушена. Если вы готовы к этому, рекомендую обеспечить включение решения для сети обмена сообщениями в исходный проект.

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

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

Подробный разбор этапов перехода

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

На рис. 2 подробно представлена архитектура организации. Изменение этой смешанной архитектуры Exchange не планируется. Основной центр данных офисов в США находится в Сиэтле. Все приложения ИТ для Остина обслуживаются из Сиэтла, а нью-йоркский офис обеспечивает работу локализованных служб Exchange. Голосовая почта для точек в США распространяется посредством разнородной инфраструктуры УАТС. Технически инфраструктуру УАТС невозможно включить в сеть для обеспечения централизованной голосовой почты. Европейские офисы, напротив, имеют единый центр данных, находящийся в Лондоне. Все приложения ИТ и связи в Евроае обслуживаются из этого единого центра данных.

Рис 2. Пример архитектуры до перехода

В целом инфраструктура голосовой почты основана на платформе Octel (теперь она называется Avaya). Все системы голосовой почты были объединены в сеть с помощью OAN (Octel Analog Networking), коммерческого сетевого протокола, использующего аналоговые телефонные линии и междугородние вызовы для отправки сообщений включенной в сеть голосовой почты. Эта архитектура обеспечивает обмен голосовыми сообщениями между филиалами в рамках всей организации.

Задачи, возникающие в предприятиях с несколькими филиалами

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

«Используется централизованная архитектура Exchange Server и смешнная среда телефонии.»

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

Если необходима локальная бесперебойность для всего филиала, хорошим вариантом станет удаленный сервер единой системы обмена сообщения, установленный в данном филиале. Если такого требования нет, в филиале можно установить шлюз SIP. Единая система обмена сообщениями Exchange обладает гибкостью, которая позволяет обойтись без объединения в сеть инфраструктуры УАТС и не требует единообразной абонентской группы.

«Выполняется обновление архитектуры сервера Exchange.»

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

«Имеется множество небольших филиалов с числом сотрудников менее 10, и в некоторых филиалах нет УАТС.»

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

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

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

Для каждого филиала группа предусматривает пользователей, мгновенно переходящих на единую систему обмена сообщениями, и сохраняет устаревшую платформу для поддержки приложений IVR, которые остаются в употреблении до момента, когда будет найдено альтернативное решение. Группа решила подождать 30 дней после перехода, прежде чем выполнять переход в следующей точке. Период ожидания предназначен для того, чтобы прежде чем выполнять перевод большего числа пользователей и увеличивать число звонков в службу поддержки, была возможность убедиться в том, что все филиалы освоились с новой платформой.

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

В нью-йоркском филиале имеются свой собственный сервер почтовых ящиков и транспортный сервер-концентратор. В соответствии с практическими рекомендациями сервер единой системы обмена сообщениями следует установить в Нью-Йорке. Группа устанавливает сервер в соответствии с документами по планированию перехода. Сервер добавляется к списку узлов на сервере сети обмена сообщениями с целью его включения в сеть голосовой почты. Пользователи проходят обучение и плавно переходят к единой системе обмена сообщениями.

В филиале в Сиэтле уже имеется сервер единой системы обмена сообщениями, развернутый на этапе перехода в Остине. Группа определяет, что сервер имеет достаточное число портов для поддержки филиала как в Сиэтле, так и в Остине. Пользователи в Сиэтле проходят обучение и переходят к единой системе обмена сообщениями.

Выполнить проект архитектуры в Европе гораздо проще. Инфраструктура УАТС объединена в сеть, и сервер Exchange централизован. Сервер единой системы обмена сообщениями разворачивается в Лондоне, и переводятся все филиалы, начиная с самых небольших. На рис. 3 показана окончательная архитектура.

Рис 3. Пример архитектуры после перехода

Важность следования плану

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

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

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

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

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