Принятые сокращения:

1. Платформа программного обеспечения системы

Система включает в себя АСР «Дороги».

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

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

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

1. Полностью открытая архитектура;
2. Ролевая система разделения полномочий;
3. Система допусков и грифов;
4. Беспрецедентный уровень аудита и диагностики;
5. Конструктор бизнес-процессов;
6. Развитый, настраиваемый веб-интерфейс.

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

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

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

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

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

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

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

Базовый интерфейс платформы АСР «Дороги» содержит все необходимые для эффективной обработки информации компоненты:

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

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

1. Общее описание системы

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

1.1. Основные компоненты Системы

Общая структурная схема компонентов Системы представлена на рисунке 2.

Рисунок 2. Структурная схема системы

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

Рисунок 3

Комплекс состоит из двух созданных на единой платформе и тесно интегрированных основных систем: Billing и CRM.

Система Billing — распределенная информационная система, выполняющая в данном комплексе роль СВП 3-го уровня (Центрального уровня). Система состоит из центрального ядра и множества центров авторизации, расположенных на ПВП и предназначенных для онлайн-взаимодействия с компонентами СВП 1-го и 2-го уровней (рисунок 4).

Рисунок 4. Взаимодействие системы с СВП 1-го и 2-го уровней

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

1. Описание структуры СВП, включая все необходимые параметры для конфигурации ПВП и полос оплаты;
2. Описание тарифной политики оператора;
3. Взаимодействие с СВП 1-го и 2-го уровней для сбора информации о транзакциях проезда и передачи в обратную сторону необходимых конфигураций;
4. Учет оборота наличных средств на полосах проезда;
5. Ведение лицевых счетов и учет транзакций по ЭСО;
6. Формирование необходимой оперативной отчетности.

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

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

1. Создание и ведение каталога продуктов (маркетинговая энциклопедия), конфигуратор продуктов;
2. Создание и сопровождение базы данных контрагентов. Настройка контактов  и управление ими — все виды контактов и история контактов; работа с клиентами, включая все виды деятельности, связанные с клиентом; ввод заказов от клиентов; создание коммерческих предложений. Сегментация клиентской базы, создание и управление списком потенциальных клиентов;
3. Настройка, запуск и выполнение процессов обработки заявок через все каналы работы с клиентами;
4. Управление маркетинговыми кампаниями, управление потенциальными сделками. Конфигурация процессов управления продажами. В том числе: анализ «воронки продаж»: прогнозирование, анализ цикла продаж, региональный анализ, запланированная и произвольная отчетность;
5. Интеграция с внешними системами Заказчика (ERP-системы, финансовые системы, биллинговые системы и т.д.).

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

Через общий интеграционный API/OSS слой строится взаимодействие систем Billing и CRM с другими системами взимания платы (1-го и 2-го уровней), внешними информационными системами, платежными и банковскими системами, осуществляется рассылка уведомлений и документов.

Центры авторизации располагаются на ПВП и могут автономно от ядра системы в онлайн-режиме взаимодействовать с СВП 1-го и 2-го уровней для обработки транзакций проездов и конфигурации.

1.1. Серверная структура Системы

На рисунке 5 приведена общая архитектурная модель серверной структуры системы. Основным компонентом является ядро. Оно присутствует в единственном экземпляре для одного экземпляра системы. Ядро — это сервер под управлением операционной системы UNIX, обеспечивающий работу RDBMS Oracle. Через драйвер WSQL с ядром системы взаимодействуют два управляющих веб-сервера:

• Веб-сервер «Операторов» отвечает за обслуживанием запросов персонала Оператора дороги;
• Клиентский веб-сервер или Сервер регистрации и статистики (STAT Server). Клиенты (пользователи) Оператора дороги используют этот сервер для получения статистики потребления услуг, для заказа услуг, получения отчетных документов, оплаты услуг через электронные платежные системы и т. д.

Рисунок 5

Одним из важнейших компонентов системы является Сервер авторизации и сбора статистики или Центр авторизации и сбора статистики (AuthPoint — AP). Одно ядро работает с несколькими серверами авторизации и сбора статистики, которые непосредственно общаются с аппаратурой для сбора статистики, управления оборудованием, а при необходимости и осуществлением процесса авторизации. Центры авторизации достаточно длительное время могут работать автономно, без ядра. Несколько центров авторизации могут дублировать друг друга.

1.2. Организация вычислительной среды

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

