«СОГЛАСОВАНО» «УТВЕРЖДАЮ» Директор

«СОГЛАСОВАНО»
«УТВЕРЖДАЮ»
Директор
Директор по контролю и управлению
Внешними ресурсами
по развитию продуктов и услуг
ОАО «Мобильные ТелеСистемы»
ОАО «Мобильные ТелеСистемы»
_____________________ В.В. Станкевич ______________________ П.Б. Ройтберг
ОТКРЫТЫЙ ЗАПРОС ПРЕДЛОЖЕНИЙ
на поставку и внедрение системы управления размещением
рекламного контента на каналах коммуникации с абонентами МТС
(Мобильная реклама)
Г. Москва
2009 г.
1
Содержание
1.
ОБЩИЕ ПОЛОЖЕНИЯ
3
1.1
Общие сведения о процедуре запроса предложений ....................................................... 3
1.2
Правовой статус процедур и документов .......................................................................... 3
1.3
Обжалование ........................................................................................................................... 4
1.4
Прочие положения ................................................................................................................. 4
2.
2.1
3.
ПРЕДМЕТ ЗАКУПКИ 5
Общее положение ................................................................................................................... 5
ПОРЯДОК ПРОВЕДЕНИЯ ЗАПРОСА ПРЕДЛОЖЕНИЙ. ИНСТРУКЦИИ
ПО ПОДГОТОВКЕ ПРЕДЛОЖЕНИЙ
23
3.1
Публикация Уведомления о проведении запроса предложений ................................ 23
3.2
Предоставление Документации по запросу предложений Исполнителям ............... 23
3.3
Подготовка Предложений .................................................................................................. 23
3.4
Требования к Участникам. Подтверждение соответствия
предъявляемым требованиям ........................................................................................... 24
3.5
Подача Предложений и их прием ..................................................................................... 25
3.6
Оценка Предложений и проведение переговоров.......................................................... 27
3.7
Принятие решения о проведении следующих этапов Запроса
предложений или определение Победителя .................................................................... 30
3.8
Подписание Договора ...............................................................Error! Bookmark not defined.
3.9
Уведомление Участников о результатах запроса предложений ................................. 30
4.
ОБРАЗЦЫ ОСНОВНЫХ ФОРМ ДОКУМЕНТОВ, ВКЛЮЧАЕМЫХ
В ПРЕДЛОЖЕНИЕ 31
4.1
Письмо о подаче оферты (форма 1) .................................................................................. 31
4.2
Техническое предложение на оказание услуг (форма 2) .............................................. 33
4.3
Анкета Участника (форма 3) ............................................................................................. 34
2
Общие положения
Общие сведения о процедуре запроса предложений
ОАО «Мобильные ТелеСистемы» (далее – Компания) - юридический адрес: 109147,
г. Москва, ул. Марксистская, д. 4 (далее — Организатор), настоящим Уведомлением,
размещенном
на
сайте
МТС
в
разделе
«Закупки»
(http://www1.company.mts.ru/purchases),
о
проведении
открытого
запроса
предложений, пригласило организации (далее — Участники) к участию в процедуре
открытого конкурентного запроса предложений (далее — Запрос предложений) на
право заключения договора на поставку и внедрение системы «Мобильная реклама»
(управление размещением рекламного контента на каналах коммуникации с
абонентами МТС).
Для справок обращаться к Организатору: контактное лицо – ДИУ КБ КЦ Группы
МТС Отдел проектного управления руководитель проекта Болдарева Светлана
Владимировна (моб. 8-915-479-68-40, e-mail: lana@mts.ru)
Правовой статус процедур и документов
Запрос предложений не является конкурсом, и ее проведение не регулируется
статьями 447—449 части первой Гражданского кодекса Российской Федерации.
Данная процедура запроса предложений также не является публичным конкурсом и
не регулируется статьями 1057—1061 части второй Гражданского кодекса
Российской Федерации. Таким образом, данная процедура запроса предложений не
накладывает на Организатора соответствующего объема гражданско-правовых
обязательств.
Опубликованное в соответствии с пунктом 1.1.1 Уведомление вместе с его
неотъемлемым приложением - настоящей Документацией, являются приглашением
делать оферты и должны рассматриваться Участниками с учетом этого.
Предложение Участника имеет правовой статус оферты и будет рассматриваться
Организатором в соответствии с этим, однако Организатор оставляет за собой право
разрешать или предлагать Участникам вносить изменения в их Предложения по
мере проведения этапов запроса предложений. Организатор оставляет за собой
право на последнем (финальном) этапе запроса предложений установить, что
Предложения Участников, поданные на данный этап, должны носить характер
твердой оферты, не подлежащей в дальнейшем изменению.
Заключенный по результатам запроса предложений Договор фиксирует все
достигнутые сторонами договоренности.
При определении условий Договора с Победителем используются следующие
документы с соблюдением указанной иерархии (в случае их противоречия):
1.1.1.1.1 Протоколы преддоговорных переговоров между Организатором и
Победителем (по условиям, не оговоренным ни в настоящей Документации по
запросу предложений, ни в Предложении Победителя);
1.1.1.1.2 Уведомление о проведении запроса предложений и настоящая
Документация по запросу предложений по всем проведенным этапам со всеми
дополнениями и разъяснениями;
3
1.1.1.1.3 Предложение Победителя со всеми дополнениями и разъяснениями,
соответствующими требованиям Организатора.
Иные документы Организатора и Участников не определяют права и обязанности
сторон в связи с данным запросом предложений.
Во всем, что не урегулировано Уведомлением о проведении запроса предложений и
настоящей Документации по запросу предложений стороны руководствуются
Гражданским кодексом Российской Федерации.
Обжалование
Все споры и разногласия, возникающие в связи с проведением Запроса
предложений, в том числе, касающиеся исполнения Организатором и Участниками
своих обязательств, должны решаться в претензионном порядке. Для реализации
этого порядка заинтересованная сторона в случае нарушения ее прав должна
обратиться с претензией к другой стороне. Сторона, получившая претензию, должна
направить другой стороне мотивированный ответ на претензию в течение 10
рабочих дней с момента ее получения.
Если претензионный порядок, указанный в пункте 1.2.1., не привел к разрешению
разногласий, Участники имеют право оспорить решение или поведение
Организатора в связи с данным Запросом предложений в Центральной Конкурсной
комиссии ОАО «МТС».
Вышеизложенное не ограничивает права сторон на обращение в суд в соответствии
с действующим законодательством.
Прочие положения
Участники самостоятельно несут все расходы, связанные с подготовкой и подачей
Предложения, а Организатор по этим расходам не отвечает и не имеет обязательств,
независимо от хода и результатов данного запроса предложений.
Организатор обеспечивает разумную конфиденциальность относительно всех
полученных от Участников сведений, в том числе содержащихся в Предложениях.
Предоставление этой информации другим Участникам или третьим лицам возможно
только в случаях, прямо предусмотренных действующим законодательством
Российской Федерации или настоящей Документацией.
Организатор вправе отклонить Предложение, если он установит, что Участник
прямо или косвенно дал, согласился дать или предложил служащему Организатора,
вознаграждение в любой форме: работу, услугу, какую-либо ценность, в качестве
стимула, который может повлиять на принятие Закупочной комиссией решения по
определению Победителя.
Организатор вправе отклонить Предложения Участников, заключивших между
собой какое-либо соглашение с целью повлиять на определение Победителя Запроса
предложений.
4
Предмет закупки
Общее положение
Предметом закупки является программно-аппаратный комплекс позволяющий
управлять размещением рекламного контента на каналах коммуникации с
абонентами МТС.
Поставляемая система должна обеспечивать реализацию следующего
функционала:
 Планирование и согласование рекламных кампаний (РК): выбор параметров
аудитории, канала и расписания доставки, предварительный расчет стоимости.
 Управление базой данных об абонентах, произведение выборок, учет Политики
контактов (ограничения по количеству показов рекламных сообщений на одного
абонента, частоты показов и т.д.).
 Размещение запланированных РК на каналах коммуникации МТС и доставка
рекламного контента абонентам.
 Он-лайн статистика прохождения РК, выгрузка итоговых отчетов.
 Биллинг: расчет стоимости РК для рекламодателей с учетом Тарифной политики
(стоимость показов и кликов на каждом канале, коэффициенты за таргетинг,
скидки за объем и т.д.) и индивидуальных скидок.
2.1.2 В качестве платформы для данного решения должен быть использована
система (или набор систем), предоставляющий необходимые инструменты и
технологии, которые позволяют создать платформу «Мобильная реклама».
2.2 Бизнес-требования
2.2.1 Необходимо обеспечение единого интерфейса системы Мобильная реклама, с
предоставлением доступа к этому интерфейсу (WAP/WEB/SMS-портал для
абонентов и WEB-портал для Рекламодателя\РА и для администрирования
МТС):
2.2.1.1 Абонентам:
 создавать и изменять свой профайл:
o заполнять анкету
o выбирать интересующие темы
o выбирать каналы коммуникации для доставки рекламы
o задавать расписание доставки рекламы
o выбирать бонусы за просмотр рекламы
 просматривать статистику по бонусам
2.2.1.2
Рекламодателям\РА:
 Создавать и изменять рекламные кампании:
o выбирать тип кампании
o задавать параметры и размер целевой аудитории
o выбирать каналы коммуникации для доставки рекламы
5




2.2.1.3
o выбирать зоны проведения кампании
o загружать список для рассылки (при наличии)
o задавать расписание доставки рекламы
o задавать ограничение по бюджету
загружать рекламный контент
отправить кампанию на утверждение
отлеживать прохождение кампании
просматривать статистику.
МТС:
 Администратор:
o создавать, блокировать, разблокировать и удалять учетные записи
Рекламодателей\РА
o просматривать, изменять и удалять профайлы Абонентов
o просматривать список сообщений отправленных Абонентам и ответы на
них
o просматривать список доставки рекламы, скрывать и отображать каналы
для выбранных Рекламодателей\РА
 Акаунт-менеджер:
o изменять учетные записи Рекламодателей\РА
o задавать Тарифную Политику для каналов коммуникаций
o просматривать, размещать (согласовывать), отклонять заявки от
Рекламодателей\РА
o отслеживать прохождение кампаний
o просматривать профайлы Абонентов
o просматривать список сообщений отправленных Абонентам и ответы на
них
o просматривать список доставки рекламы
 Оператор колл-центра:
o подключать и отключать услугу «Мобильная реклама» абоненту по заявке
абонента;
o создавать, просматривать, изменять и удалять профайлы Абонентов
o просматривать список сообщений отправленных Абонентам и ответы на
них по факту обращения абонента в звонковую службу
Необходимо предоставить подробную структуру WAP/WEB/SMS-порталов для
абонентов и WEB-портала для Рекламодателя\РА и МТС.
2.2.2
Участнику необходимо предоставить описание его возможностей по
операционной поддержке бизнес-процессов, в задачи которой входит:
o модерирование РК на предмет соответствия законодательству РФ и
корпоративной политике МТС
o мониторинг эффективности кампаний, формирование отчетов
o рекомендации по изменению форматов текущих кампаний в случае их низкой
эффективности
o анализ эффективности проведения РК, формирование шаблонов РК на основе
наиболее эффективных РК
6
o формирование репозиториев
использования в других РК
рекламных
сообщений
с
целью
их
2.2.3
Участнику необходимо предоставить описание его возможности по
привлечению рекламодателей:
o разработка и проведение программ по привлечению рекламодателей
o наличие взаимоотношений с рекламными агентствами, имеющими портфель
контрактов с рекламодателями и готовыми частично его конвертировать в
мобильную рекламу
2.3 Функциональные требования
Планирование РК
Система должна позволять:
 создавать РК,
 задавать параметры РК по выбору аудитории (пол, возраст, статус, локализация
(по номерной емкости), интересы и т.д.), рассчитывать объем аудитории,
соответствующий выбранным параметрам,
 предлагать каналы для коммуникации с выбранным сегментом аудитории,
 настраивать расписание показа внутри одного канала и в целом по РК,
 рассчитывать бюджет РК по заданным параметрам, предоставлять возможность
задать ограничение по бюджету,
 загружать рекламный контент, проверять загружаемый контент на соответствие
техническим требованиям к контенту по каждому выбранному каналу,
 предоставлять возможность задавать интерактивные сценарии общения с
абонентами, при использовании Рекламодателем\РА в качестве контактной
информации WEB\WAP-ссылки генерировать свою ссылку (для переадресации и
подсчета количества заходов), создавать при необходимости wap-сайт (иметь
конструктор wap-сайтов),
 настраивать оповещения через e-mail и SMS о наступлении событий (запрос доп.
информации, согласование, старт РК, достижение заданного уровня показов,
откликов или бюджета и др.),
 отправлять заявку на согласование,
 ежедневно формировать единые списки абонентов по текущим РК для каждого
канала коммуникаций и передавать их на платформы доставки в каждом
макрорегионе,
 осуществлять тестовую доставку рекламных сообщений по pull и push-каналам.
Согласование рекламных кампаний
 Согласование заявок на проведение РК, размещенных рекламодателями, должно
проходить по заранее заданной схеме. Необходима возможность изменять
данную схему.
 Должна быть предусмотрена возможность нотификации заинтересованных
сторон (рекламодателя, рекламного агентства, представителя Оператора) о
процессе прохождения согласования через e-mail и SMS.
7
Базы данных, произведение выборок
 База данных системы должна представлять из себя:
o хранилище данных об Абонентах (до 45.000.000 абонентов), содержащее
профиль Абонента (данные из различных систем МТС (пол, возраст, доход,
модель телефона, роуминг, пользование доп. услугами и т.д.)) и историю
взаимодействия Абонента с Системой (профайл абонента, полученные
абонентом РК, отклики абонента на РК и т.д.);
o хранилище данных о Рекламодателях\РА, содержащее данные о
Рекламодателе\РА (название, реквизиты, индивидуальные скидки,
контактные лица) и историю его заказов (название РК, статус, критерии
выборки, каналы коммуникации, рекламный контент, отклик и т.д.);
o хранилище данных о каналах доставки рекламы (объем аудитории,
требования к рекламному контенту);
o хранилище данных о проведенных кампаниях, включая названия кампаний,
Рекламодатель\РА, рекламный контент, каналы, отчеты о доставке, отклик и
т.д.);
o хранилище данных рекламных сообщений.
 Выборки по РК производятся на основе заданных рекламодателем параметров по
