Академия Датаиста

Что нужно, чтобы ИИ-автоматизация реально заработала

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

Но перед этим у вас должен быть готов паспорт агента:

1. Карточка процесса;
2. Модель AS-IS;
3. Узкие места;
4. Карта точек автоматизации;
5. Модель TO-BE;
6. Новая роль человека;
7. Данные и интеграции;
8. Граф навыков агента;
9. Метрики пилота;
10. План внедрения.

Тут возникает вопрос: почему ИИ часто не получается внедрить, даже если сам агент работает нормально?

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

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

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

И наконец — метрики нужно определить до разработки. Не «сделаем агента поддержки». А, например: сократим среднее время обработки обращения с восьми до двух минут, при этом качество не должно ухудшиться.

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

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

Получается вся методология довольно простая:

Метрики → AS-IS → точки автоматизации → TO-BE → новая роль человека → граф навыков агента → пилот и внедрение

И только после этого мы переходим от проектирования к практике — и начнем собирать агентов.

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

Как превратить мышление эксперта в работающего ИИ-агента

Мне часто приходится слышать, что есть эксперты, которых невозможно автоматизировать.

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

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

Когда мы описываем бизнес-процесс, мы в первую очередь отвечаем на вопрос: «Что делает человек?» Например, у рекрутера в процессе может быть действие «проанализировать резюме».

На входе — резюме, на выходе — оценка кандидата и решение, двигать его дальше или нет.

Но сама эта формулировка почти ничего не говорит о реальной экспертизе. Главное скрыто внутри: на что рекрутер смотрит, какие признаки замечает, как их интерпретирует, с чем сравнивает и почему в итоге принимает конкретное решение.

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

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

Вот эту структуру мышления уже можно переносить в агента.

Я бы выделил четыре базовых варианта.

1. Вход — выход

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

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

2. Цепочка размышлений

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

Каждый следующий шаг использует результат предыдущего.

3. Дерево размышлений

Иногда у эксперта возникает несколько возможных веток.

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

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

4. Граф размышлений

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

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

Здесь рассуждение превращается уже в граф: эксперт возвращается к предыдущим выводам, связывает разные признаки и обновляет гипотезы.

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

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

Получается, что когнитивное интервью — это способ оцифровать экспертное мышление.

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

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

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

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

AI-First компания: какая работа остаётся человеку в мире ИИ-агентов

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

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

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

Человека не заменяют — его повышают.

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

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

На мой взгляд, сегодня особенно важны четыре вещи.

Первая — системное мышление.

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

Вторая — критическое мышление.

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

Третья — креативное мышление.

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

Четвертая — доменная экспертиза.

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

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

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

И здесь появляется ответственность.

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

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

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

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

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

Как перестроить процесс под ИИ-агентов

Когда вы переходите от AS-IS процесса к TO-BE, главная ошибка — взять существующую диаграмму и просто добавить в несколько квадратиков слово ИИ.

Для начала нужно полностью пересмотреть его с учетом новых возможностей ИИ.

В старом процессе могут быть операции, которые теперь вообще не нужны.

Поэтому TO-BE — это не автоматизированная версия AS-IS. Это заново спроектированный процесс.

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

Причем роль человека нужно фиксировать заранее.

Когда вы приходите к сотрудникам и говорите, что часть их работы теперь будет выполнять ИИ, естественно возникает вопрос: а что тогда буду делать я?

Отсюда появляется сопротивление.

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

Я бы выделял четыре основные роли человека.

1. Оператор. Процесс может работать автономно, но у системы все равно должен быть ответственный.

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

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

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

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

Одобрять ли действие? Запускать следующий этап или останавливать процесс?

Человек принимает решение, а дальше ИИ продолжает работу.

3. Менеджер. Здесь ИИ тоже готовит информацию: собирает контекст, делает анализ и предлагает варианты.

Но следующее действие выполняет уже сам человек. В этом основное различие.

Супервайзер принимает решение для ИИ, после чего агент продолжает процесс.

Менеджер использует подготовленный ИИ контекст и уже сам что-то делает на его основе.

