Onyma xRM. Основные возможности платформы

Onyma xRM представляет собой абсолютно новую программную платформу, представленную на рынок компанией Stack Soft в 2012 г.

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

Основными архитектурными особенностями новой платформы являются:

1. Полностью открытая архитектура.

2. Ролевая система разделения полномочий.

3. Система допусков и грифов.

4. Беспрецедентный уровень диагностики.

5. Встроенная мультиязычность.

6. Развитый, настраиваемый веб-интерфейс.

Под полностью открытой архитектурой подразумевается подход, представленный на рисунке:

Для обращения к ядру системы создан развитый прикладной программный интерфейс (API), с использованием которого осуществляется взаимодействие базы данных ядра и внешних систем предприятия.

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

Платформа Onyma xRM обладает развитыми интеграционными возможностями на основе полностью открытой архитектуры, наличия пользовательского API внутри системы, интеграционных представлений (view) и развитых интеграционных методов.

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

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

Основным предназначением платформы Onyma xRM является разработка информационных систем класса OSS/BSS, интегрированных с различными внешними системами Заказчика с целью создания и эффективного использования единой структурированной базы данных объектов обслуживания.

Onyma CRM для оператора связи

Первым продуктом на базе платформы Onyma xRM является Система управления взаимоотношениями с клиентами — Onyma CRM для оператора связи и/или провайдера телекоммуникационных услуг.

Продукт ориентирован на обеспечение полноценной поддержки процессов продаж и обслуживания внутри компании и организацию тесного взаимодействия с клиентами по всем возможным каналам, включая каналы самообслуживания (Web личный кабинет, CTI).

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

Основными функциями Onyma CRM являются:

1. Создание и ведение каталога продуктов (маркетинговая энциклопедия), конфигуратор продуктов;

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

3. Конфигурирование, запуск и выполнение процессов обработки заявок через все каналы работы с клиентами;

4. Управление маркетинговыми кампаниями, управление потенциальными сделками. Конфигурация процессов управления продажами. В том числе: анализ «воронки продаж»: прогнозирование, анализ цикла продаж, региональный анализ, запланированная и произвольная отчетность;

5. Интеграция с внешними системами Заказчика (ERP-системы, финансовые системы, биллинговые системы и т. д.).

Onyma CRM тесно интегрирована с биллинговой системой Onyma Billing, имеет встроенный Личный кабинет клиента, интегрирована с платформой бизнес-аналитики Onyma BI и обладает всеми интеграционными возможностями платформы Onyma xRM.

Onyma CRM. Назначение системы

Система предназначена для обеспечения информационной поддержки бизнеса оператора связи и автоматизирует следующие процессы:

• создание и эффективное ведение единой структурированной базы клиентов — действующих и потенциальных;

• управление продажами: прогнозирование и отслеживание процесса продаж;

• управление маркетингом: подготовка, проведение и анализ эффективности маркетинговых воздействий, акций, опросов;

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

• управление ресурсами компании, которые задействованы для предоставления услуг клиентам;

• автоматизация документооборота при работе с клиентами: создание на основе шаблонов заказов, счетов, договоров, актов;

• управление временем: использование простого инструментария для планирования рабочего времени служб, контроль исполнения поручений и обработки заявок;

• осуществление анализа деятельности компании: быстрая подготовка оперативной и аналитической отчетности;

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

Общее описание Onyma CRM.

Описание базового состава и основные требования к системе

Структура и функционирование системы

Система представляет собой программный комплекс, состоящий из:

• Базы данных, обслуживаемой СУБД Oracle 11g и старше;

• Веб-сервера для обеспечения работы интерфейса и SOAP-API, обслуживаемого ПО Apache + Python;

• Системы доступа к БД, обслуживаемого ПО SQL Relay;

• Сервера приложений, обслуживаемого ПО JBOSS.

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

Связь между компонентами системы осуществляется при помощи протоколов на базе протокола TCP/IP.

Система тесно интегрируется с Onyma Billing и системой Onyma BI.

Система предоставляет API для интеграции с другими информационными системами.

Система предоставляет пользовательский веб-интерфейс на русском языке.

Функциональные возможности системы обеспечиваются следующими подсистемами:

• Подсистема пользовательского интерфейса;

• Подсистема разделения полномочий;

• Подсистема описания объектов;

• Подсистема процессов (workflows);

• Подсистема описания абонентов;

• Подсистема каталога;

• Подсистема описания ресурсов;

• Подсистема формирования документов;

• Подсистема формирования оперативной отчетности;

• Подсистема формирования аналитической отчетности (для BI);