заранее разработанной логике конвертации профилей абонентов в параметры
выборки (например, данные профиля абонента о его затратах на связь и модели
телефона конвертируются в уровень дохода абонента). Необходимо описать
подробную логику конвертации данных об абонентах, имеющихся у Оператора, в
критерии, интересующие рекламодателей.
 Выборки по длительным РК должны обновляться раз в месяц (настраиваемый
параметр).
 Выбор возможных каналов коммуникации для заданной выборки по РК
осуществляется на основе содержащихся в профилях и профайлах абонентов
данных об использовании ими каналов коммуникации.
 Система должна отслеживать общую емкость каждого канала (часть емкости
канала в регионе, выделенная под нужды системы Мобильная реклама), занятую
емкость (зарезервированная емкость для утвержденных кампаний) и свободную
емкость (общая емкость за вычетом занятой емкости) и учитывать эти данные
при планировании РК (данные по емкости в систему Мобильная реклама вводит
оператор).
Доставка рекламного контента
 На первом этапе система должна производить доставку рекламного контента по
различным push и pull каналам на основе технологий: SMS, MMS, USSD, ICB,
WAP, WEB.
 Рассылка рекламного контента по push-каналам SMS и MMS должна
производиться по базам абонентов, выбранным при планировании РК путем
передачи на SMS- и MMS-рассыльщики баз абонентов, рекламных сообщений и
расписания доставки.
 Для доставки рекламного контента по push-каналам ICB на этапе планирования
