С. Л. Кузнецов, к. и. н.
-
Первые требования к системам автоматизации делопроизводства
-
Новые требования к системам электронного документооборота
-
Требования к электронным архивам
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 Типовых требований.
В целом вопросы информационной безопасности рассмотрены в Требованиях в общем виде, так как это направление является предметом деятельности специалистов этого профиля.
Перечень сведений (метаданных), заносящихся в карточку регистрируемого документа, практически идентичен данному в приложении к Правилам делопроизводства:
-
Адресант (автор) — наименование государственного органа, юридического или физического лица, направившего документ, его почтовый и (или) электронный адрес.
-
Адресат — наименование государственного органа, подразделения или должности лица, которому адресован документ.
-
Должность, фамилия и инициалы лица, подписавшего документ.
-
Наименование вида документа (наименование раздела в справочнике групп документов, к которому относится регистрируемый документ).
-
Дата документа.
-
Регистрационный номер документа.
-
Дата поступления документа.
-
Регистрационный номер входящего документа.
-
Сведения о связанных документах (наименование вида документа, дата, регистрационный номер, тип связи).
-
Заголовок к тексту (краткое содержание документа).
-
Индекс дела по номенклатуре дел.
-
Сведения о переадресации документа — наименование государственного органа, юридического или физического лица, которым переслан документ.
-
Количество листов основного документа.
-
Отметка о приложении (количество приложений, общее количество листов приложений).
-
Указания по исполнению документа (автор поручения, исполнитель, подразделение — ответственный исполнитель документа, содержание поручения, дата и результат исполнения).
-
Отметка о контроле.
-
Гриф ограничения доступа.
-
Сведения об электронной подписи (подписях) (информация о подписании документа ЭП, фамилия и инициалы, должность, дата подписания, сведения о сертификате электронной подписи).
-
Проверка электронной подписи (подписей).
-
Подразделение ответственный исполнитель документа.
-
Файлы электронного документа (количество файлов, имена файлов.
-
Сведения о способе доставки документа.
Как мы видим, добавился только п. 22. Однако, в отличие от Правил делопроизводства, Требования отдельно дают перечни сведений, фиксируемых при регистрации как поступающих (п. 3.5.2), так и отправляемых (п. 3.5.3) и внутренних документов (п. 3.5.4). Практически полностью этот перечень повторён и в п. 4.4.7 — в перечне сведений, которые должны храниться в информационной системе на этапе архивного хранения документов.
Если вышеперечисленный набор сведений (метаданных) можно найти в большинстве СЭД, присутствующих на рынке, то та часть, которая относится уже к стадии архивного хранения, во многих случаях требует дополнительной доработки (донастройки) используемой информационной системы и на возможность добавления данного функционала следует обратить особое внимание при выборе новой СЭД. Это сведения:
-
об использовании документов
-
о проверке наличия и состояния (воспроизводимости) документов
-
о конвертации в другие форматы
-
об экспертизе ценности документов (отметки о решениях ЭК и ЭПК с ссылками)
-
сведения о передаче в гос. архив
-
вид резервного носителя
-
место хранения
Последнее поле удобнее всего использовать в виде системного справочника — топографического указателя, включающего, в свою очередь, поля:
-
Фонд № (актуально, если фондов несколько, обычно в больших организациях, существующих длительное время)
-
Опись №
-
Ед. хранения №
-
Хранилище №
-
Стеллаж №
-
Шкаф (секция) №
Топографический указатель может использоваться при указании места хранения традиционного дела, а также основного и резервного носителей электронных документов (электронных копий документов).
Особо следует отметить приведенный в Типовых функциональных требованиях порядок приёма документов из подразделений в архив. Он предусматривает целый ряд этапов:
-
получение электронных дел, документов
-
получение метаданных
-
осуществление предварительной фиксации факта поступления
-
проверка электронной подписи
-
проверка наличия в метаданных документа сведений о проверке подлинности УКЭП передаваемого электронного документа на момент его подписания и/или получения
-
проверка комплектности состава контейнеров электронных документов, которые должны содержать контент и метаданные электронного документа, файлы электронных подписей и визуализированную копию текстового электронного документа в формате PDF/A
-
проверка воспроизводимости
-
заверение принятых на хранение электронных дел электронной подписью уполномоченного лица
С одной стороны, как уже говорилось, удобнее хранить все документы в единой информационной системе организации вплоть до момента выделения к уничтожению. Однако если всё-таки используются две отдельные информационные системы — СЭД и СХЭД, может использоваться указанный алгоритм действий. Особо следует обратить внимание на такие операции, как проверка электронной подписи, заверение принятых документов подписью уполномоченного лица. Учитывая значительное количество передаваемых документов в организациях с большим документопотоком, важно максимально автоматизировать операции проверки читаемости (воспроизводимости) документов, наличия и действительности электронной подписи, комплектности, наличия файлов в формате PDF/A, а также занесения сведений в пакетном режиме о единице хранения, на которой находится архивный контейнер данного документа, месте хранения носителя и др.
Так как рассмотренный документ — «Типовые функциональные требования к системам электронного документооборота и системам хранения электронных документов в архивах государственных органов» ещё официально не введён в действие, стоит отметить и мелкие замечания. Например, непонятно, почему перенос данных с одного носителя на другой отнесен не к понятию «миграция», а к конвертации. Как указано в документе: конвертация, конвертирование (электронных документов) — процесс перемещения электронных документов с одного носителя на другой или из одного формата в другой.
По сути терминов, миграция — это перемещение, перенос, не важно, на другой носитель или в другую информационную систему, а термин «конвертация» — это преобразование, в данном случае — документов устаревших форматов в форматы современные, обеспечивающие такое важное свойство документа, как пригодность для использования.
Также, на наш взгляд, не вполне корректно увязывать выделение документов к уничтожению и передачу на государственное хранение. Для традиционного ведомственного архива это было логично, в обоих случаях документы прекращали существовать в архиве организации. Для информационной системы выгрузка годового раздела для передачи в государственный архив совершенно не означает, что документы должны быть удалены из информационной системы. Более того, и само выделение документов к уничтожению, если оно не связано с требованиями законодательства (например, персональные данные) или соображениями корпоративной безопасности, как правило, проводится не ежегодно, а исключительно в случаях кардинальных сокращений в системе, например, при миграции на новую информационную систему с целью сокращения накладных расходов на перенос документов.
В целом документ, безусловно, очень нужный, и после его официального опубликования мы рассчитываем рассказать о нём более подробно.
1 С автором можно связаться по адресу: kouznets@yandex.ru
2 http://archives.ru/sites/default/files/2018-06-14-project-tft.doc
3 Приказ Минкомсвязи РФ от 02.09.2011 № 221, зарегистрировано в Минюсте РФ 15 ноября 2011 г. № 22304.
4 Приказ Росархива от 11.04.2018 № 44 «Об утверждении Примерной инструкции по делопроизводству в государственных организациях» (Зарегистрировано в Минюсте России 17.08.2018 № 51922).
5 Указ Президента РФ от 22.06.2016 № 293 «Вопросы Федерального архивного агентства» (вместе с «Положением о Федеральном архивном агентстве»).