Серия «про IT и не только»

Хайп вокруг ИИ заставляет компании искать «серебряную пулю». Но как только проект доходит до этапа реализации, он разбивается о классические 6 слоев сопротивления Голдратта (Теория ограничений).
Для бизнес-аналитика понимание этих слоев — это не психология, а конкретные вопросы, требующие решений. Разберем их суть на примере внедрения ИИ в бизнес-процессы.
1️ Несогласие с проблемой
Что говорят: «У нас и так все работает, незачем усложнять?».
Суть: Компания пытается внедрить решение, не имея диагностированной «боли». Если проблема не оцифрована (мы не знаем точную стоимость ручной обработки одного документа, не знаем даже занятости работников в тех или иных процессах). Невозможно доказать необходимость изменений там, где нет проблем.

2️ Несогласие с направлением решения
Что говорят: «Проблема с обработкой данных есть, но ИИ тут ни при чём. Нам нужно просто модернизировать текущую информационную систему, автоматизировать вот этот процесс, допилив существующий софт».
Суть: Специалисты признают проблему, но предлагают традиционное, понятное им IT-решение. Они не верят, что ИИ сможет помочь, и считают его избыточным инструментом для данной задачи. И они же правы (см.предыдущий пост про выбор между ИИ и автоматизацией)

3️ Сомнение в выгодах решения
Что говорят: «Да, это интересно, но стоимость внедрения, лицензий, очистки данных и поддержки ИИ явно превысит ту экономию, которую мы получим. Где здесь реальный ROI?»
Суть: Любое внедрение — это всегда затраты. Тут и скептики и энтузиасты захотят посмотреть финансовое обоснование: будет ли реальная прибыль или ценность от ИИ превышать совокупную стоимость владения? Без четкого расчета, в котором выгоды гарантированно перевешивают затраты, проект выглядит как неоправданная трата бюджета. А времена нынче непростые, надо экономить. Также можете посмотреть предыдущий пост про ИИ и Excel.

4️ Опасение негативных последствий
Что говорят: «ИИ галлюцинирует, уверено врет, неправильно интерпретирует. А человек физически не может проверить каждую рекомендацию.»
Суть: Это не абстрактный страх, а конкретный риск. ИИ — вероятностная система, которая может уверенно выдавать не то. В существующих процессах человек несет персональную ответственность за каждое решение. С ИИ эта цепочка разрушается: кто отвечает, если алгоритм ошибся, а сотрудник доверился системе? Это может привести к катастрофическим последствиям, вплоть до от судебных исков и потери клиентов. Без четкого процесса верификации результатов проект будет нежизнеспособен.

5️ Опасение непреодолимых препятствий
Что говорят: «Мы понимаем, что хотим сделать, но не понимаем, какими силами. Готовых коробочных решений под наши задачи нет. У нас нет внутренней экспертизы, а на рынке мы не наблюдаем вендоров с реальным, а не маркетинговым опытом. Технология еще сырая, и найти настоящих носителей этих компетенций невозможно».
Суть: Это объективный фактор новой технологии. Внедрение ИИ в конкретный бизнес-процесс - это не просто развернуть сервис и научить пользоваться. Требуется большое исследование процессов организации в контексте внедрения ИИ. Сейчас многие уже ищут специалистов с опытом внедрения ИИ, и не могут найти. Попытка решить это «в лоб» приводит к расходам и зависанию проекта на этапе первых экспериментов, которые так и не переходят в реальную работу.

6️ «Да», но без действий
Что говорят: «Всё понятно, отличная инициатива, давайте внедрять» - но ничего не делают. Не выделяют время на тесты, не приходят на обучение, саботируют пилот другими задачами.
Суть: Даже если из-за политического давления или нажима руководства менеджеры и специалисты согласились участвовать во внедрении ИИ, это не значит, что сопротивление угасло. Конечно, чтобы успешно преодолеть этот слой нужно преодолеть предыдущие, а ещё иметь достаточно энтузиастов, готовых продвигать проект. Тут нужны не только аргументы, но и изменение контекста: новые правила и примеры успешных коллег.


Внедрение ИИ — это наконец-то проекты полной трансформации бизнес-процессов, чем и отличается от внедрений инструментов цифровизации, которые накладывались на текущие процессы сверху или служили только основой для выстраивания процессов.
Прежде чем говорить о технологиях, ответьте на три вопроса:
1. Какую конкретную проблему мы решаем и как это измерено в деньгах/времени?
2. Действительно ли нам здесь необходим ИИ? Может есть варианты пока сделать упор на упорядочивание процессов и классическую автоматизацию?
3. Понимает ли бизнес, что первые 3–6 месяцев работа скорее замедлится из-за настройки и контроля, прежде чем произойдет реальное ускорение и окупаемость?
4. Готовы ли мы переписать регламенты под вероятностную природу ИИ и взять на себя риски его ошибок?
5. Есть ли у нас специалисты, готовые решить эту проблему, перестроить процессы и не сломаться на пол-пути?
6. Достаточно ли энтузиастов среди сотрудников, можно ли выделить их в отдельную команду внедрения?
Без честных ответов на эти вопросы ИИ останется дорогим экспериментом с отрицательным эффектом.

