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

ТИПОВЫЕ ТЕХНИЧЕСКИЕ ТРЕБОВАНИЯ

К АВТОМАТИЗИРОВАННОЙ
ИНФОРМАЦИОННОЙ СИСТЕМЕ ЦОУ
(АИС «ЦОУ»)
СОДЕРЖАНИЕ

СОД Е РЖА Н И Е..................................................................................................................................................................2


С П И СО К СО К РА Щ Е Н И Й.................................................................................................................................................3
Н А З Н АЧ Е Н И Е И Ц Е Л И СО З Д А Н И Я С И С Т Е М Ы.........................................................................................................4
Х А РА КТ Е Р И С Т И КА О Б Ъ Е КТО В А ВТО М АТ И З А Ц И И................................................................................................5
3.1.1 Требования к структуре и функционированию системы.............................................................................................................. 6
Т Р Е Б О В А Н И Я К С И С Т Е М Е............................................................................................................................................6
3.1.2 Требования к численности и квалификации персонала системы и режиму его работы................................................ 7
3.1.3 Показатели назначения.............................................................................................................................................................................. 7
3.1.4 Требования к надежности......................................................................................................................................................................... 7
3.1.5 Требования безопасности......................................................................................................................................................................... 8
3.1.6 Требования к эргономике и технической эстетике......................................................................................................................... 8
3.1.7 Требования к защите информации от несанкционированного доступа................................................................................ 8
3.1.8 Требования по сохранности информации при авариях............................................................................................................... 9
3.1.9 Требования к патентной чистоте............................................................................................................................................................ 9
3.1.10 Требования по стандартизации и унификации.............................................................................................................................. 9
3.2.1 Перечень подсистем, их назначения и основные характеристики.......................................................................................... 10
3.2.2 Подсистема администрирования и настройки................................................................................................................................. 10
3.2.3 Подсистема ввода и хранения регламентов предоставления услуг........................................................................................ 14
3.2.4 Экспертная подсистема.............................................................................................................................................................................. 23
3.2.5 Подсистема автоматизированного исполнения регламентов предоставления услуг...................................................... 25
3.2.6 Подсистема электронного архива......................................................................................................................................................... 41
3.2.7 Подсистема интеграции с ЕСИА.............................................................................................................................................................. 44
3.2.8 Подсистема интеграции с ИАС МКГУ.................................................................................................................................................... 46
3.2.9 Подсистема интеграции с ЕПГУ.............................................................................................................................................................. 47
3.2.10 Подсистема интеграции с ГИС ГМП.................................................................................................................................................... 47
3.2.11 Подсистема оповещения......................................................................................................................................................................... 48
3.2.12 Подсистема анализа и статистики....................................................................................................................................................... 48
3.2.13 Подсистема управления отношениями с поставщиками услуг, предоставляемых в ЦОУ............................................ 49
3.2.14 Подсистема взаимодействия с общероссийским реестром услуг и поставщиков услуг,
предоставляемых в ЦОУ........................................................................................................................................................................................ 53
3.2.15 Подсистема взаимодействия с АИС УМФЦ...................................................................................................................................... 53
3.2.16 Подсистема интеграции с ФРГУ........................................................................................................................................................... 53
3.3.1 Требования к математическому обеспечению................................................................................................................................. 55
3.3.2 Требования к информационному обеспечению.............................................................................................................................. 55
3.3.3 Требования к лингвистическому обеспечению................................................................................................................................ 55
3.3.4 Требования к программному обеспечению....................................................................................................................................... 55
3.3.5 Требования к техническому обеспечению......................................................................................................................................... 55
3.3.6 Требования к метрологическому обеспечению............................................................................................................................... 56
3.3.7 Требования к организационному обеспечению............................................................................................................................... 56
Т Р Е Б О В А Н И Я К СО С ТА В У И СОД Е РЖА Н И Ю РА Б ОТ П О П ОД ГОТО В К Е О Б Ъ Е КТА А ВТО М АТ И З А Ц И И
К В В ОДУ С И С Т Е М Ы В Д Е Й С Т В И Е...............................................................................................................................57
Т Р Е Б О В А Н И Я К ДО КУ М Е Н Т И РО В А Н И Ю..................................................................................................................59

2
СПИСОК СОКРАЩЕНИЙ

Сокращение Расшифровка сокращения


АИС Автоматизированная информационная система
АИС ЦОУ Автоматизированная информационная система, используемая в ЦОУ
АРМ Автоматизированное рабочее место
БД База данных
Государственная информационная система о государственных и муниципальных плате-
ГИС ГМП
жах
ЕПГУ Единый портал государственных и муниципальных услуг (функций)
Единая система идентификации и аутентификации в инфраструктуре, обеспечивающей
информационно-технологическое взаимодействие информационных систем, исполь-
ЕСИА
зуемых для предоставления государственных и муниципальных услуг в электронной
форме
ЗИП Запасные изделия и приборы
ИАС МКГУ Информационно-аналитическая система мониторинга качества государственных услуг
ИС Информационная система
Государственная информационная система мониторинга предоставления государствен-
ИС МДМ
ных и муниципальных услуг на базе МФЦ
Минкомсвязи России Министерство связи и массовых коммуникаций Российской Федерации
Минэкономразвития России Министерство экономического развития Российской Федерации
МФЦ Многофункциональный центр
НСД Несанкционированный доступ
ОКОГУ Общероссийский классификатор органов государственной власти и управления
Общероссийский реестр услуг и поставщиков услуг, оказываемых субъектам малого
ОРУП
предпринимательства
ОС Операционная система
ПО Программное обеспечение
РФ Российская Федерация
СМЭВ Система межведомственного электронного взаимодействия
СУБД Система управления базами данных
ТС Техническое средство
УМФЦ Уполномоченный многофункциональный центр
ФРГУ Федеральный реестр государственных и муниципальных услуг (функций)
ЦОД центр обработки данных
ЦОУ Центр (центры) оказания услуг
ЭП Электронная подпись
HTTP Hypertext Transfer Protocol – протокол передачи гипертекстовых файлов
HyperText Transfer Protocol Secure –расширение протокола HTTP с поддержкой шифро-
HTTPS
вания в целях повышения безопасности
Набор сетевых протоколов передачи данных, используемых в сетях, включая сеть
TCP/IP
Интернет
doc, docx Файл формата MS Word

3
1 НАЗНАЧЕНИЕ И ЦЕЛИ СОЗДАНИЯ СИСТЕМЫ

1.1 НАЗНАЧЕНИЕ СИСТЕМЫ 1.2 ЦЕЛИ СОЗДАНИЯ СИСТЕМЫ

АИС ЦОУ предназначена для автоматизации процессов АИС ЦОУ создается в следующих целях:
оказания государственных и муниципальных услуг, а также
услуг, необходимых для начала осуществления и развития —— Построение автоматизированных процессов
предпринимательской деятельности, предоставление которых оказания услуг в соответствии с назначени-
осуществляется в центрах оказания услуг. ем системы.

—— Обеспечение требуемого качества процессов


оказания услуг.

—— Снижение требований к квалификации пер-


сонала ЦОУ, задействованного в процессах
оказания услуг.

—— Обеспечение автоматизированного формиро-


вания аналитической отчетности.

4
2 ХАРАКТЕРИСТИКА ОБЪЕКТОВ
АВТОМАТИЗАЦИИ

Объектами автоматизации являются процессы оказания 5) Процессы электронного обмена с электронными серви-
государственных и муниципальных услуг, а также услуг, сами органов государственной власти, органов местного
необходимых для начала осуществления и развития пред- самоуправления, оказывающих государственные и муни-
принимательской деятельности, предоставление которых ципальные услуги в электронном виде.
осуществляется в центрах оказания услуг.
6) Взаимодействие с поставщиками негосударственных
Процессы оказания услуг: услуг, необходимых для начала осуществления и развития
предпринимательской деятельности, в том числе процессы
1) Формирование и ведение реестра услуг, предоставление регистрации поставщиков, управления взаимоотношения-
которых осуществляется в центрах оказания услуг. ми с поставщиками, формирования, учета и квитирования
обязательств по оплате услуг поставщиков.
2) Настройка процессов оказания услуг, предоставление
которых осуществляется в центрах оказания услуг. 7) Ведение справочников и классификаторов, используемых
при функционировании АИС ЦОУ.
3) Взаимодействие с заявителями, обращающимися в центры
оказания услуг, в том числе процессы приема заявлений 8) Формирование статистической и аналитической
на оказание услуг, процессы оказания услуг, процессы фор- отчетности.
мирования, учета и квитирования обязательств заявителей
по оплате услуг. 9) Процессы администрирования АИС ЦОУ: ведение учетных
записей пользователей, предоставление и разграничение
4) Взаимодействие с многофункциональными центрами доступа к разделам и ресурсам АИС ЦОУ.
предоставления государственных и муниципальных услуг.

5
3 ТРЕБОВАНИЯ К СИСТЕМЕ

3.1 ТРЕБОВАНИЯ К СИСТЕМЕ В ЦЕЛОМ Штатный режим является основным режимом функ-
ционирования Системы. В этом режиме должна быть
3.1.1 Требования к структуре и функционирова- обеспечена возможность доступа пользователей
нию системы к Системе круглосуточно 7 дней в неделю для всех
пользователей с необходимыми технологическими
Разрабатываемая система должна быть централизо- перерывами на обслуживание.
ванной. Допускается централизация системы на уровне
организации, на базе которой функционирует ЦОУ, Система переходит в аварийный режим при воз-
либо на уровне организации и субъекта Российской никновении нештатной ситуации и невозможно-
Федерации, в котором на базе данной организации сти штатной работы. В случае перехода Системы
функционирует ЦОУ. Требование централизации обу- в аварийный режим, обслуживающему персоналу
словлено следующим: необходимо перевести Систему в сервисный режим
в соответствии с инструкциями, которые должны
—— необходимостью обеспечить прием запросов быть изложены в эксплуатационной документации.
заявителей об оказании услуг и получение за-
явителем результата оказания услуги в любом Функционирование Системы при отказах и сбоях
подразделении ЦОУ по выбору заявителя, в том серверного общесистемного и специального про-
числе прием запроса и получение результата граммного обеспечения и оборудования, в том числе
в разных подразделениях; структурных узлов Системы, не предусматривается.

—— необходимостью взаимодействия АИС ЦОУ В сервисном режиме Система должна обеспечивать


с другими централизованными информацион- возможность проведения следующих работ:
ными системами: АИС УМФЦ, СМЭВ, ГИС ГМП;
—— техническое обслуживание;
—— необходимостью получения единой отчетности
о функционировании ЦОУ. —— модернизацию аппаратно-программного
комплекса;
Система должна быть построена по многоуровневой
архитектуре с выделением уровней хранения данных —— устранение аварийных ситуаций.
(сервер базы данных), уровня приложений (сервер
приложений), уровня клиента. В качестве рабочих мест 3.1.1.3 Требования по диагностированию системы
пользователей может использоваться веб-браузер, а для
мобильных рабочих мест — клиентское приложение, Для целей диагностирования прикладного ПО
устанавливаемое на портативный или планшетный Система должна обеспечивать протоколирование
компьютер. событий. Для диагностирования состояния систем-
ного ПО и технических средств системы должны
3.1.1.1 Требования к способам и средствам связи использоваться существующие корпоративные
для информационного обмена между компонен- средства мониторинга и управления Заказчика,
тами системы обеспечивающие сбор и анализ данных о работе
оборудования и операционных систем серверов си-
Взаимодействие между уровнем хранения данных стемы и объектов ИТ-инфраструктуры, необходимых
(реализованным с использованием СУБД) и уровнем для доступа пользователей к системе.
обработки данных в рамках компоненты обработки
и хранения информации, должно выполняться с ис- 3.1.1.4 Перспективы развития, модерниза-
пользованием сетевых протоколов TCP/IP. ции системы

Взаимодействие между клиентским приложением Проектные решения, применяемые в Системе, долж-


(веб-браузером) и веб-сервером должно выпол- ны обеспечивать возможность дальнейшего разви-
няться по стандартным протоколам HTTP/HTTPS. тия и модернизации, расширение функциональных
возможностей за счет дополнительной разработки
3.1.1.2 Требования к режимам функционирова- и внедрения новых модулей.
ния системы
Проектные решения, применяемые в Системе, долж-
Для АИС ЦОУ устанавливаются следующие режимы ны обеспечивать возможность расширения набора
функционирования: вариантов реализации клиентской части (в том
числе, за счет реализации в виде приложений для
—— штатный режим функционирования; мобильных операционных систем, чат-ботов и т. д.).

—— аварийный режим функционирования; Проектные решения, применяемые в Системе,


должны обеспечивать возможности роста произ-
—— сервисный режим функционирования. водительности системы и объема хранимых дан-
ных без необходимости изменения ПО системы,

6
за счет масштабирования комплекса технических —— Специалист по обработке документов;
средств системы.
—— Специалист по настройке процессов оказа-
Требования к функциям системы, характеристики ния услуг;
которых определяются нормативными актами (ло-
кальными и федеральными), в перспективе могут —— Администратор системы.
изменяться в связи с изменением нормативной
базы. Программное обеспечение системы должно Пользователями портала поставщиков негосудар-
предоставлять возможности параметризации и гиб- ственных услуг являются:
кой настройки алгоритмов и функций, зависящих от
требований нормативных актов, или возможности —— Неавторизованный пользователь портала
быстрой модернизации ПО в связи с изменением
нормативной базы. —— Авторизованный пользователь — поставщик
негосударственных услуг
3.1.2 Требования к численности и квалификации пер-
сонала системы и режиму его работы —— Администратор портала.

Численность и необходимая квалификация эксплуата- 3.1.3 Показатели назначения


ционного персонала должна быть определена на стадии
«Техническое проектирование» с учетом требования АИС ЦОУ должна обеспечивать ввод информации в ко-
минимизации численности и возможности совмещения личестве не менее 10 000 дел в месяц.
функций существующего персонала.
АИЦ ЦОУ должна обеспечивать возможность хранения
Эксплуатационный персонал системы, обеспечиваю- и оперативного доступа ко всем данным за период
щий работу серверных компонентов системы, должен эксплуатации не менее 10 лет.
работать в одну смену по рабочим дням.
Система должна обеспечивать возможность одно-
Эксплуатационный персонал системы, обеспечивающий временной работы не менее 1000 авторизованных
работу рабочих станций пользователей системы и ИТ- пользователей, при этом время отклика системы при
инфраструктуры Заказчика, необходимой для доступа открытии экранных форм не должно превышать 10 сек,
пользователей к системе, должен работать в режиме, со- за исключением времени первичного запуска клиент-
ответствующем режиму работы пользователей системы. ского компонента, времени сканирования и печати,
времени передачи файлов на сервер, времени формиро-
Основными обязанностями эксплуатационного персо- вания печатных форм, времени формирования отчетов.
нала являются: Количество одновременно работающих пользователей
определено на основании статистики количества окон
—— модернизация, настройка и мониторинг рабо- в МФЦ в 2017 году и может быть уточнено на стадии
тоспособности комплекса технических средств «Техническое проектирование».
(серверов, рабочих станций);
АИС ЦОУ должна предусматривать возможность мас-
—— установка, модернизация, настройка и монито- штабирования по производительности (в том числе —
ринг работоспособности системного программ- увеличения числа пользователей сверх расчетного
ного обеспечения (операционных систем, СУБД); значения) без модификации ее программного обеспе-
чения путем модернизации используемого комплекса
—— установка, настройка и мониторинг прикладного технических средств.
программного обеспечения;
3.1.4 Требования к надежности
—— ведение учетных записей пользовате-
лей системы; Архитектурные решения и надежность компонентов
системы должны обеспечивать уровень доступность
—— выполнение операций резервного копирова- системы не менее 0,997 (под доступностью понима-
ния данных; ется состояние ресурсов информационной системы,
при котором субъекты, имеющие права доступа, могут
—— восстановление работоспособности системы реализовать их беспрепятственно).
в случае возникновения сбоев в её работе.
Выход из строя одного или нескольких клиентских при-
3.1.2.1 Пользователи системы ложений не должен приводить к выходу из строя сервер-
ной части АИС ЦОУ или других клиентских компонент.
Основными пользователями системы являются:

—— Оператор по обслуживанию заявителей;

7
Импульсные помехи, сбои или прекращение электро- —— взаимодействие пользователей с прикладным
питания не должны приводить к потере данных, за ис- программным обеспечением, входящим в состав
ключением данных незавершенных транзакций. системы, должно осуществляться посредством
визуального графического интерфейса (GUI);
Некорректные действия пользователей (за исключением
администраторов) не должны приводить к возникно- —— интерфейс должен быть полностью русифи-
вению аварийной ситуации. цирован (за исключением сообщений обще-
системного ПО, не подлежащих русификации);
Информация, хранящаяся, обрабатываемая и передава-
емая по каналам связи в АИС ЦОУ является конфиден- —— интерфейс не должен быть перегружен графи-
циальной и содержит персональные данные. ческими элементами и должен обеспечивать
быстрое отображение экранных форм;
Хранение сведений об истории обращений заявителей
должно осуществляться в соответствии с требованиями —— пользователь должен иметь возможность ука-
законодательства Российской Федерации. зания критериев поиска и выбора информации
без привлечения языков программирования;
Среднее время до восстановления (интервал времени
от момента отказа (обнаружения отказа) изделия до мо- —— элементы интерфейса (кнопки, ссылки) должны
мента его восстановления) в случае отказа единицы иметь названия, позволяющие пользователю
оборудования должно быть не более 24 часов (при однозначно интерпретировать выполняемые
наличии ЗИП и без учета времени доставки исправных ими действия;
запасных частей).
—— должно быть обеспечено визуальное различие
3.1.5 Требования безопасности между рабочими и заблокированными (в слу-
чае невозможности выполнения какого-либо
Система электропитания должна обеспечивать защитное действия) элементами интерфейса;
отключение при перегрузках и коротких замыканиях
в цепях нагрузки, а также аварийное ручное отключение. —— интерфейс должен предоставлять пользователю
Все внешние элементы технических средств системы, информацию о структуре экранных форм и/или
находящиеся под напряжением, должны иметь защи- других средств организации пользовательского
ту от случайного прикосновения, а сами технические интерфейса;
средства иметь зануление или защитное заземление
в соответствии с ГОСТ 12.1.030и ПУЭ. —— экранные формы должны быть рассчитаны
на отображение в видеорежиме 1920х1080
Общие требования пожарной безопасности должны и цветовой палитры HighColor (32 бит);
соответствовать нормам на бытовое электрообору-
дование. В случае возгорания не должно выделяться —— интерфейс должен быть рассчитан на преиму-
ядовитых газов и дымов. После снятия электропитания щественное использование манипулятора типа
должно быть допустимо применение любых средств «мышь», то есть управление системой должно
пожаротушения. осуществляется с помощью набора экранных
меню, кнопок, значков и т. п. элементов. Клави-
Факторы, оказывающие вредные воздействия на здо- атурный режим ввода должен использоваться
ровье со стороны всех элементов системы (в том чис- главным образом при заполнении и/или ре-
ле инфракрасное, ультрафиолетовое, рентгеновское дактировании текстовых и числовых полей
и электромагнитное излучения, вибрация, шум, электро- экранных форм.
статические поля, ультразвук строчной частоты и т. д.),
не должны превышать действующих норм (СанПиН 3.1.7 Требования к защите информации от несанкци-
2.2.2./2.4.1340–03 от 03.06.2003). онированного доступа

