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

ТЕХНИЧЕСКОЕ ЗАДАНИЕНа разработку и внедрение информационной системы

автоматизации органов управления

г. Москва 2016 г.

Оглавление1 ОБЩИЕ СВЕДЕНИЯ...........................................................................................................4

1.1 Полное наименование работ и условное обозначение................................................41.2 Назначение документа....................................................................................................41.3 Заказчик...........................................................................................................................41.4 Плановые сроки начала и окончания работ.................................................................4

2 Термины и определения......................................................................................................53 Назначение и цели................................................................................................................6

3.1 Назначение системы.......................................................................................................63.2 Цели разработки системы..............................................................................................6

4 Характеристика объекта автоматизации............................................................................74.1 Краткие сведения об объекте автоматизации..............................................................74.2 Основные бизнес-роли...................................................................................................7

5 Требования к системе..........................................................................................................85.1 Требования к системе в целом.......................................................................................8

5.1.1 Общие требования к системе..................................................................................85.1.2 Требования к архитектуре системы.......................................................................85.1.3 Требования по производительности......................................................................95.1.4 Требования по развитию системы.......................................................................105.1.5 Требования к эргономике и технической эстетике............................................105.1.6 Требования к надежности и восстановлению после сбоев................................115.1.7 Требования к эксплуатации, техническому обслуживанию, ремонту и хранению.............................................................................................................................115.1.8 Требования к структуре и функционированию системы...................................11

5.2 Требования к автоматизируемым процессам.............................................................115.2.1 Внесение запланированных мероприятий органа управления.........................125.2.2 Подготовка мероприятий органа управления.....................................................145.2.3 Проведение мероприятий органа управления....................................................21

5.3 Требования к функциям (задачам), выполняемым системой...................................275.3.1 Требования к структуре корпоративного управления.......................................275.3.2 Требования к поддерживаемым языкам..............................................................275.3.3 Требования к информационным объектам системы..........................................285.3.4 Требования к способам аутентификации............................................................365.3.5 Требования к блоку уведомлений........................................................................375.3.6 Требования к добавлению связи между Вопросами..........................................385.3.7 Требования к загрузке материалов......................................................................395.3.8 Требования к ограничению доступа к вопросам и материалам........................405.3.9 Требования к механизму замещения...................................................................41

5.3.10 Требования к шаблонам системы.........................................................................415.3.11 Требования к функции согласования материалов..............................................415.3.12 Требования к проведению трансляции................................................................425.3.13 Требование к аннотированию материалов..........................................................425.3.14 Требования к проведению голосования..............................................................425.3.15 Требования к подсистеме интеграции.................................................................435.3.16 Требования к подсистеме администрирования..................................................44

5.4 Требования к интерфейсу системы.............................................................................465.4.1 Требования к стартовому экрану системы..........................................................465.4.2 Требования к календарю системы.......................................................................465.4.3 Требования к эргономике интерфейса.................................................................46

5.5 Требования к информационной безопасности...........................................................475.5.1 Полное наименование подсистемы и ее условное обозначение.......................475.5.2 Требования к Подсистеме информационной безопасности..............................47

5.6 Требования к видам обеспечения................................................................................495.6.1 Требования к информационному обеспечению.................................................495.6.2 Требования к программному обеспечению........................................................505.6.3 Требования к техническому обеспечению ИС...................................................505.6.4 Требования к патентному обеспечению..............................................................515.6.5 Требования по стандартизации и унификации...................................................515.6.6 Требования к лингвистическому обеспечению..................................................51

5.7 Порядок контроля и приемки системы.......................................................................515.8 Требования к документированию...............................................................................525.9 Требования к составу услуг по технической поддержке системы...........................53

5.9.1 Терминология.........................................................................................................535.9.2 Общие положения..................................................................................................535.9.3 Требования к обращениям в службу поддержки................................................535.9.4 Реакция на запросы................................................................................................535.9.5 Выпуск исправлений.............................................................................................54

1 ОБЩИЕ СВЕДЕНИЯ

1.1 ПОЛНОЕ НАИМЕНОВАНИЕ РАБОТ И УСЛОВНОЕ ОБОЗНАЧЕНИЕ

Проведение работ по разработке и внедрению информационной системы автоматизации коллегиальных органов управления для открытого акционерного общества «Акционерная финансовая компания «Система» (далее – «ОАО АФК «Система» или «Заказчик»). Условное обозначение – AFKISATKO.1.2 НАЗНАЧЕНИЕ ДОКУМЕНТА

Настоящий документ представляет собой Техническое задание на разработку и внедрение информационной системы автоматизации коллегиальных органов управления для ОАО АФК «Система».1.3 ЗАКАЗЧИК

Открытое акционерное общество «Акционерная финансовая компания «Система».1.4 ПЛАНОВЫЕ СРОКИ НАЧАЛА И ОКОНЧАНИЯ РАБОТ

Дата начала работ: с момента подписания договораДата окончания работ: 8 календарных месяцев с момента начала работКалендарные сроки выполнения этапов, а также порядок их документального оформления определяются договором.1.5 ПОРЯДОК ОФОРМЛЕНИЯ И ПРЕДЪЯВЛЕНИЯ РЕЗУЛЬТАТОВ РАБОТ

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

2 Термины и определения

В рамках проекта разработки и внедрения Системы должны быть определены следующие понятия:

Таблица 2.1 — Используемые термины и определенияТермин ОписаниеСистема Информационная система автоматизации

деятельности коллегиальных органовГруппа юридических лиц Список юридических лиц, входящих в структуру

корпоративного управленияЮридическое лицо Единица в структуре корпоративного управления

организации Заказчика, содержащая внутри себя структуру органов управления

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

Орган управления Единица в организационной структуре Заказчика, выполняющая коллегиальное принятие решений

Структура органов управления Список органов управления конкретного юридического лица

Вопрос Потенциальный пункт в повестке дняОтветственный за подготовку (Докладчик)

Сотрудник, ответственный за подготовку и предоставление материалов по вопросу повестки дня на мероприятии органа управления

Мероприятие (Заседание) Объект Системы, участвующий в процессе подготовки и проведения коллегиального собрания органа управления

Материал Контейнер, содержащий файлы, необходимые для рассмотрения в ходе Мероприятия органа управления

Повестка дня Список вопросов, рассматриваемых на мероприятии органа управления

3 Назначение и цели

3.1 НАЗНАЧЕНИЕ СИСТЕМЫ

Система предназначена для автоматизации внутренней работы в части подготовки и проведения мероприятий органов управления Заказчика.3.2 ЦЕЛИ РАЗРАБОТКИ СИСТЕМЫ

Основными целями создания системы являются:1. Предоставление возможности проведения и подготовки мероприятий в

электронной форме.2. Автоматизация процедуры подготовки и проведения мероприятия путем

предоставления материалов к заседанию в электронной форме.3. Автоматизация процессов согласования материалов, предоставляемых к

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

мероприятия в удаленном и заочном режимах.5. Сокращения времени на подготовку мероприятий и формирование протокола.

4 Характеристика объекта автоматизации

4.1 КРАТКИЕ СВЕДЕНИЯ ОБ ОБЪЕКТЕ АВТОМАТИЗАЦИИ

Объектом автоматизации является процесс корпоративного управления в ОАО АФК «Система», включая планирование, подготовку и проведение мероприятий Совета директоров и его комитетов, а также проведение совещаний исполнительных коллегиальных органов и планерок у руководителей, обеспечивающих подготовку материалов к мероприятиям и выполнение решений Совета директоров и Общего собрания акционеров. Структура корпоративного управления в ОАО АФК «Система» представлена на Рисунке 4.1.

Рисунок 4.1 - Структура корпоративного управления

4.2 ОСНОВНЫЕ БИЗНЕС-РОЛИ

1. Секретарь органа управления – сотрудник, назначаемый соответственным органом управления, в рамках своих полномочий выполняющий работы по:

1. Разработке плана работы органа управления.a. Уведомление членов органа управления о предстоящих

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

b. Подготовке протоколов мероприятий.2. Сотрудник аппарата секретаря – группа сотрудников, ответственная за

выполнение функций Секретаря органа управления в части планирования, подготовки, проведения и оформления мероприятий.

3. Докладчик – сотрудник, ответственный за подготовку и предоставление материалов по вопросу повестки дня.

4. Член органа управления – участник заседаний органа управления, принимающий решения по вопросам повестки методом голосования.

5. Заместитель члена органа управления – сотрудник, обладающий полномочиями замещения Члена органа управления в ходе мероприятий конкретного органа управления.

6. Приглашенный участник мероприятия.7. Председатель органа управления.8. Администратор системы – сотрудник, ответственный за общее управление и

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

5 Требования к системе

5.1 ТРЕБОВАНИЯ К СИСТЕМЕ В ЦЕЛОМ

5.1.1 Общие требования к системе

Система должна удовлетворять следующим функциональным требованиям; Возможность создания и администрирования холдинга, содержащего компании и

органы управления; Возможность формирования и редактирования мероприятий, вопросов,

материалов; Возможность предложения Вопросов на рассмотрение в другие Органы

управления; Возможность создания мероприятий, вопросов, материалов по предварительно

настроенным шаблонам; Возможность отправки материалов по настраиваемым маршрутам согласования; Возможность работы через Мобильное приложение на планшетном компьютере

Apple iPad и с помощью Web-клиента; Возможность переключения языка интерфейса и контента Системы; Возможность демонстрации файлов на экранах мобильных устройств с

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

пределах Системы; Возможность оставить комментарий к объекту системы в формате адресного

сообщения; Возможность отслеживания изменений по выбранным объектам системы; Возможность просматривать новости компании;

5.1.2 Требования к архитектуре системы

Система должна иметь следующую структуру: Сервер приложений, включающий в себя Web-сервис и Web-клиент, под

управлением ОС Windows Server 2012 и выше; Сервер баз данных на базе MS SQL Server 2008 и выше;

Клиентские подключения через Web-клиент и iPad-клиент.Требования к Web-клиенту: компьютер, с каналом до сервера не менее 512 КБ, разрешение монитора - не менее 1920х1080. Браузеры – Internet Explorer (версия 11 или новее), Chrome (версия 49 или новее), Firefox. Ниже приведена рекомендованная схема архитектуры системы:

Рисунок 2. Рекомендованная схема архитектуры системы

Требования к мобильному клиенту: Мобильный клиент системы должен быть реализован в виде программы для

платформы Apple iPad с операционной системой версии не ниже 9. Программа должна быть доступна для установки из Apple AppStore, либо по прямой ссылке с собственного сервера Заказчика. Система должна запрещать установку и работу клиента на устройстве с установленным jailbreak (недокументированные возможности доступа к операционной системе мобильного устройства).

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

Мобильный клиент системы должен поддерживать работу (отображать) документы форматов PDF и Microsoft Office.

Мобильный клиент системы должен поддерживать отображение объектов системы на мобильном устройстве в удобном для просмотра представлении.

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

содержанию личного кабинета в автономном режиме должен быть ограничен по имени пользователя и паролю без возможности их кэширования(запоминания).

5.1.3 Требования по производительности

Отображение любой формы после ее вызова не должно занимать более 2 секунд. Если отображаемые данные занимают более одной страницы, то указанные интервалы относятся к первой странице результата. Под отображением в данном пункте подразумевается, в том числе возможность выполнять действия с открывшейся формой. При команде пользователя на получение результатов поиска система должна возвращать результат простого поиска (один атрибут) в течение 2 секунд и сложного (указаны условия не менее чем для четырёх атрибутов) в течение 8 секунд с момента подачи команды вне зависимости от объема хранимых данных и количества выполняемых процессов. Пауза при смене страницы в режиме трансляции презентаций не должна превышать 1 секунды вне зависимости от других операций, производимых системой в это время. Система должна позволять обслуживать не менее 100 одновременно работающих пользователей без потери производительности при штатном режиме функционирования аппаратно-программного комплекса, а также исправной работе сети. Параметры отклика форм системы определяются п. 5.1.3 и должны отвечать требованиям эргономики автоматизированных систем, но могут быть уточнены на этапе технического проектирования.Производительность системы не должна изменяться в зависимости от количества элементов в справочниках системы, количественного и качественного состава атрибутов. Производительность системы не должна изменяться при назначении прав на отдельные объекты системы.

5.1.4 Требования по развитию системы

5.1.4.1 Требования к масштабированию системы

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

5.1.4.2 Функциональное развитие системы

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

5.1.5 Требования к эргономике и технической эстетике

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

едином графическом дизайне, с одинаковым расположением основных элементов управления и навигации;

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

Внешнее поведение сходных элементов интерфейса (реакция на наведение указателя «мыши», переключение фокуса, нажатие кнопки) должно реализовываться одинаково для однотипных элементов.

