Бесплатный фрагмент - AI-автоматизация pro

PL • AI PRO SERIES • КНИГА 5

AI-АВТОМАТИЗАЦИЯ PRO

Как построить процессы, которые работают с помощью искусственного интеллекта

PL

Русское издание • 2026

От автора

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

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

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

Как пользоваться этой книгой

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

Если опыт уже есть, возьмите один реальный процесс — заявки, контент, документы, продажи или поддержку — и пропускайте его через вопросы каждой главы. Не пытайтесь одновременно автоматизировать весь бизнес.

Мы намеренно не строим книгу вокруг одного сервиса. Инструменты меняются быстрее, чем процессы. Поэтому основой будут триггеры, данные, действия, Human Gate, проверки, исключения и экономика.

Введение. Автоматизация начинается не с AI

Самая распространённая ошибка выглядит безобидно: человек видит новую технологию и начинает искать, куда её встроить. Получается вопрос: «Что я могу автоматизировать с помощью AI?» Гораздо полезнее другой: «Какой процесс сейчас забирает слишком много времени, денег или внимания — и почему?»

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

Рабочая формула книги: ТРИГГЕР → КОНТЕКСТ → AI → РЕШЕНИЕ → ДЕЙСТВИЕ → ПРОВЕРКА → HUMAN GATE → РЕЗУЛЬТАТ. Эта цепочка превращает набор соединённых приложений в управляемую систему.

Часть I. Автоматизация начинается не с AI

Глава 1. Что на самом деле означает автоматизировать процесс

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

Сначала определите начало, конец, владельца и ожидаемый результат. AI имеет смысл добавлять только там, где он уменьшает реальную стоимость или задержку.

Практика. Опишите процесс формулой «Когда происходит X, мы делаем Y, чтобы получить Z».

Разбор на практике

Представим служба доставки, где нужно улучшить процесс «обработка новых заказов». Тема этой главы — «Что на самом деле означает автоматизировать процесс» — становится полезной только тогда, когда её можно связать с конкретным решением. Поэтому сначала фиксируем исходное состояние: кто начинает процесс, какие данные получает, сколько ручных действий выполняет, где ждёт ответа и по какому признаку считает работу законченной. Такая карта быстро показывает, где действительно нужен AI, а где достаточно убрать лишний шаг или ввести простое правило.

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

Пример «до и после»

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

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

Что может пойти не так

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

Алгоритм внедрения

1. Сформулируйте результат главы «Что на самом деле означает автоматизировать процесс» как наблюдаемое изменение, а не как установку нового инструмента.

2. Возьмите 20—30 реальных примеров из процесса «обработка новых заказов» и разделите их на обычные, пограничные и ошибочные.

3. Зафиксируйте Source of Truth: откуда берутся факты, которые система не имеет права придумывать.

4. Определите Human Gate: при каких условиях человек обязательно видит результат до внешнего действия.

5. Запустите ограниченный пилот и сравните его с исходной точкой по времени цикла, ручным касаниям, ошибкам и числу исключений.

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

Мини-кейс

Допустим, в служба доставки операция выполняется 40 раз в день и занимает в среднем 8 минут. Это более пяти часов ручной работы ежедневно. После пилота автоматизация сокращает подготовительную часть до двух минут, но 15% случаев всё ещё отправляет человеку из-за исключений. Даже такой результат может быть сильнее полной автономии: команда экономит значительную часть времени, а сложные ситуации не скрываются. Именно так следует оценивать зрелость системы — по полезному перераспределению работы, а не по проценту действий, совершённых без человека.

Вопрос для самопроверки: можете ли вы одним абзацем объяснить, какие решения в этом процессе принимает правило, какие — AI, какие — человек и что произойдёт при нехватке данных? Если нет, схему стоит упростить до запуска.

Глава 2. Не автоматизируйте хаос

Плохой процесс после автоматизации часто становится просто более быстрым плохим процессом. Разрозненные каналы, неизвестные ответственные и непонятные статусы сначала нужно упорядочить.

Автоматизация должна уменьшать неопределённость. Если после внедрения процесс труднее объяснить сотруднику, архитектура, скорее всего, перегружена.

Практика. Отметьте места, где люди сейчас действуют «как получится».

Разбор на практике

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

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

Пример «до и после»

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

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

Что может пойти не так

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

Алгоритм внедрения

1. Сформулируйте результат главы «Не автоматизируйте хаос» как наблюдаемое изменение, а не как установку нового инструмента.

2. Возьмите 20—30 реальных примеров из процесса «распределение входящих задач» и разделите их на обычные, пограничные и ошибочные.

3. Зафиксируйте Source of Truth: откуда берутся факты, которые система не имеет права придумывать.

4. Определите Human Gate: при каких условиях человек обязательно видит результат до внешнего действия.

5. Запустите ограниченный пилот и сравните его с исходной точкой по времени цикла, ручным касаниям, ошибкам и числу исключений.

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

Мини-кейс

Допустим, в небольшое агентство операция выполняется 40 раз в день и занимает в среднем 8 минут. Это более пяти часов ручной работы ежедневно. После пилота автоматизация сокращает подготовительную часть до двух минут, но 15% случаев всё ещё отправляет человеку из-за исключений. Даже такой результат может быть сильнее полной автономии: команда экономит значительную часть времени, а сложные ситуации не скрываются. Именно так следует оценивать зрелость системы — по полезному перераспределению работы, а не по проценту действий, совершённых без человека.

Вопрос для самопроверки: можете ли вы одним абзацем объяснить, какие решения в этом процессе принимает правило, какие — AI, какие — человек и что произойдёт при нехватке данных? Если нет, схему стоит упростить до запуска.

Глава 3. Ищем дорогую рутину

Не вся рутина заслуживает автоматизации. Ищите сочетание частоты, времени, ошибок и последствий задержки.

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

Практика. Для трёх процессов посчитайте частоту и время одного выполнения.

Разбор на практике

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

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

Пример «до и после»

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

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

Что может пойти не так

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

Алгоритм внедрения

1. Сформулируйте результат главы «Ищем дорогую рутину» как наблюдаемое изменение, а не как установку нового инструмента.

2. Возьмите 20—30 реальных примеров из процесса «работа с обращениями покупателей» и разделите их на обычные, пограничные и ошибочные.

3. Зафиксируйте Source of Truth: откуда берутся факты, которые система не имеет права придумывать.

4. Определите Human Gate: при каких условиях человек обязательно видит результат до внешнего действия.

5. Запустите ограниченный пилот и сравните его с исходной точкой по времени цикла, ручным касаниям, ошибкам и числу исключений.

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

Мини-кейс

Допустим, в интернет-магазин операция выполняется 40 раз в день и занимает в среднем 8 минут. Это более пяти часов ручной работы ежедневно. После пилота автоматизация сокращает подготовительную часть до двух минут, но 15% случаев всё ещё отправляет человеку из-за исключений. Даже такой результат может быть сильнее полной автономии: команда экономит значительную часть времени, а сложные ситуации не скрываются. Именно так следует оценивать зрелость системы — по полезному перераспределению работы, а не по проценту действий, совершённых без человека.