Помещение, в котором находится оборудование Доступ ко всем подсистемам должен предоставлять-


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

8
—— разграничение доступа пользователей на уровне проекта на создание Системы. При просмотре выходных
задач и информационных массивов; файлов печатных форм и отчетов, сформированных
в Системе, пользователь должен иметь возможность
—— использование «слепых» паролей (при наборе использовать офисные приложения.
пароля его символы не показываются на экране
либо заменяются одним типом символов; коли- Программное обеспечение Системы должно быть сво-
чество символов не соответствует длине пароля); бодным от возможности предъявления основанных
на промышленной, интеллектуальной или другой соб-
—— автоматическая блокировка сессий пользо- ственности любых прав и притязаний третьих лиц.
вателей и приложений по заранее заданным
временам отсутствия активности со стороны Программные изделия (компоненты Системы) должны
пользователей и приложений. обладать патентной чистотой на территории России.

3.1.8 Требования по сохранности информации Должны соблюдаться положения нормативных правовых


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

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


а также возможности восстановления данных после у сторонних фирм и предприятий, должны сопрово-
аварий программное обеспечение Системы должно ждаться документацией, подтверждающей правомоч-
предусматривать: ность этих организаций поставлять данную продукцию
и сопровождаться лицензионным соглашением.
—— контроль целостности данных на уровне СУБД;
При поставке программного обеспечения для комплек-
—— сохранение целостности данных при нештат- тации системы должны быть выполнены требования
ном завершении программы в случае отказа гражданского законодательства РФ.
рабочей станции;
3.1.10 Требования по стандартизации и унификации
—— сохранение работоспособности программно-
го обеспечения при некорректных действиях —— цветовое оформление интерфейса должно быть
пользователя; выполнено в едином стиле;

—— резервное копирование информации на внеш- —— экранные формы пользовательского интерфейса


ние электронные носители с возможностью должны быть выполнены в едином графиче-
оперативного восстановления. ском дизайне, с одинаковым расположением
основных элементов управления и навигации;
Резервные копии данных системы не должны храниться
в том же помещении, а котором расположены аппарат- —— для обозначения сходных операций должны
ные средства системы. использоваться сходные графические значки,
кнопки и другие управляющие (навигационные)
Резервное копирование должно производиться соглас- элементы;
но установленному графику резервного копирования.
—— термины, используемые для обозначения типо-
Расписание и технические возможности средств резерв- вых операций (добавление информационной
ного копирования информации должны обеспечивать сущности, редактирование поля данных), а также
глубину хранения не менее одной недели с возмож- последовательности действий пользователя при
ностью восстановления данных за любой день это- их выполнении, должны быть унифицированы;
го периода.
—— внешнее поведение сходных элементов интер-
3.1.9 Требования к патентной чистоте фейса (реакция на наведение указателя «мыши»,
переключение фокуса, нажатие кнопки) должны
Установка и эксплуатация Системы не должны предъяв- реализовываться одинаково для однотипных
лять дополнительных требований к покупке лицензий элементов;
на программное обеспечение сторонних производите-
лей, кроме офисных приложений, ПО защиты каналов —— все надписи экранных форм, а также сообщения,
связей, антивирусных программ и программного обе- выдаваемые пользователю (кроме системных
спечения, явно указанного в документах технического сообщений), должны быть на русском языке.

9
3 . 2 Т Р Е Б О В А Н И Я К ФУ Н К Ц И Я М ( З АД АЧ А М ) , 7) Подсистема интеграции с ИАС МКГУ должна обеспе-
ВЫПОЛНЯЕМЫМ СИСТЕМОЙ чивать сбор и отправку оценок качества предоставления
государственных услуг, а также сбор и отправку фактов
3.2.1 Перечень подсистем, их назначения и основные предоставления государственных услуг в ЦОУ.
характеристики
8) Подсистема интеграции с ЕПГУ должна обеспечивать
АИС ЦОУ должна включать в себя следующие подсистемы: передачу в личный кабинет заявителя на ЕПГУ сведений
о создании в ЦОУ заявления, а также сведений об из-
1) Подсистема администрирования и настройки должна менении статуса созданного заявления.
обеспечивать управление списком подразделений ЦОУ,
списком ведомств, с которыми взаимодействует ЦОУ, 9) Подсистема интеграции с ГИС ГМП должна обеспе-
настройку взаимосвязей между подразделениями ЦОУ чивать запрос сведений о начислениях и платежах
и ведомствами, управление пользователями, ролями заявителя из ГИС ГМП.
и правами, настройку рабочего календаря.
10) Подсистема оповещения должна обеспечивать
2) Подсистема ввода и хранения регламентов пре- автоматизированное оповещение заявителей о ходе
доставления услуг должна обеспечивать управление и результатах оказания услуг.
списком услуг, создание и изменение услуг, настрой-
ку процессов оказания услуг, настройку жизненных 11) Подсистема анализа и статистики должна обеспечи-
ситуаций, настройку типов электронных документов, вать формирование отчетности об оказании услуг в ЦОУ.
используемых в процессах оказания услуг, управление
справочниками, настройку шаблонов печатных форм 12) Подсистема управления отношениями с постав-
документов. щиками услуг, предоставляемых в ЦОУ должна обе-
спечивать ведение реестра негосударственных услуг,
3) Экспертная подсистема должна обеспечивать на- предоставляемых в ЦОУ, ведение реестра поставщиков
стройку вопросов экспертной системы с вариантами указанных услуг, учет расчетов с заявителями по негосу-
ответов на каждый вопрос, настройку матрицы соот- дарственным услугам и учет расчетов с поставщиками
ветствия между ответами на вопросы и вариантами негосударственных услуг.
оказания услуг, построение дерева анкеты услуги на ос-
новании настроенных связей, а также применение на- 13) Подсистема взаимодействия с общероссийским
строенного дерева при консультировании по услуге реестром услуг и поставщиков услуг, предоставляемых
и по жизненной ситуации. в ЦОУ должна обеспечивать передачу в общероссийский
реестр услуг и поставщиков услуг, предоставляемых
4) Подсистема автоматизированного исполнения ре- в ЦОУ сведений о негосударственных услугах, пре-
гламентов предоставления услуг должна обеспечивать доставляемых в ЦОУ, о поставщиках указанных услуг,
исполнение процессов оказания услуг, настроенных а также статистической информации о фактах оказания
с помощью подсистемы ввода и хранения регламен- негосударственных услуг в ЦОУ.
тов предоставления услуг, в частности: регистрацию
заявителей, обращающихся за оказанием услуг, прием 14) Подсистема взаимодействия с АИС УМФЦ должна
документов заявителей для оказания услуг, выдачу обеспечивать информационный обмен между АИС ЦОУ
заявителям результатов оказания услуг, предоставле- и АИС УМФЦ в процессе оказания государственных
ние заявителям информации о ходе оказания услуг, и муниципальных услуг, а также передачу статистической
формирование заказов в ведомства, прием результатов информации об оказании государственных и муници-
заказов из ведомства, исполнение запросов в СМЭВ, пальных услуг из АИС ЦОУ в АИС УМФЦ.
исполнение этапов, связанных с обработкой документов
непосредственно в ЦОУ. 15) Подсистема интеграции с ФРГУ должна обеспечивать
импорт сведений об услугах, органах власти, техноло-
5) Подсистема электронного архива должна обеспечи- гических схемах оказания услуг из ФРГУ.
вать хранение электронного архива дел об оказании
услуг, созданных в ЦОУ, поиск дел в архиве по раз- 3.2.2 Подсистема администрирования и настройки
личным параметрам, просмотр информации о делах,
а также настройку структуры электронного архива в со- 3.2.2.1 Управление иерархическим списком
ответствии со структурой неэлектронного архива дел. подразделений

6) Подсистема интеграции с ЕСИА должна обеспечивать 1) В системе должна вестись иерархическая струк-
исполнение процессов управления учетной записью тура подразделений ЦОУ.
заявителя в ЕСИА, включая взаимодействие с элек-
тронным сервисом ЕСИА в СМЭВ. 2) Список подразделений ЦОУ должен выводиться
с учетом иерархии.

10
3) В списке подразделений должны быть доступны 3) При настройке динамических полей должна
следующие функции: предоставляться определить следующие пара-
метры поля:
—— создание подразделения;
—— название поля;
—— изменение подразделения;
—— тип поля — строка, дата, целое число, адрес;
—— удаление подразделения;
—— обязательность заполнения поля.
—— логическое удаление подразделения;
3.2.2.1.3 Настройка списка реквизитов
—— восстановление логически удаленного под- подразделения
разделения;
1) Для подразделения должна быть доступна
—— настройка динамических полей объекта. возможность настроить реквизиты подразде-
ления для осуществления оплаты услуг ЦОУ.
4) Должна быть доступна возможность настройки
взаимосвязей между подразделениями и ведомства- 2) В списке реквизитов должны быть доступны
ми, с которыми взаимодействует каждое отдельное следующие функции:
подразделение ЦОУ.
—— добавить набор реквизитов реквизиты, действу-
3.2.2.1.1 Создание, изменение подразделения ющий с заданной даты;

1) При создании, изменении подразделе- —— изменить реквизиты;


ния должны заполняться следующие данные
о подразделении: —— удалить реквизиты.

—— тип подразделения — головное или дочернее; 3) При создании набора реквизитов долж-
на быть возможность указать следующие
—— родительское подразделение — указывается параметры:
если создается, изменяется дочернее под-
разделение; —— дата начала действия реквизитов;

—— название; —— банк получателя;

—— ФИО руководителя; —— счет;

—— ОКАТО; —— БИК;

—— идентификатор подразделения в МКГУ; —— ИНН;

—— идентификатор подразделения в МДМ; —— КПП;

—— код подразделения в ЕСИА; —— ОКТМО.

—— начальный номер дела. 3.2.2.2 Управление иерархическим спи-


ском ведомств
2) Должно быть доступно сохранение внесенных
изменений. 1) В системе должен вестись иерархический список
ведомств, услуги которых предоставляет ЦОУ.
3.2.2.1.2 Настройка динамических по-
лей объекта 2) Должна быть доступна возможность группировки
ведомств таким образом, чтобы не требовалась на-
1) Должна быть доступна возможность расши- стройка отдельных услуг для каждого структурного
рить набор полей, заполняемых при создании, подразделения ведомства.
изменении подразделения.
3) В списке ведомств должны быть доступны сле-
2) Должна предоставляться возможность соз- дующие функции:
дания дополнительных динамический полей,
их изменения и удаления. —— создание ведомства;

11
—— изменение ведомства; возможность создать, изменить, удалить группу
реквизитов.
—— удаление ведомства;
2) Внутри группы реквизитов должна быть до-
—— логическое удаление ведомства; ступна возможность настроить набор реквизи-
тов, действующих в разные периоды.
—— восстановление логически удаленного
ведомства; 3) При работе с набором реквизитов должны
быть доступны следующие функции:
—— настройка динамических полей объекта.
—— создать реквизиты;
4) Должна быть доступна возможность настройки
групп реквизитов ведомства, используемых для —— создать реквизиты на основе уже существующих;
оплаты услуг, предоставляемых ведомством.
—— изменить реквизиты;
5) Должна быть доступна возможность настройки
взаимосвязей между ведомством и подразделени- —— удалить реквизиты.
ями ЦОУ, с которыми взаимодействует каждое от-
дельное структурное подразделение органа власти. 4) При создании набора реквизитов долж-
на быть возможность указать следующие
3.2.2.2.1 Создание, изменение ведомства параметры:

1) При создании, изменении подразделе- —— дата начала действия набора реквизитов;


ния должны заполняться следующие данные
о подразделении: —— банк получателя;

—— название; —— счет;

—— головное ведомство (группировка ведомств); —— БИК;

—— идентификатор ФРГУ; —— ИНН;

—— ФИО руководителя; —— КПП;

—— адрес; —— ОКТМО.

—— телефон; 5) Внутри одной группы реквизитов не должно


допускаться создание нескольких наборов рек-
—— электронная почта; визитов с одинаковой датой начала действия.

—— адрес сайта ведомства в сети Интернет; 3.2.2.3 Настройка взаимосвязей между ведомства-
ми и подразделениями
—— ОГРН;
1) В системе должна быть реализована возможность
—— ИНН; указать с какими структурными подразделения-
ми ведомств взаимодействует каждое подразде-
—— код ОКОГУ; ление ЦОУ.

—— шаблон описи пакета заказов, передаваемых 2) Среди структурных подразделений ведомств,


из ЦОУ в ведомство. которые отмечены как ведомства, с которыми вза-
имодействует подразделение ЦОУ, должна быть
2) Должно быть доступно сохранение внесенных возможность отметить основное структурное под-
изменений. разделение ведомства с которым осуществляется
основное взаимодействие подразделения ЦОУ
3.2.2.2.2 Настройка групп реквизитов в рамках оказания услуг этого ведомства.
ведомства
3.2.2.4 Управление пользователями
1) В системе должна быть реализована возмож-
ность настройки групп платежных реквизитов 1) В системе должен вестись список пользователей
ведомства, используемых при оплате различ- подразделений ЦОУ.
ных услуг ведомства. Должна быть доступна

12
2) В списке пользователей должны быть доступны —— пароль для входа в систему — должна выпол-
следующие функции: няться проверка сложности пароля, не должен
допускаться ввод слишком простых паролей;
—— создание пользователя;
—— ФИО пользователя;
—— изменение пользователя;
—— должность;
—— удаление пользователя;
—— адрес электронной почты;
—— логическое удаление пользователя;
—— секретный вопрос и ответ на него;
—— восстановление логически удаленного
пользователя; —— признак, что пользователь может выполнять
несколько входов в систему одновременно (до-
—— п р и н у д и т ел ь н о е з а в е р ш е н и е се сс и и ступна функция мультивхода);
пользователя;
—— сведения об идентификационном документе
—— изменение подразделения, к которому относится пользователя;
пользователь;
—— СНИЛС пользователя.
—— изменение пароля пользователя;
2) Должна быть доступна возможность сохра-
—— сброс пароля пользователя; нить внесенные изменения.

—— изменение контрольного вопроса; 3) Должна быть доступна возможность назна-


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

3) В списке пользователей должна быть доступна 4) Должна быть доступна возможность снять
фильтрация списка по параметрам: или добавить пользователю отдельные права,
не определенные ролями, назначенными поль-
—— по подразделению, к которому относится зователю. При этом должен визуализироваться
пользователь; полный набор прав пользователя, назначенный
как ролями, так и отдельно.
—— по признаку логического удаления пользователя.
3.2.2.4.2 Настройка ролей и прав доступа
4) При просмотре списка пользователей должны
визуализироваться параметры: 1) Назначение прав и ролей пользователям
должно осуществляться пользователем с ролью
—— признак, что в текущий момент пользователь «Администратор системы».
вошел в систему;
2) В системе должен быть реализован набор
—— признак, что заявитель блокирован; прав на действия пользователя, включающий
следующие виды прав:
—— признак, что заявитель логически удален;
—— Права на доступ к разделам системы
—— признак, что пользователь может совершать
несколько входов в систему одновременно (до- —— Права на выполнение действий с объекта-
ступна функция мультивхода). ми системы (создание, изменение, удаление,
просмотр).
3.2.2.4.1 Создание, изменение пользователя
—— Права на выполнение сценариев обслуживания
1) При создании, изменении пользователя
должна предоставляться возможность указать —— Права на обработку задач по типам задач
следующие параметры пользователя:
—— Права на специфические действия, в зависи-
—— логин для входа в систему; мости от раздела системы

—— Права на формирование отчетов

13
—— Права на управление пользователями 3) Также в системе должна быть возможность ука-
зать исключения из стандартной рабочей недели:
3) В системе должна обеспечиваться возмож- на определенную дату пометить нерабочий день как
ность создания произвольного количества ро- рабочий и пометить рабочий день как нерабочий.
лей. Должна быть возможность указать название
роли и ее описание. Должна быть возможность 3.2.3 Подсистема ввода и хранения регламентов пре-
указать набор прав, которым обладает роль. доставления услуг

4) Должна быть возможность назначения поль- 3.2.3.1 Управление списком услуг


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

6) Должна быть возможность создания, из- 3) Должна обеспечиваться группировка списка услуг
менения, удаления ролей как на уровне всей по набору параметров:
системы, так и на уровне определенного под-
разделения согласно иерархическому списку —— жизненная ситуация;
подразделений.
—— категория,
7) Роли, созданные на уровне всей системы,
должны быть доступны для назначения любому —— ведомство;
пользователю системы.
—— подразделение, которое оказывает услугу.
8) Роли, созданные на уровне определенного
подразделения, должны быть доступны для 4) В списке услуг должны обеспечиваться следую-
назначения пользователям во всех подразделе- щие функции:
ниях, подчиненных подразделению, на уровне
которого они созданы, в соответствии с иерар- —— создание услуги;
хией, определенной в списке подразделений.
—— создание информационной услуги;
9) Права, предоставляемые пользователю, долж-
ны действовать в пределах подразделения, —— создание услуги на основе другой услуги;
к которому относится пользователь. При этом
должна обеспечиваться возможность предо- —— изменение ранее созданной услуги;
ставления прав на всю систему путем отнесения
пользователя к головному подразделению в ие- —— со з д а н и е ж и з н е н н о й с и т у а ц и и ( б и з -
рархическом списке подразделений. Данное нес-ситуации);
требование распространяется, в том числе,
на предоставление прав по администрирова- —— изменение жизненной ситуации (биз-
нию системы. нес-ситуации).

3.2.2.5 Настройка рабочего календаря 3.2.3.2 Создание и изменение услуг

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

14
3.2.3.2.1 Ввод основных сведений об услуге 3.2.3.2.2 Настройка списка вариантов услуги
и списка маршрутов вариантов услуги
1) Должен обеспечиваться ввод или изменение
основных сведений об услуге: 1) Должна обеспечиваться настройка списка
вариантов услуги:
—— название;
—— добавление варианта услуги,
—— название услуги в ФРГУ;
—— изменение названия варианта услуги,
—— идентификатор цели обращения в ФРГУ;
—— активирование и деактивирование вариан-
—— уникальный номер услуги в ОРУП; та услуги,

—— список подразделений, которые оказывают —— удаление варианта услуги.


