Вопрос: подскажите, нет ли противоречия в законе, если в электронной версии договора один подписант, в бумажной — другой? Какие законы мне посмотреть, чтобы убедить людей "так не делать"?

Ответ: в описанной ситуации есть юридическая угроза недействительности договора из-за расхождения в сторонах и отсутствии единства воли.

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

Копия должна быть полностью идентична оригиналу, включая:
▪️текст
▪️реквизиты
▪️подписи

Правовые основания

1️⃣ ГК РФ, ст. 160 – сделка должна быть совершена в форме, установленной законом или соглашением сторон.
Электронная форма — самостоятельный способ заключения договора, приравненный к бумажному. Требование о наличии подписи считается выполненным, если использован любой способ, позволяющий достоверно определить лицо, выразившее волю

2️⃣ ФЗ-63 «Об электронной подписи», ст. 6 и 9:
Документ, подписанный КЭП, имеет ту же юридическую силу, что и бумажный оригинал с подписью и печатью

3️⃣ Подлинник – первый или единственный экземпляр (в установленных случаях – один из нескольких одновременно созданных экземпляров) (ГОСТ Р 7.0.8-2025)
Документ может существовать в одной форме — подлинной, а иные формы — копии, созданные с соблюдением требований идентичности.

Что происходит, если подписи разные:
▪️в электронной форме подписал Иванов,
▪️а в бумажной — Петров,
то это уже два разных документа, а не один.

Последствия:
▪️невозможно определить, какая из версий выражает волю организации;
▪️нарушается принцип юридической определённости;
▪️возникают риски признания договора незаключённым или оспоримым (ст. 432 ГК РФ);
▪️в суде документ не будет считаться единым доказательством.

Как правильно
1️⃣Определите формат издания договора:
▪️если подписывается в ЭДО – это подлинник;
▪️бумажный экземпляр в этом случае – копия, заверенная надлежащим образом.
2️⃣ Не допускайте разницы в подписантах.
Один человек = один договор = одна воля организации.
3️⃣Если нужна копия в другой форме (например, для контрагента на бумаге):
▪️распечатайте электронную версию, заверьте подпись, укажите:
«Верно, наименование должности лица, заверившего документ, собственноручная подпись, расшифровка подписи, дата заверения"

Итог
Договор – это результат юридического волеизъявления конкретных лиц, выраженный в определённой форме.
Разные подписанты = разные воли = юридическая ошибка.
Один оригинал, одна подпись, одна форма. Всё остальное — копии.

#ЭлектронныйДокументооборот #СЭД #ЭДО #УправлениеДокументами #Подлинник #Копия #ЭлектронныйДокумент #Подпись

Читаю техническое задание на внедрение СЭД:

"Состояние регистрационной карточки 'Дело' меняется автоматически согласно жизненному циклу сущности"

Сразу вспоминаю, как один коллега разработчик говорил:

Не знаешь, как это называется? Назови сущностью. Никто не придерётся

Сущность у нас всё: дело, документ, пользователь, подписант, архив и даже кофе-машина в коридоре. Главное — чтобы у неё был жизненный цикл.

А если серьёзно: такие формулировки – тревожный звоночек.
Если в ТЗ не различают "дело", "карточку", "регистрацию" и "объект контроля", а всё это называют "сущностью" – значит:
▪️архитектура данных не проработана,
▪️термины не согласованы с делопроизводством,
▪️потом будут баги и хаос в аналитике.

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

#ЭлектронныйДокументооборот #СЭД #ЭДО #ТехническоеЗадание #УправлениеДокументами

Вопрос: подскажите пожалуйста управление документами – это же не обеспечивающие процессы? Хочется отнести к управленческим

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

Как обеспечивающий процесс
подход по классическим стандартам, например ISO 9001
Цель: поддержка основных процессов ресурсами (документы = информационный ресурс).
Примеры задач:
▪️хранение договоров
▪️регистрация входящих/исходящих писем
▪️архивация
Критерий: не создает прямую ценность для клиента, но без него бизнес останавливается (как IT или бухгалтерия).

Как управленческий процесс
современный тренд в процессном управлении
Цель: контроль решений, снижение рисков, обеспечение compliance.
Примеры задач:
▪️утверждение политик и регламентов
▪️согласование договоров (включая визирование юристом, финансовым директором)
▪️работа с документами в рамках внутреннего контроля (ФЗ № 402 «О бухучете», 152-ФЗ о персданных)
Критерий: влияет на стратегию (например, через управление договорными рисками).

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

