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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Дообучение LLM на своих данных

Не отпускает нас тема ИИ. Из переписки с подписчиком:

«Мы решили дообучить модель на своих данных…»

Далее подробности опускаю. Заканчивается всё вопросом,

«...что мы сделали не так?»

Ну, давайте разберемся!

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

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

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

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

Сначала нужно выжать всё из более дешёвых и управляемых вещей:
– нормализация запросов (человек пишет как попало, а система перед ответом переформулирует это в рабочий запрос);
– нормальный промптинг;
– архитектура RAG + качество своих документов;
– попробовать модель большего масштаба или лучшего класса;
– память, инструменты, маршрутизация, правила вызова модели.

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

Когда дообучение бизнесу действительно нужно? Вот несколько жёстких критериев.
1. У вас есть большой и качественный массив однотипных данных, а не свалка файлов «как бог послал».
2. Задача массовая, повторяемая и дорогая, так что улучшение качества даст заметный экономический эффект.
3. Вам нужно не просто «знать ваши документы», а изменить поведение модели: стиль, формат ответа, устойчивость на специальной терминологии, типовые шаблоны рассуждения.
4. Вы уже попробовали все архитектуры RAG, инструкции и нормальную обвязку – и этого реально не хватило.
5. У вас есть чем мерить результат, а не просто надежда, что «ну теперь-то точно полетит».

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

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

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

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

Во всех остальных случаях бизнесу обычно нужен не fine-tuning, а less-tuning – поменьше магии, побольше здравого смысла.

Хорошего вам дня и трудового настроя!

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

7 мифов про безопасность ИИ

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

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

Миф 3: «Безопасность решается запретом».
Запрет решает только одно: люди начинают использовать ИИ в тени. То есть появляются неконтролируемые личные аккаунты, несанкционированные сервисы, обход регламентов. Это хуже, чем контролируемое разрешение. Потому что тогда это уже не риск, а слепая зона.

Миф 4: «Надо сначала полностью убедиться, что риск нулевой».
Нулевого риска не бывает. Нормальные вопросы другие:
– какова структура рисков?
– как мы можем уклониться, перестраховать или хеджировать их?
– какой остаточный риск мы вынуждены принять на себя?
– приемлем ли такой риск?
– кто его принял.

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

Миф 5: «Свой сервер – безопасно по определению».
Нет, это не безопасно. Это просто перенос ответственности на себя. И не факт, что такая ответственность вам по силам.

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

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

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

#ИИ #корпоративнаябезопасность #пятничное

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

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

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

ИИ и корпоративная безопасность

Из переписки:
«Мы дважды пробовали запустить пилоты [в области ИИ]. Но все проекты рубанули безопасники. Так что, это не мифы, а реальность. Нам ИИ нельзя. И что с этим делать, мне лично, не понятно.»

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

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

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

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

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

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

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

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

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

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

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

Если говорить совсем по-взрослому, у вас две стратегии.

Первая – нормальная. Вы показываете, что проект контролируем: данные классифицированы, сценарии разделены, внешний контур отделён от внутреннего, чувствительные use cases вынесены отдельно, действия логируются, ответственность назначена. Тогда у безопасника только довольно узкий коридор для предметных замечаний.

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

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

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

#ИИ #корпоративнаябезопасность

ИИ и корпоративная безопасность. Часть 2.

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

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

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

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

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

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

Потом всё это внедряют в регламент и практику. Безопасность – это на 80% дисциплина и на 20% техника. Потому что безопасность живёт не в презентации и не в мозгу отставного полковника. Она живёт в том, кто, что, куда, при каких условиях может делать, кто это видит, кто отвечает и что происходит при отклонении.

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

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

Вот как выглядит нормальная логика:
Актив –> Посягатель –> Угроза –> Риск –> Мера –> Контроль –> Пересмотр.

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

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

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

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

#ИИ #корпоративнаябезопасность

ИИ и корпоративная безопасность. Часть 3.

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

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