• Подсистема обработки инцидентов и массовых проблем;

• Подсистема проведения маркетинговых воздействий;

• Подсистема планирования, организации и контроля продаж.

Требования к квалификации персонала системы и режиму его работы

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

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

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

Защита информации от несанкционированного доступа

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

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

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

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

Надежность и сохранность информации при авариях

Система предназначена для работы в режиме 7 × 24 × 365.

Система предусматривает внутренние средства диагностики работоспособности собственного программного обеспечения и предполагает наличие внешних средств диагностики физической работоспособности серверов, системного программного обеспечения, СУБД.

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

Функции системы

Подсистема пользовательского интерфейса

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

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

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

Основными функциями подсистемы являются:

• Обеспечение навигации (меню) пользовательского интерфейса, в зависимости от полномочий пользователя;

• Обеспечение навигации (wizard) пользовательского интерфейса, основанной на исполнении процессов;

• Отображение информации об объектах сущностей в виде списков, с возможностью многокритериальной фильтрации списка и настройки отображения его колонок;

• Отображение и исполнение заранее определенных действий над списками;

• Работа с сохраненными фильтрами, позволяющими одной операцией применять сложный заранее настроенный фильтр;

• Отображение подробной информации об объекте сущности как внутри списка, так и в отдельном окне с использованием необходимых для эффективной работы элементов отображения;

• Обеспечение глобальной системы контекстного поиска;

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

• Настройка вида стандартных форм с целью скрытия некоторых полей ввода или, наоборот, расширения полей ввода или отображения для дополнительных атрибутов объектов;

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

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

Пользовательский интерфейс предусматривает определение шаблонов для проверки корректности ввода.

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

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

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

Подсистема разделения полномочий

Подсистема обеспечивает разделение полномочий на основе ролевой модели.

Основными понятиями системы разделения полномочий являются:

• Группа — основная сущность системы, предназначенная для группировки всех остальных сущностей по тем или иным критериям. Группы образуют иерархию в виде диаграммы Хассе (т. е. одна группа может входить в несколько других, но без возможности организации циклов);

• Разрешение — атомарное право на исполнение того или иного действия в системе;

• Роль — набор разрешений. Роли также образуют иерархию в виде диаграммы Хассе. Роли подразделяются на системные (недоступные для изменения) и пользовательские (могут быть созданы и изменены администратором системы);

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

• Пользователь — сущность, сопоставляемая реальному лицу или программе-автомату. Служит объектом для наделения полномочиями в системе через назначение на ту или иную позицию на определенный промежуток времени. В каждый конкретный момент работы в системе пользователь обладает полномочиями только одной позиции. Если пользователь занимает несколько позиций, то у него есть возможность выбора, какую именно следует использовать в данный момент. Переключение между доступными позициями может быть произведено без прерывания текущей сессии через интерфейс системы. Пользователю сопоставляется контактная информация (e-mail и номер мобильного телефона) для работы системы уведомления по e-mail и/или SMS.

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

Идентификация пользователей при входе в систему осуществляется по логину и паролю.

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

Подсистема описания объектов

Все необходимые для работы системы сущности описываются при помощи единого механизма определения объектной модели.

Объектная модель описывается при помощи следующих основных понятий:

• Класс — понятие, отражающее любую сущность системы;

• Атрибут класса — свойство сущности, отличающее один объект данного класса от другого. Класс описывается набором атрибутов;

• Связь — понятие, отражающее взаимосвязь разных классов между собой;

• Объект — конкретный экземпляр класса, обладающий собственными значениями атрибутов и связями с другими объектами.

Классы образуют иерархию, например, класс «Физическое лицо» является подклассом класса «Контрагент» и наследует все его атрибуты. Глубина иерархии не ограничивается.

Атрибут класса характеризуется:

• Типом данных значения (символьный, числовой, дата, файл).

• Наличием (обязателен для заполнения или нет).

• Областью уникальности значений.

• Кратностью (допускается только одно значение или несколько).

• Типом значения (хранимое значение или вычислимое функцией).

• Справочником значений (опционально).

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

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

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

Любой объект (экземпляр класса) в системе обладает идентификационным номером, имеющим следующую структуру: “<Номер инсталляции>.<Номер сущности>.<Порядковый номер>”. Этот номер всегда можно видеть в интерфейсе работы с объектом и использовать для быстрого поиска объекта. Помимо данного номера, формируемого системой автоматически, можно организовать альтернативную нумерацию объектов класса при помощи специального атрибута с произвольной структурой номера.

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

