exarid.uzex.uz · Web viewРешение должно обеспечивать высокую производительность в режиме реального времени

Приложение 1

ТЕХНИЧЕСКИЕ ТРЕБОВАНИЯ К АВТОМАТИЗИРОВАННОЙ КОНВЕРГЕНТНОЙ

СИСТЕМЕ НОВОГО ПОКОЛЕНИЯ ДЛЯ ПОДДЕРЖКИ БИЗНЕСА ООО «COSCOM»

(ТОРГОВАЯ МАРКА UCELL)»

Технические требования системы поддержки бизнеса

ООО «COSCOM» (UCELL)

Annex 1

TECHNICAL REQUIREMENTS FOR THE NEXT-GENERATION CONVERGENT BUSINESS

SUPPORT SYSTEM OF COSCOM LLC (UCELL BRAND)

BSS Requirements Specification

COSCOM LLC (UCELL)

22

Оглавление / Table of contentОглавление / Table of content....................................................................................................................................................................................................................23

Введение.....................................................................................................................................................................................................................................................26

Словарь используемых терминов........................................................................................................................................................................................................26

Definitions...............................................................................................................................................................................................................................................26

Список принятых сокращений.............................................................................................................................................................................................................28

Abbreviations..........................................................................................................................................................................................................................................28

Бизнес-требования.....................................................................................................................................................................................................................................29

Business requirements.................................................................................................................................................................................................................................29

Общие системные требования.............................................................................................................................................................................................................29

General system requirements..................................................................................................................................................................................................................29

Требования по тарификации и управлению балансом......................................................................................................................................................................42

Charging and Balance Management Requirements................................................................................................................................................................................42

Требования к биллингу и платежам....................................................................................................................................................................................................58

Billing and Payment Requirements.........................................................................................................................................................................................................58

Система управления печатными формами и счет-фактурами..........................................................................................................................................................63

Document Formatting and Invoice Management System.......................................................................................................................................................................63

Система приема платежей....................................................................................................................................................................................................................66

Payment system.......................................................................................................................................................................................................................................66

Система управления картами оплаты.................................................................................................................................................................................................71

Payment Card Management System.......................................................................................................................................................................................................71

Управление услугами...........................................................................................................................................................................................................................73

Service management...............................................................................................................................................................................................................................73

Система провижининга........................................................................................................................................................................................................................79

Provisioning............................................................................................................................................................................................................................................79

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

Customer Relationship Management System.........................................................................................................................................................................................82

23

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

Self-Service.............................................................................................................................................................................................................................................92

Поддержка массовых операций...........................................................................................................................................................................................................95

Bulk Operations Support.........................................................................................................................................................................................................................95

Система лояльности и стимулирования..............................................................................................................................................................................................97

Loyalty and incentive system..................................................................................................................................................................................................................97

Система учета и распределения ресурсов..........................................................................................................................................................................................99

Resource inventory and distribution System..........................................................................................................................................................................................99

Система управления дилерами..........................................................................................................................................................................................................101

Dealer Management System.................................................................................................................................................................................................................101

Система поддержки роуминга...........................................................................................................................................................................................................103

Roaming Support System......................................................................................................................................................................................................................103

Система отчетности............................................................................................................................................................................................................................106

Reporting system...................................................................................................................................................................................................................................106

Технические требования.........................................................................................................................................................................................................................107

Technical requirements..............................................................................................................................................................................................................................107

Общие архитектурные требования....................................................................................................................................................................................................107

General architectural requirements.......................................................................................................................................................................................................107

Требования к расчёту конфигурации ресурсов................................................................................................................................................................................108

HW Configuration Calculation Requirements......................................................................................................................................................................................108

Требования к надежности..................................................................................................................................................................................................................111

Reliability Requirements.......................................................................................................................................................................................................................111

Требования к документированию.....................................................................................................................................................................................................112

Documentation Requirements...............................................................................................................................................................................................................112

Требования к эксплуатации решения....................................................................................................................................................................................................113

Operational requirements...........................................................................................................................................................................................................................113

Требования по поддержке..................................................................................................................................................................................................................113

24

Support Requirements...........................................................................................................................................................................................................................113

Требования по мониторингу..............................................................................................................................................................................................................114

Monitoring requirements.......................................................................................................................................................................................................................114

Требования к проекту..............................................................................................................................................................................................................................115

Project requirements..................................................................................................................................................................................................................................115

Требования по структуре проекта внедрения..................................................................................................................................................................................115

Requirements for the structure of the implementation project.............................................................................................................................................................115

Обобщенная матрица ответственности Поставщика и UCELL по проекту..................................................................................................................................117

Matrix of responsibility (Roles & Responsibility) of the Vendor and UCELL for the project............................................................................................................117

25

1. Введение Introduction

1.1. Словарь используемых терминов Definitions

Заказчик ООО «COSCOM» - один из крупнейших операторов телекоммуникационных услуг, который охватывает своей сетью всю территорию Республики Узбекистан: сеть 2G обеспечивает покрытие примерно 97% Узбекистана, 3G сеть компании покрывает 60% страны. Компания предоставляет услуги мобильной связи. Услуги компании на рынке оказываются под маркой UCELL.

Customer COSCOM LLC is a major communications service provider in the Republic of Uzbekistan offering 2G coverage across about 97 percent and 3G coverage across 60 percent of the country’s territory. The CSP markets mobile communications services under the brand name UCELL.

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

Communications Service Provider (CSP)

A company that provides communications services to its own subscribers.

Решение / Система

Автоматизированная конвергентная система расчетов «CONVERGENT BSS SOLUTION».

Solution / System

CONVERGENT BSS SOLUTION.

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

Billing The process of generating invoices for services rendered during a billing period as well as applying discounts and calculating amounts receivable.

Клиент Физическое или юридическое лицо, заключившее с оператором связи договор на обслуживание и оплачивающее счета за услуги связи, оказанные его Абонентам (определение данного термина дано ниже).

Customer An individual or an organization who has a service agreement with a CSP and who pays bills for the communications services provided to their Subscribers (as defined below).

Лицевой счет Уникальный номер (порядковый номер записи о клиенте оператора в Автоматизированной системе расчётов), позволяющий однозначно идентифицировать клиента.

Account A number (the sequence number of a record on a CSP’s customer in the BSS) that uniquely identifies a customer.

Абонент Потребитель услуг связи Subscriber A consumer of communications services

Тип клиента Атрибут клиента, определяющий доступные ему Тарифные планы и предложения а также применимые процессы и правила работы.

Customer type A customer’s attribute determining which rate plans and offers are available to the customer as well as which processes and rules apply to the customer.

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

Service package A set of services grouped together for marketing purposes. Such a set can be associated with specific tariffs, tariff rates, discount plans, a destination plan and a rounding plan. A subscriber who orders a service package receives all the services included in it.

26

Исправление Это решение инцидента, в результате чего система работает стабильно без вмешательства человека

Correction Incident resolution that ensures that the System can continue running without human intervention.

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

Response time The time it takes for technical support reps to start recovery activities in response to a service request.

Время восстановления

Интервал времени с момента получения уведомления Клиента о проблеме в колл-центре поставщика до времени, когда Система вернулась к своей нормальной работе, то есть влияние ошибки устранено, но причина ошибки не устранена.

Recovery time The time it takes the Vendor to recover the System back to normal operation after the Client reports a problem by contacting the Vendor’s call center. Recovery means that the problem no longer affects the System but its cause has not been eliminated.

Время разрешения

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

Resolution time The time it takes for the Vendor to analyze a problem reported by the Client and resolve it.

Время простоя Это интервал времени на протяжении которого Система находится в нерабочем состоянии.

Down time The time interval when System is out of service.

Parallel run Параллельная эксплуатация двух Систем: заменяемой и заменяющей.

Parallel run The parallel run of two Systems, the one to be replaced and the one that replaces it.

27

1.2. Список принятых сокращений AbbreviationsАСР Автоматизированная система расчётов BSS Business Support System

БД База данных DB Database

ПО Программное обеспечение SW Software

ТП Тарифный план RP Rate plan

CDR Учетная запись CDR Charge detail record

CRM Система управления взаимоотношениями с клиентами (Customer Relationship Management)

CRM Customer Relationship Management

CUG Закрытая группа пользователей CUG Closed User Group

FAF \ F&F Друзья и семья, любимые номера FAF \ F&F Friends & Family, favorite numbers

IPTV IP телевидение IPTV IP Television

VPN Виртуальная частная сеть VPN Virtual private network

ДВО Дополнительные виды обслуживания VAS Value Added Service

DDoS attack Распределённая атака типа «отказ в обслуживании» DDoS attack Distributed Denial of Service attack

TAM Карта приложений для предприятия телекоммуникационной отрасли разработки TM Forum

TAM Telecom Application Map (application map for the telecommunications industry developed by TM Forum)

RT-абонент Real Time абонент RT subscriber Real-time subscriber

IMEI Международный идентификатор мобильного оборудования IMEI International Mobile Equipment Identity

MSISDN Номер мобильного абонента цифровой сети с интеграцией служб

MSISDN Mobile Subscriber Integrated Services Digital Number (Mobile subscriber number of a digital network with integration of services for communication in GSM, UMTS, etc.)

HLR База данных абонентов HLR Home Location Register

QoS Качество обслуживания QoS Quality of Service

GUI Графический пользовательский интерфейс GUI Graphical User Interface

FC Полное соответствие FC Full compliance

NC Несоответствие NC Non compliance

28

2. Бизнес-требования Business requirementsДанный раздел приводит высокоуровневые описания

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

This section provides high-level descriptions of the business requirements for the Solution. It should not be considered as a comprehensive list covering all business requirements. All of the requirements below should be included in the decision, but should not be limited to them. All restrictions in the decision should be explained.

2.1.2 Общие системные требования General system requirements

Соответствие/ Compliance (FC/NC)

Комментарии/ Comments

Автоматизированная система расчётов (АСР) должна удовлетворять системным и техническим требованиям, описанным в данном разделе.

The BSS must satisfy the system and technical requirements described in this section.

2.1.1. Функциональность Решения должна развиваться в соответствии с международными стандартами TMForum Frameworx, 3GPP.

The functionality of the Solution should be developed in compliance with generally accepted international standards, such as TM Forum Frameworx and 3GPP standards.

2.1.2. Решение должно отвечать следующим основным требованиям:

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

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

The Solution must meet the following basic requirements:

Real-time charging and rating for any services, customers and forms of payment;

Global Invariance Convergence; High availability; Scalability; Modularity; Openness; Security; Flexibility; Compatibility with third-party software products.

29




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

2.1.3. Конвергентность системы определяется следующими принципами:

Конвергенция технологий: конвергенция технологий - это способность поддерживать несколько технологий и несколько типов сетей с помощью одного решения BSS.

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

Конвергенция сегментов рынка: одно и то же решение должно поддерживать различные типы бизнес-сегментов (B2C, B2B, B2G, B2X), а также партнеров и дилеров.

The System should be convergent in the following dimensions:

Convergence of technologies: A single BSS solution should be able to support multiple technologies and kinds of networks.

Convergence of payment methods: A single BSS solution should support any type of account (prepaid, postpaid, hybrid) and product offer.

Convergence of market segments: A single BSS solution should support multiple types of business segments (B2C, B2B, B2G, B2X), partners and dealers.

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

The System should have a convergent billing architecture implementing a unified approach to generating and issuing bills for any events related to any service or product.

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

The Solution should provide real-time charging to ensure that charges are deducted from the subscriber’s balance based on the actual volume of service usage and the applicable parameters concurrently with the service consumption.

2.1.6. Решение должно поддерживать систему оценки и начисления платы в реальном времени для различных технологий доступа (широкополосный, фиксированный, Wi-Fi, IP-телевидение, LTE, VoLTE, 5G) и методов выставления счетов (включая предоплату, постоплату, гибрид), для индивидуальных и корпоративных групп клиентов.

The Solution should support a real-time rating and charging system for multiple access technologies (broadband, fixed, Wi-Fi, IPTV, LTE, VoLTE, 5G) and billing methods (including prepaid, postpaid, hybrid) for individual customers and corporate groups of customers.

2.1.7. Система должна обеспечивать управление и The System should provide service management and

30




тарификацию услуг всех поколений, включая 4G и 5G.

charging for all generations of mobile networks, including 4G and 5G.

2.1.8. Решение должно обеспечивать высокую производительность в режиме реального времени для оценки и контроля текущих сеансов для всех типов вызовов (голос, SMS, данные, видео, контент и т.д.), с несколькими параметрами оценки (длительность, на транзакцию, объем данных, время дня, пакетные услуги, бонусы, скидки, Friends & Family, VPN, CUG, местоположение, сотовая связь, позиция в роуминге и т.д.), кредитный контроль и мониторинг (кредитные лимиты, лимиты расходов) и различные типы платежей (плата за доступ, плата за использование, Абонентская плата, специальные предложения), будь то в сети или в роуминге.

The Solution should provide high performance in real time to rate and control ongoing sessions for all types of calls (voice, SMS, data, video, content, etc.), with several rating parameters (duration, transaction, data volume, time of the day, allowances, bonuses, discounts, Friends & Family, VPN, CUG, location, RAT type, roaming location, etc.), credit control and monitoring (credit limits, spending limits) and various types of fees (access fee, usage fee, subscription fee, special offers) both in the home network and when roaming.

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

The Solution should be able to provide notifications at the beginning of, during and at the end of a call (low balance alerts, expense control messages, bonus reward messages, etc.) to subscribers in real time.

2.1.10. Отказоустойчивость и доступность определяется современным уровнем и характеристиками применяемых программно-аппаратных средств, решением необходимых для этого вопросов организационного обеспечения, связанных с резервированием (в том числе и «горячим») данных, их достоверностью и т.п. При этом доступ пользователей к данным и процедурам Решения должна обеспечиваться только в пределах, установленных для каждого конкретного работника. Доступность всего Решения должна определяться уровнем 99,995% и для наиболее критичных модулей (управления оценкой в режиме реального времени) уровнем

The Solution should ensure high availability through the use of modern software and hardware with adequate performance, data backup capabilities (including “hot” reserve), data integrity assurance, etc. Solution users should have access only to the data and procedures they have permission to access. The entire Solution must maintain 99.995% availability; mission-critical modules, such as real-time rating management, must deliver 99.999% availability.

31




99,999%.

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

The Solution should ensure openness through the use of open protocols for interactions with external systems and provision of published, well-documented interfaces to developers. The Solution should be adaptable to the company’s existing infrastructure and business processes; it should ensure information compatibility with the existing systems and modules via relevant converters and programming interfaces. The Solution must be delivered with a description of its database schema, API specifications and a complete set of technical documentation; the Client should be able to change the configuration of the System on its own.

2.1.12. Решение должно содержать API для выполнения следующих операций:

Управление учетной записью клиента (add\delete\update bundles, campaigns, contact profile, offers, accumulators, balances, activation, retrieve, transfer funds, transfer units, generate one time invoice, adjustment invoice, regular invoice, back out invoice).

Управление абонентом (add\delete\update contact profile, offers, phonebook, accumulators, balances, bundles, disconnect, find, fraud un\lock, home location operation, retrieve, suspend, swap primary offer, transfer, transfer funds/units, resume billing, retrieve history, suspend billing, swap subscriber external id, update balance, swap inventory, language code operations, ping

The Solution must have an API to perform the following operations:

Customer account management (add \ delete \ update bundles, campaigns, contact profile, offers, accumulators, balances, activation, retrieve, transfer funds, transfer units, generate one-time invoice, adjustment invoice, regular invoice, back out invoice).

Subscriber management (add \ delete \ update contact profile, offers, phonebook, accumulators, balances, bundles, disconnect, find, fraud un \ lock, home location operation, retrieve, suspend, swap primary offer, transfer, transfer funds / units , resume billing, retrieve history, suspend billing, swap subscriber external id, update balance, swap inventory, language code

32




operations, rating operations, charges operations). Платежи (create\delete\find\get\ profile create\

reverse\update\prepayment create). Счет-фактура (detail adjust, find, get, reissue,

reissue with charge). Пополнение (voucher\non-voucher: recharge

account customer, recharge subscriber customer). CRM (account session, case, add note, add crm

note, find customer, find by account, get customer, case update, find by account session\subscriber) все возможные функции должны быть доступны через API.

Связки (find, retrieve) Calling circle (find, find by subscriber, remove

member etc). Unbilled (NRC, RC, настройка использования). Сервисный заказ (отменить, найти, обновить,

создать). Adjustment (Cancel, Find, Update). Возможность реализации пользовательского

API

operations, ping operations, rating operations, charges operations).

