Отличная новость, друзья!

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

Предзаказ книги:
— книга с автографом –  3000₽
— книга с pdf-классификатором бизнес-процессов CoreStream – 3900₽

Электронные версии по-прежнему доступны.

По всем вопросам – @AIgnatyuk

CoreStream: Performance Indicators представляет собой методологическое руководство по построению системы показателей для архитектурных моделей бизнес-систем. Основанный на принципах объектно-ориентированного подхода (ООП), он предлагает универсальные шаблоны метрик, применимые к бизнес-объектам, методам (процессам), связям, отношениям и способам выполнения работ. Методика позволяет формировать наблюдаемую и управляемую архитектуру, обеспечивая прозрачность, сравнимость и системность в оценке работы бизнес-системы.

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

До 6 апреля со скидкой 10%

Методическое руководство по ООП в моделировании бизнес-систем

Первое руководство для бизнес-аналитиков и бизнес-архитекторов по практическому применению объектно-ориентированного подхода готово!

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

Объектно-ориентированный подход идеально подходит для задач, где:

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

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


Доступен в магазине с 15% скидкой в течение недели.

Из личной переписки:

«Класс! Взять ООП с инкапсуляцией, наследованием, полиморфизмом, применить этот подход для целей моделирования бизнеса, а потом зашить обратно в софт – шикарная оптимизация!

Вообще, и красота и потенциальная проблема таких подходов – опережение времени.

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

Ну, что тут скажешь… Всё возможно — особенно когда понимаешь, что многое из сегодняшнего «вдруг» начиналось как «а что если?» пару с лишним десятилетий назад. 🙂

Мой подход родился более 25 лет назад — из чисто практического интереса: как сэкономить время и деньги на проектах в сфере MC (Management Consulting). Он позволял не строить две отдельные модели («как есть» и «как должно быть»), не перелопачивать сотни страниц разрозненных диаграмм, от которых слёзы наворачивались и у консультантов, и у заказчиков. Всё было куда лаконичнее, точнее, а главное — переиспользуемо.

Но по-настоящему метод созрел недавно. Он стал мостом — нет, даже больше — «венчальным залом» 🙂 между MC-специалистами и их «вечными спутниками» из мира IT. Это была не просто интеграция — это было слияние смыслов. 🙂

И оно сработало!

Во-первых, скорость. Разработка бизнес-моделей ускоряется кратно — потому что у нас теперь не просто блок-схемы, а объекты с понятным поведением, связями, состояниями.

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

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

А дальше — начинается магия. Потому что всё это ложится в софт. Легко. Органично. Будь то новый формат ERP, цифровой двойник, симулятор бизнес-реальности или движок для быстрой трансформации компании или новый, например, инструмент моделирования бизнес-процессов. А почему бы и нет?! Хм... 🤔 🤫

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

Так что, быть может, мой ООП для бизнеса — это как раз та штука, которую стоит изучить сегодня, чтобы не вылететь из тренда завтра? Кто знает?! Хотите – обсудим!
🙂

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

(по мотивам выступления в Ижевске)

О чём мечтает среднестатистический предприниматель? Быть молодым, здоровым и красивым. А его бизнес? Усталый, перегруженный и замотанный.

Почему? Потому что он живёт в режиме RUN.

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

А есть ещё Change Management — и вот с ним начинается магия. Он не обслуживает день, он формирует завтра. Это то, что отвечает за рост, за смысл, за «молодость» бизнеса.

Я видел обе стороны. И был в RUN — с 89-го, когда всё делалось «на себе». Когда бизнес буквально мешал бухгалтерии сдавать отчётность. Когда за день ты становился и курьером, и саппортом, и переговорщиком, и айтишником. Тогда казалось: «ещё чуть-чуть — и наладится». Спойлер: не наладится.

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

Урок простой:
Если ты не управляешь изменениями — они придут сами. Только в менее удобной упаковке и с гораздо более высокой ценой.