Значения атрибутов объекта также характеризуется датами начала и окончания действия значения, таким образом, вся история изменения значений атрибутов в системе сохраняется и доступна для просмотра через интерфейс и API.

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

Связи между объектами также характеризуется датами начала и окончания действия и вся история изменения связей в системе сохраняется и доступна для просмотра через интерфейс.

Подсистема процессов

Процесс — это последовательность операций, производимая при реализации заданного стандартизированного бизнес-процесса в системе.

Основными понятиями подсистемы процессов являются:

• Задача — точно определенный набор действий, осуществляемый человеком или автоматически, приводящий к получению одного из заранее определенных результатов;

• Модель задачи — описание набора действий задачи и возможных вариантов ее завершения. Однажды описанная модель задачи может затем быть использована в разных моделях процессов;

• Модель процесса — модель бизнес-процесса, состоящая из шагов, на которых решаются задачи, и правил перехода между шагами в зависимости от результатов завершения задач;

• Полный процесс — модель процесса, в котором разрешены с каждого шага переходы на все шаги данной модели процесса;

• Процесс (обращение, заявка, проект, продажа, коммуникация) — конкретный экземпляр исполняемой модели процесса;

• Ответственный — должность или конкретный пользователь системы, ответственный за выполнение задачи на том или ином шаге процесса. Ответственных за процесс может быть несколько (группа), в каждый конкретный момент за шаг ответственен один пользователь;

• Согласователь — должность и конкретный пользователь системы, без подтверждения которого невозможно завершение задачи. Согласователей для шага может быть несколько;

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

• Событие — любое изменение состояния процесса или атрибутов объектов, описывающих его шаги;

• Журнал процесса — хронологически упорядоченная последовательность событий процесса.

Модель процесса содержит класс для описания процесса. Модель задачи содержит класс для описания задачи. Соответственно, процессы и задачи — объекты системы и к ним применимы все возможности подсистемы описания объектов.

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

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

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

Шаги процесса предусматриваются двух типов — требующих действий пользователя и автоматические шаги. Шаги, требующие действий пользователя, ожидают реакции пользователя через формы ввода информации. В зависимости от выбранных действии и/или введенных данных — процесс может переместиться на другой шаг выполнения. Предусматривается возможность настройки контрольных функций, при непрохождении которых задача не может быть перемещена на следующий шаг. Для шагов, требующих действий пользователя, предусматривается возможность срабатывания автоматического перехода в другое состояние по истечению определенного времени (согласно регламенту текущего исполняемого процесса), если от пользователя не было никакой реакции. Во время выполнения автоматических шагов система позволяет выполнять действия над объектами системы и их атрибутами, а также позволяет производить действия с внешними системами (вызов API-метода или внешней программы). Начало исполнения автоматического шага может быть при необходимости отложено на определенное время.

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

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

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

• Класс объектов, для которого настраиваются оповещения;

• Событие, о котором производится оповещение;

• Перечень уведомляемых лиц для каждого события;

• При каких условиях должно производиться оповещение.

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

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

Оповещение может происходить при различных условиях, например:

• Изменение значений атрибутов процесса/задачи;

• Добавление или изменение комментария к задаче;

• Переход задачи на другой шаг процесса;

• Назначение задачи группе, в которую входит пользователь;

• Назначение задачи непосредственно пользователю;

• Нарушение сроков нахождения задачи на шаге;

• И т. д.

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

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

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

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

Подсистема адресной базы данных

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

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

Адресная база данных имеет настраиваемую администратором иерархическую структуру с описанием допустимости появления тех или иных элементов адреса на тех или иных уровнях иерархии.

Для адресов России в качестве базовой иерархии принимается база данных КЛАДР.

Адресная база данных предполагает изначальную загрузку адресов региона (из КЛАДР или другого источника) с возможностью дальнейшего ее расширения как методом загрузки, так и непосредственно пользователями из интерфейса.

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

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

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

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

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

Функция модерации адресной базы обеспечивает:

• Подтверждение вновь введенных адресов;

• Редактирование адресов;

• Поиск похожих адресов;

• Поиск всех объектов, ссылающихся своими атрибутами на адрес;

• Слияние двух адресов в один с возможностью замены ссылок на данный адрес из значений атрибутов объектов и образования пары адресоу «основной»—«дублирующий» .

Подсистема описания абонентов

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

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

При задании адресов, помимо точной адресной информации из адресной базы, возможно задания примечаний (например: как добраться, этаж офиса и т. п.).

Наборы атрибутов могут быть расширены в любой момент администратором системы.

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

Среди контактов абонента может быть выделен основной контакт и контакты для информационных сообщений.

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

