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

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

Всё это ради того, чтоб сотрудник абонентской службы, оформляя заявку на абонента, ни о чем не думал: ни о выборе правильного исполнителя, ни о времени явки инженера, ни о наличии услуги в данном доме. Об этом за него думает система. Это не CRM в классическом понимании и не ServiceDesk в понимании ITIL. Это полностью кастомное решение.

Далее, я хотел бы описать некоторые свои взгляды на подобные решения.

Почему не подходит Service Desk?

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

Во-вторых, в телекоме заявки квотируются. В исполнение берется ограниченное количество подключений или перепротяжек (замена кабеля по стояку) на интервал времени на группу исполнителей. Для разных групп разные интервалы времени. Тут много нюансов.

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

Что должно быть в системе автоматизации оператора связи?

Объединение абонентских баз

Основная сила системы это централизация всех абонентских баз и унификация обслуживания в одном продукте.

Представьте себе такие сценарии:

1. Мы приобретаем другого оператора и переносим обслуживание абонентов на свою платформу. Всё это должно произойти быстро, не дожидаясь миграции биллинга (всё-таки биллинг не быстро-заменим).
2. Мы как группа компаний используем несколько биллингов для разных услуг.

Именно для этих сценариев должен быть такой особый телекомовский CRM, который реализует все сценарии обслуживания, не привязан жестко к биллингу или мониторингу, нуждается только в загрузке данных.

Два уровня рабочих элементов

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

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

Нужно минимум два уровня — подключение и заявка по нему или инцидент и заявка по нему.

Управление процессами

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

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

Подход BPM завязывает запуски таких ситуационных процессов на тех, кто настраивает процессы в BPMS. В (нашей) CRM люди просто ищут данные и организуют работу. Ad-Hoc.

Два уровня назначения

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

Эти назначения происходят в разные моменты времени. И до дня выполнения не важно, кто именно пойдёт делать заявку, но важно правильно определить верхнее назначение, чтобы зарезервировать ресурсы группы исполнителей.

Специфичное разграничение прав

Должно быть несколько разрезов для разграничения полномочий на изменения в заявках:

1. В зависимости от состояния заявки.
2. В зависимости от роли в данной заявке (динамическая роль).
3. В зависимости от типа заявки.

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

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

Нужен запрет на изменение данных в просроченных заявках, чтоб нельзя было "незаметно" переназначить заявку на другую группу или изменить данные, используемые в рассчёте KPI.

Прочие требования

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

Я вижу огромную разницу в уровне технической подготовки саппорта, когда их 10 человек и когда это контакт центр на 70 и более мест с несколькими линиями поддержки, и убежден, что без скриптов разговоров и скриптов диагностики операторы первой линии работать не могут. Это идеально, если такие скрипты реализованы в той же CRM системе. Разумеется должна быть CTI (Computer Telephone Integration).

Желательно решение с веб-клиентом.

Должна быть недорогая лицензия, хотя бы для исполнителей заявок.

И ещё интеграция со службой каталогов (Active Directory) - т.к. 90% офиса всё ещё Windows пользователи.

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

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

Какие решения смотреть?

Это самый сложный вопрос. Пока мы внедряли Terrasoft CRM, масштаб изменился и нам его уже недостаточно. Мы получили максимум 50% из того, что я перечислил выше, хотя другие подразделения группы компаний (West Call), куда мы вступили, ездят к нам и считают, что мы много сделали.

Путь первый — собственная конфигурация на неспециализированном ПО:

1. Большинство задач решается в ELMA-BPM. Минусы есть, но соотношение цена / качество близко к идеальному.
2. Часть задач (меньше чем в ELMA) решается в BPMonline. Но лицензии дороги.
3. Siebel CRM. Говорят (давно) была неплохая практика внедрения в телекомах. Но лицензии супер-дороги.
4. Remedy мертв. Дорогой и мёртвый.
5. HP SD — не то.
6. OMNI tracker — не то.

Путь второй — ПО, ориентированное на отрасль.

1. Можно попробовать Naumen. Оно будет хуже как конструктор и хуже с принципиальных точек зрения, зато готово к работе.
2. BGCRM. Писалось для операторов. Стоит попробовать.
3. Продукты партнёров Tele-Management Forum (www.tmforum.org) трудно поддаются изучению, так же как рекомендации МСЭ и eTOM. Ещё труднее найти адекватных интеграторов. Поверьте, я изучил эти рекомендации.

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