Вопрос для самопроверки: можете ли вы одним абзацем объяснить, какие решения в этом процессе принимает правило, какие — AI, какие — человек и что произойдёт при нехватке данных? Если нет, схему стоит упростить до запуска.

Глава 4. Повторяемость важнее модности

Повторяемость создаёт экономику автоматизации. Один раз настроенная система должна приносить пользу много раз.

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

Практика. Отсортируйте процессы по количеству повторений в месяц.

Разбор на практике

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

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

Пример «до и после»

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

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

Что может пойти не так

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

Алгоритм внедрения

1. Сформулируйте результат главы «Повторяемость важнее модности» как наблюдаемое изменение, а не как установку нового инструмента.

2. Возьмите 20—30 реальных примеров из процесса «обработка новых заказов» и разделите их на обычные, пограничные и ошибочные.

3. Зафиксируйте Source of Truth: откуда берутся факты, которые система не имеет права придумывать.

4. Определите Human Gate: при каких условиях человек обязательно видит результат до внешнего действия.

5. Запустите ограниченный пилот и сравните его с исходной точкой по времени цикла, ручным касаниям, ошибкам и числу исключений.

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

Мини-кейс

Допустим, в служба доставки операция выполняется 40 раз в день и занимает в среднем 8 минут. Это более пяти часов ручной работы ежедневно. После пилота автоматизация сокращает подготовительную часть до двух минут, но 15% случаев всё ещё отправляет человеку из-за исключений. Даже такой результат может быть сильнее полной автономии: команда экономит значительную часть времени, а сложные ситуации не скрываются. Именно так следует оценивать зрелость системы — по полезному перераспределению работы, а не по проценту действий, совершённых без человека.

Вопрос для самопроверки: можете ли вы одним абзацем объяснить, какие решения в этом процессе принимает правило, какие — AI, какие — человек и что произойдёт при нехватке данных? Если нет, схему стоит упростить до запуска.

Глава 5. Где AI нужен, а где достаточно обычного правила

Однозначное условие лучше реализовать обычным правилом. Генеративный AI нужен там, где требуется интерпретация текста, документа или неоднозначного контекста.

Сильная архитектура сочетает правила, AI и человека, не заставляя модель решать то, что надёжно решается логикой.

Практика. Пометьте каждый шаг как «правило», «AI» или «человек».

Разбор на практике

Представим небольшое агентство, где нужно улучшить процесс «распределение входящих задач». Тема этой главы — «Где AI нужен, а где достаточно обычного правила» — становится полезной только тогда, когда её можно связать с конкретным решением. Поэтому сначала фиксируем исходное состояние: кто начинает процесс, какие данные получает, сколько ручных действий выполняет, где ждёт ответа и по какому признаку считает работу законченной. Такая карта быстро показывает, где действительно нужен AI, а где достаточно убрать лишний шаг или ввести простое правило.

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

Пример «до и после»

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

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

Что может пойти не так

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

Алгоритм внедрения

1. Сформулируйте результат главы «Где AI нужен, а где достаточно обычного правила» как наблюдаемое изменение, а не как установку нового инструмента.

2. Возьмите 20—30 реальных примеров из процесса «распределение входящих задач» и разделите их на обычные, пограничные и ошибочные.

3. Зафиксируйте Source of Truth: откуда берутся факты, которые система не имеет права придумывать.

4. Определите Human Gate: при каких условиях человек обязательно видит результат до внешнего действия.

5. Запустите ограниченный пилот и сравните его с исходной точкой по времени цикла, ручным касаниям, ошибкам и числу исключений.

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

Мини-кейс

Допустим, в небольшое агентство операция выполняется 40 раз в день и занимает в среднем 8 минут. Это более пяти часов ручной работы ежедневно. После пилота автоматизация сокращает подготовительную часть до двух минут, но 15% случаев всё ещё отправляет человеку из-за исключений. Даже такой результат может быть сильнее полной автономии: команда экономит значительную часть времени, а сложные ситуации не скрываются. Именно так следует оценивать зрелость системы — по полезному перераспределению работы, а не по проценту действий, совершённых без человека.

Вопрос для самопроверки: можете ли вы одним абзацем объяснить, какие решения в этом процессе принимает правило, какие — AI, какие — человек и что произойдёт при нехватке данных? Если нет, схему стоит упростить до запуска.

Глава 6. Цена ручного процесса

До изменений нужна исходная точка: время, стоимость, задержка и ошибки. Иначе невозможно доказать пользу.

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

Практика. Неделю измеряйте выбранный процесс до автоматизации.

Разбор на практике

Представим интернет-магазин, где нужно улучшить процесс «работа с обращениями покупателей». Тема этой главы — «Цена ручного процесса» — становится полезной только тогда, когда её можно связать с конкретным решением. Поэтому сначала фиксируем исходное состояние: кто начинает процесс, какие данные получает, сколько ручных действий выполняет, где ждёт ответа и по какому признаку считает работу законченной. Такая карта быстро показывает, где действительно нужен AI, а где достаточно убрать лишний шаг или ввести простое правило.

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

Пример «до и после»

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

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

Что может пойти не так

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

Алгоритм внедрения

1. Сформулируйте результат главы «Цена ручного процесса» как наблюдаемое изменение, а не как установку нового инструмента.

2. Возьмите 20—30 реальных примеров из процесса «работа с обращениями покупателей» и разделите их на обычные, пограничные и ошибочные.

3. Зафиксируйте Source of Truth: откуда берутся факты, которые система не имеет права придумывать.

4. Определите Human Gate: при каких условиях человек обязательно видит результат до внешнего действия.

5. Запустите ограниченный пилот и сравните его с исходной точкой по времени цикла, ручным касаниям, ошибкам и числу исключений.

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

Мини-кейс

Допустим, в интернет-магазин операция выполняется 40 раз в день и занимает в среднем 8 минут. Это более пяти часов ручной работы ежедневно. После пилота автоматизация сокращает подготовительную часть до двух минут, но 15% случаев всё ещё отправляет человеку из-за исключений. Даже такой результат может быть сильнее полной автономии: команда экономит значительную часть времени, а сложные ситуации не скрываются. Именно так следует оценивать зрелость системы — по полезному перераспределению работы, а не по проценту действий, совершённых без человека.

Вопрос для самопроверки: можете ли вы одним абзацем объяснить, какие решения в этом процессе принимает правило, какие — AI, какие — человек и что произойдёт при нехватке данных? Если нет, схему стоит упростить до запуска.

Глава 7. Что нельзя отдавать системе без контроля

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

Human Gate — это элемент хорошего дизайна, а не признак слабой автоматизации.

