Анкета Участника (форма 3) 35 Общие положения Общие сведения о процедуре запроса предложений ОАО «Мобильные ТелеСистемы»


НазваниеАнкета Участника (форма 3) 35 Общие положения Общие сведения о процедуре запроса предложений ОАО «Мобильные ТелеСистемы»
страница2/6
ТипАнкета
filling-form.ru > Договоры > Анкета
1   2   3   4   5   6

Обжалование


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

Если претензионный порядок, указанный в пункте 1.2.1., не привел к разрешению разногласий, Участники имеют право оспорить решение или поведение Организатора в связи с данным Запросом предложений в Центральной Конкурсной комиссии ОАО «МТС».

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

Прочие положения


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

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

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

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

Предмет закупки

Общее положение


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

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

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

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

      • Размещение запланированных РК на каналах коммуникации МТС и доставка рекламного контента абонентам.

      • Он-лайн статистика прохождения РК, выгрузка итоговых отчетов.

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

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




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

      1. Необходимо обеспечение единого интерфейса системы Мобильная реклама, с предоставлением доступа к этому интерфейсу (WAP/WEB/SMS-портал для абонентов и WEB-портал для Рекламодателя\РА и для администрирования МТС):


2.2.1.1 Абонентам:

  • создавать и изменять свой профайл:

    • заполнять анкету

    • выбирать интересующие темы

    • выбирать каналы коммуникации для доставки рекламы

    • задавать расписание доставки рекламы

    • выбирать бонусы за просмотр рекламы

  • просматривать статистику по бонусам




        1. Рекламодателям\РА:

        • Создавать и изменять рекламные кампании:

      • выбирать тип кампании

      • задавать параметры и размер целевой аудитории

      • выбирать каналы коммуникации для доставки рекламы

      • выбирать зоны проведения кампании

      • загружать список для рассылки (при наличии)

      • задавать расписание доставки рекламы

      • задавать ограничение по бюджету

        • загружать рекламный контент

        • отправить кампанию на утверждение

        • отлеживать прохождение кампании

        • просматривать статистику.




        1. МТС:

  • Администратор:

  • создавать, блокировать, разблокировать и удалять учетные записи Рекламодателей\РА

  • просматривать, изменять и удалять профайлы Абонентов

  • просматривать список сообщений отправленных Абонентам и ответы на них

  • просматривать список доставки рекламы, скрывать и отображать каналы для выбранных Рекламодателей\РА

  • Акаунт-менеджер:

  • изменять учетные записи Рекламодателей\РА

  • задавать Тарифную Политику для каналов коммуникаций

  • просматривать, размещать (согласовывать), отклонять заявки от Рекламодателей\РА

  • отслеживать прохождение кампаний

  • просматривать профайлы Абонентов

  • просматривать список сообщений отправленных Абонентам и ответы на них

  • просматривать список доставки рекламы

  • Оператор колл-центра:

  • подключать и отключать услугу «Мобильная реклама» абоненту по заявке абонента;

  • создавать, просматривать, изменять и удалять профайлы Абонентов

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


Необходимо предоставить подробную структуру WAP/WEB/SMS-порталов для абонентов и WEB-портала для Рекламодателя\РА и МТС.
2.2.2 Участнику необходимо предоставить описание его возможностей по операционной поддержке бизнес-процессов, в задачи которой входит:

  • модерирование РК на предмет соответствия законодательству РФ и корпоративной политике МТС

  • мониторинг эффективности кампаний, формирование отчетов

  • рекомендации по изменению форматов текущих кампаний в случае их низкой эффективности

  • анализ эффективности проведения РК, формирование шаблонов РК на основе наиболее эффективных РК

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


2.2.3 Участнику необходимо предоставить описание его возможности по привлечению рекламодателей:

  • разработка и проведение программ по привлечению рекламодателей

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



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


Планирование РК

