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

Блог

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

Василь Хатимов
24.12.2012 07:32:46

Данный пост - продолжение обсуждения поста "Хранить вечно 2.0" (http://www.pcweek.ru/ecm/blog/ecm/4023.php?commentId=21456#21456).
Ввиду ограничения на объем здесь я изложу лишь основные вопросы. Я дико извиняюсь перед Андреем Колесовым, но мне трудно излагать сложный материал кратко. Увы, я не журналист smile:(
Здесь речь пойдет только об электронных документах (далее – ЭД). Бумажные будут упоминаться исключительно для иллюстрации ситуаций.

1. Под техническим [электронным] документом я понимаю информационный объект, полученный в результате разработки с использованием специального программного продукта типа Autocad, Компас, Solid Works, P-CAD и т.п.
Электронный тех. документ имеет специальный формат, позволяющий однозначно отображать его содержание на экране компьютера и распечатывать на бумаге.
По содержанию тех. документ может относиться к самым разным областям: производству (механическому, электронному, электротехническому, химическому...), строительству, картографии, экологии и пр. и пр.
В дальнейшем слово "электронный" применительно к документу будем опускать, если не потребуется сравнивать его с бумажным.

2. Под сложным техническим документом я понимаю тех. документ, имеющий сложную внешнюю структуру. То есть он состоит из объектов, связанных только перекрестными ссылками. В файловой системе это набор файлов.

3. Считаю обязательным уточнить, что технический документ (далее – ТД) - это прежде всего именно документ, удовлетворяющий всем требованиям делопроизводства, имеющий необходимую значимость для принятия решений и доказательную силу.
Отсюда прямо вытекает, что информационный объект, соответствующий документу, должен удовлетворять требованию целостности и достоверности реквизитов. То есть ни в какую его часть [технически] невозможно внести изменение, не нарушив целостности, включая реквизиты. Естественно, это предполагает использование какого-то варианта подписи, одинаково признаваемой всеми лицами, имеющими отношение к нему при его создании и использовании. Вопрос действительности подписи при архивном хранении пока отложим.

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

Сейчас задача решается «как в каменном веке» (АК smile:)) – с помощью бумаги. Причина понятна, см. например, коммент Сергея Свинарева (http://www.pcweek.ru/ecm/blog/ecm/4023.php?commentId=21456#21291). Однако, для длительной сохранности документов предпочтительно использовать цифровые форматы, это общепризнанно (см. предыдущие обсуждения). Решение задачи для ЭД возможно в двух вариантах: 1) использование в архиве абсолютно конвертируемых форматов (растровых), либо 2) стандартизация специального уницифированного векторного формата для архивного хранения. Первый путь доступен уже сегодня, правда требует усложнения процедуры передачи в архив. Второй путь неизмеримо сложнее. Собственно, именно его я и хотел обсудить. Данный пост нужен лишь для того, чтобы зафиксировать очевидный случай.

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

Будем считать, что 1-й пост по теме я здесь закончил smile:)

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

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

24.12.2012 08:36:48

С почином!
Журналист и блогер - это разные вещи. Журналист - это тот, кто принят на работу в редакцию. А блогерм может быть каждый, зависит только от собственного желания smile:)

24.12.2012 12:30:56

С.Свинарев, и В.Хатимов подняли вопросы ИТ-обеспечения жизненного цикла не документов, а сложных материальных объектов. Я бы хотел обратить внимание на то, что мы тут покидаем тему маркированнную аббревиатурой ECM/СЭД и переходим к обсуждению проблематики характерной для совсем другой ИТ-дисциплины, обозначаемой PLM (Product Lifecycle Management). Исторически, бюрократический и технократический документооборот у нас разведены по разным рыночным нишам. Продукты PLM (как и сама проблематика) значительно сложнее, производителей на этом рынке меньше. В выставках Docflow участвовала на моей памяти только одна компания, работающая на этом рынке, это Лоция Софт и только до 2008 года. Я также не припомню, чтобы на выставках, посвященных документообороту, выставлялись широкоформатные сканеры или инженерные цифровые многофункциональные машины, их следует искать на выставках, посвященных САПР и автоматизации процессов подготовки производства.

24.12.2012 16:59:10

Цитата
С.Свинарев, и В.Хатимов подняли вопросы ИТ-обеспечения жизненного цикла не документов, а сложных материальных объектов

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

24.12.2012 18:00:54

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

Вот, навскидку, Опыт разработки системы электронного документооборота в ОАО «Гипроспецгаз». Даже бегло глядя на диаграмму в посте Размышления о соотношении рынка СЭД и ECM становится понятно, что речь идет о совсем других продуктах и ИТ-решениях. Я почему-то думаю, что практикующие инженеры, занимающиеся автоматизацией проектной деятельности и технических архивов, блог PCWeek/ECM не читают, в нем нет ничего для них интересного, могу, конечно, ошибаться. Если вам удастся насытить блог специфическим материалом и изменить это положение - Бог помочь.

25.12.2012 09:30:18