Практика. Поставьте Human Gate перед труднообратимыми действиями.

Разбор на практике

Представим служба доставки, где нужно улучшить процесс «обработка новых заказов». Тема этой главы — «Что нельзя отдавать системе без контроля» — становится полезной только тогда, когда её можно связать с конкретным решением. Поэтому сначала фиксируем исходное состояние: кто начинает процесс, какие данные получает, сколько ручных действий выполняет, где ждёт ответа и по какому признаку считает работу законченной. Такая карта быстро показывает, где действительно нужен AI, а где достаточно убрать лишний шаг или ввести простое правило.

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

Пример «до и после»

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

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

Что может пойти не так

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

Алгоритм внедрения

1. Сформулируйте результат главы «Что нельзя отдавать системе без контроля» как наблюдаемое изменение, а не как установку нового инструмента.

2. Возьмите 20—30 реальных примеров из процесса «обработка новых заказов» и разделите их на обычные, пограничные и ошибочные.

3. Зафиксируйте Source of Truth: откуда берутся факты, которые система не имеет права придумывать.

4. Определите Human Gate: при каких условиях человек обязательно видит результат до внешнего действия.

5. Запустите ограниченный пилот и сравните его с исходной точкой по времени цикла, ручным касаниям, ошибкам и числу исключений.

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

Мини-кейс

Допустим, в служба доставки операция выполняется 40 раз в день и занимает в среднем 8 минут. Это более пяти часов ручной работы ежедневно. После пилота автоматизация сокращает подготовительную часть до двух минут, но 15% случаев всё ещё отправляет человеку из-за исключений. Даже такой результат может быть сильнее полной автономии: команда экономит значительную часть времени, а сложные ситуации не скрываются. Именно так следует оценивать зрелость системы — по полезному перераспределению работы, а не по проценту действий, совершённых без человека.

Вопрос для самопроверки: можете ли вы одним абзацем объяснить, какие решения в этом процессе принимает правило, какие — AI, какие — человек и что произойдёт при нехватке данных? Если нет, схему стоит упростить до запуска.

Глава 8. Автоматизация и ответственность

Фраза «это сделал AI» не снимает ответственность. У процесса должен быть владелец, который понимает цель, правила и действия при сбое.

Также должна быть понятна история решения: какие данные использовались и что произошло дальше.

Практика. Назначьте владельца процесса и технической системы.

Разбор на практике

Представим небольшое агентство, где нужно улучшить процесс «распределение входящих задач». Тема этой главы — «Автоматизация и ответственность» — становится полезной только тогда, когда её можно связать с конкретным решением. Поэтому сначала фиксируем исходное состояние: кто начинает процесс, какие данные получает, сколько ручных действий выполняет, где ждёт ответа и по какому признаку считает работу законченной. Такая карта быстро показывает, где действительно нужен AI, а где достаточно убрать лишний шаг или ввести простое правило.

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

Пример «до и после»

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

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

Что может пойти не так

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

Алгоритм внедрения

1. Сформулируйте результат главы «Автоматизация и ответственность» как наблюдаемое изменение, а не как установку нового инструмента.

2. Возьмите 20—30 реальных примеров из процесса «распределение входящих задач» и разделите их на обычные, пограничные и ошибочные.

3. Зафиксируйте Source of Truth: откуда берутся факты, которые система не имеет права придумывать.

4. Определите Human Gate: при каких условиях человек обязательно видит результат до внешнего действия.

5. Запустите ограниченный пилот и сравните его с исходной точкой по времени цикла, ручным касаниям, ошибкам и числу исключений.

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

Мини-кейс

Допустим, в небольшое агентство операция выполняется 40 раз в день и занимает в среднем 8 минут. Это более пяти часов ручной работы ежедневно. После пилота автоматизация сокращает подготовительную часть до двух минут, но 15% случаев всё ещё отправляет человеку из-за исключений. Даже такой результат может быть сильнее полной автономии: команда экономит значительную часть времени, а сложные ситуации не скрываются. Именно так следует оценивать зрелость системы — по полезному перераспределению работы, а не по проценту действий, совершённых без человека.

Вопрос для самопроверки: можете ли вы одним абзацем объяснить, какие решения в этом процессе принимает правило, какие — AI, какие — человек и что произойдёт при нехватке данных? Если нет, схему стоит упростить до запуска.

Глава 9. Маленькая автоматизация против большого проекта

Большой проект создаёт слишком много неизвестных. Маленький законченный контур быстрее даёт реальные данные.

Например: заявка → классификация → черновик → проверка → запись результата. После такого пилота масштабирование становится осмысленным.

Практика. Сократите первую автоматизацию до теста на несколько дней.

Разбор на практике

Представим интернет-магазин, где нужно улучшить процесс «работа с обращениями покупателей». Тема этой главы — «Маленькая автоматизация против большого проекта» — становится полезной только тогда, когда её можно связать с конкретным решением. Поэтому сначала фиксируем исходное состояние: кто начинает процесс, какие данные получает, сколько ручных действий выполняет, где ждёт ответа и по какому признаку считает работу законченной. Такая карта быстро показывает, где действительно нужен AI, а где достаточно убрать лишний шаг или ввести простое правило.

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

Пример «до и после»

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

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

Что может пойти не так

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

Алгоритм внедрения

1. Сформулируйте результат главы «Маленькая автоматизация против большого проекта» как наблюдаемое изменение, а не как установку нового инструмента.

2. Возьмите 20—30 реальных примеров из процесса «работа с обращениями покупателей» и разделите их на обычные, пограничные и ошибочные.

3. Зафиксируйте Source of Truth: откуда берутся факты, которые система не имеет права придумывать.

4. Определите Human Gate: при каких условиях человек обязательно видит результат до внешнего действия.

5. Запустите ограниченный пилот и сравните его с исходной точкой по времени цикла, ручным касаниям, ошибкам и числу исключений.

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

Мини-кейс

Допустим, в интернет-магазин операция выполняется 40 раз в день и занимает в среднем 8 минут. Это более пяти часов ручной работы ежедневно. После пилота автоматизация сокращает подготовительную часть до двух минут, но 15% случаев всё ещё отправляет человеку из-за исключений. Даже такой результат может быть сильнее полной автономии: команда экономит значительную часть времени, а сложные ситуации не скрываются. Именно так следует оценивать зрелость системы — по полезному перераспределению работы, а не по проценту действий, совершённых без человека.

Вопрос для самопроверки: можете ли вы одним абзацем объяснить, какие решения в этом процессе принимает правило, какие — AI, какие — человек и что произойдёт при нехватке данных? Если нет, схему стоит упростить до запуска.

Глава 10. Карта возможностей автоматизации

Карта возможностей делит процессы на четыре группы: оставить человеку, упростить правилом, усилить AI, автоматизировать цепочкой.

Иногда лучший результат — удалить ненужный шаг, а не автоматизировать его.

Практика. Распределите 15 процессов по четырём группам.

