Что делать, когда «всё встало»?
или инструкция для руководителя подразделения по разгребанию завалов

Когда WIP-лимит забит и Ready-лимит на походе, а работа не движется, не надо кричать «быстрее!». Нужно включить логику. Вот пошаговая «лесенка» решений для руководителя.

Шаг 1. Найдите «самое легкое»
Не хватайтесь за новые задачи. Посмотрите в колонку In Progress. Что из этого можно закрыть прямо сегодня?
Цель: дожать задачи до статуса Done, двигаясь от простого к сложному. Как только одна задача выйдет – освободится слот для новой.

Шаг 2. Расчистите завалы – убейте блокеры
Часто работа стоит, потому что мы «ждем ответа», «не подписали» или «нет доступа».

Типовые блокеры:
• зависло на согласовании;
• ждём правку/ответ,
• не подписали/не подтвердили,
• нет данных от инициатора,
• нет доступа,

Что делать: вместо новой задачи потратьте час на пинки звонки и письма тем, кто вас тормозит. Поставьте жесткий дедлайн (например, до 16:00). Если не помогло – эскалируйте наверх. Одно закрытое «зависшее» дело ценнее трех начатых.

Шаг 3. Делайте «Обмен»
Если на вас давят, заставляя взять новую задачу – держите удар. Ну а если у них «прямо горит» то:

1. Выберите самую несрочную задачу из тех, что в работе.
2. С почестями верните её обратно в Ready (в очередь).
3. На освободившееся место берите срочную.
Это честный приоритет, а не раздувание хаоса.

Кто решает, что попадёт в Ready? Руководитель! Когда вход лавинообразный, спасает не «планирование на квартал», а короткая регулярная сортировка.

Формат: 10–15 минут один-два раза в день, на каждую новую задачу ровно одно решение: в Ready (делаем) /в Backlog (позже) / закрыть (не делаем). Если нет опции «не делаем», вы всё равно утоните, просто культурнее.

Что делать если это не помогло разгрузить очереди?
Давайте быстро проверим:

Ready пухнет, а работа не идет?
Гипотеза: узкое место не там, где вы думали. Скорее всего, у вас не хватает мощности в другом месте. Что делать: вернитесь к схеме процесса и сделайте повторный анализ.

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

Вывод для босса: WIP-лимит – это не про «нельзя работать». Это про выбор: что мы заканчиваем, а что вообще перестаем принимать, чтобы не захлебнуться.

И еще… Ваша главная проблема не в том, что люди работают медленно, а в том, что работа слишком много «отдыхает». Если вы посмотрите на путь любой задачи, то увидите, что 80% времени она просто лежит и ждёт: подписи, ответа, данных или когда у исполнителя дойдут руки. Когда вы бросаетесь «делать новое», вместо того чтобы «разбивать блокеры» в старом, вы увеличиваете время этого простоя.

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

#производительностьтруда

Типизация, шаблоны и эскалация

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

Но если нужна скорость, нужен другой принцип: Типовое – делаем быстро и молча. Нетиповое – эскалируем. Всё! Остальное – детали реализации.

1. Полномочия надо делить
Линейный сотрудник должен иметь право принимать решения в пределах лимита. Например, сейл имеет право продавать до X евро / давать скидку до Y% / обещать срок до Z дней. Всё, что выше – не «запрещено», а эскалируется.

Ключевой эффект: вы превращаете 70% действий из «ждём решения» в «делаем сразу».

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

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

3. Эскалация
Эскалация должна быть описана как система лимитов рисков и ответственности:
• цена, скидка, отсрочка платежа;
• сроки, гарантия, штрафы;
• объём работ/бюджет;
• периодичность, исключения, особые условия.

Чем выше роль, тем выше полномочия – тем выше личная ответственность. Не «коллективно решили», а кто разрешил, на основании чего, какой риск принял.

4. Сценарии и процессы пишутся только для типового
Одна из причин бюрократии: люди пытаются описать процесс так, будто жизнь – это блок-схема на 400 развилок. Нормальная инженерная логика иная:

• типовое действие – есть сценарий/инструкция/шаблон;
• отклонение – не «ветка в BPMN», а «поднимаем на уровень выше по лимитам» – эскалация.

Так вы держите модели простыми, а систему – быстрой.

5. Высшее образование – это не почетное звание
В офисе полно людей, которые умеют читать, писать и иногда думать. Значит, например, сейл может выписать приходный документ по шаблону, завести инвойс в систему, инженер – заполнить акт/отчёт по форме, менеджер – может оформить закупку по чек-листу.

Бухгалтерия, юристы и иные не должны быть «ручками», которые набирают текст. Они должны быть:
• владельцами правил,
• аудиторами качества,
• теми, кто подключается по эскалации.

Иначе любой внутренний сервис создаёт очередь.

6. Вместо согласований – уведомления
Согласование типового шага – это самоубийство. Если шаг типовой и в лимитах, то уведомил и сделал, а руководитель не «разрешил», а получает сигнал для контроля.

Согласование нужно только на исключения, потому что исключение = риск.

7. Типовое должно быть действительно типовым
Чтобы типизация не стала фарсом, нужны две вещи:

• Библиотека шаблонов. Договор, инвойс, КП – всё в шаблоны. И запрещено плодить «чуть-чуть другой файл». Любое «чуть-чуть» – это либо новый тип (официально), либо эскалация.

• Чек-лист завершения на каждую типовую операцию. Не «почти готово», а «готово», то есть, когда выполнены все пункты чек-листа.

Пример для продажи:
• запись в CRM создана/обновлена,
• инвойс заведён,
• документ отправлен клиенту,
• следующий шаг запланирован (follow-up).

Нет пункта – нет «готово» – нет зарплаты! Именно так: нет записи в системе + нет обязательных артефактов – нет начисления зарплаты.

Да, это сурово! Но это единственный способ вылечить «я всё сделал, просто не записал». В бизнесе «не записал» равносильно «не существует».

