Требования к системам электронного документооборота федеральных органов исполнительной власти (СЭД ФОИВ) были утверждены Приказом Министерства связи и массовых коммуникаций РФ № 221 от 02.09.2011 “Требования к информационным системам электронного документооборота федеральных органов исполнительной власти, учитывающие в том числе необходимость обработки посредством данных систем служебной информации ограниченного распространения”. Надо отметить, что СЭД-общественность очень неоднозначно отнеслась к данным требованиям. Было и непонимание, но был и довольно глубокий и беспристрастный анализ этого документа. Сейчас, когда эмоции улеглись, стоит еще раз внимательно взглянуть на него и попытаться понять, какой смысл авторы вкладывали в сухие строки официального документа.

Прежде чем перейти к самим требованиям, очень важно понять, что является их объектом. Ответ будет прямолинеен и прост: система электронного документооборота. Большинство авторов данных требований, судя по всему, подразумевало под СЭД ФОИВ коробочный продукт или тиражное решение, предлагаемое СЭД-вендором, -- в дальнейшем будем называть это СЭД-продуктом. Но тут, на мой взгляд, и была их главная ошибка, которая помешала взглянуть на требования под правильным углом.

Отчасти в таком недостаточно корректном восприятии требований виноваты сами авторы документа, которые пренебрегли сложившейся практикой помещать в начало или включать в виде приложения глоссарий используемых терминов. Ответ на вопрос, что же такое СЭД, они поместили почему-то во второй раздел, пункт 4: “СЭД ФОИВ представляет собой информационную систему, предназначенную для управления всеми документами ФОИВ, включая проекты документов (кроме документов, содержащих сведения, составляющие государственную тайну)”. Определение информационной системы можно найти в Федеральном законе № 149-ФЗ от 27.07.2006 “Об информации, информационных технологиях и о защите информации”, в ст. 2, п. 3: “…информационная система — совокупность содержащейся в базах данных информации и обеспечивающих ее обработку информационных технологий и технических средств”. То есть это как раз не дистрибутив системы электронного документооборота, а совокупность аппаратных (серверная часть, сетевая инфраструктура, персональные вычислительные устройства) и программных (системное, инфраструктурное, прикладное программное обеспечение и его настройки) средств, а также содержащаяся в системе информация. На мой взгляд, еще более полное определение информационной системы можно найти в руководящих документах (РД) по безопасности. Например, РД “Безопасность информационных технологий. Критерии оценки безопасности информационных технологий”, утвержденный Гостехкомиссией России 19.06.2002 дает такое определение: “Система — специфическое воплощение ИТ с конкретным назначением и условиями эксплуатации”. Это определение подчеркивает, что информационные технологии воплощены в данной системе специфическим, индивидуальным образом для достижения определенной цели. Уникальны и условия эксплуатации: помещения, организация доступа на территорию учреждения, организация работы системы (нормативы, регламенты). К условиям эксплуатации, на мой взгляд, можно отнести и персонал. Именно от его квалификации и усердия будет зависеть в конечном итоге работоспособность любой информационной системы.

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

Опять же хочется попенять авторам документа за отсутствие детальной структуры требований. Несмотря на то что, по мнению экспертов, кое-какие идеи были почерпнуты из MoReq2, требования в документе фактически свалены в одну кучу. Наличие трех больших разделов не спасает, так как, например, во втором разделе собраны самые разнообразные требования, а требования по безопасности разбросаны по всем трем разделам.

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

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

Нефункциональные требования

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

Самыми первыми идут требования по масштабируемости и производительности СЭД. Так, доступ к СЭД ФОИВ должен осуществляться в течение 3 секунд, доступ к карточке документа — в течение 5 секунд. Перебрав имеющиеся варианты, я пришел к выводу, что 3 секунды — это время реакции системы на действия пользователя, а 5 секунд — время, в течение которого должна открыться карточка документа. Полагаю, что в условиях ограниченности бюджета госорганов и кадрового голода ответственные сотрудники органа власти, занимающиеся выбором СЭД, захотят перекинуть мяч на сторону производителя системы, тогда как правильнее, на мой взгляд, было бы оценить возможности аппаратного обеспечения (и серверной, и клиентской части), архитектуру СЭД, возможности прикладного программного обеспечения, квалификацию внедренцев и администраторов.

На ликвидацию простоев системы отведено полчаса. Опять -- требование к инфраструктуре, регламентам и техническому персоналу органа власти. Если учесть объем хранимых в системе документов (об этом еще будет сказано), то сложно ожидать, что бэкап базы сможет быть поднят за такое время. Остается одно: организация отказоустойчивой системы с горячим резервированием оборудования, с дублированием баз данных. Сомневаюсь, что у отдельного органа госвласти найдутся средства на это. Остается использование облачной системы, размещенной, скажем, в ростелекомовском ЦОДе. Интересно, а требования были проверены на антикоррупционную составляющую?

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

