НовостиСобытияКонференцииФорумыIT@Work
Документооборот/ECM:

Блог

Про архивы техдокументации 2

Василь Хатимов
25.12.2012 17:19:21

Данный пост – второе продолжение обсуждения поста «Хранить вечно 2.0» (http://www.pcweek.ru/ecm/blog/ecm/4023.php). Первое продолжение здесь: «http://www.pcweek.ru/ecm/blog/ecm/4107.php». Там же соглашения и обозначения.

Будем считать установленным, что в настоящее время самыми «живучими» форматами графических файлов являются растровые форматы. Они же – самые «простоконвертируемые». Если в какой-то момент некий растровый формат будет признан устаревшим, все файлы в этом формате могут быть надежно сконвертированы в другой растровый формат. В этом смысле вечный архив ЭД можно создать прямо сегодня, используя исключительно растровые образы.
Дополнительный плюс в этом случае – сканированные образы хранятся в том же формате, при работе с ними используется тот же софт.

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

Многослойность, многомерность, свободное масштабирование с сохранением всех технических условностей… Достаточно ли этого для того, чтобы влезать в бюрократическое болото стандартизации? На мой взгляд – да. Вдобавок ко всему это дополнительный мотив для отказа от бумаги. Отметим, что для этого не обязательно разрабатывать новый формат файла. Можно выбрать подходящий из существующих. И такой стандартный формат не обязан быть единственным. Достаточно, чтобы их было не слишком много, чтобы соответствующим софтом можно было оснастить все участвующие рабочие места и это не превратилось в вавилонскую башню. К тому же нормы архивного хранения могут (нет, должны) содержать предельный срок хранения ТД, до которого можно использовать «родной» формат. При достижении этого срока обязательна конвертация в стандартный формат. Если для начала взять срок 5 лет, то никаких катаклизмов не произойдет. Старые (бумажные) документы сканируем, новые при необходимости конвертируем в течении 5 лет. Остальное – как обычно: периодическая экспертиза, уничтожение устаревших и пр.

Про конвертацию. С момента ввода в действие стандартных форматов есть 5 лет (или 4 или 3), чтобы разработать необходимые конвертеры и предоставить их разработчикам документации. За чей счет этот банкет? Вот здесь нужна государственная политика.

Есть предположение, что денег понадобится меньше, чем на «наноучебник» («http://www.pcweek.ru/gover/blog/gover/3824.php»). Впоследствии все инструменты разработки документов должны сертифицироваться для использования в России с условием наличия нужного конвертера. Всё сказанное относится и к библиотекам элементов. С течением времени наработки будут накапливаться, а затраты снижаться. Но в любом случае без участия государства всё это нереально.
Пожалуй, пора переходить к обеспечению достоверности архивных документов.

Комментариев: 8

Только зарегистрированные и авторизованные пользователи могут добавлять комментарии

26.12.2012 14:49:48

По опыту создания электронных архивов проектно-сметной документации(а они есть как разработки на базе ECM, и пользуются спросом) могу сказать, что пользователи предпочитают хранить документы в "родных форматах" с дублированием документа в растровом.
Зачем? А задачи разные!
Документ в векторном формате активно используется для создания новых продуктов- переделать всегда проще, чем ваять заново.
А растровый- констатация того. что было сделано в каждом конкретном случае.
Если делать архив"только на историю", денег на него не дадут. Вот когда есть реальный выигрыш от повторного (и многократного) использования уже сделанных разработок, деньги выделяют.

26.12.2012 16:08:40

Согласен - задачи разные. В данном случае то, о чем я говорю, относится к растровым дубликатам.
Однако, как при таком подходе устроен архив? В смысле аутентичности дубликата исходнику, ведения версий? При активной разработке это всё тоже не всегда просто отслеживать. А при согласованиях-изменениях как это выглядит?
Понятно, здесь речь о внешнем согласовании документации, уже согласованной и утвержденной внутри.
Это я к чему - можно ли при таком подходе серьезно относиться к растровому дубликату как к документу? Все-таки есть разница между архивом документов и архивом незаверенных копий. Хотелось бы говорить именно о документах.
А архив в "родных" форматах - это технологический архив разработчиков, а не архив длительного хранения, как он понимается в архивном деле. В противном случае мы как раз и попадаем в ситуацию необходимости массовой автоматической конвертации, с которой начали.
"денег на него не дадут" - это и есть главная проблема.
Вся многолетняя дискуссия, "как относиться к электронным документам", в конце концов упирается в две вещи:
1) пока не получается к электронным документам относиться ровно так же, как к бумажным по причинам их многообразия во всех смыслах;
2) достоверность бумажного документа никак не меняется при сдаче его в архив, а с электронным всё сложнее, сроки сертификатов истекают, источники теряются, подписи в разных организациях привязываются по разным правилам...
В посте я упомянул про 2 момента, но написал лишь про один. Было интересно, заметит кто-нибудь или нет smile:D
Ну да ладно...

