Вы можете подписаться на обновления блога по электронной почте.
Поиск
Рубрики
Подписка
Архив записей
Ссылки
- Архивы России Форум
- Архивы России в ЖЖ Сообщество
- Компания «Архивные Информационные Технологии» Автор блога
- Сайт Радика Губайдуллина Архивная компания
- Сайт Сергея Плотникова Автоматизированные архивные технологии
О предоставлении государственных услуг в электронном виде
Архивы, как известно, очень загружены сейчас исполнением запросов. Использование средств автоматизации, прием запросов по электронной почте — все это часть работы по предоставлению государственных услуг в электронном виде. Сейчас, одним из способов удаленной подачи заявления стали архивные сайты. Об организации такой работы и пойдет речь в этой статье.
Посмотрим, как архивы могут решить вопрос предоставления госуслуг, используя при этом свой сайт.
- Конечно, на сайте должна быть форма для оформления и подачи запроса прямо с сайта. Скачивание бланков заявлений не очень приветствуется, т.к. это замедляет и усложняет процесс отправки запроса. Форма может быть универсальной для всех видов запросов, тогда надо больше внимания уделить примеру заполнения, а можно сделать форму для каждого вида запроса, их не так уж и много (награждение, стаж, зарплата, репрессии, генеалогический, тематический).
- Наличие пояснительной информации об исполнении запросов поступивших по электронной почте или через сайт. В какие сроки рассматриваются, срок исполнения, наличие контактных данных для принятия к исполнению и т.д.
- Очень важно разместить на главной странице ссылку (текстом или картинкой) на раздел, где можно подать запрос или узнать о состоянии исполнения. Ссылки также должны быть на страницах об оказании услуг, об исполнении запросов, в гостевой книге, на странице с базами данных.
- Наличие возможности проверки состояния исполнения, поданного с сайта запроса. Известно, что количество звонков с вопросом о результате исполнения велико. Размещение на сайте базы данных с информацией об исполнении призвано сократить количество звонков по подобным вопросам.
- Ответ на запрос отсылается по электронной и обычной почте. В случае платных запросов ведется дополнительная переписка по электронке.
Теперь посмотрим процесс работы архивистов с запросами, полученными с сайта. В качестве примера средства автоматизации будем использовать программу «Учёт обращений граждан и организаций».
- Пришедший по электронке запрос уходит на рассмотрение и исполнение.
- В программе запрос регистрируется как поступивший с сайта, что позволит в дальнейшем получить необходимый отчет.
- В определенный период, с помощью функции программы ответственное лицо создает файл, который затем администратором сайта помещается в определенную папку на Web-сервере.
- На сайте имеется база данных, которая представляет данные из сформированного программой файла. Файл содержит информацию о регистрационном номере запроса, ФИО заявителя, дату поступления запроса, состояние исполнения (результат ответа) и дату ответа.
- Предложенная система производит на сайте поиск по ФИО заявителя, названию организации или регистрационному номеру.
Так как программа преобразовывает данные по запросам за последние полгода и содержит все поступившие в архив запросы, а не только через сайт, можно сообщать о возможности проверки состояния исполнения и другим заявителям (например, повесив объявление в приемной).
Хотелось бы узнать мнение архивистов о том, какую информацию необходимо показывать о запросе? Каким образом производить поиск? Насколько серьезно, если посетитель, производя поиск, может увидеть информацию об исполнении других запросов?
Популярность: 67%
Оставить комментарий или два
Навигация
Инфо
Запись опубликовал Елена Суслова 28 Май 2010 года и разместил в рубрике Исполнение запросов, Работа с сайтом. Запись имеет метки: Cайты, Исполнение запросов К статье есть 27 коммент.Случайные записи
Только смените уже капчу на dimoning.ru-captcha 
Поскольку занимался подобной задачей, то могу поделиться своими соображениями.
На сайте создается база данных, в которую при отправке запроса с сайта (из формы) заносится следующая информация – дата запроса, вид запроса (в случае нескольких форм) и номер запроса, который автоматически присваивается для запросов, поступивших с сайта. Персональные данные и содержание запроса в базу не записываются. Информация о ходе исполнения запросов редактируется сотрудником архива прямо с сайта, со страницы закрытой для обычных пользователей. Кроме трёх перечисленных выше полей отображаются следующие данные:
- архив – исполнитель запроса (это не всегда тот архив, куда пришёл запрос),
- ФИО исполнителя, его телефон (возможно у заявителя есть вопросы),
- ход исполнения (получен, исполняется, исполнен, отправлен),
- дата исполнения,
- дата отправки запроса (почтой, e-mail),
- примечания (например, запрос не принят к исполнению – требует уточнения сведений).
Пользователь после отправки запроса из формы получает e-mail с подтверждением и номером запроса (который, вы помните, был присвоен автоматически) и ссылкой на страницу мониторинга, по которой он сможет наблюдать за исполнением своего запроса. При необходимости можно включить функцию поиска запроса по его номеру. На мой взгляд, данные должны хранится до одного года, а может и более. У нас предполагается приём генеалогических запросов, по которым срок исполнения один год. Таким образом, срок хранения сведений не может быть меньше.
Поскольку в базе не хранятся персональные данные, т.е. информация обезличена, то пользователю и архивистам опасаться нечего.
К сожалению, я сумел создать только рабочую модель мониторинга и не успел внедрить эту систему на сайте.
Несколько лет назад мы реализовывали подобным образом построенную систему, правда она была связана с «Фондовым каталогом» и регистрировала заказы на копирование, сканирование. Она так же требовала изменения вручную состояния исполнения заказа, после чего происходило автоматическое уведомление заказчика.
В случае приема запросов, мы решили осуществлять связь с нашей программой. Для исключения контакта с данными (с целью сохранности), поступившие через форму на сайте запросы, регистрируются в программе вручную, а на сайт отправляется информация без персональных данных.
Можно было бы как у Вас присваивать номер обращения на сайте, но тогда бы у запроса было бы два номера.
Опять же файл, формируемый программой, содержит сведения обо всех запросах, поэтому на сайте можно посмотреть исполнение обращений не только поступивших через сайт.
Ну и редактирование вручную статуса исполнения нам показалось затратным для архивистов.
Вот если бы не было связи с программой учета,то реализовывали бы по такой схеме.
Согласен, в идеале должна существовать связь между данными на сайте и базой учёта запросов. Я не пробывал, но теоретически у программы должна быть возможность подключения к базе mysql, находящейся на сайте, для оперативной синхронизации сведений об исполнении запросов.
Теоретически такая возможность конечно есть, но практически большинство сайтов лежат не на своих серверах, а владельцы серверов очень неохотно дают право подключаться к своим базам MySQL извне. Поэтому вариант синхронизации через файл более универсален, хотя, конечно же, менее удобен. Можно в принципе научить программу подключаться по FTP к сайту и заливать файл в нужную папку автоматически, например в конце рабочего дня.
Думаю, что сейчас нужнее всего система, поддерживающая исполнение платных запросов – т.е. объединенная/интегрируемая с какой-либо платежной системой. Причины:
1) Большинство архивов и так перегружены работой за зарплату (ну, если это можно назвать зарплатой), и дополнительная нагрузка без дополнительных денег им не нужна. Вот если исполнение электронных запросов будет приносить копеечку, интерес со стороны архивов к таким системам, думаю, будет совсем другой.
2) Бесплатны социальные запросы, а в этом случае обычно нужна идентификация отправителя – поскольку дело касается персональных данных. Пока признанных средств для такой электронной идентификации нет. А тематические запросы – платные.
«исполнение электронных запросов»
согласно великой зеленой книжице архивиста, а точнее «Правилам организации хранения, комплектования, учета и использования документов Архивного фонда Российской Федерации и других архивных документов в государственных и муниципальных архивах, музеях и библиотеках, организациях Российской академии наук», п. 5.8
«При поступлении в архив интернет-обращения (запроса) пользователя с указанием адреса электронной почты и/или почтового адреса, ему направляется уведомление о приеме обращения (запроса) к рассмотрению или мотивированный отказ в рассмотрении. Принятое к рассмотрению обращение (запрос) распечатывается и в дальнейшем работа с ним ведется в установленном порядке.»
Нет смысла делить запросы на платные и платные из интернета. Они к сожалению попадают под одну гребенку.
Нет смысла делить запросы на платные и платные из интернета.
Что Вы говорите! Даже несмотря на то, что такая безделица, как операция оплаты, может выполняться и учитываться совсем иначе?
С тем же успехом можно заявить, что магазин и интернет-магазин – одно и то же.
Любой необразованный американец скажет Вам, что осмысленно всё, что помогает делать деньги. И он, как оптимально приспособленное к капитализму существо, будет прав!
Ссылки на зеленую книжечку в данном вопросе примерно так же уместны, как на законы царя Хаммурапи. «Правила» в скором ремени придётся в любом случае существенно переработать, поскольку они не учитывают реалий 21-го века – в них не только нет ничего осмысленного про работу с электронными документами, но и даже не предусмотрена возможность ведения современного компьютеризованного документирования и учёта деятельности обычного архива.
Смотря как подходить к вопросу о магазинах. Оба предоставляют товары и услуги, только разными способами происходит первоначальная оценка товара и доставка до дома потребителя.
Операция оплаты в государственных архивах будет идти также как «исполнение запросов» и входить в одну группу с запросами поступившими через традиционную почту или с запросами сформированными на приеме.
А до тех пор пока правила не переработали, они имеют силу и являются настольной книгой каждого архивиста. Как грится «Dura lex sed lex»
Предлагаю авторам, которые уже имеют наработки, открыть их в общий доступ либо поделится со мной, так как передо мной стоит эта задача
в качестве механизма синхронизации думаю использовать следующее
1. пользователь заполняет форму (этот этап можно взять у других)
2. в результате формируется XML документ с данными о запросе
3. полученный документ с интернет сервера отправляется посредством протокола XMPP (jabber) в архив
4. в архиве данные XML документ будет обрабатывать либо секретарь либо XMPP робот
5. во время обработки XML документ преобразуется в запись для базы данных картотеки учета
так же думаем стоит разместить список фондов и описей содержащих документы по личному составу, чтобы посетители могли понять стоит ли делать запрос в этот архив
этот механизм можно унифицировать, например сделать одинаковые формы на разных сайтах
можно сделать их даже разными и по разному реализовывать их обработку
но если разработать и везде применять стандартный XML документ запроса то можно будет делать следующее
например на пермском архиве оставляют запрос
XML документ идет в пермское управление, а там решают, что он подойдет для одного из пермских архивов или вообще направляют его в архив в другой области
если этот XML будет стандартен то любой архив сможет принять и обработать его и отправить ответную ссылку на почту посетителя
таким образом мы получим глобальную систему приема запросов
необходима лишь добрая воля и время
можно сделать еще интереснее
сделать некий сервис на котором смогут зарегистрироваться заинтересованные архивы, указать свои реквизиты и электронные адреса
взамен каждый архив получается JS вставку наподобие счетчиков
после установки вставки на сайте любого архива появляется возможность вызвать форму запроса с уже заполненными реквизитами архива
после заполнения пользователем формы и ее проверки данные будут передаваться посредством HTTPS запроса на сайт ключевого сервиса где будут обрабатываться программой-роботом
программа-робот получив данные запроса и ID архива формирует XML и отправляет по указанному у архива адресу посредством зашифрованного соединения (в протоколе XMPP имеется 2 вида шифрования — HTTPS и/или посредством личного OpenGPG ключа)
архив принимает и обрабатывает запрос, отправляет результат по адресу из формы запроса
если архив не может выполнить запрос то отправляет уведомление роботу на ключевом сервисе который должен принять решение (возможно с участием различных архивных управлений) куда переслать запрос
такая схема позволит создать единую, централизованную, универсальную и кроссплатформенную схему регистрации запросов
в идеале любой архив, даже не имеющий собственного сайта сможет иметь собственную форму запросов и разместить ее например на сайте своей администрации
при этом отпадает необходимость хранения данных на интернет серверах и заниматься обеспечение безопасности передачи данных
от любого архива потребуется лишь
зарегистрировать на сервисе (это можно сделать централизовано)
получить JID — уникальный идентификатор в XMPP сети, это тоже можно сделать централизованно, причем можно сделать и использовать лишь выделенные росархивом XMPP сервер с собственным шифрованием
отслеживать поступающие запросы — достаточно держать jabber клиент постоянно включенным
Все замечательно, только вот некоторые руководители архивов у нас странные, которые на разработках архива деньги зарабатывают. По поводу файла мы тоже думали, но остановились на электронной почте пока. В идеале бы еще общую систему учета запросов, мы уже 3 года работаем в этом направлении, у многих архивов своя специфика. А какая у вас программа используется?
Ну примерно это мы и реализовали практически, правда на локальном уровне. Структуру XML-документа согласовать действительно стоит, согласен.
ну так дайте мне хотя бы это, главное начать
Наши разработки являются коммерческим продуктом и принадлежит компании «Архивные Информационные Технологии».
а я у DiamondMax спрашиваю
и даже если это ваши разработки, то я не вижу абсолютно ничего плохого в том, что будет использоваться ваш формат
наоборот, вы сможете заявлять, что ваш формат использует в открытых системах и совместим с ними
в противном случае получится, что ваш формат НЕ используется в открытых системах и для его внедрения необходимы какие то коммерческие отчисления
я думаю, что мы понимаешь, что говорим просто о XML документе с определённой структурой
то-есть вашим может быть лишь название некоторых полей и порядок их следования
как плёхо, что тут низя исправлять собственные тексты
ps: жду вашего шага по формату, используя открытость формата и готовое коммерческое и открытое решение для его использования можно не хило попиарится с помощью открытого сообщества
Ну собственно (звездочкой отмечены обязательные элементы):
<inquiry type="1"> // type = вид запроса
<reg_date>дата поступления запроса, дд.мм.гггг*</reg_date>
<subject>
<topic>Тема, зарплата например</topic>
<summary>Содержание кратко, для СП-запросов ФИО человека, на которого запрашивается справка*</summary>
<content>Содержание подробно</content>
<period>Интересующий временной период</period>
<altsurname>Девичья фамилия</altsurname>
<organisation>Наименование организации</organisation>
<purpose>Куда и для какой цели</purpose>
<date_of_birth>Дата рождения в произвольном формате</date_of_birth>
</subject>
<declarant status="1"> // физ. лицо
<surname>Фамилия</surname>
<name>Имя</name>
<secondname>Отчество</secondname>
<fio>Фамилия Имя Отчество</fio>
<location>
<country>Страна</country>
<zipcode>Индекс</zipcode>
<region>Регион</region>
<district>мун. район</district>
<city>Город, населенный пункт</city>
<address>Адрес, либо полный адрес*</address>
</location>
<email>Электопочта*</email>
</declarant>
<notes>Примечание</notes>
</inquiry>
Как видно, весь запрос состоит из двух основных частей: собственно содержание запроса (subject) и сведения о заявителе (declarant). В заявителе ФИО можно указать как полностью одной строкой, так и отдельно фамилию, имя и отчество. В адресе тоже можно весь адрес записать в элемент address, а можно разбить на элементы region, district… Вот примерно так.
замечательно, но сразу встречный вопрос — формат даты, вы ведь в курсе что есть разные стандарты представления даты, а так же есть уже применяемые стандарты публикации, например vcard?
ещё можно применить их или вы уже используете этот?
Формат даты можно изменить, какой Вы предлагаете? YYYY-MM-DD?
Для сведений о заявителе можно использовать vCard
не обязательно YYYY-MM-DD
есть RFC разные, например RFC822 http://breys.ru/blog/93.html
просто RFC практически исключает разночтения
пускай некоторые избыточны и не удобны как структура АФ3, но стандартны
к тому же применяется совмещённая система определения данных тегами и параметрами, type="1" и status="1" вместо вполне логичного для такой структуры
1
1
это не приципиально, благодаря xslt, но может быть можно ещё пересмотреть ради единообразия
UDP
1
1
тьфу, движёк срезает XML теги
Имелось ввиду наверное это:
<type>1</type>
<status>1</status>
Согласен, можно сделать так
Если о формате речь, то конечно, только «за», думаю DiamondMax ответит.