8. Как это не превратить в новый ритуал
Для каждого процесса (продажа, закупка, договор, счёт) достаточно трёх таблиц:

• Таблица лимитов (кто что может): должность; лимит; что делать при превышении (эскалация).
• Список типовых операций (10–20): операция; шаблон; чек-лист завершения.
• Правила уведомлений: кого, как и в каком случае уведомляем.

И всё! Никаких регламентов на 80 страниц.

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

#производительностьтруда

С праздником, наши дорогие и любимые женщины!

Будьте любимы и счастливы, освещайте нашу планету как долгожданное вешнее солнце🌷🌷🌷

Свой или чужой

Мы уже поговорили про WIP-лимиты, типизацию, шаблоны, эскалацию и уведомления вместо согласований. Если вы это реально запустили хотя бы на одном процессе – поздравляю: вы сделали то, чего не умеет половина «серьёзных компаний». Вы превратили «работу отдела» в сервис с понятным контрактом. А раз так – дальше начинается самое интересное.

1. Покупать результат вместо «людей»
Надеюсь, что вы уже хоть где-то смогли перейти от «юристы тормозят», «бухгалтерия не успевает», «ИТ опять в домике» к простой инженерной конструкции:
• корректный вход (чек-лист; «без этого не принимаем»),
• корректный выход (что значит «готово»),
• SLA (правило очереди: сколько времени при нормальном входе),
• WIP (предохранитель от «впихнуть невпихуемое»),
• эскалация (лимиты ответственности и риска).

Это и есть «контракт сервиса». И теперь можно говорить не «кто виноват», а «что требовать».

2. Теперь подразделения можно мерить
Потому что у вас появляются нормальные вопросы, которые можно задавать и своим, и чужим:
• «Сколько задач вы реально выпускаете за неделю при корректном входе?»
• «Какое среднее время цикла?»
• «Какой SLA вы гарантируете?»
• «Какой процент возвратов по входу?»
• «Где у вас забивается WIP и что вы делаете при перегрузке?»

Это уже не придирки и не «давайте уважать коллег». Это управление потоком.

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

4. «Свой» отдел – это тоже подрядчик.
Если ваш внутренний сервис не принимает на себя SLA, не уважает входной чек-лист, не выдаёт результат по DoD, обходит WIP («ну мы же взяли ещё чуть-чуть»), то это не «свой». Это внутренний монополист, который живёт в логике «как получится». А монополии почти никогда не быстрые. Они комфортные.

5. Аутсорсинг – это не «сократить», это – «купить скорость»
Правильный смысл аутсорса:
• убрать очереди,
• стабилизировать выпуск результата,
• разгрузить узкое место,
• и удерживать ритм потока «заявка → деньги»,
• распределить риски между несколькими подрядчиками.

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

6. Мини-тест: готовы ли вы к аутсорсу (10 минут)
Возьмите одну функцию, которая у вас в категории «всё своё» (юристы, бухгалтерия, IT, кадры – что болит) и ответьте:
1. Можете ли вы на одной странице описать вход и выход этой работы?
2. Можете ли вы сказать, какой SLA нужен бизнесу (не «как удобно отделу»)?
3. Можете ли вы назвать метрику потока (время цикла / % старых задач)?
4. Есть ли понятное правило эскалации (когда и кто принимает риск)?

Если «да» хотя бы на 3 пункта, то вы готовы! Если «нет» – вы пока не готовы к аутсорсу, вы готовы только к «передаче хаоса наружу» и готовы платить за нерасторопность и комфорт. Тоже выбор! Главное делать его осмысленно!

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

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

#производительностьтруда

Аутсорсинг без идиотизма

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

Начинаем не с цены, а со смысла. Первое правило: выносить наружу нужно не «что раздражает», а то, что не является стратегически важным и при этом стандартизируется. Основа – логика матрицы Дмитрия Хлебникова: стратегическая важность vs уровень компетенций.

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

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

2. Тест клиента (мягкий тест): клиент выбирает компанию из-за этого (скорость, качество, сервис, уникальные условия), и конкуренты не могут быстро повторить.
Смысл: если это легко копируется рынком – это не стратегия, это операционка.

1. Тест денег: если сегодня сократить расходы на функцию на 20%, то выручка/маржа упадет в минус в течение недели.
Смысл: стратегическое всегда чувствуется в P&L.

3. Тест риска: ошибка в функции создаёт экзистенциальный риск (вероятные потери выше размера собственного капитала).
Смысл: тут важно не «страшно», и не «может быть», а точно убьёт бизнес. Измеримо, просто, легко запомнить. Но ошибка должна быть реальная, а не изворотливо высосанная из пальца, типа «а что если...», за которым следует цепочка из 100500 маловероятных событий. То есть, «а что если мы проиграем в суде 100 миллиардов долларов» – не подходит – вы сначала заработайте столько!

4. Тест метеорита (hardcore-тест): если эту функцию забрать в одно мгновение, бизнес не может работать 1–2 недели даже при наличии неограниченного количества денег на подрядчиков.

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

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

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

#производительностьтруда #аутсорсинг

Вопрос подписчика: «Как выстроить отношения с аутсорсом, если поставщиков мало и обсуждать требования почти невозможно? Аутсорс работает по принципу “не нравится – не покупай”.»

Во-первых, нужно признать реальность: это рынок поставщика (по Портеру), со всеми вытекающими. Это не партнёрство, это зависимость. А зависимость в бизнесе лечится только одним способом – её нужно устранять.

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

Скажу сразу: мы с Хлебом (Д. Хлебниковым) на этом поле оттоптались не по-детски. Всё ниже – не «советы из книжек», а опыт, добытый через ошибки и деньги.

1. Расширить географию поиска
Цель: найти альтернативу монополисту.
Суть: искать нужно не «за забором предприятия», а шире. Мир большой, и почти всегда можно найти тех, кто готов прийти в вашу локацию при нормальном контракте и объёме.

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

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

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

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