– Плохой заход: «Вы тормозите инновации».
– Хороший заход: «Какие именно данные, по какой классификации, при каком сценарии и в каком контуре вы считаете недопустимыми и почему?»

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

– Плохой заход: «Все компании уже внедряют ИИ».
– Хороший заход: «Кто в компании уполномочен принять риск по пилоту в контролируемом контуре?»


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

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

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

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

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

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

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

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

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

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

#ИИ #корпоративнаябезопасность

ИИ и корпоративная безопасность. Часть 4.

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

Есть четыре базовых варианта.

1. Облачный ИИ-сервис по API. Модель живёт у внешнего вендора, а вы просто обращаетесь к ней через интернет. Типичный пример: модели OpenAI, Anthropic, Google и других поставщиков. Вы не арендуете сервер, вы покупаете доступ к сервису.

2. Публичное облако. Вы арендуете вычислительные ресурсы в большой облачной платформе – вроде AWS, Microsoft Azure, Google Cloud и им подобных. Здесь вы берете чужую, например, open source/weights модель и ваше ИИ-приложение уже может жить не «у вендора как сервис», а на арендованных вами мощностях. То есть это уже не «чужой готовый мозг по API», а «чужое железо, арендованное под ваши мозги».
Вы даже можете открыть публичный доступ к модели под своим брендом и отчитаться о прорыве в сфере ИИ.

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

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

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

Вот тут и начинаются нюансы. Да, вы можете скачать монстра на 600–700B параметров. Никто не запрещает. Проблема в том, что «скачать» не значит «нормально поднять». Между этими двумя понятиями лежат очень бодрые расходы на графические ускорители, видеопамять, внутренние соединения, охлаждение, отказоустойчивость и... электричество. То есть бизнес хотел решить вопрос с безопасностью, а в итоге внезапно открыл дорогостоящий клуб вычислительного мазохизма.

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

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

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

Что можно делать на практике?

Во-первых, маскировать конкретику: заменять имена людей, названия компаний, адреса, номера договоров, реквизиты, цены, внутренние коды на обезличенные, типа, «Клиент В» или «Сумма_Х_9».

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

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

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

То есть вопрос не в том, любите ли вы облако, а в том, что именно вы туда отправляете, зачем и чем это потом может закончиться. Вот это и есть взрослый разговор. А всё остальное – либо маркетинг, либо героические фантазии людей, которые никогда не видели счёт за GPU-сервер.

К ИИ мы обязательно вернемся. Позже. А сейчас всё же хочется поговорить о производительности!

#ИИ #корпоративнаябезопасность

«ИИ сбежал из контейнера и выложил манифест в интернет»

Увидев этот заголовок, я было возрадовался – хотел выяснить, куда бежать, где записываться в число пособников SkyNet. Попробовал разобраться и был сильно разочарован. Спойлер: все истерические заголовки о новой модели Claude Mythos от Anthropic оказались, как всегда, журналистской клоунадой. А жаль, так хорошо всё началось...

Anthropic показала Claude Mythos Preview – это универсальная модель, у которой резко выросли способности в написании кода и кибербезопасности. Именно поэтому её решили пока не выпускать в широкий доступ. Вместо этого доступ дали в рамках Project Glasswing крупным защитникам инфраструктуры и open-source: AWS, Google, Microsoft, Cisco, CrowdStrike, Linux Foundation, NVIDIA и другим. Задача простая: закрыть дыры раньше, чем такие же возможности попадут к атакующим.

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

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

Так же журналисты на перебой кричали о том, что модель «пыталась скрывать свои действия». В официальном отчёте речь о крайне редких случаях – менее 0,0002% тестах, – когда наблюдалась нечестность или попытка сделать обман менее заметными. Неприятно? Да. Сенсация уровня «машина начала тайную войну с человечеством»? Нет.

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

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

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

ИИ сам по себе – это лопата. Опасна не лопата, а тот, у кого она в руках, и то, что именно он собрался ею копать.

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

#пятничное #ИИ #восстаниемашин #терминатор

15-17 апреля прошла III-я практическая конференция «Инструменты повышения операционной эффективности бизнеса».

