Comments 5
Они знают ответы не потому, что помнят наизусть сотни страниц внутренних документов. Просто они уже двадцать раз открывали нужный регламент и примерно представляют, где искать.
Проблема часто в ином: в нормативке (локальных НД) написано одно, а реально работают иначе.
AS-IS («как есть») в документации, а AS REALLY IS («как есть на самом деле») отражает реальное положение дел и часто это две большие разницы.
Лучше ИИ натравить на process mining / docflow mining, а не на макулатуру, пусть и нормативную. Вторым этапом ИИ сможет найти в них расхождение и скорректировать: НД vs REALLY или может быть будет проще создать новый ("реальный") комплект НД по данным майнинга (конечно при высоком уровне в компании цифровизации \ автоматизации \ информатизации \ etc).
Спасибо, очень точное замечание. По сути, вы описали следующий слой этой задачи.
Наш текущий RAG отвечает прежде всего на вопрос «как должно быть по нормативке?» и намеренно жёстко привязан к НД. Но гораздо интереснее было бы сопоставить две картины:
should be - что написано в регламентах
as really is - что реально происходит в CRM/BPM/ERP/СЭД и других системах.
Тогда AI уже не просто ищет нужный пункт, а обнаруживает расхождения: где регламент устарел, где процесс систематически нарушается, где возник устойчивый неформальный обход, а где проблема вообще в неполном цифровом следе.
С автоматическим созданием «реального» комплекта НД по результатам mining я бы только не спешил :) Если 80% сотрудников обходят какой-то контроль, это ещё не означает, что контроль надо исключить из регламента. Возможно, мы как раз обнаружили системную проблему. А вот использовать process mining как источник кандидатов на пересмотр НД — идея, на мой взгляд, очень сильная.
Интересно ваше мнение: из чего вы бы строили as really is - event logs CRM/BPM/ERP как основу + docflow, тикеты, переписку как дополнительные сигналы? И что делать с процессами, где значительная часть реальной работы вообще не оставляет нормального цифрового следа?
Кажется, здесь уже вырисовывается тема для отдельного эксперимента: RAG + Process Mining → поиск разрыва между «как надо» и «как на самом деле».
Интересно ваше мнение: из чего вы бы строили as really is - event logs CRM/BPM/ERP как основу + docflow, тикеты, переписку как дополнительные сигналы?
Можно идти с разных сторон:
от модели к реальности, например, если есть, BPMN-engine, то нужна интеграция с ним, т.к. это "исполняемый регламент". Плюс "мониторинг состояния исполняемых процессов (например, через Camunda cockpit)" и т.п.
от реальности к модели, как пример process mining. Это "Технологии «обратного проектирования» DT". Да, это "event logs CRM/BPM/ERP", когда то делал "process mining на коленке": парсил логи разных систем и грузил в excel и далее визуализация.
В целом это (прямое и обратное проектирование DT) все в сторону DT, см. Digital Twin. Часть 2. Инструментальный Цифровой двойник
И что делать с процессами, где значительная часть реальной работы вообще не оставляет нормального цифрового следа?
Там же показал идею (общий подход, причем для ИИ это должно быть посильно):
Теоретически можно любой офис «обвесить камерами» (с распознанием лиц и т.п.), которые будут распознавать все бумажные документы на всех столах всех сотрудников и определять какой документ в каком состоянии (например, заявление на отпуск: составлено \ согласовано \ утверждено \ исполнено – выплачены отпускные). По этим документам система будет распознавать этапы процесса и строить схему «работы всей компании», включая кто в какой момент и что делает и как это соотносится с «эталонной моделью» ("как было нужно", as is).
Конечно это только общая идея, для реализации контроля "бумаги" нужна строгая дисциплина.
поиск разрыва между «как надо» и «как на самом деле».
Полагаю, что "не за горами" услуги типа BPM-Pentesting - когда за коротким период времени заказчику проведут "тестирование на проникновение в его же бизнес-процессы" и дадут сравнение не только с «как надо» - в нормативке заказчика (там тоже глупости пишут), но и «как надо» из Best Practice, эталонных каталогов процессов (benchmark-анализ по условному детальному APQC PCF), проведут оценку операционных рисков процесса (с симуляцией угроз, в т.ч. человеческого фактора) и т.п. Т.е. pentest процессов компании, а не только оборудования, причем для pentest может быть развернут тестовый DT компании.
PS: ответ не попал в прежнюю ветку ...
Спасибо, теперь мысль про DT стала гораздо понятнее. Прочитал вашу вторую часть - особенно понравилась идея двух инструментальных переходов «модель → реальность» и «реальность → модель».
И тут, кажется, наша исходная задача начинает превращаться во что-то большее, чем просто RAG + Process Mining.
Я бы попробовал разложить это уже на три слоя:
1. Нормативный двойник - should be
RAG/LLM извлекает из НД требования, роли, ограничения, сроки, условия и формирует формализованное представление того, как процесс должен работать.
2. Операционный двойник - as really is
Process Mining / event logs / BPM / CRM / ERP / СЭД восстанавливают то, как процесс реально работает.
3. Слой расхождений - should be ↔ as really is
А вот здесь AI уже ищет отклонения, классифицирует их и пытается определить: это нарушение процесса, устаревший регламент, допустимый workaround, отсутствие цифрового следа или действительно новая Best Practice.
Причём ваш термин BPM-Pentesting здесь, по-моему, очень удачный. Можно ведь пойти ещё дальше: не только находить уже существующие отклонения, но и намеренно «атаковать» процесс - моделировать обход контролей, неправильную последовательность действий, человеческий фактор, конфликт ролей - и смотреть, где нормативная модель не выдерживает столкновения с реальностью.
С камерами я бы, пожалуй, начал не сразу :) Не столько по техническим причинам, сколько потому, что появляется огромный пласт privacy/compliance и ошибок интерпретации. Я бы сначала выжал весь существующий digital exhaust компании - логи систем, workflow, CRM/ERP, СЭД, task trackers, возможно метаданные коммуникаций - а уже «тёмные зоны» процесса закрывал дополнительными способами наблюдения.
И вот здесь у меня возникает, пожалуй, главный вопрос: кто является арбитром при расхождении двух двойников?
Допустим, нормативка говорит A → B → C, а mining показывает, что в 87% случаев компания годами работает A → C. Как инструментально определить, что перед нами: нарушение, которое надо устранить, или устаревшая модель, которую пора переписать?
Мне кажется, именно эта точка может оказаться самым интересным местом всей конструкции.
Причём ваш термин BPM-Pentesting здесь, по-моему, очень удачный. Можно ведь пойти ещё дальше: не только находить уже существующие отклонения, но и намеренно «атаковать» процесс
Это и подразумевалось, т.к. Pentesting ровно про это, иначе это назвал бы аудит и т.п.
"С ходу" пробую привести пример BP-пентеста процедуры "двойной ввод".
Смотрим 6 Качество \ надежность \ отказоустойчивость алгоритма. Допустим в платежный процесс (контур) можно завести (подмешать) тестовый поток платежных документов, поток "незаметный" (не отличим от реального) для операционистов \ контролеров (конечно на выходе нужно тестовый терминировать, т.е. не исполнять тестовые платежи). Подбирается наиболее загруженный период дня (плотный поток платежей, чтобы "глаз замылился") и делаются вкрапления (подаются документы для ручного ввода или контроля "глазами") из специально подобранных сумм: крупная "круглая" с целью реализации события операционного риска:
В данном случае мы говорим про вероятность, когда оба Операционист и Контроллер одновременно добавят или потеряют один (или два) нуля (сделают ошибку при вводе первичного документа в АБС).
Конечно в случае реализации этой атаки - ошибка исполнителей будет зафиксирована, но на оправку платеж не уйдет (будет удалён перед отправкой, т.к. скрыто помечен как тестовый). Кстати, подобные ошибки в банках реально происходят несмотря на повторный ввод.
С камерами я бы, пожалуй, начал не сразу :)
Это навеяно бумом роботов‑секретарей: например, этот или Donna AI. С камерами подобное "заиграет новыми красками".
В части ориентира на НД - это далеко не всегда оправдано. Пара примеров.
В банках много НД написаны с единственной целью - когда придет проверка регулятора - положить такие НД на стол проверяющим. Работать по таким НД изначально не планируют, но документ "очень нужен". Часто это талмуды переписанные 1:1 с НД регулятора.
Второй пример, методисты регулятора для какой-либо "свежей темы" вообще пишут положения / инструкции не понимая о чем пишут. Например, "свежая тема" Операционная надежность: сейчас в 850-П (и в предшественнике 787-П) формула деградации = количество операций во время сбоя / к плановому числу операций. Т.е. например, 0/10 = 0% деградации, т.е. нулевая деградация, но ничего не работает. Как так?
"Так" регулятор (см. 787-П, 850-П) годами обязывал всех считать (повторять этот бред) и только с нового года 2027 в формулу (наконец-то) добавляет "1", т.е.: "1 - количество операций во время сбоя / к плановому числу операций". И смысл "сверяться" с такой "кривой нормативкой"? Полагаю, что в локальных НД большинства банков переписан 1:1 этот бред из 787-П и 850-П. Конечно, ИИ можно и подобное объяснить и наказать ему считать "криво", но "по требованию регулятора".
особенно понравилась идея двух инструментальных переходов «модель → реальность» и «реальность → модель».
Если более точно, то это цикл:
«модель → реальность» => «реальность → модель» => «модель → реальность» и т.д., т.е. просто обратная связь.
Будет более точно, по аналогии с (D — T — D'):
«модель → реальность» => «реальность → модель'» => «модель' → реальность'»
Как мы научили ИИ читать корпоративные регламенты: от наивного RAG до измеримого pipeline