За гранью MoReq-2

Евгений Кочуров

Со времен 2001 года, когда был впервые опубликован оригинальный MoReq¹, практика использования его типовых требований к системам управления официальными документами перешагнула границы Европейского союза. Так, в новой версии спецификации даже добавлена глава, содержание которой будет определяться индивидуально национальными стандартами и традициями.

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

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

Трудности терминологии

Существует несколько вариантов переводов для терминов, используемых в MoReq2, в частности, даже в официальных переводах первой и второй версии MoReq термин ERMS, «Electronic Record Management System», переводится по-разному: в первой версии - АСЭД, «автоматизированная система электронного документооборота», во второй версии - СУЭОД,  «система управления электронными официальными документами». Из уже сложившейся русскоязычной терминологии наиболее близок (хотя и не совпадает по значению) к ERMS термин «система электронного документооборота» (СЭД).

Трудность возникает в самом понятии «документа» - в английском то, что мы понимаем под документами, делится на documents и records. В этом контексте «record» обычно переводят на русский, как «официальный документ»; «document» же, чтобы отличить его от record, переводят, как «информационный документ».  Поэтому, когда речь заходит о некоем «управлении документами», часто остается недосказанным, идет ли речь о documents, records или об обеих сущностях сразу.

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

Тест на соответствие

Одна из особенностей новой версии – была добавлена классификация требований для целей формального тестирования систем на соответствие MoReq2:

●  Требование может быть протестировано формально.

●  Требование не может быть протестировано формально.

●  Требование может быть протестировано, но лишь с частичным покрытием. Примером такого вида требований является «ERMS не должна ограничивать число уровней иерархии классификации официальных документов». Ясно, что утверждение о полном соответствии некоторой системы этому требованию проверить невозможно, но это и не нужно, т.к. в большинстве случаев предпочитают ограничиться относительно небольшим уровнем вложенности классификации.

На сегодняшний день существует только одна организация, аккредитованная DLM-форумом для проведения независимого тестирования ПО на соответствие требованиям MoReq2 – Imbus AG, которая и разработала спецификацию тестовых модулей, опубликованных в составе MoReq2.

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

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

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

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

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

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

«Небольшие» дополнения

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

И, надо сказать, объем функциональности, вынесенной за рамки обязательных модулей, весьма обширен:

●  управление неэлектронными (аналоговыми) документами;

●  хранение и списание гибридных папок;

●  управление информационными документами и средства коллективной работы (EDMS и Collaboration);

●  рабочие процессы (Workflow);

●  управление делами (Casework³);

●  интеграция с системами управления содержимым (контентом) (Content Management System);

●  электронная подпись;

●  шифрование;

●  средства защиты интеллектуальной собственности (Digital Rights Management);

●  поддержка распределенных систем;

●  средства поддержки в условиях удаленной работы и непостоянной связи;

●  интеграция с факсом;

●  управление категориями безопасности (грифами доступа).

Может показаться удивительным, что столь важные функции, как Workflow или поддержка распределенных систем признаны необязательными компонентами. Чтобы понять причины, придется разобраться, к чему же все-таки предъявляет требования MoReq.

EDMS и ERMS

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

Параллельно с технологией ERMS существует множество других (EDMS, Workflow, ECM, Collaboration, CMS и т.д.), которые реализованы все вместе или по отдельности в продуктах различных поставщиков. Поскольку все эти технологии так или иначе связаны с неструктурированной информацией, функциональность соответствующих продуктов часто пересекается. Более того, по мере развития идеологий ERMS и EDMS постепенно стирались границы между ними, количество общих функциональных точек все увеличивалось. Вместе с тем, ключевые различия все же сохранились.

EDMS (Electronic Document Management System) дословно означает «Система управления электронными документами». Часто такое определение вызывает вопрос, чем же этот класс систем отличается от ERMS. Итак, приведем различия, которые существенны с точки зрения MoReq2:

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

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

И снова: MoReq2 не покрывает всех требований, предъявляемых бизнесом,  на этот раз уже функциональных.

К ECM через MoReq?

Число компаний, понимающих ценность автоматизированных технологий работы с документами, постоянно растет. И каждая из них сталкивается с одной и той же проблемой: с чего начать? MoReq2 позиционируется создателями как спецификация требований к системе на этапе подготовки тендера. При этом оговаривается, что речь идет только о ERMS-системах. Поэтому, когда первоочередными целями автоматизации являются задачи, присущие в большей степени EDMS, т.е. ориентированные на поддержку всех пользователей, а не только делопроизводителей, использовать MoReq как основу не всегда оправданно.

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

Практичным выходом было бы воспользоваться лишь частью требований, затрагивающих только критичные для организации области. Например, если на первой очереди стоят EDMS, Collaboration и Workflow, то включать в требования к внедряемой системе только соответствующие разделы документа MoReq2, предварительно переработав и дополнив их. О необходимости дополнений можно судить хотя бы на основании того факта, что все требования к EDMS и Collaboration взятые вместе умещаются на шести страницах. Переработка же потребуется в силу того, что требования в дополнительных  разделах MoReq2 сформулированы как дополнения к требованиям ERMS. Например, требование «ERMS должна позволять создавать новый электронный документ как копию официального документа без пометки созданного документа, как официального» будет переформулировано в «EDMS должна позволять создавать копии документов».

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

Резюме

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

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

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

Источники и полезные ссылки

1. Сайт MoReq2 https://www.moreq2.eu.

2. Сайт 5-ого DLM-форума, на котором обсуждался MoReq2 https://www.dlm2008.com.

3. Компания Imbus AG, разработчик тестового фреймворка для MoReq2 https://www.imbus.de.

4. Интервью с Марком Фреско, руководителем проекта создания MoReq2 https://www.delo-press.ru/magazines/documents/issue/2008/11/6872/.

*  *  *

1. Cпецификация MoReq описывает типовые требования (Model Requirements) к управлению электронными документами (Management of Electronic Record), создана в 2001 г. группой консультантов Cornwell (ныне Serco Consulting) по инициативе DLM-форума, разработка финансирована Европейской Комиссией.

2. Англ. термин «Capture» несколько шире по значению, чем его перевод «Регистрация», и включает в себя такие функции, как классификация и извлечение метаданных из неструктурированных документов, потоковый ввод, «захват» сообщений электронной почты и т.д.

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