Система должна позволять:

    • создавать РК,

    • задавать параметры РК по выбору аудитории (пол, возраст, статус, локализация (по номерной емкости), интересы и т.д.), рассчитывать объем аудитории, соответствующий выбранным параметрам,

    • предлагать каналы для коммуникации с выбранным сегментом аудитории,

    • настраивать расписание показа внутри одного канала и в целом по РК,

    • рассчитывать бюджет РК по заданным параметрам, предоставлять возможность задать ограничение по бюджету,

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

    • предоставлять возможность задавать интерактивные сценарии общения с абонентами, при использовании Рекламодателем\РА в качестве контактной информации WEB\WAP-ссылки генерировать свою ссылку (для переадресации и подсчета количества заходов), создавать при необходимости wap-сайт (иметь конструктор wap-сайтов),

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

    • отправлять заявку на согласование,

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

    • осуществлять тестовую доставку рекламных сообщений по pull и push-каналам.


Согласование рекламных кампаний

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

  • Должна быть предусмотрена возможность нотификации заинтересованных сторон (рекламодателя, рекламного агентства, представителя Оператора) о процессе прохождения согласования через e-mail и SMS.


Базы данных, произведение выборок

  • База данных системы должна представлять из себя:

      • хранилище данных об Абонентах (до 45.000.000 абонентов), содержащее профиль Абонента (данные из различных систем МТС (пол, возраст, доход, модель телефона, роуминг, пользование доп. услугами и т.д.)) и историю взаимодействия Абонента с Системой (профайл абонента, полученные абонентом РК, отклики абонента на РК и т.д.);

      • хранилище данных о Рекламодателях\РА, содержащее данные о Рекламодателе\РА (название, реквизиты, индивидуальные скидки, контактные лица) и историю его заказов (название РК, статус, критерии выборки, каналы коммуникации, рекламный контент, отклик и т.д.);

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

      • хранилище данных о проведенных кампаниях, включая названия кампаний, Рекламодатель\РА, рекламный контент, каналы, отчеты о доставке, отклик и т.д.);

      • хранилище данных рекламных сообщений.

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

  • Выборки по длительным РК должны обновляться раз в месяц (настраиваемый параметр).

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

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


Доставка рекламного контента

    • На первом этапе система должна производить доставку рекламного контента по различным push и pull каналам на основе технологий: SMS, MMS, USSD, ICB, WAP, WEB.

    • Рассылка рекламного контента по push-каналам SMS и MMS должна производиться по базам абонентов, выбранным при планировании РК путем передачи на SMS- и MMS-рассыльщики баз абонентов, рекламных сообщений и расписания доставки.

    • Для доставки рекламного контента по push-каналам ICB на этапе планирования РК задаются:

      • зоны ICB вещания (на уровне макрорегионов, городов, районов и т.п.);

      • текст рекламного сообщения;

      • тип и содержание отклика абонента (переход на определенный сайт, отправка SMS);

      • расписание вещания РК;

      • тематика РК;

      • приоритет РК;

Затем система Мобильная реклама передает в макрорегиональные ICBC, соответствующие выбранным зонам вещания, указанные параметры РК.



    • Доставка рекламного контента в pull-каналах (SMS, MCA, Голосовая почта и другие сервисные SMS сообщения, USSD, WAP, WEB) должна осуществляться абонентам, чьи MSISDN присутствуют в выборках текущих РК, с учетом расписания текущих РК, других параметров РК и настроек абонентов, указанных ими в своих профайлах. Необходимо предоставить подробное описание системы менеджмента текущих кампаний и алгоритма выбора рекламного сообщения, которое будет показано конкретному абоненту, среди всех РК, в выборки по которым он попал.


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

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

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

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

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

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


Администрирование системы, требуемый функционал:

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

    • Управление профилями абонентов.

    • Возможность просмотра всех рекламных сообщений по конкретному абоненту.

    • Добавление новых параметров в систему профилей абонентов и новых критериев к выборкам.

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


Дополнительные требования


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

    • Предоставить схему масштабирования решения на другие страны, в которых работает МТС.

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

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

    • Предоставить онлайн возможность протестировать интерфейс существующего решения

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




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


Система должна позволять Компании предоставлять сервис Мобильная реклама во всех макро-регионах Бизнес-единицы «МТС Россия».


      1. Требования к архитектуре


Система Мобильная реклама (Мобильная реклама) представляет собой программно-аппаратный комплекс с распределенной архитектурой, интегрированный с рядом платформ и комплексов в сети Оператора (рис.1).

Ниже в таблице указаны платформы Оператора по макрорегионам (всего 9 макрорегионов), с которыми должна взаимодействовать система Мобильная реклама:


Канал

Распределение платформ по макрорегионам

