Журнал о системах электронного документооборота (СЭД)
Внедрение электронного документооборота

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

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

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

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

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

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

Общие рекомендации по процессу согласования

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

2.   Процесс согласования не должен быть большим, если вы хотите, чтобы он был понятным всем пользователям и не затягивался на месяц или более. Оптимальное количество этапов согласования официального документа (не рецензентов) – до 3-4.

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

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

 

Возвращаемся к вопросу: «Как организовать одновременное согласование документа в СЭД?». У большинства систем проблемы схожи в большей или меньшей степени, поэтому в рамках этой статьи я постараюсь охватить все возможные варианты реализации коллективной работы над документом с учетом перечисленных рекомендаций и без привязки к конкретным условиям. Их на самом деле масса, и выношу их на ваше обсуждение. Отмечу, что не все они решают вопрос «напрямую». Кейсы будут подкреплены наглядными примерами и скриншотами системы 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), что также позволит сэкономить время наших сотрудников при обсуждении документа, быстро корректировать его и оперативно подключать новых участников. Ну и уровень безопасности во встроенном мессенджере значительно выше.

 

Ещё материалы автора
Похожие записи
Комментарии (9)
Тейдо Тейдо 27 августа 2016 г. 12:30  

Может не стоит упираться именно в Ворд? Именно в нем организовать совместное использование сложно. По идее это нужно решать программными методами, когда формируемый документ сперва создается участниками с главным редактором во главе, который и одобряет все изменения/исправления, а уже потом документ формируется в заданный формат, пдф с изменяемыми полями, ворд, эксель и так далее и тому подобное. Или же все остается в визуально похожем на печатный формат документе, который можно из программы распечатать, посмотреть кто вносил какие исправления, кто их утверждал и когда.

Михаил Романов 27 августа 2016 г. 13:22  
Может не стоит упираться именно в Ворд?

А что вы предлагаете на замену?

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

А создается и редактируется исходный документ в каком виде?

Михаил Романов 27 августа 2016 г. 13:35  

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

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

А почему вы не рассмотрели вариант параллельной правки документа? Те же Word и PowerPoint поддерживают данный функционал начиная с 2010 версии. Мне кажется, это логичное развитие обоих предложенных вами вариантов.

Михаил Романов 27 августа 2016 г. 14:02  

А вообще тема согласования/рецензирования всплывает на EJ просто с завидной регулярностью. Вот буквально поверхностная пробежка дает уже неплохой урожай:

Неужто за 9+ лет так и не удалось поставить точку в этом вопросе?

Елена Грозова 29 августа 2016 г. 09:01  

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

Наталья Демина 31 августа 2016 г. 17:35  

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

Интеграция с теми же Google Docs и MS Office 365. Или использование SharePoint. Насколько разработка и настройка коннекторов будет дороже реализации описанных в статье механизмов? И не будет ли она дешевле, при условии, что у заказчика уже одна из упомянутых систем используется?

Михаил Романов 01 сентября 2016 г. 16:44  
Интеграция с теми же Google Docs и MS Office 365. Или использование SharePoint.

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

 

А вот какой смысл делать интеграцию с SharePoint/Office 365? Это вполне готовые платформы СЭД. Зачем их интегрировать с другими СЭД я не понимаю.

Андрей Подкин 02 сентября 2016 г. 10:03  
А вот какой смысл делать интеграцию с SharePoint/Office 365? Это вполне готовые платформы СЭД. Зачем их интегрировать с другими СЭД я не понимаю.

SharePoint - понятно. А вот что такого принципиального есть в Office 365 (без SharePoint), чего нет у Google?

 

Михаил Романов 02 сентября 2016 г. 17:32  
Office 365 (без SharePoint),

А я такие планы даже не рассматриваю. Хотя надо было бы, наверное, уточнить что речь идет о Office 365 Business и Enterprise.
Но в целом да, Office 365 это зонтичный термин, под которым скрывается, по сути, 2 варианта:

 

  • подписка на настольный офис + место в OneDrive (это персональные и академические лицензии + офис профессиональный)
  • облачный SharePoint + (необязательный) настольный офис + всякие прочие плюшки (это бизнес и корпоративные лицензии)

Сейчас обсуждают
Роман Гудков 17 января 2017 г. 10:10  
Недостающие документы, необходимые для заключения договора, можно представить в электронной форме, прибегнув к помощи нотариуса.

Ульяна, а можно ли таким образом оформить карточку с образцами подписей? Или в карточке должна быть только собственноручная "живая" подпись? 

Вадим Майшев 16 января 2017 г. 11:27  

Не особо авторы/журналисты утруждают себя использовать правильные термины: тут и "стоимость ЭЦП" - ЭЦП уж 5 лет по закону нет, да и ЭЦП "не продается" (УЦ продают сертификаты).

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

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

Кто решил, что она дорогостоящая? В сравнении с чем? В государстве нет ничего бесплатного! Давно были у нотариуса/врача/... или оплачивали пошлины за "услуги" государства, живущего на деньги налогоплательщиков? И никто (пока) не запрещает использовать неэлектронные варианты взаимодействия!

Александр Валеев 16 января 2017 г. 08:22  
«Большинство услуг и сервисов на портале требуют только простой электронной подписи, однако некоторые услуги, действительно, нужно подписывать квалифицированной электронной подписью. На сегодняшний день это необходимая технология, и она продолжит действовать», — заявил замглавы Минкомсвязи России Алексей Козырев. На сайте Минкомсвязи приведен весь список госуслуг, для которых нужна ЭЦП (XLSX,  187,5 КБ).

Многие опубликовали новость о госуслугах. Но о том, понадобится ли еще КЭП, только здесь. Спасибо

Больше комментариев