Почему я больше не поддерживаю стандарт DoD 5015.2

 От переводчика.   Стандартизация в области управления записями — очень актуальная и очень сложная тема, дискуссии по которой мы стараемся внимательно отслеживать.  Недавно на сайте AIIM была опубликована интересная подборка полемических статей вокруг стандарта DoD 5015.2.   Этот стандарт управления записями был изначально разработан в Министерстве обороны США, однако используется он в самых разных организациях как в США, так и в других странах.  На русский язык он не переведен.  Предлагаем вниманию наших читателей статью Дона Людерса, основателя компании HarborPoint Information Management. Автор высказывается о DoD 5015.2 весьма критически: по его мнению, стандарт содержит немало усложненных требований, которые вряд ли когда-либо будут соблюдены в реальных условиях работы.   Не разделяя точку зрения Дона Людерса и во многом не соглашаясь с ним, мы, тем не менее, публикуем перевод его статьи и приглашаем читателей к ее обсуждению.   Надеемся, что в дискуссии примут участие как документоведы, так и ИТ-специалисты.  В ближайшее время мы переведем и опубликуем статьи полемические отклики на предлагаемую статью. 

Мало у кого из людей, не имеющих отношения к Министерству обороны США, есть такой опыт работы со стандартом DoD 5015.2 Критерии приложений для управления записями в электронном виде, как у меня. Я начал работу с этим стандартов в конце 90-х, заняв должность консультанта в небольшой компании под названием TrueArc. Эта компания раньше называлась Provenance, выпускавшей систему управления записями ForeMost. Незадолго до моего прихода в компанию ForeMost стала первой системой управления записями, сертифицированной по стандарту DoD 5015.2.

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

 

 

В прошлом я был приверженцем стандарта DoD и действительно считал, что он при всех своих недостатках является вполне неплохой теоретической основой для управления записями в электронном виде. В последние годы, впрочем, я стал думать по-другому и считатю, что этот стандарт является не более чем музейным экспонатом, основанным на бизнес-модели двадцатилетней давности и что предпринятая его разработчиками попытка сформулировать требования к управлению электронными записями в течение всего их жизненного цикла оказалась безуспешной. Ниже я подробное расскажу о том, почему мое мнение о DoD 5015.2 изменилось.
Первая версия стандарта DoD 5015.2 появилась в 1996 году после долгих месяцев напряженной работы аналитиков Министерства обороны при поддержке приглашенных консультантов по управлению записями. С точки зрения технического прогресса 1996 год — это далекое прошлое. Многие, я думаю, помнят, что в начале 1990-х годов появились первые приложения для управления документами. Множество вендоров предлагали огромное число продуктов, но лишь небольшому числу предлагаемых решений удалось захватить значительную часть рынка.

 

 

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

 

 

