Журнал о системах электронного документооборота (СЭД)
Управление качеством и СМК

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

  7 комментариев Добавить в закладки

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ещё материалы автора
Похожие записи
Комментарии (7)
Денис Садыков 18 июля 2007 г. 08:16  

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

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

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

Павел Колесников 18 июля 2007 г. 08:43  

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

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

Евгений Кочуров 18 июля 2007 г. 10:43  

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

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

Елена Истомина 18 июля 2007 г. 15:57  

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

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

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

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

Евгений Кочуров 18 июля 2007 г. 16:43  

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

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

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

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

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

Евгений Кочуров 18 июля 2007 г. 16:51  
Кстати, критерием качества автоматизации бизнес-процесса может служить снижение числа обращений к регламентирующему документу при сохранении или улучшении качества исполнения процесса :)
Константин Муратов 18 июля 2007 г. 22:12  

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

Сейчас обсуждают
Больше комментариев