Наверх

ECM-Journal обновился!

Если вы ещё не зарегистрированы на сайте, сделайте это прямо сейчас. Если у вас уже есть профиль, то просто обновите пароль.

Маленькие по 3 или большие по 5?

Время чтения: 3 минуты
7
Маленькие по 3 или большие по 5?

Что лучше: много небольших регламентирующих документов или один большой?

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

В связи с этим возникает вопрос: а что лучше – сделать один большой документ по процессу (скажем на 20 страниц) или разбить его на несколько мелких (по 1-2 страницы) на каждую процедуру?

Поскольку ответ на этот вопрос может отличаться в зависимости от того, в бумажном или электронном виде «живут» документы СМК, то рассмотрим только электронный документооборот (его преимущества при создании СМК достаточно подробно рассмотрены в других материалах данной рубрики).

Достоинства больших документов:

●     вся информация по процессу собрана в одном месте, что позволяет получить «взгляд сверху»;

●     перемещение по документу (с помощью содержания, гиперссылок, закладок, поиска и пр. методов) значительнее удобнее поиска в разных документах СЭД.

Недостатки больших документов:

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

●     документ может дольше открываться и на перемещение по нему нужно время, особенно если интересует конкретная операция процесса.

Достоинства маленьких документов:

●     при поиске информации по конкретной операции документ открывается быстро и не тратится время на перемещение по документу;

●     каждый отдельно взятый документ меняется относительно редко.

Недостатки маленьких документов:

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

●     все равно нужен документ, который дает общее описание процесса, а из него ссылки на документы с дополнительными инструкциями;

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

●     если нужно затронуть несколько шагов процесса или рассмотреть его целиком, то приходится смотреть информацию в нескольких документах. Тратится дополнительное время на их поиск и открытие и сложнее сопоставлять информацию;

●     в случае необходимости изменений нужно найти все документы, которые эти изменения затрагивают. Это сложнее, чем, если бы информация была изложена в одном документе;

●     список документов СМК становится достаточно длинным, громоздким.

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

Чтобы прочитать эту статью до конца,
или зарегистрируйтесь

Комментарии 7

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Чтобы прокомментировать, или зарегистрируйтесь