данную услугу;
2) Должны быть доступны групповые действия
—— где допускается выдача результата оказания над вариантами услуги:
услуги заявителю (только в ЦОУ; только в ведом-
стве; либо в ЦОУ, либо в ведомстве по выбору —— групповая активация или деактивация
заявителя); вариантов;

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


оказана услуга (физическое лицо, юридиче- обращения в ФРГУ и идентификаторов услуг
ское лицо); в ИС МДМ выбранным вариантам.

—— тип услуги (федеральная, региональная, муни- 3) По деактивированному варианту услуги дол-


ципальная, негосударственная, сервисная, иная); жен быть недоступен прием документов.

—— категория услуги; 4) Активирование варианта услуги должно быть


доступно только для вариантов, имеющих ак-
—— ведомство, предоставляющее услугу; тивный маршрут услуги.

—— список жизненных ситуаций (бизнес-ситуаций), 5) Должно обеспечиваться создание марш-


в которых может быть предоставлена услуга; рутов оказания услуги для каждого вариан-
та услуги. Маршрут должен включать в себя
—— признак, что услугу оказывает ЦОУ; перечень этапов, из которых состоит процесс
оказания услуги.
—— признак, что за оказание услуги взимается плата;
6) Для каждого маршрута должно указывать-
—— признак, что допускается обращение нескольких ся наименование и дата начала действия.
заявителей по одному делу; Активным считается маршрут, дата начала
действия которого максимальна среди марш-
—— тип шаблона описи пакета заказов, передава- рутов данного варианта услуги и не превышает
емых в ведомство; текущую дату.

—— ссылка на страницу услуги на ЕПГУ; 7) Должна быть возможность создать маршрут,


дата начала которого превышает текущую дату.
—— ссылка на страницу услуги на РПГУ; Такой маршрут находится в состоянии ожидания
наступления даты начала. После наступления
—— ссылка на страницу услуги в базе знаний; даты начала маршрут автоматически становит-
ся активным — созданные по варианту услуги
—— сведения о документах, регламентирующих дела будут осуществлять движение по этому
оказание услуги; маршруту, при этом дела, созданные ранее,
продолжают движение по маршруту, действо-
2) Должно обеспечиваться сохранение введен- вавшему на момент их создания.
ных сведений об услуге.
8) Должна быть возможность удалить марш-
3) Должно обеспечиваться удаление выбран- рут, изменить его название и дату начала (два
ной услуги. маршрута с одинаковой датой начала создавать
не разрешается).

15
9) Должна быть возможность создать новый 7) Не допускается редактирование этапов ак-
маршрут на основе одного из ранее настроен- тивного маршрута активного варианта услуги.
ных маршрутов, в том числе на основе марш-
рутов, принадлежащих другим услугам. 8) Должна быть возможность удалить один или
несколько этапов типа «Формирование зака-
3.2.3.2.3 Настройка маршрута оказания услуги за в ведомство в бумажном виде и прием его
результатов», «Формирование заказа в СМЭВ»,
1) При выборе маршрута варианта услуги дол- «Рассмотрение заказа в ЦОУ».
жен выводиться древовидный перечень этапов,
ранее настроенных для маршрута. Положение 9) Если маршрут включает только этапы
этапов в древовидном перечне отражает по- «Консультирование и прием документов»
следовательность исполнения этапов маршрута. и «Выдача результатов оказания услуги»,
Для каждого этапа в списке должно указывать- то должна быть возможность удалить этап
ся, является ли он полностью настроенным или «Выдача результатов оказания услуги», при
требует завершения настройки. этом этап «Консультирование и прием доку-
ментов» автоматически заменяется на этап
2) Этапы маршрута оказания услуги должны «Консультирование».
иметь следующие типы:
10) Должна быть возможность установить
—— консультирование; последовательность исполнения этапов типа
«Формирование заказа в ведомство в бумажном
—— консультирование и прием документов виде и прием его результатов», «Формирование
от заявителя; заказа в СМЭВ», «Рассмотрение заказа в ЦОУ».
Этапы указанных типов могут выполняться по-
—— формирование заказа в ведомство в бумажном следовательно и параллельно друг другу.
виде и прием его результатов;
11) Не должно быть возможности изме-
—— формирование заказа в СМЭВ; нять порядок исполнения этапов типа
«Консультирование и прием документов»
—— рассмотрение заказа в ЦОУ; и «Выдача результатов оказания услуги». Этап
«Консультирование и прием документов» всегда
—— выдача результатов оказания услуги. выполняется в маршруте первым, этап «Выдача
результатов оказания услуги» — последним.
3) Вновь созданный маршрут по умолчанию
должен иметь один этап «Консультирование». 12) Полностью настроенным считается маршрут,
у которого все этапы помечены как полностью
4) В маршрут, не имеющий этапа «Выдача настроенные, и при этом удовлетворяющий
результатов оказания услуги» должна быть одному из следующих требований:
возможность добавить эта «Выдача ре-
зультатов оказания услуги», при этом этап —— маршрут состоит из одного этапа «Консуль-
«Консультирование» автоматически заме- тирование»;
няется на этап «Консультирование и прием
документов». —— маршрут состоит из этапа «Консультирование
и прием документов» и «Выдача результатов
5) Должна быть возможность добавить один оказания услуги»;
или несколько этапов типа «Формирование
заказа в ведомство в бумажном виде и при- —— маршрут состоит из этапа «Консультирование
ем его результатов», «Формирование заказа и прием документов», «Выдача результатов
в СМЭВ» и «Рассмотрение заказа в ЦОУ». При оказания услуги» и любого количества этапов
этом в маршрут автоматически добавляется «Формирование заказа в ведомство в бумажном
этап «Выдача результатов оказания услу- виде и прием его результатов», «Формирование
ги» (если он не был добавлен ранее), этап заказа в СМЭВ», «Рассмотрение заказа в ЦОУ»;
«Консультирование» автоматически заменяется
на этап «Консультирование и прием докумен- 13) Если все этапы на маршруте настроены,
тов» (если он не был заменен ранее). маршрут может стать активным, если его дата
начала максимальна среди маршрутов данного
6) Должна быть возможность открыть любой варианта услуги и не превышает текущую дату.
из этапов маршрута в режиме просмотра или
в режиме редактирования.

16
3.2.3.2.4 Настройка этапа типа личество экземпляров (копий или оригиналов)
«Консультирование» какого-либо документа. В этом случае при по-
пытке сохранения сведений об этапе, который
1) Должна обеспечиваться настройка перечня помечен как полностью настроенный, должно
документов, которые должны быть представ- выводиться сообщение со списком причин,
лены заявителем при обращении за получе- по которым настройка этапа не может считаться
нием услуги. завершенной.

2) Добавление документов в перечень долж- 9) Должна быть возможность сохранить на-


но производиться из справочника типов стройки этапа в любой момент. При этом про-
документов. исходит возврат к списку этапов на маршруте
варианта услуги.
3) При добавлении типа документа из справоч-
ника в перечень должны указываться: 10) Должна быть возможность отменить сде-
ланные настройки этапа. При этом происходит
—— количество копий и оригиналов документа, ко- возврат к списку этапов на маршруте вариан-
торые должен представить заявитель, та услуги.

—— необходимость печати документа в процессе 3.2.3.2.5 Настройка этапа типа


обслуживания заявителя (если отметка простав- «Консультирование и прием документов»
лена, то становится доступной возможность вы-
грузки, загрузки и удаления шаблона документа), 1) Настройка этапа «Консультирование и прием
документов» должна выполняться аналогично
—— обязательность представления документа, настройке этапа «Консультирование» с допол-
нительными возможностями:
—— ссылка на страницу базы знаний, хранящую
сведения о критериях качества документа, —— для документов должна быть возможность ука-
зать, требуется ли прикрепить к документам
—— комментарий. файлы-вложения (скан-копии документов);

4) Должна быть возможность изменить сведения —— для этапа должна обязательно настраиваться
о документах и удалить документы. плановая длительность этапа с указанием еди-
ниц изменения длительности (календарные дни,
5) Должна быть возможность установить поря- рабочие дни, календарный месяц);
док следования документов в списке.
—— может быть указана стоимость этапа (если для
6) Добавлять один тип документа несколько услуги отмечено, что она является платной);
раз не разрешается.
—— может быть указана необходимость электронной
7) Должна обеспечиваться настройка перечня подписи специалистом описания его действий
служебных документов, которые должны быть в системе после приема документов по дан-
подготовлены на этапе приема документов. ной услуге.
Добавление сведений о служебных документах
происходит аналогично пунктам 2–4 выше. 2) При попытке сохранения сведений об этапе,
Отличия: служебные документы не представля- который помечен как полностью настроенный,
ются заявителем, а формируются специалистом система должна дополнительно проверять, что
при обслуживании заявителя; служебные доку- указана плановая длительность этапа.
менты используются только в пределах одного
этапа маршрута оказания услуги (не переходят 3.2.3.2.6 Настройка этапа типа «Формирование
с этапа на этап); служебный документ не может заказа в ведомство в бумажном виде и прием
быть отмечен как необязательный. его результатов»

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

17
2) Должен указываться адресат (исполнитель) 10) Должна быть возможность указать стои-
заказа. Адресат выбирается из древовидного мость этапа (если для услуги отмечено, что она
справочника ведомств. является платной);

3) Пользователю должен выводиться список 11) Должна быть возможность указать необхо-
типов документов, которые составляют дело димость электронной подписи специалистом
на настраиваемом этапе. В этот перечень входят описания его действий в системе после фор-
документы, которые должны быть приняты у за- мирования заказа и после приема результа-
явителя, и документы, являющиеся результатами тов заказа.
заказов в ведомства или в СМЭВ, предшеству-
ющих текущему этапу. 12) Этап не может быть помечен как полностью
настроенный, если не выполняется хотя бы одно
4) Для каждого типа документа должно выво- из следующих требований:
диться количество оригиналов и копий, нахо-
дящихся в деле на данном этапе в соответствии —— не указано ни одного документа, который дол-
с настройками предшествующих этапов. Если жен войти в заказ
на настраиваемом этапе в деле не должно
остаться ни одного экземпляра какого-либо —— не указано ни одного документа, который может
типа документа, присутствующего на преды- являться результатом заказа
дущих этапах, то данный тип документа не вы-
водится в списке. —— не указана плановая длительность этапа

5) Должна быть возможность отметить в списке, В этом случае при попытке сохранения сведе-
какие типы документов должны войти в заказ. ний об этапе, который помечен как полностью
Для каждого отмеченного типа документа вво- настроенный, должно быть выведено сообще-
дится количество экземпляров, передаваемых ние со списком причин, по которым настройка
в ведомство в составе заказа (не больше, чем этапа не может считаться завершенной.
имеется в деле).
3.2.3.2.7 Настройка этапа типа «Формирование
6) Должна быть возможность указать, какие заказа в СМЭВ»
типы документов из числа вошедших в заказ
должны вернуться в дело от адресата. Также 1) Должна быть возможность указать, от каких
указывается, сколько экземпляров документов этапов зависит данный этап, то есть какие этапы
должно быть возвращено в дело (не больше, должны обязательно предшествовать данному
чем было отправлено в заказе). этапу (таким этапом по умолчанию всегда счи-
тается этап приема документов у заявителя).
7) Должна быть возможность указать, какие
документы могут являться результатом зака- 2) Должен указываться адресат (исполнитель)
за. Типы документов-результатов должны вы- заказа. Адресат выбирается из древовидного
бираться из справочника типов документов. справочника ведомств.
Должна быть возможность создать несколько
вариантов результата. В каждом из вариантов 3) Пользователю должен быть выведен список
может быть несколько документов. Для до- документов, которые составляют дело на настра-
кументов-результатов указываются сведения иваемом этапе (документы, которые должны
о количестве экземпляров (оригиналов, копий), быть приняты у заявителя, и документы, яв-
о необходимости печати и прикрепления фай- ляющиеся результатами заказов в ведомства
лов, о критериях качества документов. или в СМЭВ согласно настройкам предшеству-
ющих этапов).
8) Должна быть возможность указать, какие слу-
жебные документы должны быть подготовлены 4) Должна быть возможность выбора типа за-
при формировании заказа. Добавление сведе- проса в СМЭВ из списка. После выбора типа за-
ний о служебных документах происходит анало- проса должен выводиться список полей запроса.
гично пунктам 2–4, 7 этапа «Консультирование».
5) Должна быть возможность установить связи
9) Дальнейшие действия должны быть ана- между полями документов, составляющих дело
логичны описанным в пунктах 8–10 этапа на данном этапе, и полями запроса (указать,
«Консультирование». из каких характеристик какого документа долж-
ны получаться данные для заполнения полей
запроса — связать характеристики).

18
6) Должна быть возможность указать, скан-ко- 3) Должна быть возможность указать, какие
пии каких документов должны быть отправлены служебные документы должны быть подготов-
с запросом в СМЭВ в виде вложений к запросу. лены при выдаче результатов оказания услуги.
Добавление сведений о служебных докумен-
7) Должна быть возможность установить связи тах происходит аналогично пунктам 2–4 этапа
между полями документов-результатов (до- «Консультирование».
кументов, формируемых в результате запро-
са) и полями ответа на запрос, получаемого 4) Должна быть возможность указать, какие
из СМЭВ (указать, в какие характеристики до- документы, из числа полученных в результате
кумента-результата должны быть сохранены выполнения этапов дела, являются результатом
данные, полученные из СМЭВ с ответом на за- оказания услуги. Должна быть возможность
прос — связать характеристики). создать несколько вариантов результатов.
В каждом из вариантов может быть несколько
8) Созданные связи должны отображаться документов. Для документов-результатов ука-
на форме. зываются сведения о количестве экземпляров,
о необходимости печати и прикрепления фай-
9) Дальнейшие действия аналогичны описан- лов, о критериях качества документов.
ным в пунктах 10–11 этапа «Формирования
заказа в ведомство в бумажном виде и прием 5) В список документов-результатов могут войти
его результатов». только документы, которые были получены
как результаты заказов в ведомства, запросов
10) Должна быть возможность пометить этап СМЭВ или являются результатами рассмотрения
как полностью настроенный. заказа в ЦОУ.

11) Этап не может быть помечен как полностью 6) Дальнейшие действия аналогичны описан-
настроенный, если связаны не все обязатель- ным в пунктах 10–11 этапа «Формирования
ные характеристики или не указана плановая заказа в ведомство в бумажном виде и прием
длительность этапа. В этом случае при попытке его результатов».
сохранения сведений об этапе, который по-
мечен как полностью настроенный, система 7) Должна быть возможность пометить этап как
должна вывести сообщение со списком причин, полностью настроенный.
по которым настройка этапа не может считаться
завершенной. 8) Этап не может быть помечен как полностью
настроенный, если не указано ни одного до-
3.2.3.2.8 Настройка этапа типа «Рассмотрение кумента-результата или не указана плановая
заказа в ЦОУ» длительность этапа. В этом случае при попытке
сохранения сведений об этапе, который по-
1) Настройка этапа «Рассмотрение заказа мечен как полностью настроенный, должно
в ЦОУ» должна выполняться аналогично на- выводиться сообщение со списком причин,
стройке этапа «Формирование заказа в ведом- по которым настройка этапа не может считаться
ство в бумажном виде и прием его результатов» завершенной.
с одним отличием: для этапа «Рассмотрение
заказа в ЦОУ» не требуется указывать адресата. 3.2.3.3 Создание и изменение информаци-
онных услуг
3.2.3.2.9 Настройка этапа типа «Выдача ре-
зультатов оказания услуги» 3.2.3.3.1 Ввод основных сведений об инфор-
мационной услуге
1) Должен быть выведен список типов доку-
ментов, экземпляры (оригиналы либо копии) 1) Должен обеспечиваться ввод или изменение
которых согласно настройкам предшествую- основных сведений об услуге:
щих этапов должны находиться в деле к эта-
пу выдачи. —— название;

2) Должна быть возможность отметить в списке, —— список подразделений, которые оказывают


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

19
—— тип услуги (федеральная, региональная, муни- заполнения поля «Категория» в основных сведениях
ципальная, иная); об услуге (п. 4.2.3.2.1).

—— категория услуги; 2) В справочнике указываются наименования ка-


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

—— ссылка на страницу услуги на ЕПГУ; 4) Должна предоставляться возможность удаления


категорий услуг.
—— ссылка на страницу услуги на РПГУ;
3.2.3.6 Настройка справочника типов документов
—— ссылка на страницу услуги в базе знаний;
Справочник типов документов предназначен для
—— сведения о документах, регламентирующих определения в АИС ЦОУ типов документов, ис-
оказание услуги; пользуемых при оказании услуг. В справочнике
определяется перечень всех указанных докумен-
—— словесное описание информации по услуге. тов, описываются их свойства, задаются правила
автоматического заполнения полей документов.
2) Должно обеспечиваться сохранение введен-
ных сведений об услуге. 3.2.3.6.1 Управление списком типов документов

3) Должно обеспечиваться удаление выбран- 1) В справочнике типов документов должен


ной услуги. выводиться список типов документов, настро-
енных в системе.
3.2.3.3.2 Настройка дополнительных справоч-
ных материалов по услуге 2) В списке типов документов должны выпол-
няться следующие функции:
1) Должна обеспечиваться возможность прикре-
пить к информационной услуге файлы, содер- —— создание нового типа документа;
жащие дополнительную информацию по услуге.
—— изменение существующего типа документа;
2) Должно обеспечиваться удаление файлов,
прикрепленных к услуге. —— создание новой группы документов;

3.2.3.4 Создание и изменение жизненных ситуаций —— изменение существующей группы документов;


(бизнес-ситуаций)
—— логическое удаление типа документов;
Должны обеспечиваться следующие возможности:
—— восстановление логически удаленного типа
1 ) со з д а н и е н о в о й ж и з н е н н о й с и т у а ц и и документов;
(бизнес-ситуации);
—— удаление типа документов;
2) изменение названия существующей жизненной
ситуации (бизнес-ситуации); —— удаление группы документов;

3) удаление жизненной ситуации (бизнес-ситуации). —— настройка автоматического заполнения полей


документов.
4) настройка анкеты жизненной ситуации (биз-
нес-ситуации) (см. п. 4.2.4.2 «Настройка экс- 3) Должна обеспечиваться возможность про-
пертной подсистемы для жизненной ситуации смотра списка документов с группировкой
(бизнес-ситуации)»). по группам документов и без нее.

3.2.3.5 Настройка справочника категорий 4) Должна обеспечиваться возможность филь-


трации списка типов документов по признаку
1) В системе должен вестись справочник категорий логического удаления.
услуг. Справочник категорий услуг используется для

20
3.2.3.6.2 Создание и изменение типа документа —— указать комментарий о правилах запол-
нения поля;
1) Должен обеспечиваться ввод или изменение
общих свойств документа: —— указать обязательность заполнения поля;

—— название; —— указать правила валидации данных, введенных


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

—— настроить порядок следования полей в списке —— дата по текущий день (для поля типа «Дата
при их заполнении. и время»);

