Запаздывание в управлении документами: Когда время становится параметром риска в архивно-документационной работе (3)

(Продолжение, предыдущую часть см. https://rusrim.blogspot.com/2026/09/2_01441442037.html )

Когда запаздывание приводит к накоплению необработанной документации («документального долга»)

Здесь я вижу ещё более глубокие последствия (в данном вопросе многие, однако, делают вид, что ничего не замечают...). Если документальная реальность меняется, а инструментам требуется слишком много времени, чтобы на это отреагировать, то организация начинает накапливать нечто вроде «долга в области управления документами» (deuda de gobierno documental). На протяжении подобного периода времени могут появиться следующие проблемы:

• недостаточно чётко определенные типологии;
  
  
• непоследовательная классификация;
  
  
• дела, сформированные по разным правилам;
  
  
• параллельные структуры;
  
  
• неоднородные метаданные;
  
  
• устаревшие параметры;
  
  
• «устанавливаемые вручную» правила работы, которые трудно воспроизвести;

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

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

Или, более точно:

Связанный с документами риск = f (Запаздывание × Критичность × Объем × Скорость изменений × Слабость механизмов контроля на переходном этапе)

Такой подход позволяет нам проанализировать и понять нечто важное - обратите внимание:

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

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

Проблема управления версиями 

Есть еще один аспект, который я считаю особенно важным. Предположим, организация изменяет свою структуру документов в январе. В течение последующих месяцев она продолжает создавать документы. Затем соответствующий инструмент корректируется. Потом он снова модифицируется. Наконец, вступает в силу определенная версия. И тут встаёт, казалось бы, простой вопрос: «В рамках какой структуры документов осуществилось управление создаваемыми документами в течение каждого интервала?».

Здесь «временная» прослеживаемость (прошу прощения за такой термин) становится основополагающей, поскольку, на мой взгляд, простого сохранения последней версии перечня недостаточно.

Нам необходимо иметь возможность реконструировать:

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

При управлении электронными документами всё чаще будет требоваться рассматривать соответствующие инструменты как имеющие версии структуры управления (estructuras versionadas de gobierno), а не просто как периодически заменяемые документы.

В отсутствие динамичного управления автоматизация ограничена

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

• Автоматическая классификация,
  
  
• Автоматическое формирование дел и досье,
  
  
• Искусственный интеллект,
  
  
• Извлечение метаданных,
  
  
• Электронная передача,
  
  
• Обеспечение долговременной сохранности электронных материалов.

Но ранее мы уже спрашивали себя: «в рамках какой стабильной, идентифицируемой и версионированной институциональной структуры работает эта автоматизация?».

Искусственный интеллект способен классифицировать миллионы документов - но ему необходимо знать контекст, в котором он проводит классификацию.

• Система может автоматически формировать дела – но для этого ей нужны правила;
  
  
• Система управления электронными документами (SGDEA) может управлять сроками хранения и исполнять установленные действия по их истечении – но для этого ей нужны актуальные и регламентированные структуры.

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

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

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

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

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

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

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

создание → классификация → формирование дел → хранение → передача на архивное хранение → обеспечение долговременной сохранности

«Документальны долг» никуда не исчезает, он перемещается во времени (разумеется, путешествуя «первым классом»! :)), и обычно его последствия становятся тем более затратными, чем дольше мы занимаемся его ликвидацией.

(Окончание следует)

Джон Гонсалес (Jhon Alexander González Flórez)

Источник: LinkedIn
https://www.linkedin.com/pulse/la-latencia-del-gobierno-documental-cuando-el-tiempo-se-gonzalez-f--atcae/ 

Документирование создания и эксплуатации информационных систем государственными органами, часть 1

Правительство Российской Федерации постановлением от 13 августа 2026 № 1007 утвердило «Требования к порядку создания и эксплуатации государственными органами информационных систем, не являющихся государственными информационными системами», в которых установлены требования к документированию создания и эксплуатации таких информационных систем (ИС).

