Новые требования к системам управления документами и электронным архивам

С. Л. Кузнецов, к. и. н.

• Первые требования к системам автоматизации делопроизводства

• Новые требования к системам электронного документооборота

• Требования к электронным архивам

14 июня 2018 г. на сайте Федерального архивного агентства появились «Типовые функциональные требования к системам электронного документооборота и системам хранения электронных документов в архивах государственных органов», пока в виде проекта2.

Данный документ должен заменить уже устаревшие и очень краткие, «Требования к информационным системам электронного документооборота федеральных органов исполнительной власти, учитывающих в том числе необходимость обработки информации, доступ к которой ограничен», утверждённые ещё в 2011 г. приказом Минкомсвязи России3. Первые Требования в СЭД были подготовлены в соответствии с распоряжением Правительства РФ от 12.02.2011 № 176-р об утверждении плана мероприятий по переходу федеральных органов исполнительной власти на безбумажный документооборот. Новые Требования дополняют Примерную инструкцию по делопроизводству, подробно рассматривающую технологии работы с документами в электронной форме.4

В 2016 году функции по разработке и утверждению «типовых функциональных требований к системам электронного документооборота и системам хранения электронных документов в архивах государственных органов» были возложены на Росархив5. Таким образом, в лице Росархива возвращается орган по постановке делопроизводства в государственном масштабе. Наряду с подготовкой правил делопроизводства, примерной инструкции по делопроизводству, на Росархив возложено определение политики в области автоматизированных технологий управления документами, по крайней мере в государственном секторе. Учитывая то, что не только крупным, но и средним, мелким организациям всех форм собственности постоянно приходится взаимодействовать с государственными структурами, что невозможно полноценно осуществлять в электронном виде без унификации форматов документов, передаваемых метаданных, используемых технологий. В любом случае унификация СЭД неизбежна, если организация хочет обмениваться документами в электронной форме с другими организациями.

Таким образом, можно сказать, что в сферу ведения Росархива с 2016 г. попадает автоматизация управления документами на протяжении всего жизненного цикла, от создания до уничтожения.

В отличие от первых Требований…, новые Типовые функциональные требования… носят не столь «рамочный» характер, увеличившись почти в пять раз и гораздо детальнее определяя требования к СЭД. В то же время хватает и общих положений — что СЭД не должна противоречить российскому законодательству, установленным правилам работы с документами и т. д. (п. 1.4, 2.1).