РК задаются:
o зоны ICB вещания (на уровне макрорегионов, городов, районов и т.п.);
8
o текст рекламного сообщения;
o тип и содержание отклика абонента (переход на определенный сайт, отправка
SMS);
o расписание вещания РК;
o тематика РК;
o приоритет РК;
Затем система Мобильная реклама передает в макрорегиональные ICBC,
соответствующие выбранным зонам вещания, указанные параметры РК.
 Доставка рекламного контента в pull-каналах (SMS, MCA, Голосовая почта и
другие сервисные SMS сообщения, USSD, WAP, WEB) должна осуществляться
абонентам, чьи MSISDN присутствуют в выборках текущих РК, с учетом
расписания текущих РК, других параметров РК и настроек абонентов, указанных
ими в своих профайлах. Необходимо предоставить подробное описание системы
менеджмента текущих кампаний и алгоритма выбора рекламного сообщения,
которое будет показано конкретному абоненту, среди всех РК, в выборки по
которым он попал.
Статистика
Система должна позволять формировать статистику по каждой РК и каждому
абоненту в онлайн режиме.
Необходимо предоставить описание возможностей систем сбора и анализа
статистики, а также примеры визуализации полученных данных.
Биллинг
 Система должна иметь подсистему внутреннего биллинга для расчета
предварительной (при планировании), текущей (онлайн биллинг текущих
кампаний) и итоговой (после завершения) стоимости РК.
 Расчет должен производиться с учетом Тарифной политики, стоимости контакта
на каждом канале коммуникации, системы скидок. Тарификация должна
производиться как по схеме CPM, так и по схеме CPC.
 При расчете стоимости кампании должна быть предусмотрена возможность
проведения аукционов среди Рекламодателей\РА либо учета коэффициентов за
приоритезацию РК (параметр РК, который может задать рекламодатель).
 Должна быть предусмотрена возможность бонусирования абонентов за просмотр
рекламного контента.
Администрирование системы, требуемый функционал:
 Управление аккаунтами рекламодателей и рекламных агентств.
 Управление профилями абонентов.
 Возможность просмотра всех рекламных сообщений по конкретному абоненту.
 Добавление новых параметров в систему профилей абонентов и новых критериев
к выборкам.
 Возможность задавать новые правила конвертации параметров профиля
абонентов в критерии выборки.
9
Дополнительные требования
 Предоставить подробную схему архитектуры решения и подробное описание
функциональных блоков.
 Предоставить схему масштабирования решения на другие страны, в которых
работает МТС.
 Разработать предложения по развитию платформы и продукта. Предложить
возможность расширения списка каналов доставки.
 Обозначить возможность создания обучающего ролика для рекламодателей по
работе с платформой, а также отдельные ролики, демонстрирующие
возможности каждого канала
 Предоставить онлайн возможность протестировать интерфейс существующего
решения
 Предоставить подробный план-график реализации решения.
2.4. Технические требования
Система должна позволять Компании предоставлять сервис Мобильная реклама во
всех макро-регионах Бизнес-единицы «МТС Россия».
2.4.1. Требования к архитектуре
Система Мобильная реклама (Мобильная реклама) представляет собой
программно-аппаратный комплекс с распределенной архитектурой, интегрированный
с рядом платформ и комплексов в сети Оператора (рис.1).
Ниже в таблице указаны платформы Оператора по макрорегионам (всего 9
макрорегионов), с которыми должна взаимодействовать система Мобильная реклама:
Канал
П
л
аSMS
тWAP\WEB
ф
о
р
м
аUSSD (в части
запроса
баланса)
М
оSMS-рассылка
б
и
лMMS-рассылка
ь
н
аICB
я
Распределение платформ по макрорегионам
Кол-во
платформ
За каждый макрорегион отвечает свой SMSC
9
Для добавления рекламных баннеров в страницы, 8
отгружаемые абонентам по WAP\WEB каналам,
используется специальная Платформа WAP\WEB
Оператора, одна на макрорегионы Москва и Центр и
по одной на каждый другой макрорегион.
Макрорегионы Москва и Центр обеспечивает одна 8
платформа UniBalance, каждый другой макрорегион
обеспечивает своя платформа UniBalance
Одна
платформа
(в
макрорегионе
Москва), 1
обеспечивающая
SMS-рассылку
по
всем
макрорегионам
Одна
платформа
(в
макрорегионе
Москва), 1
обеспечивающая
MMS-рассылку
по
всем
макрорегионам
Каждая
макрорегиональная
платформа
ICB 9
осуществляет вещание на всю территорию своего
макрорегиона
10
Центральный
модуль
платформы,
выполняет
функции
согласно
функциональным требованиям (п.2.3.), осуществляет взаимодействие с внешними
источниками данных Оператора (Корпоративное информационное хранилище
(КИХ) и Автоматическая система расчетов (АСР)), отвечает за доставку рекламных
сообщения по pull-каналам и каналу ICB абонентам в макрорегионах Москва и
Центр, осуществляет SMS- и MMS-рассылки по всем макрорегионам.
Центральный модуль имеет общую базу данных платформы Мобильная реклама,
состав которой описан в п.2.3. выше.
Макрорегиональный модуль платформы Мобильная реклама расположен в
каждом макрорегионе за исключением макрорегионов Москва и Центр (т.е. в 7
макрорегионах) и отвечает за доставку рекламных сообщений по pull-каналам и
push-каналу ICB абонентам соответствующего макрорегиона.
Каждый Макрорегиональный модуль Мобильная реклама имеет свою локальную
базу данных, содержащую данные об абонентах соответствующего макрорегиона,
реплицированных с данными об этих абонентах, хранящихся в Центральном модуле
Мобильная реклама.
Между Центральным модулем и каждым макрорегиональным модулем
осуществляется обмен данными по протоколу ftp в следующих случаях:
1) раз в месяц (настраиваемый параметр) Центральный модуль обновляет
локальную базу данных абонентов макрорегионального модуля путем передачи
в макрорегиональный модуль информации об абонентах сети Оператора;
2) при необходимости доставки рекламного сообщения абонентам макрорегиона
Центральный модуль передает заявку с параметрами РК (критерии выборки
абонентов, перечень каналов, ограничение по количеству абонентов и
количеству показов одному абоненту, расписание, рекламный контент,
приоритет и т.д.) на соответствующий Макрорегиональный модуль.
На основе данных полученной заявки РК Макрорегиональный модуль
осуществляет выборку из своей локальной базы данных абонентов и формирует
списки MSISDN, которым предназначены рекламные сообщения данной РК.
Затем Макрорегиональный модуль осуществляет доставку рекламных
сообщений абонентам из сформированного списка в соответствии с
параметрами, указанными в заявке РК.
3) Макрорегиональный модуль предает на Центральный модуль отчеты о
прохождении РК в соответствующем макрорегионе.
Синхронизация общей базы данных Центрального модуля (ЦМ) с локальной
базой данных одного Макрорегионального модуля должна осуществляться
независимо от синхронизации с базой данных любого другого Макрорегионального
модуля.
Система Мобильная реклама имеет распределенную архитектуру, при которой
задействуются магистральные каналы связи между распределенными модулями
системы. Должна быть минимизирована загрузка этих магистральных каналов.
11
Производительность платформы
удовлетворять следующим условиям:
Москва Центр СевероЗапад
ответные SMS,
sms/s
USSD,
transactions/s
WAP\WEB, url/s
SMS-рассылка,
sms/s
MMS-рассылка,
mms/s
по
каждому
Поволжье
СевероЗапад
Поволжье
ЮгоВосток
Урал
Сибирь
должна
Дальний
Восток
160
160
160
160
160
160
160
160
900
900
700
700
700
700
700
700
700
130
100
100
200
100
120
100
300
300 sms/s
20 mms/s
http
ftp / http
SQL
ftp
КИХ
Юг
доставки
160
CRM
АСР
каналу
WAP\WEB
MMS-рассыльщик
SMS-рассыльщик
SOAP
Мобильная
реклама
http
(центральный модуль)
ftp / http
ICB
UniBalance
ftp
SMPP / ftp
SMSC
Центральный
макрорегион
ftp
ftp
ftp / http
Мобильная
реклама
(макрорегиональный
модуль)
http
ftp / http
WAP\WEB
Мобильная
реклама
ICB
ftp / http
SMPP / ftp
(макрорегиональный
модуль)
UniBalance
http
ICB
ftp / http
SMPP / ftp
SMSC
1-ый макрорегион
WAP\WEB
UniBalance
SMSC
N-ый макрорегион
Рис.1
12
2.4.1.1.
Интеграция с корпоративным информационным хранилищем
(КИХ), АСР (Foris) и операционным CRM оператора
Для реализации целевой доставки рекламного контента платформа Мобильная
реклама ежемесячно должна обеспечивать возможность загружать по ftp протоколу
структурированные текстовые файлы из КИХ Оператора по всей базе абонентов,
включая, но не ограничиваясь, следующие данные:
 номер абонента;
 паспортные данные абонента;
 начисления за прошедший месяц;
 начисления за роуминг (страна);
 начисления за GPRS;
 начисления за контент;
 наличие услуг «Запрет приема информационных SMS и SMS/MMS с сайта»;
 модель телефона;
 и др.
