Блог

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

Но при этом, как мне кажется, нет единого понимания, что подразумевается под "типовым ТЗ". Это вопрос тоже спорный, но я хочу пояснить свое видение на конкретном примере – "типовой интерфейс взаимодействия граждан с госорганами" (или "обращения граждан").
[spoiler]
Насколько я знаю, такие функциональные модули есть во многих СЭД-продуктах, предназначенных для госорганов, и во многих СЭД-системах (то, что внедрено и используется).
Но я, как гражданин-пользователь, вижу, что реализован этот интерфейс взаимодействия по-разному, и качество реализации меня, как гражданина (который, вообще говоря и является заказчиком такого СЭД-проекта, ведь проект оплачивает за счет бюджете, т.е. средств граждан), далеко не всегда устраивает.

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

Кстати, тоже вопрос: почемe уровень стандартизации в "рыночной стихиt" выше, чем в "регулируемом госуправлении"?

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

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

Давайте, будем считать, что общение идет через механизм электронной почты.

===============================

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

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

И, наверное, полезна процедура проверки правильности почтового адреса (если посылается с другого адреса).

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

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

2. Подтверждение получения обращения.
В ответ на свое письмо я должен получить по почте подтверждение (если не получу – буду считать, что мое письмо не дошло).

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

Так вот такой информации я никогда не получал в ответ на свое обращение. В лучшем случае (не всегда) простое подтверждение "приняли", иногда без номера регистрации, всегда – без последних двух пунктов.

3. Получение ответа.
Прежде всего – каком формате. Я получал в самых разных (PDF, TIFF и пр.), но всегда в приложении.
Меня вполне устраивает – в теле самого письма, можно "просто текст".

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

4. Подтверждение получение ответа
Процесс "обращения" должен обязательно завершаться отправкой от меня подтверждения о получении ответа "получил" и возможно "уровень удовлетворенности",

Такого я в общении с нашими госорганами, кажется, не встречал.

=========================

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

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

Как-то так…