Обзор информационной системы CRM Telecom 360

Мы рассматривали CRM Telecom 360 как отраслевую информационную систему для операторов связи, интернет-провайдеров и телеком-компаний. Основной вопрос обзора был практическим: насколько полно решение закрывает повседневные процессы — от ведения клиента и продажи услуги до подключения, учета сетевых ресурсов, договорной работы и обработки обращений в Helpdesk.

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

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

На старте обычно требуется определить организационную структуру, функциональные роли, набор справочников, стадии процессов, права доступа, состав интеграций и начальные данные. Для телеком-компании отдельно уточняются правила создания контрагентов, ОКН, услуг клиентов, сетевых ресурсов, ТМЦ, заявок и Trouble Ticket.

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

• Реестры: состав колонок, порядок, сортировка, быстрые и расширенные фильтры, итоги и сохраненные представления.

• Карточки: поля, вкладки, детали, обязательность заполнения, условия показа и доступность действий.

• Процессы: стадии, задачи, ответственные роли, сроки, результаты, эскалации и автоматические переходы.

• Аналитика: графики, показатели, план-факт, фильтры и состав рабочих столов.

• Безопасность: пользователи, организационные и функциональные роли, доступ к записям и операциям.

• Интеграции: учетные данные, веб-сервисы, webhooks, расписания и правила синхронизации.

Интерфейс CRM Telecom 360 разделен на рабочие места по функциям подразделений. Мы увидели отдельные наборы разделов для продаж, инженеров, Helpdesk, руководства и управления проектами. Одни и те же данные используются в разных рабочих местах, но каждый сотрудник видит только релевантные разделы и операции.

Рабочее место «Продажи Телеком» объединяет контрагентов, контакты, продажи, заявки, активности, договоры, каталог продуктов, ОКН и услуги клиентов. Инженерный контур включает заявки, Trouble Ticket, ресурсы и ТМЦ. Helpdesk работает с обращениями, клиентскими данными, объектами и услугами. Руководство получает итоги, планирование и сводные реестры. Управление проектами использует заявки, активности, объекты, ресурсы и материалы.

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

Система закрывает работу с юридическими лицами и государственными организациями, но модель не ограничивается корпоративным сегментом. CRM Telecom 360 может использоваться и для процессов с физическими лицами. Для B2C-клиента карточка содержит сведения, характерные для абонента-физического лица: персональные и паспортные данные, адрес и средства связи. Для юридического лица используются реквизиты организации, ИНН, КПП, отрасль, ОКВЭД, численность, ответственные контакты и договорные связи. Таким образом, B2B, B2G и B2C ведутся в одной системе, но с различающимся составом данных.

Карточка содержит тип, класс и статус контрагента. Тип определяет роль организации относительно телеком-компании: контрагент, оператор, поставщик, партнер, подрядчик или собственная компания. Класс разделяет клиентскую базу на B2B, B2G и B2C. Статус отражает фактические отношения: потенциальный клиент, активный клиент, блокировка или бывший клиент. Такая классификация используется в фильтрах, аналитике и процессах, а также помогает отличать коммерческую перспективу от реально подключенного абонента.

В карточке объединяются контакты, адреса, договоры, продажи, заявки, услуги, ОКН, Trouble Ticket, активности, файлы и история изменений. Мы считаем это важной особенностью: сотрудник продаж, Helpdesk или проектного подразделения работает с одной клиентской записью, но видит контекст своего процесса. Финансовая вкладка может показывать абонентские платежи, доход, затраты и задолженность, если эти данные поступают из биллинга или учетной системы.
Отдельный раздел «Контакты» хранит физических лиц и сотрудников организаций. Для контакта указываются ФИО, должность, подразделение, телефоны, электронная почта, основной контрагент и история взаимодействия. Один контакт может участвовать в продаже, согласовании, заявке или обращении. В карточках доступны звонки, письма, задачи, сообщения ленты и связанные каналы коммуникации.

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

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

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

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

В левой панели [1] фиксируются поля для постоянного отражения. Их набор настраивается под каждую компанию.

Все активные задачи отражаются также и в самой карточке контрагента. В части окна с активными задачами [2] и в списке связанных с контрагентом активностей любого типа (задача, звонок, e-mail, встреча)