4. Эксперт. Здесь человек и ИИ работают вместе.

ИИ помогает искать информацию, анализировать данные и готовить материалы. Но конечная ценность создается за счет человеческой экспертизы.

Например, примерно так устроена моя работа с Лабораторией Датаиста.

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

На этом этапе я выступаю как оператор.

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

Дальше из этих статей я выбираю ту, которую хочу изучить глубже.

Здесь я уже супервайзер.

Агент дает мне выбор, а я принимаю решение, какую статью изучить.

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

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

Здесь я уже выступаю как менеджер.

А дальше все разобранные исследования остаются в моей базе знаний.

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

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

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

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

В одной точке процесса он оператор, в другой — супервайзер, дальше менеджер, а где-то эксперт.

Поэтому и на самого агента я бы не смотрел как на одного виртуального «сотрудника».

Агент — это набор функций или навыков. Эти навыки соединяются между собой в определенной последовательности.

По сути, агент — это граф навыков, по которому текут данные.

А компания — это огромный граф взаимосвязанных навыков, по которому постоянно движутся данные.

Поэтому при проектировании TO-BE модели я бы начинал с вопроса:

«Как должен выглядеть этот процесс, если сегодня работу между собой могут разделить человек, ИИ и обычная автоматизация?»

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Как увидеть бизнес-процесс таким, какой он есть на самом деле

Бизнес-процессы можно описывать разными способами: UML, классическим BPMN, S-BPM и другими нотациями.

BPMN самый распространенный вариант. Но мне больше нравится субъектно-ориентированный подход — S-BPM.

В нем процесс строится вокруг субъектов. Субъектом может быть человек, система или ИИ-агент.

У каждого субъекта есть свое поведение, а между собой они обмениваются артефактами.

Такой подход с одной стороны, простой, а с другой — хорошо переносится на архитектуру мультиагентной системы.

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

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

Гораздо важнее понять, соответствует ли эта схема реальности.

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

Поэтому я рекомендую дополнять интервью Process Mining.

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

Идея Process Mining в том, что информационные системы оставляют цифровой след, и по нему можно восстановить то, как процесс действительно проходил.

Для этого нужен журнал событий минимум с тремя полями:

• Case ID — конкретный экземпляр процесса: заявка, заказ, сделка.

• Activity — какое действие произошло.

• Timestamp — когда оно произошло.

• Дополнительно полезен Resource — кто выполнил действие: человек, система или агент.

Но на практике самая трудозатратная часть Process Mining в подготовке данных.

Информационные системы почти никогда не хранят события сразу в нужном формате.

Например, Jira может хранить историю изменения задачи примерно так:

`issue = DATA-4712`
`field = status`
`from = In Progress`
`to = Review`
`author = Andre`
`created = 14:42`

А Process Mining хотелось бы получить:

`case_id = DATA-4712`
`activity = Sent to Review`
`timestamp = 14:42`
`resource = Andre`

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

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

У Jira один формат. У CRM другой. У ERP третий. У внутренней самописной системы четвертый.

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

Зато здесь очень хорошо помогает ИИ.

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

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

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

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

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

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

Поэтому Process Mining используют не только для оптимизации процессов, но и коллеги из кибербезопасности.

Но полностью заменять интервью данными тоже нельзя.

Process Mining хорошо показывает, что произошло, но далеко не всегда объясняет, почему.

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

Поэтому я бы всегда сочетал несколько источников.

Люди дают контекст. Данные дают факты.

Интервью показывает, как человек понимает процесс. Process Mining показывает цифровой след того, что реально происходило.

И только их комбинация позволяет собрать действительно честную AS-IS модель.

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

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

Как провести рентген бизнеса и извлечь знания экспертов

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

В официальном BABOK (Business Analysis Body of Knowledge) описано 50 техник бизнес-анализа.

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

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

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

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

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

Поэтому я бы дополнял классический бизнес-анализ методами, которых нет в BABOK.

Например, Process Mining позволяет восстанавливать фактический процесс по цифровым следам в информационных системах, а не только по тому, что сотрудники рассказывают на интервью.

