Вы находитесь на странице: 1из 13

Раздел IV Документации открытого 

 
запроса предложений в электронной форме на   
право заключения договора на выполнение   
работ (оказание услуг) по разработке ПО  
«Мобильное приложение сотрудника»  

Спецификация  

Мобильное приложение для сотрудников   


1. ​
Введение  
1.1. ​
Наименование программы  
Наименование программного обеспечения: 
Мобильное приложение Сотрудника  

1.2. Назначение и область применения  


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

2. Требования к программе  

2.1. Общие требования  


2.1.1 Платформа клиентских частей приложения:  

∙​
iOS - версия 9 и выше   
∙​
Android - версия 4.4 и выше  
2.1.2 Web-интерфейс для back-end должен 
работать на IE v11+ и Google Chrome (последняя 
версия) внутри и вне периметра 
корпоративной сети.  
2.1.3 Мобильное устройство должно 
поддерживать портретную и ландшафтную 
ориентацию.  
2.1.4 Логирование действий пользователя – 
с целью выявить (есть возможность 
использовать Google Analytics, Yandex AppMetrica):  
2.1.4.1 Какими функциями пользуются чаще.  
2.1.4.2 Какие слова/запросы не может обработать 
чат бот.  

2.2. Требования к функциональным 


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

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

2.2.1.1. Первый этап авторизации:


При первом запуске ПО пользователь 
2.2.1.1.1 ​
должен пройти регистрацию. ​2.2.1.1.2 
Регистрация проводится по E-mail или 
номеру мобильного телефона. 
Программное обеспечение должно 
2.2.1.1.3 ​
осуществлять поиск и проверку введенного 
E-mail или Телефона в системе, содержащей 
данные сотрудников организации и в случае 
успеха высылает SMS с кодом на телефон 
Сотрудника.  
После успешного ввода кода-SMS 
2.2.1.1.4 ​
Приложение запрашивает у Сотрудника 
ПИН-код для дальнейшего входа в Приложение.  
Код должен генерироваться в 
2.2.1.1.5 ​
соответствии с требованиями ИБ Заказчика 
для исключения возможности использования 
его на другом устройстве. После успешного 
прохождения первого этапа авторизации 
сотруднику ПО предоставляет минимальные 
права доступа в систему (Согласование 
объема минимального доступа будет 
определено на этапе проектирования).  
Для использования всех возможностей 
Приложения Пользователю необходимо 
пройти 2 этап авторизации.  

2.2.1.2. Второй этап авторизации:  


Система должна обеспечить запрос 
подтверждения пользователя о готовности 
пройти второй этап авторизации  
Приложение должно обеспечивать следующий 
функционал:  
2.2.1.2.1. Вывод краткой инструкции на экран 
пользователю.  
2.2.1.2.2. Формирование и отправка письма на E-mail 
Пользователя. Письмо должно содержать 
инструкцию по прохождению второго этапа 
авторизации.  
2.2.1.2.3. Приложение генерирует случайный код 
для сотрудника с учетом идентификатора 
устройства пользователя и передаёт его на 
корпоративный web-Портал организации в 
Личный кабинет пользователя.  
2.2.1.2.4. Введение кода-активации в Приложение.  
2.2.1.2.5. Код активации не должен быть статическим 
(должен зависеть времени).   

В случае успешного ввода кода сотрудник 


получает доступ к полному функционалу 
Приложения.  

2.2.2. Предоставление контента для сотрудников  

2.2.2.1. Обучающий раздел пользователя 