3) К функции создания, изменения поля доку- —— ИНН физических лиц;


мента предъявляются следующие требования:
—— ИНН юридических лиц;
—— настроить название поля документа;
—— кадастровый номер;
—— указать тип поля — должна быть доступна на-
стройка полей следующих типов: —— код подразделения;

—— адрес; —— КПП;

—— дата и время; —— ОГРН;

—— логический; —— ОГРНИП;

—— массив — позволяет указать в поле мас- —— серия свидетельства о рождении;


сив данных;
—— СНИЛС;
—— заявитель — позволяет выбрать в поле одного
из заявителей, зарегистрированных в системе; —— телефонный номер;

—— строка; —— цифры;

—— целое число; —— электронная почта,

—— элемент справочника — позволяет выбрать 5) К функции настройки регулярных выражений


в поле один из элементов справочника, на- предъявляются следующие требования:
строенного в системе.
—— для поля должна быть возможность указать
произвольное регулярное выражение;

21
—— должна быть возможность проверить правиль- 3.2.3.7 Настройка пользовательских справочников
ность введенного регулярного выражения
на предполагаемых значениях, которые будут Пользовательские справочники предназначены
вводиться в настраиваемое поле; для использования при настройке в справочнике
типов документов полей документов типа «Элемент
—— должна быть возможность указать сообщение справочника».
об ошибке, которое должно выводиться в слу-
чае, если данные введенные в поле не пройдут 1) В системе должен быть раздел с перечнем пользо-
проверку валидации. вательских справочников. Для каждого справочника
должна обеспечиваться возможность управления
6) Для типа документа должна быть возмож- списком элементов, входящих в него.
ность указать в какие группы документов он
входит. Должна быть возможность включить 2) Пользовательский справочник должен иметь
один тип документа в несколько групп. название.

7) Для типа документа должна быть возмож- 3) Система должна предоставлять следующие
ность настроить штрих-код — указать данные, возможности управления пользовательскими
введенные в какие поля документа должны справочниками:
использоваться в штрих-коде, в какой после-
довательности, при необходимости указать —— создание справочника;
фиксированное количество знаков, которое
отводится под конкретное поле в штрих-коде. —— изменение ранее созданного справочника;

3.2.3.6.3 Настройка автоматического заполне- —— удаление справочника.


ния полей документов
4) Для каждого справочника должна предостав-
1) В системе должна быть реализована возмож- ляться возможность ведения списка элементов
ность настройки автоматического заполнения справочника:
полей документа данными о заявителе, доку-
менте, с которым заявитель идентифицирован —— создание любого количества элементов
в системе, либо любом документе, который справочника;
принимается от заявителя при предоставле-
нии услуги. —— изменение ранее созданных элементов
справочника;
2) Функция настройки автоматического запол-
нения полей документов должна быть доступна —— удаление элементов справочника.
как для отдельных типов документов, так и для
групп документов. При настройке автомати- 5) Элемент справочника должен содержать следу-
ческого заполнения для группы документов, ющие свойства:
сохраненное правило должно распространяться
на все документы, входящие в группу и имею- —— название элемента справочника
щие данное поле.
—— код элемента справочника
3) Поля одного документа или группы докумен-
тов могут быть одновременно связаны с полями 3.2.3.8 Настройка шаблонов печатных форм
любых объектов. документов

4) Одно поле документа или группы документов 1) Система должна обеспечивать возможность на-
может быть одновременно связано с любым стройки шаблонов печатных форм документов,
количеством полей любых объектов. включая настройку предзаполнения шаблона дан-
ными известными при обслуживании заявителя.
5) Должна быть реализована возможность про-
смотра списка связей, настроенных для поля 2) Должна быть доступна возможность вывода в ша-
документа или группы документов. блон данных, содержащихся в следующих объектов:

6) Должна быть реализована возможность уда- —— заявитель;


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

22
—— ЦОУ, в котором выполняется обслуживание бранного, автоматическое проставление отметки
заявителя; напротив значения, выбранного в поле документа.

—— ведомство, предоставляющее услугу; 6) Должна обеспечиваться возможность вывода


данных в шаблон документов в табличном пред-
—— услуга; ставлении, например, вывод сведений о всех членах
семьи или о местах работы заявителя.
—— специалист, обслуживающий заявителя;
3.2.4 Экспертная подсистема
—— данные сертификата электронной подписи, ко-
торой подписан электронный документ, направ- 3.2.4.1 Настройка экспертной подсистемы
ленный в ЦОУ по результатам предоставления для услуги
услуги, или выписка из информационных систем
органов, предоставляющих услугу; 3.2.4.1.1 Настройка списка вопросов

—— источник, из которого получен электронный 1) Для услуги, настроенной в системе, должна


документ, направленный в ЦОУ по результа- быть возможность настроить список вопросов
там предоставления услуги, или выписка из ин- и ответов на них, которые должны быть заданы
формационных систем органов, предоставляю- заявителю при консультировании для опреде-
щих услугу; ления варианта услуги, который может быть
оказан заявителю в его конкретной ситуации.
—— документы, принимаемые от заявителя или яв-
ляющиеся результатом предоставления услуги; 2) Должна предоставляться возможность доба-
вить вопрос в анкету.
—— штрих-код, настроенный для типа документа,
принимаемого от заявителя или являющегося 3) Пользователь должен иметь возможность
результатом предоставления услуги; указать основную формулировку вопроса
и альтернативные формулировки, которые
—— штрих-код, содержащий номер дела. должны использоваться при консультировании
заявителя специалистами центра телефонного
3) Должна быть доступна возможность вывода в ша- обслуживания, либо при самостоятельном кон-
блоны данных о документах, принятых от заявителя, сультировании заявителя на портале ЦОУ или
включая следующие сведения: в терминалах самообслуживания. Указание аль-
тернативных формулировок вопроса не должно
—— название документа; быть обязательным.

—— количество копий документа, принятых 4) Должна предоставляться возможность из-


от заявителя; менить вопрос.

—— количество оригиналов документов, принятых 5) Должна предоставляться возможность уда-


от заявителя; лить вопрос.

—— серия документа; 6) Для каждого вопроса должна быть возмож-


ность настроить список ответов.
—— номер документа;
7) Должна быть возможность добавить новый
—— дата выдачи; ответ на вопрос, изменить существующий ответ,
удалить ответ.
—— кем документ выдан.
8) Должна предоставляться возможность на-
4) Должна обеспечиваться возможность вывода строить порядок следования ответов на вопрос
адреса как полностью, так и отдельными элементами, при их выводе в анкете.
составляющими адрес.
9) Порядок следования вопросов при их вы-
5) Должна быть реализована возможность вывода воде в анкете должен определяться системой
всех возможных для выбора значений поля до- с возможностью указания пользователей от-
кумента с автоматическим подчеркиванием вы- носительной последовательности для каждых
двух вопросов (см. пункт. 4.2.4.1.1).

23
3.2.4.1.2 Настройка матрицы ответов 4) Если комбинация ответов на вопросы не при-
водит ни к одному варианту услуги, то такой
1) Система должна предоставлять возможность выход должен приводить к отказу в предо-
настроить условия выбора того или иного ва- ставлении услуги.
рианта услуги в рамках настраиваемой анкеты.
5) Для отказа должна быть возможность указать
2) Должна предоставляться возможность указать описание причины отказа и ссылку на веб-стра-
для каждого варианта услуги, какие ответы ницу, содержащую подробное описание при-
на вопросы должна приводить к выбору этого чины отказа заявителю.
варианта услуги.
3.2.4.2 Настройка экспертной подсистемы для жиз-
3) Одному варианту услуги может соответ- ненной ситуации (бизнес-ситуации)
ствовать один или несколько вариантов отве-
та на каждый вопрос. Если вопрос не должен 1) Настройка экспертной подсистемы для жизненной
задаваться при определении одного из ва- ситуации (бизнес-ситуации) должна быть аналогич-
риантов услуги, то должна быть возможность на настройке экспертной подсистемы для услуги
не указывать ответы на вопрос для этого ва- за исключением того, что ответы на вопросы анкеты
рианта услуги. должны приводить не к варианту услуги, а к одной
или нескольким услугам, входящим в жизненную
4) Пользователь должен иметь возможность ситуацию.
просмотреть полное название вариантов услуг,
вопросов и вариантов ответов на них. 3.2.4.3 Применение экспертной системы при анке-
тировании по услуге
5) Если в анкете один вопрос логически обя-
зательно должен быть задан раньше другого 1) В ходе консультации заявителя по услуге система
вопроса, то пользователь должен иметь воз- должна переходить к анкетированию заявителя
можность задать такую последовательность с целью определения варианта услуги, который
для пары вопросов. может быть предоставлен заявителю.

6) Пользователь не должен задавать порядок 2) При переходе к анкетированию в соответствии


следования всех вопросов анкеты, он должен с настройками дерева анкеты должен выводиться
определяться автоматически при построении только первый вопрос анкеты и варианты отве-
дерева анкеты. та на него.

7) Должна предоставляться возможность очи- 3) Ответы на вопросы анкеты должны выводиться


стить выполненные настройки матрицы. в порядке, заданном в дереве анкеты.

8) Должна предоставляться возможность со- 4) Допускается выбор только одного варианта ответа
хранить выполненные настройки матрицы. При на каждый вопрос.
сохранении настроек матрицы должно выпол-
няться построение дерева анкеты. 5) В зависимости от выбранного ответа на вопрос
должен выводиться следующий вопрос в соответ-
3.2.4.1.3 Построение дерева анкеты ствии с деревом анкеты.

1) Дерево анкеты должно визуализировать 6) В результате ответов на вопросы анкеты должен


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

2) Дерево анкеты должно строиться таким об- 7) Результат анкетирования (вариант услуги, либо
разом, чтобы определить вариант, подходящий отказ) должен быть получен за минимальное число
заявителю, за наименьшее число вопросов, вопросов, заданных заявителю.
заданных заявителю.
8) Если в результате анкетирования определен отказ
3) Если задана последовательность между пара- заявителю в предоставлении услуги, то должна вы-
ми вопросов, то дерево анкеты должно строится водиться причина отказа с возможностью перейти
с учетом этих настроек. на страницу базы знаний, содержащую пояснения
о причине отказа, в соответствии с настройками
экспертной подсистемы.

24
9) Если на выходе анкеты определяется неактивный брать вручную одну или несколько услуг жизненной
вариант услуги, то такой выход приравнивается ситуации (бизнес-ситуации), которые необходимо
к отказу. Должны выводиться соответствующие по- предоставить заявителю.
яснения для пользователя.
3.2.5 Подсистема автоматизированного исполнения
10) Если в результате анкетирования определено регламентов предоставления услуг
несколько вариантов услуги, которые могут быть
оказаны заявителю, то продолжение сценария воз- 3.2.5.1 Общие требования к подсистеме
можно только после выбора одного из доступных
вариантов услуги. 1) Процесс обслуживания заявителей в системе
должен быть построен по сценарному принципу:
11) Если анкетирование заявителя выполняется система должна вести пользователя по заданному
в сценарии, доступном сотруднику ЦТО, либо зая- сценарию.
витель выполняет анкетирование самостоятельно
на портале ЦОУ или в киоске самообслуживания, 2) Процессы оказания услуг должны быть построены
то для пользователя должны выводиться соответ- с использованием сценариев и задач:
ствующие формулировки вопросов.
—— сценарии обслуживания — при работе с за-
12) В ходе ответов на вопросы анкеты пользователь явителями;
должен видеть, какие из вариантов услуги подхо-
дят заявителю на текущем этапе ответа на вопро- —— задачи — при выполнении этапов оказания ус-
сы анкеты. луг, которые не требуют личного присутствия
заявителя (внутренних процессов).
13) Пользователь должен иметь возможность пре-
рвать анкетирование с применением экспертной 3) Последовательность шагов (этапов) оказания
подсистемы в любой момент анкетирования и вы- услуги должна соответствовать настройкам услу-
брать вручную подходящий ему вариант услуги. ги, выполненным в подсистеме ввода и хранения
регламентов.
14) Пользователь должен иметь возможность про-
смотреть список документов, который требуется пре- 4) В процессе оказания услуги система должна опре-
доставить заявителю при каждом варианте услуги. делять состав и последовательность этапов оказания
услуги, учитывая следующие вводные:
15) Неактивные варианты услуги не должны выво-
диться пользователю при анкетировании. —— настройка услуги;

3.2.4.4 Применение экспертной подсистемы —— полнота комплекта документов, предоставлен-


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

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

3) Пользователь должен иметь возможность пре- 8) Должна быть возможность распределения нагруз-
рвать анкетирование с применением экспертной ки на пользователей в процессе предоставления
подсистемы в любой момент анкетирования и вы- услуг, в соответствии с настройками системы.

25
3.2.5.2 Сценарий регистрации обращения 3.2.5.2.1 Идентификация и регистрация
заявителя
1) Должна быть возможность выбрать одну из име-
ющихся тем обращения заявителя: 1) Должна быть возможность идентификации
ранее зарегистрированных заявителей и реги-
—— консультирование; страция новых заявителей.

—— прием документов; 2) Идентификация (подтверждение личности за-


явителя) должна обязательно входить в процесс
—— выдача результатов оказания услуги; обслуживания заявителя во всех случаях, когда
используются персональные данные заявителя:
—— информирование о статусе дела;
—— прием документов;
—— управление учетной записью в ЕСИА;
—— выдача результатов оказания услуги;
—— запрос сведений о начислениях и платежах.
—— информирование о статусе дела (если заявитель
2) Формы сценариев обслуживания должны содер- не знает уникальный код дела);
жать подсказки для пользователя.
—— управление учетной записью в ЕСИА;
3) Подсказки на форме должны выводиться после-
довательно и зависеть от выполненный на форме —— прием жалоб на орган власти, предоставив-
действий (по мере следования пользователя по сце- ший услуги;
нарию обслуживания).
—— просмотр персональных данных;
4) Должна быть информационная область,
в которой будет показываться краткие параметры —— отзыв согласия на обработку персональ-
обслуживания. ных данных.

5) Должна быть возможность вернуться на преды- 3) Идентификация заявителя должна произ-


дущую форму сценария при возникновении такой водиться по документам, удостоверяющим
необходимости, за исключением перехода назад личность заявителя, а также документам ор-
от приема документов (когда дело заявителя уже ганизации, которую представляет заявитель.
создано) к консультации: такой переход назад дол-
жен быть недоступен. 4) Должна быть возможность выбрать тип
заявителя:
6) Сценарий регистрации обращения, вне зависи-
мости от выбранной темы обращения, должен иметь —— физическое лицо;
страницу завершения, которая должна содержать
краткие итоги обслуживания: —— юридическое лицо/индивидуальный пред-
приниматель.
—— информация об обслуживаемом заявителе;
5) Должна быть возможность выбрать тип иден-
—— тема обращения; тифицирующего документа из настроенного
списка идентифицирующих документов по вы-
—— поле для ввода пользователем произвольного бранному типу заявителя.
комментария к обращению;
6) Список идентифицирующих документов
—— переключатель, позволяющий продолжить или должен быть настраиваемым, то есть измене-
завершить текущее обслуживание. ние списка идентифицирующих документов
для каждого типа заявителя должно произ-
7) Должна быть возможность провести обслужива- водиться пользователем с соответствующим
ние заявителя по нескольким темам обращения без правом в пользовательском интерфейсе без
повторной идентификации заявителя. программирования.

7) В процессе идентификации должна быть


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

26
8) Должна быть возможность поиска заявите- 15) При регистрации нового заявителя — юри-
лей — физических лиц как среди документов дического лица / индивидуального предприни-
необезличенных, так и среди документов обе- мателя должна быть возможность заполнения
зличенных заявителей. информации об идентифицирующем документе
заявителя, а также дополнительной информации
9) Поиск среди документов обезличенных за- о заявителе:
явителей — физических лиц должен произво-
диться при одновременном указании следую- —— организационно-правовая форма;
щих параметров:
—— наименование;
—— фамилия заявителя;
—— полное наименование;
—— имя заявителя;
—— дата государственной регистрации;
—— серия документа (при наличии);
—— ИНН;
—— номер документа.
—— КПП;
10) Если поиск заявителя производится среди
обезличенных заявителей, то найденный за- —— ОГРН;
явитель при продолжении сценария должен
быть деобезличен. —— сфера деятельности;

11) При выборе документа в результатах поиска —— адрес регистрации;


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

12) Должна быть возможность внесения измене- —— субъект РФ;


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

14) При регистрации нового заявителя — фи- —— согласие на оповещение по электронной почте.
зического лица должна быть возможность за-
полнения информации об идентифицирующем 16) При регистрации должна производиться
документе заявителя, а также дополнительной проверка наличия в системе аналогичного зая-
информации о заявителе: вителя по данным, введенным при регистрации,
путем сопоставления следующих параметров:
—— ИНН;
—— заявитель — физическое лицо (совокупность
—— СНИЛС; параметров):

—— мобильный и контактные телефоны; —— фамилия;

—— электронная почта; —— имя;

—— согласие на СМС-оповещение; —— отчество;

—— согласие на оповещение по электронной почте; —— дата рождения.

—— согласие на обработку персональных данных; —— заявитель — юридическое лицо / индивидуаль-


ный предприниматель:
—— пол;
—— ИНН.
—— гражданство.

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

—— приобщить новый идентифицирующий документ 8) Должна быть возможность провести анкети-


к существующему аналогичному заявителю; рование заявителя по услуге с использованием
экспертной системы.
—— создать нового заявителя с новым идентифи-
цирующим документом. 9) В качестве результата консультирования си-
стема должна вывести пользователю список
18) Должна быть возможность в процессе иден- документов, которые необходимо предоста-
тификации, регистрации принять от заявителя вить данному заявителю для предоставления
согласие на обработку персональных данных, выбранной услуги (услуг). Для каждого из до-
в том числе сформировать печатную форму со- кументов должны быть выведены следующие
гласия, и приложить полученное в письменной сведения:
форме согласие к карточке заявителя.
—— обязательность предоставления лично
19) Должна быть возможность перенести заявителем;
прием согласия на обработку персональных
данных заявителя с этапа идентификации зая- —— требуемое количество экземпляров (оригиналов
вителя на этап приема документов по выбран- и копий);
ной услуге.
—— текстовый комментарий о качественных ха-
20) После идентификации / регистрации за- рактеристиках (при наличии соответствующей
явителя должно происходить продолжение настройки).
текущего сценария обслуживания.
10) Должна быть возможность вывести на пе-
3.2.5.2.2 Регистрация обращения по теме чать указанную информацию о документах для
«Консультирование» передачи заявителю в печатном виде.

1) После выбора темы обращения 11) Должна быть возможность сохранить кон-
«Консультирование» должна быть возможность сультацию по обслуживаемому заявителю, при
идентифицировать либо зарегистрировать за- этом если заявитель не был идентифицирован
явителя, а также отложить идентификацию, ре- перед началом консультации, то перед сохра-
гистрацию заявителя до момента завершения нением консультации должна выполняться
консультации. идентификация регистрация заявителя.

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