Система должна соответствовать требованиям Российских стандартов, предъявляемых к эргономике и технической эстетике, а также Законодательству об охране и безопасности труда, при условии комплектования высококачественным оборудованием (ПЭВМ, монитор и прочее оборудование), имеющим необходимые сертификаты соответствия и безопасности Росстандарта. Общие требования к интерфейсу системы не специфицируются по элементам, но должны соответствовать принятым в отрасли де-факто стандартам и лучшим практикамЭкранные интерфейсы Web-приложения должны быть рассчитаны на разрешение 1280*960 и выше (при таком разрешении все элементы экранного интерфейса должны быть полностью и с необходимыми пропорциями размещены на экране).Экранные интерфейсы мобильного приложения должны быть рассчитаны на разрешение 2048*1526 и ниже (при таком разрешении все элементы экранного интерфейса должны быть различимыми и сохранять четкость).5.1.6 Требования к надежности и восстановлению после сбоев

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

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

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

При ошибках, связанных с системным программным обеспечением (ОС и ее компоненты, драйверы устройств), восстановление работоспособности системы возлагается на ОС и сотрудников Заказчика.

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

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

хранению

Система должна обеспечивать непрерывный круглосуточный режим эксплуатации (24*7). Допускается временная плановая приостановка работы Системы для проведения профилактических работ программно-аппаратного обеспечения сервера, на котором располагается Система (допустимые технологические окна должны быть определены в ходе ОПЭ). Общее время простоя системы – не более 48 часов в год при средней продолжительности остановки не более 8 часов. Данные работы должны производиться в то время, когда необходимость использования Системы минимальна.5.1.8 Требования к структуре и функционированию системы

Для функционирования программно-аппаратных комплексов должны быть использованы существующие структурированные кабельные системы и локальные вычислительные сети (ЛВС) на объектах Компании.5.1.9 Требования к переносу данных

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

5.2 ТРЕБОВАНИЯ К АВТОМАТИЗИРУЕМЫМ ПРОЦЕССАМ

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

Внесение запланированных мероприятий. Подготовка мероприятия. Проведение мероприятия. Оформление.

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

Создание мероприятия на основе Плана мероприятий органа управления. Создание проекта повестки (должна присутствовать возможность создания проекта

повестки на основе предварительно подготовленных шаблонов). Предоставление доступа к мероприятию для всех участников органа управления.

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

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

Под процессом планирования мероприятий органа управления понимается процесс создания в Системе записей о планируемых мероприятиях органов управления.Описание процесса представлено в двух разделах:

1. Графическое представление процесса.2. Пошаговое описание процесса.

5.2.1.1 Графическое представление процесса

Рисунок 5.3 - Процесс планирования мероприятий органа управления

5.2.1.2 Пошаговое описание процесса

Процесс планирования мероприятия состоит из следующих шагов:1. Заполнить сведения о мероприятии.2. Изменить параметры по умолчанию.3. Сохранить черновик мероприятия.4. Создать вопрос повестки.5. Добавить ссылку на вопрос.6. Опубликовать мероприятие.

Шаг 1. Заполнить сведения о мероприятии.Исполнитель: Корпоративный секретарь.Действие:

1. Производит создание карточки Мероприятия. Должны быть заполнены обязательные поля: Вид, Место, Время, Дата проведения.

a. Если необходимо настроить дополнительные параметры Мероприятия, производится переход на Шаг 2.

b. Если не требуется настройка дополнительных параметров Мероприятия, производится переход на Шаг 3.

Вход:1. План мероприятий. Формируется вне рамок Системы.

Выход:1. Карточка мероприятия с заполненными основными полями.

Шаг 2. Изменить значения параметров, заданных по умолчанию.Исполнитель: Корпоративный секретарь.Действие:

1. Производит изменение параметров мероприятия по умолчанию. a. Если требуется промежуточное сохранение Мероприятия, производится

переход на Шаг 3.b. Если не требуется промежуточное сохранение Мероприятия, производится

переход на Шаг 4 или 6 в зависимости от условий.Вход:

1. Карточка мероприятия с заполненными основными полями.Выход:

1. Карточка мероприятия с заполненными основными полями с измененными дополнительными параметрами.

Шаг 3. Сохранить черновик мероприятия.Исполнитель: Корпоративный секретарь.Действие:

1. Производит сохранение карточки мероприятия в Системе в статусе «Черновик».a. Если есть сведения по вопросам повестки, производится переход на Шаг 4.b. Если нет сведений по вопросам повестки, но будут предоставлены позже, то

производится переход на Шаг 4 с учетом ожидания.c. Если нет сведений по вопросам повестки и не планируется их

предоставление в текущий момент времени, производится переход на Шаг 6.

Вход:1. Карточка мероприятия с заполненными основными полями с настроенными

дополнительными параметрами.Выход:

1. Мероприятие в статусе «Черновик».Шаг 4. Создать вопрос повестки.Исполнитель: Корпоративный секретарь.Действие:

1. Производит создание новой карточки Вопроса повестки Мероприятия. Должны быть заполнены обязательные поля: Название вопроса.

a. Если требуется настроить связь с другим Вопросом, производится переход на Шаг 5.

b. Если не требуется настроить связь с другим Вопросом и добавлены не все вопросы повестки, производится переход на Шаг 4.

c. Если не требуется настроить связь с другим Вопросом и добавлены все вопросы повестки, производится переход на Шаг 6.

Вход:1. Мероприятие в статусе «Черновик».

2. План мероприятий.Выход:

1. Вопрос в повестке Мероприятия в статусе «Черновик».Шаг 5. Добавить ссылку на вопрос.Исполнитель: Корпоративный секретарь.Действие:

1. Производится связывание созданного Вопроса повестки Мероприятия с любым другим существующим Вопросом органа управления, либо вопросом любого другого органа управления, при наличии соответствующих прав доступа.

a. Если добавлены все вопросы повестки, производится переход на Шаг 6.b. Если добавлены не все вопросы повестки, производится переход на Шаг 4.

Вход:1. Вопрос в повестке Мероприятия в статусе «Черновик».

Выход:1. Связанный вопрос в повестке Мероприятия в статусе «Черновик».

Шаг 6. Отобразить мероприятие для участников.Исполнитель: Корпоративный секретарь.Действие:

1. Снимает статус «Черновик» с Мероприятия. Мероприятие становится доступным для просмотра всем членам органа управления.

Вход:1. Вопрос в повестке Мероприятия в статусе «Черновик».2. Связанный вопрос в повестке Мероприятия в статусе «Черновик».

Выход:1. Мероприятие в Календаре Системы.

5.2.2 Подготовка мероприятий органа управления

Под процессом подготовки мероприятий органа управления понимается процесс подготовки и предоставления на ознакомление материалов повестки дня участникам мероприятия.Описание процесса представлено в двух разделах:

1. Пошаговое описание процесса.2. Графическое представление процесса.

5.2.2.1 Графическое описание процесса

5.2.2.2 Пошаговое описание процесса

Процесс подготовки мероприятий состоит из следующих шагов:1. Создать из шаблона уведомление о начале подготовки.2. Прикрепить вложения.3. Отправить уведомление ответственному по вопросу.4. Начать подготовку вопроса.5. Отправить уведомления ответственным.6. Подпроцесс. Загрузить материалы в Систему.7. Настроить списки согласующих.8. Отправить на доработку.9. Запустить процесс согласования.10. Согласовать материалы.11. Согласовать материалы.12. Создать уведомление «Об окончании приема материалов после публикации».13. Отправить уведомления ответственным.14. Внести вопросы в повестку.15. Создать из шаблона уведомление «О начале подготовки».16. Загрузить материалы в систему.17. Опубликовать материалы.18. Создать из шаблона уведомление «О готовности материалов».19. Разослать уведомления участникам мероприятия.

Шаг 1. Создать из шаблона уведомление о начале подготовки.Исполнитель: Корпоративный секретарь.Действие:

1. Создает в Системе новое уведомление типа «О начале подготовки» для Вопроса Повестки дня. Производит корректировку значений полей карточки уведомления: Текст уведомления (текстовое информационное поле, включающее текст уведомления и URL-ссылки на материалы на ресурсах Заказчика), Сроки выполнения задачи.

a. Если требуется прикрепить Материал, производится переход на Шаг 2.b. Если не требуется Материал, производится переход на Шаг 3.

Вход:1. Мероприятие, запланированное в Календаре Системы.2. Если включены предварительные уведомления, Исполнитель должен получить

Уведомление о наступлении срока подготовки Мероприятия. Дата получения уведомления должна рассчитываться в зависимости от значения, указанного в параметрах Органа управления, в рамках которого производится процесс подготовки Мероприятия.

Выход:1. Карточка уведомления «О начале подготовки» с заполненными данными по

Вопросу повестки Мероприятия.Шаг 2. Прикрепить вложения.Исполнитель: Корпоративный секретарь.Действие:

1. Производит добавление необходимого количества файлов к Уведомлению о начале подготовки. После завершения прикрепления файлов производится переход к Шагу 3.

Вход:

1. Карточка уведомления о начале подготовки с заполненными данными по Вопросу повестки Мероприятия.

Выход:1. Карточка уведомления о начале подготовки с заполненными данными по Вопросу

повестки Мероприятия с прикрепленными файлами.Шаг 3. Отправить уведомление ответственному по вопросуИсполнитель: Корпоративный секретарь.Действие:

1. Производит отправку карточки уведомления о начале подготовки с заполненными данными по Вопросу повестки Мероприятия с прикрепленными файлами Ответственному по Вопросу.

a. Если была выполнена отправка по всем Вопросам, входящим в Повестку дня Мероприятия, производится переход на Шаг 4.

b. Если была выполнена отправка не по всем Вопросам, входящим в Повестку дня Мероприятия, производится переход на Шаг 1.

Вход:1. Карточка уведомления о начале подготовки с заполненными данными по Вопросу

повестки Мероприятия.2. Карточка уведомления о начале подготовки с заполненными данными по Вопросу

повестки Мероприятия с прикрепленными файлами.Выход:

1. Отправлено Уведомление о начале подготовки с заполненными данными по Вопросу повестки Мероприятия.

Шаг 4. Начать подготовку вопросаИсполнитель: Ответственный по вопросу.Действие:

1. Переводит Вопрос в статус «В подготовке». Вне рамок Системы производит передачу задач Исполнителям по подготовке материалам.

a. Если после получения Корпоративным секретарем уведомления «О скором завершении подготовки» Корпоративный секретарь принимает решение об отправке Ответственным по вопросам уведомления «Об истечении срока подготовки», производится переход на Шаг 5.

b. Если после получения Корпоративным секретарем уведомления «О скором завершении подготовки» Корпоративный секретарь принимает решение об отказе отправки Ответственным по вопросам уведомления «Об истечении срока подготовки», производится переход на Шаг 6.

Вход:1. Уведомление «О начале подготовки» с заполненными данными по Вопросу

повестки мероприятия. С уведомлением могут быть произведены следующие операции:

a. Принять уведомление – исполнитель подтверждает, что начинает подготовку по Вопросу. Вопрос автоматически переводится в статус «В подготовке».

b. Отклонить уведомление – исполнитель отклоняет уведомление по Вопросу. Перевод вопроса в статус «В подготовке» производится вручную.

c. Отложить уведомление – исполнитель временно отклоняет уведомление. Через промежуток времени, установленный на уровне Органа управления, уведомление должно быть автоматически повторно отправлено Исполнителю.

2. Уведомление «О необходимости доработки».3. Замечания по материалам Вопроса.

Выход:1. Вопрос в статусе «В подготовке».2. Задачи Исполнителям по материалам вне рамок Системы.

Шаг 5. Отправить уведомления ответственнымИсполнитель: Корпоративный секретарь.Действие:

1. Производит создание из шаблона Уведомления об истечении срока подготовки. Рассылка уведомления должна производиться массово на всех Ответственных по вопросам, занятых подготовкой Вопросов повестки Мероприятия. Производит корректировку списка получателей. Производится переход на Шаг 6.

Вход:1. Уведомление «О скором наступлении даты завершения подготовки». Дата

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

Выход:1. Уведомление «Об истечении срока подготовки».

Шаг 6. Подпроцесс. Загрузить материалы в СистемуИсполнитель: Ответственный по вопросу.Действие:

1. Производит добавление материалов, их категоризацию, добавление версий на дополнительных языках.

a. Если после получения Корпоративным секретарем уведомления «О новой версии материалов» Корпоративный секретарь принимает решение об отправке Вопроса на согласование и было передано достаточное количество вопросов с добавленными материалами, производится переход на Шаг 6. Решение о достаточном количестве вопросов с добавленными материалами принимается Корпоративным секретарем вне Системы.

b. Если после получения Корпоративным секретарем уведомления «О новой версии материалов» Корпоративный секретарь принимает решение об отправке Вопрос на согласование и не было передано достаточное количество вопросов с добавленными материалами, производится переход на шаг 5 для оповещения Ответственных по Вопросу, не предоставивших Вопросы повестки с добавленными материалами.

c. Если после получения Корпоративным секретарем уведомления «О новой версии материалов» Корпоративный секретарь принимает решение об отправке Вопроса на доработку, производится переход на Шаг 7.

Вход:1. Уведомление «Об истечении срока подготовки».2. Вопрос в статусе «В подготовке».3. Материалы по вопросу от Исполнителей по материалам. Получение материалов