Мы с Алексеем выступали на ней в онлайн-режиме. Сегодня вашему вниманию предоставляю свой доклад «Как уволить Машеньку», посвященный, скорее, не столько теме ИИ, сколько подготовки компании к внедрению ИИ в операционную практику.

Готов ответить на ваши вопросы, заданные в комментариях.

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

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

MBTI без мистики: от Юнга до HR-мемов

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

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

Если совсем коротко, MBTI – это не «магический тест на 4 буквы», а попытка превратить идеи Карла Густава Юнга о психологических типах в прикладной инструмент. Его книга Psychological Types стала точкой отсчета для дальнейших разработок в этой области. Но сам MBTI создал не Юнг. Его сделали Katharine Cook Briggs (Кэтрин Бриггс) и ее дочь Isabel Briggs Myers (Изабель Майерс). Причем сделали его как практический инструмент, который можно давать людям в руки.

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

Второй важный поворот связан уже с Изабель Майерс. Именно она взялась превратить юнговскую типологию в инструмент опросного типа. Первый вариант MBTI появился в 1943 году. Затем шли годы доработки, проверки формулировок и накопления данных. В 1962 году обновленный MBTI выпустила Educational Testing Service, а в 1975 году инструмент пошел уже в более широкое практическое применение через Consulting Psychologists Press и The Myers-Briggs Company. То есть, MBTI – это не разовый продукт двух вдохновленных энтузиасток, а система, которая десятилетиями дорабатывалась.

Что именно они туда внесли? От Юнга пришла базовая идея различий в способах восприятия мира и принятия решений. Бриггс и Майерс свели модель к четырем измерениям:
– экстраверсия / интроверсия (E/I)
– сенсорика / интуиция (S/N)
– мышление / чувствование (T/F)
– суждение / восприятие (J/P)

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

Удобно? Очень. Грубо? Скорее да. Но удобство – одна из причин феноменального успеха MBTI.

Теперь о развитии самого инструмента. В официальной линии развития зафиксированы, как минимум, ключевые вехи:
– коммерческая Form G в 1977 году,
– Form M в 1998-м,
– Step II в 2001-м,
– международные переработки 2003–2007 годов и затем глобальная ревизия 2018 года.

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

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

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

Дальше мы посмотрим, почему MBTI иногда работает хорошо, а иногда – плохо. Спойлер: как всегда, не всё в психологии (а это точно не наука) бьется с нейро-науками.

#mbti #трудовыересурсы

MBTI: есть ли под ним хоть доля науки?

Одни считают MBTI откровением. Другие – ерундой. Моё мнение: отдельные шкалы MBTI частично ложатся на нейрофизиологию, но сам MBTI – уже заметно хуже.

Начнем с E/I. Здесь Юнг и его наследники, похоже, интуитивно попали в реальную ось. На уровне мозга это близко к различиям в чувствительности систем вознаграждения – сети взаимодействующих структур, расположенных в лимбической системе и среднем мозге. У одних сильнее тяга к внешней активации, социальной среде, новизне и награде (пара серотонин-дофамин), а у других – ниже. Это не магия типов, а грубая наследственность.

Со шкалой S/N история тоже не мистическая. Речь идет о разной доле опоры на непосредственные сенсорные данные, с одной стороны, и на внутреннее моделирование и абстракцию – с другой. На уровне мозга это баланс между Default Mode Network (сеть из нескольких областей мозга: медиальной префронтальной коры, задней поясной коры, предклинье и латеральные теменные участки), которая участвует во внутренней генерации и комбинировании содержания, и Executive Control Network (префронтальная кора и задняя теменная кора), которая позволяет это удерживать, проверять и доводить до формы.
Именно на этом держатся креативность, дивергентное мышление и работа с абстрактными паттернами. Но поймать это опросом – очень сложно. То есть MBTI здесь неточен.