Платформа Мобильная реклама должна обеспечить реализацию выгрузки по ftp
протоколу в КИХ структурированных текстовых файлов по рекламным кампаниям,
включая, но, не ограничиваясь следующими данными:
 формат кампании;
 абоненты, получившие рекламный контент;
 отклик (время, канал).
Платформа Мобильная реклама на ежедневной основе (настраиваемый параметр)
получает по протоколу SOAP данные из АСР (Foris) о новых подключениях
абонентами услуги «Мобильная реклама» и передает в Foris информацию о
выбранных абонентом способах бонусирования.
Платформа Мобильная реклама должна обеспечивать интеграцию с системой
Операционного CRM по протоколу http в части выгрузки информации о
направленных рекламных сообщениях абонентам для интерфейса операторов
контактного центра (в виде iframe в пользовательском интерфейсе CRM).
2.4.1.2.
Интеграция с SMSC
 взаимодействие макрорегионального SMSC с модулем Мобильная реклама
соответствующего макрорегиона по протоколу ftp для заливки и обновления (раз в
сутки – настраиваемый параметр) на SMSC списков MSISDN, по которым должны
срабатывать триггеры на SMSC для изменения маршрутизации сообщений;
 взаимодействие макрорегионального SMSC с модулем Мобильная реклама
соответствующего макрорегиона по протоколу SMPP для передачи на платформу
Мобильная реклама SMS-сообщений от SMSC и передачи в SMSC
модифицированных SMS-сообщений, а также для предоставления на платформу
Мобильная реклама отчетов о доставке этих SMS.
13
В случае SMS канала коммуникации (сообщения о пропущенных вызовах, о
голосовой почте и т.д.) – при получении сообщения от SMPP клиента (например,
Голосовая почта) SMSC проверяет MSISDN получателя на наличие его в списке
абонентов, полученном от модуля Мобильная реклама соответствующего
макрорегиона. В случае если абонент в списке отсутствует, то сообщение передается
абоненту без изменения. Иначе сообщение пересылается на данный модуль
Мобильная реклама по SMPP для дальнейшей обработки. По факту получения
сообщения от SMSC модуль Мобильная реклама проводит модификацию тела
сообщения:
1) определение информативной части сообщения по заранее загруженным в
платформу шаблонам (вариантам) ответов от сервисных/биллинговых платформ
(MCA, Голосовая почта и т.д.);
2) удаление ранее вставленного рекламного контента (например, добавленного
MCA);
3) добавление рекламного контента платформы Мобильная реклама.
Модифицированное сообщение передается на доставку в SMSC.
Необходимо предусмотреть исключение циклов по доставке.
2.4.1.3.
Интеграция с UniBalance
 взаимодействие макрорегионального UniBalance с модулем Мобильная
реклама соответствующего макрорегиона по протоколу ftp:
o для заливки и обновления (раз в сутки – настраиваемый параметр) на
UniBalance списков MSISDN, по которым должны срабатывать триггеры на
UniBalance для изменения логики работы последней;
 Взаимодействие макрорегионального UniBalance с модулем Мобильная
реклама соответствующего макрорегиона по протоколу http для предоставления
рекламного контента по запросу платформы UniBalance.
В случае USSD канала коммуникации (ответы абонентам по запросам баланса) при получении от абонента запроса на предоставление баланса платформа
UniBalance проверяет MSISDN инициатора на наличие его в списке абонентов,
полученном от модуля Мобильная реклама соответствующего макрорегиона. В
случае если абонент в списке отсутствует, то платформа UniBalance осуществляет
обработку запросу от абонента самостоятельно. Иначе в данный модуль Мобильная
реклама передается MSISDN абонента, при этом параллельно происходит запрос
биллинговых платформ на предоставление баланса согласно стандартной схеме
работы платформы UniBalance. По факту получения запроса, содержащего MSISDN,
модуль Мобильная реклама передает в платформу UniBalance необходимый к
добавлению рекламный контент. Далее платформа UniBalance осуществляет
формирование ответного сообщения абоненту стандартными способами.
2.4.1.4.
Интеграция с WAP\WEB
 взаимодействие макрорегиональной Платформы WAP\WEB Оператора,
добавляющей рекламные баннеры в WAP\WEB страницы, с модулем Мобильная
реклама соответствующего макрорегиона по протоколу ftp для заливки и
14
обновления на Платформу WAP\WEB Оператора списков MSISDN, по которым на
ней должны срабатывать триггеры на запрос рекламных баннеров;
 взаимодействие макрорегиональной Платформы WAP\WEB Оператора,
добавляющей рекламные баннеры в WAP\WEB страницы, с модулем Мобильная
реклама соответствующего макрорегиона по протоколу http для получения ссылки
на рекламный баннер, добавляемый в отгружаемые абонентам страницы.
В случае WAP\WEB канала коммуникации (запросы на просмотр ресурсов
WAP\WEB) – при получении запроса от WAP\WEB клиента макрорегиональная
Платформа WAP\WEB Оператора проверяет MSISDN инициатора запроса на
наличие его в списке абонентов, полученном от модуля Мобильная реклама
соответствующего макрорегиона. В случае если абонент присутствует в списке, то
Платформа WAP\WEB Оператора передает в данный модуль Мобильная реклама
MSISDN абонента. В ответ модуль Мобильная реклама передает на Платформу
WAP\WEB Оператора ссылку на баннер для вставки в страницу, передаваемую на
абонентское устройство.
2.4.1.5.
Интеграция с SMS-рассыльщиком

Центральный модуль Мобильной рекламы передает по протоколу ftp на
платформу SMS информатор (SMS-рассыльщик) MSISDN-списки абонентов,
которым должен быть доставлен рекламный контент, рекламный контент,
расписание и приоритет кампании;

По окончании РК SMS информатор отгружает по ftp на Центральный
модуль Мобильной рекламы данные о доставке сообщений рассылки: список
MSISDN, которым доставлено рекламное сообщение и время доставки;

По запросу Центрального модуля Мобильной рекламы (запрос
пользователей Мобильной рекламы в онлайн режиме) SMS информатор передает
через SOAP (over HTTP) текущие данные о доставке сообщений рассылки: список
MSISDN которым доставлено рекламное сообщение и время доставки.
В случае если одна РК содержит несколько рекламных текстов, для каждого
такого текста должен формироваться отдельный запрос на SMS-рассыльщик типа:
списки MSISDN, рекламный контент, расписание, приоритет.
2.4.1.6.
Интеграция с MMS-рассыльщиком
Взаимодействие MMS-рассыльщика (на базе SQL) с Центральным модулем
Мобильная реклама посредством SQL запросов

Центральный модуль Мобильная реклама отправляет MMS-рассыльщику
списки MSISDN, которым должна быть осуществлена доставка рекламного
контента, рекламный контент, расписание и приоритет кампании;

MMS-рассыльщик передает на Центральный модуль Мобильная реклама ID
рассылки;

