Как найти ненужную работу в компании с помощью ИИ

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

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

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

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

Ответ может оказаться убедительным. Руководитель сравнивает повторные поломки, чтобы назначить проверку качества ремонта. Тогда потребность в анализе есть, хотя форма из двенадцати отдельных сводок требует пересмотра. А может выясниться, что документ появился после давнего инцидента, затем стал привычным доказательством работы и теперь лишь повторяет уже доступные записи.

В обоих случаях разговор об ИИ меняется. Во втором компания сначала пересматривает обязанность готовить отчёт. В первом формулирует более точную задачу: находить повторные обращения и показывать основания для проверки. Технологическая работа начинается после выяснения назначения результата.

Почему регулярный отчёт переживает собственную задачу

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

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

Lean Enterprise Institute описывает информационную избыточность, в том числе лишние согласования и сбор данных для отчётов, которые не помогают работе или принятию решений. Это полезное основание для проверки офисных процессов. Оно не доказывает, что конкретная таблица вашей компании бесполезна.

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

Поэтому просьбу «пусть теперь это делает ИИ» стоит дополнить вопросом о судьбе самой операции. Дешёвое производство результата не создаёт спроса на него.

Что ИИ способен заметить в рабочем следе

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

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

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

Здесь важна скромность вывода. Совпадающие значения ещё не делают документы взаимозаменяемыми. Одна сводка может показывать исполнение, другая — подтверждать приёмку клиентом. ИИ должен описать, что именно совпало, и отдельно перечислить различия. При отсутствии сведений о назначении документа полезная отметка звучит просто: «Получатель и решение не установлены».

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

Постройте цепочку от результата к решению

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

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

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

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

Такая цепочка также выявляет результат, который никто не может связать с действием. Это сильный повод исследовать процесс дальше, хотя окончательное решение ещё впереди.

Проверьте потребность разговорами

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

Попросите показать конкретное использование. Когда отчёт открывали в последний раз? Какую строку искали? С чем сравнивали? Что произошло после просмотра? Для редкого документа спросите, в какой ситуации его обязательно потребуют и кто предъявит это требование.

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

В государственном Service Manual GOV.UK исследование проблемы предшествует созданию сервиса. Руководство допускает остановку после исследования, если дальнейшая разработка не оправдана. Для бизнеса здесь полезен сам порядок: сначала подтвердить потребность и ограничения, затем выбирать способ решения.

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

Повторный запрос может создавать лишнюю работу

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

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

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

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

Измеряйте появление работы

Для такого исследования полезно считать, сколько обязательных результатов компания производит и зачем. У нашей компании двенадцать инженеров выпускают по одной сводке еженедельно. За четыре недели получается 12 × 4 = 48 документов. Координатор добавляет четыре общие сводки. Итого 52 результата.

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

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

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

Отменяйте процедуру через пробный период

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

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

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

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

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

Сохраняйте необходимые основания

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

В определении потерь Lean Enterprise Institute различаются действия, которые можно устранить, и действия, пока необходимые при существующих условиях. Это различие помогает не превращать сокращение операций в соревнование по числу удалённых форм.

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

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

Дайте ИИ задачу исследовать основание

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

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

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

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