Расстроенный проект
Автор
Андрей Федоров
С приходом кризиса в Россию большинство компаний стали интенсивно худеть, не без сожаления расставаясь с остатками «подкожных накоплений»
Осенью прошлого года в нашей компании стартовал проект, которому не суждено было реализоваться до конца. Незавершенный проект или завершенный не так, как хотелось бы, в ИТ не редкость. Однако наш был весьма амбициозным, при этом бюджет фактически не выделялся, сроки были установлены авральные, а ресурсы наличествовали только внутренние. Но обо всем по порядку.
Прошлый год для большинства компаний оказался немного лучше позапрошлого, но тоже не подарок. Да, наметился определенный рост, началось движение, но объемы не такие как раньше. С приходом кризиса в Россию большинство компаний стали интенсивно худеть, не без сожаления расставаясь с остатками «подкожных накоплений». К концу 2009 г. жира не осталось, а расставаться с мышцам было как-то жалко. Какое-то движение началось, но очень и очень осторожное. Инвестиции делались в весьма ограниченном объеме, лишь бы не потерять занятые позиции. Соответственно, при бюджетировании они не планировались, поскольку не было обозначено каких-либо кардинальных изменений в бизнесе. К осени стало ясно, что год должен пройти нормально, но пора делать уже что-то посущественнее, чтобы оторваться от ближайших конкурентов, начинающих приходить в себя после голодных кризисных лет (хотя в целом кризис в мировой экономике пока далек от завершения).
Трансформация «костюмеров»
Этим «чем-то» должна была стать давно витавшая в воздухе идея по централизации отдела Customer Service (CS, или, на нашем жаргоне, «костюмеры»). Собственно, CS-ы у нас были уже пару лет. Такой подход исповедуют немало западных компаний, know-how здесь нет, хотя в российских компаниях такое встречается нечасто. Основная задача CS состоит в разгрузке продавцов, чтобы вместо них перерабатывать приносимую «сырую добычу». Продавец модели, который «и швец, и жнец, и на дуде игрец», трансформируется в семейную пару: добытчик-коммивояжер и «наложница-костюмерша», выполняющая офисную рутинную работу. Поскольку продавец по большей части вне офиса, а «костюмер» всегда в офисе, то документы для клиентов готовятся в максимально короткие сроки, а общее количество сотрудников, занятых продажами, сокращается, поскольку они работают эффективнее. Соотношение коммерсантов и CS-ников где-то 10:1. Кроме того, при таком подходе с клиентом работают два сотрудника разных подразделений, в идеале территориально распределенных и периодически ротируемых. Все эти моменты усложняют сговор, вероятность нанести финансовый урон компании снижается, соответственно, это организационное изменение позволяет экономить на технических средствах обеспечения информационной безопасности.
Исторически сложилось, что наши «костюмеры» находились во всех более или менее крупных филиалах компании. С одной стороны, этот подход был верным из-за часовых поясов, т.е. для обеспечения концепции follow-the-sun. С другой стороны, все запросы обрабатывались в центральном офисе (ЦО) и «бутылочное горлышко» часто оказывалось именно там. Поскольку управлять оравой разбросанных по городам и весям России «костюмеров» и контролировать их взаимодействие с коммерсантами и клиентами непросто, идея централизации службы витала в воздухе достаточно давно, но до реализации руки никак не доходили.
Решение о централизации обрушилось на нас внезапно, что частенько именно так и происходит в быстроразвивающихся компаниях (это к вопросу о разработке ИТ-стратегии). Задача ставилась просто. Нужно было за пару месяцев (до конца года) обеспечить эффективную работу централизованных «костюмеров», подбор которых стартовал параллельно.
В теории, при централизации людей нужно меньше, чем при распределенной работе. На практике же, с учетом посменного характера работы из-за часовых поясов, получается примерно столько же. Однако возможности, с точки зрения повышения качества обслуживания клиентов, открываются совершенно иные при существенно меньших затратах. Опять же, одно дело — обеспечивать функционирование распределенной ИТ-инфраструктуры, и совсем другое — существенно более централизованной. Упрощается все кардинально, поскольку снижаются требования к каналам связи, серверам в филиалах, телефонному и сетевому оборудованию, а также программному обеспечению в регионах (браузера достаточно). Регионы переставали быть некоторой критичной точкой отказа, бесперебойность работы которой нужно было обеспечивать чуть ли не круглосуточно. «Умер» канал в регионе — не беда, коммерсант может отправить короткий запрос по GPRS или Wi-Fi из ближайшего McDonalds.
Для полноты ощущений бизнес озвучил, что обработка всех заявок должна происходить по максимально идеализированному «револьверному» принципу, т.е. при полной стандартизации «патронов»: любой «костюмер» в любой момент должен иметь возможность обработать запрос любого коммерсанта. Для нашего бизнеса организовать такой подход очень непросто: поскольку мы инжиниринговая компания, любая продажа уникальна и требует индивидуального, порой нетривиального и продолжительного обсчета клиентского ТЗ. При новой же схеме документ мог начать готовить один «костюмер», а продолжить — другой/другие. Подобный стиль работы невозможен без идеально функционирующей информационной системы, которая у нас была «заточена» для работы по традиционной схеме. И перекроить ее под новые веяния нужно было за пару-тройку месяцев.
ИТ-спецназ
Все сотрудники моего отдела за годы работы в компании приобрели отменный «боевой» опыт, участвовали в решении немалого количества изощренных задач в максимально короткие сроки, т.е. представляли собой эдакий ИТ-спецназ, способный находить простые решения для сложных проблем. В крупной компании (сужу по нашим собственникам) решение такой задачи затянулось бы на год, учитывая массу стандартов и процедур, которых следует придерживаться, а также обязательный выбор традиционных продуктов от ведущих производителей (своеобразная минимизация рисков), необходимость согласования бюджетов инвестиций и проч. Нам было «проще», поскольку финансирование проекта вообще не предусматривалось, и нужно было выцедить необходимые средства из бюджета на операционные расходы. Никакой экстрамотивации мне и моим сотрудникам за проект не полагалось. Как не полагалось и в случае внедрения ERP-системы и других достаточно масштабных проектов. Это штатная работа ИТ-шников, которая оплачивается в соответствии с принятой системой KPI и законодательством (сверхурочные).
Чтобы обеспечить централизованную работу «костюмеров», нужно было за два месяца решить следующие вопросы: создать контакт-центр на пару десятков агентов, интегрировать его с CRM, запустить систему для формализованной (исключающей потери) регистрации и обслуживания заявок со стороны клиентов и продавцов, предоставить безопасное (аутентифицированное) взаимодействие CS с коммерсантами, запустить оперативное уведомление продавцов о стадиях подготовки документов в back-office и т.д. Помимо меня проектом занималось два разработчика и два сисадмина. Работу по обеспечению функционирования других ИТ-систем никто не отменял, т.е. возникла дополнительная нагрузка, к внезапному появлению которой айтишники должны быть готовы, чтобы не тормозить развитие бизнеса.
Инфраструктура
В компании используется телефонная станция Nortel CS1000, поэтому первым очевидным желанием было «поднять» контакт-центр с использованием «железа» и софта этой компании (ныне Avaya). Однако было очевидно, что в случае использования Avaya/Nortel шансов за месяц с небольшим закончить проект нет никаких, а уж обойтись только бюджетом на операционные расходы — тем более. Поэтому решено было строить контакт-центр на бесплатном OpenSource softswitch Asterisk и стыковать его с основной АТС по SIP. Asterisk использовался в компании несколько лет для конвертации SIP от Panasonic (АТС в регионах) в SIP Nortel CS1000 и зарекомендовал себя как надежное и гибкое решение с достаточно удобным администрированием. Риск, что он не потянет нагрузку, несомненно, был, но неспешная обработка заказов со стороны Avaya (Nortel) однозначно не оставляла шансов запустить центр в нужные сроки. В качестве VoIP-телефонов для Asterisk использовались проверенные Nortel 1120E, популярные в компании. Asterisk, в отличие от, например, Microsoft Lync, концептуально основывается на поддержке открытых стандартов, поэтому для тех, кто его развертывает, доступен широкий выбор компонентов (например, аппаратных и программных VoIP-телефонов) сторонних производителей. В случае компаний, использующих проприетарные решения, выбор невелик, цена высока, возможны сложности с поставками и прочие «прелести» такого vendor lock-in, хотя снижается степень неопределенности, что «железо» не будет работать как полагается.
Как и прогнозировалось, потребовалось меньше месяца, чтобы «заточить» Asterisk под нужды контакт-центра: настроить гибкий IVR, распределение звонков, маршруты для стыка с основной АТС Nortel CS1000, обеспечить запись переговоров, статистику обслуживания звонков, мониторинг загрузки операторов и т.п. Интеграция Asterisk с CRM заняла примерно неделю. В случае с Nortel с привлечением аутсорсера мы больше года безуспешно пытались запустить CTI. Понятно, что системы разного класса рассчитаны на разные нагрузки, но все же достаточно показательно, насколько OpenSource-решение оказалось более дружелюбным для внедрения и разработки.
Хуже дела обстояли с обработкой звонков и e-mail запросов. Разработать за столь короткий период такую систему было нереально. Поскольку времени было в обрез, а предполагаемая бизнес-логика работы «костюмеров» по ключевым моментам сильно напоминала обработку ИТ-инцидентов, решили использовать для них OpenSource ITSM систему OTRS. OTRS я продолжительное время тестировал (отчасти локализовывал) для использования в своем отделе, и она вполне подходила для решения задач CS, так что внедрить ее сначала пришлось у «костюмеров» и лишь спустя некоторое время дошли руки до запуска в ИТ-отделе. OTRS показала себя неплохо, позволяя обрабатывать ежедневно до пятисот заявок. В системе пока немало ограничений (неудобств), но с ними вполне можно жить. Настроек у OTRS множество, а учитывая наличие Perl-овых исходников и документированного API, какие-то моменты можно решить самостоятельно, без участия разработчиков. Хотя, при оплаченной техподдержке, можно заказать доработку и им.
Одно из пожеланий со стороны руководства коммерческого департамента касалось оперативного информирования продавцов, находящихся «в полях», о стадиях подготовки документов для клиентов, прихода оплат и прочих моментов, касающихся оперативного взаимодействия. Для этих целей решено было использовать отправку SMS-сообщений с краткой информацией через шлюз «Билайн-бизнес». Для простоты разработки стыка CRM с SMS-шлюзом мы выбрали протокол SMTP, хотя, вероятно, стоило остановиться на SMPP: даже по прошествии нескольких месяцев использования услуги порядка 5% SMS-сообщений не удается отправить по SMTP с первого раза из-за непонятных ошибок на сервере «Билайн».
Коммуникации превыше всего
Одно из основных условий, поставленных бизнесом при технической реализации проекта по централизации, состояла в том, чтобы расходы клиентов на коммуникации с нами не должны были возрасти, чтобы не возник психологический дискомфорт из-за сделанных изменений в оргструктуре. Соответственно, встал вопрос о необходимости реализации единого номера 8-800, используя который, клиент мог бы бесплатно дозвониться до сотрудников контакт-центра и решить вопросы. Организация 8-800 оперативно была выполнена «Билайном».
Одной из наиболее сложных для меня задач было спрогнозировать, как перераспределятся звонки клиентов между филиалами компании и ЦО после запуска централизованного режима работы «костюмеров», чтобы корректно сверстать бюджет на следующий год. Я потратил немало времени, анализируя статистику потребления телефонного трафика, однако вынужден признать, что значительно ошибся с прогнозом, неверно предположив, что значительная доля звонков из филиалов перейдет в ЦО. По факту оказалось, что клиенты крайне инерционны и пока неактивно используют 8-800. Не исключено, что расходы будут возрастать по мере привыкания клиентов обращаться в ЦО для решения вопросов вместо коммуникаций со своим менеджером по продажам.
Помимо решения вопроса обеспечения комфортности для клиентов, для меня остро стоял вопрос не допустить значительного увеличения расходов на фиксированную и мобильную связь между продавцами в филиалах и CS. Увеличение расходов было неминуемым при традиционной схеме организации коммуникаций из-за кардинального изменения их структуры, поскольку количество междугородных звонков стало бы значительно преобладающим.
Для сокращения расходов решено было воспользоваться конвергентными услугами связи. Поскольку наибольшее количество междугородных звонков прогнозировалось между мобильными продавцов и фиксированными телефонами сотрудников контакт-центра, я остановился на схеме реализации конвергентных услуг по схеме FMTN вместо FMC. В приволжском федеральном округе мы стали второй компанией, кто воспользовался конвергентной услугой (FMTN) от «Билайн-бизнес». Этот сервис позволил нам объединить в единую технологическую сеть наши мобильные и фиксированные номера не только в рамках региона, но и по всей территории РФ, где присутствуют наши филиалы. После полугода использования FMTN, могу отметить, пожалуй, один недостаток: периодические «глюки» с биллингом по FMTN. Видать, штука сложна в реализации и пока слабо отлажена. Из-за этого ежемесячно приходится тратить время на перепроверку корректности расчетов стоимости услуг.
Основная цель запуска конвергентных услуг была достигнута: несмотря на значительное возрастание междугородних коммуникаций между CS и продавцами, затраты на мобильную телефонию подросли незначительно, по большей части из-за параллельного открытия двух десятков хоум-офисов от Хабаровска до Калининграда. Побочным эффектом от внедрения FMTN стало упрощение коммуникаций между сотрудниками компании благодаря короткому номеру и проч.
Конвергентные услуги вполне можно рассматривать как современную замену традиционной DECT-телефонии. С одной стороны, капитальные затраты на организацию DECT трансформируются в операционные (абонентская плата за использование сервиса и в некоторых случаях повременные расходы), с другой — повышается комфорт использования связи сотрудниками, поскольку не нужно таскать с собой помимо мобильника еще и DECT-трубку. Сотрудники ЦО при желании могут вообще обходится без офисного телефона, установив перевод звонка на мобильный.
При реализации проекта не оставили без внимания и вопрос безопасности коммуникаций между «половинками» — коммерсантами и CS. Поскольку предполагается, что некоторые запросы «костюмерам» поступают от коммерсантов в устной форме, была реализована процедура аутентификации, в которой помимо номера мобильного участвует и специально сгенерированный код, рассылаемый продавцам ежедневно.
Finite la comedia
Большинство упомянутых сервисов и сам контакт-центр были запущены в эксплуатацию в срок чуть более месяца и успешно работают. Теперь немного о грустном.
После реализации первого этапа нам нужно было «перекроить» существующие и внедрить новые системы для формализации бизнес-процессов обработки документов. Идеализированное требование обработки документов по «револьверому» принципу сыграло злую шутку. Обработка договоров перекраивалось из типовой конфигурации DocsVision «Согласование договоров» и заняло (силами подрядчика) более двух месяцев из-за нетрадиционного использования типового решения. Написано типовое решение не особо «эстетично», поэтому разбираться с ним непросто. При работе с механизмом Workflow понимаешь, что в случае сложных бизнес-процессов читабельность логики получается невысокой, пожалуй, не лучше, чем в случае красиво написанного объектного программного кода. Обилие скриптовых вставок в Workflow осложняет понимание и без того непростой бизнес-логики (месиво из квадратиков — просто взрыв мозга).
Адаптация информационной системы была практически завершена, когда неожиданно поступило указание от бизнеса свернуть реализацию «револьверного» принципа. Причины были достаточно просты. Количество изменений в компании оказалось столь велико и реализованы они были в столь короткие сроки (торопились к сезону продаж), что персонал не смог освоится с новшествами. Кроме того, накладные расходы на поддержание «револьверного» принципа оказались слишком значительными. CS-никам нужно было постоянно фиксировать, причем, максимально детально, контекст общения с продавцами и клиентами, чтобы при смене специалиста последователь мог продолжить общение, глупо не переспрашивая всю историю общения, как часто происходит при звонках в контакт-центры даже именитых компаний. Обеспечить такие гладкие коммуникации очень и очень непросто, если вообще возможно для нашего бизнеса.
При реализации «револьверной» схемы у меня были определенные сомнения, смогут ли «костюмеры» осилить работу в таком режиме. Идеологом централизации выступал один из очень компетентных топ-менеджеров компании, пожалуй, самый профессиональный в своей области, с кем довелось работать. Вероятно, его авторитет и напористость несколько притупила сформировавшуюся годами осторожность. Да и не скрою, сама попытка реализации подобной амбициозной бизнес-задачи была крайне интересна для меня. Откат от «револьверого» принципа оказался для участников проекта весьма болезненным.
Во-первых, реализация системы, как с айтишной, так и с организационной стороны фактически была завершена, что само по себе было достижением. Для нас остановка проекта на подлете к цели выглядела, как если бы пойти покупать ребенку игрушку, о которой он давно и страстно мечтал, и резко «обломить» его на кассе. Подобных разочарований у меня было несколько, но это — одно из самых болезненных. После мне потребовалось немало времени, чтобы собраться и приступить к реализации проекта по «деревольверизации».
Во-вторых, при постановке ТЗ подрядчику, дорабатывающему типовое решение DocsVision, оговаривались сроки именно на реализацию «револьверной» схемы. Про типовой вариант, пусть более простой, но которым все равно надо было заниматься, так как типовое решение удовлетворяло нас далеко не на 100%, разговора не было. Соответственно, мне нужно было кардинально корректировать ТЗ, да и людские ресурсы подрядчика уже были распланированы для переброса на другой проект. Естественно, столь кардинальное изменение привело к незапланированным расходам и к существенному увеличению сроков на переработку. В результате окончание проекта по автоматизации документооборота пришлось на момент, когда запускать его было небезопасно, поскольку уже начался сезон продаж, во время которого вносить существенные изменения в бизнес-логику работы бэк-офиса, мягко говоря, нежелательно.
Все же, несмотря на отказ от наиболее сложного и красивого элемента проекта, пожалуй, его можно считать удавшимся. Практически с нулевым бюджетом (используя имеющуюся инфраструктуру) за очень короткий срок было разработано вполне себе стабильно работающее решение. В очередной раз получили подтверждение, что OpenSource иногда предоставляет очень неплохие возможности для решения весьма сложных задач. Для себя же в очередной раз утвердился в мысли, что к оценке возможностей пользователей системы нужно подходить максимально тщательно на этапе «закладки» ТЗ.
Прошлый год для большинства компаний оказался немного лучше позапрошлого, но тоже не подарок. Да, наметился определенный рост, началось движение, но объемы не такие как раньше. С приходом кризиса в Россию большинство компаний стали интенсивно худеть, не без сожаления расставаясь с остатками «подкожных накоплений». К концу 2009 г. жира не осталось, а расставаться с мышцам было как-то жалко. Какое-то движение началось, но очень и очень осторожное. Инвестиции делались в весьма ограниченном объеме, лишь бы не потерять занятые позиции. Соответственно, при бюджетировании они не планировались, поскольку не было обозначено каких-либо кардинальных изменений в бизнесе. К осени стало ясно, что год должен пройти нормально, но пора делать уже что-то посущественнее, чтобы оторваться от ближайших конкурентов, начинающих приходить в себя после голодных кризисных лет (хотя в целом кризис в мировой экономике пока далек от завершения).
Трансформация «костюмеров»
Этим «чем-то» должна была стать давно витавшая в воздухе идея по централизации отдела Customer Service (CS, или, на нашем жаргоне, «костюмеры»). Собственно, CS-ы у нас были уже пару лет. Такой подход исповедуют немало западных компаний, know-how здесь нет, хотя в российских компаниях такое встречается нечасто. Основная задача CS состоит в разгрузке продавцов, чтобы вместо них перерабатывать приносимую «сырую добычу». Продавец модели, который «и швец, и жнец, и на дуде игрец», трансформируется в семейную пару: добытчик-коммивояжер и «наложница-костюмерша», выполняющая офисную рутинную работу. Поскольку продавец по большей части вне офиса, а «костюмер» всегда в офисе, то документы для клиентов готовятся в максимально короткие сроки, а общее количество сотрудников, занятых продажами, сокращается, поскольку они работают эффективнее. Соотношение коммерсантов и CS-ников где-то 10:1. Кроме того, при таком подходе с клиентом работают два сотрудника разных подразделений, в идеале территориально распределенных и периодически ротируемых. Все эти моменты усложняют сговор, вероятность нанести финансовый урон компании снижается, соответственно, это организационное изменение позволяет экономить на технических средствах обеспечения информационной безопасности.
Исторически сложилось, что наши «костюмеры» находились во всех более или менее крупных филиалах компании. С одной стороны, этот подход был верным из-за часовых поясов, т.е. для обеспечения концепции follow-the-sun. С другой стороны, все запросы обрабатывались в центральном офисе (ЦО) и «бутылочное горлышко» часто оказывалось именно там. Поскольку управлять оравой разбросанных по городам и весям России «костюмеров» и контролировать их взаимодействие с коммерсантами и клиентами непросто, идея централизации службы витала в воздухе достаточно давно, но до реализации руки никак не доходили.
Решение о централизации обрушилось на нас внезапно, что частенько именно так и происходит в быстроразвивающихся компаниях (это к вопросу о разработке ИТ-стратегии). Задача ставилась просто. Нужно было за пару месяцев (до конца года) обеспечить эффективную работу централизованных «костюмеров», подбор которых стартовал параллельно.
В теории, при централизации людей нужно меньше, чем при распределенной работе. На практике же, с учетом посменного характера работы из-за часовых поясов, получается примерно столько же. Однако возможности, с точки зрения повышения качества обслуживания клиентов, открываются совершенно иные при существенно меньших затратах. Опять же, одно дело — обеспечивать функционирование распределенной ИТ-инфраструктуры, и совсем другое — существенно более централизованной. Упрощается все кардинально, поскольку снижаются требования к каналам связи, серверам в филиалах, телефонному и сетевому оборудованию, а также программному обеспечению в регионах (браузера достаточно). Регионы переставали быть некоторой критичной точкой отказа, бесперебойность работы которой нужно было обеспечивать чуть ли не круглосуточно. «Умер» канал в регионе — не беда, коммерсант может отправить короткий запрос по GPRS или Wi-Fi из ближайшего McDonalds.
Для полноты ощущений бизнес озвучил, что обработка всех заявок должна происходить по максимально идеализированному «револьверному» принципу, т.е. при полной стандартизации «патронов»: любой «костюмер» в любой момент должен иметь возможность обработать запрос любого коммерсанта. Для нашего бизнеса организовать такой подход очень непросто: поскольку мы инжиниринговая компания, любая продажа уникальна и требует индивидуального, порой нетривиального и продолжительного обсчета клиентского ТЗ. При новой же схеме документ мог начать готовить один «костюмер», а продолжить — другой/другие. Подобный стиль работы невозможен без идеально функционирующей информационной системы, которая у нас была «заточена» для работы по традиционной схеме. И перекроить ее под новые веяния нужно было за пару-тройку месяцев.
ИТ-спецназ
Все сотрудники моего отдела за годы работы в компании приобрели отменный «боевой» опыт, участвовали в решении немалого количества изощренных задач в максимально короткие сроки, т.е. представляли собой эдакий ИТ-спецназ, способный находить простые решения для сложных проблем. В крупной компании (сужу по нашим собственникам) решение такой задачи затянулось бы на год, учитывая массу стандартов и процедур, которых следует придерживаться, а также обязательный выбор традиционных продуктов от ведущих производителей (своеобразная минимизация рисков), необходимость согласования бюджетов инвестиций и проч. Нам было «проще», поскольку финансирование проекта вообще не предусматривалось, и нужно было выцедить необходимые средства из бюджета на операционные расходы. Никакой экстрамотивации мне и моим сотрудникам за проект не полагалось. Как не полагалось и в случае внедрения ERP-системы и других достаточно масштабных проектов. Это штатная работа ИТ-шников, которая оплачивается в соответствии с принятой системой KPI и законодательством (сверхурочные).
Чтобы обеспечить централизованную работу «костюмеров», нужно было за два месяца решить следующие вопросы: создать контакт-центр на пару десятков агентов, интегрировать его с CRM, запустить систему для формализованной (исключающей потери) регистрации и обслуживания заявок со стороны клиентов и продавцов, предоставить безопасное (аутентифицированное) взаимодействие CS с коммерсантами, запустить оперативное уведомление продавцов о стадиях подготовки документов в back-office и т.д. Помимо меня проектом занималось два разработчика и два сисадмина. Работу по обеспечению функционирования других ИТ-систем никто не отменял, т.е. возникла дополнительная нагрузка, к внезапному появлению которой айтишники должны быть готовы, чтобы не тормозить развитие бизнеса.
Инфраструктура
В компании используется телефонная станция Nortel CS1000, поэтому первым очевидным желанием было «поднять» контакт-центр с использованием «железа» и софта этой компании (ныне Avaya). Однако было очевидно, что в случае использования Avaya/Nortel шансов за месяц с небольшим закончить проект нет никаких, а уж обойтись только бюджетом на операционные расходы — тем более. Поэтому решено было строить контакт-центр на бесплатном OpenSource softswitch Asterisk и стыковать его с основной АТС по SIP. Asterisk использовался в компании несколько лет для конвертации SIP от Panasonic (АТС в регионах) в SIP Nortel CS1000 и зарекомендовал себя как надежное и гибкое решение с достаточно удобным администрированием. Риск, что он не потянет нагрузку, несомненно, был, но неспешная обработка заказов со стороны Avaya (Nortel) однозначно не оставляла шансов запустить центр в нужные сроки. В качестве VoIP-телефонов для Asterisk использовались проверенные Nortel 1120E, популярные в компании. Asterisk, в отличие от, например, Microsoft Lync, концептуально основывается на поддержке открытых стандартов, поэтому для тех, кто его развертывает, доступен широкий выбор компонентов (например, аппаратных и программных VoIP-телефонов) сторонних производителей. В случае компаний, использующих проприетарные решения, выбор невелик, цена высока, возможны сложности с поставками и прочие «прелести» такого vendor lock-in, хотя снижается степень неопределенности, что «железо» не будет работать как полагается.
Как и прогнозировалось, потребовалось меньше месяца, чтобы «заточить» Asterisk под нужды контакт-центра: настроить гибкий IVR, распределение звонков, маршруты для стыка с основной АТС Nortel CS1000, обеспечить запись переговоров, статистику обслуживания звонков, мониторинг загрузки операторов и т.п. Интеграция Asterisk с CRM заняла примерно неделю. В случае с Nortel с привлечением аутсорсера мы больше года безуспешно пытались запустить CTI. Понятно, что системы разного класса рассчитаны на разные нагрузки, но все же достаточно показательно, насколько OpenSource-решение оказалось более дружелюбным для внедрения и разработки.
Хуже дела обстояли с обработкой звонков и e-mail запросов. Разработать за столь короткий период такую систему было нереально. Поскольку времени было в обрез, а предполагаемая бизнес-логика работы «костюмеров» по ключевым моментам сильно напоминала обработку ИТ-инцидентов, решили использовать для них OpenSource ITSM систему OTRS. OTRS я продолжительное время тестировал (отчасти локализовывал) для использования в своем отделе, и она вполне подходила для решения задач CS, так что внедрить ее сначала пришлось у «костюмеров» и лишь спустя некоторое время дошли руки до запуска в ИТ-отделе. OTRS показала себя неплохо, позволяя обрабатывать ежедневно до пятисот заявок. В системе пока немало ограничений (неудобств), но с ними вполне можно жить. Настроек у OTRS множество, а учитывая наличие Perl-овых исходников и документированного API, какие-то моменты можно решить самостоятельно, без участия разработчиков. Хотя, при оплаченной техподдержке, можно заказать доработку и им.
Одно из пожеланий со стороны руководства коммерческого департамента касалось оперативного информирования продавцов, находящихся «в полях», о стадиях подготовки документов для клиентов, прихода оплат и прочих моментов, касающихся оперативного взаимодействия. Для этих целей решено было использовать отправку SMS-сообщений с краткой информацией через шлюз «Билайн-бизнес». Для простоты разработки стыка CRM с SMS-шлюзом мы выбрали протокол SMTP, хотя, вероятно, стоило остановиться на SMPP: даже по прошествии нескольких месяцев использования услуги порядка 5% SMS-сообщений не удается отправить по SMTP с первого раза из-за непонятных ошибок на сервере «Билайн».
Коммуникации превыше всего
Одно из основных условий, поставленных бизнесом при технической реализации проекта по централизации, состояла в том, чтобы расходы клиентов на коммуникации с нами не должны были возрасти, чтобы не возник психологический дискомфорт из-за сделанных изменений в оргструктуре. Соответственно, встал вопрос о необходимости реализации единого номера 8-800, используя который, клиент мог бы бесплатно дозвониться до сотрудников контакт-центра и решить вопросы. Организация 8-800 оперативно была выполнена «Билайном».
Одной из наиболее сложных для меня задач было спрогнозировать, как перераспределятся звонки клиентов между филиалами компании и ЦО после запуска централизованного режима работы «костюмеров», чтобы корректно сверстать бюджет на следующий год. Я потратил немало времени, анализируя статистику потребления телефонного трафика, однако вынужден признать, что значительно ошибся с прогнозом, неверно предположив, что значительная доля звонков из филиалов перейдет в ЦО. По факту оказалось, что клиенты крайне инерционны и пока неактивно используют 8-800. Не исключено, что расходы будут возрастать по мере привыкания клиентов обращаться в ЦО для решения вопросов вместо коммуникаций со своим менеджером по продажам.
Помимо решения вопроса обеспечения комфортности для клиентов, для меня остро стоял вопрос не допустить значительного увеличения расходов на фиксированную и мобильную связь между продавцами в филиалах и CS. Увеличение расходов было неминуемым при традиционной схеме организации коммуникаций из-за кардинального изменения их структуры, поскольку количество междугородных звонков стало бы значительно преобладающим.
Для сокращения расходов решено было воспользоваться конвергентными услугами связи. Поскольку наибольшее количество междугородных звонков прогнозировалось между мобильными продавцов и фиксированными телефонами сотрудников контакт-центра, я остановился на схеме реализации конвергентных услуг по схеме FMTN вместо FMC. В приволжском федеральном округе мы стали второй компанией, кто воспользовался конвергентной услугой (FMTN) от «Билайн-бизнес». Этот сервис позволил нам объединить в единую технологическую сеть наши мобильные и фиксированные номера не только в рамках региона, но и по всей территории РФ, где присутствуют наши филиалы. После полугода использования FMTN, могу отметить, пожалуй, один недостаток: периодические «глюки» с биллингом по FMTN. Видать, штука сложна в реализации и пока слабо отлажена. Из-за этого ежемесячно приходится тратить время на перепроверку корректности расчетов стоимости услуг.
Основная цель запуска конвергентных услуг была достигнута: несмотря на значительное возрастание междугородних коммуникаций между CS и продавцами, затраты на мобильную телефонию подросли незначительно, по большей части из-за параллельного открытия двух десятков хоум-офисов от Хабаровска до Калининграда. Побочным эффектом от внедрения FMTN стало упрощение коммуникаций между сотрудниками компании благодаря короткому номеру и проч.
Конвергентные услуги вполне можно рассматривать как современную замену традиционной DECT-телефонии. С одной стороны, капитальные затраты на организацию DECT трансформируются в операционные (абонентская плата за использование сервиса и в некоторых случаях повременные расходы), с другой — повышается комфорт использования связи сотрудниками, поскольку не нужно таскать с собой помимо мобильника еще и DECT-трубку. Сотрудники ЦО при желании могут вообще обходится без офисного телефона, установив перевод звонка на мобильный.
При реализации проекта не оставили без внимания и вопрос безопасности коммуникаций между «половинками» — коммерсантами и CS. Поскольку предполагается, что некоторые запросы «костюмерам» поступают от коммерсантов в устной форме, была реализована процедура аутентификации, в которой помимо номера мобильного участвует и специально сгенерированный код, рассылаемый продавцам ежедневно.
Finite la comedia
Большинство упомянутых сервисов и сам контакт-центр были запущены в эксплуатацию в срок чуть более месяца и успешно работают. Теперь немного о грустном.
После реализации первого этапа нам нужно было «перекроить» существующие и внедрить новые системы для формализации бизнес-процессов обработки документов. Идеализированное требование обработки документов по «револьверому» принципу сыграло злую шутку. Обработка договоров перекраивалось из типовой конфигурации DocsVision «Согласование договоров» и заняло (силами подрядчика) более двух месяцев из-за нетрадиционного использования типового решения. Написано типовое решение не особо «эстетично», поэтому разбираться с ним непросто. При работе с механизмом Workflow понимаешь, что в случае сложных бизнес-процессов читабельность логики получается невысокой, пожалуй, не лучше, чем в случае красиво написанного объектного программного кода. Обилие скриптовых вставок в Workflow осложняет понимание и без того непростой бизнес-логики (месиво из квадратиков — просто взрыв мозга).
Адаптация информационной системы была практически завершена, когда неожиданно поступило указание от бизнеса свернуть реализацию «револьверного» принципа. Причины были достаточно просты. Количество изменений в компании оказалось столь велико и реализованы они были в столь короткие сроки (торопились к сезону продаж), что персонал не смог освоится с новшествами. Кроме того, накладные расходы на поддержание «револьверного» принципа оказались слишком значительными. CS-никам нужно было постоянно фиксировать, причем, максимально детально, контекст общения с продавцами и клиентами, чтобы при смене специалиста последователь мог продолжить общение, глупо не переспрашивая всю историю общения, как часто происходит при звонках в контакт-центры даже именитых компаний. Обеспечить такие гладкие коммуникации очень и очень непросто, если вообще возможно для нашего бизнеса.
При реализации «револьверной» схемы у меня были определенные сомнения, смогут ли «костюмеры» осилить работу в таком режиме. Идеологом централизации выступал один из очень компетентных топ-менеджеров компании, пожалуй, самый профессиональный в своей области, с кем довелось работать. Вероятно, его авторитет и напористость несколько притупила сформировавшуюся годами осторожность. Да и не скрою, сама попытка реализации подобной амбициозной бизнес-задачи была крайне интересна для меня. Откат от «револьверого» принципа оказался для участников проекта весьма болезненным.
Во-первых, реализация системы, как с айтишной, так и с организационной стороны фактически была завершена, что само по себе было достижением. Для нас остановка проекта на подлете к цели выглядела, как если бы пойти покупать ребенку игрушку, о которой он давно и страстно мечтал, и резко «обломить» его на кассе. Подобных разочарований у меня было несколько, но это — одно из самых болезненных. После мне потребовалось немало времени, чтобы собраться и приступить к реализации проекта по «деревольверизации».
Во-вторых, при постановке ТЗ подрядчику, дорабатывающему типовое решение DocsVision, оговаривались сроки именно на реализацию «револьверной» схемы. Про типовой вариант, пусть более простой, но которым все равно надо было заниматься, так как типовое решение удовлетворяло нас далеко не на 100%, разговора не было. Соответственно, мне нужно было кардинально корректировать ТЗ, да и людские ресурсы подрядчика уже были распланированы для переброса на другой проект. Естественно, столь кардинальное изменение привело к незапланированным расходам и к существенному увеличению сроков на переработку. В результате окончание проекта по автоматизации документооборота пришлось на момент, когда запускать его было небезопасно, поскольку уже начался сезон продаж, во время которого вносить существенные изменения в бизнес-логику работы бэк-офиса, мягко говоря, нежелательно.
Все же, несмотря на отказ от наиболее сложного и красивого элемента проекта, пожалуй, его можно считать удавшимся. Практически с нулевым бюджетом (используя имеющуюся инфраструктуру) за очень короткий срок было разработано вполне себе стабильно работающее решение. В очередной раз получили подтверждение, что OpenSource иногда предоставляет очень неплохие возможности для решения весьма сложных задач. Для себя же в очередной раз утвердился в мысли, что к оценке возможностей пользователей системы нужно подходить максимально тщательно на этапе «закладки» ТЗ.
Опубликовано 15.08.2011