ИЗМ

Ну и топовый кейс по использованию нейросетей (бесплатно для подписчиков канала)!

До LLM искусственный интеллект был как собака: все понимал (DSML), глаза умные (CV), но сказать ничего не мог (LLM)!

Друзья, а я правильно понимаю что ценность банков снизилась, так как теперь можно просто поставщикам и подрядчикам не платить?!

Кому удобнее читать дзен вот ссылка на канал.

Мировое правительство и суверенный искусственный интеллект Интересный человек написал интересный пост о новом Федеральном законе про искусственный интеллект. Основная мысль в том, что разработчики суверенных моделей будут получать дополнительные плюсы от использования наборов данных в ГИС (Государственных Информационных Системах) и это стоит учитывать при планировании обучения нейросетей. Хотя, как я понимаю, пока обучать LLM реально могут только Яндекс и Сбер. При этом, как понимаю сейчас есть только США, Китай и Россия в виде значимых игроков на рынке ИИ при этом мы в отстающих, но мы и не потратили столько на ИИ, чтобы перестать надеяться на окупаемость. Но вот с точки зрения накопленных данных в США их накопили облачные корпорации (о чем подробно пишет в книге Технофеодализм Янис Варуфакис), а в России и Китае данные накопило Правительство. Не знаю, что будет делать Китай, но Российское правительство решило поделиться этими данными, потому что хочет и может. А вот чтобы рассказать, почему оно может нужно небольшое лирическое отступление по истории электронного правительства (моими глазами). Как сейчас помню, 2011 год и Дмитрий Анатольевич Медведев после поездки в США говорит (уже не первый раз), что мы будем строить электронное правительство. Заявление немедленно вызывает волну обсуждений, критики и негатива. А я пытаюсь загуглить, что это такое, и захожу на сайты государственных структур США, которые выглядят как абсолютный "привет из прошлого" и не могу понять, что именно мы будет создавать. Теперь, 15 лет спустя, госуслуги и многие государственные сервисы у нас на высочайшем уровне (возможно, лучшем в мире) и воспринимаются как данность, но в Америке такого прогресса не добились. Потому что они говорили, что надо делать электронное правительство нам, а мы пошли и сделали. Теперь у нас есть накопленные данные по разным предметным областям и в большом объеме. Я, кстати, знаю очень сюжетно похожую историю в корпоративном поле. Одна крупная компания убедительно рассказала на референс-визите как надо делать второй. Забыв упомянуть о том, что у них не совсем так. Вторая впечатлилась и сделала как надо и как им рассказали у себя. И неожиданно стала лидером в этой теме, оставив всех конкурентов позади. Как говорится, "какого же было удивление оперативников" когда человек, перешедший в первую компанию из второй спустя много лет, не обнаружил там референсного процесса. Уже писал пост про сложности в собираемых медицинских данных с точки зрения обучения на нем ИИ, но у нас эти данные есть, их много и, скорее всего, очень даже неплохие, потому, что на них работают ежедневные процессы и они поддерживаются едиными национальными реестрами, справочниками и классификаторами. Для меня здесь есть две главные мысли. Первая мысль в том, что надо делать то, что говоришь, а говорить только хорошо подумав. А вторая, что стоит осмыслить продуктовые возможности доступа к таким данным с точки зрения стартапов и крупных компаний, но помнить что собирать надо чистые данные или чистить собранные.