Кол-во платформ

SMS

За каждый макрорегион отвечает свой SMSC

9

WAP\WEB

Для добавления рекламных баннеров в страницы, отгружаемые абонентам по WAP\WEB каналам, используется специальная Платформа WAP\WEB Оператора, одна на макрорегионы Москва и Центр и по одной на каждый другой макрорегион.

8

USSD (в части запроса баланса)

Макрорегионы Москва и Центр обеспечивает одна платформа UniBalance, каждый другой макрорегион обеспечивает своя платформа UniBalance

8

SMS-рассылка

Одна платформа (в макрорегионе Москва), обеспечивающая SMS-рассылку по всем макрорегионам

1

MMS-рассылка

Одна платформа (в макрорегионе Москва), обеспечивающая MMS-рассылку по всем макрорегионам

1

ICB

Каждая макрорегиональная платформа ICB осуществляет вещание на всю территорию своего макрорегиона

9



Платформа Мобильная Центральный модуль платформы, выполняет функции согласно функциональным требованиям (п.2.3.), осуществляет взаимодействие с внешними источниками данных Оператора (Корпоративное информационное хранилище (КИХ) и Автоматическая система расчетов (АСР)), отвечает за доставку рекламных сообщения по pull-каналам и каналу ICB абонентам в макрорегионах Москва и Центр, осуществляет SMS- и MMS-рассылки по всем макрорегионам.

Центральный модуль имеет общую базу данных платформы Мобильная реклама, состав которой описан в п.2.3. выше.
Макрорегиональный модуль платформы Мобильная реклама расположен в каждом макрорегионе за исключением макрорегионов Москва и Центр (т.е. в 7 макрорегионах) и отвечает за доставку рекламных сообщений по pull-каналам и push-каналу ICB абонентам соответствующего макрорегиона.

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

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

  2. при необходимости доставки рекламного сообщения абонентам макрорегиона Центральный модуль передает заявку с параметрами РК (критерии выборки абонентов, перечень каналов, ограничение по количеству абонентов и количеству показов одному абоненту, расписание, рекламный контент, приоритет и т.д.) на соответствующий Макрорегиональный модуль.


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

  1. Макрорегиональный модуль предает на Центральный модуль отчеты о прохождении РК в соответствующем макрорегионе.


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




Москва

Центр

Северо-Запад

Поволжье Северо-Запад

Поволжье Юго-Восток

Юг

Урал

Сибирь

Дальний Восток

ответные SMS, sms/s

160

160

160

160

160

160

160

160

160

USSD, transactions/s

900

900

700

700

700

700

700

700

700

WAP\WEB, url/s

300

130

100

100

200

100

120

100

SMS-рассылка, sms/s

300 sms/s

MMS-рассылка, mms/s

20 mms/s




Рис.1


        1. Интеграция с корпоративным информационным хранилищем (КИХ), АСР (Foris) и операционным CRM оператора


Для реализации целевой доставки рекламного контента платформа Мобильная реклама ежемесячно должна обеспечивать возможность загружать по ftp протоколу структурированные текстовые файлы из КИХ Оператора по всей базе абонентов, включая, но не ограничиваясь, следующие данные:

  • номер абонента;

  • паспортные данные абонента;

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

  • начисления за роуминг (страна);

  • начисления за GPRS;

  • начисления за контент;

  • наличие услуг «Запрет приема информационных SMS и SMS/MMS с сайта»;

  • модель телефона;

  • и др.


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

  • формат кампании;

  • абоненты, получившие рекламный контент;

  • отклик (время, канал).


Платформа Мобильная реклама на ежедневной основе (настраиваемый параметр) получает по протоколу SOAP данные из АСР (Foris) о новых подключениях абонентами услуги «Мобильная реклама» и передает в Foris информацию о выбранных абонентом способах бонусирования.
Платформа Мобильная реклама должна обеспечивать интеграцию с системой Операционного CRM по протоколу http в части выгрузки информации о направленных рекламных сообщениях абонентам для интерфейса операторов контактного центра (в виде iframe в пользовательском интерфейсе CRM).


        1. Интеграция с SMSC




  • взаимодействие макрорегионального SMSC с модулем Мобильная реклама соответствующего макрорегиона по протоколу ftp для заливки и обновления (раз в сутки – настраиваемый параметр) на SMSC списков MSISDN, по которым должны срабатывать триггеры на SMSC для изменения маршрутизации сообщений;

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