Payments (create \ delete \ find \ get \ profile create \ reverse \ update \ prepayment create).

Invoice (detail adjust, find, get, reissue, reissue with charge).

Top-up (voucher \ non-voucher: recharge account customer, recharge subscriber customer).

CRM (account session, case, add note, add CRM note, find customer, find by account, get customer, case update, find by account session \ subscriber), all possible functions should be available through the API.

SIM/MSISDN bundles (find, retrieve). Calling circle (find, find by subscriber, remove

member). Unbilled (NRC, RC, usage settings) Service order (cancel, find, update, create). Adjustment (cancel, find, update). Possibility to implement custom API

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

The Solution should ensure scalability through the use of modern programming tools that enable the company to run databases of any size and do not limit in any way the volume of document workflow, the network capacity or the number of users the System can accommodate. The Solution should be able to serve up to 12 million subscribers, subject to the recommended hardware requirements.

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

Built on a modular architecture, the Solution should enable functionality upgrades through new modules, with modules being designed and development in a manner ensuring they depend on each other as little as possible and can be deployed separately.

2.1.15. Решение должно соответствовать требованиям отказоустойчивости:

The Solution must meet the following availability requirements:

33




Резервирование базы данных должно осуществляться с использованием технологии резервного копирования;

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

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

Database backups should be performed using backup technology.

The Solution should ensure continued operation regardless of scheduled maintenance for upgrades, software updates, recovery and other activities.

Individual modules of the Solution should be able to run offline (regardless of the state of the database) and load and process the accumulated data as soon as the database goes back online.

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

информации авторизации; Создание, блокировка и удаление

пользователей; Управление атрибутами пользователя и

группами пользователей; Настройка и контроль политики паролей; Аудит действий пользователей; Уведомление о событиях, связанных с

пользователем; Центральная точка для поддержки

пользовательских привилегий; Управления ролями;

The Solution should ensure security by providing protection against unauthorized access to software and databases via multi-level password protection and assignment of access levels using standard operating system tools and internal access control mechanisms that guarantee a high degree of information security. The Solution must meet the following basic security requirements: Centralized authorization information storage; User creation, blocking and removal; User attributes and user groups management; Password policy configuration and enforcement; Audit of user actions; Notification of user-related events; A central point to support user privileges; Role management; Management of access predicates; User rights storage; Single access point support; User authentication; Verification of user access keys (tokens); Routing user requests; Enrichment of request headers with user data; Quota control requests;

34




Управление предикатами доступа; Хранение прав пользователей; Поддержка единой точки доступа; Аутентификация пользователей; Верификация ключей доступов (токенов)

пользователя; Маршрутизация пользовательских запросов; Обогащение заголовков запросов данными

пользователей; Запросы контроля квот; Сбор статистики запросов; Защита от DDoS-атак; Защита от повторения через настраиваемый

промежуток или количество замен паролей; Контроль разрешенных IP-адресов.

Collection of data query statistics; Protection against DDoS attacks; Protection against password guessing attacks

through a configurable interval or a limit on the number of consecutive password changes;

IP address control;

2.1.17. Решение должно обеспечивать архивацию данных с учётом следующих требований: предоставление абоненту всех необходимых

данных, на основании которых был выписан счет, в течение не менее трех лет;

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

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

The Solution should provide data archiving capabilities that meet the following requirements: Providing the subscriber with all the necessary

data on the basis of which the invoice was issued for at least three years;

Providing access to financial information (data on calls, sessions and charges) for at least three years;

Providing access to invoices and account data for at least three years.

2.1.18.2

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

The Solution should be able to offload voice and data usage, authorization data and charges, status of account/subscribers balances sorted by rated date and also be able to quickly load such data from archives and dynamic selection of columns.

2.1.19. Обеспечение выполнения аудита событий безопасности с возможностью интеграции с внешними хранилищами логов (SIEM).

The Solution should enable auditing of security events with the ability to integrate with external log repositories (SIEM).

35




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

The Solution should include a subsystem and an administrator UI for managing and conducting audits of operations being performed.

2.1.21..

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

The following functionalities must be supported for audit purpose:3 Maintaining a user directory; Maintaining data on operations; Defining audit rules; Viewing audit results.

2.1.22..

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

The Solution should have built-in health monitoring mechanisms for the system and all of its modules, components and services in order to ensure that services function properly by detecting failures in modules, components and services of the system, determining the location and nature of failures, as well as preventing possible failures through the use of proactive monitoring.

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

системы по протоколам: SQL*Net, HTTP/HTTPS, SNMP или др.;

Обработка данных мониторинга – анализ значений, принятие решений в автоматическом режиме;

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

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

The Solution should support the following monitoring functionalities: Collecting monitoring data from modules and

system components via SQL * Net, HTTP / HTTPS, SNMP or others;

Processing monitoring data, including KPI metrics analysis and automatic decision-making;

Providing notifications via available channels (SMS, e-mail, etc.) to responsible employees and / or displaying information in a graphical interface;

Flexibly configuring automatic responses to events reported via monitoring tools and identified during monitoring data analysis.

36




2.1.24. Решение должно поддерживать интеграции с мониторинговыми системами (например, Zabbix, Grafana, Netact, Netcool и.т.д).

The Solution should support integration with monitoring systems (for example, Zabbix, Grafana, Netact , NetCool).

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

The Solution should not have any limitations that would make it impossible to properly adjust System’s internal procedures, reporting and business processes to a changing regulatory environment.

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

The Solution should have documented capabilities for integration with external information systems, telecommunications equipment and service software, with internal ERP/Accounting systems, third-party service delivery and payment processing platforms.

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

The Solution should be flexible enough to enable software components to be implemented and deployed independently of other components. New components should be implemented without changing the main program code and not require additional data migration.

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

The Solution should have well-documented capabilities for flexible customization, tuning and adaptation, allowing to support the future CSP requirements that may not be formulated at the time of implementation.

3. Функциональные требования Functional requirements

37

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

All of the requirements below should be included in the decision, but should not be limited to them. All restrictions in the decision should be explained

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

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

This section provides high-level descriptions of the functional requirements for the Solution. This section should not be construed considered as a final and comprehensive list of functional requirements.

The functional capabilities of the Solution must comply with TM Forum’s standards and recommendations for information technologies in the telecommunications industry, including the reference telecom application map (TAM).

3.1.3 Общие требования General requirements

Соответствие/Compliance(FC/NC)

Комментарии/Comments

3.1.1. Решение должно отвечать требованиям к архитектуре, интерфейсам и функциональности, отраженным в спецификациях 3GPP (в частности: TS 32.240, TS.32.296) и поддерживать следующие основные функции:

Account Balance Management Function (ABMF) обеспечивающей хранение и управление услугами предоставляемым абонентам;

Rating Function (RF) обеспечивающей поддержку расчета предварительной и окончательной стоимости предоставления услуг;

Online Charging Function (OCF) обеспечивающей поддержку сессионного и событийного кредитного контроля.

The Solution must meet the architecture, interface and functionality requirements defined in 3GPP specifications, such as TS 32.240, TS.32.296, and support the following main functions:

Account Balance Management Function (ABMF) providing storage and management of services provided to subscribers;

Rating Function (RF) providing support for calculating the preliminary and final cost of providing services;

Online Charging Function (OCF) providing support for session and event credit control.

3.1.2. Решение должно поддерживать обслуживание клиентов различных сегментов (B2B, B2С, B2X, B2G, B2B2X) в едином решении.

The Solution should be able to serve customers in multiple segments (B2B, B2C, B2X, B2G, B2B2X) in a single installation.

3.1.3. Решение должно поддерживать различные типы клиентов, такие как предоплаченная, постоплатная, конвергентная, гибридная и

The Solution must support various types of customers, such as prepaid, postpaid, convergent, hybrid and virtual account. The Solution should

38




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

provide an opportunity to support unified customer service capabilities for selling, managing and charging for telecommunication services.

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

The Solution should support the migration of subscribers from prepaid to postpaid and vice versa at any time by changing the payment system without transferring the customer between individual modules or installations and preserving the entire history.

3.1.5. Все отчеты в предлагаемом решении должны основываться на конвергентной абонентской базе.

All reports in the proposed Solution should be based on a convergent subscriber base.

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

The Solution should have the same user interfaces for prepaid and postpaid customer service.

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

The Solution should support the creation and management of complex customer hierarchies. The customer hierarchy allows you to carry out settlements with the customer (to serve large corporate customers), but at the same time keep records of subscriber charges.

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

Многоуровневая иерархия учетных записей; Возможность обозначить любой уровень в

иерархии точку выставления счета; Возможность распределить ответственность

за расходы на различные уровни аккаунта; Поддержка неограниченного количества

уровней в иерархии Consumer/Family.

The Solution must support a hybrid account and hierarchy concept. The Solution should support at least the following account hierarchy requirements:

A multi-level hierarchy of accounts; The ability to use any level in the hierarchy as a

charging point; The ability to allocate responsibility for charges

across different levels of an account. Support for an unlimited number of levels in the

Consumer/Family hierarchy.

39




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

The Solution should provide the ability to create an individual (personal) account for members of the hierarchy with separate top-up rules and separate charging rules for splitting charges between a personal and hierarchical account.

3.1.10. Решение должно поддерживать совместное использование общего пула средств между членами иерархии. Администратор иерархии должен управлять следующими действиями на членах иерархии:

Определяет или корректирует лимиты расходов для каждого отдельного члена группы;

Контроль разрешенных услуг отдельных членов;

Контролирует пополнение баланса.

The Solution should support sharing of a common balance between members of the hierarchy. The hierarchy administrator should be able to manage hierarchy members as follows:

Define or adjust spending limits for each individual member of the group;

Control access to services and availability for individual members;

Control balance top-up and recharge.

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

The Solution should support lifecycle model of main entities – customer, account, subscriber.

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

The Solution should apply configurable lifecycle statutes and switch rules between them.

3.1.13. Решение должно поддерживать связь жизненных циклов лицевого счета и абонента

Solution must support connection between account and subscriber lifecycles.

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

It’s should be able to adjust permissible operations and actions with customer and subscriber statuses.

3.1.15. Решение должно поддерживать такие процессы, как:

прием информации о подключениях новых абонентов от дилеров;

расчет абонентской платы; контроль за наступлением "финансовой

The Solution should support the following processes:

receiving information about new subscriber activations from dealers;

subscription fee calculation; imposing and revoking of "financial blocking"; processing by payments types received in the

40




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

платежа; автоматическое закрытие неактивных

абонентов в течение длительного периода абонентов и отключение платного контента и списание задолжности.

system; automatic termination of subscribers who have

been inactive for a long time and disabling content and clearing debt.

3.1.16. Решение должно поддерживать историчность изменения основных сущностей и их атрибутов.

The Solution should be able to maintain historical records of changes in the core entities and their attributes.

3.1.17. Решение должно поддерживать языковую кодировку Unicode для отображения специальных символов.

The Solution must support Unicode encoding to ensure special characters are displayed correctly.

41

3.2.3

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

Charging and Balance Management Requirements



3.2.1.3

Решение должно поддерживать следующие режимы тарификации:

онлайн-тарификация – по информации, получаемой в режиме реального времени в рамках тарификационной сессии от сетевых элементов телеком сети и сервисных платформ;

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

The Solution should support the following charging modes:

Online charging: A charging mechanism where charging is based on information that is received in real time during a rating session from network elements and service platforms;

Offline charging: A charging mechanism that uses information received in requests or xDR files from service platforms.

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

The Solution should support online charging for all types of customers and use offline charging only for reconciliation and processing of events that were not received in online mode.

3.2.3. Решение должно поддерживать DIAMETER протоколы в соответствии с:

IETF RFC-3588 "Diameter Base Protocol"; IETF RFC-4006 "Diameter Credit-Control

Application".

The Solution must support DIAMETER protocols as specified in:

IETF RFC-3588: "Diameter Base Protocol"; IETF RFC-4006: "Diameter Credit-Control

Application".3.2.4. Решение должно поддерживать CAMEL phase 2,

3 протоколы в соответствии с 3GPP спецификациями:

TS 02.78 R98, TS 03.78 R98, TS 22.078, TS 23.078, TS 29.078.

The Solution must support CAMEL phase 2, 3 protocols in accordance with 3GPP specifications:

TS 02.78 R98, TS 03.78 R98, TS 22.078, TS 23.078, TS 29.078.

3.2.5. Решение должно поддерживать интерфейс общей сигнализации OKC 7/ SS7 с гибкой настройкой параметров, а также SIGTRAN/M3UA и SIGTRAN/M2PA.

The Solution must support the SS7 common signaling interface with flexible parameter settings, as well as SIGTRAN/M3UA and SIGTRAN/M2PA.

3.2.6. Решение должно обеспечивать возможность ведения разных типов контрактов в одной платформе: Prepaid, Postpaid, Hybrid, M2M.

The Solution should provide the ability to manage different types of contracts in one platform: Prepaid, Postpaid, Hybrid, M2M.

42

3.2.3





3.2.7. Решение должно обеспечивать возможность рейтинга: онлайн и минимум двух типов оффлайн-тарификаций для всех типов событий (звонки, смс , интернет и.т.д) для всех типов абонентов (prepaid, postpaid, hybrid, M2M).

The Solution should provide the possibility of hybrid rating: online and at least 2 types of offline charging for all types of activities (voice call, SMS, internet and etc) for all type of subscribers (prepaid, postpaid, hybrid, M2M).

3.2.8. Решение должно поддерживать авторизацию в реальном времени. Каждая попытка обслуживания (голос, данные, Интернет, SMS, MMS, видеозвонок, внешний интерфейс и т. д.) должна быть авторизована в режиме реального времени для абонентов с предоплатой, постоплатой и гибридными аккаунтами. Должна быть обеспечена поддержка дополнительной авторизации (реавторизации) в ходе сессии по истечению квоты. Идентификация абонента должна поддерживать различные параметры для определения абонента, такие как MSISDN, IMSI, IP-адреса и комбинации упомянутых параметров.

The Solution must support real-time authorization. Each service attempt (voice, data, Internet, SMS, MMS, video call, external interface, etc.) must be authorized in real time for prepaid, postpaid and hybrid accounts. This includes additional authorization (reauthorization) during the session. Subscriber identification should be based on various parameters, such as MSISDN, IMSI, IP addresses, and combinations of these parameters.

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

The Solution must track, recognize and impose credit limit restrictions on all subscribers, as well as allow or deny access to services.

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

The Solution should be able to terminate or refuse to establish a session due to insufficient balance or credit limit reached. The Solution should prevent overuse below the minimum value (for prepaid) or exceed the credit limit (for postpaid).

3.2.11. Решение должно поддерживать следующие возможности управления вызовами/сессии:

Мониторинг вызовов/сессий: в реальном времени;

Предварительное уведомления (перед началом вызова/сессии);

The Solution should support the following call control/internet session features:

Real-time call/internet session monitoring; Advance notice (before the start of the

call/session); Final notification (after the end of the

43

3.2.3





Завершающее и уведомление (после завершения вызова/сессии), а также уведомление онлайн;

Активация номера по первому вызову (активности, в зависимости от ЖЦ);

Трансляция номера для номеров доступа.

call/session) and as well as online notification; Number activation on first call(usage, based on

life cycle configuration); Number translation for access numbers.

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

The Solution must support balance reservation management. Reservation must be managed independently for each balance, for example, reservation for an SMS, reservation for a voice call, etc. The Bidder must explain the logic behind multiple simultaneous balance reservations for parallel sessions/events. It should be possible to set a minimum reservation amount in traffic or currency units.

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

The Solution must support a flexible balance management mechanism to allow configuration and use of multiple balances.

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

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

Разрешить ограничение использования баланса для определенной деятельности (например, SMS, голос, MMS или только в непиковые часы и только для локального использования и т. д.).

The Solution must support real-time balance management for prepaid and postpaid subscribers, including the ability to:

To configure which balances to use and in what order. For example, free minutes should be used before chargeable ones.

Apply balance usage restrictions for certain activities (for example, SMS, voice, MMS, or only during off-peak hours and only for local calls, etc.).

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

The Solution should be able to send notifications, depending on the subscriber, service and balance

44

3.2.3





и состояния баланса, во внешнюю систему в режиме реального времени или посредством генерации CDR.

status, to an external system in real time or by generating a CDR.

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