приложения  
ПО должно содержать вводный раздел, 
который запускается при первой 
установке приложения. Также необходимо 
обеспечить возможность вызова из 
приложения. Раздел должен содержать 
следующую информацию:  
∙​
Вступительная часть. Вступительная часть 
должна содержать контент в формате 
текстовой или видеоинформации.  
∙​
Инструкция по пользованию 
приложением. Раздел с инструкциями 
должен содержать контент в формате 
текстовой или видеоинформации.  
∙​
Должна быть реализована возможность 
редактирования количества и состава 
данных экранов из back-end приложения.  
∙​
Необходимо обеспечить поддержку анимации.  
Переход между слайдами должно быть 
реализовано через смахивание (swipe) или 
кнопки “вперёд” и “назад”.  
Содержание контента обучающего раздела 
должно модерироваться в зависимости от 
таргетинга пользователя. Должна быть 
возможность создавать более одной 
презентации с целью таргетинга по 
Организационной структуре компании (т.е. для 
разных пользователей могут быть показаны 
разные экраны при первом запуске – в 
зависимости от их геолокации и/или 
функциональной вертикали). 
2.2.2.2. Контент по адаптации  
В ПО необходимо обеспечить наличие 
вводного раздела, в котором будет 
публиковаться информация от Блока 
управления талантами.  
Раздел должен содержать контент в формате 
ссылок, текстовой или видеоинформации, а 
так же развернутую анимацию в формате 
интерактивной html-страницы в стиле Wikipedia.  

2.2.3. Функционал “Профиль сотрудника”  

2.2.3.1. Профиль сотрудника   


2.2.3.1.1. Для автоматического заполнения 
данных профиля сотрудника в мобильном 
приложении необходимо обеспечить 
интеграцию с учетной системой для 
обеспечения импорта данных.  
2.2.3.1.2. Для предоставления актуальной 
информации необходимо обеспечить 
интеграцию с системой Success Factors.  
2.2.3.1.3. Для предоставления актуальной 
информации необходимо обеспечить 
интеграцию с web-Портал компании.  
2.2.3.1.4. Обновления данных от R12 и web-Портала 
компании будут происходить периодично 
(например, 1 раз в день) и Приложение должно 
их с этим же периодом забирать.  
2.2.3.1.5. В случае изменения Пользователем 
данных своего профиля, Приложение должно 
обеспечить передачу изменений в систему 
источник.  
Требования по составу информации в 
Профиле пользователя представлена в 
приложении 1.  

2.2.3.2. Просмотр профилей других сотрудников   


2.2.3.2.1. В ПО необходимо отображать 
доступные для просмотра других 
пользователей поля профиля.  
2.2.3.2.2. Система должна обеспечивать 
возможность вызова на корпоративный номер 
при нажатии на контакт.  
2.2.3.3. Возможность написать тег коллегам  
2.2.3.3.1. ПО должно обеспечивать 
возможность создать тег в профиле 
коллег. В качестве API необходимо 
использовать стандартный API IBM Connections 5.0 - 
https://www-10.lotus.com/ldd/lcwiki.nsf/xpSearch.xsp?searchValue=tags%20api  
2.2.4. Функционал Чат  
2.2.4.1. Чат-бот  
2.2.4.1.1. В Приложении необходимо 
реализовать функционал чата. 2.2.4.1.2. Чат 
необходимо создавать для конкретной 
группы пользователей.  
В чате должна быть предусмотрены 
возможности:  
2.2.4.1.3. Возможность переписываться 
между конкретными сотрудниками. 2.2.4.1.4. 
Возможность создавать группы.  
2.2.4.1.5. Возможность отправлять файлы.  
2.2.4.1.6. Необходимо обеспечить отображение 
статусов «печатает», «доставлено», 
«прочитано». 
2.2.4.1.7. Для чата или чат-бота допускается 
использовать открытые платформы. 
Использование конкретной платформы будет 
согласовано на этапе согласования решения 
с учетом требований Информационной 
безопасности к данному классу решений. 2.2.4.1.8. 
Необходимо реализовать чат для WEB для 
конкретной группы пользователей 
техподдержки, сотрудников которой чат-бот в 
некоторых случаях будет подключать в чат.  
2.2.4.1.9. Необходимо реализовать отдельный 
чат для новичков, в котором будет 
реализовано автоматическое добавление 
сотрудников после их приема на работу и 
автоматическое исключение через 
заданный промежуток времени.   
2.2.4.1.10. Необходимо реализовать возможность 
оценки качества предоставленной 
информации  
2.2.4.1.11. Необходимо обеспечить хранение 
ответов и доступа к ним сотрудников при 
формулировки похожего запроса.  