В случае SMS канала коммуникации (сообщения о пропущенных вызовах, о голосовой почте и т.д.) – при получении сообщения от SMPP клиента (например, Голосовая почта) SMSC проверяет MSISDN получателя на наличие его в списке абонентов, полученном от модуля Мобильная реклама соответствующего макрорегиона. В случае если абонент в списке отсутствует, то сообщение передается абоненту без изменения. Иначе сообщение пересылается на данный модуль Мобильная реклама по SMPP для дальнейшей обработки. По факту получения сообщения от SMSC модуль Мобильная реклама проводит модификацию тела сообщения:

1) определение информативной части сообщения по заранее загруженным в платформу шаблонам (вариантам) ответов от сервисных/биллинговых платформ (MCA, Голосовая почта и т.д.);

2) удаление ранее вставленного рекламного контента (например, добавленного MCA);

3) добавление рекламного контента платформы Мобильная реклама.

Модифицированное сообщение передается на доставку в SMSC.

Необходимо предусмотреть исключение циклов по доставке.


        1. Интеграция с UniBalance




  • взаимодействие макрорегионального UniBalance с модулем Мобильная реклама соответствующего макрорегиона по протоколу ftp:

    • для заливки и обновления (раз в сутки – настраиваемый параметр) на UniBalance списков MSISDN, по которым должны срабатывать триггеры на UniBalance для изменения логики работы последней;

  • Взаимодействие макрорегионального UniBalance с модулем Мобильная реклама соответствующего макрорегиона по протоколу http для предоставления рекламного контента по запросу платформы UniBalance.


В случае USSD канала коммуникации (ответы абонентам по запросам баланса) - при получении от абонента запроса на предоставление баланса платформа UniBalance проверяет MSISDN инициатора на наличие его в списке абонентов, полученном от модуля Мобильная реклама соответствующего макрорегиона. В случае если абонент в списке отсутствует, то платформа UniBalance осуществляет обработку запросу от абонента самостоятельно. Иначе в данный модуль Мобильная реклама передается MSISDN абонента, при этом параллельно происходит запрос биллинговых платформ на предоставление баланса согласно стандартной схеме работы платформы UniBalance. По факту получения запроса, содержащего MSISDN, модуль Мобильная реклама передает в платформу UniBalance необходимый к добавлению рекламный контент. Далее платформа UniBalance осуществляет формирование ответного сообщения абоненту стандартными способами.


        1. Интеграция с WAP\WEB




  • взаимодействие макрорегиональной Платформы WAP\WEB Оператора, добавляющей рекламные баннеры в WAP\WEB страницы, с модулем Мобильная реклама соответствующего макрорегиона по протоколу ftp для заливки и обновления на Платформу WAP\WEB Оператора списков MSISDN, по которым на ней должны срабатывать триггеры на запрос рекламных баннеров;

  • взаимодействие макрорегиональной Платформы WAP\WEB Оператора, добавляющей рекламные баннеры в WAP\WEB страницы, с модулем Мобильная реклама соответствующего макрорегиона по протоколу http для получения ссылки на рекламный баннер, добавляемый в отгружаемые абонентам страницы.


В случае WAP\WEB канала коммуникации (запросы на просмотр ресурсов WAP\WEB) – при получении запроса от WAP\WEB клиента макрорегиональная Платформа WAP\WEB Оператора проверяет MSISDN инициатора запроса на наличие его в списке абонентов, полученном от модуля Мобильная реклама соответствующего макрорегиона. В случае если абонент присутствует в списке, то Платформа WAP\WEB Оператора передает в данный модуль Мобильная реклама MSISDN абонента. В ответ модуль Мобильная реклама передает на Платформу WAP\WEB Оператора ссылку на баннер для вставки в страницу, передаваемую на абонентское устройство.


        1. Интеграция с SMS-рассыльщиком




  • Центральный модуль Мобильной рекламы передает по протоколу ftp на платформу SMS информатор (SMS-рассыльщик) MSISDN-списки абонентов, которым должен быть доставлен рекламный контент, рекламный контент, расписание и приоритет кампании;

  • По окончании РК SMS информатор отгружает по ftp на Центральный модуль Мобильной рекламы данные о доставке сообщений рассылки: список MSISDN, которым доставлено рекламное сообщение и время доставки;

  • По запросу Центрального модуля Мобильной рекламы (запрос пользователей Мобильной рекламы в онлайн режиме) SMS информатор передает через SOAP (over HTTP) текущие данные о доставке сообщений рассылки: список MSISDN которым доставлено рекламное сообщение и время доставки.