Важно:
В стандарте ISO 30301:2019 (Системы управления документами) подчеркивается, что документооборот – стратегический инструмент, а не просто поддержка. Это аргумент в пользу управленческого статуса.

Как классифицировать в вашем случае?
Задайте вопросы:

1️⃣ Кем управляется процесс?
Участвуют ли в процессах управления документами лица, принимающие решения? (или только исполнители низкого уровня?)

2️⃣ Может ли ошибка в документе повлечь финансовые, правовые или репутационные риски?

3️⃣ Есть ли в организации формализованные регламенты (например, Положение о договорной работе, регламент визирования документов)?

Если ответы на 2-3 пункта – «да», ваш процесс управления документами – управленческий.

#ЭлектронныйДокументооборот #СЭД #ЭДО #УправлениеДокументами #ISO #УправлениеДокументами

Может ли лицо в преамбуле не совпадать с подписантом договора?

Такой вопрос мы обсуждали на прошлой неделе в чате канала.

Благодарю коллегу и эксперта по договорному праву Ольгу Алпатову за развёрнутый и взвешенный ответ — читать полный текст здесь

Суть позиции:

✔️ Если договор подписан уполномоченным лицом, но в преамбуле указано другое (ошибочно или по инерции) — договор сохраняет силу

✔️ Если исполнение шло (деньги, работы, услуги) — суд будет это учитывать

✔️ Оспаривание такой сделки — риск злоупотребления правом (ст. 10 ГК РФ)

✔️ Доказывать отсутствие полномочий — задача истца

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

ВЫВОД
Да, такая ситуация нежелательна, но не фатальна. Главное — подтверждаемость полномочий и фактическое поведение сторон.

Рекомендую подписаться на канал Ольги Юрмашина [Алпатова & Nextlegal.Pro] — там много полезного для юристов и всех, кто работает с договорами

#ЭлектронныйДокументооборот #СЭД #ЭДО #Договор #Сделка #LegalLaw #УправлениеДокументами

Эргономика и здравый смысл: как СЭД превращается в интерфейс против человека

В одной системе электронного документооборота (СЭД) столкнулась с наглядным примером антиэргономики. Покажу на примере карточки входящего документа.

Карточка разбита на вкладки. В зависимости от роли пользователя — «группа регистрации», «группа приёма» — отображаются разные вкладки и разные блоки реквизитов. Формально — гибко. На практике — перегружено и неэффективно.

Что не так?

✔️ 38 реквизитов на этапе приёма, из которых реально заполняются 1–5

✔️ 66 реквизитов на этапе регистрации, из которых обязательны только два

✔️ общий объём информации во всей карточке — более 180 реквизитов ‼️

Многие поля дублируются между вкладками. Некоторые неактуальны для конкретного вида документа.

Назначение части реквизитов неочевидно — нет подсказок, нет группировки, нет визуального разделения по смыслу.

Почему это проблема?

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

Пользователь, работающий с документом по МЭДО, видит те же поля, но заполняет… одно.

Реальное заполнение в ручном режиме — сильно затруднено, пользователь тратит время на «разгрузку» интерфейса, прокрутку, поиск нужного.

Такое количество реквизитов не обеспечивает качество, а создаёт эффект перегруженности.

Что можно улучшить?

Умная адаптация интерфейса — отображать только актуальные поля по типу канала поступления (бумага/МЭДО), роли и контексту документа.

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

Минимизация ручного ввода — использовать автозаполнение, OCR, связи с классификаторами и справочниками.

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

Чёткое разграничение обязанностей — регистрация ≠ обработка ≠ исполнение. Зачем одному пользователю видеть всё сразу?

ВЫВОД

Эргономика — это не косметика интерфейса. Это то, что определяет:
▪️скорость работы
▪️количество ошибок
▪️уровень раздражения пользователя
▪️и в итоге — принятие или отказ от СЭД

💬 А как устроен интерфейс вашей СЭД? Сколько полей заполняется вручную? Сколько на самом деле нужны?

#ЭлектронныйДокументооборот #СЭД #ЭДО #Эргономика #Интерфейс #ТехническоеЗадание #УправлениеДокументами

Распространяется ли Закон о персональных данных на архивные документы?

Нет, напрямую не распространяется. Но есть нюансы!

Подробно и по закону:

1️⃣ Прямое исключение:
Согласно п. 2 ч. 2 ст. 1 ФЗ от 27.07.2006 № 152-ФЗ "О персональных данных", действие этого закона НЕ распространяется на отношения, возникающие при:
▪️хранении,
▪️комплектовании,
▪️учете,
▪️использовании
... документов Архивного фонда РФ и других архивных документов.

Норма коррелируется с ФЗ от 22.10.2004 № 125-ФЗ "Об архивном деле в РФ"

2️⃣ Что такое "архивный документ" в этом контексте?
П. 3 ст. 3 ФЗ-125 прямо относит документы по личному составу (трудовые книжки, приказы о приеме/увольнении, личные карточки Т-2 и т.д.) к архивным документам.

П. 9 ст. 3 ФЗ-125 определяет архив как учреждение или структурное подразделение, которое как раз и занимается хранением, комплектованием, учетом и использованием этих документов.

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

4️⃣ Что это значит на практике?
Пока документ НЕ передан в архив (находится в кадровой службе, бухгалтерии, отделе продаж для текущей работы) – на него в полной мере распространяется 152-ФЗ (согласия, уведомления РКН, политики, защита и т.д.).

После передачи документа в архив – его хранение и обработка регулируются прежде всего архивным законодательством (ФЗ-125, приказы Росархива, правила делопроизводства). Специальный режим архива заменяет общий режим 152-ФЗ для этих документов.

Это подтверждается позицией регулятора:
Письмо Роскомнадзора от 02.03.2020 № 13677-02-11/77 прямо указывает, что особенности хранения архивных документов установлены законодательством об архивном деле, а не о персданных.

ВЫВОД:
Закон о персональных данных не применяется напрямую к документам, которые уже официально переданы на архивное хранение и обрабатываются в соответствии с ФЗ-125 "Об архивном деле" и подзаконными актами. Режим их защиты определяется архивным законодательством.

Важно помнить: это исключение касается именно архивов и официально переданных документов. Все документы с персданными, еще не сданные в архив, по-прежнему подпадают под действие 152-ФЗ.

#ЭлектронныйДокументооборот #СЭД #ЭДО #Архив #ПерсональныеДанные #УправлениеДокументами

В этом учебном году я провела дисциплину «Основные принципы проектирования информационных систем» для магистров кафедры Бизнес-информатики Финансового университета.

Главное, что я попыталась донести до студентов: большинство проблем в автоматизации – не технические, а модельные.

Плохо работает не потому, что «плохо написали»,
а потому что изначально не спроектировали:
▪️не определили объекты автоматизации
▪️не описали связи
▪️не зафиксировали маршруты
▪️не выделили ключевые сценарии

В итоге система превращается в нечто, что как-то работает, но не поддаётся развитию, масштабированию и поддержке.

Запускаю серию постов о том,
как проектировать программы правильно, и какие антипаттерны встречаются чаще всего.

🔜 Первый пост о том, как всего 3–5 таблиц могут описать любую систему.
А дальше – флаги, объекты-монстры, текст вместо моделей и другие ошибки проектирования, которые можно (и нужно!) избегать.

Будет полезно и аналитикам, и архитекторам, и тем, кто пишет ТЗ и внедряет программные продукты на практике.

#ЭлектронныйДокументооборот #СЭД #ЭДО #Согласование #БизнесПроцесс #BPMN #ТехническоеЗадание #УправлениеДокументами

Принципы проектирования программных продуктов

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

Если эти принципы не соблюдаются, продукт быстро превращается в:
▪️хаотичный набор десятков "сущностей"
▪️слабо масштабируемую систему
▪️неуправляемую структуру с трудной настройкой
▪️гору разрозненной документации, которая заменяет логику модели.

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

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

Это позволяет:
▪️прозрачно моделировать бизнес-логику,
▪️быстро вносить изменения,
▪️легко масштабировать решение,
▪️писать понятный и компактный код.

Хороший проект прост в описании и говорит сам за себя. Плохой объясняется сотнями страниц.

#ЭлектронныйДокументооборот #СЭД #ЭДО #Согласование #БизнесПроцесс #BPMN #ТехническоеЗадание #УправлениеДокументами

Хорошо спроектированную систему можно описать в 3–5 таблицах

Табличного описания достаточно, чтобы:
▪понять, какие объекты автоматизируются
▪увидеть их структуру
▪представить маршруты и логику работы