Task Mining показывает, что человек делает непосредственно на компьютере: между какими системами переключается, что копирует вручную и какие операции повторяет.

А когнитивный анализ задач (Cognitive Task Analysis, CTA) нужен для извлечения того, что происходит уже в голове эксперта. Тут вы становитесь своего рода психологом.

Для когнитивного анализа я бы выделил шесть вопросов для интервью:

1. Информация — на что человек смотрит? Какие данные важны? Что он замечает первым и с чем сравнивает?

2. Интерпретация — что он понимает из увиденного? Что означает конкретный признак? Какую гипотезу он строит? И какие признаки рассматривает вместе?

3. Логика решения — как выбирается результат? Какие есть варианты? По каким критериям выбирается каждый? И где проходят границы?

4. Опыт и эвристики — что находится только в голове эксперта?
Что он замечает быстрее новичка? Какие негласные правила использует? И что сложно формализовать?

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

6. Качество и обратная связь — как понять, что решение хорошее? Как проверить результат? Какие ошибки критичны? И что заставит пересмотреть решение?

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

Получается, что бизнес-анализ показывает, что делает человек, а когнитивный анализ — что он думает, когда это делает.

Для ИИ-агентов это важно, потому что автоматизировать нужно не только видимые действия, но и скрытые правила и логику принятия решений.

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

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

Тогда человек может уйти из компании, а накопленная экспертиза останется внутри.

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

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

Как выбрать правильный процесс для автоматизации

Помогая компаниям внедрять ИИ, я часто вижу одну ошибку.

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

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

Компания начинает проводить автоматический онбординг и быстрее подключает больше клиентов.

Но больше клиентов — это больше транзакций и диспутов.

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

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

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

У меня был кейс, когда компания хотела стать AI-First, но найм разработчиков занимал несколько месяцев.

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

Поэтому ИИ нужно было внедрять именно туда.

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

Они боялись, что ИИ их заменит, так как значительная часть их работы сводилась к вопросам вроде: «Готов ли кандидат к релокации?»

Такие операции можно автоматизировать, но рекрутеры все равно выполняли их вручную.

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

Об управлении такими изменениями я отдельно расскажу в одной из следующих статей.

При этом стать AI-First не означает передать ИИ всю работу.

Я бы не стал полностью автоматизировать процессы, в которых требуется персональная ответственность за решения.

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

То же самое касается финансов.

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

В юридической работе ИИ тоже должен оставаться ассистентом.

Он может искать документы и прецеденты, готовить черновики и подсвечивать потенциальные риски.

Но юридическая интерпретация зависит от контекста и практики. Поэтому окончательное заключение должно оставаться за человеком.

И вообще, помогая компаниям проходить ИИ-трансформацию, я пришел к выводу, что сегодня создать AI-First компанию с нуля зачастую проще, чем трансформировать существующую.

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

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

Поэтому некоторые основатели уже не пытаются трансформировать старую компанию, а говорят прямо: «Мы строим новую компанию с нуля».

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

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

Это уже по сути корпоративная ИИ-революция, а не ИИ-трансформация.

А предпринимателю, который начинает с нуля, вообще не нужно ничего трансформировать. Он может сразу строить AI-First компанию.

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

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

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

Почему бизнесу не нужен очередной хайповый ИИ-инструмент

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

Но гораздо реже задают вопрос: «Мы хотим улучшить конкретную бизнес-метрику. Как нам здесь поможет ИИ?»

Хотя именно с этого вопроса и должна начинаться любая автоматизация.

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

В других случаях выясняется, что проблема находится в данных: они неполные, хранятся в разных системах или вообще не собираются.

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

Думаю, здесь работает обычный FOMO. Инфлюенсеры показывают красивую картинку (зачастую это просто ложь), все вокруг обсуждают новый инструмент, и предпринимателю начинает казаться, что он что-то упускает.

На самом деле — нет.

Именно поэтому я не использую OpenClaw и подобные универсальные инструменты для автоматизации критических бизнес-процессов.

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

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

Так устроены языковые модели: иногда они могут неправильно интерпретировать задачу или просто сгаллюцинировать.