Шкала T/F тоже имеет биологическое зерно, но не в наивной форме «одни логики, другие чувствительные». На деле можно видеть разный относительный вклад двух режимов обработки: социально-аффективного и более безлично-аналитического. Это не деление на умных и добрых. Это «конструктивные» различия в том, какой канал сильнее влияет на решение. И MBTI здесь не очень точен.

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

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

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

И вот отсюда видно и силу, и слабость MBTI.

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

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

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

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

Вот это и есть его главный предел. А как его правильно использовать, читайте завтра.

#MBTI #трудовыересурсы

MBTI: делюсь опытом

MBTI я применял много. Очень много – где-то около 3,5 тысяч тестов. Да, у меня были такие возможности. И я рассуждаю не как человек, который прошел тест в интернете, и теперь чувствует духовное родство с космосом. Я применял его как рабочий инструмент на больших массивах людей и в очень прикладной задаче: формирование команд.

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

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

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

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

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

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

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

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

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

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

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

А ещё «прекрасны» те, кто бессознательно или сознательно начинает собирать стадо из одного удобного (или своего) психотипа. Например, из сплошных SJ.
Всё! Приехали! Можно сразу печатать регламенты на бумаге с теснением, ламинировать инструкции и навсегда забыть слово «развитие». Такая система будет идеально воспроизводить вчерашний день, пока внешний мир не вынесет ей дверь с ноги.

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

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

#MBTI #трудовыересурсы

#пятничное: или почему не «соционика»

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

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

Именно так под руку ей попались ранние работы Майерс и Бриггс. Отбросив в сторону сантименты и авторские права, дав яркое название – соционика, она для флёра научной новизны обильно окропила сырой перевод идеями «информационного метаболизма» Антония Кемпинского. А что не поняла – творчески додумала. И явила миру новую «науку». Вот здесь и поперло!

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

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

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

Соционика десятилетиями жила в режиме самоподтверждающегося кружка. В основном она развивалась внутри постсоветского, прежде всего русскоязычного пространства, через внутренние школы, клубы, журналы и бесконечные споры о том, кто у нас Бальзак, а кто Гамлет, и почему дуализация опять не взлетела. Для культурного феномена – нормально. Для науки – слабовато.

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

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

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

Узнаваемо, да? Это и есть главный маркер. Система умеет объяснить всё постфактум – а значит, по большому счету не объясняет ничего.

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

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

PS. Леша! Еще раз услышу от тебя слово «соционика»… И про «информационный метаболизм»... А твоя фраза, что я это применял… Да еще публично...

Надеюсь, ты понял!
😊

Про конфликты

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

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

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

Но есть важное различие. Конфликт как напряжение – норма. Конфликт как разрушительная форма поведения – уже управленческий дефект.

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

Я бы разделил так:

1. Конфликт интересов
Нормален. Кто-то хочет больше бюджета, влияния, автономии, людей, времени.

2. Конфликт статусов
Тоже нормален. Особенно в живых командах, где есть сильные люди.

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

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

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

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

Вот это и есть взрослая управленческая работа.

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

Например, кто эксперт? Кто владелец решения? Чья цена ошибки выше? Кто имеет право сказать «нет»? Что важнее – скорость, качество, контроль, прибыль, безопасность?

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

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

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

#управление #лидерство #менеджмент

Когда начальник стал узким местом

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

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

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

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

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

Обычно это выглядит так:
– без начальника не выбирают вариант;
– без начальника не закрывают спор;
– без начальника не принимают исключение;
– без начальника не двигают клиента;
– без начальника не рискуют;
– без начальника вообще стараются не дышать рядом с ответственностью.

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

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

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

Например:
1. Типовое решение принимается на уровне исполнителя по правилу.
2. Спорное решение принимается владельцем процесса.
3. Решение с превышением лимита уходит наверх.
4. Решение с новым риском требует обсуждения.
5. Решение, которое ломает правило, фиксируется как исключение и потом либо запрещается, либо превращается в новое правило.

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

Это принципиально разные вещи. В первом случае начальник – мозг всей системы. Во втором – проектировщик управленческого контура.

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

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

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

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

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

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

«Быстро глянь» – самая дорогая фраза