В таблицах можно описывать
▪функции системы
▪объекты автоматизации

Такие таблицы – это уже начало модели, а не просто ТЗ.
Они легко трансформируются в структуру БД, формы интерфейса, маршруты бизнес-процессов и даже API.

#ЭлектронныйДокументооборот #СЭД #ЭДО #Согласование #БизнесПроцесс #BPMN #ТехническоеЗадание #УправлениеДокументами

Примеры далее ⤵️

Пример табличного описания функций системы

Функция:
включение документа в электронный архив >
проверка комплектности документа >
система проверяет наличие всех файлов, составляющих документ

Результат:
▪состав документа полный > переход к проверке метаданных
▪состав документа неполный > окончание процесса

Объект основной:
▪документ

Объекты дополнительные:
▪алгоритм проверки
▪опись документов
▪реестр файлов

Атрибуты (метаданные)
▪нет

Статус основного объекта
▪проверка

#ЭлектронныйДокументооборот #СЭД #ЭДО #Согласование #БизнесПроцесс #BPMN #ТехническоеЗадание #УправлениеДокументами

Пример табличного описания объекта системы - приказа по основной деятельности

Объект:
▪приказ по основной деятельности

Реквизиты:
▪наименование организации
▪наименование вида документа
▪дата
▪регистрационный номер
▪место издания
▪заголовок
▪текст (вводная и распорядительная часть)
▪подпись руководителя организации
▪визы согласования
▪отметка об исполнителе

Вид электронной подписи:
▪УКЭП

Набор метаданных:
▪ID документа внешней системы
▪автор документа
▪регистрационный номер документа
▪дата документа
▪признак документа для служебного пользования (ДСП)
▪должность уполномоченного лица
▪номер сертификата
▪ФИО лица, которому выдан сертификат электронной подписи
▪срок действия сертификата электронной подписи
▪тип подписи
▪дата проверки электронной подписи
▪результат проверки электронной подписи
▪формат файла цифрового документа
▪объем файла цифрового документа
▪хеш-сумма файла цифрового документа

#ЭлектронныйДокументооборот #СЭД #ЭДО #Согласование #БизнесПроцесс #BPMN #ТехническоеЗадание #УправлениеДокументами

Синтетическая классификация в СЭД – ещё один антипаттерн проектирования

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

Примеры проблем синтетической классификации

1️⃣ Нарушение принципа единства основания при делении документов на типы:
▪️акт (вид документа)
▪️документ совещания (группа документов)
▪️дело (единица хранения)
▪️резолюция (реквизит документа)
▪️экспертиза дел (процедура)

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

2️⃣ Невозможность однозначной категоризации:
▪️внутренние документы (документопоток)
▪️нормативная деятельность (вид деятельности)
▪️сведения из Росстата (источник данных)
▪️миграция документов (техпроцесс)

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

3️⃣ Дублирование функций и терминов в интерфейсе системы, вследствие использования неправильной терминологии:
▪️«Контроль поручений», «Контроль документов», «Контроль резолюций»
▪️«Архивное делопроизводство» и «Оперативное хранение»

✔️Проблема:
▪️поручение - содержание документа, но вынесено в отдельный раздел → дублирование данных (например, сроки исполнения).
▪️резолюция - реквизит документа
▪️документ в архиве отображается в двух блоках («Архив» и «Все документы») → риск расхождения информации.
▪️архивное делопроизводство (смешение двух областей: делопроизводство и архивное дело, все равно что сказать "строительная эксплуатация") подразумевает архивное хранение, но не должно включать оперативное хранение, которое относится к делопроизводственному этапу

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

Характерный признак проектирования системы на основе синтетической классификации - громоздкое, многостраничное и нечитаемое техническое задание.

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

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

ВЫВОД
Хаос в классификации – это хаос в системе.
Синтетические типы ведут к синтетической логике. А дальше – всё разваливается.

#ЭлектронныйДокументооборот #СЭД #ЭДО #ЭталоннаяМодель #ТиповаяМодель #УправлениеДокументами

Антипаттерн проектирования: система из флагов

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

Итак, почему множество галочек «Да/Нет» разрушают систему?

Представьте (даже если вы не программист), что вы строите дом, а вместо четкого плана этажей у вас есть только куча стикеров на стене:
✔️ фундамент есть
✔️ стены стоят
✔️ окна вставлены
✖️ крыша не течет
✖️ двери не установлены

