1304030 - Альфа-Банк
advertisement
КОНКУРСНАЯ ДОКУМЕНТАЦИЯ № 1304030 1. Приглашение 1.1. ОАО «Альфа-Банк» приглашает Вашу компанию принять участие в проводимом «03» апреля 2013 года в Центральном офисе Банка (г. Москва, ул. Каланчевская, 27, см. схему) открытом конкурсе по выбору партнеров Банка: 1.1.1. на разработку решений по автоматизации процессов кредитования физических лиц для ОАО "АЛЬФА-БАНК" в срок до 31 декабря 2014 года (Задача № 1). 1.1.2. на оказание услуг по контролю качества (QA) при создании автоматизированной системы обработки кредитных заявок для ОАО "АЛЬФА-БАНК" в срок до 31 декабря 2014 года (Задача № 2). 1.2. Предметом конкурса является наилучшее предложение о заключении договора на следующих условиях 1.2.1. По Задаче № 1: ► объем выполняемых работ Объем выполняемых работ по доработке, настройке, инсталляции и сопровождению программного обеспечения указан в «Запросе коммерческого предложения на разработку решений по автоматизации процессов кредитования физических лиц» (Приложение № 1 к конкурсной документации); участие в функциональном и нагрузочном тестированиях; участие во внедрении; участие в опытно-промышленной эксплуатации и обеспечение оперативной поддержки опытно-промышленной эксплуатации; исправление дефектов, выявленных в течение 1 года с момента запуска в промышленную эксплуатацию каждой поставки. ► платежные условия договора 30% - аванс после подписания договора; 70% - после подписания Акта сдачи приемки выполненных работ. ► срок исполнения обязательств партнера Предельные сроки выполняемых работ по доработке, настройке и инсталляции программного обеспечения указаны в Приложении № 1 к конкурсной документации. ► прочие условия Партнер передает ОАО «Альфа-Банк» исключительные права на проведенные на платформе доработки. ► 1.2.2. По Задаче № 2: объем выполняемых работ Объем и состав услуг по контролю качества при создании автоматизированной системы обработки кредитных заявок приведены в «Запросе коммерческого предложения на услуги по контролю качества при создании автоматизированной системы обработки кредитных заявок (QA)» (Приложение № 2 к конкурсной документации); Осуществление архитектурного надзора; ► ► ► Осуществление технического надзора; Осуществление контроля качества поставок; Осуществление консультации разработчиков автоматизированной системы обработки кредитных заявок и сотрудников Банка по решениям Pegasystems (Pega Rules Process Commander, Business Intelligence Exchange (BIX), Internet Application Composer (IAC), Automic Event Service (AES), PRPC-Foundation bridge и пр.). платежные условия договора 30% - аванс после подписания договора; 70% - после подписания Акта сдачи приемки оказанных услуг. срок исполнения обязательств партнера Сроки оказания услуг соответствуют срокам реализации «Программы автоматизации процесса кредитования физических лиц», указанным в Приложении № 2 к конкурсной документации. прочие условия Партнер передает ОАО «Альфа-Банк» исключительные права на все результаты, полученные при оказании услуг. 1.3. Участники конкурса должны удовлетворять следующим требованиям: наличие аккредитации по решениям Pegasystems; ► наличие опыта консалтинговых услуг по решениям Pegasystems (только для Задачи № 2); ► наличие завершенных проектов по внедрению решений Pegasystems (Pega Rules Process Commander, Business Intelligence Exchange (BIX), Internet Application Composer (IAC), Automic Event Service (AES), PRPC-Foundation bridge); ► наличие квалифицированного сертифицированного персонала с опытом инсталляции, доработки, настройки и сопровождения программного обеспечения на базе решений Pegasystems; ► наличие специалистов по оказанию услуг технической поддержки (в режиме 24х7) (только для Задачи № 1); ► 1.4. Конкурсные предложения, содержащие ссылку на номер конкурса, будут приниматься от уполномоченных лиц СТРОГО В УСТАНОВЛЕННОЕ ВРЕМЯ: с 10-00 до 17-00 мск. «03» апреля 2013 г. только по электронной почте в любом распространенном формате MS (сканированные документы - в ZIP-файлах) Секретарем Тендерного Комитета ОАО «Альфа-Банк» Мицкевич Мариной Рудольфовной, телефон: +7 (495) 604-79-91; адрес электронной почты: tendcom@alfabank.ru. 1.5. Уполномоченный сотрудник Банка для получения разъяснений по техническим вопросам – Виславский Артем Витальевич, телефон: +7 (495) 620-91-91 доб. 011 5865, адрес электронной почты avvislavskiy@alfabank.ru. 1.6. Конкурсные предложения, переданные способом, отличным от указанного, а также не содержащие ссылку на номер конкурса, не рассматриваются. 2. Критерий определения Победителей конкурса 2.1. Определение победителей конкурса проводится в два этапа. Первым этапом определяется победитель по Задаче № 1, из числа предоставивших необходимую информацию (указанную в Приложении № 1 к конкурсной документации) по данной задаче, вторым этапом определяется победитель по Задаче № 2, из числа предоставивших необходимую информацию (указанную в Приложении № 2 к конкурсной документации) по данной задаче. Победитель по Задаче № 1 выбывает из участников конкурса по Задаче № 2 даже в случае предоставления им предложения по обеим задачам (перечисленным в п.п. 1.1). 2.2. При определении Победителя конкурса по Задаче № 1 выделяются следующие оцениваемые параметры конкурсных предложений (в скобках – обозначение весового коэффициента): 2.2.1. Стоимость работ по разработке решений, включая стоимость необходимых доработок платформы (a1 – 55%); 2.2.2. Стоимость годового сопровождения поле периода опытно-промышленной эксплуатации (b1 – 15%); 2.2.3. Качество, включая: (c1 – 30%). - сроки выполнения работ; - квалификация компании; - наличие сертификатов у персонала. - предлагаемая архитектурно-техническая реализация решения. 2.3. Сумма весовых коэффициентов (a1+b1+c1) должна быть равной 100%. 2.4. Каждый из параметров (п.п. 2.2.1 – 2.2.4) оценивается экспертно (от 1 до 5 баллов). 2.5. При определении Победителя конкурса по Задаче № 2 выделяются следующие оцениваемые параметры конкурсных предложений (в скобках – обозначение весового коэффициента): 2.5.1. Стоимость услуг по надзору и контролю качества (a2 – 55%); 2.5.2. Стоимость услуг по консалтингу (b2 – 15%); 2.5.3. Качество, включая: (c2 – 30%). - квалификация компании; - наличие сертификатов у персонала. 2.6. Сумма весовых коэффициентов (a2+b2+c2) должна быть равной 100%. 2.7. Каждый из параметров (п.п. 2.5.1 – 2.5.3) оценивается экспертно (от 1 до 5 баллов). 2.8. Подведение итогов (расчет комплексной оценки конкурсного предложения) участников производится в соответствии с утвержденными в ОАО «Альфа-Банк» правилами. 3. Конкурсные предложения должны содержать: 3.1. Информацию, необходимую для оценки параметров по указанным в п. 2 конкурсной документации критериям в форматах, описанных в соответствующих запросах коммерческих предложений (Приложения № 1 и № 2 к конкурсной документации). 3.2. Полное наименование компании, организационно-правовая форма, место и дата регистрации, юридический и почтовый адрес, полные банковские реквизиты, контактные телефоны, адрес электронной почты. 3.3. Сведения о соответствии требованиям, предъявляемым к участникам конкурса. 3.4. Краткое представление о компании, включающее в себя описание основных направлений деятельности и инфраструктуры компании. 3.5. Сведения о наличии лицензий, необходимых для выполнения работ в данном конкурсном проекте (копии в ZIP-файле). 4. Прочие условия 4.1. Каждая компания участник данного закрытого конкурса вправе предоставить требуемую для оценки ее предложения информацию (п. 3) по всем задачам, перечисленным в п.п. 1.1, либо только по одной из них. 4.2. В случае если информация, перечисленная в п.п. 3.4–3.5 ранее представлялась в ОАО «Альфа-Банк», просим сделать соответствующую ссылку и согласовать вопрос о необходимости её представления с сотрудником Банка, указанным в п. 1.5. 4.3. Сроки действия условий конкурсных предложений и заключения договора – до «31»декабря 2014 г. 4.4. Сообщение об итогах конкурса, содержащее, в случае признания его состоявшимся, наименование Победителя, высылается участникам после подведения итогов. Приложение № 1 к конкурсной документации «Программа автоматизации процесса кредитования физических лиц» Запрос коммерческого предложения на разработку решений по автоматизации процессов кредитования физических лиц Москва 2013 5 Ф.И.О. Утверждено: Бабаджанян Григорий Хачатурович Должность Дата Директор по продуктам Дирекция по продуктам Андрианова Наталия Викторовна Директор Дирекция бизнес-процессов Панкратов Михаил Викторович Директор Дирекция розничных технологий Согласовано: Володин Иван Андреевич Закерова Ольга Борисовна Герценштейн Сергей Витольдович Виславский Артем Витальевич Начальник Управления Управление внедрения и сопровождения продуктов Начальник Управления Управление технологий и тестирования Начальник Управления Управление технологий розничного кредитования Руководитель направления Дирекция розничных технологий 6 Подпись 1 ГЛОССАРИЙ Сокращение Банка, Заказчик БРБ ББ ПО НФОС SLOLP SLOLP AF SLOLP CF SLOLP MG SLOLP RB RFP BRD FSD ТЗ ОТАР DRP ОПЭ SIT LN UAT Заявитель Клиент Подрядчик, Поставщик, Поставщик услуг по разработке Поставщик услуг QA Вендор ТЦ Канал «VIP» Определение понятия Альфа-Банк Блок «Розничный бизнес» Блок «Безопасность» Программное обеспечение Новая фронт-офисная система Используемая в Банке фронт-система для создания и обработки кредитных заявок Используемая в Банке фронт-система для создания и обработки заявок на получение авто кредитов Используемая в Банке фронт-система для создания и обработки заявок на получение потребительских кредитов Используемая в Банке фронт-система для создания и обработки заявок на получение ипотечных кредитов Используемая в Банке фронт-система для создания и обработки заявок на получение розничных кредитов Request for Proposal - Запрос коммерческого предложения. Документ, подготавливаемый Банком с целью принятия обоснованного решения при выборе платформы / технологии для создания новой системы Business Requirements Document – Документ, содержащий описание бизнес-требований Functional Specifications Document – Документ, содержащий функциональный дизайн системы Техническое задание Организационно-технологическое архитектурное решение Disaster Recovery Plan (План восстановления системы после сбоев) Опытно-промышленная эксплуатация System Integration Testing Load Testing User Acceptance Testing Любое физическое лицо, обратившееся в Банк за какимлибо продуктом и/или услугой Физическое лицо, имеющее некоторые договорный отношения с Банком Организация, предоставляющая услуги по разработки и внедрению программного обеспечения Организация, предоставляющая услуги по оценке и контролю качества, а также консультационные услуги по определенным информационным технологиям Лицензиар программного обеспечения Торговый центр Специализированный канал обслуживания VIP клиентов Банка (может находиться в отделениях Банка, 7 Сокращение Канал «Кредитный брокер» Канал «Интернет магазин» Канал «Интернет» Канал «Отделение» Канал «POS» Канал «DSA» Канал «Телемаркетинг» CRUD LDAP SLA CO MC BC BO Определение понятия специализированных офисах Банка, либо обслуживается закрепленными за VIP клиентами менеджерами) Организации, работающие с Банком по агентской схеме (регистрация кредитной заявки происходит через собственное ПО партнеров) Канал кредитования клиентов интернет-магазинов (кредитная заявка заводится либо посредством специального ПО интернет-магазина, либо непосредственно через фронт-систему Банка) Канал самообслуживания, позволяющий заявителям самостоятельно заводить заявки на продукты Банка через Интернет Канал, представляющий из себя специально оборудованное помещение для обслуживания физических и юридических лиц работниками Банка Point of sale - Канал, представляющий из себя специально оборудованное рабочее место, обычно, находящееся в ТЦ, крупных магазинах, рынках и т.п. При этом продажей банковских продуктов может заниматься как сотрудник банка, так и наемный работник третьей организации Direct Sales Agents - Канал, продажи в котором осуществляют мобильные агенты (работники Банка) Обычно продажи осуществляются через презентации этими агентами продуктов Банка (на территории компаний, ТЦ и пр.) с последующей индивидуальной работой с каждым изъявившим желание заявителем Канал, обслуживающий заявителей посредством телефонной связи. Возможны как исходящие «обзвоны» потенциальных клиентов, так и обращения заинтересованных заявителей в Банк Возможные действия над объектом в системе: Create (создание), Read (чтение), Update (обновление), Delete (удаление) Lightweight Directory Access Protocol Service Level Agreement CORE — Программно-аппаратные компоненты, обеспечивающие ба-зовые системные сервисы для всех остальных классов систем. Mission Critical — Системы, позволяющие Банку выполнять свои ба-зовые функции, невозможность осуществления которых в течение 1 суток приводит к отзыву лицензии. Business Critical — Системы, обеспечивающие поддержку различных бизнесов Банка. Недоступность этих систем в течение 1 суток приводит к прямым финансовым потерям, потерям в результате упущенной выгоды и потерям, связанным с ущербом имиджу Банка. Business Operational — Системы, обеспечивающие поддержку раз-личных бизнесов Банка. Недоступность этих систем в течение 1 суток не приводит к существенным 8 Сокращение OP Целевая платформа Определение понятия финансовым потерям. Office Productivity — Офисные приложения, обеспечивающие эффек-тивную работу персонала Банка. Основная платформа для автоматизации бизнеспроцессов. Утвержденной является PEGA PRPC. 9 2 ОБЗОР ПРОГРАММЫ 2.1 Цели и задачи Программы Целью Программы является повышение эффективности и обеспечение гибкости бизнес-процессов кредитования физических лиц. Реализация этой цели позволит: За счет использования современной платформы и с учетом требований к гибкости, производительности и надежности, заложенных в архитектуру новой системы: Обеспечить высокую скорость изменения бизнес-процессов и внедрения новых продуктов; Обеспечить требуемый уровень функциональности, доступности, производительности. За счет изменения технологии и процессов разработки: Проводить большую часть изменений конфигурированием, а не разработкой; Обеспечить возможность параллельной разработки разными подрядчиками; Снизить затраты на владение и внедрение нового функционала. Указанная цель достигается за счет решения следующих задач: Разработка более эффективных целевых процессов кредитования физических лиц; Определение методологии разработки / развития новой системы, в т.ч. для обеспечения параллельности разработки разными подрядчиками; Разработка новой системы, апробирование новой системы на пилотных процессах во всех каналах продаж; Подготовка миграции на новую систему (разработка / обновление регламентов, обучение персонала); Последовательная миграция на новую систему, вывод из эксплуатации устаревших систем; Обучение персонала Банка. Реализация указанных задач должна быть направлена на обеспечение повышения эффективности бизнес-процессов кредитования и их ИТ-поддержки в следующих практических областях: Консультации клиентов по кредитным продуктам, первичный подбор продукта; Консультации клиентов по одобренным лимитам / продуктам; Проверка и подтверждение статуса заявителя / его работодателя; Прием анкеты и документов; Обработка анкеты и документов; Планирование коммуникаций с заявителями (в т.ч. через интеграцию с CRM системами Банка); Оперативная и аналитическая отчетность (в т.ч. через интеграцию с BI комплексом Банка); Подтверждение расчетов с партнерами; Продажи дополнительных (некредитных) продуктов. 10 2.2 Текущая ситуация 2.2.1 Описание продуктовой линейки Рамки Программы определяют, в первую очередь, бизнес-процессы продажи кредитных продуктов. Ниже приводится описание текущей продуктовой линейки Банка, бизнес-процессы продажи которых должны реализоваться в новой системе. На текущий момент Банк предлагает следующие кредитные продукты физическим лицам: Кредит наличными (PIL). Нецелевой необеспеченный кредит наличными физическим лицам (выдается на неэмбоссированную / эмбоссированную пластиковую карту, в качестве исключения может выдаваться через кассу без оформления карты); Кредитная карта (CC). Нецелевой необеспеченный револьверный кредит физическим лицам (выдается на эмбоссированную пластиковую карту); Кредиты быстро (Blits). Нецелевой необеспеченный кредит наличными физическим лицам (выдается на неэмбоссированную пластиковую карту, в качестве исключения может выдаваться через кассу без оформления карты). Отличается от PIL коротким сроком принятия решения (несколько минут) и пост-проверкой документов заявителя; Потребительский кредит (IL). Целевой необеспеченный кредит для оплаты товара/услуги (выдается на неэмбоссированную пластиковую карту либо без выдачи карты); Кредит быстро+. Целевой необеспеченный кредит наличными, выдаваемый на карту партнера «Кукуруза»1; Потребительская карта (Потреб.карта). Аналог кредитной карты, но продаваемый в канале POS; Карта с фиксированным платежом (КФП). Целевой / нецелевой необеспеченный револьверный кредит с погашением аннуитетными платежами; Companion Card (CompCard). Комплексные продукт, подразумевающий одновременное оформление Кредита наличными и кредитной карты; Авто-кредитование2. Ипотечное кредитование. У каждого из кредитных продуктов есть ряд разновидностей характеризующихся процентными ставками, сроками, территорией предоставления, категорией клиентов и т.п. Таким образом, перечисленные выше продукты являются, фактически, «типами продуктов», которые для каждого конкретного уникального набора характеристик на уровне АБС Банка превращаются в конкретные продукты (таких продуктов насчитывается несколько тысяч). Каждый из продуктов предлагается Банком в ряде каналов продаж. Каждый из каналов продаж обладает своей спецификой и при продаже однотипных продуктов в различных каналах могут иметься отличия в соответствующих бизнес-процессах. Текущее распределение кредитных продуктов по каналам продаж показано в таблице (распределение продуктов по каналам и состав каналов будет меняться с течением времени): 1 2 http://kykyryza.ru/ Решение о реализации Авто-кредитования и ипотечного кредитования будет принято после реализации 1-й Фазы Программы. 11 Каналы Кредитный Интернет Интернет3 Отделение POS** брокер магазин DSA Телемаркетинг* + + + + + + Продукты PIL + IL + CC + + + + + Потреб.карта Companion Card + + + Кредит быстро+ + Кредиты Быстро + + КФП + Примечание: *Канал телемаркетинга в настоящее время не осуществляет продажи непосредственно. Данный канал осуществляет консультации и планирует передачу клиента для оформления в один из каналов продаж: DSA, либо Отделение. **Канал POS работает в двух вариантах: т.н. «Людная технология» и «Безлюдная технология», первая означает, что продажи осуществляет сотрудник Банка, вторая – наемный агент третьей организации. Бизнес-процессы для этих варрантов имеют отличия. Количественные характеристики описанных каналов продаж представлены в таблице: Каналы Кредитный Интернет Интернет Отделение брокер магазин анкета POS DSA Телемаркетинг*** Кол-во, 2 70 2**** 211* 74000** 400 2 шт. Примечание: *Территориально расположены более чем в 80 городах России (представлены все часовые пояса). **Продажи в этих точках осуществляются более 25000 аккредитованными партнерами Банка. ***Существует как собственный центр обработки вызовов, так и аутсорсинговый партнер. **** К моменту внедрения Пилота будет эксплуатироваться две версии системы «Интернет анкета», с последующие заменой одной на другую. 3 Например, данный сервис https://credits.alfabank.ru/rp/retcredit?app=pil&code=alfasite 12 Перечисленные выше кредитные продукты существуют в двух вариантах (на текущий момент это относиться не ко всем их них): Первичные. Предложение для заявителя формируется без учета имеющихся у него продуктов Банка и/или его поведенческого профиля; Предодобренные (т.н. вторичные). Предложение формируется с учетом имеющихся у клиента продуктов Банка и/или его поведенческого профиля. Бизнес-процессы оформления первичных и вторичных продуктов сильно отличаются. Фактически, продажа вторичного продукта, если он существует для данного заявителя, заключается в уточнении параметров продукта в рамках одобренных лимитов, формировании некоторых документов для подписания и непосредственно открытии договора. Помимо кредитных продуктов в продуктовую линейку Банка входят также некридитные продукты и услуги, предлагаемые вместе с кредитными. К таким продуктам и услугам, на текущий момент, относятся следующие: Страхование4; Защищенная карта5; Пакеты услуг6; Альфа-Хранитель7; Альфа-Талисман8; Защита покупки. Процесс оформления некредитных продуктов также свожится к формированию ряда печатных документов и вызову некоторой внешней системы с передачей ей требуемых данных. Различные комбинации кредитных и некредитных продуктов зависят от множества факторов, в т.ч. типа продуктов, канала продаж, категории клиента и прочих факторов. 2.2.2 Описание автоматизации текущих бизнес-процессов В настоящий момент в Банке для реализации бизнес-процессов кредитования физических лиц для различных продуктов и каналов продаж используются различные взаимодействующие программные комплексы и системы. Основной системой является фронт-система, состоящая из 4-х систем: SLOLP RB (розничное кредитование), SLOLP CF (потребительское кредитование), SLOLP MTG (ипотечное кредитование), SLOLP AUTO (автокредитование). В целом, бизнес-процессы кредитования поддерживают также другие информационные системы (специализированные системы и обеспечивающие системы), полный перечень которых показан в таблице: Область Консультирование заявителей Программное обеспечение Платформа Калькулятор параметров кредита MS Office SLOLP CF BSC Gemini 4 http://www.alfabank.ru/retail/insurance/ http://www.alfabank.ru/retail/insurance/defence/ 6 http://www.alfabank.ru/retail/tariff_plans/ 7 http://www.alfahranitel.ru/ 8 http://www.alfabank.ru/retail/insurance/talisman/ 5 13 Статус Планируется к замене Планируется к замене Область Регистрация кредитной заявки9 Программное обеспечение Платформа Интернет анкета JBoss + Parser3 студии А.Лебедева SLOLP CF, SLOLP RB BSC Gemini ABBYY Form Reader ABBYY ПО партнеров (кредитный брокер) Идентификация заявителя Продажи вторичных кредитных продуктов Скоринг заявки, проверка заявителя Конвейерные проверки заявителя Сканирование документов, обработка сканов, проверка документов Администрирование бумажного документооборота Хранение сканов документов Взаимоотношение с заявителями (по первичным заявкам) Взаимоотношения с партнерами (потребительское кредитование) – Статус Планируется к замене Планируется к замене Выводится из эксплуатации10 – Планируется к замене Планируется развитие Планируется развитие OCRM, GBA планируется развитие TopUp – планируется к замене Планируется развитие Планируется развитие Direct Sales (тонкий клиент) ASP.NET GBA Java Equation (CIF) Mysis Equation OCRM, GBA, TopUp Chordiant, Java, Mysis Equation WSRM (набор вебсервисов) Комплекс платформ CCM Java ABBYY Flexy Capture ABBYY Планируется развитие ПО «Досье», Excel, Access ASP.NET, MS Office Планируется к замене Электронный архив IBM Content Manager Excel MS Office CallCRM Chordiant Комплекс систем IBM LN SLOLP CF, Excel BSC Gemini, MS Office Планируется развитие Планируется к замене Планируется развитие Планируется к замене Планируется к замене Для отдельных продуктов возможен вызов внешних сервисов партнеров Банка. При продаже страховых продуктов возможно обращение к внешним сервисам/системам партнеров. 10 Выводится из эксплуатации к концу 2012 г. – началу 2013 г. в рамках другого проекта (с частичной заменой функционала на ABBYY FC). 9 14 Область Взаимоотношения с партнерами (розничное кредитование и зарплатные проекты) Программное обеспечение Платформа Расчеты с партнерами Mysis Equation + IBM LN БД «Подтверждения дохода» IBM LN БД «Компании БРБ» IBM LN БД «Служебные записки ГБК» Direct Sales (толстый клиент), Excel Работа с з.п. счетами клиентов Администрирование Direct Sales (толстый каналов прямых клиент), Access, Excel продаж Отчетность и анализ DWH, BI IBM LN Delphi, MS Office МСОС + Mysis Equation Статус Планируется развитие Планируется к замене Планируется к замене Планируется к замене Планируется к замене Планируется развитие Delphi, MS Office Планируется к замене Комплекс платформ Планируется развитие Примечание: «Планируется развитие» - может не означать развитие в рамках только данной Программы. «Статус будет определен позже» - статус будет определен после выбора платформы. В любом случае, Заказчик обеспечит координацию всех работ при изменениях в ИТрешениях указанных областей деятельности. 2.3 Структура Программы Структурно Программа состоит из следующих взаимосвязанных проектов: Предпроект (завершен); Пилот (т.н. 1-я Фаза Программы); Проекты миграции (несколько фаз программы). Основными задачами Предпроекта являлись: подготовка к реализации Программы; проведение аналитики по ограниченному числу процессов (пилотных) процессов кредитования, проектирование; подготовка к реализации пилотных процессов кредитования в новом решении; выбор платформы для реализации новой системы. Основными задачами Пилота (1-ой Фазы программы) являются: модернизация окружения (систем обеспечивающих процессы кредитования и/или являющихся поставщиком необходимой информации для кредитных процессов); реализация пилотных процессов в новом решении; миграция справочных данных и классификаторов, включая процессы ETL; тестирование и внедрение нового решения; опытно-промышленная эксплуатация нового решения (параллельно работает новое и старое решение); подготовка к полномасштабной миграции. 15 После получения удовлетворительных результатов в ходе опытно-промышленной эксплуатации пилотной версии новой системы принимается решение о полномасштабной реализации на новой платформе всех бизнес-процессов продажи банковских продуктов кредитования физических лиц (имеется в виду начало разработки и последующее внедрение, аналитика по бизнес-процессам будет разрабатываться параллельно). Процесс миграции будет разбит на ряд фаз, позволяющих более эффективно реализовывать соответствующие группы бизнес-процессов на новом решении. Основными задачами каждого проекта миграции являются (2-я и последующие фазы Программы): планирование миграции, выбор очередных бизнес-процессов для миграции; проведение аналитики по выбранным процессам, проектирование решения; реализация выбранных бизнес-процессов в новом решении; миграция справочных данных и классификаторов, включая процессы ETL; тестирование и внедрение; опытно-промышленная эксплуатация; доработка версии, находящейся в стадии ОПЭ (при необходимости). К концу реализации Программы все устаревшие решения должны быть выведены из эксплуатации. Их функциональность в том или ином виде должна быть реализована в новых системах (платформа и технологии, выбранные для реализации, могут отличаться для различных систем). 2.4 Рамки Программы и проектов (фаз) Программы Рамки Программы определяются ее целями и задачами (см. раздел 2.1), т.е. в стратегическом плане конкретный набор решаемых задач будет корректироваться с учетом текущих потребностей бизнеса Банка для более эффективной реализации указных целей Программы. В рамки Программы входят следующие: Создание системы обработки кредитных заявок, включая весь функционал по администрированию; Создание системы для автоматизации работы кредитных менеджеров в ходе процесса взаимодействия с заявителем; Модернизация специализированных и вспомогательных систем (систем окружения) для обеспечения соответствия их целям и задачам Программы, а также стандартам реализации (см. п. 3.2) и требованиям по производительности (см. п. 3.5). Система для автоматизации работы кредитных менеджеров в ходе процесса взаимодействия с заявителем и система обработки кредитных заявок являются ядровыми системами с т.з. процессов кредитования физических лиц. В рамки их функций входят следующие: Консультирование заявителей; Регистрация кредитной заявки; Идентификация заявителя + фотографирование заявителя (безотносительно конкретных продуктов); Скоринг заявки, проверка заявителя (только на уровне интеграции с существующими сервисами скоринга, безотносительно конкретных продуктов); Взаимоотношение с заявителями; Продажи предодобренных (вторичных) кредитных продуктов (на уровне интеграции с существующими сервисами, безотносительно конкретных продуктов); Продажи некредитных продуктов совместно с кредитными продуктами; 16 Оперативная отчетность и мониторинг. Создание системы обработки кредитных заявок обеспечивает взаимодействие со всеми системами окружения в ходе реализации бизнес-процесса кредитования. В функции данной системы также входит прием и обработка заявок на кредиты, созданные в третьих внешних системах (например, в системах партнеров (т.н. кредитный брокер) и интернет анкетах). Модернизация специализированных и вспомогательных систем производится, как правило, без использования целевой платформы (Pega PRPC), но подразумевают возможность ее использования. Конкретные решения по модернизации таких систем и участие поставщика в работках по модернизации будут оговорены с выбранным поставщиком. В функции таких систем входят: Конвейерные проверки заявителя; Сканирование документов, обработка сканов, проверка документов (на уровне интеграции с существующими сервисами, безотносительно конкретных продуктов); Администрирование бумажного документооборота (безотносительно конкретных продуктов); Хранение сканов документов (на уровне интеграции с существующими сервисами, безотносительно конкретных продуктов); Управление партнерами по потребительскому кредитованию; Управление партнерами по розничному кредитованию и зарплатным проектам; Аналитическая отчетность и анализ; Уведомление заявителя о статусе его заявок через колл-центр. С т.з. реализации бизнес-процессов кредитования в новой системе подразумевается, что необходимый объем функционала в системах окружения будет реализован к моменту необходимому для старта этого процесса. Как указывалось выше Программа включает в себя несколько фаз, с явно выделенной 1-й пилотной фазой, по результатам которой будет приниматься решение о необходимости дальнейших инвестиций в Программу. Предварительно в Программе выделено 3 фазы активной миграции на новую платформу. Миграция должна проводиться «по-продуктам». Распределение продуктов, бизнес-процессы продажи которых будут реализованы на новой платформе, по фазам показаны в таблице: 1-я Фаза (Пилот) Продукт ы и услуги Банка Кредитная карта (CC) Кредиты быстро (Blits) Предодобренные кредитные карты Все некредитные (продаваемые вместе с кредитными картами и кредитами быстро) 2-я Фаза Кредит наличными (PIL) Companion Card Потребительский кредит (IL) Карта с фиксированным платежом (КФП) Предодобренные кредиты наличными Все некредитные (продаваемые вместе с кредитами наличными, Companion Card, 17 3-я Фаза Все кредитные Все предодобрен ные Все некредитные 1-я Фаза (Пилот) 2-я Фаза 3-я Фаза картами с фиксированным платежом и потребительскими кредитами) Предполагаемые сроки завершения описанных фаз приведены в следующем разделе. 2.5 Сроки Программы и проектов Программы Базовые сроки реализации Программы: начало 2012 года – конец 2014 года. Окончанием реализации Программы считается момент полного прекращения эксплуатации текущих фронт-офисных систем. Примерные сроки реализации фаз программы приведены в таблице: № Окончание Фаза Начало п.п. (не позднее) 1. Предпроект Май 2012 г. Февраль 2013 г. 2. Пилот (1-я Фаза) Март 2013 г. Ноябрь 2013 г. 3. 2-я Фаза Октябрь 2013 г. Август 2014 г. 4. 3-я Фаза Март 2014 г. Конец 2014 г. Примечание: Точные сроки фаз миграции (2-я – 3-я фазы) будут уточняться в ходе реализации Программы. Каждая фаза на верхнем уровне включает в себя ряд работ: Аналитика, Разработка, SIT/LT (Банк), UAT (Банк). Также каждая фаза подразумевает несколько точек внедрения. Аналитика подразумевает формирование бизнес-требований и дизайн системы (в первую очередь интеграция). Разработка включает как непосредственно реализацию требований, так и тестирование на стороне поставщика. SIT/LT (Банк) подразумевает интеграционное тестирование поставленного программного обеспечения, включая нагрузочное тестирование. UAT (Банк) подразумевает приемочное тестирование для определения соответствия бизнес-требованиям непосредственно конечными пользователями. 18 3 БАЗОВЫЕ ТРЕБОВАНИЯ К РЕАЛИЗАЦИИ ПРОГРАММЫ 3.1 Фазы Программы и результаты Как описано в разделе 2.3 Программа включает в себя ряд фаз. На каждой фазе реализации Программы требуется получение конкретного результата, промежуточный результаты могут внедряться по мере готовности в течение каждой фазы. Перечень основных ожидаемых результатов каждой из фаз приведен в таблице: № Фаза Результаты Критерий успеха п.п. 1. Предпроект Утверждены подходы к Выбранные подходы и целевая реализации Программы, платформа соответствуют выбрана целевая бизнес-приоритетам Банка. платформа для реализации бизнеспроцессов. 2. 1-я Фаза (Пилот) Стабильная версия пилота Согласованный план системы, прошедшая тестирования полностью приемочные испытания на выполнен. стороне Банка. Установленные критерии План миграции качества программного утвержден. обеспечения достигнуты. Результаты опытнопромышленной эксплуатации пилота положительны. 3. 2-я Фаза Стабильная версия Согласованный план системы (модулей), тестирования полностью прошедшая приемочные выполнен. испытания на стороне Установленные критерии Банка. качества программного 4. 3-я Фаза обеспечения достигнуты. Результаты опытнопромышленной эксплуатации положительны (деградации показателей производительности при наращивании нагрузки при запуске не выявлено). На рисунке ниже показана типовая структура фазы (задачи могут идти со сдвигами во времени): 19 Фаза 1 Аналитика Разработка Тестирование Задача 1 ОПЭ Rollout Задача ... Аналитика Разработка Задача N Тестирование ОПЭ Rollout 3.2 Стандарты реализации Стандарты реализации направлены на обеспечение соответствия нового решения автоматизации кредитования физических лиц целям Программы и требованиям стандартов Банка. К стандартам реализации нового решения относятся: принципы построения целевых бизнес-процессов; архитектурные принципы Альфа-Банка; стандарты документирования разрабатываемого ПО; стандарты дизайна пользовательских интерфейсов. К принципам построения целевых бизнес-процессов и их реализации в новом решении относятся следующие: Непрерывность цепочки операций (т.е. все операции для одного пользователя происходят в одной системе, вся необходимая информация доступна в одном месте, либо вводится в одном месте); Глобальная актуальность справочной информации (т.е. в каждый момент времени все участники процесса используют единую справочную информацию, актуальность справочной информации поддерживается централизованно); Глобальная актуальность обрабатываемой информации (т.е. каждый объект в системе (Анкета, Договор, Торговая точка, Агент и пр.) в каждый момент времени и для всех участников процесса находится в актуальном состоянии и статусе); Контролируемость и измеримость (т.е. все действия в системе над всеми объектами контролируются, состояние всех обрабатываемых объектов в каждый момент времени доступно и измеримо). К архитектурным принципам Альфа-Банка относятся11: 11 Пояснения по содержанию указанных принципов можно запросить отдельно у соответствующего контактного лица (см. Приложение В). 20 Принципы Архитектуры уровня предприятия: o Ориентироваться на стратегии развития бизнеса; o Проектировать для последующих изменений; o Строить для многократного использования; o Проектировать во взаимодействии и взаимосвязи; o Проектировать для адаптивности и маневренности; o Управлять информацией как всеобщим активом предприятия; o Обеспечивать рост объемов; o Обеспечивать доступность и непрерывность функционирования бизнеса; o Соответствовать стандартам, избегать дублирования; o Централизовать; o Строить для пользы всей организации; o Обеспечивать информационную безопасность; o Инновационность; Принципы Информационной Архитектуры: o Разделять транзакционные и аналитические данные; o Каждой информации – свое место и владельца; o Корректность и актуальность данных; o Консолидировать финансовую информацию; o Унифицировать способы доступа к информации; Принципы Архитектуры Решений: o Избегать «толстых клиентов»; o Информационная среда должна быть гранулированной и слабосвязанной; o Максимально использовать промышленные стандарты, технологии, продукты; Принципы Технической Архитектуры: o Принцип необходимой достаточности-адекватности бизнес-задаче; o Масштабируемость; o Управляемость; o Сохранение инвестиций; o Модульность; o Максимальная используемость. Стандарты документирования разрабатываемого ПО и дизайна пользовательских интерфейсов могут быть предоставлены по запросу. Вопросы контроля реализации указанных стандартов реализации, касающихся деятельности поставщиков, описываются в следующих разделах. Кроме того, в Банке действуют следующие стандарты технической архитектуры, определяющие параметры соответствующих системных и аппаратных компонент любой эксплуатируемой системы. Создаваемая в рамках Программы система является системой класса BC. Для систем данного класса установлены следующие стандарты технической архитектуры: Серверы баз данных: Класс ИТСУБД системы DB2 for i5/OS CO, MC, BC ORACLE 10g ORACLE 11g Аппаратная платформа IBM System i HP Integrity HP Integrity Серверы приложений: 21 Операционная система IBM i5/OS HP-UX 11i HP-UX 11i Категория ПО CO, MC, BC Аппаратная платформа Название ПО IBM WebSphere Application Server Oracle WebLogic Server Портальные серверы: Категория Название ПО ПО IBM WebSphere Portal Server CO, MC, BC Oracle WebLogic Portal Программная платформа HP Integrity HP-UX 11i HP Integrity HP-UX 11i Аппаратная платформа HP Integrity HP Integrity Программная платформа HP-UX 11i HP-UX 11i Для систем прочих классов (BO, OP) устанавливаются иные стандарты технической архитектуры, которые могут быть предоставлены по запросу. 3.3 Методология реализации Проект внедрения системы класса «business critical» на новой платформе является для Банка высоко рискованным. Для целей контроля рисков как технических, так и проектных при реализации всех фаз Программы будет применяться подход, подразумевающий углубленный контроль и мониторинг хода работ на всех этапах проекта. При этом будет требоваться итеративный подход к разработке для оценки корректности концепций и верификации бизнес-требований, т.е. формирование нескольких поставок, реализующих отдельные группы функций, до момента получения готового продукта, когда Банк сможет провести собственное интеграционное тестирование системы. Конкретные процедуры и формат мероприятий по контролю и мониторингу будет определен при заключении договора. В целом процессы создания новой системы должен содержать следующие группы процессов: аналитика (разработка бизнес-требований и дизайна системы/модулей системы, с учетом характеристик конкретной платформы). Данный этап требует работ как специалистов Банка, так и специалистов поставщика (возможно с привлечением вендора платформы); разработка (реализация требований путем кодирования и/или настройки). Данный процесс реализуется поставщиком; тестовая аналитика (разработка на основе согласованных требований тестплана, включая набор тест-кейсов); тестирование на стороне подрядчика (включает в себя весь комплекс тестовых испытаний необходимый для достижения требуемого качества). SIT/LT на стороне Банка (включает обязательно нагрузочное тестирование для контроля соответствия нефункциональным требованиям); UAT на стороне Банка; управление конфигурациями. Группа процессов, обеспечивающая контроль версий всех артефактов проекта, процессы данной группы находятся и в ведении Банка и ведении подрядчика; управление качеством. Группа процессов, обеспечивающая контроль качества создаваемой системы, процессы данной группы находятся и в ведении Банка и ведении подрядчика. В целях увеличения тестового покрытия и сокращения сроков тестирования должны широко применяться средства автоматизированного тестирования. Их спецификация и 22 способы применения также будут определены после выбора платформы с учетом требований корпоративных стандартов Банка и практик поставщика. Важной составляющей процесса контроля качества реализации Программы в части использования новой платформы будет являться привлечение отдельной организации для реализации этих задач (далее – услуги QA). Потенциальный поставщик услуг по реализации нового решения на целевой платформе (Pega PRPC) будет обязан взаимодействовать с поставщиком услуг QA для обеспечения снижения рисков и достижения должного уровня качества поставляемых решений. В состав задач поставщика услуг QA будут входить: Архитектурный надзор; Технический надзор; Контроль качества поставок (соответствия функциональным и нефункциональным требованиям). Потенциальный поставщик должен будет направлять (точный механизм реализации будет оговорен с выбранным поставщиком) данной организации соответствующие технические документы для верификации. По завершению верификации Банк принимает решение о начале реализации, либо о доработке технических спецификаций. Описанный контроль качества будет закреплен в отдельном договоре со всеми заинтересованными сторонами. 3.4 Требования к проектной отчетности В ходе реализации фаз Программы Банк вправе контролировать статус всех работ и требовать соответствующие отчеты от Исполнителей (поставщиков услуг по разработке). Список таких документов включает: Отчет о текущем статусе проекта (за период); Отчет о достигнутых результатах и проблемах (за период) Отчет о статусе изменений (за период); Тестовый план (внутреннее тестирование поставки); Отчет о тестировании (поставки), включая оценку по метрикам качества. Конкретный формат отчетов и частота их предоставления устанавливаются при заключении договора и закрепляются в методологии реализации работ (одно из приложений к договору). 3.5 Требования к производительности Ниже приводятся минимальные требования к производительности. Подразумевается, что «узким местом» не являются внешние сервисы, вызываемые системой. Пилотная версия системы (допустимо в рамках опытно-промышленной эксплуатации пилотной версии): Одновременно работающих Операций в часы пиковой Наименование операции пользователей* нагрузки, шт./час Консультации заявителей, 7000 12000 идентификация заявителей Ввод новой кредитной 6000 7000 заявки** Регистрация партнеров 5 20 (розничный бизнес)*** Регистрация партнеров 10 40 23 Наименование операции (потребительский бизнес)*** Регистрация статуса бумажных документов заявки*** Одновременно работающих пользователей* Операций в часы пиковой нагрузки, шт./час 60 200 Промышленная версия системы (требуется после завершения опытнопромышленной эксплуатации): Одновременно работающих Операций в часы пиковой Наименование операции пользователей* нагрузки, шт./час Консультации заявителей, 12000 30000 идентификация заявителей Ввод новой кредитной 10000 15000 заявки** Регистрация партнеров 5 50 (розничный бизнес)*** Регистрация партнеров (потребительский 15 80 бизнес)*** Регистрация статуса бумажных документов 100 400 заявки*** * Под пользователем подразумевается как человек, работающий через графический интерфейс, так и внешняя система (партнера Банка) через соответствующий сервис системы. ** Суммарно из всех каналов продаж. *** Подразумевается также изменение параметров уже зарегистрированных партнеров, документов. В соответствующем разделе коммерческого предложения (см. раздел 4.6) Исполнители приводят описание спецификации рекомендуемого оборудования для обеспечения указанной производительности. Следует учитывать, что в соответствии с технической политикой Банка все системы класса «business critical» должны иметь 20% запас производительности относительно указанного. Ввод кредитных заявок осуществляется в режиме 24 * 7 с учетом работы во всех регионах России. Время простоя информационных систем, связанных с процессом обработки кредитных заявок, не более 3 часов (с 23:00 вечера до 2:00 ночи по московскому времени). Количество заводимых новых кредитных заявок по всем приведенным в настоящем запросе продуктам в год порядка 11,5 млн. (план до 2014 года). Примерный суммарный размер всех поле одной кредитной заявки составляет 13 килобайт с использованием Unicode (UTF-16) для текстовых полей (не включает оцифрованные образы документов). Оцифрованные образы документов не предполагается обрабатывать непосредственно в разрабатываемой системе (за исключением хранения ссылок на них в существующей системе «Электронный архив» (IBM Content Manager). Также предполагается ограничить временной период хранения заведенных кредитных заявок в разрабатываемой системе с выгрузкой этих данных в DWH (например, текущая система хранить последние введенные заявки за 3 месяца). 24 3.6 Требования к документации и документированию Для обеспечения должного уровня отчуждаемости все поставляемые решения должны сопровождаться документацией. При этом, если поставляется исходный код, то он должен содержать комментарии, позволяющие определить заложенную в нем логику. К основным документам, сопровождающим поставку программного обеспечения и/или отдельных модулей, относятся следующие: Описание поставляемого решения, включая (если применимо): описание структуры базы данных, описание модулей системы и их спецификации; Диаграмма развертывания; Руководство по инсталляции/деинсталляции системы/модулей; Руководство по предоставлению (лишению) и разграничению прав доступа (если применимо); Требования к аппаратному и системному программному обеспечению; План восстановления после аварии (DRP); Описание регламентных процедур; Описание механизмов архивации данных; Описание BackUp/Recovery процедуры; Описание средств мониторинга системы, сопряжения со средствами мониторинга; Список известных дефектов, включая описание временных решений проблем; Порядок установки обновлений; Конкретный формат и подробное содержание указных документов будут предоставлены разработчику после выбора платформы. 3.7 Требования к обучению Поставщик должен предоставлять сервисы по обучению персонала Банка по следующим направлениям: дополнительное обучение платформе (без сертификации); обучение поставляемым разработкам; обучение конечных пользователей (может быть выполнено в форме подготовки интерактивных курсов, обучения тренеров Банка для дальнейшего обучения ими сотрудников и т.д.). Обучение должно проводиться специалистами поставщика, имеющими соответствующие сертификаты вендора платформы на право обучения. Для обучения должны предоставляться учебные материалы на русском языке. В обязательном порядке должен быть обучен следующий персонал Банка: аналитики; разработчики; инженеры сопровождения. График обучения и число обучаемых от Банка будет определен в ходе реализации Программы. 25 4 ТРЕБОВАНИЯ К КОММЕРЧЕСКОМУ ПРЕДЛОЖЕНИЮ 4.1 Формат коммерческого предложения К подаваемому коммерческому предложению предъявляются следующие общие требования: предложение подается в формате официальных документов организации потенциального поставщика, получившего данный запрос; предложение принимается только от организации получившей настоящий запрос; коммерческое предложение должно быть подписано руководителем организации, имеющим право подписания договорных документов. 4.2 Содержание коммерческого предложения Коммерческое должно включать минимум следующие разделы: общее описание предложения; профиль поставщика; описание предлагаемого решения; уровень сервиса; предлагаемые сроки реализации; оценка стоимости; замечания и предложения. Требования к содержанию перечисленных обязательных разделов коммерческого предложения описаны ниже. 4.3 Общее описание предложения Общее описание предложение должно включать: общее описание предлагаемого подхода к реализации задач Программы; общее описание предлагаемых к использованию для построения новой системы платформ/ИТ-решений и их основных возможностей и функций. Цель данного раздела дать общее представление потребителям результатов данной Программы (бизнес-пользователям) о предлагаемом решении. 4.4 Профиль поставщика услуг по разработке В данном разделе должен быть описан профиль поставщика. В ответе на данное коммерческое предложение необходимо привести следующий минимальный набор сведений: официальное наименование, бренд; общее описание организации, сферы деятельности; страны присутствия; успешные проекты/области деятельности релевантные предметной области данного запроса; наличие официального представительства в России, адрес представительства, контактные данные; контактные данные ответственных за коммерческое предложение лиц; наличие проектных менеджеров в российском представительстве; 26 наличие аналитиков/консультантов в российском представительстве; наличие группы поддержки в российском представительстве; наличие представительств в других странах СНГ (прежде всего Украина, Белоруссия, Казахстан). 4.5 Описание предлагаемого решения В данном разделе дается подробное описание предлагаемого решения. Данное описание должно, как минимум, включать следующее: описание платформы, назначения и функций платформы; опыт промышленной эксплуатации платформы (предлагаемой версии), известные крупные внедрения; ограничения платформы (явные и неявные) в контексте использования для создания рассматриваемой фронт-офисной системы; предлагаемая концептуальная архитектура решения; предлагается состав системного программного обеспечения, необходимого для функционирования платформы (в т.ч. наличие поддержки WAS/HP-UX, JBoss/Suse Linux, WebLogic/HP-UX), а также состав и характеристики систем хранения данных/базы данных (в т.ч. поддержки Oracle/HP-UX, DB2/AS-400); состав модулей системы с указанием их назначения и требований по использованию при создании новой системы (обязательно/опционально); описание способов интеграции с DWH и BI-системами, в т.ч. ограничений. общее описание процесса разработки на предлагаемой платформе; общее описание процесса автоматизированного тестирования решений созданных на базе предлагаемой платформы; описание процесса переноса изменений из тестового окружения в промышленное; описание предложений по методологии реализации проекта создания новой системы с использованием предлагаемой платформы. Отдельно приводится таблица с ответами на вопросы по оценке соответствия характеристик платформы (см. ПРИЛОЖЕНИЕ A), при необходимости даются комментарии. При заполнении ПРИЛОЖЕНИЕ A следует учесть, что при указании опций «Интеграция со сторонней технологией», либо «Через доработку платформы» следует привести стоимостные оценки в соответствующем разделе коммерческого предложения. 4.6 Описание требований к оборудованию В данном разделе потенциальный поставщик описывает рекомендуемую конфигурацию оборудования, которая позволит обеспечить требования по производительности. Описание должно позволять однозначно идентифицировать оборудование. Должна быть приведена следующая информация. Требования к серверному оборудованию, включая: o Наименование; o Рекомендуемая конфигурация; Требования к сетевому оборудованию, включая: o Наименование; o Рекомендуемая конфигурация. 27 Следует ориентироваться на стандарты технической архитектуры Банка, приведенные в разделе 3.2 данного запроса. При невозможности удовлетворить этим стандартам (например, по требованиям производительности) следует указать это. 4.7 Уровень сервиса В данном разделе описывается уровень предоставляемого сервиса на период реализации Программы. Приводится следующая информация. В ходе проектирования/разработки: Выделенный менеджер (да/нет); Выделенный архитектор/консультант; Достаточность ресурсов (аналитики, консультанты, разработчики); Возможность создавать макеты решений для подтверждения успешности концепции; Возможности по изменению требований. В ходе тестирования: Выделенный тест-менеджер (да/нет); Своя команда тестировщиков. В ходе внедрения и опытно-промышленной эксплуатации: Выделенный специалист на период внедрения и ОПЭ; Оперативность исправления дефектов. В ходе эксплуатации: Опции сервиса поддержки (приводится описание, доступные опции, наличие опции поддержки 24*7 и т.п.); Описание SLA. 4.8 Предлагаемые сроки реализации В данном разделе необходимо привести информацию по предлагаемым срокам реализации всех фаз Программы и соответствию этих предложений срокам, описанным в разделе 2.5 настоящего запроса. 4.9 Оценка стоимости Оценка стоимости предложения производится в соответствии с требованиями изложенными в Приложении № 3 к конкурсной документации. 4.10 Замечание и предложения В данном разделе приводятся замечания и предложения по описанному в данном запросе подходу к реализации Программы (в свободном формате), а также отдельно следующее: Замечания по срокам реализации фаз Программы Текст замечаний (см. раздел 2.5) Замечания по требованиям к производительности (см. Текст замечаний раздел 3.5) Замечания по оценке Текст замечаний 28 соответствия характеристик платформы (см. ПРИЛОЖЕНИЕ A) Замечания по шаблону пакета договорных документов и Текст замечаний условиям договора (см. ПРИЛОЖЕНИЕ Б) В случае отсутствия замечаний/особого мнения необходимо заполнить в вышеприведенной таблице соответствующую строку записью «Замечаний нет». 29 5 ПРИЛОЖЕНИЕ A Оценка соответствия характеристик платформы. В таблице ниже необходимо дать оценку соответствия перечисленных характеристик предлагаемому решению. При ответе на вопрос об оценке соответствия следует руководствоваться следующим: Да – означает, что предлагаемая платформа полностью отвечает требованию/характеристике; Нет – означает, что предлагаемая платформа в принципе не поддерживает такое требование/не обладает характеристикой, либо требование /характеристика не релевантна предлагаемому решению (в таких случаях рекомендуется давать соответствующий комментарий); Интеграция со сторонней технологией – означает, что предлагаемая платформа в принципе не поддерживает такое требование/не обладает характеристикой, но позволяет легко получить требуемую функциональность за счет использования/интеграции со сторонней технологией; Через доработку платформы – означает, что требование/характеристик может быть получена путем доработки стандартной версии платформы штатными средствами. В поле «Комментарий», при необходимости, можно давать пояснения к ответам, в том числе о релевантности конкретной характеристики, предлагаемой платформе. Последние три варианта ответов не являются взаимоисключающими, выбор ответа и комментарии к нему целиком в области ответственности поставщика. Категория Характеристика Бизнеспроцессы Поддержка версионности процессов Бизнеспроцессы Авторизация через LDAP Бизнеспроцессы Авторизация собственными механизмами Расшифровка требования Заявка, созданная по одной версии процесса после инсталляции следующей версии должна все-равно идти по старой версии. Т.е. система позволяет авторизовать пользователя через механизм LDAP и не хранить информацию о нем. Т.е. система позволяет создавать собственный список пользователей и назначения им прав/ролей. 30 Оценка возможности Да; Нет; Интеграция со сторонней технологией; Через доработку платформы. Да; Нет; Интеграция со сторонней технологией; Через доработку платформы. Да; Нет; Интеграция со сторонней технологией; Через доработку платформы. Коммента рий Категория Характеристика Бизнеспроцессы Авторизация LDAP + собственные механизмы Бизнеспроцессы Поддержка ролевой модели доступа Бизнеспроцессы Поддержка ролевого управления функциями Бизнеспроцессы Поддержка ролевого управления данными Бизнеспроцессы Возможность создавать произвольные справочники и классификаторы (плоские) Возможность создавать произвольные справочники и классификаторы (иерархические) Бизнеспроцессы Расшифровка требования Возможность для части пользователей выполнять авторизацию через LDAP, для другой части собственными механизмами. При этом список пользователей для собственного механизма хранится непосредственно в системе. Как минимум ролевая модель должна обеспечивать: - возможность создавать иерархию ролей; - возможность назначать роли группе пользователей в иерархии; - возможность создавать иерархию пользователей (функциональное подчинение) и назначать им роли. Т.е. в рамках ролевой модели должно обеспечиваться управление правами каждой роли на выполняемые ей функции в системе (фактически доступность тех или иных функций). Т.е. в рамках ролевой модели должно обеспечиваться управление правами каждой роли на доступные ей данные в системе (т.е. задаваться CRUD). Справочники и классификаторы, которые имеют один уровень Справочники и классификаторы, которые имеют произвольное количество уровней. Например, возможность создавать иерархию департаментов, управлений, 31 Оценка возможности Да; Нет; Интеграция со сторонней технологией; Через доработку платформы. Да; Нет; Интеграция со сторонней технологией; Через доработку платформы. Да; Нет; Интеграция со сторонней технологией; Через доработку платформы. Да; Нет; Интеграция со сторонней технологией; Через доработку платформы. Да; Нет; Через доработку платформы. Да; Нет; Через доработку платформы. Коммента рий Категория Характеристика Бизнеспроцессы Возможность создавать произвольные связи между отдельными справочниками и классификаторами Бизнеспроцессы Возможность прозрачно работать с данными справочников и классификаторов, хранимых непосредственно в системе, так и в других внешних системах. Настройка видимости содержимого справочников и классификаторов для разных признаков Возможность настройки CRUD для каждого поля формы (статическая) Возможность настройки CRUD для каждого поля формы (динамическая) Бизнеспроцессы Разработка Разработка Разработка Возможность задавать Расшифровка требования отделов, групп и т.п. с привязкой пользователей к узлам этой иерархии. Т.е. для любых справочников (плоских и/или иерархических) можно указать связи между их элементами (минимум типа: "один-к-одному, "многие-к-одному"). Например, настройка географической иерархии отделений и точек продаж, а также объединение точек в торговые сети с последующей привязкой банковских продуктов к любому узлу этой иерархии. Т.е. часть справочников и классификаторов храниться в своих мастер-системах, путем интеграции с этим системами извлекаются эти данные и согласно заданной модели данных произвольно объединяются с целью отображения в пользовательский интерфейс. Например, каждый пользователь с определенной ролью видит только часть определнного справочника. Т.е. Значение статуса CRUD (Create, Read, Delete, Update) для поля предопределено зарание и не меняется. Например, если объект падает в определнный статус, то срабатывают преднастроенные правила, определяющие CRUD-статус каждого из его полей. Т.е. валидатор срабатывает сразу после 32 Оценка возможности Да; Нет; Через доработку платформы. Да; Нет; Через доработку платформы. Да; Нет; Через доработку платформы. Да; Нет; Через доработку платформы. Да; Нет; Через доработку платформы. Да; Коммента рий Категория Характеристика Расшифровка требования валидаторы для полей формы (оперативная проверка) Разработка Разработка Бизнеспроцессы Бизнеспроцессы Разработка Разработка ввода некорректной информации в какоелибо поле с выводом соответствующих сообщений об ошибке. Возможность задавать Т.е. валидатор срабатывает после валидаторы для полей формы заполнения всех полей (часть которых (пост проверка) содержит некорректные данные) и попытки перейти по процессу дальше с выводом соответствующих сообщений об ошибке. Изменение интерфейса с Возможность настройкой (без внешней системой настройкой программирования) изменить интерфейс с внешней системой (например, добавить какое-либо поле) Возможность создавать Для отдельных ролей должна индивидуальные формы отображаться специальная форма пользовательского отличная от формы по умолчанию. Речь интерфейса для отдельных идет о создании множественного ролей пользователей представления для одних и тех же данных. Возможность настраивать Т.е. возможность без программирования бизнес-процесс настраивать бизнес-процесс, его шаги и связи между ними. Оценка возможности Нет; Интеграция со сторонней технологией; Через доработку платформы. Да; Нет; Интеграция со сторонней технологией; Через доработку платформы. Да; Нет; Через доработку платформы. Да; Нет; Интеграция со сторонней технологией; Через доработку платформы. Да; Нет; Интеграция со сторонней технологией; Через доработку платформы. Возможность отправки E-mail с Генерируемый контент должен минимум Да; программно генерируемым включать: Нет; контентом - простой текст; Интеграция со сторонней технологией; - файлы в качестве вложений. Через доработку платформы. Кросс-браузорность Контент генерируемых страниц содержит Да; только HTML и JavaScript. Одинаковость Нет; отображения во всех браузерах не имеется Интеграция со сторонней технологией; в виду. Через доработку платформы. 33 Коммента рий Категория Характеристика Расшифровка требования Печатные формы Генерация печатных форм в формате Adobe PDF на основе шаблонов Печатные формы Генерация печатных форм в формате MS Word (doc/docx) на основе шаблонов Печатные формы Генерация печатных форм в формате MS Excel (xls/xlsx) на основе шаблонов Печатные формы Возможность встраивания штрих-кодов в печатные формы. Печатные формы Версионность шаблонов печатных форм Печатные формы Поддержка расчетных полей при генерации печатных форм Печатные формы Передача сгенерированных печатных форм во внешние Генерация печатных форм в формате Adobe PDF на основе шаблонов, корректировка которых доступна пользователям и производится без программирования Генерация печатных форм в формате MS Word (doc/docx) на основе шаблонов, корректировка которых доступна пользователям и производится без программирования Генерация печатных форм в формате MS Excel (xls/xlsx) на основе шаблонов, корректировка которых доступна пользователям и производится без программирования Т.е. возможность динамической генерации штрих-кодов и их встраивание в печатную форму в место, определенное шаблоном печатной формы. Поддержка версионности шаблонов печатных форм с тем, чтобы обеспечить генерацию печатной формы документ того вида, который действовал на момент ее актуальности. Например, расчет и печать значений полной стоимости кредита при генерации печатной формы без необходимости хранить это значение в БД и т.п. Возможность генерировать и передавать печатные формы во внешние системы (ПО 34 Оценка возможности Да; Нет; Интеграция со сторонней технологией; Через доработку платформы. Да; Нет; Интеграция со сторонней технологией; Через доработку платформы. Да; Нет; Интеграция со сторонней технологией; Через доработку платформы. Да; Нет; Интеграция со сторонней технологией; Через доработку платформы. Да; Нет; Интеграция со сторонней технологией; Через доработку платформы. Да; Нет; Интеграция со сторонней технологией; Через доработку платформы. Да; Нет; Коммента рий Категория Характеристика системы Печатные формы Получение файлов из внешних систем Печатные формы Настройка генерации различных печатных форм на основе определенной группы шаблонов в зависимости от значений некоторых вычисляемых признаков Открытый код платформы Разработка Разработка Разработка Расшифровка требования партнеров Банка) через веб-сервисы в формате Base64binary. Возможность получения из внешних систем файлов, привязка этих фалов к каким-либо объектам (например, кредитной заявке), с возможностью последующего просмотра этих файлов через пользовательский интерфейс. Например, по продуктам, продающимся у разных партнеров, должна быть возможность печати различных документов. Т.е. нужна привязка печатных форм к конкретному продукту (и/или торговой точке). Возможность просматривать исходный код платформы. Возможность параллельной разработки (в том числе несколькими разными командами одновременно) Поддержка системы управления версиями Сопровожде Поддержка кластеризации ние Возможность работы в кластере (вертикальном\горизонтальном) Сопровожде Поддержка горизонтальной ние масштабируемости Поддержка возможности разносить отдельные функции/модули платформы по различным серверам с целью управления производительностью без 35 Оценка возможности Интеграция со сторонней технологией; Через доработку платформы. Да; Нет; Интеграция со сторонней технологией; Через доработку платформы. Да; Нет; Интеграция со сторонней технологией; Через доработку платформы. Да; Нет. Да; Нет. Да; Нет; Интеграция со сторонней технологией. Да; Нет; Через доработку платформы. Да; Нет. Коммента рий Категория Характеристика Разработка Возможность копирования установленного экземпляра системы (инстанса) Разработка Поддержка деперсонификации Разработка Гибкость разработки пользовательского интерфейса Разработка Кастомизация пользовательского интерфейса Бизнеспроцессы Расширяемость пользовательского интерфейса Разработка Поддержка обновлений через установку пакетов (патчей) Расшифровка требования какой-либо модификации платформы и/или приложения построенного на ее основе. Возможность создания неограниченного числа тестовых/девелоперских сред путем простого копирования БД системы, файлов конфигурации и пр. с одного сервера на другой. Возможность деперсонификации или очистки бизнес-данных без потери целостности данных или работоспособности системы. Наличие специальных инструментов поддержки разработки пользовательского интерфейса. Возможность произвольно кастомизировать пользовательский интерфейс, задавать визуальное представление элементам управления и страницы в целом. Возможность использовать визуальные компоненты собственной разработки. Т.е. результат проведения любого вида доработки должен иметь вид патча, который можно распространять на все приложения (промышленные и тестовые) и доработки системы не должны 36 Оценка возможности Да; Нет. Да; Нет; Интеграция со сторонней технологией; Через доработку платформы. Да; Нет; Интеграция со сторонней технологией; Через доработку платформы. Да; Нет; Интеграция со сторонней технологией; Через доработку платформы. Да; Нет; Интеграция со сторонней технологией; Через доработку платформы. Да; Нет. Коммента рий Категория Характеристика Тестировани Модульность приложения е Тестировани Возможность автоматизации е функционального тестирования Тестировани Возможность проведения е нагрузочного тестирования Тестировани Возможность проведения е пользовательского тестирования Тестировани Возможность настройки е уровня логирования Внедрение Возможность установки типовых изменений без рестарта приложения Сопровожде Прозрачная поддержка ние установки новых версий системного программного обеспечения Сопровожде Возможность наложения ние timeout на какой-либо обрабатываемый объект или Расшифровка требования принимать вид действия администраторов на низком уровне - например, "зайти в БД, в такой-то таблице изменить такое-то значение)". Внесение изменений в одном модуле не должны приводить к необходимости проведения полного регрессионного тестирования приложения Такими средствами, как HP QTP/Selenium Оценка возможности Да; Нет. Да; Нет. Такими средствами, как HP LoadRunner и др. Такими средствами, как HP QTP/Selenium Да; Нет. Да; Нет. Например, для тестирования и анализа дефектов может понадобиться более высокий уровень логирования (debug), чем для промышленной среды Например, изменение шаблонов печатных форм, изменения в справочной информации и т.п. Переход на новую версию системного ПО должен быть простым и не приводить к большим затратам на разработку и тестирование Т.е. каждый этап обработки должен иметь определенное ограничение по времени его реализации В случае его превышения Да; Нет; Интеграция со сторонней технологией; Через доработку платформы. Да; Нет. 37 Да; Нет. Да; Нет; Интеграция со сторонней технологией; Коммента рий Категория Характеристика процесс обработки Сопровожде Возможность рестарта ние процесса обработки какоголибо объекта по процессу с любого из пройденных этапов Сопровожде Возможность массового ние рестарта процесса обработки какого-либо объекта Сопровожде Мониторинг работы системы ние Сопровожде Возможность построения Расшифровка требования система сигнализирует о превышении timeout для обрабатываемого объекта. Типовой пример: 1. Кредитная заявка ушла в ошибку на этапе Б 2. В ходе разбора выяснилось, что причина ошибки - получены некорректные данные из внешней системы на этапе А 3. Производится рестарт бизнес-процесса по заявке с этапа А 4. Заявка заново проходит этап А, получает на нем корректные данные 5. Уже с корректными данными заявка идет дальше и успешно проходит этап Б Типовой пример: 1. Произошел сбой в работе какой-либо внешней системы 2. В результате сбоя большое количество кредитных заявок упало в ошибку на этапе вызова этой системы 3. После восстановления работы внешней системы все ошибочные заявки массово перезапускаются и корректно проходят нужный этап Возможность мониторинга ключевых показателей - загруженности серверов, массовых ошибок и зависания заявок на различных этапах, активности пользователей и т.д. Например, либо прямыми запросами к БД, 38 Оценка возможности Через доработку платформы. Да; Нет; Через доработку платформы. Да; Нет; Через доработку платформы. Да; Нет; Интеграция со сторонней технологией; Через доработку платформы. Да; Коммента рий Категория ние Характеристика оперативной отчетности по БД Сопровожде Поддержка режим работы ние системы 24 на 7 Сопровожде Мониторинг исполнения ние бизнес-процессов Сопровожде Интеграция с внешними ние системами мониторинга Автоматическое Сопровожде информирование о сбоях и ние логирование Сопровожде Управление доступом Расшифровка требования либо выгрузка данных средствами ETL в специальную базу Т.е. обеспечивает ли система режим непрерывной круглосуточной работы без ежедневных обязательных остановок на технологические работы. Мониторинг ключевых точек бизнеспроцесса обработки по системным параметрам: время, значение. Т.е. система должна уметь сообщать о своем состоянии внешним системам мониторинга, используемым в банке (HP OpenView), по стандартным протоколам, (например SNMP) Т.е. в случае возникновения сбоя система должна: - идентифицировать сбойный компонент, выделить его в административном интерфейсе, вывести сообщение об ошибке с рекомендациями по исправлению; - зафиксировать ошибку в логах; - отправить оповещение администратору посредством отсылки сообщения в центральную банковскую систему мониторинга HP OpenView (допустимо использования дополнительной рассылки сообщений посредством sms, e-mai) Т.е. возможность включения в on-line 39 Оценка возможности Нет; Интеграция со сторонней технологией; Через доработку платформы. Да; Нет. Да; Нет; Через доработку платформы. Да; Нет; Через доработку платформы. Да; Нет; Через доработку платформы. Да; Коммента рий Категория ние Характеристика пользователей к системе Оперативное Сопровожде информирование ние пользователей о статусе системы Сопровожде Сервисы справки и подсказок ние Стабильность системы при Сопровожде недоступности внешних ние интерфейсов (глобальная) Расшифровка требования режиме ограничения на количества входов пользователей при работающей системе. Например, если в системе уже авторизовано 10 пользователей и стоит ограничение на 10 входов, то 11-й пользователь уже не сможет войти в систему. При этом предоставляется возможность проверки, что новому пользователю доступна квота на вход, а также возможно удаление сессии пользователя администратором. Т.е. возможность показа «бегущей строки»/информационных баннеров пользователям, а также возможность изменения этих баннеров, текстов ошибок/сообщений и прочих подобных настроек без остановки системы. Предоставление справочных материалов пользователям (подсказки в интерфейсе, ссылки на руководства и пр.). Причем для изменения контента таких справочных материалов не должна производиться остановка сервера. Т.е. система должна сохранять работоспособность (естественно, с утратой возможности выполнять штатные функции), при недоступности внешних интерфейсов, включая СУБД (любой JDBC datasource), включая MQ, при этом, 40 Оценка возможности Нет; Через доработку платформы. Да; Нет; Через доработку платформы. Да; Нет; Интеграция со сторонней технологией; Через доработку платформы. Да; Нет; Через доработку платформы. Коммента рий Категория Характеристика Стабильность системы при Сопровожде недоступности внешних ние интерфейсов (локальная) Сопровожде Раздельное логирование ние Сопровожде Минимальный состав Расшифровка требования возможность выполнять штатные функции немедленно восстанавливается при возобновлении доступности внешних интерфейсов. Т.е. недоступность отдельного интерфейса может приводить к недоступности части функционала, но не должна влиять на стабильность и доступность системы в целом. Когда процесс обработки объекта (напримре, кредитной заявки) доходит до этапа где необходим вызов внешнего сервиса, который недоступен, процесс обработки всех таких объектов останавливается в данной точке, другие объекты не имеющие такого этапа обрабатываются штатным образом. Т.е. поддержка различных дополняющих друг друга способов логирования:штатное системное логирование (например, systemout.log);- логирование в таблицу (с web-инструментом просмотра) интерфейсов общения с внешними системами (in, out, логика обработки для случаев ok/error); - логирование в таблицу функциональных операций в системе. В таблице Должна быть предусмотрена логическая связь (по id) с сообщениями в системном логе sysytemout;- таблица логирования должна партиционироваться. Т.е. уровень логирования должен быть 41 Оценка возможности Да; Нет; Через доработку платформы. Да; Нет; Интеграция со сторонней технологией; Через доработку платформы. Да; Коммента рий Категория ние Характеристика системных логов Сопровожде Производительность системы ние при логировании Сопровожде Логирование действий ние пользователей Сопровожде Минимальный состав логов ние действий пользователей Сопровожде Оперативная настройка ние уровня логирования Сопровожде Гибкая работа с логами ние Расшифровка требования достаточен для однозначного определения неисправного компонента системы и причины ошибки. Минимум включает: время, host_узла_кластера, application_server, id_шага-бизнеспроцесса, id_заявки, полный URL вызываемого внешнего интерфейса. Т.е. требуемый уровень штатного логирования не должен приводить к ухудшению производительности системы и/или требовать увеличения системных ресурсов оборудования. Т.е. поддержка журналирования операции пользователей (клиентов и сотрудников банка) в таблицах базы данных системы. Перечень журналируемых операций должен настраиваться администратором. Записи о действиях пользователей должны содержать дату, время с точностью до миллисекунд, IP-адрес компьютера, с которого выполнялась операция. Т.е. изменение уровня логирования в режиме on-line, возможность on-line переконфигурирования настроек путей для сохранения файлов логов. Т.е. возможность: - настройки разделения логирования по: login, host, (т.е. в зависимости от группы выбранных параметров формировать 42 Оценка возможности Нет; Через доработку платформы. Да; Нет; Через доработку платформы. Да; Нет; Через доработку платформы. Да; Нет; Через доработку платформы. Да; Нет; Через доработку платформы. Да; Нет; Через доработку платформы. Коммента рий Категория Характеристика Сопровожде Поддержка интеграции с HP ние Service Manager Сопровожде Модульность системы в части ние BPM Сопровожде Инструмент обработки ние ошибок Сопровожде Уведомление пользователей ние Расшифровка требования соответствующий лог); -наличие интерфейса для просмотра и поиска записей по журналам операций; - отображение информации о действиях в различных разрезах (например, пользователя - все действия конкретного пользователя, как клиента, так и сотрудника банка, клиента - все изменения в настройках клиента в хронологической последовательности). Поддержка интеграции с HP Service Manager 9.30 для ведения карточек обращений клиентов в техподдержку. Например, каждый обработчик, являющийся отдельным этапом бизнеспроцесса, представляет собой отдельное приложение/процесс/поток - со своим логированием, возможностью запуска/остановки, очередями (в т.ч. ошибочными). Т.е. предоставление возможности с помощью одного инструмента выполнить повторную обработку как одиночной, так и массовых ошибок движения заявок по бизнес-процессу. Возможность добавлять бегущую строку (информирование пользователей) через GUI администратора Сопровожде Последовательная архивация ние в два этапа - архив в БД, 43 Оценка возможности Да; Нет; Через доработку платформы. Да; Нет; Через доработку платформы. Да; Нет; Через доработку платформы. Да; Нет; Через доработку платформы. Да; Нет; Интеграция со сторонней технологией; Через доработку Коммента рий Категория Характеристика Расшифровка требования доступный для чтения (для отчетности и т.п.), и off-line архив (файловый) Сопровожде Возможность разнесения ние архива и оперативной базы на разные сервера. Сопровожде Настройка глубины архивации ние для разных заявок (по статусам, типам продуктов и т.п.) Разработка Поддержка взаимодействия с другими системами по протоколу MQ Разработка Наличие механизмов кеширования запросов получения данных. Разработка Поддержка отчуждаемости презентационного слоя системы Разработка Поддержка разделения на отчуждаемые бизнес-модули Оценка возможности платформы. Т.е. Есть штатная возможность получения/передачи данных по протоколу MQ без написания кода Наличие механизмов кеширования на уровне бизнес-сущностей внешних и внутренних запросов получения данных и методов частичной очистки кеша (в том числе вызовом сервиса из сторонних систем) с возможностью настройки без написания программного кода. Возможность независимой разработки презентационного слоя сторонними разработчиками на основе сторонних платформ, посредством вызовов библиотеки бизнес-сервисов, публикуемых системой. Разделение системы на самостоятельные бизнес-модули с возможностью 44 Да; Нет; Интеграция со сторонней технологией; Через доработку платформы. Да; Нет; Интеграция со сторонней технологией; Через доработку платформы. Да; Нет; Интеграция со сторонней технологией; Через доработку платформы. Да; Нет; Через доработку платформы. Да; Нет; Интеграция со сторонней технологией; Через доработку платформы. Да; Нет; Коммента рий Категория Печатные формы Бизнеспроцессы Характеристика Поддержка интеграции с промышленными системами генерации отчетов (Oracle BI Publisher) Отсутствие необходимости установки дополнительного программного обеспечения на рабочие места пользователей системы. Разработка Поддержка интернационализации Разработка Ведение пользователей и справочников из внешних систем Разработка Интеграция с системами Расшифровка требования независимого размещения и горизонтального масштабирования на различных слоях системы(презентационный, бизнес-логика, данные). Т.е. есть возможность вынести отдельные высоконагруженные процессы на выделенные сервера на уровне web, application, db. Возможность подключения к Oracle BI Publisher и гибкой настройки передаваемых на печать данных без программирования. Систем предоставляет web-интерфейс пользователя работающий без установки дополнительного программного обеспечения, т.е. ActiveX, SilverLight, JRE и т.д. за исключением случаев работы с крипто-системами и аппаратными устройствами. Т.е. возможность создавать локализованные интерфейсы и печатные формы, с учетом возможности прозрачного переключения между различными локализациями. Т.е. система должна позволять заводить пользователя (а также часто изменяемые справочники - торговые точки, продукты) посредством веб-сервиса или процедуры, к которым можно обратиться извне Интеграция с системами телефонии Банка 45 Оценка возможности Да; Нет; Да; Нет; Через доработку платформы. Да; Нет; Интеграция со сторонней технологией; Через доработку платформы. Да; Нет; Интеграция со сторонней технологией; Через доработку платформы. Да; Коммента рий Категория Характеристика телефонии Разработка Поддержка синхронного вызова веб-сервисов (SOAP) Разработка Поддержка асинхронного вызова веб-сервисов (SOAP) Разработка Поддержка кэширования вызовов веб-сервисов Разработка Подключение системы к внешним веб-сервисам без доработки этих сервисов и системы Разработка Поддержка публикации вебсервисов (API бизнес-логики) для вызова из внешних систем Разработка Наличие стандартных Расшифровка требования на платформе AVAYA (в.ч. управление распределением вызовов, переадресация вызова и пр.) Т.е. управление вызывающему приложению не возвращается, пока не отработает сервис. Т.е. управление вызывающему приложению возвращается немедленно после вызова сервиса, после получения результат из вызванного сервиса, вызывающее приложение специальным образом уведомляется. Т.е. повторного запроса к удаленному серверу не происходит, вместо этого используются ранее полученные параметры для данного запроса. При этом, подразумевается наличие механизма контроля актуальности кэша. Штатная возможность использования внешних веб-сервисов в рамках разрабатываемых бизнес-процессов посредством настройки без написания программного кода. Штатная возможность публикации вебсервисов (в том числе вызова разрабатываемых банком процессов) посредством настройки без написания программного кода. Система штатным образом (без написания 46 Оценка возможности Нет; Через доработку платформы. Да; Нет; Интеграция со сторонней технологией; Через доработку платформы. Да; Нет; Интеграция со сторонней технологией; Через доработку платформы. Да; Нет; Интеграция со сторонней технологией; Через доработку платформы. Да; Нет; Интеграция со сторонней технологией; Через доработку платформы. Да; Нет; Интеграция со сторонней технологией; Через доработку платформы. Да; Коммента рий Категория Характеристика компонентов построения пользовательского интерфейса с асинхронным взаимодействием с сервером Расшифровка требования программного кода) позволяет использовать компоненты web 2.0 (например, grids, suggests и пр.), работа с которыми не требует перерисовки страницы браузера целиком. 47 Оценка возможности Нет; Интеграция со сторонней технологией; Через доработку платформы. Коммента рий 6 ПРИЛОЖЕНИЕ Б Шаблон пакета договорных документов. ДОГОВОР №[указать номер договора] г. Москва [указать дату договора] ОАО «АЛЬФА-БАНК», именуемое в дальнейшем «Заказчик», в лице [указать ФИО лица, подписывающего договор], действующего на основании [указать название и реквизиты документа], с одной стороны, и [указать название контрагента], именуемое в дальнейшем «Исполнитель», в лице [указать ФИО лица, подписывающего договор со стороны контрагента], действующего на основании [указать на основании чего действует представитель контрагента], с другой стороны, в дальнейшем совместно именуемые «Стороны», заключили настоящий договор (далее – «Договор») о нижеследующем: Предмет Договора В рамках Договора Исполнитель принимает на себя обязательство выполнить работы по разработке/доработке программного обеспечения [указать название] (далее – «ПО») [на основании технического задания Заказчика (Приложение №1 к Договору)], сдать результат работ Заказчику (согласно п. 3.1.2. Договора) [и предоставить Заказчику право использовать ПО в предусмотренных Договором пределах], а Заказчик обязуется принять работы в порядке и на условиях, установленных Договором, а также оплатить работы [и вознаграждение за предоставленное право]. При создании ПО Исполнитель обязан оформить сопроводительную документацию к ПО: [указать название документов]. Копия такой сопроводительной документации на бумажном носителе должна быть передана Заказчику одновременно с Актом сдачи-приемки работ. Результатом работ по Договору является разработанное/доработанное ПО, удовлетворяющее [техническому заданию (далее – «ТЗ», а также бизнес-требованиям (далее – «BRD») и/или функциональным требованиям] (далее – «FSD») и требованиям по производительности (далее – «ТП») (Приложение №1 к Договору)], включая сопроводительную документацию к ПО (далее совместно именуемые «Документация»). [Документация будет разработана и согласована Сторонами в рамках исполнения Договора.] Состав работ, подлежащих выполнению Исполнителем (далее – «Работы») определен в Приложении №2 к Договору. Способ реализации работ определен методологией выполнения работ (Приложение №6 к Договору). Сроки выполнения Работ Работы по Договору должны быть выполнены Исполнителем в срок до [________]. ПО должно быть передано Заказчику для приемки (согласования) в срок до [________.]. Исполнитель обязан приступить к выполнению Работ в срок, указанный в п.3.1.1 Договора. В случае несвоевременного и ненадлежащего выполнения Заказчиком взятых на себя по Договору обязательств, сроки выполнения Работ по Договору увеличиваются на срок задержки выполнения Заказчиком своих обязательств, если иное не предусмотрено Договором. Права и обязанности Сторон 3.1. Права и обязанности Исполнителя 48 Исполнитель обязуется приступить к выполнению Работ на следующий рабочий день после заключения Договора и выполнить их в сроки, предусмотренные п.2.1. Договора, при условии надлежащего исполнения Заказчиком всех взятых на себя по Договору обязательств. Посредством электронных каналов связи передать Заказчику ПО на основании ст. 703 ГК РФ по акту приема-передачи дистрибутива, форма которого приведена в Приложении №3 к Договору, для проведения тестирования. или 3.1.2 Передать Заказчику экземпляр ПО на основании ст. 703 ГК РФ и по акту приема-передачи дистрибутива, форма которого приведена в Приложении №3 к Договору, для проведения тестирования. [Предоставить право использовать ПО способами, определенными п.9.1 Договора. Право использовать ПО считается предоставленным Заказчику со дня подписания им акта сдачиприемки работ, форма которого приведена в Приложении №4 к Договору. Заключения каких-либо иных сделок для предоставления права не требуется.] Исполнитель обязан не позднее следующего рабочего дня после заключения Договора назначить своего представителя из числа своих работников и сообщить Заказчику ФИО, название должности и контактные данные своего представителя. Исполнитель вправе требовать от Заказчика предоставления необходимой информации для выполнения Работ согласно Договора. Исполнитель обязан выполнить Работы с надлежащим качеством, а именно: ПО должно удовлетворять Документации, быть применимым для выполнения функций перечисленных в Документации и не нарушать прав третьих лиц на интеллектуальную собственность. 3.2. Права и обязанности Заказчика Заказчик вправе в любое время проверять ход и качество Работ, выполняемых Исполнителем по Договору. Заказчик обязан в течение 3 (Трех) рабочих дней с момента подписания Договора назначить своего представителя из числа своих работников и сообщить Исполнителю ФИО, название должности и контактные данные своего представителя. Заказчик обязан принимать и оплачивать результаты Работ, выполненных Исполнителем в рамках Договора, в порядке, предусмотренном разделами 4, 5 Договора. Заказчик не предоставляет отчетов об использовании ПО. Заказчик обязан своевременно предоставлять (в срок, не превышающий 5 (Пять) рабочих дней с момента поступления вопроса/запроса Исполнителя) информацию, необходимую для выполнения Работ. Стоимость и порядок расчетов Общая стоимость всех Работ, выполняемых Исполнителем по Договору, составляет [указывается общая стоимость в рублях] рублей и ___ коп., в том числе НДС (18%) - [указывается сумма в рублях] рублей и ___ коп. Счет на оплату авансового платежа должен быть передан Заказчику не ранее 5 (Пяти) рабочих дней до даты подписания Договора. Заказчик в течение 15 (Пятнадцати) рабочих дней с момента получения оригинала счета Исполнителя выплачивает аванс в размере [указывается сумма в рублях] рублей и ___ коп., в том числе НДС (18%) - [указывается сумма в рублях] рублей и ___ коп.. Окончательный платеж производится после подписания акта сдачи-приемки работ (далее – «Акт»), форма которого приведена в Приложении №4 к Договору, на основании оригинала счета Исполнителя. Оплата производится в течение 15 (Пятнадцати) рабочих дней с момента получения оригинала счета путем перечисления Заказчиком на расчетный счет Исполнителя денежной 49 суммы в размере [указывается сумма в рублях] рублей и __ коп., в том числе НДС (18%) [указывается сумма в рублях] рублей и __коп. Счет для оплаты передается Заказчику одновременно с подписанием Акта, или в течение 3 (Трех) рабочих дней с момента подписания Акта обеими Сторонами. Стороны осуществляют расчеты путем перечисления денежных средств в безналичном порядке по указанным в Договоре банковским реквизитам. Днем оплаты считается день списания денежных средств с корреспондентского счета Заказчика. Порядок сдачи-приемки результатов Результаты Работ, выполненных по Договору, предоставляются Исполнителем по электронной почте \ с сервера _____ (адрес) Заказчику в срок до [________] для проведения тестирования на основании акта приема-передачи дистрибутива, форма которого приведена в Приложении №3 к Договору. или 5.1. Результаты Работ, выполненных по Договору, предоставляются Исполнителем на компакт диске [или ином материальном носителе (с указанием формата записи)]. Критериями приемки результатов служит Документация, согласованная Сторонами. Исполнитель обязуется обеспечить соответствие разрабатываемого\дорабатываемого ПО Документации, а также условиям, указанным в п. 3.1.6. настоящего Договора. Для подтверждения соответствия разработанного\доработанного Исполнителем ПО Документации, Заказчик вправе провести Приемочное Функциональное Тестирование (далее – «ПФТ») и/ или Приемочное Нагрузочное Тестирование (далее – «ПНТ») ПО (далее - экспертиза) в соответствии с применяемой им методикой [указать документ, в котором эта методика описана и его реквизиты] самостоятельно, или возложить обязанности по проведению экспертизы на любое третье лицо по своему выбору на основании отдельно заключенного с таким лицом договора. ПФТ и/или ПНТ ПО должны быть проведены в течение срока не превышающего [указать срок] с момента передачи ПО Заказчику для проведения тестирования (далее – срок тестирования). В случае выявления несоответствия ПО требованиям Договора, Заказчик обязан уведомить Исполнителя о выявленных дефектах в течение 5 (Пяти) рабочих дней с момента их обнаружения. В случае соответствия результата Работ условиям Договора, Заказчик обязан подписать Акт в течение 10 (Десяти) рабочих дней с момента завершения срока тестирования и произвести окончательную оплату. В случае, если ПФТ и, или ПНТ выявляют несоответствие разработанного\доработанного ПО требованиям Договора, Исполнитель обязан выполнить все необходимые работы по устранению выявленных дефектов в соответствии с документом «Регламент управления дефектами программного обеспечения», утвержденным Распоряжением заместителя руководителя Блока «Информационные технологии» и передать Заказчику ПО в течение 10 (Десяти) рабочих дней с момента получения уведомления о дефектах для повторного ПФТ и, или ПНТ ПО. В случае повторного и последующих выявлений Заказчиком несоблюдения Исполнителем требований Договора, Исполнитель по требованию Заказчика обязан уменьшить договорную стоимость ПО, указанную в п.4.1. Договора, на сумму документально подтвержденных расходов Заказчика на проведение повторной и последующих тестирований, но не более стоимости ПО, либо обязан возместить Заказчику расходы, которые понес Заказчик на проведение ПФТ и/или ПНТ, в том числе по договорам с третьими лицами, в полном объеме, на основании претензии Заказчика в сроки, указанные в претензии Заказчика. Информирование Исполнителя о необходимости уменьшении договорной стоимости ПО производится Заказчиком по Форме, приведенной в Приложении №5 к Договору с приложением заверенных Заказчиком копий документов, подтверждающих его расходы на проведение ПФТ и/или ПНТ. 50 Документом, подтверждающим выполнение Работ, является подписанный Сторонами Акт. Обязанность по подготовке, подписанию и передаче Заказчику Акта (в двух экземплярах) лежит на Исполнителе. Акт передается Заказчику ответственным лицом Исполнителя после установления в рамках проведенных ПФТ и, или ПНТ соответствия ПО Договору. Заказчик обязан в течение 10 (Десяти) рабочих дней с момента получения Акта принять результаты, подписав и передав Исполнителю один экземпляр Акта. При возникновении между Заказчиком и Исполнителем разногласий по поводу соответствия ПО условиям Договора, каждая Сторона вправе за свой счет заключить договор с организацией осуществляющей проведение экспертиз программ для ЭВМ (далее – «Эксперт»). В случае если сделку с Экспертом будет заключать Заказчик, он вправе выбрать в качестве Эксперта любое лицо по своему усмотрению. Исполнитель обязан компенсировать расходы по сделке с Экспертом в случае, если Эксперт подтвердит наличие недостатков ПО. В случае если сделку с Экспертом будет заключать Исполнитель, он обязан получить письменное согласие на заключение сделки с Заказчиком. Расходы по сделке с Экспертом компенсирует Заказчик в случае, если Эксперт сделает вывод о необоснованности претензий Заказчика. Конфиденциальность Исполнитель обязуется соблюдать конфиденциальность в отношении информации Заказчика, полученной в связи с исполнением обязательств по Договору. К конфиденциальной информации Заказчика, в том числе, но не ограничиваясь этим, относится: информация об организационной структуре Заказчика, о системе материально-технического обеспечения, финансовые документы, техническая информация, информация об операционных системах Заказчика и доступе к ним, сведения по операциям, счетам, вкладам и сделкам Заказчика, клиентов Заказчика и аффилированных лиц Заказчика, а также любая другая информация, которая имеет статус конфиденциальной в соответствии с особыми в ней оговорками об этом или в соответствии с законодательством Российской Федерации. Исполнитель не вправе без письменного разрешения Заказчика разглашать или иным образом раскрывать конфиденциальную информацию третьим лицам, как в период действия Договора, так и после его прекращения. или 6.1. В отношении конфиденциальности Стороны руководствуются подписанным Сторонами Соглашением о конфиденциальности и неразглашении информации от «__» ____ 20__ г. и действующим законодательством Российской Федерации. Ответственность Сторон В случае просрочки оплаты стоимости Работ Исполнитель вправе требовать от Заказчика уплаты пени в размере 0,1 (Одной десятой) процента от неоплаченной в срок суммы за каждый день просрочки, но не более 10 (Десяти) процентов от неоплаченной в срок суммы. В случае просрочки выполнения Исполнителем Работ Заказчик вправе требовать от Исполнителя уплаты пени в размере 0,1 (Одной десятой) процента от стоимости Работ, указанной в п.4.1 Договора, за каждый день просрочки, но не более 10 (Десяти) процентов от стоимости Работ. Заказчик несет ответственность за качество предоставленной необходимой информации. Исполнитель гарантирует качество разработанной по Договору Документации (отсутствие какихлибо ошибок и ее применимость для эксплуатации ПО) за исключением случаев, когда недостатки документации вызваны недостоверностью (некачественностью) информации, предоставленной Заказчиком по Договору. Исполнитель гарантирует соответствие ПО Документации. Гарантии на ПО: Гарантийный срок составляет [указать срок гарантии в месяцах] с момента подписания Акта. 51 Гарантия на ПО включает диагностику и устранение ошибок, т.е. отклонений от Документации. Устранение ошибок производится путем внесения изменений в ПО согласно требованиям Заказчика, при условии, что ошибка воспроизводится и встречается в соответствующей действующей версии. Срок устранения ошибок составляет не более 5 (Пяти) рабочих дней с момента поступления требований Заказчика в письменной форме. В течение гарантийного срока устранение ошибок Исполнитель осуществляет за свой счет, без взимания дополнительной платы со стороны Заказчика. Исполнитель передает Заказчику все необходимые в связи с устранением ошибки документы и сведения. До передачи исправленного ПО, Исполнитель предоставит промежуточное решение для обхода ошибки. Срок предоставления промежуточного решения составляет не более 2 (Двух) рабочих дней с момента поступления запроса от Заказчика. Гарантия не распространяется на неисправности, возникающие не по вине Исполнителя вследствие ошибок и /или несоблюдения инструкций по обслуживанию или предписаний по техобслуживанию, включая случаи неправильного или халатного обращения Заказчика с ПО. Гарантия не распространяется также на неисправности, возникающие вследствие сбоев оборудования Заказчика, на котором установлено ПО, в случаях, когда сбой в работе оборудования вызван иными причинами, чем сбой в работе ПО. Обстоятельства непреодолимой силы Ни одна из Сторон не будет нести ответственность за неисполнение или ненадлежащее исполнение своих обязательств, если надлежащее исполнение оказалось невозможным вследствие действия непреодолимой силы, то есть чрезвычайных и непреодолимых при данных условиях обстоятельств, которые возникли после заключения Договора. К таким обстоятельствам Стороны относят: пожар, наводнение, землетрясение, другие стихийные бедствия, войну, военные действия, забастовки, гражданские волнения, эпидемии, блокаду, эмбарго, принятие органами государственной власти и управления нормативных актов, делающих невозможным исполнение или надлежащее исполнение сторонами своих обязательств. В случаях наступления обстоятельств, предусмотренных в п.8.1 Договора, срок выполнения Стороной обязательств по Договору отодвигается соразмерно времени, в течение которого действуют эти обстоятельства и их последствия. Если наступившие обстоятельства, перечисленные в п.8.1 Договора, и (или) их последствия продолжают действовать более 2 (Двух) месяцев подряд, Стороны проводят дополнительные переговоры для выявления приемлемых альтернативных способов исполнения Договора. Сторона, ссылающаяся на наступление обстоятельств непреодолимой силы, должна, по требованию другой Стороны, предоставить документальное подтверждение происшедших событий, а также их влияния на ее деятельность. В случае непредставления подтверждающих документов Сторона не вправе ссылаться на обстоятельства непреодолимой силы. Исключительное право Исполнитель одновременно с передачей результатов выполненных Работ предоставляет Заказчику право на воспроизведение ПО в памяти ЭВМ Заказчика без ограничения по количеству экземпляров, применять воспроизведенные в памяти ЭВМ экземпляры ПО с целью получения результатов в работе ЭВМ Заказчика для достижения необходимых Заказчику результатов, а также право делать архивные копии ПО и документации к нему, которые могут понадобиться для восстановления работоспособности ПО в случае сбоя работы ПО без ограничения по количеству экземпляров. Исполнитель передает Заказчику указанные права на срок действия исключительного права без ограничения территории использования. Вознаграждение за передаваемые права включено в стоимость работ по Договору и составляет 1% (Один процент) от 52 стоимости работ. Заключения между Сторонами отдельного договора/соглашения о передаче Заказчику указанных прав, не требуется. или 9.1. В соответствии с п.1 статьи 1296 ГК РФ исключительное право на ПО принадлежит Заказчику. Срок полезного использования переданного Заказчику ПО составляет [указать срок полезного использования в месяцах или годах] и начинает исчисляться с даты подписания Сторонами Акта сдачи-приемки работ. Заключительные положения Договор вступает в силу с момента его подписания обеими Сторонами и действует в течение срока действия исключительного права на произведение. Договор может быть расторгнут по соглашению Сторон либо в порядке, предусмотренном законодательством Российской Федерации. Дополнения и изменения к Договору действительны, если они совершены в письменной форме путем составления и подписания Сторонами дополнительных соглашений. Права, обязанности и ответственность Сторон, не урегулированные Договором, регламентируются законодательством Российской Федерации. Приложения №№ 1, 2, 3, 4, 5, 6 подписываются Сторонами и являются неотъемлемыми частями Договора. Договор составлен и подписан в 2 (Двух) экземплярах, имеющих одинаковую юридическую силу, – по одному для каждой Стороны. Споры и разногласия, возникающие в процессе исполнения обязательств по Договору, разрешаются путем переговоров между Сторонами, а при не достижении взаимоприемлемого результата – в Арбитражном суде г. Москвы. Переговоры в контексте настоящего пункта не следует рассматривать как установление претензионного порядка разрешения спора. Приложения. Приложение №1 – Техническое задание, бизнес-требования и/или функциональные требования и требования по производительности. Приложение №2 – Состав работ, подлежащих выполнению Исполнителем. Приложение №3 – Форма акта приема-передачи дистрибутива. Приложение №4 – Форма акта сдачи-приемки работ. Приложение №5 – Форма Уведомления об уменьшении стоимости разработки\доработки программного обеспечения Приложение №6 – Методология реализации работ. Адреса, банковские реквизиты и подписи Сторон Исполнитель [Заполнить реквизиты контрагента] Место нахождения: ОГРН ИНН/КПП Р/с К/с Заказчик Место нахождения:107078, г. Москва, ул. Каланчевская, д.27 ОГРН 1027700067328 ИНН/КПП 7728168971/ 775001001 Р/с 47422810200000001242 в ОАО «АЛЬФА-БАНК», г. Москва К/с 30101810200000000593 в ОПЕРУ Московского ГТУ Банка России 53 БИК БИК 044525593 _____________________ ______________________ ______________________ \ _________________ _______________________ М.П. М.П. 54 Приложение №1 к Договору [указать номер и дату Договора] Техническое задание Бизнес-требования к ПО Функциональные требования к ПО Требования по производительности к ПО ИСПОЛНИТЕЛЬ _____________________ /_______________ ЗАКАЗЧИК ________________________ /___________ 55 Приложение №2 к Договору [указать номер и дату Договора] Состав работ, подлежащих выполнению Исполнителем: № Наименование Основные результаты п/п 1 2 3 4 Дата завершения ИСПОЛНИТЕЛЬ ЗАКАЗЧИК _____________________ /_______________ ________________________ /___________ 56 Приложение №3 к Договору [указать номер и дату Договора] ФОРМА АКТА ПРИЕМА-ПЕРЕДАЧИ ДИСТРИБУТИВА АКТ приема-передачи дистрибутива г. Москва «___» ___________ 201_ г. «__________», именуемое в дальнейшем «Исполнитель», в лице __________________, действующего на основании ____________________________________, с одной стороны, и ОАО «АЛЬФА-БАНК», именуемое в дальнейшем «Заказчик», в лице _________________________________________, действующего на основании доверенности _______________, с другой стороны, вместе и по отдельности именуемые «Стороны(а)», составили настоящий Акт приема-передачи дистрибутива (далее – «Акт») к Договору от _______________ № _____ (далее – «Договор») о нижеследующем: Исполнитель передал, а Заказчик принял следующие результаты работ: ПО «……………», модуль «…………….»… файл…(далее – ПО) Отчеты, документация, описание… ИСПОЛНИТЕЛЬ ЗАКАЗЧИК ____________________________ _____________________________ __________________ /________________/ ____________________ /__________/ ИСПОЛНИТЕЛЬ _____________________ /_______________ ЗАКАЗЧИК ________________________ /___________ 57 Приложение №4 к Договору [указать номер и дату Договора] ФОРМА АКТА СДАЧИ-ПРИЕМКИ РАБОТ АКТ сдачи-приемки работ г. Москва «___» ___________ 201_ г. «__________», именуемое в дальнейшем «Исполнитель», в лице __________________, действующего на основании ____________________________________, с одной стороны, и ОАО «АЛЬФА-БАНК», именуемое в дальнейшем «Заказчик», в лице _________________________________________, действующего на основании доверенности _______________, с другой стороны, вместе и по отдельности именуемые «Стороны(а)», составили настоящий Акт сдачи-приемки работ (далее – «Акт») к Договору от _______________ № _____ (далее – «Договор») о нижеследующем: Исполнитель выполнил работы в соответствии с п. ___ Договора. Общая стоимость выполненных работ составляет ХХХХ (________________) рублей ___ коп., включая НДС (18%) ХХХХ (________________) рублей ___ коп. Исполнитель передал, а Заказчик принял следующие результаты работ: ПО «……………», модуль «…………….»… файл…(далее – ПО) Отчеты, документация, описание… Работы выполнены Исполнителем в полном объёме, с надлежащим качеством, в срок и подлежат оплате в сумме ХХХХ (________________) рублей ___ коп., включая НДС (18%) ХХХХ (________________) рублей ___ коп. Исполнитель одновременно с передачей результатов выполненных Работ предоставляет Заказчику право на воспроизведение ПО в памяти ЭВМ Заказчика без ограничения по количеству экземпляров, применять воспроизведенные в памяти ЭВМ экземпляры ПО с целью получения результатов в работе ЭВМ Заказчика для достижения необходимых Заказчику результатов, а также право делать архивные копии ПО и документации к нему, которые могут понадобиться для восстановления работоспособности ПО в случае сбоя работы ПО без ограничения по количеству экземпляров. Исполнитель передает Заказчику указанные права на срок действия исключительного права без ограничения территории использования. Вознаграждение за передаваемые права включено в стоимость работ по Договору и составляет 1% (Один процент) от стоимости работ. Заключения между Сторонами отдельного договора/соглашения о передаче Заказчику указанных прав, не требуется. или 6. В соответствии с п.1 статьи 1296 ГК РФ исключительное право на ПО принадлежит Заказчику. Срок полезного использования ПО - _____. После производства оплаты вышеуказанных работ Стороны не будут иметь претензий в отношении друг друга в рамках Договора. ИСПОЛНИТЕЛЬ ЗАКАЗЧИК ____________________________ _____________________________ __________________ /________________/ ____________________ /__________/ 58 ИСПОЛНИТЕЛЬ _____________________ /_______________ ЗАКАЗЧИК _____________________ /_______________ 59 Приложение №5 к Договору [указать номер и дату Договора] Форма Уведомления обеспечения об уменьшении стоимости разработки\доработки программного Уведомление об уменьшении стоимости разработки\ доработки программного обеспечения ОАО «АЛЬФА-БАНК» на основании п.5.7 Договора №___ от «___» _________ 201__г. (далее – «Договор») сообщает об уменьшении стоимости разработки\доработки ПО / возникновении расходов на проведение экспертизы и намерении воспользоваться своим правом требовать их компенсации/. Стоимость разработки\доработки ПО (____________________) рублей __ коп. согласно п.4.1. Договора составляет ________ Общая сумма расходов ОАО «АЛЬФА-БАНК» на проведение ____ экспертизы составляет _________ (______________________) рублей __ коп. На основании п.__ Договора ОАО «АЛЬФА-БАНК» требует уменьшит цену _______ - на сумму ______ (_______________) рублей ___ коп, включая НДС 18 % в размере ______ (______________) рублей __ коп. В срок до ____ направить в адрес Заказчика текст дополнительного соглашения об уменьшении цены Договора на указанную сумму // в срок до ______ вернуть излишне уплаченную сумму в размере _____ (________________) рубле __ коп. на счет Заказчика, указанный в Договоре. К данному уведомлению прилагаются следующие документы, подтверждающие расходы ОАО «АЛЬФА-БАНК» на проведение экспертизы ПО ________________________ : 1.__________________________________________________________________ 2.__________________________________________________________________ 3.__________________________________________________________________ 4.__________________________________________________________________ П О Д П И С И: ИСПОЛНИТЕЛЬ ЗАКАЗЧИК Должность: Должность: Подпись / ФИО / подпись / ФИО ------------------------------------------------------------образец------------------------------------------------------------------ ИСПОЛНИТЕЛЬ ЗАКАЗЧИК 60 / _____________________ /_______________ _____________________ /_______________ 61 Приложение №6 к Договору [указать номер и дату Договора] Содержание будет определено после выбора платформы. 62 7 ПРИЛОЖЕНИЕ В Список контактных лиц от Банка Список контактных лиц: № Контактное лицо п.п. 1. Виславский Артем Витальевич 2. Закерова Ольга Борисовна 3. 4. 5. 6. Герценштейн Сергей Витольдович Романова Людмила Михайловна Омельянчук Артем Борисович Ищенко Артем Дмитриевич Должность Область Руководитель направления Начальник управления Начальник управления Архитектор систем розничного кредитования Руководитель направления Руководитель направления E-mail Все avvislavskiy@alfabank.ru Банковские продукты и процессы Все ozakerova@alfabank.ru Архитектура новой системы lromanova@alfabank.ru Архитектурные стандарты Сопровождение aomelyanchuk@alfabank.ru sgertsenshteyn@alfabank.ru adischenko@alfabank.ru Если вопрос относиться к конкретной области из приведенных в таблице, обращение производится непосредственно ответственному с копией Виславскому А.В. (при отсутствии Герценштейну С.В.). 63 Приложение № 2 к конкурсной документации «Программа автоматизации процесса кредитования физических лиц» Запрос коммерческого предложения на услуги по контролю качества при создании автоматизированной системы обработки кредитных заявок (QA) Москва 2013 64 Ф.И.О. Утверждено: Бабаджанян Григорий Хачатурович Должность Дата Директор по продуктам Дирекция по продуктам Андрианова Наталия Викторовна Директор Дирекция бизнес-процессов Панкратов Михаил Викторович Директор Дирекция розничных технологий Согласовано: Володин Иван Андреевич Закерова Ольга Борисовна Герценштейн Сергей Витольдович Виславский Артем Витальевич Начальник Управления Управление внедрения и сопровождения продуктов Начальник Управления Управление технологий и тестирования Начальник Управления Управление технологий розничного кредитования Руководитель направления Дирекция розничных технологий 65 Подпись 1 ГЛОССАРИЙ Сокращение Банка, Заказчик БРБ ББ ПО НФОС SLOLP SLOLP AF SLOLP CF SLOLP MG SLOLP RB RFP BRD FSD ТЗ ОТАР DRP ОПЭ SIT LN UAT Заявитель Клиент Поставщик услуг по разработке Подрядчик, Поставщик, Поставщик услуг QA Вендор ТЦ Канал «VIP» Определение понятия Альфа-Банк Блок «Розничный бизнес» Блок «Безопасность» Программное обеспечение Новая фронт-офисная система Используемая в Банке фронт-система для создания и обработки кредитных заявок Используемая в Банке фронт-система для создания и обработки заявок на получение авто кредитов Используемая в Банке фронт-система для создания и обработки заявок на получение потребительских кредитов Используемая в Банке фронт-система для создания и обработки заявок на получение ипотечных кредитов Используемая в Банке фронт-система для создания и обработки заявок на получение розничных кредитов Request for Proposal - Запрос коммерческого предложения. Документ, подготавливаемый Банком с целью принятия обоснованного решения при выборе платформы / технологии для создания новой системы Business Requirements Document – Документ, содержащий описание бизнес-требований Functional Specifications Document – Документ, содержащий функциональный дизайн системы Техническое задание Организационно-технологическое архитектурное решение Disaster Recovery Plan (План восстановления системы после сбоев) Опытно-промышленная эксплуатация System Integration Testing Load Testing User Acceptance Testing Любое физическое лицо, обратившееся в Банк за какимлибо продуктом и/или услугой Физическое лицо, имеющее некоторые договорный отношения с Банком Организация, предоставляющая услуги по разработки и внедрению программного обеспечения Организация, предоставляющая услуги по оценке и контролю качества, а также консультационные услуги по определенным информационным технологиям Лицензиар программного обеспечения Торговый центр Специализированный канал обслуживания VIP клиентов Банка (может находиться в отделениях Банка, специализированных офисах Банка, либо обслуживается 66 Сокращение Канал «Кредитный брокер» Канал «Интернет магазин» Канал «Интернет» Канал «Отделение» Канал «POS» Канал «DSA» Канал «Телемаркетинг» CRUD LDAP SLA CO MC BC BO Определение понятия закрепленными за VIP клиентами менеджерами) Организации, работающие с Банком по агентской схеме (регистрация кредитной заявки происходит через собственное ПО партнеров) Канал кредитования клиентов интернет-магазинов (кредитная заявка заводится либо посредством специального ПО интернет-магазина, либо непосредственно через фронт-систему Банка) Канал самообслуживания, позволяющий заявителям самостоятельно заводить заявки на продукты Банка через Интернет Канал, представляющий из себя специально оборудованное помещение для обслуживания физических и юридических лиц работниками Банка Point of sale - Канал, представляющий из себя специально оборудованное рабочее место, обычно, находящееся в ТЦ, крупных магазинах, рынках и т.п. При этом продажей банковских продуктов может заниматься как сотрудник банка, так и наемный работник третьей организации Direct Sales Agents - Канал, продажи в котором осуществляют мобильные агенты (работники Банка) Обычно продажи осуществляются через презентации этими агентами продуктов Банка (на территории компаний, ТЦ и пр.) с последующей индивидуальной работой с каждым изъявившим желание заявителем Канал, обслуживающий заявителей посредством телефонной связи. Возможны как исходящие «обзвоны» потенциальных клиентов, так и обращения заинтересованных заявителей в Банк Возможные действия над объектом в системе: Create (создание), Read (чтение), Update (обновление), Delete (удаление) Lightweight Directory Access Protocol Service Level Agreement CORE — Программно-аппаратные компоненты, обеспечивающие ба-зовые системные сервисы для всех остальных классов систем. Mission Critical — Системы, позволяющие Банку выполнять свои ба-зовые функции, невозможность осуществления которых в течение 1 суток приводит к отзыву лицензии. Business Critical — Системы, обеспечивающие поддержку различных бизнесов Банка. Недоступность этих систем в течение 1 суток приводит к прямым финансовым потерям, потерям в результате упущенной выгоды и потерям, связанным с ущербом имиджу Банка. Business Operational — Системы, обеспечивающие поддержку раз-личных бизнесов Банка. Недоступность этих систем в течение 1 суток не приводит к существенным финансовым потерям. 67 Сокращение OP Целевая платформа Определение понятия Office Productivity — Офисные приложения, обеспечивающие эффек-тивную работу персонала Банка. Основная платформа для автоматизации бизнеспроцессов. Утвержденной является PEGA PRPC. 68 2 ОБЗОР ПРОГРАММЫ 2.1 Цели и задачи Программы Целью Программы является повышение эффективности и обеспечение гибкости бизнес-процессов кредитования физических лиц. Реализация этой цели позволит: За счет использования современной платформы и с учетом требований к гибкости, производительности и надежности, заложенных в архитектуру новой системы: Обеспечить высокую скорость изменения бизнес-процессов и внедрения новых продуктов; Обеспечить требуемый уровень функциональности, доступности, производительности. За счет изменения технологии и процессов разработки: Проводить большую часть изменений конфигурированием, а не разработкой; Обеспечить возможность параллельной разработки разными подрядчиками; Снизить затраты на владение и внедрение нового функционала. Указанная цель достигается за счет решения следующих задач: Разработка более эффективных целевых процессов кредитования физических лиц; Определение методологии разработки / развития новой системы, в т.ч. для обеспечения параллельности разработки разными подрядчиками; Разработка новой системы, апробирование новой системы на пилотных процессах во всех каналах продаж; Подготовка миграции на новую систему (разработка / обновление регламентов, обучение персонала); Последовательная миграция на новую систему, вывод из эксплуатации устаревших систем; Обучение персонала Банка. Реализация указанных задач должна быть направлена на обеспечение повышения эффективности бизнес-процессов кредитования и их ИТ-поддержки в следующих практических областях: Консультации клиентов по кредитным продуктам, первичный подбор продукта; Консультации клиентов по одобренным лимитам / продуктам; Проверка и подтверждение статуса заявителя / его работодателя; Прием анкеты и документов; Обработка анкеты и документов; Планирование коммуникаций с заявителями (в т.ч. через интеграцию с CRM системами Банка); Оперативная и аналитическая отчетность (в т.ч. через интеграцию с BI комплексом Банка); Подтверждение расчетов с партнерами; Продажи дополнительных (некредитных) продуктов. 69 2.2 Текущая ситуация 2.2.1 Описание продуктовой линейки Рамки Программы определяют, в первую очередь, бизнес-процессы продажи кредитных продуктов. Ниже приводится описание текущей продуктовой линейки Банка, бизнес-процессы продажи которых должны реализоваться в новой системе. На текущий момент Банк предлагает следующие кредитные продукты физическим лицам: Кредит наличными (PIL). Нецелевой необеспеченный кредит наличными физическим лицам (выдается на неэмбоссированную / эмбоссированную пластиковую карту, в качестве исключения может выдаваться через кассу без оформления карты); Кредитная карта (CC). Нецелевой необеспеченный револьверный кредит физическим лицам (выдается на эмбоссированную пластиковую карту); Кредиты быстро (Blits). Нецелевой необеспеченный кредит наличными физическим лицам (выдается на неэмбоссированную пластиковую карту, в качестве исключения может выдаваться через кассу без оформления карты). Отличается от PIL коротким сроком принятия решения (несколько минут) и пост-проверкой документов заявителя; Потребительский кредит (IL). Целевой необеспеченный кредит для оплаты товара/услуги (выдается на неэмбоссированную пластиковую карту либо без выдачи карты); Кредит быстро+. Целевой необеспеченный кредит наличными, выдаваемый на карту партнера «Кукуруза»12; Потребительская карта (Потреб.карта). Аналог кредитной карты, но продаваемый в канале POS; Карта с фиксированным платежом (КФП). Целевой / нецелевой необеспеченный револьверный кредит с погашением аннуитетными платежами; Companion Card (CompCard). Комплексные продукт, подразумевающий одновременное оформление Кредита наличными и кредитной карты; Авто-кредитование13. Ипотечное кредитование. У каждого из кредитных продуктов есть ряд разновидностей характеризующихся процентными ставками, сроками, территорией предоставления, категорией клиентов и т.п. Таким образом, перечисленные выше продукты являются, фактически, «типами продуктов», которые для каждого конкретного уникального набора характеристик на уровне АБС Банка превращаются в конкретные продукты (таких продуктов насчитывается несколько тысяч). Каждый из продуктов предлагается Банком в ряде каналов продаж. Каждый из каналов продаж обладает своей спецификой и при продаже однотипных продуктов в различных каналах могут иметься отличия в соответствующих бизнес-процессах. Текущее распределение кредитных продуктов по каналам продаж показано в таблице (распределение продуктов по каналам и состав каналов будет меняться с течением времени): 12 13 http://kykyryza.ru/ Решение о реализации Авто-кредитования и ипотечного кредитования будет принято после реализации 1-й Фазы Программы. 70 Каналы Кредитный Интернет Интернет14 Отделение POS** брокер магазин DSA Телемаркетинг* + + + + + + Продукты PIL + IL + CC + + + + + Потреб.карта Companion Card + + + Кредит быстро+ + Кредиты Быстро + + КФП + Примечание: *Канал телемаркетинга в настоящее время не осуществляет продажи непосредственно. Данный канал осуществляет консультации и планирует передачу клиента для оформления в один из каналов продаж: DSA, либо Отделение. **Канал POS работает в двух вариантах: т.н. «Людная технология» и «Безлюдная технология», первая означает, что продажи осуществляет сотрудник Банка, вторая – наемный агент третьей организации. Бизнес-процессы для этих варрантов имеют отличия. Количественные характеристики описанных каналов продаж представлены в таблице: Каналы Кредитный Интернет Интернет Отделение брокер магазин анкета POS DSA Телемаркетинг*** Кол-во, 2 70 2**** 211* 74000** 400 2 шт. Примечание: *Территориально расположены более чем в 80 городах России (представлены все часовые пояса). **Продажи в этих точках осуществляются более 25000 аккредитованными партнерами Банка. ***Существует как собственный центр обработки вызовов, так и аутсорсинговый партнер. **** К моменту внедрения Пилота будет эксплуатироваться две версии системы «Интернет анкета», с последующие заменой одной на другую. 14 Например, данный сервис https://credits.alfabank.ru/rp/retcredit?app=pil&code=alfasite 71 Перечисленные выше кредитные продукты существуют в двух вариантах (на текущий момент это относиться не ко всем их них): Первичные. Предложение для заявителя формируется без учета имеющихся у него продуктов Банка и/или его поведенческого профиля; Предодобренные (т.н. вторичные). Предложение формируется с учетом имеющихся у клиента продуктов Банка и/или его поведенческого профиля. Бизнес-процессы оформления первичных и вторичных продуктов сильно отличаются. Фактически, продажа вторичного продукта, если он существует для данного заявителя, заключается в уточнении параметров продукта в рамках одобренных лимитов, формировании некоторых документов для подписания и непосредственно открытии договора. Помимо кредитных продуктов в продуктовую линейку Банка входят также некридитные продукты и услуги, предлагаемые вместе с кредитными. К таким продуктам и услугам, на текущий момент, относятся следующие: Страхование15; Защищенная карта16; Пакеты услуг17; Альфа-Хранитель18; Альфа-Талисман19; Защита покупки. Процесс оформления некредитных продуктов также свожится к формированию ряда печатных документов и вызову некоторой внешней системы с передачей ей требуемых данных. Различные комбинации кредитных и некредитных продуктов зависят от множества факторов, в т.ч. типа продуктов, канала продаж, категории клиента и прочих факторов. 2.2.2 Описание автоматизации текущих бизнес-процессов В настоящий момент в Банке для реализации бизнес-процессов кредитования физических лиц для различных продуктов и каналов продаж используются различные взаимодействующие программные комплексы и системы. Основной системой является фронт-система, состоящая из 4-х систем: SLOLP RB (розничное кредитование), SLOLP CF (потребительское кредитование), SLOLP MTG (ипотечное кредитование), SLOLP AUTO (автокредитование). В целом, бизнес-процессы кредитования поддерживают также другие информационные системы (специализированные системы и обеспечивающие системы), полный перечень которых показан в таблице: Область Консультирование заявителей Программное обеспечение Платформа Калькулятор параметров кредита MS Office SLOLP CF BSC Gemini 15 http://www.alfabank.ru/retail/insurance/ http://www.alfabank.ru/retail/insurance/defence/ 17 http://www.alfabank.ru/retail/tariff_plans/ 18 http://www.alfahranitel.ru/ 19 http://www.alfabank.ru/retail/insurance/talisman/ 16 72 Статус Планируется к замене Планируется к замене Область Регистрация кредитной заявки20 Программное обеспечение Платформа Интернет анкета JBoss + Parser3 студии А.Лебедева SLOLP CF, SLOLP RB BSC Gemini ABBYY Form Reader ABBYY ПО партнеров (кредитный брокер) Идентификация заявителя Продажи вторичных кредитных продуктов Скоринг заявки, проверка заявителя Конвейерные проверки заявителя Сканирование документов, обработка сканов, проверка документов Администрирование бумажного документооборота Хранение сканов документов Взаимоотношение с заявителями (по первичным заявкам) Взаимоотношения с партнерами (потребительское кредитование) – Статус Планируется к замене Планируется к замене Выводится из эксплуатации21 – Планируется к замене Планируется развитие Планируется развитие OCRM, GBA планируется развитие TopUp – планируется к замене Планируется развитие Планируется развитие Direct Sales (тонкий клиент) ASP.NET GBA Java Equation (CIF) Mysis Equation OCRM, GBA, TopUp Chordiant, Java, Mysis Equation WSRM (набор вебсервисов) Комплекс платформ CCM Java ABBYY Flexy Capture ABBYY Планируется развитие ПО «Досье», Excel, Access ASP.NET, MS Office Планируется к замене Электронный архив IBM Content Manager Excel MS Office CallCRM Chordiant Комплекс систем IBM LN SLOLP CF, Excel BSC Gemini, MS Office Планируется развитие Планируется к замене Планируется развитие Планируется к замене Планируется к замене Для отдельных продуктов возможен вызов внешних сервисов партнеров Банка. При продаже страховых продуктов возможно обращение к внешним сервисам/системам партнеров. 21 Выводится из эксплуатации к концу 2012 г. – началу 2013 г. в рамках другого проекта (с частичной заменой функционала на ABBYY FC). 20 73 Область Взаимоотношения с партнерами (розничное кредитование и зарплатные проекты) Программное обеспечение Платформа Расчеты с партнерами Mysis Equation + IBM LN БД «Подтверждения дохода» IBM LN БД «Компании БРБ» IBM LN БД «Служебные записки ГБК» Direct Sales (толстый клиент), Excel Работа с з.п. счетами клиентов Администрирование Direct Sales (толстый каналов прямых клиент), Access, Excel продаж Отчетность и анализ DWH, BI IBM LN Delphi, MS Office МСОС + Mysis Equation Статус Планируется развитие Планируется к замене Планируется к замене Планируется к замене Планируется к замене Планируется развитие Delphi, MS Office Планируется к замене Комплекс платформ Планируется развитие Примечание: «Планируется развитие» - может не означать развитие в рамках только данной Программы. «Статус будет определен позже» - статус будет определен после выбора платформы. В любом случае, Заказчик обеспечит координацию всех работ при изменениях в ИТрешениях указанных областей деятельности. 2.3 Структура Программы Структурно Программа состоит из следующих взаимосвязанных проектов: Предпроект (завершен); Пилот (т.н. 1-я Фаза Программы); Проекты миграции (несколько фаз программы). Основными задачами Предпроекта являлись: подготовка к реализации Программы; проведение аналитики по ограниченному числу процессов (пилотных) процессов кредитования, проектирование; подготовка к реализации пилотных процессов кредитования в новом решении; выбор платформы для реализации новой системы. Основными задачами Пилота (1-ой Фазы программы) являются: модернизация окружения (систем обеспечивающих процессы кредитования и/или являющихся поставщиком необходимой информации для кредитных процессов); реализация пилотных процессов в новом решении; миграция справочных данных и классификаторов, включая процессы ETL; тестирование и внедрение нового решения; опытно-промышленная эксплуатация нового решения (параллельно работает новое и старое решение); подготовка к полномасштабной миграции. 74 После получения удовлетворительных результатов в ходе опытно-промышленной эксплуатации пилотной версии новой системы принимается решение о полномасштабной реализации на новой платформе всех бизнес-процессов продажи банковских продуктов кредитования физических лиц (имеется в виду начало разработки и последующее внедрение, аналитика по бизнес-процессам будет разрабатываться параллельно). Процесс миграции будет разбит на ряд фаз, позволяющих более эффективно реализовывать соответствующие группы бизнес-процессов на новом решении. Основными задачами каждого проекта миграции являются (2-я и последующие фазы Программы): планирование миграции, выбор очередных бизнес-процессов для миграции; проведение аналитики по выбранным процессам, проектирование решения; реализация выбранных бизнес-процессов в новом решении; миграция справочных данных и классификаторов, включая процессы ETL; тестирование и внедрение; опытно-промышленная эксплуатация; доработка версии, находящейся в стадии ОПЭ (при необходимости). К концу реализации Программы все устаревшие решения должны быть выведены из эксплуатации. Их функциональность в том или ином виде должна быть реализована в новых системах (платформа и технологии, выбранные для реализации, могут отличаться для различных систем). 2.4 Рамки Программы и проектов (фаз) Программы Рамки Программы определяются ее целями и задачами (см. раздел 2.1), т.е. в стратегическом плане конкретный набор решаемых задач будет корректироваться с учетом текущих потребностей бизнеса Банка для более эффективной реализации указных целей Программы. В рамки Программы входят следующие: Создание системы обработки кредитных заявок, включая весь функционал по администрированию; Создание системы для автоматизации работы кредитных менеджеров в ходе процесса взаимодействия с заявителем; Модернизация специализированных и вспомогательных систем (систем окружения) для обеспечения соответствия их целям и задачам Программы, а также стандартам реализации (см. п. 3.2) и требованиям по производительности (см. п. 3.5). Система для автоматизации работы кредитных менеджеров в ходе процесса взаимодействия с заявителем и система обработки кредитных заявок являются ядровыми системами с т.з. процессов кредитования физических лиц. В рамки их функций входят следующие: Консультирование заявителей; Регистрация кредитной заявки; Идентификация заявителя + фотографирование заявителя (безотносительно конкретных продуктов); Скоринг заявки, проверка заявителя (только на уровне интеграции с существующими сервисами скоринга, безотносительно конкретных продуктов); Взаимоотношение с заявителями; Продажи предодобренных (вторичных) кредитных продуктов (на уровне интеграции с существующими сервисами, безотносительно конкретных продуктов); Продажи некредитных продуктов совместно с кредитными продуктами; 75 Оперативная отчетность и мониторинг. Создание системы обработки кредитных заявок обеспечивает взаимодействие со всеми системами окружения в ходе реализации бизнес-процесса кредитования. В функции данной системы также входит прием и обработка заявок на кредиты, созданные в третьих внешних системах (например, в системах партнеров (т.н. кредитный брокер) и интернет анкетах). Модернизация специализированных и вспомогательных систем производится, как правило, без использования целевой платформы (Pega PRPC), но подразумевают возможность ее использования. Конкретные решения по модернизации таких систем и участие поставщика услуг по разработке в работках по модернизации будут оговорены с выбранным поставщиком. В функции таких систем входят: Конвейерные проверки заявителя; Сканирование документов, обработка сканов, проверка документов (на уровне интеграции с существующими сервисами, безотносительно конкретных продуктов); Администрирование бумажного документооборота (безотносительно конкретных продуктов); Хранение сканов документов (на уровне интеграции с существующими сервисами, безотносительно конкретных продуктов); Управление партнерами по потребительскому кредитованию; Управление партнерами по розничному кредитованию и зарплатным проектам; Аналитическая отчетность и анализ; Уведомление заявителя о статусе его заявок через колл-центр. С т.з. реализации бизнес-процессов кредитования в новой системе подразумевается, что необходимый объем функционала в системах окружения будет реализован к моменту необходимому для старта этого процесса. Как указывалось выше Программа включает в себя несколько фаз, с явно выделенной 1-й пилотной фазой, по результатам которой будет приниматься решение о необходимости дальнейших инвестиций в Программу. Предварительно в Программе выделено 3 фазы активной миграции на новую платформу. Миграция должна проводиться «по-продуктам». Распределение продуктов, бизнес-процессы продажи которых будут реализованы на новой платформе, по фазам показаны в таблице: 1-я Фаза (Пилот) Продукт ы и услуги Банка Кредитная карта (CC) Кредиты быстро (Blits) Предодобренные кредитные карты Все некредитные (продаваемые вместе с кредитными картами и кредитами быстро) 2-я Фаза Кредит наличными (PIL) Companion Card Потребительский кредит (IL) Карта с фиксированным платежом (КФП) Предодобренные кредиты наличными Все некредитные (продаваемые вместе с кредитами наличными, Companion Card, 76 3-я Фаза Все кредитные Все предодобрен ные Все некредитные 1-я Фаза (Пилот) 2-я Фаза 3-я Фаза картами с фиксированным платежом и потребительскими кредитами) Предполагаемые сроки завершения описанных фаз приведены в следующем разделе. 2.5 Сроки Программы и проектов Программы Базовые сроки реализации Программы: начало 2012 года – конец 2014 года. Окончанием реализации Программы считается момент полного прекращения эксплуатации текущих фронт-офисных систем. Примерные сроки реализации фаз программы приведены в таблице: № Окончание Фаза Начало п.п. (не позднее) 5. Предпроект Май 2012 г. Февраль 2013 г. 6. Пилот (1-я Фаза) Март 2013 г. Ноябрь 2013 г. 7. 2-я Фаза Октябрь 2013 г. Август 2014 г. 8. 3-я Фаза Март 2014 г. Конец 2014 г. Примечание: Точные сроки фаз миграции (2-я – 3-я фазы) будут уточняться в ходе реализации Программы. Каждая фаза на верхнем уровне включает в себя ряд работ: Аналитика, Разработка, SIT/LT (Банк), UAT (Банк). Также каждая фаза подразумевает несколько точек внедрения. Аналитика подразумевает формирование бизнес-требований и дизайн системы (в первую очередь интеграция). Разработка включает как непосредственно реализацию требований, так и тестирование на стороне поставщика услуг по разработке. SIT/LT (Банк) подразумевает интеграционное тестирование поставленного программного обеспечения, включая нагрузочное тестирование. UAT (Банк) подразумевает приемочное тестирование для определения соответствия бизнес-требованиям непосредственно конечными пользователями. 77 2.6 Фазы Программы и результаты Как описано в разделе 2.3 Программа включает в себя ряд фаз. На каждой фазе реализации Программы требуется получение конкретного результата, промежуточный результаты могут внедряться по мере готовности в течение каждой фазы. Перечень основных ожидаемых результатов каждой из фаз приведен в таблице: № Фаза Результаты Критерий успеха п.п. 5. Предпроект Утверждены подходы к Выбранные подходы и целевая реализации Программы, платформа соответствуют выбрана целевая бизнес-приоритетам Банка. платформа для реализации бизнеспроцессов. 6. 1-я Фаза (Пилот) Стабильная версия пилота Согласованный план системы, прошедшая тестирования полностью приемочные испытания на выполнен. стороне Банка. Установленные критерии План миграции качества программного утвержден. обеспечения достигнуты. Результаты опытнопромышленной эксплуатации пилота положительны. 7. 2-я Фаза Стабильная версия Согласованный план системы (модулей), тестирования полностью прошедшая приемочные выполнен. испытания на стороне Установленные критерии Банка. качества программного 8. 3-я Фаза обеспечения достигнуты. Результаты опытнопромышленной эксплуатации положительны (деградации показателей производительности при наращивании нагрузки при запуске не выявлено). На рисунке ниже показана типовая структура фазы (задачи могут идти со сдвигами во времени): 78 Фаза 1 Аналитика Разработка Тестирование Задача 1 ОПЭ Rollout Задача ... Аналитика Разработка Задача N Тестирование ОПЭ Rollout 3 БАЗОВЫЕ ТРЕБОВАНИЯ К РЕАЛИЗАЦИИ ПРОГРАММЫ 3.1 Стандарты реализации Стандарты реализации направлены на обеспечение соответствия нового решения автоматизации кредитования физических лиц целям Программы и требованиям стандартов Банка. К стандартам реализации нового решения относятся: принципы построения целевых бизнес-процессов; архитектурные принципы Альфа-Банка; стандарты документирования разрабатываемого ПО; стандарты дизайна пользовательских интерфейсов. К принципам построения целевых бизнес-процессов и их реализации в новом решении относятся следующие: Непрерывность цепочки операций (т.е. все операции для одного пользователя происходят в одной системе, вся необходимая информация доступна в одном месте, либо вводится в одном месте); Глобальная актуальность справочной информации (т.е. в каждый момент времени все участники процесса используют единую справочную информацию, актуальность справочной информации поддерживается централизованно); Глобальная актуальность обрабатываемой информации (т.е. каждый объект в системе (Анкета, Договор, Торговая точка, Агент и пр.) в каждый момент времени и для всех участников процесса находится в актуальном состоянии и статусе); Контролируемость и измеримость (т.е. все действия в системе над всеми объектами контролируются, состояние всех обрабатываемых объектов в каждый момент времени доступно и измеримо). 79 К архитектурным принципам Альфа-Банка относятся22: Принципы Архитектуры уровня предприятия: o Ориентироваться на стратегии развития бизнеса; o Проектировать для последующих изменений; o Строить для многократного использования; o Проектировать во взаимодействии и взаимосвязи; o Проектировать для адаптивности и маневренности; o Управлять информацией как всеобщим активом предприятия; o Обеспечивать рост объемов; o Обеспечивать доступность и непрерывность функционирования бизнеса; o Соответствовать стандартам, избегать дублирования; o Централизовать; o Строить для пользы всей организации; o Обеспечивать информационную безопасность; o Инновационность; Принципы Информационной Архитектуры: o Разделять транзакционные и аналитические данные; o Каждой информации – свое место и владельца; o Корректность и актуальность данных; o Консолидировать финансовую информацию; o Унифицировать способы доступа к информации; Принципы Архитектуры Решений: o Избегать «толстых клиентов»; o Информационная среда должна быть гранулированной и слабосвязанной; o Максимально использовать промышленные стандарты, технологии, продукты; Принципы Технической Архитектуры: o Принцип необходимой достаточности-адекватности бизнес-задаче; o Масштабируемость; o Управляемость; o Сохранение инвестиций; o Модульность; o Максимальная используемость. Стандарты документирования разрабатываемого ПО и дизайна пользовательских интерфейсов могут быть предоставлены по запросу. Вопросы контроля реализации указанных стандартов реализации, касающихся деятельности поставщиков, описываются в следующих разделах. Кроме того, в Банке действуют следующие стандарты технической архитектуры, определяющие параметры соответствующих системных и аппаратных компонент любой эксплуатируемой системы. Создаваемая в рамках Программы система является системой класса BC. Для систем данного класса установлены следующие стандарты технической архитектуры: Серверы баз данных: Класс ИТАппаратная Операционная СУБД системы платформа система DB2 for i5/OS IBM System i IBM i5/OS CO, MC, BC ORACLE 10g HP Integrity HP-UX 11i ORACLE 11g HP Integrity HP-UX 11i 22 Пояснения по содержанию указанных принципов можно запросить отдельно у соответствующего контактного лица (см. Приложение А). 80 Серверы приложений: Категория Название ПО ПО IBM WebSphere Application Server CO, MC, BC Oracle WebLogic Server Портальные серверы: Категория Название ПО ПО IBM WebSphere Portal Server CO, MC, BC Oracle WebLogic Portal Аппаратная платформа Программная платформа HP Integrity HP-UX 11i HP Integrity HP-UX 11i Аппаратная платформа HP Integrity HP Integrity Программная платформа HP-UX 11i HP-UX 11i Для систем прочих классов (BO, OP) устанавливаются иные стандарты технической архитектуры, которые могут быть предоставлены по запросу. 3.2 Методология реализации 3.2.1 Общие принципы Проект внедрения системы класса «business critical» на новой платформе является для Банка высоко рискованным. Для целей контроля рисков как технических, так и проектных при реализации всех фаз Программы будет применяться подход, подразумевающий углубленный контроль и мониторинг хода работ на всех этапах проекта. При этом будет требоваться итеративный подход к разработке для оценки корректности концепций и верификации бизнес-требований, т.е. формирование нескольких поставок, реализующих отдельные группы функций, до момента получения готового продукта, когда Банк сможет провести собственное интеграционное тестирование системы. Конкретные процедуры и формат мероприятий по контролю и мониторингу будет определен при заключении договора. В целом процессы создания новой системы должен содержать следующие группы процессов: аналитика (разработка бизнес-требований и дизайна системы/модулей системы, с учетом характеристик конкретной платформы); разработка (реализация требований путем кодирования и/или настройки); тестовая аналитика (разработка на основе согласованных требований тестплана, включая набор тест-кейсов); тестирование на стороне подрядчика (включает в себя весь комплекс тестовых испытаний необходимый для достижения требуемого качества). SIT/LT на стороне Банка (включает обязательно нагрузочное тестирование для контроля соответствия нефункциональным требованиям); UAT на стороне Банка; управление конфигурациями. Группа процессов, обеспечивающая контроль версий всех артефактов проекта, процессы данной группы находятся и в ведении Банка и ведении подрядчика; управление качеством. Группа процессов, обеспечивающая контроль качества создаваемой системы, процессы данной группы находятся и в ведении Банка и ведении подрядчика. В целях увеличения тестового покрытия и сокращения сроков тестирования должны широко применяться средства автоматизированного тестирования. 81 Важной составляющей процесса контроля качества реализации Программы в части использования новой платформы будет являться привлечение отдельной организации для реализации данных задач (далее – услуги QA). 3.2.2 Роль поставщика услуг по разработке Потенциальный поставщик услуг по реализации нового решения на целевой платформе (Pega PRPC) будет обязан взаимодействовать с поставщиком услуг QA для обеспечения снижения рисков и достижения должного уровня качества поставляемых решений. 3.2.3 Роль поставщика услуг QA Потенциальный поставщик услуг QA должен будет играть роль независимого контролирующего органа в ходе реализации Программы. В задачи поставщика услуг QA будут входить следующие: Архитектурный надзор; Технический надзор; Контроль качества поставок (соответствия функциональным и нефункциональным требованиям); Консультации разработчиков и сотрудников Банка по целевой платформе. Под архитектурным решением подразумевается совокупность базовых принципов решения некоторой задачи, включая использование различных компонент целевой платформы, способов их использования и взаимодействия. Архитектурное решение также включает способы и методы взаимодействия существующих и разрабатываемых компонент целевой платформы с внешними системами и сервисами. В задачу архитектурного надзора входят: Оценка реализуемости задачи при использовании целевой платформы; Оценка корректности архитектурного решения; Оценка оптимальности архитектурного решения при реализации на целевой платформе; Формирование заключения о корректности и оптимальности архитектурного решения (с указанием причин несоответствия и возможных последствий от его реализации); Формирование предложений по изменению архитектурного решения. Под техническим решением подразумевается совокупность конкретных способов реализации задачи с использованием целевой платформы, включая используемые аппаратные средства для размещения созданных программных компонент. В задачу технического надзора входят: Оценка корректности технического решения; Оценка оптимальности технического решения; Формирование заключения о корректности и оптимальности технического решения (с указанием причин несоответствия и возможных последствий от его реализации); Формирование предложений по изменению технического решения. Контроль качества поставок подразумевает участие поставщика услуг QA в процессах тестирования (функционального, интеграционного, нагрузочного и т.д.) для снижения рисков неуспешного внедрения и/или уменьшения количества инцидентов в ходе эксплуатации, а также проведения анализа инцидентов, обнаруженных в ходе опытно-промышленной эксплуатации внедренных решений. В задачу контроля качества поставок входят: 82 Оценка корректности методов тестирования решения на целевой платформе; Оценка достаточности тестового покрытия (на основе анализа тест-плана23); Формирование заключения о корректности используемых методов и достаточности тестового покрытия решения (с указанием причин несоответствия и возможных последствий от его реализации); Формирование предложений по изменению тест-плана и методов тестирования; Формирование заключения по причинам возникновения инцидентов, обнаруженных в ходе опытно-промышленной эксплуатации, с т.з. принятых архитектурных и технических решений. Задача по контролю качества осуществляется с учетом принятых ранее решений по соответствию поставляемого программного обеспечения архитектурным и техническим принципам. Консультации разработчиков и сотрудников Банка по целевой платформе подразумевает возможность обратиться к поставщику услуг QA за разъяснениями по вопросам использования целевой платформы, ее функциональным возможностям, а также оптимальным способом реализации на ней тех или иных задач. Консультации также включают необходимые разъяснения по заключениям и оценкам, разработанным поставщиком услуг QA. Описанный контроль качества будет закреплен в отдельном договоре со всеми заинтересованными сторонами. Детали данного договора будут оговорены с выбранными поставщиками услуг по разработке и QA. 3.3 23 Требования к проектной отчетности Проектной отчетностью для поставщика услуг QA является: Заключения (см. п. 3.2.3); Отчеты по выявленным несоответствиям; Отчеты по учтенным и неучтенным несоответствиям. В состав тест-плана минимум входят: Цели и задачи тестирования Описание тестируемого решения Описание методов проведения тестирования Набор тест-кейсов Критерии успеха 83 4 ТРЕБОВАНИЯ К КОММЕРЧЕСКОМУ ПРЕДЛОЖЕНИЮ 4.1 Формат коммерческого предложения К подаваемому коммерческому предложению предъявляются следующие общие требования: предложение подается в формате официальных документов организации потенциального поставщика, получившего данный запрос; предложение принимается только от организации получившей настоящий запрос; коммерческое предложение должно быть подписано руководителем организации, имеющим право подписания договорных документов. 4.2 Содержание коммерческого предложения Коммерческое должно включать минимум следующие разделы: общее описание предложения; профиль поставщика; описание предлагаемых услуг; оценка стоимости; замечания и предложения. Требования к содержанию перечисленных обязательных разделов коммерческого предложения описаны ниже. 4.3 Общее описание предложения Общее описание предложение должно включать: общее описание места и роли поставщика услуг QA при реализации программы (взгляд потенциального поставщика); общее описание предлагаемого подхода к реализации услуг QA. Цель данного раздела дать общее представление потребителям результатов данной Программы (бизнес-пользователям). 4.4 Профиль поставщика услуг QA В данном разделе должен быть описан профиль поставщика услуг QA. В ответе на данное коммерческое предложение необходимо привести следующий минимальный набор сведений: официальное наименование, бренд; общее описание организации, сферы деятельности; страны присутствия; успешные проекты/области деятельности релевантные предметной области данного запроса; наличие официального представительства в России, адрес представительства, контактные данные; контактные данные ответственных за коммерческое предложение лиц; наличие специалистов с необходимыми компетенциями по целевой платформе. 84 Успешные проекты по оказанию аналогичных данному запросу услуг должны быть подтверждены соответствующим перечнем и кратким описанием этих проектов. Наличие специалистов с необходимыми компетенциями по целевой платформе должно быть подтверждено приложением списка таких специалистов с резюме (с указанием уровня сертификации по целевой платформе). 4.5 Уровень сервиса В данном разделе описывается уровень предоставляемого сервиса на период реализации Программы. Приводится следующая информация: Выделенный менеджер (да/нет); Выделенный ведущий архитектор/консультант; Достаточность ресурсов (аналитики, консультанты, архитектора); Описание SLA по задачам оценки и формирования заключений. Описание SLA должно включать в себя базовые требования поставщика услуг QA к входной информации для выполнения им своих функций и среднее время выполнения этих функций. Поскольку решения о реализации и внедрении будут приниматься Заказчиком на основе заключений поставщика услуг QA, содержание указанного SLA является существенным фактором, позволяющим оценить влияние контроля качества на сроки реализации Программы. 4.6 Оценка стоимости услуг QA Оценка стоимости предложения производится в соответствии с требованиями, изложенными в Приложении № 3 к конкурсной документации. Форма договора по оплате услуг QA - Fixed Price. 4.7 Замечание и предложения В данном разделе приводятся замечания и предложения по описанному в данном запросе подходу к реализации Программы (в свободном формате), а также отдельно следующее: Замечания по стандартам Текст замечаний реализации (см. п. 3.2) Замечания по методологии реализации и ролям Текст замечаний поставщиков (см. п. 3.3) Замечания к требованиям по проектной отчетности (см. п. Текст замечаний 3.3) В случае отсутствия замечаний/особого мнения необходимо заполнить в вышеприведенной таблице соответствующую строку записью «Замечаний нет». 85 5 ПРИЛОЖЕНИЕ А Список контактных лиц от Банка Список контактных лиц: № Контактное лицо Должность Область п.п. 7. Виславский Артем Руководитель Все Витальевич направления 8. Закерова Ольга Начальник Банковские Борисовна управления продукты и процессы 9. Герценштейн Сергей Начальник Все Витольдович управления 10. Романова Людмила Архитектор Архитектура Михайловна систем новой системы розничного кредитования 11. Омельянчук Артем Руководитель Архитектурные Борисович направления стандарты 12. Ищенко Артем Руководитель Сопровождение Дмитриевич направления E-mail avvislavskiy@alfabank.ru ozakerova@alfabank.ru sgertsenshteyn@alfabank.ru lromanova@alfabank.ru aomelyanchuk@alfabank.ru adischenko@alfabank.ru Если вопрос относиться к конкретной области из приведенных в таблице, обращение производится непосредственно ответственному с копией Виславскому А.В. (при отсутствии Герценштейну С.В.). 86