Многие сотрудники, освоив Word и Excel, начинают искать пути автоматизации своей работы с использованием этих программ. Сначала это формулы в Excel, затем макросы. Делают сетевые папки чтобы делиться файлами, потом начинают использовать Google Таблицы. Это всё «ползучая» автоматизация, которая дает эффект в виде локального ускорения процессов.
Проблема «Excel-подхода»
Работа в электронных таблицах чревата разными проблемами: данные перемешаны с логикой, разрозненность файлов, отсутствие контроля версий бизнес-правил и решений, теневые процессы. Решения принимаются в уме или в личных файлах, сохраняясь только у сотрудника, причем иногда только в голове.
Сегодня ИИ часто сравнивают с Excel: «С ним тоже можно делать кучу задач быстрее». Будет ли ИИ повторять этот путь и тоже приводить к проблемам? Несомненно.
Давайте посмотрим на это через призму Теории Ограничений (ТОС).
Если использовать ИИ как «умный калькулятор» без интеграции в систему, мы получим локальную оптимизацию. Сотрудник пишет промпт, получает ответ за 5 секунд вместо 30 минут. Он доволен. Но результат остается в его личном чате, логика не зафиксирована, данные не попали в общую базу. Даже если это не чат, а локальный агент, всё равно итог будет похожим. Вроде агент работает, но работает только пока сотрудник работает и ускоряет свою работу. На общие процессы организации это может влиять крайне слабо.
Согласно Теории Ограничений, оптимизация любого элемента системы, кроме узкого места (constraint), не дает прироста общей производительности. Если ваше ограничение - согласование или качество данных, то ускорение генерации черновиков просто создаст затор на следующем этапе https://habr.com/ru/companies/vktech/articles/1086302/
и https://habr.com/ru/articles/1090612/
Агентов нужно загонять в единый процесс, выводить из зоны локального применения. Конечно одно дело, когда за это берутся программисты, которые ускоряют кодинг за счет четкого пайплайна https://habr.com/ru/companies/sberbank/articles/1088632/, другое дело, когда мы хотим автоматизировать разные задачи обычной офисной работы (как Excel). Я думаю выход будет только в использовании лоу-код платформ с встроенными ИИ-агентами.
https://habr.com/p/1054790/ вот пример лоукод платформы с ИИ агентами, которых можно привлекать как к задачам разработки, так и к выполнению рабочих задач бизнеса/

Многие руководители задаются вопросом: «Нам нужен ИИ-агент или достаточно внедрения системы автоматизации?» Ответ часто ищут в технологиях, но он кроется в зрелости процессов.
Здесь всё просто. Прежде чем выбирать инструмент, задайте один вопрос: «А что у нас уже автоматизировано?»
Вариант 1: Автоматизации нет или она хаотична
Если процессы выполняются вручную, разрозненны или зависят от «серых схем» в Excel и почте — забудьте про ИИ.
Почему: ИИ не умеет наводить порядок. Если вы подадите ему хаос, он масштабирует этот хаос с невероятной скоростью.
Что делать: Сначала наведите порядок. Опишите регламенты, устраните «узкие горлышки», внедрите систему учета задач и процессов, CRM, SRM, ERP, MES, LIMS или сделайте интеграции между системами, если у вас их несколько.
Правило: Сначала детерминированная автоматизация (правила «если-то»), потом вероятностный ИИ.
Вариант 2: Уровень автоматизации высокий
У вас всё работает по регламентам, данные чистые, системы интегрированы. Но дальше упираться в стену: новые задачи требуют сложного программирования, нестандартной логики обработки данных или работы с неструктурированными данными (тексты, голоса, изображения).
Почему: Традиционный код становится слишком дорогим, слишком сложным и ненадежным из-за поддержки каждого исключения.
Что делать: Здесь пора подключать AI-инструменты. Они берут на себя ту часть, где нужны «человеческие» навыки: понимание контекста, генерация текста, принятие решений в условиях неполной информации.
Перспектива: Когда AI-инструменты научатся самостоятельно ставить подзадачи и использовать другие сервисы, они превратятся в полноценные AI-агенты.

Формула выбора:
Хаос в процессах ➡️ Пишем стандарты и регламенты на процессы, налаживаем базовую автоматизацию.
Стандартизированные процессы ➡️ Глубокая автоматизация (CRM, SRM, ERP, MES, LIMS).
Сложные, неформализуемые задачи на фоне автоматизации ➡️ AI-инструменты (LLM, компьютерное зрение).
Автономное выполнение цепочек задач ➡️ AI-агенты.

Для получения правильных результатов на выходе, нужно давать правильные данные на вход. Это актуально как для классической автоматизации, так и для нейросетей (ИИ). И дело не в промтах, а в налаженных процессах.
UPD. Забыл про тележку https://t.me/limsaccreditation