3) Должна быть возможность выбрать и про- 3.2.5.2.3 Регистрация обращения по теме


должить сохраненную ранее консультацию. «Прием документов»

4) Должна быть возможность выбрать и продол- 1) Прием документов должен производиться


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

5) Должна быть возможность поиска услуги, 2) Пользователю должен выводиться список


в том числе с использованием комбинации документов, необходимых для оказания услуги,
имеющихся фильтров и группировок. сформированный в результате выполнения
сценария консультирования.
6) Должна быть возможность провести анке-
тирование заявителя по жизненной ситуации 3) В списке могут присутствовать отдельные до-
(бизнес-ситуации) с использованием эксперт- кументы, а также группы документов. Группа —
ной системы. объединение документов по признаку необ-
ходимости представления заявителем одного
из нескольких документов.

28
4) Список документов должен быть сгруппиро- 12) Должна быть возможность прикрепить
ван на следующие категории: сформированную печатную форму как файл
к документу.
—— документы (группы документов), предоставляе-
мые заявителем лично в обязательном порядке; 13) Должна быть возможность просмотра под-
сказки (настроенного комментария) к документу
—— необязательные документы (группы документов), (группе документов).
которые могут быть предоставлены заявителем
по собственной инициативе и которые могут 14) Система должна проводить проверку кор-
быть в том числе получены посредством запро- ректности вводимых пользователем в поля до-
сов к ведомствам; кументов данных в соответствии с настройками.

—— служебные документы (группы документов), 15) Должна быть возможность принять несколь-
формируемые для собственных нужд ЦОУ, не- ко экземпляров одного и того же типа докумен-
обходимые для внутренних процессов ЦОУ. та, принимаемого от заявителя.

5) Должна быть возможность принять едино- 16) Должна быть возможность указать количе-
временно комплект документов по всем ус- ство листов принимаемого документа.
лугам в рамках одной жизненной ситуации
(бизнес-ситуации). 17) Должна быть возможность сформировать
и вывести на печать расписку о приеме доку-
6) Должна быть возможность выбрать из группы ментов от заявителя.
документов конкретный документ, который
предоставил заявитель. 18) Должна быть возможность принять от за-
явителя данные, необходимые для отправки
7) Должна быть возможность для выбранного межведомственных запросов с целью получения
документа заполнить характеристики (поля), документов, необходимых для оказания услуги.
в соответствии с настройкой соответствую-
щей услуги. 19) Должна быть возможность указать, в каком
отделении ЦОУ заявитель желает получить ре-
8) Должна быть возможность автоматизирован- зультат услуги.
ного заполнения полей документов данными,
хранящимися в карточке заявителя и его иден- 20) По итогам обработки документов пользова-
тифицирующего документа. тель должен иметь возможность выбрать один
из вариантов результата приема документов:
9) Должна быть возможность приложения к до-
кументам скан-копий, в том числе: —— успешный прием документов;

—— сканирование в АРМ пользователя, и сохранение —— прием документов необходимо отложить по ка-


электронных образов в форматах: кой-либо причине, с указанием причины;

TIFF (многостраничный); —— заявитель отказался от получения услуги, с ука-


занием причины отказа.
PDF (многостраничный);
3.2.5.2.4 Регистрация обращения по теме
JPEG (одностраничный); «Статус дела»

PNG (одностраничный); 1) Информирование о статусе дела должно


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

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

29
4) При предоставлении информации без иден- 3) Должна быть возможность поиска дела по его
тификации заявителя должна быть возмож- номеру среди данного списка.
ность найти дело с использованием номера
дела и уникального кода, предоставленного 4) Если заявителю предоставлялся комплекс
заявителю в расписке о приеме документов услуг в рамках жизненной ситуации (бизнес-си-
на оказание услуги. туации), то должна быть возможность выдачи
комплекса результатов по данным услугам.
5) После того как дело найдено, должна быть
возможность перейти к просмотру информации 5) После выбора дела должен выводиться
о найденном деле. список документов, которые требуется выдать
заявителю или оформить в процессе выдачи
6) Система должна показать общую информа- результата.
цию по делу, в том числе:
6) Список документов должен быть сгруппиро-
—— наименование услуги; ван на следующие категории:

—— дата создания; —— документы (группы документов), предоставлен-


ные заявителем при обращении за получением
—— сотрудники, работавшие с делом; услуги и возвращаемые ему по окончании пре-
доставления услуги;
—— текущий статус;
—— документы, являющиеся результатами услуги;
—— дата завершения (если предоставление услуги служебные документы (группы документов),
уже завершено); формируемые для собственных нужд ЦОУ, не-
обходимые для внутренних процессов ЦОУ.
—— отклонение от плановых сроков.
7) Должна быть возможность просмотра харак-
7) Должна быть возможность просмотра всего теристик (полей) документов, а также возмож-
маршрута предоставления услуги, в том числе: ность просмотра прикрепленных к ним файлов.

—— список этапов предоставления услуги (прой- 8) Должна быть возможность отложить процесс
денных, текущий этап, последующие этапы); выдачи результата услуги с обязательным ука-
занием причины.
—— плановый срок по каждому этапу;
9) При успешной выдаче результатов услуги
—— отклонение по каждому этапу. должна быть возможность указать место в ар-
хиве, в котором будет храниться данное дело.
8) Должна быть возможность просмотра спи-
ска обращений заявителя в рамках выбран- 10) Система должна проверять обязательность
ного дела. указания места в архиве при успешном завер-
шении сценария.
9) Должна быть возможность просмотра истории
событий, произошедших по выбранному делу. 3.2.5.3 Обработка задач

10) Должна быть возможность просмотра списка 3.2.5.3.1 Список задач


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

3.2.5.2.5 Регистрация обращения по теме 2) Должна быть доступна фильтрация списка


«Выдача результата услуги» задач по следующим параметрам:

1) Выдача результата предоставления услуги —— тип задачи;


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

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

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

—— сроки выполнения задач — должна быть до- —— комментарий к задаче;


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

4) Должна быть доступна возможность про- 9) Не должна быть доступна возможность брать
смотра списка задач без наложения фильтров. в обработку задачу, которая уже находится в об-
работке у другого пользователя.
5) Должна выполняться цветовая индикация за-
дач в списке по статусам и срокам исполнения 10) Пользователь должен иметь возможность
(задачи в работе, плановое время выполнения брать в обработку только задачи, относящиеся
которых не превышено; задачи в работе, пла- к его подразделению.
новое время выполнения которых превышено;
завершенные задачи). 3.2.5.3.2 Настройка групп компетенций

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

—— тип задачи; 2) В системе должна быть реализована возмож-


ность создания, изменения и удаления групп
—— номер задачи; компетенций.

—— номер дела, в рамках исполнения которого со- 3) Для каждого подразделения должна быть
здана задача; доступна возможность настроить свои группы
компетенций.

31
4) Для группы компетенции должна быть воз- 4) На форму обработки задачи должен выво-
можность настроить название группы, опреде- диться список документов, которые должны
лить руководителя группы из числа пользовате- быть изъяты из дела и переданы в ведомство.
лей подразделения, для которого выполняется
настройка. 5) Для каждого документа должно выводиться
число копий и оригиналов документов, которые
5) Должна быть доступна возможность опре- должны быть изъяты.
делить список сотрудников, входящих в группу
компетенций (сотрудников можно добавлять 6) Список изымаемых документов и их ко-
только из числа сотрудников подразделения, личество должен выводиться в соответствии
для которого выполняется настройка). Один с настройками этапа «Формирование заказа
сотрудник может входить в любое количество в ведомство в бумажном виде и прием его
групп компетенций и быть руководителем лю- результатов».
бого числа групп компетенций.
7) Для каждого документа, который должен
6) Должна быть доступна возможность опреде- быть изъят из дела, должна быть возможность:
лить типы задач, которые будут обрабатывать
сотрудники, входящие в группу компетенций. —— просмотреть значения полей документа;

7) Если для группы компетенций определены —— просмотреть прикрепленные файлы;


задачи типа «Формирование заказа», то должна
быть доступна возможность настроить список —— при необходимости отсканировать документы.
ведомств, с которыми будут взаимодействовать
сотрудники, входящие в группу компетенций. 8) Пользователь должен иметь возможность
отметить, что документ изъят из дела.
8) В списке задач сотрудникам, входящим
в группы компетенций, должны отображаться 9) Должна быть возможность просмотреть спи-
только те типы задач, которые определены для сок служебных документов, которые должны
них настройками групп компетенций, в которые быть сформированы пользователем при фор-
они входят. мировании заказа, в соответствии с настройка-
ми этапа «Формирование заказа в ведомство
9) Для сотрудников, не входящих ни в одну в бумажном виде и прием его результатов».
группу компетенций, должны быть доступны
все типы задач без ограничений. 10) Для каждого служебного документа должны
быть доступны возможности:
3.2.5.3.3 Выполнение задачи
«Формирование заказа» —— заполнить поля документа;

1) Задачи на формирование заказа должны —— отсканировать документ;


создаваться при переходе дела на этап фор-
мирования заказа в ведомство на бумажных —— прикрепить файл;
носителях.
—— сформировать печатную форму (если она
2) На форме обработки задачи должны выво- настроена).
диться подсказки о необходимых действиях
пользователя. 11) Пользователь должен иметь возможность
отметить служебные документы, которые он
3) На форме обработки задачи должны быть обработал.
доступны следующие функции:
12) Пользователю должны быть доступны следу-
—— просмотреть, по какой услуге создано дело; ющие варианты завершения работы с задачей:

—— просмотреть, в какое ведомство формиру- —— отложить исполнение задачи:


ется заказ;
должна быть возможность указать при-
—— просмотреть, к какому делу относится задача; чину, по которой исполнение задачи от-
кладывается;
—— перейти в карточку дела для просмотра под-
робной информации по делу.

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

должна быть возможность оставить должна быть возможность указать количе-


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

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


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

должна быть возможность оставить до- по данному делу должна быть поставлена
полнительный комментарий о причинах задача на оповещение заявителя о необ-
отказа заявителя от исполнения задачи; ходимости явиться в ЦОУ и предоставить
дополнительные документы.
задача, от исполнения которой отказал-
ся один из пользователей, должна быть —— указать, что заказ сформирован успешно:
доступна для обработки другим поль-
зователям. должна быть возможность выгрузить ар-
хив файлов, прикрепленных к документам
—— вернуть дело на доработку сотруднику, приняв- изъятым из дела;
шему документы от заявителя:
должен выполняться пересчет числа ко-
должна быть доступна возможность ука- пий и оригиналов документов, которые
зать комментарий о причинах возврата в действительности остаются в деле;
дела на доработку;
дело, по которому сформирован заказ
после возврата дела на доработку на должно перейти к следующему шагу эта-
сотрудника, принявшего документы по па — прием результата заказа;
делу, должна быть назначена задача «До-
работка дела». если выдача результатов оказания услу-
ги выполняется в ведомстве, в которое
—— указать, что документы заявителя некорректны: направляется заказ, то после успешного
формирования заказа процесс оказания
должна быть доступна возможность ука- услуги должен завершиться, дело должно
зать комментарий о причинах некор- перейти состояние «В архиве».
ректности документов заявителя;
3.2.5.3.4 Выполнение задачи «Прием резуль-
дело, по которому была обработана за- тата заказа»
дача, должно вернуться на этап приема
документов; 1) Задачи типа «Прием результата заказа» долж-
ны создаваться, после того как сформирован
по данному делу должна быть поставле- заказ в ведомство, при условии, что выдача
на задача на оповещение заявителя о результата оказания услуги заявителю будет
причинах некорректности документов и выполняться в ЦОУ.
необходимости явиться в ЦОУ.
2) На форме обработки задачи должны выво-
—— указать, что от заявителя требуются дополни- диться подсказки о необходимых действиях
тельные документы: пользователя.

33
3) На форме обработки задачи должны быть ровать, что отмечены все документы одного
доступны следующие функции: из вариантов результата, обработка документов
из разных результатов не допускается.
—— просмотреть по какой услуге создано дело;
12) Должна быть возможность просмотреть
—— просмотреть из какого ведомства должен быть список служебных документов, которые должны
получен результат заказа; быть сформированы пользователем при приеме
результата заказа, в соответствии с настройка-
—— просмотреть к какому делу относится задача; ми этапа «Формирование заказа в ведомство
в бумажном виде и прием его результатов».
—— перейти в карточку дела для просмотра под-
робной информации по делу. 13) Для каждого служебного документа должны
быть доступны возможности:
4) На форму обработки задачи должен выво-
диться список документов, которые должны —— заполнить поля документа;
быть возвращены в ЦОУ вместе с результата-
ми заказа. —— отсканировать документ;

5) Для каждого документа должно выводиться —— прикрепить файл;


число копий и оригиналов документов, которые
должны быть возвращены. —— сформировать печатную форму (если она
настроена).
6) Список возвращаемых документов и их ко-
личество должен выводиться в соответствии 14) Пользователь должен иметь возможность
с настройками этапа «Формирование заказа отметить служебные документы, которые он
в ведомство в бумажном виде и прием его обработал.
результатов».
15) Пользователю должны быть доступны следу-
7) Для каждого документа, который должен быть ющие варианты завершения работы с задачей:
возвращен в дело, должна быть возможность:
—— отложить исполнение задачи:
—— просмотреть значения полей документа;
должна быть возможность указать при-
—— просмотреть прикрепленные файлы; чину, по которой исполнение задачи от-
кладывается;
—— при необходимости отсканировать документы.
должна быть возможность указать дату
8) Пользователь должен иметь возможность и время, когда пользователь планирует
отметить, что документ возвращен в дело. вернуться к исполнению задачи;

9) На форму должен выводиться список ва- должна быть возможность оставить


риантов результатов заказа в соответствии комментарий;
с настройками этапа «Формирование заказа
в ведомство в бумажном виде и прием его отложенная задача должна назначать-
результатов». ся пользователю, который ее отложил,
и должна быть недоступна для обработки
10) Для документов-результатов должны быть другим пользователям.
доступны возможности:
—— отказаться от исполнения задачи:
—— заполнить поля документа;
должна быть возможность указать причи-
—— отсканировать документ; ну, по которой пользователь отказывается
от исполнения задачи;
—— прикрепить файл.
должна быть возможность оставить до-
11) Пользователь должен иметь возможность полнительный комментарий о причинах
отметить, что приняты документы одного из ва- отказа заявителя от исполнения задачи;
риантов результата. Система должна контроли-

34
задача, от исполнения которой отказал- ходимости явиться в ЦОУ и предоставить
ся один из пользователей, должна быть дополнительные документы.
доступна для обработки другим поль-
зователям. —— указать, что принят успешный результат выпол-
нения заказа, из ведомства получен документ:
—— результат заказа некорректен:
должен выполняться пересчет числа ко-
должна быть доступна возможность пий и оригиналов документов, которые
указать комментарий о некорректно- в действительности остаются в деле после
сти заказа; приема результата заказа;

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

35
—— указать, что заявителю отказано в услуге, ре- —— просмотреть ранее внесенные значения полей
зультатом заказа не является документ: документа;

должна быть возможность указать до- —— при необходимости изменить значения полей
полнительный комментарий о причинах документов;
отказа заявителю;
—— просмотреть прикрепленные файлы;
должна быть возможность указать бу-
дущее место хранения дела, после его —— при необходимости отсканировать документы;
завершения;
—— сформировать печатные формы документов
по данному делу должна быть поставлена (если они настроены).
задача на оповещение заявителя о ре-
зультате оказания услуги. 9) Пользователь должен иметь возможность
отметить, что документ доработан, ошибки, если
3.2.5.3.5 Выполнение задачи «Доработка дела» они были, исправлены.

1) Задачи типа «Доработка дела» должны соз- 10) Должна быть возможность просмотреть спи-
даваться, если в результате обработки задачи сок служебных документов, которые были сфор-
«Формирование заказа» выбран вариант «воз- мированы при приеме документов от заявителя.
врат дела на доработку».
11) Для каждого служебного документа должны
2) Задача на доработку дела должна автомати- быть доступны возможности:
чески назначаться на сотрудника, выполнившего
прием документов до делу. —— просмотреть ранее внесенные значения полей
документа;
3) На форме обработки задачи должны выво-
диться подсказки о необходимых действиях —— при необходимости изменить значения полей
пользователя. документов;

4) На форму должен выводиться комментарий, —— отсканировать документ;


оставленный пользователем, который вернул
дело на доработку. —— прикрепить файл;

5) На форме обработки задачи должны быть —— сформировать печатную форму (если она
доступны следующие функции: настроена).

—— просмотреть по какой услуге создано дело; 12) Пользователь должен иметь возможность
отметить служебные документы, которые он
—— просмотреть к какому делу относится задача; обработал.

—— перейти в карточку дела для просмотра под- 13) Пользователь должен иметь возможность
робной информации по делу. изменить адресатов заказов.

6) На форму обработки задачи должен выво- 14) Пользователю должны быть доступны следу-
диться список документов, которые были при- ющие варианты завершения работы с задачей:
няты от заявителя.
—— отложить исполнение задачи:
7) Для каждого документа должно выводиться
число копий и оригиналов документов, которые должна быть возможность указать при-
были приняты от заявителя. чину, по которой исполнение задачи от-
кладывается;
8) Для каждого документа, который был принят
от заявителя, должна быть возможность: должна быть возможность указать дату
и время, когда пользователь планирует
вернуться к исполнению задачи;

36
должна быть возможность оставить 3.2.5.3.6 Выполнение задачи «Рассмотрение
комментарий; заказа в ЦОУ»

отложенная задача должна назначать- 1) Задачи типа «Рассмотрение заказа в ЦОУ»


ся пользователю, который ее отложил, должны создаваться при переходе дела на этап
и должна быть недоступна для обработки «Рассмотрение заказа в ЦОУ».
другим пользователям.
2) На форме обработки задачи должны выво-
—— указать, что документы заявителя некорректны: диться подсказки о необходимых действиях
пользователя.
должна быть доступна возможность ука-
зать комментарий о причинах некор- 3) На форме обработки задачи должны быть
ректности документов заявителя; доступны следующие функции:

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

по данному делу должна быть постав- —— перейти в карточку дела для просмотра под-
лена задача на оповещение заявителя робной информации по делу.
о причинах некорректности документов
и необходимости явиться в ЦОУ 4) На форму обработки задачи должен выво-
диться список документов, которые должны
—— указать, что от заявителя требуются дополни- быть возвращены заявителю вместе с резуль-
тельные документы: татами рассмотрения заказа.

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

должна быть возможность указать количе- 6) Список возвращаемых документов и их коли-