2. Дробление работ
Цель: завести на рынок больше поставщиков.
Суть: монополии часто держатся не потому, что они лучшие, а потому что объём работ неделим или «так исторически сложилось». Если есть возможность – делите!

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

И после этого на рынок заходят мелкие игроки, которым «целый комбинат» не по зубам, а «кусок работ» – вполне.

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

Критическое временно забираем внутрь. Да, иногда придётся. Но цель не «вечно держать внутри», а выиграть время и разрушить зависимость. Переманивание персонала монополиста – приемлемая мера.

Риск: потребуется нормальная «служба заказчика» (планирование, контроль, эскалации).
Но это не минус – это признак зрелости.

3. Создать нового игрока (свой бизнес как анти-монополия)
Цель: та же – создать альтернативу и рыночную силу, а может быть и выйти на новый рынок.
Суть: вы уже сделали шаг 2: дробление, SLA, служба заказчика.

Дальше варианты:
• M&A: купить пару мелких игроков и собрать компетенцию.
• Создать ДЗО: нанять персонал и построить поставщика с нуля.
• Выделить внутреннее подразделение в ДЗО, если оно уже есть.

Ключевые правила, чтобы это работало:
• вы даёте стартовый объём работ;
• каждый год доля работ «на сторону» должна расти (лучше всего – за счёт клиентов нынешнего монополиста, но сойдут любые);
• даёте опцион на выкуп компании менеджментом/коллективом через 3 года.

Почему это работает:
• с вашим SLA у нового игрока хорошие рыночные шансы;
• возможность стать собственником стимулирует лучше любого KPI;
• при правильной реализации за 2–3 года можно снизить совокупные затраты примерно на 15–20% при заданном качестве и точно перестать быть заложником.

Совет: начинать с пилота небольшого масштаба – иначе увязнете в «великом строительстве».

Риски:
• нужно держать стратегический фокус;
• относиться к своему ДЗО как к бизнесу: не выкручивать руки «админресурсом», не заставлять работать ниже рынка.

Иначе вы потеряете людей и качество.

Собственно, всё!
Хороших выходных!

#аутсорсинг

Одной матрицы мало

Скажу прямо: многие проваливают аутсорс не потому, что «подрядчики плохие» или их нет, а потому что выбирают неправильную игру. Есть еще 5 факторов, которые убивают аутсорсинг в реальности.

Фактор 1. Нужна конкуренция
Если ваш «аутсорсер» – монополист, вы не покупаете услугу. Вы покупаете зависимость. Монополист всегда будет медленный и дорогой.

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

Фактор 2. «Оверфлоу компетенций» внутри – не аргумент против аутсорса
«У нас юрист дерёт зад всем» – это не причина держать отдел. Это сигнал: либо компетенция стратегически важна и её надо защищать/развивать, либо вы просто гордитесь человеком, который случайно оказался сильнее рынка в типовой ситуации. Матрица Хлебникова как раз про это: сила внутри не всегда означает «держим внутри».

Фактор 3. Перераспределение накладных
Как только вы выводите функцию наружу, ваши накладные расходы не исчезают магически. Они перераспределяются. И внезапно может выясниться, что «внутренние результаты» стали дороже, потому что постоянные накладные легли на меньшее число людей/процессов.

Если накладные высокие – считать надо внимательно, иначе вы «сэкономите» на функции и проиграете в себестоимости продукта.

Фактор 4. Один подрядчик – это слабость
Нужны минимум два источника, чтобы была конкуренция и была возможность переключиться. Иначе через полгода вы окажетесь в позиции «ну мы уже к ним привыкли».

Фактор 5. Нельзя становиться «якорным клиентом» подрядчика
Если ваши заказы составляют значимую долю объёма подрядчика (порог – порядка 35-40%), вы по факту начинаете оплачивать ему постоянные издержки почти как внутренний отдел, только без контроля. В этот момент аутсорс превращается в «ваш отдел, который сидит не у вас».

Как сравнивать «свои vs чужие» по цене честно

Тут люди чаще всего врут себе дважды:
(а) «чужие дорогие, потому что в счёте большая сумма»,
(б) «свои дешёвые, потому что зарплата маленькая».

Но честная, да и правильная схема, такая:

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

Шаг 2. Своих считаем по полной стоимости владения (TCO).
Это не просто «зарплата», а:

• зарплата + все налоги и отчисления на рабочую силу,
• плюс доля накладных (управление/админка – по численности; офис/тепло/свет – по площади; IT-инфраструктура – по потреблению/учёткам; и т.п.),
• плюс стоимость управления (время руководителя и согласования – это тоже деньги),
• плюс стоимость капитала,
• плюс ваша внутренняя «норма прибыли» (да-да: внутренний сервис должен жить как бизнес, иначе он всегда будет «удобным» и медленным).

По сути, это небольшой ABC/ABS-подход: распределяем накладные по понятной базе, без фанатизма, но честно.

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

Но всё это только в контексте конкретного SLA, одинакового, как для своих, так и чужих.

Вывод на сегодня: аутсорсинг – это не про «отдать наружу и забыть». Это про то, чтобы купить рыночную конкуренцию, скорость и управляемый сервис, опираясь на контракт (вход/выход/SLA/WIP/эскалация), который вы уже научились формулировать.

#производительностьтруда #аутсорсинг

Автоматизация: а почему не КИС?
Сразу расставим все точки над i

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

Раньше была простая мечта: поставим большую КИС, накроем ею все процессы, и компания станет работать, как швейцарские часы.

В 90-х это ещё выглядело как истина. В нулевых – еще более-менее логичная идея. А вот сегодня это звучит просто как бред. И дело даже не в самих КИС, а в том, что мир изменяется быстрее, чем монолитные системы умеют меняться.

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

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

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