Один абонент может иметь несколько договоров с одним или разными операторами-поставщиками.

Одному договору может быть поставлен в соответствие только один лицевой счет.

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

Предоставление услуг в рамках одного договора может осуществляться по нескольким фактическим адресам.

Подсистема каталога услуг

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

Основными сущностями каталога услуг являются:

• Услуга — сущность, описывающая единичную услугу. Объект подкласса Услуга характеризуется соответствующим набором атрибутов. Услуги образуют иерархию, т. е. подключение некоторых дополнительных услуг возможно только при наличии подключения базовой услуги;

• Продукт — сущность, описывающая совокупность услуг, позиционируемых для клиента как единое предложение. Объект подкласса Продукт, характеризуется соответствующим набором атрибутов. Услуга может входить в продукт как базовая (автоматически подключается при подключении продукта) или как дополнительная. Продукты образуют иерархию в виде диаграммы Хассе (т. е. один продукт может входить в несколько других, но без возможности организации циклов);

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

• Прейскурант — сущность, содержащая правила определения стоимости услуг продукта при предоставлении этого продукта в определенной группе (регионе). Отсутствие прейскуранта для продукта означает невозможность его предоставления в данной группе (регионе);

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

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

• Наименование акции;

• Описание акции;

• Необходимое условие;

• Ключевое событие: событие на основе имеющихся в CRM сущностей или событие, генерируемое скриптом отчета;

• Набор модификаторов стоимости. Модификатор может быть как числовым коэффициентом, так и скриптом (в случае нестандартных условий акции);

• Даты начала и окончания действия акции;

• Дата начала действия преференций;

• Дата окончания действия преференций (до момента наступления дата окончания может изменяться в ручном режиме оператором CRM в карточке абонента). Может быть как фиксированной, так и рассчитанной с применением различных алгоритмов расчета;

• Крайняя дата наступления ключевого события;

• Взаимодействие с другими маркетинговыми акциями, варианты:

• Инвариант: совместное применение с другими акциями невозможно;

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

• Синергия: при совместном применении периоды действия синергетических акций суммируются;

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

Подсистема каталога услуг не содержит ограничений на число услуг, продуктов и тарифов.

Управление конфигурацией каталога услуг осуществляется администратором системы через интерфейс.

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

Подсистема описания ресурсов

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

Различные типы ресурсов описываются в системе при помощи различных классов, связи между конкретными ресурсами — связями между объектами классов.

Ввод информации о ресурсах осуществляется через интерфейс системы, средства импорта из текстовых файлов с разделителем и API.

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

Подсистема формирования документов

Основными задачами подсистемы формирования документов являются:

• Настройка модели данных и вида документов, формируемых в системе;

• Формирование единичных конкретных документов по запросу оператора;

• Формирование набора документов по списку (оперативному отчету);

• Формирование доступных для лицевого счета абонента документов в АСР Онима по запросу оператора или списку (оперативному отчету);

• Рассылка сформированных документов по e-mail или формирование пакета документов для печати и рассылки обычной почтой;

• Хранение и просмотр копий выставленных документов.

Подготовка модели данных документа осуществляется при помощи интерфейса системы на основе API-представлений и API-функций.

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

Для отображения и печати документы формируются в формате PDF.

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

При последовательном выставлении номерных документов предусматривается настраиваемый механизм ведения номеров документов.

Формирование документа является одним из возможных автоматических действий процесса. Уведомление о возникновении события процесса также является документом.

Подсистема формирования оперативной отчетности

Основными задачами подсистемы оперативной отчетности являются:

• Предоставление механизма онлайн-генерации, просмотра и выгрузки во внешние системы отчетов, сформированных на основе доступных в системе API-представлений;

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

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

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

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

Предусматривается возможность загрузки списка (или части списка) из файла, вместо (или совместно) заполнения его оперативным отчетом.

Подсистема формирования аналитической отчетности

Собственной подсистемы аналитической отчетности в системе не предусматривается. Роль системы для формирования аналитической отчетности возлагается на продукт Onyma BI.

Для построения аналитической отчетности используются штатные API-представления, доступ к которым организуется из Onyma BI.

Подсистема обработки инцидентов и массовых проблем

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

Фиксация инцидентов осуществляется при помощи механизма процессов. При этом предусматриваются следующие атрибуты:

• Тип: авария или плановые работы;

• Подтип (справочник);

• Регион возникновения проблемы;

• Элемент сети, на котором возникла проблема (из списка описанных ресурсов);

• Дата возникновения;

• Планируемая дата устранения;

• Дата окончания;

• Описание;

