MoReq (2002)


Home » Библиотека » Стандарты » Система электронного документооборота » Типовые Требования к СЭД  » MoReq (2002)

Официальный документ и электронный официальный документ

В материалах DLM-Форума (Приложение 1 ссылка [6] раздел 2.4) предлагается рассматривать служебные документы как состоящие из:

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

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

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

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

Электронные дела и тома

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

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

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

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

Схема классификации

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

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

Папки (дела) могут появляться на любом уровне иерархии. Это показано на рисунке выше, который является адаптацией из ISAD(G) (Приложение 1 ссылка [7]).

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

Класс

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

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

Данная спецификация не делает попытки определить, как схема классификации должна быть построена; этот вопрос рассматривается в другой литературе, например

Данная спецификация не делает попытки определить, как схема классификации должна быть построена. Это вопрос рассматривается в другой литературе, например UBC-MAS (Приложение 1 ссылка [8]).

Автоматизированная система электронного документооборота (АСЭД)

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

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

Регистрация документов

Документы, произведенные или полученные в процессе деятельности организации, становятся официальными, когда они регистрируются в АСЭД. В процессе регистрации документы “классифицируются”, т.е. им присваиваются коды соответственно классам, к которым они относятся, что позволяет АСЭД управлять ими. Кроме того, каждому документу присваивается уникальный идентификатор.

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

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

Роли пользователей

Данная спецификация определяет два типа пользователей:

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

“Администратор”    пользователь, который управляет документами, хранящимися в АСЭД и самой АСЭД вместе с ее базой данных.

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

  1. Модель “сущность-связь”

    В данном разделе описывается модель “сущность – связь”, которая имеет своей целью облегчить понимание данной спецификации. Раздел 13.3 содержит более пространное объяснение.

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

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

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

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

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


  1. Схема классификации

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

    В этой главе сначала перечисляются требования по настройке схемы классификации в разделе 3.1. Затем перечисляются требования относительно классов и папок (раздел 3.2) и томов (раздел 3.3). В заключительной секции (3.4) перечисляются требования по ведению схемы классификации.

  1. Настройка схемы классификации

Требование

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

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

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

Ни в коем случае не должно быть ограничений на число уровней классификации в иерархической схеме.

АСЭД обязательно должна предоставлять настраиваемый механизм именования узлов (уровней).

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

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

Это может быть на любом уровне.

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

АСЭД обязательно должна поддерживать определение и одновременное использование нескольких схем классификации.

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

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

  1. Классы и папки (дела)

    В данном разделе приведены требования применительно к классам и
    папкам (делам).

Требование

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

Требования к метаданным приведены ниже в главе 12.

АСЭД обязательно должна предоставлять, по крайней мере, два механизма именования электронных папок и классов в схеме классификации:

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

Обязательно должна быть возможность независимого параллельного использования обоих механизмов.

АСЭД обязательно должна разрешать администратору добавить (открыть) папку (дело) только на самом нижнем уровне класса в схеме классификации.

Замечание: не обязательно, чтобы все классы имели одинаковое число уровней.

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

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

Например, если папка “Корреспонденция” расположена в иерархическом пути:

    План регионального развития : публичное обсуждение : Корреспонденция

и администратор добавляет новую папку именуемую “Формальные возражения” на том же уровне, что и папка “Корреспонденция”, то эта папка должна автоматически наследовать префикс ” План регионального развития :  Консультации с общественными организациями “.

АСЭД должна поддерживать опциональный механизм именования классов и папок, который основывается на терминах из управляемого словаря и отношениях из тезауруса, совместимого с ISO 2788 или ISO 5964, а также связи на основе тезауруса в схеме классификации.

АСЭД должна поддерживать опциональный механизм именования классов и папок, который включает названия (в т.ч. персональные имена) и/или даты (в т.ч. даты рождения) как названия папок, включая сверку этих имен по справочникам.

Это требование применимо к транзакционным системам. (Например, кадрового учета – прим. перев.)

АСЭД должна поддерживать назначение терминов из управляемого словаря, совместимого с ISO 2788 или ISO 5964 в качестве описательных метаданных класса или папки в дополнение к другим требованиям данного раздела.

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

АСЭД обязательно должна позволять автоматическое создание и ведение списка (описи) папок (дел).

 

Pages: 1 2 3 4 5 6 7 8 9

Комментарии закрыты.