В-третьих, бизнес-модель
Любая КИС – это не «нейтральный софт». Это упакованная бизнес-модель, просто спрятанная в справочниках, ролях, проводках, статусах, документах и «правильных» сценариях. Вендор не продаёт вам пустой конструктор. Он продаёт то, как устроены продажи, как устроены закупки, что считается «заказом», «отгрузкой», «счётом», «закрытием», какие бывают роли и полномочия, какая логика контроля и рисков «правильная».

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

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

1. вы ломаете бизнес под систему – теряете скорость и особенности,
2. вы ломаете систему под бизнес – теряете деньги, сроки и нервы,
3. вы строите над системой «вторую систему» из костылей и интеграций и потом живёте в ней. Но цена такой кастомизации – просто запредельная.

В-четвертых, монолит не переваривает разнообразие
Современный ландшафт – это не один огромный комбайн, а связка:
• CRM, биллинг, документооборот, поддержка,
• финтех и партнёрские сервисы,
• витрины, маркетплейсы, интеграции,
• и всё это через API.

И я еще ни слова не сказал про ИИ! Добавьте его сюда и становится очевидно: «накрыть всё одним» означает просто бороться с реальностью.

Что работает вместо «накрыть всё»
Не «анти-ERP», а более взрослая модель:
• «узкая» ERP является ядром управленческого учёта (важно: не бухгалтерского, а именно управленческого учета) – деньги, склад, активы, проводки, нормативка.
• Поверх – слой процессов и интеграций, который можно менять быстро.
• Вход/выход/SLA/WIP – в правилах, а не в головах.
• Автоматизация начинается с типового, а исключения уходят в эскалации.
• ИИ подключается как усилитель типового труда, а не как «мозг компании».

Мечта «покрыть всё одной КИС» умерла потому, что бизнес стал жить в режиме постоянной адаптации 7/24/365. Сегодня выигрывают не те, у кого «всё в SAP», а те, у кого скорость изменения процесса выше скорости изменения рынка – и автоматизация как система помогает этой скорости.

Конечно, из всего этого не следует, что «SAP всё». Думаю, подобные системы еще вашим детям будут «пить кровь». Если, конечно, вы их не воспитаете правильно…

😊

#производительностьтруда #автоматизация

Что такое «ИТ-слой процесса» и как он «женит» разные системы

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

Если по-простому: CRM, ERP, ТОиР, склад, документооборот – это «органы». А ИТ-слой процесса – это нервная система: кто кому что сказал, когда, по какому правилу, и как это отразилось на статусе работы. И в большинстве случаев сейчас это люди.

Чтобы «поженить» разное ПО на этом уровне, нужны 4 вещи:

1. Единая модель событий процесса
Например: «сделка создана», «договор подписан», «вагон назначен», «ремонт начат/окончен», «счёт выставлен/оплачен».
Смысл: системы разные, но события процесса общие.

2. Контракты данных
Не «перекинем файлик», а стабильные структуры: идентификаторы, справочники, статусы, атрибуты.
Смысл: чтобы не было 5-ти разных «клиентов» и 7-и разных «статусов» в каждой системе.

3. Оркестрация
Это ответ, кто где главный. Например, где-то главный CRM (продажи), где-то ERP (учёт), где-то ТОиР-SaaS.
Смысл: у каждого шага есть «источник истины», иначе начинается бардак синхронизации.

4. Интеграция через API/шины/очереди событий
Для тех, кто не из IT: вы (человек) взаимодействуете с тем или иным ПО через его интерфейс. Программы так могут, но это им не удобно. Для них существует другой тип взаимодействия – интерфейсы «программа-программа». Технически это делается через API или брокер сообщений (шину).
Смысл: процесс не должен падать, если одна система «чихнула».

Итог: ИТ-слой процесса – это правила + события + контракты + оркестрация, которые превращают зоопарк систем в единый поток с измеримым SLA и статусами.

Пара нетривиальных выводов:
1. Если вы покупаете ПО без официальных документированных интеграционных интерфейсов (API/Events/Connectors), вы покупаете технологический долг – устаревший продукт, который трудно встроить в современную архитектуру без «шаманства и плясок с бубном» (читай – много денег).

2. Если вы IT-компания и ваш продукт нельзя встроить в внешнюю оркестрацию и событийный контур, то он не соответствует текущей «гигиене» рынка, а ваше отставание – примерно 3-5 лет от текущей потребности, вне зависимости от длины списка фич.

На чем строить «ИТ-слой процесса»
Это обычно 4 класса продуктов:

• iPaaS (Integration Platform as a Service) – чтобы быстро соединять приложения и данные, управлять интеграциями и API. Это «трубы» и трансформаторы данных. Бери, если есть задача «поженить» более 3-4 систем. Пример.

• Process Orchestration / BPM – чтобы управлять именно процессом, людьми, решениями, сервисами и API как одним потоком. Это «диспетчер процесса» и его «карта прохождения». Бери, если нужен управляемый процесс «от начала до конца» с этапами, правилами, ролями, SLA, эскалациями и видимостью статусов. Пример.

• Workflow orchestration – если хочешь надёжную оркестрацию длинных бизнес-транзакций. Это «движки гарантированного исполнения», реализуемые, как правило, в коде (увы). Бери, если процессы длинные, с ожиданиями и повторами, и важна надёжность исполнения без ручного «дожима». Пример.

• Плюс часто рядом живёт Event Streaming / Kafka-платформа – когда интеграции строятся на событиях («договор подписан», «инвойс оплачен» и т.п.) и нужна шина и коннекторы. Это «нервная система» – события летят всем, кто должен реагировать. Добавляй, если нужен событийный контур: много подписчиков, реактивность, масштаб, слабая связанность и журнал событий. Пример.

Можно ли объединить что-то с чем-то из этого списка? Да, можно – такие системы сейчас начинают выходить на рынок. Это отдельная тема, и к ней мы еще обязательно вернемся. Особенно в контексте ИИ.