Наткнулся на такое утверждение:

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

Также вижу очень много статей по типу:
"Кто вырастит будущих сеньоров, если код теперь пишет AI?"
"Марк Руссинович и Скотт Хансельман из Microsoft опасаются, что ИИ вытеснит джунов в программировании"
Некоторые новые джуны на самом деле не умеют писать код без ИИ-помощников
И некоторые считают, что из этого факта проистекают проблемы с вакансиями для молодых специалистов - "Как найти работу джуну, когда джуны никому не нужны"
Но это не так.
Если мы внимательно посмотри на анализы рынка труда, в которых фиксируется недостаток работы для джунов, например тут - "Forbes: «джуны» сейчас не нужны или почему выпускникам IT-курсов стало сложнее найти работу" https://habr.com/ru/news/681468/, то видим, что проблема не в ИИ, который заменил джунов, а в целом в сокращении потребности отрасли в специалистах и большом количестве переученных выпускников курсов.
На самом деле джуны также нужны и сейчас и в будущем пригодятся по тем же самым причинам, что и раньше:
1. Им можно меньше платить.
2. Они больше мотивированы и готовы расти.
3. Они меньше спорят и больше делают.
Но конечно меня спросят, а что насчет того, что всю работу джунов может заменить ИИ?
На этот счет у меня есть история из моей лабораторной практики. Когда я поступил в аспирантуру, общей практикой было то, что все новички: студенты и аспиранты, сначала в лаборатории моют посуду. Многие студенты на практике и аспиранты в первые пару месяцев только этим и занимались. Такой же подход был показан в сериале Теория Большого взрыва. Когда Шелдон приходит к Эми в лабораторию и предлагает помощь, она отправляет его мыть посуду.
Но в скором времени, наша лаборатория стала переходить на одноразовую пластиковую посуду, и потребность в мытье посуды просто отпала. По аналогии с ИИ, лаборатория должна была отказаться от студенческих практик и молодых аспирантов. Ведь теперь посуду мыть не надо, значит эти люди не будут приносить пользу. Но это не так. Просто студентам на практике стали давать больше заданий в рамках реальной экспериментальной работы.
Эта история мне всегда напоминает о том, что в реальном производственном или исследовательском процессе всегда остается много того, что пока может сделать только человек. И если у вас есть потребность в разработке, аналитике и т.д., то с помощью ИИ джун может сделать много того, что раньше мог делать только опытный разработчик.

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

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

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

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

4. Собиратели конструкторов - аналитики заменяют разработку в проектах с лоу-код и ноу-код конструкторами.

5. Вайб-кодеры - в настоящее время за счет нейросетей аналитик может самостоятельно тестировать идеи в коде и прототипах вообще без разработчиков. Далее рассмотрим подробнее.

1. Разделение труда - основа эффективности

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

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

2. Дешёвая замена - страховка от некомпететености

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

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

3. Тушитель пожаров и «универсальная затычка»

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

• Руководитель проекта перегружен и не успевает расставить приоритеты? Аналитик делает это сам.

• Тестировщики не понимают бизнес-логику? Аналитик пишет сценарии и проверяет функции ПО.

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

• Разработчик не хочет вникать в нюансы? Аналитик «додумывает» логику и исправляет требования постфактум.

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

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

4. Собиратели конструкторов - аналитик становится разработчиком

С приходом платформ вроде Bubble, Airtable, Power Apps, ELMA, Первая форма аналитик получил суперсилу: он может сам создавать рабочие решения без единой строчки кода.
Теперь он не просто описывает форму для приложения — он может собрать её сам и она сразу будет работать, при это не требуется писать код. Я знаю, что на Хабре мало поклонников ноу-код, но тем не менее такие платформы используются, работают и выполняют свои функции. Если в компании внедряют какую-то лоу-код платформу, то ей нужны аналитики, которые будут там настраивать и править, сразу реализуя то, что нужно пользователям. Программисты в этом случае конечно тоже нужны, но только для написания плагинов, коннекторов, каких-то базовых функций и т.д. Здесь вот про это подробно описано https://habr.com/p/977318/
Это превращает аналитика в продуктового инженера одного лица: от идеи до MVP — за день. Но есть и риски. No-code — не панацея. Такие решения часто не масштабируются, сложны в поддержке и могут стать «цифровым мусором», если не продумана архитектура. Аналитик должен понимать границы возможностей платформ и вовремя передавать зрелые продукты в руки программистов то, что требует классической разработки через код.

5. Вайб-кодинг и ИИ: от ТЗ к архитектуре намерений

Самый мощный тренд 2024–2025 годов — вайб-кодинг (vibe coding): когда достаточно описать желаемое поведение на естественном языке, чтобы ИИ (GitHub Copilot, Cursor, V0, Lovable) сгенерировал рабочий интерфейс или даже full-stack приложение.

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

Выводы

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