производится вне рамок Системы.Выход:

1. Вопрос в статусе «В подготовке» с прикрепленными материалами.2. Уведомление «О новой версии материалов».

Шаг 7. Настроить списки согласующихИсполнитель: Корпоративный секретарь.

Действие:1. Производит настройку процесса согласования по Вопросам с добавленными

материалами: указывает пользователей Системы, которым будут присвоены роли Ответственный за контент, Ответственный за форму. Производится переход на Шаг 9.

Вход:1. Вопрос в статусе «В подготовке» с прикрепленными материалами.2. Уведомление «О новой версии материалов».

Выход:1. Заполненная карточка процесса согласования.

Шаг 8. Отправить на доработкуИсполнитель: Корпоративный секретарь.Действие:

1. Производит ознакомление со всеми поступившими Вопросами с добавленными материалами, указывает замечания и отправляет Ответственным по Вопросам на доработку. Формируется уведомление «О необходимости доработки». Производится переход на Шаг 4.

Вход:1. Вопрос в статусе «В подготовке» с прикрепленными материалами.2. Уведомление «О новой версии материалов».

Выход:1. Уведомление «О необходимости доработки».2. Замечания по материалам Вопроса.

Шаг 9. Запустить процесс согласованияИсполнитель: Корпоративный секретарь.Действие:

1. Производит запуск процесса согласования по Вопроса повестки Мероприятия. Производится отправка уведомления «О необходимости согласовать материалы». Производится переход на Шаг 10.

Вход:1. Заполненная карточка процесса согласования.

Выход:1. Уведомление «О необходимости согласовать материалы».2. Повестка Мероприятия.

Шаг 10. Согласовать материалыИсполнитель: Ответственный за контент.Действие:

1. Производит ознакомление с содержанием Вопросов повестки Мероприятия. По каждому Вопросу повестки Мероприятия принимает решение – «Согласован», «Не согласован».

a. Если принимается решение «Согласован» по всем Вопросам повестки Мероприятия, производится переход на Шаг 11.

b. Если по некоторым Вопросам повестки Мероприятия принимается решение «Не согласован», производится переход на Шаг 8.

Вход:1. Задача на согласование.

Выход:1. Повестка мероприятия с материалами, согласованными ответственным за контент.2. Повестка мероприятия с материалами, не согласованными ответственным за

контент.Шаг 11. Согласовать материалыИсполнитель: Ответственный за форму.Действие:

1. Производит ознакомление с содержанием Вопросов повестки Мероприятия. По каждому Вопросу повестки Мероприятия принимает решение – «Согласован», «Не согласован».

Вход:1. Задача на согласование.

Выход:1. Повестка мероприятия с согласованными материалами.2. Повестка мероприятия с несогласованными материалами.

Шаг 12. Создать уведомление «Об окончании приема материалов после публикации»Исполнитель: Корпоративный секретарь.Действие:1. Если принимается решение «Согласован» по всем Вопросам повестки Мероприятия, и

необходимо уведомить Ответственных по Вопросам об окончании приема материалов, производится производит создание из шаблона уведомления «Об окончании приема материалов после публикации».

a. Если на момент получения уведомления у Ответственного за вопрос существует новая версия материала, производится переход на Шаг 6.

b. Если на момент получение уведомления у Ответственного за вопрос нет новой версии:

i. Если наступил срок публикации, есть неподготовленные вопросы, производится переход на Шаг 5.

ii. Если нет неподготовленных вопросов, но были добавлены дополнительные вопросы, производится переход на Шаг 14.

iii. Если нет неподготовленных вопросов, не были добавлены дополнительные вопросы, производится переход на Шаг 17.

iv. Если не наступил срок публикации, есть неподготовленные вопросы, производится переход на Шаг 13.

Вход:1. Повестка Мероприятия с согласованными материалами.

Выход:1. Уведомление «Об окончании приема материалов после публикации».

Шаг 13. Отправить уведомления ответственнымИсполнитель: Корпоративный секретарь.Действие:

1. Производит создание уведомления Ответственным за вопрос, не выполнившим подготовку материалов. Производит переход на Шаг 16.

Вход:1. Повестка Мероприятия.

Выход:1. Уведомление «Об истечении срока подготовки».

Шаг 14. Внести вопросы в повестку.Исполнитель: Корпоративный секретарь.Действие:

1. Производит создание карточек Вопросов в повестке Мероприятия. Должны быть заполнены обязательные поля Название вопроса и Докладчик. Производится переход на Шаг 15.

Вход:1. Список незапланированных Вопросов.

Выход:1. Неподготовленные вопросы в повестке Мероприятия.

Шаг 15. Создать из шаблона уведомление «О начале подготовки».Исполнитель: Корпоративный секретарь.Действие:

1. Создает в Системе новое уведомление типа «О начале подготовки» для Вопроса Повестки дня. Производит корректировку значений полей карточки уведомления: Текст уведомления (текстовое информационное поле, включающее текст уведомления и URL-ссылки на материалы на ресурсах Заказчика), Сроки выполнения задачи. Производится переход на Шаг 13.

Вход:1. Неподготовленные вопросы в повестке Мероприятия.

Выход:1. Уведомление «О начале подготовки».

Шаг 16. Загрузить материалы в систему.Исполнитель: Ответственный по вопросу.Действие:

1. Производит добавление материалов, их категоризацию, добавление версий на дополнительных языках. Производится переход на Шаг 17.

Вход:1. Уведомление «О начале подготовки».

Выход:1. Уведомление «О новой версии материалов».

Шаг 17. Опубликовать материалы.Исполнитель: Корпоративный секретарь.Действие:

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

a. Если необходимо разместить уведомить «О готовности материалов», производится переход на Шаг 18.

b. Если не требуется размещение уведомления «О готовности материалов», производится завершение процесса.

Вход:1. Уведомление «О новой версии материалов».

Выход:1. Опубликованная повестка Мероприятия.

Шаг 18. Внести проекты решенийИсполнитель: Корпоративный секретарь.Действие:

1. Производит добавление Проектов решений из согласованного файла типа «Пояснительная записка». Производится переход на Шаг 19.

Вход:1. Опубликованная повестка Мероприятия.

Выход:1. Вопрос с добавленными Проектами решения.

Шаг 19. Создать из шаблона уведомление «О готовности материалов»Исполнитель: Корпоративный секретарь.Действие:

1. Создает в Системе новое уведомление типа «О готовности материалов» для Вопроса Повестки дня. Производит корректировку значений полей карточки уведомления. Производится переход на Шаг 20.

Вход:1. Вопрос с добавленными Проектами решения.

Выход:1. Карточка уведомления «О готовности материалов» с заполненными данными.

Шаг 20.Разослать уведомления участникам мероприятия.Исполнитель: Корпоративный секретарь.Действие:

1. Производит рассылку уведомления всем пользователям, указанным в карточке уведомления. Производится завершение процесса.

Вход:1. Карточка уведомления «О готовности материалов» с заполненными данными.

Выход:1. Уведомление «О готовности материалов».

5.2.3 Проведение мероприятий органа управления

Под процессом проведения мероприятий органа управления понимается процесс рассмотрения вопросов повестки мероприятия, включающий ознакомление с прикрепленными материалами и волеизъявление участников. В Системе должна быть реализована возможность одновременного проведения нескольких мероприятий – заседаний органа управления.В процессе Подготовки Мероприятий органа управления должны принимать участие следующие Роли:Описание процесса представлено в двух разделах:

1. Пошаговое описание процесса.2. Графическое представление процесса.

5.2.3.1 Графическое описание процесса

5.2.3.2 Пошаговое описание процесса

Процесс проведения мероприятий состоит из следующих шагов:1. Отметить присутствующих.2. Подключиться к системе.3. Начать рассмотрение вопроса.4. Запустить трансляцию.5. Ознакомиться с материалами.6. Добавить аннотацию.7. Отредактировать проекты решения.8. Запустить голосование по вопросу.9. Проголосовать по вопросу.10. Принять решение по вопросу.11. Завершить заседание.12. Добавить версию протокола.13. Отправить протокол на согласование.14. Согласовать протокол.15. Опубликовать протокол.

Шаг 1. Отметить присутствующих (для очного мероприятия)Исполнитель: Корпоративный секретарь.Действие:

1. Отмечает Участников, присоединившихся к мероприятию.2. Вне рамок Системы производит проверку кворума.

a. Если кворум не соблюден и возможно ожидание участников, производится переход на Шаг 1.

b. Если кворум не соблюден и истек срок ожидания участников, производится завершение Мероприятия.

c. Если кворум соблюден, производится переход на Шаг 3.Вход:

1. Мероприятие в статусе «Проводится».Выход:

1. Список участников, фактически присутствующих на мероприятии.2. Мероприятие в статусе «Закрыто».

Шаг 2. Подключиться к системеИсполнитель: Участник мероприятия с правом голоса, Приглашенный участник мероприятия, Председатель.Действие:

1. Производит вход в Систему одним из следующих способов: связка логин-пароль (в том числе доменная аутентификация при помощи службы каталогов Active Directory), по сгенерированному ПИН-коду, «методом Рассадки». В результате успешного входа в Систему производится переход на Шаг 3.

Вход:1. Мероприятие в статусе «Проводится».

Выход:1. Аутентифицированный пользователь Системы.

Шаг 3. Начать рассмотрение вопросаИсполнитель: Корпоративный секретарь.Действие:

1. Запускает рассмотрение Вопроса повестки мероприятия. Вопрос переводится в статус «Рассматривается». Производится переход на Шаг 4.

Вход:1. Мероприятие в статусе «Проводится».2. Вопрос повестки мероприятия в статусе «Опубликован».

Выход:1. Вопрос повестки мероприятия в статусе «Проводится».

Шаг 4. Запустить трансляциюИсполнитель: Докладчик.Действие:

1. Запускает трансляцию материалов Вопроса повестки мероприятия. Участникам мероприятия доступна трансляция в ручном и синхронном режиме просмотра. Производится переход на Шаг 5.

Вход:1. Вопрос повестки мероприятия в статусе «Проводится».

Выход:1. Запущена трансляция материалов вопроса повестки мероприятия.

Шаг 5. Ознакомиться с материаламиИсполнитель: Участник мероприятия.Действие:

1. Производит ознакомление с материалами по рассматриваемому Вопросу.a. Если требуется добавление аннотации по Материалам, производится

переход на Шаг 6.b. Если не требуется добавление аннотации по Материалам, производится

переход на Шаг 1,7,8,11 в зависимости от выполнения условий.Вход:

1. Запущена трансляция материалов вопроса повестки мероприятия.Выход:

1. Запущена трансляция материалов вопроса повестки мероприятия.Шаг 6. Добавить аннотациюИсполнитель: Участник мероприятия.Действие:

1. Производит добавление личной или публичной аннотации к файлам материала Вопроса повестки мероприятия. Производится переход на Шаг 3,7,8,10 в зависимости от выполнения условий.

Вход:1. Запущена трансляция материалов вопроса повестки мероприятия.

Выход:1. Личная или публичная аннотация к файлам материала Вопроса повестки

мероприятия.Шаг 7. Отредактировать проекты решенияИсполнитель: Корпоративный секретарь.Действие:

1. Выполняется если в Системе необходимо выполнить голосование по вопросу, но в ходе мероприятия возникла необходимость в редактировании проектов решений. Выполняется корректировка формулировки, производится переход на Шаг 8.

Вход:1. Запущена трансляция материалов вопроса повестки мероприятия.2. Личная или публичная аннотация к файлам материала Вопроса повестки

мероприятия.3. Решение о необходимости корректировки проектов решений (вне рамок Системы).

Выход:1. Вопрос повестки мероприятия с изменёнными формулировками проектов решений.

Шаг 8. Запустить голосование по вопросуИсполнитель: Корпоративный секретарь.Действие:

1. Запускает голосование по Вопросу повестки мероприятия. Вопрос переводится в статус «На голосовании». Производится переход на Шаг 9.

Вход:1. Запущена трансляция материалов вопроса повестки мероприятия.2. Личная или публичная аннотация к файлам материала Вопроса повестки

мероприятия.3. Вопрос повестки мероприятия с изменёнными формулировками проектов решений.

Выход:1. Вопрос повестки мероприятия в статусе «На голосовании».

Шаг 9. Проголосовать по вопросуИсполнитель: Участник мероприятия.Действие:

1. Принимает решение по Вопросу в зависимости от сценария мероприятия:a. Голосует по формулировкам проектов решений и пунктам проектов

решений. Должны быть доступны варианты «ЗА», «ПРОТИВ», «ВОЗДЕРЖАЛСЯ». При необходимости, производит добавление текстового комментария - Особого мнения.

b. Голосует по вопросу в целом. Должны быть доступны варианты «ЗА», «ПРОТИВ», «ВОЗДЕРЖАЛСЯ». При необходимости, производит добавление текстового комментария - Особого мнения.

2. Производится переход на Шаг 10.Вход:

1. Вопрос повестки мероприятия в статусе «На голосовании».2. Вопрос повестки мероприятия с изменёнными формулировками проектов решений.

Выход:1. Голоса по Вопросу повестки мероприятия».

Шаг 10. Принять решения по вопросуИсполнитель: Корпоративный секретарь.Действие:

1. Производит ознакомление с результатами голосования. a. Если производилось голосование, принимает решение по Вопросу: Принят,

Отклонен. Производит смену статуса Вопроса в статус «Закрыт (Принято решение)».

b. Если не производилось голосование, производит перевод Вопроса в статус «Закрыт (Рассматривался).

2. Затемa. Если принято решение по всем Вопросам повестки мероприятия,

производится переход на Шаг 11.b. Если принято решение не по всем Вопросам повестки мероприятия,

производится переход на Шаг 3. Вход:

1. Вопрос повестки мероприятия в статусе «На голосовании».2. Голоса по Вопросу повестки мероприятия».

Выход:1. Вопрос в статусе «Закрыт (Принято решение)».2. Вопрос в статусе «Закрыт (Обсуждался)».3. Принято решение по всем вопросам повестки мероприятия.

Шаг 11. Завершить мероприятиеИсполнитель: Корпоративный секретарь.Действие:

1. Производит смену статуса Мероприятия на «Проведено». Опционально производится отправка уведомления Секретарю «О необходимости сформировать протокол». Производится переход на Шаг 12.

Вход:1. Принято решение по всем вопросам повестки мероприятия.

Выход:1. Мероприятие в статусе «Проведено».

Шаг 12. Добавить версию протоколаИсполнитель: Корпоративный секретарь.Действие:

1. Производит добавление в Систему версии Протокола мероприятия.a. Если требуется согласование версии Протокола, производится переход на

Шаг 13.b. Если не требуется согласование версии Протокола, производится переход на

Шаг 15.Вход:

1. Мероприятие в статусе «Проведено».2. Уведомление «О необходимости сформировать протокол».

Выход:1. Неопубликованный протокол мероприятия.2. Протокол мероприятия.

Шаг 13. Отправить протокол на согласованиеИсполнитель: Корпоративный секретарь.Действие:

1. Производит настройку процесса согласования, затем передает неопубликованный протокол мероприятия на согласование. Производится переход на Шаг 13.

Вход:

1. Неопубликованный протокол мероприятия.Выход:

1. Задача на согласование протокола мероприятия.Шаг 14. Отправить протокол на согласованиеИсполнитель: Председатель органа управления, участник процесса согласования протокола.Действие:

1. Производит ознакомление с содержанием протокола мероприятия и принимает решение о согласовании.

a. Если протокол успешно согласован, производится переход на Шаг 13.b. Если есть замечания по протоколу, производится переход на Шаг 12.

Вход:1. Задача на согласование протокола мероприятия.

Выход:1. Протокол мероприятия.2. Несогласованный протокол мероприятия.

Шаг 15. Опубликовать протоколИсполнитель: Корпоративный секретарь.Действие:

1. Производит публикацию протокола мероприятия. Опубликованный протокол доступен для просмотра всем участникам мероприятия.

Вход:1. Протокол мероприятия.

Выход:1. Опубликованный протокол мероприятия.

5.3 ТРЕБОВАНИЯ К ФУНКЦИЯМ (ЗАДАЧАМ), ВЫПОЛНЯЕМЫМ СИСТЕМОЙ

5.3.1 Требования к структуре корпоративного управления

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

Таблица 5.2 - Требования к структуреУровень Название Описание1 Группа юридических лиц Список юридических лиц, входящих в структуру

корпоративного управления Заказчика2 Юридическое лицо Организация, входящая в группу юридических

лиц организации Заказчика, содержащая список органов управления

3 Орган управления Организационная единица юридического лица из группы юридических лиц организации Заказчика, ответственная за принятие решений.

Рисунок 5.4 - Структура корпоративного управления

5.3.2 Требования к поддерживаемым языкам

Система должна поддерживать работу с интерфейсом и контентом на нескольких языках.5.3.2.1 Требования к языку интерфейса

Интерфейс Web и iPad приложения Системы должен поддерживать русский и английский языки. Пользователи Системы должны иметь возможность выбора языка интерфейса без необходимости обращения к Администратору Системы.В Системе должна присутствовать возможность указания администратором языка интерфейса по умолчанию для каждого пользователя Системы.5.3.2.2 Требования к языку контента

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

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

5.3.3 Требования к информационным объектам системы

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

1. Мероприятие.2. Вопрос.3. Проект решения.4. Пункт проекта решения.5. Карточка материала.6. Файл материала.7. Поручение.

В настоящем разделе представлены требования к параметрам и статусам информационных объектов Системы.Параметры, которые должны быть обязательно указаны при создании информационных объектов отмечены символом «*».Окончательный список атрибутов объектов будет уточнен или расширен на этапе технического проектирования.5.3.3.1 Требования к информационному объекту типа «Мероприятие»

Информационный объект типа «Мероприятие» должен содержать атрибуты объекта, а также список ассоциированных информационных объектов типа «Вопрос», формирующих повестку Мероприятия, а также список Участников.5.3.3.1.1 Список атрибутов информационного объекта типа «Мероприятие»

Информационный объект типа «Мероприятие» должен содержать следующие атрибуты:

Таблица 5.3 — Список атрибутов объекта «Мероприятие»Атрибут ОписаниеОрган управления* Ссылка на объект типа «Орган управления», а рамках которого

производится работа над объектомВид мероприятия* Содержит одно из следующих значений:

Очное. Заочное.

Дата* Дата, на которую назначено мероприятие. Поле должно быть доступно при выборе типа Мероприятия «Очное»

Время начала Время начала Мероприятия типа «Очное»Место Место проведения Мероприятия типа «Очное»Дата начала приема голосов*

Дата начала приема голосов по Проектам решения связанных информационных объектов типа «Вопрос» Участников с правом голоса Мероприятия типа «Заочное»

Дата окончания приема голосов*

Дата завершения приема голосов по Проектам решения связанных информационных объектов типа «Вопрос» Участников с правом голоса Мероприятия типа «Заочное»

Дата окончания приема материалов

Дата, до которой необходимо опубликовать Материалы по Вопросам Повестки для Участников Мероприятия

Дата начала подготовки

Дата, за которую необходимо начать подготовку Вопросов Повестки

Статус Статус информационного объекта типа «Мероприятие»Повестка Список ссылок, ассоциированных с МероприятиемУчастники Список пользователей, имеющих доступ к объекту, в

соответствии с правами роли, в которой они выступают в Органе управления.В зависимости от прав, переданных участникам на уровне информационного объекта типа «Орган управления», Участники должны принимать следующие роли:

Секретарь мероприятия. Председатель мероприятия. Постоянный участник мероприятия с правом голоса. Постоянный участник мероприятия без права голоса. Приглашенный участник мероприятия (без права

голоса).

5.3.3.1.2 Список статусов информационного объекта типа «Мероприятие»

Для информационного объекта типа «Мероприятие» должны быть определены следующие статусы:

Таблица 5.4 — Список статусов объекта «Мероприятие»Статус ОписаниеЧерновик Статус «Черновик» должен использоваться для редактирования

карточки информационного объекта типа «Мероприятие» и формирования списка связанных информационных объектов типа «Вопрос».Присваивается Системой автоматически при создании нового информационного объекта типа «Мероприятие».Для информационного объекта «Мероприятие» в статусе «Черновик» должны предоставляться права на чтение и редактирование для Секретаря мероприятия, либо для членов секретариата. В списках Системы для Участников Мероприятия должен отображаться факт запланированного мероприятия без возможности перехода к содержанию

Запланировано Статус «Запланировано» должен использоваться для подготовки содержания Мероприятия ответственными сотрудниками.Статус должен устанавливаться пользователем, обладающим правами на операцию смены статуса информационного объекта типа «Мероприятие». По умолчанию права должны быть присвоены роли «Секретарь мероприятия».Объект становится доступен всем пользователям Системы, обладающим правами на просмотр информационного объекта типа «Мероприятие» и любого из объектов, входящих в состав информационного объекта типа «Мероприятие».

Проводится Статус «Проводится» должен использоваться для рассмотрения

Статус Описаниеи голосования по Вопросам Повестки Мероприятия.Должен устанавливаться пользователем, обладающим правами на операцию смены статуса информационного объекта типа «Мероприятие». По умолчанию права должны быть присвоены роли «Секретарь мероприятия».

Проведено Статус «Проведено» должен использоваться для отражения факта проведения Мероприятия, формирования, согласования и публикации Протокола Мероприятия.Должен устанавливаться пользователем, обладающим правами на операцию смены статуса информационного объекта типа «Мероприятие». По умолчанию права должны быть присвоены Секретарю мероприятия.На статусе «Проведено» информационный объект типа «Мероприятие» должен быть защищен от редактирования всех Участников Мероприятия, кроме Секретаря Мероприятия.

Закрыто Статус «Закрыто» должен использоваться для отображения Мероприятия, которое было проведено и по которому были выполнены действия по формированию, согласованию и публикации Протокола.Должен устанавливаться пользователем, обладающим правами на операцию смены статуса информационного объекта типа «Мероприятие». По умолчанию права должны быть присвоены Секретарю мероприятия.На статусе «Закрыто» информационный объект типа «Мероприятие» должен быть защищен от редактирования всех Участников Мероприятия, кроме Секретаря Мероприятия.

Система должна позволять редактировать права на чтение и редактирование для ролей Системы при помощи Ролевой модели.5.3.3.2 Требования к информационному объекту типа «Вопрос»

Информационный объект типа «Вопрос» должен содержать атрибуты объекта, а также список ассоциированных информационных объектов типа «Материал» и «Проект решения».5.3.3.2.1 Список параметров информационного объекта типа «Вопрос»

Информационный объект типа «Вопрос» должен содержать следующие атрибуты:

Таблица 5.5 — Список атрибутов объекта «Вопрос»Атрибут ОписаниеНаименование вопроса*

Текстовое поле, содержащее название вопроса

Ответственный (докладчик) по вопросу*

Пользователь Системы, ответственный за подготовку Материалов и выступление по Вопросу

Категория Метка вопроса. Выбирается из справочника категорий СистемыОрган управления Ссылка на информационный объект типа «Орган управления»,

с которым ассоциирован данный Вопрос. При создании объекта из интерфейса Мероприятия

Мероприятие Ссылка на информационный объект типа «Мероприятие», с

Атрибут Описаниекоторым ассоциирован данный Вопрос

Статус Статус информационного объекта типа «Вопрос»Проекты решения Список информационных объектов типа «Проект решения»,

ассоциированных с ВопросомМатериалы Список информационных объектов типа «Материал»,

ассоциированных с ВопросомУчастники Это список пользователей, которые находятся в той или иной

роли по отношению к Вопросу. По умолчанию должен наследоваться от списка Участников связанного информационного объекта типа «Мероприятие»

Комментарий Список личных сообщений, привязанных к данному объектуСвязанный вопрос Ссылка на информационный объект типа «Вопрос», с которым

ассоциирован данный ВопросФлаг «Отложенное голосование»

Переключатель, позволяющий выполнить отложенное голосование по Вопросу в ходе процесса проведения Мероприятия в очной форме для случая, когда Участниками Мероприятия было принято положительное решение, но содержание информационного объекта типа «Вопрос» требует доработки

Флаг «Проверка аффилированности»

Переключатель, позволяющий заблокировать доступ к информационному объекту для всех участников Органа управления, у которых установлен атрибут «Аффилированность»

Флаг «Голосование по пунктам проекта решения»

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

5.3.3.2.2 Список статусов информационного объекта типа «Вопрос»

Для информационного объекта типа «Вопрос» должны быть определены следующие статусы:

Таблица 5.6 — Список статусов объекта «Вопрос»Статус ОписаниеЧерновик Статус «Черновик» должен использоваться для редактирования

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

Ответственный (докладчик) по Вопросу. Секретарь КО.

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

Статус Описаниевозможности просмотра содержания Вопроса

Опубликован Должен устанавливаться пользователем, обладающим правами на публикацию информационного объекта типа «Вопрос». По умолчанию права должны быть присвоены Секретарю мероприятия.Объект становится доступен всем пользователям Системы, обладающими правами на просмотр объектов, входящих в состав информационного объекта типа «Мероприятие»

Рассматривается Должен устанавливаться пользователем, обладающим правами на операцию смены статуса информационного объекта типа «Вопрос». По умолчанию права должны быть выданы Секретарю мероприятия.Статус должен использоваться для индикации рассматриваемого Вопроса Повестки в процессе визуального выделения рассматриваемого Вопроса из общего списка вопросов повестки

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

Закрыт (Принято решение / Обсуждался / Не рассматривался)

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

Секретарь мероприятия. Администратор Системы.

Для Участников мероприятия (постоянных и приглашенных) и Ответственному за подготовку вопроса должен быть предоставлен доступ на чтение информационного объекта типа «Вопрос» и вложенных сущностей без права редактирования.