26.12.2012 17:03:00

Цитата
Однако, как при таком подходе устроен архив? В смысле аутентичности дубликата исходнику, ведения версий? При активной разработке это всё тоже не всегда просто отслеживать. А при согласованиях-изменениях как это выглядит?

Есть понятие "Регистрация". При проведении регистрации СОЗДАЕТСЯ растровый документ( или преобразованием оригинального файла, или сканированием бумажного подлинника(есть там есть визы и т.д.). Ответственность регистратора- соответствие документов.
При дальнейшем использовании этот документ МЕНЯТЬ НЕЛЬЗЯ, он только хранится. Для модификации создается копия, которая начинает жить как отдельный документ. При внесении изменений пользователь может сохранить измененный документ как версию (документа, сохраненного в качестве копии).
Для удобства отслеживания изменений карточки документов можно связать между собой, а к связи сделать комментарий- чем именно изменный документ отличается от исходного.
При сложном архиве можно строить графические "деревья" видоизменений разрабатываемых изделий.
Цитата
А архив в "родных" форматах - это технологический архив разработчиков, а не архив длительного хранения, как он понимается в архивном деле.

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

26.12.2012 18:35:04

Цитата
Ответственность регистратора- соответствие документов...
При внесении изменений пользователь может сохранить измененный документ как версию (документа, сохраненного в качестве копии).

Спасибо smile:) Если всё обстоит действительно так, то замечательно. Очень хочется верить, что это всегда так и происходит smile:D Сложность, которую я имел в виду, связана с тем, что внесение изменений в копию происходит в среде внешней программы, не обязательно интегрированной с архивной системой на уровне внутренних операций. Вот, кто реально является регистратором?
Если разработчик, то он второпях может легко пропустить создание нового растрового образа. Например, подсунет старый образ (а я наблюдал и такое: подсовывали совершенно "левые" файлы). Просто некогда - измененные документы нужны срочно.
Возникает потребность дополнительного контроля.
Если это архивист, то нагрузка на него получается нешуточная, как и требования к квалификации. Ведь мы имеем в виду использование не одного и не двух сложных средств разработки. Может потребоваться создание нескольких растров с одного векторного документа, и это надо сделать грамотно.
Цитата
Пока нет оперативных архивов, не будет и долгосрочных.

Ну, это слишком сильное утверждение. Это точка зрения разработчика, но у меня-то другая smile:D
А с практической точки зрения - да, Вы правы, так и происходит. Я ведь против этого не возражаю. Мне интересно, что и в каком виде уходит в "настоящий" официальный архив.
Цитата
пока не разработаны алгоритмы, дающие 100% уверенность, что переконвертированный документ- тот же самый документ, что был подписан

Именно. С этого факта и началось обсуждение.
Цитата
Остальные оставляют простор ошибкам и простому жульничеству.
Например. документ в формате WORD может содержать код, меняющий вид документа...

А это еще один аргумент против "родных" форматов. Сегодня - да, всё решается с помощью растра. Но хочется-то большего! smile:D

26.12.2012 18:48:34

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

Именно поэтому я написала, что растровый образ СОЗДАЕТСЯ(системой, а не регистратором) в момент регистрации. НЕ ДОЛЖНО БЫТЬ ВОЗМОЖНОСТИ ПОДСУНУТЬ левый файл! Заложите в систему правильные подходы! И требования к регистратору будут - умение нажимать кнопку "Зарегистрировать".
Цитата
Пока нет оперативных архивов, не будет и долгосрочных.

Ну, это слишком сильное утверждение. Это точка зрения разработчика, но у меня-то другая

Это -точка зрения практика по созданию всевозможных архивов "под заказ" .
Для организации передачи документов на архивное хранение необходимо думать об этой передаче с момента создания документа. Нужно думать, как он будет храниться дальше и как уничтожаться. Если не поставлена работа на уровне оперативного архива, полноценного долгосрочного архива не будет. Будет свалка случайно отловленных документов.

27.12.2012 09:01:48

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