В случае если одна РК содержит несколько рекламных текстов, для каждого такого текста должен формироваться отдельный запрос на SMS-рассыльщик типа: списки MSISDN, рекламный контент, расписание, приоритет.


        1. Интеграция с MMS-рассыльщиком


Взаимодействие MMS-рассыльщика (на базе SQL) с Центральным модулем Мобильная реклама посредством SQL запросов

  • Центральный модуль Мобильная реклама отправляет MMS-рассыльщику списки MSISDN, которым должна быть осуществлена доставка рекламного контента, рекламный контент, расписание и приоритет кампании;

  • MMS-рассыльщик передает на Центральный модуль Мобильная реклама ID рассылки;

  • MMS-рассыльщик по запросу Центрального модуля Мобильная реклама, содержащему ID рассылки, передает последнему информацию о результатах доставки этой рассылки.

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

В случае если одна РК содержит несколько рекламных текстов, для каждого такого текста должен формироваться отдельный запрос на MMS-рассыльщик типа: списки MSISDN, рекламный контент, расписание, приоритет.


        1. Интеграция с ICB


Взаимодействие макрорегионального модуля MAd с платформой ICBC соответствующего макрорегиона:

  • взаимодействие по протоколу SOAP (over http) для обмена управляющей информацией по РК (например, замена вещания одной РК на ICBC на вещание другой РК).

  • модуль MAd передает на платформу ICBC по протоколу SOAP (over http), следующие параметры РК:

    • зона ICB вещания (на уровне макрорегионов, городов, районов и т.п.);

    • текст рекламного сообщения;

    • тип и содержание отклика абонента (переход на определенный сайт, отправка SMS);

    • расписание вещания РК;

    • тематика РК.

  • получение по протоколу SOAP (over http) модулем MAd от платформы ICBC данных о загруженности ICBC (занятости времени вещания).

  • платформа ICBC по запросу платформы MAd передает (по ftp) на последнюю файл, содержащий данные по откликам абонентов на ICB-сообщения: отклик (url\sms-номер) – MSISDN – дата и время отклика.



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


Платформа должна иметь возможность формировать статистику по следующим параметрам:

  • Рекламодатель/Рекламное агентство

  • MSISDN

  • Рекламная кампания

  • Рекламный контент

  • Канал коммуникации

  • Количество отправленных сообщений

  • Количество доставленных сообщений

  • Количество уникальных абонентов для каждой кампании

  • И др.


Минимальная глубина хранения детализированной статистики не менее 6 месяцев.


      1. Управление системой


Система управления должна поддерживать следующие модули:

  • Модуль конфигурации;

  • Модуль сбора статистики;

  • Модуль мониторинга системы;

  • Модуль аварий с обязательной поддержкой SNMP;

  • Модуль конфигурации клиентов;

  • Удалённое администрирование;

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

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

  • Все оборудование системы должно иметь консольный доступ.

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

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




      1. Мониторинг системы.


Модуль мониторинга Системы должен состоять из 2-х компонентов:

  • Мониторинг системных ресурсов, реализуемый на базе нашей платформы HP OVO при помощи агентов (обязательное условие - интеграция с HP OVO);

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


Обязательна настройка всего оборудования, которое может отсылать SNMP-трапы, для отправки трапов на HP OVO. Должно поддерживаться 3 типа трапов:

  • Трап, сигнализирующий о возникновении аварии (newAlarm).

  • Трап, сигнализирующий об устранении аварии (clearAlarm).

  • Трап об аварии, которая не требует устранения (Alarm).

На каждый трап newAlarm обязательно должен приходить clearAlarm.

Уникальным ключем в комбинации newAlarm/clearAlarm является связка alarmId/object. На основе этих данных происходит автоматическое подчищение аварий.

Пример каждого типа трапов:

1. При возникновении аварийной ситуации на платформе, формируется трап (пример MIB-файла приведен ниже):
newAlarm {

severity ::= 5

alarmId ::= "CPU1_HIGH_LOAD"

object ::= "hostname"

text ::= "CPU usage is abnormal"

}
2. При устранении аварийной ситуации, формируется трап:
clearAlarm {

severity ::= 1

alarmId ::= "CPU1_HIGH_LOAD"

object ::= "hostname"

text ::= "CPU usage is normal"

}
3. Если требуется информирование о ситуации, которая не может быть устранена (к примеру: ошибка ввода пароля, ошибка в запросе в WEB-интерфейсе и т.д.), формируется трап:
alarm {

severity ::= 3

alarmId ::= "SSH_FAILED_LOGIN"

object ::= "hostname"

text ::= "Login failed for user root"

}

Пример MIB файла с описанием трапов:

-- Skip some unnecessary definitions like IMPORTS, MODULE-IDENTITY etc.
-- Needed objects

severity OBJECT-TYPE

SYNTAX INTEGER {

critical(5),

major(4),

minor(3),

warning(2),

normal(1)

}

ACCESS not-accessible

STATUS mandatory

DESCRIPTION

"Severity of alarm"

::= { enterprise 1 }

alarmId OBJECT-TYPE

SYNTAX DisplayString (SIZE (0..64))

ACCESS not-accessible

STATUS mandatory

DESCRIPTION

"Identification of alarm"

::= { enterprise 2 }

object OBJECT-TYPE

SYNTAX DisplayString (SIZE (0..64))

ACCESS not-accessible

STATUS mandatory

DESCRIPTION

"Object"

::= { enterprise 3 }

text OBJECT-TYPE

SYNTAX DisplayString (SIZE (0..255))

ACCESS not-accessible

STATUS mandatory

DESCRIPTION

"Additional information"

::= { enterprise 4 }

-- Traps difinition.

newAlarm NOTIFICATION-TYPE

OBJECTS {

severity,

alarmId,

object,

text

}

STATUS current

DESCRIPTION

"Notification indicates that new alarm was occurred."

::= {trap 1}

clearAlarm NOTIFICATION-TYPE

OBJECTS {

severity,

alarmId,

object,

text

}

STATUS current

DESCRIPTION

"Notification indicates that alarm was cleared."

::= {trap 2}

alarm NOTIFICATION-TYPE

OBJECTS {

severity,

alarmId,

object,

text

}

STATUS current

DESCRIPTION

"Notification indicates about something, which will not be cleared. Such as login error, failed querys etc."

::= {trap 3}


      1. Требования к подключению к IP-сети Компании


На все оборудование должен быть реализован удаленный консольный доступ: serial console, iLO, ALOM, iLOM, SC и т.д. (спецификация удаленного консольного доступа зависит от поставщика). При использовании консольных интерфейсов в состав платформы должен быть включен консольный роутер.


      1. Платформа должна поддерживать следующие основные принципы:




  • Резервируемости:

Электрическое питание программно-аппаратного комплекса осуществляется через сеть постоянного тока (опционально).

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

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

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

  • Масштабируемости,

  • Управлению перегрузками,

  • Управлению ресурсами,

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

  • Распределенности,

  • Защищенности:

Операционная система программно-аппаратного комплекса должна основываться на *nix-подобной системе (опционально).

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


      1. Требования по документации к Системе


Минимальный набор необходимой документации должен включать:

  • Общее описание системы;

  • Детальное описание сетевой части оборудования;

  • Детальное описание аппаратной части оборудования;

  • Техническая документация по эксплуатации платформы;

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

  • Документация по формированию и мониторингу аварийных/информационных сообщений;

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



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


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

    • Консультации.

    • Исправление ошибок.

Детальное описание требований ОАО «МТС» к гарантийному и пост-гарантийному обслуживанию на поставляемое оборудование и проводимые работы приведено в Приложении 1 «Требования SLA».

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



    1. Требования к управлению проектом со стороны участника


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

        • Управление проектом.

        • Описание рабочей группы проекта, с перечислением ключевых участников.

        • График реализации проекта, включающий ключевые события.

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

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

        • Сервисное сопровождение и поддержка: подробное описание осуществления поддержки и сопровождения




    1. Ценовая информация


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

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

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

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

        • Бизнес-модель и стоимость операционной поддержки бизнес-процессов.

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

        • Стоимость масштабирования на другие страны присутствия МТС.

    • Стоимость эксплуатации системы на 5 лет в рублях.

        • Интеграция, адаптация и инсталляция: трудовой ресурс поставщика (в денежном выражении), трудовой ресурс МТС (в кол-ве специалистов с указанием квалификации)

        • Дополнительные затраты




    1. Дополнительные требования