Разбор на практике

Представим служба доставки, где нужно улучшить процесс «обработка новых заказов». Тема этой главы — «Карта возможностей автоматизации» — становится полезной только тогда, когда её можно связать с конкретным решением. Поэтому сначала фиксируем исходное состояние: кто начинает процесс, какие данные получает, сколько ручных действий выполняет, где ждёт ответа и по какому признаку считает работу законченной. Такая карта быстро показывает, где действительно нужен AI, а где достаточно убрать лишний шаг или ввести простое правило.

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

Пример «до и после»

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

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

Что может пойти не так

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

Алгоритм внедрения

1. Сформулируйте результат главы «Карта возможностей автоматизации» как наблюдаемое изменение, а не как установку нового инструмента.

2. Возьмите 20—30 реальных примеров из процесса «обработка новых заказов» и разделите их на обычные, пограничные и ошибочные.

3. Зафиксируйте Source of Truth: откуда берутся факты, которые система не имеет права придумывать.

4. Определите Human Gate: при каких условиях человек обязательно видит результат до внешнего действия.

5. Запустите ограниченный пилот и сравните его с исходной точкой по времени цикла, ручным касаниям, ошибкам и числу исключений.

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

Мини-кейс

Допустим, в служба доставки операция выполняется 40 раз в день и занимает в среднем 8 минут. Это более пяти часов ручной работы ежедневно. После пилота автоматизация сокращает подготовительную часть до двух минут, но 15% случаев всё ещё отправляет человеку из-за исключений. Даже такой результат может быть сильнее полной автономии: команда экономит значительную часть времени, а сложные ситуации не скрываются. Именно так следует оценивать зрелость системы — по полезному перераспределению работы, а не по проценту действий, совершённых без человека.

Вопрос для самопроверки: можете ли вы одним абзацем объяснить, какие решения в этом процессе принимает правило, какие — AI, какие — человек и что произойдёт при нехватке данных? Если нет, схему стоит упростить до запуска.

Часть II. Архитектура надёжной AI-автоматизации

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

Глава 11. Триггер: что запускает систему

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

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

Практика. Опишите событие запуска и условие, при котором его нужно проигнорировать.

Разбор на практике

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

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

Пример «до и после»

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

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

Что может пойти не так

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

Алгоритм внедрения

1. Сформулируйте результат главы «Триггер: что запускает систему» как наблюдаемое изменение, а не как установку нового инструмента.

2. Возьмите 20—30 реальных примеров из процесса «передача лида между этапами» и разделите их на обычные, пограничные и ошибочные.

3. Зафиксируйте Source of Truth: откуда берутся факты, которые система не имеет права придумывать.

4. Определите Human Gate: при каких условиях человек обязательно видит результат до внешнего действия.

5. Запустите ограниченный пилот и сравните его с исходной точкой по времени цикла, ручным касаниям, ошибкам и числу исключений.

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

Мини-кейс

Допустим, в отдел продаж операция выполняется 40 раз в день и занимает в среднем 8 минут. Это более пяти часов ручной работы ежедневно. После пилота автоматизация сокращает подготовительную часть до двух минут, но 15% случаев всё ещё отправляет человеку из-за исключений. Даже такой результат может быть сильнее полной автономии: команда экономит значительную часть времени, а сложные ситуации не скрываются. Именно так следует оценивать зрелость системы — по полезному перераспределению работы, а не по проценту действий, совершённых без человека.

Вопрос для самопроверки: можете ли вы одним абзацем объяснить, какие решения в этом процессе принимает правило, какие — AI, какие — человек и что произойдёт при нехватке данных? Если нет, схему стоит упростить до запуска.

Глава 12. Входные данные и обязательные поля

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

Чем лучше устроен вход, тем меньше дорогих исправлений дальше по цепочке.

Практика. Разделите поля на обязательные, желательные и необязательные.

Разбор на практике

Представим экспертный проект, где нужно улучшить процесс «обработка запроса на консультацию». Тема этой главы — «Входные данные и обязательные поля» — становится полезной только тогда, когда её можно связать с конкретным решением. Поэтому сначала фиксируем исходное состояние: кто начинает процесс, какие данные получает, сколько ручных действий выполняет, где ждёт ответа и по какому признаку считает работу законченной. Такая карта быстро показывает, где действительно нужен AI, а где достаточно убрать лишний шаг или ввести простое правило.

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

Пример «до и после»

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

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

Что может пойти не так

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

Алгоритм внедрения

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

2. Возьмите 20—30 реальных примеров из процесса «обработка запроса на консультацию» и разделите их на обычные, пограничные и ошибочные.

3. Зафиксируйте Source of Truth: откуда берутся факты, которые система не имеет права придумывать.

4. Определите Human Gate: при каких условиях человек обязательно видит результат до внешнего действия.

5. Запустите ограниченный пилот и сравните его с исходной точкой по времени цикла, ручным касаниям, ошибкам и числу исключений.

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

Мини-кейс

Допустим, в экспертный проект операция выполняется 40 раз в день и занимает в среднем 8 минут. Это более пяти часов ручной работы ежедневно. После пилота автоматизация сокращает подготовительную часть до двух минут, но 15% случаев всё ещё отправляет человеку из-за исключений. Даже такой результат может быть сильнее полной автономии: команда экономит значительную часть времени, а сложные ситуации не скрываются. Именно так следует оценивать зрелость системы — по полезному перераспределению работы, а не по проценту действий, совершённых без человека.

Вопрос для самопроверки: можете ли вы одним абзацем объяснить, какие решения в этом процессе принимает правило, какие — AI, какие — человек и что произойдёт при нехватке данных? Если нет, схему стоит упростить до запуска.

Глава 13. Контекст перед запросом к AI

Модель работает только с контекстом конкретного запуска. Поэтому важные факты должны приходить из проверяемых источников.

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

Практика. Запишите факты, которые AI обязан получать каждый раз.

Разбор на практике

Представим сервисная компания, где нужно улучшить процесс «маршрут заявки от формы до исполнителя». Тема этой главы — «Контекст перед запросом к AI» — становится полезной только тогда, когда её можно связать с конкретным решением. Поэтому сначала фиксируем исходное состояние: кто начинает процесс, какие данные получает, сколько ручных действий выполняет, где ждёт ответа и по какому признаку считает работу законченной. Такая карта быстро показывает, где действительно нужен AI, а где достаточно убрать лишний шаг или ввести простое правило.

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

Пример «до и после»

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

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

Что может пойти не так

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

Алгоритм внедрения

1. Сформулируйте результат главы «Контекст перед запросом к AI» как наблюдаемое изменение, а не как установку нового инструмента.

2. Возьмите 20—30 реальных примеров из процесса «маршрут заявки от формы до исполнителя» и разделите их на обычные, пограничные и ошибочные.

3. Зафиксируйте Source of Truth: откуда берутся факты, которые система не имеет права придумывать.

