Все проектные организации, независимо от масштаба, так или иначе сталкиваются с проблемой организации электронного архива разработанной документации. Сразу заметим, что все проектные организации считают, что такой архив у них есть, но вот организованы они зачастую очень различными способами.
Способов организации электронного архива существует достаточно много, попробуем перечислить их:
К недостаткам 1-го и 2-го способа отнесем следующие:
Недостатки 3-го способа заключаются в следующем:
Четвертый способ имеет следующие недостатки:
Таким образом, нужно понимать, что идеального способа хранения файлов не существует. Так или иначе организация архива (да и любого другого объекта во вселенной) это предмет компромисса между потребностями, удобством использования, стоимостью и т.п.
Несомненно каждый найдет очень много аргументов в пользу именно своего способа хранения файлов в электронном архиве.
Создавая нашу систему мы решили создавать ее ближе к 3-му способу и вот почему:
Т.е. для наших пользователей проблема того, что кто-то скопирует отдельные файлы или даже объект целиком не так важна (как правило, в таких организациях и так все пользователи имеют доступ ко всем папкам) как угроза потери всех файлов целиком или проблема быстрого поиска необходимого альбома.
По сути работа пользователей практически не меняется - ознакомление новых пользователей с системой происходит за 1-2 дня.
Способов организации электронного архива существует достаточно много, попробуем перечислить их:
- Хранение файлов в системе папок на рабочем компьютере одного из работников, как правило, главного инженера проектов с управлением архивом через файловые менеджеры.
- Хранение файлов в системе папок на сервере с управлением архивом через файловые менеджеры.
- Хранение файлов в системе папок с организацией предоставления доступа к ним посредством ссылок из базы данных.
- Хранение файлов в специальным образом организованной базе данных.
К недостаткам 1-го и 2-го способа отнесем следующие:
- Низкая защищенность хранения - любой пользователь может получить доступ к документации, скопировать ее, изменить, удалить и т.д.
- Полнота архива зачастую замыкается на одного человека, например, главного инженера проектов - на него возлагается обязанность скидывать в архив ту документацию, которую передали ему разработчики.
- Сложность поиска необходимой информации - при количестве альбомов более сотни держать в памяти информацию о месте хранения, например, пятого изменения альбома достаточно затруднительно.
- Отсутствие единообразия в системе хранения файлов - один пользователь разделяет альбомы на папки вида объект\стадия\раздел, другой пользователь может разделить на папки вида объект\очередь\раздел\стадия и т.д.
Недостатки 3-го способа заключаются в следующем:
- При некорректной работе пользователей с папками возможно их перемещение, в результате чего ссылки со стороны базы данных могут оказаться недействительными.
Четвертый способ имеет следующие недостатки:
- Для хранение больших объемов документации требуются базы данных "тяжелого класса" которые могут стоить не один десяток или даже сотни тысяч долларов.
- Сложность администрирования промышленных баз данных, т.е. обойтись в этом случае без выделенного администратора в штате компании вряд ли удастся, а стоимость такого специалиста труда довольна значительно, да и само его наличие, допустим, в небольшом городке под большим вопросом.
- В случае если база данных окажется поврежденной даже частично, получить все файлы хранящиеся внутри файлов базы данных вряд ли получится, т.е. требования к отказоустойчивости оборудования и, соответственно, его стоимости многократно повышаются.
Таким образом, нужно понимать, что идеального способа хранения файлов не существует. Так или иначе организация архива (да и любого другого объекта во вселенной) это предмет компромисса между потребностями, удобством использования, стоимостью и т.п.
Несомненно каждый найдет очень много аргументов в пользу именно своего способа хранения файлов в электронном архиве.
Создавая нашу систему мы решили создавать ее ближе к 3-му способу и вот почему:
- Наши основные пользователи - небольшие и средние проектные компании (до 50-100 человек), которые не могут позволить себе наличие штата администраторов (базы данных, так как администратор Windows вряд ли сможет разобраться в тонкостях администрирования промышленных баз данных), да даже и одного администратора базы данных тоже, как правило, такие организации позволить себе не могут. В этом случае требуется система класса "включил и работает".
- В случае повреждения базы данных (как минимум на время ее восстановления) файлы должны быть доступны. К сожалению, случаи повреждения баз данных хоть и достаточно редки, но приводят к печальным последствиям и происходят всегда в самый неподходящий момент.
- Работа с новой системой документооборота не должна отличаться для пользователя от привычной схемы работы с файлами - копирование, перемещение и т.п. Иначе пользователи просто не будут работать с Вашей системой и она будет стоять дорогой игрушкой - ситуация когда "менеджеры не могут, а низы не хотят".
- Копирование файловой структуры без наличия базы данных не имеет особого смысла, так как разобраться в системе папок без базы данных будет затруднительно.
Т.е. для наших пользователей проблема того, что кто-то скопирует отдельные файлы или даже объект целиком не так важна (как правило, в таких организациях и так все пользователи имеют доступ ко всем папкам) как угроза потери всех файлов целиком или проблема быстрого поиска необходимого альбома.
По сути работа пользователей практически не меняется - ознакомление новых пользователей с системой происходит за 1-2 дня.