Новые Типовые требования содержат три десятка определений основных понятий в области автоматизации ДОУ, Общие функциональные требования к управлению документами в СЭД и системах хранения. Третий и четвёртый разделы содержит более детальные функциональные требования ко всем этапам организации жизненного цикла документов в электронной форме. Третий раздел посвящён СЭД, а четвёртый повторяет все уже применительно к СХЭД. Перечислены категории документов, работу с которыми должны обеспечивать система хранения (СХЭД), требования к управлению доступом пользователей, порядок комплектования (включения документов в СХЭД, учёт и классификация, хранение электронных документов в СХЭД, их использование, проведение экспертизы ценности, выделение к уничтожению и подготовка документов к передаче в государственный архив.

Типовые требования делят метаданные, которые вносятся в карточку каждого документа на несколько основных групп:

поля, заполняемые при добавлении документа в СЭД (СХЭД);

сведения, отражающие весь жизненный цикл документа;

метаданные, используемые при взаимодействии СЭД с другими (внешними) СЭД;

метаданные, используемые при передаче документов на государственное хранение (выгрузке для последующего импорта в ПК «Архивный фонд».

От СЭД и СХЭД требуется уметь взаимодействовать (п. 2.7 ,2.8) и с другими информационными системами, обмениваться документами с МЭДО, СМЭВ и др. Если 8–10 лет назад практически все СЭД представляли собой замкнутые системы, не предусматривавшие обмен документами в электронной форме с другими СЭД, то сегодня СЭД – часть корпоративной информационной системы, в рамках которой СЭД тесно взаимодействует с системами управления кадрами, CRM (взаимодействие с клиентами), ERP (управление предприятием) и другими системами, отправляет и принимает документы в электронной форме, используя электронную подпись.

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

СЭД/СХЭД должна формировать выходные формы, статистическую отчётность по документам, действиям с ними и т. п. Например, о количестве согласованных сотрудником (подразделением) документов, количестве поступивших, выполненных, отправленных документов, документов с нарушенными сроками рассмотрения, с разбивкой по подразделениям, сотрудникам и любую другую отчётность, которая может потребоваться в организации. Тут надо добавить, что для организаций, не имеющих штатных программистов, важно обратить внимание, нужен ли программист для внесения изменений в существующие формы и создания новых, или для этого достаточно квалификации системного технолога СЭД. Особенно это актуально для средних и малых организаций, но и для крупных быстрое создание или модификация выходных форм существенно упростит работу службы ДОУ.

Главная часть рассматриваемого документа – это Функциональные требования к обеспечению жизненного цикла документа в СЭД и СХЭД государственных органов (3 и 4 разделы).

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

Интересно, что хотя п. 38 Правил делопроизводства предусматривает, что документы создаются в электронной форме без предварительного документирования на бумаге, а п. 45 этих же Правил – регистрацию документов на бумаге вместе с созданием их электронных копий, тем не менее рассматриваемые Типовые требования предусматривают, что СЭД может и не быть полнотекстовой, т. е. содержать информацию о документах, но не сами документы или электронные копии. Можно предположить, что сохранение подобного варианта связано со сложившейся практикой работы с документами ограниченного доступа, так как отсутствие в системе конфиденциальных документов существенно снижает расходы на обеспечение информационной безопасности СЭД.

Безопасность. Иногда встречаются программы, допускающие вход в информационную систему без пароля (с «пустым» паролем). Если при этом СЭД сохраняет имя последнего пользователя, то получается, что любой человек, получивший доступ к компьютеру, может войти в СЭД. Чтобы этого не случилось, обязательна аутентификация пользователей (п. 2.2). Желательно, чтобы СЭД имела ограничение, не позволяющее устанавливать короткие и простые пароли. Обычно устанавливают ограничение на минимальную длину пароля в 6 или 8 знаков, при необходимости добавляется требование использования как цифр, так и букв в разном регистре (как заглавных, так и строчных). Важно также установить обязательность смены пароля через определённый период времени. Иногда встречается требование еженедельной смены пароля. На наш взгляд, это имеет смысл только на наиболее важных рабочих местах с высокими рисками взлома. В большинстве случаев пароли могут меняться значительно реже, так как часто меняющиеся пароли сотрудники не успевают запомнить и носят с собой на бумаге, что существенно повышает риски утечки пароля.

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

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

Управление правами доступа к документам и метаданным — важный компонент обеспечения информационной безопасности, рассмотренный в п. п. 3.2 и 4.2 Типовых требований.

В целом вопросы информационной безопасности рассмотрены в Требованиях в общем виде, так как это направление является предметом деятельности специалистов этого профиля.

Перечень сведений (метаданных), заносящихся в карточку регистрируемого документа, практически идентичен данному в приложении к Правилам делопроизводства:

1. Адресант (автор) — наименование государственного органа, юридического или физического лица, направившего документ, его почтовый и (или) электронный адрес.

2. Адресат — наименование государственного органа, подразделения или должности лица, которому адресован документ.

3. Должность, фамилия и инициалы лица, подписавшего документ.

4. Наименование вида документа (наименование раздела в справочнике групп документов, к которому относится регистрируемый документ).

5. Дата документа.

6. Регистрационный номер документа.

7. Дата поступления документа.

8. Регистрационный номер входящего документа.

9. Сведения о связанных документах (наименование вида документа, дата, регистрационный номер, тип связи).

10. Заголовок к тексту (краткое содержание документа).

11. Индекс дела по номенклатуре дел.

12. Сведения о переадресации документа — наименование государственного органа, юридического или физического лица, которым переслан документ.

13. Количество листов основного документа.

14. Отметка о приложении (количество приложений, общее количество листов приложений).

15. Указания по исполнению документа (автор поручения, исполнитель, подразделение — ответственный исполнитель документа, содержание поручения, дата и результат исполнения).

16. Отметка о контроле.

17. Гриф ограничения доступа.

18. Сведения об электронной подписи (подписях) (информация о подписании документа ЭП, фамилия и инициалы, должность, дата подписания, сведения о сертификате электронной подписи).

19. Проверка электронной подписи (подписей).

20. Подразделение ответственный исполнитель документа.

21. Файлы электронного документа (количество файлов, имена файлов.

22. Сведения о способе доставки документа.

Как мы видим, добавился только п. 22. Однако, в отличие от Правил делопроизводства, Требования отдельно дают перечни сведений, фиксируемых при регистрации как поступающих (п. 3.5.2), так и отправляемых (п. 3.5.3) и внутренних документов (п. 3.5.4). Практически полностью этот перечень повторён и в п. 4.4.7 — в перечне сведений, которые должны храниться в информационной системе на этапе архивного хранения документов.

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

• об использовании документов

• о проверке наличия и состояния (воспроизводимости) документов

• о конвертации в другие форматы

• об экспертизе ценности документов (отметки о решениях ЭК и ЭПК с ссылками)

• сведения о передаче в гос. архив

• вид резервного носителя

• место хранения

Последнее поле удобнее всего использовать в виде системного справочника — топографического указателя, включающего, в свою очередь, поля:

• Фонд № (актуально, если фондов несколько, обычно в больших организациях, существующих длительное время)

• Опись №

• Ед. хранения №

• Хранилище №

• Стеллаж №

• Шкаф (секция) №

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

Особо следует отметить приведенный в Типовых функциональных требованиях порядок приёма документов из подразделений в архив. Он предусматривает целый ряд этапов:

• получение электронных дел, документов

• получение метаданных

• осуществление предварительной фиксации факта поступления

• проверка электронной подписи

• проверка наличия в метаданных документа сведений о проверке подлинности УКЭП передаваемого электронного документа на момент его подписания и/или получения

• проверка комплектности состава контейнеров электронных документов, которые должны содержать контент и метаданные электронного документа, файлы электронных подписей и визуализированную копию текстового электронного документа в формате PDF/A

• проверка воспроизводимости

• заверение принятых на хранение электронных дел электронной подписью уполномоченного лица

С одной стороны, как уже говорилось, удобнее хранить все документы в единой информационной системе организации вплоть до момента выделения к уничтожению. Однако если всё-таки используются две отдельные информационные системы — СЭД и СХЭД, может использоваться указанный алгоритм действий. Особо следует обратить внимание на такие операции, как проверка электронной подписи, заверение принятых документов подписью уполномоченного лица. Учитывая значительное количество передаваемых документов в организациях с большим документопотоком, важно максимально автоматизировать операции проверки читаемости (воспроизводимости) документов, наличия и действительности электронной подписи, комплектности, наличия файлов в формате PDF/A, а также занесения сведений в пакетном режиме о единице хранения, на которой находится архивный контейнер данного документа, месте хранения носителя и др.

Так как рассмотренный документ — «Типовые функциональные требования к системам электронного документооборота и системам хранения электронных документов в архивах государственных органов» ещё официально не введён в действие, стоит отметить и мелкие замечания. Например, непонятно, почему перенос данных с одного носителя на другой отнесен не к понятию «миграция», а к конвертации. Как указано в документе: конвертация, конвертирование (электронных документов) — процесс перемещения электронных документов с одного носителя на другой или из одного формата в другой.

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

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

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