4. Определите Human Gate: при каких условиях человек обязательно видит результат до внешнего действия.

5. Запустите ограниченный пилот и сравните его с исходной точкой по времени цикла, ручным касаниям, ошибкам и числу исключений.

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

Мини-кейс

Допустим, в сервисная компания операция выполняется 40 раз в день и занимает в среднем 8 минут. Это более пяти часов ручной работы ежедневно. После пилота автоматизация сокращает подготовительную часть до двух минут, но 15% случаев всё ещё отправляет человеку из-за исключений. Даже такой результат может быть сильнее полной автономии: команда экономит значительную часть времени, а сложные ситуации не скрываются. Именно так следует оценивать зрелость системы — по полезному перераспределению работы, а не по проценту действий, совершённых без человека.

Вопрос для самопроверки: можете ли вы одним абзацем объяснить, какие решения в этом процессе принимает правило, какие — AI, какие — человек и что произойдёт при нехватке данных? Если нет, схему стоит упростить до запуска.

Глава 14. Решение и уровень уверенности

AI может ошибаться и сомневаться, поэтому не каждое решение должно немедленно становиться действием.

Полезно предусмотреть состояние «не уверен» и безопасную передачу человеку.

Практика. Добавьте маршрут для неоднозначных случаев.

Разбор на практике

Представим отдел продаж, где нужно улучшить процесс «передача лида между этапами». Тема этой главы — «Решение и уровень уверенности» — становится полезной только тогда, когда её можно связать с конкретным решением. Поэтому сначала фиксируем исходное состояние: кто начинает процесс, какие данные получает, сколько ручных действий выполняет, где ждёт ответа и по какому признаку считает работу законченной. Такая карта быстро показывает, где действительно нужен AI, а где достаточно убрать лишний шаг или ввести простое правило.

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

Пример «до и после»

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

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

Что может пойти не так

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

Алгоритм внедрения

1. Сформулируйте результат главы «Решение и уровень уверенности» как наблюдаемое изменение, а не как установку нового инструмента.

2. Возьмите 20—30 реальных примеров из процесса «передача лида между этапами» и разделите их на обычные, пограничные и ошибочные.

3. Зафиксируйте Source of Truth: откуда берутся факты, которые система не имеет права придумывать.

4. Определите Human Gate: при каких условиях человек обязательно видит результат до внешнего действия.

5. Запустите ограниченный пилот и сравните его с исходной точкой по времени цикла, ручным касаниям, ошибкам и числу исключений.

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

Мини-кейс

Допустим, в отдел продаж операция выполняется 40 раз в день и занимает в среднем 8 минут. Это более пяти часов ручной работы ежедневно. После пилота автоматизация сокращает подготовительную часть до двух минут, но 15% случаев всё ещё отправляет человеку из-за исключений. Даже такой результат может быть сильнее полной автономии: команда экономит значительную часть времени, а сложные ситуации не скрываются. Именно так следует оценивать зрелость системы — по полезному перераспределению работы, а не по проценту действий, совершённых без человека.

Вопрос для самопроверки: можете ли вы одним абзацем объяснить, какие решения в этом процессе принимает правило, какие — AI, какие — человек и что произойдёт при нехватке данных? Если нет, схему стоит упростить до запуска.

Глава 15. Действие: обратимое и необратимое

Создать черновик и отправить его клиенту — разные уровни риска.

Архитектура должна различать подготовку действия и фактическое выполнение.

Практика. Разделите действия на обратимые и труднообратимые.

Разбор на практике

Представим экспертный проект, где нужно улучшить процесс «обработка запроса на консультацию». Тема этой главы — «Действие: обратимое и необратимое» — становится полезной только тогда, когда её можно связать с конкретным решением. Поэтому сначала фиксируем исходное состояние: кто начинает процесс, какие данные получает, сколько ручных действий выполняет, где ждёт ответа и по какому признаку считает работу законченной. Такая карта быстро показывает, где действительно нужен AI, а где достаточно убрать лишний шаг или ввести простое правило.

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

Пример «до и после»

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

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

Что может пойти не так

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

Алгоритм внедрения

1. Сформулируйте результат главы «Действие: обратимое и необратимое» как наблюдаемое изменение, а не как установку нового инструмента.

2. Возьмите 20—30 реальных примеров из процесса «обработка запроса на консультацию» и разделите их на обычные, пограничные и ошибочные.

3. Зафиксируйте Source of Truth: откуда берутся факты, которые система не имеет права придумывать.

4. Определите Human Gate: при каких условиях человек обязательно видит результат до внешнего действия.

5. Запустите ограниченный пилот и сравните его с исходной точкой по времени цикла, ручным касаниям, ошибкам и числу исключений.

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

Мини-кейс

Допустим, в экспертный проект операция выполняется 40 раз в день и занимает в среднем 8 минут. Это более пяти часов ручной работы ежедневно. После пилота автоматизация сокращает подготовительную часть до двух минут, но 15% случаев всё ещё отправляет человеку из-за исключений. Даже такой результат может быть сильнее полной автономии: команда экономит значительную часть времени, а сложные ситуации не скрываются. Именно так следует оценивать зрелость системы — по полезному перераспределению работы, а не по проценту действий, совершённых без человека.

Вопрос для самопроверки: можете ли вы одним абзацем объяснить, какие решения в этом процессе принимает правило, какие — AI, какие — человек и что произойдёт при нехватке данных? Если нет, схему стоит упростить до запуска.

Глава 16. Проверка результата

Технически успешный запуск не гарантирует бизнес-результат.

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

Практика. Определите проверку после каждого критического действия.

Разбор на практике

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

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

Пример «до и после»

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

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

Что может пойти не так

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

Алгоритм внедрения

1. Сформулируйте результат главы «Проверка результата» как наблюдаемое изменение, а не как установку нового инструмента.

2. Возьмите 20—30 реальных примеров из процесса «маршрут заявки от формы до исполнителя» и разделите их на обычные, пограничные и ошибочные.

3. Зафиксируйте Source of Truth: откуда берутся факты, которые система не имеет права придумывать.

4. Определите Human Gate: при каких условиях человек обязательно видит результат до внешнего действия.

5. Запустите ограниченный пилот и сравните его с исходной точкой по времени цикла, ручным касаниям, ошибкам и числу исключений.

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

Мини-кейс

Допустим, в сервисная компания операция выполняется 40 раз в день и занимает в среднем 8 минут. Это более пяти часов ручной работы ежедневно. После пилота автоматизация сокращает подготовительную часть до двух минут, но 15% случаев всё ещё отправляет человеку из-за исключений. Даже такой результат может быть сильнее полной автономии: команда экономит значительную часть времени, а сложные ситуации не скрываются. Именно так следует оценивать зрелость системы — по полезному перераспределению работы, а не по проценту действий, совершённых без человека.