Рисунок 6.

Ядро системы обеспечивает работу следующих компонентов:

• Основная база данных Системы (RDBMS Oracle);
• Веб-сервер (Apache 2.4.x + ModSSL + PHP 5.3.x);
• Драйвер SQL-Relay, обеспечивающий веб-серверам доступ к основной базе данных.

Сервер приложений JBoss обеспечивает:

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

Центры авторизации (AuthPoint) обеспечивают работу следующих подсистем:

• Базу данных центра авторизации (RDBMS Oracle), состоящую из копии части основной базы данных (в центр авторизации копируется только та часть информации, которая необходима для обеспечения процессов авторизации и сбора статистики). Синхронизация с основной базой данных для передачи собранной статистики и получения измененной в ядре информации осуществляется по инициативе ядра, например, со следующей периодичностью (значения настраиваются из интерфейса АСР):
  • Справочная информация — раз в сутки;
  • Информация по настройке системы авторизации — раз в час;
  • Информация по тарифам — раз в час;
  • Статистика и информация по клиентам — раз в 5 минут.

Если требуется, чтобы изменения, внесенные в ядро системы, были отображены в центре авторизации немедленно, следует воспользоваться функцией принудительной синхронизации интерфейса системы (Администратор | Система авторизации | AP-монитор), где нужно отметить нужный центр авторизации и нажать Синхронизировать.

В АР-мониторе отображаются две даты:

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

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

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

Сервер приложений UNIS обеспечивает:

• Функциональность RADIUS-сервера;
• Загрузку статистической информации из файлов.

Драйвер WSQL обеспечивает серверу приложений UNIS доступ к RDBMS.

PreBilling — набор программ, обеспечивающих сбор и агрегацию статистики.

1.3. Рекомендации к аппаратной части Системы

На рисунке 7 приведен рекомендуемый вариант аппаратной части системы.

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

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

Рисунок 7.

1.3.1. Web-сервер и сервер приложений (Web/App)

Конфигурация серверов:

1.3.2. Сервер ядра (DB Oracle)

Конфигурация сервера:

* — все платформы Power содержат аппаратную виртуализацию ресурсов и полную изоляции между виртуальными машинами без потери производительности.

Применение аппаратной виртуализации позволяет очень существенно сократить расходы на лицензирование DB Oracle как на первоначальном этапе, так и в процессе использования.

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

Конфигурация лицензий DB Oracle:

* — неограниченное полное использование в составе ПО разработчика, скидка 50%;

** — полное использование.

Примечание: Требуемое количество лицензий DB Oracle определяется конфигурацией используемого сервера (-ов).

Варианты резервирования сервера Ядра (DB Oracle):

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

IBM Power 770 cluster

Аппаратный отказоустойчивый кластер на базе платформы Power 770.

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

IBM PowerHA

Решение требует наличия двух аналогичных серверов размещенных на одной или удаленных площадках и применение IBM PowerHA (специализированное ПО, которое  управляет прикладным программным обеспечением на серверах).

Решение требует:

• Резервированного канала связи между серверами;
• Доступности дискового массива с двух серверов или двух mirror-массивов.

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

Oracle RAC

Требуется установка второго сервера на локальной или удаленной площадке.

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

Требуется лицензирование второго экземпляра DB Oracle и опции RAC.

Oracle Main-Standby

Требуется установка аналогичного сервера на локальной или удаленной площадке.

Может потребоваться лицензирование второго экземпляра DB Oracle.

1.3.3. Сервер авторизации и сбора статистики (AuthPoint, AP)

Конфигурация серверов:

Конфигурация лицензий DB Oracle:

* — неограниченное полное использование в составе ПО разработчика, скидка 50%;

** — полное использование.

1.3.4. Внешний дисковый массив

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

Конфигурация массивов:

2. Основные функции и реализованные бизнес-процессы системы

2.1. Основные функции

2.1.1. Интеграция с СВП 1-го и 2-го уровня

Система полностью интегрирована с СВП 1-го и 2-го уровня для работы в полностью автоматическом режиме, как в режиме онлайн, так и в режиме офлайн.

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

2.1.2. Система описания ресурсов

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

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

2.1.3. Система CRM

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

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

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

2.1.4. Система Billing

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

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

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

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

Система интегрирована с российской системой бухгалтерского учёта 1С и другими популярными учётными системами.

2.1.5. Система построения отчетности

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

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

