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

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

Прямая аналогия с декомпозицией схем.

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

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

Описывать то может и удобнее... А удобнее ли тем, кому регламенты эти исполнять? Например, в талмуде на 50 страниц описывается процесс, который интересен целиком, скажем, только 2-3 людям, а основная масса сотрудников выполняют только 1-2 операции, описание которых умещается на две страницы. Не будет ли логичнее вынести эти две страницы в отдельный документ?

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

Речь изначально и шла об интересах простых пользователей: "чтобы участники процесса легко и удобно могли пользоваться такими документами в реальной работе", причем о документе в 20, а не 50 страниц :).

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

По поводу "Описывать то может и удобнее... ", так тоже вещь не маловажная. Если будет не удобно, то будут забывать или лениться описывать. В результате документы станут не актуальными и пользы тому же конечному пользователю не принесут.

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

но вот как это сделать - задача не простая.

Возникла мысль, как выявлять "кандидатов" на оптимизацию и/или автоматизацию:

1) регламентирующие документы, число обращений к которым максимально в некоторый период времени (часто читают - что-то здесь не так, или операция труднопонимаемая, или содержит слишком много деталей, которые трудно удержать в голове);

2) процессы, при выполении которых допускается большое количество ошибок.

п.2 вполне очевиден, такие процессы и так привлекают внимание, а вот п.1 может оакзаться интересным. Например, есть инструкция по установке SQL-сервера, но сервера ставят не часто, соответственно обращений к инструкции мало, тут незачем автоматизировать процесс. Или есть документ с правилами по планированию и учету работ, к которому каждый сотрудник достаточно часто обращается - вот, пожалуйста, документ-кандидат на то, чтобы выделить из него правила, поддающиеся автоматизации.

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