Вопрос для самопроверки: можете ли вы одним абзацем объяснить, какие решения в этом процессе принимает правило, какие — AI, какие — человек и что произойдёт при нехватке данных? Если нет, схему стоит упростить до запуска.

Глава 17. Human Gate как часть дизайна

Human Gate концентрирует человеческое внимание там, где цена ошибки или неопределённость высоки.

Он особенно полезен для внешних коммуникаций, денег, обязательств и исключений.

Практика. Укажите критерии обязательной остановки.

Разбор на практике

Представим отдел продаж, где нужно улучшить процесс «передача лида между этапами». Тема этой главы — «Human Gate как часть дизайна» — становится полезной только тогда, когда её можно связать с конкретным решением. Поэтому сначала фиксируем исходное состояние: кто начинает процесс, какие данные получает, сколько ручных действий выполняет, где ждёт ответа и по какому признаку считает работу законченной. Такая карта быстро показывает, где действительно нужен AI, а где достаточно убрать лишний шаг или ввести простое правило.

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

Пример «до и после»

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

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

Что может пойти не так

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

Алгоритм внедрения

1. Сформулируйте результат главы «Human Gate как часть дизайна» как наблюдаемое изменение, а не как установку нового инструмента.

2. Возьмите 20—30 реальных примеров из процесса «передача лида между этапами» и разделите их на обычные, пограничные и ошибочные.

3. Зафиксируйте Source of Truth: откуда берутся факты, которые система не имеет права придумывать.

4. Определите Human Gate: при каких условиях человек обязательно видит результат до внешнего действия.

5. Запустите ограниченный пилот и сравните его с исходной точкой по времени цикла, ручным касаниям, ошибкам и числу исключений.

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

Мини-кейс

Допустим, в отдел продаж операция выполняется 40 раз в день и занимает в среднем 8 минут. Это более пяти часов ручной работы ежедневно. После пилота автоматизация сокращает подготовительную часть до двух минут, но 15% случаев всё ещё отправляет человеку из-за исключений. Даже такой результат может быть сильнее полной автономии: команда экономит значительную часть времени, а сложные ситуации не скрываются. Именно так следует оценивать зрелость системы — по полезному перераспределению работы, а не по проценту действий, совершённых без человека.

Вопрос для самопроверки: можете ли вы одним абзацем объяснить, какие решения в этом процессе принимает правило, какие — AI, какие — человек и что произойдёт при нехватке данных? Если нет, схему стоит упростить до запуска.

Глава 18. Обработка ошибок

Сбои сети, пустые документы и недоступные сервисы неизбежны. Вопрос не в том, будут ли ошибки, а в том, что система сделает после них.

Нужны повтор, уведомление и ручной резервный маршрут.

Практика. Для трёх ошибок опишите поведение системы.

Разбор на практике

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

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

Пример «до и после»

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

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

Что может пойти не так

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

Алгоритм внедрения

1. Сформулируйте результат главы «Обработка ошибок» как наблюдаемое изменение, а не как установку нового инструмента.

2. Возьмите 20—30 реальных примеров из процесса «обработка запроса на консультацию» и разделите их на обычные, пограничные и ошибочные.

3. Зафиксируйте Source of Truth: откуда берутся факты, которые система не имеет права придумывать.

4. Определите Human Gate: при каких условиях человек обязательно видит результат до внешнего действия.

5. Запустите ограниченный пилот и сравните его с исходной точкой по времени цикла, ручным касаниям, ошибкам и числу исключений.

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

Мини-кейс

Допустим, в экспертный проект операция выполняется 40 раз в день и занимает в среднем 8 минут. Это более пяти часов ручной работы ежедневно. После пилота автоматизация сокращает подготовительную часть до двух минут, но 15% случаев всё ещё отправляет человеку из-за исключений. Даже такой результат может быть сильнее полной автономии: команда экономит значительную часть времени, а сложные ситуации не скрываются. Именно так следует оценивать зрелость системы — по полезному перераспределению работы, а не по проценту действий, совершённых без человека.

Вопрос для самопроверки: можете ли вы одним абзацем объяснить, какие решения в этом процессе принимает правило, какие — AI, какие — человек и что произойдёт при нехватке данных? Если нет, схему стоит упростить до запуска.

Глава 19. Логи и наблюдаемость

Без журнала событий трудно восстановить историю конкретной заявки.

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

Практика. Определите минимальный набор событий для журнала.

Разбор на практике

Представим сервисная компания, где нужно улучшить процесс «маршрут заявки от формы до исполнителя». Тема этой главы — «Логи и наблюдаемость» — становится полезной только тогда, когда её можно связать с конкретным решением. Поэтому сначала фиксируем исходное состояние: кто начинает процесс, какие данные получает, сколько ручных действий выполняет, где ждёт ответа и по какому признаку считает работу законченной. Такая карта быстро показывает, где действительно нужен AI, а где достаточно убрать лишний шаг или ввести простое правило.

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

Пример «до и после»

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

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

Что может пойти не так

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

Алгоритм внедрения

1. Сформулируйте результат главы «Логи и наблюдаемость» как наблюдаемое изменение, а не как установку нового инструмента.

2. Возьмите 20—30 реальных примеров из процесса «маршрут заявки от формы до исполнителя» и разделите их на обычные, пограничные и ошибочные.

3. Зафиксируйте Source of Truth: откуда берутся факты, которые система не имеет права придумывать.

4. Определите Human Gate: при каких условиях человек обязательно видит результат до внешнего действия.

5. Запустите ограниченный пилот и сравните его с исходной точкой по времени цикла, ручным касаниям, ошибкам и числу исключений.

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

Мини-кейс

Допустим, в сервисная компания операция выполняется 40 раз в день и занимает в среднем 8 минут. Это более пяти часов ручной работы ежедневно. После пилота автоматизация сокращает подготовительную часть до двух минут, но 15% случаев всё ещё отправляет человеку из-за исключений. Даже такой результат может быть сильнее полной автономии: команда экономит значительную часть времени, а сложные ситуации не скрываются. Именно так следует оценивать зрелость системы — по полезному перераспределению работы, а не по проценту действий, совершённых без человека.

Вопрос для самопроверки: можете ли вы одним абзацем объяснить, какие решения в этом процессе принимает правило, какие — AI, какие — человек и что произойдёт при нехватке данных? Если нет, схему стоит упростить до запуска.

Глава 20. Первая архитектура на одном листе

Первую архитектуру полезно уметь объяснить на одном листе без технического жаргона.

Если владелец бизнеса понимает маршрут за несколько минут, скрытой сложности обычно меньше.

Практика. Нарисуйте блоки: триггер, данные, AI, правило, человек, действие, проверка.

Разбор на практике

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

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

Пример «до и после»

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

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

Что может пойти не так

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

Алгоритм внедрения

1. Сформулируйте результат главы «Первая архитектура на одном листе» как наблюдаемое изменение, а не как установку нового инструмента.