Для эксперимента это допустимо. Но представьте, что на такой системе завязан реальный бизнес-процесс.

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

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

Например, если нужно проверить, заполнено ли обязательное поле или соответствует ли телефон заданному формату, языковая модель попросту не нужна.

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

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

Есть и другая ошибка — пытаться решать с помощью LLM задачи, для которых она сама по себе не предназначена.

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

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

ChatGPT может помочь написать код, проанализировать текст или картинку, но просто загрузить историю котировок и спросить: «Что будет дальше?» — недостаточно.

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

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

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

Бизнес — это потоки данных

Когда я занимался ИИ-трансформацией Сбера, поле моей работы уже было описано.

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

Директор по данным каждого блока отвечал за цифровизацию своих процессов. Директор по искусственному интеллекту — за внедрение в них ИИ.

Отдельный центр координировал эту работу на уровне всей компании.

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

Но в большинстве компаний такой карты нет.

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

Например, он уверен, что у него многое автоматизировано. А в реальности сотрудники продолжают делать все вручную.

Поэтому я смотрю на компанию не как на набор отделов, а как на систему потоков данных.

Возможно, это мое профессиональное искажение, так как я начинал карьеру как инженер данных.

Для меня не так важно, что находится передо мной: экономический прогноз, HR-процесс, маркетинговое исследование, продажи или разработка продуктов.

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

Предметная область меняется, но общая логика остается неизменной.

Нужно видеть сквозные цепочки создания ценности.

Если продукт или сервис предназначен для внешнего клиента — это основной бизнес-процесс.

Если сервис нужен сотруднику или другому подразделению — это поддерживающий процесс.

Но в обоих случаях мы создаем и передаем кому-то ценность.

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

Современную компанию можно представить как матрицу.

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

По вертикали — функции, которые вызываются внутри процессов в определенном порядке. Одна функция может использоваться в нескольких процессах и по-разному влиять на их результат.

Именно такое мышление я хочу сформировать у вас этим курсом.

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

В ней уже нет привычного разделения на маркетинг, продажи, HR и другие отделы.

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

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

Еще я заметил одну закономерность.

Основатели, которые любят свое дело и живут им, относятся к бизнесу как к системе.

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

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

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

Они не знают, как оценить успешность бизнеса, эффективность процессов и работу сотрудников.

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

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

После метрик появляются описанные процессы — и тогда вы становитесь управленцем.

Но сегодня быть просто управленцем уже недостаточно. Это только первая ступень. Следующая — цифровизация. И только после нее начинается полноценная ИИ-автоматизация бизнеса.

Об этом новая статья.

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

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

Как разобрать бизнес-процесс и превратить его в ИИ-агента

Возвращаюсь со второй лекцией курса «Автоматизация бизнес-процессов с помощью ИИ-агентов».

Мне пришлось два года проучиться в магистратуре Высшей школы экономики, получить диплом Международного института бизнес-анализа и перевести для официальной русской версии около 500 страниц BABOK (Business Analysis Body of Knowledge), чтобы собрать эту лекцию.

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

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

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

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

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

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

Если просто добавить в этот хаос ИИ-агента, он станет еще одним участником плохо спроектированного процесса.

Поэтому сначала нужно восстановить модель AS-IS: понять, кто участвует в процессе, какие действия выполняет, как движутся данные, где принимаются решения, по каким правилам они принимаются, где возникают задержки, возвраты и исключения.

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

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

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

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

Именно этому посвящена вторая лекция курса «Автоматизация бизнес-процессов с помощью ИИ-агентов».

В практической части вы возьмете один реальный процесс из своей компании и проведете его полный анализ:

• Определите бизнес-цель, метрику и границы процесса;
•Восстановите реальный процесс AS-IS и построите его модель;
• Найдете узкие места и точки автоматизации;
• Спроектируете процесс TO-BE и граф навыков будущего агента;

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

Чтобы вам не пришлось самостоятельно рисовать все диаграммы, в практической части я оставил шесть готовых примеров и четыре промта:

1. Превращает расшифровку интервью в схему AS-IS
2. Находит точки автоматизации и быстрые победы
3. Проектирует модель TO-BE
4. Собирает граф навыков агента

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

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

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