5 шагов к изменению, которые можно начать уже завтра:

1️⃣ Пересмотри бизнес-модель. На одном листе. Кто твой клиент? Что ему важно? Как ты зарабатываешь? Попробуй изменить что-то одно!

2️⃣ Наведи порядок в архитектуре. Связи, роли, «узкие места» и особенно — «старые калоши». Удобные? Да. Но тормозят ли они?

3️⃣ Следи за трендами. Не надо быть пророком. Достаточно не быть слепым.

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

4️⃣ Создай проектный офис. Хоть из одного человека. Один документ. Один ритм. Один шаг — но осознанный.

5️⃣ И самое главное — не дай не сделать. Встречи. Ритм. Ответственность. И без фанатизма — никакой «бирюзы» и «бережухи» вместо здравого смысла.

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

Run Management — это не причина. Это следствие. Следствие твоего выбора меняться или нет. Хочешь управлять — управляй изменениями. Всё остальное — от Лукавого производная.

«Объектно-ориентированное моделирование бизнес-процессов: просто о сложном.»

ОТКРЫТЫЙ ВЕБИНАР

Мы разберёмся, как современные компании могут использовать объектно-ориентированный подход (ООП), чтобы сделать управление понятным, автоматизацию дешёвой, а процессы — прозрачными.

3 июля 2025 11:00 MSK (GMT+3)

🟢 Участие бесплатное.
🔴 Требуется предварительная регистрация.

Программа:
I. Что такое ООП и почему он всё чаще вытесняет классический процессный подход.
II. Что такое ООП в моделировании бизнеса.
III. Жизненный цикл объекта.
IV. Отношения и связи.
V. Как перейти на ООП-мышление без боли.
VI. Обсуждение кейсов и ответы на вопросы.


Данные по платформе будут позже.

Организовано при поддержке компании Современные Технологии Управления (Business Studio)

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

«В нашей компании процесс разработки конструкторской документации (КД) для производства конкретного заказа в разы длительнее, чем само производство данного заказа. В среднем жизненный цикл заказа составляет 24 месяца, из которых производственные процессы занимают всего 2-3 недели.»

Ошибка в организации процесса

Есть несколько вероятных причин, почему на разработку уходит в 10 раз больше времени, чем на производство:
— ваш главный конструктор окончил вуз после 1995-го, и про серийность слышал только в теории или вообще не слышал;
— или он – внедрённый агент конкурентов;
— или он просто не очень разбирается в масштабируемом инжиниринге.

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

Инженерная тайна: в мире, где правят ГОСТы, ОСТы, DINы и ISO уникальность встречается только в очень специфичных местах – науке или стартапах, или там, где это кому-то выгодно. Ну не поставщики же вы Большого Адронного Коллайдера... И даже в этом случае...

Рекомендация:

Шаг 1. Соберите архив проектов
Возьмите проекты за последние 3–5 лет, желательно в разрезе изделий или комплексов. Чем больше – тем лучше.

Шаг 2. Определите ключевые параметры изделий
Составьте перечень инженерных характеристик, которые определяют конструктив и исполнение. Например:
— напряжение/ток/мощность;
— тип среды (взрывоопасная, радиационно активная, агрессивная);
— климатическое исполнение;
— тип монтажа (шкаф, стойка, подземка);
— способ подключения (фланец, муфта, спецразъём);
— наличие доп. опций (мониторинг, сигнализация, защита, цвет и т.д.).

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

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

Оцените, сколько реально уникальных случаев, а сколько – «одно и то же, но в другой обёртке».

👉 Результат почти всегда один и тот же:
70–80% решений – это комбинации 3–10 конструктивов. Почему? Так природа устроена!

Шаг 4. Сформируйте набор типовых решений
Каждый устойчиво повторяющийся набор параметров превращается в типовое изделие или конфигурацию. Оно должно включать:
— конструкторскую документацию;
— шаблон ТЗ/ТУ;
— схемы подключения/эксплуатации;
— описания ограничений/допустимых вариантов адаптации.