ство копий, оригиналов дополнительных чество должен выводиться в соответствии с на-
документов, которые должен предоставить стройками этапа «Рассмотрение заказа в ЦОУ».
заявитель;
7) Для каждого документа, который должен быть
должна быть возможность указать допол- возвращен в дело, должна быть возможность:
нительный комментарий разъясняющий
требования к предоставлению дополни- —— просмотреть значения полей документа;
тельных документов;
—— просмотреть прикрепленные файлы;
дело, по которому требуются дополни-
тельные документы от заявителя должно —— при необходимости отсканировать документы.
вернуться на этап приема документов;
8) Пользователь должен иметь возможность
по данному делу должна быть поставлена отметить, что документ обработан.
задача на оповещение заявителя, о необ-
ходимости явиться в ЦОУ и предоставить 9) На форму должен выводиться список вари-
дополнительные документы. антов результатов заказа в соответствии с на-
стройками этапа «Рассмотрение заказа в ЦОУ».
—— указать, что дело доработано успешно:
10) Для документов результатов должны быть
дело, по которому выполнена успешная доступны возможности:
доработка, должно вернуться на этап за-
каза, с которого дело было возвращено —— заполнить поля документа;
на доработку.
—— отсканировать документ;

—— прикрепить файл.

37
11) Пользователь должен иметь возможность задача, от исполнения которой отказал-
отметить, что приняты документы одного из ва- ся один из пользователей, должна быть
риантов результата. Система должна контроли- доступна для обработки другим поль-
ровать, что отмечены все документы одного зователям.
из вариантов результата, обработка документов
из разных результатов не допускается. —— указать, что документы заявителя некорректны:

12) Должна быть возможность просмотреть должна быть доступна возможность ука-
список служебных документов, которые должны зать комментарий о причинах некор-
быть сформированы пользователем при рассмо- ректности документов заявителя;
трении заказа, в соответствии с настройками
этапа «Рассмотрение заказа в ЦОУ». дело, по которому была обработана за-
дача, должно вернуться на этап приема
13) Для каждого служебного документа должны документов;
быть доступны возможности:
по данному делу должна быть постав-
—— заполнить поля документа; лена задача на оповещение заявителя
о причинах некорректности документов
—— отсканировать документ; и необходимости явиться в ЦОУ.

—— прикрепить файл; —— указать, что от заявителя требуются дополни-


тельные документы:
—— сформировать печатную форму (если она
настроена). должна быть возможность указать типы
документов, которые должен предоставить
14) Пользователь должен иметь возможность заявитель;
отметить служебные документы, которые он
обработал. должна быть возможность указать количе-
ство копий, оригиналов дополнительных
15) Пользователю должны быть доступны следу- документов, которые должен предоставить
ющие варианты завершения работы с задачей: заявитель;

—— отложить исполнение задачи: должна быть возможность указать допол-


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

38
дело, по которому получен отказ в предо- 8) Если выполнение запроса закончилось ошиб-
ставлении услуги, должно пропуская все кой на любом из этапов процесса, то статус
последующие этапы заказа в соответствии задачи должен измениться на соответствую-
с маршрутом оказания услуги, перейти щий (например, «ошибка при отправке запроса
на этап выдачи результата предоставле- в СМЭВ»). Пользователь должен иметь возмож-
ния услуги заявителю; ность просмотреть подробную информацию
об ошибке в карточке дела.
по данному делу должна быть поставлена
задача на оповещение заявителя о необ- 9) Должна быть реализована возможность по-
ходимости явиться в ЦОУ. вторной отправки запроса в СМЭВ в случае его
завершения ошибкой.
3.2.5.3.7 Выполнение задачи «Формирование
заказа в СМЭВ (на сервере)» 3.2.5.3.8 Выполнение задачи «Формирование
заказа в СМЭВ (в АРМе)»
1) Задачи на формирование заказа в СМЭВ
на сервере должны создаваться при переходе 1) Задача типа «Формирование заказа в СМЭВ
дела на этап запроса в СМЭВ, если в настройке (в АРМе)» должна создаваться при переходе
этапа дополнительно не указано, что требуется дела на этап выполнения запроса в СМЭВ,
ручная обработка заказа перед формированием в настройке которого указано, что требуется
запроса в СМЭВ. ручная обработка заказа перед формированием
запроса в СМЭВ.
2) Задачи на формирование заказа в СМЭВ
на сервере должны создаваться после выпол- 2) На форме обработки задачи должны выво-
нения задачи на формирование заказа в СМЭВ диться подсказки о необходимых действиях
в АРМ, если в настройке этапа указано, что тре- пользователя.
буется ручная обработка заказа перед форми-
рованием запроса в СМЭВ. 3) На форме обработки задачи должны быть
доступны следующие функции:
3) Задачи на формирование заказа в СМЭВ
на сервере должны быть недоступны для обра- —— просмотреть по какой услуге создано дело;
ботки пользователем, но должны отображаться
в списке задач, для возможности просмотра —— просмотреть кто является адресатом запроса;
изменений статусов задачи.
—— просмотреть к какому делу относится задача;
4) В процессе выполнения отправки запроса
в СМЭВ статус задачи должен изменяться в со- —— перейти в карточку дела для просмотра под-
ответствии с этапом отправки: задача создана; робной информации по делу.
ждет ответа из СМЭВ; ответ из СМЭВ получен.
4) На форму обработки задачи должен выво-
5) Запрос должен формироваться в соответ- диться список документов, данные из полей
ствии с настройками этапа «Формирование которых используются при формировании за-
заказа в СМЭВ», поля запроса должны за- проса в СМЭВ.
полняться данными, введенными при приеме
документов от заявителя в поля документов, 5) Для каждого документа, значения полей кото-
с которыми связаны поля запроса. рого используются при формировании запроса
в СМЭВ, должны быть доступны возможности:
6) В случае успешного получения результа-
та запроса из СМЭВ в деле должен создаться —— просмотреть значения полей документа;
документ-результат запроса в соответствии
с настройками этапа запроса в СМЭВ, в поля —— просмотреть прикрепленные файлы;
которого в соответствии с привязками должны
сохраниться данные, полученные с результа- —— при необходимости отсканировать документы.
том запроса.
6) Пользователь должен иметь возможность
7) При успешном выполнении запроса задача отметить, что значения полей документа
на отправку запроса в СМЭВ на сервере долж- проверены.
на завершаться. Дело, по которому выполнен
запрос в СМЭВ, должно перейти на следую-
щий этап в соответствии с маршрутом испол-
нения дела.

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

—— отложить исполнение задачи: —— указать, что заказ сформирован успешно:

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


чину, по которой исполнение задачи от- обработка задачи на формирование за-
кладывается; проса в СМЭВ в АРМе, должна создаться
задача типа «Формирование запроса
должна быть возможность указать дату в СМЭВ (на сервере)», дальнейшая об-
и время, когда пользователь планирует работка которой должна выполняться
вернуться к исполнению задачи; в соответствии с требованиями к обра-
ботке задач такого типа.
должна быть возможность оставить
комментарий; 3.2.5.3.9 Выполнение задачи «Оповещение
заявителя»
отложенная задача должна назначать-
ся пользователю, который ее отложил, 1) Задачи типа «Оповещение заявителя» долж-
и должна быть недоступна для обработки ны создаваться, когда в результате обработки
другим пользователям. других задач требуется оповещение заявителя.
Например: получен результат оказания услуги,
—— отказаться от исполнения задачи: документы заявителя некорректны, от заявителя
требуются дополнительные документы.
должна быть возможность указать причи-
ну, по которой пользователь отказывается 2) На форме обработки задачи должны выво-
от исполнения задачи; диться подсказки о необходимых действиях
пользователя.
должна быть возможность оставить до-
полнительный комментарий о причинах 3) На форме обработки задачи должны быть
отказа заявителя от исполнения задачи; доступны следующие возможности:

задача, от исполнения которой отказал- —— просмотреть контактную информацию заявителя,


ся один из пользователей, должна быть оповещение которого выполняется;
доступна для обработки другим поль-
зователям. —— перейти к просмотру подробной информации
о заявителе, оповещение которого выполняется;
—— вернуть дело на доработку сотруднику, приняв-
шему документы от заявителя: —— просмотреть основную информацию о деле,
с которым связано оповещение заявителя;
должна быть доступна возможность ука-
зать комментарий о причинах возврата —— перейти к просмотру подробной информа-
дела на доработку; ции о деле, с которым связано оповещение
заявителя.
после возврата дела на доработку на со-
трудника, принявшего документы по делу, 4) Пользователь должен иметь возможность
должна быть назначена задача «Дора- просмотреть тему оповещения и дополнитель-
ботка дела». ную информацию, а также комментарий, остав-
ленный пользователем при обработке задачи,
—— указать, что документы заявителя некорректны: обработка которой привела к созданию задачи
на оповещение.
должна быть доступна возможность ука-
зать комментарий о причинах некор- 5) Пользователю должна быть доступна воз-
ректности документов заявителя; можность указать каким способом выполнено
оповещение заявителя:
дело, по которому была обработана за-
дача, должно вернуться на этап приема —— по телефону;
документов;
—— по электронной почте;
по данному делу должна быть постав-
лена задача на оповещение заявителя —— по почте;

40
—— лично при обращении заявителя. —— успешная обработка задачи не должна приво-
дить к переводу дела на новый этап маршрута
6) Пользователь должен иметь возможность исполнения дела.
сформировать печатную форму уведомле-
ния заявителя, которая может быть отправ- 3.2.6 Подсистема электронного архива
лена по электронной почте или почтовым
отправлением. 3.2.6.1 Список (реестр) дел

7) При оповещении заявителя по телефону 1) В системе должен быть предусмотрен список


пользователь должен иметь возможность со- (реестр) дел об оказании услуг.
вершить исходящий вызов.
2) В списке дел должны отображаться дела, найден-
8) Пользователь должен иметь возможность ные в результате поиска. Требования к поиску дел
указать результат обработки задачи: изложены в пункте 4.2.6.2 «Поиск дел».

—— отложить исполнение задачи: 3) В списке дел должна быть доступна фильтрация


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

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

должна быть возможность оставить до- —— сформировать печатную форму реестра всех
полнительный комментарий о причинах найденных дел;
отказа заявителя от исполнения задачи;
—— сформировать печатную форму реестра вы-
задача, от исполнения которой отказал- бранных дел.
ся один из пользователей, должна быть
доступна для обработки другим поль- 3.2.6.2 Поиск дел
зователям.
1) В системе должна быть реализована возможность
—— отменить задачу: поиска дел, созданных в системе в процессе оказа-
ния услуг, по параметрам самого дела и связанных
должна быть возможность указать при- с делом объектов.
чину отмены задачи;
2) Должен быть доступен поиск по следующим па-
должна быть возможность оставить до- раметрам дела:
полнительный комментарий о причинах
отмены задачи. —— номер дела;

—— указать, что оповещение заявителя выполне- —— н о м е р ко м п л е кс н о го д ел а , в кото р о е


но успешно: входит дело;

41
—— дата создания дела; 5) Фильтры, заданные по различным параметрам
объектов, должны накладываться друг на друга при
—— дата завершения дела; поиске дел.

—— дата передачи дела в архив; 3.2.6.3 Просмотр подробной информации о деле

—— статус дела; 1) При просмотре подробной информации о деле


должна быть возможность просмотреть параметры
—— ведомство, оказывающее услугу, по которой самого дела и связанных с делом объектов.
создано дело;
2) Должна быть доступна возможность просмотреть
—— услуга, по которой создано дело; следующие параметры дела:

—— вариант услуги, по которому создано дела; —— номер дела;

—— подразделение, пользователем которого со- —— уникальный код дела;


здано дело;
—— заявитель по делу;
—— сотрудник, создавший дело;
—— дата создания дела;
—— сотрудник, принявший документы;
—— дата завершения дела;
—— сотрудник, получивший результат;
—— дата передачи дела в архив;
—— сотрудник, выдавший результат оказания дела
заявителю; —— статус дела;

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

3) Должен быть доступен поиск дел по следующим —— вариант услуги, по которому создано дела;
параметрам заявителя по делу:
—— сотрудник, создавший дело;
—— тип заявителя — физическое лицо, юридическое
лицо или индивидуальный предприниматель; —— сотрудник, принявший документы;

—— параметры клиента физического лица (ФИО, —— сотрудник, получивший результат;


дата рождения, пол, СНИЛС, ИНН, гражданство
и т. д.); —— сотрудник, выдавший результат оказания дела
заявителю;
—— параметры клиента юридического лица или
индивидуального предпринимателя (организа- —— место хранения дела в архиве;
ционно-правовая форма, наименование, ИНН,
КПП, ОГРН, ОГРНИП и т. д.). —— подразделение, в котором дело создано;

4) Должен быть доступен поиск дел по параметрам —— подразделение, которое будет выполнять об-
документов в деле: работку дела;

—— должна быть доступна возможность указать —— подразделение, в котором должен быть выдан
тип документа в деле, по параметрам которого результат оказания дела;
необходимо выполнить поиск;
—— подразделение, в котором дело находится в те-
—— должна быть доступна возможность указать кущий момент;
искомое значение одного или нескольких полей
документа; —— стоимость оказания услуги, в случае если дело
создано по услуге, предоставляемой ЦОУ
—— должна быть доступна возможность поиска дел за плату;
по наличию прикрепленных файлов-вложений
к документам в деле. —— номер договора на оказание услуги, в случае
если дело создано по услуге, предоставляемой
ЦОУ за плату;

42
—— признак получения согласия заявителя на уча- —— Должна быть доступна возможность перейти
стие в СМС-опросе оценки качества предостав- к просмотру подробной информации по ка-
ления услуги; ждому документу.

—— плановая длительность обработки дела; —— При просмотре подробной информации


о документе должны отображаться следующие
—— отклонение от плановой длительности обра- параметры:
ботки дела.
этап, на котором документ был соз-
3) Должна быть доступна возможность просмотреть дан в деле;
информацию об этапах маршрута варианта услуги,
по которому создано дело. Для каждого этапа долж- дата получения документа;
на выводиться следующая информация:
дело, к которому относится документ;
—— название этапа;
поля документа, заполненные значения-
—— плановая длительность этапа; ми, введенными при создании докумен-
та в деле;
—— текущий статус этапа;
должна быть доступна возможность
—— стоимость этапа, в случае если дело создано просмотреть файлы, прикрепленные
по услуге, предоставляемой ЦОУ за плату; к документу.

—— отклонение длительности исполнения этапа 7) Должна быть доступна возможность просмотреть


от плановой длительности. журнал всех событий по делу, которые были созда-
ны в процессе оказания дела. О каждом событии
4) Должна быть возможность просмотреть инфор- по делу должна выводиться следующая информация:
мацию о заявителях по делу. Для каждого заявителя
должна быть возможность перейти к просмотру —— дата и время создания события по делу;
подробной информации о заявителе.
—— тип события;
5) Должна быть возможность просмотреть список
обращений заявителя в ЦОУ в рамках оказания —— заявитель, с которым связано событие по делу
дела. О каждом обращении должна выводиться (в случае если по делу несколько заявителей);
следующая информация:
—— специалист, в результате действий которого
—— дата и время обращения; было создано событие по делу;

—— тип обращения; —— комментарий к событию по делу;

—— подразделение ЦОУ, в которое обращался —— наименование ведомства, взаимодействие с ко-


заявитель; торым выполнялось, должно отображаться для
событий, связанных со взаимодействием ЦОУ
—— сотрудник, обслуживающий заявителя; с ведомством;

—— канал обращения (личное обращение, обраще- —— канал оповещения должен отображаться для
ние в колл-центр). событий, связанных с оповещением заявителя.

6) Должна быть возможность просмотреть список 8) Должна быть возможность просмотреть список
документов в деле. задач, созданных по делу. Для каждой задачи долж-
на выводиться следующая информация:
—— Должен выводится полный список документов,
созданных в процессе оказания дела заявителю —— номер задачи;
(документы принятые от заявителя, документы
сформированные в ЦОУ, документы, полученные —— дата и время создания задачи;
из ведомств).
—— тип задачи;
—— Для каждого документа должно указываться
число оригиналов и копий, которые в настоящий —— текущий статус задачи;
момент находятся в ЦОУ.

43
—— исполнитель; 4) При создании места хранения должна быть до-
ступна возможность определить тип места хране-
—— этап дела, к которому относится задача; ния (склад, зал, стеллаж, полка и т. д.) и номер, либо
буквенное обозначение.
—— подразделение, к которому относится задача;
5) Должна быть доступна возможность настройки
—— плановое время начала и окончания обработ- древовидной структуры архива.
ки задачи;
6) Должна быть доступна возможность изменения
—— фактическое время начала и окончания обра- уровня вложенности места хранения.
ботки задачи;
7) Должна быть доступна возможность настрой-
—— комментарий, оставленный пользователем, об- ки порядка отображения дочерних мест хранения
рабатывавшим задачу. одного уровня.

9) При просмотре подробной информации о деле 3.2.7 Подсистема интеграции с ЕСИА


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

10) При просмотре подробной информации о деле 3) Сценарии управления учетной записью в ЕСИА долж-
должны быть доступны следующие функции: ны быть доступны при обслуживании заявителя в каче-
стве одной из тем обращения в сценарии «Регистрация
—— формирование версии для печати, содержащей нового обращения».
краткую информацию о деле, текущем статусе
дела, этапе на котором находится дело; 4) Должны быть реализованы следующие сценарии
управления учетной записью в ЕСИА:
—— формирование истории дела — печатной формы,
содержащей подробную информацию о деле: —— регистрация новой учетной записи;
общую информацию о деле, информацию
об этапах маршрута дела, о документах в деле, —— подтверждение учетной записи;
о событиях по делу.
—— восстановление учетной записи;
—— отправка на почту версии для печати с краткой
информацией о деле. —— проверка статуса запроса.

11) Пользователям с соответствующими правами 3.2.7.1 Регистрация новой учетной записи в ЕСИА
должна быть доступна возможность изменять поля
дела и поля документов в деле. 1) Сценарий регистрации учетной записи в ЕСИА
должен быть доступен только для физических лиц.
3.2.6.4 Настройка структуры электронного архива
2) В данном сценарии идентификация в системе
1) В системе должна быть возможность настроить заявителей — граждан Российской Федерации долж-
структуру электронного архива, которая будет по- на выполняться только по паспорту гражданина
вторять структуру физического архива, имеюще- Российской Федерации, заявителей — иностранных
гося в ЦОУ. граждан и лиц без гражданства — по документу
удостоверяющему личность, по которому заявителю
2) Должна быть возможность настроить собствен- был выдан СНИЛС.
ную структуру электронного архива для каждого
подразделения ЦОУ. 3) Для регистрации новой учетной записи в ЕСИА
должна использоваться операция «Зарегистрировать
3) Должна быть возможность добавить новое место подтвержденную учетную запись в ЕСИА с отправкой
хранения, удалить существующее место хранения. пароля для первого входа на контактные данные»
сервиса СМЭВ «Сервис регистрации пользователей

