Архив без пыльных полок или способы организации архива предприятия

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

Планируемые сроки сканирования документов, производительность подсистемы сканирования;

Необходимость дальнейшего пополнения архива вновь отсканированными документами;

Окончательное решение о формате электронного изображения;

Классификация документов по форматам, ветхости, состоянию, "сброшюрованности" и всем явленным  при обследовании дополнительным признакам. Эту классификацию лучше всего составить в виде таблицы с указанием "класса" документов и их количества;

Реальные "борки" документов каждого определенного  класса в виде пачек, папок, рулонов, книг и т. д.

Методика и способы обследования подробно описывались ше.

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

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

Разработка технологии работ по сканированию

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

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

Обработка сканированных документов

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

В настоящее время существует множество таких средств. Спектр велик — от небольших утилит, "обрезающих", например, рамки и "грязь" по краям, до сложных редакторов с полным набором средств, позволяющих, если не получить идеальное изображение из плохого, то отреставрировать ту часть, которая утеряна (естественно, "вручную").

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

Как правило, пакетная обработка эффективна для массивов файлов, полученных при сканировании "одинакох" по "недостаткам" документов. К счастью, в большинстве случаев в "бумажных" архивах они так и хранятся. Ветхость бумаги, её тип и прочие характеристики, влияющие на результаты сканирования, скорее всего, в одной пачке, папке мало чем отличаются. Поэтому качество изображений приблизительно одинаковое "внутри" всего файлового массива. В связи с этим, возможны одинакое настройки для обработки и, как следствие, пакетная обработка такого массива файлов. Если же качество документов разное "внутри" одной пачки (массива графических файлов), то задача по обработке значительно усложняется. Например, "обрезать" края можно и "пакетно", а вот "чистить" грязный фон "пакетно" не получится. У одного файла фон может быть более интенсивным, у второго — менее, а у третьего — фона вообще может не быть. Если такой массив обрабатывать "пакетно", то "плохие" изображения может и станут гораздо лучше, а вот "хорошие" могут быть просто "испорчены".

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

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

Разработка технологии работ по обработке сканированных изображений и ввода в систему электронного архива

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

Создание подсистемы хранения документов

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

В современных СУБД и архивных системах (работающих с этими СУБД) существуют 2 основных способа хранения документов. В первом случае файл записывается непосредственно в ячейку таблицы в бинарном виде. Такая ячейка должна иметь соответствующий формат, например, Image (MSSQL) и т. д. Такой способ хранения файлов можно сравнить с рыболовной сетью, в некоторых ячейках которой застряла рыба. Сеть — таблица СУБД, а рыба — файлы в бинарном виде. Общий вес складывается из "веса" рыбы и самой сети. То есть физический размер таблицы СУБД, а отсюда и требования к аппаратным средст ше, а быстродействие базы ниже (сеть с рыбой поднять гораздо тяжелее) при такой записи документов. Этот способ хранения файлов хорош при сравнительно "небольшом весе рыбы" — физическом объеме файлов архива. Материал посвящен созданию электронных архивов, объемы хранимой информации в которых, как правило, велики. При шеописанном способе хранения возникают проблемы с резервным копированием, "местом на дисках", быстродействием базы, требованиями к аппаратным средст, производительностью и эффективностью системы в целом.

Второй способ хранения документов в системе электронного архива заключается в том, что файлы не записываются в ячейки таблиц СУБД в бинарном виде. При таком способе в ячейку пишется лишь ссылка на файл. Сам же электронный документ находится в той или иной области хранения. Размер самой таблицы при записи в неё информации о файле документа увеличивается мизерно (по сравнению с записью в бинарном виде). Для получения самого документа система архива не "проворачивает всю сеть с рыбой", а обращается к СУБД, "видит" ссылку на файл и, подобно рыбаку с удочкой, таскивает "рыбу" на леске (нужный документ по ссылке). Отличие лишь в том, что в случае с СУБД всегда на 100% заранее известно "какая рыба будет тащена".

Конечно, если все-таки по каким-либо причинам  считаете, что целесообразно хранить файлы документов в бинарном виде в ячейках СУБД, я не стану спорить. Хотя такой способ имеет все шеперечисленные недостатки.

Минимум 2 раздела хранения

