Наверх

Лист согласования vs новые версии документа

Время чтения: 6 минут
4
Лист согласования vs новые версии документа

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

Лист согласования vs новые версии документа

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

Цель согласования – повышение качества документов, управленческих процессов и решений в целом. Именно поэтому процесс необходимо выстраивать четко и прозрачно. Результат согласования – визирование документа всеми заинтересованными лицами, а итог – подписание согласованного документа руководителем.

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

По итогам согласования можно выделить три возможных результата:

●    согласовано;

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

●    отказано.

Более интересными для нас будут первые два, так как в случае отказа процесс фактически завершается. Если документ возвращается с результатом «требуется доработка» или «согласовано с замечаниями», возникает необходимость в фиксации возникших замечаний.

Наиболее распространенными способами отображения замечаний в документе являются:

●    лист согласования и фиксация в нем замечаний,

●    создание новой версии документа и внесение правок в сам документ.

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

Согласование документа

Создание новой версии и внесение замечаний в документ

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

Плюсы

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

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

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

●    есть возможность подписать свою версию ЭП, чтобы гарантировать ее неизменность.

Минусы

●    инициатору задачи необходимо объединять замечания согласующих из разных версий в один документ;

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

Фиксация замечаний в листе согласования

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

Плюсы

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

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

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

Минусы

●    если замечаний к документу много, то фиксировать их в отчете «Лист согласования» неудобно.

Подписание документа

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

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

Если в итоге документ распечатывается из СЭД и подписывается на бумажном носителе, то можно закрепить следующий порядок работы:

1.   На основании виз, внесенных в документ в СЭД, автоматически формируется и печатается из системы лист согласования, а также сам документ.

2.   Затем уполномоченный сотрудник проверяет лист согласования, проверяет визы, внесенные в СЭД, а затем заверяет лист согласования и распечатанный документ.

3.   Распечатанный и заверенный документ передается руководителю на подписание вместе с распечатанным и заверенным листом согласования.

4.   После подписания документа на бумажном носителе в СЭД заносится отметка об этом событии.

Вывод

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

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

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

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

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

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

Источник: Журнал "Современные технологии делопроизводства и документооборота"

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

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

Михаил Романов 24 ноября 2014
Наиболее распространенными способами отображения замечаний в документе являются

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

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

Основные плюсы данного подхода:

  • В текст документа не вносится случайных или намеренных изменений, а все правки делаются на основе примечаний, т.е. нет необходимости контролировать изменения в самом тексте
  • Все рецензенты работают с одной и той же версией тела документа, и значит автору не нужно собирать примечания по версиям
  • Рецензенты могут работать параллельно, и не заморачиваясь техническими (и, откровенно говоря, не особо интуитивными) вопросами вида "как мне открыть и продолжить редактировать МОЮ версию?".

Есть и ряд других, менее значимых

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

Однако, во-первых, это 2 самых распространённых формата: DOC/DOCX и PDF - а, во-вторых, требуемые на уровне СЭД доработки не слишком велики.

Более того, описанная мною схема на базе PDF даже встречалась мне в материалах одного из западных вендоров, как рекомендуемая.

Михаил Романов 24 ноября 2014

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

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

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

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

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

Михаил Романов 24 ноября 2014
с реализацией описанного Вами варианта сталкиваться не приходилось

Ну это не страшно, главное, чтобы был интерес и желание искать новые (лучшие) варианты.

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

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

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