За 1-ю ссылку спасибо smile:)
Уважаю продукт TDMS от CSoft. Мне довелось внедрять версию 2.0 на крупном предприятии.
Эх, хотел выразить свои впечатления, но получается реклама, а здесь всё-таки СМИ.
Теперь по существу. Я поискал в этой публикации, какие документы там хранятся. На Рис.1 ясно показано, что тех. архив хранит бумажные документы. Кроме того, электронный архив (такое подразделение?) осуществляет контроль электронных экземпляров перед приемом. И только после этого бумажные документы принимает тех. архив. Схема упрощенная и остаются вопросы, но одно совершенно ясно: оригиналами являются бумажные документы. Поэтому вопрос о свойствах ЭД именно как документов здесь даже не стоит. Соответственно, к нашей теме это прямого отношения не имеет.
Кроме того, к сожалению публикация посвящена прежде всего работе с заданиями, а не с результатами их выполнения.
В любом случае желаю «Гипроспецгазу» и «Бюро ЕСГ» дальнейших успехов.
2-я ссылка опять про оценку рынка... и ничего нового мне не говорит. Ну, есть такая оценка, и что? Мне, например, известно, что есть решения по эл. архивам на той же TDMS, не имеющие отношения к техдокументации. В то же время есть тех. архивы на DIRECTUM и на Documentum и даже на 1С:Документооборот. Учтены ли они на приведенной диаграмме неизвестно.
Что из этого следует? Ничего.
Я согласен лишь с тем, что ИТ-решений существует море. Как это соотносится с темой поста? Соотносится совершенно однозначно - нужна унификация форматов архивного хранения, если речт идет именно о длительном хранении. Вот и всё.
И еще. Мы не обсуждаем автоматизацию проектной деятельности. К проблематике именно технических архивов я обратился с одной единственной целью, которую уже называл. Есть существующее положение, когда свойства бумажных документов как документов не зависят от их природы. Все люди работают с ними одинаково: архивариусы, следователи, историки, студенты... Они сравнительно легко копируются, пока находятся в приличном состоянии сохранности. Есть сильное желание довести эл. документы до такого же положения. То есть соединить простоту использования бумажных документов и сохранность электронных.
Отклоняться от этой темы я здесь не намерен.

24.12.2012 12:45:02

Цитата
стандартизация специального уницифированного векторного формата для архивного хранения


Такого рода форматы существуют, см., например JT (visualization format), но не всем одинаково нравятся.

Векторные форматы, даже если они основаны на общем геометрическом ядре, не обеспечивают однозначное наследование ассоциативных связей, см., например, Ассоциативная связь между NX и Solid Edge. Я уже писал об этом в длинномерном посте Хранить вечно. 2.0 как-то так:

Цитата
может возникнуть большой объем квалифицированной работы по перемоделированию


Еще раз хочу подчеркнуть, что PLM - совсем другая тема. 99,9% специалистов по ECM/СЭД при словах "библиотека элементов" сделают круглые глаза.

24.12.2012 17:41:50

Похоже, и это не о том. Кого интересует наследование ассоциативных связей? Конструктора, технолога.
А мы говорим о длительном хранении документов в архиве. Говорить о связном хранении полных моделей никто не собирался. Просто Вы этого не заметили. Речь изначально и всегда шла о замене бумажных документов в архиве электронными документами.
Вот если в бумажных документах есть наследуемые ассоциативные связи, которые почему-то трудно изобразить визуально в электронных документах, тогда это проблема smile;)
Только ничего этого нет, поскольку этого нет на бумаге.
Также Вы не заметили, что в качестве простейшего формата можно рассмотреть растровый. Да, там есть недостатки, поэтому пост будет иметь продолжение.
Документ - это продукт использования инструмента, правильно оформленный как документ, не более того. Этот результат можно выдать на бумагу и соответствующим образом оформить в качестве документа. А можно выдать на виртуальный принтер, получив растровый файл. Этот файл тоже можно соответствующим образом оформить в качестве документа. В первом случае бумажный документ попадет в бумажный архив, а во втором случае электронный документ попадет в электронный архив. Дальше мы попытаемся рассмотреть другие варианты.

Цитата
99,9% специалистов по ECM/СЭД при словах "библиотека элементов" сделают круглые глаза

Да. Скажу больше, многие сделают круглые глаза, когда понадобится организовать разработку и дальнейшее движение большого многофайлового документа, даже не технического. Это просто документ с приложениями, которые надо разрабатывать в разных программах. Экономика, статистика, законы... много чего.
И, кстати, кто сказал, что архив - это PLM?
Ну, а PLM - это точно не архив.
Архив может содержать документы не только об изделиях дискретного производства. Например, я не слышал, чтобы для работы с чисто строительной документацией использовались системы PLM. Хотя для отдельных механических конструкций - вполне. Но когда комплект документации уходит заказчику, там только документы, никаких PLM.
А еще упоминалась картография (инструмент - ГИС), экология... Где там PLM?

24.12.2012 18:18:15

Цитата
я не слышал, чтобы для работы с чисто строительной документацией использовались системы PLM


См., допустим, СОЮЗ-PLM - Система управления инженерно-технической информацией на протяжении всего жизненного цикла объекта. PLM Система Союз -PLM предназначена для решения задач управления инженерными данными в области машиностроения, приборостроения, архитектуры, строительства и смежных с ними областях. .

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

Цитата
можно выдать на виртуальный принтер, получив растровый файл


Виртуальный принтер выдает метафайл печати, он далеко не всегда растровый, может быть и векторным и смешанным.

25.12.2012 09:58:57

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

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