Юридический техдолг: как он появляется и почему его не видят

[Cordekk]

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

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

[kirill_knaub]

Согласен с разделением. То, что описано в статье: именно процессный техдолг, накопленный в операционной модели. Термин “юридический” в заголовке использован в значении “техдолг внутри юридических процессов”, а не “техдолг в праве как системе норм”.

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

Спасибо за уточнение, оно точное.

[Cordekk]

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

[kirill_knaub]

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

[Cordekk]

Тут позвольте не согласиться.

Надо оставить и такую форму аудита, когда просто приходим и смотрим из-за плеча сотрудников на их работу.

Конечно для полностью автоматизированных процессов можно поставить контроль по техническим метрикам.

[kirill_knaub]

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

[AlisaIlushkina]

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

Хотелось бы уточнить детали по абзацу про почтовую корреспонденцию:

• Как выглядит процесс отправки писем в Копидефенд?

• Какую задачу решал новый формат с печатью марок на конвертах?

• Сколько времени в итоге удалось сэкономить?

• Как замеряли эти два смежных этапа?

• Что имеется в виду под «процесс рядом никто не пересмотрел»?

Было бы интересно узнать больше деталей по этому кейсу!

[kirill_knaub]

Спасибо за вопросы, раскрою подробнее.

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

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

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

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

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

Ключевой момент: когда мы оптимизировали только марки, сотрудники считали, что процесс уже улучшен. Сопротивление дальнейшим изменениям было не из-за сложности, а из-за ощущения “мы же уже это оптимизировали”. Техдолг прятался за ощущением завершённости.