Так мы переходим к системной ИИ-трансформации бизнеса.

Если вы еще не переводите свой бизнес в AI-First модель, то чем вы вообще занимаетесь?

Лекцию можно посмотреть или прочитать. В конце вас ждет практика на собственном бизнес-процессе.

👉 Смотреть вторую лекцию

AI-First-компания: новые роли и новая оргструктура

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

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

Во главе обычно стоит Chief AI Officer (CAIO), который отвечает за ИИ-стратегию.

Когда я работал в Сбере, похожая роль называлась Chief Data Scientist. Сегодня чаще используют Chief AI Officer, но функция схожа.

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

Классические ML Engineer, Data Engineer и Data Analyst никуда не исчезают, но для ИИ-трансформации я бы выделил несколько новых ролей.

• AI Engineer — разрабатывает ИИ-системы и работает с моделями, данными и инфраструктурой

• AI Automation Engineer — разбирает бизнес-процессы и автоматизирует их с помощью агентов.

• AI Product Engineer — создает внутренние и внешние ИИ-продукты, может быть и отдельный AI Product Manager, который больше про бизнес и меньше про технику

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

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

Это ИИ-консультант. По сути, именно этим я занимался последние несколько лет.

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

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

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

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

Компания состоит из набора компетенций внутри нее.

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

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

Мне также доводилось слышать мнение: «ИИ-консультант вообще не нужен, лучше все делать самим».

Здесь вопрос, как по мне, не в том, нужен консультант или нет, а в том, кого именно вы нанимаете.

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

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

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

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

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

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

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

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

В новой статье — более подробно про новые роли.

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

AgentOps: как поставить разработку ИИ-агентов на поток

Я привык все повторяющиеся процессы превращать в Ops.

Есть DevOps, MLOps, DataOps и так далее. С ИИ-агентами происходит та же история.

Недостаточно один раз собрать агента и считать задачу завершенной.

Разработка агентов должна стать постоянной операционкой.

Этот цикл называется AgentOps.

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

1. Анализ процесса

Сначала нужно определить цель.

Допустим, мы хотим ускорить обработку заявок.

После этого описываем процесс таким, какой он существует сейчас, — AS-IS.

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

Затем проектируем TO-BE.

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

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

2. Разработка агента

Мы определяем роль агента, логику его работы, граф навыков, модели, инструменты и контекст.

Где достаточно детерминированного кода, а где действительно нужна модель.

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

А понимать содержание письма и формулировать ответ уже имеет смысл отдавать модели.

На этом этапе появляется рабочий прототип.

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

3. Внедрение

Агента нужно подключить к реальным источникам данных: CRM, ERP, почте, базе знаний, внутренним API и другим корпоративным сервисам.

Здесь сразу становится видно реальное состояние ИИ-зрелости компании.

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

4. Дообучение

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

Здесь появляется постоянная обратная связь.

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

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

Так универсальная модель превращается в корпоративного специалиста, который понимает логику принятия решений.

Причем этот датасет становится отдельным активом компании.

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

Эти знания находятся в головах людей.

Когда сотрудники исправляют работу агента, часть этого неявного знания постепенно превращается в данные.

5. Тестирование

После этого агента нужно проверить на реальном бизнес-процессе.

Мы в самом начале выбрали конкретную бизнес-метрику.

Значит, теперь берем один процесс и сравниваем, как он работает без агента и с агентом.

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

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

Но на этом работа не заканчивается.

6. Мониторинг

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

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

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

Если мониторинг показывает проблему, мы возвращаем агента обратно в цикл.

Собираем новые примеры, исправляем промпты, обновляем контекст, при необходимости дообучаем, снова тестируем и выкатываем новую версию.

Разработка ИИ-агентов — это важный навык для AI-First компании.

Чем лучше компания умеет проходить цикл AgentOps, тем выше ее реальная ИИ-зрелость.

Каждый из этих этапов мы будем разбирать отдельно в последующих статьях.

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

Как разработать стратегию ИИ-трансформации