Высшая арифметика или весь мир имеет вероятностную природу Когда я, получив специальность «прикладной математик и системный программист» начал работать на проектах в крупном российском бизнесе, то через какое-то время стал иронизировать, что у меня «высшее арифметическое образование». Конечно, можно сказать, что так было всегда и будет всегда, как в известном анекдоте. Но что-то мне подсказывает, что это не совсем так и понемногу даже высшая математика придет в нашу жизнь и работу. Давайте посмотрим на теорию вероятностей и математическую статистику. Для меня она была всегда очень прикладной, так как весь мир имеет вероятностную природу, а не детерминированную, сценарную или диапазонную. То есть когда мы что-то планируем, то возможные исходы имеют свое распределение вероятностей. Так, при планировании выручки компании стоит понимать, с какой вероятностью будут достигнуты планируемые показатели. Например, поставленная цель может быть достигнута с вероятностью 5% (очень амбициозно) или с вероятностью 50% (немаловероятно), а может быть даже 95% (практически гарантированная) и это разные ситуации, хотя они могут выглядеть весьма похоже. Так, неправильно думать, что текущий уровень получаемой выручки является гарантированным и не нужно прилагать усилия, чтобы его поддерживать. Это, кстати, часто звучит как полная неожиданность при попытке расчета экономического эффекта, так как все привыкли говорить об эффекте в виде прироста к текущему, но, например, в период кризиса или сильных изменений рынка необходимо вкладывать деньги, чтобы сохранить текущий уровень. В подтверждение вышесказанного хочу заметить, что уже есть случаи весьма объемного и успешного применения теории вероятностей в бизнес-практиках: Центробанк применяет риск-ориентированный (читай вероятностный) подход. Риск-менеджмент (в том числе имитационное моделирование Монте-карло) - риск можно определить как вероятность наступления негативного события или не наступления запланированного. Это новая функция корпоративного управления. Стоимостной инжиниринг — оказывается, что расчеты стоимости капитальных проектов тоже не точные, а вероятностные. И риски у них, вероятно, тоже есть. RCM или Reliability-centered maintenance в ремонтах использует риск-ориентированный подход, который основывается на теории вероятностей. Кстати, data science и machine learning — это упакованные в прикладные методы и цифровые инструменты теорвера и матстата (и другие разделы математики), отсюда и мем. Закончить хотелось бы небольшим прикладным советом: если у вас руководитель спросит: «Какого значения целевого показателя вы достигнете в этом периоде?», то предлагаю вам перевернуть игру и предложить, чтобы он назвал желаемое значение целевого показателя, а вы бы определили вероятность его достижения. Что-то вроде такого диалога: Руководитель: Какой шанс, что мы в этом году отработаем хуже, чем прошлом? Вы: Немаловероятно!

Два типа менеджера в кризис Недавно общался со своим товарищем, который сейчас трудится ИТ-директором, и он сказал, что различает два типа менеджеров. Первый тип системно выстраивает команду, процессы и технологии, а второй собирает команду и дальше полностью делегирует ей. Мне больше понятен первый тип, а со вторым ещё предстоит углубленное знакомство. Эта простая и полезная классификация напомнила мне про другие два типа - это два типа менеджеров в кризис, которые соответствуют персонажам Миронова и Папанова в гениальном кинофильме Бриллиантовая рука. В кризис компании теряют связь с рынком, как поднятый на вертолете автомобиль москвич потерял сцепление с дорогой, высота прибавляется с каждой секундой и становится страшно. Менеджер типа "Миронов" пытается взглянуть правде в глаза, открывает дверь машины, кричит "Мама!" и теряет сознание от страха. Фактически он парализован страхом и пониманием тяжести ситуации. Менеджер типа "Папанов" продолжает "управлять" через интенсивное использование привычных инструментов управления, не поддается панике, бесстрашно поет песню "я встретил вас и все былое...", но несмотря на эти позитивные характеристики, он не замечает отсутствия реакции на его действия (пропущено звено Check - PDCA цикла). Он крутит-вертит руль в право и в лево, но упорно не замечает, что автомобиль ведет себя не как всегда, потому внешние силы (вертолет) сильнее его управляющих воздействий (кручения руля). Я задал себе вопрос, какой у меня тип, и неожиданно понял, что я возможно третий тип ("Никулин"), который лежит связанным в закрытом багажнике и при попытке выбраться падает. Да, я сломаю ногу, но зато окажусь в новой реальности и, возможно, даже найду другую машину или дождусь посадки этой и смогу действительно что-то сделать, а не находится в кризисной невесомости.  Для лучшего понимания ситуации советую пересмотреть эпизод, а лучше и весь фильм. Какой менеджер ты?)

Новая рубрика: ИИ галлюцинация или реальность?

