(Продолжение, начало см. http://rusrim.blogspot.com/2012/03/i.html )
Момент третий: Конфигурирование/настройка системы
Время конфигурирования и ввода в эксплуатацию системы является критической точкой для управления документами. Очевидно, что то, как система проектируется, создается и развертывается, самым существенным образом влияет на её возможности по управлению документами. При настройке своих систем необходимо проверить, все ли соответствующие поля метаданных активизированы, все ли соответствующие функциональные возможности имеются в наличии, и сможет ли система на деле формировать необходимые Вам типы документов.
Кроме того, документирование конфигурации системы весьма важно с точки зрения обеспечения долговечности информации и сохранения деловой информации до тех пор, пока в ней сохраняется потребность.
Так, например, одна крупная государственная организация использовала SharePoint во всех сферах своей деятельности. За три года использования организация неоднократно переконфигурировала и перенастраивала свою инсталляцию SharePoint. Эти конфигурации редко документировались. Когда пришло время для проведения миграции, не оказалось в наличии доступной, пригодной для использования документации, точно описывающей, как именно система использовалась. В результате миграция оказалась очень трудоемким и длительным процессом. Кроме того, не было возможности установить состав ключевых компонентов системы, а также определить, были ли извлеченные и мигрированные вместе с документами метаданные наиболее точными и актуальными. Метаданные часто упускают из виду, однако сведения о том, как они сконфигурированы, является ключевой деловой информацией. Деловой системой гораздо сложнее управлять и намного труднее её поддерживать в отсутствие документированной информации о том, как именно применялись метаданные.
Точно так же для приложений «веб 2.0», таких, как блоги, хорошая документация по архитектуре реализованной системы необходима для проведения миграции и поддержания этих сред и их данных во времени и при частых обновлениях программного обеспечения, влияющих на эти приложения.
Момент четвертый: Использование необычных, устаревающих или сложных форматов
Необычные, устаревающие и сложные форматы может быть трудно поддерживать во времени. С управлением этими форматами во времени связан один из основных рисков для управления документами.
Опубликованная в январском 2012 года номере американской военной газеты «Звёзды и полосы» (Stars and Stripes) статья «По мере того, как развивается технология, военным приходится решать проблему обеспечения сохранности важнейших инженерных данных» (As technology evolves, military wrestles with preserving vital engineering data, http://www.stripes.com/news/as-technology-evolves-military-wrestles-with-preserving-vital-engineering-data-1.166093 ) ярко иллюстрирует сложность данной проблемы и рассказывает о больших усилиях, предпринимаемых для отыскания решений.
В статье описаны проблемы, с которыми столкнулось Министерство обороны США при обеспечении долговременной сохранности своих электронных данных. Основные для американцев проблемы связаны с форматами, с необходимостью обеспечить доступность хранимых данных и их непротиворечивость.
Проблемы возникли в связи с тем, что многие активы оборонного ведомства, такие, как корабли и самолеты, имеют очень долгий срок службы. Их чертежи и схемы хранятся в сложных электронных форматах. В статье цитируется следующее высказывание специалиста Национальных Архивов США по электронным данным Марка Конрада (Mark Conrad): «Когда флот спускает на воду новый корабль, ожидается, что он прослужит около 50 лет, - однако программное обеспечение системы автоматизированного проектирования (САПР), использованное при его конструировании, имеет срок службы около 18 месяцев. Компании-разработчики программного обеспечения делают деньги за счет внедрения новых наворотов и «примочек»... но при обновлении программного обеспечения, при попытке перемещения информации из одной системы в другую может оказаться, что навороты и «примочки» системы А не поддерживаются системой Б». В результате может оказаться необходимым проводить миграцию планов и чертежей таких активов каждые 18 месяцев.
При попытке обновить или мигрировать файлы в старых форматах и «подтянуть» их до более свежих версий преобразования могут оказаться некорректными. Старший консультант компании, специализирующейся на решении проблем интероперабельности САПР-решений говорит, что эти проблемы «могут очень быстро возникнуть при перемещении инженерных данных из одной системы в другую. Это может быть или потеря данных, или их интерпретация не тем образом, как изначально предполагалось... Больше всего специалистов беспокоят коварные, трудно обнаруживаемые ошибки и нестыковки, которые остаются незамеченными и накапливаются, а пользователи при этом по-прежнему считают модели данных правильными. И только выходя из цифрового мира в реальный, Вы вдруг осознаёте, что у Вас есть серьезные проблемы.»
Поэтому, если необходимо иметь доступ, хранить и использовать цифровую информацию долее 3 -5 лет, следует обратить особое внимание на выбор и управление форматами. И если документы в сложных форматах служат для поддержки долгоживущих активов, таких, как здания, инфраструктуры или критически-важное оборудование, нужно очень внимательно отнестись к управлению такими документами и бдительно отслеживать появление малозаметных изменений, которые со временем могут в них появиться. Следует принять все возможные меры для уменьшения всех возможных уязвимостей и управления ими.
(Окончание следует, см. http://rusrim.blogspot.com/2012/03/iii.html )
Кейт Камминг (Kate Cumming)
Источник: сайт архивно-документационной службы штата Новый Южный Уэльс, Австралия
http://futureproof.records.nsw.gov.au/top-7-moments-you-should-think-is-my-digital-information-ok/
Комментариев нет:
Отправить комментарий