Принят с учетом замечаний

Должен устанавливаться пользователем, обладающим правами на редактирование статуса информационного объекта типа «Вопрос». По умолчанию права должны быть присвоены Секретарю мероприятия.

Статус ОписаниеСтатус должен использоваться для индикации отложенного голосования по Вопросу, когда в ходе процесса проведения Мероприятия было принято положительное решение, но содержание информационного объекта типа «Вопрос» требует доработки.Для информационного объекта «Вопрос» в статусе «Закрыт (принято решение)» должны предоставляться права на чтение и редактирование для следующих ролей Системы:

Секретарь мероприятия. Администратор Системы Ответственный за вопрос.

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

Система должна позволять редактировать права на чтение и редактирование для ролей Системы при помощи Ролевой модели.5.3.3.3 Требования к информационному объекту типа «Проект решения»

Информационный объект типа «Проект решения» содержать основные атрибутыобъекта, и ассоциированный с объектом набор информационных объектов типа «Пункт проекта решения».Информационный объект типа «Проект решения» должен содержать следующие Атрибуты:

Таблица 5.7 — Список атрибутов объекта «Проект решения»Атрибутов ОписаниеТип* Содержит одно из следующих значений:

Текст. Файл.

При выборе типа «Текст» используется текстовый формат отображения информационного объекта типа «Проект решения».При выборе типа «Файл» используется формат отображения информационного объекта типа «Проект решения» в виде файла следующих форматов:

PDF. Microsoft Office (doc, docx, xls, xlsx, ppt, pptx).

Вопрос Информационный объект типа «Вопрос», с которым ассоциирован Проект решения

Формулировка* Текстовая формулировка проекта решения. Поле должно быть доступно при выборе типа Проекта решения «Текст»

Название проекта решения*

Текстовое поле, содержащее название Проекта решения. Поле должно быть доступно при выборе типа Проекта решения «Файл»

Результат голосования Таблица, содержащая результат голосования («За», «Против», «Воздержался») всех Участников с правом голоса

Атрибутов Описаниеинформационного объекта «Мероприятие», в рамках которого производится процесс голосования

Связанное поручение Информационный объект типа «Поручение», ассоциированный с Проектом решения

Пункт проекта решения

Список информационных объектов типа «Пункт проекта решения», ассоциированных с Проектом решения. Привязка объекта должна быть доступна при выборе типа Проекта решения «Текст»

5.3.3.4 Требования к информационному объекту типа «Пункт проекта решения»

Информационный объект типа «Пункт проекта решения» должен содержащую основные атрибуты объекта, и связь с информационным объектом типа «Проект решения».Информационный объект типа «Пункт проекта решения» должен содержать следующие атрибуты:

Таблица 5.8 — Список атрибутов объекта «Пункт проекта решения»Атрибутов ОписаниеФормулировка* Текстовая формулировка пункта проекта решенияПроект решения Информационный объект типа «Проект решения», с которым

связан Пункт проекта решенияРезультат голосования Таблица, содержащая результат голосования («За», «Против»,

«Воздержался») всех Участников с правом голоса информационного объекта «Мероприятие», в рамках которого производится процесс голосования

Связанное поручение Информационный объект типа «Поручение», привязанный к Проекту решения

5.3.3.5 Требования к информационному объекту типа «Материал»

Информационный объект типа «Материал» должен представлять собой карточку, содержащую атрибуты объекта, и привязанный к карточке набор файлов.5.3.3.5.1 Список атрибутов информационного объекта типа «Материал»

Информационный объект типа «Материал» должен содержать следующие атрибуты:

Таблица 5.9 — Список атрибутов объекта «Материал»Атрибут ОписаниеНаименование Текстовое поле, содержащее название материалаДокумент Файл, ассоциированный с данным материалом. К материалу

может быть прикреплено несколько файловКатегория Метка материала. Выбирается из справочника категорий

СистемыСтатус Статус информационного объекта типа «Материал»Комментарий Список личных сообщений, ассоциированных с материалом

5.3.3.5.2 Список статусов информационного объекта типа «Материал»

Для информационного объекта типа «Материал» должны быть определены следующие статусы:

Таблица 5.10 — Список статусов объекта «Материал»Статус ОписаниеЧерновик Присваивается Системой автоматически при создании нового

информационного объекта типа «Материал».Для информационного объекта «Материал» в статусе «Черновик» должны предоставляться права на чтение и редактирование для следующих ролей Системы:

Ответственный по Вопросу, в рамках которого производится подготовка материалов.

Секретарь мероприятия.Статус «Черновик» должен использоваться для загрузки рабочих версий файлов и редактирования карточки информационного объекта типа «Материал».

На согласовании Присваивается Системой автоматически при создании задания на согласование содержания карточки информационного объекта типа «Материал».

Статус ОписаниеДля информационного объекта «Материал» в статусе «На согласовании» должны предоставляться права на чтение и редактирование для следующих ролей Системы:

Ответственный по Вопросу, в рамках которого производится подготовка материалов.

Секретарь мероприятия. Ответственный за контент. Ответственный за форму.

Статус «На согласовании» должен использоваться для индикации запущенного процесса согласования материалов

Опубликован Должен устанавливаться пользователем, обладающим правами операцию смены статуса информационного объекта типа «Материал».Объект становится доступен всем пользователям Системы, обладающими правами на просмотр объектов, входящих в состав информационного объекта типа «Мероприятие».

Система должна позволять редактировать права на чтение и редактирование для ролей Системы при помощи Ролевой модели.5.3.3.6 Требования к информационному объекту типа «Файл»

Информационный объект типа «Файл» ассоциируется с карточкой информационного объекта типа «Материал». Права на просмотр и изменение объекта «Файл» должны наследоваться в зависимости от статуса связанного информационного объекта типа «Материал».5.3.3.6.1 Список атрибутов информационного объекта типа «Файл»

Информационный объект типа «Файл» должен содержать следующие атрибуты:

Таблица 5.11 — Список атрибутов объекта «Файл»Атрибут ОписаниеНаименование Наименование файлаФайл Документ в одном из следующих форматов:

PDF. Форматы Microsoft Office (doc, docx, xlx, xlsx, ppt, pptx). Прочие форматы (без возможности просмотра в

Системе).Язык Используется для языковой идентификации файла при работе

Системы в мультиязычном режимеВерсия Номер версии файла, загруженной в Систему.

Нередактируемое поле. Значение устанавливается Системой автоматически

Тип файла Содержит одно из следующих значений: Пояснительная записка. Презентация. Приложение.

Дата добавления Дата добавления в Систему последней версии файлаСтатус Статус информационного объекта

Атрибут ОписаниеТэг Список ключевых слов, добавленных к объекту, используемых

для поиска в Системе

5.3.3.6.2 Список статусов информационного объекта типа «Файл»

Для информационного объекта типа «Файл» должны быть определены следующие статусы:

Таблица 5.12 — Список статусов объекта «Файл»Статус ОписаниеНовый Присваивается Системой автоматически при добавлении

нового файла, либо новой версии файла, к карточке информационного объекта типа «Материал».

На согласовании Присваивается Системой автоматически при отправке связанного информационного объекта типа «Материал» на согласование

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

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

5.3.3.7 Требования к объекту системы типа «Поручение»

5.3.3.7.1 Список атрибутов информационного объекта типа «Поручение»

Объект типа «Поручение» должен содержать в себе следующие параметры:

Таблица 13. Список атрибутов объекта типа «Поручение»Атрибут ОписаниеНазвание Название поручения должно представлять собой текстовое поле.Формулировка Формулировка поручения должна представлять собой текстовое

полеДата постановки Данный параметр должен представлять собой дату, в которую

создан данный объектПлановая дата Данный параметр должен представлять собой дату, до которой

необходимо исполнить данное поручениеОтветственный Пользователь, который отвечает за выполнение поручения

Контролер Пользователь, который отвечает за проверку порученияТип по контролю Тип поручения по контролю. Данный параметр должен

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

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

Статус Статус жизненного цикла для данного объектаМатериалы Список объектов системы типа «материал», привязанных к

поручению.Записи о ходе исполнения

Записи о ходе исполнения поручения должны представлять собой таблицу, содержащую текстовые записи, автора записи и дату

создания записи.Связанные поручения

Список объектов системы типа «поручение», привязанных к данному поручению

Комментарии Список личных сообщений, привязанных к данному объекту

5.3.3.7.2 Создание поручения и контроль его исполнения

5.3.3.7.2.1 Формирование поручений по исполнению решений органа управления

По получении протокола курирующие топ-менеджеры готовят проект поручений по исполнению решений органа управления, который в отношении каждого поручения содержит следующую информацию:Вопрос, по которому принято решение, на исполнение которого направлена реализация описываемого поручения;

Решение органа управления, на исполнение которого направлена реализация описываемого поручения;

Формулировка поручения, начинающаяся с глагола совершенного вида; Срок исполнения поручения; Инициатор поручения; Контролёр, проверяющий результаты исполнения поручения; Ответственный исполнитель за исполнение поручения (сотрудник компании с

указанием должности и ФИО); Другие исполнители поручения (опционально); Связь поручения с другими поручениями, направленными на исполнение

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

1.

2.

3.

4.

4.1.

4.2.

4.3.

4.4.

4.5.

4.6.

4.7.

4.8.

4.8.1.5.3.3.7.2.2 Контроль исполнения поручений по исполнению решений органа

управления

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

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

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

поручений по исполнению решений органа управления

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

решений органа управления

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

5.3.4 Требования к способам аутентификации

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

Должна быть предусмотрена возможность аутентификации посредством службы каталогов Active Directory.

В Системе должен быть реализован один из следующих дополнительных способов аутентификации:

1. Аутентификация с использованием ПИН-кода.

Способ аутентификации должен использоваться для Мероприятий типа «Очное» для переговорных комнат с фиксированным количеством устройств. В Системе должен быть реализован экран, позволяющий производить генерацию уникальных ПИН-кодов всех участников Мероприятия (постоянных и приглашенных) в файл формата MS Excel.

2. Аутентификация участников Ответственным сотрудником.Способ аутентификации должен использоваться для Мероприятий типа «Очное» для переговорных комнат с фиксированным количеством устройств. В Системе должен быть реализован экран, позволяющий резервировать устройство в переговорной комнате для конкретного участника. Возможны следующие сценарии работы:1. Ответственный сотрудник (Администратор мероприятия) заранее производит

размещение участников по соответствующим устройствам. В момент начала Мероприятия типа «Очное» пользователь Системы подходит к устройству, на

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

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

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

5.3.5 Требования к блоку уведомлений

В Системе должен быть разработан Блок уведомлений, выполняющий рассылку следующих видов уведомлений:

1. Информационные уведомления.2. Напоминания.3. Уведомления типа SmartText.

5.3.5.1 Требования к информационным уведомлениям

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

В Системе должна быть предусмотрена возможность отправки уведомлений по следующим каналам:

1. Система уведомлений внутри приложения.2. Почтовым сообщением на электронный адрес.3. Push-уведомлением на iPad с установленным Мобильным приложением Системы.

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

При отправке нового уведомления Система должна обеспечить редактирование списка получателей уведомлений, текста уведомления и каналов отправки.

В Системе должны быть разработаны шаблоны уведомлений. В интерфейсе Системы должна присутствовать возможность редактировать шаблоны уведомлений.

5.3.5.2 Требования к уведомлениям типа «Напоминание»

В Системе должен быть реализован механизм уведомлений типа «Напоминание». Напоминания должны активироваться Ответственным сотрудником на этапе создания информационных объектов Системы.Напоминания представляют собой уведомления, отсылаемые указанным адресатам с целью информирования о наступлении срока выполнения задач в рамках процессов подготовки и проведения Мероприятий Органа управления. Настройка сроков, за которые производится отправка напоминаний, должна производиться на уровне Органа управления.При скором наступлении установленных сроков в параметрах Мероприятия, у Секретаря мероприятия должно быть отображено предложение об отправке соответствующего Напоминания.В Системе должны быть разработаны шаблоны напоминаний. В интерфейсе Системы должна присутствовать возможность редактировать шаблоны напоминаний.

В Системе должна быть предусмотрена возможность отправки уведомлений по следующим каналам:

1. Система уведомлений внутри приложения.2. Почтовым сообщением на электронный адрес.3. Push-уведомлением на iPad с установленным Мобильным приложением Системы.

При получении Напоминания по Системе уведомлений внутри приложения в интерфейсе Системы должны быть реализованы следующие варианты:

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

времени, установленный в конфигурации Системы.5.3.5.3 Требования к уведомлениям типа «SmartText»

В Системе должен быть реализован механизм уведомлений типа «SmartText». В рамках данного механизма на экране информационного объекта должен находиться элемент блока уведомлений, отображающий текущую информацию об объекте. 5.3.6 Требования к добавлению связи между Вопросами

Система должна предоставить возможность добавлять связи между информационными объектами типа «Вопрос». Должно быть обеспечено создание связи для следующих сценариев:

1. Создание связи с существующим Вопросом текущего, либо любого другого Органа управления Системы, при наличии соответствующих прав доступа у лица, выполняющего привязку Вопросов.

2. Создание на основе текущего Вопроса связанного Вопроса с последующим предложением созданного Вопроса на рассмотрение в другой Орган управления.

В результате выполнения операции по добавлению связи в карточках связанных информационных объектов типа «Вопрос» должна появиться ссылка для взаимного перехода.В случае, если связанный Вопрос принадлежит другому Органу управления, информация должна отображаться в зависимости от прав просматривающего пользователя. 5.3.6.1 Требования к созданию связи с существующим Вопросом

В карточке информационного объекта «Вопрос» должно быть предусмотрено поле для добавления связи с существующим объектом «Вопрос». В зависимости от прав доступа, пользователь должен иметь возможность выполнить поиск Вопроса по текущему, либо любому другому Органу управления и отправить запрос на создание связи. Система должна уведомить Секретаря соответствующего Мероприятия о запросе на предоставление доступа. После подтверждения доступа, между карточками объектов должна быть создана связь.5.3.6.2 Требования к процедуре предложения Вопроса на рассмотрение

В Системе должна присутствовать возможность предложить существующий Вопрос в повестку Мероприятия текущего, либо любого другого Органа управления Системы. В результате выполнения операции в Системе должен быть создан новый информационный объект типа «Вопрос». В новый объект типа «Вопрос» должен быть передан параметр «Наименование вопроса». В поле «Ответственный по вопросу» Система должна подставлять Секретаря Мероприятия, в состав которого был включен Вопрос.В интерфейсе предложения Вопроса должны присутствовать следующие опции:

1. Перенести проекты решения – в новый Вопрос будут перенесены существующие Проекты решения (включая Пункты проекта решения) без результатов голосования.

2. Перенести материалы – в новый Вопрос будут перенесены существующие опубликованные Материалы без истории согласования. Для перенесенных Материалов должен быть автоматически установлен статус «Черновик».

В созданном информационном объекте типа «Вопрос» должна быть автоматически добавлена связь с исходным Вопросом.Инициатору предложения Вопроса должно быть отображено предложение об отправке Секретарю мероприятия уведомления «О предложении Вопроса в повестку Мероприятия».5.3.6.3 Требования к просмотру содержания связанных Вопросов

Просмотр содержания связанных Вопросов должен регламентироваться следующими правилами:

1. Если Пользователь является Ответственным по Вопросу, либо Секретарем, при переходе к связанному Вопросу другого Органа управления, пользователю должен быть предоставлен доступ на просмотр параметров и всех вложений связанного Вопроса: Материалы, Проекты решения, результат голосования, комментарии.

2. Если Пользователь является Участником (постоянным или приглашенным) Мероприятия без прав на просмотр объектов Органа управления связанного Вопроса, в карточке связанного Вопроса должно быть отображено только название.

3. Если Пользователь является Участником (постоянным или приглашенным) Мероприятия с правами на просмотр объектов Органа управления связанного Вопроса, в карточке связанного Вопроса должен быть предоставлен доступ на просмотр параметров и всех вложений связанного Вопроса: Материалы, Проекты решения, результат голосования, комментарии.

В Системе должна реализована функция запроса на предоставление прав просмотра параметров и вложений связанного Вопроса.Система должна позволять редактировать права на чтение и редактирование для ролей Системы при помощи Ролевой модели.5.3.7 Требования к загрузке материалов

В Системе должна быть возможность добавления к Вопросам повестки Мероприятия информационный объект типа «Материал», представляющий собой контейнер для хранения файлов, необходимых для рассмотрения Вопроса.5.3.7.1 Требования к способам загрузки файлов

Система должна обеспечивать добавление в Материал файлов следующих типов:1. Пояснительная записка – используется для документа «Пояснительная записка»,

который содержит информацию о рассматриваемом Вопросе и список проектов решений данного Вопроса.

2. Презентация – используется для файлов, которые в дальнейшем планируется использовать в Трансляции в ходе проведения Мероприятия типа «Очное».

3. Приложение – используется для дополнительных файлов, которые должны быть предоставлены к Вопросу.

На экране информационного объекта «Вопрос» Web интерфейса Системы должны быть предусмотрены поля для добавления каждого вида файлов (см. Рис. 5.4). Система должна обеспечить добавление файлов следующими способами:

1. Через диалоговое окно файловой Системы. В интерфейсе должна быть создана кнопка <Загрузить>, позволяющая выполнить загрузку одного или нескольких файлов при помощи стандартного окна загрузки операционной системы.

2. Методом Drag-and-Drop. Система должна обладать возможностью переноса файлов из файловой системы устройства пользователя в соответствующую часть интерфейса Системы.

Рисунок 5.5 – Макет интерфейса добавления файлов

5.3.7.2 Требования к загрузке файлов на нескольких языках

Для каждого информационного объекта «Орган управления» должна быть реализована настройка, регламентирующая обязательное, либо необязательное использование Материалов по Вопросам повестки Мероприятий Органа управления на нескольких языках. Настройка в режиме «Включена» разрешает создание и отправку на согласование Материалов, для которых было выполнено обязательное добавление файлов типа «Пояснительная записка» и «Презентация» на всех используемых языках Органа управления.В интерфейсе добавления файлов к объекту «Материал» должен присутствовать переключатель, добавляющий отдельные поля для загрузки версий файлов на дополнительном языке способом Drag-and-Drop или при помощи диалогового окна файловой системы.Для случая, когда на уровне Органа управления активирована настройка, регламентирующая обязательное прикрепление версии на дополнительном языке, но на момент формирования материала пользователь не обладает всеми необходимыми файлами, в Системе должна быть реализована возможность добавить «файл-пустышку». При использовании «файла-пустышки» Система должна автоматически создать SmartText уведомление для Секретаря мероприятия о необходимости добавить файл перевода.5.3.7.3 Требования к наименованию материалов

Система должна обеспечивать прикрепление к информационному объекту типа «Вопрос» одного или нескольких Материалов.В случае, если по Вопросу необходимо прикрепить только один информационный объект типа «Материал», название Материала должно быть скрыто с интерфейса Системы.В случае, если по Вопросу необходимо прикрепить один и более объектов типа «Материал», объектам должен присваиваться параметр «Наименование материала» как «Материал N», где N – порядковый номер Материала в вопросе.

Интерфейс Системы должен поддерживать изменение пользователями с соответствующими правами автоматически сгенерированных названий материалов.5.3.7.4 Требования к наименованию файлов

Система должна автоматически подставлять в параметр «Наименование» информационного объекта типа «Файл» значение названия электронного документа в файловой системе пользователя без учета формата файла.Пример: Пояснительная записка.docx -> Пояснительная записка.5.3.7.5 Требования к версионированию

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

В Системе должен быть реализован механизм ограничения доступа к информационным объектам «Вопрос» и «Материал» аффилированных пользователей.

1. На уровне Органа управления для каждого участника Органа управления должен быть установлен логический атрибут «Аффилированность».

a. Если атрибут находится в положении «Да», для участника Органа управления должен быть заблокирован доступ к информационным объектам «Вопрос» и «Материал», для которых установлен атрибут «Проверка аффилированности». Вопрос с ограниченным доступом должен отображаться в Повестке Мероприятия без возможности перехода на экран Вопроса. Пользователь не должен участвовать в голосовании по заблокированному Вопросу.

b. Если атрибут установлен в положении «Нет», для участника Органа управления должны быть доступны все информационные объекты Органа управления, в зависимости от установленной роли.

Установка атрибута «Аффилированность» должна производиться пользователем с правами Администратора.

2. Пользователь с правами Секретаря мероприятия должен иметь возможность установить атрибут «Проверка аффилированности» для информационных объектов «Вопрос» и «Материал».При установке атрибута «Проверка аффилированности» для информационного объекта типа «Вопрос» Система должна автоматически выполнить установку признака «Аффилированность» для всех ассоциированных информационных объектов типа «Материал».

3. Пользователь с установленным атрибутом «Аффилированность» должен иметь право запросить доступ к конкретному информационному объекту у Секретаря Мероприятия в интерфейсе Системы.

5.3.9 Требования к механизму замещения

1. В Системе должен быть разработан механизм передачи прав одного пользователя Системы другому пользователю. Функционал замещения должен обеспечить передачу прав на выполнение следующих операций с информационными объектами Системы:Голосование по проектам решения повестки Мероприятия.

2. Права на редактирование информационных объектов, включая атрибуты, списки ассоциированных информационных объектов и редактирование статуса.

5.3.9.1 Требования к механизму замещения при голосовании

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

1. Выбор пользователя, являющегося замещающим для Участника органа управления, должен производиться Администратором Системы на уровне Органа управления.

2. В интерфейсе Системы должна автоматически устанавливаться информационная отметка напротив результата голосования пользователя, являющегося замещающим Участника органа управления. Например, Иванов И.И. – голос «ЗА» (зам.).

3. При одновременном голосовании Участника органа управления и Замещающего лица, приоритет должен отдаваться голосу Участника органа управления. Голос Замещающего лица учтен не будет.

5.3.9.2 Требования к механизму замещения для управления информационными объектами

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

В Системе должны быть реализованы шаблоны информационных объектов «Мероприятие», «Вопрос», «Материал», позволяющие производить автоматическое создание соответствующих информационных объектов и связей между ними согласно заранее внесенной информации.Шаблоны информационных объектов типа «Материал» должны обеспечивать возможность автоматического формирования списка участников согласования на основе заранее внесенной информации.5.3.11 Требования к функции согласования материалов

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

1. Согласовано.2. Не согласовано.

Интерфейс Системы должен предоставить возможность добавления текстового комментария по согласованию. При выборе варианта согласования «Не согласовано», текстовый комментарий должен добавляться обязательно.Система должна позволять производить согласование материалов с использованием и без использования электронной подписи.5.3.12 Требования к проведению трансляции

В Системе должен быть реализована функция проведения показа материалов на экранах Web и iPad интерфейсов Системы.

В трансляции должны участвовать прикрепленные к Материалу по Вопросу файлы типа «Презентация» форматов ppt, pptx, pdf.Запуск трансляции должен осуществляться из экрана Мероприятия. По умолчанию, ведущим трансляции должен устанавливаться Докладчик по вопросу.Система должна производить управление трансляцией при помощи кликера, либо iPad с установленным Мобильным приложением Системы.В Системе должно быть реализовано два режима просмотра материалов:

1. Синхронный просмотр.2. Ручное управление.

В режиме синхронного просмотра переключение слайдов производится синхронно с действиями Ведущего трансляции (по умолчанию – Докладчик по вопросу).В режиме ручного управления переключение слайдов производится пользователем Системы независимо от Ведущего трансляции с возможностью переключения на режим синхронного просмотра.При наличии версий на нескольких языках, Система должна выполнять трансляцию на нескольких языках. Выбор языка должен происходить автоматически, в зависимости от установленного для пользователя языка Системы по умолчанию. Каждый пользователь должен обладать возможностью переключения языка трансляции.Должна быть реализована интеграция трансляции материалов Системы и системы видеоконференц связи с возможностью демонстрации презентации на основном экране и обсуждения при помощи устройств видеоконференц связи зала проведения совещаний, находящемся в головном офисе Заказчика.5.3.13 Требование к аннотированию материалов

В Мобильном приложении Системы должен быть доступен функционал создания аннотаций к файлам в формате PDF. Данные аннотации должны храниться на устройстве как приложение к исходному файлу.Должны быть доступны следующие виды аннотаций:

1. Выделение маркером области текста. Должен быть реализован выбор цвета выделения.

2. Выделение области текста зачеркиванием.3. Инструмент рисования «Карандаш». Инструмент должен позволять рисовать линии

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

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

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

Модуль должен обеспечить проведение голосования по Вопросу повестки Мероприятия по следующим сценариям:

1. Голосование по предварительно подготовленной формулировке проекта решения без редактирования проекта решения в ходе проведения Мероприятия.

2. Голосование по предварительно подготовленной формулировке проекта решения с редактированием проекта решения в ходе проведения Мероприятия.

3. Принятие общего решения по Вопросу повестки Мероприятия.4. Отложенное голосование.5. Пропуск голосования по Вопросу.

5.3.14.1 Требования по проведению голосования по предварительно подготовленной формулировке проекта решения

Система должна обеспечить проведение голосования по предварительно подготовленной формулировке проекта решения.В Системе должна быть реализована возможность редактирования текста информационных объектов типа «Проект решения» и «Пункт проекта решения» в ходе рассмотрения Вопроса повестки Мероприятия.Секретарь мероприятия должен произвести в интерфейсе Системы запуск голосования по ассоциированным с объектом «Вопрос» объектам «Проект решения» и «Пункт проекта решения» (при установленном флаге «Голосование по пунктам проекта решения» для соответствующего информационного объекта «Вопрос»).Система должна предоставить Участникам мероприятия с правом голоса следующие варианты решений: «ЗА», «ПРОТИВ», «ВОЗДЕРЖАЛСЯ».В Системе должна быть реализована возможность добавления Особого мнения – текстового комментария по решению. Результаты голосования Участников мероприятия с учетом Особых мнений должны быть отражены в Протоколе мероприятия.5.3.14.2 Требования к режиму «Принятие общего решения по Вопросу»