44
Единой системы идентификации и аутентификации» 7) Система должна информировать пользователя
(SID0003923). о результатах выполнения запроса к ЕСИА.

4) Система должна обеспечивать передачу в ЕСИА 8) Если в ответе на запрос получено сообщение
всех данных, необходимых для регистрации под- об ошибке, то пользователь должен иметь воз-
твержденной учетной записи. При этом не должен можность внести изменения в данные и повторить
требоваться повторный ввод данных, известных выполнение запроса, либо перейти к регистрации
о заявителе после его идентификации в системе. новой учетной записи заявителя в ЕСИА.

5) Должна быть реализована возможность подписа- 9) Если запрос выполнен успешно, то для пользова-
ния заявки на регистрацию в ЕСИА ЭП-СП оператора, теля должна выводиться соответствующая информа-
обслуживающего заявителя. ция, работа со сценарием подтверждения учетной
записи заявителя в ЕСИА завершается.
6) Система должна информировать пользователя
о результатах выполнения запроса к ЕСИА. 3.2.7.3 Восстановление учетной записи

7) Если в ответе на запрос получено сообщение 1) Сценарий восстановления учетной записи в ЕСИА
об ошибке, то пользователь должен иметь возмож- предназначен для восстановления учетной записи
ность внести изменения в данные и повторить вы- в ЕСИА заявителя.
полнение запроса.
2) Сценарий восстановления учетной записи в ЕСИА
8) Если запрос выполнен успешно, то для пользова- должен быть доступен только для физических лиц.
теля должна выводиться соответствующая инфор-
мация, работа со сценарием регистрации учетной 3) Идентификация заявителей в системе в рамках
записи заявителя в ЕСИА завершается. данного сценария должна быть доступна только
по паспорту гражданина РФ, либо по документу,
3.2.7.2 Подтверждение учетной записи в ЕСИА удостоверяющему личность, по которому был выдан
СНИЛС заявителю иностранному лицу или лицу без
1) Сценарий подтверждения учетной записи в ЕСИА гражданства.
предназначен для подтверждения упрощенной
учетной записи в ЕСИА заявителя. 4) Для восстановления учетной записи в ЕСИА долж-
на использоваться операция «Восстановить доступ
2) Сценарий подтверждения учетной записи в ЕСИА к учётной записи ЕСИА с выдачей пароля для входа»
должен быть доступен только для физических лиц. сервиса СМЭВ «Сервис регистрации пользователей
Единой системы идентификации и аутентификации»
3) Идентификация заявителей в системе в рамках (SID0003923).
данного сценария должна быть доступна только
по паспорту гражданина РФ, либо по документу, 5) Система должна обеспечивать передачу в ЕСИА
удостоверяющему личность, по которому был выдан всех данных, необходимых для восстановления
СНИЛС заявителю иностранному лицу или лицу без учетной записи. При этом не должен требоваться
гражданства. повторный ввод данных, известных о заявителе
после его идентификации в системе.
4) Для подтверждения учетной записи в ЕСИА
должна использоваться операция «Подтвердить 6) Должна быть реализована возможность под-
личность гражданина РФ или иностранного гражда- писания заявки на подтверждение учетной за-
нина в ЕСИА» сервиса СМЭВ «Сервис регистрации писи в ЕСИА ЭП-СП оператора, обслуживающего
пользователей Единой системы идентификации заявителя.
и аутентификации» (SID0003923).
7) Система должна информировать пользователя
5) Система должна обеспечивать передачу в ЕСИА о результатах выполнения запроса к ЕСИА.
всех данных, необходимых для подтверждения
учетной записи. При этом не должен требоваться 8) Если в ответе на запрос получено сообщение
повторный ввод данных, известных о заявителе об ошибке, то пользователь должен иметь возмож-
после его идентификации в системе. ность внести изменения в данные и повторить вы-
полнение запроса.
6) Должна быть реализована возможность под-
писания заявки на подтверждение учетной за- 9) Если запрос выполнен успешно, то для пользова-
писи в ЕСИА ЭП-СП оператора, обслуживающего теля должна выводиться соответствующая информа-
заявителя. ция, работа со сценарием восстановления учетной
записи заявителя в ЕСИА завершается.

45
3.2.7.4 Проверка статуса запроса 3.2.8.1 Сбор и отправка оценок качества предо-
ставления государственных и муниципальных услуг
1) Сценарий проверки статуса запроса на управ-
ление учетной записью в ЕСИА предназначен для 1) В системе должна быть реализована возмож-
проверки статусов заявок заявителя на управление ность сбора оценок качества предоставления услуг
учетной записи в ЕСИА. по следующим каналам:

2) Сценарий проверки статуса запроса должен быть —— в информационных киосках (инфоматах);


доступен только для физических лиц.
—— в окне оператора на планшетных устройствах;
3) Идентификация заявителей в системе в рамках
данного сценария должна быть доступна только —— посредством обзвона заявителей.
по паспорту гражданина РФ, либо по документу,
удостоверяющему личность, по которому был выдан 3.2.8.1.1 Оценка качества предоставления ус-
СНИЛС заявителю иностранному лицу или лицу без луги заявителем в информационном киоске
гражданства. (инфомате)

4) В сценарии должна быть доступна возможность 1) Система должна предоставлять заявителям


проверить статус любой заявки заявителя из чис- возможность оценить качество предоставлен-
ла направленных из системы, либо проверить ных услуг в сценарии в информационном ки-
статус заявки, выполненной вне системы, по ее оске (инфомате).
идентификатору.
2) Оценка качества оказания услуги должна
5) Для запроса статуса заявки на управление учет- выполняться по номеру дела. Одно дело должна
ной записью в ЕСИА должна использоваться опе- быть возможность оценить только один раз.
рация «Проверить статус заявки на выполнение
операции» сервиса СМЭВ «Сервис регистрации 3) Оценка качества оказания услуги должна вы-
пользователей Единой системы идентификации полняться по анкете, полученной от ИАС МКГУ.
и аутентификации» (SID0003923).
4) На формы сценария должны выводится во-
6) Система должна обеспечивать передачу в ЕСИА просы анкеты с вариантами ответов на них.
всех данных, необходимых для запроса статуса заяв- Заявитель должен иметь возможность выбрать
ки управления учетной записью. При этом не должен один из вариантов ответа на вопрос.
требоваться повторный ввод данных, известных
о заявителе после его идентификации в системе. 5) Сценарий оценки качества оказания услуги
заявителем в информационном киоске (ин-
7) Система должна информировать пользователя фомате) должен быть адаптирован под сен-
о результатах выполнения запроса к ЕСИА. сорный экран.

8) Если в ответе на запрос получено сообщение 3.2.8.1.2 Оценка качества предоставления


об ошибке, то пользователь должен иметь возмож- услуги заявителем с помощью планшетных
ность внести изменения в данные и повторить вы- устройств
полнение запроса.
1) При обслуживании заявителя по сценариям,
9) Если запрос выполнен успешно, то для пользова- связанным с делом (прием документов, выдача
теля должна выводиться соответствующая информа- результатов предоставления услуги), заявитель
ция, работа со сценарием восстановления учетной должен иметь возможность оценить качество
записи заявителя в ЕСИА завершается. оказания услуги с помощью сценария оценки
качества предоставления услуг на планшетном
3.2.8 Подсистема интеграции с ИАС МКГУ устройстве, установленном в окне оператора.

1) Подсистема интеграции с ИАС МКГУ должна обеспе- 2) Сценарий оценки качества оказания услуги
чивать следующие возможности: на планшетном устройстве должен быть до-
ступен только во время обслуживания заяви-
—— сбор и отправка оценок качества предоставле- теля по указанным темам. После завершения
ния государственных и муниципальных услуг; сценария обслуживания заявителя в системе
сценарий оценки качества оказания услуги
—— сбор и отправка фактов согласия заявителей на планшетном устройстве должен автомати-
на участие в СМС-опросе оценки качества ока- чески завершаться.
зания федеральных услуг.

46
3) Одно обращения заявителя по делу (прием 4) Отправка фактов согласия и телефонных
документов или выдача результатов предостав- номеров заявителей должна выполняться по-
ления услуги) должна быть доступна возмож- средством сервиса СМЭВ.
ность оценить только один раз.
5) Должна быть возможность настроить рас-
4) Оценка качества оказания услуги должна вы- писание отправки фактов согласия на участие
полняться по анкете, полученной от ИАС МКГУ. в СМС-опросе и телефонных номеров заявите-
лей в ИАС МКГУ.
5) На формы сценария должны выводится во-
просы анкеты с вариантами ответов на них. 6) По каждому подразделению ЦОУ должен
Заявитель должен иметь возможность выбрать формироваться отдельный пакет фактов со-
один из вариантов ответа на вопрос. гласия на участие в СМС-опросе и телефонных
номеров заявителей для отправки в ИАС МКГУ.
6) Сценарий оценки качества оказания услу-
ги на планшетных устройствах должен быть 3.2.9 Подсистема интеграции с ЕПГУ
адаптирован под сенсорный экран.
1) Система должна быть интегрирована с ЕПГУ в части
3.2.8.1.3 Отправка оценок качества предостав- передачи статусов дел, созданных в системе, на ЕПГУ,
ления услуг в ИАС МКГУ с целью предоставления заявителю возможности от-
слеживать изменения статусов дел, созданных в ЦОУ,
1) В системе должна выполняться отправка в личном кабинете на ЕПГУ.
оценок качества предоставления услуг, полу-
ченных от заявителей, в ИАС МКГУ. 2) После обращения заявителя в ЦОУ за оказанием
услуги и создания в системе дела должна выполнять-
2) Отправка оценок качества предоставления ся отправка сведений о созданном деле (заявлении)
услуг должна выполняться с помощью сервиса на ЕПГУ посредством сервиса СМЭВ.
СМЭВ приема оценок из внешних систем.
3) После успешной отправки заявления на ЕПГУ должна
3) Должна выполняться пакетная отправка оце- выполняться отправка на ЕПГУ информации об изме-
нок качества оказания услуг в ИАС МКГУ. нении статуса дела по мере изменения его статуса.
Отправка статусов дела должна выполняться посред-
4) Должна быть возможность настроить распи- ством сервиса СМЭВ.
сание отправки оценок в ИАС МКГУ.
3.2.10 Подсистема интеграции с ГИС ГМП
5) По каждому подразделению ЦОУ должен
формироваться отдельный пакет оценок для 1) Система должна быть интегрирована с ГИС ГМП по-
отправки в ИАС МКГУ. средством сервиса СМЭВ.

6) Число оценок в одном пакете не должно 2) Подсистема интеграции с ГИС ГМП должна обеспе-
превышать 10 тысяч. чивать следующие возможности:

3.2.8.2 Сбор и отправка фактов предоставления —— выполнение запроса сведений о платежах


федеральных для участия заявителей на уча- в ходе приема документов от заявителя;
стие в СМС-опросе оценки качества
—— проверка начислений и платежей заявителя
1) В процессе обслуживания заявителей по фе- в виде отдельной темы обращения в сценарии
деральным услугам система должна предо- регистрации нового обращения.
ставлять оператору возможность принять факт
согласия заявителя на участие в СМС-опросе 3.2.10.1 Запрос сведений о платежах в ходе
оценки качества оказания федеральных услуг. приема документов от заявителя

2) В случае согласия заявителя на участие 1) При обслуживании заявителя по услуге,


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

47
3) Пользователь должен иметь возможность 3) При получении результата оказания услуги из ве-
проверить платеж по идентификатору платель- домства заявителю по делу должно направляться СМС-
щика, либо по идентификатору начисления. уведомление содержащее сведения о результатах вы-
полнения заказа:
4) Результаты выполнения запроса должны
выводиться на форму, пользователь должен —— получен результат услуги — направляется в слу-
иметь возможность выбрать один из платежей чае получения положительного или отрицатель-
информация о которых получена. ного результата заказа;

5) В деле должна сохраняться информация —— получена информация для заявителя по услу-


о дате платежа. ге — направляется в случае, если из ведомства
получен результат, который требует участия зая-
6) Результат выполнения запроса не должен вителя для дальнейшего продолжения процесса
влиять на возможность продолжения обслу- оказания дела.
живания заявителя.
4) В системе должна вестись история отправленных
3.2.10.2 Проверка начислений и платежей за- СМС-уведомлений.
явителя в виде отдельной темы обращения
сценария регистрации нового обращения 5) Система должна получать статусы исполнения отправ-
ки СМС-уведомлений. Должна быть возможность просмо-
1) В ходе обслуживания заявителя должна быть треть информацию о текущем статусе СМС-уведомления:
возможность запросить сведения о начисле- сообщение отправлено, сообщение доставлено.
ниях и платежах заявителя в виде отдельной
темы обращения сценария регистрации нового 3.2.12 Подсистема анализа и статистики
обращения.
1) В составе Системы должен быть разработан набор
2) Система должна предоставлять возможность аналитических и статистических отчетов.
выполнять следующие запросы к ГИС ГМП:
2) В набор отчетов системы должны входить отчеты,
—— запрос неоплаченных начислений; позволяющие получать такие сведения как:

—— запрос начислений и статусов их сопоставления —— Количество обращений за период


с платежами;
—— Количество проведенных консультаций
—— запрос начислений, не полностью сопоставлен-
ных с платежами; —— Количество принятых пакетов документов

—— запрос всех платежей заявителя; —— Количество выданных результатов ока-


зания услуг
—— запрос платежей, не сопоставленных с на-
числениями. 3) Должна обеспечиваться детализация указанных све-
дений в следующих разрезах:
3) Должна быть доступна возможность выпол-
нения запроса сведений по идентификатору —— По подразделениям ЦОУ
плательщика, либо идентификатору начисления.
—— По сотрудникам ЦОУ
4) Должна быть доступна возможность вы-
полнения любого числа запросов начислений —— По организациям, оказывающим услуги (ведом-
и платежей в ходе одного обращения заявителя. ствам, поставщикам негосударственных услуг)

3.2.11 Подсистема оповещения —— По услугам

1) В системе должна быть реализована возможность —— По видам услуг (федеральные, региональные,


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

48
5) Детальные требования к отчетности в Системе —— фактический адрес;
должны быть разработаны на стадии «Техническое
проектирование». —— банковские реквизиты;

3.2.13 Подсистема управления отношениями с постав- —— перечень лиц, имеющих право подписи:
щиками услуг, предоставляемых в ЦОУ
должность;
В Системе должно быть предусмотрено:
ФИО;
1) Ведение реестра негосударственных услуг, предо-
ставляемых в ЦОУ. основания (устав или доверенность).

2) Ведение реестра поставщиков негосударственных 2) В системе должен быть реализован учет до-
услуг, предоставляемых в ЦОУ. говоров с поставщиками услуг. Для каждого до-
говора должен обеспечиваться учет следующей
3) Учет расчетов с заявителями по негосударственным информации:
услугам, предоставляемым в ЦОУ.
—— поставщик, с которым заключен договор;
4) Учет расчетов с поставщиками негосударственных
услуг, предоставляемых в ЦОУ. —— дата начала действия договора;

3.2.13.1 Ведение реестра негосударственных услуг, —— дата окончания действия договора;


предоставляемых в ЦОУ
—— условия оплаты услуг (за каждую услугу, сводно
1) Должно обеспечиваться создание, изменение за месяц и т. д.);
удаление негосударственных услуг.
—— список дополнительных соглашений;
2) Должна обеспечиваться настройка процессов пре-
доставления негосударственных услуг в соответствии —— список услуг поставщика, оказываемых по дан-
с требованиями, предъявляемыми к подсистеме вво- ному договору:
да и хранения регламентов предоставления услуг.
услуга из реестра негосударственных ус-
3) Должна обеспечиваться возможность предо- луг, предоставляемых в ЦОУ;
ставления негосударственных услуг в соответствии
с требованиями, предъявляемыми к подсистеме уникальный реестровый номер услу-
автоматизированного исполнения регламентов услуг. ги в ОРУП;

3.2.13.2 Ведение реестра поставщиков негосудар- список тарифов услуги с данным по-
ственных услуг, предоставляемых в ЦОУ ставщиком:

1) В системе должен быть реализован учет постав- a. дата начала действия тарифа;
щиков негосударственных услуг. Для каждого постав-
щика должно обеспечиваться хранение следующей b. дата окончания действия тарифа;
информации:
c. п л а т а з а у с л у г у, п о л у ч а е м а я
—— краткое наименование; с заявителя;

—— полное наименование; d. размер комиссии ЦОУ.

—— организационно-правовая форма; 3) Каждое дополнительное соглашение является


объектом «Договор», подчиненным основному дого-
—— ИНН; вору (обладает всеми свойствами договора) и может
изменять любое условие основного договора (любое
—— КПП; свойство, которым обладает договор).

—— ЕГРН; 4) Должна обеспечиваться возможность просмотра


действующих условий договора с учетом всех до-
—— юридический адрес; полнительных соглашений.

—— почтовый адрес;

49
5) Должна обеспечиваться возможность выполнения 5) Должна обеспечиваться возможность информа-
следующих действий с договором: ционного взаимодействия между АИС ЦОУ и систе-
мой учета платежей, используемой в организации,
—— пролонгация договора; на базе которой создано ЦОУ:

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


по договору; ванных обязательств;

—— расторжение договора. —— прием сведений о поступивших платежах из си-


стемы учета платежей в АИС ЦОУ.
6) Должно обеспечиваться рассмотрение заявок
поставщиков услуг, поданных с портала и из личного 6) В случае отсутствия информационного взаимо-
кабинета портала: действия между АИС ЦОУ и системой учета плате-
жей должна обеспечиваться возможность ввода
—— На регистрацию нового поставщика сведений о платежах и квитирования обязательств
и платежей пользователем АИС ЦОУ.
—— На заключение договора
7) Должна быть реализована возможность учета
—— На расторжение договора актов оказания услуг заявителям.

—— На пролонгацию договора 3.2.13.4 Учет расчетов с поставщиками негосудар-


ственных услуг, предоставляемых в ЦОУ
3.2.13.3 Учет расчетов с заявителями по негосу-
дарственным услугам, предоставляемым в ЦОУ 1) Должна быть реализована возможность учета
обязательств ЦОУ перед поставщиками негосудар-
1) В процессе оказания негосударственной услуги ственных услуг, оказываемых в ЦОУ на основании
должна обеспечиваться возможность сформировать фактов оказания услуг и условий договоров, за-
обязательство заявителя по оплате негосударствен- ключенных между ЦОУ и поставщиками негосу-
ной услуги в соответствии с условиями договора дарственных услуг.
об оказании услуги с выбранным поставщиком.
2) Должна обеспечиваться возможность форми-
2) В сформированном обязательстве должны фик- рования платежных поручений для исполнения
сироваться следующие сведения: обязательств ЦОУ перед поставщиками.

—— заявитель, у которого возникло обязательство 3) Должна обеспечиваться периодичность фор-


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

—— сумма; 5) Должна обеспечиваться возможность информа-


