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

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

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

Что не так?

✔️ 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

Отмечаю День рождения🎈🎈

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

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

Со своей стороны обещаю быть по-прежнему полезной, профессиональной и интересной.

Для новых подписчиков – немного обо мне: уже 23 года я работаю в области управления документами, совмещая науку, разработку ПО, проектную практику и преподавание.

Образование
Я окончила Историко-архивный институт. Кандидат исторических наук по специальности документалистика, документоведение, архивоведение.

Карьера
▪️Начинала как процессный методолог в крупнейших российских финансовых и страховых организациях: ВТБ, «Русский Стандарт», «Росгосстрах», «Банк Траст», «РОСНАНО» и др.

▪️С 2012 по 2020 руководила направлением методологии электронного документооборота в фирме «1С». Сделала методологию самостоятельным продуктом, а методическое сопровождение стало ключевым преимуществом «1С:Документооборота».

▪️За плечами 20+ проектов автоматизации на разных СЭД.

▪️Сегодня я помощник заместителя федерального министра по цифровизации. Участвую в эксперименте по цифровизации электронного документооборота, исполнения поручений и контроля исполнительской дисциплины в отдельных ФОИВ.

Разработка программных продуктов
Проектировала продукты с нуля:

▪️«1С:РСП» – автоматизация работы с гостайной
▪️СХЭД – электронный архив для госкорпорации
▪️Модуль сбора и обработки данных при внедрении СЭД (патент)

Преподавание
▪️Доцент кафедры документоведения, аудиовизуальных и научно-технических архивов ИАИ РГГУ
▪️Доцент кафедры бизнес-информатики Финансового университета при Правительстве РФ

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

▪️В 2025 году утвержден ГОСТ Р 59999 – «Цифровой документооборот организации. Требования к эталонной модели» – это результат моей совместной работы с Союзом ИТ-директоров и Финансовым университетом.

▪️И моя особая страсть – документная лингвистика. Выпустила в прошлом два учебных пособия в соавторстве с коллегами из Института Массмедиа РГГУ.
Практикум по русской стилистике
Практикум по литературному редактированию

▪️Учебник "Документоведение" в соавторстве с коллегами с кафедры документоведения, аудиовизуальных и научно-технических архивов ИАИ РГГУ

Спасибо, что вы со мной. Будем дальше обсуждать, анализировать и создавать профессиональные смыслы — вместе

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

Цель и задачи: как правильно формулировать

Цель – это общее направление и конечный ожидаемый результат исследования или проекта. Она отвечает на вопрос: "Зачем?" или "К чему стремимся?"

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

Примеры правильных формулировок цели:
▪️разработка модели управления документами в цифровой среде
▪️анализ факторов, влияющих на внедрение СЭД в госсекторе
▪️обоснование выбора архитектуры для интеграции СЭД с внешними сервисами

Задачи – это конкретные шаги, которые нужно выполнить для достижения цели. Они отвечают на вопрос: "Что нужно сделать, чтобы достичь цели?"

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

Пример набора задач:
1️⃣ изучить нормативно-методическую базу в области электронного документооборота
2️⃣ проанализировать существующие подходы к классификации документов в СЭД
3️⃣ разработать структуру карточки электронного документа, соответствующую требованиям законодательства
4️⃣ описать модель маршрутизации документов в условиях смешанного документооборота

❌ Типичные ошибки
▪️цель совпадает с названием работы/проекта (название – это тема, а не результат)
▪️цель звучит как процесс, например, "Изучение…" (процесс – это задача, а не цель)
▪️в задачах перечислены главы (структура ≠ логика действий)
▪️задачи не связаны с целью (нарушена логика "от общего к частному")

✅ Рекомендации по оформлению
▪️в научной работе цель часто формулируется в первой части введения, задачи – сразу после неё
▪️в проектной документации (бизнес-план, ТЗ, концепция) цели и задачи выносятся в отдельный раздел
▪️цель должна быть одна, задачи – от 3 до 7, логично раскрывающих путь к достижению цели

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

Как правильно описывать процесс согласования в проектной документации

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

Что такое "согласование" на самом деле?

Согласование может быть как процессом (совокупность действий), так и результатом экспертной оценки ("согласовано").

Действия, которые совершаются участниками согласования:
◾️рассмотрение документа
◾️фиксация результата в виде одной из возможных отметок:
▪️согласовано
▪️не согласовано
▪️согласовано с замечаниями

❌ Нельзя писать:
«Документ проходит согласование у руководителя подразделения».

✅ Лучше так:
«Руководитель подразделения рассматривает документ и фиксирует результат рассмотрения в СЭД в виде одной из доступных отметок».

Такой подход
▪️убирает двусмысленность
▪️проще реализуется в системах
▪️позволяет строить метрики и отчёты по действиям, а не по абстракциям

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

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

Прецедент: Верховный суд поставил под сомнение легальность простой электронной подписи

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

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

Позиция Верховного суда
ВС отменил решения трёх инстанций и вернул дело на новое рассмотрение. Ключевые тезисы:

1️⃣ ПЭП ≠ автоматическая легальность
Чтобы документ, подписанный ПЭП, был равнозначен бумажному, нужны не только коды и пароли, но и достоверная идентификация лица, выразившего волю. Суду следовало установить, действительно ли заемщик сам совершал действия, либо ими воспользовалось третье лицо.

2️⃣ Важна не только техника, но и воля
Сделка – это всегда волеизъявление. Если клиент совершал лишь технические действия (или их совершил другой человек), а воля на заключение договора отсутствовала, то договор может считаться незаключенным.

3️⃣ Индивидуальные условия должны подписываться надлежащим образом
ВС напомнил позицию Банка России (письмо ИН-02-59/6 от 03.02.2022): практика, когда согласие выражается только через конклюдентные действия или звонок, не соответствует Закону о потребительском кредите.

4️⃣ Повышенные меры предосторожности
Конституционный суд ранее указывал: если кредит выдается и тут же переводится третьим лицам, банк обязан проявить особую бдительность.

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

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

❗️Риски для рынка

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

СЭД и ЭДО: повышенное внимание к юридической силе ПЭП в B2C-сценариях. Техническая фиксация действия уже недостаточна – нужны процессы, исключающие использование подписи третьими лицами.

Заемщики: дополнительный аргумент в спорах, когда кредит оформлен мошенниками.

ВЫВОД
Верховный суд фактически сказал:

ПЭП – это не просто «код из SMS», а инструмент, юридическая сила которого зависит от того, может ли он достоверно подтвердить, что именно владелец подписи выразил волю на сделку.

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

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

#ЭлектронныйДокументооборот #СЭД #ЭДО #УправлениеДокументами #ПЭП #БанкОнлайн #SMS #КЭП #НЭП