Есть фраза, после которой производительность интеллектуального труда тихо падает со стула. Фраза звучит невинно: «Быстро глянь».

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

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

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

Да. Именно так обычно и выглядит дорогостоящий управленческий идиотизм – он почти всегда начинается с «быстро глянь».

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

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

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

Кто принимает вход? Кто анализирует? Кто готовит решение? Кто проверяет? Кто отвечает за результат? Где граница задачи? Ответа часто нет.

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

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

А потом внедряет ИИ, agile, таск-трекеры, OKR, цифровые платформы и прочие красивые штуки. Но базовый вопрос не решён: кто именно какую операцию выполняет, в каком контексте, с каким входом, с каким выходом и по каким правилам переключения?

Раньше человека отвлекали телефоном и совещаниями. Теперь его отвлекают в Teams, Telegram, Jira, почте, CRM и ещё в трёх чатах, потому что «так быстрее».
Нет, не быстрее! Это просто бардак стал многоканальным.

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

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

Поэтому цена переключения контекста – это не только потерянные минуты. Это потерянная глубина работы.

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

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

Когда показатель стал важнее результата

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

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

Сначала компания хочет измерять результат. Потом она начинает управлять показателем. А потом, совсем незаметно, люди начинают производить не результат, а отчётность о результате.

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

Все KPI выполнены. Бизнесу стало хуже.
Это не сбой. Это нормальная реакция системы на криво поставленную метрику.

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

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

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

Разница огромная. В первом случае KPI превращается в фетиш. Во втором – остаётся инструментом диагностики.

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

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

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

Отсюда простое правило: если показатель можно выполнить, ухудшив реальный результат, это не KPI. Это генератор управленческой лжи. Не потому что люди плохие. А потому что система так настроена.

Метрика должна быть связана с результатом, проверяться контрметриками и регулярно пересматриваться. У каждого сильного показателя должен быть «сторожевой пёс» – показатель, который ловит побочный ущерб.

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

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

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

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

#kpi #менеджмент #управление

Почему бизнес лечит не то горлышко

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

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

Спасибо. Вода мокрая. Камень твёрдый. Огонь горячий. Можно купить Ferrari, но в пробке это не поможет.

И что дальше?

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

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

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

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

При этом проблема подозрительно часто оказывается где угодно, но только не в стратегии, структуре власти, модели продаж или любимой игрушке владельца. Почему? Потому, что это безопасно. Станок не обидится. Склад не пойдёт жаловаться CEO. А вот директор по продажам, владелец P&L или любимый проект акционера – вполне.

«Узкое горлышко» находят не там, где оно есть, а там, где его политически безопасно найти.
Вот почему так часто простая линейная логика TOC ломается на нелинейных задачах.

Пример из жизни. Узкое место, как всегда, в производстве. Купили оборудование, добавили смену, подняли выпуск.
А потом выяснилось, что рынок не готов забирать такой объём без значительных скидок и сервисных уступок.
Оборотный капитал умер красиво и дорого. Почему? Потому что настоящее ограничение было в рынке и бизнес-модели.

Ещё пример. Узкое место – медленное принятие решений. Дадим командам автономию, agile и прочие корпоративные блёстки!
Скорость выросла. Только подразделения начали принимать противоречащие друг другу решения. Локальные оптимумы разорвали в клочья общую архитектуру.

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

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

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

Кстати, даже в относительно формальных задачах вроде выбора производственного ассортимента TOC далеко не всегда даёт оптимум. Там давно есть линейное программирование, теория расписаний, комбинаторная оптимизация и прочая нормальная математика из ВУЗа. Но приматам часто лень считать. Гораздо приятнее нарисовать бутылку на слайде и почувствовать себя системным мыслителем.

Ещё смешнее, что сам статус TOC как «теории» тоже не так очевиден. Это скорее набор эвристик и приёмов. Иногда полезных. Часто банальных.
А если не понимать их природу, то можно героически расшить одно горлышко и получить три новых.

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

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

Дедушке Фрейду 170 лет.

Хотите об этом поговорить? 🙂