Панель вкладок [3] и важно, что и логика показа её в зависимости о значений в полях контрагента и иных сущностях, настраивается через визуальный конструктор бизнес-правил.

На страницах вкладок [4] уже размещена информация по смысловым связкам.

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

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

Мы рассматриваем карточку продажи как рабочую область менеджера. Она содержит не только итоговую сумму, но и все данные, необходимые для передачи сделки в технический контур. Вкладка «Услуги в продаже» используется для выбора продуктов из каталога и формирования конкретного предложения: наименование услуги для коммерческого предложения, количество, разовый и ежемесячный платеж, НДС, параметры подключения и статьи затрат.

Стадии не являются простыми метками воронки. На переходах запускаются проверки, меняются права, создаются заявки и фиксируются даты.

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

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

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

Результат задачи влияет на маршрут. Положительное завершение позволяет продолжить процесс, а запрос информации, перенос или эскалация формируют альтернативный сценарий. Такой механизм делает контроль воспроизводимым: последовательность действий определяется не только памятью менеджера, но и настройками процесса.

Ключевая особенность продаж — связь с услугами клиентов. На этапе предложения менеджер работает с «Услугами в продаже»: это будущие услуги, выбранные из каталога и дополненные коммерческими параметрами. После согласования и запуска включения система создает или обновляет записи в разделе «Услуги клиентов». Они уже отражают фактически предоставляемые услуги и связаны с контрагентом, ОКН, заявкой, ресурсами и ТМЦ.

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

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

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

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

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

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

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

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

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

Для заявки указываются контрагент, контакт, ответственный менеджер, проектный менеджер, ОКН, связанная продажа или услуга, обрабатываемые услуги, сроки, комментарии и техническое задание. Карточка содержит ленту, файлы, активности, историю и хронологию. Состав полей меняется в зависимости от вида заявки: для блокировки важно необходимое действие и перечень услуг, для обследования — требования и расчет затрат, для ВОЛС — параметры строительства и точки подключения.

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

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

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

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

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

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

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

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

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

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

Заявка связывается с конкретными услугами клиента и ОКН. Проектный менеджер определяет состав работ, инженеры выполняют отключение и демонтаж, а система контролирует задачи и результаты. На завершении проставляется дата отключения услуги, ресурсы получают статус «Расформирован», а ТМЦ меняют местонахождение или состояние в соответствии с фактическим результатом.

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

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

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

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

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

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

Права на заявку и обрабатываемые услуги меняются по стадиям. Во время уточнения менеджеру открывается возможность корректировки. После начала технических работ редактирование ограничивается, чтобы сохранить согласованный объем. Финальные состояния блокируют изменения и фиксируют даты закрытия. Это снижает риск незаметного изменения требований после передачи в исполнение.
Связи заявок обеспечивают сквозную трассировку. Из заявки можно перейти к контрагенту, контакту, продаже, ОКН, услугам, ресурсам, ТМЦ и активностям. После выполнения включения результат отражается в услугах клиентов. После блокировки меняется состояние услуги. После расформирования обновляются услуга, ресурсы и материальные ценности. При ВОЛС изменяется технический контекст объекта.

Внешние системы участвуют в процессе через интеграции. Биллинг может получить команду или данные об изменении услуги, 1С — сведения для учета, OSS — технические параметры, а почтовые и коммуникационные сервисы — уведомления. Конкретный набор обменов не является одинаковым для всех операторов и проектируется отдельно.

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

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

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

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

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

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

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

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

Для крупных B2B-подключений применяется полный маршрут с обследованием, коммерческим расчетом и проектным управлением. Для стандартного B2C-подключения маршрут может быть сокращен до проверки доступности, назначения технической задачи и активации услуги. Low-code механизмы позволяют использовать общую модель заявок, но различать обязательные поля, стадии и задачи по типу клиента, продукту, технологии или стоимости проекта.

Активности — единый механизм задач, встреч, звонков и письменных работ. Они создаются вручную, из карточки объекта или автоматически из бизнес-процесса и кейса. Для активности указываются название, начало, плановое завершение, категория, состояние, результат, приоритет, роль, ответственный, автор, участники и напоминания.

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

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

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