2.2.5. Сервисы (наличие раздела и набор 

сервисов зависит от таргетинга 

пользователя). 2.2.5.1. Сервис “Заказ 

корпоративного транспорта”   

2.2.5.2. Сервис должен предоставлять 


возможность заказа корпоративного 
транспорта, согласно установленным 
регламентам.  

2.2.5.3. Сервис “Заказ пропуска на объект». 


Сервис должен автоматизировать процесс 
заказа гостевого пропуска на территорию 
Заказчика.  
2.2.5.4. Сервис “Бронирование переговорной”. 
Сервис должен поддержать процесс 
бронирования переговорных комнат. 
Необходимо обеспечить интеграцию с 
порталом компании, для синхронизации 
информации о наличии свободных 
переговорных комнат.  
2.2.5.5. Сервис “Расчётный лист”. Сервис 
должен обеспечить интеграцию для 
получения информации о начислениях и 
удержаниях Заработной платы 
конкретного сотрудника.  
2.2.5.6. Сервис “Калькулятор премий”  
2.2.5.7. Сервис “Отпуск” (РТ-сам бот). Сервис 
должен иметь возможность просмотра 
баланса отпускных дней, а также переноса, 
заказа и согласования отпуска.   
2.2.5.8. Сервис “Заказ АКС”. Необходимо 
разработать сервис заказа 
аудиоконференций. Необходимо 
предусмотреть интеграцию с web-Порталом 
компании  
2.2.5.9. Сервис “Заявки ServiceDesk”  
2.2.5.9.1. Сервис должен обеспечивать возможность 
создания Заявки в ServiceDesk  
2.2.5.9.2. Сервис должен обеспечивать 
возможность просмотра Заявки в 
ServiceDesk  
2.2.5.9.3. Сервис должен обеспечивать 
возможность редактирования Заявки в 
ServiceDesk  
2.2.5.9.4. Сервис должен обеспечивать 
возможность согласования или 
отклонения Заявки в ServiceDesk  
2.2.5. Настройки  
2.2.5.1. Необходимо поддержать ролевую модель  
2.2.5.2. Необходимо поддержать 
организационную структуру 2.2.5.3. 
Необходимо реализовать 
настройки чата:  
2.2.5.3.1. Включение/ Выключение чата  
2.2.5.3.2. Доступность: Градации сотрудников 
2.2.5.3.3. Возможность установки 
внутренних ограничений: по грейду 
(корпоративному званию).  
2.2.5.4. Настройки Push-уведомлений  
2.2.5.5. Отключение Push-уведомлений   
2.2.5.6. Настройка приоритетности Push-уведомлений  

2.2.6. Помощник по планированию рабочего времени  


2.2.6.1. Необходимо реализовать оповещения о 
новых поручениях 2.2.6.2. Необходимо выводить 
информацию о дедлайнах по имеющимся 
поручениям или документам, требующим 
согласования.  
2.2.6.3. Необходимо предусмотреть функционал 
Календарь с запланированными встречами и 
синхронизацию с Outlook.  
2.2.6.4. Необходимо реализовать оповещения 
(указание только темы и андресанта) о новых 
письмах в почту (интеграция с Outlook).  

2.2.7. Информационный раздел “О нас”  

В данном разделе необходимо реализовать 


разделы:  
2.2.7.1. Инфографика по стратегии и бюджету на год.  
2.2.7.2. Корпоративные КПЭ на год и статус 
исполнения.   
2.2.7.3. Слепки отчетов по NPS и SLA (для 
руководства) с указанием 
подразделений/ответственных за 
исполнение заявок клиентов.   
2.2.7.4. Корпоративные СМИ  
2.2.7.5. Новости  

2.2.8. Раздел «Развитие персонала»  


