Жизнь в общении
С давних пор в качестве основного средства коммуникаций в компаниях живет телефония, упорно не желая сдавать свои позиции. Она серьезно трансформировалась за последние десятилетия, перейдя от аналоговой к цифровой форме, а затем и к VoIP, сократив стоимость междугородных и международных переговоров.
Каналов связи стало много. Наш день проходит в общении по мобильному и офисному телефону, телефонным IP-сервисам, вроде Skype/WebEx/Google+, регулярной переписке по e-mail, ответам на IM, участии в аудио/видеоконференциях и пр. Причем орудуем этими средствами с разных устройств, беспрестанно переключаясь между ними. Мы тонем в беспрерывных коммуникациях, пытаясь параллельно заниматься делом. Думается, десять, да даже лет пять назад плотность общения была куда меньше, и вроде как на реализацию чего-то полезного оставалось времени побольше. Да, было время, чтобы спокойно подумать…
Сшивая бесшовно
Наплодив огромное количество средств общения, компании не один год пытаются как-то сшить все эти средства коммуникации в нечто удобоваримое. Казалось бы, чего сложного — ан нет, все как-то неаккуратненько получается.
Ну Microsoft, понятно, всегда идет своим путем, поэтому концептуально вроде выглядит неплохо, но стандарты изобретают свои, поэтому с другими далеко не всегда стыкуется, но vendor lock-in не позволяет расслабиться, поскольку затраты нормально так подрастают с каждой новой лицензией. Поэтому не живется спокойно креативным айтишникам по всему миру, ищут как бы оптимизнуть свое хозяйство не в урон клиентам, как внутренним, так и внешним, пытаясь то тут, то там подтащить менее дорогие проприетарные или OpenSource-решения. Не всегда удачно, но «дорогу осилит идущий».
Иногда не возьму в толк, почему не столь обеспеченные производители решений пытаются идти дорогим Microsoft-овским путем, упрямо изобретая велосипед. Например, есть неплохое проприетарное UC-решение Communigate Pro от Stalker Software. Обходится раза в два дешевле, чем монстроидальная связка Microsoft Exchange + Lync, хотя некоторые фичи далеко не так изящны, как у редмондцев. Однако ребята молодцы, разрабатывают хороший почтовик (и не только) поддерживающий множество открытых стандартов (хоть в этом плане не следуют за Microsoft).
Вместе с тем ума не приложу, зачем они решили самостоятельно разрабатывать все модули, входящие в UC. Ну, понимаю, почтовый сервер, но взвалить неподъемную ношу в виде VoIP-телефонии, XMPP-сервера и много чего ещё — уже чересчур. Это отдельные масштабные разработки, нормально профинансировать которые может разве что монстр вроде Microsoft или Google. Зачем они расходуют ресурсы на направления, где не смогут быть победителями? Почему не выберут более реалистичный путь интеграции своего почтовика с Asterisk для VoIP и видеообщения, Openfire в качестве корпоративного XMPP (Jabber) сервера для IM, OpenMeetings для вебинаров и видеоконференций и т.п.?
У того же Asterisk уже сформировалось окружение производителей аппаратного обеспечения, поддерживающих стыковку с традиционной аналогово-цифровой телефонией. Близкого по масштабам движения нет у Communigate и вряд ли когда будет, все-таки это проприетарная платформа, менее распространенная, чем Asterisk. Из-за того что «нормальные герои всегда идут в обход», получаем, вроде неплохой продукт, но, опять же, какой-то ущербный, но с другого бока. Вроде уже нет жесткого vendor lock-in, поскольку используются открытые стандарты, но разработка отдельных частей идет крайне медленно, и их функциональность и темпы изменений сильно не дотягивают до OpenSource-реализаций.
При этом они во многом позади того же Microsoft, поскольку создаваемая ими конструкция не столь целостна. UC-клиент Pronto!, написанный ими на сомнительной с точки зрения перспектив развития технологии Adobe Air, интересный, но какой-то «угловатенький». Да, пытаются его как-то развивать, но явно видно, что ресурсов не хватает. Удобного UC-клиента, аналога Microsoft Communicator/Lync + Outlook, ой как не хватает для успешного использования продукта в корпоративной среде.
Stalker-овцы даже не удосужились отранжировать имеющиеся на рынке UC-клиенты, в первую очередь OpenSource, чтобы выбрать продукты, максимально закрывающие функционал их сервера. Им стоило поддержать имеющиеся OpenSource UC-клиенты и сделать нормальный стык с Mozilla Thunderbird + Lightning вместо того, чтобы изобретать очередной велосипед. Собирать зрелые продукты воедино, делая бесшовные стыки, — задача куда более простая, чем пытаться разработать и развивать эти технологии самостоятельно. В конце концов, попробовали бы воспользоваться Microsoft-овским Lync, смогли ведь работать с Outlook через MAPI Connector.
У «чистых» OpenSource UC-решений тоже как-то все не клеится. Порознь имеется немало достойных продуктов, способных сложиться в красивую мозаику UC, но движение пока напоминает потуги лебедя, рака и щуки в известной басне. Корпоративщикам приходится применять куски мозаики порознь, так как интеграция практически отсутствует. Естественно, страдает удобство для пользователей и для администраторов.
Слышу голос из прекрасного далека
Множество каналов общения, «повзрослевших» за последние годы, — вроде, удобно, однако, с другой стороны, постоянные переключения несколько истощают нервную систему. Не всегда помнишь, где обсуждался тот или иной момент, поэтому поиски информации трудозатратны. Спустя некоторое время после голосового общения не сразу вспомнишь, о чем был разговор, если не прислали выжимку совещания по e-mail.
Вообще, далеко не всегда понимаю любовь некоторых коллег (как минимум замечено на наших датских собственниках) к аудиоконференциям, вроде того же WebEx. Мало того, что сборы небольшой компании в конференции, бывает, занимают с десяток минут из-за разных технических сложностей, так еще люди подключаются с различных устройств, в том числе с мобильных, VoIP, для которых нередки замирания, выпадения, бульканья и прочие артефакты. Даже если бы общение проходило на великом и могучем — и то было бы проблематично разобрать, а когда это английский, причем язык не родной для большинства участников, результативность подобного совещания нередко остается под вопросом. И, главное, те же вопросы можно обсудить по e-mail или IM куда быстрее и с меньшими затратами времени.
Электронные голуби
E-mail очень тесно вошел в корпоративную жизнь. Множество вопросов решается с помощью данной технологии. Вместе с тем это весьма неформализованный и неконтролируемый способ общения. Мало того, что нет гарантий, что «благодаря» антиспам-системам письмо вообще будет доставлено адресату, так еще и далеко не факт, что на проблему, озвученную в послании, обратят хоть какое-то внимание. А если и обратят, нет уверенности, что не забудут в следующую минуту, переключившись на другой коммуникационный канал, случайно сняв пометку о прочтении.
При общении с западными коллегами приходится тщательно придерживаться простого правила: одно письмо — одна проблема, и желательно, чтобы суть была передана в двух-трех первых строчках. Если в письме написать о нескольких проблемах — с высокой вероятностью при хорошем стечении обстоятельств только на одну будет дан ответ. Если текст послания будет обширным, скорее всего, ответа даже на один вопрос не поступит.
Сегодня популярно в качестве контактной информации размещать на сайтах организаций помимо телефона еще и e-mail. Это здорово, конечно, ибо времени на телефонные переговоры всегда не хватает, да и после общения по почте остается задокументированный ответ, к которому можно вернуться впоследствии. Проблема одна — культура общения по e-mail. Она на приемлемом уровне далеко не во всех организациях. Можно долго гадать, по какому критерию получатель сообщения определяет, стоит ли ему отвечать или просто промолчать, но проблема таких «молчунов» довольно распространена.
Например, недавно ради интереса посмотрел, как отрабатывается контактный e-mail на сайте «Комстара» (МТС). Включение опции «уведомление о прочтении» при отправке сообщения дает возможность проследить, насколько важен клиент для организации. Итак, отправляю сообщение о проблеме с кабельным ТВ. Через некоторое время получаю пяток уведомлений о прочтении разными сотрудниками и пару удалений без прочтения. Делаю вывод, что до систем ServiceDesk организация пока не доросла, поскольку сообщение клиента отрабатывается веерной рассылкой по сотрудникам. {PAID}
Ущербность такого подхода очевидна. Во-первых, много людей тратят время на прочтение одного и того же сообщения, а это непродуктивное расходование рабочего времени. Во-вторых, каждый из них знает, что в рассылку включено несколько коллег и полагает, что ответит его сосед, в результате не отвечает никто. В-третьих, при получении уведомлений клиент видит реальные внутренние e-mail-адреса сотрудников, включенных в алиас. Это не всегда хорошо с точки зрения безопасности, да и в дальнейшем он может воспользоваться прямым е-mail и не получить ответ, например, из-за увольнения человека или смены фамилии (нерадивые айтишники не всегда оставляют переадресацию со старого e-mail на новый). В-четвертых, клиент видит, что толпа народу прочитала сообщение, однако парочка без зазрения совести, не глядя, его удалила. Ему же невдомек, что эти двое — руководители подразделений, и кто додумался включить их в алиас — одному богу известно. Это к вопросу о бездумном расходовании рабочего времени. Пока не узнал по внутренним МТС-каналам, кто удалил без прочтения моё сообщение, было как-то неприятно. Хотя «ложечки нашлись, но осадочек остался».
Печально, что бизнес-руководство далеко не всегда удается переубедить в необходимости отказа от использования e-mail с веерной рассылкой по сотрудникам службы поддержки и перехода на систему ServiceDesk в бизнес-подразделениях (про ИТ-департамент и так ясно). Почему-то руководители наивно полагают, что раз уж все сотрудники клиентского сервиса получили письмо от клиента, то уж всяко найдется кто-то, кто ответит. Причем многие искренне уверены, что уж у нас-то клиент точно будет обслужен наилучшим образом. Однако на вопрос, на каких данных основываются эти суждения, получить объективный ответ, как правило, не удается. Кстати, по моему опыту, как раз в случае таких веерных рассылок вероятность, что клиент получит ответ, — минимальная.
Доставка с гарантией
Кстати, любопытный момент, дополнительно характеризующий клиентоориентированность МТС. Некоторое время назад компания консолидировала различные сервисы: мобильную и фиксированную телефонию, кабельное телевидение, Интернет. Однако чтобы получить на веб-сайте доступ к личному кабинету, задать вопрос и даже подать идею, почему-то необходимо ввести номер МТС-овского мобильного телефона. Номер является обязательным параметром, без которого приобщиться к электронным сервисам не дадут. Видимо, считается, что если уж начал использовать кабельное или Интернет от МТС, то надо и их мобильный номер сразу получать, по-другому никак. Кстати, у «Билайна» одно время была аналогичная проблема с IVR, невозможно было добраться до живого человека, пока не введешь номер Билайновского мобильного.
Мне представляется, что применение e-mail в корпоративе требует определенного переосмысления и перехода на более формализованные системы, напоминающие процесс обслуживание в системе ServiceDesk. Большая часть писем, по сути, является вполне определенной задачей для одного или нескольких сотрудников. В идеале нужно писать не письма, а поручения в терминологии Outlook. Однако даже этого часто не делается, хотя вкупе с «беседами» может что-то удобоваримое и вышло бы. Однако все же в этом почтовом клиенте процесс отработки поручений далек от идеала, да и пользователи, применяющие другие системы, скажем, Lotus Notes или Thunderbird + Lightning, не смогут отработать задачу, отправленную из Outlook. А хотелось бы, чтобы при отправке поручения партнерам/коллегам оно было гарантированно отработано с соответствующими изменениями статусов, возможностью эскалации, получения уведомлений и т. п.
У себя в ИТ-отделе уже давно не приветствую общение по e-mail. Если есть задача, которую нужно обсудить и реализовать, пусть родилась она внутри ИТ-коллектива, а не у клиента — надо написать на e-mail ServiceDesk, чтобы запрос зафиксировался в системе. При этом при его закрытии заявитель получит соответствующее уведомление, а переписку по задаче вполне можно вести в почтовом клиенте, добавляя в качестве адресата и e-mail ServiceDesk-а, не убирая тему с идентификатором исходного сообщения. К сожалению, так вести дела не всегда удобно в используемой у нас системе, но куда лучше, чем e-mail, поскольку гарантирует, в отличие от последнего, что рано или поздно задача будет отработана либо сама рассосется.
В качестве системы накопления задач у нас неплохо прижилась бесплатная OpenSource-система OTRS (www.otrs.org). Наличие открытых исходников и документации для разработки позволяет «затачивать» систему под нужды сотрудников. ПО достаточно активно развивается, и в конце января этого года вышло очередное обновление с новым интересным модулем «управление процессами». Эх, если бы разработчики реализовали прямой доступ по IMAP к сообщениям, зарегистрированным в OTRS (естественно, без возможности удаления), да еще бы поддержку протокола CalDAV или iCalendar. В этом случае можно было бы продуктивно работать с задачами, заменив набивший оскомину Outlook куда более стабильным, шустрым и бесплатным Thunderbird.
Мобильный OpenSource
С мобильными коммуникациями ситуация пока тоже далека от идеала. Похоже, идеологию лебедя, рака и щуки продвигает и Google в Android. Для массы вендоров удобно было использовать OpenSource-решение Android, неплохо подходящее для различных устройств. Но каждый производитель стремился по-своему усовершенствовать ОС, внеся какие-то изменения как в интерфейс, так и в подноготную. В результате получаем, что одна и та же версия Android на устройствах разных производителей в корпоративной среде ведет себя по-разному.
Скажем, с 4-й версии наконец-то появилась полноценная поддержка IPSEC VPN, так что планшеты стало возможным вязать с Cisco ISR-роутерами без установки дополнительного ПО. Однако рано мы обрадовались, ибо на оттестированных нами устройствах от Samsung, Huawei и Google с идентичной версией прошивки где-то VPN устанавливался, а где-то отказывался напрочь.
Долгожданная NTLM-аутентификация в родном браузере наконец появилась на Android 4. Однако вот напасть, Google с компанией умудрились крупно лажануться, поскольку после авторизации с использованием NTLM скачать какой-либо файл не получится, ибо скачивание работает под другим процессом, которому забыли передать NTLM-авторизацию, поэтому он не может забрать файлы. В результате вся радость моментально улетучилась. Непонятно, чего ждет толпа участников OpenSource-разработки Android, если эта ошибка не исправляется уже более года. По сути, получается, что Google по-прежнему не интересен корпоративный рынок, если такую проблему не могут так долго «вылечить».
Аналогичную инфантильность OpenSource-сообщества можно наблюдать в плане безопасности мобильной ОС. Android лидирует по количеству незалатанных брешей. Непонятно, зачем орава производителей лепят свои надстройки, если уже реализованный функционал ОС работает криво и улучшений пока не видать. Стоило сосредоточиться на заделывании дыр, раз даже у Google, похоже, в погоне за фичами, не хватает сил, чтобы обеспечить стабильную работу существующего функционала. Учитывая, что на мобильных устройствах частенько хранится куда более приватная информация, чем на ПК, защищать есть что.
Несмотря на всю OpenSource-ность Android, задержка в обновлении версий когортой производителей девайсов может измеряться годами. Некоторые производители после выпуска очередного шедевра в лучшем случае сделают пару обновлений в течение полугода, лишь бы он хоть как-то работал, после чего бросаются выпускать новый, куда более совершенный гаджет. В результате на Android велики риски, что пользователь останется со своими проблемами (с безопасностью) один на один. В лучшем случае кто-то (не оригинальный производитель) выпустит неофициальную прошивку, опять же, сомнительного содержания. В этом плане использование устройств на iOS, не смотря несколько более высокую цену, выглядит более разумным, т.к. производитель поддерживает обновление как минимум 3 года – типичный срок жизни оборудования в корпоративной среде.
После тестирования различных устройств на предмет работы с корпоративными приложениями, как это ни печально, но пришли в очередной раз к выводу, что пока Android-устройства сыроваты для корпоративного использования.
Опубликовано 25.02.2013