Что пойдет не так?

1️⃣ Хаос вместо ясности: вы не видите текущую стадию стройки (начало? почти готово?). Только гору разрозненных фактов

2️⃣ Сложность управления: Добавили «санузел»? Теперь нужно 5 новых стикеров: «Раковина есть», «Унитаз подключен»… И проверять их все каждый раз!

3️⃣ Ошибки гарантированы: рабочие видят ✔️«Стены стоят» и начинают крыть крышу, не заметив ✖️ «Несущие балки не закреплены»

Это и есть «система из флагов» в IT: когда вместо понятного статуса («проект», «на согласовании», «утверждено») объект описывают кучей меток:
«Просмотрен»
«Отправлен»
«Одобрен»
«Отклонен»
«В архиве»

...и десяток других «Да/Нет».

Чем это плохо для бизнеса?

▪️Невозможно отследить этапы: где сейчас документ? у кого застрял?
▪️Ошибки в процессах из-за сложной проверки большого кол-ва условий
▪️Сложные обновления: добавить этап «Доработка»? придется перелопатить все метки
▪️Замедление: чтобы понять, можно ли работать с документом, система проверяет 10 условий вместо одного статуса

Решение: статусы вместо меток

Вместо 20 меток «Да/Нет» вводим четкие этапы для документа:
1. Проект → 2. Согласован → 3. Подписан → 4. Зарегистрирован → 5. Исполнен→ 6. В архиве

Плюсы подхода:
▪️документ не может быть «Подписан», если он в статусе «Проект»
▪️добавили этап «Доработка» и вставили его между 2 и 3
▪️меньше шансов на конфликтующие действия.

Философия подхода:
Сложные системы управляются не кучей переключателей, а четкими этапами с контролем перехода между ними

Как в строительстве: сначала фундамент, потом стены, потом крыша. Не наоборот.

#ЭлектронныйДокументооборот #СЭД #ЭДО #ЭталоннаяМодель #ТиповаяМодель #УправлениеДокументами

Эталонная модель — сердце конструктора процессов
или как перестать тушить пожары в документообороте

Если у вашей системы нет логического ядра – она быстро превращается в лабиринт исключений, ручных проверок и скриптов.

Кажется, вы строите конструктор:
документ → этап → правило → роль.
Но как только появляются реальные требования…

«Если договор без приложений – не пускать!»
«Юрист подписывает ТОЛЬКО договоры свыше 1 млн»
«Срочные заявки идут без финконтроля»

…система перестаёт справляться.

Что происходит без эталона:

Система не знает, что такое "приложение"
"Правило" – просто текст без логики
Ошибки всплывают только при запуске
Каждый кейс требует нового костыля
А изменения – это технический долг, который только растёт

Такая гибкость – это граната с выдернутой чекой.

Что даёт эталонная модель:

Это не про код. Это про чёткие сущности (документ, этап, правило) и их встроенное поведение.

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

Вы не пишете правила заново – вы выбираете поведение из готовой библиотеки.

Зачем это нужно:

▪️новый документ не создаётся "с нуля", а наследует поведение
▪️одно изменение применяется в десятках маршрутов автоматически
▪️бизнес-логика протестирована в одном месте – работает везде
▪️поддержка и масштабирование в разы проще
▪️клиенты получают удобный интерфейс вместо ручной настройки

Эталонная модель – это ваш набор стандартных кубиков LEGO. А конструктор процессов – просто способ их собирать

Что происходит без модели? Всё держится на скотче (скриптах, условиях и флагах). И каждый новый кейс – как мина замедленного действия.

#ЭлектронныйДокументооборот #СЭД #ЭДО #ЭталоннаяМодель #ТиповаяМодель #УправлениеДокументами

Удалённый доступ к архивам: утверждены правила работы ГИС

Росархив запускает цифровизацию исторических документов.
Правительство утвердило Положение о ГИС удалённого использования архивных документов (ГИС УИАД) — постановление № 981 от 30.06.2025

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

Что можно будет делать через ГИС УИАД:

✔️ искать архивные документы
✔️ просматривать/прослушивать их электронные копии
✔️ работать с материалами онлайн в личном кабинете

Ключевые принципы работы:

▪️оператор системы – Росархив
▪️защита персональных данных (152-ФЗ)
▪️сохранность подлинников
▪️засекреченные документы остаются офлайн
▪️доступ к данным – только при наличии правовых оснований