ционного взаимодействия между АИС ЦОУ и систе-
—— срок исполнения обязательства (срок оплаты). мой учета платежей, используемой в организации,
на базе которой создано ЦОУ:
3) Должна обеспечиваться возможность формирова-
ния как разовых, так и периодических обязательств. —— передача сформированного обязательства в си-
Периодическое обязательство представляет собой стему учета платежей;
набор связанных разовых обязательств, для каждого
из которых известны все параметры обязательства, —— прием сведений о совершенных платежах из си-
определенные выше. стемы учета платежей в АИС ЦОУ.

4) Должна обеспечиваться возможность учета фак- 6) В случае отсутствия информационного взаимо-


тов исполнения заявителями обязательств по оплате действия между АИС ЦОУ и системой учета плате-
негосударственных услуг — квитирования обяза- жей должна быть реализована возможность ввода
тельств и платежей. сведений о платежах и квитирования обязательств
и платежей пользователем АИС ЦОУ.

50
7) Должны быть реализована возможность выгрузки 2) В режиме поиска поставщиков по заданным
платежей и статусов их квитирования на портал параметрам должен обеспечиваться поиск по-
поставщиков в личный кабинет поставщика него- ставщика по сведениям, выведенным в список
сударственных услуг. поставщиков негосударственных услуг.

8) Должна быть реализована возможность учета 3) В режиме просмотра сведений о выбранном


актов между ЦОУ и поставщиками услуг. поставщике должны выводиться следующие
сведения:
9) Должна быть реализована возможность выгрузки
сформированных актов на портал поставщиков —— краткое наименование;
в личный кабинет поставщика негосударствен-
ных услуг. —— полное наименование;

3.2.13.5 Портал поставщиков негосудар- —— организационно-правовая форма;


ственных услуг
—— ИНН;
В Системе должен быть реализован портал постав-
щиков негосударственных услуг, обеспечивающий —— КПП;
следующие функциональные возможности:
—— ЕГРН;
1) Просмотр сведений о поставщиках негосудар-
ственных услуг ЦОУ —— юридический адрес;

2) Просмотр сведений о негосударственных услугах —— почтовый адрес;


ЦОУ, оказываемых поставщиками услуг
—— фактический адрес;
3) Подача поставщиком заявки на внесение в реестр
поставщиков —— банковские реквизиты;

4) Личный кабинет поставщика негосудар- —— список услуг данного поставщика:


ственных услуг
наименование услуги:
3.2.13.5.1 Просмотр сведений о поставщиках
негосударственных услуг даты начала и окончания действия
договора ЦОУ с поставщиком на дан-
В общедоступном разделе портала поставщиков ную услугу;
негосударственных услуг должна обеспечивать-
ся возможность просмотра и поиска сведений плата за услугу, получаемая с заявителя;
о поставщиках.
3.2.13.5.2 Просмотр сведений о негосудар-
Должны обеспечиваться режимы просмотра ственных услугах ЦОУ, оказываемых постав-
списка поставщиков, поиска поставщиков по за- щиками услуг
данным параметрам, просмотра сведений о вы-
бранном поставщике. В общедоступном разделе портала поставщиков
негосударственных услуг должна обеспечивать-
1) В режиме просмотра списка поставщиков ся возможность просмотра и поиска сведений
должны выводиться следующие сведения о по- о негосударственных услугах, оказываемых ЦОУ.
ставщиках негосударственных услуг:
Должны обеспечиваться режимы просмотра
—— краткое наименование поставщика списка услуг, поиска услуг по заданным параме-
трам, просмотра сведений о выбранной услуге.
—— организационно-правовая форма
1) В режиме просмотра списка негосударствен-
—— ИНН ных услуг должны выводиться следующие све-
дения о негосударственных услугах:
—— КПП
—— название услуги;
—— Фактический адрес
—— категория услуги;

51
—— признак платности услуги; В составе заявки на внесение в реестр долж-
на быть возможность передать следующие
2) В режиме поиска негосударственных услуг сведения:
должен обеспечиваться поиск услуг по следу-
ющим параметрам: —— краткое наименование;

—— название услуги; —— полное наименование;

—— категория услуги; —— организационно-правовая форма;

—— жизненная ситуация (бизнес-ситуация); —— ИНН;

—— признак платности услуги; —— КПП;

—— категории заявителей, которым оказывает- —— ЕГРН;


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

—— перечень жизненных ситуаций (бизнес-ситуа- ФИО


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

—— признак платности услуги; Поданная заявка должна направляться


на рассмотрение в АИС ЦОУ в рамках процесса
—— перечень подразделений ЦОУ, в которых ока- 4.2.13.2 «Ведение реестра поставщиков него-
зывается услуга; сударственных услуг, предоставляемых в ЦОУ».

—— перечень поставщиков, которые оказыва- 3.2.13.5.4 Личный кабинет поставщика него-


ют услуги: сударственных услуг

краткое наименование Личный кабинет поставщика негосударственных


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

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


доступны следующие возможности:
3.2.13.5.3 Подача поставщиком заявки на вне-
сение в реестр поставщиков 1) Просмотр сведений о поставщике

В общедоступном разделе портала поставщиков 2) Просмотр перечня договоров с ЦОУ


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

52
4) Просмотр условий предоставления каждой 3.2.15 Подсистема взаимодействия с АИС УМФЦ
услуги, согласованных с ЦОУ:
1) Должна обеспечиваться передача сведений о за-
—— список тарифов услуги по данному договору: регистрированных в ЦОУ заявителях, обратившихся
за оказанием государственных и муниципальных услуг
—— дата начала действия тарифа; из АИС ЦОУ в АИС УМФЦ.

—— дата окончания действия тарифа; 2) Должна обеспечиваться передача сведений о соз-


данных в АИС ЦОУ делах об оказании государственных
—— плата за услугу, получаемая с заявителя; и муниципальных услуг, принятых в ЦОУ документах
на оказание государственных и муниципальных услуг
—— размер комиссии ЦОУ. из АИС ЦОУ в АИС УМФЦ.

5) Подача заявки на изменение сведений 3) Должна обеспечиваться передача сведений об из-


о поставщике менении статуса дела в УМФЦ в процессе оказания
государственной или муниципальной услуги из АИС
6) Подача заявки на заключение нового дого- УМФЦ в АИС ЦОУ.
вора, пролонгацию или расторжение существу-
ющего договора. 4) Должна обеспечиваться передача результатов оказа-
ния государственной или муниципальной услуги из АИС
7) Просмотр сведений о платежах по каждому УМФЦ в АИС ЦОУ.
договору.
5) Должна обеспечиваться передача сведений о выдаче
8) Просмотр и печать актов по каждому заявителю результатов оказания государственной или
договору. муниципальной услуги из АИС ЦОУ в АИС УМФЦ.

3.2.14 Подсистема взаимодействия с общероссий- 6) Должна обеспечиваться передача статистической


ским реестром услуг и поставщиков услуг, предостав- информации о количестве проведенных консультаций,
ляемых в ЦОУ количестве созданных дел (принятых пакетов докумен-
тов), количестве выданных результатов оказания услуг
1) Должен обеспечиваться импорт сведений о негосу- по государственным и муниципальным услугам из АИС
дарственных услугах из общероссийского реестра услуг ЦОУ в АИС УМФЦ.
и поставщиков услуг (ОРУП).
7) Информационное взаимодействие между АИС ЦОУ
2) Состав сведений о негосударственных услугах, под- и АИС УМФЦ должно строиться на базе интеграционных
лежащих импорту из ОРУП, определяется правилами веб-сервисов.
ведения ОРУП и техническими требованиями к ОРУП
и уточняется на этапе технического проектирования. 8) Состав интеграционных веб-сервисов, втрибутивный
состав и структура передаваемых данных, а также ин-
3) Допускается выполнение импорта сведений о него- формационные системы, ответственные за реализацию
сударственных услугах по расписанию либо по запросу интеграционных веб-сервисов (системы — поставщики
пользователя. сервисов и системы — потребители сервисов) должны
быть определены на этапе технического проектирования.
4) Должен обеспечиваться экспорт сведений о постав-
щиках негосударственных услуг в ОРУП. 3.2.16 Подсистема интеграции с ФРГУ

5) Должен обеспечиваться экспорт статистических све- 1) В Системе должна быть предусмотрена возможность
дений об оказании негосударственных услуг в ОРУП. загрузки сведений из ФРГУ.

6) Состав сведений, подлежащих экспорту в ОРУП, опре- 2) Должна обеспечиваться загрузка следующих сведений
деляется правилами ведения ОРУП и техническими
требованиями к ОРУП и уточняется на этапе техниче- —— о федеральных государственных услугах
ского проектирования.
—— о п р о ц ед у р а х ф ед е р а л ь н ы х го суд а р -
7) Экспорт сведений должен производиться путем об- ственных услуг
ращения АИС ЦОУ к интеграционным сервисам ОРУП.
—— о целях обращения по федеральным государ-
8) Допускается выполнение периодического экспорта ственным услугам
сведений (по расписанию) либо регулярного экспорта
сведений (по мере изменения сведений о поставщике —— о федеральных органах государственной власти,
в АИС ЦОУ). оказывающих государственные услуги

53
3) Должна обеспечиваться возможность создания ве- 7) Должна обеспечиваться возможность автоматизиро-
домств в иерархическом списке ведомств на основании ванной настройки процесса оказания услуги на осно-
сведений, загруженных из ФРГУ (см. п. 4.2.2.2). вании технологической схемы оказания услуги в ма-
шиночитаемом виде, в том числе:
4) Должна обеспечиваться возможность создания услуг
в списке услуг на основании сведений, загруженных —— Заполнение основных сведений об услуге (см.
из ФРГУ (см. п. 4.2.3.2). п. 4.2.3.2.1)

5) Должна обеспечиваться возможность установления —— Создание списка вариантов услуги (см.


соответствия между сведениями о процедурах и целях п. 4.2.3.2.2)
обращения по федеральным государственным услугам
и вариантами услуг в Системе (см. п. 4.2.3.2). —— Создание этапов маршрута оказания услуги (см.
пп. 4.2.3.2.3, 4.2.3.2.4, 4.2.3.2.5, 4.2.3.2.6, 4.2.3.2.9).
6) Должна обеспечиваться возможность загрузки
из ФРГУ технологической схемы оказания услуги в ма- —— Создание типов документов в справочнике ти-
шиночитаемом виде. пов документов (см. п. 4.2.3.6.2).

54
3.3 ТРЕБОВАНИЯ К ВИДАМ ОБЕСПЕЧЕНИЯ Либо аналогичной реляционной СУБД, обеспечи-
вающей все функциональные возможности одного
3.3.1 Требования к математическому обеспечению из перечисленных продуктов.

Требования к математическому обеспечению 3.3.4.2 Программное обеспечение веб-сервера


не предъявляются. и сервера приложений

3.3.2 Требования к информационному обеспечению Сервер приложений должен функционировать под


управлением операционной системы семейства MS
Состав, структура и способы организации дан- Windows (Windows 2008, Windows 2008R2, Windows
ных в Системе должны быть определены на стадии Server 2012, Windows Server 2012 R2, Windows
«Техническое проектирование». Server 2016).

Проектирование структуры БД Системы должно осущест- В качестве веб-сервера и сервера приложений дол-
вляться с использованием инструмента проектирования жен использоваться промышленный веб-сервер,
на основе реляционного подхода. такой как Microsoft Internet Information Services
версии 7.5 и выше, Apache Tomcat версии 7 и выше
Для обеспечения целостности данных Системы должны или аналог.
использоваться встроенные механизмы СУБД.
На сервере приложений должно быть установлено
Кодировка и значения справочных данных Системы, средство криптографической защиты информации
соответствующих общероссийским классификаторам, (КриптоПро CSP версии 3.6 и выше, ViPNet CSP вер-
должна соответствовать стандартам общероссийских сии 3.0 и выше или аналог).
классификаторов.
3.3.4.3 Программное обеспечение пользовательских
Система должна быть организована рациональным спо- рабочих мест
собом, исключающим избыточную обработку, хранение
и передачу информации. Пользовательские рабочие места должны функци-
онировать под управлением операционной систе-
Атрибутивный состав основных информационных объ- мы семейства MS Windows (Windows 7, Windows 8,
ектов Системы, данные о которых являются предметом Windows 10).
информационного обмена Системы с информационными
системами, используемыми в ЦОУ, должен включать На пользовательских рабочих местах должно быть
идентификаторы, позволяющие идентифицировать установлено следующее прикладное программное
соответствующий информационный объект в инфор- обеспечение:
мационных системах.
—— офисный пакет (Microsoft Office версии 2013
3.3.3 Требования к лингвистическому обеспечению и выше либо Apache OpenOffice версии
4.0.0 и выше):
Все прикладное программное обеспечение системы для
организации взаимодействия с пользователем должно —— средство просмотра PDF-документов;
использовать русский язык.
—— средства просмотра графических файлов с под-
3.3.4 Требования к программному обеспечению держкой форматов TIF, JPG, PNG и других;

3.3.4.1 Программное обеспечение сервера —— средства криптографической защиты информа-


баз данных ции (КриптоПро CSP версии 3.6 и выше, ViPNet
CSP версии 3.0 и выше или аналог).
Сервер СУБД должен функционировать под управ-
лением операционной системы семейства MS Доступ к Системе должен быть реализован с рабо-
Windows (Windows Server 2008, Windows Server чих станций посредством одного из веб-браузеров:
2008R2, Windows Server 2012, Windows Server 2012 Microsoft Internet Explorer 11 и выше, Google Chrome
R2, Windows Server 2016) или аналогичной ОС. 40 и выше, Chromium 40 и выше, Mozilla Firefox
40 и выше.
В качестве СУБД рекомендуется использование
одного из следующих продуктов: 3.3.5 Требования к техническому обеспечению

• Microsoft SQL Server версии 2008 и выше; Техническое обеспечение системы должно максимально
и наиболее эффективным образом использовать суще-
• PostgreSQL версии 9.3.X и выше. ствующие у Заказчика технические средства.

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

Требования к техническому обеспечению систе- —— обработку информации АИС ЦОУ;


мы должны быть уточнены на стадии «Техническое
проектирование». —— администрирование АИС ЦОУ;

3.3.6 Требования к метрологическому обеспечению —— обеспечение безопасности информа -


ции АИС ЦОУ;
Требования к метрологическому обеспечению
не предъявляются. —— управление работой персонала по обслужива-
нию АИС ЦОУ.
3.3.7 Требования к организационному обеспечению
К работе с Системой должны допускаться сотрудники,
Организационное обеспечение системы должно быть имеющие навыки работы за персональным компьюте-
достаточным для эффективного выполнения персоналом ром, ознакомленные с правилами эксплуатации и про-
возложенных на него обязанностей при осуществлении шедшие обучение работе с Системой.
автоматизированных и связанных с ними неавтомати-
зированных функций Системы.

56
4 ТРЕБОВАНИЯ К СОСТАВУ
И СОДЕРЖАНИЮ РАБОТ ПО ПОДГОТОВКЕ
ОБЪЕКТА АВТОМАТИЗАЦИИ К ВВОДУ
СИСТЕМЫ В ДЕЙСТВИЕ

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

Таблица 5.1.

№ Этап Мероприятие Результат


Разработка технического зада- Разработка и согласование технического зада-
1 Техническое задание
ния ния
Разработка структуры и состава Системы
Разработка функциональной структуры Системы
Разработка технических решений по подсисте-
мам
Разработка решений по информационному обе-
спечению

2 Техническое проектирование Разработка решений по программному обеспе- Пояснительная записка


чению к техническому проекту
Разработка решений по техническому обеспече-
нию
Разработка решений по организационному обе-
спечению
Согласование решений по связям видов обеспе-
чения между собой
Разработка подсистемы администрирования и
настройки
Разработка подсистемы ввода и хранения регла-
ментов предоставления услуг
Разработка экспертной подсистемы
Разработка подсистемы автоматизированного
исполнения регламентов предоставления услуг
Разработка подсистемы электронного архива
Разработка подсистемы интеграции с ЕСИА
Разработка подсистемы интеграции с ИАС МКГУ
Разработка подсистемы интеграции с ЕПГУ
Разработка программного обе-
3 Разработка подсистемы интеграции с ГИС ГМП Разработанная АИС ЦОУ
спечения подсистем и модулей
Разработка подсистемы оповещения
Разработка подсистемы анализа и статистики
Разработка подсистемы управления отношени-
ями с поставщиками услуг, предоставляемых в
ЦОУ

Разработка подсистемы взаимодействия с обще-


российским реестром услуг и поставщиков услуг,
предоставляемых в ЦОУ

Разработка подсистемы взаимодействия с АИС


УМФЦ

57
Разработка руководства пользователя Руководство пользователя
Разработка эксплуатационной
4 Руководство администрато-
документации Разработка руководства администратора
ра
Программа и методика ис-
Разработка программы и методики испытаний
пытаний
Протокол проведения пред-
Проведение предварительных испытаний
варительных испытаний
5 Предварительные испытания
Протокол устранения заме-
Устранение замечаний, выявленных по результа- чаний, выявленных по ре-
там предварительных испытаний зультатам предварительных
испытаний
Отчет о проведении обуче-
6 Опытная эксплуатация Обучение пользователей
ния пользователей
Акт о завершении опытной
Проведение опытной эксплуатации
эксплуатации
Протокол проведения прие-
Проведение приемочных испытаний
мочных испытаний
Протокол устранения заме-
Устранение замечаний, выявленных по результа- чаний, выявленных по ре-
там приемочных испытаний зультатам приемочных ис-
пытаний
Акт о переводе в промыш-
Сдача Системы в промышленную эксплуатацию
ленную эксплуатацию

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

Документация должна разрабатываться с учетом требований Документация должна включать следующие документы:
комплекса государственных стандартов «Информационная
технология. Комплекс стандартов на автоматизированные —— Техническое задание на разработку АИС ЦОУ;
системы»:
—— Пояснительная записка к техническому проек-
—— ГОСТ 34.601–90 «Автоматизированные системы. ту АИС ЦОУ;
Стадии создания»;
—— Программа и методика испытаний АИС ЦОУ;
—— ГОСТ 34.003–90 «Автоматизированные системы.
Термины и определения»; —— Руководство пользователя АИС ЦОУ;

—— ГОСТ 34.602–89 «Техническое задание на со- —— Руководство администратора АИС ЦОУ.


здание автоматизированной системы»;
Вся документация должна быть выполнена на русском языке
—— ГОСТ 34.201–89 «Виды, комплектность и обо- и передана заказчику в печатном виде в одном экземпляре,
значение документов при создании автомати- а также в электронном виде в одном экземпляре в формате
зированных систем»; doc, docx или pdf.

—— ГОСТ 34.603–92 «Виды испытаний автоматизи-


рованных систем»;

—— РД 50–34.698–90 «Автоматизированные си-


стемы. Требования к содержанию документов».

59