BSS must store Notification history with generated time, sent time, and store duration not less than 3 months in current load profile.

3.2.17. Решение должно поддерживать текстовое уведомление через SMS и USSD. Например: при использовании Х% бонуса, X дней до истечения срока действия бонуса, после каждого списания стоимости звонка / транзакции и т. д. Решение должно отправлять уведомления об окончании звонка с возможностью различать тексты для разных подгрупп (на основе следующих критериев: тарифные планы, постоплата и предоплата, используемый тип услуги (SMS, данные и т. д.). Определение подгруппы должно быть динамичным (на основе критериев кампании). Система также должна иметь возможность изменять статус абонента, когда основной баланс достигает порогового уровня. Уведомления должны поддерживать различные языки с автоматическим выбором.

The Solution should enable text notifications via SMS and USSD. For example: after using a certain amount of bonus; a certain number of days before a bonus expires; after charging a call / transaction, etc. The Solution should be able to send end-of-call notifications using different texts for different subgroups (based on various criteria, such as rate plans, postpaid and prepaid, type of service – SMS, data, etc.) Subgroups should be defined dynamically (based on campaign criteria). The System should also be able to change the status of a subscriber when the subscriber’s main balance reaches a certain threshold level. Notifications must support different languages with automatic selection.

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

Customer type-specific balance threshold notifications, with customers of each type being assigned their own thresholds for various notifications.

3.2.19. Уведомление о пороге достижения скидки должно содержать такие данные, как остаток по скидке, общий объем, информация об абоненте.

The threshold notification for achieving the discount should contain such data as the balance of the discount, total amount, information about the subscriber.

3.2.20. Возможность отправлять уведомления нескольким внешним сторонним приложениям/интерфейсам.

The ability to send notifications to multiple external third-party applications/interfaces.

45

3.2.3





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

It must be possible to send notifications to a group of subscribers according to a predefined list.

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

The Solution should be able to ensure that the depletion of one balance does not affect the ability of the subscriber to use other services if there is a positive balance for this service. Even if there are no funds left on the main balance, the services can be used if there are available funds or resources on other corresponding bonus balances.

3.2.23. Решение должно обладать развитой системой тарификации стоимости совершенных вызовов и интернет сессий. При этом должны быть реализованы:

Возможность тарификации по объему трафика и по длительности сессии.

Возможность тарификации по скорости передачи данных.

Возможность поминутной/посекундной тарификации.

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

Возможность хранения данных округленных и неокруглённых в БД

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

Возможность тарификации на основе событий (например, загрузка контента).

The Solution should have a fully functional rating system for charging calls and Internet sessions, including:

The possibility of charging according to the volume of traffic and duration of session.

Possibility of charging according to data transfer rate

The possibility of per-minute rating/per-second. Flexible configuration of rounding methods and

duration of services in online and offline rating. The ability to store data rounded and unrounded in

the database The use of various features of the subscriber and

the session in the process of charging any traffic. In particular, the identifiers of the subscriber and customer, offline indication, the location of the subscriber, special functions (favorite number, hierarchy, groups) indication, time zone.

Event based rating (for example, downloading content).

Rating by connection type (fax, streaming video, ftp, torrent, html, data call (CSD) ).

Support for price definition depending on the direction (based on the dialed number, calls within the group (CUG, account, parent account, within

46

3.2.3





Возможность тарификации по типу соединения (факс, потоковое видео, ftp, torrent, html, дата звонок (csd)).

Поддержка задания стоимости в зависимости от направления (на основании набранного номера, звонки внутри группы (CUG, account, parent account, внутри т.п.), Friends and Family).

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

Поддержка тарификации на специальные (платные/бесплатные) номера.

Возможность настройки тарификации за счет вызываемого абонента.

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

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

(например, 1-я минута – 1000сум, начиная со 2-й по 500 сум/мин.).

Поддержка возможности использования различных правил округления на pay-as-you-go и на специальных предложениях (скидках).

Возможность тарификации в зависимости от региона нахождения абонента и по его локации (по cell_id).

Возможность тарификации в зависимости от типа аккаунта или пакета.

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

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

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

Возможность создания интернет пакетов

TP), Friends and Family). Support for the price definition based on the

parameters of the customer/subscriber and assigned products/offers.

Support special (paid/free) numbers charging. Support CPP/charging for called party (B-

subscriber). Support for using custom rating functions. Support rounding schemes. Support for telescopic tariffs (for example, the 1st

minute – 1000sum, starting from the second at 500 sum/min).

Support for the possibility of using various rounding rules on pay-as-you-go and on special offers (discounts).

The possibility of charging depending on the region of location

The subscriber and by his location (by cell_id). The possibility of charging depending on the type

of account or package. The possibility of charging based on specific time

of day. The possibility of charging based on the overall

volume (aggregate and multi-level rating). The ability to create individual billing periods for

a given segment of subscribers (for example, for individuals).

The ability to create Internet packages (one-time fee) and Internet options (daily/monthly subscription fee).

Rating based on time of the day/day of week or calendar. For example, on working days from 8:00 to 19:00 - x, from 19:00 to 23:00 - y, from 23:00 to 8:00 - z. On weekends, another price.

Rating based on the time of day and type of day, taking into account the aggregated volume. For example, from 8:00 to 19:00 - “x”, but if more than 10 units are consumed, then “y”.

The capability to configure volume in offers. For 47

3.2.3





(разовый платеж) и интернет опций (ежедневная/ежемесячная абонентская плата).

Зависимость стоимости тарифицируемого ресурса от времени суток и типа дня. Например, в рабочие дни с 8:00 до 19:00 – x, с 19:00 до 23:00 – y, с 23:00 до 8:00 – z. В выходные дни – другая стоимость.

Зависимость стоимости тарифицируемого ресурса от времени суток и типа дня с учетом объема потребления. Например, с 8:00 до 19:00 – «x», но если потреблено более 10 тарифицируемых единиц, то «y».

Возможность изменения объема услуги. Например, 1 Мбит/с безлимитного доступа стоит х. Если покупается y Мбит/с, то стоимость «y*x».

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

Возможность применения нескольких налогов (НДС, Акцизный налог, налог на абонентский номер и т.д.). Поддержка настройки правил списания с

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

другие аккаунты, отличные от текущего на основе предопределённых правил

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

Поддержка офлайн тарификации Поддерживать ценообразование в коридоре,

то есть специальные тарифы для выбранных клиентов для использования между указанными местоположениями, например, поддерживать тарифные планы типа «Friends&Family».

Возможность тарифицировать звонки по

example, 1 Mbps unlimited access costs x. If we buy y Mbps, then the cost is "y * x".

Ability to limit bonus / included traffic by time and day. For example, only traffic from 0 to 8 hours on weekdays and around the clock on weekends will be considered as a bonus.

The capability to apply several taxes (VAT, Excise tax, tax on subscribers and etc).

Support for setting up rules for write off from personal and corporate balance.

Support for consumption limits per subscriber in case of writing off from a corporate account.

Support for offline charging. Support pricing in the corridor, that is, special

rates for selected customers for use between the indicated locations, for example, support rate plans such as “Friends & Family”.

The ability to charge calls at the old and new rates based on the effective date.

Support for different reservation sizes for the same traffic case depending on various parameters (for example, rating groups in data usage).

48

3.2.3





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

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

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

The Solution should create fault filters for non rating faults (free of charge income calls or zero-duration calls).

3.2.25. Решение должно поддерживать одновременные сеансы и сервисы.

The Solution must support concurrent sessions and services.

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

The Solution should support the simultaneous assessment and charging of various simultaneous but independent voice, data and additional services in real time with proper synchronization of charging operations.

3.2.27. Решение должно поддерживать динамическое обновление параметров сервиса (предоставленных единиц, времени удержания квоты, QoS и т. д.) в зависимости от поведения пользователя.

The Solution should support dynamic updating of service parameters (units provided, quota retention time, QoS, etc.) depending on user behavior.

3.2.28. Решение должно быть способным в режиме реального времени взимать плату не только с исходящих, но также с входящих вызовов (если таковые имеются). Акции/скидки в режиме реального времени также должны применяться для MO&MT событий. Должна быть возможность установки приоритета скидок.

The Solution must be able to charge in real time a fee not only from outgoing, but also from incoming calls (if any). Real-time promotions/discounts should also apply for MO & MT events. It should be possible to prioritize discounts.

3.2.29. Скидки должны быть применимы как для услуг абонента, так и клиента. Скидки могут изменять или обнулять стоимости различных usage-based

Discounts should be applicable for both subscriber and customer services. Discounts can change or nullify the cost of various usage-based

49

3.2.3





услуг связи, а также иметь возможность распространения на не usage-based услуги, например, абонентскую плату или разовые начисления.

communication services, as well as being able to extend to non-usage-based services, for example, a monthly fee or one-time charges.

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

The Solution should support the order of several packages at the same time. The expiration period for each ordered package must be monitored separately (for example, when a new package is ordered, the expiration date of the package also increases).

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

The System should have a function of prolonging packets (balance transfer to the next month or reset ) when the packet/balance is updated on time) with data/voice services. Prolongation applicability should be configurable.

3.2.32. Система должна поддерживать установку даты истечения пакетов по времени.

The System should support setting the expiration date of packets by time.

3.2.33. Решение должно поддерживать ведение нормативно-справочной информации для тарификации (в том числе путем импорта из внешних источников):

справочник типов тарифных планов; справочник тарифных планов и их

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

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

The Solution should support the maintenance of reference information required for charging (manually or via import), including:

Rate plan types; Rate plans and their parameters; Services and their parameters; Time ranges for rating; Call directions; Toll free numbers; Short numbers; Tariff options and their parameters; Tariff discounts; Charge types.

3.2.34. Решение должно поддерживать возможность ведения и массового ведения тарифов для учета

The Solution should support the ability to maintain and mass maintaining tariffs for accounting services.

50

3.2.3





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

администратор системы должен иметь доступ к ним в определенном временном интервале с даты их вступления в действие (ввода в систему) до отмены;

должна поддерживаться возможность заменять их другими тарифами (того же типа);

тарифы должны распространяться на определенную категорию клиентов/абонентов или дополнительную атрибутику;

тарифы должны распространяться на определенных абонентов;

должна быть возможность связывать различные типы тарифов в различные тарифные планы.

Different types of tariffs have common features, in connection with which:

The system administrator must have access to them in a certain time interval from the date of their entry into force (entry into the system) to cancellation;

The ability to replace them with other tariffs (of the same type) should be supported;

Tariffs should apply to a certain category of customers/subscribers or additional attributes;

Tariffs should apply to certain subscribers; It should be possible to link different types of

tariffs into different rate plans.

3.2.35. Решение должно поддерживать возможность тарификации в CUG (Closed User Group, Закрытых групп пользователей).

The Solution should support the ability to charge in CUG (Closed User Group).

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

The Solution should support the possibility of preferential charging between subscribers belonging to one corporate customer.

3.2.37. Решение должно поддерживать возможность отката и повторной тарификации событий.

The Solution should support the ability to roll back and re-charge events.

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

The Solution should support the ability to convert one type of traffic in packets to another, for example, minutes to megabytes.

3.2.39. Решение должно обеспечивать настраиваемую логику обработки остатков пакетов и абонентской платы при смене продукта, включая:

обнуление и расчет за полный период; пропорциональный перенос объема и

The solution should provide customizable logic for processing packet remains and monthly fees when changing a product, including:

Zeroing and calculation for the full period; Proportional transfer of the volume and value of

the package;

51

3.2.3





стоимости пакета; разрешение переключения с начала нового

периода.

Postponing of switching to the beginning of a new period.

3.2.40. Решение должно поддерживать процессы перевода части неиспользованного/ доступного трафика между абонентами.

The Solution should support the processes of transferring part of the unused/available traffic between subscribers.

3.2.41. Решение должно обеспечивать поддержку периодических начислений (абонентской платы) и разовых начислений.

The Solution should provide support for recurring charges (monthly fees) and one-time charges.

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

The subscription fee is charged to each subscriber for each service of a telecom operator used by him individually in accordance with the subscriber's rate plan.

3.2.43. Для расчета периодических начислений поставляемое Решение должно поддерживать следующую функциональность:

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

Авансом в начале месяца; Пропорционально по заказу; Авансом с пропорционализацией за

первый месяц; Авансом с пропорционализацией с

ежедневным приращением; Авансом с даты подключения; Авансом со сдвигом периода; Авансом, с уводом абонента в

блокировку; Поддержка нескольких вариантов расчета

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

To calculate periodic charges, the delivered Solution must support the following functionality:

Support for several methods of charging a monthly fee according to the list below:

Advanced payment at the beginning of the month;

Proportional to order; Advanced payment with proportionalization

for the first month; Advanced payment with proportionalization

with daily increment; Advanced payment from the date of

connection; Advanced payment with a period shift; Advanced payment, with the withdrawal of

the subscriber to the lock; Support for several options for calculating the

monthly fee according to the list below: Subscription fee n-per day; Subscription fee for n-days; Subscription fee per n-week; Subscription fee per n-montly ; Subscription fee per n-quarterly; Subscription fee for the n-half-year

52

3.2.3





Поддержка различных периодов снятия абонентской платы (с поддержкой выравнивания периодов как по дате подключения, так и календарное).

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

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

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

Subscription fee for the n-year. Support for various periods of subscription fees

(with support for period equalization both by connection date and calendar);

The ability to configure redefinition of the amount of a charge from specified conditions (with the ability to support custom functions);

The ability to change the Subscription monthly fee rate during the operation of periodic charge.

The ability to set a fee for the activation of periodic charges.

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

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

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

Условно перенаправлены на учетные записи в пределах или через иерархию учетных записей.

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

The Solution should support the usual configuration of periodic and one-time charges for the subscriber in real time or not in real time. The Solution must support the following functionality:

User-specified frequency of charges. A few preliminary cycles. Support prorate. Automatically corrected for insufficient balances

in accordance with the threshold values determined by the subscriber. The balance can be updated by transferring money from another subscriber or from a bank account or some other sources.

Conditionally redirected to accounts within or through the hierarchy of accounts.

Prioritization among several recurring charges. If a customer is charged more than one periodic commission, it should be possible to determine which one will be charged first.

The ability to configure redefinition of the amount of charge from the given conditions;

The possibility of processing and accounting for charges charged by an external billing system / external billing module;

The ability to customize subscription fees in

53

3.2.3





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

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

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

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

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

пополняемым. Базовая стоимость регулярного начисления

может зависеть от: тарифный план или пары исходный/целевой

тарифный план (для смены ТП); регион регистрации; операции (тип подключаемой услуги/офера); Итоговая (рассчитываемая) стоимость

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

детализации).

specific cases; The possibility of making adjustments to the

charges recorded in previous billing periods. should not be negative Applicable for the following operations:

change of rate plan SIM replacement order details user operations change of number renewal other one-time services, the list should be

updated. The base cost of regular charge may depend on:

rate plan or source / target rate plan pairs (for changing rate plan);

region of registration; operations (type of connected service /

offer). The total (calculated) charge cost depends on:

number of service units; period (for example, the number of months

when ordering a drilldown).

3.2.45. Решение должно поддерживать функцию ре-рейтинга на основе существующих CDR.

The Solution must support the re-rating function based on existing CDRs.

3.2.46. При ре-рейтинге должны учитываться состояние баланса, аккумуляторов и услуг клиента на дату CDR.

When re-rating should take into account the state of balance, accumulators and customer services at the date of CDR.

54

3.2.3





3.2.47. Решение должно поддерживать развитую систему различных скидок с возможностью просмотра истории их использования. Должны быть реализованы разнообразные механизмы предоставления скидок и бонусов:

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

период; скидки и бонусы на основе накопителей за

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

The Solution should support a developed system of various discounts with the ability to view the history of their use. A variety of mechanisms for providing discounts and bonuses:

discounts calculated during charging; discounts and bonuses following the results of the

billing period; the possibility of accumulating bonus points.

3.2.48. Решение должно обеспечивать корректный расчет налогов при предоставлении монетарных скидок

The Solution should ensure the correct calculation of taxes when providing monetary discounts

3.2.49. Решение должно обеспечивать предоставление скидок с динамическим объёмом в различных единицах – денежные средства, объёмы тарификации, периоды длительности.

The Solution should ensure the provision of discounts with dynamic volume in various units – money, rating volumes, periods of duration.

3.2.50. Решение должно давать возможность настраивать период действия накопителей (с учетом кратности) с поддержкой выравнивания по календарным правилам:

Суточные; Недельные; Месячные; Квартальные; Годовые. цикличные правила

The Solution should make it possible to configure the validity period of the drives (taking into account the multiplicity) with support for alignment according to calendar rules:

per diem; weekly; monthly; quarterly; annual. cycle/flexible

3.2.51. Система должна обеспечивать возможность ведения накопителей на уровне абонента и/или лицевого счета без обнуления накопления или после каждого действия. Накопление должно посчитать по кл-ву событиый, суммы пополнения.

The system should provide the ability to maintain drives at the subscriber and/or personal account level without resetting the accumulators or after each action. Accumulators should calculate by number of events, the amount of recharges/refills

3.2.52. Решение должно обеспечивать предоставление скидок группам клиентов/ абонентов с учётом

The Solution should ensure the provision of discounts to groups of customers/ subscribers taking into

55

3.2.3





суммарных потреблений услуг. account the total consumption of services.

3.2.53. Система скидок должна обладать следующими возможностями:

предоставление скидок на один абонентский номер и на все номера на одном лицевом счете;

предоставление скидок на тарифный план (пакет) и отдельные услуги;

предоставление абсолютных и относительных скидок (в виде суммы, либо процента);

предоставление однократных и периодически повторяющихся скидок;

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

The discount system should have the following features:

providing discounts on one subscriber number and on all numbers on one account;

providing discounts on the rate plan (package) and certain services;

The provision of absolute and relative discounts (in the form of an amount or a percentage);

The provision of one-time and periodically repeated discounts;

The ability to plan discount changes in future dates.

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

The discount system should support multiple discount mechanism, which allows automatically, online, to provide subscribers with discounts by crediting their accounts, depending on various conditions and their combination.

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

The Solution should provide the ability to provide discounts both on the total invoice amount and on individual invoice items.

3.2.56. Система скидок должна поддерживать блокировку потребления объемов при нахождении абонента в блокировке.

The discount system should support blocking the consumption of volumes when the subscriber is in the block.

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

Объёма типов начислений, зарегистрированных на лицевые счета абонентов или клиента;

Объёма типов платежей, поступивших на

The System of discounts should provide the possibility of forming a discount plan from elementary blocks, allowing to calculate the discount amount depending on:

the volume of charges registered in the accounts of subscribers;

the volume of payments received to the accounts of subscribers;

56

3.2.3





лицевые счета абонентов или клиента; объема и направление трафика . Объема звонков, смс и ММС по направлению

the volume and direction of traffic. The volume of calls, SMS and MMS in the

direction3.2.58. Система скидок должна обеспечивать

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

The System of discounts should provide calendar discounts (weekends, holidays, etc.), discounts on the time of day (various tariffs depending on the time of day).

3.2.59. Решение должно поддерживать перенос остатков скидок и обновлять/обнулять скидки. Применение настройки должны быть настраиваемыми

The Solution should support the transfer of discount balances and updated/reset discounts. Settings must be customizable

3.2.60. Решение должно поддерживать нотификацию абонентов при приближении и/или достижении порога накопителя в режиме онлайн.

The Solution should support notification of subscribers when approaching and/or reaching the accumulator threshold online.

3.2.61. Решение должно поддержать функциональность блокировки потребления определенного типа услуг, после исчерпания соответствующего объема (исчерпания всех объемов для данного типа услуги).

The Solution should support the functionality of blocking the consumption of a certain type of service, after exhausting the corresponding amount (exhaustion of all volumes for this type of service).

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

The System should ensure the availability of a predefined set of services with a zero or negative balance, including, but not limited to access to emergency services, customer service, payment methods and account refill pages, etc.

3.2.63. Система должна иметь возможность управления возможностью входящих/исходящих вызовов при нулевом или отрицательном балансе за определенный промежуток времени ( не весь блокированный период).

The System should be able to control the possibility of incoming/outgoung calls at zero or negative balance for a certain period of time (not the entire blocked period).

57

3.3. Требования к биллингу и платежам Billing and Payment RequirementsСоответствие/Compliance(FC/NC)


3.3.1. Решение должно обеспечивать следующие особенности при проведении биллинга:

расчет необходимой суммы оплаты по лицевому счету;

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

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

The Solution should provide the following features when conducting billing:

calculation of the required amount of payment on the account;

convergence of all types of services of one subscriber in a single invoice;

the possibility of billing for selected customer groups or customers belonging to a specific branch.

3.3.2. Решение должно поддерживать проведение биллинга за полный расчетный период для всех видов клиентов.

The Solution should support billing for the full billing period for type of clients.

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

The possibility of an extraordinary billing in relation to the selected customer.

3.3.4. Возможность проведения тестового биллинга The possibility of running test billing

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

The Solution should provide mechanisms for rolling back billing, conducting repeated billing. Rollback of billing should lead to rollback of relevant transactions. The rollback time should not exceed the billing time.

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

The ability to roll back for all types of billing: both regular and extraordinary.

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

The possibility of forming billing discounts for any billing (both monthly and extraordinary), the coefficient value of which determined by various parameters (for example, by the number of subscribers, by the number of unpaid bills).

3.3.8. Фиксация результатов всех расчетов. Recording the results of all calculations.

3.3.9. Автоматическая генерация счетов по введенным Automatic generation of accounts according to the

58



условиям (критериям). entered conditions (criteria).

3.3.10. При выполнении биллинга должен производится расчет биллинговых скидок на уровне клиента/абонента/услуг и создание биллинговых счетов и счет-фактур за выбранный период в CRM.

When performing billing, billing discounts must be calculated on account, subscribers, additional services level and bills and invoices created for given period through CRM.

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

Flexible settings for the generation of Acts of rendered services and invoices for payment for various tariffs and services.

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

The Solution should support billing and posting to enable generation of monthly account balance reports for customers and on-demand balance reports in response to third-party system requests.

3.3.13. Решение должно обеспечивать следующие возможности по управлению процессом биллинга:

Формирование блоков клиентов для проведения биллинга

Отслеживание статуса проведения биллинга по блокам

Ведение статистики по итогам биллинга

The solution should provide the following capabilities for managing the billing process:

• Formation of customer blocks for billing

• Tracking the status of billing by blocks

• Statistics on the results of billing

3.3.14. Решение должно обеспечить расчет закрывающего баланса лицевого счета по итогам биллинга и расчет открывающего баланса нового периода. Эти балансы должны совпадать.

The Solution should ensure the calculation of the closing balance of the account based on the billing results and the calculation of the opening balance of the new period. These balances must match.

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

The Solution should provide summary statistics on the results of billing indicating the number of processed accounts, generation status, number of errors, start and end dates of generation.

3.3.16. Решение должно предусматривать следующие варианты отката биллинга:

откат результатов биллинга (ежемесячного

The Solution should include the following billing rollback options:

rollback of billing results (monthly or

59



или внеочередного); откат счета клиента в последнем биллинговом

цикле; откат результатов биллинга по диапазону

клиентов; откат биллинга по единой иерархии клиентов; откат последнего биллингового счета.

extraordinary); rollback of the customer’s account in the last

billing cycle; rollback of billing results for a range of customers; rollback billing in a single hierarchy of customers; rollback of the last bill.

3.3.17. Решение должно учитывать в счете все платежи, поступившие от клиента за заданный период, все начисления за услуги связи, оказанные в тот же период, и все корректировки:

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

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

The Solution should take into account all payments received from the customer for a given period, all charges for communication services provided in the same period, and all adjustments.

The billing process must not miss any single transaction;

Transactions with a date out of the cycle parameters should not be included. Transactions must be included in their billing cycle.

3.3.18. Решение должно поддерживать управление следующими видами корректировок:

корректировки платежей; корректировки начислений текущего и

прошлых биллинговых периодов; корректировки при переводе баланса с

одного на другой лицевой счет; корректировки при выводе денежных

средств с лицевого счета на руки (вывод средств).

The Solution should support the management of the following types of adjustments:

payment adjustments; adjustments to the charging of the current and

past billing periods; adjustments when transferring the balance from

one to another account; adjustments for the withdrawal of funds from the

account on hand (withdrawal of funds).

3.3.19. Необходимо, чтобы в поставляемом Решении имелась финансовая система и отдельное автоматизированное рабочее место для работы с ней.

It is necessary that in the delivered Solution there should be a financial system and a separate system role for working with it.

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

The System should provide the possibility of forming a savings account, which reflects balances and all customer turnover for the previous billing period.

60



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

The System should provide the ability to generate documents: regular invoices, one-time invoices, corrective invoices, invoices, and others.

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

Полную информацию по балансу клиента; Сумму учтенных платежей по клиенту

текущего периода расчета; Сумму всех начислений текущего периода

расчета; Сумму всех корректировок текущего периода

расчета; Сумму всех вызовов текущего периода

расчета; Сумму задолженности клиента.

The System should store, manage and allow to receive the summary financial information on the customer, in part comprising:

Full information on the balance of the customer; The total amount of recorded payments for the

customer of the current settlement period; The sum of all charges of the current settlement

period; The sum of all adjustments to the current

calculation period; The sum of all calls of the current billing period; The amount of customer debt.

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

The System should support accounting-like logic in terms of charges, distribution of advances, reports, information uploads.

3.3.24. Система должна поддерживать возможность учета налогов, которые взимаются в соответствии с налоговым законодательством Республики Узбекистан.

The System should support the ability to account for taxes that are levied in accordance with the tax laws of the Republic of Uzbekistan.

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

The System should support flexible adjustment of taxation schemes, a list of taxes and the sequence of their application, with the possibility of setting individual schemes for each customer.

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

Information about the tax scheme for the customer should be available to the operator through the Web-GUI interface.

61



3.3.27. Система должна поддерживать различные виды налогов при начислении.

The System should support various types of taxes during charge.

3.3.28. Налоговые сборы должны основываться на налоговой категории, относящейся к клиенту, и по типу услуги (Голос, GPRS, SMS и т.д.).

Tax fees should be based on the tax category related to the customer and by type of service (Voice, GPRS, SMS, etc.).

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

The tax category of the customer should mean the definition of the formula / percentage and tax calculation modes (exemption from payment tax, single tax, several taxes).

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

The tax may be calculated on charges or top-ups; both methods must be implemented in the same system for different types of customers (subscribers, companies, etc.).

3.3.31. Система должна поддерживать регулярный налог.

The System must support regular tax.

3.3.32. Система должна поддерживать налог включительно (ставка налога * начисление)

The System must support tax inclusive (tax rate * charge)

3.3.33. Система должна поддерживать налог с учетом (налоговая ставка / (1 + налоговая ставка) * сумма сбора).

The System should support tax taking into account (tax rate / (1 + tax rate) * fee amount).

3.3.34. Система должна в принципе поддерживать возможность построения процессов переноса мобильных номеров – MNP (Mobile Number Portability)

The system should, in principle, support the ability to build mobile number transfer processes - MNP (Mobile Number Portability)

3.3.35. Поддержка интеграционной совместимости со сторонними ERP-системами по итогуБиллинга

Support for integration compatibility with third-party ERP-systems based on Billing data

62

3.4. Система управления печатными формами и счет-фактурами

Document Formatting and Invoice Management System



3.4.1. Решение должно содержать набор стандартных бухгалтерских документов в соответствии с отраслевыми требованиями и требованиями действующего законодательства:

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

Счет-фактура – документ, подтверждающий факт «отпуска» услуг или материальных ценностей клиенту на определенную сумму или факт получения от клиента авансового платежа;

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

Биллинговый счет – документ формируется для клиента категории «Постоплатный», имеющего дебетовый баланс по результатам биллинга, и подлежит оплате в установленный срок;

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

Финансовые отчёты; Платежные требования и их реестр с

возможностью выведения их на просмотр или на печать.

The Solution should produce a standard set of accounting documents in accordance with the industry requirements and applicable laws:

Customer Invoice: A document that is issued to the customer on subscripting to the CSP’s network. In its standard form, the document consists of a set of items that can have an impact or no impact on the subscriber’s account balance;

Tax Invoice: A document acknowledging the provision of services or the sale of some hard goods to the customer for a certain amount of money or the receipt of an advance payment from the customer;

Advance Payment Invoice: a document that is issued at the request of the customer for any amount indicated by the customer;

Bill: A document generated for a postpaid customer who has a debit balance after billing and who has to pay the amount due within a predefined period;

Cash Receipt: A document acknowledging that a cash payment has been accepted. In addition to a receipt that can be printed by a cash register, an additional receipt is generated when information on a cash payment is entered into the System through a CSP’s cash desk;

Financial statements; Payment requirements and their register with the

possibility of displaying them for viewing or printing.

3.4.2. Решение должно поддерживать возможность интеграции путем экспорта/импорта формализованной информации в формате XML.

The Solution should support the ability to integrate by exporting / importing formalized information in XML format.

63





3.4.3. Решение должно обеспечивать генерацию печатных форм в следующих форматах: PCL, HTML, XML PDF.

The Solution should provide the generation of printing forms in the following formats: PCL, HTML, XML PDF.

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

The Solution should support the ability to use different account templates for different categories of customers.

3.4.5. Решение должно поддерживать версионность шаблонов счетов и возможность повторной генерации счета в старом и новом формате.

The Solution should support versioning of invoice templates and the ability to re-generate invoices in the old and new format.

3.4.6. Решение должно поддерживать гибкую настройку форматов файлов экспорта/импорта в соответствии с договорами на банковское обслуживание.

The Solution should support flexible configuration of export / import file formats in accordance with bank service agreements.

3.4.7. Решение должно поддерживать возможность экспорта счетов-фактур во внешние системы.

The Solution should support the ability to export invoices to external systems.

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

It is necessary to upload invoices to external storage using a digital signature. For example, State Tax Service.

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

The Solution must support delivery functionality regular and extraordinary bills for various types of delivery.

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

The Solution must support the ability to bulk print and / or send invoices and call details per bill by e-mail to the entire customer base, to the selected group, or depending on the customer profile setting.

3.4.11. Решение должно позволять отправку счета в защищённом паролем zip архиве с хранением пароля в системе на уровне клиента или аккаунта.

The Solution should allow sending an account in a password-protected zip archive with password storing in the system at the customer or account level.

3.4.12. Решение должно обеспечивать возможность просмотра печатных форм из CRM сразу после

The Solution should provide the ability to view printed forms from CRM immediately after

64





генерации. generation.

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

Параметров учетной записи Объема начислений Суммы платежей

The Solution should provide the ability to include advertising in accounts and advertising should be customizable. Advertising may depend on:

Account Settings Volume of charges Amounts of payments

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

It should be possible to include barcodes in printed forms.

3.4.15. Должна быть возможность генерировать счета на нескольких языках на основе языка клиента.

It should be possible to generate invoices in several languages based on the language of the customer.

65

3.5. Система приема платежей Payment systemСоответствие/Compliance(FC/NC)


3.5.1. Решение должно иметь возможность принимать платежи в режиме онлайн следующими способами:

прием наличного платежа в Web-кассе отделения оператора связи;

посредством оплаты через электронные системы приема платежей;

по платежному поручению через отделение банка;

с использованием карт оплаты; мобильный перевод со счета

абонента/клиента донора.

The Solution should be able to accept payments in the following ways online :

acceptance of cash payment in the Web-cash desk of a branch of a telecom operator;

payment through electronic payment acceptance systems;

on a payment order through a bank branch; using payment cards; mobile transfer from the balance of the donor

account/subscriber.

3.5.2. Система должна обеспечивать правила применения методов оплаты для типов клиентов, включая применимость scratch карт для пополнения/оплаты счета.

System must support rules of payment methods for customer types, including scratch cards.

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

It is necessary that the supplied Solution supports a universal interface (gateway), allowing integration with any payment systems, interaction with banks, payment terminals of various suppliers and other participants in the financial ecosystem.

3.5.4. В решении должна быть поддержана возможность интеграции с межбанковскими системами платежей.

The Solution should support the possibility of integration with interbank payment systems.

3.5.5. В решении должна быть поддержана возможность интеграции с электронными системами платежей в режиме online.

The Solution should support the possibility of integration with electronic payment systems online.

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

The Solution should support the ability to accept different types of payments and the ability to limit the types of payments by type of contract.

3.5.7. Решение должно обеспечивать возможность автоматического приема банковских выписок в

The Solution should provide the ability to automatically receive bank statements in 1C and

66



форматах 1С и SWIFT и сохранение их в хранилище банковских документов.

SWIFT formats and save them in a bank data storage.