Шаг 5. Постройте процесс адаптации
Оставшиеся 10–20% покрываются за счёт адаптаций типовых (для вашей компании в нише ее специализации) решений, а не «чистого листа». Более того, не факт, что это ваши целевые клиенты – иногда дешевле отказать, чем сделать – нужно считать.

Для этого:
— добавьте в типовые решения поля для параметризации (например: длина кабеля, тип корпуса, окраска, комплектация);
— введите инженерные правила адаптации;
— автоматизируйте рутинные части проектирования (например, через конфигураторы или шаблоны в CAD-системе);
— а главное – измените систему мотивации КБ на долго = без зарплаты. И уберите все их пустые вакансии, незаполненные более 6 месяцев – это «мертвые души», чей ФОТ «пилится» каждый квартал.

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

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

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

Применение ИИ в agile-исследовании бизнес-архитектуры: методы, ограничения, эффекты, риски – и немного здравого смысла

1. Я и agile – мы из разных вселенных.
Agile прекрасен, когда есть готовый продукт и требуется постоянная адаптация. Но исследование архитектуры – это не адаптация. Это системное мышление. Это работа с целостностью, не с фичами.

2. ИИ для бизнес-архитектуры? Звучит заманчиво. Но...
Если под ИИ мы понимаем LLM (типа ChatGPT), то, увы – это не тот инструмент. Почему?

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

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

Надежда, что «LLM сама догадается, что спросить» – утопия. Архитектура требует вопросов не из Википедии, а из логики бизнеса. А логика бизнеса живёт в методологии.

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

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

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

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

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

Ошибка в иерархии объектов

То, что вы называете «решением», на самом деле является комплексным продуктом, включающим в себя разные составляющие:
— изделия собственного производства,
— покупные компоненты,
— услуги (например, монтаж, обучение, аутсорсинг ТОиР и т.п.),
— финансовые инструменты (рассрочка, лизинг),
— страховые и сервисные предложения и т. д.
— и даже, например, «впечатления» (да, это отсылка к книге к шаблону ценностного предложения) – клубную карта «Клуб Любителей Электротехники».

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

И да, им нужно управлять!

Попробую помочь скоротать пятницу. Ещё каких-то 5-8 часов (вряд-ли у нас есть кто-то из Петропавловска-Камчатского) и начнется weekend.

А пока можно обсудить ещё один вопрос от подписчика:

«В Универсальном межотраслевом классификаторе бизнес-процессов версии 6.0 вы не выносите процесс «Управления качеством» на верхний уровень.
Объясните, пожалуйста, почему вы пошли по этому пути. Можно было бы «Управление качеством» вынести на верхний уровень? И какой объект управления был бы у этого процесса?»

Отличный вопрос – и, по сути, вы уже сами на него ответили: а какому бизнес-объекту соответствовал бы процесс «Управление качеством»?

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

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

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

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

Вот и подошла к концу очередная рабочая неделя. Но остался последний вопрос от подписчика.

«Как донести руководству»

Не хочу душнить темой управления изменениями, поэтому попробую ответить в стиле «хэш-тэг #пятничное».

Как донести идею изменений руководству?

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

И, наверное, это даже нормально. По крайней мере естественно.

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

А руководство спрашивает: «А где гарантия?»

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

Вот и думай, что отвечать!

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

А гарантия – она в ваших руках! Это ваша воля довести дело до конца. И не дать не сделать!»

Подумает руководство и пошлёт – спроси, мол, у аналитика. Ему же делать.

А аналитики скажут: «Что-то больно сложно это. Мы так не делали никогда».

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

А вот ИТ-шники спросят: «А нельзя было сразу так сделать?..» И в чем-то будут правы. Но по привычке начнут искать подвох. 😊