Активности обеспечивают ежедневный контроль продаж, заявок и обращений. Просрочка видна по плановой дате, а результат становится условием продолжения процесса. Для руководителя это дает более объективную картину, чем простое сравнение стадий: можно оценить количество задач, сроки выполнения, возвраты и эскалации.

Активность связывается с контрагентом, контактом, продажей, заявкой, договором, ОКН или Trouble Ticket. Поэтому одна и та же задача видна и в общем календаре, и в карточке бизнес-объекта. Участники получают уведомления по обсуждению, а подписка на ленту позволяет следить за изменениями без назначения ответственным.

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

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

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

Жизненный цикл включает «Черновик», «На согласовании» и «Действующий», а также финальные варианты «Отменен» и «Расторгнут». В черновике заполняются реквизиты и готовится документ. На согласовании контролируется прохождение ответственных участников. После подписания договор переводится в действующий. Отмена применяется до вступления в силу, расторжение — после начала действия.

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

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

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

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

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

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

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

Типы продуктов включают «Другое», «Интернет», «Каналы», «Мобильная связь» и «Телефония». Внутри используются подтипы: для интернета — BGP, L2-канал, Lan-to-Lan, Wi-Fi, доступ в Интернет и спутниковый канал; для каналов — E1, E3 и ETH; для мобильной связи — базовые, безлимитные и IoT; для телефонии — SIP, ВАТС и телефония через E1; для других продуктов — ВОЛС, оборудование и телевидение.

Продукт отвечает на вопрос, что компания предлагает рынку. Услуга клиента отвечает на вопрос, что фактически подключено конкретному клиенту на конкретном ОКН. Один продукт может стать основой множества услуг клиентов с разными параметрами, ценами, ресурсами и состояниями.

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

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

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

Для продукта могут быть определены обязательные параметры подключения и набор допустимых ресурсов. Например, интернет-услуга может требовать скорость и тип доступа, ВАТС — платформу и номерную емкость, канал — точки и транспорт. Конкретная модель зависит от настройки каталога и технических справочников.

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

ОКН — объект коммерческой недвижимости или другой объект подключения, на котором оказываются либо планируются услуги. Карточка объединяет адрес, координаты, вид объекта, технические и коммерческие параметры, ответственных сотрудников, продажи, заявки, услуги, ресурсы и Trouble Ticket.

Виды объектов включают ЖК, классы А, Б и С, многофункциональные комплексы, торговые центры и ЦОД. Состояние отражает техническую ситуацию: потенциальный объект, подключение по ВОЛС, включение по радиоканалу, арендованные канал или ВОЛС, строительство, расформирование и другие варианты.

Для объекта указываются менеджер продаж, менеджер развития и проектный менеджер. Коммерческая часть может содержать площадь, проникновение услуг и потенциал. Техническая часть — точки подключения, контакты, существующие ресурсы и история работ. Мастер-объект позволяет объединять связанные здания или площадки в структуру.

ОКН используется в продаже, обследовании, заявке, услуге клиента и Trouble Ticket. Благодаря этому инженер видит, где физически предоставляется услуга, а менеджер — какие возможности и ограничения связаны с объектом.

Интеграция с DaData может использоваться для нормализации адресов и координат. При внедрении требуется определить правила создания объектов и устранения дублей: один и тот же адрес не должен появляться в нескольких вариантах написания. Если в компании есть GIS или специализированная система объектов, роли мастер-систем согласуются отдельно.

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

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

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

Раздел «Услуги клиентов» хранит фактически предоставляемые услуги. В карточке указываются продукт, состояние, контрагент, заявка-основание, ОКН, даты активации и отключения, финансовые параметры, ресурсы и связанное оборудование. Услуга создается после согласования продажи и выполнения заявки либо загружается из биллинга при миграции.

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

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

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

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

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

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

Для сопровождения услуга используется как отправная точка. Из карточки видны открытые Trouble Ticket, последние изменения, ответственные подразделения и технические ресурсы. Это сокращает время поиска информации при обращении клиента.

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