2.2. Примеры реализованных бизнес-процессов для оператора СВП

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

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

2.2.1. Отдел кадров

Прием на работу нового сотрудника с доступом в СВП:

Увольнение сотрудника:

Генерация лота карта доступа в СВП:

Блокировка карты доступа в СВП:

Выдача новой карты доступа в СВП:

2.2.2. Касса ПВП

Выдача размена/инкассация:

2.2.3. Финансовый контроль

Разбор аномалий:

Претензия к кассиру:

Закрытие дня и формирование документов за день:

2.2.4. Эмитент ЭСО

Генерация лота ЭСО:

 Выдача диапазона ЭСО на пункт продаж:

Прием ЭСО с пунктов продаж:

2.2.5. Пункт продаж

Заведение нового контрагента:

Заключение договора (доп. соглашения) с контрагентом на предоставление услуг по ЭСО:

Расторжение договора на предоставление услуг по ЭСО:

Прием ЭСО, ранее сданного в аренду:

Прием ранее проданного ЭСО (возврат):

Замена ЭСО по гарантии:

Блокировка/разблокировка  ЭСО по запросу клиента:

2.2.6. Департамент обслуживания клиентов

Формирование и рассылка отчетности для клиентов за период

Формирование финансовой отчетности и передача ее в бухгалтерию:

Блокировка/разблокировка ЭСО по запросу клиента:

Претензия клиента:

2.2.7. Личный кабинет

Самообслуживание

3. Характеристики системы

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

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

• Баз данных, обслуживаемых СУБД Oracle 11g и старше;
• Веб-сервера (-ов) для обеспечения работы интерфейса и SOAP/REST-API, обслуживаемого ПО Apache + Python.
• Сервера приложений, обслуживаемого ПО JBoss.

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

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

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

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

Лицензионные параметры системы:

• 10 000 лицевых счетов в системе;
• 1 млн транзакций оплаты проезда в месяц.

Система не предусматривает ограничений в работе при несоответствии лицензионным параметрам.

3.2. Квалификация персонала

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

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

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

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

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

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

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

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

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

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

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

4. Функционал ключевых подсистем

4.1. Подсистема сбора и первичной обработки информации

Основной задачей подсистемы является сбор первичной информации с оборудования предоставления услуг (СВП уровней 1 и 2).

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

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

• Автоматический, автоматизированный и ручной сбор исходной информации об оказанных услугах с учетом особенностей их тарификации (в режиме отложенного времени, в режиме реального);
• Автоматический и автоматизированный сбор исходной информации об услугах, оказанных другим оператором;
• Объединение различной исходной информации, относящейся к одной оказанной услуге;
• Фильтрация и сортировка исходной информации об оказанных услугах;
• Накопление исходной информации об оказанных услугах;
• Автоматическая и автоматизированная проверка достоверности и корректности исходной информации, включающая:
• Настройку критериев и условий, в соответствии с которыми исходная информация об оказанных услугах считается ошибочной;
• Проверку на соответствие заданным критериям;
• Проверку на отсутствие дублирования исходной информации;
• Формирование информационного массива с исходной информацией (далее — массив «отсева»), не прошедшей проверку, с указанием кода ошибки при тарификации в отложенном времени;
• Обеспечение возможности просмотра, корректировки и последующей обработки массива «отсева» при тарификации в отложенном времени;
• Регистрация перечня исправленных записей в массиве «отсева», даты и времени проведения корректировок, идентификатора исполнителя при тарификации в отложенном времени;
• Мониторинга в режиме реального времени исходной информации об оказываемых услугах.

4.2. Подсистема тарификации и расчета

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

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