Итого: «ИТ-слой процесса» на практике – это комбинация интеграций (iPaaS/API), оркестрации (BPM/Workflow) и иногда событийная шина. И если ваш ИТ-директор на это скажет, что «для такой схемы нам нужно много людей и денег», то не пора ли опять вернутся к теме аутсорсинга или просто расстаться со старыми калошами? Ведь чувак не в теме 😉

Хороший вам выходных!

#автоматизация #производительностьтруда

А нужны ли программисты в штате?
Из переписки: «Ок, мы поняли про WIP, шаблоны, эскалации, ИТ-слой процесса. Но тогда нужно нанимать программистов в штат? И каких?»

Сначала базовая развилка: «гигиена» vs «двигатель»
Есть автоматизация-гигиена: CRM, учет, документооборот, заявки, типовые шаблоны, интеграции. Это нужно всем и всегда это дешевле купить готовым.

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

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

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

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

Вечный настройщик коробки – это не стратегия
Если «коробку» нужно «донастраивать» всю жизнь, значит это не «коробка», а вечная стройка. Это не значит, что «все коробки плохие». Это значит, что вы либо купили не тот класс решения, либо пытаетесь одной коробкой заменить процесс и архитектуру (объять необъятное и впихнуть невпихуемое), либо строите вокруг неё костыли на все случаи жизни, вместо того, чтобы стабилизировать вход/выход и правила.

Кого на самом деле нужно нанимать и когда
Теперь аккуратно «отрежем» малый бизнес. Пока вы маленькие, у вас обычно 1–2 ключевые системы, изменения редкие, интеграций мало, а половина процессов держится на голове владельца (и на его телефоне). В таком состоянии постоянный программист чаще вреден: он превращается в личного шамана, который «единственный знает как». И вы получаете новую зависимость вместо скорости.

Но как только вы становитесь средним предприятием, появляются признаки, которые нельзя «перетерпеть»:
• 3+ критичных систем (CRM + учет + документы + что-то ещё),
• 2–3 потока, которые должны работать параллельно и быстро,
• регулярные изменения и интеграции,
• видимые очереди между функциями.

Вот здесь почти неизбежно нужны две роли. И это не «IT-директор с армией». Это две точки управления скоростью:

Роль 1. Архитектор потока (процесс/BA-роль).
Это человек, который держит контракты процессов: вход/выход/DoD, SLA, эскалации, метрики потока. Он превращает «работу отдела» в сервис с понятными правилами. Из этой роли естественным образом вырастет бизнес-архитектор.

Роль 2. Инженер автоматизации и интеграций.
Не «настройщик одной коробки», а тот, кто строит нервную систему: API, события, оркестрация, надежность, наблюдаемость. Он делает так, чтобы ваши системы работали как единый поток, а не как зоопарк с пересылкой Excel по почте. Из этой роли вырастает enterprise/integration architect – архитектура ландшафта, а не «прикрутить кнопку».

Разработка ИТ-слоя процесса: в штате или на стороне?
Моё мнение простое – прямо по Хлебникову: архитектура должна быть своей, исполнение может быть смешанным (зависит от контекста).

Если ИТ-слой процесса – критичен (а он критичен, когда от него зависит P&L напрямую), то внутри должен быть человек, который определяет события, контракты данных, «источники истины» и правила оркестрации, а разработку адаптеров/коннекторов можно отдавать наружу, но строго по вашим контрактам и под его контролем.

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

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

#автоматизация #производительностьтруда

Break point: почему технологии меняют нашу профессию
и почему это хорошая новость для бизнес-архитекторов

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

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

Ещё недавно компании реально было достаточно одного разумного специалиста, который мыслит процессами, рисует BPMN (а лучше еще и IDEF), умеет описать требования и в идеале слышал про Enterprise Architecture. Это работало в мире, где ИТ – отдельный «цех», а бизнес-изменения – это проекты на кварталы.

Сейчас этот мир закончился. Почему? Потому что современная компания живёт не «в системе», а между системами: CRM – отдельно, ERP – отдельно, документооборот – отдельно, подрядчики – отдельно, интеграции – отдельно, события, API, автоматизация, ИИ – отдельно. И главный эффект технологий состоит в том, что бизнес теперь можно менять быстрее, чем раньше, но только если кто-то умеет держать в голове целостную логику. Именно поэтому сегодня нужен не «Enterprise Architecture thinker», а «Business Architecture thinker».

Enterprise Architecture (в классическом, корпоративном смысле) часто упирается в ИТ-ландшафт, стандарты, платформы, целевую архитектуру софта и железа. Это важно, но это не главный рычаг скорости.

Business Architecture – это другое. Это когда ты держишь в руках:
• поток создания ценности,
• правила принятия решений (лимиты/эскалации),
• SLA/WIP/метрики потока,
• границы сервисов (внутренних и внешних),
• и понимаешь, как технологии реально меняют механику бизнеса.

Если упрощённо: EA отвечает «на каких платформах и как мы строим», а BA отвечает зачем, где деньги, где риски, где скорость, и что должно измениться в системе управления и как все это организовать.

И да, требования к нашей работе выросли. Но это не трагедия – это повышение ставок. Теперь «сильный BA» – это человек, который умеет быть профессиональным постановщиком задач сразу нескольким мирам – юристам, процессникам, риск-менеджерам, ИТ и операционке (деньги, скорость, ответственность).

Звучит тяжело? Да. Невозможно? Нет. Почему? Потому что большинство задач не «сложные», а «системные». Вернее, эти задачи просто не собраны в систему. Когда ты умеешь это делать, то ты становишься весьма редким ресурсом.

Если ты не понимаешь технологические рычаги (API, события, оркестрация, автоматизация, ИИ как усилитель типового), ты рискуешь остаться человеком, который красиво описывает «как есть», но не умеет спроектировать «как будет работать быстрее». А бизнес сейчас платит не за описания. И даже не не эффективность или результативность, как таковые. Он платит за изменение механики – сокращение рисков и стоимости решения.

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

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