3.5.8. Необходимо, чтобы в поставляемом Решении имелась система управления скретч-картами (картами оплаты) с предоставлением API для поддержки процессов активации карт оплаты посредством IVR/USSD.

It is necessary that the supplied solution should have a scratch card (payment card) management system with an API to support payment card activation processes via IVR/USSD.

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

The Solution must support the functionality of a trust (“promised”) payment to prevent blocking of services. The trust payment should be part of the product offer and have a limited validity and repayment period by making real payment. The promised payment should be part of the product and have a limited validity period and be able to clear the debt with any positive change in the balance (Money transfer).

3.5.10. Решение должно поддерживать функциональность предоставления клиентам оператора связи услуги по переводу денежных средств с одного лицевого счета на другой (Money Transfer) с помощью USSD и SMS запросов.

The Solution should support the functionality of providing customers of a telecom operator with a service for transferring funds from one account to another (Money Transfer) using USSD and SMS requests.

3.5.11. Информация о клиенте и абоненте (имя и фамилия) должна быть доступна по API для отображения в приложениях Банка, чтобы снизить количество пополнений до неправильных номеров. Должны быть предусмотрены средства контроля и механизм проведения сверок приема платежей в расчетах с внешней платежной системой.

Information about the customer and subscriber (name and surname) should be available via API for display in the Bank’s applications to reduce the number of top-ups to incorrect numbers. Means of control and a mechanism for reconciling payments must be provided in settlements with an external payment system.

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

An autonomous mode of operation must be provided, followed by loading data into the database.

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

The Solution should include a mechanism for automatically posting payments based on key criteria

67



ключевым признакам (не менее двух), которые присутствуют в банковской выписке, как минимум:

номер лицевого счета; номер счета; ФИО (в случае с физическими лицами); номер договора; ИНН, КПП (для юридических лиц); сумма платежа.

(at least two) that are present in the bank statement, at least:

account number; invoice number; full name (individuals); contract number; TIN (taxpayer reg. No.), RRC (registration

reason code) (for organizations); payment amount.

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

The Solution should provide support for condition filters and regular expressions for identification of loaded / unloaded information.

3.5.15. Для обработки поступающих платежей в Решении должны быть предусмотрены:

средства обеспечения ввода платежа на необходимый лицевой счет;

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

возможность направлять (нацеливать) платежи на погашение задолженности по следующим целевым уровням: o лицевому счёту; o по выставленному счету;

возможность проведения частичных платежей;

возможность проведения корректировки платежа или операции возврата наличных и безналичных денег (сторнирование).

To process incoming payments, the Solution should include:

means of ensuring the input of payment to the necessary account;

the ability to add comments to the payment by manually entering payments;

the ability to direct (target) payments to pay off debt at the following target levels:o account;o invoice;

the possibility of partial payments; the ability to make a payment adjustment or

refund cash and non-cash payments (reversal).

3.5.16. Должны быть предусмотрена возможность обработки неопознанных платежей.

It should be possible to process unidentified payments.

3.5.17. В Решении должна предусматриваться возможность обрабатывать платежи или начисления как спорные. Соответственно,

The Solution should provide the ability to process payments or charges as controversial. Accordingly, two main processing methods should be provided:

68



должны быть предусмотрены два основных способа обработки:

откат (возврат к состоянию системы до начала спорной транзакции)

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

rollback (return to the state of the system before the start of the controversial transaction)

compensating adjustment (available to authorized users of the Solution is the function of introducing adjustments into the calculation and / or balance of the user's account within the user's authority).

3.5.18. Решение должно поддерживать оповещение клиента о пополнении его счета и о проведенной оплате.

The Solution should support the notification of the customer about the top-up of his account and about the payment made.

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

Отключение услуг связи при различных сроках просрочки оплаты долга;

Реструктуризацию дебиторской задолженности с настраиваемыми параметрами графиков реструктуризации;

Возможность приобретения услуг в рассрочку;

Управление услугами с учетом графика реструктуризации / рассрочки.

The Solution must support the following capabilities for working with the customer's debt:

Disconnection of communication services for various periods of delay in debt payment;

Restructuring of receivables with customizable parameters of restructuring schedules;

The possibility of acquiring services in installments;

Service management, taking into account the restructuring / installment plan.

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

The Solution should be able to disconnect subscribers depending on various time levels (number of days of non-payment of the bill) and money levels (debt limits), depending on the subscriber category and rate plan of the subscriber. At the same time, there should be a category of customers that does not turn off for any amount of balance.

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

The Solution should have built-in tools for creating and flexible management of many work plans (a set

69



воздействия) с должниками. of specified measures of impact) with debtors.

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

The assignment of work plans should be flexibly redefined by the rules of the application depending on the attributes of the customer and performed in both automatic and manual modes.

3.5.23. Решение должно предоставлять возможность применения активных мер к клиентам в зависимости от их балансов для предотвращения возникновения задолженности:

Для клиентов, обслуживаемых по кредитной схеме необходимо применение мер по приближению и превышению кредитного лимита;

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

The Solution should provide an opportunity to apply active measures to customers, depending on their balance sheets, in order to prevent arrears:

For customers serviced under a credit scheme, it is necessary to apply measures to approximate and exceed the credit limit;

For customers served by prepaid and hybrid schemes, it is necessary to apply warning notifications when the thresholds are reached, taking into account all advance payments and calculating the amount of the required advanced payment.

3.5.24. Поддержка платежей в разных денежных валют Support payments in different currencies

3.5.25. Возможность ведения справочника курс валют через GUI

The ability to maintain exchange rates through GUI

3.5.26. Должен быть механизм запрещения/разрешения ухода баланса в минус при отмене платежа, для препейд и постпейд клиентов это правило должно настраиваться в отдельности. Так же это правило должно настраиваться по разным типам платежей в отдельности

There should be a mechanism for prohibiting / allowing the balance to go negative when a payment is canceled, for pre-paid and post-paid clients this rule must be configured separately. Also, this rule must be configured for different types of payments separately.

70

3.6. Система управления картами оплаты

Payment Card Management System

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

The Solution should include a scratch card management module for generating secret voucher codes in a secure encrypted form, an interface for downloading scratch cards through several channels (IVR, USSD, Internet, customer service GUI, electronic account top-up, etc.) with support for promotions, and marketing campaigns aimed at boosting scratch card sales and increasing the number of repeat downloads.

3.6.2. Сервер базы данных ваучеров должен содержать не менее 75 миллионов ваучеров. Конфиденциальная информация о ваучерах должна храниться в зашифрованной форме.

The voucher database server must contain at least 75 million vouchers. Confidential voucher information must be stored in encrypted form.

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

The Solution should be able to provide information on incorrect top-ups attempts using the appropriate incorrect combinations of PINs (so-called secret codes), which were used for prepayment and subsequent payment in order to preserve the existing process of detecting fraud with the manipulation of scratch cards.

3.6.4. Система должна поддерживать генерации кода активации ваучеров.

The System must support voucher activation code generation.

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

The Solution should provide a voucher generator, which is software for creating encrypted vouchers in batch mode.

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

The System must support the distinction and uniqueness of codes issued by card providers and the system. For example when 3 providers issuing scratch cards will generate codes in parallel with the solution code generation system.

71

3.6. Система управления картами оплаты

Payment Card Management System

3.6.7. Система должна поддерживать выдачу и отправку кодов для каждого номинала в партиях. Например: 300 кодов для 100 сумов в партии, 10000 кодов для 2 сумов в партии и так далее.

The System must support the issuance and sending of codes for each face value in batches. For example: 300 codes for 100 soums in a batch, 10,000 codes for 2 soums in a batch, and so on.

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

The software must produce a file-list that can be delivered to the card manufacturer.

3.6.9. Максимально возможное число ваучеров в партии должно быть не менее 500 000

Maximum number of voucher cards in one batch should not be less than 500 000

72

3.7. Управление услугами Service managementСоответствие/Compliance(FC/NC)


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

The system should ensure the creation and management of product offers for subscribers and customers

3.7.2. Продуктовые предложения должны иметь несколько типов: базовые, дополнительные, смешанные

Product offers must have several types: basic, additional, mixed

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

The basic product offer should include a tariff plan and a set of services necessary for the provision of communication services to the subscriber. The basic offer is obligatory for the subscriber and may be with the subscriber in a single copy.

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

Дополнительные услуги с регулярной или разовой оплатой

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

Скидки и модификаторы правил тарификации (например, F&F)

Оборудование и аксессуары, как позиции счета

Additional offers are designed to enhance the capabilities of the basic offer and may include:

Additional services with regular or one-time payment

Traffic packets (minutes, megabytes, etc.), one-time and renewable

Discounts and tariff rule modifiers (for example, F&F)

Equipment and accessories as account items

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

The solution should provide the ability to group one or more additional offers among themselves or with a base offer for forming bundles.

3.7.6. Решение должно обеспечивать управления правилами подключения предложений (доступность, (не)совместимость, применимость)

The solution should provide management of the rules for connecting proposals (availability, (not)compatibility, applicability)

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

The decision should provide control over the terms of sale and use of the product offer.

3.7.8. Доступность предложения должна определяться The availability of the proposal should be determined

73



на основе таких параметров как:

Тип клиента и абонента Наличие у клиента продуктов и услуг Клиента/абонента Пользовательских функций

on the basis of such parameters as:

Type of customer and subscriber Availability of customer products and services Account/subscriber Custom built function

3.7.9. Решение должно обеспечивать управления правилами перехода между продуктами (основными и дополнительными).

The solution should provide management of the rules for the transition between products (primary and secondary).

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

Transition rules should determine the possibility of switching from one product to another (compatibility).

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

Transition rules should determine the cost and transition period between products.

3.7.12. Правила перехода должны определять порядок пересчета абонентской платы и объемов услуг(для пакетов).

Transition rules should determine the procedure for recalculating the monthly fee and the volume of services (for packages).

3.7.13. Решение должно обеспечивать привязку статуса жизненного цикла к доступности услуги.

The solution should ensure that life cycle status is linked to service availability.

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

As part of the subscriber’s life cycle, the set of statuses and transition rules between them must be customizable

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

Transition rules should determine the need to change the status of services and configuration on network elements.

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

The life cycle of offers and services should be related to the life cycle of the customer and subscriber.

3.7.17. Решение должно учитывать и управлять следующими типами абонентских услуг:

Периодические услуги (периоды списания: месяц, день, год);

Разовые услуги (предоплата, подключение к сети, продажа оборудования и т.д.);

The Solution should consider and manage the following types of subscription services:

Periodic services (charging periods: month, day, year);

One-time services (prepayment, network

74



Услуги по аренде/расрочка. Например, аренда/расрочка. цифровых каналов связи.

connection, sale of equipment, etc.); Rental/installment services. For example,

rental/ installment of digital communication channels.

3.7.18. В Решении должны учитываться зависимости услуг:

Иерархия услуг: при отключении / подключении главной услуги с необходимостью отключать / подключать подчиненные услуги;

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

The Decision should take into account the dependencies of services:

Hierarchy of services: when disconnecting / connecting the main service with the need to disconnect / connect subordinate services;

Service exceptions: when disconnecting / connecting a certain service, a ban is placed on disconnecting / connecting services recorded in the exception.

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

The Solution should provide a single mechanism for processing orders for connecting / disconnecting services with configurable conditions depending on billing status, balance, connected services and other features of the subscriber.

3.7.20. Поставляемое Решение должно поддерживать следующие операции по управление услугами / подписками абонента:

Возможность заказа услуги телефонной связи и добровольный отказ абонента от услуги через системы обслуживания и самообслуживания абонентов;

Возможность автоматического управления услугами на телекоммуникационном оборудовании;

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

The supplied Solution shall support the following operations for the management of subscriber services / subscriptions:

The ability to order telephone services and the voluntary decline of a subscriber from a service through subscriber service and self-service systems;

The ability to automatically manage services on telecommunications equipment;

The ability to automatically notify the subscriber about events associated with a change in the state of his balance: reaching warning thresholds and disabling telephone services;

The ability to block services, suspension of

75



Возможность блокировки услуг, приостановления услуг;

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

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

Возможность применения индивидуальных стоимостных показателей услуг;

Возможность управления услугами для RT-абонентов с контролем жизненного цикла абонента;

Возможность задавать условия расчета платы за услугу (пропорционально/авансом);

Возможность гибкой настройки тарификации на услуги телефонной связи;

Возможность гибкой настройки скидок на услуги телефонной связи;

Возможность подключения/отключения услуг будущей датой;

Поддержка услуг роуминга, контроль роуминг по балансу, статусу абонента и клиента;

Возможность пакетного заказа и отказа от услуг;

Поддержка версионности (предыстории) вносимых изменений.

Возможность управления услугами с воздействием на другие сетевые элементы (HLR, PCRF, VAS, и тд)

services; The ability to prohibit the disconnection of

telephone services by balance for certain subscribers;

The possibility of using individual service names (on the contract, on the subscriber resource);

The possibility of applying individual cost indicators of services;

The ability to manage services for RT-subscribers with control of the subscriber's life cycle;

The ability to set the conditions for calculating the service fee (proportionally / in advance);

The ability to flexibly configure charging for telephone services;

The ability to flexibly configure discounts on telephone services;

The ability to connect / disconnect services with a future date;

Support for roaming services, control by balance, state of subscriber and account;

The possibility of a package order and rejection of services;

Support for versioning (history data) of changes.

Ability to manage services with worklow on NE (HLR, PCRF, VAS, etc)

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

Hierarchical providing of services. Interconnected services should be supported: related services, mutually exclusive, etc. At the same time, the rules of interconnectedness should apply, both for operations to activate services on the customer, and for operations to deactivate services. When adding a rate

76



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

plan to a customer, a linked list of services included in it (adding a bundled service package), valid promotions and discounts should be added. When changing the rate plan, all services included in it must be disconnected, as well as the service package associated with the rate plan. Optionally, it should be possible to leave connected services and packages that are on the new rate plan.

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

Service packaging. The supplied Solution must support the function of packaging - the ability to sell several services (tariffs) that work with the customer at the same time, in one package. The package should include the ability to specify required services and optional services. The package can be formed in advance and sold to the customer as a product. The opportunity should also be provided for the customer to independently choose a service package. For services purchased in the package, the customer can be assigned a discount.

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

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

направлений; групповое занесение кодов телефонных

направлений в тарифные зоны; привязка кодов телефонных направлений к

различным тарифным зонам; тарифные зоны должны быть включены в

группы тарифных зон; возможность загрузки (импорта) кодов

телефонных направлений и тарифных зон

Support for group operations. The supplied Solution must support the possibility of applying the following group operations:

group creation of numbering capacity; a group institution of codes of telephone

directions; group entry of codes of telephone directions in

tariff zones; binding telephone codes to various tariff zones; tariff zones should be included in groups of

tariff zones; the ability to download (import) codes of

telephone directions and tariff zones from external tables (csv);

77



из внешних таблиц (csv); групповое создание абонентских ресурсов; групповое переназначение абонентских

ресурсов на другие договоры (при перерегистрации договора).

У Администратора должен быть инструмент расширить групповых операций

group creation of subscriber resources; group reassignment of subscriber resources to

other agreements (upon re-registration of the agreement).

Administrators must have the tool to add additional mass operations

78

3.8. Система провижининга ProvisioningСоответствие/Compliance(FC/NC)


3.8.1. Необходимо, чтобы в поставляемом Решении имелась система провижининга и отдельное автоматизированное рабочее место для работы с ней.

It is necessary that in the delivered Solution there should be a provisioning system and a separate workstation for working with it.

3.8.2. Решение должно поддерживать интеграцию с внешними платформами и оборудованием (HLR, EPC, VAS-системы и т.д.) по следующим протоколам: ssh, telnet, http(s), SOAP, REST.

The Solution should support integration with external platforms and equipment (HLR, EPC, VAS-systems, etc.) using the following protocols: ssh, telnet, http (s), SOAP, REST.

3.8.3. Решение должно поддерживать мультивендорную интеграцию с коммутационным оборудованием MSC / HLR (HP UDR, ERICSSON, HUAWEI, NOKIA, ZTE, Lucent, Siemens и др.) в рамках поддерживаемых протоколов.

The Solution should support multi-vendor integration with MSC / HLR switching equipment (HP UDR, ERICSSON, HUAWEI, NOKIA, ZTE, Lucent, Siemens, etc.) with supported protocols.

3.8.4. Предлагаемая система должна поддерживать provisioning GSM, GPRS, EDGE, UMTS, LTE, VAS, VPN и широкополосных IP-сетей для услуг передачи голоса, данных и контента.