• Настройка тарифных планов, позволяющих осуществлять разовые, периодические и фактические начисления за услуги с многокритериальным выбором тарифа, в том числе в зависимости от даты и времени предоставления, места предоставления и дополнительных квалификаторов (класс ТС, тип оплаты и т.п.);
• Настройка для каждого вида услуг критериев, применяемых при формировании тарифных планов, в соответствии с которыми оказанная услуга учитывается в объеме оказанных услуг с или без тарификации;
• Настройка функций тарификации, определяющих скидки и другие правила изменения тарифа в зависимости от интегрального потребления и других параметров лицевого счета клиента;
• Настройка единиц тарификации каждого вида услуг;
• Настройка правил округления величины, характеризующей объем оказанной услуги;
• Обеспечение возможности настройки округления величины, характеризующей объем оказанной услуги;
• Тарификация и расчет стоимости оказанных услуг с учетом тарифов, действующих на момент начала оказания услуги;
• Выполнение (в том числе срочных, непосредственно после оказания услуги) расчетов в межрасчетный период (до регламентированной даты начала расчетов) для одного или группы клиентов;
• Хранение «истории» начислений и оплат для каждого лицевого счета в течение срока исковой давности, установленного законодательством Российской Федерации;
• Корректировка и перерасчет (в режиме отложенного времени) стоимости оказанных услуг;
• Регистрация результатов корректировки и перерасчета стоимости оказанных услуг;
• Расчет налогов в соответствии с действующим законодательством;
• Хранение результатов тарификации и расчетов, в том числе результатов расчетов по начисленным пени в течение срока исковой давности, установленного законодательством Российской Федерации.

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

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

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

• Регистрация и учет наличных и безналичных платежей;
• Учет нераспознанных платежей;
• Ввод информации о перерасчетах за оказанные услуги;
• Автоматизация распределения платежей (поиск соответствия по виду платежа, по клиенту, по сумме платежа, дате платежа и деталям платежа);
• Актуализация баланса состояния лицевого счета клиента в момент поступления в автоматизированную систему расчетов информации о платежах клиента;
• Регистрация целевого платежа:
• За определенный вид услуг;
• На определенный лицевой счет (если у клиента несколько лицевых счетов);
• За определенный расчетный период.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Типом данных значения (символьный, числовой, дата, файл);
• Наличием (обязателен для заполнения или нет):
• Областью уникальности значений;
• Кратностью (допускается только одно значение или несколько);
• Типом значения (хранимое значение или вычислимое функцией);
• Справочником значений (опционально).

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

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

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

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

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

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

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

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

Основные сущности, используемые в компонентах системы, приведены в таблице 1.

Таблица 1

4.7. Подсистема workflow (конструктор бизнес-процессов)

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

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

• Задача — точно определенный набор действий, осуществляемый человеком или автоматически, приводящий к получению одного из заранее определенных результатов;
• Модель задачи — описание набора действий задачи и возможных вариантов ее завершения. Однажды описанная модель задачи может затем быть использована в разных моделях процессов;
• Модель процесса — модель бизнес-процесса, состоящая из шагов, на которых решаются задачи, и правил перехода между шагами в зависимости от результатов завершения задач;
• Полный процесс — модель процесса, в котором разрешены с каждого шага переходы на все шаги данной модели процесса;
• Процесс (обращение, заявка, проект, продажа, коммуникация) — конкретный экземпляр исполняемой модели процесса;
• Ответственный — должность или конкретный пользователь системы, ответственный за выполнение задачи на том или ином шаге процесса. Ответственных за процесс может быть несколько (группа), в каждый конкретный момент за шаг ответственен один пользователь;
• Согласователь — должность и конкретный пользователь системы, без подтверждения которого невозможно завершение задачи. Согласователей для шага может быть несколько;
• Регламент — набор правил, определяющий временные и стоимостные характеристики исполнения задач. Одни и те же задачи могут исполняться в разных случаях по разным регламентам, что позволяет, например, для разных категорий клиентов производить обслуживание с разным приоритетом и временными рамками выполнения работ;
• Событие — любое изменение состояния процесса или атрибутов объектов, описывающих его шаги;
• Журнал процесса — хронологически упорядоченная последовательность событий процесса.

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

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

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

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

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

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

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

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

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

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

В системе предусматривается возможность размещения заявок на исполнение будущим временем.

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

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

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

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

4.8. Подсистема описания клиентов

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

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

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

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

Лицо из каталога контрагентов соотносится с базовой группой - регионом.

Лицо из каталога лиц может входить в произвольное число заранее определенных дополнительных групп (например: VIP, Гос. структуры и т. п.).

Клиентом считается лицо из каталога лиц, с которым возможно заключение договора.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Настройка модели данных и вида документов, формируемых в системе;
• Формирование единичных конкретных документов по запросу оператора;
• Формирование набора документов по списку (оперативному отчету);
• Формирование доступных для лицевого счета клиента документов по запросу оператора или списку (оперативному отчету);
• Рассылка сформированных документов по e-mail или формирование пакета документов для печати и рассылки обычной почтой;
• Хранение и просмотр копий выставленных документов.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4.14. Личный кабинет

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

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

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

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

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

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