Государственными органами при создании и эксплуатации ИС осуществляется их учет в соответствии с «Положением об учете ИТ-активов, используемых для осуществления деятельности по цифровой трансформации системы государственного (муниципального) управления», утвержденным постановлением Правительства Российской Федерации от 1 июля 2024 г. № 900 (п.7). 

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

• Правовой акт государственного органа о создании ИС (п. 8)
  
  
• Техническое задание на создание ИС (п. 11)
  
  
• Эксплуатационная документация (п. 19)
  
  
• Документы о правах на интеллектуальную собственность (п. 20)
  
  
• Документы учета в системе координации (п. 7, п. 13)
  
  
• Технико-экономическое обоснование (ТЭО) (п. 10)
  
  
• Правовой акт о вводе ИС в эксплуатацию (п. 18)

Правовой акт государственного органа о создании ИС (п. 8)

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

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

Отсутствие такого акта делает создание ИС нелегитимным. Это особенно важно для бюджетного планирования и контрольных мероприятий, поскольку для любых затрат на ИС должно иметься правовое основание.

Техническое задание на создание ИС (п. 11)

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

Установлены следующие требования к содержанию ТЗ:

• «ТЗ разрабатывается с учетом модели угроз безопасности информации» - это означает, что заказчик (государственный орган) обязан предварительно провести анализ возможных угроз и отразить в ТЗ соответствующие меры защиты.
  
  
• ТЗ должно учитывать уровни защищенности персональных данных, определенные в соответствии с Федеральным законом «О персональных данных», в зависимости от конкретных угроз.

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

Эксплуатационная документация (п. 19) разрабатывается, начиная с этапа создания ИС, и предназначена для использования на этапе её эксплуатации. 

Документы о правах на интеллектуальную собственность (п. 20)

Постановление устанавливает запрет на эксплуатацию ИС без надлежащего оформления прав на использование её компонентов, являющихся объектами интеллектуальной собственности:

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

Это означает, что государственный орган обязан, в частности, располагать:

• Лицензионными договорами или сублицензиями на все используемое ПО;
  
  
• Актами передачи исключительных прав (для заказного ПО);
  
  
• Документами, подтверждающими наличие прав на открытое ПО с учетом его лицензий (GPL, MIT и т.п.), если такие компоненты используются.

Отсутствие таких документов делает эксплуатацию ИС не вполне нелегитимной, даже если технически всё работает. Также в таком случае нельзя будет зарегистрировать ИС  как «соответствующую стандартам».

Документы учета в системе координации информатизации (п. 7, п. 13)

Речь идет о сведениях об информационной системе, которые размещаются государственным органом в Федеральной государственной информационной системе координации информатизации (ФГИС КИ).

Для справки: Федеральная государственная информационная система координации информатизации (ФГИС КИ) предназначена для технического обеспечения учёта и мониторинга мероприятий по информатизации государственных органов и учреждений. Помимо этого, в её функции входят: проектное управление ведомственными программами цифровой трансформации, информационно-аналитическая и методическая поддержка пользователей, формирование статистической отчётности и распространение общедоступной информации см.: https://digital.gov.ru/activity/czifrovizacziya-gosudarstva/czifrovaya-transformacziya/federalnaya-gosudarstvennaya-informaczionnaya-sistema-koordinaczii-informatizaczii-fgis-ki?ysclid=mtpy4vger8242705463 .

п.7. Государственными органами при создании и эксплуатации ИС осуществляется их учет в соответствии с «Положением об учете ИТ-активов, используемых для осуществления деятельности по цифровой трансформации системы государственного (муниципального) управления», утвержденным постановлением Правительства Российской Федерации от 1 июля 2024 г. № 900. 

п.13. Оценка информационных систем осуществляется посредством обработки системой координации сведений, размещенных государственными органами при ведении учета информационных систем.

Учёту и фиксации подлежат:

• Сведения о самой ИС (наименование, назначение, фасет, используемое ПО);
  
  
• Результаты оценки соответствия стандартам (п. 12–13);
  
  
• Статус системы (соответствует/не соответствует);
  
  
• Информация о компонентах ИС для простановки специального признака в реестрах ПО.