После диагностики начинается разработка стратегии.

Диагностика показывает, что происходит в компании сейчас.

Стратегия отвечает на вопрос: что с этим делать дальше?

Если продолжать аналогию с медициной, мы провели обследование, нашли проблемы и теперь можем выписывать рецепт.

Я бы начинал со старого доброго SWOT-анализа: сильные стороны, слабые стороны, возможности и угрозы.

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

Слабые стороны — это те самые дыры, которые диагностика показала.

Где-то данные разбросаны, где-то мешает легаси, не хватает экспертизы или сотрудники не готовы к изменениям.

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

Так уже появляется концептуальная дорожная карта.

Но здесь важно не начать искать, куда бы внедрить ИИ.

Начинать нужно с целей бизнеса.

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

Дальше ищем процессы, которые влияют на эти показатели.

Если хотим увеличить выручку — смотрим продажи, маркетинг, конверсию, удержание клиентов.

Если хотим сократить расходы — операционные процессы, поддержку и другие ручные операции.

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

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

И здесь я бы начинал с быстрых побед.

Это процессы, где есть хороший потенциальный эффект и при этом относительно мало ограничений.

Сделали, посчитали эффект, показали руководству и сотрудникам, что ИИ действительно работает, а потом пошли дальше.

Поэтому стратегию удобно разделять как минимум на три горизонта.

Первый — быстрые победы. То, что можно внедрить прямо сейчас.

Второй — среднесрочная перспектива. Здесь сначала нужно устранить барьеры: объединить данные, внедрить платформу, изменить инфраструктуру или обучить людей.

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

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

Я видел компании, которые принципиально хотели делать все свое.

Допустим, есть продукт, который используют другие компании. Можно подключить его сейчас и начать получать пользу.

А можно нанять целую команду и несколько месяцев делать собственную систему.

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

Если потом появится смысл — готовое решение можно постепенно вытеснять своим.

Но у внешних инструментов тоже есть минус.

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

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

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

Поэтому здесь нужно смотреть на сам процесс.

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

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

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

Но пока мы определили только, какие процессы нужно трансформировать.

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

В следующих статьях разберем фреймворк AgentOps и перейдем уже непосредственно к анализу бизнес-процессов.

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

Готова ли ваша компания к ИИ-трансформации?

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

Если у вас уже существующий бизнес, начинать нужно не с технологий.

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

Это как в медицине: врач не начинает лечение с операции или случайного набора препаратов.

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

С бизнесом то же самое.

Можно нанять лучших специалистов по ИИ и дать доступ к самым современным модели.

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

Поэтому первым этапом должна быть диагностика ИИ-зрелости компании.

Такие maturity-модели давно используют McKinsey, Accenture (где, я, кстати тоже успел поработать дата-инженером) и другие консалтинговые компании.

Еще в 2019-ом году мы в Сбере тоже создавали собственную методику на основе лучших практик, чтобы руководители одинаково оценивали точку старта и прогресс трансформации.

Тогда мне удалось «поднять» ИИ-зрелость стратегических процессов с полного нуля до 93%.

Я взял этот опыт, разные существующие подходы и адаптировал их под новую реальность.

Получилось семь измерений зрелости.

1. Стратегия и управление

Если ИИ отсутствует в целях компании, нет ответственного руководителя и поддержки сверху — системной трансформации не будет.

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

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

2. Люди и культура

Инновации плохо приживаются в культуре, которая сопротивляется изменениям.

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

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

Об управлении изменениями мы позже поговорим отдельно.

3. Технологическая инфраструктура

Только после этого идут технологии.

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

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

4. Данные

Данные — это топливо для ИИ. Они должны быть, как минимум, доступны, и качественны.

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

5. ИИ-модели

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

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

6. Внедрение ИИ

Здесь уже можно измерять реальный прогресс: сколько процессов использует ИИ и сколько операций автоматизировано.

И главное — какой получается возврат инвестиций (ROI).

Потому что конечная метрика трансформации — не количество внедренных агентов, а бизнес-результат.

7. Исследования и разработки

Это уже задача со звездочкой.

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

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

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