А подвох действительно есть – «просто на 1С» это не взлетит, и придется действительно пересмотреть архитектуру предприятия (не Business Architecture, а Enterprise Architecture). Но они не долго будет этому сопротивляться...

Примерно так и живем...😊

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

Закрывая тему прошедшего открытого семинара по ООП в моделировании бизнес-систем, выкладываю ссылки с материалами:
– запись трансляции на РуТьюб.
– запись трансляции на YouTube.
– pdf-презентация.
– методические материалы.
Спасибо всем, кто проявил интерес. Будут вопросы – задавайте!

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

С понедельником вас и началом новой трудовой недели!

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

Как перестать не спасать компанию

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

Если перевести с управленческого на человеческий – то это режим «ломай-круши всё подряд». Проекты – под нож. Маркетинг – в расход. Развитие – до свидания! Офисная бумага? Нарезаем на четыре. Туалетная? Стираем и сушим!

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

Разберёмся, где рвёт логику:

1. «Оптимизировать» нужно на подъеме, а не в кризис

Когда всё растёт — это как раз момент задавать жёсткие вопросы: а зачем нам этот проект? Чем занято оргразвитие?А нужен ли этот отдел? А окупится ли реклама?

Но в реальности происходит обратное. Пока деньги текут рекой, никто их не считает. А как только начинается шторм – начинается паника: «Срочно убираем всех, кто тратит – и оставим тех, кто только приносит!»

Проблема в том, что всё, что приносит – тратит. Просто по-другому.

2. Атаковать рынок нужно на спаде, а не в рост

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

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

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

3. Когда всё падает – думать надо. Быстро и трезво!

А теперь спросим руководство.

Вы последние 5–8 лет жили на автопилоте – бабло шло, рынок рос, всё было «тип-топ». Руководили вы этим? Да ну! Вы к этому не имели ну никакого отношения! Как минимум с управленческой точки зрения. Просто так совпало – ваше «чуткое руководство» пришлось на «рыночный чёс». А когда совпадать перестало, и настало время работать головой – упс!

И вот тут начинается самое интересное.

Что действительно надо делать в кризис

1. Считаем косты.
Прямо сейчас. Не в целом, не «по направлениям», а по процессам.
Ищем те, где постоянные издержки конкретного процесса составляют 30–40%+.
Зачем? Чтобы понизить точку безубыточности — это ключ к выживанию.
Не можете собрать затраты процесса? А чем вы раньше занимались?! Управляли?!

2. Переводим постоянные издержки в переменные.
Везде, где доля постоянных велика переводим их в переменные: аутсорсинг, аренда, почасовка, контракты с KPI — всё, что позволяет платить меньше, если работа стоит или нет нужной загрузки.
То есть, резать нужно не развитие, а операционку! Более того...

3. Не трогаем тех, кто может это сделать.
Вы хотите срезать оргразвитие и автоматизаторов? А кто вас будет спасать? Кто реализует то, что нужно делать сейчас! Они и есть те, кто вам сейчас нужен. И именно сейчас. Разберётесь с ними потом, на подъеме, если когда он наступит.

4. Запускаем реструктуризацию, автоматизацию, пересборку процессов. Причем, быстро!
То, что казалось «долгим и дорогим» в 2022-м, в 2025-м — вопрос выживания.

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

То есть это время начать делать то, за что вам платят – управлять!

А вы в это время что? Сидите и экономите на мыле в туалете?
Ну... удачи вам с этим!

Кризис – это время действовать. Действовать с умом. Даже если вокруг делают не так.

Кто понял — тот уже переходит в наступление. Остальные… скоро будут покупать у них.

С новой рабочей неделей вас!

С понедельником вас и началом новой трудовой недели!

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

А звучит он примерно так:
«Это всё здорово, но что делать с тем, что наработано непосильным трудом, за что уже получены зарплата и бонусы, что уже приняло и разделило руководство?»

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

Так вот, господа, это ваш сон, что хотите, то можно и сделать. А сделать можно как минимум:

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