Необходимо реализовать следующую 
функциональность:  
2.2.8.1. Опросы   
2.2.8.2. Портал идей (возможность просмотра 
предложений и голосование). 2.2.8.3. 
Библиотека, бизнес литература (в т.ч. 
ссылки на ресурсы, приложения). 2.2.8.4. Edusson  
2.3. Требования к надежности  
2.3.1. Время восстановления после отказа  
Время восстановления после отказа, 
вызванного сбоем электропитания 
технических средств (иными внешними 
факторами), не фатальным сбоем (не крахом) 
операционной системы,  
не должно превышать 30-ти минут при 
условии соблюдения условий 
эксплуатации технических и 
программных средств.  
Время восстановления после отказа, 
вызванного неисправностью технических 
средств, фатальным сбоем (крахом) 
операционной системы, не должно превышать 
времени, требуемого на устранение 
неисправностей технических средств и 
переустановки программных средств.  
2.3.2. Отказы из-за некорректных действий 
оператора  
Отказы программы возможны 
вследствие некорректных действий 
оператора (пользователя) при 
взаимодействии с операционной 
системой.  
Во избежание возникновения отказов программы 
по указанной выше причине следует  
обеспечить работу конечного 
пользователя без предоставления ему 
административных привилегий.  
3. Условия эксплуатации  
3.1. Климатические условия эксплуатации  
Климатические условия эксплуатации, при 
которых должны обеспечиваться заданные 
характеристики, должны удовлетворять 
требованиям,  
предъявляемым к техническим средствам в 
части условий их эксплуатации.   

3.2. Требования к квалификации и численности 


персонала  
Минимальное количество персонала, 
требуемого для работы программы, должно 
составлять не менее 2 штатных единиц — 
системный администратор и администратор 
БД.  
Системный администратор должен иметь 
высшее профильное образование и 
сертификаты компании-производителя 
операционной системы. В перечень задач, 
выполняемых системным администратором, 
должны входить:  
а) задача поддержания работоспособности 
технических средств;  
б) задачи установки (инсталляции) и 
поддержания работоспособности 
системных программных средств — 
операционной системы;  
в) задача установки (инсталляции) программы.  
г) задача создания резервных копий базы 
данных.  

3.3. Специальные требования  


Специальные требования к данной программе не 
предъявляются.  

4. Требования к программной документации  

4.1. Предварительный состав программной 


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

5. Технико-экономические показатели  

5.1. Экономические преимущества разработки  


Ориентировочная экономическая 
эффективность не рассчитываются. 
Аналогия не проводится ввиду 
уникальности предъявляемых 
требований к разработке.  

6. Стадии и этапы разработки  

6.1. Стадии разработки  


Разработка должна быть проведена в две 
стадии:  
1. Разработка MVP.  
2. Разработка дополнительной 
функциональности.  

6.2. Этапы разработки  


1. Разработка MVP .  
2. Разработка дополнительной 
функциональности - 1 этап.  
3. Разработка дополнительной 
функциональности - 2 этап. 
6.3. Содержание работ по стадиям  

6.3.1. Разработка MVP и срок сдачи  


Двухфакторная аутентификация  
CMS (подготовка контента для 
новостной ленты, 
онбоардинг-гайда, 
конфигурирование сервисов)  
Гайд для нового сотрудника  
Сервис "Заказ пропуска на объект"  
Сервис "Бронирование переговорной"  
Сервис "Отпуск"  
Заявки ServiceDesk  
Профиль сотрудника  
Телефонный справочник  
Чат + Чат-бот + Web-интерфейс чата  
Новостная лента  
Настройки по функционалу MVP  
Срок реализации до 05.09.2018г.  

6.3.2. Разработка дополнительной 


функциональности - 1 этап ​и срок сдачи  

Сервис "Заказ корпоративного транспорта"  


Сервис "Заказ АКС (Аудиоконференций)"  
Отображение заявок и задач, с 
согласованием  
Wiki (база знаний)  
Сервис "Расчётный лист"  
Сервис "Калькулятор премий"  
Тег коллегам  
Настройки по функционалу 2-го этапа 
проекта  
Срок реализации до 15.11.2018г.  