Классики, cигнал и шум в ИИ Недавно чуть не поучаствовал в панельной дискуссии по ИИ с представителями Яндекса и Сбера. На нее в итоге не хватило времени, но я уже настроился. Поэтому хочу поделиться в посте. В рамках разговоров про скорое возвышение больших языковых моделей (LLM) и ожидание общего искусственного интеллекта (AGI) мне вспомнился эпизод авторства классика, который привожу ниже: ... — А по какому обвинению, смею спросить, и кого? Человек почесал щеку и стал вычитывать по бумажке из портфеля. — По обвинению Преображенского, Борменталя, Зинаиды Буниной и Дарьи Ивановой в убийстве заведующего подотделом очистки МКХ Полиграфа Полиграфовича Шарикова. ... — Простите, профессор, не пса, а когда он уже был человеком. Вот в чём дело. — То-есть он говорил? — спросил Филипп Филиппович, — это ещё не значит быть человеком. Впрочем, это не важно. ... — Как же, позвольте?.. Он служил в очистке… — Я его туда не назначал, — ответил Филипп Филиппович, — ему господин Швондер дал рекомендацию, если я не ошибаюсь. ... — Он же говорил… Кхе… Кхе… — И сейчас ещё говорит, но только всё меньше и меньше, так что пользуйтесь случаем, а то он скоро совсем умолкнет. ... — Наука ещё не знает способов обращать зверей в людей. Вот я попробовал да только неудачно, как видите. Поговорил и начал обращаться в первобытное состояние. Атавизм. — Неприличными словами не выражаться, — вдруг гаркнул пёс с кресла и встал. Вот так вот. ... От себя добавлю, что не все, что говорит, обладает интеллектом. Нейросети, как технология существуют давно, но именно когда они заговорили, то начался ажиотаж вокруг технологии и ее стали пытаться применять везде. При этом в обсуждениях успехов LLM я бы предложил, вслед за другим классиком Клодом Шенноном, отделять сигнал от шума, то есть не все, что создает LLM является полезной информацией, а часть является просто "водой". Этот тезис очень хорошо визуализируется мем в заголовке поста. А зачем нам ИИ, который помогает создавать шум?

Задача обучения LLM на основе открытых данных и размещения его локально, а не в облаке, мне чем-то напоминает просьбу 25 летней давности выкачать интернет на диск, чтобы дома его спокойно смотреть без интернет-подключения!

Дикие институты и Искусственный интеллект Эпиграф: Иду по бизнес-процессу, вижу шаг, оказался дикий... Институционализация — это важная часть системного менеджмента. При этом есть проблема, когда некоторые институты менеджмента выходят из-под контроля и становятся "дикими" или живут в виде карго-культа. Уверен, что вы все сталкивались с такими ситуациям, когда какой-то институт, бизнес-процесс или бюрократическая процедура работают как-будто сами по себе, без связи с реальностью, без понимания необходимости и больше как ритуал. То есть кто-то сформулировал правило, но сейчас уже никто не понимает его смысла. Примерами таких диких институтов может что угодно и это очень индивидуальная ситуация для компании. При этом я заметил, что есть некоторые широко распространенные "лучшие практики" которые или могут быть незрелыми в виде карго-культа или выходить из под контроля и становится дикими: Бюджетирование: мы должны потратить в этом году весь бюджет, иначе нам не дадут его в следующем. Получается что бюджетирование заставляет нас что-то делать; KPI: важно достигнуть нашей оценки любой ценой в несмотря на текущую ситуацию (режим дополненной реальности), даже ценой других показателей и любых последствий; Технико-экономическое обоснование (или расчет): мы посчитали, что проект эффективен, а то, что ситуация меняется, циклична и так далее, — это уже другой вопрос, вообще даже термин "расчет" здесь не совсем верен, так как он не предполагает оценку, которая есть в любом ТЭО; Тендерные процедуры: мы выбрали что-то, но не сами, а по результату тендерной процедуры; Искусственный Интеллект - претендент, который может стать лидером; Выход из под контроля происходит в случае, когда человек снимает с себя ответственность за принятое решение и начинает говорить, а потом и сам так думать, что это все результаты процедуры, расчета, методики или автоматизации. Такие вещи уже сейчас часто происходят при автоматизации. Я встречал ситуации, когда сотрудники уже не помнят алгоритма, по которому работает программа, а ИТ-специалисты не понимают бизнес-задачи. Алгоритм при этом крутится как может. Это будет происходить в ИИ решениях и в data-driven. Будут говорить, согласно нашим данным или ИИ шепнул решение. Вообще думаю, что скоро увидим первые увольнения "ИИ-агентов", это ведь даже проще, чем смена "плохого подрядчика" или увольнение "не справившегося с обязанностями сотрудника". Чтобы этого не происходило, предлагаю простой чек-лист (каждое утро с восклицательной интонацией): Мы понимаем, как у нас принимаются решения (Plan)! Мы принимаем ответственность за решения (Do)! Мы анализируем последствия наших решений (Check)! Мы вмешиваемся, если нас что-то не устраивает (Act)! В любом случае скоро надо будет запускать программу проектов, а может и национальную программу "Естественный интеллект (ЕИ)", чтобы уравновесить набирающий силу Искусственный интеллект (ИИ)!

