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

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

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

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

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

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

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

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

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

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

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

Мой вывод: документооборот для сферических коней в вакууме имеет сложность на уровне небольшого модуля учетной системы. На деле можно встретить проблему уровня 2.5 ERP ((c) Dogen) и более за счет совокупной тяжести модулей интеграции и проблем общесистемного характера при работе с извращенными многофайловыми документами.