Регламенты электронного документооборота: статусы, роли, сроки

Зачем сначала регламент, а потом автоматизация

Автоматизация усиливает то, что уже есть. Если правила не согласованы, система просто делает хаос быстрее: документы уходят не тем людям, зависают «у кого-то на стороне», а спор о том, что значит «на согласовании», превращается в ежедневные переписки.

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

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

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

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

Чтобы прийти к единым правилам, обычно хватает короткой договоренности: один владелец процесса фиксирует финальную версию; определения статусов единые и без «двойных смыслов»; замещение на отпуск/командировку заранее настроено; есть одно понятное правило про молчание (например, «молчание не равно согласованию» - или наоборот, но одинаково для всех).

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

Определите охват: какие документы и процессы автоматизируем

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

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

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

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

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

Когда этот охват согласован, дальше проще обсуждать маршруты и сроки: вы автоматизируете конкретные процессы, а не «все документы сразу».

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

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

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

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

• Черновик: документ создается и редактируется автором. Вход: создан. Выход: отправлен на согласование.
• На согласовании: документ у согласующих. Вход: автор отправил. Выход: согласован или возвращен.
• На подписании: документ у подписанта. Вход: все согласовали. Выход: подписан или отказано.
• Возвращен на доработку: есть замечания. Вход: кто-то вернул. Выход: исправлен и снова отправлен на согласование или закрыт.
• Отказано: документ не будет принят. Вход: отказ согласующего или подписанта. Выход: финал с причиной.
• Подписан: подпись поставлена, версия зафиксирована. Вход: подписант подписал. Выход: исполнение или архив.
• Исполнен: обязательства выполнены (если применимо). Вход: подписан. Выход: архив.
• Архив: финальное хранение, только чтение.

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

Возврат на доработку и отказ лучше фиксировать с причиной. Обычно хватает 5-7 стандартных причин (неверные реквизиты, нет бюджета, риск по условиям, не хватает вложений) и поля «комментарий». Это снижает споры и помогает потом улучшать шаблоны и требования.

Роли и ответственность: кто за что отвечает

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

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

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

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

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

Исполнитель закрывает задачу по документу (например, отправил контрагенту, отгрузил, передал в архив), а контролер фиксирует факт выполнения и сроки. Так вы отделяете «сделал» от «проверил, что сделано».

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

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

Маршруты согласования и матрица ответственности

Маршрут согласования отвечает на простой вопрос: кто и в каком порядке должен принять решение. Если это не закрепить заранее, автоматизация только ускорит хаос: документ будет «гулять» между людьми, а спор «кто должен согласовать» станет ежедневным.

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

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

Параллельное согласование обычно подходит для юристов, безопасности и ИТ: они проверяют разные вещи. Последовательное - когда важен порядок, например «инициатор -> финансовый контролер -> руководитель». Системные интеграторы, включая GSE.kz, часто просят на старте выбрать этот принцип для каждого типа документа, иначе сроки будут считаться неверно.

Отдельно закройте конфликт интересов. Признаки простые: согласующий является инициатором или прямым выгодоприобретателем; согласующий подчиняется инициатору и нет независимой проверки; один человек одновременно «проверяет» и «утверждает» рискованные условия; участник процесса связан с контрагентом.

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

Сроки, контроль и эскалации: чтобы процесс не зависал

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

Разделяйте «время на решение» и «время в ожидании». Пауза допустима, когда не хватает данных, нужно уточнение у контрагента или нет приложений. Но пауза должна фиксироваться отдельным статусом (например, «Ожидание данных») и иметь владельца, который отвечает за запрос и контроль возврата.

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

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

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

Пример: при закупке оборудования (например, серверов) договор вернули с замечаниями юриста. Если регламентом задано 2 рабочих дня на доработку и 1 день на повторное согласование, документ не «гуляет» неделями, а задержка сразу видна и поднимается по эскалации.

Пошагово: как утвердить статусы, роли и сроки до внедрения

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

Минимальный план работ

Начните не с теории, а с фактов. Возьмите несколько свежих документов (обычно хватает 5-10 за последний месяц) и пройдите их путь от создания до архива. Так быстрее видно, где есть лишние круги и где «все зависит от одного человека».

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

Как закрепить договоренности

После обсуждения оформите регламент в одном документе: статусы, роли, сроки, точки контроля и исключения (например, «срочные» договоры). Затем согласуйте его так же, как обычный документ, иначе у регламента не будет веса.

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

Только после этого переносите правила в систему. Иначе вы автоматизируете не процесс, а спор о том, «как правильно».

Частые ошибки при подготовке регламентов ЭДО

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

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

Вторая ошибка - нет владельца процесса. Когда никто не отвечает за правила целиком, маршрут согласования начинает меняться «как договорились в этот раз». Сегодня юрист проверяет одну версию, завтра просит прислать другую, а бухгалтерия добавляет еще один шаг, потому что «так надежнее».

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

И еще одна частая проблема: сроки прописаны, но нет эскалации, замещения и понятного правила, что делать, если человек в отпуске. Тогда документ просто зависает.

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

Когда эти ошибки убраны, регламент становится рабочим инструментом, а не документом «для галочки».

Быстрая проверка перед запуском автоматизации

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

Сначала убедитесь, что вы точно знаете, что автоматизируете в первую очередь. Не пытайтесь охватить все сразу: лучше выбрать несколько самых частых и болезненных типов документов и довести их до ясных правил.

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

Дальше проверьте, что правила не противоречат реальности. Для этого достаточно 2-3 живых кейса, но они должны быть разными: один простой, один конфликтный, один срочный.

Мини-тест на реальных кейсах

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

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

Финальный сигнал «можно стартовать»

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

Пример сценария: согласование договора без лишних споров

Представим типичную ситуацию: отдел закупок готовит договор на поставку оборудования (например, серверов для обновления инфраструктуры). Цель простая: пройти согласование быстро и без переписки в стиле «а кто должен править документ?».

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

Чтобы не спорить о том, где сейчас договор, он проходит понятные статусы:

• Черновик (инициатор готовит и прикладывает обоснование)
• На согласовании (документ у одного или нескольких согласующих)
• На доработке (возвращен инициатору с замечаниями)
• Утвержден (все обязательные согласующие подтвердили)
• Подписан (подписи получены)
• Архив (делопроизводитель закрыл карточку и сохранил комплект)

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

Замечания фиксируются в одном месте: комментарий к версии или поле «замечания», где у каждого пункта есть автор, дата и статус «принято/отклонено/нужна встреча». Править текст может только инициатор, а согласующие либо принимают версию, либо возвращают на доработку.

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

Следующие шаги: пилот, внедрение и поддержка

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

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

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

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

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

На внедрении сразу заложите поддержку: кто отвечает на вопросы пользователей, кто меняет маршруты, кто следит за сроками и отчетами. Если нужна помощь с инфраструктурой и внедрением, это можно обсудить с GSE.kz (gse.kz) как с системным интегратором: от построения решений до круглосуточной технической поддержки и подбора серверов S200 Series и рабочих мест под ваш масштаб.