Ругать старое, чтобы продать новое (бизнес-анекдот) Многие знают анекдот про три конверта, где содержание второго конверта варьируется, но содержание первого всегда одинаково: "ругай старое". Это бизнес-анекдот, то есть анекдот, который имеет прикладной смысл и повторяется в разных ситуациях и областях (ИТ-аутсорсинг, погранслужба), так как является паттерном. Даже президент его рассказывал. Возможно, вместо шоу три аккорда надо делать шоу три конверта?! Точнее это анти-паттерн — так делать не надо. Мне кажется, ошибочным и опасным подход по построению нового без оглядки на старое. Назовем это управленческой проблемой номер 1917. А где еще встречается схема "ругать старое, чтобы продать новое"? При этом ругается огульно и не всегда правдиво. Сам этот анекдот родился из ситуации, когда новое руководство ругало старое применяя это как стратегию выживания. Также применяется, чтобы продать в прямом и переносном смысле что-то новое. Посмотрим табличку из нескольких таких кейсов, чтобы точно все правильно понять. С waterfall/agile лукавство состоит в том, что никакого движения напропалую вперед по проектам никогда не было, а всегда были итерации, которые оформлялись в виде этапов в виде эскизов, прототипов, PoC и так далее. А продают так, как будто в аgile впервые придумали слово итерации. Проектное и продуктовое управление: не будет никакого продуктового управления без проектного, любой чистый продуктолог вам все профукает, потому что продуктовое управление — это пока ограниченный набор методов, а проектное управление — это главный инструмент упаковки и доставки изменений (нам с вами известный Change товарищ Run). В общем, проектное управление по-прежнему доставляет. Бюджетирование/ZBB или beyond budgeting, в случае с ZBB это вообще не новое, а просто небольшая вариация старого. А beyond budgeting это прекрасная концепция и очень правильная критика, но в основном без конкретных предложений. Монолит и микросервисы — последний пример похож на первый, а именно никогда не было монолитных приложений, они всегда были высоко структурированные, и даже была обработка с разделением по мощностям (параллелизация), так что это просто очередной логичный шаг вперед в виде разделения в среде исполнения на отдельные микросервисы. Конечно, микросервисы очень хорошо будут работать в гугл, нетфликс и амазон, но это совсем специфичные компании и у них сама бизнес-модель cloud native к этому толкает. Надо сказать, что я не против продаваемого нового, но за более открытый диалог. Хотя грустная правда может быть в том, что без этого новое вообще не продать... А вы какие примеры знаете?

Трансформация Управления персоналом : поиск команд Мы все видим и слышим много разговоров про цифровую трансформацию, но в действительности сильная или даже принципиальная трансформация процесса на основе цифровых возможностей происходит не всегда. Например, чудеса происходят в части управления персоналом (HR): автоматизирован кадровый учет и расчет зарплат, наëм с отбором искусственным интеллектом, КЭДО, порталы с обучением и системы целеполагания с порталом работник и менеджера. Но в чем принципиальные изменения процессов от того, что было? Мы по-прежнему гоним одинокого человека от hire до retire с остановками на онбординг, командообразование и целеполагание. Есть предположение, что в функции HR не хватает возможности делать командный поиск. В ИТ тема точно полезная, да и в других направлениях может быть небезынтересна. Онбординг легче и веселее делать вместе, командообразование уже есть, целеполагание на общий результат более естественно (не надо каскадировать и декомпозировать). Представим возможное будущее: мне нужна команда, чтобы внедрить систему для командировок или разработать приложение по учету показателей счетчиков. Давайте так и скажем: "ищем команду из разработчиков, аналитиков и так далее для разработки...". Можно сказать, что для этого и существуют компании, чтобы мы передавали эту возможность целиком через тендер к подрядчику на его команду, но, мне кажется — это не взаимоисключающие возможности. В целом компания — это сеть из людей (корпоративная социальная сеть), хотя ее чаще хотят представить как сеть бизнес-процессов или баланс с прибылями и убытками. Дальше может стать интереснее — команда становится ячейкой компании, а делают организационный дизайн вокруг взаимозаменяемых и взаимодополняющих команд.