2. Возьмите 20—30 реальных примеров из процесса «передача лида между этапами» и разделите их на обычные, пограничные и ошибочные.

3. Зафиксируйте Source of Truth: откуда берутся факты, которые система не имеет права придумывать.

4. Определите Human Gate: при каких условиях человек обязательно видит результат до внешнего действия.

5. Запустите ограниченный пилот и сравните его с исходной точкой по времени цикла, ручным касаниям, ошибкам и числу исключений.

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

Мини-кейс

Допустим, в отдел продаж операция выполняется 40 раз в день и занимает в среднем 8 минут. Это более пяти часов ручной работы ежедневно. После пилота автоматизация сокращает подготовительную часть до двух минут, но 15% случаев всё ещё отправляет человеку из-за исключений. Даже такой результат может быть сильнее полной автономии: команда экономит значительную часть времени, а сложные ситуации не скрываются. Именно так следует оценивать зрелость системы — по полезному перераспределению работы, а не по проценту действий, совершённых без человека.

Вопрос для самопроверки: можете ли вы одним абзацем объяснить, какие решения в этом процессе принимает правило, какие — AI, какие — человек и что произойдёт при нехватке данных? Если нет, схему стоит упростить до запуска.

Часть III. Данные, контекст и память системы

На этом этапе становится видно, что качество модели — лишь часть результата. Даже сильный AI будет ошибаться, если получает старые цены, противоречивые правила или лишний контекст. Следующие главы посвящены тому, чем именно мы «кормим» систему и что она должна помнить.

Глава 21. Источник истины

Цены, условия и правила должны поступать из утверждённого Source of Truth, а не из памяти модели.

Это снижает риск уверенных выдумок и упрощает обновление системы.

Практика. Назначьте авторитетный источник для каждого типа фактов.

Разбор на практике

Представим сервисный бизнес, где нужно улучшить процесс «база клиентов и история обращений». Тема этой главы — «Источник истины» — становится полезной только тогда, когда её можно связать с конкретным решением. Поэтому сначала фиксируем исходное состояние: кто начинает процесс, какие данные получает, сколько ручных действий выполняет, где ждёт ответа и по какому признаку считает работу законченной. Такая карта быстро показывает, где действительно нужен AI, а где достаточно убрать лишний шаг или ввести простое правило.

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

Пример «до и после»

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

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

Что может пойти не так

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

Алгоритм внедрения

1. Сформулируйте результат главы «Источник истины» как наблюдаемое изменение, а не как установку нового инструмента.

2. Возьмите 20—30 реальных примеров из процесса «база клиентов и история обращений» и разделите их на обычные, пограничные и ошибочные.

3. Зафиксируйте Source of Truth: откуда берутся факты, которые система не имеет права придумывать.

4. Определите Human Gate: при каких условиях человек обязательно видит результат до внешнего действия.

5. Запустите ограниченный пилот и сравните его с исходной точкой по времени цикла, ручным касаниям, ошибкам и числу исключений.

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

Мини-кейс

Допустим, в сервисный бизнес операция выполняется 40 раз в день и занимает в среднем 8 минут. Это более пяти часов ручной работы ежедневно. После пилота автоматизация сокращает подготовительную часть до двух минут, но 15% случаев всё ещё отправляет человеку из-за исключений. Даже такой результат может быть сильнее полной автономии: команда экономит значительную часть времени, а сложные ситуации не скрываются. Именно так следует оценивать зрелость системы — по полезному перераспределению работы, а не по проценту действий, совершённых без человека.

Вопрос для самопроверки: можете ли вы одним абзацем объяснить, какие решения в этом процессе принимает правило, какие — AI, какие — человек и что произойдёт при нехватке данных? Если нет, схему стоит упростить до запуска.

Глава 22. Почему плохие данные портят хорошую автоматизацию

Автоматизация масштабирует качество входных данных. Дубликаты и старые статусы превращаются в систематические ошибки.

Очистка данных иногда даёт больший эффект, чем новая модель.

Практика. Проверьте источник на дубли, пустые поля и устаревшие записи.

Разбор на практике

Представим оптовая компания, где нужно улучшить процесс «каталог товаров и цен». Тема этой главы — «Почему плохие данные портят хорошую автоматизацию» — становится полезной только тогда, когда её можно связать с конкретным решением. Поэтому сначала фиксируем исходное состояние: кто начинает процесс, какие данные получает, сколько ручных действий выполняет, где ждёт ответа и по какому признаку считает работу законченной. Такая карта быстро показывает, где действительно нужен AI, а где достаточно убрать лишний шаг или ввести простое правило.

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

Пример «до и после»

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

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

Что может пойти не так

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

Алгоритм внедрения

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

2. Возьмите 20—30 реальных примеров из процесса «каталог товаров и цен» и разделите их на обычные, пограничные и ошибочные.

3. Зафиксируйте Source of Truth: откуда берутся факты, которые система не имеет права придумывать.

4. Определите Human Gate: при каких условиях человек обязательно видит результат до внешнего действия.

5. Запустите ограниченный пилот и сравните его с исходной точкой по времени цикла, ручным касаниям, ошибкам и числу исключений.

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

Мини-кейс

Допустим, в оптовая компания операция выполняется 40 раз в день и занимает в среднем 8 минут. Это более пяти часов ручной работы ежедневно. После пилота автоматизация сокращает подготовительную часть до двух минут, но 15% случаев всё ещё отправляет человеку из-за исключений. Даже такой результат может быть сильнее полной автономии: команда экономит значительную часть времени, а сложные ситуации не скрываются. Именно так следует оценивать зрелость системы — по полезному перераспределению работы, а не по проценту действий, совершённых без человека.

Вопрос для самопроверки: можете ли вы одним абзацем объяснить, какие решения в этом процессе принимает правило, какие — AI, какие — человек и что произойдёт при нехватке данных? Если нет, схему стоит упростить до запуска.

Глава 23. Структурированные и неструктурированные данные

Свободный текст и структурированные поля требуют разной обработки. AI полезен как мост от человеческой формулировки к структуре.

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

Практика. Выберите три поля, которые можно извлекать из текста.

Разбор на практике

Представим онлайн-школа, где нужно улучшить процесс «карточки учеников и программы». Тема этой главы — «Структурированные и неструктурированные данные» — становится полезной только тогда, когда её можно связать с конкретным решением. Поэтому сначала фиксируем исходное состояние: кто начинает процесс, какие данные получает, сколько ручных действий выполняет, где ждёт ответа и по какому признаку считает работу законченной. Такая карта быстро показывает, где действительно нужен AI, а где достаточно убрать лишний шаг или ввести простое правило.

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

Пример «до и после»

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

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

Что может пойти не так

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

Алгоритм внедрения

1. Сформулируйте результат главы «Структурированные и неструктурированные данные» как наблюдаемое изменение, а не как установку нового инструмента.

