Как найти точки автоматизации с максимальной отдачей

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

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

В ИИ-трансформации нужно понять, где достаточно правила, где действительно нужен ИИ, а где решение должен принимать человек.

Отсюда возникает второй вопрос — границы автономности.

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

Теоретически такую систему можно построить. Но я бы не ставил полную автономность конечной целью.

В бизнесе есть решения, где важна ответственность за последствия.

Можно ли запустить продукт на рынок «для взрослых»? Стоит ли принимать неэтическое решение? Стоит ли идти на финансовый риск? А может вообще закрыть неперспективное направление?

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

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

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

У меня был кейс, где у службы поддержки не было конкретного владельца. В компании было несколько продуктов, а каждый владелец продукта внедрял свой сервис поддержки.

Мы разработали достаточно универсального агента для унификации службы поддержки, но возник простой вопрос: а кто вообще должен сказать, что результат удовлетворительный и его можно катить в прод?

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

Бывают и чисто технические проблемы. Например, данные находятся в старой легаси-системе, к которой нет нормального доступа.

Где-то нужной базы данных вообще нет. Где-то данные есть, но необходимые метрики никто никогда не собирал.

Получается, что иногда первый этап ИИ-трансформации вообще не связан с ИИ. Тут мы возвращаемся к статье об индексе ИИ-зрелости.

Сначала нужно привести в порядок сам процесс. Назначить владельца. Определить метрики и снять текущее состояние. Подготовить данные и доступы. Понять границы процесса и ответственность.

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

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

Самый простой способ расставить приоритеты — посмотреть на матрицу ценности и сложности.

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

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

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

А если ценность низкая, а сложность высокая, я бы вообще возвращался к ним в самый последний момент. А иногда не возвращался бы совсем.

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

В следующий раз разберемся, как спроектировать целевую TO-BE модель процесса и определить в ней роль человека..

👉 Полная статья