Повышение эффективности ИТ-отрасли или ученический открытый код Недавно появилась новость: С 1 января 2026 года для крупных аккредитованных ИТ-компаний вводится новое требование о необходимости направлять не менее 3% объема средств, сэкономленных в результате применения льготных тарифов страховых взносов и пониженной ставки налога на прибыль, на поддержку ИТ-образования. Новая норма направлена на повышение качества подготовки кадров для ИТ-отрасли, а также на укрепление долгосрочного и системного партнерства между ИТ-компаниями и образовательными учреждениями. То есть теперь ИТ-компании будут обязаны участвовать в обучении студентов, а это дополнительная нагрузка. А может, то, что нам мешает, то нам и поможет? В интересах открытого диалога хотел бы предложить идею: повысить эффективность ИТ-отрасли путем развития российского открытого кода (open source) в процессе выполнения этого требования. Для этого организуем проекты ПО с открытым кодом как передаточное звено между компанией, учебным заведением и студентом. Рассмотрим возможные действия каждого из участников. Компании инициируют проект открытого кода и создают основу, тем более уже есть компании, построившие свои бизнес-модели вокруг открытого кода. Вузы адаптируют программу обучения и практических заданий вокруг этих проектов. Востребованность конкретного проекта — наглядный показатель "крутости" учебного заведения (можно даже в рейтинге это учесть). Студенты не будут сначала делать теоретическую фигню, а потому заново на практике всему учиться на работе (как в известном анекдоте). Работодатели будут понимать уровень учебных заведений и студентов / выпускников по контрибуции, а также отдавать предпочтение в зависимости от специализации и используемого открытого кода. Страшно представить, но и преподаватели смогут участвовать и доказывать/поддерживать свой уровень. Доценты, что думаете? Студенческие стартапы будут возникать коммерциализацией родного опен сорса своей альма матер. Это, конечно, не просто "открытый код", а "ученый код" или "студ проект".

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

Помните книгу Александра Волкова «Урфин Джюс и его деревянные солдаты»? Недавно жена с ребенком её читали, а я понял, что у произведения есть второй бизнес-смысл. Напомню история в том, что плотник оживляет деревянных солдат с помощью волшебного порошка, но солдаты не очень умны и все для них вызывает сложности, так как они все выполняют слишком прямолинейно, ломаются, падают в воду и так далее. Так вот, получается Урфин Джюс — это слабый руководитель, а деревянные солдаты — это работники с твердыми навыками, но без мягких (ну вы знаете: адаптивность, коммуникация, работа в команде итд). Работники-солдаты в целом могут выполнять свои функции, но будет столько проблем в процессе, что это никому не понравится. Ну и обзор от ИИ подтверждает мою гипотезу.

Неожиданная проблема факторного анализа Давайте вернемся к вопросу неожиданных проблем факторного анализа на условном примере с себестоимостью продукции с единственным компонентом. Визуализируем отклонение себестоимости в графическом виде. В нашем примере, отклонения это S1+S2+S3, S1 - вызвана отклонением количества при отсутствии отклонения цены, а S2 - отклонение цены при отсутствии отклонении количества. S3 - это отрицательный командный результат, который вызван сочетанием отклонения цены и отклонения количества. Арифметическая проблема состоит в том, что есть дополнительное отклонение S3, оно возникает как сочетание двух отклонений, но чем больше факторов в ваших вычислениях, тем больше будет разных сочетаний. В них никто не будет виноват по отдельности — командная работа. При этом с увеличением количества факторов таких «командных результатов» тоже станет больше и разделить ответственность без остатка в числовом становится все сложнее. Проблема взаимосвязи факторов — если цена будет уменьшаться, то есть риск роста количества. Это происходит потому, что есть соотношение цены и качества. Получается, что мы разделяем на факторы в факторном анализе, чтобы по отдельности влиять на составляющие и улучшить управление, а получается обратный эффект из-за сложной взаимосвязи между ценой и качеством. Соотношение цены и качества в сырье производственной компании — это уже высшая арифметика. Если вам после прочтения показалось, что не может быть, чтобы этого не понимали уважаемые финансисты и экономисты, то хочу привести пример публикаций с похожим направлением мысли. Это книга авторов Блюмина, Суханова и Чеботарева (рецензент уважаемый Дмитрий Александрович Новиков, теперь директор ИПУ РАН) — Экономический факторный анализ. Можно и дальше разбирать проблемы применения этого метода, но в целом понятно, что при таком анализе деятельности мы неправильно перетягиваем между ответственными шкуру планового медведя. Что делать? Солюшен намбер 1: Можно продолжить считать также, но понимая эту особенность учитывать нюансы и визуализировать данные с их учетом; Солюшен намбер 2: ставить командные цели по снижению себестоимости; Солюшен намбер 3: использовать другой или даже придумать свой способ анализа отклонений.