#пятничное

В пятницу о цифровой трансформации

Есть старая корпоративная мечта – если в бардак добавить CRM, ERP, BPM, пару интеграций и сверху присыпать это ИИ – получится цифровая трансформация. Нет, друзья – получится не Индустрия 4.0, а Бардак 2.0. Быстрый, блестящий, с ярким дашбордом. Но всё равно бардак.

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

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

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

Напомню простую вещь. Автоматизировать имеет смысл только три вещи: типовое, понятное, повторяемое.

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

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

Но, безусловно, выглядит это всё инновационно на все 146%!
Жить с этим, правда, всё равно неприятно.

Так что, прежде чем «внедрять AI», неплохо бы ответить на два скучных, абсолютно не пятничных, вопроса:

1. Что у нас должно происходить типовым образом без героизма?
2. Где у нас люди до сих пор изображают процесс вручную?

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

Хорошей вам пятницы! И осторожнее с цифровой трансформацией!

#пятничное #автоматизация #производительностьтруда #цифроваятранформация

ИИ? Не валите всё в одну кучу!

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

Чат ответил на вопрос? ИИ.
Картинку нарисовал? ИИ.
Письмо дописал? ИИ.
Сделал сводку по документу? ИИ.
Где-то в компании стоит скоринг, который решает, давать кредит или нет? Тоже ИИ.
У кого-то бот ходит по системам и сам запускает действия? Опять ИИ.

Слово-то одно, а вот сущности под ним – вообще разные. Примерно, как если бы вы называли словом «транспорт» и самокат, и бетономешалку, и Boeing, и SpaceX. Формально не соврал. Практической пользы – ноль.

Поэтому давайте честно: ИИ – это не один продукт и не одна программа. Это общее название для целого семейства технологий. Внутри него есть, например:

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

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

– у них ChatGPT сочиняет письма;
– у них LLM сидит на базе знаний;
– у них ассистент помогает сотруднику;
– у них агент сам ходит по API;
– у них multi-agent система выполняет последовательные фрагменты работы;
– у них программный скрипт по жёсткому алгоритму считает себестоимость;
– а иногда у них просто Excel с комплексом величия.

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

Какую именно?! Для чего?! С каким контуром управления?! Или просто чтобы мигала лампочками и радовала инвесторов?

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

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

#ИИ #ИИавтоматизация

Разбираемся подробнее.

Вчера я намеренно не разбирал ИИ-зоопарк по видам. Теперь давайте точнее – не строго академически, а для минимального понимания.

Когда люди говорят «у нас ИИ», под этим прячутся как минимум четыре разных зверя.

1. ИИ, который распознаёт и классифицирует
Это старый добрый прикладной ИИ: распознать документ, найти дефект на фото, определить тональность обращения, отнести заявку к категории, спрогнозировать спрос или риск оттока.

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

2. ИИ, который генерирует
Тексты, картинки, код, видео, сводки, письма. Именно здесь живут ChatGPT, Claude и остальные звёзды последних лет.

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

3. ИИ как усилитель человека
Здесь модель встроена в работу конкретного сотрудника или группы: помогает писать, искать, суммировать, сравнивать, готовить черновики. Такие системы часто называют ассистентами. Человек остаётся в петле – он принимает решение, ассистент снижает его стоимость.

Это не замена сотрудника. Это другой класс инструмента – и другой разговор о пользе.

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

Это уже не «чатик с подсказками». Это – агент – часть рабочего механизма, у которого есть вход, выход и ответственность за результат. Да, ответственность!

Зачем это всё и почему это важно?
Потому что у каждого из этих вариантов – разная цена ошибки, разная архитектура интеграции и разная логика окупаемости.

Грубо:
– надо разобрать 10 000 документов по типам – чат тут вообще ни при чём;
– надо готовить черновики писем – не нужно строить агентную систему;
– надо встроить ИИ в процесс – «просто доступ к GPT» задачу не закроет.

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

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

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

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

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

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

#ИИавтоматизация #ИИ

Сегодня, 1-го апреля у меня для вас две новости – хорошая и плохая.
Хорошая новость: многие компании уже внедрили ИИ.
Плохая новость: пока только в PowerPoint.

Делюсь наблюдением из реальной жизни. Как говорится, «основано на реальных событиях».

Компания. Средняя. Стабильная. На стратегической сессии кто-то серьёзным голосом говорит: «Нам нужен AI-first подход». Все кивают – ну, а кто против прогресса?!

Дальше начинается...
В презентациях появляется слайд «AI Transformation Roadmap», в речи CEO возникают слова «агенты» и «цифровой сотрудник», маркетинг срочно пишет, что компания «активно исследует применение ИИ».

А в это время внизу, на земле, как делали отчёт две недели пять человек в трех Excel-файлах, так и делают. Как с клиента запрашивали по два раза одни и те же данные, так и запрашивают. Как принимали решение, которое можно принять за 10, ну максимум – 20 минут, так и крутят его неделями по кругу согласований.

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

Самое смешное, что это даже не всегда ложь. Компания и правда «занимается ИИ» – много читает, обсуждает, мечтает, покупает подписки. Даже регулярно проходят совещания по выбору процессов для очередного пилота.

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

У меня для вас сегодня тест дня – оценка вашей цифровой зрелости.

Если в вашей компании:
– ИИ есть в презентации, но нет в процессе,
– чат есть у сотрудников, но нет правил применения,
– пилоты есть, а метрики эффекта нет,
– все говорят «ИИ», но никто не определил, что именно должно стать быстрее,
– на корпоративном сайте выскакивает навязчивое окошко «Консультант Робо-Вася»,

то поздравляю, вы запросто можете сказать, что вы внедрили ИИ в свою операционную практику! 🎉 🎊

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

С Первым апреля, друзья! 🙂

