с нашего сайта - Госуслуги в электронном виде

IV. Технические требования
на выполнение работ по созданию комплексной системы предоставления
государственных и муниципальных услуг в электронном виде на региональном и
муниципальном уровнях электронного правительства Вологодской области I
очереди
ОБЩИЕ СВЕДЕНИЯ.
1.
Настоящие технические требования (далее по тексту – ТТ) определяют основные
требования по созданию в органах исполнительной государственной власти Вологодской области
(далее по тексту – ОИГВ ВО) комплекса следующих автоматизированных систем:
 региональная комплексная информационная система «Госуслуги – Вологодская
область» (далее по тексту - РКИС ГУ–ВО);
 интегрированная система электронного документооборота органов исполнительной
государственной власти Вологодской области (далее по тексту – АСЭД ОИГВ);
 официальный Интернет-портал органов исполнительной государственной власти
Вологодской области (далее по тексту – АИС «ИП ОИГВ ВО»).
РКИС ГУ–ВО предназначена для комплексной автоматизации процесса предоставления
ОИГВ ВО государственных услуг для граждан и организаций – физических или юридических
лиц, имеющих право в соответствии с законодательством Российской Федерации и (или)
Вологодской области на получение государственных услуг на территории Вологодской области.
Система предназначена для повышения эффективности оказания государственных услуг
ОИГВ ВО и повышения комфортности взаимодействия граждан и организаций, в том числе за
счет электронного межведомственного взаимодействия и возможности оказания услуг в
электронном виде.
АСЭД
ОИГВ
предназначена
для
автоматизации
межведомственного
и
внутриведомственного документооборота и делопроизводства в Правительстве Вологодской
области и ОИГВ ВО.
АИС «ИП ОИГВ ВО» предназначена для реализации прав граждан и организаций на
доступ к информации о деятельности ОИГВ ВО в сети Интернет.
1.1.
ТЕРМИНЫ И ОПРЕДЕЛЕНИЯ
Термин
Определение
Автоматизированная
информационная система
Система, состоящая из персонала и комплекса средств
автоматизации его деятельности, реализующая информационную
технологию выполнения установленных функций.
Аутентификация
Установление подлинности информации исключительно на основе
внутренней структуры самой информации независимо от ее
источника
Административный
регламент
Нормативный правовой акт, устанавливающий
предоставления
государственной
услуги
и
предоставления государственной услуги.
Безопасность информации
Состояние
защищенности
информации,
характеризуемое
способностью персонала, технических средств и информационных
технологий обеспечивать конфиденциальность (т.е. сохранение в
тайне от субъектов, не имеющих полномочий на ознакомление с
ней), целостность и доступность информации при ее обработке
техническими средствами.
Государственная услуга
Государственная услуга, предоставляемая ОИГВ ВО, а также
стр. 1 из 69
порядок
стандарт
органом местного самоуправления Вологодской области (далее по
тексту – ОМС ВО) при осуществлении отдельных
государственных полномочий, переданных федеральными
законами и законами Вологодской области.
Заявитель
Физическое или юридическое лицо (за исключением
государственных органов и их территориальных органов, органов
государственных внебюджетных фондов и их территориальных
органов,
органов
местного
самоуправления)
либо
их
уполномоченные представители, обратившиеся в орган,
предоставляющий государственные услуги с запросом о
предоставлении государственной услуги, выраженным в устной,
письменной или электронной форме.
Инфраструктура
электронного
правительства
Совокупность технических, организационных и иных решений,
программно-аппаратных компонентов и информационных
ресурсов,
обеспечивающих
создание
и
эффективное
функционирование сервисов электронного правительства
Конфиденциальная
информация
Документированная
информация,
доступ
к
которой
ограничивается в соответствии с законодательством Российской
Федерации;
В практической деятельности конфиденциальную информацию
принято разделять на предметную и технологическую.
Технологическая информация (например, пароли пользователей) в
информационной системе выполняет техническую роль, но ее
раскрытие особенно опасно, поскольку чревато возможностью
получения несанкционированного доступа ко всей информации,
включая предметную.
Действующее
законодательство
РФ
определяет
только
предметную конфиденциальную информацию.
Конфиденциальная информация может представлять служебную
тайну,
коммерческую
тайну,
тайну,
связанную
с
профессиональной производственной деятельностью субъекта
(физического или юридического лица) - врачебную тайну, тайну
следствия и судопроизводства, нотариальную тайну, адвокатскую
тайну, банковскую тайну и др., а также тайны, связанные с
частной жизнью гражданина - персональные данные, тайну
переписки, телефонных переговоров, почтовых отправлений,
телеграфных сообщений, тайну усыновления, голосования,
вероисповедования и т.д.
Электронное
правительство
Новая форма организации деятельности органов государственной
власти, обеспечивающая за счет широкого применения
информационно-коммуникационных технологий (далее - ИКТ)
качественно новый уровень оперативности и удобства получения
гражданами и организациями государственных услуг и
информации о результатах деятельности государственных
органов.
1.2. ОБЩИЕ СВЕДЕНИЯ ОБ ОБЪЕКТАХ АВТОМАТИЗАЦИИ
Основная цель Правительства Вологодской области - обеспечение достойной жизни
вологжан. Согласно Уставу Вологодской области, устанавливающему статус области, принципы
организации и деятельности органов исполнительной государственной власти области,
стр. 2 из 69
Правительство области, возглавляемое Губернатором области, и органы исполнительной
государственной власти области составляют систему исполнительной власти Вологодской
области.
Правительство области и органы исполнительной государственной власти области
организуют и осуществляют управление областью.
Правительство области разрабатывает для представления Губернатором области в
Законодательном Собрании области проекты областного бюджета и программ социальноэкономического развития области, а также обеспечивает их исполнение.
Правительство области и органы исполнительной государственной власти области,
представляя интересы населения области, берут на себя решение существующих проблем, а также
заботятся о перспективном гармоничном развитии региона.
Основными полномочиями Правительства области являются:

разработка и реализация мер по обеспечению комплексного социальноэкономического развития области;

участие в проведении единой государственной политики в области финансов, науки,
образования, здравоохранения, социального обеспечения и экологии.
Объектом автоматизации являются ОИГВ ВО и ОМС ВО.
Вологодская область имеет развитую структуру ОИГВ в следующем составе:

Губернатор Вологодской области;

Правительство Вологодской области;

Органы исполнительной государственной власти Вологодской области.
Структура ОИГВ ВО на момент объявления конкурса приведена в таблице 1.
Таблица 1
Структура органов исполнительной государственной власти Вологодской области
№ п/п
Подразделение, должностное лицо
1.
Губернатор области
2.
Правительство области
3.
Органы исполнительной государственной власти области в составе:
- Главное управление архитектуры и градостроительства области
- Государственная жилищная инспекция области
- Департамент государственной службы и кадровой политики области
- Департамент дорожного хозяйства и транспорта области
- Департамент занятости населения области
- Департамент здравоохранения области
- Департамент земельных отношений области
- Департамент имущественных отношений области
- Департамент информационных технологий и телекоммуникаций области
- Департамент культуры и охраны объектов культурного наследия области
- Департамент лесного комплекса области
- Департамент международных, межрегиональных связей и туризма области
- Департамент образования области
- Департамент по обеспечению деятельности мировых судей области
- Департамент по охране, контролю и регулированию использования объектов
животного мира области
- Департамент природных ресурсов и охраны окружающей среды области
- Департамент развития муниципальных образований области
- Департамент сельского хозяйства, продовольственных ресурсов и торговли
области
стр. 3 из 69
№ п/п
Подразделение, должностное лицо
-
Департамент топливно-энергетического комплекса области
Департамент труда и социального развития области
Департамент финансов области
Департамент экономики Правительства области
Государственно-правовой департамент Правительства области
Инспекция государственного строительного надзора области
Комитет государственного заказа области
Комитет информации, печати и телерадиовещания области
Комитет по физической культуре, спорту и молодёжной политике области
Комитет социальной безопасности области
Представительство Губернатора области и Правительства области в
Законодательном Собрании области
Представительство Вологодской области в Северо-Западном федеральном округе
Представительство Вологодской области при Президенте РФ и Правительстве РФ
Региональная энергетическая комиссия области
Контрольно-аналитическое управление Правительства области
Управление делами Правительства области
Управление делопроизводства и архива Правительства области
Управление по профилактике правонарушений и взаимодействию с
правоохранительными органами Правительства Вологодской области
Управление государственной инспекции по надзору за техническим состоянием
самоходных машин и других видов техники области
Управление гражданской защиты и пожарной безопасности области
Управление записи актов гражданского состояния области
Управление по делам архивов области
Управление труда и социального развития по муниципальному образованию
"Город Вологда" Вологодской области
Служба по правам ребенка Правительства области
ОИГВ ВО (Таблица 1), характеризуются:

многоуровневой вертикально-интегрированной структурой;

территориальной распределенностью – часть объектов (структурных подразделений
Правительства области и ОИГВ ВО) находится в рамках главного здания в единой локальновычислительной сети (ЛВС), а часть – в территориально обособленных зданиях в удаленных ЛВС;

значительным объемом документооборота, осуществляемого как в бумажной, так и в
электронной форме.
В виду проведения административной реформы структура ОИГВ ВО в течение года
меняется, в связи с этим окончательный список ОИГВ ВО должен быть определен в ходе
обследования.
Вологодская область разделена на 26 муниципальных районов и 2 городских округа
(Вологда и Череповец). Вологда, Череповец, Великий Устюг и Сокол - города областного
значения.
Муниципалитеты: Бабаевский район, Бабушкинский район, Белозерский район,
Вашкинский район, Великоустюгский район, Верховажский район, Вожегодский район,
Вологодский район, Вытегорский район, г.Вологда, г.Череповец, Грязовецкий район, Кадуйский
район, Кирилловский район, Кич-Городецкий район, Междуреченский район, Никольский район,
Нюксенский район, Сокольский район, Сямженский район, Тарногский район, Тотемский район,
стр. 4 из 69
Усть-Кубинский район, Устюженский район, Харовский район, Чагодощенский район,
Череповецкий район, Шекснинский район.
Каждый муниципалитет характеризуется:

многоуровневой вертикально-интегрированной структурой;

территориальной распределенностью как на территории районного центра, так и по
территории муниципалитета;

значительным объемом документооборота, осуществляемого в основном в бумажном
виде;

различной степенью развития информационно-коммуникационной инфраструктуры.
1.3. ОСНОВАНИЯ СОЗДАНИЯ КОМПЛЕКСА АВТОМАТИЗИРОВАННЫХ СИСТЕМ
Основанием для проведения работ являются:
 Федеральный закон от 9 февраля 2009 года № 8-ФЗ «Об обеспечении доступа к
информации о деятельности государственных органов и органов местного
самоуправления».
 Федеральный закон от 27 июля 2010 года № 210-ФЗ «Об организации предоставления
государственных и муниципальных услуг»;
 Постановление Правительства Российской Федерации от 15 июня 2009 года № 478 «О
единой системе информационно-справочной поддержки граждан и организаций по
вопросам взаимодействия с органами исполнительной власти и органами местного
самоуправления с использованием информационно - телекоммуникационной сети
интернет».
 Стратегия развития информационного общества в Российской Федерации, утвержденная
поручением Президента Российской Федерации от 7 февраля 2008 года № Пр-212.
 Распоряжение Правительства Российской Федерации от 17 ноября 2008 года № 1662-р
«О Концепции долгосрочного социально-экономического развития Российской Федерации
на период до 2020 года».
 Распоряжение Правительства Российской Федерации от 17 ноября 2008 года № 1663-р
«Об утверждении основных направлений деятельности Правительства Российской
Федерации на период до 2012 года».
 Распоряжение Правительства Российской Федерации от 17 октября 2009 года № 1555-р
«Об утверждении Плана перехода на предоставление государственных услуг и исполнение
государственных функций в электронном виде федеральными органами исполнительной
власти».
 Распоряжение Правительства Российской Федерации от 6 мая 2008 года № 632-р «О
Концепции формирования в Российской Федерации электронного правительства до 2010
года».
 Постановление Правительства Российской Федерации от 28 января 2002 года № 65 «О
федеральной целевой программе «Электронная Россия (2002 - 2010 годы)».
 Распоряжение Губернатора Вологодской области от 1 июля 2010 года № 2199-р «О Плане
перехода на предоставление в электронном виде государственных и муниципальных
услуг»;
 Долгосрочная целевая программа «Информатизация Вологодской области на 2010-2012
годы».
стр. 5 из 69
1.4. ОБЩИЕ
ТРЕБОВАНИЯ
АВТОМАТИЗИРОВАННЫХ СИСТЕМ
К
РАЗРАБОТКЕ
И
ВНЕДРЕНИЮ
Создание комплекса систем должно базироваться на следующих основных
принципах:
 максимальное экономически оправданное использование и логическое развитие
решений существующей информационно-технологической инфраструктуры электронного
правительства Вологодской области;
 учет положений действующих федеральных и региональных нормативных актов и
рекомендаций по развитию информационного общества и формированию электронного
правительства;
 учет текущего состояния и тенденций развития информационных потребностей
населения и ОИГВ Вологодской области;
 унификация информационных ресурсов регионального уровня на основе использования
интегрированных баз данных, использования единой системы классификации и
кодирования информации, а также унифицированных документов;
 максимальное экономически оправданное использование результатов ведущихся
проектов
по
информационно-технологической
инфраструктуре
электронного
правительства Вологодской области;
 обеспечение гибкой развиваемой и масштабируемой архитектуры комплекса систем на
базе концепции информационно-технологических сервисов;
 использование интеграционных подсистем, разработанных на принципах сервисноориентированной архитектуры, для организации межведомственного электронного
взаимодействия,
 поэтапное проектирование, разработка и внедрение отдельных компонентов каждой из
комплекса систем;
 обеспечение возможности поэтапного наращивания функциональных возможностей
каждой системы;
 использование единых стандартов при проектировании и разработке элементов каждой
системы в рамках создания всего комплекса систем.
На этапе обследования объектов автоматизации Исполнитель должен изучить технические
возможности Заказчика, разработать оптимальный вариант развертывания систем на имеющемся
у Заказчика оборудовании с учётом максимального сохранения сделанных ранее инвестиций в
программное обеспечение и подготовить технические спецификации для приобретения
дополнительного недостающего оборудования, программного обеспечения и организации каналов
связи. В отчёте о результатах обследования должно быть приведено технико-экономическое
обоснование решений по использованию, модернизации или замене существующих
автоматизированных систем ОИГВ ВО, относящихся к предмету настоящих ТТ.
Объемы, сроки и стоимость внедрения окончательно определяются Заказчиком после
утверждения проектных решений по системам.
1.5. ОБЩИЕ ТРЕБОВАНИЯ К ПОРТАЛЬНЫМ РЕШЕНИЯМ ПОДСИСТЕМЫ РКИС
ГУ-ВО «ПОРТАЛ ГОСУДАРСТВЕННЫХ И МУНИЦИПАЛЬНЫХ УСЛУГ» И АИС «ИП ОИГВ
ВО»
Портал должен строиться на промышленной платформе с максимальным использованием
готового ПО и для него могут использоваться общие программные и аппаратные компоненты,
например, системы хранения данных, средства построения консолидированной отчетности,
средства аутентификации пользователей.
При построении архитектуры Портала должны учитываться:

функции, возлагаемые на Портал, в части взаимодействия с пользователями;
стр. 6 из 69

функции, возлагаемые на Портал, в части взаимодействия с информационными
ресурсами и автоматизированными информационными системами ОИГВ ВО;

предполагаемое число пользователей и характер их взаимодействия через Портал;

нефункциональные
требования
(безопасность,
резервное
копированиевосстановление, доступность сервисов, требования к системе администрирования, управления
контентом и пр.).
Портал должен иметь два сегмента – внутренний (для работы сотрудников ОИГВ ВО через
ЛВС ОИГВ ВО) и внешний (через сеть Интернет).
Эти сегменты могут быть реализованы как на едином аппаратно-программном комплексе
(то есть являться фактически единым порталом с соответствующим разграничением доступа
различных категорий пользователей), так и на различных серверных комплексах (тогда должны
быть два отдельных портала).
В зависимости от уровня нагрузки и требований к уровню доступности Портала его
архитектура должна предусматривать возможность использования кластеризации одного или
нескольких вышеприведенных компонентов. Кластеризация не предусматривается для этапов
разработки и опытной эксплуатации.
Для веб-сервера кластеризация подразумевает также и решение для балансировки нагрузки
– перенаправления внешних запросов (от веб-браузеров пользователей Портала) на наименее
загруженный элемент кластера.
Портал должен иметь возможность изменять свои эргономические свойства для разных
категорий пользователей (в том числе, с ограниченными возможностями).
С функциональной точки зрения Портал должен представлять собой единую среду,
формирующую средствами веб-технологий пользовательский интерфейс, осуществляющую
агрегирование и визуализацию информации, предоставляемой пользователям различными
прикладными системами и источниками данных, и содержащую подсистемы:
 администрирования;
 управления доступом;
 поиска;
 навигации;
 управления веб-контентом;
 управления электронными формами;
 разработки и тестирования.
Подсистема администрирования предназначена для решения административных задач по
управлению Порталом через веб-интерфейс (организация дерева страниц, публикация веб-частей,
электронных форм, задание правил персонализации предоставления информации, работу с
другими подсистемами).
Подсистема управления доступом предназначена для обеспечения разграничения
безопасного доступа к информационным ресурсам пользователей, в зависимости от их ролей.
Подсистема поиска предназначена для сбора данных из доступных статических
информационных ресурсов (включая веб-страницы, текстовые файлы, документы в формате MS
Word, Excel, Powerpoint, Adobe Acrobat), построения соответствующих индексов на базе
собранных данных и реализация поиска по ней.
Подсистема навигации предназначена для удобного и наглядного перемещения
пользователей по разделам и страницам Портала.
Подсистема «Управление веб-контентом» предназначена для хранения, управления и
изменения содержимого страниц Портала (кроме работы с формами и служебными веб-частями).
Подсистема должна содержать следующие модули:

«Подготовка контента».

«Управление публикацией».

«Репозиторий контента».
стр. 7 из 69
Модуль «Подготовка контента» должен предоставлять интерфейс и распределение ролей
для администраторов Портала и персонала, ответственного за поддержание в актуальном
состоянии веб-страниц Портала. При этом модуль должен предоставлять шаблоны, дающие
возможность ввода-редактирования контента без использования языков программирования и
html-разметки.
Модуль «Управление публикацией» предназначен для управления продвижением
контента от его создания до его публикации на страницах Портала, в том числе:

создание и редактирование контента, хранение версий;

согласование и утверждение контента;

создания новых разделов и подразделов Портала, удаление существующих;

публикация контента.
Модуль «Репозиторий контента» предназначен для обеспечения хранения контента
портала и должен использовать общую СУБД с Порталом.
Подсистема «Управление электронными формами» предназначена для создания
электронных форм (которые затем отображаются на страницах портала, в соответствии с
функциональным предназначением Портала), сохранения информации, вносимой в формы
пользователями Портала, доставке заполненных форм ответственному лицу в органе власти, а
также хранения этих форм и построения отчетов на основе хранимой информации. Электронные
формы должны предоставлять возможность автоматического заполнения полей с использованием
подсистемы НСИ.
Подсистема разработки и тестирования предназначена для создания веб-страниц,
размещаемых на Портале и обеспечивающих бизнес-процессы по оказанию услуг пользователям
Портала. Кроме того, задачей этой подсистемы является разработка дизайна и шаблонов вебстраниц Портала (информационное наполнение которых может осуществляться как через систему
управления веб-контентом, так и самой подсистемой разработки). В рамках этой подсистемы
создается среда тестирования Портала, на которой проходят проверку все элементы и сервисы
перед переносом на официальный Портал.
Архитектура Портала должна обладать адаптивностью к изменению правовой и
нормативной базы, а также масштабируемостью при изменении нагрузки и условий
функционирования и эти свойства должны достигаться за счет минимальных доработок
архитектурных решений.
Для полноценного функционирования подсистем Портала должна быть предусмотрена
возможность интеграции с основными существующими и создаваемыми информационными
ресурсами инфраструктуры электронного правительства:

системы НСИ;

интеграционная шина;

АСЭД ОИГВ;

каталог пользователей системы с хранимыми учетными данными пользователей
системы;

информационно-аналитическая система электронного правительства;

каталог веб-сервисов (UDDI) интеграционной шины;

единый удостоверяющий центр для работы с ЭЦП.
Актуализация информационного наполнения Портала осуществляется непосредственно
поставщиками информации на основе разработанных регламентов создания ведомственного
контента и публикации его на Портале.
При создании типовых пользовательских интерфейсов должны выполняться следующие
требования:
 интерфейс конечного пользователя должен быть русскоязычным, с возможностью
перехода на англоязычный и немецкоязычный интерфейсы;
стр. 8 из 69







функциональная группировка элементов, т.е. пункты меню (или их аналоги) должны
быть сгруппированы в соответствии с функциональными задачами и технологией
работы;
уникальная функциональность, т.е. каждому пункту меню (или его аналогу) должна
соответствовать только одна выполняемая функция;
однозначность в понимании, т.е. пункты меню (или их аналоги) должны называться или
отображаться так, чтобы пользователь однозначно понимал их назначение;
наличие глобальной помощи по работе с системой;
наличие контекстной помощи при выполнении сложных действий в системе;
сигнализация об ошибках или ошибочных действиях должна сопровождаться
подсказкой о дальнейших действиях;
задание критериев поиска и выбора информации должно производиться без
привлечения языков программирования.
1.6. ТРЕБОВАНИЯ
К
ФУНКЦИОНАЛУ
СИСТЕМ,
ОБЕСПЕЧИВАЮЩИХ
НЕОБХОДИМЫЙ УРОВЕНЬ ИНТЕГРАЦИИ МЕЖДУ ВНЕДРЯЕМЫМИ СИСТЕМАМИ
1.6.1. ИНТЕГРАЦИЯ АСЭД ОИГВ ВО С РКИС ГУ-ВО
АСЭД ОИГВ должна предоставлять возможность интеграции с РКИС ГУ-ВО по
следующим направлениям:
 импорт информации о поступающих документах (заявках на предоставление
Государственных услуг);
 экспорт информации об исходящих документах (результат предоставления
Государственных услуг);
 предоставление информации о статусе обработки документов (заявок на
предоставление Государственных услуг).
Обмен информацией должен производиться в формате XML.
Заявки на предоставления Государственных услуг, зарегистрированные в РКИС ГУ-ВО (в
случае, если регламент оказания Государственной услуги предусматривает ее оказание данным
ОИГВ ВО), должны быть автоматически переданы в ОИГВ ВО и зарегистрированы в данном
органе (органах) как входящий документ с указанием следующих параметров:
 дата заявки (дата обращения за Государственной услугой);
 номер заявки (уникальный номер, присвоенный в РКИС ГУ-ВО);
 ФИО заявителя;
 наименование Государственной услуги;
 сопроводительные документы (электронные образы);
 дополнительная информация (сведения о месте обращения за Государственной
услугой).
Поступающие документы должны быть автоматически загружены в АСЭД ОИГВ, должен
быть указан вид документа «Заявка на предоставление ГУ».
Согласно действующему регламенту оказания Государственной услуги, заявка может быть
направлена одновременно в несколько ОИГВ ВО.
Заявка подлежит исполнению в ОИГВ ВО согласно действующему Регламенту
Правительства области (как исполнение входящего документа).
Заинтересованным лицам в режиме реального времени должна быть предоставлена
информация:
 номер заявки (уникальный номер, присвоенный в РКИС ГУ-ВО);