Новый тикет ожидает обработки. После перехода «В работе» устанавливается первая линия поддержки. Если нужна техническая работа, тикет передается инженерам, уровень поддержки меняется, а система создает задачу с описанием требуемых действий. После выполнения инженерной задачи тикет возвращается первой линии в состоянии «Отработан инженерами».

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

SLA используется для контроля реакции и решения. Эскалации могут последовательно привлекать персонального менеджера, руководителя технической поддержки, директора по сервису, директора по эксплуатации сети и генерального директора. Конкретная схема зависит от приоритета, клиента и регламентов.

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

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

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

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

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

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

Раздел «Учет ресурсов» ведет технические и логические ресурсы, используемые при предоставлении услуг. Ресурс создается в контексте услуги клиента. После выбора услуги система автоматически определяет контрагента и ОКН. Благодаря этому связь строится последовательно: ресурс — услуга — ОКН и контрагент. Через услугу и объект ресурс далее связан с продажами, заявками, Trouble Ticket и ТМЦ.

В общей части карточки указываются уникальный идентификатор, статус, признак аренды, родительский ресурс, даты создания и расформирования и примечания. Родительская связь позволяет строить иерархии, например связать порт с оборудованием или канал с транспортным ресурсом. Состояния включают «Включение», «Активный», «Блокировка» и «Расформирован».

В системе используется справочник типов ресурсов. Для каждого типа отображается собственный набор вкладок и полей. Это позволяет не смешивать параметры BGP, ВАТС, волокна, мобильной связи и оборудования в одной универсальной карточке. Список типов расширяем: аналитик может добавить новый тип, поля, вкладки, правила и процессы средствами платформы.

Справочник CRM Telecom 360 также содержит типы ETH, мобильная связь, оборудование, ВАТС, телефония, E3, волокно, канал L2, телевидение, E1, BGP, порт доступа, Lan-to-Lan, канал L3 и СКС. Для части типов применяется общая специализированная форма, например E1/E3/ETH или L2/L3.

Привязка к услуге является обязательной. Из ресурса автоматически определяется клиент и объект. В Trouble Ticket можно понять, какие технические параметры относятся к проблемной услуге. В заявке на изменение или расформирование видно, какие ресурсы должны быть добавлены, изменены или освобождены. ТМЦ связывается с ресурсом или объектом, если техническая реализация включает физическое оборудование.

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

Раздел подходит для прикладного учета ресурсов, используемых CRM-процессами. Для полной топологии, автоматической инвентаризации сети, мониторинга и управления конфигурациями может потребоваться OSS/NMS. В этом случае CRM Telecom 360 хранит клиентские связи и необходимые параметры, а специализированная система остается мастер-источником сетевой модели.

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

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

Родительские связи позволяют описывать составные конфигурации. Например, услуга использует канал, канал проходит через порты и оборудование, а оборудование соответствует ТМЦ. Полная глубина иерархии определяется задачами оператора: Product Book фиксирует возможность, но не задает единственную модель технического учета.

Раздел «Учет ТМЦ» хранит оборудование, материалы, комплектующие и приборы, используемые при подключении и эксплуатации услуг. В карточке фиксируются название, тип, номенклатура, статус, серийные и инвентарные признаки, склад или местонахождение, ответственный и связь с оборудованием, объектом или клиентом.

Типы включают оборудование, аксессуары, кабель, приборы и электронику. В номенклатуре могут использоваться DSL-модемы, SFP-модули, аналоговые и цифровые АТС, коммутаторы, маршрутизаторы, платы расширения и точки доступа Wi-Fi. Справочник расширяется по мере появления нового оборудования.

Статус показывает, находится ли ТМЦ на складе, ожидает поставки, выдана сотруднику, установлена на узле, находится у клиента или списана. При складском состоянии указывается номер склада. Признак «В комплекте с оборудованием» позволяет учитывать компонент как часть более крупной единицы.

ТМЦ участвуют в заявках на включение, изменение, ВОЛС и расформирование. При выдаче оборудование закрепляется за сотрудником или работой, после монтажа — за объектом, услугой или ресурсом. При расформировании оно возвращается, перемещается или списывается. История обеспечивает трассировку фактического движения.