И да прибудет с вами Сила Естественный Интеллект! 🧠
🙂

Что такое LLM

Объясняю: LLM – это Large Language Model, то есть Большая Языковая Модель. Если по-простому, это система, обученная на огромных массивах текста и умеющая работать с языком: понимать, продолжать мысль, писать, сокращать, переводить, сравнивать, объяснять, классифицировать и в каком-то смысле рассуждать.

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

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

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

Но вот, что важно. LLM сама по себе не знает, что делать. У неё нет собственной цели, понимания проигрыша или успеха, страха или желания получить наслаждение. И именно здесь у людей чаще всего и происходит путаница. Они видят, что модель связно отвечает, пишет, объясняет, и мысленно дописывают ей ещё один этаж: «раз понимает, значит и действовать может». Не может!

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

Например, под капотом ChatGPT, Claude и других сильных систем живёт не только сама LLM, а ещё целый цирк из технологий вокруг неё:

1. Память. Чтобы система держала настройки, контекст, историю и важные факты.

2. Извлечение знаний. Чтобы она могла «видеть» документы, записи, знания и не полагаться только на то, что когда-то видела при обучении.

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

4. Инструменты и интеграции.
Поиск, вычисления, СУБД, CRM, API, иные системы – всё, что позволяет не только разговаривать, но и выполнять полезные действия.

5. Правила маршрутизации и контроля. Чтобы в одном случае ответить сразу, в другом – попросить уточнение, в третьем – позвать человека, а в четвёртом – вообще не лезть, куда не надо.

И это еще не весь список. Опять же уместна аналогия с нашим мозгом. Сравните, какую его часть занимает затылочная ассоциативная кора (6 слоев нейронов под вашей ладонью, положенной выше затылка), а сколько «всё остальное».

Опасно путать LLM с готовым решением. Потому что тогда начинаются фантазии, типа «сейчас дадим всем доступ к чату, и работа ускорится» или «сейчас загрузим документы, и получим цифрового эксперта». А итог предсказуем – не выйдет!

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

Пример из жизни. Ставили клиенту систему экспертизы договоров. На непосредственно проектирование и запуск потратил примерно часа два (правда, на специальной платформе). Еще полтора часа ушло на подготовку системы – индексацию ёмкого объема корпоративной документации и правил. Отладка заняла пару дней.
А вот на сборку контекста – корпоративной документации, матрицы полномочий, правил эскалации, маршрутизации клиент потратил более месяца!

Правда, игра стоила свеч – 4 минуты вместо 3-12 дней на экспертизу одного договора. И 1 юрист вместо 4-х.

Что можно сделать сегодня? Возьмите одну задачу, где вы без успеха уже пробовали ChatGPT или другой подобный инструмент, и честно ответь на вопрос:

Вам не хватило именно «ума модели» или данных, контекста, памяти, инструментов и правил работы вокруг неё?

Это хороший тест. Потому что после него обычно становится видно – вам нужна более сильная модель (правда не понятно, а куда сильнее) или все же нужен нормально собранный контур вокруг неё.

А это, как понимаете, две очень разные задачи!

#ИИавтоматизация #ИИ

LLM бывают разными

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

Размер LLM – это её количество параметров. Грубо говоря, это объём внутренних настроек, через которые она «упаковывает» знания и связи.

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

Есть средний класс – 7B–30B и около того. Это уже более серьёзные модели, которые умеют писать приличные тексты, держать длинный контекст, помогать с кодом, решать задачи анализа и генерации.

А есть большие модели – 100B–200B и выше. Вот тут уже начинается тяжёлая артиллерия. Такие модели лучше справляются со сложным многошаговым рассуждением, тонким удержанием контекста, работой на широком массиве тем, генерацией более качественного текста, кода и объяснений. Но за это приходится платить железом, деньгами и инфраструктурой. Это уже не «поставил вечерком на ноутбук», а отдельная взрослая история.

Важно: большая LLM-модель не всегда нужна. Если вам надо разбирать входящие заявки по типам, выделять реквизиты из акта или помогать оператору с шаблоном ответа, то тащить чудовище на 200B параметров – это как ездить за хлебом на карьерном самосвале. Впечатляет, конечно, но обескураживает.

В реальной работе почти никогда не бывает «просто LLM». Её обычно «обвешивают». Вот несколько простых формул.

1. Вам нужен простой чат для помощи работнику
LLM от 15B-30B + память = ассистент, который помнит контекст. Он помнит историю диалога, имеет общие представления о мире.

2. Вам нужен профессиональный ассистент для команды или работника.
LLM от 30B параметров и выше + RAG + инструменты работы с файлами + память = вопрос-ответ по вашим знаниям

Здесь RAG – это Retrieval-Augmented Generation. Если переводить на «человеческий» язык, это генерация текста, дополненная поиском. Такие системы переводят файловый массив в систему смыслов и умеют их извлекать по запросу.

3. Вам нужен агент, выполняющий конкретную операцию
Ой, здесь всё не просто. Это тема большая и отдельная. Потребуются детали – пишите, отдельно отвечу. Но если кратко, то вам нужен полный управленческий контур.

На чём всё обычно ломается? Не на «слабой модели», как потом удобно рассказывать, а на куда более скучных вещах:
– исходные данные плохие: документы не структурированы, термины плавают, написаны как поток сознания уставшего растамана с Ямайки, а потом все удивляются, что RAG «не видит смысл». Но трудно извлечь смысл там, где его нет. И на практике это самая частая проблема;
– задачу не разложили: хотят от одной LLM сразу и классификацию, и экспертизу, и генерацию, и принятие решений;
– не собрали контур: нет нормальной памяти, файлов, правил, маршрутизации, инструментов и контроля ошибок;
– не понимают цену ошибки: где-то можно терпеть «примерно правильно», а где-то одна галлюцинация модели уже превращается в убыток, конфликт или управленческий цирк.