стр. 9 из 69

номер заявки (номер входящего документа, присвоенный при регистрации в
государственном органе);
 дата приема заявки к исполнению;
 ФИО ответственного исполнителя;
 информация о статусе исполнения заявки.
После завершения исполнения заявки в ОИГВ ВО должен быть сформирован исходящий
документ, на основании которого в РКИС ГУ-ВО автоматически передается следующая
информация:
 номер заявки (уникальный номер, присвоенный в РКИС ГУ-ВО);
 Номер заявки (номер исходящего документа, присвоенный в ОИГВ ВО);
 дата приема заявки к исполнению;
 дата исполнения заявки;
 ФИО ответственного исполнителя;
 сопроводительные документы (электронные образы).
Точная структура экспортируемой и импортируемой информации должна быть определена
на этапе обследования и формирования техно-рабочего проекта.
1.6.2. ИНТЕГРАЦИЯ АСЭД ОИГВ ВО С АИС «ИП ОИГВ ВО»
АСЭД ОИГВ должна предоставлять возможность интеграции с АИС «ИП ОИГВ ВО» по
следующим направлениям:
 импорт информации о поступающих обращениях;
 экспорт информации об исходящих документах (результат рассмотрения обращения);
 предоставление информации о статусе обработки обращений.
Обмен информацией должен производиться в формате XML.
Заявители обращаются на АИС «ИП ОИГВ ВО» и классифицируют обращение согласно
разделу номенклатуры дел.
В случае, если действующим регламентом предусмотрена обработка обращения в ОИГВ
ВО, информация об обращении заявителя на АИС «ИП ОИГВ ВО» должна быть автоматически
загружена в АСЭД ОИГВ соответствующего ОИГВ ВО (или группы ОИГВ ВО если подобное
предусмотрено действующим регламентом).
Поступающее обращение должно быть
зарегистрировано в АСЭД ОИГВ с указанием вида документа «Обращение граждан». Для
каждого обращения указывается следующая информация:
 дата обращения (дата обращения на АИС «ИП ОИГВ ВО»);
 номер обращения (уникальный номер, присвоенный в АИС «ИП ОИГВ ВО»);
 ФИО заявителя;
 контактная информация заявителя;
 текст обращения;
 раздел номенклатуры дел (классификация обращения).
Обращение подлежит исполнению в ОИГВ ВО согласно действующему Регламенту
Правительства области (как исполнение входящего документа).
Заинтересованным лицам в режиме реального времени должна быть предоставлена
информация:
 номер обращения (уникальный номер, присвоенный в АИС «ИП ОИГВ ВО»);
 номер обращения (номер входящего документа, присвоенный при регистрации в ОИГВ
ВО);
 дата приема обращения к исполнению;
 ФИО ответственного исполнителя;
 информация о статусе исполнения обращения.
стр. 10 из 69
Для обращений, находящихся в процессе обработки, после получения запроса вида:
 Номер обращения (уникальный номер, присвоенный в РКИС ГУ-ВО).
После завершения исполнения обращения в ОГИВ ВО должен быть сформирован
исходящий документ, на основании которого в АИС «ИП ОИГВ ВО» автоматически передается
следующая информация:
 номер обращения (уникальный номер, присвоенный в АИС «ИП ОИГВ ВО»);
 номер обращения (номер исходящего документа, присвоенный в ОИГВ ВО);
 дата приема обращения к исполнению;
 дата исполнения обращения;
 ФИО ответственного исполнителя;
 сопроводительные документы (электронные образы).
Точная структура экспортируемой и импортируемой информации должна быть определена
на этапе обследования и формирования техно-рабочего проекта.
1.6.3. ТРЕБОВАНИЯ К ИНТЕГРАЦИИ АИС «ИП ОИГВ ВО» С АСЭД ОИГВ ВО
В информационном разделе «Электронная приемная» необходимо сформировать форму
обратной связи. Разделы формы обратной связи должны соответствовать следующим
требованиям:
 форма обратной связи не должна запрашивать персональные данные пользователя;
 обязательным полем в форме обратной связи, но не обязательным для заполнения
должно быть поле ввода почтового адреса пользователя для последующего
дублирования ответного письма в бумажном виде;
 дополнительным атрибутом в форме обратной связи должна быть незаполненная
ячейка для указания «галочки» с разрешением публикации заданного вопроса и
полученного ответа в соответствующем информационном разделе АИС «ИП ОИГВ
ВО».
Остальные поля формы обратной связи должны быть согласованы с Заказчиком на этапе
формирования требований и разработки Технического задания.
Полученные данные заполненной формы обратной связи должны проходить
предварительную модерацию на правильность заполнения полей и пресечения получения
вирусных и сообщений рекламного характера. Модерация должна проходить в рамках
функциональности АИС «ИП ОИГВ ВО»
Далее полученные данные должны формироваться в согласованный с Заказчиком формат
выгрузки данных для последующей отправки, обработки и согласования в АСЭД.
1.7. ТРЕБОВАНИЯ К ЛИНГВИСТИЧЕСКОМУ ОБЕСПЕЧЕНИЮ СИСТЕМ
Все прикладное ПО создаваемых систем для организации взаимодействия с пользователем
должно использовать русский язык.

