И вот, как бы в ответ на эти мои сетования, один из активных участников ECM-Фейсбук-группы сообщил о выходе своей статьи как раз по теме (см. страницу 32 PDF-файла).
Отлично! Читаю.
И, к сожалению, мало чего понимаю. А многие вещи просто отказываюсь понимать…
[spoiler]
Я сразу хочу сказать, что отлично осознаю субъективность своего восприятия. Вполне возможно, мое непонимание многих вещей объясняется слабой компетенцией в данной области. Наверное, там есть вещи, очевидные настоящему профессионалу с простого намека, а дилетантам и подробные пояснения не помогу.
Так что советую заинтересованным читателям самим познакомиться с публикацией и составить собственное мнение.
Но все же одновременно хочу (понимая риски демонстрации своей некомпетентности) поделиться своими соображениями и вопросами. А вопросом у меня очень много, и по сути статьи в целом и по отдельным ее фрагментам и даже фразам.
1. Прежде всего, я просто не понял, как у них там, в Новосибирском департаменте строительства, организовано информационное взаимодействие. Да и вообще, вся работа. Приводится большой перечень используемых систем, а что же они реально делают – непонятно. Я лично смог понять (точнее – догадаться, в явном виде об этом не сказано), что у них там реализована некоторая версия бумажного документооборота с некоторой электронной поддержкой. Но как распределены роли между бумагой и электронной частью – можно только догадываться.
В качестве общего пожелания-совета (все же есть собствнный опыт описания подобных вещей) хочу сказать, чтобы бы много полезнее, просто взять один конкретный характерный бизнес-процесс и на его примере рассмотреть проблемы и варианты их решения.
В целом, я могу также догадываться, что данный пример отлично демонстрирует тупиковость самой идеи "бумажно-безбумажного"документооборота, который мы уже много лет выдает как наше "национальное ноу-хуа". И пытаемся в одном проекте соединить современные достижения в строительстве небоскребов с технологиями деревянного зодчества времен татарского ига на Руси.
2. Автор выделяет перечень основных проблем. Очень хорошо. Но лично мне – не понятно!
Вот описание одной из проблем.
Я прочитал его несколько раз, но понять, в чем тут проблема понять не могу. Для начала мне не понятно, почему автор ставит знак равенства между "машиночитаемым документом" и "документом, имеющим электронную подпись". И замечу, что ЭЦП не обеспечивает достоверность информации как таковую. Она определяет лицо, ответственное за предоставление информации, но это еще совсем не достоверность.
Я не понял, почему "машиночитаемый документ" нужно приводить в "удобный для чтения вид". Зачем это нужно делать, точнее – в чем тут проблемы?
Или может быть, никаких "машиночитаемых документов" у них нет и в помине? Но почему бы тогда об этом так и не сказать?
Проблема преобразования бумажных документов в электронный вид хорошо известна. Как и хорошо известный методы ее решения (лучший вариант – исключение преобразования, как такового). Почему их не могут применять в Новосибирске – не понятно.
3. Я не буду продолжать перечень собственный вопросов по статье, он получится очень большим. Остановлюсь только еще на одном месте, где речь идет о предложениях по решению проблем.
Я перечитал эту фразу несколько раз, но понимания от этого не прибавилось, тут загадка для меня кроется в каждом слове.
О каких "Документах-основаниях" идет речь? В каком виде реализованы эти документы? В чем собственно проблема их хранения? Почему проблему можно решить именно открытием содержания документа причем именно в браузере?
Чтобы понять ситуацию, было бы хорошо увидеть логику сущестующего бизнес-процесса в виде простой блок-схемы. И предлагаемый вариант в таком же виде…
Вот с чем я могу полностью согласиться, то это вот с этим выводом автора в конце статьи.
А вот рекомендация, как нужно решать эту глобальную проблему, выглядит слишком общей, и нереализуемой.
Дело в том, что автор тут дает задание, с которым наше государство явно и давно не может справиться. И главное: до сих пор так и не понятно, кто же именно должен все это делать.
Но опять же - зачем нужен такой закон? Нужно четко сформулировать - зачем нужен закон. Наверное, он нужен, что был решать судебный дела. Так же можно сказать, что уточненные требования к документам в разных областях деятельности, должны содержаться в требованиях конкретных ведомств.
И закон должен быть кратким - не более трех страниц текста.
2. По статье. Странно читать про ссылка на редактирование и урезание текста. Редактирование - это процедура добровольная, а не принудительная. Правку должен принимать или не принимать автор. Автор несет ответственность за текст, а не редактор. Если искажен смысл, то это проблема автора, а не редактора (принимает правку автор).
Еще страннее выглядит ссылка на объем. Извините, но это все пережитки бамажной психологии. Какие есть ограничения в электронные времена.
Да, с бумажными все вполне решалось. Могу привести сколько угодно примеров бумажных публикация с обилием иллюстраций, схем и пр.
Да, с бумажными все вполне решалось. Могу привести сколько угодно примеров бумажных публикация с обилием иллюстраций, схем и пр.
Выскажу свое мнение на основе своего опыта в проекте Мосгостройнадзора http://stroinadzor.mos.ru/.
1. Проблема извлечения полученных данных.
Думаю, это проблема этапа проектирования ИС.
Приведу пример г.Москвы (проекта, которым я сейчас занимаюсь): по межведомственному взаимодействию передаётся:
1) Структурированные данные в xml + ЭП на этот xml
2) Электронный образ документа (например, цветной pdf) + ЭП на этот ЭО.
Выверкой соответствия структурированных данных и ЭО берет на себя ведомство, выдающее документ.
Таким образом, специалист получает в работу и электронный образ документа (т.е. как он бы получил на бумажном носителе), и в виде структурированы данных – что помогает исключить повторный ввод данных в систему ведомства и избежать ошибок перепечатывания (человеческий фактор).
Например, при оказании госуслуги «Выдача разрешения на строительство для объекта капитального строительства/линейного объекта» Мосгостройнадзор запрашивает через межведомственное взаимодействие следующие документы:
1) Градостроительный план земельного участка (ГПЗУ)
2) Договор аренды земельного участка (ДАЗУ) или Свидетельство о регистрации права на земельный участок (выписка из росреестра)
3) Заключение экспертизы (Заключение МГЭ)
Например, после получения документов у специалиста «Отдела выдачи разрешения на строительство» есть доступ к технико-экономическим показателям (далее ТЭПам) заключения МГЭ в структурированном виде (часть из них наследуется в Разрешение на строительство, далее РС) и в результате решается сразу 2 задачи:
1) Обеспечивается строгое соответствие ТЭПов в заключении МГЭ и РС;
2) Исключаются ошибки повторного ввода данных.
Возвращаясь к примеру с кадастровой выпиской на земельный участок – вопрос отображения картографических данных решается грамотной ИС. В Москве действует ИСОГД, в которой можно посмотреть расположение земельного участка на карте с приложенной к нему всей проектной и разрешительной документацией (как структурированные данные, так и ЭО).
Таким образом проблема извлечения данных из «машиночитаемого» в «человекочитаемый» вид не возникает.
2. Проблема идентификации и классификации объектов.
На мой взгляд, это тоже проблема этапа проектирования ИС.
В Москве реализован принцип «вязанки» документов по определенным признакам. Настроить связи документов по определенным атрибутам (кадастровый номер, строительный или почтовый адрес и т.д.) – решаемая задача.
1) В ИС Мосгостройнадзора это «объект\ паспорт объекта», к котором в течении строительного цикла «подвязываются» все заявления, РС, акты проверок, предписания и протоколы, ЗОС и РВ. Реализован поиск по структурированным данным: адрес, номер дела, номер РС, Застройщик и т.д.
2) В базовый регистр (далее БР) запросы документов идут по параметрам, определенным нормативными актами:
Наименование документа \ Параметры запроса
Градостроительный план земельного участка (ГПЗУ) - Номер
Свидетельство о регистрации права на земельный участок (выписка из росреестра) - Кадастровый номер земельного участка
Договор аренды земельного участка (ДАЗУ) - Номер договора+дата договора
Заключение экспертизы (Заключение МГЭ) - Номер заключения по реестру + Дата утверждения заключения
Таким образом, чтобы получить ДАЗУ, достаточно указать номер и дату договора. В полученном по межведомственному взаимодействию ответе будут и структурированные данные (в т.ч. кадастровый, условный номер земельного участка) и ЭО документа.
3) В ИСОГД установлены связи между всей «вязанком» документов к земельному участку.
В электронном документообороте возможно устанавливать «связи» между документами. Это надо закладывать на этапе проектирования.
В результате на примере г.Москвы можно утверждать, что проблема идентификации и классификации объектов решаема, в т.ч. Мосгостройнадзор в настоящее время легко устанавливает связь между номером дела (договора) о земельном участке и РС, может просмотреть всю историю выдаваемых РС за последние 10 лет (выдачу, продления).
рис.1 По адресу объекта (в данном случае - о здании Мосгостройнадзора) можно увидеть всю проектную и разрешительную документацию. Скриншоты предоставлены Заказчиком.
рис.2.
рис.3
3. Проблема переноса данных между бумажной и электронной формами
Автор, на мой взгляд, смешивает в одну строку адрес и наименование объекта, этап строительства и т.д. С подобной проблемой столкнулся Мосгостройнадзор при приеме дел по новым территориям. Удобное решение здесь – ввести структурирование данных, т.е. отдельными полями (блоками) вести адрес, наименование объекта, этап и т.д.
Хочу подчеркнуть, что считаю, что обе формы должны совпадать, иначе это – разные документы!
В ИС должны параллельно вести и структурированные данные и ЭО документов, отдельно необходимо строго контролировать полное совпадение ЭО и структурированных данных. Тогда проблем с «падежами, оговорками, исключениями и т.д.», о которых говорил автор, не будет в принципе.
4. Проблема хранения документа-основания
Не согласна с автором в «фактически эти данные не являются документом, который был получен вместе с электронной подписью» (т.к. загружены в базу данных).
Не нужно путать два понятия:
1) Полученные данные нужно хранить отдельно, тогда в случае проверки прокуратурой всегда можно предъявить исходные документы, подписанные ЭП
2) Данные, загружаемые в собственную базу данных (на сколько я понимаю, идёт речь о структурированных данных) – это необходимый производственный процесс, тут уже на уровне проектирования ИС нужно продумать вопрос защиты данных от искажения, чтобы на случай проверки Прокуратурой можно было однозначно показать полное соответствие полученных по межведомственному взаимодействию данных (хранящихся отдельно) и данных в производственной системе. Например, как я уже говорила выше, ТЭПы из заключения МГЭ (полученные по межведомственному взаимодействию) и ТЭПы в РС (выданном как результат оказания госуслуги Мосгостройнадзором на основании заключения МГЭ как одного из документов).