Методический текст преподавателя к неделе 11
Восемь страниц о должности, которой нет в описании процессов, о числе, которое стало участником совещаний, и о том, почему успешное внедрение иногда разваливается через полгода после успешного запуска.
На семинаре вы будете допрашивать меня как архитектора системы — сорок пять минут, любые вопросы, включая неудобные. Этот текст нужен, чтобы вопросы были содержательными. Читайте с карандашом: всё, что покажется недосказанным, выписывайте — это и будет ваш список на занятие.
В любой достаточно большой организации есть поток входящих документов: письма, договоры, претензии, заявки, запросы от ведомств. Сотни в день. С каждым нужно проделать пять операций.
Первое — принять. Документ приходит бумагой, почтой, через портал.
Второе — прочитать и понять, что это и насколько срочно.
Третье — решить, кому внутри компании это адресовать.
Четвёртое — передать: зарегистрировать, присвоить номер, назначить срок.
Пятое — проследить, что ответили вовремя, и напомнить, если нет.
Из этих пяти операций четыре описаны в регламенте. Третья — нет.
Человека, который всем этим занимается, будем называть регистратором. Формально его работа — раскладывать документы по маршрутам. Фактически он держит в голове карту организации, которой не существует ни в одном документе.
Что именно он знает:
Здесь стоит остановиться и не романтизировать. Такое знание — не только ресурс организации, но и ресурс самого человека: оно делает его незаменимым и даёт неформальное влияние. Оно же делает его уязвимым: то, что нельзя предъявить, нельзя и защитить при разговоре о сокращении.
Вспомните в своей учёбе или работе человека, без которого «всё встанет», хотя по должности он не решает ничего важного. Что именно он знает? Записано ли это где-нибудь?
ИИ-канцелярия делает то же самое автоматически. Документ проходит пять шагов.
| Шаг | Что происходит | Насколько надёжно |
|---|---|---|
| Загрузка | Скан, почта, портал. На входе изображение или файл | Надёжно, кроме плохих сканов |
| Распознавание | Из изображения получается текст со своими ошибками | Зависит от качества оригинала |
| Классификация | Договор, письмо, претензия, счёт — появляется категория | Средне: бывают гибриды |
| Извлечение полей | От кого, кому, дата, тема, срочность, сумма | По-разному: см. ниже |
| Маршрутизация | Документ уходит адресату сам. Решение состоялось | Настолько, насколько верны шаги 3–4 |
Обратите внимание на третий шаг. Это классификация из первой недели курса: категория не описывает документ, она определяет, что с ним произойдёт дальше. «Претензия» и «письмо» — разные маршруты, разные сроки, разные люди.
От кого и дата — надёжно. Стоят в шапке, формат устойчивый, вариантов немного.
Тип документа — средне. Определяется по формулировкам и структуре, но встречаются гибриды: письмо, которое по сути претензия.
Срочность — плохо. Почти никогда не написана прямо. Читается из контекста и из того, кто отправитель. То есть требует ровно того знания, которое было у регистратора и которого нет у модели.
Коэффициент уверенности — оценка системы, насколько она уверена в собственном выводе.
Система не решает молча. Она сообщает: «я думаю, это договор, уверенность 70 %». От этого числа зависит, уйдёт документ сразу в маршрут или попадёт человеку на проверку.
Здесь происходит то, ради чего мы читали Латура. Число становится актором: оно меняет ход событий, у него есть эффект, но нет ни лица, ни должности, ни приёмных часов. Спорить с ним нельзя — можно спорить только с решением о пороге.
И вот вопрос, который стоит задать на семинаре первым: кто в компании имеет право двигать этот порог и с кем он это согласовывает?
Порог — не настройка. Это распределение нагрузки и риска между людьми, оформленное как техническое решение.
Поднять порог — больше документов уходит человеку на проверку. Меньше пропущенных ошибок, но растёт нагрузка на проверяющих. Если штат при этом не увеличили, проверка превращается в формальность: человек нажимает «согласен», не читая. Порог формально высокий, фактически не работает.
Опустить порог — больше документов идёт автоматически. Процесс быстрее и дешевле, но растёт доля ошибок, которые никто не заметит. Цену платит тот, чей документ ушёл не туда, — и он об этом, как правило, не узнает.
Третьего варианта нет. Любое движение ползунка кому-то добавляет работы, а кому-то — риска. Поэтому вопрос «какой порог правильный» не имеет технического ответа: он зависит от того, чью цену организация готова оплачивать.
Как бы вы обосновали выбор порога перед финансовым директором? А перед профсоюзом? Отличаются ли аргументы — и что это говорит о природе решения?
Без этого различения не разобрать ни один инцидент внедрения.
| Тип ошибки | Что произошло | Кто исправляет |
|---|---|---|
| Ошибка описания | Система неверно отнесла объект к категории: назвала претензию письмом | Инженеры: данные, разметка, модель |
| Ошибка последствия | Категория верная, но действие несоразмерно: обычный запрос ушёл в юридическую проверку на месяц | Организация: процедура после срабатывания |
| Ошибка категории | Система измеряет не то, что важно: сортирует по типу документа, когда людям важна срочность | Тот, кто задавал постановку задачи |
Третий тип — самый дорогой и самый незаметный. Его нельзя обнаружить, глядя на метрики: модель работает отлично, точность высокая, отчёт зелёный. Просто задача была поставлена не та.
Аналогия из другой области: «вовлечённость» — разумная метрика для того, чтобы понять, какой контент людям интересен. Но если сделать её главной целью, платформа начнёт предпочитать не полезное, а удерживающее. Метрика изменит поведение системы, оставаясь корректно измеренной.
Человек, к которому раньше приходили за подсказкой, становится оператором, проверяющим спорные случаи. Формально та же зарплата и меньше рутины. Фактически экспертиза превратилась в обслуживание: раньше он решал, теперь подтверждает чужое решение.
Регистратор был мини-социальной сетью организации. Через него узнавали новости, выясняли, у кого лежит документ, договаривались в обход процедуры. Этот канал закрывается вместе с должностью — и закрывается для всех, а не только для него.
Стоит проговорить прямо: неформальный канал не был багом организации. Он был её несущей конструкцией. Значительная часть работы делалась потому, что кто-то кому-то сказал в коридоре.
Появляются новые. Раньше при просрочке было понятно, с кем разговаривать: документ отдал регистратор, значит, с ним и выяснять. Теперь маршрут выбрала система, срок сорвал человек, а виноватого нет. Спорить не с кем — и конфликт не исчезает, он просто перестаёт разрешаться.
Слово «жертва» здесь — аналитическая категория, а не моральная. Потерявший статус сотрудник может быть доволен зарплатой и всё равно проигрывать в другом измерении. Задача — назвать измерение точно.
Регистратор. Теряет экспертизу как ресурс: то, что он знал, больше не нужно и не конвертируется в новую роль.
Отделы-получатели. Теряют возможность договориться напрямую: маршрут теперь определяет порог, который настраивает ИТ-служба.
Отправитель документа. Теряет адресата для возражения: раньше можно было позвонить и попросить пересмотреть, теперь непонятно кому.
Организация в целом. Теряет неформальный канал, о существовании которого узнаёт только после его исчезновения.
Четвёртый пункт — самый недооценённый при подготовке бизнес-кейса. В расчёте выгоды его нет, потому что он не измерялся: у неформального канала не было ни бюджета, ни метрики.
У ИИ-канцелярии нет лица, имени и окна диалога. Она не здоровается и не предлагает помощь. Она заполняет поля и работает в фоне, а к человеку обращается тогда, когда сама не справилась, — то есть по коэффициенту уверенности.
Это тихий ИИ из недели 6 в производственной эксплуатации. И это существенно: обсуждать с руководством нечего — нет демонстрации, нет персонажа, нечего показать на совете директоров. Отсюда, кстати, известная трудность: тихие системы труднее продать внутри компании, чем говорящие, хотя пользы от них обычно больше. К этому вернёмся на воркшопе недели 12.
Четыре сюжета, которые повторяются от внедрения к внедрению.
Регламент описывает четыре шага из пяти. Автоматизируют по регламенту. Третий шаг — тот, где живёт экспертиза, — оказывается воспроизведён хуже всего, и именно он определяет качество.
Решение выглядит техническим, поэтому принимается там, где нет ни проверяющих, ни отправителей документов.
Регистратор возражает, старая база «не отдаёт данные», служба безопасности тормозит. Всё это читается как помеха. На деле это информация об архитектурном расхождении, которое не учли. К этому — ролевая игра недели 13.
Операционная выгода видна сразу и попадает в отчёт. Организационные, культурные и властные последствия проявляются позже и в отчёт не попадают, потому что для них нет графы.
Из четырёх сюжетов выберите тот, который кажется вам наиболее вероятным в вашем будущем проекте, и придумайте один вопрос, который вы зададите мне на семинаре.
Какая из пяти операций канцелярии не описана в регламенте и почему именно она?
Что конкретно знал регистратор такого, чего нет ни в одном документе?
Кому добавляет работы поднятие порога и кому — его снижение?
Чем ошибка последствия отличается от ошибки описания и кто исправляет каждую?
Почему ошибку категории невозможно увидеть в метриках?
Какой канал коммуникации закрылся вместе с должностью — и для кого?
Почему тихие системы труднее продать внутри компании, чем говорящие?
Кого в этом кейсе не спросили при проектировании?
Назовите две-три «жертвы» ИИ-канцелярии и опишите, что именно каждая теряет: роль, статус, доступ к информации, повод поговорить с коллегами, адресата для возражения. Работа не должна превратиться в обвинение работодателя — задача аналитическая: точно назвать измерение потери.
К воркшопу недели 12 принесите пример плохого корпоративного чат-бота: скриншот или описание.
Текст сознательно не содержит полевых деталей: они добавляются голосом на семинаре и работают тем сильнее, чем меньше их в раздатке. Держите в запасе три собственные истории провалов — они разгоняют дискуссию лучше любых уточняющих вопросов. Формат недели 11 работает только при активной аудитории, поэтому просите прийти с тремя написанными вопросами и начинайте занятие со сбора этих вопросов, а не с рассказа.