В качестве языков программирования должны использоваться языки
программирования высоко уровня (SQL, C#, HTML, Javascript и другие).
1.8. ОБЩИЕ ТРЕБОВАНИЯ К ЗАЩИТЕ ИНФОРМАЦИИ
Комплексная система должна соответствовать требованиям Федерального закона
Российской Федерации от 27 июля 2006 г. №152-ФЗ «О персональных данных» и требованиям
нормативных актов по защите персональных данных.
Применяемые в системах средства и технологии защиты должны объединяться в
подсистему безопасности (далее по тексту - ПБ). Средства и технологии защиты должны обладать
стр. 11 из 69
свойствами модульности, масштабируемости и возможности адаптации ПБ к различным
организационным и техническим условиям и подключаемым к системам дополнительным
программным компонентам.
Средства защиты, входящие в состав ПБ, должны иметь развитые средства регистрации
критических системных событий в электронных журналах и средства оперативного оповещения
об этих событиях администраторов безопасности.
В ходе выполнения работ на стадии обследования Исполнитель должен определить
требуемые классы защищенности систем и согласовать их с Заказчиком и отделом по защите
информации Правительства области.
В ходе выполнения работ на стадии разработки проектной документации Исполнитель
должен предложить решения по защите информации в соответствии с требованиями
действующих нормативных документов. Исполнитель должен подготовить пакет документов для
аттестации систем на соответствие требованиям действующих нормативных документов по
защите персональных данных.
1.9. ТРЕБОВАНИЯ К ГАРАНТИИ КАЧЕСТВА ПО ВЫПОЛНЕННЫМ РАБОТАМ
Гарантия должна распространяться на все виды выполненных работ.
В виду наличия работ по интеграции внедряемых автоматизированных систем между
собой гарантийные сроки устанавливаются на срок не менее 12 месяцев с момента подписания
сторонами последнего акта-приёмки создаваемых автоматизированных систем в постоянную
эксплуатацию.
В случае выявления в течение этого срока недостатков в программах для ЭВМ или иных
разработках, составляющих результаты работ, Исполнитель обязуется по требованию Заказчика
незамедлительно устранять такие недостатки за свой счет.
Гарантия качества не распространяется на случаи повреждения системы вследствие
действий третьих лиц или нарушений условий эксплуатации системы не по вине Исполнителя.
1.10. ОБЩИЕ ТРЕБОВАНИЯ К НАДЕЖНОСТИ СИСТЕМ
Системы относятся к обслуживаемым восстанавливаемым изделиям общего назначения
многократного циклического применения. Проектные решения должны обеспечивать два уровня
надежности:

уровень сохранности работоспособности - сохранение работоспособности систем
при отказе или выходе из строя по любым причинам одного из компонентов комплекса
технических средств или части телекоммуникационной системы;

уровень сохранности данных - сохранение всей накопленной на момент отказа или
выхода из строя информации при отказе двух и более одинаковых по назначению программных
компонентов систем, независимо от их назначения, с последующим восстановлением после
проведения ремонтных и восстановительных работ функционирования систем.
В зависимости от степени критичности для штатного функционирования систем
значениями показателей надежности являются:

критичный случай - время на обслуживание и ремонт или замену вышедшего из
строя программного компонента – не более 2-х часов;

не критичный случай - время на обслуживание и ремонт или замену вышедшего из
строя программного компонента – не более 6-х часов;

критичный случай - время на обслуживание вышедшего из строя программного
компонента, которое проводится в процессе его эксплуатации – не более 2-х часов;

не критичный случай - время на обслуживание вышедшего из строя программного
компонента, которое проводится в процессе его эксплуатации – не более 4-х часов;
стр. 12 из 69

критичный случай - время на восстановление вышедшего из строя программного
компонента – не более 2-х часов;

не критичный случай - время на восстановление вышедшего из строя программного
компонента – не более 6-х часов;

критичный случай - время на восстановление работоспособности (включает время на
локализацию и диагностирование проблемы, замену и ремонт оборудования, конфигурирование
оборудования и ПО, восстановление данных и тестирование работоспособности технических
средств и ПО) – не более 2-х часов;

не критичный случай - время на восстановление работоспособности (включает время
на локализацию и диагностирование проблемы, замену и ремонт оборудования,
конфигурирование оборудования и ПО, восстановление данных и тестирование
работоспособности технических средств и ПО) – не более 6-х часов.
В целом, надежность систем должна соответствовать возможности штатного выполнения
функций со временем однократного простоя не более 2-х часов и суммарным временем простоя
не более 16 часов в год.
Степень критичности определяется Заказчиком.
Сохранность информации должна обеспечиваться:
 при пожарах, затоплениях, землетрясениях и других стихийных бедствиях:
организационными и защитными мерами, опирающимися на подготовленность помещений и
персонала, обеспечивающими сохранность хранимых копий информации на магнитном носителе;
 при механических и электронных сбоях и отказах в работе компьютеров: на основе
программных процедур восстановления информации с использованием хранимых копий баз
данных, файлов журналов изменений в базах данных, копий программного обеспечения.
В системах должно быть обеспечено автоматическое резервирование баз данных,
восстановление целостности баз данных и диагностирование программно-технических средств.
Для обеспечения сохранности информации в системах должны выполняться следующие
функции:

резервное копирование баз данных систем;

восстановление данных в непротиворечивое состояние при программно-аппаратных
сбоях (отключение электрического питания, сбоях операционной системы и других)
вычислительно-операционной среды функционирования;

восстановление данных в непротиворечивое состояние при сбоях в работе сетевого
программного и аппаратного обеспечения.
Программное обеспечение систем должно автоматически восстанавливать свое
функционирование при корректном перезапуске аппаратных средств. В системах должна быть
реализована возможность организации автоматического или ручного резервного копирования с
использованием стандартных программных и аппаратных средств, для обеспечения сохранности
резервных копий.
При сбоях серверов резервное копирование должно проводиться непосредственно на
альтернативные носители.
Системы должны обеспечивать:

сохранение работоспособности при отказе или выходе из строя по любым причинам
одного из компонентов комплекса технических средств или средств телекоммуникации;

сохранение всей накопленной на момент отказа или выхода из строя информации с
последующим восстановлением после проведения ремонтных и восстановительных работ
функционирования систем.
стр. 13 из 69
Под отказом или выходом из строя понимается прекращение штатного функционирования
компонент систем из-за ошибок в программном коде, сбоев аппаратных средств компьютера и
пользовательских ошибок.
Действия по восстановлению работоспособности при отказе или выходе из строя
компонент систем регламентируются условиями гарантии и Соглашениями о технической
поддержке, представляемыми производителями программного обеспечения и технических
средств защиты.
Должны быть реализованы механизмы обеспечения
контроля целостности
конфиденциальной информации, обрабатываемой в автоматизированных системах. Требования
должны реализовываться средствами системы управления базами данных.
1.11. ПОРЯДОК КОНТРОЛЯ И ПРИЕМКИ АВТОМАТИЗИРОВАННЫХ СИСТЕМ
Виды, состав, объём и методы испытаний для всех разрабатываемых систем должны
соответствовать требованиям ГОСТ 34.603-92 «Виды испытаний автоматизированных систем».
Должны быть предусмотрены следующие виды испытаний:
 предварительные испытания;
 опытная эксплуатация;
 приёмочные испытания.
Для планирования проведения всех видов испытаний должны использоваться документы
«Программа и методика испытаний», разрабатываемые Исполнителем по требованиям РД 5034.698-90 «Автоматизированные системы. Требования к содержанию документов».
Состав приёмочной комиссии, место и время проведения испытаний определяются
распорядительным документом Заказчика.
В состав комиссии по проведению испытаний должны входить представители Заказчика,
Исполнителя и ОИГВ области, участвующих в эксплуатации систем.
Каждый вид испытаний должен завершаться оформлением соответствующего акта с
приложением протоколов испытаний.
Испытания и приемка в постоянную эксплуатацию интеграционного модуля внедряемых
систем должны проводиться после готовности подсистем интеграции всех внедряемых систем в
рамках настоящего открытого конкурса.
1.12. ТРЕБОВАНИЯ К ДОКУМЕНТИРОВАНИЮ
Порядок оформления и предъявления результатов работ по созданию автоматизированных
систем должен соответствовать требованиям комплекса стандартов и руководящих документов на
автоматизированные системы в соответствии с ГОСТ 34.201, ГОСТ 34.602, ГОСТ 34.601, ГОСТ
34.603, ГОСТ 2.105, ГОСТ РД 50.698, ГОСТ 2.102.
Для каждой из создаваемых систем должны быть разработаны следующие документы:
 Отчет об обследовании объектов автоматизации.
 Пояснительная записка к техническому (техно-рабочему) проекту.
 Технический (техно-рабочий) проект.
 Ведомость покупных изделий (спецификация программных средств и технического
оборудования), необходимых для успешной реализации государственного контракта и развития
автоматизированных систем в будущем.
 Руководство администратора.
 Руководство пользователя.
 Программа и методика предварительных испытаний.
 Программа и методика опытной эксплуатации.
 Программа и методика приёмочных испытаний.
стр. 14 из 69
 Вспомогательная документация (не указанная в качестве непосредственного результата
работ по Государственному контракту), а также разработанное прикладное программное
обеспечение (включая исходные коды с комментариями) передается только в электронном виде.
Документация должна быть выполнена на русском языке.
Документация должна быть выпущена на бумажных (2 экземпляра) и электронных
носителях (1 экземпляр на CD в формате MS Office Word).
1.13. ТРЕБОВАНИЯ К ОРГАНИЗАЦИОННО ПРАВОВЫМ АСПЕКТАМ
Проектные решения построения систем должны отвечать требованиям к патентной чистоте
согласно действующему законодательству РФ; должны соблюдаться положения нормативных
правовых актов РФ по соблюдению авторских прав и защиты специальных знаков.
Реализация технических, программных, организационных и иных решений,
предусмотренных техническими проектами систем, не должна приводить к нарушению авторских
и смежных прав третьих лиц.
При использовании в системах программ (программных комплексов или компонентов),
разработанных третьими лицами, условия, на которых передается право на использование
(исполнение) этих программ, не должны накладывать ограничений, препятствующих
использованию системы по ее прямому назначению.
При создании систем должно использоваться лицензионное программное обеспечение:
операционные системы, программные средства разработки специальное программное
обеспечение и др.
Исключительные права на результаты выполненных работ должны принадлежать
Вологодской области.
ТРЕБОВАНИЯ
ПО
СОЗДАНИЮ
ПЕРВОЙ
ОЧЕРЕДИ
АВТОМАТИЗИРОВАННОЙ СИСТЕМЫ РКИС ГУ–ВО
Пользователями РКИС ГУ-ВО являются сотрудники ОИГВ, ведомств, организаций и
учреждений Вологодской области, участвующие в процессах оказания государственных услуг,
технические специалисты и операторы, обеспечивающие эксплуатацию, а также физические или
юридические лица, имеющие право в соответствии с законодательством Российской Федерации и
(или) Вологодской области на получение государственных услуг на территории Вологодской
области.
2.
2.1. ПЛАНОВЫЕ СРОКИ НАЧАЛА И ОКОНЧАНИЯ РАБОТ
Разработка РКИС ГУ-ВО ведётся исполнителем в форме технического (техно-рабочего)
проекта.
РКИС ГУ-ВО должна вводиться в действие поэтапно в следующей последовательности:

Этап I: Пилотное внедрение.

Этап II: Тиражирование 2010.

Этап III: Тиражирование 2011.

Этап IV: Автоматизация многофункциональных центров оказания услуг населению.
В рамках настоящего конкурса должны быть выполнены работы этапа I: Пилотное
внедрение. Перечень работ и планируемая продолжительность этапа I приводится в пункте 2.16
настоящих ТТ.
Начало работ этапа I - с момента подписания государственного контракта.
Окончание работ этапа I – в течение 34 недель с момента подписания государственного
контракта.
2.2. ЦЕЛИ СОЗДАНИЯ РКИС ГУ-ВО.
стр. 15 из 69
Основными целями создания РКИС ГУ-ВО являются:

повышение качества оказания государственных услуг Вологодской области,
предоставляемых гражданам и хозяйствующим субъектам за счет снижения сроков их оказания, и
обеспечения комфортных условий при получении государственных услуг;

повышение уровня информированности граждан и организаций о деятельности
органов государственной власти и ОМС Вологодской области за счет расширения возможностей
доступа к информации о государственных услугах;

обеспечение многообразия форм взаимодействия органов государственной власти и
ОМС Вологодской области с гражданами;

повышение прозрачности деятельности органов государственной власти и ОМС
Вологодской области;

повышение качества исполнения административных регламентов и принимаемых
решений, необходимых для реализации государственных услуг;

обеспечение оперативности и полноты контроля за результативностью деятельности
органов государственной власти и ОМС Вологодской области.
2.3. ЗАДАЧИ СОЗДАНИЯ РКИС ГУ-ВО.
РКИС ГУ–ВО должна обеспечивать решение следующих задач:

дистанционное предоставление заявителям общей информации об услуге: порядок
получения услуги и адреса мест приема документов для предоставления услуги;

возможность дистанционно получить формы документов, необходимые для
получения услуги;

информационное обеспечение процесса дистанционного обучения пользователей
РКИС ГУ–ВО и предоставления методических материалов.

возможность разработки и внедрения разнообразных механизмов взаимодействия
органами государственной власти и ОМС Вологодской области с гражданами, в том числе за счет
предоставления интерактивных сервисов по дистанционному получению государственных услуг
(Интернет, телефон, электронная почта, sms, факс);

возможность моделирования и исполнения автоматизированных регламентов по
оказанию государственных услуг, включая процессы электронного взаимодействия, в том числе
межведомственного;

автоматизация регламентов оказания 10 государственных услуг до 5 этапа из перечня
государственных и муниципальных услуг Плана перехода на предоставление в электронном виде
государственных и муниципальных услуг, утвержденного распоряжением Губернатора
Вологодской области от 1 июля 2010 года № 2199-р, определенных в ходе обследования объектов
автоматизации и формирования техно-рабочего проекта;

возможность интеграции отдельных элементов РКИС ГУ–ВО с информационными
системами федерального уровня (в соответствии с постановлением Правительства РФ от
15.06.2009 г. № 478 «О единой системе информационно-справочной поддержки граждан и
организаций по вопросам взаимодействия с органами исполнительной власти и органами
местного самоуправления с использованием информационно-телекоммуникационной сети
Интернет»), а также с ведомственными информационными системами ОИГВ ВО и структурных
подразделений Правительства Вологодской области.
Заявитель должен иметь возможность:

оформить все необходимые документы в удобном для него месте при наличии
доступа к сети Интернет для подачи в удобное для него время в соответствующий орган
государственной власти области или ОМС ВО;

предоставить в режиме реального времени в электронном виде документы для
получения услуги, в том числе путем заполнения электронных форм и предоставления
электронных копий документов;
стр. 16 из 69

получать доступ в режиме реального времени к информации о ходе предоставления
услуги, в том числе о результатах рассмотрения его документов: выдерживается ли срок
выполнения административных процедур, какие решения приняты (мониторинг и контроль
качества оказания услуг);

получить результат услуги полностью в электронном виде1.
2.4. ХАРАКТЕРИСТИКА АВТОМАТИРУЕМЫХ ПРОЦЕССОВ
Автоматизируемыми процессами является деятельность ОИГВ ВО и ОМС ВО, по
оказанию государственных и муниципальных услуг гражданам и организациям.
К административным процедурам, совершаемым при предоставлении услуг, относятся:

консультирование о порядке и сроках подготовки документов;

проверка правильности оформления заявления и прилагаемого к нему пакета
документов;

регистрация обращений к электронной базе данных и выдача заявителю выписки
из электронного журнала, подтверждающей факт приема заявления для исполнения и дату выдачи
запрашиваемого документа;

формирование и направление запросов в другие организации с целью получения
согласований и заключений, необходимых для подготовки требуемого заявителем документа;

контроль за сроками исполнения согласований и общим сроком подготовки
документа;

регистрация подготовленного документа в электронной базе данных;

оповещение заявителя в случае, если документ подготовлен в более ранние сроки;

выдача заявителю запрашиваемого документа или мотивированного отказа;

представление информационно-справочных и дополнительных услуг.
2.5. ОСОБЕННОСТИ УСЛОВИЙ ЭКСПЛУАТАЦИИ
Внедрение РКИС-ГУ ВО предполагает установку прикладного программного обеспечения
как внутри одной ЛВС, объединяющей ОИГВ ВО, расположенные в рамках одного здания, так и
на объектах, находящихся в удаленных ЛВС в территориально-обособленных зданиях.
2.6. ТРЕБОВАНИЯ К РАБОТАМ ПО ВНЕДРЕНИЮ РКИС ГУ-ВО
Для развертывания РКИС ГУ–ВО должны быть выполнены следующие работы:

в случае обоснования необходимости замены автоматизированных информационных
систем «Портал муниципальных услуг (функций) Вологодской области» (www.gosuslugi.gov35.ru)
и «Реестр государственных и муниципальных услуг (функций) Вологодской области» необходимо
осуществить:
 развертывание нового системного и специального программного обеспечения РКИС
ГУ–ВО;
 наполнение нового, регионального Портала государственных и муниципальных
услуг (функций) Вологодской области, его интеграцию с федеральным порталом
государственных и муниципальных услуг (в соответствии с требованиями
Постановления Правительства РФ от 15 июня 2009 г. № 478), интеграцию с Реестром
государственных и муниципальных услуг (функций) Вологодской области и с
Предоставление услуг полностью в электронном виде на пятом этапе не
исключает необходимости предоставления заявителем (лично или посредством
почтовой связи) материальных объектов (вещей), за исключением документов, а
также необходимости осуществления личного взаимодействия заявителя с
работниками органов государственной власти по обстоятельствам, не связанным
с приемом документов, если указанная необходимость установлена федеральным
законом.
1
стр. 17 из 69
региональным Порталом государственных и муниципальных услуг (функций)
Вологодской области;
 интеграцию с функционирующим в МФЦ города Вологды Контакт-центром.

развертывание всех подсистем РКИС ГУ-ВО2;

настройку взаимодействия всех подсистем РКИС ГУ-ВО;

настройку автоматизированных регламентов в РКИС ГУ-ВО;

установку программного обеспечения автоматизированных рабочих мест;

настройку информационного взаимодействия РКИС ГУ-ВО и информационных
систем территориальных подразделений федеральных органов государственной власти;

наполнение базы знаний Контакт-центра справочной информацией и запуск Контактцентра в опытную эксплуатацию

обучение персонала работе с РКИС ГУ-ВО;

разработку эксплуатационной документации;

разработку проектов необходимых нормативно-правовых актов для легитимации
процесса межведомственного электронного взаимодействия и осуществить их сопровождение до
принятия и придания юридической значимости;

проведение предварительных испытаний;

проведение опытной эксплуатации;

проведение приемочных испытаний.
Состав работ должен быть уточнен на этапе обследования объектов автоматизации и
подготовки техно-рабочего проекта.
2.7. ТРЕБОВАНИЯ К СТРУКТУРЕ И ФУНКЦИОНИРОВАНИЮ РКИС ГУ-ВО
РКИС ГУ-ВО должна состоять из следующих подсистем:

подсистема обработки обращений заявителей;

подсистема моделирования автоматизированных регламентов;

подсистема управления автоматизированными регламентами;

подсистема мониторинга и контроля процессов оказания государственных услуг;

подсистема «Портал государственных и муниципальных услуг (функций)»;

подсистема «Реестр государственных и муниципальных услуг (функций)»;

подсистема Контакт-центр;

подсистема дистанционного обучения.
Создание РКИС ГУ-ВО должно быть ориентировано, в первую очередь, на заявителя,
предоставляя ему: свободу выбора способов взаимодействия; обеспечивая конфиденциальность
сведений, получаемых от граждан и организаций; предоставляя различные варианты условий
получения государственных услуг.
При создании РКИС ГУ-ВО должны быть учтены особенности существующей
инфраструктуры и информационных систем, в том числе предназначенных для автоматизации
деятельности ОИГВ ВО при оказании государственных услуг.
Система должна проектироваться как набор независимых компонент, взаимодействующих
между собой на высоком уровне по заданным интерфейсам и протоколам.
В рамках создания РКИС ГУ-ВО должно быть осуществлено и налажено информационное
взаимодействие с различными информационными системами и ресурсами ОИГВ ВО,
территориальных органов федеральных органов исполнительной власти Вологодской области,
ОМС ВО.
Перечень подсистем РКИС ГУ-ВО определяется настоящим Техническим заданием
(п. 2.7.).
2
стр. 18 из 69
РКИС ГУ-ВО должна обеспечивать интеграцию с АСЭД ОИГВ в части направления
электронных запросов на получение недостающих сведений или подтверждение имеющихся и
получение ответа на электронный запрос.
2.8. ТРЕБОВАНИЯ ПО ВЗАИМОСВЯЗЯМ РКИС ГУ-ВО С ВНЕШНИМИ И СО
СМЕЖНЫМИ
АВТОМАТИЗИРОВАННЫМИ
СИСТЕМАМИ,
ОБЕСПЕЧЕНИЮ
ЕЕ
СОВМЕСТИМОСТИ
Взаимодействия со смежными системами должны строиться на использовании
унифицированных подходов. В качестве основного протокола взаимодействия должен
использоваться протокол SOAP версии 1.2 (http://www.w3.org/TR/soap12-part0/) или выше. Для
передачи
бинарных
данных
должен
использоваться
стандарт
MTOM
(http://www.w3.org/TR/soap12-mtom/). Все работы должны быть осуществлены в рамках
исполнения государственного контракта по данному открытому конкурсу.
2.9. ТРЕБОВАНИЯ К ЭРГОНОМИКЕ И ТЕХНИЧЕСКОЙ ЭСТЕТИКЕ
Программное обеспечение (далее по тексту - ПО) должно обеспечивать удобный для
пользователя интерфейс, отвечающий следующим требованиям:

взаимодействие пользователя с РКИС ГУ–ВО должно осуществляться на русском
языке;

в части диалога с пользователем при создании РКИС ГУ–ВО должен быть обеспечен
удобный и интуитивно понятный интерфейс3 для пользователя, который хорошо знает свою
предметную область и не является специалистом в области информационных технологий;

должно быть обеспечено предоставление контекстно-зависимой помощи, интерфейс
пользователя должен способствовать уменьшению вероятности совершения оператором
случайных ошибочных действий.
Пользовательские интерфейс РКИС ГУ–ВО должен быть спроектирован и разработан с
применением единых принципов графического представления информации и организации
доступа к функциональным возможностям и сервисам. Должен быть разработан графический
дизайн пользовательского интерфейса, цветовые, шрифтовые и композиционные решения для
отображения текстов, изображений, таблиц, гиперссылок, управляющих и навигационных
элементов (меню, кнопок, форм и т.п.).
2.10. ТРЕБОВАНИЯ К ЗАЩИТЕ ИНФОРМАЦИИ
РКИС ГУ–ВО должна обеспечивать разграничение и администрирование доступа к
данным и функциям системы в соответствии с полномочиями групп пользователей
установленных в системе.
Система информационной безопасности РКИС ГУ–ВО должна быть основана на
подсистеме безопасности Active Directory, все настройки безопасности должны осуществляться в
интерфейсе РКИС ГУ–ВО.
Все обращения пользователей к информационным ресурсам РКИС ГУ–ВО должны
авторизовываться, должна осуществляться проверка прав доступа к информации и разрешенным
операциям на основе матрицы доступа и ролей пользователей.
При доступе операторов и экспертов к РКИС ГУ–ВО должна осуществляться
идентификация и аутентификация субъектов доступа по идентификатору и паролю условнопостоянного действия, длиной не менее шести буквенно-цифровых символов.
3
Критериями интуитивно понятного интерфейса являются:


функциональная группировка элементов (разделы меню или их аналоги) должна соответствовать
функциональным задачам и технологии работы;
сигнализация об ошибках или ошибочных действиях пользователей.
стр. 19 из 69
В рамках РКИС ГУ–ВО должна осуществляться регистрация входа (выхода) операторов в
систему (из системы). Для серверных компонентов должна обеспечиваться регистрация загрузки
основных модулей РКИС ГУ–ВО. В параметрах регистрации должны указываться дата и время
входа (выхода) оператора в систему (из системы) или загрузки (останова) РКИС ГУ–ВО.
РКИС ГУ–ВО должна протоколировать все нештатные ситуации с указанием даты,
времени и описания нештатной ситуации.
Сохранность информации в РКИС ГУ–ВО должна обеспечиваться при аварийных
ситуациях:

полный или частичный отказ технических средств РКИС ГУ–ВО, включая сбои и
отказы накопителей на жестких магнитных дисках;

сбой общего или специального ПО;

ошибки в работе персонала.
В целях сохранности информации РКИС ГУ–ВО при авариях должно быть предусмотрено
оперативное ежедневное резервное копирование (архивирование) информации из базы данных
(далее по тексту - БД) РКИС ГУ–ВО с хранением архивных копий.
Восстановление данных должно осуществляться в соответствии со следующими
требованиями:

при аварии или сбое в процессе выполнения пользовательских задач должно быть
обеспечено восстановление БД до состояния на момент последней завершенной системой
управления базами данных (далее по тексту – СУБД) транзакции;

при повреждении журналов регистрации СУБД должно быть обеспечено
восстановление БД до состояния на момент создания последней резервной копии данных, но не
позднее, чем за сутки до момента сбоя;

восстановление БД с резервной копии должно осуществляться средствами СУБД.
В случае повреждения данных РКИС ГУ–ВО должна обеспечивать восстановление
состояния РКИС ГУ–ВО на момент создания последней резервной копии данных, но не более чем
за сутки до момента сбоя.
Для обеспечения защиты данных от разрушений при авариях и сбоях в процессе
выполнения пользовательских задач при повреждении журналов регистрации СУБД должно быть
обеспечено создание резервных копий БД.
Иные требования по защите информации при передаче информации по каналам связи и
использования корпоративной сети должны быть разработаны в ходе выполнения работ этапа I
после проведения обследования объектов автоматизации.
2.11. ТРЕБОВАНИЯ К ФУНКЦИЯМ (ЗАДАЧАМ) ВЫПОЛНЯЕМЫМ РКИС ГУ–ВО
2.11.1. ТРЕБОВАНИЯ К ПОДСИСТЕМЕ ОБРАБОТКИ ОБРАЩЕНИЙ ЗАЯВИТЕЛЕЙ
Подсистема обработки обращений заявителей предназначена для обеспечения процессов
взаимодействия с гражданами и организациями в части предоставления государственных услуг, а
также хранения истории этого взаимодействия и оперативного доступа к ней.
Подсистема обработки обращений заявителей должна включать в себя следующие модули:

модуль регистрации обращений. Модуль должен обеспечивать регистрацию
обращений заявителя, с указанием всех данных по обращению и регистрацию документов
представленных заявителем;

модуль исполнения обращений. Модуль должен обеспечивать отслеживание
жизненного цикла подготовки итогового документа, в целях оказания государственной услуги, в
том числе отслеживание обмена информацией с организациями, обеспечивающими подготовку
документов;
стр. 20 из 69

модуль регистрации выдачи подготовленных по обращению документов. Модуль
должен обеспечивать регистрацию факта выдачи заявителю документа, подготовленного в
результате оказания государственной услуги;

модуль администрирования. Модуль должен обеспечивать возможность настройки
подсистемы в части перечня оказываемых услуг, взаимодействия с организациями,
обеспечивающими подготовку документов, разграничение ролей пользователей.
Подсистема обработки обращений заявителей должна обеспечивать:

использование механизмов описания государственных услуг, в том числе:
 возможность гибкой настройки плановых сроков оказания услуг, в соответствии с
регламентом оказания услуги;
 возможность настройки перечня обязательных документов, необходимых для
представления заявителем для получения услуги;
 возможность настройки связи оказываемой услуги и организации(-ий),
обеспечивающей подготовку итоговых документов;
 возможность указания признака платности оказания услуги и размер стоимости
оказания услуги, если стоимость фиксирована и утверждена соответствующими
нормативными актами.

возможность указания специфических атрибутов по каждой услуге, в соответствии с
требования организации, осуществляющей подготовку документов;

регистрацию обращений заявителей с указанием следующих параметров4:
 фамилия, имя, отчество заявителя (для физических лиц и индивидуальных
предпринимателей);
 наименование заявителя (для юридических лиц);
 ИНН и КПП (для юридических лиц и индивидуальных предпринимателей);
 паспортные данные заявителя (для физических лиц и индивидуальных
предпринимателей), в составе: серия паспорта, номер паспорта, кем выдан паспорт,
дата выдачи паспорта, дата рождения заявителя;
 адрес регистрации заявителя, в составе: населенный пункт, улица, дом, сооружение
(при необходимости), строение (при необходимости), корпус (при необходимости),
«/» (номер дома после дроби - при необходимости), квартира;
 фактический адрес заявителя, в составе: населенный пункт, улица, дом, сооружение
(при необходимости), строение (при необходимости), корпус (при необходимости),
«/» (номер дома после дроби - при необходимости), квартира;
 контактные данные заявителя: номер домашнего телефона, номер рабочего телефона,
номер мобильного телефона, номер факса, адрес электронной почты (до трех
адресов);
 данные доверенного лица (в случае предоставление документов по обращению
представителем заявителя): фамилия, имя, отчество доверенного лица, паспортные
данные доверенного лица (серия паспорта, номер паспорта, кем выдан паспорт, дата
выдачи паспорта, дата рождения); адрес регистрации доверенного лица: населенный
пункт, улица, дом, сооружение (при необходимости), строение (при необходимости),
корпус (при необходимости), «/» (номер дома после дроби - при необходимости),
квартира); фактический адрес проживания доверенного лица: населенный пункт,
улица, дом, сооружение (при необходимости), строение (при необходимости), корпус
(при необходимости), «/» (номер дома после дроби - при необходимости), квартира;
контактные данные доверенного лица: номер домашнего телефона, номер рабочего
телефона, номер мобильного телефона, номер факса, адрес электронной почты (до
трех адресов); данные документа-основания (тип документа, на основании которого
Для каждой услуги должна быть реализована возможность настройки
обязательности параметров, необходимых для регистрации обращения (Настройка
должна осуществляться Администратором подсистемы).
4
стр. 21 из 69
действует доверенное лицо, номер документа, дата документа, кем подписан
документ, срок действия документа, на основании которого действует доверенное
лицо);
 перечень документов, представленных заявителем при обращении, который должен
отображаться в виде предопределенного списка, наличие документа в
представленном заявителем комплекте подтверждается указанием атрибутов
документа напротив соответствующего наименования;
 атрибуты документов, представленных заявителем при обращении. Атрибутивный
состав каждого документа должен включать в себя номер документа, дату документа,
количество листов, количество экземпляров, примечание;
 перечень дополнительных документов, представленных заявителем при обращении,
который должен заполняться путем добавления записей в перечень документов,
представленных заявителем;
 специфические параметры, характерные для каждого типа обращения и необходимые
для передачи данных по обращению в организацию, обеспечивающую подготовку
документов;
 наименование организации, в которую будет направлен пакет документов по
обращению для подготовки итогового документа;
 краткое содержание обращения;
 стоимость услуги;
 количество экземпляров итогового документа;

автоматическое указание параметров по обращению, в том числе:
 дата регистрации обращения;
 регистрационный номер обращения, формируемый по порядку в рамках
календарного года;
 плановый срок подготовки запрашиваемого документа по обращению (в
соответствии с регламентом оказания данной услуги);
 плановая дата выдачи документа заявителю.

регистрацию пакета обращений, состоящего из государственных услуг, оказываемых
различными организациями и в различные сроки, но для одного заявителя, с обеспечением
возможности однократного заполнения общих атрибутов по обращению в рамках пакета;

возможность сохранения данных по пакету обращений до его регистрации;

возможность автоматической сортировки документов при потоковом сканировании и
автоматического прикрепления отсканированных копий документов к пакету обращений;

поддержку всего жизненного цикла обращения:
 регистрация;
 выдача выписки установленного образца, подтверждающей факт регистрации
обращения;
 выдача квитанции на оплату услуг;
 регистрация факта оплаты услуг (или получение информации из автоматизированной
системы Казначейства, если возможно);
 отправка в организации, участвующие в процессе подготовки итогового документа;
 регистрацию факта выдачи документа заявителю.

ввод и хранение информации о заявителях, обратившихся за государственными
услугами;

отображение информации о заявителях, обратившихся за государственными
услугами в процессе поиска обращений;

определение наличия в БД учётных записей заявителей при последующих
обращениях заявителя отображение сохраненной в базе данной информации, возможность ее
выбора для добавления в карточку обращения;

редактирование вновь сохраненных данных заявителя;

поиск записи в БД заявителей;
стр. 22 из 69

автоматический контроль сроков обработки обращения и оповещение исполнителей
и ответственных лиц о приближении и наступлении контрольного срока;

запуск и мониторинг выполнения автоматизированного регламента по каждой услуге
в подсистеме управления автоматизированными регламентами с передачей атрибутов обращения;

автоматическое или автоматизированное формирование заданий для Контакт-центра
на уведомление заявителя по электронной почте или по телефону при наступлении определенных
событий;

хранение и представление полной истории обращений заявителя за
государственными услугами;

поиск обращений в БД по:
 основным атрибутам обращения, характеризующим тип, сроки подготовки и
регистрации обращений;
 заявителю;
 статусу выполнения работ по обращению.

формирование квитанций для оплаты платной услуги в форме, достаточной для
предъявления в кассе, банке или платежном терминале;

формирование выписки из электронного журнала обращений;

добавление, хранение, удаление и редактирование данных по пользователям
подсистемы с обязательным указанием:
 ФИО пользователя;
 логин пользователя для входа в подсистему;
 пароль пользователя для входа в подсистему;
 должность сотрудника в рамках организации;

настройку и разграничение прав пользователей подсистемы, с возможностью
настройки доступных функций и прав на удаление и редактирование информации.
Данный перечень функций подсистемы не является конечным, в ходе обследования
объектов автоматизации и подготовки техно-рабочего проекта он должен быть расширен и
уточнен.
В подсистеме должен быть предусмотрен раздел, содержащий проекты обращений
граждан, сформированные пользователями подсистемы Портала государственных и
муниципальных услуг (функций) Вологодской области и операторами Контакт-центра. Должна
быть обеспечена возможность направления обращения в работу, при этом генерируется номер
обращения и планируемая дата подготовки ответа. Должна быть реализована возможность отказа
в приеме обращения на обработку с формированием описания причины отказ. При изменении
статуса информация должна поступать на Портал государственных и муниципальных услуг
(функций) Вологодской области и в Контакт-центр для информирования заявителя, включая
информацию о номере обращения, и планируемой дате подготовки ответа или причине отказа.
2.11.2. ТРЕБОВАНИЯ
К
ПОДСИСТЕМЕ
МОДЕЛИРОВАНИЯ
АВТОМАТИЗИРОВАННЫХ РЕГЛАМЕНТОВ
Подсистема моделирования автоматизированных регламентов должна позволять описать
все этапы процесса оказания государственной услуги с указанием для каждого этапа срока
выполнения, ответственных за выполнение этапа и данных, необходимых для выполнения этапа.
Подсистема должна позволять моделировать этапы регламента, выполняемые в различных
организациях и различных информационных системах с указанием данных, передающихся в
процессе выполнения. Моделирование автоматизированных регламентов должно осуществляться
без использования средств программирования. Должна существовать возможность вывода на
экран и печать моделей регламентов в графическом и текстовом виде, выгрузка в формат данных,
определяемый на этапе обследования.
Подсистема моделирования автоматизированных регламентов должна обеспечивать
следующие возможности:
стр. 23 из 69

использование технологии Microsoft Windows Workflow Foundation;

использование библиотеки шаблонов автоматизированных регламентов;

использование библиотеки активностей автоматизированных регламентов;

использование подпроцессов;

использование ветвления и ожидания выполнения нескольких условий;

гибкая настройка событий для запуска регламента, возможность использования
событий регистрации обращения и изменения атрибутов обращения;

возможность использования циклических процессов с сохранением атрибутов на
каждой итерации;

возможность динамического получения атрибутов регламента при его запуске;

возможность подключения новых библиотек шаблонов регламента и библиотек
активностей;

другие необходимые возможности, выявленные в ходе обследования объектов
автоматизации.
Подсистема моделирования автоматизированных регламентов должна быть интегрирована с
подсистемой управления автоматизированными регламентами.
2.11.3. ТРЕБОВАНИЯ К ПОДСИСТЕМЕ УПРАВЛЕНИЯ АВТОМАТИЗИРОВАННЫМИ
РЕГЛАМЕНТАМИ
Подсистема управления автоматизированными регламентами должна позволять запускать,
останавливать, приостанавливать и возобновлять выполнение регламента, вносить изменения в
регламент. Подсистема должна быть проинтегрирована с подсистемой обработки обращений и
обеспечивать движение зарегистрированных в подсистеме обращений в соответствии с
административным регламентом.
Подсистема управления автоматизированными регламентами должна обеспечивать
следующие возможности:

ручной или автоматический запуск регламента;

приостановка и возобновление регламента;

внесение изменений в уже запущенный регламент;

мониторинг выполнения запущенных регламентов;

возможность поиска регламента в системе по его атрибутам;

другие необходимые возможности, выявленные в ходе обследования объектов
автоматизации.
2.11.4. ТРЕБОВАНИЯ К ПОДСИСТЕМЕ МОНИТОРИНГА И КОНТРОЛЯ ПРОЦЕССОВ
ОКАЗАНИЯ ГОСУДАРСТВЕННЫХ УСЛУГ
Основными задачами подсистемы мониторинга и контроля процессов оказания
государственных услуг являются анализ и контроль ключевых показателей эффективности
процессов оказания государственных услуг.
Подсистема мониторинга и контроля процессов оказания государственных услуг должна
обеспечивать решение следующих основных задач:

сбор статистической информации, формирование и сопровождение БД о состоянии
процессов оказания государственных услуг на основании сведений, получаемых из других
подсистем и информационных систем органов ОИГВ ВО и ОМС ВО, участвующих в процессах
оказания государственных услуг, для чего должно быть обеспечено:
 создание БД, содержащей информацию о состоянии процессов оказания
государственных услуг;
 создание унифицированных веб-сервисов по получению необходимой информации из
других подсистем автоматизированных информационных систем ОИГВ ВО и ОМС
ВО (при необходимости);
стр. 24 из 69

аналитическую обработку и подготовку информации из БД статистической
информации о состоянии процессов оказания государственных услуг для представления по
запросам пользователей в табличном и графическом видах.
Перечень задач подсистемы должен быть доработан и уточнен в ходе обследования
объектов автоматизации и подготовки техно-рабочего проекта.
РКИС ГУ–ВО должна представлять статистическую информацию в следующих видах:

в виде отчетов в соответствии с вводимыми пользователями критериями;

в виде оперативной сводки: набор индикаторов, информирующих пользователей о
состоянии работы ОИГВ ВО и ОМС ВО в части предоставления государственных услуг;

в других видах, определенных в ходе обследования объектов автоматизации.
РКИС ГУ–ВО должна предоставлять следующие отчеты:

количество принятых обращений за период, в том числе с разбивкой по услугам;

количество обращений, отправленных для исполнения в организации,
обеспечивающие подготовку документов обращений, в том числе с разбивкой по типам
обращений;

количество исполненных обращений, в том числе с нарушением срока, также с
разбивкой по типам обращений;

количество обращений, по которым документы выданы заявителям, а также
количество обращений, по которым заявитель не явился за документом, в том числе с разбивкой
по типам обращений;

количество обращений, находящихся на исполнении, в том числе с разбивкой по
типам обращений;

количество обращений, находящихся на исполнении, по которым срок исполнения
заканчивается в указанный при формировании отчета период, в том числе с разбивкой по типам
обращений;

количество обращений, находящихся на исполнении, срок исполнения которых уже
истек, в том числе с разбивкой по типам обращений;

количество отозванных заявителем документов;

количество обращений, поступивших в Контакт-центр, с разбивкой по формам
обращения (телефон, Интернет, электронная почта, визит);

количество обращений сформированных на Портале государственных и
муниципальных услуг (функций) Вологодской области;

количество услуг, оказанных в электронной форме.
Данный перечень отчетов не является конечным. Вид, состав отчетов и их перечень
должны быть уточнены в ходе обследования объектов автоматизации и подготовки технорабочего проекта.
Индикаторы должны представлять собой графическое представление показателей
эффективности оказания государственных услуг. Каждый показатель рассчитывается на
основании других показателей или первичных статистических данных.
Подсистема также должна обеспечивать:

отображение в систематизированном виде системы показателей и их оценки;

отображение динамики изменения показателя;

мониторинг показателей;

сравнение контрольных и фактических показателей деятельности;

установление и отображение предупреждения по критическим событиям;

генерацию и рассылку уведомлений ответственным исполнителям, в случае выхода
показателя за пределы допустимых значений.
стр. 25 из 69
2.11.5. ТРЕБОВАНИЯ К
МУНИЦИПАЛЬНЫХ УСЛУГ»
ПОДСИСТЕМЕ
«ПОРТАЛ
ГОСУДАРСТВЕННЫХ
И
Подсистема «Портал государственных и муниципальных услуг (функций) Вологодской
области» (далее по тексту – Портал) должна соответствовать требованиям, установленным для
региональных порталов государственных услуг (функций) постановлением Правительства РФ от
15.06.2009 г. № 478, а также требованиям, установленным протоколом заседания
Правительственной комиссии по проведению административной реформы от 17.09.2009 г. № 92
(раздел XIII, пункт 2)).
Портал должен обеспечить выполнение следующих задач:

обеспечение удобства доступа и использования пользователями необходимой
информации о государственных услугах, в том числе нормативно-справочной информации на
основании документов, регламентирующих оказание государственных услуг;

обеспечение поиска услуг по типам жизненных ситуаций, уровням ОИГВ ВО и
учреждений, предоставляющих государственные и муниципальные услуги, направлениям
деятельности ОИГВ ВО и ОМС ВО, категориям получателей услуг;

адресное предоставление заявителям информации о ходе оказания государственной
услуги;

обеспечение возможности получения государственных услуг в электронной форме;

предоставление широкого набора интерактивных сервисов: возможность задать
вопрос по интересующей услуге, возможность организовать опрос, возможность размещения
дополнительных справочных материалов, возможность заявителя оценить качество
предоставленной услуги;

обеспечение возможности размещения информации об услугах федеральных органов
исполнительной власти, предоставляемой Минкомсвязью РФ в соответствии с разработанными
форматами;

другие возможности, выявленные в ходе обследования объектов автоматизации и
подготовки техно-рабочего проекта.
Дизайн Портала должен быть схожим с дизайном единого портала государственных и
муниципальных услуг, расположенного по адресу http://www.gosuslugi.ru/.
В рамках создания Портала (дополнительно к требованиям п.1.5 настоящих ТТ), должен
быть разработан функциональный модуль «Личный кабинет».
Допускается модернизация типового решения, развернутого в Вологодской области.
2.11.5.1. ТРЕБОВАНИЯ К МОДУЛЮ «ЛИЧНЫЙ КАБИНЕТ»
Модуль «Личный кабинет» предназначен для:

приема обращений заявителей на оказание государственных услуг;

адресного предоставления заявителям информации о ходе оказания государственной
услуги.
Модуль «Личный кабинет» должен обеспечивать:

просмотр всех обращений заявителя с указанием статуса и дополнительной
информации;

предоставление перечня услуг, оказание которых возможно в электронном виде;

возможность получения услуг в электронном виде.
Авторизация пользователя в личном кабинете должна быть построена с использованием
единого механизма аутентификации Федерального портала государственных услуг.
стр. 26 из 69
Модуль «Личный кабинет» должен предоставлять возможность формирования
предварительных заявок на оказание услуг. После выбора услуги заявитель должен иметь
возможность ввести следующие данные по обращению:

запрос на оказание услуги;

перечень электронных образов документов, представленных заявителем при
обращении и их атрибуты;

электронные образы дополнительных документов, представляемых заявителем;

количество экземпляров итогового документа;

примечание;

другие возможности, выявленные в ходе обследования объектов автоматизации и
подготовки техно-рабочего проекта.
Данная заявка должна направляться в подсистему обработки обращений и после проверки
операторами подсистемы обработки обращений заявителей должна быть направлена на
исполнение.
2.11.6. ТРЕБОВАНИЯ К
МУНИЦИПАЛЬНЫХ УСЛУГ»
ПОДСИСТЕМЕ
«РЕЕСТР
ГОСУДАРСТВЕННЫХ
И
Подсистема «Реестр государственных и муниципальных услуг» должна в основе своей
иметь типовое ПО, поставляемое Министерством экономического развития Российской
Федерации, версии 2.5 и выше, или другое решение, обеспечивающее аналогичные функции в
соответствии с требованиями, установленными постановлением Правительства РФ от 15 июня
2009 года № 478.
Допускается модернизация автоматизированной информационной системы «Реестр
государственных и муниципальных услуг (функций) Вологодской области», функционирующей в
Вологодской области.
2.11.7. ТРЕБОВАНИЯ К ПОДСИСТЕМЕ КОНТАКТ-ЦЕНТР
Подсистема Контакт-центр (далее по тексту - КЦ) предназначена для обработки
обращений, поступивших по телефону, электронной почте, факсу, с помощью sms-сообщения от
граждан и организаций (далее - заявителей), для обеспечения приема входящих и формирования
исходящих вызовов от абонентов телефонной сети, включая идентификацию абонентов,
регистрацию всех входящих и исходящих соединений, аудиозапись телефонных разговоров.
КЦ должен состоять из 4-х функциональных модулей:
 модуль автоматического информирования и маршрутизации вызовов;
 модуль «Рабочее место оператора»;
 модуль мониторинга и протоколирования;
 модуль База Знаний.
Модуль автоматического информирования и маршрутизации вызовов должен решать
задачи предоставления заявителям ответа на интересующий его вопрос в автоматическом режиме
и/или выбора специалиста для соединения.
Модуль «Рабочее место оператора» должен реализовать набор функциональных
возможностей, необходимых операторам КЦ (далее операторам) для обработки обращений
граждан и организаций.
Модуль мониторинга и протоколирования предназначен для учета обращений заявителей и
их предоставления в виде отчетов. Модуль предоставляет информацию как о текущем состоянии
подсистемы (количество заявителей, ожидающих ответ, количество работающих операторов, и
т.д.), так и сводные отчеты о работе подсистемы за определенный интервал времени.
Модуль База Знаний предназначен для оперативного доступа ко всей необходимой
справочной информации, касающейся предоставления государственных услуг. База Знаний
стр. 27 из 69
должна обеспечивать автоматический и автоматизированный ввод в подсистему справочных
данных, хранение справочных данных и предоставление справочных данных.
2.11.7.1. МОДУЛЬ
МАРШРУТИЗАЦИИ ВЫЗОВА
АВТОМАТИЧЕСКОГО
ИНФОРМИРОВАНИЯ
И
В модуле автоматического информирования и маршрутизации должны быть реализованы
следующие функции:
 поддержка многоуровневого голосового меню с возможностью получения абонентом
справки в автоматическом режиме, путем использования клавиатуры телефона (без
специализированных средств). Многоуровневое голосовое меню должно позволять получить
доступ к информации в соответствии с наиболее распространенными темами обращений;
 маршрутизация входящего вызова. Анализ информации, полученной по каналам связи
в процессе предварительной обработки входящего звонка и направление звонка либо на
оператора, либо на автоматическое проигрывание предварительно записанных голосовых
сообщений;
 проигрывание приветствий и музыки для заявителя, ожидающего ответа;
 организация очереди;
 удержание поступившего вызова в очереди на время принятия решения о
маршрутизации звонка, электронной почты, sms, факс и т.п. (в зависимости от загруженности и
квалификации оператора);
 поддержка приема голосовых сообщений абонентов и режима ожидания ответа
оператора.
2.11.7.2. МОДУЛЬ «РАБОЧЕЕ МЕСТО ОПЕРАТОРА»
Модуль должен обеспечивать выполнение следующих функций:
 обеспечение основных телефонных режимов:
 ответ на звонок;
 освобождение линии;
 конференция;
 переадресация вызова;
 удержание.
 обеспечение приема электронных писем, sms-сообщений, факсимильных сообщений:
 прием сообщения;
 отправка ответа.
 обеспечение учета визита;
 обеспечение взаимодействия посредством web-чата;
 регистрация заявителя. При поступлении обращения оператор должен иметь
возможность зарегистрировать заявителя, заполнив карточку, состоящую из следующих полей:
 фамилия и имя;
 наименование организации, в случае если заявитель является юридическим лицом;
 контактные телефоны (при звонке телефонный номер должен определяться и
подставляться автоматически);
 адреса электронной почты (при поступлении электронного письма, адрес
электронной почты должен определяться и подставляться автоматически).
 регистрация обращения (обращение должно быть привязано к карточке заявителя).
Должна быть реализована возможность регистрации обращения по следующим полям:
 вопрос – текст вопроса;
 комментарий – комментарий по сути вопроса;
 тема/подтема – тема, к которой относится запрос заявителя;
стр. 28 из 69
 тип обращения – вопрос (по умолчанию), жалоба, предложение, выдача документов;
 тип заявителя – физическое, юридическое лицо;
 оператор – ФИО оператора, обрабатывающего обращение (заполняется
автоматически при входе сотрудника в подсистему);
 статус запроса – открыт, отложен, в работе, передан, готов, закрыт;
 способ информирования – по телефону, по электронной почте, sms;
 ответ – ответ на вопрос заявителя.
 просмотр истории обращений. Должна обеспечиваться возможность просмотра всех
зарегистрированных в подсистеме обращений в табличном виде с возможностью сортировки и
поиска по следующим столбцам:
 статус – статус зарегистрированного в подсистеме обращения;
 дата – дата регистрации обращения в подсистеме;
 вопрос – вопрос заявителя;
 контакт – Фамилия, Имя заявителя;
 оператор – ФИО оператора, зарегистрированного обращения заявителя.
 поиск ответа в Базе Знаний. Оператор в процессе взаимодействия с заявителем и
регистрации информации об обращении должен иметь возможность обратиться к Базе Знаний для
поиска необходимой информации, воспользоваться функциональными возможностями Базы
Знаний;
 идентификация заявителя. При повторном обращении заявителя в КЦ с номера
телефона или электронного адреса уже зарегистрированного в подсистеме, оператор должен
иметь возможность просмотреть уже заполненную карточку заявителя и перечень обращений
данного заявителя.
Подсистема должна обеспечивать возможность доступа операторов КЦ к подсистеме
обработки обращений для:
 предварительного формирования обращения заявителя (заявки);
 просмотра и информирования заявителя об этапах обработки его обращения и дате
получения результатов;
 консультирования при формировании заявки в подсистеме Портал государственных
услуг.
2.11.7.3. МОДУЛЬ МОНИТОРИНГА И ПРОТОКОЛИРОВАНИЯ
Модуль мониторинга и протоколирования должен обеспечивать следующие возможности:
 мониторинг состояния КЦ (работающие операторы, их состояние, количество
обращений в очереди, количество обращений в процессе обслуживания и т.д.);
 протоколирование обращений в КЦ и отображение накопленной информации в виде
отчетов;
 запись телефонных разговоров.
2.11.7.4. МОДУЛЬ «БАЗА ЗНАНИЙ»
Модуль должен обеспечивать следующие возможности:
 хранение и полнотекстовое индексирование документов;
 ведение рубрикатора (дерева папок) документов хранящихся в Базе Знаний;
 добавление, удаление и редактирование документов, перемещение по дереву рубрик;
 прикрепление к документу базы знаний произвольного набора бинарных файлов в
произвольном формате, удаление прикрепленных файлов;
 печать документа из Базы Знаний;
 загрузка информации в Базу Знаний в автоматическом режиме посредством webсервисов;
стр. 29 из 69
 хранение истории изменения документов;
 представление информации из Базы Знаний посредством web-сервисов (в т.ч.
предоставление всей информации в подсистему «Портал государственных услуг»;
 поиск по слову или набору слов, встречающихся в тексте или заголовке документа,
подсветка найденных слов в тексте найденных документов;
 формирование уведомления сотрудника, отвечающего за ведение Базы Знаний о
необходимости внесения изменений в Базу Знаний.
2.11.7.5. ОСОБЕННОСТИ ВНЕДРЕНИЯ ПОДСИСТЕМЫ КОНТАК-ЦЕНТР
В том случае, если по итогам этапа обследования Заказчиком будет принято решение о
замене или модернизации действующего КЦ МФЦ города Вологды, то создаваемый или
модернизируемый КЦ должен удовлетворять выше перечисленным требованиям п. 2.11.7
настоящих ТТ, иначе – подсистема КЦ должна быть интегрирована с автоматизированной
системой КЦ МФЦ города Вологды.
Механизмы интеграции и взаимодействия должны быть выявлены в ходе обследования
объектов автоматизации и реализованы в рамках выполнения работ этапа I.
2.11.8. ТРЕБОВАНИЯ К ПОДСИСТЕМЕ ДИСТАНЦИОННОГО ОБУЧЕНИЯ
Подсистема дистанционного обучения (далее по тексту - ПДО) должна обеспечивать
выполнение следующих функций:

формирование учебно-методического комплекса;

формирование дополнительных информационных материалов (дополнительная
литература, комментарии преподавателей, ответы на часто задаваемые вопросы и т.п.) по
запросам обучающихся;

разработка индивидуальных программ для некоторых категорий должностных лиц
ОИГВ ВО и ОМС ВО;

корректировка материалов без реструктурирования БД.
ПДО предназначена для:

эффективного управления учебными материалами, курсами, тестами;

автоматизации процессов проверки качества знаний пользователей по работе с РКИС
ГУ-ВО;

планирования и мониторинга учебного процесса;

анализа эффективности и результативности процессов обучения.
Целью создания ПДО является автоматизация процесса электронного обучения
пользователей РКИС ГУ–ВО в соответствии с утвержденными принципами и процедурами.
В результате внедрения ПДО должны быть реализованы:

доступ к ПДО посредством веб-интерфейса, включая администрирование;

обеспечение информационной безопасности посредством настройки ролевой модели
и разграничения прав доступа;

интеграция с Active Directory.
ПДО должна обеспечивать управление обучением и учебными материалами, в части:

централизованного хранения учебных материалов в хранилище, структурированном
согласно классификатору учебных тем с разграничением прав доступа;

использования в качестве учебных материалов внешние файлы произвольных
форматов, а также тесты, сформированные в ПДО;

поддержки управления обучением с использованием курсов, соответствующих
стандартам SCORM 1.2 и SCORM 2004;
стр. 30 из 69

предоставление возможности просмотра истории изменений учебных материалов.
При просмотре истории изменений должна быть возможность:
 просмотреть список изменений документа;
 просмотреть комментарии к каждому изменению.

обеспечения совместной работы над документами, использующимися в качестве
учебных материалов. После каждого изменения документ должен проходить процедуру
утверждения;

редактирования документов MS Office (соответствующих форматов) в онлайн
режиме, с последующим сохранением документа в хранилище РКИС ГУ–ВО без обязательного
предварительного сохранения на локальных дисках компьютера пользователя;

предоставления средства для мониторинга процесса обучения;

реализации отчётов5 о прогрессе изучения учебных программ и выполнения
отдельных заданий отдельными пользователями и структурными единицами;

реализации отчёта7 о прохождении тестирований пользователями;

обеспечения встроенного каталога мультимедиа-файлов, предназначенного для
структурированного хранения мультимедийных объектов, используемых в учебном процессе;

реализации возможности поиска по учебным ресурсам;

поддержки единой политики безопасности и разграничения доступа в ИТинфраструктуре, построенной на решениях Microsoft.
Для прохождения обучения ПДО не должна требовать установки дополнительного ПО на
компьютерах сотрудников, за исключением ПО для отображения используемых типов учебных
материалов. В качестве клиентского приложения, при помощи которого осуществляется доступ в
РКИС ГУ–ВО, должен выступать web-браузер.
За счет реализации модуля управления процессом обучения ПДО должна обеспечивать:

автоматизацию процессов работы с электронными учебными пособиями (удобство
создания, хранение, версионирование, организация совместной работы над учебными
материалами);

автоматизацию основных этапов обучения с использованием электронных средств
(управление созданием и назначением электронных учебных пособий (далее по тексту - ЭУП),
контроль изучения, проверку качества знаний, сбор статистики, получение аналитических отчетов
о ходе и результатах электронного обучения).
Модуль управления процессом обучения должен обеспечивать:

автоматическое назначение курсов пользователям в зависимости от должности и
подразделения пользователя;

уведомление пользователя о необходимости прохождения нового курса;

возможность формирования программ обучения, включающих как дистанционные,
так и очные мероприятия;

для проведения тестирования обучающихся в модуле управления процессом
обучения должны быть реализованы следующие функции:
 возможность импорта тестов из текстовых файлов со специальной разметкой с
последующей генерацией SCORM-пакетов;
 сохранение детальной статистики по тестированию;
 возможность группировать вопросы теста по секциям и указывать для каждой секции
количество отображаемых вопросов;
 ограничение времени прохождения тестирования;

для контроля обучения в модуле управления процессом обучения должны быть
реализованы виды отчётов, позволяющие:
 получить сводную информацию об обучении пользователя;
Все отчёты в ПДО должны иметь возможность экспорта данных в форматы MS
Excel, MS Word, PDF
5
стр. 31 из 69
 проверить прогресс изучения электронных курсов пользователями;
 посмотреть результаты прохождения тестов пользователями;
– при просмотре каждого из вышеуказанных отчётов должна быть возможность настройки
представления информации при помощи фильтрации и сортировки по колонкам в отчётах;

должна быть возможность экспорта сформированных отчетов в приложения,
совместимые с Microsoft Office (Excel, Word) или в формат PDF;

должна существовать возможность создания комплексных программ обучения;

правила доступа к программам должны регулироваться (обязательные, доступные,
недоступные);

в качестве выполнения учебного задания должна быть возможность прикрепления к
отчету о задании произвольного файла.
ПДО должна поддерживать ролевую модель полномочий, предоставляющую как минимум
четыре базовые роли: администратора ПДО, организатора обучения, инструктора/преподавателя,
учащегося. Перечень ролей в ПДО должен иметь возможность расширения без участия
специалистов Исполнителя.
Оценка знаний и управление тестированием в ПДО должна быть реализована следующим
образом:

должны формироваться результаты прохождения тестов, должна быть доступна
возможность получения детальной информации по каждому ответу сотрудника на вопросы теста;

должна быть реализована возможность распечатки результатов тестирований
пользователя на принтер;

должна обеспечиваться поддержка различных шкал перевода баллов, набранных при
тестировании, в оценки и позволять инструкторам создавать новые шкалы и редактировать
существующие. Для любого задания должна быть возможность выбора одной из шкал оценок,
которая будет применяться для расчета оценки по этому заданию.
Модуль управления процессом обучения должен обеспечивать формирование учебнометодического комплекса (далее по тексту - УМК) по каждому изучаемому курсу (разделу).
УМК должна включать в себя различные виды электронного контента (документы в
различных форматах, электронные интерактивные учебные курсы, тесты и т.п.). Электронные
интерактивные учебные курсы должны соответствовать стандарту SCORM 20046.
Структура и упаковка создаваемого курса должна реализовываться в соответствии с
требованиями SCORM Content Aggregation Model 1.3.1. Созданный пакет контента должен
соответствовать сертификационным требованиям CP CAM 1.3.1, CP RTE 1.3.1.
Каждый курс должен представлять собой набор объектов SCO, передающих в ПДО
следующие данные:

статус прохождения объекта;

время, потраченное на изучение;

балл, набранный при выполнении итогового тестирования (при наличии).
Элементы SCO должны представлять собой запускающую страницу html и набор ресурсов,
используемых этой страницей. Коммуникации SCO с ПДО в момент воспроизведения должны
6
Sharable Content Object Reference Model (SCORM) — стандарт, разработанный для
систем дистанционного обучения. Данный стандарт содержит требования к организации
учебного материала и всей системы дистанционного обучения. SCORM позволяет
обеспечить совместимость компонентов и возможность их многократного использования:
учебный материал представлен отдельными небольшими блоками, которые могут включаться
в разные учебные курсы и использоваться системой дистанционного обучения независимо
от того, кем, где и с помощью каких средств были созданы. SCORM основан на стандарте
XML.
стр. 32 из 69
быть реализованы в соответствии с требованиями SCORM Run-Time Environment 1.3.1. SCO и
соответствовать сертификационным требованиям SCO RTE 1.3.1
Навигация внутри курса:

вход в каждый SCO доступен через меню в ПДО;

внутри каждого урока возможны как переходы между соседними слайдами, так и
переход на любой слайд;

в тестировании навигация ограничена: невозможно зайти в теоретические
материалы, невозможно вернуться назад, невозможно выйти из тестирования, не завершив его.
Каждый курс должен быть логически поделен на главы (уроки), содержащие в себе
теоретические материалы, практические задания и вопросы для самопроверки. После изучения
всех теоретических материалов пользователь должен пройти итоговое тестирование. После
прохождения тестирования пользователю должен быть доступен отчет с детализацией по
вопросам, количество набранных баллов и интегральная оценка (пройдено тестирование или нет).
УМК по каждому изучаемому курсу должен:

представлять собой логически целостный фрагмент изучаемой технологии
использования возможностей РКИС ГУ–ВО;

устанавливать точное место конкретного изучаемого компонента в общей
технологии применения РКИС ГУ–ВО;

учитывать уровень подготовки обучающихся, при этом, для оценки уровня
начальных знаний, могут использоваться претесты. После прохождения претеста пользователь
получает обратную связь по уровню начальных знаний и рекомендации по изучению курса;

базироваться на выборе наиболее рациональных методов, приемов и средств
обучения, стимулирования и контроля, обеспечение их оптимального взаимодействия;

обеспечивать оптимальный темп обучения;

рационально использовать различные средства обучения.
2.12. ТРЕБОВАНИЯ К ИНФОРМАЦИОННОМУ ОБЕСПЕЧЕНИЮ РКИС ГУ–ВО
Структура и способы организации данных РКИС ГУ–ВО должны соответствовать
следующим основным требованиям:

максимальное использование единых понятий, терминов и определений, принятых в
предметной отрасли, единых справочников, классификаторов и кодов, форматов данных,
признаков актуальности и т.п.;

использование единой или распределенной территориально БД без дублирования
информации;

использование СУБД;

обеспечение целостности данных;

наличие контроля корректности ввода и обработки данных, контроля
непротиворечивости данных, контроля целостности данных и защиты их от разрушения
вследствие некорректных действий пользователей.
Должна быть обеспечена возможность изменения структуры БД (создание новых объектов
и связей) для учета изменений в нормативно-правовой базе.
Информационная совместимость РКИС ГУ–ВО с другими автоматизированными
информационными системами должна достигаться на основе использования единых открытых
форматов и способов обмена данными, в качестве основного формата обмена данными должен
использоваться XML. В случае невозможности использования XML должен и использоваться
другой формат обмена данными, согласованный с Заказчиком и обеспечивающий совместимость
автоматизированных систем.
стр. 33 из 69
В РКИС ГУ–ВО должен быть реализован контроль корректности вводимой информации, а
также механизм проверки логической целостности информации при выполнении любой
прикладной операции.
2.13. ТРЕБОВАНИЯ К ПРОГРАММНОМУ ОБЕСПЕЧЕНИЮ СИСТЕМЫ
ПО РКИС ГУ-ВО должно состоять из общего и специального.
Общее ПО предпочтительно должно быть основано и разработано на ПО компании
Майкрософт (Microsoft Windows Server 2003-2008, Microsoft SQL Server 2008, Microsoft Dynamics
CRM v.4.0, Microsoft SharePoint Server 2010 или выше, Microsoft BizTalk Server 2009 или выше и
т.п.), а так же:

Genesys v 7.5 или выше или эквивалент;

QPR ScoreCard v.8.0 или выше или эквивалент;

Competentum ShareKnowledge или эквивалент;

ПО, необходимое для обеспечения информационной безопасности.
Специальное ПО РКИС ГУ-ВО в составе следующих подсистем:
 подсистема Контакт-центр;
 подсистема дистанционного обучения.
 подсистема обработки обращений заявителей;
 подсистема моделирования автоматизированных регламентов;
 подсистема управления автоматизированными регламентами;
 подсистема мониторинга и контроля процессов оказания государственных услуг;
 подсистема «Портал государственных и муниципальных услуг».
 подсистема «Реестр государственных и муниципальных услуг».
2.14. ТРЕБОВАНИЯ К МЕТОДИЧЕСКОМУ ОБЕСПЕЧЕНИЮ РКИС ГУ-ВО
Методическое обеспечение РКИС ГУ-ВО должно в полной мере обеспечиваться
публикацией методических материалов и проведением обучения как очного, так и заочного с
использованием функций ПДО.
2.15. ТРЕБОВАНИЯ К ТЕЛЕКОММУНИКАЦИОННОМУ ОБЕСПЕЧЕНИЮ РКИС ГУ-ВО
Основным протоколом, на базе которого строится взаимодействие внешних систем с РКИС
ГУ–ВО, должен являться HTTP. Заказчик должен обеспечить возможность взаимодействия по
вышеуказанному протоколу.
2.16. СТАДИИ, СРОКИ ВЫПОЛНЕНИЯ РАБОТ И ПРЕДЪЯВЛЯЕМЫЕ РЕЗУЛЬТАТЫ
Стадии, сроки выполнения работ и предъявляемые результаты приведены в таблице 2.
стр. 34 из 69
Таблица 2
1
2
Стадии, сроки выполнения работ и предъявляемые результаты
Срок
Содержание работ
выполнения
Предъявляемый результат
работ
Подготовительные работы:
В течение 5-7 Отчет об обследовании объекта
 Обследование
объектов недель с момента автоматизации;
Технические спецификации для
автоматизации в соответствии с п.1.4 заключения
государственного
приобретения дополнительного
настоящих ТТ.
контракта
недостающего
оборудования,
 Разработка
техно-рабочего
ПО и организации каналов
проекта.
связи;
 Развертывание
и
настройка
Техно-рабочий проект;
серверной части РКИС ГУ-ВО на
Программное
обеспечение,
аппаратных средствах Заказчика.
развернутое на технических
 Интеграция
с
Порталом
средствах Заказчика;
государственных и муниципальных
Отчет о выполненных работах;
услуг
(функций)
Вологодской
Акт-приемки выполненных
области (www.gosuslugi.gov35.ru).
работ.
 Интеграция
с
Реестром
государственных и муниципальных
услуг
(функций)
Вологодской
области.
 При
внедрении
нового
регионального
реестра
государственных услуг (функций)
его наполнение описаниями услуг
первой
очереди,
настройка
механизмов
синхронизации
со
сводным реестром.
Автоматизация
регламентов
оказания 10 государственных услуг
первой очереди до 5 этапа:
 Разработка
форм
приема
заявлений
на
государственные
услуги первой очереди на портале
государственных и муниципальных
услуг.
 Разработка форм приема и
обработки
заявлений
на
государственные
услуги
первой
очереди в подсистеме обработки
обращений.
 Разработка
интеграционных
адаптеров
для
обеспечения
информационного взаимодействия с
системами,
участвующими
в
процессах оказаний государственных
услуг первой очереди.
стр. 35 из 69
В течение 12-14
недель с момента
заключения
государственного
контракта
Административные
регламенты на каждую из 10
услуг;
Программное обеспечение,
развернутое на технических
средствах Заказчика;
Отчет о выполненных работах;
Соглашения о взаимодействии
с ведомствами, участвующими
в процессах оказаний
государственных услуг первой
очереди;
Акт-премки выполненных
работ.
Содержание работ
3
4
Подготовка к вводу в опытную
эксплуатацию:
 Подготовка проектов соглашений
и регламентов для органов власти ВО
и
территориальных
органов
федеральных
органов
власти,
участвующих в процессах оказаний
государственных
услуг
первой
очереди
 Интеграция
с
подсистемой
Контакт-центр
 Установка рабочих мест
 Разработка
курсов
дистанционного
обучения
по
процессам оказания государственных
услуг первой очереди
 Проведение обучения
Проведение
предварительных
испытаний и приемка в опытную
эксплуатацию
5
Опытная эксплуатация
6
Приемка системы в постоянную
эксплуатацию.
Срок
выполнения
работ
В течение 12-14
недель с момента
заключения
государственного
контракта
Не более 2 недель
с момента приема
Заказчиком работ
по подготовке к
вводу в опытную
эксплуатацию
В течение 14-16
недель с момента
приема системы в
опытную
эксплуатацию
Не более 2 недель
с
момента
окончания
опытной
эксплуатации
Предъявляемый результат
Программное обеспечение,
развернутое на технических
средствах Заказчика;
Отчет о выполненных работах;
Проекты
соглашений
и
регламентов, согласованные с
ОИГВ и территориальными
органами федеральных органов
власти;
Руководства пользователя и
администратора;
Описание
курсов
дистанционного обеспечения;
Акт-премки
выполненных
работ.
Методика
предварительных
испытаний;
Протокол
предварительных
испытаний;
Акт-приемки
выполненных
работ;
Акт-приемки
в
опытную
эксплуатацию.
Отчет о проведении опытной
эксплуатации;
Акт-приемки
выполненных
работ.
Методика испытаний;
Протокол испытаний;
Акт-приемки
выполненных
работ;
Акт-приемки
системы
в
постоянную эксплуатацию
3. ТРЕБОВАНИЯ К АСЭД ОИГВ
3.1. ПЛАНОВЫЕ СРОКИ НАЧАЛА И ОКОНЧАНИЯ РАБОТ
Начало работ - с момента подписания государственного контракта.
Окончание работ – в течение 34 недель с момента подписания государственного контракта.
3.2. ЦЕЛИ ВНЕДРЕНИЯ
стр. 36 из 69
Целью внедрения АСЭД ОИГВ, как составной части процесса управления в ОИГВ ВО,
является повышение качества ведения делопроизводства и взаимодействия между ОИГВ ВО,
контроль за своевременным исполнением документов, упорядочение документооборота,
совершенствование учета и поиска зарегистрированных документов, снижение трудоемкости
работ.
3.3. ЗАДАЧИ СОЗДАНИЯ АСЭД ОИГВ
АСЭД ОИГВ должна обеспечивать решение следующих задач:

организация единого информационного пространства в ОИГВ ВО, обеспечение
информационного взаимодействия между ОИГВ ВО;

автоматизация технологического процесса обработки документов, формируемых в
процессе предоставления государственных услуг в электронном виде;

автоматизация технологического процесса регистрации входящих, исходящих,
внутренних документов;

сокращение временных и трудовых затрат подготовки и согласования
организационно-распорядительных документов (далее по тесту - ОРД) (включая хранение версий
проекта) на обработку документов и работу с ними;

организация электронного архива;

организация единого электронного хранилища документов;

разграничение прав доступа пользователей к документам;

организация удаленной работы;

организация эффективного документооборота;

автоматизация технологических процессов контроля исполнения документов
(входящих, исходящих, внутренних, ОРД);

создание эффективной работы с документами, поступающими от заявителей;

автоматизация процессов отчетности по работе с документами;

обеспечение поиска документов как по атрибутам учетных форм, так и по тексту их
прикрепленных электронных образцов (полнотекстовый поиск).
3.4. ХАРАКТЕРИСТИКИ АВТОМАТИЗИРУЕМЫХ ПРОЦЕЕСОВ
Процессами автоматизации является система документооборота и делопроизводства ОИГВ
ВО.
Порядок организации документационного обеспечения управления в ОИГВ ВО
организован в соответствии с ГОСТ Р6.30-2003, инструкциями по делопроизводству ОИГВ ВО,
Регламентом работы Правительства области. В ряде ОИГВ ВО уже используются
автоматизированные системы электронного документооборота.
В документообороте и делопроизводстве ОИГВ ВО участвуют:
 Губернатор области;
 Правительство области;
 структурные подразделения Правительства области;
 ОИГВ ВО.
Для работы с документами в документообороте и делопроизводства ОИГВ ВО принимают
участие:
 руководители высшего звена Правительства области и ОИГВ ВО;
 советники, помощники руководителей Правительства области и ОИГВ ВО;
 руководители структурных подразделений ОИГВ ВО;
 управление делопроизводства и архива Правительства области;
стр. 37 из 69
 специалисты ответственные за ведение делопроизводства в структурных
подразделениях Правительства области и ОИГВ ВО;
 специалисты, ответственные за выполнение поручений и резолюций по документам.
3.5. ТРЕБОВАНИЯ К АСЭД ОИГВ
3.5.1. ТРЕБОВАНИЯ К АСЭД ОИГВ В ЦЕЛОМ
Создаваемая АСЭД ОИГВ ВО должна соответствовать требованиям ГОСТ Р6.30-2003,
инструкциям по делопроизводству ОИГВ ВО и Регламенту работы Правительства области. АСЭД
ОИГВ не предназначена для обработки информации, содержащей сведения, составляющие
государственную тайну.
Система документооборота и делопроизводства должна включать в себя:
 обработку документов, формируемых подсистемой РКИС ГУ ВО в ходе
предоставления государственных услуг в электронном виде (заявки на предоставление услуг);
 обработку входящих документов;
 обработку исходящих документов;
 обработку внутренних и организационно-распорядительных документов;
 ведение контроля исполнения документов;
 формирование документов в дела;
 обработка документов коллегиальных органов управления;
 использование документов в справочно-информационной работе.
В АСЭД ОИГВ ВО должны принимать участие:
 руководители высшего звена Правительства области и ОИГВ ВО;
 советники, помощники руководителей Правительства области и ОИГВ ВО;
 руководители структурных подразделений ОИГВ ВО;
 управление делопроизводства и архива Правительства области;
 специалисты ответственные за ведение делопроизводства в структурных
подразделениях Правительства области и ОИГВ ВО;
 специалисты, ответственные за оказание государственных услуг в электронном виде в
ОИГВ ВО;
 сотрудники ОИГВ ВО при дальнейшем развитии АСЭД ОИГВ.
3.5.1.1. ТРЕБОВАНИЯ К СТРУКТУРЕ И ФУНКЦИОНИРОВАНИЮ АСЭД ОИГВ
АСЭД ОИГВ должна автоматизировать следующие направления деятельности:
 внешний документооборот — для автоматизации делопроизводства по входящим
документам и исходящим документам;
 внутренний документооборот — для автоматизации делопроизводства по внутренним и
организационно-распорядительным документам;
 организация контроля исполнения поручений – как для внутреннего, так и для
внешнего документооборота (взаимодействие с ОИГВ ВО)
 формирование дел — ведение оперативного архива документов по хронологическому и
предметно-вопросному принципам;
 документооборот и делопроизводство коллегиальных органов управления;
 ведение тематических библиотек документов в подразделениях.
АСЭД ОИГВ должна состоять из следующих подсистем:

Управление входящими документами;

Управление обращениями граждан;
стр. 38 из 69

Управление исходящими документами;

Управление внутренними документами;

Управление организационно-распорядительными документами;

Ведение контроля исполнения документов;

Управление архивом и формирование документов в дела;

Управление совещаниями и обработка документов коллегиальных органов
управления;

Использование документов в справочно-информационной работе;

Управление нормативно-правовыми актами;

Потоковый ввод документов;

Ведение электронных реестров;

Управление договорами;

Защита информации и использование ЭЦП.
Для автоматизации документооборота и делопроизводства АСЭД ОИГВ должна
обеспечивать сервисные функции в масштабах всего Правительства области и ОИГВ ВО, такие
как:
 ознакомление с документом;
 согласование документа перед его подписанием;
 наложение резолюции с различными сроками исполнения (конечными и
периодическими);
 использование справочников организационных структур Правительства области и
ОИГВ ВО;
 уведомление о поступлении документа;
 автоматическая привязка документа при формировании исходящего документа на
входящий документ;
 обеспечение возможности передачи информации между ОИГВ ВО.
Полный перечень сервисных функций должен быть определен на стадии обследования и
формирования «Технического проекта» и зафиксирован в эксплуатационной документации на
Систему
Кроме того, АСЭД ОИГВ должна обеспечить такие внутренние сервисные функции, как:
 ведение списков рассылки;
 ведение справочника организаций;
 ведение справочника структуры организации Правительства области и ОИГВ ВО;
 подготовка и печать отчетов;
 использование сканера и системы распознавания символов для ввода содержания
документов.
Полный перечень внутренних сервисных функций должен быть определен на стадии
обследования и формирования «Технического проекта» и зафиксирован в эксплуатационной
документации на Систему
АСЭД ОИГВ должна быть масштабируемой и наращиваемой для дальнейшего расширения
функциональности системы.
3.5.1.2. ТРЕБОВАНИЯ К РАБОТЕ АСЭД ОИГВ
АСЭД ОИГВ должна обеспечивать коллективную работу пользователей в режиме
реального времени, что означает с одной стороны - возможность использования программных
модулей в любых подразделениях Правительства области и ОИГВ ВО, и с другой стороны стр. 39 из 69
возможность работы в коллективном режиме любому количеству сотрудников независимо от их
принадлежности к тому или иному подразделению Правительства области или ОИГВ ВО.
Должно быть поставлено не менее 100 конкурентных лицензий.
3.5.1.3. ПЕРЕЧЕНЬ АВТОМАТИЗИРУЕМЫХ ФУНКЦИЙ
Должны быть автоматизированы следующие основные направления:
 прием, регистрация и учет документов;
 работа с поручениями и резолюциями;
 согласование и подписание документов;
 хранение и поиск документов;
 разграничение доступа к документам;
 формирование отчетности;
 администрирование.
Полный перечень автоматизированных функций должен быть определен на стадии
обследования и формирования Техно-рабочего проекта и зафиксирован в эксплуатационной
документации на АСЭД ОИГВ.
3.5.1.4. ПЕРЕЧЕНЬ ВИДОВ ДОКУМЕНТОВ
АСЭД ОИГВ должна поддерживать, в том числе, возможность регистрации следующих
видов документов:
 Входящий документ;
 Исходящий документ;
 Внутренний документ;
 Обращение граждан;
 Договор;
 Архивный документ (далее по тексту - АРК);
 Заявка на выдачу дела;
 Заявка на выдачу документа.
Полный перечень документов должен быть определен на стадии обследования и
формирования Техно-рабочего проекта и зафиксирован в эксплуатационной документации на
АСЭД.
3.5.1.5. РОЛИ ПОЛЬЗОВАТЕЛЕЙ АСЭД ОИГВ
Перечень и краткие описания ролей персонала АСЭД ОИГВ приведены ниже по тексту.
Полный перечень требований к персоналу АСЭД ОИГВ, должен быть определен на стадии
обследования и формирования Техно-рабочего проекта и зафиксирован в эксплуатационной
документации на АСЭД ОИГВ.
Для выполнения различных действий в АСЭД ОИГВ и разграничения прав доступа к
объектам должны быть предусмотрены следующие виды ролей:
 Функциональные роли;
 Роли подразделений;
 Должностные роли;
 Персональные роли.
Функциональные роли должны обеспечить разграничение прав пользователей на
выполнение определенных действий с объектами, а также доступ к основным модулям АСЭД
стр. 40 из 69
ОИГВ. Состав функциональных ролей определен на этапе разработки АСЭД ОИГВ и должен
иметь возможность пополняться на этапе внедрения.
Роли подразделений, должностные роли и персональные роли должны обеспечивать
разграничение прав доступа пользователей к объектам АСЭД ОИГВ: регистрационным карточкам
документов, поручений и резолюций. Эти роли должны создаваться как вручную, так и
автоматически при создании соответственно подразделения, должности или пользователя в
определенных для этого справочниках.
АСЭД ОИГВ должна поддерживать работу с ролями, перечень и описание которых
приведено в таблице 3.
Таблица 3
Перечень и описание ролей АСЭД ОИГВ
№
Роль
Описание
п/п
Администратор
Пользователь, ответственный за установку и сопровождение
сервера БД и АСЭД ОИГВ, включая ответственность за
выполнение регламентных процедур (например, резервное
копирование, восстановление данных).
Системный технолог
Пользователь, ответственный за ведение справочной
информации в АСЭД ОИГВ и поддержание ее в актуальном
состоянии, а также ответственный за ведение информации о
пользователях и ролях в АСЭД ОИГВ.
3
Регистратор входящих
документов
Пользователь, выполняющий регистрацию входящих
документов.
4
Регистратор исходящих
документов
Пользователь, выполняющий регистрацию исходящих
документов.
5
Регистратор внутренних
документов
Пользователь, выполняющий регистрацию внутренних
документов.
6
Регистратор обращений
граждан
Пользователь, выполняющий регистрацию поступивших
обращений граждан.
7
Регистратор проектов
документов
Пользователь, выполняющий регистрацию на основании
подписанных проектов исходящих или внутренних
документов, финансово-хозяйственных документов.
Исполнитель проектов
Пользователь, являющий создателем проекта документа.
Согласующий
Пользователь, выполняющий действия по согласованию
проектов документов.
Подписывающий
Пользователь, выполняющий действия по подписанию
проектов документов.
Экспедитор
Пользователь, ответственный за централизованный прием и
отправку документов, но не выполняющий регистрацию
документов.
1
2
8
9
10
11
Пользователь, ответственный за работу с архивом
организации.
Полный перечень ролей должен быть определен на стадии обследования и формирования
Техно-рабочего проекта и зафиксирован в эксплуатационной документации на АСЭД ОИГВ.
12
Архивариус
3.5.1.6. СОСТАВ ФУНКЦИОНАЛЬНЫХ РАБОЧИХ МЕСТ
стр. 41 из 69
АСЭД ОИГВ должна поддерживать, в том числе, нижеследующий набор функциональных
рабочих мест, создаваемых при первоначальной настройке АСЭД ОИГВ в рамках проекта. В
дальнейшем администратор должен иметь возможность создать в АСЭД ОИГВ другие роли и
назначить каждой из них свой собственный набор функций.
 Регистратор входящих документов и договоров:
 создание и регистрация входящих документов;
 отправка на рассмотрение входящих документов;
 наложение и исполнение поручений и резолюций.
 Регистратор внутренних документов:
 создание и регистрация внутренних документов;
 отправка на рассмотрение внутренних документов;
 наложение и исполнение поручений и резолюций.
 Регистратор исходящих документов:
 создание и регистрация исходящих документов;
 отправка на рассмотрение исходящих документов.
 Регистратор писем граждан:
 создание и регистрация писем граждан;
 отправка на рассмотрение писем граждан;
 наложение и исполнение поручений и резолюций.
 Регистратор проектов документов
 регистрация проектов документов;
 наложение и исполнение поручений и резолюций.
 Исполнитель проектов:
 создание проектов документов (исходящих, внутренних);
 отправка на согласование проектов документов;
 доработка проектов документов на этапе согласования;
 отправка на подписание проектов документов;
 доработка проектов документов на этапе подписания;
 отправка на регистрацию проектов документов.
 Согласующий:
 согласование проектов документов.
 Подписывающий:
 подписание проектов документов.
 Архивариус:
 принятие дела в архив;
 возврат дела на доработку;
 выдача дела;
 отказ о выдаче дела;
 возврат дела в архив
 уничтожение дел.
Полный перечень функционала ролей должен быть определен на стадии обследования и
формирования Техно-рабочего проекта и зафиксирован в эксплуатационной документации на
АСЭД.
3.5.2. ТРЕБОВАНИЯ К ПРОЦЕССАМ ОБРАБОТКИ ДОКУМЕНТОВ В АСЭД ОИГВ
3.5.2.1. ПЕРЕЧЕНЬ АВТОМАТИЗИРУЕМЫХ ПРОЦЕССОВ
В АСЭД ОИГВ должны быть, в том числе реализованы следующие процессы:
 «Входящие документы»;
 «Исходящие документы»;
 «Внутренние документы»;
стр. 42 из 69
 «Обращения граждан»;
 «Списание в архив»;
 «Выдача дел из архива».
Процесс «Входящие документы»
Цель – обработка входящей корреспонденции.
Участники процесса:
Регистратор входящих документов – создает регистрационную карточку (далее по тексту РК) документа, привязывает электронный образ документа к РК, вносит основную информацию о
документе в РК, пересылает РК пользователям для дальнейшего ознакомления, передачи на
рассмотрение и вынесения решения;
Пользователь – знакомится с документом и осуществляет работы по документу.
Руководитель – знакомится с документом, выдает поручения по документу, в случае
необходимости осуществляет продление сроков исполнения поручений, снимает документ с
контроля или возвращает на доработку;
Контролер – получает документ от руководителя для дальнейшего контроля за
исполнением поручений по документу, в случае необходимости осуществляет продление сроков
исполнения поручений, снимает документ с контроля или возвращает его на доработку;
Исполнитель – осуществляет исполнение поручения, отчитывается об исполнении
поручения, при необходимости запрашивает продление срока поручения;
Выполнение процесса включает в себя следующую последовательность действий:
Регистратор входящих документов создает РК входящего документа, прикрепляет файл с
входящим документом.
Документу присваивается регистрационный номер. Формирование регистрационного
номера осуществляется по заданному шаблону автоматически при создании.
Регистратор входящих документов пересылает РК, указав в регистрационной карточке
входящего документа перечень исполнителей.
Пользователь, которому адресован документ, получает его в личном рабочем пространстве,
и при необходимости выдает поручение или резолюцию по документу. Для исполнения
поручения или резолюции назначаются один или несколько исполнителей. Поручение всегда
имеет статус «контрольное» со сроком исполнения. Резолюция бывает:
 контрольной (со сроком исполнения);
 неконтрольной (без сроков исполнения).
Исполнители, получив документ к исполнению, отчитываются о выполнении поручения
или резолюции по документу в виде отчета об исполнении, введя текст отчета, а также имеют
возможность прикрепить к отчету об исполнении файл.
При необходимости исполнитель может запросить у автора поручения продление срока
исполнения.
Должна быть обеспечена иерархия поручения или резолюции. Подчиненные поручения
или резолюции также могут быть контрольными и неконтрольными. Авторами подчиненных
поручений или резолюций по умолчанию назначаются исполнители поручений или резолюций
верхнего уровня.
Контролер (в случае его отсутствия - автор резолюции) снимает документ с контроля, если
поручение или резолюция исполнены. При снятии с контроля имеет возможность внести
информацию о дате снятия с контроля и указать основание для снятия в соответствующих полях
карточки документа, а также присоединить к карточке документа документ, на основании
которого снимается поручение или резолюция с контроля.
стр. 43 из 69
Процесс «Исходящие документы»
Цель - регистрация и отправка адресату исходящей корреспонденции.
Участники процесса:
Регистратор исходящих документов – создает РК документа, вносит основную
информацию о документе в РК, пересылает документ на ознакомление, в случае ответа на
входящий документ создает РК исходящего документа с автоматической привязкой к входящему
документу и переносом необходимой информации из входящего документа (ответ на номер
входящего документа, адресат и т.п.);
Регистратор проектов документов – получает карточку проекта документа для
последующего создания на ее основе РК документа;
Сотрудник ОИГВ ВО – получает документ на ознакомление, выполняет работы по
документу.
Сотрудник, отправляющий документ внешним адресатам – получает документ, готовит его
к отправке, непосредственно отправляет документ, заносит в карточку документа информацию об
отправке.
Выполнение Процесса включает в себя следующую последовательность действий:
Регистратор исходящих документов – создает РК документа, вносит основную
информацию о документе в РК, пересылает РК пользователям для дальнейшего ознакомления.
Регистратор проектов документов создает исходящий документ на основе проекта
документа. РК исходящего документа создается автоматически на основании РК проекта
документа. В РК исходящего документа автоматически переносятся значения в том числе
следующих полей:
 Исполнитель;
 Доступ;
 Содержание;
 Файлы.
Документу присваивается регистрационный номер. Формирование регистрационного
номера осуществляется по заданному шаблону автоматически при создании.
Регистратор исходящих документов пересылает РК указанному в одном из полей перечню
пользователей.
Пользователь, которому адресован документ, получает его в личном рабочем пространстве.
В случае необходимости пользователь может удалить поступивший документ из личного
рабочего пространства.
Пользователь, отвечающий за отправку документа в сторонние организации, получает
документ в его рабочем пространстве. Непосредственно отправляет оригинал документа внешним
адресатам. В РК документа проставляет информацию об отправке: организация или гражданин
адресат, дата отправки и вид отправки. В случае, если адресат указан заранее, то пользовательотправитель может воспользоваться отдельным рабочим пространством, предназначенным для
учета документов, приготовленных к отправке и отправленных.
Для удобства учета карточек документов должны быть созданы папки, например,
«Подготовлено к отправке» и «Отправлены адресатам», используя которые пользователь будет
иметь возможность переложить документы из папки в папку в зависимости от их состояния.
Процесс «Внутренние документы»
Цель - регистрация и отправка адресату внутренней корреспонденции.
Участники процесса:
Регистратор внутренних документов – создает РК документа, вносит основную
информацию о документе в РК, пересылает документ на ознакомление или на исполнение;
стр. 44 из 69
Регистратор проектов документов – получает карточку проекта документа для
последующего создания на ее основе РК документа;
Сотрудник организации – получает документ на ознакомление или исполнение, выполняет
работы по документу.
Выполнение Процесса включает в себя следующую последовательность действий:
Регистратор внутренних документов – создает РК документа, вносит основную
информацию о документе в РК, пересылает РК пользователям для дальнейшего ознакомления.
Регистратор проектов документов создает внутренний документ на основе проекта
документа. Для выполнения данной задачи должны быть реализованы соответствующие
интерфейсы и функции, при помощи которых будет обеспечено автоматическое создание РК
внутренних документов, в которые будет перенесена в автоматическом режиме основная
информация из карточки проекта:
 Исполнитель;
 Доступ;
 Содержание;
 Файлы.
Документу присваивается регистрационный номер. Формирование регистрационного
номера осуществляется по заданному шаблону автоматически при создании.
В случае необходимости детализировать информацию о документе, регистратор
внутренних документов вводит информацию о разделах документа в РК.
Регистратор внутренних документов пересылает РК для ознакомления или исполнения,
указав список пользователей в регистрационной карточке внутреннего документа.
Пользователь, которому адресован документ, получает его в персональном рабочем
пространстве и при необходимости выдает поручение или резолюцию по документу. Поручение
или резолюция могут быть выданы как относительно всего документа, так и отдельно по каждому
разделу документа. Для исполнения поручения ил резолюции назначаются один или несколько
исполнителей. Поручение всегда имеет статус «контрольное» со сроком исполнения. Резолюция
бывает:
 контрольная (со сроком исполнения);
 неконтрольная (без сроков исполнения).
Исполнители, получив документ к исполнению, отчитываются о выполнении поручения по
документу в виде отчета об исполнении, введя текст отчета, а также имеют возможность
прикрепить к отчету файл.
При необходимости исполнитель может запросить у автора поручения или резолюции
продление срока исполнения.
Существует иерархия поручений или резолюций. Подчиненные поручения или резолюции
также могут быть контрольными и неконтрольными. Авторами подчиненных поручений или
резолюций по умолчанию назначаются исполнители поручений или резолюций верхнего уровня.
Контролер (в случае его отсутствия - автор поручения или резолюции) снимает документ с
контроля, если поручение или резолюция исполнены. При снятии с контроля имеет возможность
внести информацию о дате снятия с контроля и указать основание для снятия в соответствующих
полях карточки документа.
Процесс «Проект документа»
Цель - согласование и подписание проекта документа.
Участники процесса:
Исполнитель проектов – создает РК проекта, отправляет проект на согласование и
подписание, дорабатывает проект, отправляет согласованный проект на регистрацию;
стр. 45 из 69
Согласующий – осуществляет согласование документа, формирует замечания к документу,
требующие доработки;
Подписывающий – осуществляет подписание документа.
Выполнение процесса включает в себя следующую последовательность действий:
Исполнитель проекта создает РК проекта, предварительно определив, проект какого
документа он готовит: исходящего или внутреннего. Прикрепляет файл с текстом проекта
документа, подписывает прикрепленный файл ЭЦП7.
Для обеспечения работы в данном процессе в АСЭД ОИГВ должны быть созданы папки
«На согласовании», «Не согласовано» (или аналогичные).
Исполнитель проекта направляет документ на согласование. В РК сохраняется дата и
время отправки на согласование. Список согласующих лиц определяется:
 непосредственно перед отправкой с указанием даты, до которой должно быть
произведено согласование. Согласование в данном случае может осуществляться
параллельно или последовательно всеми указанными сотрудниками. РК проекта документа
поступает в папку «На согласовании» рабочего пространства согласующих лиц.
 выбирается с помощью листа согласования. Лист согласования создается заранее и
содержит перечень сотрудников для каждого этапа последовательного согласования и
сроки согласования, указанные в днях. Согласование может быть как параллельным, так и
последовательным. РК проекта документа поступает в папку «На согласовании» рабочего
пространства согласующих лиц.
В случае отсутствия необходимости в согласовании документа исполнитель проекта имеет
возможность отправить проект на подписание.
Каждый согласующий может согласовать документ, отказать или согласовать с
замечаниями. В случае отказа согласующего процесс согласования прекращается. Замечания
согласующих, дата и время согласования сохраняются в РК.
В случае отказа от согласования исполнитель получает проект на доработку в папке «Не
согласовано»
рабочего пространства. Исполнитель имеет возможность изменить проект
документа и внести исправления согласно замечаниям согласующих лиц. Прикрепляет новую
версию файла и подписывает его ЭЦП. После этого определяет перечень согласующих лиц для
повторного согласования и отправляет и направляет им РК проекта документа.
В случае успешного согласования исполнитель отправляет документ на подписание.
Подписывающий (или подписывающие) определяется исполнителем при создании РК проекта
или после окончательного согласования.
Каждый подписывающий может подписать проект документа или отказать в подписании.
В обоих случаях подписывающие лица имеет возможность указать свои комментарии, которые
сохранятся в РК проекта документа.
В случае если проект документа не подписан, исполнитель получает проект на доработку
или исправление. После доработки исполнитель определяет необходимость повторного
согласования и подписания. В зависимости от данного решения – РК проекта документа
отправляется исполнителем на согласование или подписание.
После окончательного подписания документа проект документа отправляется на
регистрацию.
Регистратор проектов документов регистрирует документ в Журнале исходящих или
Журнале внутренних документов в зависимости от типа проекта документа: внутренний или
исходящий.
В системе создается РК документа соответствующего типа. Документу
присваивается регистрационный номер, сформированный по правилам для номеров
соответствующего типа.
Здесь и далее предполагается, что типовое решение АСЭД ОИГВ готово к использованию ЭЦП. Если Заказчик не
использует ЭЦП, данная операция не выполняется
7
стр. 46 из 69
Регистратор проектов сканирует подписанный документ и прикрепляет файл с документом
к РК проекта. Накладывает на файл ЭЦП.
Требования к листу согласования:
Для удобства отправки проекта на согласования в Системе должна быть возможность
создания листов согласования. Количество листов согласования – не ограничено.
Листы согласования должны быть созданы до создания проекта документа
администратором, системным технологом или исполнителем проекта.
В карточке проекта документа должен быть доступен только тот лист согласования,
который удовлетворяет следующим условиям:
 Тип проекта должен совпадать с указанным в листе согласования;
 Вид документа должен совпадать с указанным в листе согласования;
Пользователь должен принадлежать подразделению, указанному в листе согласования.
Лист согласования должен быть доступен для выбора в случае, если одно из указанных
полей пусто.
В листе согласования должна быть возможность задать согласующих лиц из справочника, а
также сроки согласования по каждому этапу. Срок согласования должен быть определен как
числовая величина, которая будет определять, на какой срок согласующим будет передан проект
на согласование. После окончания срока проект не отзывается от согласования. Сроки
согласования должны задаваться автоматически в соответствии с Регламентом Правительства
области.
Процесс «Проекты исходящих договоров»
Цель – согласование исходящего договора с контрагентом.
Участники процесса:
Исполнитель проектов – создает и дорабатывает проект договора, оправляет документ на
согласование, отправляет документ на подпись, отправляет документ контрагенту.
Согласующий - осуществляет согласование документа, формирует замечания к документу,
требующие доработки.
Подписывающий – подписывает документ.
Регистратор проектов документов – регистрирует исходящий договор.
Выполнение процесса включает в себя следующую последовательность действий:
Исполнитель проектов создает РК договора, прикрепляет к ней файл с проектом договора,
накладывает на файл ЭЦП.
Исполнитель указывает в РК с помощью листа согласования список лиц, согласующих
документ. Согласование может быть как последовательное, так и параллельное. Исполнитель
проектов отправляет документ на согласование.
Каждый согласующий может согласовать документ, отказать или согласовать с
замечаниями. В случае отказа согласующего процесс согласования продолжается. Любое
действие согласующего лица подписывается ЭЦП (подписываются прикрепленные к РК файлы).
Замечания согласующих лиц, дата и время согласования сохраняются в РК.
После согласования
документ возвращается исполнителю проекта. Сотрудник
анализирует полученные от согласующих лиц замечания. Если замечания
критичны –
редактирует файл проекта, определяет повторный список согласующих лиц и отправляет на
повторное согласование. Отредактированный файл подгружается в РК в качестве новой версии
файла. Предыдущая версия становится недоступной для редактирования, ЭЦП на ней
сохраняется. Исполнитель проектов накладывает ЭЦП на новую версию файла.
Если замечания не критичны – проект отправляется на подпись.
Подписывающий подписывает документ. Документ возвращается исполнителю проекта.
стр. 47 из 69
Исполнитель проекта отправляет документ на регистрацию
Регистратор проектов документов регистрирует документ в Журнале проектов документов.
Документу присваивается документу регистрационный номер, сканирует и прикрепляет к РК
подписанный бумажный документ. На файл накладывается ЭЦП.
Исполнитель отправляет документ контрагенту.
Исполнитель получает ответный документ от контрагента. Если документ согласован
контрагентом, то документ регистрируется как Договор. Если не согласован – процесс
запускается сначала.
Процесс «Проекты входящих договоров»
Общее описание
Цель – согласование входящего договора с контрагентом.
Участники процесса:
Исполнитель проектов – создает проект договора на основе полученного договора,
отправляет на регистрацию, оправляет документ на согласование, отправляет документ на
подпись;
Согласующий - осуществляет согласование документа, формирует замечания к документу,
требующие доработки;
Подписывающий – подписывает документ;
Регистратор проектов документов – регистрирует проект входящего договора.
Выполнение Процесса включает в себя следующую последовательность действий:
Исполнитель проекта создает РК договора, прикрепляет к ней файл с проектом договора,
накладывает на файл ЭЦП. Исполнитель указывает в РК список согласующих документ
(указывает ФИО руководителя подразделения).
Исполнитель указывает в РК с помощью листа согласования список лиц, согласующих
документ. Согласование может быть как последовательное, так и параллельное. Исполнитель
проектов отправляет документ на согласование.
Каждый согласующий может согласовать документ, отказать или согласовать с
замечаниями. В случае отказа согласующего процесс согласования продолжается. Любое
действие согласующего лица подписывается ЭЦП (подписываются прикрепленные к РК файлы).
Замечания согласующих лиц, дата и время согласования сохраняются в РК.
После согласования в правовой (юридической) службе (отделе, управлении) документ
возвращается инициатору. Сотрудник анализирует полученные от согласующих лиц замечания.
Если замечания
критичны – редактирует файл проекта, определяет повторный список
согласующих лиц и передает документ для отправки на повторное согласование в структурное
подразделение ОИГВ ВО, отвечающее за ведение договоров для отправки на повторное
согласование. Отредактированный файл подгружается в РК в качестве новой версии файла.
Предыдущая версия становится недоступной для редактирования, ЭЦП на ней сохраняется.
Сотрудник накладывает ЭЦП на новую версию файла.
Сотрудник структурного подразделения ОИГВ ВО, отвечающего за ведение договоров,
отправляет файл на повторное согласование.
Если замечания не критичны – документ передается на подпись подписывающему лицу.
Подписывающий подписывает договор.
Исполнитель сканирует и прикрепляет к РК подписанный бумажный документ. На файл
накладывается ЭЦП.
Исполнитель отправляет документ контрагенту.
После получения документа от контрагента отправляет документ на регистрацию.
стр. 48 из 69
Регистратор проектов документов регистрирует документ в Журнале проектов документов.
Документу присваивается документу регистрационный номер.
Процесс «Обращения граждан»
Цель – регистрация и обработка обращений граждан.
Участники процесса:
Регистратор обращений граждан – создает документ, регистрирует документ, передает на
рассмотрение;
Пользователь – знакомится с документом, при необходимости накладывает резолюцию
Выполнение процесса включает в себя следующую последовательность действий:
Регистратор обращений граждан создает РК обращения граждан, прикрепляет к ней файл с
обращением. Накладывает на файл ЭЦП. Сотрудник проводит проверку на наличие предыдущих
обращений по данной теме. Делает связку с предыдущими обращениями.
В случае, если данный документ передан в Канцелярию ошибочно и требуется пересылка
обращения в ответственные за данный вопрос инстанции, должна быть предусмотрена
возможность создания исходящих документов, а также формирования и печати на бланке
стандартных бумажных документов-сопроводительных писем.
Регистратор обращений граждан регистрирует документ в журнале обращений граждан.
Документу присваивается регистрационный номер.
Регистратор обращений граждан пересылает документ адресату .
Лицо, которому передан на рассмотрение документ, может выдать поручение или
резолюция по обращению (провести поверку, сформировать ответ и т.п.). Для поручения или
резолюции назначаются один или несколько исполнителей. Исполнитель, указанный первым,
считается ответственным. Поручение всегда носит статус «контрольное» со сроком исполнения.
Резолюция бывает:
 контрольная (со сроком исполнения);
 неконтрольная (без сроков исполнения).
Исполнители, получая сообщение к исполнению, отчитываются в виде текста отчета об
исполнении (с возможностью прикрепить файл). Автора резолюции – пишут в текст сообщения.
Контролера назначают при создании поручения или резолюции.
При необходимости исполнитель может запросить у автора поручения или резолюции
продление срока исполнения.
Существует иерархия поручений или резолюций. Подчиненные поручения или резолюции
также могут быть контрольными и неконтрольными.
Контролер (автор поручения или резолюции) снимает документ контроля в случае, если
поручение или резолюция исполнены.
Процесс «Списание в дело»
Цель – списание документа в дело и принятие в архив.
Участники процесса:
Пользователь, обладающий правом списать в дело – списывает документ в дело,
формирует АРК дела, дорабатывает АРК дела; списание документа должно проводиться как по
отдельно выбранному документу, так и за определенный временной интервал и по видам
документов;
Архивариус – осуществляет проверку АРК дела, принимает дело в архив;
Выполнение процесса включает в себя следующую последовательность действий:
стр. 49 из 69
Пользователь, обладающий правом списать в дело, находит документ, требующий
списания в дело. Делает в документе запись о списании в дело. Документ автоматически
классифицируется номенклатурным заголовком.
Автоматически в АСЭД ОИГВ создается архивная регистрационная карточка дела.
Архивариус проверяет АРК дела. Если АРК заполнена неверно, Архивариус может вернуть
дело на доработку сотруднику, формировавшему его с указанием комментариев.
Если АРК заполнена верно, то Архивариус принимает дело в архив.
Процесс «Выдача дел из архива»
Цель – списание документа в дело и принятие в архив.
Участники процесса:
Читатель – создает заявку на выдачу дела, редактирует ее, возвращает дело;
Архивариус – осуществляет проверку заявки на выдачу дела, выдает дело, принудительно
возвращает дело в архив при необходимости;
Выполнение Процесса включает в себя следующую последовательность действий:
Пользователь оформляет заявку на выдачу дела. При этом происходит автоматическая
регистрация заявки (присвоение регистрационного номера).
Пользователь отправляет заявку Архивариусу. Архивариус проверяет правильность
оформления заявки. Если заявка оформлена неверно, Архивариус возвращает заявку
пользователю на доработку с указанием причины.
Если заявка оформлена верно, то Архивариус принимает заявку в работу.
Архивариус производит выдачу дела. В деле делается запись о выдаче дела с указанием
срока.
Архивариус может принудительно забрать дело у пользователя (например, по истечению
срока выдачи дела). При этом автоматически в деле фиксируется дата возврата дела.
Пользователь самостоятельно возвращает дело в архив. При этом автоматически в деле
фиксируется дата возврата дела.
В ходе обследования и формирования Техно-рабочего проекта должны быть уточнены
автоматизируемые процессы, их функциональность и особенности.
3.5.3. ТРЕБОВАНИЯ К ФУНКЦИЯМ, ВЫПОЛНЯЕМЫМ АСЭД ОИГВ
3.5.3.1. ТРЕБОВАНИЯ К ПОИСКУ ДОКУМЕНТОВ В АСЭД ОИГВ
АСЭД ОИГВ должна поддерживать как контекстный поиск по тексту документа и
электронному образу документа, так и поиск по реквизитам карточек с осуществлением контроля
разграничения прав доступа. Процесс поиска документов должен выполняться по следующим
правилам:
 Пользователь заполняет форму задания критериев поиска по формуляру или тексту
документов;
 АСЭД ОИГВ осуществляет поиск документов и отображает список удовлетворяющих
заданным критериям РК;
 Пользователь просматривает документы в зависимости от его прав доступа к
документам.
Поиск должен осуществляться по всем реквизитам документов, хранимых в БД.
3.5.3.2. ТРЕБОВАНИЯ К ОТЧЕТАМ В АСЭД ОИГВ
стр. 50 из 69
В АСЭД ОИГВ должна быть обеспечена возможность получения, в том числе следующих
групп отчетов:
 Отчеты по регистрации:
 Отчеты по регистрации входящих документов;
 Количество входящих документов;
 Отчеты по регистрации исходящих документов;
 Отчеты по регистрации внутренних документов;
 Отчеты по регистрации обращений граждан;
 Отчеты по исполнению:
 Отчеты по исполнению входящих документов;
 Отчеты по исполнению исходящих документов;
 Отчеты по исполнению внутренних документов;
 Отчеты по исполнению обращений граждан;
 Отчеты по исполнителям задач;
 Отчеты по авторам резолюций
 Справки-напоминания об исполнении документов:
 Справки-напоминания об исполнении входящих документов;
 Справки-напоминания об исполнении исходящих документов;
 Справки-напоминания об исполнении внутренних документов;
 Справки-напоминания об исполнении обращений граждан;
 Отчеты по проектам документов:
 Отчеты по проектам исходящих документов;
 Отчеты по проектам внутренних документов;
 Отчеты по проектам договоров;
 Журнал пересылки;
 Журнал передачи документов;
 Отчет по отправленным исходящим документам.
Группы и формы отчетов должны быть уточнены в ходе обследования, формирования
техно-рабочего проекта и доработаны в процессе внедрения АСЭД ОИГВ.
Одновременно должна быть обеспечена возможность построения нерегламентированной
отчетности в соответствии с потребностями пользователей АСЭД ОИГВ в процессе эксплуатации
системы.
3.5.3.3. ПРАВИЛА НУМЕРАЦИИ ДОКУМЕНТОВ В АСЭД ОИГВ
В АСЭД ОИГВ должна быть обеспечена сквозная нумерация по видам документов в
пределах календарного года.
При наступлении нового года нумераторы должны обновляться автоматически, номера не
списанных в архив документов не должны влиять на очередность нумератора новых документов,
выдача номеров производится с номера 1.
В АСЭД ОИГВ должна быть предусмотрена возможность создать нумератор для каждого
вида по определенным правилам.
3.5.4. ТРЕБОВАНИЯ К ФУНКЦИЯМ И ЗАДАЧАМ АСЭД ОИГВ
АСЭД ОИГВ должна состоять из следующих подсистем:
 Управление входящими документами;
 Управление обращениями граждан;
 Управление исходящими документами;
стр. 51 из 69
 Управление внутренними документами;
 Управление организационно-распорядительными документами;
 Ведение контроля исполнения документов;
 Управление архивом и формирование документов в дела;
 Управление совещаниями и обработка документов коллегиальных органов управления;
 Использование документов в справочно-информационной работе;
 Управление нормативно-правовыми актами;
 Потоковый ввод документов;
 Ведение электронных реестров;
 Управление договорами;
 Защита информации и использование ЭЦП.
Требования как к перечню подсистем АСЭД ОИГВ ВО, так и к их функциям и задачам
должны быть уточнены в ходе обследования и формирования Техно-рабочего проекта.
3.5.4.1. УПРАВЛЕНИЕ ВХОДЯЩИМИ ДОКУМЕНТАМИ
Подсистема входящих документов должна обеспечивать полный цикл работы с входящими
документами от момента получения документа до его уничтожения или передачи на архивное
хранение.
Должна быть обеспечена возможность выполнения следующих функций:
 регистрация документа — создание РК документа;
 постановка документа на контроль;
 модификация существующей РК (внесение изменений);
 перенаправление РК другим сотрудникам организации;
 фиксирование связи регистрируемого входящего документа с некоторым (некоторыми)
исходящим документом этой же организации;
 ознакомление с документом сотрудников организации и сотрудников из других
организаций (где установлена АСЭД ОИГВ);
 фиксация наложенного поручения или резолюции, в том числе не требующей
исполнения;
 снятие документа с контроля исполнителя поручения или резолюции;
 сдача документа на хранение в дело;
 просмотр хода исполнения документа (текстов поручений или резолюций и отчетов об
исполнении);
 возможность проверить наличие аналогичного документа (ранее зарегистрированного
документа с совпадающими реквизитами: наименование организации, исходящий номер и дата);
 печать РК на бланке.
3.5.4.2. УПРАВЛЕНИЕ ОБРАЩЕНИЯМИ ГРАЖДАН
Подсистема управления обращениями граждан должна обеспечивать полный цикл работы
с документами от момента получения документа до его уничтожения или передачи на архивное
хранение. Должна быть обеспечена возможность выполнения следующих функций:
 регистрация документа — создание РК;
 ведение реестра граждан, возможность связать поступивший документ с раннее
полученными документами;
 постановка документа на контроль;
 модификация существующей РК (внесение изменений);
 перенаправление РК другим сотрудникам организации;
стр. 52 из 69
 фиксирование связи регистрируемого входящего документа с некоторым (некоторыми)
исходящим документом этой же организации;
 ознакомление с документом сотрудников организации и сотрудников из других
организаций (где установлена АСЭД ОИГВ);
 фиксация наложенного поручения или резолюции, в том числе не требующей
исполнения;
 снятие документа с контроля исполнителя поручения или резолюции;
 сдача документа на хранение в дело;
 просмотр хода исполнения документа (текстов поручений или резолюций и отчетов об
исполнении);
 печать РК на бланке.
3.5.4.3. УПРАВЛЕНИЕ ИСХОДЯЩИМИ ДОКУМЕНТАМИ
Подсистема исходящих документов должна обеспечивать полный цикл работы с
исходящими документами от момента подготовки проекта документа до фиксации момента
отправки и факта получения
Подсистема исходящих документов должна обеспечивать выполнение следующих
функции:
 создание проекта исходящего документа с заполнением реквизитов в РК;
 согласование документа как с использованием листа согласования так и без него;
 отправка документа на подпись;
 регистрация документа — присвоение номера документу с фиксацией этой
информации в РК;
 автоматическое фиксирование связи исходящего документа с некоторым (некоторыми)
входящим, внутренним или организационно-распорядительным документом («в ответ на…»);
 сдача документа (его копии) на хранение в дело.
3.5.4.4. УПРАВЛЕНИЕ ВНУТРЕННИМИ ДОКУМЕНТАМИ
Подсистема внутренних документов должна обеспечивать полный цикл работы с
внутренними документами от момента подготовки документа, его регистрации, получения до его
уничтожения или передачи на архивное хранение.
Подсистема внутренних документов должна обеспечивать выполнение следующих
функции:
 создание проекта документа с заполнением полей РК;
 согласование проекта документа;
 отправка проекта документа на подпись;
 регистрация документа — присвоение номера с фиксацией информации в РК;
 ознакомление с документом;
 фиксирование связи внутреннего документа с некоторым (некоторыми) входящим,
внутренним, исходящим, организационно-распорядительным документом («в ответ на…»);
 фиксация наложенного поручения или резолюции, в том числе не требующей
исполнения;
 постановка документа на контроль;
 создание отчета об исполнении поручений или резолюций;
 снятие документа с контроля;
 сдача документа (его копии) на хранение в дело.
стр. 53 из 69
3.5.4.5. УПРАВЛЕНИЕ ОРД
Подсистема ОРД должна обеспечивать полный цикл работы с ОРД от момента подготовки
документа, его регистрации, получения до его уничтожения или передачи на архивное хранение.
Подсистема ОРД должна обеспечивать выполнение следующих функции:
 создание проекта документа с заполнением полей РК;
 согласование проекта документа;
 отправка проекта документа на подпись;
 регистрация документа — присвоение номера документу с фиксацией этой
информации в РК;
 постановка документа на контроль;
 рассылка документа;
 фиксация отдельных поручений или резолюций по ОРД, в том числе не требующих
исполнения;
 создание отчета об исполнении поручения или резолюции;
 снятие документа с контроля;
 отметка о полном исполнении поручения или резолюции;
 просмотр истории исполнения документа;
 сдача документа на хранение в дело;
 печать документа на бланке.
3.5.4.6. ВЕДЕНИЕ КОНТРОЛЯ ИСПОЛНЕНИЯ ДОКУМЕНТОВ
Подсистема должна обеспечивать выполнение следующих функций:
 создание карточки поручения или резолюции при постановке на контроль поручения
или резолюции соответственно;
 отображение в карточке поручения или резолюции информации о снятии с контроля,
исполнении задания;
 уведомление при приближении срока исполнения;
 получение перечня заданий по исполнителям, авторам поручений или резолюций, по
срокам исполнения, по номеру документа.
3.5.4.7. УПРАВЛЕНИЕ АРХИВОМ И ФОРМИРОВАНИЕ ДОКУМЕНТОВ В ДЕЛА
Подсистема управления архивом должна обеспечивать автоматизацию следующих
функций, связанных с архивным хранением документов, в котором участвуют сотрудники
структурных подразделений ОИГВ ВО и сотрудники архивов:
Комплектование дел в подразделении в соответствии с утвержденной номенклатурой дел:
 создание, индексация дел в соответствии с номенклатурой;
 задание срока хранения дела в соответствии с номенклатурой;
 формирование дел с разбивкой на тома;
 учет и архивное хранение документов на бумажных носителях;
 фиксация факта передачи дел из подразделений на архивное хранение;
 автоматическое составление сдаточной описи дел подразделения при передаче на
хранение в архив.
Поиск документов в архиве:
 выдача документов (дел, томов) во временное пользование;
 фиксация факта выдачи документов (дел, томов) во временное пользование;
стр. 54 из 69
 учет передачи дел (ведение истории).
Уничтожение дел в связи с истечением срока хранения:
 фиксация факта уничтожения дел в связи с истечением срока хранения;
 оформление акта о выделении к уничтожению документов, не подлежащих хранению.
Передача документов на постоянное хранение в государственные архивы:
 фиксация факта передачи дел на постоянное хранение в государственные архивы;
 составление описи дел для передачи на постоянное хранение в государственные
архивы.
3.5.4.8. УПРАВЛЕНИЕ
СОВЕЩАНИЯМИ
СОВЕЩАТЕЛЬНЫХ ОРГАНОВ УПРАВЛЕНИЯ
И
ОБРАБОТКА
ДОКУМЕНТОВ
Подсистема подготовки и проведения заседаний должна обеспечивать полный цикл
подготовки для проведения заседаний коллегиальных органов управления Правительства области
и ОИГВ ВО, участия в подготовке материалов заседаний Правительства области и ОИГВ ВО,
фиксации протокола заседания, выдачи отдельных поручений (с использованием ОРД) с
контролем их исполнения.
Подсистема заседаний должна обеспечивать выполнение следующих функции:
 формирование проекта повестки дня;
 рассылка уведомлений сотрудникам, ответственным за подготовку материалов к
заседанию;
 получение проекта решения и справок от ответственного исполнителя;
 утверждение повестки дня;
 формирование пакета документов к заседанию, включающего проекты решений;
 рассылка приглашений на заседание;
 создание проекта протокола заседаний;
 регистрация протокола в подсистеме ОРД;
 создание карточек поручений по протоколу, контроль исполнения поручений с
использованием подсистемы ОРД;
 печать документов, используемых при подготовке и проведении заседаний по бланкам.
Формы бланков уточняются на этапе опытной эксплуатации АСЭД ОИГВ.
3.5.4.9. ИСПОЛЬЗОВАНИЕ
РАБОТЕ
ДОКУМЕНТОВ В
СПРАВОЧНО-ИНФОРМАЦИОННОЙ
Специализированная справочная подсистема хранения данных по изменению названий и
реквизитов государственных организаций должна обеспечивать выполнение следующих функций:
 создание карточки организации, её регистрация, сохранение, редактирование;
 обработку и хранение информации об контрагентах;
 предоставление удобных средств для информационно-поисковой работы по всему
массиву хранимой информации;
 возможность хранения дополнительной информации об контрагентах;
 подготовка справок и отчетов установленной формы.
3.5.4.10. УПРАЛЕНИЕ НОРМАТИВНО-ПРАВОВЫМИ АКТАМИ
стр. 55 из 69
АСЭД ОИГВ должна обеспечить хранение и поддержание в актуальном состоянии
(возможность фиксации статуса документа – действующий/отменен) нормативно-правовых актов
(далее по тексту - НПА) Правительства области и ОИГВ ВО.
Каждый НПА регистрируется в АСЭД ОИГВ посредством заполнения специальной
карточки, содержащей атрибуты документа, а также поля статуса, категории и других
вспомогательных признаков.
АСЭД ОИГВ должна предоставлять возможность установки взаимосвязей между
документами.
Должна быть реализована поддержка версионности документов, а также предоставлен
механизм проверки актуальности и обновления текущих версий.
Должен обеспечиваться удобный и быстрый поиск документов. Поиск может
производиться по значениям ключевых атрибутов документов, статусам, категориям и другим
признакам. Кроме этого, должен быть реализован полнотекстовый поиск по содержанию
документов, а также поиск документов, взаимосвязанных друг с другом или относящихся к
одному полномочию.
Доступ к документам для чтения должен быть открыт всем заинтересованным
пользователям АСЭД ОИГВ. Добавлять, изменять, удалять информацию в хранилище могут
только назначенные для этих целей ответственные специалисты (регистраторы НПА) в
соответствии с настройками прав доступа (в т.ч. по видам нормативных документов).
3.5.4.11. ПОТОКОВЫЙ ВВОД ДОКУМЕНТОВ
Подсистема должна обеспечивать как подокументное, так и потоковое сканирование
бумажных документов с последующим вводом полученных электронных образов в АСЭД ОИГВ.
Сканирование отдельных документов проводится через специальный программный
интерфейс или непосредственно из РК документа.
В системе должно быть реализовано взаимодействие с программными-аппаратными
комплексами потокового сканирования и распознавания документов (в том числе и реализующих
функцию распознавания форм с сохранением полей формы в виде записи БД).
Для идентификации многостраничных документов, а также автоматического прикрепления
электронных образов документа к РК должна поддерживаться технология штрих-кодов. При
заведении РК документа АСЭД ОИГВ должна поддерживать формирование и вывод на печать
штрих-кода, прикладываемого к бумажному документу. При сканировании этого документа его
электронный образ должен подсоединиться к заведенной ранее РК автоматически. Вместе с
электронным образом к РК может прикрепляться и файл с распознанным текстом документа.
АСЭД ОИГВ должна поддерживать функцию поиска РК с прикрепленными электронными
образами документов, их распознавание и добавление файлов с текстом документов к
соответствующим РК.
3.5.4.12. ВЕДЕНИЕ ЭЛЕКТРОННЫХ РЕЕСТРОВ
Подсистема предназначена для автоматизации работы с информацией, представление
которой требует использования электронных реестров: в том числе информация об контрагентах,
информация об обращениях граждан, информация касающейся наград и поощрений работников и
пр. Подсистема должна обеспечивать выполнение следующих функций:
 ведение РК;
 учет и анализ РК;
 группировка и представление РК в виде электронных реестров;
 печать информации;
стр. 56 из 69

поиск информации.
3.5.4.13. УПРАВЛЕНИЕ ДОГОВОРАМИ
Подсистема управления договорами должна обеспечивать полный цикл работы как с
внешними (поступающими), так и с внутренними (формируемыми в ОИГВО ВО) документами от
момента подготовки документа, его регистрации, получения до его уничтожения или передачи на
архивное хранение.
Подсистема должна обеспечивать выполнение следующих функции:
 создание проекта документа с заполнением полей РК;
 согласование проекта документа;
 отправка проекта документа на подпись;
 регистрация документа — присвоение номера с фиксацией информации в РК;
 ознакомление с документом;
 фиксирование связи документа с некоторым (некоторыми) входящим, внутренним,
исходящим, ОРД («в ответ на…»);
 фиксация наложенного поручения или резолюции, в том числе не требующей
исполнения;
 постановка документа на контроль;
 создание отчета об исполнении поручения или резолюции;
 снятие документа с контроля;
 сдача документа (его копии) на хранение в дело.
3.5.4.14. ЗАЩИТА ИНФОРМАЦИИ И ИСПОЛЬЗОВАНИЕ ЭЦП
Защита от несанкционированного доступа должна обеспечивать условия эксплуатации
АСЭД ОИГВ, не допускающие работу с АСЭД ОИГВ посторонних лиц. Защита должна
выполняться как собственными средствами АСЭД ОИГВ, так и стандартными средствами
операционных систем, а также программно-аппаратными средствами сторонних производителей.
Система защиты информации должна включать организационные меры и программноаппаратные методы и средства. Организационные меры должны осуществляться
соответствующими службами Заказчика и исключать неконтролируемый доступ посторонних лиц
к техническим средствам информационно-телекоммуникационной сети, к носителям информации,
средствам печати бумажных копий, кабельным системам. Методические рекомендации и
требования по организации системы защиты информации АСЭД ОИГВ разрабатываются и
передаются Заказчику в рамках выполнения работ по настоящим ТТ Исполнителем.
АСЭД ОИГВ должна обеспечивать хранение и работу с электронными копиями
документов, содержащих открытую, конфиденциальную (для служебного пользования)
несекретную или персональную информацию.
АСЭД
ОИГВ
должна
использовать
только
сертифицированные
средства
криптографической защиты информации, электронной цифровой подписи и гибкие возможности
настройки прав доступа к АСЭД ОИГВ.
Подсистема «ЭЦП и шифрование» предназначена для наложения на объекты и
электронные документы АСЭД ОИГВ электронно-цифровой подписи для однозначной
аутентификации владельца подписи и гарантии неизменяемости документа после его подписи, а
также шифрования содержания документов.
Неизменность хранимой в системе информации обеспечивается данной подсистемой при
помощи механизма ЭЦП, применяемой к электронным документам. Достоверность информации в
стр. 57 из 69
системе должна обеспечиваться соблюдением регламентов работы пользователей с системой и
соблюдением свойства неизменности хранения документов.
Технология работы с ЭЦП должна обеспечивать:
 проверку факта неизменности документа с помощью ЭЦП в РК (в т.ч. и прикрепленных
файлов)
 проверку принадлежности ЭЦП (ФИО подписавшего и дату подписания при наличии
соответствующей информации в ЭЦП)
 возможность подписания ЭЦП в АСЭД ОИГВ любых электронных документов (в т.ч. и
прикрепленных файлов);
 поддержку сертификатов, выпущенные на основе алгоритмов ГОСТ Р 34.10-2001, с
использованием сертифицированных СКЗИ (CryptoPro 3.6 и выше), международного
стандарта X.509 (ITU-T X.509), MS Crypto API 2.0.
При создании электронно-цифровой подписи в АСЭД ОИГВ должны производиться
следующие действия:
 выбор закрытого ключа для создания ЭЦП;
 обеспечение возможности работы с внешними носителями секретных ключей
пользователя (e-Token, Ru-Token, электронными идентификаторами iButton);
 создание ЭЦП блока данных и/или файла документа вместе с датой и временем
совершения операции;
 прикрепление сертификата к подписанному блоку данных или файлу документа;
 сохранение ЭЦП и ее сертификата в базе данных.
При проверке электронно-цифровой подписи должны производиться следующие действия:
 визуализация результатов проверки ЭЦП и даты/времени совершения операции;
 просмотр сертификата ЭЦП, использованного для подписания документа.
Доступ к АСЭД ОИГВ должен быть представлен только для зарегистрированных
пользователей. Каждому пользователю присвоена роль, согласно которой осуществляется его
доступ к тем или другим компонентам системы.
Должна быть обеспечена возможность создания произвольного количества ролей
пользователей;
Должна быть обеспечена возможность регистрации произвольного количества учетных
записей пользователей.
3.5.5. ТРЕБОВАНИЯ К ПРОГРАММНОМУ ОБЕСПЕЧЕНИЮ
АСЭД ОИГВ должна быть гибкой и масштабируемой, должна поддерживать самые
сложные процессы и структуры обработки документов.
АСЭД ОИГВ должна быть готова к подключению сертифицированных крипто-библиотек и
подключению ЭЦП.
АСЭД ОИГВ должна быть построена на базе промышленной СУБД.
АСЭД ОИГВ должна быть простой в настройке и обслуживании, создание документов в
АСЭД ОИГВ должно быть на основе настраиваемых форм (шаблонов). Количество создаваемых
шаблонов должно быть не ограничено. Изменения, вносимые в конфигурацию АСЭД ОИГВ
должны быть сразу доступны пользователю (без перекомпиляции исходного кода). АСЭД ОИГВ
должна обеспечить присоединение документов любого формата к карточке электронного
документа.
АСЭД ОИГВ должна иметь развитую защиту от несанкционированного доступа,
включающую систему идентификаторов и паролей, разграничение прав доступа к объектам и
стр. 58 из 69
функциям, создание ролей пользователей, хранения и передачи информации в зашифрованном
виде.
АСЭД ОИГВ должна иметь развитые возможности по настройке системы без применения
навыков программирования.
АСЭД ОИГВ должна обеспечить версионный контроль присоединенных электронных
образов, поиск по реквизитам карточки и полнотекстовый поиск по содержанию электронного
образа документа.
АСЭД ОИГВ должна обеспечить возможность получения информации из различных
источников с использованием стандартных протоколов обмена данными, а так же позволять
реализацию дополнительных адаптеров к различным системам.
АСЭД ОИГВ должна обеспечить возможность централизованного и децентрализованного
хранения и обработки документов, объединение и группировку документов с установкой между
электронными образами документов логических связей и возможностью прикреплять к одной РК
несколько произвольных файлов.
АСЭД ОИГВ должна обеспечить пользователям возможность создания произвольных схем
обработки документов, использование типовых схем обработки документов, параллельную и
последовательную обработку документов, организацию коллективной работы над документами,
ведение классификаторов и рубрикаторов.
АСЭД ОИГВ должна обеспечить формирование типовых форм отчетов, статистические
отчеты (OLAP). Подсистема формирования отчетов должна быть встроенной, позволять без
программирования создавать OLAP-отчеты, и визуализировать результаты с помощью диаграмм.
При выборе любой ячейки OLAP-отчета или аналитического отчета (перечня) пользователю
должна быть доступна возможность детализации полученных данных с учетом прав доступа.
АСЭД ОИГВ должна обладать широкими интеграционными возможностями.
АСЭД ОИГВ должна поддерживать возможность интеграции с Active Directory (AD или
LDAP) для синхронизации данных о правах доступа пользователей, а также поддерживать
возможность авторизации в системе «без пароля», используя доменный пароль пользователя.
АСЭД ОИГВ должна позволять выполнять поиск данных как по реквизитам, так и по
данным присоединенных файлов.
АСЭД ОИГВ должна позволять использовать как серверную, так и клиентскую часть на
свободном ПО.
Должна быть обеспечена возможность массовой загрузки информации в АСЭД ОИГВ.
3.6. ИНТЕГРАЦИЯ С ДРУГИМИ АВТОМАТИЗИРОВАННЫМИ
ЭЛЕКТРОННОГО ДОКУМЕНТООБОРОТА ОИГВ ВО
СИСТЕМАМИ
В части ОИГВ ВО уже внедрены АСЭД (Правительство области, Департамент информационных технологий
и телекоммуникаций области и др.). Конечное число внедренных АСЭД в ОИГВ ВО и их технические
характеристики должны быть выявлены на этапе обследования объекта автоматизации.
Исполнитель по итогам обследования объекта автоматизации должен предложить
заказчику варианты интеграции Системы с существующими в ОИГВ ВО АСЭД или, по
согласованию с Заказчиком и ОИГВ ВО, в котором внедрена АСЭД, в рамках данного открытого
конкурса провести замену АСЭД ОИГВ ВО на внедряемую.
3.7. СОСТАВ И СОДЕРЖАНИЕ РАБОТ ПО СОЗДАНИЮ АСЭД ОИГВ
Стадии, сроки выполнения работ и предъявляемые результаты приведены в таблице 4.
стр. 59 из 69
Таблица 4
№
1.
Стадии, сроки выполнения работ и предъявляемые результаты
Срок выполнения
Содержание работ
работ
Обследование ОИГВ ВО в
В течение 5-7 недель с
соответствии с п. 1.4 настоящих ТТ момента
заключения
государственного
контракта
2.
Разработка требований к составу
нормативно-справочной
информации, необходимой для
конфигурации АСЭД ОИГВ
3.
Разработка техно-рабочего проекта
4.
Развертывание и настройка
серверной части АСЭД ОИГВО на
аппаратных средствах Заказчика
В течение 5-7 недель с
момента
заключения
государственного
контракта
5.
Конвертация данных
6.
Разработка документов
«Руководство пользователя» и
«Руководство администратора»
В течение 2-4 недель с
момента
подписания
акта-приемки
выполненных работ по
развертыванию
и
настройке
серверной
части АСЭД ОИГВО на
аппаратных средствах
Заказчика
7.
Проведение тестовых испытаний и
приемка в опытную эксплуатацию
8.
Разработка документа «Инструкция
по эксплуатации Комплекса
Технических Средств (далее по
тексту - КТС)»
стр. 60 из 69
Не более 2 недель после
подписания
актаприемки выполненных
работ по конвертации
данных
Не более 2 недель после
подписания
актаприемки выполненных
работ по конвертации
данных
Предъявляемый
результат
Отчет об обследовании;
Технические спецификации
для
приобретения
дополнительного
недостающего
оборудования,
ПО
и
организации каналов связи;
Акт-приемки выполненных
работ.
Требования
к
составу
нормативно-справочной
информации в виде отчета;
Акт-приемки выполненных
работ.
Техно-рабочий проект;
Акт-премки выполненных
работ.
Программное обеспечение,
развернутое на технических
средствах Заказчика;
Отчет
о
выполненных
работах;
Акт-премки выполненных
работ.
Отчет
о
выполненных
работах;
Акт-премки выполненных
работ.
Руководство пользователя;
Руководство
администратора;
Акт-приемки выполненных
работ.
Методика испытаний;
Протокол испытаний;
Акт-приемки выполненных
работ.
Инструкция по
эксплуатации КТС;
Акт-приемки выполненных
работ.
Содержание работ
№
9.
Развертывание АСЭД ОИГВ на
рабочих местах пилотной группы
пользователей и обучение
пользователей пилотной группы по
направлению «Системный
технолог» и «Пользователь».
10.
Проведение предварительных
испытаний и приемка в опытную
эксплуатацию
11.
Опытная эксплуатация:
- доработка и настройка системы
по предложениям и замечаниям
Заказчика и пилотной группы
пользователей,
- обучение пользователей ОИГВ
ВО,
- подготовка системы к приемосдаточным испытаниям.
Приемка системы в постоянную
эксплуатацию.
12.
Срок выполнения
Предъявляемый
работ
результат
Не более 2 недель после Программное обеспечение,
проведения
тестовых развернутое на рабочих
испытаний
местах пилотной группы
пользователей;
Программы обучения
пользователей;
Акт-приемки выполненных
работ
Не более 2 недель после Методика предварительных
подписания
акта- испытаний;
приемки выполненных Протокол предварительных
работ по установке ПО испытаний;
пилотной
группы Акт-приемки выполненных
пользователей и их работ;
обучения
Акт-приемки в опытную
эксплуатацию.
В
течение
12-14 Отчет
о
проведении
недель с момента опытной эксплуатации;
приема системы в Акт-приемки выполненных
опытную
работ.
эксплуатацию
Не более 2 недель с
момента
окончания
опытной эксплуатации
Методика испытаний;
Протокол испытаний;
Акт-приемки выполненных
работ;
Акт-приемки системы в
постоянную эксплуатацию
4. ТРЕБОВАНИЯ К АИС «ИП ОИГВ ВО»
4.1. ПЛАНОВЫЕ СРОКИ НАЧАЛА И ОКОНЧАНИЯ РАБОТ
Начало работ – с даты подписания государственного контракта.
Окончание работ – в течение 34 недель с даты подписания государственного контракта.
4.2. ЦЕЛЬ СОЗДАНИЯ
Целью АИС «ИП ОИГВ ВО» является реализация прав граждан и организаций на доступ к
информации о деятельности ОИГВ ВО.
Основными целями создания АИС «ИП ОИГВ ВО» являются:
стр. 61 из 69
 публикация сведений о деятельности ОИГВ ВО в сети Интернет, в соответствии с
Федеральным законом от 09.02.2009 № 8-ФЗ «Об обеспечении доступа к информации о
деятельности государственных органов и органов местного самоуправления»;
 повышение информационной открытости и прозрачности деятельности ОИГВ ВО;
 обеспечение более тесного взаимодействия ОИГВ ВО с населением и бизнесом.
4.3. ХАРАКТЕРИСТИКА АВТОМАТИЗИРУЕМЫХ ПРОЦЕССОВ
Автоматизацией процессов является деятельность ОИГВ ВО по:
 поддержке и развитию официального Интернет-портала ОИГВ ВО в сети Интернет;
 предоставлению информационных услуг для различных представителей целевых
аудиторий Интернет-портала ОИГВ ВО;
 подготовке, согласованию, публикации и актуализации информации на Интернетпортале ОИГВ ВО.
Основным инструментом пользователей АИС «ИП ОИГВ ВО» является браузер, который
обеспечивает ему доступ к информации в необходимом объеме и формате.
Пользователями АИС «ИП ОИГВ ВО» являются:
 пользователи сети Интернет;
 операторы АИС «ИП ОИГВ ВО»;
 администраторы АИС «ИП ОИГВ ВО».
Для пользователей АИС «ИП ОИГВ ВО» предусматриваются наборы типовых задач,
функциональных возможностей, а также групповые и индивидуальные права доступа к разделам
АИС «ИП ОИГВ ВО» и созданным на его основе сайтам.
4.4. ТРЕБОВАНИЯ К АИС «ИП ОИГВ ВО»
4.4.1. ТРЕБОВАНИЯ К АИС «ИП ОИГВ ВО» В ЦЕЛОМ
АИС «ИП ОИГВ ВО» должна быть построена с использованием стандартных и
унифицированных методов разработки программных средств..
При проектировании и разработке пользовательских интерфейсов должны использоваться
единые принципы организации доступа к предоставляемым функциональным возможностям.
Разрабатываемое прикладное ПО и техническая документация должны соответствовать
действующим национальным стандартам.
4.4.2. ТРЕБОВАНИЯ К ФУНКЦИЯМ АИС «ИП ОИГВ ВО»
4.4.2.1. ТРЕБОВАНИЯ К СТРУКТУРЕ И ФУНКЦИОНИРОВАНИЮ АИС «ИП ОИГВ
ВО»
По значимости публикуемой информации АИС «ИП ОИГВ ВО» должна относиться к
уровню управления отраслевыми информационными ресурсами для предоставления детальной
информации по различным отраслям деятельности ОИГВ ВО.
АИС «ИП ОИГВ ВО» должна основываться на трехуровневой модели:
 Презентационный уровень, обеспечивающий интерфейсы необходимые для управления
и настройки информационных разделов и сервисов (открытая часть) АИС «ИП ОИГВ
ВО».
стр. 62 из 69


Уровень бизнес-логики, содержащий программные объекты (закрытая часть) и
программный код, который реализует логику работы подсистем, и модулей
реализующих информационные и интерактивные сервисы.
Уровень хранения данных, включающий в себя СУБД и компоненты для доступа к
данным. Для хранения информации должна использоваться файловая система и СУБД.
ПРЕЗЕНТАЦИОННЫЙ УРОВЕНЬ
Структура информационных разделов должна основываться на специфике использования
информационных материалов Правительством Вологодской области и ОИГВ ВО для публичного
ознакомления, в частности в сети Интернет, материалах текущего сайта Правительства
Вологодской области по адресу: www.vologda-oblast.ru , интернет-сайтов ОИГВ ВО и требованиях
8-ФЗ.
Необходимо определить и сегментировать по характеристикам потенциальную аудиторию
Интернет-портала с детализацией до подгрупп. Составить и согласовать с Заказчиком матрицу
релевантных потребностей подгрупп. На основе полученных данных, опираясь на приоритетные
предпочтения потенциальной аудитории:
 Разделить на основные темы/направления, которые впоследствии должны быть
представлены отдельными сайтами с доменными адресами третьего уровня и
объединены в общее кольцо сайтов. Например:
 Губернатор области.
 Правительство Вологодской области.
 Органы исполнительной государственной власти области.
 Органы местного самоуправления области.
 Экономика, Бизнес, Госзаказ.
 Социальная сфера.
 Туризм.
 Создать матричную схему, которая за счет средств навигации (тегов, фильтров,
категорий информации) предоставит полную информацию по интересующей теме
(общую, частную – по муниципалитетам, сопутствующую информацию – видео,
документы, схемы, графики).
Разделение на основные темы должно позволить организовать максимально комфортное
ознакомление с материалами основных групп аудитории. Структура и навигация по материалам
на тематических сайтах должны быть выдержаны в едином стиле, но отличаться конкретными
целевыми предпочтениями в части структуры, навигации, в т.ч. для английской и немецкой
версий Интернет-портала.
В информационной структуре АИС «ИП ОИГВ ВО» должен быть раздел, содержащий
информацию о размещении заказов государственными заказчиками Вологодской области, а также
ссылку на сайт: www.gz.gov35.ru
УРОВЕНЬ БИЗНЕС-ЛОГИКИ
Функциональная часть АИС «ИП ОИГВ ВО» должна являться общей для всех сайтов
Интернет-портала и регулироваться на уровне прав доступа к разделам подсистем и модулей АИС
«ИП ОИГВ ВО» для каждого из администраторов сайтов.
УРОВЕНЬ ХРАНЕНИЯ ДАННЫХ
стр. 63 из 69
Вся информация, используемая в рамках функционирования Интернет-портала должна
храниться в СУБД в структурированном виде. СУБД должна удовлетворять следующим
требованиям:
 физическая и логическая структуры СУБД должны соответствовать друг другу;
 структура СУБД должна допускать ее дальнейшее развити
4.4.3. ТРЕБОВАНИЯ К СОЗДАВАЕМЫМ ПОДСИСТЕМАМ АИС «ИП ОИГВ ВО»
4.4.3.1. ПОДСИСТЕМА УПРАВЛЕНИЯ ИНТЕРНЕТ-РЕСУРСАМИ
Управления содержанием
Управление информационным наполнением сайтов АИС «ИП ОИГВ ВО» должно
осуществляться на уровне информационных блоков, каждый из которых должен быть привязан к
различным выделенным разделам макетов и расположен одновременно на нескольких страницах
сайтов АИС «ИП ОИГВ ВО».
Выбор и замена шаблонов разделов должны происходить из набора имеющихся в
подсистеме. Так же должна предусматриваться возможность загрузки в подсистему новых
шаблонов, представляющих собой особым образом размеченный ASCII-файл, определяющий как
графическое оформление страниц раздела, так и их макет (раскладку).
При формировании разделов должен использоваться механизм кэширования,
обеспечивающий индивидуальные настройки времени кэширования для информационных блоков,
размещенных в разделе.
Должен вестись журнал операций, в котором фиксируются дата, время, имя
администратора Интернет-ресурса, совершившего операцию, тип операции, данные о
совершенных действиях.
Главное меню / Карта сайтов
Должна быть обеспечена возможность создания, редактирования и удаления разделов
сайтов АИС «ИП ОИГВ ВО». Разделы должны быть организованы в иерархическую древовидную
структуру, любой раздел должен иметь произвольное количество подразделов. Для представления
разделов должна быть возможность размещения на страницах сайтов навигационных элементов:
главное меню, строка навигации и карта сайта.
В главном меню каждого из сайтов должны выводится только те разделы, у которых будет
установлен соответствующий атрибут. В главное меню также должны быть включены ссылки на
произвольные URL. Количество пунктов в меню и глубина вложенности уровней могут иметь
ограничения вызванные особенностями макетов.
Так же должна быть разработана возможность выбора и размещения альтернативного
меню разделов. Альтернативное меню должно иметь возможность использоваться совместно с
главным меню, а также иметь отличающуюся структуру и содержание разделов.
Публикация текстовых материалов.
Должна быть обеспечена возможность размещения текстовых материалов, в том числе
включающих HTML-теги, их хранение и согласование.
Для представления информационного наполнения конечным пользователям сайтов, АИС
«ИП ОИГВ ВО» должна обеспечить:
 Возможность редактирования HTML текста в двух режимах: в виде исходного HTML
кода и в WYSIWYG режиме (What You See Is What You Get).
 Организацию цепочки согласования и публикацию информационного наполнения для
каждого из сайтов АИС «ИП ОИГВ ВО», а также деление доступа администраторов к операциям
в процедуре публикации;
стр. 64 из 69
 Поддержку тестовых версий сайтов. Для каждого сайта тестовая версия должна иметь
отдельное доменное имя и представлять собой полнофункциональную динамическую версию,
позволяющую просмотреть размещенные материалы перед публикацией на рабочей версии.
 Вывод в отдельном окне браузера версии для печати.
Публикация новостной ленты
Публикация новостной ленты необходима для размещения сообщений сайтов,
публикуемых в хронологическом порядке (новостных лент), а также освещения различных
событий, имеющих четкую привязку ко времени (календарей событий).
Должна поддерживаться возможность настройки количества новостей на странице,
межстраничной навигации, порядок сортировки, экспорта в RSS.
Представление текстовых списков и списков файлов.
Функциональность предназначена для вывода форматированных текстовых списков или
списков файлов на страницах сайтов. Должна включать в себя возможность настройки по
количеству элементов на странице, вариантам использования (краткий список, полный список,
полный список с оглавлением), нумерации, порядку сортировки, необходимости версии для
печати.
Форма обратной связи
Для получения обратной связи от посетителей сайтов должны быть разработаны формы
для обратной связи. Формы должны включать в себя описание вопроса, различные виды
вариантов ответов, обязательность заполнения.
На e-mail администратора соответствующего сайта должны приходить уведомления о
заполненных формах со всеми заполненными данными. Все заполненные анкеты пользователей
должны сохраняться в БД.
Форум
Форум предназначен для интерактивного общения пользователей, организации форумов и
конференций, обсуждения тематических вопросов, проблем и т.п.
Функциональность должна обеспечивать реализацию обмена информацией между
пользователями с сохранением указанных сообщений в информационной базе сайтов АИС «ИП
ОИГВ ВО». Структура данных должна представлять собой «дерево» сообщений, связанных
отношениями «вопрос-ответ».
Администраторы должны иметь возможность модерирования форумов, блокирования
учетных записей, получения уведомлений о поступлении новых сообщений.
Медиагалерея
Медиагалерея предназначена для размещения и воспроизведения графических файлов,
видео, аудиофайлов.
Список медиаконтента на страницах порталов АИС «ИП ОИГВ ВО» должен быть
представлен в табличном виде с заданным количеством столбцов. Для видео и аудиофайлов
должно выводиться ассоциированное изображение – превью (кадр видеоролика, фотография в
малом разрешении для ознакомления). Каждый элемент должен сопровождаться названием и
описанием. Воспроизведение медиаконтента должно быть обеспечено элементами управления
воспроизведением.
стр. 65 из 69
Таксономия
Должна быть обеспечена возможность разметки различных элементов контента: текстовых
материалов, новостей, списков, фотографий, видеороликов, с возможностью поиска по
назначенным тегам (облако тегов) и элементам контента.
Минимальные параметры представления:
 Вариант использования (список) — определяет способ подачи информации.
Возможные значения: «облако тегов», «поиск по тегу»;
 Элемент контента (список) — определяет элементы контента которые участвуют при
выводе тегов. Предварительные возможные значения: «все материалы», «новости», «список»,
«простой текст», «фото», «видео»;
 Минимальный размер шрифта (число) — определяет минимальный размер шрифта в
пикселях, задаваемого для отображения наименований тегов в варианте использования «Облако
тегов».
Экспорт элементов контента
Автоматический экспорт элементов контента в текстовый XML-файл, должен быть
организован в соответствии со стандартом RSS 2.0., который должен предоставлять возможность
подписки на материалы, по различным тематикам (тегам).
Полнотекстовый поиск
В АИС «ИП ОИГВ ВО» должна использоваться подсистема полнотекстового поиска с
морфологией русского, английского и немецкого языков, обеспечивающая поиск документов,
содержащих заданные пользователем ключевые слова.
Статистика
Должен быть обеспечен учет посещений пользователями сайтов АИС «ИП ОИГВ ВО»,
анализ полученных данных и их предоставление в формализованном виде администраторам.
Должно быть обеспечено решение следующих задач:
 сбор информации о посещении страниц сайтов;
 создание отчетов содержащих информацию о посещаемости сайтов;
 настройка состава информации отчетов о посещаемости сайтов.
Должен быть обеспечен сбор, обработка и отображение следующий информации:
 Информация о статистике посещений сайтов АИС «ИП ОИГВ ВО»:
 размер аудитории сайтов;
 статистика посещений сайта по дням недели;
 статистика посещений сайта по часам;
 статистика посещений выбранных страниц сайта.
 Информация о навигации пользователей по сайтам:
 ссылающиеся Интернет-ресурсы;
 переходы на страницы сайта;
 переходы между страницами сайта.
 Информация о параметрах конфигурации компьютеров пользователей:
 разрешение экрана пользователя;
 глубина цвета;
 браузер;
 операционных систем.
стр. 66 из 69
4.5. ТРЕБОВАНИЯ К ВИДАМ ОБЕСПЕЧЕНИЯ
4.5.1. ТРЕБОВАНИЯ К ИНФОРМАЦИОННОМУ ОБЕСПЕЧЕНИЮ
Для хранения данных должны использоваться реляционные СУБД, обеспечивающие
реализацию встроенных механизмов построения индексов и контроля целостности данных.
Допускается размещение отдельных параметров конфигурации, не подлежащих модификации в
ходе их нормального функционирования и обслуживания, во внешних конфигурационных
файлах. Информация должна размещаться в БД в нормализованной форме. Допускается
использование дополнительных ненормализованных структур данных для повышения
производительности.
4.5.2. ТРЕБОВАНИЯ К ТЕХНИЧЕСКОМУ ОБЕСПЕЧЕНИЮ АИС «ИП ОИГВ ВО»
Серверная часть системы должна включать 3 компонента: сервер СУБД, сервер
приложений администраторской части и сервер приложений пользовательской части.
4.5.3. ТРЕБОВАНИЯ К ПРОГРАММНОМУ ОБЕСПЕЧЕНИЮ
АИС «ИП ОИГВ ВО» должна корректно работать при размещении на программноаппаратной платформе со следующими характеристиками:
 операционная система - последняя стабильная версия FreeBSD, Linux или ПО
компании Майкрософт по выбору Исполнителя;
 Web-сервер - Apache версии не ниже 1.3.26. или другое ПО, с аналогичным
функционалом;
 СУБД – промышленная реляционная СУБД;
 межсетевой экран и другие средства защиты информации, если их функции не
реализованы средствами технического обеспечения;
 необходимые программные библиотеки;
 системные утилиты и другое необходимое ПО.
4.5.4. ТРЕБОВАНИЯ К ОРГАНИЗАЦИОННОМУ ОБЕСПЕЧЕНИЮ
Для минимизации организационных рисков создания и развития системы должно быть
обеспечено планирование изменений и развитие системы, направленное на удовлетворение
информационных потребностей пользователей, обеспечение совместимости с другими
информационными ресурсами и системами. Организационное обеспечение может осуществляться
как силами организации Заказчика, так и на основании соглашения с внешними организациями.
4.5.5. ТРЕБОВАНИЯ К БЕЗОПАСНОСТИ
Все данные, содержащиеся в БД АИС «ИП ОИГВ ВО», должны быть защищены по
матричной схеме безопасности.
Матрицы уровней доступа, которые присваиваются пользователям, должны создаваться и
редактироваться в защищенном редакторе, доступ к которому должен осуществляться
администраторами.
стр. 67 из 69
Программные средства обеспечения безопасности не должны ухудшать основные
функциональные характеристики АИС «ИП ОИГВ ВО» (надежность, быстродействие,
возможность изменения конфигурации).
4.6. СОСТАВ И СОДЕРЖАНИЕ РАБОТ
Состав и содержание работ, сроки их выполнения и результаты работ по окончании
соответствующих стадий и этапов работ, приведены в таблице 5.
Таблица 5
Содержание работ
1. Обследование объектов
автоматизации в соответствии с п. 1.4
настоящих ТТ
Срок выполнения
работ
В течение 2-4 недель
с момента
заключения
государственного
контракта
2. Разработка техно-рабочего проекта
Предъявляемый результат
Отчет об обследовании;
Технические спецификации для
приобретения дополнительного
недостающего
оборудования,
ПО и организации каналов
связи;
Акт-приемки выполненных
работ.
Техно-рабочий проект;
Акт-приемки выполненных
работ.
3. Разработка проектных решений,
развертывание и настройка системы на
технических средствах Заказчика
В течение 5-7 недель
с момента
заключения
государственного
контракта
Программное обеспечение,
развернутое на технических
средствах Заказчика;
Отчет о выполненных работах;
Акт-приемки выполненных
работ.
4. Разработка эксплуатационной
документации
В течение 5-7 недель
с момента
заключения
государственного
контракта
Руководства оператора;
Руководство администратора;
Акт-приемки выполненных
работ.
5. Проведение предварительных
испытаний и приемка в опытную
эксплуатацию (исключая подсистему
интеграции с АСЭД ОИГВ ВО)
В течение 7-9 недель
с момента
заключения
государственного
контракта
Методика
предварительных
испытаний;
Протокол
предварительных
испытаний;
Акт-приемки
выполненных
работ;
Акт-приемки
в
опытную
эксплуатацию.
стр. 68 из 69
6. Опытная эксплуатация
В течение 21-23
недель с момента
приемки системы в
опытную
эксплуатацию
Отчет о проведении опытной
эксплуатации;
Акт-приемки
выполненных
работ.
7. Проведение испытаний подсистемы
интеграции с АСЭД ОИГВО ВО
В течение 14-16
недель с момента
заключения
государственного
контракта
Методика испытаний;
Протокол испытаний;
Акт-приемки
выполненных
работ;
Акт-приемки
в
опытную
эксплуатацию.
8. Приемка системы в постоянную
эксплуатацию.
Не более 2 недель с
момента окончания
опытной
эксплуатации
Методика испытаний;
Протокол испытаний;
Акт-приемки
выполненных
работ;
Акт-приемки
системы
в
постоянную эксплуатацию
Критерий оценки
Значимость критерия
стр. 69 из 69
Цена контракта
(Ra)
35 %
Качество
работ и
квалификаци
я участника
конкурса
Сроки
(периоды)
выполнения
работ (Rf)
(Rc)
20 %
35 %
Сроки
предоставлени
я гарантии
качества работ
(Rg)
10%