Факторный анализ Многие компании при автоматизации, цифровизации и трансформации финансово-экономической службы идут сходным путём лучших практик в виде планирования и бюджетирования, быстрого закрытия, отчётности и дашбордов и факторного анализа. Факторный анализ — апофеоз большого пути, так как позволяет разложить на компоненты причины отклонения факта от плана. Чтобы прийти к этому процессу, нужно разобраться с планированием, сбором факта, сопоставить план и факт между собой и только потом можно делать сам анализ. Это важно, потому что планировать — не мешки ворочать. Например, я могу легко запланировать сделать в следующем периоде в 10 раз больше по любому бизнес-показателю. Так все и будут делать, если не пользоваться в управлении циклом план-факт-анализ отклонения-действие по исправлению (PDCA). Можно, конечно, вообще не планировать, но это отдельный интересный разговор. Проблемы начнутся при попытках исполнения такого плана и при ожидаемом невыполнении встанут два классических вопроса "кто виноват? и что делать?". Факторный анализ позволяет структурировать дискуссию при анализе отклонения и выработке действий по исправлению. Основные показатели для факторного анализа — это прибыль и денежный поток, дальше разберемся на примере прибыли и конкретно на формуле себестоимости. Для анализа, почему себестоимость больше плановой используются следующие факторы: цены сырья, нормы/количества потребления в производство, курса валюты (в импортной составляющей) и так далее. То есть если у вас выросла себестоимость, то могли увеличиться цены или увеличиться потребление, а, скорее всего, и то и то, просто в разных пропорциях. Кто виноват понятно: за цены отвечают закупщики, за потребление — производственник, за курс валют — американцы. Что делать тоже понятно: снижать цены закупки, контролировать фактические нормы. Все довольны, все смеются, но есть неожиданные проблемы, о которых расскажу в следующем посте. А важно это потому, что потратить много времени и денег на дорожную карту цифровизации и трансформации, реализовать факторный анализ и только тогда узнать об этих проблемах лично мне бы не хотелось.

KPI - Ай-яй-яй Тут вот современные классики давят на больное про KPI, но несмотря на разделяемое недовольство ситуацией хотелось бы добавить несколько мыслей, что не все так однозначно в этой теме. Грустно признавать, что взрослые и зрелые люди зачастую не способны к автономности и самоорганизации в команде, а это немедленно вызывает необходимость в человеке с табличкой / менеджере.  Дальше в эту игру приходится играть вдвоём. Появляется потребность в показателях деятельности, которые часто называют KPI (Key Performance Indicators), что буквально и означает ключевые показатели деятельности. При этом нет никакой отдельной правильной методологии KPI и вся надежда на "на крепость рук, на руки друга и вбитый крюк". В нашей российской практике менеджмента следует отметить карго-культ, то есть поведение, при котором мы делаем, что хотим, но пока мы это правильно называем KPI - все должно получиться. Поэтому я считаю KPI — диким институтом менеджмента, который давно вышел из-под контроля и живет сам по себе без влияния человека (спойлер: есть и другие дикие). Чтобы исправить ситуацию нам нужно понимать, как влияют наши показатели на общий результат (прибыль). Есть несколько полезных методик, которые могут помочь пойти в правильном направлении, помня, что содержание важнее формы: VDT Value driver tree — помогает понять, как цифры в вашей карте целей связаны с основными показателями деятельности компании, например, влияет ли ваше количество выполненные проектов на прибыль? BSC Balanced scorecard — напоминает, что кроме прибыли есть еще важные показатели удовлетворенности клиентов или внутренние операционные, потому что прибыль не извлекается прямым отжимом и недовольные клиенты не покупают больше. OKR Objectives and key results — подсказывает, что если нужные показатель разложить на составляющие и периодически обсуждать прогресс, то есть шанс в конце года не расстраиваться. Если вы все это знаете, то это ничего не дает. А вот если вы все это делаете, то можно экспертов по предметной области послушать, раздачу бюджетов привязать к обещаниям по KPI и с коллегами по отрасли бенчится. Ну и не забываем, что кадры решают все и если у вас будут хорошие работники и хорошие менеджеры, то размер таблички уже не так важен.