Без диагностики вы не трансформируете компанию, а внедрите отдельные инструменты.

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

Об этом в новой статье и отдельной методичке по диагностике ИИ-зрелости.

А тут вы можете пройти оценку ИИ-зрелости вашей компании.

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

Три трансформации, которые полностью изменили бизнес

Когда я пришел в Сбер дата-инженером в 2017 году и начал работать в стратегическом блоке, там как раз шла Agile-трансформация (точнее, Sbergile).

Вместо жестких вертикальных иерархий начали формироваться небольшие автономные продуктовые команды, обычно до 10 человек — условно «на две пиццы».

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

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

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

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

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

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

Появился запрос на умных ассистентов, прогнозную аналитику, стресс-тесты и сценарии «а что будет, если?».

Так поверх данных появился AI-Driven подход, где ИИ помогает человеку принимать решения, но не снимает с него ответственность.

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

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

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

Сегодня наступила новая эпоха — AI-First. Здесь ИИ уже не просто подсказывает человеку, что делать, а выполняет значительную часть работы, тогда как человек остается оператором и менеджером ИИ-агентов и отвечает за результат.

Следующий этап — AI-Native, когда компания изначально занимается созданием ИИ-систем, которые и являются основными продуктами компании. Этому будет посвящен отдельный курс.

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

Но если вы строите HR-, маркетинговое или SMM-агентство, колл-центр или другой бизнес с большим количеством повторяемых процессов, переход в AI-First уже становится вопросом выживания: конкурент с ИИ-агентами будет быстрее, дешевле и легче масштабироваться.

Я думаю, в новой экономике все три типа будут существовать вместе. В центре окажутся AI-Native компании, создающие новую ценность; их будут обслуживать AI-First компании, берущие на себя отдельные функции; а AI-Driven останется в управленческих процессах и в сферах с высокой ценой ошибки — в медицине, безопасности, государственных системах, где человек должен оставаться в контуре принятия решений.

Поэтому главный вопрос трансформации — какую ответственность оставляет за собой человек.

Компании проходят эту эволюцию, а начинать трансформацию стоит с управленческой системы: структуры команд, процессов, данных, принятия решений и распределения ответственности.

Об этом подробнее в новой статье.

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

Где ИИ-агенты создают бизнесу максимум ценности

Я ко всему стараюсь относиться системно, и наука о менеджменте не исключение.

Когда я впервые стал руководителем команды дата-инженеров, первое, что я понял: людьми невозможно управлять, потому что люди — субъекты.

Людей можно мотивировать деньгами или «пряниками», а можно манипулировать ими: объединять вокруг великой цели или угрозой увольнения — кто во что горазд.

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

Я разделяю их на три вида:

• Процессы — деятельность с низкой степенью неопределенности: есть повторяемость, метрики и KPI.

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

• Продукты — создают ценность для конечного клиента, поэтому здесь важны бизнес-результаты, которые удобно формализовать через SMART-цели.

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

Отсюда возникает фреймворк «RUN, CHANGE и DISRUPT»:

• RUN сохраняет устойчивость текущего бизнеса (процессы);

• CHANGE помогает адаптироваться (проекты);

• DISRUPT — создавать новое и совершать бизнес-прорывы (продукты).

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

Сами процессы в классической методологии делятся на три типа:

• Основные бизнес-процессы создают ценность и в конечном счете приносят деньги;

• Поддерживающие выручку обычно не создают и потребляют ресурсы, но без них система не работает;

• Управленческие отвечают за целеполагание, контроль и принятие решений.

Отсюда простая логика: сначала определяем бизнес-цель, потом выбираем тип процесса.

Хотим увеличить продажи или выручку — смотрим на основные бизнес-процессы.

Хотим сократить косты — на поддерживающие.

Хотим быстрее и качественнее принимать решения — усиливаем управленческие процессы.

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

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

Но это не канон, а мое наблюдение: в корпорациях обычно рассматривают три основных типа.

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

Я бы ставил туда ИИ-ассистентов, которые помогают руководителю принимать решения, но не руководят за него.

Потому что управление — это ответственность.

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

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

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

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

