(Продолжение)
Перечень больше нельзя рассматривать как «просто таблицу»
Концептуальная трансформация, которую я считаю неизбежной, заключается в следующем.
На протяжении многих лет мы [архивисты и специалисты по управлению документами – Н.Х.] рассматривали перечни в основном как инструменты архивной работы. Они по-прежнему ими остаются (подчеркиваю это, чтобы традиционалисты не обижались).
Однако в рамках цифровой экосистемы этого определение недостаточно для объяснения их технологической функции. Перечень содержит решения, определяющие классификацию документов, их группировку, их хранение и уничтожение. В электронной среде эти решения в конечном итоге должны интерпретироваться и реализовываться людьми, процессами и системами. Ввиду этого современный перечень также должен рассматриваться как ключевой инструмент управления документами.
И это существенно меняет ход дискуссии - или, скорее, «постоянные жалобы» - потому что ключевой инструмент нуждается - и об этом стоит задуматься – в обеспечении:
- версионирования;
- достоверности;
- отслеживаемости;
- согласованных идентификаторов;
- контроля изменений;
- взаимосвязей между структурами;
- переходных правил;
- интероперабельности; и
- возможности использования различными системами.
Это, конечно, не означает превращение управления документами и архивного дела в подраздел ИТ. Расслабьтесь!
Это означает признание того, что решение архивно-документационного характера, которое не может быть должным образом распространено по всей технологической экосистеме, вряд ли позволит эффективно управлять цифровой организацией. Обратите на это внимание.
- Модификация определения серии документов (в российской традиции, «серия» примерно соответствует статье в номенклатуре дел или в перечне – Н.Х.) не должна потребовать ручного обновления пяти разных систем;
- Для одного и того же типа документа не должны использоваться пять разных идентификаторов, в зависимости от приложения;
- Указание по срокам хранения не должно одновременно существовать в нескольких локальных таблицах без какого-либо контроля версий;
- Архитектура создающих документы систем должна давать их возможность распознавать и использовать устанавливаемые организацией документационные структуры.
В этом контексте обновление перечня перестает быть просто событием в управлении документами - и, несомненно, может стать событием архитектурного характера (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/