2. Возьмите 20—30 реальных примеров из процесса «карточки учеников и программы» и разделите их на обычные, пограничные и ошибочные.

3. Зафиксируйте Source of Truth: откуда берутся факты, которые система не имеет права придумывать.

4. Определите Human Gate: при каких условиях человек обязательно видит результат до внешнего действия.

5. Запустите ограниченный пилот и сравните его с исходной точкой по времени цикла, ручным касаниям, ошибкам и числу исключений.

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

Мини-кейс

Допустим, в онлайн-школа операция выполняется 40 раз в день и занимает в среднем 8 минут. Это более пяти часов ручной работы ежедневно. После пилота автоматизация сокращает подготовительную часть до двух минут, но 15% случаев всё ещё отправляет человеку из-за исключений. Даже такой результат может быть сильнее полной автономии: команда экономит значительную часть времени, а сложные ситуации не скрываются. Именно так следует оценивать зрелость системы — по полезному перераспределению работы, а не по проценту действий, совершённых без человека.

Вопрос для самопроверки: можете ли вы одним абзацем объяснить, какие решения в этом процессе принимает правило, какие — AI, какие — человек и что произойдёт при нехватке данных? Если нет, схему стоит упростить до запуска.

Глава 24. Память процесса

Процессу нужен контекст предыдущих действий: что спрашивали, что уже отправляли и что согласовано.

Память должна хранить полезное состояние, а не бесконечную историю.

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

Разбор на практике

Представим сервисный бизнес, где нужно улучшить процесс «база клиентов и история обращений». Тема этой главы — «Память процесса» — становится полезной только тогда, когда её можно связать с конкретным решением. Поэтому сначала фиксируем исходное состояние: кто начинает процесс, какие данные получает, сколько ручных действий выполняет, где ждёт ответа и по какому признаку считает работу законченной. Такая карта быстро показывает, где действительно нужен AI, а где достаточно убрать лишний шаг или ввести простое правило.

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

Пример «до и после»

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

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

Что может пойти не так

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

Алгоритм внедрения

1. Сформулируйте результат главы «Память процесса» как наблюдаемое изменение, а не как установку нового инструмента.

2. Возьмите 20—30 реальных примеров из процесса «база клиентов и история обращений» и разделите их на обычные, пограничные и ошибочные.

3. Зафиксируйте Source of Truth: откуда берутся факты, которые система не имеет права придумывать.

4. Определите Human Gate: при каких условиях человек обязательно видит результат до внешнего действия.

5. Запустите ограниченный пилот и сравните его с исходной точкой по времени цикла, ручным касаниям, ошибкам и числу исключений.

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

Мини-кейс

Допустим, в сервисный бизнес операция выполняется 40 раз в день и занимает в среднем 8 минут. Это более пяти часов ручной работы ежедневно. После пилота автоматизация сокращает подготовительную часть до двух минут, но 15% случаев всё ещё отправляет человеку из-за исключений. Даже такой результат может быть сильнее полной автономии: команда экономит значительную часть времени, а сложные ситуации не скрываются. Именно так следует оценивать зрелость системы — по полезному перераспределению работы, а не по проценту действий, совершённых без человека.

Вопрос для самопроверки: можете ли вы одним абзацем объяснить, какие решения в этом процессе принимает правило, какие — AI, какие — человек и что произойдёт при нехватке данных? Если нет, схему стоит упростить до запуска.

Глава 25. Короткая память и долговременная база

Текущий диалог и постоянные сведения о клиенте — разные типы памяти.

Их смешивание создаёт ошибки и ненужное накопление данных.

Практика. Разделите временный контекст и долговременные сведения.

Разбор на практике

Представим оптовая компания, где нужно улучшить процесс «каталог товаров и цен». Тема этой главы — «Короткая память и долговременная база» — становится полезной только тогда, когда её можно связать с конкретным решением. Поэтому сначала фиксируем исходное состояние: кто начинает процесс, какие данные получает, сколько ручных действий выполняет, где ждёт ответа и по какому признаку считает работу законченной. Такая карта быстро показывает, где действительно нужен AI, а где достаточно убрать лишний шаг или ввести простое правило.

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

Пример «до и после»

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

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

Что может пойти не так

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

Алгоритм внедрения

1. Сформулируйте результат главы «Короткая память и долговременная база» как наблюдаемое изменение, а не как установку нового инструмента.

2. Возьмите 20—30 реальных примеров из процесса «каталог товаров и цен» и разделите их на обычные, пограничные и ошибочные.

3. Зафиксируйте Source of Truth: откуда берутся факты, которые система не имеет права придумывать.

4. Определите Human Gate: при каких условиях человек обязательно видит результат до внешнего действия.

5. Запустите ограниченный пилот и сравните его с исходной точкой по времени цикла, ручным касаниям, ошибкам и числу исключений.

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

Мини-кейс

Допустим, в оптовая компания операция выполняется 40 раз в день и занимает в среднем 8 минут. Это более пяти часов ручной работы ежедневно. После пилота автоматизация сокращает подготовительную часть до двух минут, но 15% случаев всё ещё отправляет человеку из-за исключений. Даже такой результат может быть сильнее полной автономии: команда экономит значительную часть времени, а сложные ситуации не скрываются. Именно так следует оценивать зрелость системы — по полезному перераспределению работы, а не по проценту действий, совершённых без человека.

Вопрос для самопроверки: можете ли вы одним абзацем объяснить, какие решения в этом процессе принимает правило, какие — AI, какие — человек и что произойдёт при нехватке данных? Если нет, схему стоит упростить до запуска.

Глава 26. Версии документов и правил

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

Версионность позволяет объяснить различия в результате и безопасно обновлять правила.

Практика. Добавьте дату или номер версии к ключевым источникам.

Разбор на практике

Представим онлайн-школа, где нужно улучшить процесс «карточки учеников и программы». Тема этой главы — «Версии документов и правил» — становится полезной только тогда, когда её можно связать с конкретным решением. Поэтому сначала фиксируем исходное состояние: кто начинает процесс, какие данные получает, сколько ручных действий выполняет, где ждёт ответа и по какому признаку считает работу законченной. Такая карта быстро показывает, где действительно нужен AI, а где достаточно убрать лишний шаг или ввести простое правило.

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

Пример «до и после»

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

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

Что может пойти не так

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

Алгоритм внедрения

1. Сформулируйте результат главы «Версии документов и правил» как наблюдаемое изменение, а не как установку нового инструмента.

2. Возьмите 20—30 реальных примеров из процесса «карточки учеников и программы» и разделите их на обычные, пограничные и ошибочные.

3. Зафиксируйте Source of Truth: откуда берутся факты, которые система не имеет права придумывать.

4. Определите Human Gate: при каких условиях человек обязательно видит результат до внешнего действия.

5. Запустите ограниченный пилот и сравните его с исходной точкой по времени цикла, ручным касаниям, ошибкам и числу исключений.