• Сервисы, работа которых была нарушена.

Наборы атрибутов могут быть расширены в любой момент администратором системы.

При заведении инцидента на основе информации об элементе сети производится расчет и оценка количества пострадавших абонентов. В зависимости от этой оценки (решение оператора) инцидент может быть признан массовой проблемой и инициирован процесс обработки массовой проблемы.

Процесс обработки массовой проблемы предусматривает:

• Задание описания проблемы для операторов системы и абонентов (при необходимости информирования абонентов) и планируемого срока решения проблемы;

• Определение точного списка пострадавших абонентов и указания, следует ли информировать их о начале и/или окончании проблемы;

• Информирование операторов системы посредством сообщения в карточке абонента о существовании у данного абонента проблемы;

• Информирование абонентов через личный кабинет о существовании проблемы (при необходимости);

• Отображение заявок по массовым проблемам в карточке абонента в списке обращений;

• Определение списка обращений, поступивших от абонентов, подверженных массовой проблеме в период ее действия и автоматическое закрытие этих обращений по окончанию действия массовой проблемы.

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

Подсистема проведения опросов

Основными сущностями подсистемы проведения опроса являются:

• Вопрос — атомарный элемент опроса, состоящий из текста вопроса и возможных вариантов ответа. По типу ответы подразделяются на единичные (из списка), множественные (из списка) и/или собственные;

• Опрос — последовательность вопросов с определенными правилами перехода в зависимости от ответов. Опрос, помимо вопросов, может содержать и атрибуты, заполнение которых может быть осуществлено оператором в любой момент опроса, вне зависимости от текущего вопроса;

• Правила переходов — матрица, определяющая для каждого вопроса, какой вопрос будет следующим по умолчанию или при получении определенного ответа;

• Результат — ответы на вопросы опроса, полученные от одного респондента;

• Таблица результатов — сводная таблица ответов на вопросы опроса по всем респондентам.

Основными функциями подсистемы проведения опросов являются:

• Конфигурация опроса;

• Предоставление интерфейса опроса для оператора;

• Предоставление интерфейса опроса для личного кабинета;

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

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

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

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

Респондент может отказаться от проведения опроса или перенести его проведение на более поздний срок.

Настройка опроса производится администратором через интерфейс системы.

Подсистема системного администрирования

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

Основными функциями подсистемы системного администрирования являются:

• Ведение журнала системных сообщений;

• Контроль над сессиями пользователей системы;

• Контроль над исполнением фоновых задач;

• Управление системными параметрами;

• Внутренний мониторинг системы с настраиваемыми уведомлениями о тех или иных событиях в системе или отклонении тех или иных показателей системы от расчетных. Под событием понимается любая запись в журнале системных сообщений. Показатель – произвольная пользовательская API-функция расчета c заданным периодом расчета и границами допустимых значений;

• Ведение сводного журнала аудита по изменению данных в системе.

Интеграция с Onyma Billing

Система Onyma CRM тесно интегрируется с Onyma Billing — биллинговым решением, обеспечивающим все необходимые операции по ведению лицевых счетов абонентов, управлению предоставлением услуг и формированию необходимых документов.

Интеграция с Onyma Billing осуществляется на уровне взаимного использования предоставляемых системами через протокол SQLNet API-методов. Физическое расположение систем при этом не имеет значения, важно лишь наличие доступа к ядру Onyma Billing по протоколу SQLNet.

Для реализации некоторых функций в части работы подсистемы формирования документов, может потребоваться обращение к интерфейсу Onyma Billing (далее АСР) по протоколу HTTPS.

Для обеспечения целостности информации, принимается следующая схема интеграции, регламентирующая зоны ответственности систем в части изменения данных:

Интеграция с SMS-шлюзом

Для обеспечения информирования абонентов посредством SMS предусмотрена интеграция системы с внешним SMS-шлюзом по протоколу SMPP.

SMS является одним из канала коммуникации с абонентом, соответственно все предусмотренные уведомления процесса могут быть отправлены абоненту как по e-mail, так и по SMS, в зависимости от настроек абонента.

Предусмотрен вариант ручной отправки SMS-сообщения из карточки абонента.

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

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

Интеграция с другими информационными системами

Для интеграции с другими информационными системами возможно использование двух сценариев:

• CRM является ведомой системой. В этом случае внешняя информационная система может воспользоваться полным набором функций CRM, доступных в виде API-методов и API-представлений по протоколам SQLNet или SOAP;

• CRM использует информацию других систем. В этом случае внешняя информационная система должна предоставить информацию в виде API-представлений, доступных по протоколу SQLNet.