CRM Telecom 360 закрывает операционный учет в контексте клиента и работ. Финансовый складской учет, партии, себестоимость, бухгалтерские проводки и регламентированная отчетность остаются в 1С или ERP. Интеграция должна согласовать номенклатуру, идентификаторы, остатки и события движения.

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

При замене оборудования старая ТМЦ переводится в состояние возврата, склада, ремонта или списания в зависимости от настроенного справочника, а новая закрепляется за услугой. История обеспечивает понимание, какое устройство использовалось в каждый период.

Для комплектов оборудования используется связь «В комплекте с оборудованием». Она помогает учитывать блок питания, модуль, плату или аксессуар вместе с основным устройством, не теряя отдельную номенклатурную запись.

Аналитика CRM Telecom 360 строится на операционных данных системы и объединяет коммерческий, технический, сервисный и управленческий контуры. Изменение продажи, заявки, активности, услуги или Trouble Ticket отражается в показателях без подготовки отдельной копии данных. Мы рассматриваем этот подход как важное преимущество: руководитель и исполнитель работают с одной информационной основой и могут перейти от сводной картины к конкретной записи.

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

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

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

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

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

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

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

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

Состав мобильного приложения настраивается no-code средствами в основном приложении BPMSoft. В мастере мобильного приложения определяются рабочие места, доступные разделы и детали, вид реестров, страницы записей и набор полей. Права доступа продолжают действовать и в мобильном клиенте, поэтому пользователь видит только разрешенные объекты и данные.

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

После такой настройки мобильное приложение может использоваться для работы с активностями, заявками, обследованиями, объектами недвижимости, услугами клиентов, Trouble Ticket, ресурсами и ТМЦ. Конкретный состав мобильных сценариев CRM Telecom 360 следует подтверждать на проекте внедрения: наличие платформенного приложения не означает, что все отраслевые разделы автоматически готовы для работы на смартфоне без адаптации.

CRM Telecom 360 занимает центральное место между клиентскими процессами и корпоративными системами. BPMSoft предоставляет открытый API и несколько способов обмена: внешнее приложение может читать и изменять данные CRM, запускать процессы, а CRM может вызывать внешние сервисы и обрабатывать ответы внутри бизнес-процесса.

Для запуска бизнес-процессов из внешнего приложения используется системный веб-сервис ProcessEngineService. Для работы с данными доступны OData версии 3 и 4 и сервис DataService. OData предоставляет адресуемые ресурсы и стандартные HTTP-операции, а DataService поддерживает создание, чтение, обновление и удаление данных, фильтры, встроенные макросы и пакетные запросы.

Для специфических задач можно создавать пользовательские RESTful веб-сервисы. Вебхуки дают low-code механизм реагирования на события без разработки отдельного интеграционного приложения. Внешние запросы должны быть аутентифицированы; документация описывает Forms-аутентификацию и работу через Identity-провайдеры по OIDC.

В конструкторе BPMSoft настраивается описание REST или SOAP веб-сервиса. Элемент процесса «Вызвать веб-сервис» отправляет запрос, получает ответ и использует данные для создания или изменения записей и дальнейшей маршрутизации. Для сложных объектов с большим числом параметров или вызовов непосредственно из пользовательского интерфейса может потребоваться программная реализация.

Документация BPMSoft перечисляет готовые механизмы единого входа и управления пользователями: OneLogin, ADFS, Just-In-Time User Provisioning и LDAP. Для коммуникаций предусмотрены IMAP/SMTP, MS Exchange и Microsoft 365. Среди готовых интеграций телефонии указаны Asterisk, Infinity, UIS и WebRTC.

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

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

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

Для OSS/NMS возможен обмен техническими параметрами, ресурсами и состояниями. CRM Telecom 360 при этом сохраняет клиентский контекст, а специализированная система может оставаться мастер-источником сетевой топологии. Госуслуги и Seldon в обзор не включены, поскольку такие интеграции не подтверждены для рассматриваемой конфигурации.

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

Функциональная конфигурация сохраняется при разных вариантах размещения, но условия сопровождения, резервирования, обновления, интеграций и информационной безопасности определяются договором и проектом внедрения. Отдельно проверяются требования 152-ФЗ, схема доступа к внутренним системам и допустимость размещения персональных данных.

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