Ответственность за достоверность и актуальность этих сведений несут руководитель и уполномоченные лица государственного органа (п. 14). Это персональная ответственность, закрепленная законодательством РФ.

(Окончание следует)

Источник: Консультант Плюс
https://www.consultant.ru/cons/cgi/online.cgi?req=doc;base=LAW;n=541976

Запаздывание в управлении документами: Когда время становится параметром риска в архивно-документационной работе (2)

(Продолжение, предыдущую часть см. https://rusrim.blogspot.com/2026/09/1_0966289141.html )

Перечень больше нельзя рассматривать как «просто таблицу»

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

На протяжении многих лет мы [архивисты и специалисты по управлению документами – Н.Х.] рассматривали перечни в основном как инструменты архивной работы. Они по-прежнему ими остаются (подчеркиваю это, чтобы традиционалисты не обижались). 

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

И это существенно меняет ход дискуссии - или, скорее, «постоянные жалобы» - потому что ключевой инструмент нуждается - и об этом стоит задуматься – в обеспечении:

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

Это, конечно, не означает превращение управления документами и архивного дела в подраздел ИТ. Расслабьтесь!

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

• Модификация определения серии документов (в российской традиции, «серия» примерно соответствует статье в номенклатуре дел или в перечне – Н.Х.)  не должна потребовать ручного обновления пяти разных систем;
  
  
• Для одного и того же типа документа не должны использоваться пять разных идентификаторов, в зависимости от приложения;
  
  
• Указание по срокам хранения не должно одновременно существовать в нескольких локальных таблицах без какого-либо контроля версий;
  
  
• Архитектура создающих документы систем должна давать их возможность распознавать и использовать устанавливаемые организацией документационные структуры.

В этом контексте обновление перечня перестает быть просто событием в управлении документами - и, несомненно, может стать событием архитектурного характера (evento arquitectónico).

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

Здесь важно избегать нередко встречающегося чрезмерного упрощения, с учётом того, что:

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

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

Ответственность самой организации

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

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

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

В противном случае мы можем породить легкомысленное и даже опасное, отношение: «Поскольку инструмент еще не прошёл валидацию, мы не модем двигаться дальше».

С точки зрения корпоративной архитектуры - инженеры-архитекторы, внимание! - вопрос должен ставиться иначе: «Какие инструменты организация разработала для управления переходным периодом в плане работы с документами?».

Утверждение (валидация) как архитектурный фактор

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

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

Эти вопросы не должны решаться после возникновения проблемы. Они должны рассматриваться в ходе проектирования (что, на мой взгляд, очевидно).

Реальный риск: превращение утверждения (валидации) в единую точку отказа

Существует широко используемое в технологической архитектуре понятие «единая точка отказа» (Single Point of Failure, SPOF). Считается, что компонент представляет собой единую точку отказа, если его недоступность или отказ могут остановить работу всей системы. Нечто подобное может произойти и в институциональной среде. Если вся стратегия управления документами последовательно зависит от следующего:

Актуализация перечня → Валидация (утверждение) перечня → Заключение контрактов → Параметризация → Организация работы → Автоматизация → Передача на архивное хранение → Обеспечение долговременной сохранности

- то любая задержка на ранних этапах может задержать всё остальное. В такой ситуации следует ожидать, что будет задан неизбежный вопрос: «Кроется ли проблема исключительно в задержке на «внешнем» этапе - или также в том, что была спроектирована архитектура, неспособная компенсировать эту задержку?»

Имейте в виду, я поднимаю этот вопрос не для того, чтобы переложить ответственность на кого-то; напротив, ответ на него позволяет мне (нам) правильно её распределить. 

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

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

(Продолжение следует)

Джон Гонсалес (Jhon Alexander González Flórez)

Источник: LinkedIn
https://www.linkedin.com/pulse/la-latencia-del-gobierno-documental-cuando-el-tiempo-se-gonzalez-f--atcae/ 

Обязательные стандарты Минцифры для ведомственных информационных систем

В условиях цифровой трансформации государственного управления особое значение приобретает правовое и технологическое регулирование информационных систем (ИС), используемых органами власти для обеспечения собственных организационных, информационных, документационных, финансовых и технических нужд. При этом значительная часть таких систем не относится к категории «государственных информационных систем» (ГИС), однако их функционирование напрямую влияет на эффективность государственного управления.

Правительство Российской Федерации постановлением от 13 августа 2026 № 1007 утвердило «Требования к порядку создания и эксплуатации государственными органами информационных систем, не являющихся государственными информационными системами», которое вступило в силу 1 сентября 2026 года.

Документ устанавливает требования к порядку создания и эксплуатации государственными органами информационных систем, не являющихся государственными информационными системами (они упоминаются в части 1.1 статьи 13 федерального закона «Об информации, информационных технологиях и о защите информации»), в целях организационного, информационного, документационного, финансового и технического обеспечения деятельности этих органов.

Следует отметить введённые в документе определения (п.2):

• «стандарт» - документ, устанавливающий минимальные требования к информационным системам в части состава осуществляемых функций, реализуемых процессов, к иным характеристикам, которым должны соответствовать ИС, относящиеся к соответствующему фасету информационной системы (фасетам);
  
  
• «фасет информационной системы» - группа уникальных классификационных признаков ИС, объединенных на основе их характеристик и иных параметров.

Стандарты разрабатываются Министерством цифрового развития, связи и массовых коммуникаций Российской Федерации (Минцифры России) и утверждаются президиумом Правительственной комиссии по цифровому развитию, использованию информационных технологий для улучшения качества жизни и условий ведения предпринимательской деятельности (п.3).

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

Интересно, что, согласно информации на сайте Правительства РФ, последнее заседании Президиума комиссии состоялось в ноябре 2022 года (см: http://government.ru/news/47127/ )

Стандарты размещаются в течение 2 рабочих дней со дня их утверждения президиумом Комиссии в интернете на портале федеральной государственной информационной системы (ФГИС) координации информатизации, функционирование которой осуществляется в соответствии с «Положением о федеральной государственной информационной системе координации информатизации», утвержденным постановлением Правительства Российской Федерации от 14 ноября 2015 г. №1235 (п.4).

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

Уполномоченный орган по результатам рассмотрения предложений принимает решение о разработке стандарта с указанием сроков его разработки либо направляет мотивированный отказ с установлением требований применения действующих стандартов в следующих случаях (п.6):

• Предложение государственного органа по разработке стандарта не содержит обоснования необходимости его разработки;
  
  
• Имеется утвержденный президиумом Комиссии стандарт (стандарты), которым установлены требования для соответствующего фасета ИС (фасетов);
  
  
• Предложение государственного органа по разработке стандарта предусматривает цели создания ИС, не соответствующие целям, установленным частью 1.1 статьи 13 Федерального закона «Об информации, информационных технологиях и о защите информации».
  
  Мой комментарий: Данный пункт вводит «фильтр», позволяющий отклонять инициативы, выходящие за рамки «обеспечения деятельности органов власти» (в их число потенциально могут попасть проекты, связанные с оказанием услуг населению или созданием общедоступных сервисов). 

Мой комментарий: Следует отметить, что в Постановлении под «стандартом» понимается документ, устанавливающий минимальные требования к информационным системам государственных органов. Этот стандарт не является национальным стандартом (ГОСТом) в смысле Закона о стандартизации; он разрабатывается не Росстандартом в рамках программы национальной стандартизации, а Минцифры и утверждается президиумом Правительственной комиссии.

Для сравнения: Федеральный закон от 29.06.2015 № 162-ФЗ «О стандартизации в Российской Федерации»

5) национальный стандарт - документ по стандартизации, который разработан участником или участниками работ по стандартизации, в отношении которого проведена экспертиза в техническом комитете по стандартизации или проектном техническом комитете по стандартизации и в котором для всеобщего применения устанавливаются общие характеристики объекта стандартизации, а также правила и общие принципы в отношении объекта стандартизации

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

Источник: Консультант Плюс
https://www.consultant.ru/cons/cgi/online.cgi?req=doc;base=LAW;n=541976