
Комментарии 2
Если процесс редкий, или малозатратный, или уже полностью автоматизирован — он отсекается как «не приоритет», и в детальный разбор не идёт. Это банально, но без этого слоя сканер тратил бы 18 вопросов на процессы, которые в принципе не стоит анализировать.
а вот туту вопрос - т.к. есть огромный пласт редких процессов который требует некоторых компетенций и ключевых знаний как "процедуры" так и "базы" - возможно как раз автоматизация таких редких процессов которые съедают кучу времени именно из-за редкости использования и потребности восстановления знаний тоже может иметь и даже больший чем попытки автоматизировать более частые процессы.
Дельное замечание, спасибо. Действительно, классическая формула «частота × длительность» упускает кейс, когда половина работы - это разрозненные редкие задачи, и в сумме их много.
Но для редких процессов знание контекста часто важнее самой операции, особенно когда между повторами успело поменяться законодательство, регламент или система. И как будто тут хорошо подойдет персональный ИИ-агент с RAG (базой знаний). Но как бы не вышло так, что автоматизация редкого процесса сама станет "редко используемой системой". И эта база знаний будет требовать постоянного мониторинга (обновления, права доступа, изменения в смежных системах), и при каждом следующем запуске вы будете тратить время не на сам процесс, а на починку его автоматизации.
Хотя мысль ценная, и факт большого количества разнородных редких задач нужно как минимум отфиксировать (если применимо). А вот как его решать - пока для меня вопрос открытый. Если Вы уже думали что-то в эту сторону, с удовольствием почитаю.
Я построила диагностику «стоит ли это автоматизировать» — и она трижды говорила глупости. Разбор ошибок