Как организовать одновременное согласование документа в СЭД. Четыре кейса

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

Безусловно, есть такие программные продукты, действительно позволяющие одновременно редактировать документ разным пользователям и видеть онлайн корректировки друг друга, типа Google Docs и MS Office 365. Однако, во-первых, они являются облачными, а, во-вторых, не являются системами документооборота.

На моей практике практически у любого большого заказчика регулярно возникает вопрос «Как организовать у нас одновременное согласование документа именно в СЭД, без участия других внешних систем (кроме Word) и с максимальной минимизацией субъективного фактора?».

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

Возвращаемся к вопросу: «Как организовать одновременное согласование документа в СЭД?». В рамках этой статьи я постараюсь охватить все возможные варианты реализации коллективной работы над документом с учетом перечисленных рекомендаций и без привязки к конкретным условиям. Их на самом деле масса, и выношу их на ваше обсуждение. Отмечу, что не все они решают вопрос «напрямую». Кейсы будут подкреплены наглядными примерами.

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

Варианты реализации одновременного согласования в СЭД

Итак, в этой главе мы рассмотрим 4 кейса реализации одновременного согласования документов в СЭД. Отдельно, в разделе ниже, вынесла описание «помощников», которых можно использовать в совокупности с основными вариантами.

Кейс 1. Разделение документа на части

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

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

Плюсы:

1. Экономит время, позволяет фокусироваться только на нужном разделе.

Минусы:

1. Не зря мною сделан акцент, что данный вариант отлично подходит только для типовых документов. А если речь идет о нетиповом документе? Согласитесь, что в таком случае вероятность того, что рецензенту (например, юристу или финансовому директору) потребуется увидеть весь документ целиком, резко возрастает.

Кейс 2. Слияние версий

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

Самостоятельную функцию слияния версий поддерживают не все системы, предпочитая использовать готовый механизм «Объединить» в MS Word, а те, которые поддерживают, к сожалению, учитывают не всю специфику документа (например, отслеживают изменения текста, а колонтитулы и переносы – нет).

После слияния всех версий рецензентов по согласуемому документу получается итоговая версия (рис.1.) со статусом «Действующая», которая направляется на обработку Инициатору. Статусы всех предыдущих версий при этом меняются на «Не актуальна».

Рис.1. Пример слияния нескольких версии документа в одну

Плюсы:

1.   С одним документом одновременно смогут работать несколько рецензентов. Причем в теле документа не будет никаких лишних примечаний и правок – они не будут «замыливать» взгляд.

2.   Все правки будут фиксироваться прямо в тексте документа.

Минусы:

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

Кейс 3. Слияние примечаний

Данный вариант является частным случаем кейса 2, позволяющей ВСЕМ согласующим одновременно видеть примечания друг друга и работать с единой версией документа. При этом шаблон документа должен быть создан в формате docx (Word 2007 и старше). Происходит программное управление текстом документа на сервере: слияние примечаний, закрытие текста от редактирования и т.п. Это может быть реализовано с помощью библиотек Microsoft для работы с форматом OpenXML и без установки приложения MS Office на сервер.

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

Сам главный документ при этом никто редактировать не может, он всегда будет заблокирован. В качестве примечаний могут выступать предложения по формулировкам, вопросы или пометки для инициатора, на что стоит обратить внимание. За счет того, что рецензенты могут вносить примечания непосредственно в текст, обозначенный в кейсе 2, минус автоматически разрешается.

Плюсы:

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

2. Удобное представление документа: нет нагромождений корректировок (все примечания будут автоматически сливаться системой в текущую версию), не требуется производить лишние действия (не нужно пользоваться функционалом «Сравнение версий»).

Минусы:

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

Кейс 4. Фиксирование пожеланий в тексте задания

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

Отмечу, что рецензенты при этом по-прежнему смогут вносить правки в документ (например, исправить некорректное окончание, изменить формулировку пункта и т.д.). Но, если замечание к содержимому документа будет существенное, то рецензент должен будет продублировать информацию о корректировке в текст задачи и нажать «На доработку», чтобы вернуть документ инициатору. После первого круга согласования инициатору возвращается документ на доработку. Он создает новую версию документа, вносит в нее корректировки, отмеченные в задаче и возвращает документ на повторное согласование.

Рис.2. Пример реальной карточки процесса согласования договора

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

Рис.3. Сформированный лист согласования по договору

Плюсы:

1. Четкое регламентирование, разграничение этапов и ответственных.

2. Примечания рецензентов на карточке процесса представлены структурированно и доступны для просмотра по ходу процесса согласования не только инициатору, но и самим рецензентам.

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

4. Использование листа согласования в данном примере дополнительно акцентирует внимание руководителя на наиболее важных условиях документа и позволяет снизить возможные финансовые потери.

Минусы:

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

2. В случае некорректно выстроенного процесса время согласования документа может оказаться сильно затянутым.

Альтернативные варианты, которые стоит предусмотреть

Перечисленные выше кейсы закрывают наиболее типовые ситуации. Однако всегда возникают ситуации «внештатные», когда в срочном порядке нужно согласовать документ в самые сжатые сроки. Отходить от регламента даже в таких ситуациях нежелательно, но сроки желаемые и запланированные в процессе между собой не стыкуются. Что можно сделать, чтобы не отходить от регламента и в то же время каким-либо образом оптимизировать время согласования документа?

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

Кейс 1. Параллельное согласование и уведомление об освобождении

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

Рис.4. Всплывающее окно-предупреждение о том, что в данный момент документ редактируется другим рецензентом

Рецензент может либо создать свою версию документа и приступить к работе с ней, либо дождаться, когда документ освободиться, сделав пометку «Оповестить о возможности редактировании документа». После того как документ освободиться, второму рецензенту придет соответствующее уведомление (рис.5).

Рис.5. Уведомление об освобождении документа

Кейс 2. Использование корпоративных мессенджеров

Просто взять и собраться для обсуждения документа – часто используется в практике. Однако физическая возможность собрать всех появляется не всегда: кто-то может находиться в командировке, кто-то – в «полях», кто-то работает из дома, в связи с болезнью… Но и здесь есть решение – корпоративные мессенджеры. Да-да. Они позволят удобно обмениваться информацией и мгновенными сообщениями с вашими сотрудниками.

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

Рис.6. Окно беседы в DIRECTUM Talk

Еще лучше, если этот мессенджер «вшит» в СЭД. При этом все сотрудники автоматом будут в вашем списке контактов. Если кто-либо из сотрудников отсутствует на рабочем месте, информация об этом будет сразу видна. А с объектами СЭД (задачами, документами, записями справочников и т.д.) можно будет работать непосредственно из окна бесед (рис.6), что также позволит сэкономить время наших сотрудников при обсуждении документа, быстро корректировать его и оперативно подключать новых участников. Ну и уровень безопасности во встроенном мессенджере значительно выше.