Техническое задание для поставщиков. Приложение №2 к Закупочной документации



страница14/14
Дата24.04.2016
Размер0.9 Mb.
1   ...   6   7   8   9   10   11   12   13   14

Информация об Участнике


  1. Предложение должно содержать:

  • краткую информацию о компании-Участнике (профиль), истории, структуре, линейке поддерживаемых продуктов,

  • информацию о заказчиках, сотрудничавших с Участником (см. также 11.2 «Опыт внедрения аналогичных проектов»),

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

  • сертификаты компании в области ITIL/ITSM,

  • текущий статус партнерских отношений с производителями составляющих решения.

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

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


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

  • название, местоположение и бизнес-сектор компании, в которой выполнен проект/предоставлены услуги поддержки,

  • количество пользователей ITSM решения,

  • суть проекта/предоставленных услуг,

  • даты начала и завершения соответствующих проектов/контрактов,

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

  • письменные отзывы заказчиков завершенных проектов,

  • контактная информация представителей компании (имя, должность, телефон, электронный адрес), которые могут дать рекомендации в отношении выполненного проекта/предоставленных услуг8.
    1. Организационная структура, опыт и квалификация проектной команды


      1. Предложение должно содержать полный перечень специалистов, входящих в состав проектной команды. ВАЖНО: любые дальнейшие изменения заявленного состава участников проекта со стороны Исполнителя должны быть согласованы с Заказчиком; несогласованное изменение может служить основанием для разрыва договорных отношений.

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

  • имя,

  • должность и отношение к Участнику (штатный/будет нанят/представитель субподрядчика),

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

  • выделенная занятость на проекте («100% - только данный проект»/«X% - частично в проекте»)

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

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

  • Менеджер проекта от Исполнителя,

  • Главный архитектор,

  • Технический эксперт (с указанием специализации),

  • Главный эксперт по проектированию и документированию процессов,

  • Эксперты по проектированию и документированию процессов.
    1. Презентация продукта


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

    Ориентировочный план презентации



  1. Вводная информация о производителе решения, продукте и интеграторе (презентация проектной команды) - не более 15 минут.

  2. Краткий обзор предлагаемого решения - 1 час.

    1. Общие характеристики

    2. Архитектура

    3. Внешний вид и возможности интерфейсов

  3. План и подходы к реализации проекта - 1 час.

  4. Реализация предложенных сценариев - 3 часа.



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

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

    2. Информация предложения должна быть предоставлена как в распечатанном виде на бумажном носителе, так и в электронном виде, в двух экземплярах. Формат предоставляемых файлов – MS Word.

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

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

    5. Предложение должно содержать схему функциональной структуры Системы и интеграционную схему решения.

    6. Предложение должно содержать КПЭ проекта (в формате, указанном в Приложении 5) и модель расчета окупаемости решения (технико-экономическое обоснование). При необходимости вводных данных Заказчика для построения модели расчета окупаемости, они будут предоставлены по запросу.

    7. Предложение должно содержать анализ рисков проекта в формате таблицы, представленной в Приложении 6.

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

  2. Коммерческая доступность продуктов и технологий

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




  1. Приложения

Приложение 1. Ценообразование



Приложение 2. Информация об обучении



Приложение 3. Информация о внедренных проектах



Приложение 4. Таблица соответствия требованиям



Приложение 5. Ключевые показатели эффективности проекта



Приложение 6. Анализ рисков



Приложение 7. Стандарт СТ-БЕУ-081 «Требования информационной безопасности для новых информационных систем»



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





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

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

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

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

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

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

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

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

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

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



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

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

2 Альтернатива – обеспечение аналогичного функционала средствами самой Системы.

3 И, при необходимости, уточнены и доработаны по результатам опытно-промышленной эксплуатации.

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

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

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




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

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

9 Данный перечень не является ограничивающим.

Стр. из
1   ...   6   7   8   9   10   11   12   13   14


База данных защищена авторским правом ©bezogr.ru 2016
обратиться к администрации

    Главная страница