MMS-рассыльщик по запросу Центрального модуля Мобильная реклама,
содержащему ID рассылки, передает последнему информацию о результатах
доставки этой рассылки.
15
Результаты доставки включают в себя: ID рассылки, список MSISDN, которым
сообщение было доставлено в рамках этой рассылки и время доставки сообщения
для каждого абонента.
В случае если одна РК содержит несколько рекламных текстов, для каждого
такого текста должен формироваться отдельный запрос на MMS-рассыльщик типа:
списки MSISDN, рекламный контент, расписание, приоритет.
2.4.1.7.
Интеграция с ICB
Взаимодействие макрорегионального модуля MAd с платформой ICBC
соответствующего макрорегиона:
 взаимодействие по протоколу SOAP (over http) для обмена управляющей
информацией по РК (например, замена вещания одной РК на ICBC на вещание
другой РК).
 модуль MAd передает на платформу ICBC по протоколу SOAP (over http),
следующие параметры РК:
o зона ICB вещания (на уровне макрорегионов, городов, районов и т.п.);
o текст рекламного сообщения;
o тип и содержание отклика абонента (переход на определенный сайт, отправка
SMS);
o расписание вещания РК;
o тематика РК.
 получение по протоколу SOAP (over http) модулем MAd от платформы ICBC
данных о загруженности ICBC (занятости времени вещания).
 платформа ICBC по запросу платформы MAd передает (по ftp) на последнюю
файл, содержащий данные по откликам абонентов на ICB-сообщения: отклик
(url\sms-номер) – MSISDN – дата и время отклика.
2.4.2. Требования по сбору статистики
Платформа должна иметь возможность формировать статистику по следующим
параметрам:
 Рекламодатель/Рекламное агентство
 MSISDN
 Рекламная кампания
 Рекламный контент
 Канал коммуникации
 Количество отправленных сообщений
 Количество доставленных сообщений
 Количество уникальных абонентов для каждой кампании
 И др.
Минимальная глубина хранения детализированной статистики не менее 6
месяцев.
16
2.4.3. Управление системой
Система управления должна поддерживать следующие модули:
 Модуль конфигурации;
 Модуль сбора статистики;
 Модуль мониторинга системы;
 Модуль аварий с обязательной поддержкой SNMP;
 Модуль конфигурации клиентов;
 Удалённое администрирование;
 Платформа должна поддерживать управление услугой и базой данных с
помощью различных интерфейсов;
 Платформа должна обеспечивать управление услугами на нескольких уровнях в
зависимости от типа доступа (оператор, администратор, пользователь).
 Все оборудование системы должно иметь консольный доступ.
 Должна быть обеспечена возможность удалённого доступа к элементам
аппаратной части системы специалистов Компании для контроля, управления,
выяснения неисправностей, просмотра статистики и формирования отчётности
круглосуточно через WEB-интерфейс.
 Программное обеспечение должно осуществлять мониторинг всех процессов,
происходящих в системе, и обрабатывать сигналы о критических ситуациях в
режиме реального времени. Программное обеспечение платформы должно также
вести логи вводимых в систему команд, лог аварийных сообщений, и
проводимых в базе данных платформы изменений.
2.4.4. Мониторинг системы.
Модуль мониторинга Системы должен состоять из 2-х компонентов:
 Мониторинг системных ресурсов, реализуемый на базе нашей платформы HP
OVO при помощи агентов (обязательное условие - интеграция с HP OVO);
 Мониторинг
прикладных
ресурсов,
реализуемый
на
усмотрение
разработчиков.
Обязательна настройка всего оборудования, которое может отсылать SNMPтрапы, для отправки трапов на HP OVO. Должно поддерживаться 3 типа трапов:
 Трап, сигнализирующий о возникновении аварии (newAlarm).
 Трап, сигнализирующий об устранении аварии (clearAlarm).
 Трап об аварии, которая не требует устранения (Alarm).
На каждый трап newAlarm обязательно должен приходить clearAlarm.
Уникальным ключем в комбинации newAlarm/clearAlarm является связка
alarmId/object. На основе этих данных происходит автоматическое подчищение
аварий.
Пример каждого типа трапов:
1. При возникновении аварийной ситуации на платформе, формируется трап (пример
MIB-файла приведен ниже):
newAlarm {
severity ::= 5
17
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
18
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}
2.4.5. Требования к подключению к IP-сети Компании
На все оборудование должен быть реализован удаленный консольный доступ:
serial console, iLO, ALOM, iLOM, SC и т.д. (спецификация удаленного консольного
19
доступа зависит от поставщика). При использовании консольных интерфейсов в
состав платформы должен быть включен консольный роутер.
2.4.6. Платформа должна поддерживать следующие основные принципы:
 Резервируемости:
Электрическое питание программно-аппаратного комплекса осуществляется
через сеть постоянного тока (опционально).
Всё аппаратное обеспечение соответствует принципу резервируемости, т.е.
остановка функционирования одного из серверов не должна являться причиной
остановки предоставления услуги.
Для случая фатального сбоя в программно-аппаратном комплексе
предусматривается восстановление потерянных данных. Все важные данные
(например, конфигурационные файлы системы, персональные настройки
пользователей, база данных и т.п.) сохраняются на ленточном накопителе
(опционально) не реже одного раза в сутки.
После принудительной/неконтролируемой перезагрузке систем восстановление
полного функционирования комплекса происходит автоматически.
 Масштабируемости,
 Управлению перегрузками,
 Управлению ресурсами,
 Открытости (система должна иметь открытую архитектуру, использует открытые
интерфейсы взаимодействия функциональных блоков системы),
 Распределенности,
 Защищенности:
Операционная
система
программно-аппаратного
комплекса
должна
основываться на *nix-подобной системе (опционально).
Администратор платформы должен иметь средства, позволяющие ограничивать
доступ к комплексу третьих лиц не только на основе аутентификации
«логин/пароль», но и по ip адресу (опционально).
2.4.7. Требования по документации к Системе
Минимальный набор необходимой документации должен включать:
 Общее описание системы;
 Детальное описание сетевой части оборудования;
 Детальное описание аппаратной части оборудования;
 Техническая документация по эксплуатации платформы;
 Описание продукта с детальной документацией по устройству системы, её
логическим модулям, описание внутренних и внешних интерфейсов
взаимодействия, правил настройки и администрирования модулей и интерфейсов;
 Документация по формированию и мониторингу аварийных/информационных
сообщений;
Описание методов сбора и анализа статистической информации.
20
2.4.8. Требования к поддержке оборудования
В течении действующего периода технической поддержки введенной в
эксплуатацию системы поставщик решения обязан обеспечить следующий
минимальный набор услуг:
 Консультации.
 Исправление ошибок.
Детальное описание требований ОАО «МТС» к гарантийному и постгарантийному обслуживанию на поставляемое оборудование и проводимые работы
приведено в Приложении 1 «Требования SLA».
Расширение предоставляемого набора услуг является одним из положительных
факторов, влияющих на выбор победителя конкурса.
2.5. Требования к управлению проектом со стороны участника
Со стороны Участника запроса должен быть выделенный менеджер проекта с
опытом внедрения как минимум одного проекта в области интеграции с системами
МТС, специалисты по предметным блокам и технические специалисты. Участник
запроса должен предоставить детализированный план управления проектом
Мобильная реклама. План должен включать пункты:
 Управление проектом.
 Описание рабочей группы проекта, с перечислением ключевых участников.
 График реализации проекта, включающий ключевые события.
 Проект и подготовка к эксплуатации платформы Мобильная реклама: описание
предложенной платформы, ее внедрения и интеграции в сетевую инфраструктуру
МТС с учетом различных вариантов пиковой нагрузки.
 Обучение: подробное описание всех тренингов, необходимых для проекта, и их
проведения.
 Сервисное сопровождение и поддержка: подробное описание осуществления
поддержки и сопровождения
2.6. Ценовая информация
Предложение должно включать в себя описание распределения расходов по
следующим статьям:
 Оборудование: каждый компонент оборудования должен быть перечислен
отдельно с указанием стоимости в рублях.
 Программное обеспечение: программное обеспечение системы и приложений,