С 1 января 2027 года доступ – только с усиленной квалифицированной ЭП (УКЭП). До этого – упрощённая процедура.

Кому это нужно:

▪️историки – доступ к фондам из любой точки мира
▪️генеалоги – поиск сведений о предках без командировок
▪️юристы и бизнес – подтверждение прав и фактов через онлайн-архивные справки

Важно:
▪️копии документов не скачиваются, только просмотр/прослушивание в личном кабинете
▪️авторские права – по 4 части ГК РФ
▪️за просмотр: 90 ₽ в час или 350 ₽ в сутки (Постановление № 982)

Регистрация в системе – бесплатная

ГИС УИАД создаётся в рамках закона № 469-ФЗ от 2024 года.
Интеграция будет осуществляться с помощью инфраструктуры электронного правительства.

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

#ЭлектронныйАрхив #Архив #Росархив #ГИС #УИАД #УправлениеДокументами

Постатейный разбор главных отличий ГОСТ Р 7.0.97-2025 и ГОСТ Р 7.0.97-2016. Разбираемся, что поменялось по пунктам

Новый стандарт оформления организационно-распорядительных документов вступает в силу 18 августа 2025 г. Он заменяет ГОСТ Р 7.0.97-2016.

Общие положения (раздел 1 и 2)

✔️ область применения осталась без изменений: охватывает уставы, регламенты, приказы и т. д.

✔️ в нормативных ссылках появилась новая:
ГОСТ Р 51511 о печатях с гербом РФ.

✔️ из описания исчезли ссылки на ГОСТ Р 7.0.8 и на ISO 15489-1 как “системообразующие” – теперь они просто в перечне.

Раздел 3. Общие требования к созданию документов

✔️ теперь разрешено использование электронных шаблонов документов и бланков.

✔️ размер шрифта теперь устанавливается локальными актами, ГОСТ лишь рекомендует: 12, 13, 14.

✔️ уточнено: шрифты меньшего размера допустимы при оформлении реквизитов 08 и 25 (справочные данные и отметка об исполнителе).

✔️ более чётко регламентировано оформление заголовков, многострочных реквизитов и выравнивание строк.

Раздел 4. Реквизиты документа

✔️ новый реквизит №04: штрих-код документа – актуально для СЭД и автоматизации.

✔️ названия реквизитов и их описание уточнены, но состав остался из 30 пунктов.

✔️ реквизит 14 теперь называется "гриф (пометка) об ограничении доступа" – терминология приведена в соответствие с ИБ и архивным делом.

Раздел 5. Оформление реквизитов

✔️ запрещено одновременно размещать герб РФ и герб субъекта РФ на одном бланке.

✔️ уточнены правила размещения эмблем и товарных знаков – особенно для документов, изданных двумя и более организациями.

✔️ добавлены правила по штрих-кодированию документов: размещается в левом нижнем углу (или в другом свободном месте).

✔️ реквизит "адресат" теперь оформляется более гибко: подробно описаны случаи с физлицами, юридическими, подразделениями и массовыми рассылками.

✔️ приложения (новое)
В новой редакции отметка о приложении (реквизит 19) чётко дифференцируется:
▪️сопроводительные письма оформляются отдельно;
▪️распорядительные документы и договоры не имеют отметки о приложении (!), информация об этом находится только в тексте.

✔️ добавлены новые примеры оформления приложений на носителях (CD, флешка).

Что важно для СЭД и делопроизводства

✔️ появление штрих-кода и разрешение электронных шаблонов – зелёный свет для цифровизации.

✔️ упрощение форматных требований (шрифт, отступ, интервал) – теперь это зона локального регулирования.

✔️ уточнены формулировки для оформления титульных листов, обращений, подписей и др. – это поможет валидации шаблонов.

Вывод
ГОСТ Р 7.0.97-2025 – это эволюция, а не революция. Он приводит документ в соответствие с современными практиками и электронным документооборотом, убирает лишние детали и делает акцент на локальное регулирование. Это значит, что у организаций появляется больше гибкости, но и больше ответственности за качество шаблонов.

В следующем посте приведу чек-лист для подготовки шаблонов документов к новому ГОСТу.

#ЭлектронныйДокументооборот #СЭД #ЭДО #ГОСТ #УправлениеДокументами #Документоведение #Делопроизводство #ОформлениеДокументов

Чек-лист подготовки шаблонов по ГОСТ Р 7.0.97-2025