Цитата
При проведении регистрации СОЗДАЕТСЯ растровый документ( или преобразованием оригинального файла, или сканированием бумажного подлинника(есть там есть визы и т.д.). Ответственность регистратора- соответствие документов.
...
НЕ ДОЛЖНО БЫТЬ ВОЗМОЖНОСТИ ПОДСУНУТЬ левый файл! Заложите в систему правильные подходы! И требования к регистратору будут - умение нажимать кнопку "Зарегистрировать".

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

27.12.2012 13:54:00

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

Не вижу оснований делать вывод, что первичным документом является бумажный документ.
Скан бумажного документа прикладывается к карточке документа в том случае, если хотят иметь копии бумажных документов, но это не является обязательным условием!
Напомню, что условием обмена документами в электронном виде является наличие соглашения о таком обмене.
У организации, использующей архив проектно-конструкторской документации, с частью контрагентов может быть заключено соглашение об обмене документами в электронном виде, а с частью - нет.
Поэтому для первой группы можно обходится без распечатывания бумажного документа и потом сканирование подписанного варианта, а для второй- нужно.
Есть еще такой момент. Вполне возможно. что проектная организация даже заключила соглашение с заказчиком о предоставлении документации в электронном виде, но для согласования в госорганах все равно могут потребоваться бумажные экземпляры. В это случае к регистрационной карточке документа нужно будет прикреплять:
- файл в "родном" формате;
- файлы в растровом формате;
- отсканированные экземпляры с подписями и визами.
Если удастся перейти на утверждение проектной документации в госорганах на электронные документы, от сканов можно будет уйти.
Сейчас они нужны для удобства создания набора копий бумажных документов, если такую нужно сделать.

27.12.2012 15:08:51

Приведенная цитата касается сканированного образа. В моем комменте это слово специально подчеркнуто. Вывод о первичности бумажного экземпляра сделан для случая сканирования с бумаги. И дальше есть пояснение, откуда такой вывод - из необходимости повторного сбора подписей для скана. А это не здорово, и практически мало кто на это пойдет. Соответственно, первична бумага, скан - копия. Это 1-е.
2-е связано с исходной темой - "Хранить вечно". Я сознательно обхожу вопросы обмена "активными" документами между организациями. Мы говорим именно об архиве и только об архиве. Предшествующая история интересует нас лишь как источник артефактов. Например создание аутентичных растровых образов при регистрации - имеет отношение к делу, а соглашения между организациями - не имеют. Документы могут быть затребованы из архива когда угодно, в том числе и после ликвидации проектной организации. Какие уж тогда соглашения... Архив будет передан государству или будет унаследован другой организацией, в любом случае соглашения перестанут действовать "в связи с отсутствием одной стороны соглашения". А то и обеих.
Да, да, я понимаю, что сертификаты подписей имеют срок действия. Это предмет следующего поста. Здесь я хотел обсудить вопросы технологического и организационного обеспечения создания эл. документов и помещения их в архив. При этом главное условие - эти документы должны заменить бумагу при длительном хранении. И еще хочется, чтобы эта замена привела к повышению уровня комфорта пользователей. Это не догма и пока еще не цель, просто сильное желание.
По поводу оборота документов между проектной конторой и партнерами (заказчиками, экспертами, поставщиками решений и пр.) я с Вами полностью согласен. Здесь спорить не о чем. И по вариантам "представлений" документа, подвешенных к карточке - тоже всё понятно... Правда там опять возникает вопрос о контроле аутентичности скана с подписями первоисточнику. Будем считать, что это должно решаться организационно.
А вот Ваше последнее утверждение я не совсем понял:

Цитата
Если удастся перейти на утверждение проектной документации в госорганах на электронные документы, от сканов можно будет уйти.
Сейчас они нужны для удобства создания набора копий бумажных документов, если такую нужно сделать.

Это речь опять о "чистых" копиях для удобства размножения? Эх! Да, они сейчас так используются, но я же не об этом... Я о полноценных документах, пригодных для представления в суд и для других ответственных случаев. То есть для использования ровно так же, как сейчас используются бумажные документы. Точнее вместо них, в качестве их полноценной замены. И в любой момент после завершения работ, хоть через 100 лет.
Да, да, сегодня это невозможно. Именно с этого начиналась когда-то моя полемика с Андреем Колесовым. Сейчас в связи с постом "Хранить вечно 2.0" мы договорились зафиксировать позиции. И вот я добросовестно пытаюсь найти подходы к "вечному" архиву: как бороться с устареванием форматов, что делать с подписями... Даже если сегодня это не работает. А как должно быть? Что надо было бы сделать? Кому?
Если мы хотя бы найдем путь, реализуемый в принципе, это уже будет хорошо. Вот, собственно...

Только зарегистрированные и авторизованные пользователи могут добавлять комментарии