включая стоимость лицензий в рублях.
 Приветствуются предложения по покрытию расходов по модели разделения
доходов.
21
 Бизнес-модель и стоимость операционной поддержки бизнес-процессов.
 Стоимость дальнейшего расширения по лицензии в соответствии с региональной
структурой размещения в рублях.
 Стоимость масштабирования на другие страны присутствия МТС.
 Стоимость эксплуатации системы на 5 лет в рублях.
 Интеграция, адаптация и инсталляция: трудовой ресурс поставщика (в денежном
выражении), трудовой ресурс МТС (в кол-ве специалистов с указанием
квалификации)
 Дополнительные затраты
2.7. Дополнительные требования
Участник должен привести примеры успешных интеграции решений поставщика с
корпоративными базами данных, системами биллинга и VAS платформами (SMSC,
MMSC, ICB и др.) телекоммуникационных операторов с количеством активных
пользователей более 3 млн. Привести общее количество успешных внедрений и
крупнейшее внедрение по количеству пользователей, а так же указать примеры внедрений
с использованием федеративной архитектуры решения.
22
Порядок проведения запроса предложений. Инструкции по
подготовке Предложений
Публикация Уведомления о проведении запроса предложений
Уведомление о проведении запроса предложений было опубликовано в порядке,
указанном в пункте 1.1.1.
Предоставление Документации по запросу предложений Исполнителям
Участники должны получить Документацию в порядке, указанном в Уведомлении о
проведении запроса предложений.
Порядок предоставления Документации на последующие этапы, в случае их
проведения, будет доведен до сведения Участников дополнительно.
Подготовка Предложений
Общие требования к Предложению
Участник должен подготовить Предложение, включающее:
3.3.1.1. Письмо о подаче оферты по форме и в соответствии с инструкциями,
приведенными в настоящей Документации (Приложение №1);
3.3.1.2. Техническое предложение на оказание услуг по форме и в
соответствии с инструкциями, приведенными в настоящей Документации по
запросу предложений Приложение №2);
3.3.1.3. Ценовое предложение в соответствии с инструкциями, приведенными
в настоящей Документации по запросу предложений (Приложение №3);
3.3.1.4. Протокол разногласий к проекту Договора по форме и в соответствии
с инструкциями, приведенными в настоящей Документации по запросу
предложений (Приложение № 4);
3.3.1.5. Документы, подтверждающие соответствие Участника требованиям
настоящей Документации по запросу предложений (подраздел 0).
Участник имеет право подать только одно Предложение. В случае нарушения этого
требования все Предложения такого Участника отклоняются без рассмотрения по
существу.
Каждый документ, входящий в Предложение, должен быть подписан лицом,
имеющим право в соответствии с законодательством Российской Федерации
действовать от лица Участника без доверенности, или надлежащим образом
уполномоченным им лицом на основании доверенности. В последнем случае
оригинал доверенности прикладывается к Предложению.
Каждый документ, входящий в Предложение, должен быть скреплен печатью
Участника.
Требования пунктов 3.3.3. и 3.3.4. не распространяются на нотариально заверенные
копии документов или документы, переплетенные типографским способом.
Документы (листы и информационные конверты), входящие в Предложение,
должны быть скреплены или упакованы таким образом, чтобы исключить случайное
выпадение или перемещение страниц и информационных конвертов.
23
Участник также должен подготовить одну копию Предложения.
Никакие исправления в тексте Предложения не имеют силу, за исключением тех
случаев, когда эти исправления заверены рукописной надписью «исправленному
верить» и собственноручной подписью уполномоченного лица, расположенной
рядом с каждым исправлением.
Организатор по окончании запроса предложений возвращает (по просьбе
Участника) оригиналы всех материалов, вложенные в информационные конверты, за
исключением тех оригиналов, не имеющих копий, на основании рассмотрения
которых было принято решение об отклонении или принятии Предложения данного
Участника.
Требования к языку Предложения
3.3.10.1. Все документы, входящие в Предложение, должны быть
подготовлены на русском языке за исключением нижеследующего.
3.3.10.2. Документы, оригиналы которых выданы Участнику третьими лицами
на ином языке, могут быть представлены на языке оригинала при условии, что
к ним приложен перевод этих документов на русский язык (в специально
оговоренных случаях — апостилированный). При выявлении расхождений
между русским переводом и оригиналом документа на ином языке Организатор
будет принимать решение на основании перевода.
3.3.10.3. Организатор вправе не рассматривать документы, не переведенные на
русский язык.
Разъяснение Документации по запросу предложений
3.3.11.1. Участники вправе обратиться к Организатору за разъяснениями
настоящей Документации по запросу предложений. Запросы на
разъяснение Документации по запросу предложений должны
подаваться в письменной форме за подписью руководителя
организации или иного ответственного лица Участника.
3.3.11.2. Организатор в разумный срок ответит на любой вопрос, который он
получит не позднее, чем за 2 дня до истечения срока приема Предложения
(пункт 3.5.5.). Если, по мнению Организатора, ответ на данный вопрос будет
интересен всем Участникам, копия ответа (без указания источника запроса)
будет направлена всем Участникам, официально получившим настоящую
Документацию (подраздел 3.2.1).
Продление срока окончания приема Предложений
3.3.12.1. При необходимости Организатор имеет право продлевать срок
окончания приема Предложений, установленный в подпункте 3.5.5. с
уведомлением всех Участников.
3.3.12.2. Все Участники, официально получившие настоящую Документацию
(подраздел 3.2.1), незамедлительно уведомляются об этом с использованием
средств оперативной связи (телефон, факс, электронная почта).
Требования к Участникам. Подтверждение соответствия предъявляемым
требованиям
Требования к Участникам
3.4.1.1. Участвовать в данной процедуре Запроса предложений может либо
любое юридическое или физическое лицо. Чтобы претендовать на победу в
данной процедуре Запроса предложений и на право заключения Договора,
24
Участник на момент подачи Предложения должен отвечать следующим
требованиям:
o Наличие опыта работы с крупными корпоративными клиентами на
российском рынке - не менее3 лет;
o Наличие опыта разработки и внедрения аналогичных систем;
o Наличие возможности оказания технической поддержки в режиме 24х7;
o Организация не должна находиться под процедурой банкротства, в
процессе ликвидации или реорганизации, на ее имущество не должен
быть наложен арест.
Требования
к
документам,
подтверждающим
соответствие
Участника
установленным требованиям
3.4.2.1. В связи с вышеизложенным Участник должен включить в состав
Предложения следующие документы, подтверждающие его соответствие
вышеуказанным требованиям:
o нотариально заверенные копии учредительных документов;
o нотариально заверенную копию свидетельства о регистрации;
o формы бухгалтерской отчетности (ф. № 1, 2) за 1ый квартал 2009 года.
o справка об отсутствии решений органов управления организации или
судебных органов о ликвидации или реорганизации организации или
ареста ее имущества подписанную руководителем организации;
3.4.2.2. Все указанные документы прилагаются Участником к Предложению.
3.4.2.3. В случае если по каким-либо причинам Участник не может
предоставить требуемый документ, он должен приложить составленный в
произвольной форме справку, объясняющую причину отсутствия требуемого
документа, а также содержащую заверения Организатору в соответствии
Участника данному требованию.
Подача Предложений и их прием
Перед подачей Предложение и его копия должны быть надежно запечатаны в
конверты (пакеты, ящики и т.п.). Предложение и его электронная копия (компактдиск или дискета) запечатывается в конверт, обозначаемый словами «Оригинал
Предложения». Копия Предложения запечатывается в конверт, обозначаемый
словами «Копия Предложения». На каждом из этих конвертов также необходимо
указать следующие сведения:
 наименование и адрес Организатора в соответствии с пунктом 1.1.1.;
 полное фирменное наименование Участника и его почтовый адрес;