1️⃣ Общие положения
✔️ шаблоны поддерживают бумажную и электронную форму документа
✔️ в системе предусмотрены электронные шаблоны (DOCX, PDF, XML и др.)

2️⃣ Шрифт и форматирование
✔️ используются шрифты и размеры, установленные локальными актами (рекомендуемые: 12, 13, 14 pt)
✔️ абзацный отступ: 1,25 см
✔️ межстрочный интервал: 1–1,5; двойной при уменьшении масштаба
✔️ выравнивание текста по ширине; один пробел между словами
✔️ заголовки с отступом или центрированные

3️⃣ Реквизиты документа (всего 30)
✔️ шаблоны содержат все необходимые реквизиты
✔️ добавлен новый реквизит 04 — Штрих-код (левый нижний угол)
✔️ нет одновременного размещения гербов РФ и субъекта РФ
✔️ актуализированы правила для реквизитов 05–07, 08, 10, 14, 15, 19, 23

4️⃣ Оформление шаблонов
✔️ соблюдаются схемы размещения реквизитов (Приложение А)
✔️ многостраничные документы имеют титульный лист
✔️ грифы утверждения и согласования оформлены по правилам
✔️ формы текста соответствуют типу документа (приказ, протокол, письмо и т.д.)

5️⃣ Приложения
✔️ отсутствует отметка о приложении в распорядительных документах
✔️ предусмотрено оформление приложений на электронных носителях (CD, USB)
✔️ нумерация приложений ведется по ГОСТу


Рекомендации
1️⃣ Обновите локальные нормативные акты (инструкции, шаблоны)
2️⃣ Протестируйте шаблоны в СЭД
3️⃣ Внедрите автозаполнение реквизитов

#ЭлектронныйДокументооборот #СЭД #ЭДО #УправлениеДокументами #ГОСТ #Документоведение #Делопроизводство #ОформлениеДокументов

Ошибки в разделении задач и функций: как путаница разрушает вашу команду

Управленческие сбои, выгорание и хаос часто растут из одной проблемы – смешения задач и функций. Разберем ТОП-5 дорогостоящих ошибок и, главное, как это исправить

❌ ТОП-5 Ошибок (с последствиями)

1️⃣ Задачи подменяют функцией
✖️ Вместо «Подготовить отчет по продажам до 20 июля» → «Иванов занимается отчетностью»
Итог: нет дедлайнов, результат «размазан», сотрудник в вечном процессе.

2️⃣ Функции дробят на сотни микро-задач
✖️ «Ведение кадрового учета» превратили в 20 несвязанных поручений в Trello
Итог: потеря системности, постоянное переключение контекста, ноль ответственности за итог.

3️⃣ KPI скопированы без понимания сути
✖️ «Напиши отчет по своему функционалу» (где метрика? срок? образец?)
Фиаско: метрики задач (например, «срок») бессмысленны для функций (где важна «стабильность»).

4️⃣ Персонал подбирают «вслепую»
✖️ Реальность: креативщика нагружают рутиной, системного аналитика кидают в «авральные проекты»
Результат: демотивация, текучка, упущенная прибыль.

5️⃣ Бюджет планируют без разделения
✖️ Почему это фатально:
Задачи = разовые расходы (например, внедрение CRM) Функции = постоянные затраты (например, техподдержка)
Итог: деньги утекают впустую, ROI не считается.


✅ Как исправить

1️⃣ Разделяйте понятия
Задачи
Результат (что сделано?)
Срок (когда сдать?)
Конкретный KPI (%/шт.)
Функции
Процесс (как ведется?)
Регулярность (как часто?)
Качество (ошибки/сбои)

2️⃣ Разделяйте инструменты
задачи: Trello, Jira, Asana (дедлайны, приоритеты, статусы)
функции:
▪️матрица ответственности (RACI)
▪️дорожная карта процессов (BPMN)
▪️чек-листы контроля качества

3️⃣ Делайте разным KPI
задача: «отчет сдан до 20 июля + 100% данных без ошибок»
функция: «ведение кадрового учета: 0 жалоб от сотрудников, время обработки заявок ≤ 1 дня»

4️⃣ Соблюдайте Золотое правило баланса
70% времени – функции (стабильность)
30% – задачи (развитие)
Нарушение = перекос в эффективности.

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

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

#менеджмент #KPI #управлениекомандой #процессы #эффективность #hr #бизнес_советы #softskills