The proposed system should support provisioning GSM, GPRS, EDGE, UMTS, LTE, VAS, VPN and broadband IP networks for voice, data and content services.

3.8.5. Запросы на provisioning услуг будут включать (но не ограничиваться) следующее действия:

Временные отключения абонентов по разным причинам.

Деактивация абонентов Реактивация абонентов Дополнительные удаления, или изменение

добавленной стоимости / дополнительные услуги

Смена SIM-карты Смена номера Выполнять различные действия на

платформе IN и других сетевых элементах (например, VPN и т. Д.)

provisioning профиля provisioning различных услуг HLR Закрытая группа пользователей (CUG) и

Friends & Family

Requests for provisioning services will include, but are not limited to, the following actions:

Temporary disconnection of subscribers for various reasons.

Deactivation of subscribers Reactivation of subscribers Additional removals, or change in value added /

additional services Change SIM card Change of number Perform various actions on the IN platform and

other network elements (for example, VPN, etc.)

provisioning of profile provisioning of various HLR services Closed User Group (CUG) and Friends &

Family

79



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

The Solution should support flexible configuration of provisioning scenarios for various business requirements at any stage of order processing - acceptance, validation, enrichment, execution.

3.8.7. Решение должно поддерживать своевременное и гарантированное исполнение сценариев провижининга с возможностью асинхронного взаимодействия в том числе со сторонними системами в рамках открытого API.

The Solution should support timely and guaranteed execution of provisioning scenarios with the possibility of asynchronous interaction including with third-party systems within the framework of an open API.

3.8.8. Решение должно поддерживать сценарии массовых операций провижининга с внешними платформами и оборудованием.

The Solution should support scenarios for mass provisioning operations with external platforms and equipment.

3.8.9. Предлагаемая система должна иметь возможность обрабатывать запросы провижининга на основе приоритетов, чтобы обеспечить быстрое предоставление некоторых запросов. Это может включать в себя (но не ограничиваясь этим) назначение приоритетов на основе источника и / или назначения запросов обеспечения.

The proposed system should be able to process priority-based provisioning requests to ensure that some requests are submitted quickly. This may include (but not limited to) prioritization based on the source and / or assignment of warranty requests.

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

The proposed system should be able to send notification to the superior system(s) from which the request was received about the successful or unsuccessful completion of the initialization request on network elements.

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

The proposed system should provide a reason if a particular command cannot be executed on network elements. If some numbers fail during boot, the system should not stop and reject the entire file or command. Preparation should continue and report errors when the file is complete. The error should be descriptive, not systemic.

80



описательной, а не системной.

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

The proposed system should provide the ability to align upstream business support systems with network elements. The external GUI must provide a screen for reconciling one or more numbers.

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

The system should have a mechanism for deferred collection of orders (commands) for re-sending to network elements.

81

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

Customer Relationship Management System



3.9.1. Решение должно предоставлять следующие функции управления клиентской информацией: Регистрация нового юридического лица со

всеми сопутствующими реквизитами и генерация документов и бланков;

Локализирована платформа CRM и отчетности (Английский, Узбекский, Русский)

Регистрация нового физического лица со всеми сопутствующими реквизитами и генерация документов и бланков;

Управление договорами клиента/абонента: история договоров, повторная печать;

Просмотр и изменение данных клиента на уровне биллинга;

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

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

Учет и хранение реквизитов клиентов; Изменение условий обслуживания; Завершение обслуживания; Поддержка иерархии клиентов и различных

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

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

The Solution should provide the following customer information management functions: Registration of a new legal entity with all related

details and generation of documents and forms; Localization of CRM platform and reporting

(English, Uzbek, Russian) Registration of a new individual with all related

details and generation of documents and forms; Management of customer / subscriber contracts:

contract history, reprint; View and change customer data at the billing

level; Validation of input certificate data, the

implementation of user logic in case of their incorrectness;

Check for restrictions: by age, by office, by the number of numbers on the document and by the document (White, black list)

Accounting and storage of customer details; Change of service conditions; Completion of service; Support for the hierarchy of customers and

various customer associations to provide special conditions of service, as well as flexible distribution of payments between customers of one association;

Registration and processing of customer requests with the ability to integrate with an external ticket-system, for quick response / opening tasks to the desired units.

3.9.2. Рабочее место оператора должно обладать следующими возможностями: GUI в тонком клиенте с поддержкой Internet

The operator’s workplace should have the following features: GUI in a web client with support for Internet

82





Explorer и Google Chrome; Вывод информации о клиенте, абоненте,

балансе, их персональных данных; Вывод информации по тарифному

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

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

Explorer and Google Chrome; Information output about the customer,

subscriber, balance, their personal data; Information output on the rate

plan/service/package: the name of the rate plan, cost, date of the start of the rate plan must be displayed;

The output of information about user attributes of the customer, discounts, customization of data sources.

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

The Solution should provide a simple setup (without coding) of the customer model (hierarchies, entities, customer segments, relationship types, attribute).

3.9.4. Клиент в системе должен обладать следующими свойствами: Тип клиента (граждане, предприниматели,

индивидуальное предприятие, хозяйственное общество, государственная организация и.т.д);

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

Название предприятия или ФИО; Место жительства или юридический адрес,

контактная информация; Паспортные данные (только для физических

лиц); Юридические реквизиты клиента.

The customer in the system must have the following properties: Type of customer (citizens, entrepreneurs, sole

proprietorship, business company, state organization and etc);

Name of the company or name; Place of residence or legal address, contact

information; Passport data (only for individuals); Legal details of the customer.

3.9.5. Основанием для регистрации клиента в системе является договор, заключенный между компанией – оператором и пользователем, неотъемлемыми частями которого являются: Название компании – агента; Тип клиента (юридическое лицо, физическое

лицо);

The basis for registering a customer in the system is a contract concluded between the operator company and the user, the integral parts of which are: Name of the company - agent; Type of customer (legal entity, individual); Legal category of customer (resident / non-

83





Юридическая категория клиента (резидент/нерезидент);

Метод расчетов с клиента (авансовый/кредитный);

Информация о клиенте или об организации- клиенте;

Данные контактного лица; Метод доставки и адрес отсылки счетов к

оплате; Метод оплаты счетов абонентом, банковские

и платежные реквизиты; Оказываемые услуги; Пакеты услуг; Тарифный план; Абонентские номера (основной и

дополнительный); IP адрес и маска сети оборудования; Печати и подписи лиц, заключивших

договор; Кодовое слово, пароль (для идентификации

клиента).

resident); Method of settlements with a customer (advance /

credit); Information about the customer or the customer

organization; Contact person data; Delivery method and billing address; Method of payment of bills by the subscriber,

bank and payment details; Services provided; Service packages; Rate plan; Subscriber numbers (primary and secondary); IP address and network mask of the equipment; Seals and signatures of the parties to the contract; Code word, password (for customer

identification).

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

The System should contain the above attributes, allow you to make changes and delete them, and also provide the ability to define attributes, both mandatory and optional (with the subsequent change of this requirement).

3.9.7. Система должна поддерживать расширенный состав дополнительных (пользовательских) атрибутов клиента, позволять вносить изменения и удалять их, сохраняя историчность в базе. Набор расширенных атрибутов должен быть изменяем без доработок.

The System should support an expanded set of additional (custom) customer attributes, allow changes to be made and deleted, while maintaining historicity in the database. The set of extended attributes must be modifiable without program code modification.

3.9.8. Должна быть возможность выбора языка абонента

It should be possible to select a subscriber language

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

The System should allow to delete the subscriber’s account (making it invisible to the interface), but

84





сохраняя полную его историю в базе. keeping its full history in the database.

3.9.10. Решение должно поддерживать следующие функции управления абонентами/подписками: Создание нового клиента с абонентом; По завершению регистрации

абонента/клиента система должна позволять печатать публичную оферту (prepaid) или договор/приложения (postpaid)

Добавление абонента на зарегистрированного клиента;

Учет и хранение атрибутов абонента; Изменение атрибутов абонента; Управления и сверка профиля абонента на

уровне HLR/VAS массово и единично; Управление тарифными планами / услугами /

пакетами услуг / тарифными опциями на абоненте;

Включение/отключение маркетинговых акций;

Временное закрытие (suspension) абонента и возобновление обслуживания;

Замены SIM-карты и замены номера; Закрытие абонента (у клиента может быть

несколько абонентов, каждый из которых может быть отключён по своему жизненному циклу);

Использование услуг связи абонентами корпоративного клиента за свой счет при превышении ими установленного лимита использования услуг связи за счет корпоративного клиента;

Гибкая привязка абонентов к клиентам с возможностью переноса абонента другому клиенту (между препейд и постпейд, а также между клиентами одной категории)

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

The Solution should support the following subscriber / subscription management functions: Creating a new customer with a subscriber; Upon completion of registration of the subscriber

/ customer, the system should allow printing of a public offer (prepaid) or contract / application (postpaid)

Adding a subscriber to a registered customer; Accounting and storage of subscriber attributes; Change of subscriber attributes Management and reconciliation of the subscriber

profile at the HLR/VAS level by mass and single; Management of rate plans / services / service

packages / tariff options of subscriber; Enable / disable marketing campaigns Temporary suspension of the subscriber and

resumption of service; SIM card replacements and number changes; Closing a subscriber (a customer can have several

subscribers, each of which can be disconnected in its own life cycle);

Use of communication services by subscribers of a corporate customer at their own expense if they exceed the established limit for the use of communication services at the expense of a corporate customer;

Flexible binding of subscribers to customers with the ability to transfer a subscriber to another customer (between pre-paid and post-paid, as well as between customers of the same category).

Ability to manage credit control for subscribers / accounts.

85





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

номеров; Управление SIM-картами

(резервной/основной) абонента; Управление «красивыми» номерами: логика

назначения / начисления / скидки; Учет групп абонентских номеров,

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

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

Учет закрытых групп пользователей (CUG); Тарификационная зона абонента для услуг

мобильной связи; Учет установленных лимитов на услуги

связи; Отображение информации об остатках

трафика и текущих параметров QoS пакетов; Учет проданного оборудования с привязкой

к IMEI.

The supplied Solution shall implement the following functions of accounting and management of subscriber resources:

The account of a subscriber number / additional numbers;

Management of SIM cards (backup / primary) of the subscriber;

Management of “gold/silver” etc. numbers: the logic of the assignment / charge / discount;

Accounting of groups of subscriber numbers served by one rate plan to ensure preferential rating of calls between subscribers - members of the group;

Accounting for F&F groups - functionality to support preferential rating of outgoing calls addressed to specific phone numbers included in an individually defined list for each subscriber;

Accounting for closed user groups (CUG); Subscriber billing area for mobile services; The account of the established limits for

communication services; Displaying information about traffic residuals

and current parameters of QoS packets; Accounting for sold equipment with reference to

IMEI.

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

Support for versioning (historic data) of changes made. The System should contain the above characteristics, allow you to make changes and delete them, and also provide the ability to determine the characteristics, both mandatory and optional (with a subsequent change in this requirement).

86





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

The System should make changes automatically and manually based on predefined fields by the current date, with the possibility of adding services by the future date, both for an individual subscriber and for a group.

3.9.14. Система должна иметь web-интерфейс для поиска в системе клиентов и абонентов по разным идентификаторам: MSISDN / account / паспорт / ИНН / номер договора и т.д.

The System should have a web-interface for searching customers and subscribers in the system for different identifiers: MSISDN / account / passport / TIN / contract number, etc.

3.9.15. Оператору должны быть доступны только действующие тарифные планы и услуги.

Only valid rate plans and services should be available to the operator.

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

The System should make it possible to view all the previously performed actions, with the automatic formation of the file of the entered data, to associate the entered data with the existing ones in the file.

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

The System should provide customizable automatic informing of subscribers about events that affect the change in the account balance, activation / deactivation of additional service functions directly by the subscriber in a dialogue with the self-service system, delivery of regular and extraordinary accounts for various types of delivery, delivery of information and marketing materials.

3.9.18. Система должна обеспечивать возможность временного закрытия абонента – приостановки предоставления ему доступа к услугам связи. Впоследствии должна осуществляться автоматическая активация временно закрытого абонента: безусловная (по истечении предопределенного срока) или с учетом баланса.

The System should provide the ability to temporarily close the subscriber - to suspend the provision of access to communication services. Subsequently, the automatic activation of the temporarily closed subscriber should be carried out: unconditional (after a predetermined period) or taking into account the balance.

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

The System should allow, if necessary, to complete the service of subscribers, fixing the reason for the

87





абонентов, фиксируя причину завершения обслуживания.

completion of service.

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

The System should support the functionality of the institution of internal applications for complaints of subscribers, maintaining a history of appeals, monitoring appeals, tasks tracking, processing statistics and reporting.

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

The System must support integration with the call center platform for servicing subscriber calls.

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

The System should support the ability to make comments by call center employees in order to quickly receive information about the customer in the future.

3.9.23. В CRM должна быть информация по балансам (наименование, доступный баланс, общий баланс, дата окончания действия баланса)

CRM should contain information on balances (name, available balance, total balance, balance expiration date)

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

The CRM should have detailed information on the balance settings, that is, if a package is connected to a customer / subscriber, then you can look at the balance sheet, in which directions this package allows you to spend money.

3.9.25. В CRM должна быть возможность сделать корректировки.

CRM should be able to make adjustments.

3.9.26. В CRM должна быть возможность установки лимитов: можно указать сумму лимитов также периодичность лимитов (еженедельно,

ежемесячно, никак (1 раз на всю жизнь), еженедельно)

в какой день должно происходить обнуление лимитов (каждое третье число)

CRM should be able to set limits it is possible to specify the amount of limits also the recurrence of limits (weekly, monthly, no

recurrence (only once in a lifetime), weekly) On what day should the limits be reset (every

third day)

3.9.27. В CRM должна быть возможность изменить CRM should be able to change the balance life date.

88





дату жизни баланса.

3.9.28. В CRM должна быть возможность сделать трансфер баланса.

In CRM should be able to make a balance transfer.

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

CRM should be able to top-up the balance through a voucher or payment system (top-up through vouchers is available only on certain categories of users).

3.9.30. В CRM должна быть детальная информация по депозитам: сумма внесенного депозита - используется

для B2B клиентов тип дата получения дата возврата сумма возможность вернуть депозит

CRM should have detailed information on deposits: deposit amount - used for B2B customers type date of receiving return date amount ability to return a deposit

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

CRM should display information on hierarchies (all information is displayed in a hierarchical structure): display of a child account parent account subscribers products packages

3.9.32. В CRM должна быть детальная информация по клиентской абонентской плате

CRM must have detailed information about the customer's monthly fee.

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

The CRM should be able to withdraw a one-time charge - indicate the amount, type of charge, date, type of event. It can be positive or negative. It is possible to add from the past (if the bill is not yet closed so that something falls into that bill), or by a future date.

3.9.34. В CRM должна возможность увидеть SIM-карты CRM should be able show the subscriber’s SIM

89





абонента, возможные резервации номеров, SIM. cards, possible reservation numbers, SIM.

3.9.35. В CRM должна возможность запустить внеочередной биллинг по клиенту.

CRM should be able to launch an extraordinary billing for a customer.

3.9.36. В CRM должна возможность генерировать корректирующие счета.

CRM should be able to generate corrective accounts.

3.9.37. В CRM должна возможность просмотра платежей.

CRM should be able to view payments.

3.9.38. В CRM должна возможность добавлять, изменять параметры платежного профиля клиента.

CRM should be able to add, change the parameters of the customer’s payment profile.

3.9.39. В CRM должна возможность возврата денежных средств.

CRM should be able to refund.

3.9.40. В CRM должна возможность просмотр истории возврата средств.

CRM should be able to view refund history.

3.9.41. В CRM должна возможность работать с заказами: история всех заказов возможность изменить просмотреть детальную историю по тому,

что внутри заказа выполнилось или нет

CRM should be able to work with orders: history of all orders ability to change view a detailed history of what has been

completed or not inside the order

3.9.42. В CRM должна быть информация по дебиторской задолженности.

The CRM should be able to view information on receivables

3.9.43. В CRM должна быть возможность оставлять, и редактировать комментарии на уровне клиента и абонента.

In CRM should be able to leave, change comments at the customer and subscriber level

3.9.44. В CRM должна возможность в один заказ добавить несколько услуг.

CRM should be able to add several services in one order.

3.9.45. В CRM должна возможность сформировать заказ прошлым или будущим числом.

