У нас в компании есть решение для автоматизации операторской деятельности (предоставление широкополосного доступа в Интернет), которое мы называем CRM. Чуточку о том, что у нас работает, и ещё больше о том, что должно быть, написано здесь.

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

Вкратце перечислю, на какие бизнес-процессы ориентирована эта несуществующая система:

  1. Подключение абонентов
  2. Управление инцидентами
  3. Сервисное обслуживание абонентов
  4. Обработка жалоб и перерасчёт

Какие заложены особенности:

  1. Учитывается возможность работы нескольких операторов связи в рамках холдинга, возможность работы с территориальными подрядчиками, возможность работы по агентской схеме. В этой связи, заложена система территориальных прав и разграничения прав по операторам.
  2. Для управления объемами подключений и загрузкой монтажных бригад заложено квотирование заявок. Так же, заложено территориальное управление днями обслуживания.
  3. Уделено внимание максимальному упрощению работы со стороны операторов ЦОВ и сотрудников клиентских служб — описаны требования по автоматическому выбору групп исполнителей, дат, по отображению доступных дат в календаре. То есть, в функциональных требованиях учтено, что обычно требуется персоналу в точке контакта с клиентом, соответствующий дизайн заложен в структуры данных.
  4. Учтены требования по возможному контролю исполнителей. Предлагается исключить возможность изменения первичных данных, отслеживать движения заявок и запас по сроку на каждом переходе, уведомлять контролирующих лиц.
  5. Учтены некоторые технические моменты, касающиеся использования базы данных, индексирования, расширения заявок на основе XML конфигурации.

Что просится в качестве дальнейшего развития идей:

  1. Маршрутизация заявок вместо групп по-умолчанию — заранее определенная последовательность, например, для маршрута перерасчета: ИТ-> Бухгалтерия -> ЦОВ.
  2. Группировка заявок в кейсы. Кейсы должны быть легкие - только для связывания заявок в один случай. Например, если подключение и жалоба связаны между собой.
  3. Возможность субквотирования (разделения квоты) по группам домов и по типам заявок. В нашей текущей практике, это действительно запрашиваемая возможность.
  4. Возможность квотирования с повышенным/пониженным коэффициентом для отдельных территорий

Сам документ — Функциональные требования и дизайн системы заявок оператора ШПД.