У Т В Е Р Ж Д А Ю: Директор по информационным технологиям ___________________ / В.А. Пуляев мая 13 "___"______________2020 г. ТЕХНИЧЕСКОЕ ЗАДАНИЕ НА ДОРАБОТКУ ФУНКЦИОНАЛА КЛИЕНТСКОГО ПРИЛОЖЕНИЯ ПАО «СИЛОВЫЕ МАШИНЫ» СОГЛАСОВАНО: Заместитель генерального директора – руководитель дивизиона сервиса _______________________ Лариошкин В.А. РАЗРАБОТАЛ: Старший менеджер центра развития бизнессистемы _____________________ Васяев В.Д. Санкт-Петербург 2020 ОГЛАВЛЕНИЕ Термины и определения Сокращения и обозначения 1. ОБЩИЕ СВЕДЕНИЯ О РЕШЕНИИ 1.1. Наименование решения 1.2. Платформа для реализации решения 1.3. Сведения о Заказчике и Исполнителе 2. ЦЕЛИ, ЗАДАЧИ И НАЗНАЧЕНИЕ РЕШЕНИЯ 2.1. Цели и задачи 2.2. Назначение 3. ТРЕБОВАНИЯ К АРХИТЕКТУРЕ РЕШЕНИЯ 3.1. Схема целевой архитектуры 3.2. Требования к мобильному приложению 3.3. Требования к эргономике и технической эстетике 4. ФУНКЦИОНАЛЬНЫЕ ТРЕБОВАНИЯ К РЕШЕНИЮ 4.1. Общие требования 4.2. Требования к ролям и полномочиям 4.3. Требования к внесению функциональных изменений 5. СОДЕРЖАНИЕ ОСНОВНЫХ НАПРАВЛЕНИЙ РАЗВИТИЯ 5.1. Бизнес-процесс управления заказами в интернет-магазине 5.2. Развитие функционала программы лояльности 5.3. GPS-трекинг доставки отгруженных Заказов 6. Требования к интеграции с информационными системами 7. ТРЕБОВАНИЯ ПО ФУНКЦИОНАЛЬНОСТИ ИНТЕРНЕТ-МАГАЗИНА 7.1. Общие требования: 7.2. Требования к эргономике и технической эстетике 7.3. Требования к масштабированию 7.4. СОДЕРЖАНИЕ ОСНОВНЫХ НАПРАВЛЕНИЙ ПРОДАЖ 8. ТРЕБОВАНИЯ К ЛИЦЕНЗИРОВАНИЮ ПО 9. СРОКИ И ЭТАПЫ ПРОЕКТА 9.3. Порядок контроля и приемки 10. ТРЕБОВАНИЯ К ДОКУМЕНТИРОВАНИЮ ПО ПРОЕКТУ 11. ТРЕБОВАНИЯ К ПОТЕНЦИАЛЬНОМУ ПОСТАВЩИКУ 12. ТРЕБОВАНИЯ К СОСТАВУ ПРЕДЛОЖЕНИЯ 3 4 5 5 5 6 7 7 8 11 11 12 12 14 14 14 14 16 16 16 17 18 25 25 25 26 26 31 32 33 34 35 36 2 Термины и определения Термин Заказчик Исполнитель Клиент Значение Публичное акционерное общество «Силовые машины - ЗТЛ, ЛМЗ, Электросила, Энергомашэкспорт» (ПАО «Силовые машины») Организация, выполняющая работы или оказывающая услуги в рамках договорных отношений с ПАО «Силовые машины» Клиент Заказчика Клиентское приложение Информационная система, внедряемая для / личный кабинет автоматизации процессов взаимодействия с клиента ключевыми клиентами, в частности, для развития каналов коммуникации, оптимизации маркетинга и улучшения обслуживания клиентов путём сохранения информации о клиентах и истории взаимоотношений с ними, установления и улучшения бизнес процедур и последующего анализа результатов. 3 Сокращения и обозначения Сокращение ТЗ ТКП ИС УС СУБД GPS ОГК ТГК ЗИП Наименование Техническое задание Технико-коммерческое предложение Информационная система Управляющий совет проекта Система управления базой данных Global Positioning System (система глобального позиционирования) Оптовые генерирующие компании Территориальные генерирующие компании Запасные части, инструменты и принадлежности 4 1. ОБЩИЕ СВЕДЕНИЯ О РЕШЕНИИ Настоящее техническое задание (далее – ТЗ) определяет функциональные и технические требования на разработку дополнительного функционала клиентского приложения «Личный кабинет клиента ПАО «Силовые машины», развернутого на платформе bpm’online (Creatio) и интернет-магазина (далее – клиентское приложение). 1.1.Наименование решения Полное наименование: Клиентское приложение «Личный кабинет клиента и интернет-магазин ПАО «Силовые машины»». Краткое наименование: Клиентское приложение. 1.2.Платформа для реализации решения На серверах Заказчика в настоящее время развернута информационная система на базе bpm’online sales («Террасофт», версия 7.14.4.1046) – Клиентский портал. Система в настоящее время позволяет: - предоставлять и управлять доступом работникам Клиентов Заказчика; - создавать карточки контрагентов, контактов, договоров, проектов, статей базы знаний, новостей; - через интеграционное решение загружать в систему контрагентов (SAP) и контакты сотрудников Заказчика (Active Directory) - сопровождать функционирование программы лояльности – рассчитывать и накапливать баллы программы лояльности по формуле на основании поступающих платежей по проектам; создавать и сопровождать обработку заявки на списание баллов программы лояльности на сертификаты партнеров, благотворительность, скидки; создавать записи об обеспечении списаний начислениями по требованиям ведения учета (биллинг); вести каталог сертификатов партнеров; - создавать разного вида обращения и обрабатывать их. 5 - создавать страницы итогов в разделах, управлять доступом к ним. Дополнительная демонстрация функциональности может быть произведена по запросу без демонстрации исходного кода. 1.3.Сведения о Заказчике и Исполнителе Заказчик: Публичное акционерное общество «Силовые машины - ЗТЛ, ЛМЗ, Электросила, Энергомашэкспорт» (ПАО «Силовые машины»); Исполнитель: Организация, выполняющая работы / оказывающая услуги в рамках договорных отношений с ПАО «Силовые машины» по разработке клиентского приложения. 1.4.Внутренние границы проекта Подразделения Сбытового блока ПАО «Силовые машины» (г. СанктПетербург) – около 50 внутренних пользователей (для оценки). Программное решение не должно иметь ограничений по количеству пользователей и должно позволять масштабирование клиентского приложения на все сбытовые подразделения Заказчика до 6 дивизионов с расширением числа внутренних пользователей до 200 сотрудников. 1.5.Внешние границы проекта Ключевые клиенты ПАО «Силовые машины». ИТОГО: 300 внешних пользователей (для оценки). Программное решение не должно иметь ограничений и должно позволять масштабирование клиентского приложения на всех клиентов Заказчика с числом внешних пользователей 1000 сотрудников и более. Интернет-магазин должен являться открытой площадкой, с неограниченным количеством регистрируемых пользователей. Регистрация на сайте интернет-магазина может предполагать ручную проверку документов для создания учетной записи. 6 2. ЦЕЛИ, ЗАДАЧИ И НАЗНАЧЕНИЕ РЕШЕНИЯ 2.1.Цели и задачи 1. Развитие цифровых клиентских сервисов Заказчика в виде портала и мобильного приложения на платформе bpm’online. 2. Развитие существующей системы в части разработки и внедрения дополнительных бизнес-правил, позволяющих ускорить и упростить, максимально автоматизировать работу в системе. 3. Создание дополнительных интеграционных потоков в и из ИС Заказчика для сокращения ручного ввода в систему. 4. Развитие существующей системы в части настройки конструктора печатных форм и подключения к данным информационной системы через канал OData в целях анализа информации, построения аналитических моделей. 5. Разработка дополнительного функционала: a. Интернет-магазина запасных частей и услуг с возможностью создания заявки на технико-коммерческое предложение Заказчика (далее – ТКП), настройку бизнес-процесса подготовки ТКП; b. Процесс обработки заказов, поступивших из интернет-магазина; c. Возможности отслеживания заказов для клиента заказчика – GPS- трекинг доставки; Для достижения заявленной цели в рамках проекта должны быть решены следующие задачи: - произвести обследование бизнес-процессов и информационных систем Заказчика; - Произвести концептуальное проектирование, провести демонстрацию Заказчику и согласование с заказчиком; - выполнить разработку дополнительного функционала клиентского приложения в соответствии с техническим заданием и согласованным функциональным дизайном; 7 разработать необходимые и согласованные на этапе - концептуального проектирования отчеты; выполнить функциональное тестирование настроенной - функциональности клиентского приложения с учетом особенностей сценариев использования, архитектуры и инфраструктуры Заказчика; разработать необходимые процедуры для организации выгрузки, - выверки, загрузки в личный кабинет клиента и интернет-магазин необходимых справочников, исторических данных, документов и остатков, проверки корректности переноса данных (включая методики сбора и представления данных для загрузки, шаблоны для загрузки данных); провести обучение ключевых пользователей клиентского - приложения, разработать пользовательские инструкции; разработать детальный ресурсный план реализации проекта по - подготовке, настройке и переходу дополнительного функционала клиентского приложения в промышленную эксплуатацию; подготовить пакет проектной и эксплуатационной документации. - 2.2. Назначение В рамках развития Клиентского приложения необходимо осуществить доработку функционала в целях уменьшения количества операций, осуществляемых персоналом Заказчика в системе вручную; а также создать, в дополнение к существующим, следующие информационные блоки бизнеспроцессов взаимодействия с клиентами: 1. Интернет-магазин запасных частей, услуг, документации с каталогом продукции, указанием цены и плановых сроков производства Заказчика; 2. Создание рабочего места сбытового менеджера для сопровождения заказов интернет-магазина. 3. Настройка дополнительных интеграционных потоков для автоматизации работы сбытовых менеджеров; 8 История договорных отношений, доступ к сканам договоров и 4. первичной бухгалтерской документации по ним. GPS-трекинг доставки произведенных и отгруженных заказов 5. клиента. Для достижения заявленной цели в рамках проекта должны быть решены следующие задачи: разработать концептуальный проект и проектные решения, с учетом существующих бизнес-процессов Заказчика, включая, но не ограничиваясь: d. e. f. g. h. i. Процесс управления продажами; Процесс подготовки технико-коммерческих предложений; Процессы уже реализованные на платформе Заказчика Процессы подготовки и согласования договоров. Процессы документационного оборота. Существующие информационные системы Заказчика, обеспечивающие работу бизнес-процессов. разработать детальное решение обеспечению информационных потоков клиентского приложения в и из Информационных систем Заказчика. Описание информационных потоков приведено в п 3.1, 3.5; выполнить разработку функционала клиентского приложения и интеграцию со Информационными системами Заказчика в соответствии с техническим заданием и согласованным концептуальным проектом; разработать необходимые и согласованные на этапе концептуального проектирования отчеты; выполнить функциональное и интеграционное тестирование (по критичным в части производительности бизнес-процессам), настроенной функциональности клиентского приложения с учетом особенностей сценариев использования, архитектуры и инфраструктуры Заказчика; разработать необходимые процедуры для организации выгрузки, выверки, загрузки в клиентское приложение необходимых справочников, исторических данных, документов и остатков, проверки корректности переноса данных (включая методики сбора и представления данных для загрузки, шаблоны для загрузки данных); провести обучение ключевых пользователей клиентского приложения, разработать пользовательские инструкции. Оценку стоимости обучения пользователей привязать к их количеству (оценить стоимость человеко-курса обучения для групп разного количества пользователей в общей совокупности не менее 50 человек); - 9 разработать детальный ресурсный план реализации проекта по подготовке, настройке и переходу клиентского приложения в промышленную эксплуатацию; подготовить пакет проектной и эксплуатационной документации. - 10 ТРЕБОВАНИЯ К АРХИТЕКТУРЕ РЕШЕНИЯ 3. 3.1. Схема целевой архитектуры Существу Контур разработки ющие ИС Потоки SAP ERP Контраг енты -> Проекты Клиент -> Платежи ->; <- карта Личный Основной договора кабинет функционал -> клиента сайта: сервер <- Корпорат Новости ивный -> Клиент Рабочее Интернет- место магазин; сбытового менеджера сайт САПР КТИ Прайслист запасных Структура изделия -> Себестои мость запасных частей Каталоги, сервисы, Интерфейс создание управлени заказов Front-Сайт Почтовый Собрания Регистрация на сайте CУД- Firewall SAP OT Клиент я каталогом Мобильное и 3D- приложение моделями частей Active Directory Контакт ы -> Клиент 11 3.2.Требования к мобильному приложению Мобильное приложение клиентского приложения настроено и доступно для пользователей смартфонов и планшетов на операционных системах iOS и Android. Необходима настройка дополнительного функционала мобильного приложения: Настройка push-уведомлений при создании обращения клиентом Настройка push-уведомлений при ответе на обращение клиента и изменении статуса. Настройка push-уведомлений при создании заказа клиентом (на устройстве сотрудника, ответственного за заказчика) Настройка push-уведомлений при изменении статуса заказа (на устройстве Клиента). В случае решения реализации GPS трекинга – настройка раздела с просмотром доставки заказов на карте; Настройка разделов системы в соответствии с полной браузерной версии. Оценка рисков и стоимости полного брендирования мобильного приложения и отдельного размещения в Appstore / AndroidMarket. 3.3.Требования к эргономике и технической эстетике Интерфейс пользователя и администраторов клиентского приложения должен быть организован таким образом, чтобы исключить полосы прокрутки при работе с формами ввода и отображения данных. В клиентском приложении должна быть обеспечена возможность изменения стандартных представлений отображения данных, с возможностью их сохранения для дальнейшего использования. В клиентском приложении должен быть эргономичный пользовательский веб-интерфейс и интерфейс мобильного приложения, оформленный и брендированный в корпоративные цвета ПАО «Силовые машины». 12 Интерфейс пользователя клиентского приложения должен быть простым, информативным, без усложненных конструкций. Прочие требования к эргономике и технической эстетике должны быть уточнены на этапе концептуального проектирования системы и согласованы с заказчиком в виде дизайн-проекта. Настройки визуальных элементов интерфейса, такие как цвета, размеры, формы, положение объектов, шрифты, изображения в финальном продукте должны быть доступны к настройке, изменению Заказчиком. 13 4. ФУНКЦИОНАЛЬНЫЕ ТРЕБОВАНИЯ К РЕШЕНИЮ 4.1.Общие требования 1. Клиентское приложение должно обеспечивать соответствие актуальным требованиям Законодательства РФ, применимым к Клиентскому приложению на момент начала проектных работ. 2. Клиентское приложение должно обеспечивать защиту от несанкционированного доступа к данным и разграничивать доступ пользователей к информации. 3. Клиентское приложение должно позволять перестраивать организационные и функциональные роли пользователей в случае изменения организационной структуры, состава должностей средствами Администрирования. 4. Архитектура клиентского приложения и его реализация должны обеспечивать возможность дальнейшего расширения функционала. 5. Разработка клиентского приложения должна производиться в соответствии с методическими рекомендациями вендора ПО. 6. В клиентском приложении должна быть предусмотрена авторизация пользователей по персональному логину и паролю, обеспечивающая доступ ко всем сервисам клиентского приложения. 7. Прочие общие требования должны быть уточнены Исполнителем на этапе концептуального проектирования решения. 4.2.Требования к ролям и полномочиям Клиентское приложение должно позволять Заказчику гибко настраивать права доступа пользователей к отдельным элементам системы, объектам, записям разделов и определенным полям записи на уровне чтения, изменения, записи, удаления. 4.3.Требования к внесению функциональных изменений Конфигурация доработок клиентского приложения и интернет-магазина должна иметь три уровня сложности: 1. Конфигурация настроек без изменения программного кода: используется стандартный функционал решения без написания программного кода. Настройки выполняются через интерфейсы администрирования решения. 2. Конфигурация функционала с изменением программного кода: программный код используется для расширения стандартного функционала бизнес-объектов клиентского приложения в части расширения логики стандартных активностей и добавления новых активностей в целях расширения логики Workflow. Выполняется через студию разработки. 14 3. Разработка: создание полностью нового функционала клиентского приложения, не заложенного в стандартную поставку и не достижимого путем конфигурации без написания программного кода или конфигурации с написанием программного кода (типы 1 и 2). Выполняется через студию разработки. Каждое требование/процесс должен быть классифицирован по данной градации в рамках формирования концептуального проекта и/или обсуждения запросов на изменение. Для всей настроенной функциональности должны быть сформированы технические описания и пояснения. Предоставлены инструкции по безопасному для остального функционала внесению изменений. Настройки логики бизнес процессов, формул расчетов, констант, системные настройки, должны быть доступны заказчику. 15 СОДЕРЖАНИЕ ОСНОВНЫХ НАПРАВЛЕНИЙ РАЗВИТИЯ 5. 5.1.Развитие автоматизации Настройка и создание бизнес-процессов для автоматического формирования печатных документов, ускорения передачи информации между пользователями, маршрутизации обращений. Цели автоматизации: - уменьшение количества операций в системе, производимых вручную, в том числе путем настройки интеграционных потоков с ИС Заказчика; - повышение скорости реагирования на запросы клиентов Заказчика. Дополнительные предложения по автоматизации Исполнитель должен уточнить у пользователей системы в ходе концептуального проектирования. 5.2.Бизнес-процесс управления заказами в интернет-магазине Настройка и тестирование бизнес-процесса Заказчика по управлению продажами в интернет-магазине. Цели доработки: - Обеспечение получения заказов, поступивших через интернет-магазин, назначения ответственного менеджера; - Использование данных Заказа, в том числе автоматически сформированных договоров, спецификаций в исполнении проекта; - Автоматическое формирование документов для запуска в производство; - Обеспечение отслеживаемости выполнения заказа Клиентом (по стадиям – принят в обработку, запуск в производство, производство, отгрузка, доставка, выполнен). 5.3.Развитие функционала программы лояльности Развитие функционала программы лояльности должно обеспечить: - Сегментирование клиентов по уровням лояльности (в настоящее время уровень один); - Создание бизнес-правил по автоматическому присвоению уровня лояльности; - Создание дополнительных бизнес-правил по расчету бонусных баллов программы лояльности (в зависимости от уровня лояльности клиента Заказчика); 16 - Создание дополнительных уровней доступа к использованию контента Клиентского приложения Детальные требования по настройке бизнес-правил будут уточнены Исполнителем в ходе осуществления обследования бизнес-процессов. 5.4.GPS-трекинг доставки отгруженных Заказов Реализация данного функционала подразумевает, что Клиенту заказчика, использующему Клиентское приложение, должна быть предоставлена возможность мониторинга текущей геопозиции каждого отгруженного ему Заказа. Исполнитель на этапе концептуального дизайна должен предложить Заказчику механизм отслеживания доставки отгруженных заказов с оценкой стоимости, включающей все необходимое программное обеспечение, консультационные услуги, аппаратные средства и устройства с предоставлением КП поставщиков, расчет стоимости мониторинга 1 заказа, описание технических ограничений. Решение о реализации данного функционала будет принято при рассмотрении предложения Исполнителя. 17 6. Требования к интеграции с информационными системами При интеграции будут использоваться информационные потоки: Проекты: (см. Таблица№1) следующие основные Таблица 1 Характеристика Значение Цель интеграции Интеграция проводится с целью синхронизации записей о проектах, осуществляемых Заказчиком для его Клиентов. (Проекты в настоящее время создаются в SAP ERP, чтобы не вводить информацию о проекте повторно для отображения клиенту в Клиентском приложении необходима интеграция) Мастер-система SAP ERP Направление SAP ERP > Клиентское приложение интеграции Регулярность В фоновом режиме интеграции 1 раз в сутки (00:00 – 06:00) и по запросу администратора Количество До 20 атрибутов Ограничения на 1. В качестве ключа интеграции поток применяется одно поле типа Guid • Платежи: (Таблица №2) Таблица 2 Характеристика Значение Цель интеграции Интеграция проводится с целью синхронизации информации о платежах, поступивших в рамках проектов Заказчика, для последующей их обработки и начисления бонусных баллов системы лояльности. Мастер-система SAP ERP Направление SAP ERP > Клиентское приложение интеграции Регулярность В фоновом режиме интеграции 1 раз в сутки (00:00 – 06:00) и по запросу администратора Количество Не менее 30-ти атрибутов 18 Характеристика Значение Ограничения на Первичный импорт не производится поток • • Программа лояльности (баллы программы лояльности): (Таблица №3) Таблица 3 Характеристика Значение Цель интеграции Интеграция проводится с целью автоматизации учета в SAP ERP/ подразумевается передача информации о начислениях и списаниях баллов. Мастер-система Направление интеграции Регулярность интеграции Количество атрибутов Ограничения на поток Клиентское приложение (для расчета баллов) Клиентское приложение > SAP ERP В фоновом режиме 1 раз в сутки (00:00 – 06:00) и по запросу администратора Не менее 40 Первичный импорт не производится • Структура изделия: (Таблица №4) Таблица 4 Характеристика Значение Цель интеграции Интеграция проводится с целью первичной загрузки и обновления структуры изделия в соответствии с конструкторской документацией для наполнения каталога запасных частей интернет-магазина номенклатурой. Мастер-система САПР КТИ Направление САПР КТИ > Клиентское приложение интеграции Регулярность В фоновом режиме интеграции 1 раз в сутки (00:00 – 06:00) и по запросу администратора Количество Не менее -ти атрибутов Объем потока 1 изделие – до 10 000 элементов. 19 • Событие в календаре: (Таблица №5) Таблица 5 Характеристика Значение Цель интеграции Интеграция проводится для дублирования календарей MS Outlook и клиентского приложения (для автоматического добавления всех созданных в клиентском приложении активностей в календарь Outlook) Мастер-система Клиентское приложение (создание активностей) Направление Клиентское приложение > MS Outlook интеграции Регулярность Запуск обновления при создании события в интеграции календаре Количество Не менее 10 атрибутов Ограничения на Первичный импорт не производится поток Новости: (Таблица №6) Таблица 6 Характеристика Значение Цель интеграции При добавлении Новости на корпоративном сайте, она автоматически попадает в Клиентское приложение. Мастер-система Направление интеграции Регулярность интеграции Количество атрибутов Ограничения на поток Интернет-сайт Интернет-сайт > Клиентское приложение В фоновом режиме 1 раз в сутки (00:00 – 06:00) и по запросу администратора Не менее 10 Первичный импорт не производится 20 • Договоры: (Таблица №7) Таблица 7 Характеристика Значение Цель интеграции При создании карточки договора определенного контрагента в OpenText, автоматически создается Договор в КП. После передачи подписанного скана в архив, файл договора передается в КП и прикрепляется к соответствующей карточке. В случае подписания дочернего документа, в КП создается отдельная карточка дочернего документа, привязанная к родительскому. Мастер-система SAP OpenText Направление SAP OpenText > Клиентское приложение интеграции Регулярность В фоновом режиме интеграции 1 раз в сутки (00:00 – 06:00) и по запросу администратора Количество Не менее 30 атрибутов Ограничения на Первичный импорт не производится поток • Себестоимость: (Таблица №8) Таблица 8 Характеристика Значение Цель интеграции Интеграция производится для передачи в каталог интернет-магазина сведений о параметрах для расчета себестоимости как отдельных запасных частей, так и общих коэффициентов Мастер-система 3 файла Excel Направление Excel> Клиентское приложение интеграции Регулярность В фоновом режиме интеграции 1 раз в сутки (00:00 – 06:00) и по запросу администратора Количество Не менее 20 атрибутов 21 • Наличие на складе: (Таблица №9) Таблица 9 Характеристика Значение Цель интеграции Интеграция производится для передачи в каталог интернет-магазина сведений о наличии товаров на складе (в случае наличия товаров на складе в каталоге цена должна быть ниже как если бы товар надо было производить). Мастер-система SAP ERP Направление SAP ERP > Клиентское приложение интеграции Регулярность В фоновом режиме интеграции 1 раз в сутки (00:00 – 06:00) и по запросу администратора Количество Не менее 10 атрибутов • Сроки изготовления: (Таблица №10) Таблица 10 Характеристика Значение Цель интеграции Интеграция производится для передачи в каталог интернет-магазина сведений о сроках изготовления отдельных товаров для включения данных условий в автоматически формируемый договор на поставку запасных частей. Мастер-система SAP ERP Направление SAP ERP > Клиентское приложение интеграции Регулярность В фоновом режиме интеграции 1 раз в сутки (00:00 – 06:00) и по запросу администратора Количество Не менее 10 атрибутов 2. Решения о необходимости реализации конкретных интеграционных потоков для каждой смежной системы Заказчика будут приниматься совместно с Исполнителем на этапе концептуального проектирования функционирования клиентского приложения. 3. При проектировании или обновлении интеграционных процессов, должны быть выполнены работы по детальному проектированию и описанию 22 объема и форматов, передаваемых данных между информационными системами. Принятые решения по интеграции с клиентским приложением должны быть отражены в виде отдельных проектных решений для каждой информационной системы Заказчика. 4. Каждое интеграционное взаимодействие между системами должно быть проверено в рамках процедуры интеграционного тестирования с подтверждением факта успешной интеграции и обмена данными. 5. Работы по тестированию интеграционных связей между системой и интегрируемыми информационными системами должны быть запланированы в рамках работ по концептуальному проектированию клиентского приложения и учтены в ресурсном плане проекта. 6. Прочие требования (в т. ч. список интегрируемых систем) должны быть предложены Заказчику и уточнены Исполнителем на этапе концептуального проектирования. 7. При проектировании или обновлении интеграционных процессов, должны быть выполнены работы по детальному проектированию и описанию объема и форматов, передаваемых данных между информационными системами. Принятые решения по интеграции с клиентским приложением должны быть отражены в виде отдельных проектных решений для каждой информационной системы Заказчика. 8. Каждое интеграционное взаимодействие между системами должно быть проверено в рамках процедуры интеграционного тестирования с подтверждением факта успешной интеграции и обмена данными. 9. Работы по тестированию интеграционных связей между системой и интегрируемыми информационными системами должны быть запланированы в рамках работ по концептуальному проектированию клиентского приложения и учтены в ресурсном плане проекта. 10. Прочие требования (в т. ч. список интегрируемых систем) должны быть предложены Заказчику и уточнены Исполнителем на этапе концептуального проектирования. 11. Должна быть разработана инструкция по удалению / изменению / добавлению атрибутов и маппинга интеграции. Должна быть настроена 23 возможность управления периодичностью интеграции по каждому потоку в системных настройках bpm’online. 24 7. ТРЕБОВАНИЯ ПО ФУНКЦИОНАЛЬНОСТИ ИНТЕРНЕТ- МАГАЗИНА 7.1. Общие требования: Интернет-магазин (сайт) должен удовлетворять следующим требованиям: Сайт должен быть удобен для использования как со стороны Заказчика, так и со стороны покупателей его продукции, удовлетворять требованиям эргономики; Сайт должен обеспечивать бесперебойный контакт клиентов и сбытовых менеджеров, действия клиентов должны быть доступны для анализа; Сайт должен адаптироваться к просмотру на разных устройствах; Сайт должен позволять производить выгрузку сгенерированных клиентами данных для анализа; Внешний вид сайта должен удовлетворять бренду Заказчика; На сайте должны быть установлены счетчики посещаемости страниц и действий пользователей; Сайт должен удовлетворять требованиям законодательства РФ в сфере интернет-торговли; Сайт должен иметь доступный интерфейс настройки внешнего вида (замены изображений, цветов блоков, цветов шрифтов, типов шрифтов, расположения блоков); Сайт должен предусматривать возможность масштабирования – добавления новых каталогов, форматов типовых документов, поскольку планируется подключение других поставщиков к продажам через сайт. Сайт должен быть доступен из Личного электронного кабинета и из сети Интернет; Сайт должен удовлетворять требованиям корпоративной информационной безопасности. 7.2. Требования к эргономике и технической эстетике Интерфейс пользователя и администраторов сайта быть организован таким образом, чтобы исключить полосы прокрутки при работе с формами ввода и отображения данных. Интерфейс пользователя сайта должен быть простым, информативным, без усложненных конструкций. 25 Прочие требования к эргономике и технической эстетике сайта интернетмагазина должны быть уточнены на этапе концептуального проектирования системы. 7.3. Требования к масштабированию Доступ к отдельным каталогам интернет-магазина должен быть только у авторизованных пользователей. Авторизация пользователей подразумевает регистрацию на сайте интернет-магазина с указанием персональных данных физических лиц, согласие на их хранение, обработку, а также реквизитов юридических лиц, от имени которых будет действовать пользователь. Регистрация новых пользователей не должна подразумевать платное лицензирование. 7.4. СОДЕРЖАНИЕ ОСНОВНЫХ НАПРАВЛЕНИЙ ПРОДАЖ Управление функциональностью интернет-магазина (удалить, скрыть функциональность) и каталогом должно быть доступно для заказчика средствами администрирования. 7.4.1. Запасные части Заказчик производит сложное, многокомпонентное оборудование для электростанций – турбины, генераторы, трансформаторы, системы автоматического управления и т.д., многие из моделей уникальны, для каждой единицы изделия есть свой индивидуальный набор запасных частей и деталей. Исполнителю необходимо в первую очередь сформулировать требования к структуре каталога Заказчика, предоставить шаблон для наполнения и формирования данных для загрузки в интернет-магазин для получения необходимого отображения и функциональности. Т.к. номенклатура изделий Заказчика измеряется десятками тысяч, Исполнителю необходимо разработать решение по управлению каталогом, в т. ч. регулирование цен на группы наименований и отдельные позиции в специальном интерфейсе управления каталогом. Исполнителю в ходе концептуального проектирования необходимо сформировать предложения по 26 интеграции с ИС Заказчика для автоматического наполнения, обновления, дополнения каталога, включая библиотеки изображений, 3D-моделей, данных о структуре изделий. Реализованные ориентиры по настройке интернет-магазина запасных частей – emex.ru, exist.ru. Каждое выпущенное изделие имеет заводской идентификационный номер, используя который, клиент находит выборку запасных частей каталога именно для установленного у него оборудования. Исполнителем должен быть разработан механизм шифрования обозначений продуктов Заказчика (номеров чертежей) в артикулы, публикуемые в интернет-магазине, с возможностью обратной дешифровки для использования сотрудниками Заказчика при проработке заказов. Исполнитель должен реализовать в системе возможность графического представления искомых деталей в виде динамических изображений. Для поиска конкретных деталей, клиент должен «раскрывать» уровни детализации изделия. На последнем уровне детализации должно появиться приближенное графическое представление узла. При наведении пользователем системы на само изображение должны появляться подписи входящих в него деталей. Рядом с каждым элементом каталога отображается цена. Для элементов, находящихся на не последнем уровне детализации должна быть предусмотрена опция отправки запроса на оценку стоимости. Для запчастей, для которых указана цена, должна быть настроена функция «Добавить в Корзину», в которой далее настраивается количество для заказа каждого добавленного наименования. На странице корзины должны присутствовать опции настройки заказа – деталей доставки, даты потребности и др. В случае, если не все выбранные позиции оценены, запрос на расчет стоимости должен направляться в проработку сбытовому менеджеру. Исполнитель должен передать Заказчику приложение, позволяющее реализовать требуемые графические представления основываясь на 3D моделях 27 в общедоступных форматах и обучить сотрудников Заказчика для самостоятельного занесения в интернет-магазин. Графическое представление должно соответствовать степени детализации согласно Приложению А. Исполнитель обязуется самостоятельно наполнить каталог интернетмагазина и согласовать с Заказчиком формат представления по одному проекту: паровой турбины, турбогенератору, гидротурбины, гидрогенератору и котельному оборудованию. В целях управления номенклатурой Исполнитель создает специальный интерфейс управления каталогом, в котором сотрудники Заказчика смогут управлять коэффициентами для расчета цен в интернет-магазине, присваивать каждому отдельному товару или выбранной группе товаров категории для использования того или иного коэффициента. После заполнения деталей заказа интернет-магазин должен формировать типовой договор, платежные документы и направлять их Заказчику и Клиенту. Оформленный заказ означает согласие Клиента с условиями договора. После оформления заказ автоматически направляется на адрес Заказчика, где сбытовым менеджером производятся необходимые действия по запуску заказа в производство. Клиенту через сайт после авторизации должна быть доступна история оформленных заказов, с указанием дат, сумм, состава, контактов Заказчика, архива документов по заказу. 7.4.2. Услуги шеф-инженеров В функционале портала должен быть реализован алгоритм расчета стоимости услуг шеф-персонала заказчика (математическая формула, часть переменных которой обновляются Заказчиком ежеквартально (параметры расчета, действующие на все заявки в течение определенного времени), другая часть переменных вводится системой автоматически (зависит от атрибутов Клиента Заказчика (месторасположение, реквизиты и др.), третья часть 28 переменных заполняется клиентом Заказчика каждый раз при расчете стоимости). Т.к. стоимость услуг изменяется во времени, все переменные для расчета стоимости услуг должны доступно изменяться (без применения кода). Расчет стоимости услуг производится по мере заполнения формы, в конце заполнения всех обязательных полей формы должна появляться опция «Добавить в корзину». Дальнейшие действия аналогичны работе «Корзины» при заказе запасных частей. Отдельный кейс – аварийный случай, в таком случае, для скорейшей отправки персонала на станцию формируется гарантийное письмо от Клиента Заказчику с принятием обязательств по оплате услуг. Для заказчика должен быть реализован и описан алгоритм внесения изменений в формулу расчета, изменения значений и количества констант. 7.4.3. Разработка документации. Заказчик по запросу клиента может разрабатывать специальные документы – инструкции по ремонту, обучающие материалы и др. Для продажи такого вида услуг должен быть настроен отдельный каталог, содержащий наименования документов, доступных для заказа. Для заказа документов клиенту необходимо выбрать документ из каталога, заполнить уточняющую форму и добавить в «Корзину». Дальнейшие действия аналогичны работе «Корзины» при заказе запасных частей. 7.4.4. GPS-трекинг доставки отгруженных Заказов Реализация данного функционала подразумевает, что Клиенту заказчика, использующему Клиентское приложение, должна быть предоставлена возможность мониторинга текущей геопозиции каждого отгруженного ему Заказа. Исполнитель на этапе концептуального дизайна должен предложить Заказчику механизм отслеживания доставки отгруженных заказов с оценкой 29 стоимости, включающей все необходимое программное обеспечение, консультационные услуги, аппаратные средства и устройства с предоставлением КП поставщиков, расчет стоимости мониторинга 1 заказа, описание технических ограничений. Решение о реализации данного функционала будет принято при рассмотрении предложения Исполнителя. 30 8. ТРЕБОВАНИЯ К ЛИЦЕНЗИРОВАНИЮ ПО Для работы Личного кабинета клиента в настоящее время используется: 10 лицензий bpm’online sales enterprise on-site для внутренних пользователей; 50 лицензий bpm’online sales commerce on-site для внешних пользователей. Планируется расширение количества пользователей на: 50 внутренних пользователей; 300 внешних пользователей. Для работы интернет-магазина лицензии требоваться не должны. Потенциальный исполнитель включает стоимость лицензий в КП. 31 9. СРОКИ И ЭТАПЫ ПРОЕКТА Вариант 1 - Итерации Работы по развитию Клиентского приложения Заказчика должны проходить итерациями по 1 календарному месяцу. Каждый месяц в установленный Заказчиком срок должен происходить релиз обновления Клиентского приложения сначала в тестовой, а после согласования – и в продуктивной среде. Каждая итерация развития должна включать следующие этапы: обследование процессов, сбор и систематизация пожеланий пользователей; формулировка целей текущей итерации; формирование пула задач для проработки в текущей итерации; приоритизация задач заключение дополнительного соглашения к договору; выполнение настроек на тестовой среде и тестирование с привлечением пользователей; Демонстрация выполненных доработок, согласование релиза в продуктивной среде. Вариант 2 - Традиционный Работы по развитию Клиентского приложения Заказчика должны проходить поэтапно: 1. Обследование – интервьюирование пользователей, составление подробного описания целевого состояния. 2. Настройка на тестовой среде 3. Демонстрация и тестирование 4. Доработка и переход в эксплуатацию. 32 9.1.Основные этапы Этап 1. Концептуальное проектирование Результат выполнения Согласованный функциональный дизайн, прототип решения, дизайн-проект. 2. Разворачивание инфраструктуры Все необходимое для работы решения программное и аппаратное обеспечение установлено и находится в распоряжении Заказчика Все настройки, согласованные в функциональном дизайне осуществлены и доступны к тестированию пользователю Сформированы протоколы тестирования, замечания Заказчика по результатам тестирования устранены Произведено обучение пользователей, подтверждение – явочный лист. Предоставлены пользовательские инструкции. Приемка системы пользователями и руководством 3. Реализация и настройка 4. Тестирование и доработки 5. Обучение пользователей 6. Запуск в эксплуатацию 9.2.Состав и содержание работ по этапам Состав и содержание работ по проекту внедрения Клиентского приложения будут согласованы и определены в договоре. 9.3.Порядок контроля и приемки В случае осуществления Исполнителем разработки без привязки к платформе (в части интернет-магазина), реализованный продукт переходит в собственность Заказчика, включая исходные коды. Ожидаемые результаты выполнения работ и отчетные документы по этапам будут согласованы и определены в договоре. Этап 1 «Концептуальное проектирование» выполняется на условиях авансирования. В случае отказа Заказчиком в приемке результатов этапа, сумма аванса должна быть полностью возмещена Исполнителем. 33 10. ТРЕБОВАНИЯ К ДОКУМЕНТИРОВАНИЮ ПО ПРОЕКТУ Документация по проекту должна быть выполнена на русском языке, за исключением официальных наименований используемого программного и технического обеспечения, а также системных сообщений, для которых отсутствует перевод на русский язык, выполненный разработчиком программного обеспечения. Исполнитель должен представить один комплект согласованных и утвержденных документов по проекту в распечатанном и электронном виде. 34 11. ТРЕБОВАНИЯ К ПОТЕНЦИАЛЬНОМУ ПОСТАВЩИКУ Наличие успешного опыта реализации проектов (минимум 2 проекта) по внедрению Клиентского приложения, принятых Заказчиком и находящихся в промышленной эксплуатации за последние 2 года. Потенциальный поставщик предоставляет на конкурс резюме специалистов, которые будут задействованы на проекте, с указанием стажа работы, должности, квалификации и перечня проектов, в которых участвовал специалист. 35 12. ТРЕБОВАНИЯ К СОСТАВУ ПРЕДЛОЖЕНИЯ Предложение потенциального поставщика должно содержать: оценку стоимости необходимого ПО, лицензий исходя из описанных в настоящем техническом задании требований расчет полной стоимости владения ПО на 5 лет, включая все возможные варианты лицензирования, техническую поддержку; детализацию оценки разрабатываемого функционала (оценку настройки отдельных функциональных блоков, интеграционных решений, визуальных компонентов, страниц, бизнес-процессов оценку работ по подготовке документации, обучению пользователей); Референц-лист выполненных проектов с демонстрационными материалами; Прототип Клиентского приложения, выполненный максимально приближенно к требованиям настоящего технического задания позволяющий оценить возможности исполнителя, предлагаемого решения. 36 Приложение А. Визуализация каталога 38 39