Система должна обеспечить принятие общего решения по Вопросу. Сценарий должен использоваться для Мероприятий, в ходе которых принимается общее положительное или отрицательное решение по Вопросу без необходимости детального голосования по предварительно подготовленным Проектам решения.Секретарь мероприятия должен выполнить запуск Общего голосования.Система должна предоставить Участникам мероприятия с правом голоса следующие варианты решений: «ЗА», «ПРОТИВ», «ВОЗДЕРЖАЛСЯ». Решение принимается по Вопросу в целом.В Системе должна быть реализована возможность добавления Особого мнения – текстового комментария по решению.Результаты голосования Участников мероприятия должны быть отражены в Протоколе мероприятия.5.3.14.3 Требования к режиму «Отложенного голосования»

Система должна обеспечить принятие решения по вопросу в режиме отложенного голосования:

1. В случае, если в ходе рассмотрения Вопроса Члены органа управления и Председатель органа управления согласны утвердить рассматриваемый Вопрос с учетом последующего устранения замечаний, Секретарь должен иметь возможность установить информационный объект типа «Вопрос» в статус «Закрыт» с признаком «Принят с учетом замечаний». Вопрос должен фиксироваться в протоколе как «Вопрос на доработке».

2. Производится перевод Мероприятия в статус «Проведено».3. Производится редактирование содержания информационного объекта типа

«Вопрос» в статусе «Принят с учетом замечаний».4. Производится отправка отредактированного Вопроса на согласование

Председателю Органа управления.

a. В случае положительного решения должно производиться голосование по Проектам решения и Пунктам проекта решения (при установленном флаге «Голосование по пунктам проекта решения» для соответствующего информационного объекта «Вопрос»).

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

5.3.14.4 Требования к функционалу пропуска голосования по Вопросу

В Системе должна быть реализована возможность пропуска голосования по рассматриваемому Вопросу. Для данного сценария в Системе должен быть реализован статус информационного объекта типа «Вопрос» «Закрыт (Рассматривался)».5.3.15 Требования к подсистеме интеграции

Система должна предоставить средства информационного обмена (интеграции) с элементами, входящими в существующую информационную среду Заказчика:

1. Почтовая система.2. Служба каталогов Microsoft Active Directory.3. Система хранения файлов.

Информационный обмен между Системой и почтовой системой Заказчика должен осуществляться путем обращения Системы к почтовой системе и осуществления следующих операций:

1. Передачи в почтовую систему сформированных e-mail сообщений.2. Передачи в почтовую систему информации о запланированных мероприятиях

органа управления.Информационный обмен между Системой и системами хранения файлов должен производиться путем запросов к Web-сервисам.Детальные требования по интеграции должны уточняться на этапе внедрения системы.5.3.16 Требования к подсистеме администрирования

5.3.16.1 Подсистема администрирования

Подсистема администрирования должна предоставлять Администратору системы инструменты настройки, обеспечивающие:

1. Управление учетными записями пользователей.2. Управление ролями пользователей.3. Управление шаблонами уведомлений.

5.3.16.2 Управление учетными записями пользователей

Создание и управление учетными записями пользователей должно производиться из интерфейса администратора.Карточка пользователя должна содержать следующие параметры:

1. Логин.2. Пароль.3. ФИО.4. Должность.5. Электронная почта.

5.3.16.3 Управление ролями пользователей

В рамках ролевой политики Система должна предоставлять администратору системы функционал создания ролей, задание прав для ролей на операции над сущностями в определенных статусах, присвоения ролей пользователям. В рамках ролевой политики Система должна иметь механизм распределения прав и доступов к различным объектам системы (далее Ролевая модель). Администратор системы

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

Цель ролевой модели - управление доступом к объектам системы. Объект системы с точки зрения ролевой модели должен состоять из следующих атрибутов:

1. Название объекта. Уникально идентифицирует тип объекта.2. Статусы жизненного цикла объекта. Опционально. Описывают возможные

состояния объекта.3. Операции объекта. Описывают действия, выполнимые с объектом.4. Родительские объекты. Указывают на связь объекта с вышележащей в иерархии

объектами.5. Дочерние объекты. Указывают на связь объекта с нижележащей в иерархии

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

Рисунок 5.6 - Иерархия сущностей системы

5.3.16.3.2 Требования к операциям в рамках ролевой модели

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

1. Просмотр объекта - просмотр электронного представления объекта.2. Просмотр связанных объектов - просмотр электронных представлений объектов,

являющихся связанными для данного объекта.

3. Создание связанного объекта - создание связанного с данным объектом объекта системы, либо создание связи между существующими объектами в системе.

4. Редактирование объекта - изменение полей самого объекта. При этом данная операция может относиться как ко всему объекту, так и к отдельным полям.

5. Редактирование связанных объектов - изменение полей для связанных объектов. При этом данная операция может выдаваться как на весь связанный объект, так и на отдельные его поля.

6. Удаление объекта - удаление самого объекта из списка отображаемых объектов.7. Удаление связанных объектов - удаление связанных объектов из списка

отображаемых объектов, либо удаление связи между объектами.8. Изменение статуса жизненного цикла для объекта системы.

Кроме того, ролевой моделью должны регулироваться отдельные операции, специфические для каждого типа сущности:

1. Для мероприятия - приглашение участников мероприятия.2. Для вопроса - голосование по вопросу, ручной ввод результатов голосования.3. Для компании, холдинга, коллегиального органа - право назначать роли

пользователям.5.3.16.3.3 Требования к роли

Пользователь, имеющий права в рамках определенной роли на объект определенного уровня, должен иметь права на дочерние объекты, но не иметь прав на родительские объекты в рамках данной роли.Роль должна состоять из следующих атрибутов:

1. Название роли.2. Тип объекта, к которой она принадлежит.3. Тип роли – «системная» или «пользовательская».4. Разрешенные операции. Статусы объектов. Опционально. Операция разрешается

только для объектов в указанных статусах. Разрешение должно учитывать как статус типа объекта, к которой принадлежит роль, так и статусы объектов на которые направлена операция, на которую выдается разрешение.

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

1. Председатель Коллегиального органа.2. Секретарь Коллегиального органа.3. Участник Коллегиального органа.4. Председатель мероприятия.5. Секретарь мероприятия.6. Участник мероприятия.7. Приглашенный участник мероприятия.8. Инициатор вопроса.9. Инициатор поручения.10. Ответственный за исполнение поручения.

11. Контролер поручения.5.4 ТРЕБОВАНИЯ К ИНТЕРФЕЙСУ СИСТЕМЫ

5.4.1 Требования к стартовому экрану системы

Стартовый экран Системы должен автоматически отображаться в результате входа в Систему и должен содержать следующие блоки:

1. Интерактивный календарь.2. Блок новостей компании.3. Блок уведомлений.

5.4.2 Требования к календарю системы

В Системе должен быть реализован экран, позволяющий в виде Календаря производить отслеживание следующих событий:

1. Запланированные мероприятия органов управления юридических лиц.2. Уведомления о необходимости выполнить действия в Системе.

Календарь Системы должен предоставлять информацию в следующих временных срезах:1. День.2. Месяц.3. Год.

Календарь Системы должен содержать Блок управления, позволяющий производить фильтрацию отображаемой информации по следующим параметрам:

1. Юридическое лицо.2. Орган управления.3. Тип мероприятия.4. Тип уведомления.

5.4.3 Требования к эргономике интерфейса

Пользовательский интерфейс Системы должен быть интуитивно понятным. Область работы должна быть разделена на функциональные блоки. Элементы Системы должны быть выполнены в едином графическом стиле. Интерфейс Системы должен быть адаптирован (разрешение экранов и скорость выполнения операций Системы и действий пользователя) и иметь максимально схожие визуальные элементы и блоки как на мобильных устройствах на базе iOS- и Android-платформах, так и на desktop-устройствах на Windows- и Mac-платформах. Пользовательский интерфейс Системы должен быть приближен (с точки зрения логики расположения объектов, а также расположения и поведения элементов управления) к текущему веб-интерфейсу Портала Совета директоров Заказчика, находящегося в рабочей эксплуатации. При выполнении схожих действий должны использоваться схожие графические управляющие или навигационные элементы. Поведение элементов интерфейса должно быть одинаковым при выполнении однотипных действий.Требуемые Системой действия пользователя должны выполняться за минимальное количество операций.В Системе должен быть реализован механизм drag-and-drop для переноса файлов в соответствующий интерфейс Системы из файловой системы пользователя или смежного интерфейса Системы. Скорость выполнения операции должна зависеть только от объема файла и скорости интернет-соединения. Мобильный клиент системы должен поддерживать работу в многооконном режиме Split View на соответствующих устройствах.

5.5 ТРЕБОВАНИЯ К ИНФОРМАЦИОННОЙ БЕЗОПАСНОСТИ

5.5.1 Полное наименование подсистемы и ее условное обозначение

Наименование подсистемы: подсистема обеспечения информационной безопасности информационной системы автоматизации деятельности коллегиальных органов ОАО АФК «Система».Условное наименование подсистемы: AFKISATKO.ПИБ.5.5.2 Требования к Подсистеме информационной безопасности

5.5.2.1 Требования к структуре и функционированию Подсистемы

Требования подсистемы AFKISATKO.ПИБ распространяются на ограниченный состав информационных объектов (ИО) Системы, содержащих коммерческую тайну. Точный перечень указанных ИО должен быть определен отдельно совместно Заказчиком и Разработчиком Системы на этапе проектирования.Требования настоящего раздела должны реализовываться для следующих типов пользовательских рабочих мест:

доменные персональные компьютеры под управлением ОС Windows, расположенные в пределах и за пределами корпоративной вычислительной сети ОАО «АФК Система».

доменные персональные компьютеры под управлением ОС MacOS, расположенные в пределах и за пределами корпоративной вычислительной сети ОАО «АФК Система».

планшетные компьютеры iPad 2 и выше под управлением ОС iOS 7.1 и выше.

В состав AFKISATKO.ПИБ должны входить следующие модули ИБ:

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

5.5.2.2 Требования к функциям, выполняемым подсистемой ИБ

5.5.2.2.1 Требования к сценарию работы пользователей

В ходе работы с системой пользователь должен иметь возможность самостоятельного определения уровня конфиденциальности ИО: «Неконфиденциально», «Конфиденциально», «Строго конфиденциально». Уровень конфиденциальности определяется на основании Кодекса Безопасности, действующего в ОАО АФК «Система». Уровень конфиденциальности должен быть выбран пользователем как в случае загрузки ИО в систему, так и в случае выгрузки ИО из системы. Уровень конфиденциальности может быть изменен пользователем в отношении уже находящихся в системе ИО.При выборе уровня конфиденциальности «Конфиденциально» и «Строго конфиденциально» средствами системы, а также средствами смежных средств защиты информации, должны быть реализованы следующие механизмы обеспечения информационной безопасности:

ИО должен храниться в виде, зашифрованном системой Digital Rights Management (Microsoft RMS);

под ИО должна стоять электронная подпись сотрудника, который загрузил или выгрузил данный информационный объект;

слепок ИО должен быть передан в систему защиты от утечки конфиденциальной информации;

ИО должен быть оснащен меткой конфиденциальности и уникальным регистрационным номером;

факт создания и обращения к ИО должен протоколироваться. отчет при экспортировании пользователем Системы должен быть сохранен в

хранилище Системы с возможностью последующего доступа к нему сотрудником безопасности.

Указанные выше требования должны быть реализованы совместной работой модулей подсистемы информационной безопасности, которые описываются в следующих пунктах.При выборе уровня конфиденциальности «Неконфиденциально» указанных выше требований к обеспечению информационной безопасности к ИО не предъявляется.

5.5.2.2.2 Требования к модулю управления доступом

Доступ к функциям и ресурсам Системы должен предоставляться только аутентифицированным и авторизованным пользователям.Должен быть реализован механизм сквозной двухфакторной аутентификации веб-клиента или устройства iPad (по технологии RSA SecurID или с применением сертификатов x509). Ввод данных аутентификации должен производиться минимально возможное число раз1.Разграничение доступа к ИО всех типов, хранимым в Системе, должно осуществляться в соответствии с правами пользователей и их ролями, определяемыми Ролевой моделью. В основе Ролевой модели должно лежать управление правами доступа через объекты Active Directory (группы безопасности, Organization Unit и пр.).При разграничении доступа к ИО, содержащим коммерческую тайну, должна использоваться система класса Digital Rights Management (Microsoft RMS).Вход в систему по механизму распознавания отпечатков пальцев, используемый в планшетах Apple iPad Air 2 должен дополнять существующие способы проверки пользователя системы и являться необязательным.Все операции по взаимодействию с отпечатком пальца должны обрабатываться локально в iOS с использованием внутренних механизмов защиты информации планшета. Полученные данные отпечатка должны храниться в зашифрованном виде в специальной области «Secure Enclave» в процессоре планшета. Данные должны шифроваться приватным ключом, который генерируется и записывается в «Secure Enclave» во время производства процессора на фабрике. Ни зашифрованные данные отпечатка, ни приватный ключ не доложны покидать мобильное устройство и не должны быть переданы третьим лицам. Для использования биометрической аутентификации в мобильном клиенте пользователю необходимо выполнить вход в систему по связке логин/пароль, придумать ПИН-код, затем при желании привязать отпечаток для входа в систему. При следующем входе в приложение пользователю будет предложено выполнить вход в систему по отпечатку пальца, либо указав ПИН. При пятикратном некорректном распознавании отпечатка система должна запросить обязательный ввод ПИН-кода приложения.