Вариант 2. Использовать то, что наработано в качестве обширной библиотеки неупорядоченной и неструктурированной деятельности:

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

Всё! Вы переложили все «нажитое непосильным трудом» в ООП-структуру. Да, многое оказалось лишним, и не влезло ни в одну «лунку». Ну, так это здорово! Да, чего-то не хватало! Отлично, ведь вы умны, опытны и прозорливы, и всё вы восполнили!

Так что теперь ваш уровень профессионализма +100, карма +1000, и вы – монстр рока!
Поздравляю!

Примерно так...
🙂🤷🏼‍♂️

Почему «всё в одних руках» – это не про эффективность, а про катастрофу

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

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

Почему?

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

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

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

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

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

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

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

Хочешь «держать всё под контролем»? Тогда отпусти! Не сжимай всё в одном кулаке. Как говорил Цезарь, разделяй и властвуй! Разделяй роли, разделяй ответственность. И доверяй процессу – если он выстроен правильно.

Интересная новость для корпоративных разработчиков: OpenAI представила бесплатную языковую модель GPT-OSS — первую за шесть лет

GPT-OSS доступна в двух версиях: с 20 млрд и 120 млрд параметров. Для первой для работы требуется минимум 16 ГБ видеопамяти, а для второй — 80 ГБ. Эти бесплатные модели сравнимы с топовыми o3-mini и o4-mini, но уступают флагманской o3.

Протестировать GPT-OSS можно на отдельном сайте, а скачать на Hugging Face. На GitHub находится инструкция по запуску модели локально на ПК.

PS. Думаю теперь стоит ожидать новых прорывных продуктов от Сбер и Яндекс, расцвета продвинутого отечественного ИИ-ПО 🙂

Разрушение легенд: мозговой штурм

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

Звучит красиво. Проблема в том, что в реальности всё работает иначе.

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

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

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

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

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

Результат – иллюзия, что решение придумала вся команда. На деле оно родилось в голове одного человека ещё до встречи.

Что работает лучше? Вместо того, чтобы собирать «танцы с бубном», попробуйте другой подход:

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

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

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

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

Ключевые приёмы:
─ Вбросить свою мысль как «один из вариантов», не подавая её как финальное решение.
─ Задать несколько наводящих вопросов, чтобы участники сами начали развивать именно эту идею.
─ Поддерживать тех, кто высказывается в её пользу, и быстро сворачивать разговоры в другие стороны.

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

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

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

Классические методики управления изменениями уверяют нас: достаточно обучить команду, донести правильные смыслы и дать инструменты – и изменения заработают. Но если всё так просто, почему столько проектов разваливаются?

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

Но если посмотреть внимательнее, то чаще всего их уровень не хуже и не лучше среднеотраслевого. Эти люди умеют работать, знают своё дело и делают его на уровне коллег. Так в чём же загвоздка?

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

Это не всегда те, кто обладает:
— наибольшим опытом,
— стратегическим видением,
— профессиональными компетенциями.

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

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

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

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

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

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

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

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

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

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

А как у вас? Вы больше вкладываетесь в повышение квалификации команды или в работу с лидерами мнений?

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

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

Хороший вам трудовых будней!

Эволюция против революции

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

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

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

И вот что важно понимать.

История: революция всегда выигрывает. Все рыночные прорывы всегда были революцией.

IBM: пока компания делала революцию (BPR, PC XT), она была лидером. Как только увлеклась эволюцией – приверженность корпоративным стандартам и сложившейся культуре – скатилась вниз.

Alibaba не постепенно улучшал лавку, Uber не занимался постепенным улучшением сервиса такси, SpaceX не занималась устойчивым развитием, как и Tesla – все они не латали старое, а взрывали рынок новыми бизнес-моделями.

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

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

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

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

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

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

А вот медленно гнить внутри старой системы – это почти гарантированный проигрыш.

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

Что думаете?