Именно поэтому большинство неудач с ИИ – это не «нейросеть тупая», а «люди опять накуралесили».

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

Мне нужен просто ответ – или работа с моими файлами, памятью и инструментами? Я хочу помощь человеку – или хочу встроить ИИ в процесс?

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

По теме ИИ осталось только два не закрытых вопроса – мульти-агенты и оркестраторы. Закроем их и вернёмся к производительности и автоматизации. Если только вы не подкините вопросов или тем для обсуждения.

Хороших вам выходных!

#ИИавтоматизация #ИИ

Поговорим об ответственности ИИ

Вопрос подписчика:
«Любопытно как ИИ может отвечать за результат?»

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

С юридической точки зрения всё довольно просто – ИИ не является субъектом права. Он не может (пока) сам нести ответственность за ущерб, ошибку, нарушение обязательств или дефект решения.
То есть за юридические последствия деятельности отвечает компания, которая использует ИИ.
За организацию процесса и контроль – руководитель функции/процесса или руководитель организации.
За дефект самого инструмента – вендор или поставщик услуг. Но обычно это определяется договором, SLA и урезано ограничениями ответственности.

Сам ИИ в юридическом смысле ни за что не отвечает.

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

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

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

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

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

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

Стоп! А разве всё это не нужно исполнителю-человеку? Разве не об этом мы говорили, когда пытались поднять скорость потока, сократить WIP и убрать провалы качества?
Опаньки! 🤷🏼‍♂️

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

Поэтому вопрос надо ставить не «может ли ИИ отвечать?», а «есть ли у нас вообще управление, в котором на ком-то замкнут результат?». Если такого контура нет, человек будет косячить гораздо сильнее любой нейросети. А если есть, то уже почти неважно, сделан он из мяса или из кода.

Хорошей вам недели!

#ИИ #ИИавтоматизация #производительностьтруда

Агент, мульти-агент и оркестратор

Продолжаем наводить порядок в терминологии. После слов LLM, RAG и прочей цифровой нечисти обычно начинается новая путаница. Любую систему с ИИ начинают называть агентом. А если таких систем две – уже «мульти-агентная платформа». Иногда, правда, это просто чат, которому выдали бейджик и внушили чувство собственной важности.

Давайте по-человечески.

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

Теперь следующий уровень – мульти-агент. Это не «один агент потолще», это система, где несколько агентов делят работу между собой по ролям.

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

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

Простой пример – подготовка коммерческого предложения клиенту.
Один отдельно взятый агент может решать только свою конкретную задачу:
– расшифровать (транскрибировать) интервью с клиентом;
– составить перечень требований из расшифровки;
– сверится с базой данных по продуктам;
– найти решение проблемы клиента;
– написать черновик текста;
– редактировать структуру и логику;
– корректировать язык, ошибки, повторы;
– верстать материал в нужный формат;
– проверять соблюдение требований по стилю, объёму, оформлению;
– извлечь адрес клиента и отправить e-mail.

То есть, мы не обращаемся к одной большой LLM с просьбой «вот запись разговора, сделай КП в pdf и отправь его». Мы разбиваем процесс на шаги, каждый из которых может быть решен без применения «тяжелой артиллерии». Каждый агент решает свою задачу, а вместе они работают лучше, чем одна большая модель, которую заставили сразу и сочинять, и редактировать, и корректировать, и оформлять. Это как пытаться одним очень талантливым сотрудником заменить целый отдел. Иногда можно. Но обычно дорого, нервно, с перекосами и многократными переделками.

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

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

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

Но оркестратор – это не только логика маршрутизации. В более взрослой архитектуре он ещё может знать, где физически размещён нужный агент, на каком сервере, в каком контуре или узле его лучше запускать. А это уже важно для multi-server организации: балансировки нагрузки, скорости, отказоустойчивости и безопасности, а не «пусть всё живёт где попало»

Главный вывод очень практичный. Когда вы слышите слова «мы строим агентную систему», нужно сразу задавать три вопроса:

1. Какая у агента роль?
2. Какой у него вход и выход?
3. Кто управляет последовательностью, проверками и эскалациями?

Если на это нет ответа, то перед вами, скорее всего, не агентная архитектура, а маркетинговый стендап.

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

Это должен делать один «супер-агент 007» или здесь естественным образом напрашивается мульти-агентная схема с оркестратором?

Вот это и будет первый взрослый шаг от разговоров «про ИИ» к нормальному проектированию.

Хорошего дня!

#ИИ #ИИавтоматизация

Возвращаемся к производительности

Поздравляю, ликбез по ИИ мы с вами закрыли!

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

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

Раньше что было, нарисовали километровую портянку в EPC или BPMN, написали регламент на 40 страниц, провели 100500 согласований, и интегратор пошёл героически внедрять это в систему. Со скрипом, матом, но на почасовой ставке ему было терпимо. В принципе, все при деле, все довольны.

Для классической автоматизации это ещё как-то работало. Плохо, тяжело, но работало. Для ИИ – нет, не работает. Почему?

Во-первых, для ИИ процесс должен отражать суждение.
А суждение – это не «мнение начальника» и не «Маша знает, как правильно». В ИИ-контексте это микро-решение внутри операции: понять контекст, вкурить задачу, найти решение, сопоставить его с нормой, оценить риск, выбрать следующий шаг и уметь объяснить почему именно так. Если суждение воспроизводимо, его можно передавать машине. Если нет – оставляем человеку.

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

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

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

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

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

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

Нужно учиться другому:
– видеть в процессе не только действия, но и суждения;
– резать работу до уровня, где можно задать контекст, вход, выход и DoD;
– мыслить не «от согласования», а «от эскалации»;
– и проектировать не бумагу, а исполняемый контур.

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

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

Попробуйте уложиться в ~1000 символов. Ладно, для славянских языков в 1150.

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

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

Хорошего вам дня!

#ИИ #ИИавтоматизация #производительностьтруда