5.5.2.2.3 Требования к модулю регистрации и учета

В рамках технического проектирования должен быть определен перечень типов ИО, в текст которых могут вноситься атрибуты регистрации.

1 Число вводов пользователем аутентификационных данных определяется на этапе технического проектирования и ограничено спецификой инфраструктуры Заказчика.

Средствами Системы должен вестись локальный реестр ИО, маркированных регистрационным номером, не коррелируемый с другими реестрами. Регистрационный номер ИО должен записываться в реестр КТ файлов/ИО (хранится в базе данных Системы), в атрибуты ИО (служебные поля), в текст документов. В техническом проекте должен быть отображен метод нанесения регистрационного номера на документы формата MS Office.Кроме регистрационного номера и даты регистрации, в свойства ИО или в текст документа формата MS Office вносится гриф и метки конфиденциальности. Формат регистрационного номера и меток конфиденциальности должен определяться на этапе технического проектирования.Должна быть реализована возможность регистрации событий безопасности.В рамках технического проектирования должен быть определен состав и формат регистрируемых событий безопасности.Должна быть реализована возможность формирования отчетов по совокупности регистрируемых событий с использованием фильтрации по любым атрибутам, которые фиксируются при регистрации событий.Должна быть возможность модернизации системы формирования отчетов при возникновении необходимости анализа новых типов событий.Система формирования отчетов должна иметь встроенный язык запросов, предоставляющий возможность формирования отчетов произвольного вида.Система формирования отчетов должна предоставлять программный интерфейс для возможности вызова функций системы из сторонних приложений.5.5.2.2.4 Требования к модулю защиты от утечки конфиденциальной информации

Для загружаемых в Систему ИО, должны сниматься отпечатки системой защиты от утечки конфиденциальной информации (Websense DSS). Отпечатки должны сниматься с незашифрованных ИО. Хранение ИО в незашифрованном виде после снятия отпечатков не допускается.Передача распечатанных ИО с меткой конфиденциальности «Конфиденциально» и «Строго конфиденциально» за пределы контролируемой зоны2 по сети должна контролироваться системой Websense DSS.5.5.2.2.5 Требования к модулю криптографической защиты информации

Загружаемый в систему ИО и сохраняемый в базе данных системы ИО должны подписываться ЭП пользователя, загрузившего (сохранившего) ИО (для всех типов рабочих станций, в случае выбора уровня конфиденциальности ИО «Конфиденциально» или «Строго конфиденциально»). ЭП должна производиться по алгоритму ГОСТ Р 34.10.2001.Должна быть реализована возможность проверки ЭП под ИО (для всех типов рабочих станций). При формировании и проверке ЭП должен использоваться механизм усовершенствованной электронной подписи, в рамках которого должны применяться протокол TSP для проставления метки времени и протокол OCSP для проверки статуса сертификата ключа подписи.Должна быть предусмотрена возможность запечатывания (шифрования) ИО, содержимое которых составляет коммерческую тайну, при хранении их в системе.

2 Под контролируемой зоной в данном проекте понимается офисное здание Заказчика, расположенное по адресу: 125009, Москва, ул. Моховая, 13, строение 1

ЭП должна быть выполнена после внесения в ИО регистрационного номера и меток конфиденциальности, формирования слепка ИО средствами СЗИ Websense DSS, и до шифрования ИО средствами Microsoft RMS.При выполнении ЭП под ИО должна быть обеспечена возможность однократного ввода необходимого для данной операции ПИН-кода (как для отдельного ИО, так и для нескольких ИО, одновременно загружаемых в систему).При формировании и проверке ЭП должны быть использованы ключи и сертификаты, выданные корпоративным УЦ ОАО АФК «Система».Должна быть обеспечена возможность шифрования всех ИО, хранящихся в БД, штатными средствами СУБД MS SQL Server.5.5.2.2.6 Требования к модулю обеспечения сетевой безопасности

Удаленный доступ пользователей к Системt должен быть реализован посредством защищенных каналов связи на базе протоколов SSL VPN или IPsec VPN.5.6 ТРЕБОВАНИЯ К ВИДАМ ОБЕСПЕЧЕНИЯ

5.6.1 Требования к информационному обеспечению

Информационное обеспечение Системы должно быть достаточным для выполнения всех ее автоматизированных функций. Информационное обеспечение Системы должно быть совместимо с информационным обеспечением систем, взаимодействующих с ней, по содержанию, системе кодирования, методам адресации, форматам данных и форме представления информации, получаемой и выдаваемой Системой.5.6.1.1 Хранение данных

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

Система должна иметь общесистемные справочники, построенные по линейному или иерархическому типу, которые должны заполняться администраторами системы.Система должна предоставлять возможность заполнения полей форм документов на основании содержимого классификаторов и справочников, хранящихся централизованно.Ответственность за корректное внесение данных в классификаторы и справочники возлагается на прикладного администратора системы.В Системе должен быть реализован справочник Категорий, представляющий собой список значений, которые могут быть присвоены информационным объектам Системы для обеспечения категоризации поиска информации.5.6.1.3 Защита данных от сбоя в электропитании системы

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

5.6.2 Требования к программному обеспечению

При создании системы должно использоваться только лицензионное общее и специальное программное обеспечение, и лицензионные операционные системы.Программное обеспечение Системы должно обеспечивать работу пользователей с Системой через Web-интерфейс и с помощью нативного приложения на мобильном устройстве Apple iPad. В состав коммерческого предложения Исполнитель обязан включить сведения об используемых программных платформах и компонентах, подлежащих обязательному лицензированию, с указанием разработчика, наименования и количества необходимых лицензий и их стоимости.При условии необходимости обязательного приобретения лицензируемого программного обеспечения необходимо обязательно предоставить расчет стоимости технической поддержки правообладателя программного обеспечения сроком не менее 5 лет. Обязательный состав услуг по технической поддержке должен включать в себя:

Обновления ПО (в том числе предоставление новых версий и релизов), по мере их выхода на рынок;

Удаленную помощь в ответ на запросы Заказчика/Исполнителя для решения:o вопросов по основам установки, использования и конфигурирования;o вопросов по документации по Программам;o вопросов по проблемам, связанным с программным кодом;

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

Для известных дефектов — информацию по доступным способам коррекции и исправлениям ПО.

Все приобретаемое ПО должно быть свободным от обязательств перед третьими лицами.5.6.3 Требования к техническому обеспечению ИС

Предоставление комплекса технических средств Системы, необходимого для эксплуатации Системы, должно осуществляться Заказчиком.В состав коммерческого предложения Исполнитель обязан включить технические требования к аппаратному обеспечению, необходимому для развертывания и эксплуатации Системы, исходя из перспектив развития системы.5.6.4 Требования к патентному обеспечению

Программное обеспечение Системы должно быть свободным от возможности предъявления любых притязаний третьих лиц, основанных на промышленной, интеллектуальной или другом виде собственности.Патентная чистота Системы и её частей должна быть обеспечена в отношении действующего Законодательства Российской Федерации.5.6.5 Требования по стандартизации и унификации

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

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

Интерфейсы администрирования, использующиеся для настройки и конфигурирования автоматизированной системы должен быть на русском языке.

5.7 ПОРЯДОК КОНТРОЛЯ И ПРИЕМКИ СИСТЕМЫ

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

5.8 ТРЕБОВАНИЯ К ДОКУМЕНТИРОВАНИЮ

В настоящем разделе приводится перечень подлежащих разработке Исполнителем комплектов и видов документов, которыми должна сопровождаться Система.Таблица 14. Перечень этапов работ и список отчетных документов

Стадия (этап) создания АИС

Предъявляемые документы

Аналитическое обследование

Рекомендации по выбору серверного оборудования и инфраструктурного программного обеспечения для развертывания Системы, рекомендаций по необходимой пропускной способности канала передачи данных

Техническое заданиеЧастное техническое задание по миграции данныхЧастное техническое задание по защите коммерческой тайныЧастное техническое задание по защите персональных данных

Проектирование Отчет о техническом проектировании

Реализация проекта Разработка программы и методики испытаний Системы

Протокол проведения приемо-сдаточных испытаний согласно Программы и методики испытаний Системы

Опытно-промышленная эксплуатация системы

Руководства пользователя и администратора

Протокол о завершении опытной эксплуатации

Описание технического решения в соответствии с шаблоном Заказчика

5.9 ТРЕБОВАНИЯ К СОСТАВУ УСЛУГ ПО ТЕХНИЧЕСКОЙ ПОДДЕРЖКЕ СИСТЕМЫ

Гарантийная поддержка Системы осуществляется в течение 3 лет.В состав работ по гарантийной поддержке входит корректировка и исправление недостатков, выявленных в ходе эксплуатации Системы, вызванных несоответствием возможностей разработанной системы требованиям, описанным в документе «Техническое задание».5.9.1 Терминология

Таблица 15. Термины и определения, относящиеся к технической поддержке.

Термин Определение

Исполнитель Компания, выигравшая конкурс на разработку системы

Продукт/Система Клиентское и серверное программное обеспечение, разработанное Исполнителем

Клиент/Заказчик ОАО АФК «Система»

Инициатор Сотрудник клиента, инициировавший обращение в техническую поддержку

Инцидент Событие, которое привело или может привести к нарушению нормального использования Системы

5.9.2 Общие положения

Под гарантийным обслуживанием понимается обеспечение безотказной работы базового функционала продукта.5.9.3 Требования к обращениям в службу поддержки

Запросы на гарантийное обслуживание должны приниматься в виде электронного письма, направленного на адрес электронной почты, либо по телефону.Письмо должно содержать:

· Описание проблемы, включая порядок ее воспроизведения;· Скриншот, отображающий проблемную ситуацию;· Влияние на функциональность, в соответствии с описанием:

o Высокое – невозможность использования функционала системы в целом;o Среднее – нарушение функций отдельных пользователей;o Низкое – ошибка, не влияющая на процесс работы и не приводящая к

сокращению функциональности.5.9.4 Реакция на запросы

После направления запроса, его обработка должна происходить в следующем порядке:1. Получение запроса – запросу по умолчанию присваивается статус “Новый”;2. Утверждение приоритета и назначение ответственного – запрос переводится в статус “В работе”, инициатору запроса направляется соответствующее уведомление;3. Уточнение информации по инциденту – инициатору запроса направляется запрос на дополнительную информацию, инцидент переводится в статус “Ожидание”.

После получения ответа запрос возвращается в статус “В работе”;4. Предложение решения либо указание срока выпуска исправления – инициатору направляется информация об устранении проблемы, либо срок выпуска исправления, запрос переводится в статус «Ожидание»:

· Если инициатору направлен срок выпуска исправления, запрос остается в статусе «Ожидание» до момента установки исправления.

· Если инициатору было предложено решение проблемы, но предложенное решение не помогло, запрос возвращается в статус «В работе».

· Если инициатору было предложено решение проблемы, и предложенное решение помогло, запрос переводится в статус «Решен».

Назначение ответственного и предложение решения должно осуществляться в сроки, указанные в таблице:Таблица 16. Сроки реакции на запросы

Влияние на функциональность Назначение ответственного

Предложение решения

Высокое 2ч 8ч

Среднее 4ч 16ч

Низкое 8ч 32ч

Время, указанное в таблице, считается от момента получения запроса и учитываются только рабочие часы, т.е. с 10.00 до 19.00 по рабочим дням. Время нахождения запроса в статусе “Ожидание” при этом не учитывается.Примечания:1. В случае, если рамках изучения запроса не выявлено нарушений в работе базового функционала системы, в обработке запроса может быть отказано;2. В случае, если в течение 10 рабочих дней от инициатора обращения не было получено ответа на запрос уточняющей информации или предложенное решение, запрос может быть закрыт Исполнителем в одностороннем порядке (запрос принимает статус “Закрыт”, инициатору направляется соответствующее уведомление).5.9.5 Выпуск исправлений

В случае, если по результатам рассмотрения запроса обнаружен сбой в продукте, требующий исправления, служба технической поддержки в зависимости от срочности запроса должна выпустить внеочередное обновление ПО, либо включить исправление в очередное обновление версии продукта:Таблица 17. Порядок выпуска исправления

Влияние на функциональность

Выпуск исправления

Высокое Внеочередное обновление

Среднее/Низкое Очередная версия продукта

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