Кроме того, Участник доставляет копию коммерческого предложения (т.е
только ценовое предложение) по адресу 109147, Москва, ул.Марксистская д.4.
ДУВР комн.410.
Запечатанные конверты с Предложением и его копией помещаются в один
внешний конверт, который также должен быть надежно запечатан. На внешнем
конверте указывается следующая информация:
 наименование и адрес Организатора в соответствии с пунктом 1.1.1.;
 пометку «Не вскрывать» до 07.07.2009, 12-00 часов (время московское).
Вскрывать только на заседании Закупочной комиссии».
25
Если иное не предусмотрено правилами почтовой или курьерской пересылки, на
внешнем конверте не следует указывать адрес Участника.
Участники должны обеспечить доставку своих Предложений по месту
нахождения Организатора: 109147, Москва, ул. Марксистская д.34, стр. 10. При этом
Участникам запроса предложений рекомендуется предварительно позвонить по тел.
89154796840, контактное лицо – Болдарева Светлана Владимировна. В случае
направления Предложения через курьерскую службу рекомендуется уведомить
представителя курьерской службы или курьера о настоящем порядке доставки
Предложения.
Организатор заканчивает принимать Предложения в 17:00 часов (московское
время) 06.07.2009. Предложения, полученные позже установленного выше срока,
будут отклонены Организатором без рассмотрения по существу, независимо от
причин опоздания.
Организатор выдает расписку лицу, доставившему конверт, о его получении с
указанием времени получения.
26
Оценка Предложений и проведение переговоров
Общие положения
Оценка Предложений осуществляется Закупочной комиссией по запросу
предложений и иными лицами (экспертами и специалистами), привлеченными Закупочной
Комиссией.
Оценка Предложений включает отборочную стадию, проведение при необходимости
переговоров и оценочную стадию.
Отборочная стадия
В рамках отборочной стадии Закупочная комиссия проверяет:
 правильность оформления Предложений и их соответствие требованиям
настоящей Документации по существу;
 соответствие Участников требованиям настоящей Документации;
 соответствие коммерческого и технического предложения требованиям
настоящей Документации.
В рамках отборочной стадии Комиссия по запросу предложений может запросить
Участников разъяснения или дополнения их Предложений, в том числе представления
отсутствующих документов. При этом Комиссия по запросу предложений не вправе
запрашивать разъяснения или требовать документы, меняющие суть Предложения.
При проверке правильности оформления Предложения Комиссия по запросу
предложений вправе не обращать внимания на мелкие недочеты и погрешности, которые
не влияют на существо Предложения. Комиссия по запросу предложений с письменного
согласия Участника также может исправлять очевидные арифметические и
грамматические ошибки.
По результатам проведения отборочной стадии Комиссия по запросу предложений
имеет право отклонить Предложения, которые:
 в существенной мере не отвечают требованиям к оформлению настоящей
Документации;
 поданы Участниками, которые не отвечают требованиям настоящей
Документации;
 содержат предложения, по существу не отвечающие техническим,
коммерческим или договорным требованиям настоящей Документации;
 содержат очевидные арифметические или грамматические ошибки, с
исправлением которых не согласился Участник.
Проведение переговоров
После рассмотрения и оценки Предложений Организатор вправе провести
переговоры с любым из Участников по любому положению его Предложения.
Переговоры могут проводиться в один или несколько туров. Очередность
переговоров устанавливает Организатор. При проведении переговоров Организатор будет
избегать раскрытия другим Участникам содержания полученных Предложений, а также
хода и содержания переговоров, т.е.:
 любые
переговоры
между
Организатором
и
Участником
носят
конфиденциальный характер;
 ни одна из сторон переговоров не раскрывает никакому другому лицу никакой
технической, ценовой или иной рыночной информации, относящейся к этим
переговорам, без согласия другой стороны.
27
Организатор в результате переговоров может предложить:
 выступить любому из Участников в качестве генерального исполнителя и
привлечь в качестве соисполнителя как любого из Участников, так и стороннюю
организацию;
 объединиться нескольким конкретным Участникам в коллективного участника.
 Любой из Участников вправе отказаться от этого предложения без каких-либо