Все начиналось точно так же, как и с системами управления документами: сначала было выпущено множество решений, но рынок впоследствии был охвачен лишь небольшим количеством продуктов. (Значение маркетингового хода, каковым прежде всего было разделение на документы и записи, мало кто адекватно оценивает. То, что на разных стадиях жизненного цикла управление документами осуществляется при помощи ПО разных категорий, только укрепляет убежденность в том, что весь неструктурированный контент можно разделить на официальные документы и не официальные записи. На самом деле все документы имеют доказательственное значение, и управление ими должно осуществляться соответствующим образом. Уверен, что разделение на документы и записи нанесло огромный ущерб ECM-индустрии, пользователям, вендорам и профессионалам в области управления записями). — Наш комментарийС этим высказыванием автора мы вряд ли можем согласиться. Документы (documents) и записи (records) представляют собой два разных типа объектов, управление которыми осуществляется при помощи различного ПО.  Нивелирование различия между documents и records вызвовет еще большую путаницу.
И хотя некоторые наиболее дальновидные вендоры уже пытались объединять решения для управления с уже существовавшими тогда решениями для управления записями, создавая таким образом первые несовершенные ECM-решения, разделение на документы и записи было широко распространенной практикой, когда в Министерстве обороны было принято решение создании первой версии стандарта. Было решено стандартизировать практику управления документами на конечной стадии жизненного цикла, осуществляемую с помощью приложений для управления записями, не принимая во внимания практику управления жизненным циклом, реализуемую с помощью приложений для управления документами.
Сказанное выше вполне объясняет , почему DoD получил название «Критерии для разработки приложений по управлению электронными записями» и почему в самом стандарте утверждается «излагаются обязательные базовые требования к приложениям, используемых для управления записями во всех подразделениях Министерства обороны.
Проблема очевидна для каждого, кто хотя бы поверхностно имел дело с ECM: независимых приложений для управления записями не существует вот уже почти как десять лет! Период конца прошлого — начала нынешнего века был отмечен волной приобретений небольших компаний-поставщиков решений для управления записями вендорами ПО для управления документами. Два типа продуктов были интегрированы (с разной степенью успешности): так получились первые ECM-решения. Они позволяли управлять неструктурированным контентом на всех стадиях жизненного цикла: от создания до перевода на архивное хранение и удаления.
В стандарте DoD вообще не уделено внимания произошедшим изменениям в области технологий управления контентом. Во все трех версиях, появившихся на протяжении 17 лет, он представлял собой детальный набор функциональных требований к приложениям по управлению записями.

 

 

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

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

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

Я не внес никакого вклада в создание стандарта DoD 5015.2. Когда он повергался пересмотру, я тоже не вносил никаких предложений. Если бы я что-то сделал, то, думаю, у меня получилось бы лучше, чем у специалистов из Министерства обороны.

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

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

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

 

 

 

 

Выделение в отдельную группу записей с истекающим сроком хранения

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

Я не знаю, зачем нужно использовать подобную практику по отношению к записям в электронном виде. Записи с истекающим сроком хранения в бумажном виде объединяли в отдельные папки, чтобы затем было удобнее их упаковывать и уничтожать. (Например, одна запись должна быть удалена 3 июня, вторая — 17, третья — 25; все они помещаются в отдельную папку и хранятся там до конца месяца, т. е. до 30 июня, а затем уничтожаются.

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

 

 

Управление метаданными

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

 

 

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

 

 

 

 

Управление электронной почтой

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

 

 

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

Представьте себе, что вам нужно распределить само сообщение электронной почты и четыре вложения по категориям, назначить им всем разные (!) наборы метаданных и добавить к ним ссылку на само сообщения и остальные вложения. Впечатляет, правда? При этом речь идет только об одном сообщении электронной почты. А ведь в реальной жизни приходится ежедневно иметь дело с огромным количеством почтовых сообщений! Поэтому работать в точности так, как описано в стандарте, вряд ли получится.

 

 

Неэлектронные документы

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

 

 

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

 

 

Отношения и связи между записями

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

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

 

 

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

 

 

Модель безопасности, основанная на метаданных

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

 

 

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

 

 

Ограничения доступа могут использоваться дополнительно. Например, некоему документу может быть добавлено свойство «Регион», которое может принимать три значения: Регион А, Регион B, Регион C. Эти свойства могут быть приписаны пользователям и группам пользователей. При этом пользователю, которому назначено свойствуо «Регион» с одним значениям, доступны документы, у которых это свойство имеет другое значение. Например, пользователю со свойством «Регион А» будут доступны документы со свойствами «Регион В» или «Регион С».

 

 

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

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

 

 

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

 

 

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

 

 

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

 

 

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

 

 

Например, я видел решения (в разработке которых участия не принимал) для управления потоками работ, в которых требуется приостанавливать процессы по наступлении определенного события, а затем возобновлять их по истечении срока хранения записи. А если срок хранения составляет 25 лет? Какая организация будет поддерживать приостановленные процессы в течение всего этого срока? Это все равно, что остановить автомобиль и бросить посреди дороги с оживленным движением. Может быть, имеет смысл сократить срок хранения до 10 лет? Или даже до 5?

 

 

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

 

 

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

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