CRM should be able to form an order with a past or a future date.

3.9.46. В CRM должна возможность просмотра общей информации по заказу.

CRM should be able to view general order information.

90





3.9.47. В CRM должна быть возможность отображения: бонусов по клиенту и абоненту, скидок (например, если аккумулятор что-то

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

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

аккумуляторов бонусов, которые выплачиваются по клиенту

и абоненту, скидок, которые получил клиент и абонент

CRM should be able to display: bonuses for the customer and subscriber, discounts (for example, if the accumulator has

accumulated something, a bonus may be paid out as a result))

customer-level accumulators accumulators at the subscriber level detailed information on setting up accumulators bonuses that are paid to the customer and

subscriber, discounts received by the customer and

subscriber

3.9.48. В CRM должна быть возможность экспорта всех абонентов на клиенте с настраиваемой атрибутикой после поиска в Excel, PDF, TXT или другой нужный формат.

In CRM should be able to export all subscribers on the customer with customizable attributes after searching in Excel, PDF, TXT or another needed format.

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

CRM should be able to create a printed form / report in order to display customer information on subscribers along with rate plan and status.

3.9.50. В CRM должна быть возможность массовых операции

There must be possibility for mass operation in CRM

91

3.10. Самообслуживание Self-ServiceСоответствие/Compliance(FC/NC)


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

Web self-service portal for subscribers should be set up in accordance with the corporate style requirements of the Customer.

3.10.2. Web-кабинет должен быть совместим с основными Web-браузерами, используемыми для просмотра Web-ресурсов сети Интернет, такие как:

Microsoft Internet Explorer, Mozilla Firefox, Google Chrome, Opera.

The web portal should be compatible with the main Web-browsers used to view Web-resources of the Internet such as:

Microsoft Internet Explorer, Mozilla Firefox, Google Chrome, Opera.

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

The web portal should display the following information and allow to perform those actions for subscribers, including

3.10.4. регистрация в Web-кабинете; восстановление забытого пароля для доступа

к Web-кабинет; смена своего пароля для доступа к Web-

кабинету;

registration in the web portal; restoration of the forgotten password for access

to the web portal; change password to access the web portal;

3.10.5. Просмотр личных и контактных данных клиента

Viewing personal and contact data of the customer

3.10.6. просмотр состояния лицевого счета; просмотр пополнений/оплат за текущий

месяц;

viewing the status of the account; view top-ups/payments for the current month;

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

Просмотр статуса текущих немонетарных балансов

Viewing current balance and current period charges

Viewing current non-monetary balances status

3.10.8. заказ ежемесячного счета, разовой детализации и счета на предоплату;

выбор способа доставки ежемесячного счета;

ordering a monthly invoice, one-time details and an advance payment invoice;

the choice of method of delivery of a monthly

92



bill;

3.10.9. внесение обещанных платежей; making promised payments;

3.10.10. управление переводом денежных средств; money transfer management;

3.10.11. функции по работе с услугами и тарифным планом:

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

разовых тарифных опциях; продление срока действия тарифных опций,

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

переадресацию и запрет вызовов

functions for working with services and the rate plan:

change of the current rate plan; changing the set of available services; management of tariff options; viewing information about used one-time tariff

options; extension of validity of tariff options ordered for

a certain period; calculation of the cost of the call; change of number; management of additional numbers; management of other user number service parameter management including call

forwarding and call barring

3.10.12. регистрация обращений в CRM; registration of request/complains in CRM;

3.10.13. управление авто информированием; Управление параметрами нотификации

auto information management; notification parameters management

3.10.14. просмотр истории операций; получение SMS-оповещений о событиях,

совершенных посредством Web-кабинета.

viewing the history of operations; receiving SMS notifications about events

committed through the Web portal.

3.10.15. Предлагаемое решение должно включать в себя расширенные возможности самообслуживания для корпоративных/M2M клиентов:

Proposed solution should include additional self-service capabilities for corporate/M2M customers:

3.10.16. Управление группировкой абонентов/SIM-карт

Managing subscribers and SIM card grouping

3.10.17. Определение администратора и управление правами доступа

Selecting account administrator and assigning access rights

93



3.10.18. Управление лимитами потребления на SIM/абонента (монетарные и немонетарные)

Managing personal limits on consumption (monetary and non-monetary)

3.10.19. Оправка SMS сообщений отдельным абонентам и группе абонентов

Sending SMS to separate subscribers and subscribers groups

3.10.20. Массовые операции над группой SIM карт:

Подключение /отключение услуг Изменение тарифного плана Блокировка/разблокировка

Mass operations for groups of SIM:

Adding/removing services Changing rate plan Suspending/resuming

3.10.21. Просмотр текущего потребления и расходов по отдельным SIM и группам

Viewing current spending and consumption for SIM or group

3.10.22. Система должна иметь встроенную функциональность USSD для проверки балансов\компонентов абонента и клиента и пополнения через скретч-карты, промо-кодов.

The System should have built-in USSD functionality for checking balances \ subscriber and customer components and top-up through scratch cards, promo codes.

3.10.23. Возможность написать обращение в компанию There must be the possibility to write complains to company

94

3.11. Поддержка массовых операций Bulk Operations SupportСоответствие/Compliance(FC/NC)


3.11.1. Система должна обеспечивать интерфейс для проведения массовых операций:

Создать новую учетную запись; Создать нового подписчика; Отключение аккаунтов; Отключение абонентов; Корректировок баланса; Возобновление услуг Приостановка услуг Добавление услуг в аккаунт / подписчиков Удалить услуг от подписчиков / аккаунтов Замена Тарифного Плана подписчика на

другое; Изменить статус аккаунта / подписчика; Изменить язык аккаунта / подписчика; Изменить идентификатор абонента (замена

IMSI / MSISDN); Перевод абонента на другой аккаунт; Активация карты пополнения (изменение

статуса);

The System should provide an interface for mass (bulk) operations:

Create a new account; Create a new subscriber; Disconnecting accounts; Disconnecting subscribers; Balance adjustments; Renewal of services Suspension of services Adding services to the account / subscribers Remove services from subscribers / accounts Replacement of the Subscriber's Rate Plan with

another; Change the status of the account / subscriber; Change the language of the account / subscriber; Change the subscriber identifier (IMSI /

MSISDN replacement); Transfer of the subscriber to another account; Activation of a recharge card (status changing);

3.11.2. Интерфейс массовых операции должен поддерживать различные методы ввода:

TXT; XML; SQL; EXCEL; ручной ввод по одному.

The bulk operation interface must support various input methods:

TXT; XML; SQL; EXCEL; manual entry one per unite.

3.11.3. Интерфейс должен поддерживать паузу / возобновление / повторный запуск массовой операции и должен поддерживать изменение конфигурации во время выполнения (или приостановленной) операции.

The interface must support pause / resume / restart of the bulk operation and must support configuration changes during the execution (or paused) of the operation.

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

The interface must support starting, stopping, pausing, and resuming a scheduled operation. During the mass operation, system must check on the rules for activation the service and the rules for tariff

95

3.11. Поддержка массовых операций Bulk Operations SupportСоответствие/Compliance(FC/NC)


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

transitions. There must be control the speed and time of the transaction

3.11.5. Интерфейс должен сохранять журналы операций и предоставлять отчеты об успехах и неудачных операции.

The interface must save activity logs and report success and failure of the operation.

3.11.6. Интерфейс должен поддерживать два типа пользователей:

менеджер по работе с клиентами, формулирующий параметры массовой операции

технический инженер (разработчик API), который может создать необходимый запрос с помощью вызовов API.

An interface must support two types of users:

customer service manager describing the parameters of the bulk operation

a technical engineer (API developer) who can create the necessary request using API calls.

3.11.7.

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

Subscriber should be transferred to another account with all existing offers, balances, accumulators and history. Any information should not lost.

96

3.12. Система лояльности и стимулирования Loyalty and incentive system



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

The System must support flexible rules for segmentation of the subscriber base based on various types of classification (such as rate plan, type of subscriber, etc. including user-defined)

3.12.2. Система должна обладать развитыми возможностями стимулирования абонентов, посредством осуществления программы начисления бонусов за использование услуг связи.

The System should have well-developed capabilities to stimulate subscribers through the implementation of a program for top-ups of bonuses for the use of communication services.

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

The Solution must support the functionality of working with bonus programs, which provide for the accrual of bonus points for subscribers who fulfill predetermined rules.

3.12.4. Решение должно обеспечивать использование предоставления бонусов в зависимости от следующих параметров:

объем потребленных услуг; сумма оплаченных услуг; сумма потребленных услуг; срок подключения к сети оператора. Зависимость по тарифному плану Зависимость по региону абонента, клиента

The Solution should ensure the use of bonuses depending on the following parameters:

volume of services consumed; the amount of paid services; the amount of consumed services; term of connection to the operator’s network depending on tariff plan. depending on region of subscriber/account

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

The System should have a mechanism to create an unlimited number of bonus programs and include subscribers in them, both individually and in groups. All subscribers participating in bonus programs should be able to receive notifications about their inclusion or exclusion from the bonus program, and about points accrued.

3.12.6. Система должна вести бонусный (немонетарный) баланс для каждого участника бонусной программы. На бонусном балансе

The System must maintain a bonus (non-monetary) balance for each participant in the bonus program. Bonus points must be accumulated on the bonus

97

3.12. Система лояльности и стимулирования Loyalty and incentive system



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

balance. Accrued bonuses should be taken into account when issuing monthly bills.

3.12.7. Система должна поддерживать ведение множества немонетарных балансов на уровне клиента.

The System must support the maintenance of multiple non-monetary balances at the customer level.

3.12.8. Система должна поддерживать возможность перевода единиц тарификации между монетарными и не монетарными балансами.

The System should support the ability to transfer charging units between monetary and non-monetary balances.

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

The System should provide a flexible API that allows to integrate with any third-party systems to interact with subscribers through various channels.

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

The System must process event information coming from external data sources using the open API.

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

The System should allow for individual customization of each individual campaign. The list of campaign parameters must be extensible.

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

The System must support flexible prioritization of marketing campaigns, campaign chains, sorting lists.

98

3.13. Система учета и распределения ресурсов

Resource inventory and distribution System



3.13.1. Решение должно реализовывать функции учета и управления ресурсами (номерная емкость, SIM карты, телефоны, модемы и.т.д).

The Solution must implement the resource inventory and management functions (numbering capacity, SIM cards, phones, modems, and etc).

3.13.2. Управление номерной емкостью должно позволять выполнять следующие задачи:

добавление номерной емкости; просмотр списка номеров; ввод номеров в эксплуатацию; вывод номеров из эксплуатации; сегментация по классам номеров (золотой,

серебряный и т.д.); выгрузка списка номеров.

Number capacity management should allow to perform the following tasks:

adding numbering capacity; viewing the list of numbers; entering numbers into operation; decommissioning of numbers; segmentation by classes of numbers (gold,

silver, etc.); uploading a list of numbers.

3.13.3. Управление SIM-картами. Решение должно обеспечивать технологический процесс по работе с SIM-картами:

формирование заказов на изготовление SIM-карт;

связывание и пакетное связывание SIM-карт с телефонными номерами;

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

ввод SIM-карт в эксплуатацию; дефектование SIM-карт, вывод из

эксплуатации с истекшим сроком активации;

выгрузка списка SIM-карт.

SIM card management. The Solution should provide a technological process for working with SIM cards:

the formation of orders for the manufacture of SIM cards;

Binding and batch binding of SIM cards with phone numbers;

preparation of starter kits for sale through the operator’s dealer network of both preactivated kits (with a hard bundle of SIM cards with a rate plan, a set of tariff options and / or services), and non-activated ones (flexible bundle of a SIM card with RP);

commissioning of SIM cards; SIM card defects, decommissioning with

expired activation; Export of a list of SIM cards.

3.13.4. Решение должно поддерживать несколько SIM-карт на абоненте с целью использования объёмов трафика в различных устройствах.

The Solution must support multiple SIM cards per subscriber in order to use the volume of traffic in various devices.

99

3.13. Система учета и распределения ресурсов

Resource inventory and distribution System



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

The Solution should implement a predefined life cycle of SIM cards with the ability to set user statuses.

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

Поддержка интеграционной совместимости со сторонними информационными и учетными системами;

Поддержка интеграционной совместимости со сторонними ERP-системами.

Поддержка распределения по всем складам компании и дилерами

The Solution should support business processes related to warehouse accounting and sale of operator resources:

Support for integration compatibility with third-party information and inventory systems;

Support for integration compatibility with third-party ERP-systems.

Support of distribution among company and dealer warehouse.

100

3.14. Система управления дилерами Dealer Management SystemСоответствие/Compliance(FC/NC)


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

The System should implement work on an agent and sub-agent settlement scheme between structural divisions of UCELL and other CSP.

3.14.2. Система должна обеспечивать выполнение функций:

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

The System should provide the following functions:

creating a new dealer; work with dealer accounts; cancellation of the contract with the dealer; control of the return of the contract; work with shipment orders; maintaining additional dictionaries; calculation of dealer fees.

3.14.3. Система должна вести учет и контроль доступа сотрудников дилера к системе с учетом ролевых матриц компании.

The System should keep records and control the access of the dealer employees to the system based on the role of user matrix of the company..

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

The System should have a dictionary of points of sale and their types, as well as the possibility of linking points of sale to the dealer, providing a flexible policy of mutual settlements with the dealer and stimulating the development of the dealer network.

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

The System should provide mutual settlements with dealers both in advance and credit schemes.

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

The System should be able to configure prohibition and warning thresholds for the advance settlement scheme.

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

The System should be able to configure a grace period (in days) for payments due under a credit settlement scheme.

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

The System should provide separate accounting of dealers' accounts by type of operation:

101

3.14. Система управления дилерами Dealer Management SystemСоответствие/Compliance(FC/NC)


Продажа оборудования, Прием платежей, Подключение Обслуживание абонентов.

sale of equipment, reception of payments, connection maintenance of subscribers.

3.14.9. В системе должен быть интерфейс по приему платежей на счета абонентов, клиентов в сторону биллинг системы.

The system must have an interface for receiving payments from subscribers, accounts in billing system.

102

3.15. Система поддержки роуминга Roaming Support SystemСоответствие/Compliance(FC/NC)


3.15.1. Система должна поддерживать возможность тарификации роуминга онлайн (Camel-роуминг) и офлайн (TAP-роуминг).

The System must support the ability to charge roaming online (Camel-roaming) and offline (TAP-roaming).

3.15.2. У абонента должна быть возможность смены услуги с Camel-роуминг на TAP-роуминг и обратно. При этом не должно возникать дублирования тарификации.

The subscriber should be able to change the service from Camel-roaming to TAP-roaming and vice versa. In this case, duplication of rating should not occur.

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

работа с данными о партнерах по роумингу; взаимодействие с партнерами по роумингу

на уровне групп; работа с TAP-файлами; работа со списком потоков роуминговых

данных; поддержка Return & Reject Procedure; работа с финансовыми документами; работа с fraud-отчетами; выгрузка данных для последующего

формирования аналитических отчетов в сторонних DWH системах;

учет сезонного временного сдвига; ведение справочников валют и курсов их

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

оператора связи при помощи файлового интерфейса;

сбор статистических данных об обработке файлов;

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

Тарификация TAP файлов во всех случаях, в т.ч. в случае расторжения контракта

Возможность настраиваемой опции для начисления полной суммы, даже если она

The System should include a roaming charging system that solves the following tasks:

work with data on roaming partners; interaction with partners in roaming at the group

level; work with TAP files; work with a list of roaming data streams; support Return & Reject Procedure; work with financial documents; work with fraud-reports; export of data for the subsequent formation of

analytical reports in third-party DWH systems; support of seasonal time shift; maintaining reference books of currencies

conversion rates, countries, payment details; interaction with a billing system of a telecom

operator using a file interface; collection of statistics on file processing; monitoring and managing data processing

processes. rating of TAP files in all cases, including in case

of termination of the contract ability to have configurable option to charge full

amount even it causes negative value (negative balance / overdraft) during offline usage processing (TAP roaming, Hotbilling)

103



вызывает отрицательное значение (отрицательный баланс / овердрафт) во время оффлайн рейтинга (TAP роуминг, Hotbilling)

3.15.4. Система должна поддерживать процессы NRTRDE IN/OUT, TAP IN/OUT как минимум TAP 3.11/3.12.

The System must support the processes NRTRDE IN / OUT, TAP IN / OUT at least TAP 3.11 / 3.12.