Вертикальное решение CRM Telecom 360 рассматривается как основная лицензия. В дополнении к ней возможно установить и иные решения из магазина приложений BPMSoft.

Стоимость зависит от типа размещения платформы, количества пользователей, аренды/выкупа.
Лицензия CRM Telecom 360 включает весь функционал платформы BPMSoft, а значит возможно развитие функционала без ограничений.

В стоимость лицензия входит:

• Функционал вертикального решения CRM Telecom 360
• Функционал платформы BPMSoft
• Техническая поддержка функционала платформы от вендора BPMSoft
• Техническая поддержка функционала CRM Telecom от интегратора Умные новации
• Обновления платформы BPMSoft и CRM Telecom 360, включая новый функционал

Основные плюсы:

• Готовая отраслевая модель для телеком-операторов: ОКН, услуги клиентов, заявки для ключевых бизнес-процессов, сетевые ресурсы, ТМЦ и Обращения (Trouble Ticket) уже присутствуют в конфигурации.

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

• Единая среда для B2B, B2G и B2C без разрыва между коммерческими и техническими подразделениями.

• Low-code инструменты позволяют аналитикам изменять карточки, правила, кейсы, процессы и аналитику, исключить или минимизировать привлечение программистов, что существенно снижает стоимость владения системой (TCO).

• Ролевые рабочие места для продаж, инженеров, Helpdesk, руководства и управления проектами уже готовы и их можно менять легко.

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

• По сравнению с универсальной CRM требуется на 2 порядка меньше настроек под отралсь на старте.

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

В независимом исследовании российских low-code-платформ 2025 и 2026 года BPMSoft заняла первое место по итогам экспертной оценки Сколково и TAdviser.

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

Первичная оценка BPMSoft составила 82 балла из 100 за функциональность, 86 баллов за технологическую зрелость и 79 баллов за организационный потенциал. Средний результат 82% стал вторым среди 30 российских платформ, участвовавших в исследовании.

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

Телеком прямо указан в исследовании среди отраслей специализации BPMSoft. Это соответствует назначению CRM Telecom 360 и снижает риск выбора технологической основы, не рассчитанной на специфику операторского бизнеса.

Основыне минусы:

• Запуск требует проекта внедрения для средних и крупных операторов.

• Биллинг, OSS, телефония и часть корпоративных систем требуют проектной интеграции.

• Гибкость low-code повышает требования к управлению изменениями и компетенциям внутренней команды сопровождения.

• Учет ресурсов и ТМЦ не заменяет специализированные OSS/NMS, ERP, используемые в крупных операторах связи.

• Учет договоров реализован и встроен в бизнес-процессы, но далеко не охватывает весь функционал систем ЭДО. Требуется приобретение дополнительно конфигурации Документооборот.

• Публичная тарифная сетка не просматривается как простой прайс; стоимость рассчитывается по модели лицензий.

• Для небольшого оператора с простыми процессами полный состав конфигурации может быть избыточным.

После разбора материалов мы считаем CRM Telecom 360 комплексной отраслевой конфигурацией, а не набором разрозненных CRM-разделов. Решение покрывает клиентскую базу, продажи, обследования, подключения и изменения услуг, договорную работу, объекты подключения, услуги клиентов, сетевые ресурсы, ТМЦ, Helpdesk и управленческую аналитику.

Наиболее убедительно система выглядит для телеком-компании, которой нужна единая операционная среда поверх биллинга, 1С и технических систем. CRM Telecom 360 координирует работу подразделений и хранит сквозной контекст клиента, услуги и объекта. При этом она не отменяет специализированные системы и не исключает проектную настройку интеграций.

Для первичного отбора мы бы включили CRM Telecom 360 в короткий список, если критичны отраслевые процессы, low-code развитие и единая модель коммерческого и технического учета. Следующим этапом оценки должна стать демонстрация на собственном сценарии: продажа — обследование — заявка — подключение — услуга — Trouble Ticket, а также проверка интеграции с действующим биллингом и правил лицензирования.



Хотите увидеть обзор какого-то конкретного сервиса? Напишите нам: soft@softadvisor.ru