Инжиниринг корпорации

В Казахстане нейросеть приняли в совет директоров

Искусственный интеллект впервые стал членом совета директоров госфонда с активами на $81 млрд.

ИИ-модель SKAI, созданная на основе казахстанской языковой модели Alem, получила право участвовать в голосованиях совета директоров Национального фонда благосостояния «Самрук-Казына».

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

SKAI работает на суперкомпьютере Al Farabium — самом мощном в Казахстане. Напомним, с сентября в стране появилось Министерство искусственного интеллекта.

Глава фонда Нурлан Жакупов назвал это «квантовым скачком» и заявил, что цифровизация теперь становится частью управленческой философии.

Ранее в Албании появился первый ИИ-министр Diella, отвечающий за госзакупки.

Дайте знать, когда ваша компания будет морально готова к ИИ-менеджерам! Обойдёмся без супер-компьютера 😉

Мы все учились понемногу чему-нибудь и как-нибудь

(А.Пушкин «Евгений Онегин)

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

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

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

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


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

Что из этого следует:
— Стратегически важная, но слабая компетенция: развивать внутри поздно, нужно хантить – искать на стороне, привлекать, а потом удерживать.

— Важная но средняя – обучать, развивать, защищать.

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

— Стратегически не важна (вне зависимости от уровня): не тратить ресурсы. Да и вообще, не лучше ли здесь аутсорсинг?

Думаю, остальные комбинации вы сформулируете в этой логике без особого труда.

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

Реальный пример из практики моего клиента. Компания вкладывает деньги в курсы переговоров для среднего менеджмента. Все довольны, сертификаты на стенах.
Но на рынке главный вызов – переход на цифровые каналы продаж. Компетенция «управление e-commerce» стратегически важна и у компании она слабая.
Куда стоило вложить ресурсы? Очевидно. Но культ тренингов сработал как всегда: «надо учить людей чему-то полезному».

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

А что у вас в компании?

В Албании министром стал искусственный интеллект

Албания стала первой страной в мире, где должность министра досталась ИИ, сообщает Politico.

Виртуального министра зовут Диэлла (в переводе с албанского «солнце»). Премьер-министр Албании Эди Рама заявил, что ИИ-министр будет отвечать за все государственные закупки. Дьелла будет оценивать тендеры и получит право «нанимать сюда таланты со всего мира», одновременно разрушая «страх предрассудков и косности администрации».

Он пообещал, что Албания, для которой остро стоит проблема коррупции, станет страной, где государственные тендеры «на 100% неподкупны».

Бот Диэлла уже знаком жителям Албании, поскольку он действует на платформе государственных услуг e-Albania. У него есть аватар в виде молодой женщины в традиционной албанской одежде.

#пятничное

ИИ-менеджеры.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Что думаете?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Почему?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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