последствий и участвовать в дальнейшей процедуре Запроса предложений
самостоятельно.
Оценочная стадия
В рамках оценочной стадии Комиссия оценивает и сопоставляет Предложения, в том
числе с учетом результатов переговоров, и проводит их ранжирование по степени
предпочтительности для Организатора, исходя из следующих критериев:
1
1.1
1.2
1.3
1.4
2
Опыт участника
Участник имеет опыт установки подобных решений у операторов мобильной связи
Участник предоставил рекомендательные письма
Опыт реализации совместных с МТС проектов в области дополнительных услуг
Наличие опыта интеграции с сетью МТС
Бизнес требования
30
40
40
30
2.1
Обеспечение единого интерфейса управления функциональными возможностями
платформы Мобильная реклама
2.2
2.3
3
Предложения поставщика по дополнительному функционалу, способу реализации
единого интерфейса управления платформой
Участник представил предложение по операционной поддержке бизнес-процессов
Функциональность продукта
3.1
Участник предоставил подробную блок-схему решения с подробным описанием
алгоритма взаимодействия блоков платформы
50
3.2
Участник подробно описал процесс планирования РК. Предложение Участника
удовлетворяет всем функциональным требованиям к планированию РК
50
3.3
Решение Участника предоставляет широкие возможности создания интерактивных
сценариев РК и способов получения отклика на РК от абонентов
40
3.4
Предложение Участника удовлетворяет всем функциональным требованиям к
согласованию РК
50
3.5
Участник подробно описал структуру базы данных платформы и систему управления
этими данными
50
3.6
3.7
Участник предложил подробное описание логики конвертации параметров профилей
абонентов в критерии выборки. Описанная логика предоставляет широкие возможности для
таргетирования РК
Участник подробно описал логику выбора каналов для каждой РК и распределение
абонентов по ним
Участник подробно расписал систему приоритетов РК
50
50
50
50
50
40
3.8
Участник предоставил подробное описание системы управления размещением
рекламного контента, позволяющей оптимально использовать ресурсы (свободные емкости)
каналов доставки
70
3.9
Предложение Участника удовлетворяет всем функциональным требованиям к доставке
рекламного контента, подробно описаны возможные каналы доставки рекламного контента и
сам процесс доставки через эти каналы
70
3.10
Участник предоставил подробное описание алгоритма выбора рекламного контента
для абонентов pull-каналов
50
28
3.11
Предложение Участника содержит подробное описание системы сбора и анализа
статистики, перечень отчетов, доступных в он-лайн режиме и по итогам РК, примеры
визуализации отчетов
40
3.12
3.13
Предложение Участника удовлетворяет всем функциональным требованиям к
биллингу. Участник подробно описал систему расчета стоимости РК.
Решение Участника предоставляет возможность он-лайн биллинга РК
40
40
3.14
3.15
3.16
4
Предложение Участника удовлетворяет всем функциональным требованиям к
администрированию системы
Участник предоставил программу развития платформы
Участник предложил дополнительные функциональные возможности системы
Технические требования
4.1
4.2
Решение участника имеет распределенную архитектуру в соответствии с
требованиями заказчика
Предоставлены требования к транспортной инфраструктуре ОАО МТС
4.5
Решение удовлетворяет требованиям заказчика по синхронизации баз данных
распределенных модулей платформы мобильной рекламы
Производительность платформы по каналам доставки удовлетворяет требованиям
заказчика.
Предложенная в решении участника интеграция системы с платформами и
комплексами заказчика удовлетворяет требованиям заказчика
4.6
Порядок взаимодействия системы мобильной рекламы с платформами и комплексами
оператора удовлетворяет требованиям заказчика
4.3
4.4
4.7
4.8
4.9
4.10
4.11
4.12
4.13
4.14
4.15
5
5.1
5.2
5.3
6
Предложенное решение имеет открытую архитектуру и использует открытые
интерфейсы взаимодействия функциональных блоков системы
Предоставлена подробная схема масштабируемости платформы в соответствии с
требованиями заказчика по развитию платформы (в части расширения баз данных,
увеличения производительности доставки рекламных сообщений по pull и push каналам) с
описанием линейки шагов, их стоимости, необходимой дополнительной мощности
электропотребления, дополнительного места (дополнительные unit в стойке, дополнительные
стойки) и т.д.
Предлагаемое решение участника удовлетворяет требованиям заказчика по сбору
статистики
Решение участника удовлетворяет требованиям заказчика по управлению системой
мобильная реклама
Решение участника удовлетворяет требованиям заказчика по мониторингу системы
мобильная реклама
Решение участника соответствует требованию по резервируемости системы и другим
основным принципам, поддерживаемым платформой в соответствии с требованиями
заказчика
Поставщик готов оказывать полноценную техническую поддержку продукта, включая
обеспечение незамедлительной реакции технических служб в случае возникновения
технических неполадок и аварийных ситуаций согласно требованиям ОАО «МТС»
(Приложение №4).
Соответствие требованиям МТС к управлению проектом
Поставщик обеспечивает обучение специалистов МТС по эксплуатации платформы
Сроки и стоимость
Участник предложил наиболее выгодную для Оператора финансовые условия
Участник предложил наименьшую стоимость операционной поддержки
Сроки поставки и запуска в коммерческую эксплуатацию платформы составляют 4
месяца с момента подписания договора
Дополнительные требования
29
50
40
30
70
60
60
60
60
60
60
60
60
60
60
60
60
70
60
1200
580
300
6.1
Участник должен привести примеры успешных интеграций систем поставщика с
корпоративными базами данных, системами биллинга и VAS платформами (SMSC, MMSC,
ICB и др.) телекоммуникационных операторов с количеством активных пользователей более
3 млн.
Итого (возможное максимальное количество баллов)
60
4160
Победителем объявляется Участник, набравший наибольшее количество баллов.
Принятие решения о проведении следующих этапов Запроса предложений или
определение Победителя
Закупочная комиссия на своем заседании принимает решение либо по определению
Победителя, либо по проведению дополнительных этапов Запроса предложений,
либо по завершению данной процедуры Запроса предложений без определения
Победителя и заключения Договора.
В случае если Предложение какого-либо из Участников окажется существенно
лучше Предложений остальных Участников, и это Предложение полностью
удовлетворит Организатора, Организатор определит данного Участника
Победителем и подпишет с ним Договор.
В случае если самое лучше Предложение не удовлетворит Организатора полностью,
Закупочная комиссия вправе принять решение о проведении дополнительных этапов
Запроса предложений и внесении изменений в условия Запроса предложений.
Если, по мнению Закупочной комиссии, возможностей для улучшения
Предложений Участников не предвидится и проведение дальнейших этапов
бессмысленно, Закупочная комиссия вправе принять решение о прекращении
процедуры Запроса предложений.
Решение Закупочной комиссии оформляется протоколом заседания комиссии.
Уведомление Участников о результатах запроса предложений
Организатор незамедлительно после подписания Договора направит всем
Участникам письменное уведомление, в котором указывает наименование и адрес
Победителя, подписавшего Договор;
Организатор вправе опубликовать вышеприведенные сведения о результатах
запроса предложений.
30
Образцы основных форм документов,
включаемых в Предложение
Письмо о подаче оферты (форма 1)
Форма письма о подаче оферты
начало формы
«_____»_______________ года
№________________________
Уважаемые господа!
Изучив Уведомление о проведении запроса предложений, опубликованное
[указывается источник и дата публикации], и Документацию по запросу предложений,
и принимая установленные в них требования и условия запроса предложений,
________________________________________________________________________,
(полное наименование Участника с указанием организационно-правовой формы)
зарегистрированное по адресу
________________________________________________________________________,
(юридический адрес Участника)
предлагает заключить Договор на оказание следующих услуг:
________________________________________________________________________
(краткое описание оказываемых ус луг)
на условиях и в соответствии с Техническим предложением, Графиком оказания услуг,
Сметой расходов и Графиком оплаты оказания услуг, являющимися неотъемлемыми
приложениями к настоящему письму и составляющими вместе с настоящим письмом
Предложение, на общую сумму
Итоговая стоимость Предложения с НДС, ___________________________________
руб.
(итоговая стоимость, рублей, без НДС)
Настоящее
Предложение
имеет
правовой
до «____»_______________________года.
31
статус
оферты
и
действует
Настоящее Предложение дополняется следующими документами, включая
неотъемлемые приложения:
[Указывается перечень прилагаемых документов:
1. Техническое предложение на оказание услуг (форма 2) — на ____ листах;
2. Приложения на ____ листах;
3. Документы, подтверждающие соответствие Участника установленным
требованиям — на ____ листах.
4. И т.д.]
____________________________________
(подпись, М.П.)
____________________________________
(фамилия, имя, отчество подписавшего, должность)
конец формы
Инструкции по заполнению
Письмо следует оформить на официальном бланке Участника. Участник присваивает
письму дату и номер в соответствии с принятыми у него правилами документооборота.
Участник должен указать свое полное наименование (с указанием организационноправовой формы) и юридический адрес.
Участник должен указать стоимость оказания услуг цифрами и словами, в рублях, с
НДС.
Письмо должно быть подписано и скреплено печатью в соответствии с требованиями
подпунктов 0 и 0.
32
Техническое предложение на оказание услуг (форма 2)
Форма Технического предложения на оказание услуг
начало формы
Приложение 1 к письму о подаче оферты
от «____»_____________ г. №__________
Техническое предложение на оказание услуг
Наименование и адрес Участника: _________________________________
(Здесь Участник в свободной форме приводит свое техническое предложение, опираясь на
проект Технического задания на оказание услуг в соответствии с требованиями раздела
2)
____________________________________
(подпись, М.П.)
____________________________________
(фамилия, имя, отчество подписавшего, должность)
конец формы
Инструкции по заполнению
Участник указывает дату и номер Предложения в соответствии с письмом о подаче
оферты.
Участник указывает свое фирменное наименование (в т.ч. организационно-правовую
форму) и свой адрес.
В техническом предложении описываются все позиции раздела 2 с учетом
предлагаемых условий Договора. Участник вправе указать, что он согласен на проект
Технического задания, изложенного в разделе 2.
33
Анкета Участника (форма 3)
Форма Анкеты Участника
начало формы
Приложение 2 к письму о подаче оферты
от «____»_____________ г. №__________
Анкета Участника
Наименование и адрес Участника: _________________________________
№
п/п
Наименование
1.
4.
Организационно-правовая форма и
фирменное наименование Участника
Учредители (перечислить наименования
и организационно-правовую форму или
Ф.И.О. всех учредителей, чья доля в
уставном капитале превышает 10%)
Свидетельство о внесении в Единый
государственный реестр юридических
лиц (дата и номер, кем выдано)
ИНН Участника
5.
Юридический адрес
6.
Почтовый адрес
7.
Филиалы: перечислить наименования и
почтовые адреса
Банковские реквизиты (наименование и
адрес банка, номер расчетного счета
Участника в банке, телефоны банка,
прочие банковские реквизиты)
Телефоны Участника (с указанием кода
города)
Факс Участника (с указанием кода
города)
Адрес электронной почты Участника
2.
3.
8.
9.
10.
11.
12.
Сведения об Участнике
Фамилия, Имя и Отчество руководителя
Участника, имеющего право подписи
согласно учредительным документам
Участника, с указанием должности и
контактного телефона
34
№
п/п
Наименование
13.
Фамилия, Имя и Отчество главного
бухгалтера Участника
Фамилия, Имя и Отчество
ответственного лица Участника с
указанием должности и контактного
телефона
14.
Сведения об Участнике
____________________________________
(подпись, М.П.)
____________________________________
(фамилия, имя, отчество подписавшего, должность)
конец формы
Инструкции по заполнению
Участник указывает дату и номер Предложения в соответствии с письмом о подаче
оферты.
Участник указывает свое фирменное наименование (в т.ч. организационно-правовую
форму) и свой адрес.
Участники должны заполнить приведенную выше таблицу по всем позициям. В
случае отсутствия каких-либо данных указать слово «нет».
В графе 8 «Банковские реквизиты…» указываются реквизиты, которые будут
использованы при заключении Договора.
35