Заслуживает внимания, на мой взгляд, требование к объему базы данных системы — она должна “обеспечивать хранение всех электронных документов, обрабатываемых в ФОИВ за период не менее 5 лет”. С легким сердцем отнесем это требование к “специфическому воплощению информационных технологий, то есть должна быть принята в расчет архитектура СЭД, ее способность обрабатывать такое количество документов и такой объем данных, а также зависимость СЭД от инфраструктурного программного обеспечения. Например, если для построения СЭД используется определенная СУБД, стоит оценить, способна ли эта СУБД масштабироваться до такого объема. Ну и, наконец, сам орган власти или уполномоченный им оператор должны обеспечить требуемый объем дискового пространства.

Функциональные требования

Функциональным требованиям посвящен практически весь второй раздел документа. После определения СЭД ФОИВ идет требование о её интегрируемости с системой межведомственного электронного документооборота (МЭДО). Это требование к конкретному экземпляру системы, ибо с точки зрения интеграции неважно, обладает ли она необходимым функционалом или применяется специализированное интеграционное решение. Разумеется, чем проще интегрировать СЭД-продукт в МЭДО, тем больше очков может набрать данный вендор в конкурсе по выбору СЭД, проводимому госорганом.

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

Захват (создание) документов

СЭД ФОИВ должна поддерживать следующие способы получения документа:

  • импорт электронного документа, поступившего по каналу МЭДО;
  • импорт электронного документа, поступившего по каналу СМЭВ;
  • импорт электронного документа, поступившего по электронной почте;
  • сканирование бумажного документа и сохранение его образа в системе;
  • сохранение в системе сведений о бумажном документе без сохранения его образа в системе (по требованиям безопасности);
  • создание документа непосредственно в СЭД ФОИВ.

Авторы отдельно остановились на вводе многокомпонентных документов: “СЭД ФОИВ должна обеспечить возможность управления этим электронным документом как единым целым, сохраняя взаимосвязи между компонентами и поддерживая структурную целостность электронного документа”. СЭД должна поддерживать возможность ввода документа в систему и при отсутствии приложения, в котором данный документ был создан.

Определены и основные требования к сбору и обработке метаданных документов, хранимых в СЭД ФОИВ. Так, СЭД должна поддерживать:

  • автоматическое извлечение метаданных для документов, полученных из МЭДО, СМЭВ и других информационных систем. Состав импортируемых полей и виды документов определяются администратором СЭД ФОИВ;
  • сохранение связи метаданных с документом на протяжении всего жизненного цикла;
  • отображение метаданных на экране;
  • запрос у пользователя ввода значений метаданных, которые не были заполнены автоматически;
  • информирование пользователя о незаполненных метаданных.

За реализацию указанных требований отвечает как непосредственно СЭД-продукт, особенно в сфере обработки метаданных, так и средства, процедуры и персонал, обеспечивающие интеграцию СЭД с электронной почтой, МЭДО, СМЭВ и другими информационными системами.

Согласование документов

Стадию согласования документа в рассматриваемых требованиях в явном виде регламентирует только один пункт. Workflow-составляющая СЭД должна соответствовать следующим требованиям:

  • доведение документов до участников процесса согласования;
  • контроль исполнения поручений.

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

Еще одно требование, которое нельзя отнести только к стадии согласования, это необходимость отображения файлов определенных форматов. Обязательные форматы -- pdf, rtf, doc, tiff, но авторы требований не имеют ничего против, если система будет способна отображать и другие форматы. Судя по этому списку, требования готовили явно не непримиримые сторонники свободного программного обеспечения. Я, право, не знаю, чем можно объяснить включение в него пусть популярных, но проприетарных форматов — принятием действительности или все же коррупционным интересом. Реализуют эти требования приложения-редакторы, которые входят в состав информационной системы СЭД ФОИВ.

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

Хранение документов

Требования предполагают, что органом госвласти будет разработана классификационная схема, состоящая из разделов и подразделов, соответствующая разделам и подразделам номенклатуры дел ФОИВ. Для каждого раздела и подраздела классификационной схемы должен быть установлен как минимум один срок хранения. Должна быть предусмотрена возможность снять/установить запрет на уничтожение раздела классификационной схемы.

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

По окончании срока хранения документа администратору системы должно быть отправлено уведомление. СЭД должна предусмотреть следующий минимальный набор действий:

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

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

Требования безопасности

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

  • защищенность от несанкционированного доступа в случаях, когда в СЭД ФОИВ предусмотрена обработка служебной информации ограниченного распространения — не ниже класса 1Г;
  • возможность фиксации документа путем запрета внесения в него изменений;
  • обеспечение аутентичности документа;
  • обеспечение целостности документа;
  • фиксацию всех операций с документом, невозможность изменить или удалить эти сведения;
  • организацию контроля доступа к документам;
  • централизованный контроль прав доступа и управление пользователями;
  • К требованиям безопасности можно отнести также требования по наличию автоматизированных процедур резервного копирования и восстановления информации.

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

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

У операторов персональных данных, не обладающих компетенцией и средствами для реализации вышеперечисленных требований, возникало вполне объяснимое желание переложить всё это на плечи СЭД-вендора. Мистический сертификат должен был заменить всю систему мероприятий.

Разумеется, часть этих требований должна быть реализована в СЭД, но но многие из них не всегда возможно и эффективно реализовать лишь на прикладном уровне.

Вместо резюме

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

Автор статьи — ИТ-аналитик DIRECTUM.

СПЕЦПРОЕКТ