А на старте трансформации нужны быстрые победы — кейсы, где можно быстро получить и измерить эффект.

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

В новой статье я подробнее разобрал RUN, CHANGE, DISRUPT, карту процессов компании, цели внедрения ИИ и то, где именно искусственный интеллект приносит бизнесу максимальную ценность.

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

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

Пять уровней эволюции ИИ-агентов:
от экспертных систем до AI-First-компании

Я застал почти все эпохи того, что сегодня мы называем искусственным интеллектом.

Мое первое знакомство с ИИ произошло в 1998 году: в 3 года мой первый компьютер учил меня играть в шахматы.

Благодаря этому в 6 лет я даже выиграл уссурийский турнир.

Потом в школе на информатике мы изучали экспертные системы, основанные на правилах.

Сам термин «искусственный интеллект» появился в 1950-х. В 1950 году Алан Тьюринг опубликовал работу «Вычислительные машины и разум» и поставил вопрос о способности машины «мыслить».

А в 1955 году Джон Маккарти использовал термин «искусственный интеллект» в заявке на Дартмутский семинар, который прошел летом 1956-го.

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

Но, как мы понимаем, проблема актуальна и по сей день.

Более подробно об этом я писал тут.

Следующая эпоха для меня началась в 2012 году.

Я учился в ДВФУ и летом приехал из Владивостока в Москву на первую конференцию по машинному обучению.

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

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

С этого момента я начал заниматься машинным обучением всерьез.

Причем тогда никто не называл это «искусственным интеллектом».

Позже, когда я учился в магистратуре ВШЭ, слово «ИИ» вообще старались не использовать, это считалось маркетинговым термином.

Когда я уже учился в аспирантуре ВШЭ на ФКН (ИИ и анализ данных), мы подробно разбирали разные архитектуры нейронных сетей: сверточные, рекуррентные и другие подходы того времени (кстати, экзамен по этим нейронкам был самым тяжелым в моей жизни).

А потом появился «трансформер».

В 2017 году вышла статья «Attention Is All You Need», где исследователи предложили новую архитектуру, построенную вокруг механизма «внимания».

В итоге именно она стала фундаментом для больших языковых моделей.

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

Дальше «стрельнули» диффузионные модели, с помощью которых мы научились генерировать картинки — тогда мне это казалось каким-то чудом.

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

Я тогда делал LLM-систему для сервисов для взрослых: модель должна была имитировать общение с реальным человеком — подробнее об этом кейсе тут.

На подобных сервисах за собеседников обычно работают целые команды индусов.

Во время одного из экспериментов я дал LLM доступ в интернет и сделал симулированных мужчину и женщину.

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

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

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

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

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

Дальше я подумал: а что будет, если направить все это в бизнес?

Дать модели данные компании, доступ к CRM, почте, календарю и возможность взаимодействовать с другими агентами.

И именно с того эксперимента я стал смотреть на LLM не просто как на очередной класс моделей машинного обучения, а как на фундамент для новой архитектуры ИИ-систем — а в конечном счете и для нового способа строить компании.

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

Поэтому до агентов, которые создают что-то новое, им еще нужно дорасти.

А полноценные мультиагентные системы — это «вишенка на торте».

Об этом подробнее — в новой статье.

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

Кто такой ИИ-агент и почему он меняет устройство компании

Само понятие агентности появилось задолго до современного ИИ.

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

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

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

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

Мне кажется, именно через это понятие проще всего понять, что сегодня происходит с ИИ-агентами.

Обычная программа обладает очень небольшой, заранее заданной степенью свободы.

Человек заранее определяет, что она должна сделать, в какой последовательности и при каких условиях.

ИИ-инструмент дает больше возможностей: он может проанализировать информацию, создать текст, построить прогноз или предложить решение.

Но инициатором действия по-прежнему остается человек.

ИИ-агент — следующий уровень.

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

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

Так мы переходим от программирования действий к постановке целей.

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

Но чем больше свободы — тем меньше контроля.

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

В новой статье разобрал, кто такой ИИ-агент, как устроен его цикл работы и каковы его основные свойства.

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