Опыт показывает, что общий объем архива может составлять терабайты информации, с одной стороны, но в интенсивном использовании находится 5% — 10%. Доступ к документам оперативного использования наиболее интенсивен, а объем сравнительно невелик. Доступ к оставшейся значительной части (90%-95%) информации нельзя назвать интенсивным. Документ может быть востребован 1 раз/неделю, месяц, год. С другой стороны, невозможно создать идеальное по качеству "хранилище", позволяющее мгновенно "получить" документ, бранный из терабайтов информации. Такое "идеальное" хранилище должно обеспечить сокую надежность хранения, "быть свободным" от таких "банальностей", как действие магнитных полей, необходимость "зеркалировать диски" и ко всему прочему иметь доступную цену!

В связи с этим, можно делить минимум 2 раздела хранения:

область оперативного хранения — сравнительно небольшой объем и сокая интенсивность доступа;

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

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

Оперативный архив

Думаю не стоит особенно подробно останавливаться на описании области оперативного хранения. Поскольку организовать её не стоит особых усилий, используя "часть" жесткого диска сервера, специально деленного для этой цели диска или Raid — массива. Все подобные решения обеспечивают быстрый доступ к оперативной части информации, имеют сравнительно небольшой объем. Объем рассчитывается исходя из реального объема документов, находящихся в оперативном использовании.

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

Долгосрочный архив

Для организации долгосрочной области хранения можно, конечно, использовать "причные" жесткие диски или Raid — масси. Хотя, когда объем хранимой информации исчисляется терабайтами, это не очень годно. Причины в том, что необходимо организовать резервное копирование этих объемов, "зеркалировать" диски и пошать надежность системы прочими способами, принятыми для таких носителей. Как правило, все эти способы связаны с резким увеличением стоимости решения. Приведу простой пример: для создания "зеркальных" дисков объем носителя должен быть в 2 раза больше.

Когда мы говорили о втором разделе хранения — долгосрочном архиве — не зря упоминали не только о соких требованиях к надежности, но и о достаточно "низких" требованиях, связанных со сравнительно несокой интенсивностью доступа (возможно документ потребуется 1 раз/неделю, месяц, год). Исходя из этого, наиболее интересными и перспективными устройст для организации области долгосрочного хранения являются роботизированные DVD — библиотеки.

DVD — технологии получили  особенно бурное развитие в  последние годы. Что же такое  роботизированная библиотека? Представьте  себе диск, внешне напоминающий  обычный CD, только "объем" его составляет 2,6; 4,7 или, скажем, 9,4 Gb. Конечно, такой  объем уже является достаточным  преимуществом, по сравнению с  обычным CD, к тому же, если  используете, например, технологию DVD-RAM, то работа  с таким диском по записи  и чтению может ничем не  отличаться внешне от записи  и чтения на обычный жесткий  диск. Конечно, скорость доступа  ниже. А теперь представьте, что 100, а может и 600 таких дисков размещены  в отдельном корпусе. Общий объем  такого устройства может достигать  до 5,5 терабайт. Остается решить вопрос  доступа к информации. Роботизированная DVD-библиотека как раз и представляет  собой такой массив дисков, размещенных  в отдельном корпусе. Количество  носителей может быть разным  и зависит от конкретной модели. Как правило, все производители  пускают модельные ряды, каждое  из устройств которых может "вмещать" 100 — 600 DVD — носителей. Для защиты  дисков от повреждений внутри  корпуса каждый носитель находится  в специальном пластиковом конверте, исключающем механические прикосновения  к поверхности.

Внутри корпуса роботизированной библиотеки кроме самих носителей расположены приводы, обеспечивающие запись и считывание информации. Число приводов может быть различным в зависимости от конкретной модели. Их может быть от 1 до14. Причем стоит отметить модульность этих библиотек. Дело в том, что для работы необходим минимум один привод, но в дальнейшем, при увеличении требований к производительности, число приводов может быть увеличено (до максимально возможного для данной модели). Роботизированная библиотека представляет SCSI — устройство, подключаемое к серверу или отдельному компьютеру. На управляющем компьютере устанавливается специализированное ПО, позволяющее представить всю роботизированную библиотеку одним логическим ресурсом. Говоря проще, открыв вкладку "Мой компьютер",  видите диск Z: "размером" терабайт в пять!