Как ИТ-хаос сжирает вашу прибыль? Разбор бизнес-романа «Проект Феникс» В управлении обычно ищут большие причины потерь. Плохие проекты. Ошибки стратегии. Неверные инвестиции. Но значительная часть потерь возникает в другом месте — в том, что не видно как отдельная проблема. В повседневной работе системы всегда существует слой незапланированной активности. Он не попадает в планы, не учитывается в бюджетах и почти никогда не обсуждается как отдельная категория. Однако именно он определяет, сколько энергии остаётся у организации на развитие. Каждый неожиданный инцидент, каждая срочная правка, каждое переключение внимания разрывает последовательность стратегической работы. И чем больше таких разрывов, тем меньше вероятность, что долгосрочные инициативы будут доведены до результата. Поэтому производительность системы определяется не только тем, сколько работы она делает. Но и тем, сколько незапланированной работы она вынуждена постоянно поглощать. Возможно, главные потери бизнеса происходят не из-за неправильных проектов, а из-за того, что у системы не остаётся времени на правильные. Подробнее эта идея разбирается в подкасте: www.youtube.com/...sro
Александр Пономарев | Управленческий дневник
Архитектор решений: Калькулятор реальности или как ИТ-архитектура спасает (или топит) ваш бизнес? Разбор книги Саурапха и Ниланжайри Шривастава «Solutions Architect» (2025). В сложных организациях редко ломаются технологии. Чаще ломается согласование между тем, как система устроена, и тем, как её представляют. Архитектор решений находится именно в этом разрыве. Он работает не с кодом и не с бизнесом по отдельности, а с ограничениями, которые возникают между ними. Любая система живёт в балансе трёх параметров: стоимость, время и риск. И любое решение — это не улучшение одного из них, а перераспределение напряжения между всеми тремя. Поэтому архитектура почти никогда не про «правильную форму». Она про цену выбора. Когда этот баланс нарушается, система начинает вести себя непредсказуемо. Технически правильные решения могут разрушать экономику продукта. Экономически выгодные — увеличивать операционные риски. Быстрые — создавать долгосрочную хрупкость. Возможно, роль архитектуры заключается не в том, чтобы строить идеальные системы, а в том, чтобы честно фиксировать стоимость каждого компромисса. Подробнее эта идея разбирается в подкасте: www.youtube.com/...jc8
Цена первой реакции О киберинцидентах обычно говорят как о технической проблеме. Но самые тяжёлые последствия нередко возникают не из-за самой атаки, а из-за первых решений после её обнаружения. Когда система перестаёт работать, естественное желание — как можно быстрее всё восстановить. Однако действия, которые кажутся правильными с точки зрения эксплуатации, могут уничтожить информацию, необходимую для расследования, юридической защиты и понимания реальных причин произошедшего. Получается парадокс. Попытка быстрее вернуть систему в рабочее состояние иногда делает ущерб значительно больше, чем сама атака. Поэтому киберинцидент — это не момент, когда ИТ-служба начинает ремонт. Это момент, когда одновременно сталкиваются интересы бизнеса, безопасности, права, репутации и непрерывности процессов. В такие ситуации компания входит с теми правилами, которые были определены заранее. Во время кризиса их уже не создают — ими пользуются. Возможно, зрелость системы безопасности проявляется не в способности остановить каждую атаку, а в способности не усугубить её последствия собственными действиями. Разбор книги «Реагирование на инциденты и компьютерная криминалистика»: www.youtube.com/...s9e
Почему ИИ-подписки заводят разработку в тупик: Конец классического IT-менеджмента Долгое время управление строилось вокруг одного принципа. Кто-то формулирует задачу, кто-то её реализует, кто-то проверяет результат. Эта цепочка выглядела естественной и почти незыблемой. Но в системах с агентной логикой часть этой конструкции начинает исчезать. Исполнение перестаёт быть ручным процессом, требующим постоянного контроля и распределения задач между людьми. Оно уходит в среду, где действия выполняются автоматически, а человек всё меньше участвует в самой реализации. В центре остаётся другой слой — формирование намерения. Не «как сделать», а «что должно быть достигнуто». Это смещение меняет саму природу управления. Контроль исполнения теряет прежнюю ценность, потому что исполнение становится распределённым и частично автономным. В такой системе ключевым становится не управление действиями, а управление смыслом действий. Возможно, граница между управлением и исполнением начинает проходить не по людям и ролям, а по разрыву между намерением и реализацией. Подробнее эта идея разбирается в подкасте: www.youtube.com/...ojm
Шум вместо знания Кажется логичным, что чем больше данных собирает организация, тем точнее становятся её решения. На практике эта зависимость работает далеко не всегда. С ростом объёма информации увеличивается не только количество полезных сигналов, но и количество случайных закономерностей. Они выглядят убедительно, пока не приходится принимать реальные решения. Поэтому ценность аналитики определяется не тем, сколько данных удалось накопить, а тем, насколько удалось отделить главное от второстепенного. Иногда один устойчивый показатель говорит о состоянии системы больше, чем сотни детализированных отчётов. В этом и заключается парадокс цифровой эпохи. Ограничением становится уже не дефицит информации, а способность распознавать действительно значимые связи. Получается, что самые зрелые системы анализа не стремятся увидеть всё. Они стремятся не потерять то немногое, что действительно имеет значение. Возможно, качество управления определяется не количеством данных, а количеством шума, который удалось исключить до принятия решения. Разбор книги Стивена Брантона (Steven Brunton) и Натана Куца (Nathan Kutz) под названием «Data Driven Science and Engineering»: www.youtube.com/...cfw
Иллюзия контроля | Концепции сквозной наблюдаемости (end-to-end observability) В сложных системах знание и понимание — не одно и то же. Можно собирать огромное количество данных, видеть десятки показателей и регулярно получать отчёты. Но при этом плохо понимать, что на самом деле происходит внутри системы. Проблема в том, что показатели обычно отвечают на вопрос «что произошло». А самый важный вопрос часто звучит иначе: «почему это произошло». Чем сложнее организация, тем больше расстояние между событием и его причиной. Сбой может возникнуть в одном месте, а проявиться совсем в другом. Решение, принятое несколько месяцев назад, способно повлиять на результат только сейчас. Поэтому большое количество информации ещё не гарантирует ясности. Иногда наоборот — данные создают ощущение контроля именно в тот момент, когда понимания становится меньше. Настоящая сложность управления заключается не в дефиците информации, а в способности увидеть связи между разрозненными событиями. Возможно, зрелость системы определяется не количеством показателей, а тем, насколько быстро она способна объяснить сама себе причины происходящего. Подробнее эта идея разбирается в подкасте: www.youtube.com/...qrq