6.3.3. Разработка дополнительной 


функциональности - 2 этап и срок сдачи  
Развиваемся вместе. Опросы (с таргетингом)  
Развиваемся вместе. Портал идей с 
голосованием  
Развиваемся вместе. Библиотека ссылок  
Развиваемся вместе. Edusson  
Помощник по планированию рабочего 
времени. Оповещения о новых поручениях 
Помощник по планированию рабочего 
времени. Календарь  
Помощник по планированию рабочего 
времени. Оповещения о новых письмах 
Стратегия Ростелекома / О нас. 
Инфографика по стратегии и бюджету на 
год Стратегия Ростелекома / О нас. 
Корпоративные КПЭ на год и статус 
исполнения Стратегия Ростелекома / О 
нас. Слепки отчетов по NPS и SLA  
CMS (конструктор новых сервисов) + 
поддержка добавления новых сервисов 
на мобильном устройстве  
Срок реализации до 31.03.2019г. 
7. Порядок контроля и приемки  

7.1. Виды испытаний  


7.1.1. Приемо-сдаточные испытания должны 
проводиться на объекте Заказчика в 
оговоренные сроки.  
7.1.2. Приемо-сдаточные испытания 
программы должны проводиться согласно 
разработанной Исполнителем и 
согласованной Заказчиком Программы и 
методик испытаний.  
7.1.3. Ход проведения приемо-сдаточных 
испытаний Заказчик и Исполнитель 
документируют в Протоколе 
проведения испытаний  

7.2. Общие требования к приемке работы  


На основании Протокола проведения 
испытаний Исполнитель совместно с 
Заказчиком подписывает Акт приемки-сдачи 
программы в эксплуатацию. 
Приложение 1Перечень информации, необходимой 
для формирования   
Профиля сотрудника. 
№  Поле   Возможно Комментарий 
сть  
редактир
ования 

1   ФИО   Нередак - 


тируемо
е  

  2 Должность   Нередак Если должностей 


тируемо несколько, то необходимо 
е   отражать Основную (либо 
ту, на которую раньше 
устроился сотрудник) с 
возможностью просмотра 
остальных должностей 
  3  Нередак При нажатии 
Подразделен тируемо отображает структуру 
ие   е   от текущего 
подразделения до 
компании.  
Требования к отображению 
как и для Должности. 

  4 Адрес   Нередак - 
тируемо
е  

  5 Помещение   Нередак - 
тируемо
е  

  6 Цепочка  Нередак - 
подчинения   тируемо
е  

  7 Телефон   Нередак - 
тируемо
е  

  8 Рабочий e-mail   Нередак - 


тируемо
е  

  9 “Спасибо” на  Нередак - 


портале   тируемо
е  

  0 Фотография   Редакти - 
руемое  

  1 Статус   Редакти Текстовое поле, 


руемое   обновляемое сотрудником 
и доступное другим для 
просмотра. 

  2 Рабочий  Редакти Может подгружаться либо 


татус   руемое   статус   
Несколько вариантов, 
среди которых может 
выбрать сотрудник. 

  3 О себе   Редакти Текстовое поле, 


руемое   обновляемое сотрудником 
и доступное другим для 
просмотра. 
  4 Коллеги   Редакти 1) Сотрудник будет сам 
руемое   выбирать из списка 
своих коллег  
2) Отображать такой 
список в Профиле 
необходимо в виде списка,  
3) Должна быть 
возможность нажать на 
конкретного коллегу и 
открыть его карточку с 
информацией о нем. 

  5 Тэги   Редакти Например, Python, ФИО 


руемое   Начальника, аудит, 
отчетность -- то есть те 
теги, которыми можно 
определить работу 
человека, для облегчения 
поиска 

  6 Мобильный  Редакти Текстовое поле (с маской) 


елефон   руемое   для редактирования 
(конфиде
нциальн
ое ) 

Вам также может понравиться