3.15.5. Система должна поддерживать работу с TAP-файлами и решать следующие задачи:

обработку входящих TAP-файлов; формирование исходящих TAP-файлов; поддержку коммерческого и тестового

роуминга; откат TAP-файлов или отдельных вызовов

из TAP-файлов; повторную загрузку TAP-файлов в базу

данных; повторное формирование TAP-файлов; просмотр и редактирование TAP-файлов; получение, отправка, подсчет с учетом

нескольких налоговых ставок TAP файлов; архивацию файлов; сбор статистических данных об обработке

файлов.

The System should support work with TAP files and solve the following tasks:

processing incoming TAP files; creation of outgoing TAP-files; support for commercial and test roaming; rollback of TAP files or individual calls from

TAP files; reloading the TAP files to the database; re-generation of TAP files; viewing and editing TAP files; receipt, sending, calculation taking into account

several tax rates of TAP files; archiving files; collection of statistics on file processing.

3.15.6.3

Должна быть возможность через GUI ввести, обновить, удалить следующую информацию:

Соглашения Курсы валют Тарифы Системные и пользовательские настройки Права доступа и роли Настройки и шаблоны документов,

формируемых в системе (счета-инвойсы, соглашения)

Параметры отчетности.

Data should inserted/updated/deleted through GUI:

agreements exchange rates tariffs system and user settings access rights and roles settings and templates of document which are

formed in the system (such as invoices , statements.)

report parameters.

3.15.7. Система должна поддерживать обработку RAP файлов, фиксации ошибок, переотправке

The solution should support processing of RAPs, errors fixing and re-sending the corrected CDRs in

104



корректных CDR в исходящих TAP файлах.

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

Исключение RAP данных их прибыли за роуминговые услуги.

the following TAP-OUT files.

The possibility of RAP files generation on the basis of the received TAP-IN files and sending them to the operator

Exclusion of RAPs data from roaming revenue

3.15.8. В системе должна хранить TAP файлы в виде таблице в БД

System must support to store TAP files in tables on DB

105

3.16. Система отчетности Reporting systemСоответствие/Compliance(FC/NC)


3.16.1. Решение должно включать прединтегрированную и гибкую систему отчетности, позволяющую Заказчику (ООО Coscom) самостоятельно (без обращения к поставщику) задавать и готовить обычные и специальные отчеты, а также сохранять их макеты.

The Solution should include a pre-integrated and flexible reporting system that allows the Client (COSCOM LLC) independently (without contacting the Vendor) set and prepare regular and special reports, as well as save their layouts.

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

The reporting system should have a “report editor” that allows you to create and edit reports in the presence of relevant production needs. In this case, the historicity of the report layouts must be observed.

3.16.3. Система отчетности должна иметь возможность сохранять формируемые системой отчёты (в том числе и пользовательские) в различных форматах (Word, Excel, Adobe Acrobat, HTML, CSV).

The reporting system should be able to save reports generated by the system (including user reports) in various formats (Word, Excel, Adobe Acrobat, HTML, CSV).

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

When generating reports, the system should allow changing the data sampling period (if this is provided for by the report input parameters).

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

The reporting system should be able to implement reports in other languages and controlling access based on role of user matrix.

3.16.6. В рамках проекта планируется перевод порядка 600 операционных отчетов на встроенную систему отчетности.

In the scope of project to develop about 600 operational reports to the integrated reporting system.

106

4. Технические требованияВсе приведенные ниже требования должны быть включены в решение, но не должны ограничиваться ими. Все ограничения в решении должны быть объяснены.

Technical requirementsAll of the requirements below should be included in the decision, but should not be limited to them. All restrictions in the decision should be explained

4.1. Общие архитектурные требования General architectural requirementsСоответствие/Compliance(FC/NC)


4.1.1. Решение должно обеспечивать следующие конструктивные особенности и принципы построения системы:

Возможность восстановления Системы после повреждений посредством установки патчей, обновления версии силами инженеров эксплуатации Системы;

Переносимость (способность к смене оборудования / операционных систем);

Возможность обновления; Возможность горизонтального

масштабирования решения; Возможность вертикального

масштабирования решения; Совместимость с последующими

обновлениями/релизами; Обновления модулей должны учитывать

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

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

WEB-интерфейсы для пользователей Решения

Открытый API;

The Solution should provide the following design features and principles of the system:

The ability to restore the System after damage by installing patches, updating the version by the engineers of the System;

Portability (ability to change equipment / operating systems);

Possibility of updating; The possibility of horizontal scaling of the

solution; Possibility of vertical scaling of the solution; Compatibility with subsequent updates / releases; Module updates should take into account the

specifics of existing functions. The ability to control versions implemented

sequentially or simultaneously; WEB-interfaces for users. Solutions Open API;

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

It should be possible to place and operate the solution in a virtualization environment, using licensed hypervisors

4.1.3. Решение должно иметь: возможность установки, использования в качестве hardware компонент любого стандартного оборудования, любой

The solution should have: the ability to install, use as hardware components of any standard equipment,

107

4.1. Общие архитектурные требования General architectural requirementsСоответствие/Compliance(FC/NC)


линейки производителей архитектуры x86 any line of x86 architecture manufacturers

4.2. Требования к расчёту конфигурации ресурсов

HW Configuration Calculation Requirements



4.2.1. Аппаратная емкость Решения должна соответствовать 5-ти летним планам компании по увеличению емкости с точки зрения свободного места на жестком диске, основной памяти и изменений в системе.

The hardware capacity of the Solution should comply with the company's 5-year plans to increase capacity in terms of free space on the hard drive, main memory and changes in the system.

4.2.2. Аппаратная емкость Решения должна поддерживать 12 000 000 абонентов в течение следующих 5-ти лет, из которых около 91% будут препейд и около 9% постпейд.

The hardware capacity of the Solution should support 12,000,000 subscribers over the next 5 years, of which about 91% will be pre-paid and about 9% post-paid.

4.2.3. Решение должно поддерживать, c 30% резервом, процесс обработки учетных записей: 700 000 000 CDR в день (~11000 CDR/сек в пиковые часы нагрузки) с возможностью хранения в оперативном хранилище данных в течении 6 месяцев и в хранилище в течении 5 лет.

The Solution should support, with 30% reserve, the process of processing accounts: 700,000,000 CDR per day (~ 11000 CDR / sec during peak hours) with the possibility of storage in the online data warehouse for 6 months and in the storage for 5 years.

4.2.4. Решение должно быть рассчитано на создание 500 000 счетов для постпейд клиентов не более 3-х часов .

The Solution should be designed to create 500,000 accounts for post-paid customers no more than 3 hours .

4.2.5. Решение должно поддерживать процесс биллинга по всей абонентской базе не более 8 часов.

The Solution should support the billing process for the entire subscriber base for no more than 8 hours.

4.2.6. Решение должно отвечать следующим требованиям к производительности:

Среднее количество бизнес-процессов над абонентом в месяц: 45 000 000

Среднее количество бизнес-процессов в минуту в пиковые часы(TPM): 5000

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

The Solution must meet the following performance requirements:

Average number of business processes per subscriber per month: 45,000,000

Average number of business processes per minute during peak hours (TPM): 5000

Average number of transaction requests per minute during peak hours (atomic action by the

108





(атомарное действие со стороны абонента, т.е. заказ/отказ от пакета, услуги и т.п.): 60 000

Пиковое количество отправляемых смс в секунду: 2000

subscriber, i.e. order / refusal of a package, service, etc.): 60,000

Peak SMS sent per second: 2000

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

Количество запросов на обслуживание (provisioning) в день – 5 000 000

Количество запросов на обслуживание (provisioning) в секунду (TPS) – 200

The Solution must meet the following requirements in terms of provisioning performance:

The number of service requests (provisioning) per day - 5,000,000

The number of service requests (provisioning) per second (TPS) - 200

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

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

Любое время отображения экрана: не более 2 секунд.

The Solution must meet the following requirements in terms of GUI performance:

Time taken to request information from the database (except for reports): no more than 5 seconds (including screen display time);

Any screen display time: no more than 2 seconds

4.2.9.

Решение должно отвечать следующим требованиям с точки зрения емкость обработки голосовых вызовов :

Средний показатель завершения звонка 99%

Среднее время удержания вызова (в секундах) после ответа на вызов 130 сек

Количество вызовов в час максимальной нагрузки на каждого активного абонента в сети GSM 3.5

Количество активных абонентов в сети GSM 60%

Минимальное/среднее/максимальное время между запросами квот в голосовых вызовах : 60секунд/ 300

The Solution must meet the following requirements in terms of voice call processing capacity :

Average call completion rate of 99% Average call hold time (in seconds) after

answering a call 130 sec The number of calls per hour of maximum load

for each active subscriber in the GSM 3.5 network

The number of active subscribers in the GSM network is 60%

Minimum / average / maximum time between quota requests in voice calls: 60 seconds / 300 seconds / 900 seconds

109





секунд / 900 секунд

4.2.10. Решение должно отвечать следующим требованиям с точки зрения емкость обработки интернет сессий :

Средняя продолжительность временных сеансов 40 минут

Среднее количество обновлений (например, резерв / расход) на переходный сеанс : 5

Общий количество одновременных сессий Dimeter : 7000000

Транзакция в секунду : 15000 Максимальное количество открытых

сессий DCCA (данный расчет предоставлен на 70% нагрузку системы) :2500000

Среднее количество групп тарификации трафика открытых на 1 абонента : 6

The Solution must meet the following requirements in terms of internet session:

The average duration of Transient sessions is 40 minutes

Average number of updates (for example, reserve / expense) per Transient session: 5

Total number of concurrent sessions Dimeter: 7000000

Transaction per second: 15000 Maximum number of open DCCA sessions (this

calculation is provided for 70% of the system load): 2500000

Average number of traffic rating groups open per subscriber: 6

4.2.11. Решение должно отвечать следующим требованиям с точки зрения емкость обработки периодических /не периодических оплат:

Количество периодических оплат максимальной нагрузки за 1 час : 22 000 000

Количество не периодических оплат максимальной нагрузки за 1 час : 2 000 000

The Solution must meet the following requirements in terms of recurring/non recurring charge:

The number of recurring charge of the maximum load for 1 hour: 22 000 000

• The number of non- recurring charge of the maximum load for 1 hour: 2 000 000

110

4.3. Требования к надежности Reliability RequirementsСоответствие/Compliance(FC/NC)


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

The Solution should provide the ability to backup critical areas of the system.

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

The Solution Vendor must provide backup/recovery(no more than 60minutes) and fault tolerance schemes at the software and hardware levels.

4.3.3. Требуемая доступность для Решения составляет 99,999% (99,995% для всех модулей в течение 6-месячного периода стабилизации после даты миграции).

The required availability for the Solution is 99.999% (99,995% for all modules during the 6-month stabilization period after the migration date).

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

The Solution should contain an integrated monitoring system that is able to promptly notify about operational events.

111

4.4. Требования к документированию Documentation Requirements Соответствие/Compliance(FC/NC)


4.4.1. Документация по Системе должна включать следующие документы:

Руководство по администрированию Системы;

Руководство пользователей Системы; Описание интерфейсов Системы; Описание доступных механизмов миграции

данных; Описание API;

System documentation should include the following documents:

System Administration Guide; System User Guide; Description of System interfaces; Description of the available data migration

mechanisms; API Description;

4.4.2. Документация для пользователей Системы (файлы помощи и руководства пользователей) должна быть предоставлена в цифровом виде на русском языке.

Documentation for users of the System (help files and user manuals) should be provided in digital form in Russian.

112

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

Operational requirementsAll of the requirements below should be included in the decision, but should not be limited to them. All restrictions in the decision should be explained

5.1. Требования по поддержке Support RequirementsСоответствие/Compliance(FC/NC)


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

The Vendor is required to provide Service and Support documentation for all equipment and software supplied.

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

The Solution Vendor must provide during the implementation project implementation documents for the data model (information model, database structure and description), as well as ensure the transfer of skills.

5.1.3. Время присутствия специалистов Поставщика перед переходом на коммерческую эксплуатацию (baby sitting) – 2 месяца. Бебиситтинг должен включать в себя и срок после перехода

The presence duration of the Vendor’s specialists before the transition to commercial operation (babysitting) is 2 months. The babysitting should include the period after the transition

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

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

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

The supplied Solution must be configurable and supported and include, but are not limited to, the following functionality:

The supplied Solution should be able to add, configure and delete its components in the monitoring system, including databases and application servers.

The supplied solution should be able to install patches and perform updates to its components.

113

5.2. Требования по мониторингу Monitoring requirementsСоответствие/Compliance(FC/NC)


5.2.1. Поставляемое Решение должно обладать несколькими каналами оповещения (e-mail, SMS) для информирования о возникновении превышения порогов срабатывания метрик мониторинга.

The supplied Solution must have several notification channels (e-mail, SMS) to inform about the occurrence of exceeding the thresholds for the operation of monitoring metrics.

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

The monitoring system should display information in real time, and also be able to store and analyze the stored data of monitoring metrics, generate reports. Information to be analyzed includes application metrics and resource use metrics: processor, disk, memory.

5.2.3. Все аварии компонентов Решения должны регистрироваться в журнале системы мониторинга.

All failures of the components of the Solution should be recorded in the log of the monitoring system.

114

6. Требования к проектуВсе приведенные ниже требования должны быть включены в решение, но не должны ограничиваться ими.Все ограничения в решении должны быть объяснены.

Project requirementsAll of the requirements below should be included in the decision, but should not be limited to them.All restrictions in the decision should be explained

6.1. Требования по структуре проекта внедрения

Requirements for the structure of the implementation project



6.1.1. Участник тендера должен предоставить документ, описывающий роли и зоны ответственности каждого участника проекта (Участника Тендера и Заказчика при реализации проекта).

The Bidder must provide a document describing the roles and areas of responsibility of each project participant (Bidder and Client during the implementation of the project).

6.1.2. Участник тендера должен предоставить детальный план проекта с указанием сроков каждого этапа внедрения: Совещания рабочих групп по проекту; Анализ требований; Настройка программного продукта; Тренинг для администраторов и

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

The Bidder must provide a detailed project plan indicating the timing of each stage of implementation:

Project Working Group Meetings; Analysis of requirements; Setting up the software product; Training for administrators and users; Testing tests for acceptance.

6.1.3. Для каждой из задач должен быть указан срок. For each of the project tasks, a deadline should be indicated.

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

The Bidder confirms that he will transfer the necessary knowledge for the further maintenance and operation of the Solution.

6.1.5. Участник Тендера подтверждает использование инструмента поддержки совместной работы в проекте - Atlassian Confluence или аналогичное ПО, предоставляемого Участником Тендера, в течение всего срока проекта.

The Bidder confirms the use of the collaboration support tool in the project - Atlassian Confluence or similar software, provided by the Bidder, throughout the duration of the project.

115

6.1. Требования по структуре проекта внедрения

Requirements for the structure of the implementation project



6.1.6. Участник Тендера подтверждает использование инструмента трассировки и обработки требований в проекте - Atlassian Jira или аналогичное ПО, представляемого Участником Тендера, в течение всего срока проекта.

The Bidder confirms the use of the tracing and processing tool for requirements in the project - Atlassian Jira or similar software, submitted by the Bidder, throughout the duration of the project.

6.1.7. Участник Тендера предоставляет как минимум следующие документы:

Vision and scope – документ, обозначающий границы проекта;

Техническое задание на внедрение Решения, уточненное по результатам сбора требований;

План обучения; Стратегия миграции; Формат миграции; План миграции; Стратегия нагрузочного тестирования; План нагрузочного тестирования; План переключения.

6.1.7. The Bidder provides at least the following documents:

Vision and scope - a document indicating the boundaries of the project;

The terms of reference for the implementation of the Decision, updated according to the results of the collection of requirements;

Training plan; Migration strategy; The format of migration; The migration plan; The strategy of load testing; The plan of load testing; The switching plan.

116

6.2. Обобщенная матрица ответственности Поставщика и UCELL по проекту

Matrix of responsibility (Roles & Responsibility) of the Vendor and UCELL for the project



6.2.1. Участник Тендера \ Поставщик подтверждает готовность работы с приведенной схемой распределения ответственности (приложение 3).

The Bidder \ Vendor, confirms the willingness to work with the above scheme of distribution of responsibility (Appendix 3).

117

Documents

exarid.uzex.uz · Web viewРешение должно обеспечивать высокую производительность в режиме реального времени