Участник должен привести примеры успешных интеграции решений поставщика с корпоративными базами данных, системами биллинга и VAS платформами (SMSC, MMSC, ICB и др.) телекоммуникационных операторов с количеством активных пользователей более 3 млн. Привести общее количество успешных внедрений и крупнейшее внедрение по количеству пользователей, а так же указать примеры внедрений с использованием федеративной архитектуры решения.
1   2   3   4   5   6

Похожие:

Анкета Участника (форма 3) 35 Общие положения Общие сведения о процедуре запроса предложений ОАО «Мобильные ТелеСистемы» iconАнкета Участника (форма 3) 18 Техническое предложение (форма 4) 20...
Принятие решения о проведении следующих этапов Запроса предложений или определение Победителя 15

Анкета Участника (форма 3) 35 Общие положения Общие сведения о процедуре запроса предложений ОАО «Мобильные ТелеСистемы» iconАнкета участника (форма 4) Типовой договор по доставке корреспонденции...
Принятие решения о проведении следующих этапов Запроса предложений или определение Победителей

Анкета Участника (форма 3) 35 Общие положения Общие сведения о процедуре запроса предложений ОАО «Мобильные ТелеСистемы» iconАнкета участника (форма 4) типовой договор по доставке корреспонденции...
Требования к Участникам. Подтверждение соответствия предъявляемым требованиям

Анкета Участника (форма 3) 35 Общие положения Общие сведения о процедуре запроса предложений ОАО «Мобильные ТелеСистемы» iconАнкета Участника (Форма №4) 11 Расписка о получении конверта с Предложением...
Оао «Мобильные ТелеСистемы», юридический адрес: 109147, г. Москва, ул. Марксистская, д. 4, уведомлением о проведении запроса цен,...

Анкета Участника (форма 3) 35 Общие положения Общие сведения о процедуре запроса предложений ОАО «Мобильные ТелеСистемы» icon1. Общие положения Общие сведения о процедуре запроса предложений
Участники), к участию в процедуре открытого конкурентного запроса предложений (далее — Запрос предложений) на право заключения договора...

Анкета Участника (форма 3) 35 Общие положения Общие сведения о процедуре запроса предложений ОАО «Мобильные ТелеСистемы» iconАнкета участника закупочной процедуры (форма ) 76 общие положения...
Требования к участникам закупочной процедуры, документам, предоставляемым в составе заявки на участие в запросе предложений 45

Анкета Участника (форма 3) 35 Общие положения Общие сведения о процедуре запроса предложений ОАО «Мобильные ТелеСистемы» iconАнкета Участника (форма 4) расчет начальной (максимальной) цены договора...
Муниципального унитарного предприятия «Ритуал» г. Иркутска на 1 квартал 2015 года

Анкета Участника (форма 3) 35 Общие положения Общие сведения о процедуре запроса предложений ОАО «Мобильные ТелеСистемы» iconАнкета Участника (форма 4) расчет начальной (максимальной) цены договора...
Муниципального унитарного предприятия «Ритуал» г. Иркутска на 2 квартал 2015 года

Анкета Участника (форма 3) 35 Общие положения Общие сведения о процедуре запроса предложений ОАО «Мобильные ТелеСистемы» iconАнкета Участника (форма 3) Справка о кадровых ресурсах (форма 4)...
Порядок вскрытия конвертов с заявками, рассмотрение, оценка и сопоставление заявок

Анкета Участника (форма 3) 35 Общие положения Общие сведения о процедуре запроса предложений ОАО «Мобильные ТелеСистемы» iconАнкета Участника (форма 3) расчет начальной (максимальной) цены договора...
Порядок вскрытия конвертов с заявками, рассмотрение, оценка и сопоставление заявок

Вы можете разместить ссылку на наш сайт:


Все бланки и формы на filling-form.ru




При копировании материала укажите ссылку © 2019
контакты
filling-form.ru

Поиск