Системный менеджмент

Анатолий Левенчук · Поиск в руководстве · MCP

Системный менеджмент.

Анатолий Левенчук

Введение

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

Материал нашего курса довольно короткий, он не заменяет вузовского курса MBA (master of business administration), но по разным вариантам этого курса прошло 26 учебных потоков, и среди студентов этих потоков были и студенты MBA, которые указывали, что курс помогает понять, каким образом увязать между собой разные знания, полученные ими в курсах программы MBA, и как с пользой использовать эти знания — это даётся за счёт инженерного подхода к созданию и развитию организаций. Вместе с тем в курсе указана литература (более двухсот ссылок), и если в ходе изучения курса потратить достаточное время на проработку не только материала нашего курса, но и на проработку литературы к нему, то курс вполне может быть сравним с курсом MBA, вопрос только в выделении времени студента.

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

Курс ставит перед собой две задачи:

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

Курс в качестве пререквизита требует прохождения курса «Системной инженерии»¹, а также курсов-пререквизитов к курсу «Системная инженерия». В тексте есть многочисленные отсылки к разным идеям из этих курсов. Это сильно упрощает понимание студентами традиционно трудных для менеджеров тем стратегирования, оргпроектирования и орг-архитектуры. Вместе с тем, в курсе очень специфичные для исключительно менеджерской специализации практики (корпоративные финансы, орг-архитектура, администрирование) описываются очень кратко. Всё-таки основное назначение курса — это помочь инженерам, которым приходится быть начальниками, полноценно стать этими начальниками, научиться прежде всего организовывать людей на выполнение каких-то работ, создание и развитие какой-то системы. Нет цели научить людей быть профессиональными финансовыми аналитиками, профессиональными администраторами. Ничего не говорится и о практике продвижения (маркетинг, реклама, продажи), а также практике привлечения инвестиций/фандрайзинга, ибо мы не считаем это практиками менеджмента.

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

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

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

Курс не является обзорным по существованию разных источников менеджерской теории и практики, исторические экскурсы практически отсутствуют. Приоритет даётся SoTA материалам по источникам последних пяти лет. Часть материала авторская, ибо автор курса имеет три десятка лет опыта организационной работы в стартапах, которые затем выходили в десятку самых крупных в своей отрасли в масштабах страны, а также в крупных компаниях и даже органах государственной власти и управления. Так что этот курс не представляет собой реферат по менеджерской литературе, автор наблюдал работу описываемых в курсе идей в жизни. Из экономики идёт опора на маржинализм и австрийскую школу экономики, в операционном менеджменте идёт опора на идеи TameFlow и product development flow, в лидерстве упор не на психологию и социологию, а на ролевое мастерство и связь лидерства и оргпроектирования, в стратегировании опора на идеи Tony Seba по экспоненциальному развитию и подрыву, а также идеи бесконечного развития и техно-эволюцию.

Материалы курса могут быть использованы в самых разных форматах: просто чтение текста материала курса, прохождение онлайн-курса self-paced с выполнением упражнений и заданий, прохождение онлайн-курса self-paced с проверкой выполнения заданий инструкторами, прохождение онлайн-курса в заданном ритме с группой других студентов и обсуждением трудных вопросов (study group), прохождение полноценного тренинга с преподавателем (например, автор ведёт на базе материала курса тренинг²).

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

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

В конце 2022 года материал курса был полностью переработан, ибо поменялось поколение системного мышления, поменялись практики системной инженерии, поменялись SoTA практики самого менеджмента, надо было учитывать эти изменения. В ходе написания текста курса автор учёл доступность полноценных курсов-пререквизитов, прежде всего курса «Системная инженерия». Это позволило сделать изложение исключительно компактным, не потеряв глубины изложения материала. Этот вариант также отличается от предыдущего видеокурса 2021 года тем, что полностью согласован с курсом «Системная инженерия» и по содержанию, и по терминологии.

Текущий курс вузовского уровня, это не «попсовый вариант менеджмента для чайников». Текущая текстовая (без видео) версия онлайн-курса появилась в программе «Бесконечное развитие»⁴ Школы системного менеджмента⁵ в последние дни 2022 года, этот же материал (без заданий и упражнений) был отправлен в издательство Ridero как «Системный менеджмент 2023». После этого в онлайн-версии прошло несколько итераций исправления ошибок и дополнений (они доступны в истории изменений в «личном кабинете» Aisystant).

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

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

Курс можно найти во втором семестре «Системный менеджмент и стратегирование» программы «Организационное развитие» Школы системного менеджмента⁶, чат поддержки https://t.me/systemsthinking_course, там вы можете не только задать вопросы студентам и преподавателям курса, но и дать предложения авторам курса. Курс регулярно обновляется, ибо системный менеджмент и лежащая в его основе системная инженерия быстро развиваются, а курс уделяет особое внимание изучению современных практик, а не старинных (в менеджменте и инженерии старинными будут практики буквально пятилетней давности).

Дополнительные материалы

Чат поддержки курса общий с курсами системного мышления, методологии, системной инженерии — https://t.me/systemsthinking_course

[Широкое, узкое и слишком узкое понимание менеджмента. Менеджерские (под)практики и (под)роли 48](#широкое-узкое-и-слишком-узкое-понимание-менеджмента.-менеджерские-подпрактики-и-подроли)

[Роли, должности, организационные статусы 53](#роли-должности-организационные-статусы)

[Менеджмент, предпринимательство и начальничество 61](#менеджмент-предпринимательство-и-начальничество)

[Задания 67](#задания-3)

[Тренды современного менеджмента и выбор SoTA 68](#тренды-современного-менеджмента-и-выбор-sota)

[Упражнения 76](#упражнения-2)

[Задания 76](#задания-4)

[3. Практика бизнеса (прибыльности) 76](#практика-бизнеса-прибыльности)

[Предприятие как продукт: оно тоже продаётся 76](#предприятие-как-продукт-оно-тоже-продаётся)

[TEST Бизнес 80](#test-бизнес)

[Упражнения 81](#упражнения-3)

[Задания 83](#задания-5)

[Практика корпоративных финансов (инвестиции и займы) 83](#практика-корпоративных-финансов-инвестиции-и-займы)

[Практика корпоративной подназдорности (corporate governance) 88](#практика-корпоративной-подназдорности-corporate-governance)

[4. Практика стратегирования 94](#практика-стратегирования)

[Понятие стратегии 94](#понятие-стратегии)

[Практика стратегирования 100](#практика-стратегирования-1)

[Задания 105](#задания-6)

[Качества хорошей стратегии: это фильтр 105](#качества-хорошей-стратегии-это-фильтр)

[Задания 111](#задания-7)

[Бизнес-модель и её «холстовое» моделирование 111](#бизнес-модель-и-её-холстовое-моделирование)

[Модель оргразвития 121](#модель-оргразвития)

[Модель целеполагания/motivation для согласования интересов 126](#модель-целеполаганияmotivation-для-согласования-интересов)

[Упражнения 129](#упражнения-4)

[Культура съедает стратегию на завтрак, а реорганизацию на обед 130](#культура-съедает-стратегию-на-завтрак-а-реорганизацию-на-обед)

[TEST Получение инвестиций 132](#test-получение-инвестиций)

[5. Теория стратегирования 133](#теория-стратегирования)

[Будущее уже здесь 133](#будущее-уже-здесь)

[Подрыв подо всей цивилизацией сразу 137](#подрыв-подо-всей-цивилизацией-сразу)

[Пример подрыва: электромобили уже сейчас дешевле бензиновых автомобилей 143](#пример-подрыва-электромобили-уже-сейчас-дешевле-бензиновых-автомобилей)

[TEST Технологический подрыв 145](#test-технологический-подрыв)

[Задания 146](#задания-8)

[Роботы заберут работу? Нет! 147](#роботы-заберут-работу-нет)

[Инновации: всегда сбоку 151](#инновации-всегда-сбоку)

[TEST Скорость обучения нейросети 160](#test-скорость-обучения-нейросети)

[Упражнения 161](#упражнения-5)

[Неудачная практика Коллинза: стратегирование ежа 162](#неудачная-практика-коллинза-стратегирование-ежа)

[Упражнения 164](#упражнения-6)

[Задания 165](#задания-9)

[Стратегирование вместо мечтаний 165](#стратегирование-вместо-мечтаний)

[Упражнения 182](#упражнения-7)

[Бесконечное развитие (open-endedness) 183](#бесконечное-развитие-open-endedness)

[TEST бесконечного развития 191](#test-бесконечного-развития)

[Упражнения 192](#упражнения-8)

[Задания 193](#задания-10)

[Теории счастья и богатства 193](#теории-счастья-и-богатства)

[Упражнения 199](#упражнения-9)

[Задания 200](#задания-11)

[6. Практика управления работами (операционный менеджмент) 201](#практика-управления-работами-операционный-менеджмент)

[Практика управления проектами 201](#практика-управления-проектами)

[Практики управления процессами и управления кейсами 208](#практики-управления-процессами-и-управления-кейсами)

[TEST Проекты, программы, процессы, кейсы 218](#test-проекты-программы-процессы-кейсы)

[Упражнение 221](#упражнение)

[«Распожаризация» и управление работами 221](#распожаризация-и-управление-работами)

[Упражнение 223](#упражнение-1)

[TEST Управление кейсами 224](#test-управление-кейсами)

[Упражнение 224](#упражнение-2)

[Основные книги по современному операционному менеджменту 225](#основные-книги-по-современному-операционному-менеджменту)

[Задания 229](#задания-12)

[Управленческий финансовый учёт и контроллинг 229](#управленческий-финансовый-учёт-и-контроллинг)

[TEST Много разных финансовых учётов 232](#test-много-разных-финансовых-учётов)

[Задание 232](#задание)

[7. Практика организационного дизайна 233](#практика-организационного-дизайна)

[Оргразвитие: оргдизайнеры и лидеры 233](#оргразвитие-оргдизайнеры-и-лидеры)

[Упражнение 237](#упражнение-3)

[Работа оргдизайнеров 238](#работа-оргдизайнеров)

[Упражнение 242](#упражнение-4)

[Концепция организации и оргпроект 243](#концепция-организации-и-оргпроект)

[Выбор оргмоделера 248](#выбор-оргмоделера)

[TEST концепция организации 252](#test-концепция-организации)

[Конструкция организации и координация работ 253](#конструкция-организации-и-координация-работ)

[TEST 257](#test-1)

[Упражнение 257](#упражнение-5)

[Модель органиграммы 258](#модель-органиграммы)

[Упражнение 261](#упражнение-6)

[Задания 261](#задания-13)

[8. Практика архитектуры предприятия 261](#практика-архитектуры-предприятия)

[Архитектурные характеристики предприятия 261](#архитектурные-характеристики-предприятия)

[Исторические подходы к орг-архитектуре 265](#исторические-подходы-к-орг-архитектуре)

[TEST Бирюзовая организация 272](#test-бирюзовая-организация)

[Современная (SoTA) орг-архитектура 272](#современная-sota-орг-архитектура)

[Задания 274](#задания-14)

[9. Практика лидерства 275](#практика-лидерства)

[Лидерство как практика изготовления организаций 275](#лидерство-как-практика-изготовления-организаций)

[Рабочие продукты и корпоративные ритуалы как видимая форма оргизменений 280](#рабочие-продукты-и-корпоративные-ритуалы-как-видимая-форма-оргизменений)

[Табло и визуальный менеджмент 282](#табло-и-визуальный-менеджмент)

[Лидерство для достижения уровней сотрудничества 285](#лидерство-для-достижения-уровней-сотрудничества)

[Шаг развития: постановка оргвозможности 290](#шаг-развития-постановка-оргвозможности)

[Упражнение 300](#упражнение-7)

[Задания 301](#задания-15)

[Личное целеполагание как практика лидерства 301](#личное-целеполагание-как-практика-лидерства)

[Упражнения 306](#упражнения-10)

[Задания 306](#задания-16)

[10. Практика администрирования 307](#практика-администрирования)

[Администрация как оператор внутрифирменной организационной платформы 307](#администрация-как-оператор-внутрифирменной-организационной-платформы)

[Опасность: администрация для организаторов или организаторы для администрации? 309](#опасность-администрация-для-организаторов-или-организаторы-для-администрации)

[Задания 315](#задания-17)

[Что потом? 316](#что-потом)

1. Системный менеджмент и системная инженерия

Менеджмент как прикладная системная инженерия для организаций

Практику менеджмента/management мы считаем прикладной инженерией организаций. Системный менеджмент/systems management — это как раз использование системной инженерии как нормативной дисциплины для создания и развития организаций. Конечно, есть и другие варианты значения термина «системный менеджмент», словарное гнездо его имеет множество самых разных значений. Например, systems management в википедии ведёт не столько на практику администрирования людей, сколько на практику администрирования компьютеров, «система» тут означает компьютерную аппаратуру⁷. Иногда «системным» называют любой менеджмент, не имеющий отношения к системной инженерии, но использующий слова «система» в описании своих практик. Часто даже эти слова используются по делу, только речь идёт чаще всего о первом поколении системного мышления: замечание, что «всё со всем в системах сложно связано, но сначала нужно посмотреть в окружение системы перед разбирательством как там всё связано внутри». И всё, практики как именно «смотреть», как именно моделировать, как именно использовать компьютерные системы для обеспечения целокупности организаций — этого ничего нет, зато в этих книгах много примеров описания нестандартных причинно-следственных отношений, которые можно выявить в организациях. Мы назовём эти книги «системное мышление для менеджмента», и важно, что там ровно вот эта пара: «системное мышление первого или даже второго поколения» и сразу переход к «менеджменту организации как системе».

Наш подход кардинально отличается:

У нас тоже системное мышление, использование понятия «система» для обсуждения практик менеджмента. Но речь идёт не о первом и втором поколении системного подхода, а о третьем, учитывающем бесконечное развитие (open-endedness) систем с увеличением их сложности, их эволюцию.
У нас не просто системное мышление в приложении к практикам менеджмента, а методология (в экономике и менеджменте методологию часто называют праксеологией⁸) как общая теория деятельности безотносительно способов её организованности и дальше системная инженерия как нормативная методология (предписание SoTA практик мышления и действия) создания и развития: безмасштабная (то есть организационные системы попадают её объектом как системы одного из масштаба) и непрерывная (идея техно-эволюции/бесконечного развития, отражённая в понятии «непрерывное всё»/continuous everything, то есть непрерывная разработка, непрерывное изготовление, непрерывное введение в эксплуатацию и т.д.).
Организационная система рассматривается не сама по себе, а как создатель (constructor system), входящая в цепочку создания целевой системы (system of interest). То есть организация в менеджменте не целевая система (мы считаем ошибкой считать организацию-создатель целевой системой), а «наша система» (system-in-hand, engineered system). И может быть довольно много организаций в цепочке создания (даже «цепочка» тут очень условно, это направленный граф), связанных с созданием какой-то целевой системы. И наличие целевой системы позволяет всем этим организациям как-то договариваться о действиях, людям с их оборудованием достигать каких-то согласованных целей — и эти цели обычно связаны с созданием и далее бесконечным развитием целевых систем.

Так что в нашем подходе системный менеджмент — это приложение SoTA системной инженерии к организационным системам. Организационных инженеров мы называем менеджерами/managers. Мы избегаем переводить тут managers как «управленцы» или «управляющие»: одно дело организовывать людей с их оборудованием (включая компьютеры, запасы сырья для производства, помещения и т.д.), а другое дело управлять ими — мало кому хочется, чтобы ими управляли, они и сами с собой управиться могут. Но многие будут согласны с тем, чтобы их организовали. А уж чтобы ими руководили (буквально «водили их руками»), то есть отдавали приказы на отдельные действия, таких желающих нет. Поэтому мы остановимся на термине «организация» (предприятие/enterprise — это один из видов организации), а manager так и будем давать как «менеджер», ибо кроме собственно организовывания людей, то есть организации известных всем полномочий людей-агентов по распоряжению трудом (социальный капитал) и капиталом (капитал в его обычном понимании: оборудование, сырьё, помещения) есть ещё и эксплуатация уже организованной системы из людей и оборудования, и вопросы экономики-финансов-инвестирования и много чего ещё, чем надо заниматься менеджерам.

Тут и далее мы будем использовать понятия, определённые ранее в наших курсах «Системное мышление», «Методология», «Системная инженерия»⁹. Именно там даны определения и системного мышления, и системной инженерии, и что такое нормативная дисциплина, и что такое прикладная инженерия, и что такое open-endedness. Более того, в этих курсах дано и определение организации: это системы из людей и оборудования, в которых известны полномочия по распоряжению трудом и наличными ресурсами.

Но если в предыдущих курсах всё уже описано, то почему кроме общего курса системной инженерии требуется проходить ещё и курс системного менеджмента? Потому, что:

Люди и их организации имеют особенности по сравнению с системами из косного вещества, вещества с универсальным компьютером (киберфизическими системами) и даже живыми существами. Люди — это агенты, которые способны к планированию и кооперации в коллективы-суперагенты (недаром «юридическое лицо» назвали именно так, «лицом»).
Есть SoTA практик инженерии организаций, эти практики — результат меметической эволюции, не нужно каждый раз придумывать новую практику. Но в этих практиках объекты называются на специфическом языке мета-модели дисциплин менеджмента, и сразу непонятно, каких они типов в более универсальном языке мета-мета-модели. Нужен текст, в котором показана эта типизация и дана терминология.
Основные идеи концепции использования (для чего нужны организации, их функции в окружении), концепции организации (какие функциональные/ролевые объекты есть в организации и какие физические объекты могут выполнять эти роли, то есть какие аффордансы/оргзвенья из людей и оборудования можно взять для оргстроительства, чтобы результирующая организация могла выполнять свои функции в её клиентском и бизнес окружении), архитектурные паттерны (как именно организация разбивается на модули для удовлетворения каким архитектурным характеристикам) должны быть обсуждены, ибо они для разных организаций варьируются, но всё-таки не должны изобретаться с нуля. Это совсем не безмасштабные идеи, это идеи для определённого эволюционного уровня, уровня «популяции разумных существ» (помним, что популяция — это не только все, проживающие на какой-то территории, но и меньшие образования: семьи, коллективы и только дальше кланы и сообщества. В биологии самец и самка это уже популяция, ибо приходится рассматривать больше одного организма).
Сам «материал» (физические объекты, из которых строится система) организации как аффорданс для организационных ролей имеет свои особенности: сотрудников не напечатаешь на 3D-принтере, не каждую организационную роль сегодня поручишь выполнить компьютеру, но это уже не факт для «завтра»: сотрудника в части его тела может заменить робот, в части его мозга может заменить компьютер с AI — и это тоже нужно обсуждать в практике, основной тренд в менеджменте — автоматизация/«цифровая трансформация».
Не всегда понятно, как общая информация о необходимых системных описаниях может быть приложена к конкретным системам. Скажем, потоки электричества в энергосистеме подчиняются законам Кирхгофа, их понятно как обсчитывать. На каждом системном уровне функциональные описания (в силу эмерджентности, ибо появляются новые свойства) отличаются. Например, потоки товаров, работ, информации (логистика) в организации нельзя обсчитывать по закону Кирхгофа, но как тогда их обсчитывать? А ведь это и есть операционный менеджмент: правильная эксплуатация уже созданной и постоянно развиваемой организационной системы на базе корректных методов описания такой системы и известных закономерностей её функционирования.
Нужно описать взаимодействия менеджеров и других ролей организации (инженеры целевой системы, инженеры сообщества клиентов/клиентуры — люди, занимающиеся маркетингом продукции или услуг).

TEST

!!! Эльдар был назначен собственником в качестве генерального директора предприятия. Он очень гордится тем, что ему доверили коллектив из 53 человек штатных сотрудников! Он назвал свой проект корпоративного строительства (реорганизацию предприятия для усиления его конкурентоспособности) «Сила единства». Какая его целевая система?

+++ неизвестно ### Да, нам неизвестно, чем занято его предприятие. Само предприятие — это система создания для этой целевой системы.

--- вверенные ему 53 сотрудника предприятия, которых он должен реорганизовать ### нет, они могут быть «его системой», но не целевой системой. Эти сотрудники из системы создания целевой системы. Целевая система и её окружение пока неизвестны.

--- предприятие, состоящее из 53 человек, оборудования, зданий и сооружений, расходных материалов и других ресурсов ### Нет, предприятие может быть «его системой», но не целевой. Это предприятие — система создания целевой системы, но не сама целевая система. Это типичная ошибка менеджера: считать предприятие целевой системой.

--- прибыль предприятия ### Нет, даже если считать прибыль «кучкой золота», то это не его целевая система, а целевой системой будет тот продукт, который делает его предприятие, или тот продукт клиента, который изменяется сервисом его предприятия (и что это — неизвестно).

Задания

Поставьте отметки о выполнении дел:

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

Теории менеджмента

Есть огромное количество теорий менеджмента/школ управления. Ситуация похожа на психологию: чуть ли не каждый исследователь менеджмента (и он же часто оказывается «ведущим консультантом по менеджменту», то есть практикующим советником менеджеров) разрабатывает полноценную общую теорию менеджмента, базирующуюся на каких-то своих консультантских эвристиках, а далее объявляет это «истинной дисциплиной менеджмента». Есть и огромное число классификаций теорий менеджмента, похожих друг на друга, но и не очень похожих, где выделяют в том числе и системные теории менеджмента¹⁰. Высшее образование менеджеров (университетские курсы MBA, master of business administration¹¹) устроено так, что студентам читают учебные программы из наборов курсов, причем каждый из курсов может быть основан на идеях какой-то отдельной школы менеджерской мысли, в результате:

Не возникает целостного представления о менеджменте в его отношениях с другими инженерными практиками. Например, непонятно пересечение методов работы в менеджменте как создании и развитии организаций и методов работы в продвижении продуктов (маркетинг, реклама, продажи) как создании и развитии сообществ (неорганизованных групп людей). Непонятно соотносятся практики менеджмента организаций и менеджмента себя как личности. Непонятна общность практик инженерии организации и инженерии целевых систем самых разных масштабов и видов. Студенты предыдущих версий нашего курса «Системный менеджмент», имеющие до его прохождения степень MBA, отмечали, что только после прохождения нашего варианта курса понимали, о чём именно говорилось в курсах программы MBA и как нужно применять знания курсов этих программ — «всё разлеглось по полочкам, стало понятно, чего на этих полочках не хватает, а что явно лишнее». Мы относим это высказывание к тому, что менеджеров нужно учить прежде всего тому, что они инженеры организации, и это даёт основу для гармонизации знаний самых разных школ менеджмента и позволяет как-то определять полноту применения инженерных практик к организации.
Помним также о том, что инженерия использует теории там, где они есть. А где их нет, прибегает к инженерному творчеству, пока не поддержанному теорией (помним из курса «Системная инженерия» байку Billy Koen про средневекового инженера, который не ссылается на то, что теорию сопромата ещё не изобрели, а строит мост через реку). Упор на теории и «анализ» вместо инженерного творчества как синтеза с неизбежными пробами и ошибками (это подробно рассматривалось в курсе «Системная инженерия») в программах MBA приводит к тому, что выпускники этих программ становятся не менеджерами, а «аналитиками» и вместо предприятий и крупных производственных подразделений возглавляют финансовые аналитические службы компаний: они хорошо проверяют на отсутствие ошибок (аналитики!), но не способны предлагать какие-то новые способы действий, что ожидается от инженеров. На эту особенность программ MBA, которые массово выпускают не-менеджеров указывал Henry Mintzberg¹², который и сам один из авторов в области теорий менеджмента. Он также популяризирует несколько альтернативных форматов образования менеджеров¹³, которые исправляют этот «аналитический» недостаток.

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

В целом в классическом менеджменте было принято выделять подходы

организационного развития/organizational development¹⁴, посвящённые главным образом construction/dev-time в части изменения поведения людей,
операционного менеджмента/operations management¹⁵, затрагивающем прохождение потока обрабатываемых материалов, информации и работ по рабочим местам компании,
стратегирования, как предпринимательства в менеджменте.

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

В ходе попытки привлечь на менеджерские программы выпускников естественнонаучного бакалавриата (физиков, математиков, химиков) появились и программы инженерного менеджмента/engineering management¹⁶ как особое учебное предложение для менеджеров, которые будут иметь дело с инженерами. Основное там отличие — это большое число учебных часов на «инженерную» (безлюдную) часть менеджмента, то есть на операционное управление как главным образом управление проектами, а в остальном это самый обычный менеджмент «как везде». Для того, чтобы хоть как-то представить инженерный менеджмент как отдельную менеджерскую дисциплину, был организован консорциум университетов¹⁷, предлагающий курсы на степень MEM, master of engineering management и организована профессиональная ассоциация¹⁸, спонсорами которой являются исключительно университеты, а не инженерные организации, заинтересованные в развитии инженерного менеджмента. Этот консорциум требует от поступающих пререквизитом бакалаврской степени по STEM (то есть естественным наукам или инженерии), указывая, что на MBA могут поступать историки, юристы и т.д., которые затем хуже понимают, чем занимаются инженеры в высокотехнологических организациях. Вот диаграмма, которая даёт представление о таком понимании инженерного менеджмента как «общего менеджмента, только для инженерных команд — менеджеры и инженеры будут лучше понимать друг друга, имея общее STEM образование»:

Но во всём остальном образование на степень MEM аналогично образованию на степень MBA, в нём нет рассмотрения самой организации как инженерной конструкции, которую нужно тщательно проектировать, используя подходы системной инженерии. Менеджмент в инженерном менеджменте по-прежнему понимается как «управление людьми», а не создание/construction и последующее развитие организационной структуры, где какие-то агенты вместе (социальный капитал) и с помощью оборудования (капитала) могут изменить мир к лучшему быстрее и дешевле, чем они же поодиночке — причём структура эта должна быть инженерно спроектирована на основе каких-то знаний, а не просто быть «договоркой» людей, согласившихся вдруг работать друг с другом по итогам уговоров менеджера-лидера, занимающегося оргразвитием (organizational development) на базе полученных откуда-то (владельцев предприятия, придуманных самостоятельно, предложенных инженерами, консультантами и т.д.) стратегических идей.

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

Например, организационная инженерия/organizational engineering¹⁹ — это подход, в котором люди рассматриваются как информационные системы, ведущие более-менее рациональную обработку информации по схеме «входная информация — обработка — выходная информация», а не принимающие иррациональные «психологические» решения. Это подход разработан одним человеком, есть институт его поддержки²⁰. И дальше рассматриваются простые причинно-следственные отношения на базе такой простой схемы (скажем, если пытаться много внимания уделять входной информации и набирать её побольше, то это будет медленно, если мало и плохо заниматься обработкой, будут ошибки в выходной информации). Проблема в том, что организация опять-таки рассматривается не в целом, а только как состоящая из людей — и текущий акцент в подходе делается на корпоративную культуру, а не на инженерное проектирование организации с использованием лучших известных на сегодня практик (таких как разработка, архитектура, обеспечение непрерывного ввода в эксплуатацию каких-то частей организации — мы пока используем практики из системной инженерии, не называя привычным менеджерам их наименования для организаций). То есть нам не подходит название «организационная инженерия», оно уже занято, и не инженерией.

Бизнес-инженерия/business engineering²¹ выглядит более многообещающим подходом, он обычно говорит о создании и дальше развитии организаций «под ключ» как раз в рамках инженерного взгляда на бизнес — дисциплина рассматривается очень похоже на «инженерный менеджмент» как стоящая где-то между «менеджерами людей» и «инженерами целевой системы». Опять же, идея тут идёт не со стороны бизнеса/промышленности, а со стороны образовательных организаций, готовящих «бизнес-инженеров», реализующих «современные бизнес-модели» (бизнес-модель/business model²² — это практика получения денег за продукты и/или сервисы, продажа продукта или подписка на сервис тут просто самые простые варианты, об этом в нашем курсе будет подробнее рассказано позже, когда будем обсуждать стратегирование, частью которого и является бизнес-моделирование как предложение гипотезы о способе превращения пользы от продукта или сервиса предприятия в деньги). Есть даже ассоциация, которая помогает студентам в нахождении работы. Основная идея: всё в менеджменте выражать численно/количественно и делать упор на «бизнес-процессы», связывая взгляды на организацию как на производство, как на какую-то экономическую активность (бизнес), как на менеджмент (работу с людьми).

Это очень близкий взгляд к нашему, но организация в нём воспринимается всё-таки как что-то гуманитарное, что пытаются как-то описать/отмоделировать моделями, похожими на использующиеся в инженерии. Определение дисциплины (и её практики) бизнес-инженерии во всех источниках даётся как «промежуточной» между собственно менеджментом (как будто в нём нет инженерии) и инженерией (в которой менеджмент не предусмотрен), как мост между двумя этими дисциплинами. Конечно, этот термин используется более-менее произвольно²³, например, его приводят в манифесте бизнес-инжиниринга (калька с engineering) компании БИГ²⁴, написанного по мотивам работ в области организационной инженерии/business engineering. В этом манифесте много больше внимания уже уделяют не собственно вопросам менеджмента как то ли науки, то ли искусства управляться с людьми, чьи цели обычно довольно далеки от целей служения какой-то организации, но организации как хорошо спроектированной системы:

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

…

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

…

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

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

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

Дальше важно перейти от общих деклараций про важность использования инженерии в проектировании и «изготовлении» организаций к конкретным нормативным (то есть обязательному использованию SoTA-практик в реальных проектах вместо попыток изобрести велосипед) инженерным практикам. За последние пять лет существенно изменился сам набор этих практик, поэтому нужно пересматривать и текущую литературу по бизнес-инженерии. Например, «архитектура предприятия» всегда путалась с «архитектурой информационных систем предприятия», и это не случайно — пришла пора дать чёткие рекомендации на этот счёт. А ещё архитектура в системной инженерии выделилась в отдельную дисциплину и отделилась от собственно прикладной разработки требуемой функциональности/«фич» по предметам своего интереса, и ещё выделилась производственная деятельность DevOps — все они должны быть найдены в инженерии бизнеса, но пока обсуждение этих вопросов отсутствует, традиция концентрируется на моделировании «бизнес-процессов».

Ещё одно соображение связано с выделением разработки бизнес-модели как выработки стратегии предприятия с обязательным предложением способа получения денег в обмен на пользу/value от продуктов и сервисов организации, оно получило название «бизнес-анализ»/business analysis²⁵, хотя задача вроде как получить синтез: предложение бизнес-модели, а не её анализ! Бизнес-анализ тоже имеет свою ассоциацию, проводящую профессиональную сертификацию своих членов²⁶, бизнес-анализу учат как отдельной специальности, нормативная часть практики опубликована как BABoK (business analysis body of knowledge) Guide²⁷. Помня, как путают «системный анализ», «системное мышление» и «системную инженерию», легко представить, как будут путать «бизнес-анализ» и «инженерию бизнеса».

Само слово business тут проблематично:

С одной стороны, оно означает предпринимательский проект, «дело», предприятие. И поскольку не все организации ориентированы на получение предпринимательской прибыли (например, благотворительные организации, государственные органы и административные учреждения, «бизнес» процесса мытья полов в офисе заводоуправления), то стандарт ISO 29148 предлагает слово «бизнес» заменять словом «организация» или «организационный» (в зависимости от контекста). Если следовать рекомендациям стандарта, то business engineering надо переводить как «организационная инженерия» или «инженерия организации» (как мы, впрочем, и делаем в нашем курсе).
Слово может означать вопросы бизнесменов по прибыльности и способам зарабатывания, поэтому можно считать, что речь идёт о business analysis, который означает именно анализ бизнес-модели, который неявно включает не только анализ, но и предложение этой бизнес-модели, то есть «бизнес/предпринимательская сторона вопроса» (что бы ни понималось под словом «предприниматель» и «бизнес», но в быту это «про деньги»), «на чём делаем деньги», а не «как устроена организация/предприятие/проект». Чтобы подчеркнуть этот аспект, будем говорить о разнице между бизнесменом и организатором как разнице между ролями (хотя в жизни обе роли можно легко представить и у одного человека).

Ещё один термин для того же самого — это инженерия предприятия/enterprise engineering²⁸. Это, пожалуй, самое популярное и продвинутое понимание использования инженерии для создания и развития предприятий: широко используется в промышленности, а не только в университетской среде или отдельными консалтинговыми фирмами, сразу отсылает к поддержанному компьютерному системному моделированию и системной инженерии с особым акцентом на важность архитектурных решений для предприятия (что для нас сейчас ценнее всего, это поддерживает тезис о том, что менеджмент — это специализация системной инженерии). Конечно, и у этого термина есть проблемы:

Используемые сегодня в инженерии предприятия подходы чаще всего не SoTA, учебники и статьи отстают на десяток и больше лет от фронтира как программной инженерии (при всех заверениях, что инженерия предприятия учитывает тренд автоматизации и опоры на компьютерные корпоративные системы для целей и операционного менеджмента, и управления изменениями, а также стратегирования, включая бизнес-моделирование).
Слово «предприятие» ограничивает область применения подхода уровнем предприятия, а не уровнем произвольных оргзвеньев. То есть мы можем считать, что организация — это команда, или коллектив как команда команд, или предприятие, или даже расширенное предприятие/extended enterprise из отдельных юридических лиц, объединившихся для выполнения какого-либо большого проекта (создания и дальнейшего обслуживания атомной электростанции, там одним предприятием не обойдёшься, и менеджмент нужен в масштабах всего проекта). И ещё можно обсуждать общественные организации, клубные объединения, хоббийные проекты, где не требуется образование юридического лица и не предусмотрена коммерческая деятельность, органы муниципальной власти или учебные заведения. А вот слово «предприятие» означает, что речь идёт о стандартном юридическом лице, имеющем целью извлечение прибыли в пользу акционеров.

Так что мы будем говорить про организационную инженерию как специализацию системной инженерии для организаций (игнорируем тот факт, что organizational engineering уже занятый другим значением термин, мы не будем часто им пользоваться, нам нужно подчеркнуть содержание подхода), а системный менеджмент (systems management) будем считать синонимом системной инженерии. Конечно, в состав инженерных практик для создания и развития организации в системном менеджменте входит рассмотрение всех трёх времён:

Разработки (стратегирование, архитектурирование/architecting, проектирование организации или её части/оргвозможности/capability),
создания (организационные изменения: претворение стратегии и оргпроекта/orgdesign в жизнь),
непрерывного развития (эволюция).

Упражнения

Вспомните последние пять проектов, в которых вы участвовали. Поставьте оценку качеству менеджмента в этих проектах (1 — менеджмента вообще не было, 5 — отличный менеджмент). Поставьте отметку успешности проекта (1 — проект неуспешен, 5 — проект крайне успешен). Отметьте те проекты, где вам приходилось заниматься менеджментом (поставьте *). Отметьте те проекты, где вы использовали системное мышление, играя любую роль (поставьте *, если учитывали системы не менее трёх системных уровней и обсуждали конфликты между системами разных уровней).

Номер проекта	Название проекта	Качество менеджмента	Успешность проекта	Участие как менеджера	Использование системного мышления
1
2
3
4
5

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

Ситуация	Что натолкнуло на эти мысли	Чем закончились эти мысли (выход в действие)
1.
2.
3.

Перечислите, какие три последних шага вы предпринимали по поводу обучения менеджменту (чтение книг и статей, прохождение курсов, работа с наставниками/учителями):

Шаги	Что учили (дисциплина менеджмента)	Из каких источников брали материал, год публикации источника	Какие результаты обучения (использование в жизни)
1.
2.
3.

Праксеология, экономика и менеджмент

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

В интеллект-стеке в основании всех этих вопросов лежит методология, как самая общая наука о человеческой деятельности. В части обсуждения обменов и человеческого сотрудничества экономисты предпочитают её называть праксеологией²⁹ (иногда праксиологией, о правописании так и не договорились). Есть несколько разных школ праксеологии, но нас будет интересовать прежде всего австрийская школа праксеологии, потому что из этой школы праксеологии выросла австрийская школа экономики, дающая объяснения многих интересующих нас эффектов. По замыслу праксеологов австрийской школы, на этих идеях должна была вырасти ещё и австрийская школа права, и австрийская школа социологии, но эти проекты так и не случились.

Для понимания экономики и природы денег рекомендуем читать учебник австрийской школы экономики Хесуса Уэрта де Сото «Австрийская экономическая школа» (книга вышла на испанском в 2000 году):

Увы, более свежего SoTA знания по экономике нет. Сама по себе экономика делится на макроэкономику (что происходит с распределением ресурсов на уровне таких систем как страны: рынки, деньги) и микроэкономику (что происходит с распределением ресурсов на уровне таких систем, как фирмы: принятие менеджерских решений). И австрийская школа экономики на базе методологии по факту является рациональным описанием происходящего в экономике. Рациональное — это наличие фальсифицируемой объяснительной модели, высказанной в виде догадки (как говорят в самой австрийской школе, «аксиоматическая теория», то есть основанная на догадках-аксиомах, а не выведенная из опыта эмпирически. Нас как раз не интересуют эмпирические теории, мы придерживаемся рационализма³⁰, подробней это пока рассказывается в курсе «Образование для образованных»).

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

Как управлять территорией (страна, регион, район, город), понимаемой как общество (что такое «управлять» тут даже не будем пытаться объяснять). Тут полно неверных идей, что это тоже менеджмент: страна представляет собой какой-то аналог акционерного общества, где налогоплательщики вроде как его собственники, поэтому идеи менеджмента сюда переносимы. Нет, ни в коем случае. Во-первых, речь идёт о совершенно другом виде систем, где нет понимания, кто именно ответственен за распоряжение трудом и капиталом, обмены труда на долю в прибылях и убытках (отсылки к «народу» тут не помогают, см. обсуждение госпроектов в курсе «Системное мышление»). Во-вторых, речь не идёт об обменах и сотрудничестве, но о простом принуждении силой (скажем, госуслуга получения паспорта или постановки на военный учёт: отказаться нельзя, принцип взаимовыгодности не работает), и «продать акции этого предприятия, купить акции другого» нельзя, последствия смены гражданства тут совсем другие. Есть, конечно, много разных идей о «страховом государстве», конкурентных «контрактных юрисдикциях», но это пока не более чем идеи. В сфере государственного управления говорить о системном менеджменте и применять практики менеджмента нельзя, там работают другие нормативные/инженерные дисциплины.
Как организовать труд чиновников в оргзвене органов муниципального и государственного управления. Речь идёт о том, что целевой системой мы считаем общество, а чиновники (включая депутатов разных выборных органов, которые с момента выборов по факту тоже становятся чиновниками) договариваются между собой о не столько создании (общество уже наличествует), сколько развитии (уж как они понимают это развитие, часто можно увидеть и деградацию) общества. Госорганы трудно назвать предприятием (там совсем другая экономическая часть, это ни разу не «предпринимательство»), но они всё-таки организации, и там должен быть организован системный менеджмент. Со многими и многими оговорками (опять отошлём к разделу про заведомую неудачу госпроектов в курсе «Системное мышление», добавим соображения про «власть развращает, абсолютная власть развращает абсолютно») материал нашего курса может быть использован и для этой работы, практика системного менеджмента применима и к таким оргзвеньям.

Похожее замечание можно дать и по части организации маркетинга и продаж, где тоже различаем практики в цепочке создания (оргзвено маркетинга создаёт и развивает сообщество клиентов):

Сам маркетинг как создание и развитие лояльного комьюнити покупателей продуктов и сервиса — это инженерия сообществ (пропаганда как «маркетинг» идей госстроительства — это создание и развитие обществ, тоже социальная инженерия, хотя часто речь идёт и о создании сообществ, «маркетинг идей госстроительства». Сюда же можно отнести и просвещение как маркетинг образовательных идей). Это не системный менеджмент, он тут не применим.
Организация оргвозможности маркетинга в предприятии (оргвозможности пропаганды в госорганах, партийных организациях, организация просвещения) это создание и развитие организации, для оргзвеньев таким занимается системный менеджмент.

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

Но всё-таки нельзя не признать наличия проблем в аксиоматике австрийской школы, ибо она по факту прекратила своё развитие ещё в 20 веке (недаром рекомендованный учебник выпуска аж 2000 года, более 20 лет назад). Продвинутым студентам хорошо бы подумать над следующими вопросами:

Австрийская праксеология (и экономика как её развитие) рациональна, а не эмпирична, в отличие от мейнстримных направлений экономики, которые эмпиричны (то есть «выводят законы из данных»). Но сама рациональность времён становления австрийской праксеологии (середина 20 века) изменилась³¹. Как изменится праксеология, если в её основе лежит новое понимание рациональности? Например, сегодняшняя (то есть предложенная ещё в прошлом веке) праксеология отказалась от численных оценок в экономике, ибо считает их невозможными (как потому что события считает уникальными неповторяющимися, поэтому не поддающимися статистическим оценкам, так и потому что не надо заниматься цифрами, если из них нельзя вывести теорию). Если учесть новое понимание рациональности, то можно получить и количественные праксеологические и экономические модели. Но это пока не сделано (а когда будет сделано, вряд ли это будет называться «австрийской школой праксеологии и экономики»).
Австрийская праксеология опирается на принцип методологического индивидуализма, который сама же и формулирует: все решения принимает индивид-человек, нет никаких решений «социума» (сообществ, обществ, человечества). Но в последнее время всё активней разбирается вопрос о биологическом индивиде (кто тут субъект эволюции: микроб или микробный мат? Геном, или организм-феном, или всё-таки популяция — ибо лев и львица это уже два организма, популяция? Или львиный прайд? Или все львы на Земле как «биологический вид», то есть не скрещивающийся с другими видами и поэтому все мутации отрабатывают в нём?). Дальше обсуждение идёт по линии центральной догмы молекулярной биологии (что информация от генома к феному идёт прямо, а вот обратный отклик от окружающей среды через мутации, совсем другим способом). Вот всё то же самое для нормативных дисциплин в менеджменте (инженерия организаций) и далее социальной инженерии (идеи организации распределения редких ресурсов — экономика, идеи права, идеи общественного устройства типа «государство», основные черты которого тоже исторически меняются, и т.д.). Тут возможен учёт современных знаний по основанной на физике теории действия (active/embodied inference), квантовоподобности принятия решений, панпсихизме в версии минимального физикализма в определении агентности (в праксеологии агенты — это только отдельные люди, проблема детей с их маленькой разумностью не обсуждается, людей с компьютерами и даже агентности организаций из людей с компьютерами не обсуждается, хотя понятие капитала и фирмы вводится).
Именно австрийская школа праксеологии и экономики дала наиболее адекватное понятие предпринимателя и различение предпринимателя и инвестора. Современная инженерия с её идеями «всё стартап», идеями бесконечного развития, описаниями предпринимательства как поиска аффордансов для каких-то функций могла бы сильно добавить к идеям предпринимательства в их текущем изложении адептами австрийской школы.

Задания

Поставьте отметку о выполнении:

Прочитана книга Хесуса Уэрта де Сото «Австрийская экономическая школа».
Написан пост в блоге по поводу контринтуитивных идей («до сих пор трудно верится, что …») из этой книги.
Написан пост в блоге по как минимум одному изменению в ваших личных или рабочих практиках, которые вы сделали по итогам прочтения этой книги: почему выбрали изменять именно это и какие другие варианты возможных изменений рассматривались, какие получены результаты.

Право, этика и менеджмент

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

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

Ещё один вопрос — это вопрос этики «эксплуатации», который поднимается множеством экономических теорий, например, марксистской. Ваша организация продала какой-то товар и получила доход: как будем его делить между собственником фирмы, работниками фирмы и клиентами (клиенты тут тоже претендуют на этот доход: дайте им на эту сумму скидку! Это же их деньги, не забирайте лишнего!). В курсе австрийской праксеологии говорится, что это всё связано с добровольными ненасильственными обменами, а не «эксплуатацией», теория марксизма попросту неверна (фальсифицирована, логически противоречива), а как делить полученные в ходе работы деньги — это предмет инженерного/предпринимательского решения, решающего многокритериальную задачу оптимизации. Элияху Голдратт в этом месте просто добавляет, что постановку задачи о делёжке денег нужно вывести из ситуации «деньги сейчас» в постановку вопроса «деньги сейчас и в будущем» — а дальше австрийская школа экономики расскажет о предпринимательстве, основанном на межвременны́х предпочтениях предпринимателя. Меньше период времени — меньше риск, точнее предсказание, но может быть и меньше прибыль. Разные предприниматели имеют разные предпочтения уровня риска и уровня возможной прибыли, поэтому у них будут разные решения о распределении денег между удешевлением продукции, выводом предпринимательского дохода и оплатой труда сотрудников (включая выполняющих роль менеджеров).

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

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

Должна ли компания заботиться о каких-то социальных целях? То есть насколько нужно придерживаться идей Environmental, Social, and Governance (ESG) Investing³²? Как всегда в таких случаях, когда речь идёт о социалистических идеях (примат кем-то озвучиваемых «общественных интересов» над любыми другими), то в период моды на такие идеи трудно получить какую-то взвешенную и уж тем более критическую оценку. Скажем, вам предлагается брать не лучших работников, которые вам доступны, а всех подряд, чтобы выполнить условие по достаточному для госорганов количеству работающих у вас инвалидов и «национальных кадров» (как говорили раньше про представителей национальных меньшинств) — надо ли это делать, ибо компания очевидно будет при этом работать хуже, зато это вроде как «правильно»? Или компания строит ещё один кусочек города на планете, вместо удержания Земли в первозданной дикости — тренд на урбанизацию разве не прогрессивен, а «назад к нетронутой природе» это разве не «назад к дикости»? Должна ли компания поддерживать тот или иной международный бойкот, не работая на какой-то «оккупированной территории» (что ещё больше ухудшит жизнь «оккупированных»)? Должна ли поддерживать «культуру отмены», исключая использование заведомо хороших продуктов и сервисов людей и компаний, которые чем-то не понравились тем или иным лидерам общественного мнения? Должна ли компания работать на военных?

И даже более простые вопросы типа исключать или не исключать человеческое поведение типа флирта в рабочее время, или считать это (как и любое другое проявление гендера) заведомо неприемлемым — на работе должны остаться бесполые роботы? Уместно ли увольнять человека, которому остался год до пенсии, но он не нужен компании? Должна ли компания нанимать детей, или это «эксплуатация детского труда»? И как вообще отличить «эксплуатацию» от «добровольной работы», все ж могут уволиться сами, если им более выгодно не эксплуатироваться, чем эксплуатироваться?

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

Например, насколько этично использование схем, описанных в текущем подразделе? Мы считаем, что абсолютно этично: нельзя признавать безумные требования (даже не гипотезы, как в инженерии), предъявляемые самыми разными проектными ролями, утверждающими, что они говорят от имени «народа», если вы понимаете, что эти требования всем делают только хуже, а лучше станет некоторым, и то ненадолго. Не надо делать итальянскую забастовку, не надо бездумно тратить деньги инвесторов, надо просто сконструировать подходящую схему, минимизирующую риски. Этично ли это? Авторы курса считают, что абсолютно этично: законность («что написано в законах и регламентах, то и справедливо», правовой позитивизм в его этатистской версии, легизм³³, закон вполне может санкционировать и произвол и даже необоснованное никак насилие) и правозаконность (справедливо то, что справедливо — результат многоуровневой оптимизации конфликтов разных системных уровней, законы и приказы это отражают, а где не отражают, должны не исполняться).

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

Менеджмент и эволюция

Как и любые практики, менеджмент в организациях реализует набор идей-мемов (мемом менеджмента как все относящиеся к менеджменту мемы в организации), который

Не так уж очевиден, ибо определяет объекты, «невидимые» для необученного глаза. Даже «очевидные» объекты менеджмента не так уж и очевидны, если их не объяснять и просто уповать на опыт работы в организации. Скажем, «работа» и «практика» — это разные объекты, не так просто их научиться различать. Оргроли и оргзвенья с возможностью переназначения оргролей на разные оргзвенья выглядят естественным описанием для организации, но само понятие оргроли в его отличии от оргзвена и связка практики с оргролью и оргзвена с сервисом и потом понятие оргвозможности/capability — это тоже не так очевидно. Неочевидна даже сама идея инженерии организации как «машины, которую нужно спроектировать и построить», а не просто «менеджмента» как уговаривания людей дружно поработать вместе и связанным с этими способами уговаривания бесконечным последующим обсуждением авторитарного стиля управления, мыслительного стиля команд и прочих мемокомплексов (псевдотеорий), мало влияющих на гибкость (скорость изменения) и производительность организации.
Эволюционирует, реплицируясь с мутациями (иногда сознательными «умными мутациями», а иногда и просто с «ошибками передачи») между мемомами разных организаций. Этот мемом отличается от биологического генома следующим:
- Находится в мозгах сотрудников. Сотрудники перетаскивают отдельные идеи менеджмента, перемещаясь из одной организации в другую.
- Находится в софте, который поддерживает какие-то практики. Сотрудники задействуют какие-то менеджерские идеи (например, какие объекты считать важными в менеджменте, именно эти объекты будут отражены в базе данных софта).
- Находятся в учебниках менеджмента, материалах менеджерских курсов.

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

Эволюция идей менеджмента, которая идёт на планете. Мемы разных практик менеджмента осознаются или не осознаются, но переносятся людьми из организации в организацию, при этом удачные переносятся многократно (ибо задействующие их организации успешны), а неудачные приводят к гибели организации, эта зависимость неудачи от использования каких-то определённых мемов осознаётся, и дальше эти мемы не переносятся. Если мем приводит к гибели организации как фенома, то причинно-следственная связь с плохими практиками менеджмента может не осознаваться, а в головах сотрудников эти мемы могут оставаться и нестись дальше, в другие организации. Но если это будут устойчивые неудачи, то эти сотрудники просто не будут в новых организациях начальниками и не смогут распространить эти мемы сильно. Так что всё плохое будет глохнуть в ходе эволюции, а хорошее накапливаться. Но это медленно, кроме тех мемов, которым удалось попасть в образование. Тогда хорошее действенное знание менеджерских практик подвержено «умным мутациям» и удачные мутации накапливаются, это быстрее. Так что мы сейчас говорим об эволюции менеджмента в целом, а как части этой эволюции всего менеджмента — эволюции системного менеджмента, которая в том числе может считаться и частью эволюции системной инженерии.
Развитие (по-русски так передаём evolving, continuous development, continuous improvement, то есть те же идеи «эволюции, постоянного улучшения, прогресса, развития») менеджмента в одной организации. Одни мемы/идеи практик менеджмента, которые используются в разных частях организации или во всей организации в целом становятся обязательными в использовании, а другие наоборот — объявляются вредными. В организациях идёт процесс постоянного улучшения, постоянного развития компании как замены одних практик другими. За это развитие как раз ответственны практики менеджмента, этому посвящён наш курс. Но в число практик, которыми занята организация, входят как практики собственно организации работы (время создания и развития организации), так и практики планирования и отслеживания работ и других ресурсов (например, финансовых ресурсов), это практики операционного менеджмента (время эксплуатации организации). Так что менеджмент помогает эволюции/бесконечному развитию практик как инженерии целевых систем, так и практик развития самого менеджмента: менеджеры организуют как других, так и организуют себя. Менеджмент как практика, которой должна заниматься организация, просто обязан становиться всё лучше и лучше. Менеджмент меняется не только в глобальных масштабах дисциплины, но и в локальных масштабах практики работы организации.

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

Есть множество вариантов, которые на данном этапе эволюции можно назвать «лучшими» (множество вариантов SoTA примерно одной результативности и эффективности)
Эти варианты будут хвалиться на каких-то одних уровнях (личности, организации, сообщества, общества и т.д.), и ругаться на других за неэтичность, неэффективность, некультурность и т.д., ибо конфликты между системными уровнями неизбежны, что в мутации/изменении мемов кажется хорошо на одном уровне, явно будет выглядеть плохо на другом уровне.
Время от времени будут появляться эволюционные скачки, которые будут приводить к резкой оптимизации. Например, египетские писцы с их записями позволяли налаживать какую-то организационную собранность (управление вниманием коллектива по понятийному наведению внимания и удержанию внимания на важных объектах) для больших коллективов ещё во времена фараонов. Но вот пришли компьютеры, и с ними софт issue trackers, реализованный как low code системы — и массово наладилось управление работами в случае case management. Конфигурация работ стала иметь меньше коллизий, менеджмент улучшился. Всё это как раз предмет нашего курса, это будет разъясняться в последующих разделах (и мы даже не даём пока русскоязычных переводов: это всё приходит из мировой культуры, эволюция менеджмента глобальна).

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

Эта эволюция рассматривается нами как специализация практик системной инженерии, так что можно ожидать какого-то развития практик менеджмента по тому пути, который проходят практики системной инженерии в других прикладных инженериях, прежде всего программной инженерии — с учётом, конечно, особенностей оргсистем. Так организационные системы, конечно, нельзя «изготовить и собрать» (процесс DevOps) ни как программные системы, ни как «железные системы».

Менеджмент также занимает особое место в прикладных практиках: им нужно заниматься практически во всех проектах, ибо большинство деятельностей коллективны. Даже если считать личность оргзвеном, всегда можно выделить вниманием команду из ролей, исполняемых субличностями, которые в целом составляют эту личность, и этот ход довольно продуктивен (даже некоторые психотерапии его используют, например internal family systems, IFS³⁴).

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

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

Задания

Поставьте отметку о выполнении:

Прочтена статья «Physical foundations of biological complexity», https://www.pnas.org/doi/10.1073/pnas.1807890115 и на основе её материала написан пост «Почему так трудно выбрать поставщика корпоративного софта».
Прочтена статья «Toward a theory of evolution as multilevel learning», https://www.pnas.org/doi/10.1073/pnas.2120037119 и на основе её материала написан пост с тремя примерами по разделу статьи «E2. Frustration» («E2. Неустроенность») о конфликтах между системными уровнями как причине неустроенности. Желательно брать примеры из своего рабочего проекта. В каждом примере рассмотреть конфликты между не менее чем между тремя уровнями и далее дать примеры неустроенности. Рекомендуем также ссылаться на разъяснения из статьи предыдущего пункта задания.
Прочтена работа «Thermodynamics of evolution and the origin of life», https://www.pnas.org/doi/full/10.1073/pnas.2120042119 и написан пост «Почему я мог бы понять содержание этой статьи, если бы мне это задали при обучении в магистратуре, но сейчас я не могу себе представить, как бы я подступился к этому материалу». Попробуйте прочесть статью, игнорируя формулы, но с учётом содержания двух предыдущих прочитанных текстов из текущего задания.

2. Практики менеджмента и роли менеджеров

Конкретизация мета-мета-модели инженерии до мета-модели прикладной практики

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

Культурно-обусловленной, то есть не придуманной. Понятия, выражаемые этой мета-моделью, и термины, которыми они выражаются, должны браться из текущей организационной культуры, а не просто придумываться. Эти объекты внимания должны легко находиться в жизни, о них должна легко находиться литература.
Нарезка на объекты (роли и их функции-практики) должна быть достаточно мелкой, чтобы отражать самые разные причудливые сочетания функций, которые выполняют самые разные универсальные аффордансы (конструктивные части, которые можно приспособить под выполнение тех или иных функций). Как компьютер может выполнять огромное количество функций, так и оргзвено может выполнять огромное количество функций. Функции должны быть достаточно мелкими, чтобы указать, какие функции какой аффорданс (конструктивный объект, который мы задействовали) выполняет. Поэтому берём какого-нибудь product-manager или product owner в конкретной организации, понимаем, что в этой организации имеют свои особенные представления, чем работа на этих должностях отличается друг от друга, а также отличается от представлений, которые описаны в самой разной литературе самых разных лет издания, написанной людьми, вышедшими из самых разных школ инженерии и менеджмента, и понимаем, что в нашей мета-модели уровня «учебник менеджмента» (вы читаете именно его) есть какие-то роли, которые вы в разных сочетаниях можете найти у агентов, занимающих эти должности (это могут быть не только люди!). Далее вы понимаете, что происходит, каких ролей не хватает, какие дублируются, какие роли выполняются для разных системных уровней и поэтому неминуемо конфликтуют, и так далее.
Названия ролей не должны провоцировать ошибки типизации. Если вы назовёте узкую роль очень похожей на распространённое название широкой должности, у вас дальше будут проблемы в понимании разными людьми, ибо в разных организациях одинаково называемые должности (их популярных названий не так много, например «менеджер проектов») назначаются на удивительно разные наборы ролей. При этом должность — это оргместо и ещё упоминание относится ко времени организовывания/создания организации, ибо во время эксплуатации вас будет волновать не должность (агент-сотрудник::«конструктивный объект», размещённый на должности::оргместо, дающий оргзвено в оргструктуре), а (орг/проектная/деятельностная/практическая/трудовая/инженерная)роль — это функциональный объект, важный для времени выполнения работ по практикам, operations time. Если слово будет провоцировать путать агентов-в-должности (оргзвенья) и роли с их мастерством делать что-то в целевом для них domain, будут проблемы или в обсуждении организовывания (кто куда, кому подчиняется в организовывании), или в обсуждении собственно работы (что они делают, а не кому подчиняются), а также в обсуждении концепции организации и архитектуры организации (как связано то, что делают с тем, кто на какой должности). Поэтому такие «общераспространённые для должностей» слова надо табуировать в мета-модели ролей. Пример: слово «стейкхолдер» понималось иногда как агент, а иногда как роль, что приводило к путанице (и Вася Пупкин, играющий Принца Гамлета, «стейкхолдер», и Принц Гамлет «стейкхолдер» — оба варианта звучат хорошо, поэтому табуируем «стейкхолдера» и Васю называем агентом, а Принца — ролью. Принц-агент звучит не очень хорошо, но Принц-роль — ОК, Вася-роль не звучит, Вася-агент — ОК. Про табуирование понятий, которые вносят путаницу, рассказывается в курсе «Моделирование и собранность», а затем повторяется в курсе «Системное мышление». Дальше в нашем курсе мы дадим примеры табуирования «системного инженера» и «предпринимателя».

Мета-модель уровня учебника (метаУ-модель) в нашем курсе системного менеджмента получается конкретизацией мета-мета-модели системной инженерии из интеллект-стека, при этом учитываются указанные выше принципы культурной обусловленности, мелкой нарезки и непровоцирования ошибок типизации.

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

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

Вы узнаете в «Системной инженерии»::мета-мета-модель, что системы создают разработчики::инженеры::роль, а из нашего курса «Системный менеджмент»::метаУ-модель вы узнаете, что систему-организацию создают организаторы::разработчики::инженеры::роль, а придя в одну конкретную организацию вы узнаете, что роль организаторов там у агентов, которые находятся в офисе CTO (все эти «офицеры» СTO, CIO и даже CEO в крупных фирмах имеют «офисы», работают-то они не в одиночку, а задействуя множество сотрудников в своих офисах). А вот в другой организации вы найдёте, что организаторы в отдельном оргзвене «Служба развития», а CTO и его офис заняты совсем другими вопросами. В третьей организации организаторами становятся кто угодно, просто создаются рабочие группы оргпроектов, и членство в них определяется не штатным расписанием. Вы приходите в новую для вас организацию (проект, предприятие, команду) не с пустой головой, вы что-то об этой организации уже знаете перед тем, как в ней оказаться. Например, вы знаете, что искать в любой организации, это известно из метаУ-модели нашего курса: роль организатора должна быть, и она должна заниматься теми практиками, которые описаны в курсе менеджмента!

Конкретизация системноинженерных практик и ролей для менеджмента

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

Разработка (выполняет разработчик/developer): изучить предметную область и предложить концепцию использования (инкремент, «фича», новая функция), концепцию системы (как и из чего сделать систему — с ограничениями от архитектора), согласовать их с визионером, затем спроектировать с точностью, достаточной для изготовления (используем моделеры), затем изготовить на конвейере/платформе, подготовленном технологом производства (DevOps/platform engineering) и ввести в эксплуатацию, а затем эксплуатировать — и всё это непрерывно.
Надзор/governance за выгодностью (выполняет визионер, часть роли product manager, ответственный за business case): установить приоритеты для реализации фич/инкрементов и отслеживать, что создание системы в целом (всеми автономно работающими разработчиками, архитектором и DevOps) приносит прибыль, а не убыток.
Архитектурная практика (выполняет архитектор, ответственный за архитектурные характеристики): установить приоритетные архитектурные характеристики, принять решения по способам их достижения путём предписания деления системы на части и указания способа взаимодействия этих частей, а также отслеживать, что создание системы в целом улучшает эти характеристики (то есть, что не накапливается «технический долг» как долг по проведению работ, предотвращающих ухудшение архитектурных характеристик в долгосрочной перспективе)
Инженерия «производственного конвейера» (выполняет DevOps/инженер «производственного конвейера»/internal development platform, ответственный за средства/технологию воплощения проектных и архитектурных решений, а также технологию эксплуатации результата): создание условного завода-автомата/pipeline/internal development platform («конвейер»: оборудование и софт в компьютерах, но иногда это всё не работает без людей-операторов — и это не совсем «автомат», а «обычный завод»), который используется разработчиками и архитекторами, чтобы воплотить проектные и архитектурные решения, провести инженерное обоснование (испытания, проверка соответствия архитектурным решениям и т.д.), а затем выдать пользователям/клиентам для эксплуатации. Современный взгляд на это — «изготавливают» фичи системы разработчики, а DevOps только предоставляют им полностью работающее и обслуживаемое «заводское оборудование»/конвейер/pipeline/IDP (internal development platform). DevOps становится инженером конвейера, он осуществляет platform engineering, разрабатывает тот самый «завод-автомат», «конвейер», internal development platform. Редко бывает, что это именно завод/фабрика с настоящим конвейером или трубопроводом, ибо системы бывают крайне разные. Конвейер/platform начинается с правильной системы автоматизации проектирования, заканчивается системой поддержки цифрового двойника и не требует от разработчика никаких специальных знаний по его запуску и наладке, разработчики его просто используют. Вы как разработчик сами пользуетесь лопатой, чтобы копать, и точно так же сами пользуетесь internal development platform, чтобы создавать системы. Эту платформу вы сами не создаёте, её создают инженеры производственного конвейера/DevOps/инженеры платформы разработки, но пользуетесь платформой вы сами, это называется «самообслуживание»/self-service³⁵. Если таки надо дорабатывать IDP, то это обеспечивают инженеры конвейера/платформы, то есть исполнители ролей DevOps, но они сами ничего не изготавливают в целевой системе, занимаются только «станочным парком». Кнопку «изготовить» нажимает сам разработчик, а не DevOps, и он же имеет дело с последствиями, это принципиально: you build it, you run it — ты это строишь, ты и эксплуатируешь³⁶). Тут сразу сложно, ибо мы получаем «систему создания внутри системы создания», создатели-операторы целевой системы «холдинг из конструкторского бюро (КБ) и завода» и «создатели-операторы КБ плюс завода». При этом понимаем, что в большинстве случаев это совсем не похоже на «конструкторское бюро» и «завод», например, трудно говорить о «конструкторском бюро для оргсистем» и «заводе оргсистем», «конструкторском бюро мастерства» и «заводе мастерства» и даже для компьютерных программ это не так очевидно. Но структура производства и эксплуатации везде будет одинаковой.

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

Напомним системную схему проекта:

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

В организации редко бывает один проект. Этих проектов множество. Они как иерархичны (проекты и подпроекты), так и множественны (заказная разработка: разные заказчики получают разные системы), и всё это сложным образом перепутано.
Редко так мало звеньев в цепочке создания. На диаграмме три звена, а в жизни в типовых ситуациях 4-6 звеньев в не самых даже больших проектах. И там не цепочки, а «деревья», и они сложно перепутаны, если учитывать ещё и множественность самих проектов из предыдущего пункта.
Схема используется для MVP системы, а затем для каждого инкремента/фичи в порядке «непрерывного всего»/continuous everything (разработки, введения в эксплуатацию). То есть нужно учитывать, что для каждого инкремента нужно порождать адаптированный экземпляр диаграммы (и напомним, что лучше бы это делать в табличных представлениях, а не графическом представлении диаграммы).

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

Эту схему мы прокомментируем чуть дальше, а пока заметим, что конкретизация из схемы «для всех случаев» в схему «для нашего проекта» ведётся на двух уровнях метамоделирования:

Мета-модель domain «как в учебниках предметной области» (где самая общая терминология, иногда на иностранном языке, а ещё перечисляются альтернативные варианты представления предметной области, разные школы мысли с предложением разных практик и способов их описания). Для краткости можем называть её метаУ-модель (как в Учебниках)
Мета-модель domain ситуационная, как это принято в вашей организации, где термины могут быть совсем не «из учебника», а исторически сложившимся сленгом, изо всего разнообразия практик выбраны какие-то конкретные практики (необязательно SoTA, а уж какие исторически сложились, при этом адаптированные под конкретный подвид систем или особенности систем создания — скажем, не просто жарка картошки, а жарка картошки особых сортов, как в McDonalds). Для краткости можем называть её метаС-модель (Ситуационная).

Предметная область/domain в каждом звене цепочки создания, представленном отдельной зоной интересов своя! Где-то это domain целевой системы, где-то это domain менеджмента, где-то будет domain маркетинга как работы с сообществами, и т.д. Когда у вас не мета-мета-модель, а просто мета-модель с одним «мета» — это уже не «безмасштабно» и «беспредметно» типа «каких угодно систем», а для какого-то масштаба, какой-то предметной области работы с какими-то конкретными типами систем.

Примеры ошибок, которые делают практически все наши студенты, проверьте, что вы их не делаете (тут приведены, конечно, не все ошибки, люди очень изобретательны в ошибках, но вот эти делают практически все новички в системном менеджменте):

Число звеньев цепочки создания (включая то, что разветвления цепочек создания даже не рассматривается, там ведь дерево, а в общем случае направленный граф из таких цепочек) ровно такое, как на наших картинках. Нет, выше было написано, что там граф, и даже в линейном случае очень часто 5-6 звеньев в такой цепочке. Поэтому нельзя копировать схему из нашего курса, в ней просто другое число элементов! А почему случай не будет линейным? Например, вы тут не видите организации, которая создаёт клиентуру (команда, выполняющая практику продвижения), а она обычно есть.
Поскольку наш этот единственный пример с курсом (мета-модель, как раз пример конкретизации) явно не подходит для проекта студента, студент вздыхает и берёт диаграмму общего вида (мета-мета-модель), прямо из курса «Методология», где она приводится впервые. И рассуждения ведутся для мета-модели предметной области устно, а на диаграмме так и остаются нетронутыми типы мета-мета-модели в надежде, что «когда-нибудь потом, не сейчас» будет проведена адаптация для предметной области и «когда-нибудь потом всё перерисуем, и даже переложим в таблички». Это откладывание «на потом» ошибка: в этом и смысл всей работы с мета-мета-моделью, что надо проводить адаптацию, это же поиск важных объектов внимания в вашем проекте, которые вы будете отслеживать! Найдите их, выясните их имена! Честно стройте вашу собственную схему, адаптированную для вашей системы, и в которой другое число элементов, чем на диаграммах из наших курсов (может быть и то же самое, но такое бывает редко, не промахнитесь — если визуально ваш труд «по картинке» и по именам основных альф похож на то, что в наших курсах, то вы уже ошиблись, хватает пары секунд взгляда на результаты вашего моделирования, чтобы это понять).
Эти диаграммы распухают, графически их поддерживать становится невозможно. Графическая форма не позволяет легко вносить изменения, диаграммы плохо эволюционируют, они хороши для случая «один раз красиво нарисовал, потом показал начальству, потому что это красиво», а вот редактировать их — замучаетесь, их долго править. Вы уже знаете, что для альф придётся добавлять подальфы, для альф и подальф задать ожидаемые состояния, для них сформулировать контрольные вопросы и превратить всё это в кейс в управлении работами — но вместо того, чтобы делать это в табличках какого-нибудь универсального low code моделера, делаете очень долго в графическом виде. А поскольку изменения вносить в диаграмму трудно, то не вносите изменения, и диаграмма теряет актуальность и потом не превращается в исполняемую модель управления кейсами. Поэтому не увлекайтесь рисованием, вовремя переходите к табличному моделированию.
Обращается внимание не на понятие, а на термин, «совпадение слов», а не совпадение значений — это грубая ошибка. Так, на первом уровне создания «организация», «организация проекта», «предприятие», «инженерная команда», «поток студентов на курсе» — это всё про одно и то же: организованную группу людей.

Теперь надо показать, как оргпроект (создание организации какого-то звена в цепочке создания, плавно переходящее в бесконечное развитие этой организации — мы будем называть это «проектом оргразвития», с акцентом не столько на момент создания, сколько на момент continuous delivery новых оргвозможностей/capabilities и фич в этих оргвозможностях) раскладывается на вышеописанные роли из «Системной инженерии». Различаем при этом время развития организации/«организационных изменений»/«change management» (не путаем «organizational change management»/«управление организационными изменениями»/организовывание с «configuration and change management» из инженерии целевой системы) и время работы/функционирования/operations организации/оргзвена/предприятия/проекта (тут мы показываем эти термины как синонимы: организации/оргзвена/предприятия/проекта, но в реальности за ними могут скрываться разные сущности, будьте внимательны).

Итак, менеджмент как инженерия предприятия включает в себя следующие практики и роли:

Организатор (аналог developer в системной инженерии) выполняет организовывание. Он предлагает концепцию использования организации (зачем её делать, каких изменений в мире ожидать, какие оргизменения нужно сделать, какие практики нужно освоить организации как development и затем превратить их в оргвозможности/capability как delivery, чему научиться новому). Предлагает, ибо это «гипотеза», организационная гипотеза/guess. Он затем разрабатывает концепцию организации (как и из чего сделать организацию — с ограничениями от архитектора), затем проектирует (моделеры! Корпоративный софт!) с точностью, достаточной для «изготовления» (конечно, это не заводское изготовление! Потребуются закупки оборудования, найм сотрудников, лидерство и т.д.), будет работать администрация (аналог DevOps/internal development platform engineering), затем введение в эксплуатацию — и всё это непрерывно, цикл непрерывного оргразвития.
Практику прибыльности осуществляет бизнесмен, ответственный за отношения с инвесторами (IR, investor relations) и надзор за прибыльностью. Так же как визионер/стратег (например, как одна из ролей должности product manager) отслеживает, что клиентура «покупает» целевую систему дороже, чем затрачивается на её изготовление, бизнесмен отслеживает, что инвестура (все владельцы, их часто называют одним словом «инвесторы») «покупает» организацию не дешевле, чем нужно для начала зарабатывания, выхода на break even. Если денег от инвесторов не удалось собрать, то организация никому не нужна, её не будет. При этом инвесторы сами контролируют то, что на эти деньги будет прибыль в рамках corporate governance (это как бы «потребительский надзор», «клиентский контроль за качеством целевой системы» — только этой системой тут будет организация, а «клиентом» будет «инвестор»)! Бизнесмен компании отслеживает обратную ситуацию: чтобы инвестиций хватило для организации нового дела, он должен проверить идею/орггипотезу организатора, которая достаточно убедительна для инвесторов. Отдельно можно обсуждать, как все упомянутые роли разложены по должностям в некоммерческих организациях, в небольших стартапах, в крупных холдингах, государственных/правительственных организациях, и даже командах агентов внутри личности (internal team в практике ролевого мастерства личности, команды из частей личности с интеллектом меньше, чем у полной личности). При этом как визионер сам не осуществляет продвижения (маркетинг, реклама, продажа), а лишь выполняет оценку выгодности производства продукта, сервиса, фичи, так и бизнесмен не сам выполняет практику привлечения инвестиций, но он занимается стратегированием: согласует все идеи о том, как компания может зарабатывать деньги для инвесторов. И если эти идеи будут убедительными, то как «в основе хорошей рекламы лежит хороший товар», то и тут «в основе хорошего привлечения инвестиций лежит прибыльная фирма». Вот бизнесмен и озабочен этой прибыльностью.
Практика архитектуры выполняется архитектором организации (часто архитектора выделяют на уровне предприятия, самой верхушке организации, поэтому называют архитектор предприятия. Но легко вообразить роль архитектора какой-нибудь службы предприятия, а не всего предприятия): установить приоритетные архитектурные характеристики, принять решения (с учётом обратного манёвра Конвея) по способам их достижения через предписание деления организации на отдельные максимально автономные/независимые оргзвенья и указания способа взаимодействия оргзвеньев, а также отслеживания/надзора/governance, что оргизменения как результат работы разных организаторов улучшают эти характеристики организации в целом (то есть, что не накапливается «технический долг» из системной инженерии, когда система — организация): «организационный долг» — это работы, которые надо выполнить для предотвращения ухудшения архитектурных характеристик организации в долгосрочной перспективе.
Администрирование (аналог DevOps/internal development platform engineering) как практика, выстраивающая и эксплуатирующая «организационный конвейер», позволяющий организаторам проводить изменения. Администраторы довольно разнообразны, ибо тут идёт довольно дробное разделение на подроли: финансисты, снабженцы (административно-хозяйственная часть, закупки), HR, офис-менеджеры, хелп-деск и ресешпн, и т.д. Администратор (который как врач, давно специализирован в своих подролях, и эти подроли выполняются разными даже не людьми, а часто целыми службами) предоставляет разработчикам «конвейер», по которому организаторы проводят изготовление оргвозможностей: получают необходимые «сырые ресурсы» и проводят их превращение в оргвозможности согласно разработанным ими оргпроектам/orgdesign при надзоре со стороны архитектора, следящего за общими архитектурными характеристиками организации. Тут та же сложность, что в определении «производственного конвейера» в более общем случае системной инженерии — этот конвейер сначала надо построить, а затем только эксплуатировать. То есть обсуждаем и время создания целевой организации, и работающий в это время «конвейер» администратора создателя организации, но перед временем создания организации нужно предусмотреть ещё время создания этого «конвейера» его разработчиком/«создателем создателя организации»/«создателем администрации». Сложность в том, что в жизни всё это происходит одновременно в физическом времени, а «логические» времена создания выделяются исключительно вниманием: и производится целевая система, и производятся организационные изменения в организации-создателе, и производятся организационные изменения в администрировании. Эта цепочка создания каждый раз продумывается — и таки дотягивается до целевой системы в конечном итоге, или до клиентуры, или до инвестуры (фирма создаёт минимально три системы). Пока мы будем называть администраторами и создателей (включая разработчиков/организаторов) конвейера (platform engineers) и его работников (не всё там удаётся автоматизировать, хотя даже HR практики сегодня пытаются автоматизировать), но если в вашем внимании создание самого этого конвейера, вам придётся их различить. К цепочкам создания надо быть внимательным, они в жизни не такие простые, как на примерах диаграмм из нашего курса! Сам термин взят из критики Henry Mintzber программ MBA (master of business administration): они вроде нацелены на подготовку организаторов и стратегов в целом, но по факту готовят глав финансовых служб, глав служб HR и прочих администраторов, которые явно не справляются с должностями, требующими компетенций в других ролях. Они «работники производственного конвейера для поддержки жизни организации, поддержки развития», а после приобретения какого-то опыта могут пытаться ещё и строить такой конвейер. Но вот использование этого конвейера для развития организации в целом требует других специализаций: организатора, бизнесмена, архитектора организации. И мы понимаем, что слово «администратор» очень широкое, но всё-таки означает чаще «исполнительные» роли поддержки какого-то конвейера, а не роли, занятые использованием этого конвейера для какого-то дела (при всём понимании, что «всё со всем связано, конвейер должен быть согласован с типом тех систем, которые по нему проходят»).

Примеры соответствия системноинженерных и прикладных ролей

Давайте попробуем изложить всё то же самое в виде таблички, в которой пропишем роли (но за каждой ролью обязательно скрывается практика этой роли, её просто не будем писать для экономии места):

Роль создателя системы (из мета-мета-модели)	Инженер/деятель/создатель/constructor
Стадия на V-диаграмме	Время замысливания/Conception time	Время проектирования/design-time			Время изготовления/ manufacturing time		Время эксплуатации/operations time	Время проекта создания платформы разработки
Подроли создателя системы/роли команды организации создания (из мета-мета-модели)	Визионер/visionary	Архитектор/architect	Разработчик/developer					Инженер платформы разработки
	Визионер/visionary	Архитектор/architect	Проектировщик/designer		Технолог/manufacturing engineer		Оператор/operator	Инженер платформы разработки
Роль создателя целевой системы (из метаУ-модели, пример киберфизической системы)	Инженер целевой системы
Подроли создателя целевой системы/роли команды организации создания (из метаУ-модели, пример киберфизической системы)	Визионер целевой системы	Архитектор целевой системы	Разработчик/developer целевой системы					Инженер платформы разработки целевой системы
	Визионер целевой системы	Архитектор целевой системы	Проектировщик		Технолог		Оператор	Инженер платформы разработки целевой системы
Роль создателя организации создания целевой системы (из метаУ-модели системного менеджмента)	Менеджер (в широком понимании)/инженер предприятия
Подроли организации развития /Подроли команды менеджеров (из метаУ-модели системного менеджмента)	Бизнесмен	Орг-архитектор	Организатор					Администратор
			Менеджер оргразвития				Операционный менеджер
			Орг-проектировщик		Лидер/управляющий орг-изменениями		Операционный менеджер
Роль создателя клиентуры	Продвиженец
Подроли создателя клиентуры/ организации продвижения (из метаУ-модели продвижения)	Разбиение, какое определено в учебнике по практике продвижения (маркетинга, рекламы и продаж)
Роль создателя мастерства	Учитель
Подроли организации создания мастерства/курсов, школы, факультета, кафедры (из метаУ-модели обучения)	Культуртрегер	Архитектор учебной программы/curriculum	Автор курса		Преподаватель		Тьютор	Декан
	Культуртрегер	Архитектор учебной программы/curriculum	Методолог	Методист	Предметник	Лидер	Тьютор	Декан
Роль создателя инвестуры	Фандрайзер/fundraiser
Подроли фандрайзера/создания инвестуры (из метаУ-модели инвестирования)	Разбиение, какое определено в учебнике по привлечению инвестиций

Как совместить эту табличку с системной схемой проекта? В первой же зоне интересов создателя есть альфа организации проекта создания целевой системы (её могут называть в каких-то вариантах диаграммы альфой «организация» без упоминания «проекта создания», альфой «команда», альфой «инженерная команда»), это и есть оргроль «инженера», и в ней можно выделять практики визионера, архитектора, разработчика (проектировщика, технолога, оператора), инженера платформы разработки. Если берём «создателя создателя», то там тоже есть организация развития — развития той самой команды инженеров, это оргроль «менеджер». Это редко называют «организация менеджеров», но вот «менеджерская команда» вполне можно услышать, равно как и просто множественное число «менеджеры», равно как и «служба развития», хотя бы часть этой команды, например, люди в подролях оргроли менеджера развития. У оргроли «менеджер» (помним, что в жизни эта роль обычно исполняется целой организацией, а не одним человеком) множество подролей, это будут подальфы — бизнесмен, орг-архитектор, организатор (с его подролями, которые в проекте могут быть отслеживаемы как подальфы, проходящие каждая свои состояния), администратор.

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

Можно, конечно, обсуждать — в каких именно командах и как должны работать все указанные роли, но уже понятно, что такие быстрые прикидки («кто такой преподаватель? Он инженер-технолог, стадия изготовления. Это не автор курса? Сколько нам надо иметь преподавателей? Сколько авторов курса? Понимаем ли мы, что преподаватели по конкретному предмету/курсу — по роли это не столько члены «потоков», сколько члены команды создания курсов, подроль «разработчика»? Получается, что команда потока состоит из людей, которые частично пришли в неё из другой команды! То есть «поток» представляет собой не столько «команду разработки мастерства», сколько банальный станок изготовления мастерства (предоставляется деканом как «инженером платформы», ответственным за «станочный парк»), а инженер-технолог/преподаватель просто использует студенческую группу как конвейер со станками, изготавливающий мастерство в мозгах студентов в ходе занятий. Но точно так же можно использовать и компьютерную систему, и даже вообще обойтись без преподавателя, если у нас «завод-автомат» (скажем, так устроены онлайн-курсы).

То, что вы должны делать, когда адаптируете системную схему проекта — это проводить вот такие рассуждения. И, конечно, поскольку каждый раз речь идёт о каких-то командах и налаживании их работы, нужно задавать вопрос — а кто и как эти команды организует? Это уже будет обсуждением менеджерских ролей. Команду создания курса надо организовать, команду потока надо организовать — первую как команду разработчиков/авторов курса и преподавателей этого курса, вторую как учебную группу (куда будут входить в том числе и люди первой команды — преподаватели). Число рассматриваемых ролей быстро начинает расти, и даже для небольшого проекта вы будете находить не только от 15 внешних ролей проекта, но и чуть ли ни несколько десятков внутренних ролей, нужных для создания самых разных встречающихся в проекте систем, и эти роли будут раскиданы по самым разным командам (да ещё и люди в этих командах будут пересекаться, но орг-архитекторы будут приглядывать, чтобы команды всё-таки были по возможности автономны).

Как это всё увязать вместе? Понимая, что в наших курсах даны только типы мета-мета-модели интеллект-стека (включая практику системной инженерии), а в нашем курсе «Системного менеджмента» только метаУ-модель менеджмента, при этом даже если вы будете пытаться моделировать очень простую организацию, вам придётся сразу рассматривать довольно сложные раскладки разных ролей по командам (хотя все эти роли могут играться даже одним человеком, он же и будет единственной «командой»). Так, фирма должна «изготовить» целевую систему, инвестуру (привлечь инвестиции), клиентуру (заполучить клиентов). Вот пример³⁷ объектов, которые нужно при этом отслеживать: системная схема предприятия, и это опять-таки только пример! Не пытайтесь скопировать его для вашей фирмы, для вашего проекта! Чётко видно, что визуальное представление «не работает» — вам его будет довольно сложно адаптировать для вашей фирмы (хотя рассматривать в курсе диаграммы довольно просто, но непросто будет редактировать³⁸), нужно сразу переходить на табличное моделирование. «Фирма» — это альфы в голубых областях интереса, клиентура и инвестура — внешние проектные роли для разных команд в фирме, показаны в зелёных областях интереса надсистем, связанные с целевой системой альфы показаны в её жёлтой области интереса. Ориентируемся всегда на жёлтенькое — область интересов целевой системы, всё остальное разворачиваем вокруг неё. В большинстве основных альф показаны через перечисления ещё и их возможные подальфы:

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

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

Упражнения

Впишите в таблицу, какую часть времени вы выполняете менеджерские роли изо всего вашего рабочего времени и какую часть времени — практики инженерии целевой системы (если вы не занимаетесь целевой системой, а далеко по цепочке создания, можете взять вашу систему — ту, которую создаёт и развивает ваш проект). В сумме по столбцу необязательно будет 100%, ибо кроме целевой/вашей системы и её системы создания (вашего проекта) ваше время может расходоваться на другие системы.

Система	Название системы	Роль	Процент времени работы
Целевая/ваша		Разработчик
Целевая/ваша		Визионер
Целевая/ваша		Архитектор
Целевая/ваша		DevOps
Оргсистема создания целевой/вашей системы		Организатор
Оргсистема создания целевой/вашей системы		Бизнесмен
Оргсистема создания целевой/вашей системы		Архитектор предприятия
Оргсистема создания целевой/вашей системы		Администратор
Другие системы в цепочке создания		Все роли

По итогам заполнения предыдущей таблички заполните табличку по соответствию вашей должности и ваших ролей (роли берите обобщённые, по мета-мета-модели из «Системной инженерии» и метаУ-модели из «Системного менеджмента». Для ясности можете указывать системы, для которых выполняются эти роли, если систем несколько):

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

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

Система	Название системы	Роль	Процент времени работы
Целевая/ваша		Разработчик
Целевая/ваша		Визионер
Целевая/ваша		Архитектор
Целевая/ваша		DevOps
Оргсистема создания целевой/вашей системы		Организатор
Оргсистема создания целевой/вашей системы		Бизнесмен
Оргсистема создания целевой/вашей системы		Архитектор предприятия
Оргсистема создания целевой/вашей системы		Администратор
Другие системы в цепочке создания		Все роли

И соответствие должности:

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

Широкое, узкое и слишком узкое понимание менеджмента. Менеджерские (под)практики и (под)роли

Только что мы определили, что если создаём и развиваем организацию, то нам нужны следующие роли для инженерии организации как общей практики: организатор::разработчик, бизнесмен::визионер, орг-архитектор::архитектор, администратор::DevOps/«organizational platform engineer» (и сюда же неявно относим и сотрудников этой организационной платформы). Эту инженерию организации мы затем назвали менеджментом, а подход к такому же описанию менеджмента::инженерия, как в системной инженерии — системным менеджментом.

Зачем разбираться в том, как мы получили описание практики менеджмента из описания практики инженерии? Затем, что в жизни никогда не будет «как в учебнике», и вам придётся самостоятельно «дорабатывать учебник», это неизбежно. Так что хорошо бы вам знать, каким образом (какой практикой) этот наш курс «Системный менеджмент», содержащий метаУ-модель с «типами учебника», создан, чтобы знание из курса не оказалось плохо применимой в жизни догмой. Вы всё время будете сталкиваться с новыми и новыми ситуациями, где нужно будет не только конкретизировать метаУ-модель менеджмента до метаС-модели для типов важных объектов во впервые встреченной вами организации, но и адаптировать саму метаУ-модель — начиная с таких маленьких адаптаций, как смена терминологии. Вы-то будете понимать, что «роза пахнет розой, хоть розой назови её, хоть нет», что термины и важны, но и неважны тоже, а для окружающих вас людей терминология может вдруг оказаться принципиальной. И вы тогда организатора назовёте не организатором, а вожатым, вожаком, вождём, начальником, шефом, боссом или ещё как-нибудь. Но мышление у вас останется прежним, в терминах метаУ-модели, ибо вам жизнь в вашей организации придётся всё время состыковывать с жизнью в других организациях, и нужно будет поддерживать некоторый общий для них всех язык размышлений, «знание принципов освобождает от знания фактов», мышление надо экономить. В некоторых же случаях вам придётся разбираться на более глубоком уровне, например, вы можете встретить книгу по классической системной инженерии, где инженерия целевой системы и менеджмент инженерной организации серьёзно перепутаны вместе до полного неразличения, плюс остались какие-то старые идеи (типа инженерии требований и водопадного проектного управления). Что вы будете делать? Вам потребуется понимание, как использовать фундаментальную мета-мета-модель интеллект-стека и прикладную мета-модель (в нашем курсе это метаУ-модель менеджмента). И ещё надо будет докрутить самостоятельно это знание до более приземлённого вида метаС-модели менеджмента в вашей конкретной организации. Это всё практики метамоделирования как подпрактики онтологической инженерии (создания онтологий, подробнее проходится в курсе «Онтология и коммуникации», а затем работа с онтологиями проходится во всех курсах: все мета-уровни моделирования какой-то системы, в данном случае организации как системы создания целевой системы — это и есть онтология. Её нужно создать, просто это создание разнесено по очень разным сообществам. Интеллект-стеком и мета-мета-моделью занимается одно сообщество (условно «системные мыслители», «философские логики»), метаУ-моделью другое (профессиональное сообщество, создатели body of knowledge), метаС-моделью третье (работники организации и все, кто с этой организацией сталкиваются и хотят лучше понять там происходящее), моделью (операционной) — работники организации, но уже во время operations, а не во время construction, как в случае с метаС-моделью.

С точностью до довольно запутанных цепочек создания (то есть в предельном упрощении) в организации вы найдёте множество самых разных ролей:

Все, кто занимаются инженерией (созданием и развитием) целевой системы — инженеры целевой системы. Мы оставляем тут общее слово «инженеры», понимая, что для каждой предметной области это слово будет меняться. Например, если целевая система — это тело человека, то это «врачи». Помним, что нас тут интересуют не слова, а роли в деятельности. Если интересно, как должны работать эти люди, надо брать курс «Системная инженерия» и адаптировать его для предметной области примерно так же, как мы это делаем для системы-организации. Среди прикладных инженеров, например, корпоративных информационных систем можно найти разработчиков, визионеров, архитекторов, DevOps. И мы дальше для краткости будем говорить, что прикладные инженеры создают целевую систему (а длинно — создают и развивают, continuous everything).
Все, кто создаёт и развивает клиентуру целевой системы (инженерия клиентуры: маркетинг, реклама, продажи) — это продвиженцы по их роли, а практика — продвижение продукта или услуги. Важно понимать, что клиентура::сообщество это не целевая система, а внешние проектные роли в проектах системного окружения целевой системы (прежде всего проект надсистемы). В менеджменте мы найдём и частный вид клиентуры: инвестуру, потенциальных собственников, покупателей долей в самой компании. Так что обсуждение тут опять уровня мета-мета-модели, общей для самого разного вида систем. Конечно, агент, выполняющий роль прикладного инженера, может хорошо объяснить, чем его система лучше систем конкурентов, но всё-таки продажей занимается обычно не он: главное ведь найти среди всех людей на Земле тех немногих людей, кому это надо объяснять, и вот этот «поиск людей в окружении целевой системы, которым нужна наша система» совсем другая практика, чем разбирательство с самой целевой системой. Но и тут вы можете найти разработчиков, визионеров, архитекторов, DevOps (тут даже не будем давать примеров, но обычно «конвейер», который тут строится DevOps, сегодня часто называется «воронка продаж», отдельные «инкременты» создаваемой клиентуры — это сегменты целевой аудитории, обрабатываемые «маркетинговыми/рекламными кампаниями» — всё то же самое на уровне типов мета-мета-модели системной инженерии, но другие слова для других типов систем). Для краткости мы будет говорить, что продвиженец развивает клиентуру, а не создаёт и развивает клиентуру, упор на бесконечное развитие, а не на однократное создание. Слово-термин для «продвиженца» везде будет другое, терминология тут совсем ещё не устоялась. Например, бизнесмен как агент в роли «продвиженца» продаёт организацию потенциальным акционерам/собственникам/инвесторам/«инвестуре». И всё чаще и тут используется термин «воронка продаж», всё выглядит очень похоже: изо всех людей планеты нужно найти тех, кто заинтересован в его «товаре» и сервисе этого «товара» по добыче из него денег либо через дивиденды, либо в форме последующей перепродажи по более высокой цене.
Все, кто занимаются инженерией организации как созданием и развитием организации-создателя целевой системы — инженеры организации. Это и есть менеджеры в широком понимании, описанные выше: организатор::разработчик, бизнесмен::визионер/стратег, орг-архитектор::архитектор, администратор::DevOps/«инженер оргплатформы». Тут мы тоже для краткости будем говорить «развитие организации», а не полностью и точно «создание и развитие организации», называя функцию (обще)менеджерской роли, но для самого функционального объекта/роли «менеджер» по отношению к организации будем говорить «создатель», а не «создатель и развиватель» и не «развиватель». Кратко получится «создатель организации её развивает», а не «создатель и развиватель организации её создаёт и развивает». При этом интуитивно понимаем, что MVP организации — это когда она не распалась, исчерпав деньги инвестора, а как-то функционирует, получая рыночный доход (в том числе и до момента break even³⁹ — то есть организация что-то зарабатывает). Дальше в ней в ходе по возможности бесконечного развития появляются новые capability, которые позволяют ей сначала зарабатывать больше, чем расходовать, а потом и начинать возвращать инвестированные деньги, это может продолжаться и несколько лет, а в случае удачи и сотни лет.

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

В принципе, это же верно и для прикладной инженерии. Если взять ту же разработку корпоративного софта, то разработчика вполне назовут software engineer, а вот DevOps так уже не назовут. Понятие platform engineer для создаваемого DevOps «конвейера самообслуживания разработчиками»/«internal development platform» появилось совсем недавно, и хотя эти инженеры вроде бы такие же software engineers, только софт у них другой, за ними не признаётся полноценное «инженерство» и «разработка», когда идёт коммуникация внутри компании. Но это такие же разработчики софта для pipeline разработки, как и разработчики целевого софта для поддержки практик целевой компании, для которой разрабатывается этот корпоративный софт. Всё везде «одно и то же», «инженерия», поэтому в языке постоянно появляются различения «нашей инженерии» и «не нашей инженерии».

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

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

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

Операционный менеджер/управляющий работами, выполняющий практику операционного менеджмента/управления работами всех сотрудников предприятия (включая инженеров целевой системы, продвиженцев, администраторов и отчасти бизнесменов и самих организаторов). В системной инженерии это оператор системы: тот, кто нажимает на кнопки, загружает сырьё, отслеживает поломки и проводит эксплуатацию. Операционный/operations менеджер работает в operations/run-time.
Менеджер по оргразвитию, выполняющий практику организационного развития в design/construction time. Тут тоже возможны разные названия (часто про оргразвитие говорят «оргстроительство», а роль менеджера по оргразвитию называют «оргстроитель»). Этот менеджер работает во время развития организации. Помним, что мы сократили «создание и развитие» до «развития», подчёркивая непрерывный характер развития предприятия. В свою очередь это тоже большая практика и большая роль, поэтому в ней выделяется две части:
- Оргпроектирование/оргдизайн как предложение концепции использования организации и концепции организации, выполняется оргпроектировщиком/оргдизайнером. В литературе последних лет это часто называют «архитектура организации», но в этой литературе смешивается оргпроектирование и архитектура. SoTA инженерии сегодня — разделение разработки в части проектирования-изготовления, то есть создания концепции использования, концепции организации, информационной модели организации, достаточной для создания необходимых оргвозможностей и архитектурной работы как достижения приемлемых архитектурных характеристик (наименее плохих, как об этом говорят архитекторы). Поэтому архитекторы предприятия оказались отделёнными от организаторов, они принимают архитектурные решения и далее объясняют их оргпроектировщикам и осуществляют менторинг.
- Лидерство/leadership как обеспечение сотрудничества путём создания «атмосферы» (организационной культуры), где работники помогают друг другу удерживать выполнение организационных ролей, прописанных оргпроектировщиками и при этом сотрудничать. Лидер осуществляет надзор за тем, что эта атмосфера доброжелательного понукания к исполнению своих ролей (удержанию на них внимания, собранности) существует, работники вовремя узнают о своих ролях, совершенствуются в их исполнении, соблюдают производственную дисциплину, поддерживают корпоративную культуру. Лидерство — это про людей. Организации согласно оргпроекту не воплощают на каком-то станке, изготавливая детали и собирая. Их воплощают задействованием практики лидерства, обеспечивая сотрудничество/«дружелюбное взаимодействие в ходе работы и организационных изменений» обучаемых/настраиваемых на ту или иную работу универсальных людей и обучаемого/настраиваемого на ту или иную работу универсального оборудования. Как ни странно, у многих людей «менеджмент» означает именно лидерство, «работу с людьми, учитывающую особенности их психологии». Но это «бытовое», слишком узкое понимание. Даже узкое понимание «менеджер — это организатор, который оргпроектировщик и лидер» уже шире. При этом «лидером» могут называть как роль «создателя атмосферы сотрудничества», так и роль реализующего эту атмосферу эпизодическими какими-то действиями сотрудника (скажем кто-то напомнил исполняющему роль юриста, что он должен всем рассказывать, как надо оформить какой-то схемой что-то нужное команде, а не рассказывать, что этого делать нельзя: его задача помогать работать и придумывать схемы для этого, а не мешать работать и просто цитировать законодательство. Вот это эпизодическое лидерство. А «создатель атмосферы» сделает атмосферу/«корпоративную культуру», в которой юристу это обязательно напомнят, «мешать по линии юристов у нас не принято, принято помогать: придумывать схемы»). А откуда вообще возьмётся роль юриста? Её заложит в проект оргпроектировщик, администраторы предоставят человека-мастера для этой роли, а лидер объяснит, что от этого мастера ожидается: составление схем по обходу каких-то ограничений законодательства в порядке помощи организации, а не просто надзор за соблюдением ограничений как «итальянская забастовка» (работа по придуманным государством правилам).
- Принципиально, что организатор включает в себя подроли операционного менеджера/управляющего работами и менеджера по развитию, а не только менеджера по развитию. Это подробно разбирается в случае традиционных инженерных систем как один из важнейших принципов DevOps/SRE/internal development platform engineering, который формулируется как ответственность за эксплуатацию теми же людьми, которые создавали систему: you built it, you run it! (ты это построил, ты это и эксплуатируй!). В курсе «Системная инженерия» дано достаточно литературы по DevOps, где обсуждается этот принцип. Как раз DevOps (в менеджменте администраторы) были отделены для того, чтобы разработчики (в менеджменте организаторы) могли и проектировать, и воплощать организацию и далее быть её эксплуатационными операторами. Главное тут в том, что убирается вечная война между создателями системы и её операторами: одна и та же роль (можно обсуждать, как она дальше делится между оргзвеньями) и проектирует, и создаёт, и проводит эксплуатацию системы, а DevOps обеспечивают для этого «внутреннюю инфраструктуру разработки, internal development platform».

Роли, должности, организационные статусы

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

Работа может выполняться не человеком-начальником, а его подчинённым («я это выполню» может означать «мой сотрудник Петя это сделает»), поэтому разговаривать о деталях дела надо не с начальником, а с подчинённым. С начальником надо договариваться о координационных актах (поручения, обещания, информирование о моменте выполнения обещания, подтверждение приёмки работы как выполнения вашего обещания её сделать, и т.д.). Мы называем «начальником» человека с ролевым аспектом распоряжения трудом и ресурсами.
Должности часто называются по ведущей роли, но это не обязательно. Есть штатное расписание, и там будет какой-нибудь «специалист второй категории» как должность (организационное место), на этой должности может находиться человек с самым разным мастерством, выполняющий самые разные роли. И даже начальник, который распоряжается его трудом, у него может оказаться не тот, который записан в штатном расписании. Это «схема»: штатное расписание нужно только для того, чтобы «официально» выписывать человеку зарплату, а реальное положение дел закреплено устными договорённостями.
Ведущая роль обозвана неправильно. Когда вам представляют какого-нибудь «аналитика», то это может быть или и впрямь аналитик (который ничего не решает сам, а только «понимает», о чём пишет аналитические отчёты), но может быть и вполне инженер (который решает всё сам, ибо это входит в признаваемые остальными членами команды полномочия). А как же он может принимать решения на такой должности? Очень просто: он «серый кардинал», его полномочия нигде не прописаны, но он имеет большое влияние. В его вроде как «пониманиях» будут «рекомендации», представляющие собой инженерные решения. Вокруг таких «аналитиков» постоянные конфузы, это «скользкая должность»: кто-то обращает внимание на должность и общается не как с полномочным инженером, а как с аналитиком, который не полномочен ничего решать (а он полномочен, но неформально), а кто-то обращается как с полномочным, но неожиданно в критический момент такой «аналитик» говорит, что он всего-навсего аналитик, и пусть кто-то другой из начальства принимает решение, а он тут просто «дал рекомендации». Инженеры принимают решения, а не дают рекомендации по этим решениям. И несут ответственность за решения. Ответственность аналитиков обычно даже не обсуждается. Поэтому мы рекомендуем (если вы начальник и можете это сделать) назвать всех аналитиков по должности инженерами. Это сильно оздоровляет отношения в коллективе. Не все аналитики хотят брать на себя ответственность, но им при переименовании придётся это сделать. Не все сотрудники хотят тратить время на беседы с аналитиками, ибо это пустая трата времени с непонятным результатом. Но беседы с инженерами — это совсем другое дело, результат тут понятен, «принятие решения» (а не «я передам начальству, они примут решение — поиграю в испорченный телефон на одно звено»).
Традиции могут врать. Например, ГИП (главный инженер проекта) в некоторых отраслях означает главного разработчика (принимает технические решения), а в некоторых отраслях — главного менеджера проекта (организует команду проекта и становится операционным менеджером, а технические решения в проекте выполняют какие-нибудь «начальники отделов», которые как раз не принимают операционных решений по ресурсам, но зато принимают технические решения, часто даже сами, а не перепоручая принятие таких решений своим сотрудникам в отделе). Вы общаетесь с ГИПом тем самым то по важнейшим инженерным вопросам (какие-нибудь архитектурные решения по поводу целевой системы), и не встречаете почему-то интереса, то наоборот, по менеджерским (выдача зарплаты вовремя, выплаты по контракту вовремя) — и тоже не встречаете интереса. Просто «главный инженер проекта» — это должность, и традиционное распределение ролей и связанных с ними ролевых предметов интереса в разных отраслях (а иногда и в разных организациях одной и той же отрасли) разное. Уточняйте всегда не должности, а роли, чтобы понять, чем занимается (практика) тот или иной сотрудник незнакомой вам организации, какие у него предметы интереса и предпочтения в значениях важных для него характеристик важных для него систем!
Если вы ищете какую-то менеджерскую практику (которая обязана быть согласно мета-модели из нашего курса), то она может оказаться в самом неожиданном месте. Так, составление плана-графика работ по модели «водопада» (ибо про более современные варианты не слышали, не думали) регулярно попадает к главному разработчику, или архитектору. И вместо дополнительного рассмотрения ещё одного варианта концепции системы или архитектурного решения время этих сотрудников расходуется на планирование (которое потом никем не используется в качестве плана, зато какие-то агенты в основной роли менеджеров ставят на контроль дедлайны, прописанные этими агентами, у которых основная роль инженеров, и используют их не как предварительные инженерные оценки длительности работ, а как обещания — и дальше «никто тебя за язык не тянул», типичный бандитский разворот с превращением оценки в обещание. Дальше инженеры делают «схему»: формальные рапорты о выполнении работ вовремя живут собственной жизнью, а содержательно выполнение работ оказывается никак не связанным с планом-графиком. Контрольные вопросы тут про мастерство: какие методы работы используют все помянутые участники в своих ролях, из каких учебников инженерии и менеджмента? Но если вы ищете операционного менеджера в проекте, то часто им будет даже не менеджер по должности, а кто-то из инженеров: он и пишет планы, и выполняет их, а менеджер-по-должности будет только «аналитик», который не принимает никаких решений, но внимательно слушает инженеров, оформляет услышанное красиво и идёт докладывать «наверх» об услышанном. Просто ступенька в «испорченном телефоне». Так что интересуемся, что люди делают, а не как они называются. Интересуемся вплоть до указания практики, ибо «чистить зубы» может оказаться и съесть утром яблоко вместо использования зубной пасты и щётки («в книжке какой-то читал, что этого достаточно, если утром. Но на ночь лучше щёткой» — это и есть, где взял практику), и сходить к зубному врачу на чистку зубов специальным аппаратом. Внимательней будьте не только к ролям, но и к вариантам практики, которые эти роли используют. Они могут быть неожиданными!
Главный инженер предприятия, CTO и CIO могут оказаться кем угодно в части основной выполняемой роли агентов на этих должностях. Обычное соглашение в том, что они занимаются «внутренней производственной платформой/инфраструктурой» (разработкой, архитектурой, поддержанием эксплуатации), то есть заведуют практикой DevOps/platform engineering как инженеры платформы создания целевой системы. Метафорически (а в производстве «железа» и буквально) они ответственны за «станочный парк» (компьютеры — это тоже «станочный парк», только современный) для инженеров, а также заказ сервисов, которые выполняются «нашими людьми на чужих станках». Но это «обычное» соглашение выполняется отнюдь не везде. Во многих местах на этих должностях люди много времени тратят на работу в ролях организаторов разработчиков (включая и организацию разработчиков внутренней разработческой/производственной платформы, но и организацию разработчиков целевой системы), организаторов архитектурной работы архитекторов предприятия, то есть это инженеры предприятия. Но не менее часто люди на этих должностях занимаются «курированием» (что превращается в перехват деятельности) разработчиков и архитекторов целевой системы, принимая важнейшие решения по концепции использования, концепции системы, архитектурные решения. Всё, что у людей вызывает ассоциации с «техникой» или людьми, прикасающимися к «технике» — всё вдруг начинает отдаваться CTO, CIO, главному инженеру без различения тех систем и служб, по поводу которых принимаются «технические решения». В результате перегруза часть вопросов неизбежно попадает к каким-то другим людям, сидящим на совсем других должностях, и нужно всегда интересоваться, каково же реально распределение ролей у топ-менеджеров. Ибо CIO может быть и «ответственным» (то есть если что не так, вопросы будут к нему, при этом полномочий на решение вопросов у него может и не быть — слово «ответственный» в менеджменте всегда этим подозрительно) за DevOps и в инженерии целевой системы, и в менеджменте/инженерии предприятия (администраторы), и вдруг заниматься архитектурой организации (а заодно и архитектурой софта и аппаратуры для софта, ибо от CIO именно этого ожидают в качестве подразумеваемой целевой системы его проектов, а что развивать нужно не только софт, но и использующую его организацию, так это уже «так получилось, когда давно создавали должность CIO, этого не учли, кто ж знал, само выросло»). Может быть и наоборот: CFO становится «главным администратором» и тем самым начальником CIO, который делает IT-часть административного конвейера (после этого не ждите, что компьютеры для инженеров целевой системы будут стоить больше, чем компьютеры для подсчёта денег, которые зарабатывают инженеры на дешёвых компьютерах. CTO редко выигрывает у CFO в схватке за IT-ресурсы, если только сама фирма не производит какие-то IT-сервисы — а что IT тут поддерживает абсолютно разные конвейеры, так это в голову не приходит. Но это разные конвейеры: административный для организации и DevOps для целевой системы! Поэтому и информационные системы разные! И должно быть два CIO, по большому счёту!). Уточняйте всегда, кто какие решения на какой должности обычно принимает и какими практиками пользуется, какая у него система в цепочке создания, в какой он сам системе в цепочке создания, думайте в терминах ролей, а не должностей.
Должность «системный инженер» осталась с тех пор, когда выделялись отдельно «системноинженерные специальности» в прошлом поколении системной инженерии: роли, занимающиеся инженерией требований (концепция использования и переформулирование её в требования), системной архитектурой (в старом понимании: концепция системы плюс принятие архитектурных решений), проведением испытаний, управлением конфигурацией и инженерной документацией, и прочим «для всей системы». Сегодня разделение труда в инженерии изменилось, вся инженерия (а не только системная инженерия как особая практика) уже опирается на понятие системы (подробности были в курсе «Системная инженерия»). Так что можно только гадать, чем именно занимается «системный инженер» по должности (какую практику инженерии выполняет), какие решения он принимает, тем самым какая у него роль и какие ролевые интересы. Если встретите «системного инженера», всегда интересуйтесь его практиками. В том числе у «системного инженера», «главного системного инженера», «старшего системного инженера» могут оказаться какие-то частные инженерные практики очень древних времён, без опоры на понятие системы, а слово «системный» поставлено какими-нибудь аналитиками в штатное расписание для красоты и значимости, и утверждено какими-нибудь менеджерами с образованием юриста или финансиста без понимания того, что это означает. И совсем не удивляйтесь, если на этой должности обнаружите человека, который 100% времени выполняет практики менеджмента. Общаться же с людьми надо по ролевому принципу, а не по принципу должности с надеждой на то, что роли и должности как-то совпадают.
Должность «менеджер проекта» может скрывать самые разные роли, ибо в центре этой должности вроде бы операционный менеджер, работающий по нормам практики проектного управления (версия этой нормы немного отличается для вариантов разных ассоциаций проектного управления), но в реальности всё может быть по-другому. Во-первых, «проект» сегодня совсем необязательно выполняется именно по практикам классического проектного управления (об этом будет в нашем курсе позже). Во-вторых, в маленьких коллективах разработчиков «менеджер проекта» на своей должности будет не только операционным менеджером, но и организатором, а дальше — сюрприз! — можно легко обнаружить, что он исполняет роли стратега/визионера, а ещё и архитектора, и даже принимает принципиальные для разработчика решения по концепции системы, а потом делит работу согласно этим принятым решениям по разработчикам. Но это же инженерные роли, а не менеджерские! Да, на должности «менеджер проекта» часто работает инженер. Это так же часто, как «ведущий инженер» может выполнять главным образом менеджерские роли, а инженерией целевой системы заниматься только маленькую часть времени. Всегда уточняйте, чем занимается на своей должности человек: какая практика, какая роль, какие ролевые интересы и какая у него система в цепочке создания и в какой он сам системе в цепочке создания.
Продакт-менеджер/product manager и собственник продукта/product owner. На этих должностях существенная часть деятельности, существенное время выполнения практики — это стратегирование/визионерство по отношению к продукту как целевой системе, или целевой услуге. Но вот дальше там будет «букет» из как менеджерских ролей, так и ролей инженерии целевой системы. При этом ни в одной организации вы не встретите одинакового набора ролей и одинакового распределения времени на выполнение практик этих ролей, а если в организации будут одновременно и product manager и product owner, то вы услышите в каждой из этих организаций пространные объяснения, как между этими должностями разлеглись разные роли, но вот только эти объяснения в разных организациях будут разными (при полной уверенности, что «везде одинаково, и у нас так же»).
Наставник как организационный статус — это непонятно что. Должность — это не единственное понятие, с которым путаница, бывают и её эквиваленты — организационные статусы как оргместа для размещения туда людей, просто «должность» обычно входит в штатное расписание, а «организационный статус» не входит. Оргзвено становится таким, когда агента размещают на оргместе (должности или организационном статусе). В оргзвеньях не-подразделениях это может быть секретарь комиссии, председатель научно-технического совета и т.д. Под «наставником» обычно понимается какой-то опытный сотрудник, передающий свой опыт менее опытному. Но за этими словами непонятно какая именно практика (что делают эти люди, а не какой им почёт, уважение, признание заслуг и опыта), поэтому непонятно, какая там роль — непонятно, что на этой роли делать, как к этому относиться другим ролям. Как сказал один начальник отдела, которого пытались сделать «наставником»: «если я этому инженеру наставник, то я должен быть уверен, что он выполняет мои советы. То есть должен стать его начальником, и он никуда не денется, буду передавать ему опыт. А если я его начальник, то зачем мне этот титул наставника? Я ж и так по должности озабочен растить-развивать своих сотрудников! А если я не начальник, то что я буду ему советы давать, когда у него для этого свой начальник есть? И зачем я буду тратить время на то, чтобы уговаривать его эти советы выполнять, если я могу не тратить этого времени, когда я начальник? Пустое это: начальник и наставник это одно и то же». Тут будет сразу множество возражений и разъяснений, но над этой организацией нужно очень хорошо подумать: что там с практиками, ролями и распределениями их по статусам. Потом попробовать табуировать слово «наставник» (и похожие слова типа agile coach⁴⁰ и дальше оргстатусы приглашённых консультантов по отдельным практикам) и подумать о том, что происходит в жизни там, где вроде как должна существовать практика наставничества. Потом попробовать вспомнить, где практика наставничества реально существует и даёт результаты, и как она там организована (автор в своей менеджерской практике нигде такого не видел: наставничество «пожилыми молодых» как таковое жило только на бумаге, а реальное всегда было организовано в рамках какой-то организации труда с обычным распределением обычных полномочий обычных сотрудников, а не «как в наставничестве» каким-то особым порядком. С «консультантами» и «учителями/тренерами» обычно понятно, а вот с «наставниками» — нет. Вот и переходите от названий ролей к подробному описанию практик и не забывайте оценить реалистичность выполнения этих практик).
На должность может быть назначено целое предприятие, даже на должность директора. Например, как поменять CEO мимо решения акционеров? Назначаем ООО «Директор» единоличным исполнительным органом АО «Марионетка» решением собрания акционеров. Затем директор ООО «Директор» назначает Васю исполняющим роль директора АО «Марионетка» от имени ООО «Директор». И если затем нужно по-быстрому сменить Васю на Дашу, то это пять минут на оформление приказа по ООО «Директор», а не внеочередной созыв собрания акционеров. Такая схема (помним, что у нас это термин: когда официальное/юридически признаваемое оформление организационных статусов по-одному, а реализация в жизни — совсем по-другому) используется повсеместно. Например, при реорганизации РАО «ЕЭС России» было именно так: директора региональных энергокомпаний могли быть переназначены за минуты, никаких месячных ожиданий на созыв собраний акционеров, договорённости с местными властями и прочие реверансы. Второй пример: стаффинговые компании⁴¹, которые одалживают людей для работы в других фирмах, но формально эти люди работают у них в штате (случай директоров РАО «ЕЭС России» на это очень похож, «одалживают директора», хотя не по просьбе одалживающей фирмы, но принудительно). Консалтинговые фирмы занимаются примерно тем же: могут одолжить тебе целый отдел консультантов (скажем, аудиторов), но формально люди работают у них в штате. Должности как организационные статусы этих людей обычно отсутствуют, но могут существовать невнятные организационные статусы в самой организации, по этим статусам вообще невозможно понять ролей. Скажем, консультантов по новым технологиям так и представляют: «это наш консультант» (организационный статус) и часто даже не добавляют, по чему именно (какой практике) консультант: потому как приходится консультировать и по какой-то прикладной инженерии чего-то в целевой системе, и по организовыванию на эту инженерию какой-то службы, и по многому ещё, что понадобится. За словом «консультант» точно так же может скрываться огромное число ролей, и надо разбираться специально, о чём в каждый момент времени идёт с ним разговор).

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

Должности (и подразделения как аналоги должностей уровня выше личности) и другие оргстатусы — это чаще всего просто элемент «схемы для найма на работу и выплаты зарплаты», возможность как-то платить зарплату (в случае подразделения то же самое, плюс может речь идти о делёжке бюджета, квотам на разные бонусы) разных размеров разным нужным для выполнения каких-то практик (играющих какие-то нужные роли) людям, возможность понятным образом назначить «формального начальника». Это нельзя путать с ролями. Когда говорят «исполнение должности», то это «исполнение большого количества ролей, на которые назначена эта должность».

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

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

Автору курса пришлось как-то уволить системного администратора, который был ласков, общителен и работоспособен, но не владел практикой системного администрирования: коллектив его очень любил, но по своей роли он работать не мог, ни одна задача системного администрирования не решалась вовремя (и вообще не решалась, приходилось эти задачи решать другим людям). Коллективу было жалко расставаться с приятным сотрудником, но после увольнения все облегчённо вздохнули: сильно уменьшилось количество проблем по линии системного администрирования. Это тоже рассказ про агентов с их ролями и выполнением практик, должностями/оргместами/организационными статусами, психологическими особенностями и квалификацией в выполнении практики выполняемой роли. Обсуждать такие случаи нужно ровно так: это и есть набор важных объектов при работе с оргзвеньями (включая internal team частей личности уровня ниже уровня личности, а также крупные подразделения больших компаний уровня много выше уровня личности).

Роли и выполнение практик — главное, приучайтесь обращать внимание на них в первую очередь, на реальные (не по штатному расписанию и должностям, а по линии «кто на кого влияет, кто с кем дружит») полномочия во вторую очередь, на психологические особенности — в третью.

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

Менеджмент, предпринимательство и начальничество

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

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

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

это шумпетеровский предприниматель из австрийской школы экономики (с уточнениями Кирцнера и многих других исследователей этой школы). Роль, которая имеет межвременные предпочтения: считает, что использование каких-то ресурсов сейчас по сравнению с будущим даст больше NPV (net present value). Смотрит в будущее, угадывает спрос и говорит, что «это выгодно» или «это невыгодно». Капиталист (владелец предприятия, инвестор), изобретатель/инженер с идеей аффорданса для надсистемы — это другие роли. Шумпетеровского предпринимателя мы будем называть «стратег/визионер» в его роли по отношению к выгодности продаж целевой системы и «бизнесмен» в его роли по отношению к выгодности инвестиций в организацию. Конечно, есть и другие варианты трактовки предпринимателя в экономике, появившиеся позже предложений Шумпетера, но для нас сейчас эти нюансы неважны, берём самое распространённое на сейчас понимание.
человек, который затевает какое-то дело и поэтому имеет определённый склад характера, то есть «предприимчивость» и склонность к принятию рисков (в отличие от людей, которые затевают свои дела без такого склада характера, а просто затевают и затевают — не выпячивая свою "предприимчивость", а просто всё время что-то предпринимая). Основное качество этого человека-агента: толерантен к рискам, в том числе невосприимчив к критике (выслушивает всех и делает наоборот, меднолобый фанатик, только не религиозный, а какой-то другой идеи, что мало меняет суть дела), «прёт напролом». Если тихо что-то делает, быстро соглашается, то вроде «не предприимчив». Когда мы говорим о «предпринимательстве» с сотрудниками стартап-акселераторов и инвестиционных фондов, то сразу речь заходит о людях с подобными психологическими характеристиками⁴² — они просто описывают психологические характеристики людей, с которыми общаются. То есть в данном случае «предприниматель» — это психотип.
основатель/founder какого-то предприятия как юрлица. Поскольку речь идёт именно об открытии нового предприятия, то его называют стартапом. То есть если не стартап, и ты в нём не в числе учредителей, то вроде не предприниматель. То, что там собственность делится с инвесторами, которые пришли со стороны, это уже неважно, важен сам момент участия в основании дела как юрлица. Если в стартап пришёл CEO, который делает ровно то же, что месяц назад делал основатель/founder, и которому инвесторы дали такую же долю, какую имел founder, то его не будут называть предпринимателем, но назовут менеджером (ещё и «наёмным менеджером»). А менеджера (или даже инженера), который в свободное от работы по найму время уболтал инвестора дать начальные деньги и зарегистрировал стартап как отдельный проект — вот его назовут предпринимателем. И тут надо вспомнить, что Eric Ries в Lean Startup писал, что любое дело — это стартап, ибо предусматривает примерно одинаковое поведение при ведении каких угодно проектов по созданию систем и предоставлению сервисов. То есть необязательно это «предприятие», запуск любого проекта внутри большой фирмы, запуск проекта в порядке хобби. Получается, что и само понятие основателя/founder тоже размыто, предприниматель-как-основатель — это основатель любого проекта, даже меньше, чем организационный статус, просто замечание про момент формализации проекта. Плюс множество споров, кто же основатель: в основании фирм обычно участвует множество людей с различным ролевым вкладом. Некоторые больше озабочены, чтобы оформить результат основания фирмы юридически, и не забывают при этом оформить кусочек себе побольше, а некоторые больше озабочены, чтобы создать успешный MVP и мало заботятся о юридическом оформлении своей доли, и их вклад содержательно оказывается определяющий, а юридически оказывается не закреплён. Это ведёт к конфликтам⁴³.
просто деятель, который всё время что-то предпринимает, предприниматель как синоним «предприимчивый человек». Необязательно предприимчивый человек (предприниматель) вообще как-то озабочен коммерческой стороной вопроса, «бизнесом». Например, могут сказать, что предприимчивый человек приспособил камень вместо молотка как «забивало». Вот прямо «предпринимателем» такого человека не назовут, но язык не проведёшь: это и называют предприимчивостью, умение приспособить какой-то аффорданс (какой-то физический объект, найденный в окружающей среде) для выполнения какой-то нужной функции. То есть любой инженер — это предприниматель, предприимчивый человек. Если эти аффордансы описаны в литературе, то предприимчивости тут мало, если не описаны, но не очень оригинальны — это рационализатор, а если оригинальны — изобретатель. Предпринимателем часто называют изобретателя, который хочет на своей или даже чужой идее аффорданса заработать деньги, открыв дело/бизнес: сочетание изобретателя, шумпетеровского предпринимателя и основателя в одном лице. То есть это и агент, и психотип агента, и букет ролей (выполняемых по разным практикам), и организационный статус, и психотип, и всё что угодно, обсуждать такое профессионально невозможно, предмет обсуждения всё время плывёт.
инвестор, имеющий собственные деньги (или управляющий деньгами других людей) и вложивший их куда-нибудь, чтобы иметь ещё больше денег. Капиталист, владелец предприятий (то есть не шумпетеровский предприниматель: сам ничего не делает, его интересует только "пассивный доход" от деятельности других людей).
... ещё множество самых разных значений слова «предприниматель»: богатый человек, представитель «бизнеса» в отличие от «чиновничества» (даже неважно, собственник он предприятия или нет), и т.д. У каждого человека в голове при слове «предприниматель» возникает что-то своё. У кого это роль, у кого агент, у кого должность/организационный статус, у кого социальный статус (принадлежность к сословию, это неважно, что сословий уже вроде нет), у кого психотип — в сложных их сочетаниях.

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

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

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

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

«Начальника» не надо путать с «менеджером», хотя в быту эти слова разве что не взаимозаменяемы. Так sales manager это ни разу не менеджер по своей роли, а просто salesman, которому для представления публике, что с ними теперь говорит «начальник», а не просто «низовой продавец», дали титул «начальник продаж», «управляющий продажами», «менеджер по продажам». Менеджер — это не начальник, это профессиональная роль, выполняющая практику менеджмента, а не просто раздающая поручения и обладающая полномочиями распоряжаться чужим трудом и капиталом. Полномочия тут вторичны, а вот использование дисциплины менеджмента и технологии менеджмента (практики менеджмента, причём чаще всего не всего менеджмента, а какой-то только части — подпрактик и подроли, например, практик операционного менеджмента в роли операционного менеджера) первично.

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

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

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

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

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

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

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

Давайте ещё раз выпишем деление практик менеджмента и их ролей, начиная с широкого понимания менеджмента (инженерия предприятия) через узкое (организовывание) и кончая сверхузким (лидерство), уже без комментариев и даже без синонимов:

инженерия целевой системы — инженер целевой системы
- визионерство целевой системы (прогноз целесообразности создания целевой системы) — визионер
- архитектурная деятельность для целевой системы — архитектор
- разработка — разработчик
  - проектирование — проектировщик
  - изготовление/производство — инженер-технолог
  - эксплуатация — оператор целевой системы
- инженерия платформы разработки (DevOps) — инженер платформы разработки
менеджмент (инженерия организации) — менеджер в широком понимании (инженер организации)
- стратегирования (для удержания стоимости бизнеса) — бизнесмен
- орг-архитектурная деятельность — орг-архитектор
- организовывание — организатор, менеджер в узком понимании
  - организационное развитие — менеджер по оргразвитию
    - оргпроектирование — оргпроектировщик
    - лидерство — лидер, менеджер в слишком узком понимании
  - операционный менеджмент — операционный менеджер
администрирование — администратор
продвижение продукта или услуги (инженерия клиентуры: маркетинг, реклама, продажи) — продвиженец (там тоже разбиение на подпрактики и подроли!)
привлечение инвестиций (инженерия инвестуры, fundraising) — фандрайзер

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

Задания

Поставьте отметку о выполнении:

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

Тренды современного менеджмента и выбор SoTA

Главный тренд современного менеджмента — это его компьютеризация, причём этот тренд принимает самые разные имена:

компьютеризация (скажем, «бухгалтерия», «механизированная бухгалтерия» с машинами-табуляторами или счётными машинками вместо счёт с костяшками, затем «компьютеризированая бухгалтерия», затем просто «бухгалтерия», ибо некомпьютеризированной уже не бывает).
Автоматизация (ибо вроде как компьютеры заменяют людей)
Автоматизация с разными эпитетами — экстремальная, тотальная, гипер).
Цифровая трансформация (ибо в основе лежит цифровое, то есть численное/дискретное моделирование, опора на данные — хотя тут тоже есть разночтения о том, что такое «цифра» и что такое «трансформация»)
Роботизация (это указание на то, что при автоматизации речь идёт о более-менее автономно работающих самостоятельно включающихся в работу алгоритмах, а не каких-то небольших автоматически выполняемых работах, запускаемых сотрудником-человеком. Роботизация необязательно про выход в физический мир автономных роботов! Если софт нажимает на кнопки, нарисованные на экране, и заполняет формочки, то это тоже «роботизация», например, robotic process automation, RPA⁴⁵)
Интеллектуализация (и тут даже необязательно использование алгоритмов искусственного интеллекта, просто это попытка сказать, что речь идёт не о самых простых алгоритмах, а о машинном обучении, которое может оказаться банальной и простейшей линейной регрессией из первой главы курса статистики).
… много других имён, маркетинг поставщиков компьютерных технологий для практик менеджмента не дремлет.

Дальше идёт игра словами: пытаются различать «автоматизированные» (что-то делают компьютеры, что-то человек) и автоматические (всё делает компьютер) системы, но это разделение не прижилось. Понятно, что без людей не обходится вообще нигде. Другой вариант игры словами идёт по типу того, что происходит сейчас в сфере AI и роботов — всё, что большинству людей непонятно как автоматизировать, называют AI и «робот», а что уже понятно — «обычные алгоритмы». С менеджментом происходит то же самое: автоматизация практик/процессов, которые понятно стало как автоматизировать — это уже не считают менеджментом, а что осталось непонятным как автоматизировать — это и считают «настоящим менеджментом».

Операционный менеджмент уже весь почти ушёл в алгоритмику и там всё меньше остаётся решений, которые должны принимать люди. Администрирование загрузки конвейера/pipeline (помним, что это термин из DevOps/SRE/internal development platform практик, а не только настоящий заводской конвейер) при его работе оказывается хорошо автоматизируемым навыком, люди нужны только при изменении структуры самого конвейера (ремонтах, замене оборудования, изменении самих операций, которые должны выполняться на конвейере). В операционном менеджменте всё сводится к вычислениям и остаётся только лидерство: объяснение необходимости следовать при загрузке людей и оборудования работами не интуиции, а результатам расчётов (а эти расчёты делает компьютер на базе формул из учебников, причём даже не учебников менеджмента). Смогли уболтать людей верить контринтуитивным результатам бездушных расчётов — получите на сегодня даже не конкурентное преимущество (конкурентным преимуществом это было вчера, а сегодня это как гигиена, «все так давно делают»), а отсутствие ошибок в загрузке оборудования, небольшой запас прочности.

«Архитектура предприятия» тоже во многом уходит к архитекторам, но дальше можно придётся обсуждать — это архитекторы предприятия или архитекторы корпоративного софта, так как в силу той самой цифровой трансформации эти две роли стремительно сливаются в одну. Взаимосвязь архитектуры предприятия и архитектуры софта будет подробней рассмотрено в курсе дальше, хотя в «Системной инженерии» было уже дано достаточно литературы, чтобы это заметить. Современные фирмы склеиваются из своих частей оргзвеньев-модулей не столько людьми, сколько корпоративным софтом. Этот софт даёт «один источник правды»/one source of truth (расхожий термин управления конфигурацией) и одни и те же объекты внимания (организационная собранность) и понятные каналы коммуникации между максимально автономными модулями-оргзвеньями. В курсе «Собранность» ШСМ об этом понятийно наведённом коллективном внимании рассказывается подробно.

Остаётся стратегирование: визионерство (по отношению к целевой системе и потенциальной клиентуре) и бизнес (по отношению к организации и потенциальной инвестуре). Некоторые не относят их к менеджменту, но если речь идёт о системе предприятия, мы будем относить это тоже к менеджменту как части инженерии. И ещё есть собственно «организовывание» (organizational change management, оргизменения, практика развития предприятия). Это да: что менять, на что менять и как менять (а менять нужно постоянно) — это плохо алгоритмизируется.

Но всякий присмотр за людьми-роботами (типа "кто там матом из сейлзов ругался на наших клиентов?") плюс попытки автоматизировать HR (у наших студентов был хороший пример с роботом HR Yva⁴⁶ — робот пишет: «сотрудник хочет уволиться», сотрудник категорически возражает против этой гипотезы, но потом выясняется, что проблема таки замечена правильная: беременность и грядущий декрет, но «уход в декрет — это же не увольнение!». И таких случаев с беременностью и «никакого увольнения, просто уйду в декрет» в женском коллективе роботом отслежено было несколько, что позволило заранее подготовить замены этим сотрудникам). Автоматизация найма-увольнений (оценка анкет, оценка производительности), автоматизация начисления штрафов за отсутствие улыбки на рабочем месте и мат в разговоре (клиентам надо улыбаться! Мат недопустим! Механические глаза и уши смогут отсмотреть все разговоры, и не устанут — а о нарушениях доложат «кому надо»), и т.д.

Ещё одно направление — это автоматизация compliance/соблюдения законодательства и стандартов. Уже не менеджер (как «более умный и опытный, чем ты») согласует на предмет цензуры публикации в блогах, на сайте, письма компаниям-партнёрам, а софт. Цензура стала ультрадешёвой, её делают роботы (литературу тут приводить бессмысленно, настолько её сейчас много: проблемы типа мата в выдачах поисковых систем, цензуры неприличных картинок в соцсетях, отслеживания упоминаний запрещённых законом организаций обсуждаются повсеместно, и разного качества софт для решения этих проблем широко рекламируется и доступен для закупки самыми разными компаниями. И этот софт с каждым годом становится дешевле и отслеживает нарушения точнее. Цензура стала удивительно дешёвой, эффективной и доступной — но это нужно понимать как «уволили full time цензоров, сняли нагрузку цензуры с part time цензоров, оставили роботов»). Part time цензоры — это сотрудники, которые часть времени проводили в роли цензоров (понятно, что это не так называлось, но «согласование» включает эту работу! Надо просто называть вещи своими именами).

Переход с синхронной коммуникации (совещания) на асинхронную с записью реплик в надёжную компьютерную память (чаты, на каждую проблему, каждый проект по отдельному чату. Вплоть до «чат и его участники» как синоним проекта/кейса из кейс-менеджмента) — это тот же тренд «автоматизации», в итоге асинхронная коммуникация съедает синхронную, как бы ни переживали по поводу «живого общения, которое ничто не заменит». Заменит, в большинстве случаев заменит⁴⁷. Не надо больше сидеть час на совещании, чтобы твой вопрос пообсуждали три минуты в конце совещания уставшими мозгами.

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

Мода на «аутсорсинг» проходит в том числе и потому, что воплощение спроектированной системы делает теперь завод-автомат, а автоматизировать чужое производство становится невыгодно, медленно. Поэтому platform engineering происходит не за пределами фирмы в предприятиях-аутсорсерах, а внутри фирмы, так производить оказывается быстрее и дешевле, чем оплачивать разработку, наладку и эксплуатацию роботов на далёком чужом заводе — при этом переналадку надо делать часто, ибо это же continuous everything! Одним из ходов Elon Musk при создании SpaceX был отход от практики NASA заказывать всё максимально большому числу контракторов, ибо «это же государственные деньги, пусть достанутся разным людям по всей стране». Нет, всё производство было максимально собрано внутрь SpaceX — и не только чтобы уменьшить затраты на достижение договорённостей, но и чтобы перестать оплачивать автоматизацию чужих производств.

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

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

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

Современная организация — это киборг (cyborg, читать можно как оригинальное CYBernetic ORGanism, так и CYBernetic ORGanization), рассматривать её как «сообщество людей и оборудования» с игнорированием факта, что «современное оборудование — это прежде всего компьютеры» нельзя. Попробуйте поработать неделю без смартфона и доступа к компьютеру: окажется, что это сегодня практически невозможно, хотя раньше вроде все так делали. Но и производительность труда раньше была в разы и разы меньше. Это всё результат эволюции организации в киборга, усиление её оргвозможностей через компьютеризацию менеджмента, компьютеризацию инженерии организации: компьютеризацию практики создания, развития и эксплуатации организации.

Масштабы автоматизации: люди едят компьютеры примерно в таких же количествах, как и обычную еду (в 2019 году рынок еды — $6 триллионов долларов, рынок информационно-коммуникационных технологий — $5 триллионов долларов), а поскольку этого рынка несколько десятков лет назад просто не существовало, все эти «телеграфы с телефонами» и «вычислительные машинки Феликсы» в части рынка были маргинальны, то можно ожидать, что затраты человечества на компьютеры уже больше затрат на еду. Проблема только в том, что в съедаемой пищи люди разборчивы и экономны, хотя иногда и роскошествуют, следят за сроками годности, а вот в вычислениях — неразборчивы. В сортах софта и аппаратуры понимают плохо, в ценах разных сортов софта ориентируются плохо, в свежести софта не осведомлены. Менеджер должен уделять внимание софту хотя бы столько же в день, сколько уделяется внимания пище. А лучше — больше, ибо это профессиональный интерес, качество менеджмента обеспечивается сегодня и качеством софта. Плотник следит за своими инструментами, менеджер тоже следит за своими инструментами — и эти инструменты у него компьютерные, их нужно поддерживать. Для инженера целевой системы это тоже верно, но почему-то при замене целевой системы на организационную систему про софт забывают, но зря.

Как договариваться о софте менеджерам (тем более что они договариваются о софте между собой: одни менеджеры просят разрешить софт у других менеджеров)? Очень просто: все рассуждения вести, начиная от целевой системы, формулировать выгоду не на языке компьютерщиков, а на языке предметной области (и даже не предметной области менеджмента, а предметной области той организации, которую создаёт и развивает менеджер — дотягивая цепочку рассуждений до целевой системы через цепочку систем создания), а ещё учитывая, что любой софт надо будет «дорабатывать напильником», он мгновенно устареет, оптимального софта не бывает, поэтому решения принимаются «политически» (что легче купить, то и покупайте, а после некоторой эксплуатации приобретёте опыт в том, что надо покупать дальше, заодно и предложение на рынке изменится. Помним о неустроенностях: есть огромное число очень близких по уместности/полезности решений, поэтому не переживайте сильно по поводу выбора, не будьте буридановым ослом, не впадайте в analysis paralysis, ничего не ждите, действуйте быстро). Этого вопроса про софт мы ещё коснёмся в нашем курсе, менеджерам сегодня надо знать про софт много больше, чем надо было знать вчера.

Есть два варианта использования софта:

Полная замена людей в каком-то процессе, при этом софт будет работать чуть хуже. Думать нужно примерно так же, как о «переводчике Гугля», который хуже профессионального переводчика, но крайне дёшев, потому как переводит уже даже не как восьмиклассник, а как студент первого или даже второго курса. Вот такой софт найдёт применение. Это линия NoCode (ничего не надо кодировать, «всё само»).
Софт по линии «компьютерного усиления интеллекта так же, как скрипка-инструмент усиливает возможности музыканта-без-инструмента» Энгельбарта («скрипка Энгельбарта»⁴⁸). Проблема тут в том, что такой софт требует существенного времени на его освоение. Лучшая практика — это которой нет, дисциплина ушла в софт, остался только инструмент, а в головы ничего класть не надо. Репликация мастерства компьютеров в разы и разы дешевле репликации мастерства людьми: не нужно долго учиться и при этом платить зарплату — докупил оборудования и скопировал код, если архитектура масштабирования такое развитие событий учитывала (а сегодня это учитывается архитекторами обязательно), это быстро. Это как раз предыдущий пункт «замены людей на 100%», он и финансируется. А вот линия «усиления интеллекта» как гибриды из людей и компьютеров со спецалгоритмами для усиления интеллекта практически не развивается в менеджменте. Cкажем, операционный менеджмент требует специфических вычислений по алгоритмам ERP (enterprise resource planning), но в большинстве установок ERP-софта в отечественных предприятиях нет собственно модуля планирования, который центральный и главный. То есть менеджмент даже не признаётся инженерией, где что-то нужно вычислять. Вычисления (простая арифметика, но не сложные оптимизационные задачи планирования) поддерживаются LowCode моделерами (начиная с Excel), из спецсофта для целей менеджмента могут допустить какие-то системы администрирования, связанные с необходимостью удовлетворять госрегулирование (налоговая бухгалтерия, кадровый учёт и т.д.). Даже менеджерам нужно уметь рассказывать ощутимое преимущество, которое даёт софт — но преимущества корпоративной собранности рассказывать трудно. Но и у инженеров целевой системы почти невозможно договориться о покупке сложного специального софта для поддержки их разнообразных инженерных практик, особенно если речь идёт о каких-то дорогих специальных системах моделирования, а не о конкретных алгоритмах расчёта каких-то конкретных инженерных параметров. «Скрипка Энгельбарта» как усиление возможностей человеческого интеллекта софтом систематически недофинансируется.

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

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

Эта линия сегодня называется LowCode: универсальный софт, настройка/программирование которого делается «обычными» сотрудниками с высшим образованием, которые понимают сложности своей предметной области и не потеряли вкуса к математике и программированию (проходятся во всех технических вузах!), но не сотрудниками-айтишниками/программистами. Как побочный эффект, тут исключается «испорченный телефон» передачи знания от специалистов из инженерии или менеджмента к программистам (и уж точно мимо «аналитиков»). Из проблем — архитектурно получается всё очень плохо, ибо программисты готовы признать необходимость ограничений модульности со стороны архитектуры, а специалисты предметной области плохо разбираются в архитектуре и не готовы что-то с этим делать. В какой-то мере это похоже на происходящее с социальными сетями: СМИ (контент производится редакцией, Web 1.0) в небольшом количестве остались, но их роль в существенной мере была отобрана социальными сетями (Web 2.0, user generated content). При этом в соцсетях нет ни рубрикации СМИ, ни корректоров грамматических ошибок, ни дополнительного фактчекинга, зато никакого испорченного телефона и задержек между знанием или мнением и его публикацией. Вот и в информационных системах предприятия тренд на замену данных и программ их обработки, создаваемых программистами на всё то же самое, создаваемое сотрудниками: менеджерами и инженерами — с ошибками собственно программирования, с ужасной архитектурой и качеством алгоритмов (никакой оптимизации по скорости расчётов), но без задержек и искажений в формулировании того, что надо сделать и потом собственно программировании. А программисты? Они остались. Думать нужно про это всё по линии DevOps/platform engineering — одни создают «платформу», другие с её помощью делают что-то своё, и так на несколько уровней цепочки «платформы создания платформы создания платформы создания чего-то конечного». Именно по этой причине Excel в компаниях оказывается неистребим, несмотря на всё им производимое «архитектурное зло», а сейчас оказываются неистребимы универсальные табличные моделеры вроде coda.io и notion.so.

Скрытая проблема: усиление интеллекта (подготовка к заранее неизвестным проблемам) в организации не финансируется, ибо это не ощущается как «автоматизация» конкретной практики, но просто «компьютеризация впрок». Поддержка мышления людей и коллективов компьютерным экзокортексом не финансируется. В скрытом виде это происходит через закупку «универсальных моделеров» как LowCode платформ корпоративного экзокортекса (софт типа coda.io, notion.so и т.д. — к этому вопросу мы ещё вернёмся в нашем курсе), это финансируется не как универсальное решение для поддержки организационной собранности, управления вниманием, но как программы операционного управления, подготовки отчётности и т.д. По сути же это — средства универсального корпоративного моделирования («мышления моделированием»), но также моделирования архитектуры предприятия, поддержки операционного управления (управления кейсами) и т.д., мы этого коснёмся позже в нашем курсе.

По конечному же итогу: нет массовой веры в умнеющее с компьютерами человечество, будет экстремальная автоматизация того, что уже есть путём исключения людей, замены их компьютерами на 100% (пусть и с более плохим, но зато более дешёвым результатом замены — и тут тренд RPA, robotic process automation, программирование процедур, которые раньше выполняли люди). Финансирование подготовки организации к тому, что будет (но непонятно, что), то есть рост evolvability, agility и других аналогичных архитектурных характеристик организации маскируется через закупку универсальных моделеров в виде платформ LowCode. «Мышление письмом/моделированием» в организациях идет с помощью таких платформ, а универсальность моделирования обеспечивается гибридными функциями редактора текстов, электронных таблиц и баз данных.

Этот тренд усиления мышления компьютерами (при активном сопротивлении такому усилению, ибо выгодность «поумнения» трудно обосновать экономически, но кто не верит в необходимость компьютеризации — быстро вылетает с рынка) выполняется для инженеров целевой системы, для инженеров организационной системы (менеджеров) и даже для инженеров клиентуры/продвиженцев. Вот софт для продвиженцев, на диаграмме 2020 года изображено 8 тысяч приложений для экзокортекса продвиженцев⁴⁹:

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

Упражнения

Заполните табличку, какими словам разные люди в вашей организации называют цифровую трансформацию (автоматизация, компьютеризация и т.д.). Они имеют в виду одно и то же, или разное? Уточните у них.

Термин	Кто так называет (ФИО, а не должность или роль)	Примечание, что имеется в виду

Задания

Поставьте отметки о выполнении дел:

Написан пост про проекты цифровой трансформации/автоматизации/компьютеризации, в которых вы участвуете.
Написан пост с обзором литературы по примерам использования искусственного интеллекта в ваших рабочих практиках, или хотя бы исследованиях в этой области (гуглите новости! news.google.com).
Написан пост, с самым свежим примером, когда вы разгрузили память сотрудников в вашем проекте при помощи компьютеров и использовали компьютер для обеспечения коллективной собранности: удержания внимания в команде вашего проекта на важных объектах.

3. Практика бизнеса (прибыльности)

Предприятие как продукт: оно тоже продаётся

Бизнес/business имеет множество словарных значений, но основных из них два:

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

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

Организация-как-бизнес/предприятие/компания/фирма сама по себе является продуктом, основная функция которого — приносить деньги сейчас и в будущем («инструмент для добычи денег из окружающей среды»). Если в организацию приходит от клиентов денег больше, чем она проедает на поддержание своего существования, то у организации появляется избыток денег. Его можно потратить на расширение бизнеса как практики зарабатывания денег. То есть «расширение бизнеса» — это «как организоваться так, чтобы зарабатывать денег больше». Но можно и просто отдать заработанные предприятиям деньги владельцам/инвесторам (впрочем, можно отдать и сотрудникам предприятия, а можно и не брать у клиентов, сделав цены дешевле — тут всегда разные предпочтения у разных ролей, вечный источник неустроенности/frustration).

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

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

Эта аналогия коровы и фирмы очень и очень условна (сами придумайте не меньше трёх существенных отличий), тем не менее она обращает внимание на различение трёх отдельных объектов для продажи:

Молоко коровы — продукция или услуга/service фирмы, за которую она получит деньги.
Корова как производитель молока (живая!) — сама фирма как производитель продукта или услуги.
Корова как мясо (когда о молоке уже речь не идёт, например, оно вдруг никому не нужно, а корова требует кушать — в этот момент оказывается, что мясо сколько-то ещё стоит, хотя и меньше, чем мясо и будущее молоко. Но кормить корову «просто чтобы была» никто не будет!). С фирмами такое тоже бывает: персонал просто увольняют, а её имущество распродаётся. Содержать фирму себе в убыток никто не будет, если нет надежды, что она скоро принесёт такую большую прибыль, что хватит на покрытие убытка от содержания фирмы, которая работает, но ничего не продаёт.

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

выгодно или невыгодно создателю заниматься каким-то продуктом (проектом, сервисом — мы считаем, что к данному моменту у вас уже есть достаточный навык работы с понятием целевой системы, чтобы легко разбираться с целевыми системами как продуктами, а системами создания как провайдерами сервисов по созданию и развитию целевой системы, не обращая внимания на терминологию и пробегая при необходимости несколько шагов по цепочке создания). Ответ на этот вопрос даёт роль шумпетеровского предпринимателя. А поскольку слово «предприниматель» мы табуировали (это в нашем курсе тоже уже разбиралось, почему так), то заменяем роль на «визионер». Визионер занимается вопросом о будущей прибыльности какого-то продукта или сервиса с учётом того, сколько нужно будет вложить денег сейчас и в ходе разработки, и насколько дёшево фирма сможет его производить «потом» и насколько дорого какому числу клиентов (все клиенты — клиентура) этот продукт можно продать «потом».
выгодно или невыгодно предыдущему создателю по цепочке создания заниматься созданием следующей системы (целевой или системы создания). Это принятие решения нужно провести для каждого звена цепочки создания — пока мы не приходим к тому, что кто-то принимает решение о покупке фирмы или её части и определяет цену, по которой это делать выгодно. Эту роль назовём «бизнесмен». Бизнесмен занимается вопросом о будущей прибыльности фирмы (независимо от того, какой у этой фирмы продукт/целевая система вот прямо сейчас: ибо фирма может менять продукты) с учётом того, насколько дорого можно будет продать фирму (или её часть, для рассуждения это неважно) «потом» инвесторам (слово «инвестура» практически не используется, обходятся множественным числом от «инвестор», но мы будем его использовать по аналогии с «клиентурой»). Если фирма будет прибыльна, то «потом» она будет стоить дороже. Если так и не будет прибыльна, и надежды на прибыльность уже не будет — продать можно будет только мёртвое имущество фирмы. Если надежда на прибыльность хоть у кого-то будет, то продаётся как живая фирма (даже если стартап ещё не успел выйти на прибыльность, и это радостное событие только ожидается с какой-то вероятностью).

В этом месте нужно обязательно посмотреть в качестве учебного пособия фильм «Деньги чужих людей» (1991)⁵⁰. Собственники (как главные исполнители роли бизнесменов) обычно не могут передать полностью всё стратегирование менеджменту: менеджмент обычно не заинтересован кардинально меняться (менеджеры уволятся в другую компанию, декапитализация фирмы для них не фатальна). Поэтому высших менеджеров заинтересовывают в собственности «потом» (опционы), чтобы они поддерживали темп изменений в надежде получить часть возросшей стоимости компании в свой карман, а не просто «выполнили одно задание собственника и успокоились».

Роли визионера и бизнесмена существенно перепутаны. Но в целом:

Визионер оценивает продукт, на который может быть спрос. Он оценивает будущий денежный поток от продукта по сравнению с вложениями в производство продукта. Он изучает клиентов и надсистемы продукта, предложения инженеров по производству продукта/оказанию сервиса. И если понимает, что денег от этого продукта (или фичи) не будет — прикрывает проект.
Бизнесмен оценивает фирму, на которую может быть спрос у инвесторов. Он изучает «инвестиционный климат», надсистемы инвесторов и фирму, оценивая ещё шансы вырасти. Если фирма (менеджер/служба оргразвития) пытается затеять какой-то шаг оргразвития, который ему кажется неудачным, он вмешивается: отношение governance/надзора, как и у архитектора предприятия. Но у архитектора предприятия архитектурные характеристики важны, а у бизнесмена — его оценка того, вырастет ли от этого шага развития стоимость фирмы, или нет.

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

Это всё разговор про роли, а не про реальных людей. В крупной фирме в форме акционерного общества роль бизнесмена выполняют множество служб, визионеров (внутренних предпринимателей) огромное количество. В маленьком стартапе из пяти человек визионер и бизнесмен могут быть в одном лице основателя/founder, а ещё и бизнесмен может продать фирму себе же, и начальные деньги на «бизнес» фирма получит из личных сбережений основателя. Основателей может быть несколько, тогда мы непременно увидим, как их роли будут постепенно расходиться: кто-то будет больше заниматься товаром (визионерство), кто-то озаботится инвесторами (привлечение инвестиций, бизнес), кто-то займётся организацией фирмы (найм и обучение людей), кто-то продажами. При этом легко представить ситуацию, когда кто-то занимается частью всех этих практик в счёт будущей прибыли (и одновременно — в счёт будущих убытков, тут всё симметрично обычно, бизнес как раз про это), но кто-то может получать зарплату — и тогда у него ни прибыли, ни убытков, а заранее понятная сумма. Конечно, есть и промежуточные режимы (скажем, если люди выполняют свою работу хорошо, то они могут получить в собственность часть фирмы по цене, которая была на момент начала их работы. Если фирма поднялась за это время в цене, на этом можно очень неплохо заработать!).

TEST Бизнес

!!! Какие тексты вы бы отнесли к текстам по бизнесу?

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

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

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

--- предприятие должно считать деньги, чтобы не работать в убыток. Для этого нужно использовать современные методы управленческого учёта, например throughput accounting. ### Нет, тут говорится о том, что в проекте нужно использовать практику управленческого учёта, речь не идёт о практике продажи фирмы (указание на то, что «фирма не должна прогореть» тут — обычная отсылка к важности бизнес-стороны работы предприятия). «Проход» сейчас волнует операционного менеджера прежде всего, а бизнесмена волнуют оценки «прохода» в будущем визионерами, чтобы прикинуть, сколько могла бы стоить при этом сама фирма.

!!! Укажите, какие практики относятся к бизнесу:

--- инженерия требований ### Нет, это практика системной инженерии, причём сейчас это уже устаревшая практика, требования уже не разрабатывают (подробней об этом говорится в курсе «Системная инженерия»).

--- финансовый учёт и контроллинг ### Нет, это практика операционного менеджмента.

--- продвижение продукта (маркетинг, реклама, продажи) ### Нет, это практика продвижения.

--- оргдизайн и лидерство ### Нет, это практика организатора.

--- проверка и приёмка ### Нет, это часть практики инженерных обоснований в инженерии прикладной системы.

+++ корпоративные финансы (инвестиции и займы) ### Да, когда бизнесмен идёт к инвестору за деньгами, они договариваются о сумме с использованием этой практики

+++ корпоративная поднадзорность (corporate governance) ### Да, это практика бизнеса, в рамках которой строятся отношения по поводу распоряжения имуществом и деньгами предприятия.

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

!!! Отметьте высказывания, с которыми вы согласны.

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

--- бизнесмен — это тот, кто получает всю прибыль от продажи товара или услуги, а потом делится этой прибылью с командой. ### Нет, бизнесмен получает не только всю прибыль, но и все убытки. А прибылью он делится не только с командой, но и с инвесторами.

--- бизнесмен — это главный из менеджеров фирмы, единоличный управляющий. ### Нет, бизнесмен — это роль, которая может исполняться несколькими людьми. Бизнесмен занимается угадыванием стоимости будущей фирмы, он не принимает решений ни операционного менеджмента, ни оргразвития, ни архитекторов предприятия. Но он согласовывает стратегию как фильтр на те решения, которые будут приемлемы для других ролей, а также имеет полномочия для настаивания на том, чтобы этот фильтр работал (если кто-то намеренно не подчиняется стратегии фирмы, или принимает решения, ведущие к падению стоимости фирмы сейчас и в будущем — он может быть бизнесменом уволен).

--- бизнесмен — это тот человек, который даёт фирме деньги/инвестиции ### Нет, во-первых, бизнесмен не человек, а роль, а во-вторых, роль дающего фирме деньги (покупающего фирму — доля в фирме в обмен на деньги) — это инвестор. Бизнесмен работает с содержательной стороной вопроса инвестиций (стратегия), он приводит фирму к состоянию, в котором она выгодна для инвесторов. Инвестор даёт деньги фирме, опираясь на обоснование, которое ему приводит бизнесмен и ориентируясь на общую ситуация с инвестициями (финансовые кризисы, страновые риски и т.д.).

--- бизнесмен реализует собственные желания (полететь на Марс, накормить бездомных, поддержать любителей собак в городе) ### Нет, по роли бизнесмен занят удовлетворением потребностей инвесторов. Агент, выполняющий роль инвестора, может захотеть просто купить уже как покупатель полёт на Марс, кормёжку бездомных и т.д. Задача бизнесмена — иметь прибыльный бизнес, который может помочь инвестору заработать на покупку объектов своих желаний.

Упражнения

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

Номер п/п	Имя инициативы	Продукт или сервис	Какую проблему потребителя решает продукт или сервис	Сколько ожидали получить с рынка и сколько получили	Сколько ожидали потратить на реализацию и сколько потратили	Где брали деньги на реализацию идеи (кто инвестор)	Сколько ожидалось времени от начала проекта до выхода продукта/сервиса на рынок и когда реально вышли	Результаты (прибыль или убытки)
1.
2.
3.

Приведите от трёх примеров идей бизнеса, в которые вы не верили, но которые вопреки вашим ожиданиям принесли инвестиции и затем успех (например, «я не верил, что SpaceX сделает возвращаемую ракету, реально в разы уменьшит стоимость одного запуска на орбиту, и не ожидал, что бизнес-модель у него будет не столько на деньгах от этих запусков, сколько от торговли интернетом Starlink» или «я не верил, что twitter станет большой социальной сетью и покупка его будет в какой-то момент стоить $44 млрд, ибо это безумие ограничивать размер сообщения в социальной сети 140 символами»).

Номер п/п	Предпринимательская идея, в которую вы не верили, но она оказалась успешной
1.
2.
3.

Оцените свою склонность к денежному риску по десятибалльной системе (1 — абсолютно не хочу рисковать, 10 — удача со мной, готов рисковать в ситуациях, которые всем остальным кажутся абсолютно безумными).

Оценка риска в баллах

Укажите, кто выполнял роли визионера и бизнесмена в ваших проектах (от трёх проектов), и дайте вашу оценку квалификации исполнителей этих ролей в выполнении практик визионерства (оценка прибыльности продукта) и бизнеса (оценка прибыльности фирмы) по 10-балльной системе (1 — никакой квалификации, 10 — опытный и успешный человек, всё о визионерстве и бизнесе знающий и умеющий действовать в этих ролях). Если исполнение ролей было групповым, отразите это (впишите в соответствующие клеточки таблицы несколько значений, а не одно).

Номер п/п	Проект	Исполнитель роли визионера	На какой должности роль визионера	Квалификация исполнителя в роли визионера	Исполнитель роли бизнесмена	На какой должности роль бизнесмена	Квалификация исполнителя в роли бизнесмена
1.
2.
3.

Задания

Поставьте отметки от выполнения следующих дел.

Посмотрен фильм «Деньги чужих людей» https://www.imdb.com/title/tt0102609/ (есть и в русском дубляже). Опубликуйте рецензию на этот фильм, используйте в рецензии материал нашего курса.
Написан пост в блог о том, как вы в последний раз получали инвестиции для какого-то вашего проекта (в том числе можете описать и ситуацию, в которой вы как бизнесмен получали инвестиции от себя же как инвестора — как договаривались с собой, как решали неизбежный конфликт интересов). Особо обратите внимание на разницу между инвестицией («я купил акции булочной и жду или повышения их стоимости, или дивидендов») и просто покупкой для потребления («я купил булочку в булочной и съел её»).

Практика корпоративных финансов (инвестиции и займы)

Корпоративные финансы/corporate finance⁵¹ — это практика привлечения денег в фирму, в том числе попытки «справедливой» оценки как стоимости денег, так и стоимости фирмы. Для этого рассматривается взаимоувязка различных направлений доходов фирмы и различных направлений расходов фирмы, а также сама фирма в части её уже имеющихся активов. Поэтому формально в корпоративные финансы входят как привлечение капитала, так и его расходование. Но мы будем отделять «управленческий учёт» как учёт для принятия решений операционным менеджментом (практики типа throughput accounting, beyond budgeting) или «операционные финансы» от «корпоративный финансов», связанных больше с разными моментами инкорпорации (то есть образования экономически независимого и прибыльного юридического лица).

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

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

Это довольно сложная практика, косвенно её сложность можно оценить по толщине книг, описывающих метаУ-модель корпоративных финансов. Так, один из самых популярных в Европе (помним, что в регулировании финансовых рынков разных стран есть особенности) учебников Pierre Vernimmen, Pascal Quiry, Yann Le Fur, «Corporate Finance: Theory and Practice», шестое издание 2022 содержит 1040 страниц текста альбомного формата, только чуть-чуть не дотягивающего до А4.

Этот огромный объём учебников — обычное дело. Скажем, распространённый вузовский учебник Jonathan Berk, Peter Demarzo «Corporate Finance», 2010 имеет страницы ещё больше по размеру, и там 1001 страница текста.

Основные учебные программы, где учат предмету «корпоративные финансы» — это MBA, и студенты считают, что без помощи преподавателей нормально (профессионально) освоить этот предмет не удастся. Но тут есть небольшой подвох. С одной стороны, корпоративные финансы — это подпрактика бизнеса, который вроде как подпрактика менеджмента (хотя инвесторы и бизнесмены считают по-другому, у них главное отношение не часть-целое в практиках, а отношение найма людей: это вроде как они нанимают менеджеров-организаторов, поэтому менеджмент у них выглядит как подпрактика бизнеса). С другой стороны, Henry Mintzberg говорит, что как раз упор на финансовую аналитику (а корпоративные финансы при ближайшем рассмотрении оказываются главным образом аналитической дисциплиной, нет рассказа «что делать», есть рассказ как оценивать) делает выпускников программ MBA (master of business administration) далёкими от бизнеса, они массово идут работать не первыми лицами (CEO), не организаторами развития (например, CTO или CIO), но финансовыми аналитиками и в случае успеха финансовыми директорами, ибо хорошо освоили как раз финансовую аналитику в рамках курса корпоративных финансов. Помним, что для решений нужен синтез, а анализ подчинён целям синтеза. Курс корпоративных финансов позволит вам не сделать ошибок в оценке, но он не может помочь собственно бизнесу: привлечению инвестиций. Кроме того помним, что кроме чисто финансовых аспектов инвестиций есть аспекты юридические. И, конечно, психологические и социологические, при этом отношение к «капиталистам» и «бизнесменам» в мире везде разное. Это может проявляться со стороны страновой культуры: не забываем о странах социализма, странах госкапитализма, где население не любит «капиталистов», считает их эксплуататорами. Но это отношение может быть разным и со стороны инвесторов. В некоторых культурах акционеры считают, что они свои деньги не отдали фирме, чтобы делить прибыли и убытки, а «заняли в форме акций» (займ обычно не подразумевает возможность принятия решений по управлению фирмой, а акции вроде как подразумевают, поэтому возникает впечатление, что акции это «займ с возможностью управленческого контроля»). Юридически при такой путанице претензий может и не быть, но неформально акционеры могут высказать менеджеру в роли бизнесмена большие претензии, «карточные долги надо платить» — и «принуждение к платежу» будет жёстким, мир денег очень жесток и не вписывается в официальное правоприменение, там могут быть очень неофициальные методы (как, впрочем, в любой деятельности). Этот подход к путанице между акциями и облигациями встречается не везде, но чем ближе к странам проигравшего социализма, тем встречается чаще.

Но зачем вообще берут внешний капитал? Для старта дела: надо купить начальный труд, начальное оборудование, начальные расходные материалы, оплатить начальный маркетинг. Вопрос: а зачем берут инвестиции дальше? Для скорости развития. Различают «органический рост»⁵² без взятия денег у инвесторов и инвестиционный/неорганический рост⁵³ за счёт привлечения инвестиций, а также расходования имеющихся у компании денег не на выращивание собственных подразделений путём организации их из набираемого обычным способом персонала «с улицы» и закупки оборудования у его производителей, но за счёт слияний и поглощений с другими фирмами. Но не может быть никакого «органического роста», пока фирма не начала окупаться. Вот типичная диаграмма, показывающая откуда обычно берутся деньги на новое дело/предприятие/бизнес («приключение», venture, «рисковое вложение»):⁵⁴

Таких диаграмм много, это типичное представление, вот ещё вариант:

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

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

Практика корпоративной подназдорности (corporate governance)

Корпоративная подназорность/corporate governance⁵⁶ (общепринятый перевод — «корпоративное управление», но речь не идёт об управлении компанией, перевод governance лучше давать как «подназорность») определяется очень по-разному, но в широком смысле это практика успешности компании в том смысле, в каком говорят об успешных системах/successful systems в части удовлетворения интересов самых разных проектных ролей для системы: корпоративная поднадзорность гарантирует, что компания будет служить интересам самых разных внешних проектных ролей для самой компании как целевой системы инвестиционного проекта её собственников. В более узком значении и без использования эвфемизмов — это практика прислеживания за тем, чтобы служащие компании (в том числе, и даже особенно — менеджеры) не воровали деньги инвесторов.

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

В реальности всё сильно запутанней, плюс ещё на тему владения компаниями ещё и развитое госрегулирование, которое нужно тоже соблюдать. Если страна близка к социализму, то там и частной собственности нет, если чуть дальше, то может существовать концепция «эффективного собственника», где собственность можно отобрать у собственника под предлогом, что он ей не управляет, вариантов тут тоже много. При этом и при капитализме растёт движение за то, чтобы компании свои деньги направляли не собственникам и заботились не об интересах собственников, а на что-то другое. Так, ESG (Environmental, Social and Governance) investing — иначе известное как «социально-ответственное инвестирование» подразумевает, что инвесторы вкладываются в компании, которые каким-то образом не просто зарабатывают прибыль, а тратят деньги и на защиту окружающей среды, и на борьбу с бедностью, и на прочие цели, которые явно противоречат тому, чтобы просто заработать деньги и отдать их инвесторам (а те, если хотят, могут отдать их в благотворительный фонд). Эти социалистические идеи активно распространяются, при этом миф о том, что финансово ESG-инвестирование так же выгодно, как и просто инвестирование, но только нужно хорошенько подумать и «что-нибудь придумать, чтобы оставаться конкурентоспособными при всей благотворительности», активно распространяется. Как надо? Компаниям надо честно зарабатывать деньги, отдавать деньги инвесторам. Если инвесторы хотят, они вместо вложения денег в компании могут отдать (не вложить! Просто отдать) уже собственные деньги (каждый инвестор — свои, а не общие для них деньги компании) на цели, которые сочтут нужными: поддержку политических партий, просвещение, защиту редких животных, борьбу с голодом, исследования по биологическому бессмертию и т.д.

Идея сверхпопулярной книги Deborah Hicks Midanek «The Governance Revolution: What Every Board Member Needs to Know, NOW!», 2018, идёт ещё дальше.

Акционеры (shareholders, держатели долей, не путать с внешними ролями, stakeholders) объявляются имеющими влияние на компанию, но не собственниками. Между акционерами::сообщество и компанией::оргзвено появляется промежуточное оргзвено: совет директоров, который защищает компанию от собственников. Тем самым структура владения компании такая: работники, которые управляются (management) менеджерами, дальше corporate governance как совет директоров (board of directors или часто просто board), а затем уже владельцы-инвесторы. И говорится, что интересы всех уровней управления абсолютно разные, межвременные предпочтения («маленькие деньги и маленький риск сейчас или большие деньги и большой риск в будущем») тоже крайне разные, и поэтому «они никогда не договорятся, надо просто это признать». Да, теория говорит, что на разных системных уровнях у всех систем интересы разные, поэтому будет всегда множество самых разных вариантов многоуровневой организации, которые всегда будут неоптимальны, а только квазиоптимальны и крайне неустроенны/неустаканенны/frustrated (то есть легко будут меняться). Говоря о разных системных уровнях организации как уровнях распоряжения трудом и капиталом, мы понимаем, что есть оргзвенья, которые являются частями друг друга, и вот саму фирму очень грубо можно рассматривать как неотъемлемую часть её собственника (это обсуждалось ещё в курсе системной инженерии, когда говорилось про людей). Всё это сильно осложняется тем, что собственников обычно много и говорить «одна рука на двоих» — уж слишком метафорично. При этом рука без человека в целом работать не будет, а вот фирма у нового владельца — будет. Тем не менее, общие выводы теории, что договориться в этих условиях не удастся по буквально термодинамическим причинам (помним работы Ванчурина-Кацнельсона-Вольфа-Кунина), можно считать верными и для этой ситуации: вариантов оптимального структурирования оргструктуры существует огромное количество, но все они квазиоптимальны и не слишком устойчивы.

Отчуждение совета директоров от собственников, «которые не понимают в бизнесе, а хотят побольше денег, а случись чего, просто перепродадут свои акции, каждый из этой толпы немного потеряет — но компания обесценится» настолько уже велико, что в совет директоров вводят «независимых директоров», которые не являются собственниками, но которые могли бы улучшить управление. Тут не надо путать модных ныне для маленьких компаний менторов и коучей (в России смесь ролей ментора и коуча назвали трекер⁵⁷, но в мире этот термин по факту не используется) из ускорителей/accelerators, которые дают основателям/founders советы, но дальше основатели вольны их или использовать, или не использовать. Тут же даже независимые члены совета директоров имеют право голоса, то есть участвуют в принятии решений как полномочные представители — кого? Представители окружения компании, с интересами, отличными от интересов краткосрочной выгоды спекулятивных владельцев акций, в этом их назначение.

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

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

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

Один инвестор, который увеличивает собственность за счёт интересов другого инвестора — это тоже забота корпоративной поднадзорности. Скажем, стало известно, что компания будет сверхприбыльна, у одного акционера доля 70% (это мажоритарный акционер, с большим влиянием на голосование), у другого 30% (миноритарный акционер, маленькое влияние на голосование), обсуждается вопрос инвестиций в рост. Оценка компании — миллион долларов. Первый акционер говорит: «Давай вложим в компанию ещё миллиард долларов, она будет сверхприбыльна, а чтобы доли были равные, то я вложу $700 миллионов, а ты $300 миллионов. Ах, у тебя нет денег? Как жаль! Тогда все нужные деньги вложу я, проголосовать против ты не сможешь, но у тебя теперь будет доля в 1%, а не 30%». Цифры тут вымышленные, но сама ситуация крайне частая, абсолютно типовая. Конфликты между «партнёрами по бизнесу» (собственникам компании, владельцами долей в компании) случаются много чаще, чем известно широкой публике, просто их не афишируют.

Конфликт между собственниками и менеджментом тоже более чем част. Скажем, менеджмент может предложить выкуп менеджментом/management buyout⁵⁸, выкуп компании у собственников текущей командой менеджеров за небольшие, иногда даже символические деньги. Это не совсем та ситуация, о которой можно прочесть в учебниках по инвестициям. Скажем, что будет, если собственник говорит, что не хочет продавать компанию менеджерам? Менеджмент может предупредить, что уволится и уведёт за собой ключевых сотрудников, а у собственника останется владение пачкой юридических документов компании, непонятной суммы долгов по недавно взятым на эту компанию кредитам, а также старые столы, стулья и некоторое количество морально устаревшей техники, что стоит заведомо меньше той суммы, которую предлагают менеджеры для выкупа. А менеджеры учредят новую компанию, потратив деньги не на выкуп доли, а на закупку нового оборудования. Инвесторов же они тоже найдут новых, если потребуется, ибо все знают, работать они умеют — и работают-то они, а не владельцы! А вот умеет ли владеть компанией текущий владелец, у которого эту компанию выкупают? Может ли владелец рассчитывать на «пассивный доход» в небольшой компании, или он как-то должен участвовать в управлении? Совсем недаром в большинстве фильмов про рынок ценных бумаг повторяется мотив, что «в жизни совсем не так, как в учебниках». Да, в жизни люди ведут себя крайне изобретательно и имеют абсолютно разные представления о том, что делать этично, а что неэтично, в чём договариваться обязательно, а в чём можно просто принять собственное решение или наоборот, подчиниться чужому решению.

Особое внимание надо уделять и отношениям с собственниками/investor relations (IR), прежде всего при акционерной форме собственности. Это часто выделяют в отдельную практику. Главное тут — это публичное раскрытие информации, что сильно отличается от привычной практики «охраны коммерческой тайны». Это очень контринтуитивно, ибо ещё и поддерживается законодательством. Так, многие предприятия выбирают не выходить на биржу как раз для того, чтобы не иметь законодательных обязательств раскрывать информацию о своей деятельности — хотя лишние деньги, собираемые от инвесторов, этим предприятиям бы не помешали, но такие предприятия выгоды от сохранения тайны деятельности считают, что перевешивают выгоды от выхода на биржу.

Что касается практики управления слияниями и поглощениями/merges and acquisitions (M&A), то это отдельный большой предмет. Неорганический рост за счёт дружественных и недружественных поглощений других компаний — это очень важное направление корпоративного развития, но на этом пути подстерегает множество ошибок, удачных слияний и поглощений не так много.

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

4. Практика стратегирования

Понятие стратегии

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

Стратегия — это про цели и средства, причём всегда стоит вопрос, чьи именно цели и средства, мои/«наши» в защите от чужих/«их». Стратегия подразумевает выигрыш в конкуренции, уход от опасностей/голода и приход в безопасность/изобилие. В стратегии обычно нет привычного языка обсуждения работ (планирование), но есть язык обсуждения интересов/предпочтений, желаемых целевых систем и практик. Стратегия задаёт и обосновывает направление, в котором будет происходить развитие.

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

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

Стратегия — это альфа, о состоянии которой мы можем судить по рабочим продуктам, документированным моделям. Стратегия (выраженная в документированных стратегических моделях, примеры метаУ-моделей для трёх из них мы рассмотрим в конце раздела) направляет и организует как менеджеров организации (инженеров предприятия, главным образом организаторов команд инженеров целевой системы и команды продвиженцев/инженеров клиентуры), так и сами команды инженеров целевой системы и продвиженцев. Команды инженеров и продвиженцев пользуются стратегией, чтобы фильтровать идеи проектов (какие целевые системы, и какие сервисы для них планируется делать), которыми они будут заниматься. Команда менеджеров-организаторов пользуется стратегией, чтобы отфильтровать идеи проектов развития (какие практики будут поставлены в организации и какие оргзвенья будут заниматься этими практиками).

Сама стратегия на этой диаграмме разрабатывается и утверждается командой менеджеров инвестпроекта (который создаёт организацию), хотя в реальности всё сложней: агенты, чьи роли участвуют в команде менеджеров инвестпроекта, могут быть заняты и на всевозможных других ролях в разных проектах цепочки создания. В любом случае, из диаграммы видно, что важна роль бизнесмена — инвестициями занимается именно он. И если фирма плохо определила, чем ей заниматься и куда развиваться (то есть у фирмы плохая стратегия, или фирма имеет хорошую стратегию, но агенты-сотрудники её игнорируют), отдуваться перед инвесторами придётся ему. Поэтому в стратегировании главный бизнесмен, а остальные позиции в команде инвестпроекта он рекрутирует или снаружи, хотя это и редко (иногда идеи для стратегий дают консультанты, иногда клиенты), или внутри организации.

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

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

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

Начальник дурак, не осведомлён о ваших планах. Да, вполне возможно. Но начальник обычно сильно менее дурак, чем можно себе представить. Просто он выполняет какие-то другие роли, в которых ваши планы нужно проигнорировать.
Жизнь изменилась, стратегия изменилась, поэтому реализация старых планов — это путь к разорению. Планы надо срочно перевёрстывать. Как и всё, что связано с предприятием, стратегию можно начать разрабатывать, а вот закончить её разработку нельзя — «непрерывное всё», continuous everything. Так что практика непрерывного стратегирования заставляет оперативно менять стратегию, а потом надо перевёрстывать все планы реализации новой стратегии. Вы не знаете новой стратегии, не слышали о ней? Ваша беда, вам будет нервно.
начальство понимает, что никакой стратегии у вашей организации нет, и текущие действия этой организации не направлены на достижение какой-либо осмысленной и разделяемой людьми цели. В этот момент начальство понимает, что лучше уж в режиме ручного управления дать пару-тройку целевых ориентиров-проектов, чем организация будет тратить деньги просто так, бесцельно отапливая мировое пространство в «броуновском движении» самых разных проектов. В броуновском движении вы или берётесь за очень нужные проекты, либо за очень ненужные — стратегии, которая позволит быстро оценить, какие проекты достойны ими занятия, у вас нет.

Довольно много лет специалисты менеджмента не могли договориться, что такое стратегия. Henry Mintzberg⁵⁹ провёл исследование⁶⁰, по которому пришёл к выводу, что это слово может принимать пять разных значений (они известны как 5P от Henry Mintzberg):

Perspective (для предприятия примерно то же, что «характер» для человека: какое поведение ожидается от фирмы)
Plan (последовательность просчитанных шагов)
Ploy (уловка, «военная хитрость»)
Pattern (предпочтительный образ действий, практика ведения какого-то дела)
Position (выбор сегмента рынка — товара и географии, акцент на окружении)

В исследовании было выяснено, что каждая фирма настаивает на своём значении, но не признаёт другие: для какой-то фирмы стратегией были только планы, а для какой-то фирмы — только «хитрости». Henry Mintzberg сделал примерно такой же вывод, как Ralf Johnson в отношении архитектуры, когда говорил «Архитектура — это про всё важное, что бы это ни было».

Mintzberg немного в других формулировках сказал, что стратегия — это всё важное, что бы это ни было, абсолютно не нужно соответствовать какому-то определению стратегии или даже изобретать собственное определение. А все эти 5P вполне можно найти в стратегии, это просто разные важные аспекты стратегии.

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

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

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

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

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

Потом после высказывания, что «архитектура — это про всё важное», в архитектуре выяснилось, что важное — это архитектурные характеристики, сама архитектура может меняться (evolvable architecture), а решения архитектора — это постепенно меняющиеся в ходе проекта ограничения в разбиении на модули и связь между модулями, принимаемые для достижения этих архитектурных характеристик, -остей/-ilities. И тем самым были отделены концепция использования и концепция системы от архитектуры как набора появляющихся в ходе архитектурной деятельности/architecturing архитектурных решений, принимаемых архитектором/architect. В курсе «Системная инженерия» эта история приводится более подробно, литература на эту тему появилась примерно в 2017 году.

Примерно то же самое происходит сейчас со стратегией: она перестаёт связываться с «важнейшими решениями, которые нельзя потом изменить», а становится чуть ли не наоборот: «важнейшими решениями, которые потом позволят быстро изменяться, быстро расти, не исчезнуть». Тот же Mintzberg заметил, что планирование начинается после принятия стратегических решений (strategy is not the consequence of planning but the opposite: its starting point⁶¹) — ибо планы появляются после того, как становится понятно, чего эти планы хотят достичь. Но в ходе выполнения планов успевает измениться ситуация, «пункт назначения успевает измениться во время путешествия». Поэтому стратегия ничто, а стратегирование/strategizing — всё, стратегию нужно непрерывно менять, принимать всё новые и новые стратегические решения (по аналогии с архитектурными решениями). Но Mintzberg полагал градуальные изменения, «дрейф» какой-то постоянно поправляемой в мелочах стратегии. Сейчас к этому «дрейфу» прибавили и крутые «виражи» (pivots), означающие занятие совсем другим делом (полная смена продукта, выход на полностью новый рынок, полная замена бизнес-модели — то есть перестройка практически всей деятельности компании, разве что администрирование остаётся прежним).

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

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

Дальше мы не всегда будем упоминать личность, когда говорим о стратегировании. Но помним, что большинство рассуждений приложимо и к личности. В принципе, весь курс «Системный менеджмент» в какой-то мере приложим к личности, хотя именно «в какой-то мере», нюансы при переходе от одного вида систем (организации) к другому (личности) будут всегда. Для сообществ всё сложней, ибо в них обычно нет общности целей и каких-то явно признаваемых «договорок»/commitments, которые позволяют поручать кому-то работу (а если есть, то связанных такими «договорками» людей можно просто признать полноценной организацией, например какая-то ассоциация членов профессионального сообщества, или организаторы танцевальной вечеринки для сообщества любителей какого-то стиля танца).

В организации непрерывно ведётся организационная работа (оргдизайн и лидерство), архитектурная работа (architecturing) в части достижения архитектурных характеристик типа гибкости/agility, масштабируемости/scalability и т.д., а также непрерывно ведётся стратегирование/strategizing — принятие согласованных самыми разными ролями (то, что довольны самые разные роли — это успешность!) решений, направленных на рост прибыли.

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

Практика стратегирования

Переход от стратегии к стратегированию крайне важен: стратегия ничто, а стратегирование (непрерывная разработка стратегии и непрерывный переход к её реализации во всё новых и новых версиях) — всё.

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

Практика стратегирования в бизнесе имеет не очень долгую историю, и по большей части это история неудач⁶²:

До 40-х годов прошлого века: стратегия только у военных. Бизнес про стратегии и стратегирование не слышал.
Бюджетирование (James McKinsey, Budgetary Control, 1922) как предтеча бизнес-стратегий. Бюджеты как запланированные траты, которые должны были пополняться запланированными доходами исполнялись, но запланированные доходы почему-то не случались.
Стратегическое планирование (60-70-е годы прошлого века, упор на анализ, чтобы точнее «понять рынок»). Менеджмент по целям (management by objectives) — классический пример поветрия. Научно обосновать спрос и спустить «стратегию» как требование заработать столько-то денег на таком-то рынке снова и снова оказывалось невозможно: сотрудники могли исполнить такую стратегию, а вот клиенты почему-то не входили в положение и не исполняли её, не покупали в запланированных количествах. Сейчас словами «стратегическое планирование» обозначают самую плохую практику: «я придумал вам стратегию в виде подробного плана действий, вам нужно только выполнить эти действия, и мы разбогатеем».
Самосбывающиеся теории в основе стратегирования (80-90-е прошлого века, основанные на ошибочном понимании рынка как равновесия спроса и предложения: теория сравнительных преимуществ) — mission statements and core competencies. Оценка силы и слабости как самый популярный приём (SWOT — strength, weakness, opportunities and threats), 5 сил, работы Портера по пути к мифу «sustainable competitive advantage», то есть «самоподдерживающееся/устойчивое конкурентное преимущество». Жизнь показала, что самые сильные стороны сегодня становятся залогом проигрыша завтра: если у тебя самая лучшая в мире фотобумага, как у Kodak, то ты просто не замечаешь прихода цифровой фотографии, где фотобумага не нужна вообще, а фотографии рассматриваются главным образом на экранах мониторов.
Огромная россыпь текущих подходов к стратегированию есть и сегодня (2022 год): надёжно работающих среди них нет! На каждый пример есть контрпример!
Одно стало понятно: провал стратегии — это просто повод её подправить в очередном цикле, а иногда не «подправить», а радикально изменить (ну, или это действительно провал, если ресурсы уже кончились и их не хватит на реализацию очередной версии).

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

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

Визионерства как оценки того, что продуктные инициативы прибыльны (разработчики продукта выдают концепцию использования и какую-то концепцию системы, службы продвижения по концепции использования дают оценку по объёму возможных продаж, разработчики дают оценку стоимости реализации концепции системы — визионеры пытаются увязать одно с другим и прикинуть, сколько денег на каком интервале времени это принесёт),
Бизнеса как оценки того, что компания сможет взять инвестиции с рынка в текущей и продать компанию в будущей ситуации (страновые риски, финансовые риски, репутационные риски, какие-то возможные проблемы с учредителями, ситуация с заёмными средствами, а ещё что там думают визионеры по поводу продуктов и сервисов, а также организаторы и архитекторы по поводу самой компании).

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

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

Главным в организации этих переговоров обычно выступает бизнесмен. Если фирма в конечном итоге работает в убыток, её стоимость падает — фирму закрывают, дальше исполнители всех других ролей будут искать себе другие работы. Поэтому слово бизнесмена самое главное — он выражает интересы собственников фирмы, как он скажет по части принятия решений, так в конечном итоге и будет. Проблема только в том, что у него такие же гипотезы по поводу будущего, как и у всех других, и они могут не подтвердиться. Но по поводу его распоряжений — это не гипотезы, а исполняемые решения. Скажет по поводу какого-то стратегического решения «мы этого делать не будем» — и проект не будет финансироваться, но если скажет «мы будем вот это делать», то именно это и будет делаться. Если всё с прибыльностью фирмы сейчас и в будущем ОК, то бизнесмен не вмешивается, это надзор/governance за ходом стратегирования. Поэтому стратегированием занимаются все, оно распределённое по самым разным ролям (и тем самым должно быть организовано, компания должна практиковать стратегирование, менеджер-организатор должен предусмотреть поддержку этой практики), но слово бизнесмена по утверждению стратегии оказывается главным, именно он является интерфейсом к собственникам/инвесторам и именно он высказывает свой прогноз о том, что будет происходить с рыночной оценкой фирмы.

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

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

Бизнес-модель — в какой форме за какой продукт у клиентов забираются деньги, и будет ли это выгодно.
Модель оргразвития — какие новые практики работы нужно освоить (что делаем), чтобы выжить в быстро меняющейся ситуации (состояние желаемого мира), и почему (обоснование, почему практика приведёт к желаемому состоянию). Миссия/mission и видение/vision — это тут.
Модель целеполагания (увязки интересов) — каким деятельностным ролям что надо и как этого добиться (какую практику применить).

Откуда же берутся стратегии? Их придумывают, понимая при этом, что статус этих стратегий — догадки, это «стратегические гипотезы». Все модели построены на догадках о том, как устроен мир. Эти догадки существуют до тех пор, пока не опровергнуты логической критикой, или экспериментом — в эксперименте может оказаться, что какая-то другая догадка, которая тоже выдержала логическую критику, даёт совпадение её предсказаний с жизнью лучше, чем текущая, поэтому текущая догадка считается фальсифицированной/falsified/опровёргнутой. Иногда её откидывают, но иногда просто подправляют.

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

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

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

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

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

И тут нужно вспомнить о многоуровневости стратегирования: оно должно вестись на всех системных уровнях организации (если нам нужно что-то изменить быстрее и точнее, то надо иметь многоуровневость и многоразмерность на этих уровнях, помним про исследования John Doyle⁶³).

А вот книга, Bijan Khezri, «Governing Continuous Transformation. Re-framing the Strategy-Governance Conversation», 2022, которая напрямую связывает подход active inference и непрерывную реорганизацию, которая подразумевает надзор над этой реорганизацией со стороны непрерывно изменяющейся стратегии на базе идей active/embodied inference, которые мы рассматриваем в наших курсах системного мышления, методологии, системной инженерии и вот теперь системного менеджмента:

Задания

Поставьте отметку о выполнении следующих заданий:

Прочтён обзор методов стратегирования http://vijaykumarbhatia.weebly.com/strategic-management-history-and-development.html, опубликован пост с мыслями, пришедшими в голову по мере чтения текста.
Прочтена книга Bijan Khezri «Governing Continuous Transformation. Re-framing the Strategy-Governance Conversation», 2022, опубликован пост о том, как вы изменили своё понимание стратегии организации после знакомства с материалом этой книги.

Качества хорошей стратегии: это фильтр

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

Jeann Liedtka сравнила стратегию с маленьким чёрным платьем.

Добавьте к маленькому чёрному платью жемчуг и каблуки, чтобы одеться торжественно. Яркий шарф и брошку, чтобы одеться демократично. Возможности безграничны, поэтому маленькое чёрное платье часто считают наиболее полезным платьем в женском гардеробе. Чёрные платья очень удобны, подходя для выполнения множества ролей во множестве ситуаций. Хорошая стратегия должна быть такой же: очень простой, но элегантным (lean, сознательный минимализм) способом полезной в огромном числе ситуаций.

Стратегия должна использоваться для быстрого и грубого определения того, чем будет и чем не будет заниматься фирма. Для этого нужно, чтобы она была очень краткой и не слишком детальной, чтобы грубый ответ можно было дать быстро. «Будем ли мы выпускать X? Нет, не будем — по нашей стратегии мы должны двигать продуктовую линейку в сторону товаров Y и Z». Будем ли мы запускать оргпроект R? Будем, и срочно, это хорошо отвечает нашей стратегии», примерно такого уровня простые рассуждения.

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

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

Michael Porter⁶⁴ любил обсуждать фокусирование на каком-то предмете (мы это называем собранностью). Поэтому можно предложить тест Портера, который будет отличать даже не хорошую стратегию от плохой, а стратегию от не-стратегии: стратегия предусматривает, что вы немедленно бросаете заниматься чем-то одним и начинаете заниматься чем-то другим. А не-стратегия предлагает заняться чем-то ещё вдобавок к тому, что вы уже делаете. Стратегия — это фильтр для идей «чем заняться», она не добавляет лишнего, но отсекает ненужное. Если не удалось сказать, чем вы бросаете заниматься, когда вы принимаете (к реализации) новую стратегию, то подождите с реализацией, это вряд ли стратегия, это просто какое-то рабочее планирование. Буквально: составьте список дел, которые вы прекратите выполнять — этот список должен оказаться не пустым в момент принятия новой стратегии к реализации.

В какие моменты нужна стратегия? Прежде всего в момент, когда вы выбираете новый продукт. В ISO 15288 есть практика анализа бизнеса и миссии (business and mission analysis), которая проводится на старте проекта — и там задаётся простой вопрос: мы начинаем новый проект, а он соответствует текущей стратегии, или нам надо от него отказаться?

В операционном менеджменте также будет разобрано, что мультитаскинг вреден. Это означает, что когда вы захотите реализовать сразу «полноценную стратегию» и начнёте выполнять одновременно сто годичных проектов, то это сразу испортит дело: параллельно выполнить их вы всё равно не сможете, а через несколько лет в новой ситуации нужны будут уже другие проекты, а эти будут как раз все «надкушены, но не съедены». Нет, в планировании реализации стратегии нужна жёсткая приоритизация: делать нужно только то, на что у вас есть ресурсы действительно это доделать, и доделать быстро. Это же относится и к личному стратегированию, если вы реализуете какой-то вариант GTD⁶⁵, то там тоже требуется честно выкидывать из списка дел те, которые вы хотели бы сделать бы, если бы было бы время бы и силы, но руки всё равно не дойдут — есть дела поважней и интересней. Стратегия должна быть сформулирована достаточно узко, чтобы такие дела, до которых не дойдут руки (но которые очень хочется сделать! Если бы — поставьте сюда ещё несколько «бы») не попадали в планы, не надо, чтобы они вас отвлекали. Будьте собраны, избегайте мультитаскинга.

Если вы вдруг поменяли стратегию, тогда пожалуйста — занимайтесь новыми делами, но не забудьте резко прекратить делать старые дела. Фокусирование на чём-то, накопление мастерства в чем-то — вот для чего нужна стратегия. Jack of all trades, master of none (знаком со многими профессиями, мастер ни в какой из них) — это заведомый проигрыш в конкуренции. Для получения мастерства, какого-то преимущества, надо много этим делом заниматься. Если занимаешься десятками дел сразу, то мастером просто не успеешь стать до того момента, когда жизнь опять изменится, и нужно будет заняться чем-то другим. Фокусируйте (то есть заставляйте придерживаться стратегии, соберитесь) себя, фокусируйте (заставляйте придерживаться стратегии, соберите) организацию.

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

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

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

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

Это обсуждается как реализация цикла выигрыша в конкуренции John Boyd⁶⁶:

Этот цикл военный лётчик Джон Бойд сформулировал на примере военного сражения, но потом это было переформулировано для ситуации рыночной конкуренции:

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

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

Очень опасно впадать в заблуждение. В том же военном деле классическим способом уменьшить число ошибок будет разнесение по разным агентам шагов цикла Бойда. Так, в системе управления авианосцем «Клемансо»⁶⁷ рубка была разделена прозрачным экраном, и это помогало убрать конфликт интересов разведки и управления огнём⁶⁸:

На одной стороне экрана отображалась информация наблюдения и ориентация во внешней среде (порождающая модель внешней среды), на другой стороне экрана — информация о собственных ресурсах действия (порождающая «модель себя»). Если это не разделить, то разведка может быть заинтересована искать не там, где потерял (где противник, где максимум опасности), а под фонарём (куда уже направлено всё вооружение, где удобней проводить интервенцию или оборону) — это конфликт интересов. Лицо, принимающее решение (стратег, согласовывающий интересы самых разных ролей) далее принимает решение на основе и одной модели, и другой модели. Как это обычно и делается в модели active/embodied inference, принимается решение о том, что меняем во внешнем мире, и каким образом с какой скоростью, и что меняем в себе, и каким образом. Главное — честно видеть свои оргвозможности/capabilities и уметь найти возможности/opportunities, а также вовремя заметить неприятности и отреагировать на них.

Можно ли «жить мирно, никому не мешать, и чтобы тебе не мешали», без конкуренции? Без войны жить можно, а вот без конкуренции за ресурсы — нельзя, помним об эволюции, конфликтах между объектами разных системных уровней, и принципиальную невозможность решать эти конфликты. Чтобы убрать неприятный байесовский сюрприз (помним о теории active inference), вам нужно побольше ресурсов. И чтобы их добыть, вы конкурируете с окружением, ведь агентам в окружении нужно то же самое! И ситуация может только усложняться, поскольку агенты эволюционируют, чтобы лучше соответствовать своему окружению (например, лучше сопротивляться конкуренции с вашей стороны).

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

Задания

Отметьте выполнение следующих дел:

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

Бизнес-модель и её «холстовое» моделирование

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

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

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

В какой-то мере стратегия отвечает и на вопрос о концепции использования организации (концепция системы из «Системной инженерии» для случая организации): чем занята работающая организация во внешнем мире, какие системы делает, так что стратегия может рассматриваться и как часть документации проекта развития. Раньше это назвали бы «требования к организации», но требований сейчас нет — есть гипотезы о том, что правильно угадали стратегию в этой части, а сама стратегия представлена моделями use case, данными чаще всего в виде бизнес-модели. Хотя модели стратегии чаще всего гибридны, несводимы к «концепции использования организации», «концепции организации», гибридность представлений как раз нужна для согласования набора моделей между отдельными ролями с их уникальной экспертизой и ролевыми интересами.

Общее тут замечание в банальности итоговых моделей, банальности результатов стратегирования. Если ваши стратегические модели не выглядят банальными (то есть после ознакомления с ними не звучит фраза «спасибо, Кэп⁶⁹. Это и так понятно, зачем мы на это тратим время?»), то вы ещё не досогласовали интересы, это ещё не совсем стратегия. Стратегия должна быть банальна, очевидна, проста, походить на «просто здравый смысл», не требовать каких-то специальных разъяснений и особых знаний по её пониманию. Тогда она будет и быстро принята, и успешно реализована.

Это другой вопрос, оправдаются ли предположения/догадки/гипотезы о мире, высказанные в стратегии, но уж точно у вас не будет саботирования при выполнении: если стратегия выглядит как «здравый смысл», то этой стратегии просто будут придерживаться. Если стратегия подозрительна (а непонятная стратегия всегда подозрительна), то её не будут придерживаться, а будут делать что-то своё, на ходу придуманное и никак не соответствующее стратегии. Это гарантированно приведёт к неудаче. Поэтому важна не форма, а содержание моделей, но к содержанию выставляется дополнительное требование внятности и подробности изложения, чтобы на возникающие вопросы модели отвечали без их доработки. Шаблоны моделирования в существенной мере отражают это требование.

Первой из необходимых для стратегирования моделей будет бизнес-модель — в какой форме за какой продукт у клиентов забираются деньги, и будет ли это выгодно. Бизнес-модель с её возможной новизной (помним, что «новизна» в стратегировании — важная характеристика, это шанс выскочить на полянку, более-менее свободную от конкурентов, хотя бы на очень короткое время) не менее важна, чем забота о новых практиках работы и новых технологиях для этих практик (хотя можно думать о ней, как «новой практике для того, чтобы взять деньги клиента»). Вот примеры практик получения денег, revenue models, это материал для построения части бизнес-модели⁷⁰.

Самая распространённая форма представления бизнес-модели — это «холст»/canvas, «нетабличная таблица», обеспечивающая явные типы метаУ-модели для важных объектов внимания модели какой-то предметной области (тут это бизнес-моделирование), указываемых в клетках таблицы. Инструкция по пользованию «холстами» проста: печатайте форму на бумаге размера A2 во множестве экземпляров, вешайте на стенку (закрепляйте на флипчарте) и заполняйте потом фломастерами. Когда поймёте, что это всё плохо, снимайте лист бумаги, комкайте его и выкидывайте в урну (итерации стратегирования должны быть дешёвыми и быстрыми в части документирования моделей!), закрепляйте очередную пустую форму и продолжайте моделировать, пока результат не понравится. Оставьте конечный результат на этой форме, дальше разошлите фотографии всем заинтересованным. Важно, что через некоторое время стратегирование продолжится — смело комкайте и этот вариант, рисуйте новый на новом листе.

Классический холст вот:

В 2004 году Alexander Osterwalder⁷¹ защитил диссертацию «The business model ontology a proposition in a design science approach»⁷², где подробно разбиралось само понятие бизнес-модели и предлагалось моделирование на языке Busines Model Modeling Language (BM²L, определялся собственной XML-схемой, так было модно в 2004 году). Это могло бы пройти незамеченным, но в 2010 году на базе его идей им и его научным руководителем диссертации Yves Pigneur была написана даже не книга, а дизайнерски оформлен роскошный альбом Business Model Generation⁷³.

Вместо формального языка моделирования было предложено использовать «холст» (схема-пустографка), а в качестве примера были приведены бизнес-модели крупных компаний, которые были у всех на слуху. Это неважно, что бизнес-модели компаний не очень соответствовали тому, что происходило там на самом деле в части стратегирования, но широкая публика получила простой и красивый инструмент компактного и универсального описания самого важного в стратегиях (то есть инструмент моделирования), а ещё книга создавала смутное ощущение, что большие истории успеха то ли тоже могут быть так отмоделированы/оформлены, то ли именно так и были спроектированы.

Рассказ про пользу этого варианта документирования бизнес-моделей был коротким: текущее (на момент 2010 года) бизнес-планирование в инвестфондах, принимавших решение о выдаче инвестиций командам стартапов оформлялось в виде толстых томиков «бизнес-планов» стартапов, которые хранились потом на полках инвестфондов. Оказалось, что эти бизнес-планы и никто не читал, и никто ими не руководствовался, но они массово производились — деньги инвестфондами выдавались «под бизнес-планы». Почему так? Во-первых, инвесторам нужно было убедиться, что команда может хоть что-то документировать (но бизнес-план написать команда могла поручить кому-то ещё), а во-вторых, если что-то шло не так и деньги пропадали в силу каких-то неудач, то вроде как был ответ на вопрос, почему вообще эти деньги выдали: вон, на полке лежит обоснование! Предложение поэтому было в стиле элегантности/lean для инвестпланирования: давайте возьмём самые важные объекты внимания для инвесторов (конечно, это и была онтология из диссертации Osterwalder, это ж и есть «самые важные объекты внимания») и позволим легко и непринуждённо моделировать, оформив метаУ-модель в виде схемы-пустографки, аннотирование элементов бизнес-модели типами метаУ-модели происходит путём вписывания элементов бизнес-модели в место, указывающее тип из метаУ-модели. Вот эти девять типов для частей модели в классическом варианте:

Ключевые партнёры (Key Partners).
Ключевые практики (Key Activities)
Ключевые ресурсы (Key Resources)
Предложение пользы (Value Proposition)
Взаимоотношения с клиентами (Customer Relationships)
Каналы сбыта (Channels)
Виды клиентов (Customer Segments)
Структура затрат (Cost Structure)
Источники доходов (Revenue Streams)

Никакого «специального формального компьютерного языка моделирования», никаких компьютеров вообще, бумага и фломастеры, нацеленные на дешевизну и скорость получения очередного варианта (continuous strategizing — непрерывная разработка стратегии, непрерывные её изменения). Это совпало с предложениями книги Eric Ries «Lean Startup» по уменьшению количества документации. Вместо томов бизнес-планов нужно было писать действительно важные вещи, а форма записи стимулировала пробовать много вариантов перед тем как выдавать «очередной окончательный», который тоже потом мог меняться, как и требовалось идеями «непрерывного всего». Проблемы были в том, что такие модели было трудно редактировать (рекомендация была использовать стикеры, наклеиваемые на холст, но всё одно писали фломастером крупными буквами — надписи на стикерах были плохо видны при групповом моделировании). По объёму текста бизнес-модели получались небольшие, если нужно было что-то исправить, не изменяющаяся часть просто переписывалась начисто. И ещё трудно такие модели «фломастером на холсте как флипчарте» пересылать и публиковать. Для слайдов это просто красиво версталось на слайдах (модель компактная), а для пересылки часто использовались фотографии с распространившихся как раз в то время смартфонов.

В результате в мире прекратили документировать бизнес-планы, а все акселераторы стартапов, бизнес-инкубаторы, инвестфонды и прочие перешли на рассмотрение бизнес-моделей в форме заполненных холстов, где тип объекта бизнес-моделирования указывался прямо в холсте. Появилось множество работ, которые или подтверждали онтологические выборы Osterwalder (например, «Business Model Ontology (BMO): An Examination, Analysis, and Evaluation»⁷⁴, 2016), или пытались что-то улучшить. Вот пример попытки такого улучшения, lean canvas от Ash Maurya⁷⁵:

Появилось и множество других примеров «холстового моделирования», например, для облегчения работы визионеров, которым нужно одобрять или не одобрять предложения новых фич Никита Ефимов предложил «холст фичи»⁷⁶, как вариант моделирования фичи с использованием онтологии (метаУ-модель) фичи, помогающую с обоснованием, то есть ответом на вопрос «почему важно реализовать эту идею/фичу»:

Ещё один вариант холста для бизнес-модели:

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

Но обратите внимание, что смысл тут немного меняется: речь идёт не столько о том, чтобы о чём-то подумать, сколько о чеклисте для разделов статьи. Тем не менее, это подчёркивает онтологичность (указание важных объектов внимания) разделов статьи и превращает статью в альфу, которую дальше двигают по её состояниям в проекте написания статьи: для ответа на вопрос о содержании каждого раздела статьи надо планировать какие-то работы. Это в какой-то мере относится и к бизнес-моделированию: если смотреть на business model canvas как на чеклист какой-то альфы, то нужно выполнить работы, переводящие ситуацию «бизнес-модели нет» в «бизнес-модель есть» (то есть на вопросы холста есть ответы).

Это приводит к ещё одному вопросу про управление работами для стратегирования, планирования работ по реализации стратегии, и затем отслеживания выполнения стратегии. Есть целый класс софта для выполнения таких работ, он называется roadmap software, примером тут служит Aha!⁷⁸:

Мы рекомендуем использовать для бизнес-моделирования универсальные моделеры (notion.so, coda.io и т.д.), в них вполне могут быть реализованы canvas как развитие табличного представления. Уж какая именно вами будет использована метаУ-модель — смотрите в литературе по бизнес-моделированию (например, указанной в нашем курсе), вы теперь знаете, что там искать.

Бизнес-моделирование в ходе стратегирования (в стратегировании нужно уторговать не только бизнес-модели, но и модели оргразвития, и модели целеполагания, и в разных организациях могут ситуативно потребоваться и другие виды моделей) выполняется тем самым

или в разговорах: «мышление коллективным проговариванием», самая слабая форма, но вы можете записать аудио или даже видео, которое потом никто не пересмотрит,
или в ходе написания текстов: «мышление письмом» как изложение моделей в свободной форме, не слишком привязанное к типам метаУ-модели, но уже с возможностью инкрементального обновления/редактирования текста, запоминания промежуточных результатов моделирования в тексте, возможностью привлечения дополнительных людей к обсуждению, возможностью использования машинного интеллекта для улучшения текста, возможностью рассылки/публикации (то есть модель «подписки» участников на обновления) необходимому числу участников
или в ходе заполнения таблиц или упрощённых таблиц/холстов/canvas с явно задаваемыми типами объектов, на которые нужно обратить внимание: «мышление моделированием», причём в этом случае можно выходить на моделирование альф и отслеживать изменение состояния альф в проекте. Как вариант, это может быть и просто текст, но тогда типы задаются подзаголовками (например, аутлайнер), или в тексте используются явные указания типа через специальную разметку (в нашем курсе используем знак :: для указания типа).

В любом случае, использование типов не говорит ничего о качестве самого моделирования. Если указано 78°C::«температура тела клиента», то даже если вас интересует именно температура тела, что-то не так. Если у вас в бизнес-модели указано «летаем на Луну дирижаблями за рубль»::«уникальное предложение пользы»/«unique value proposition», с вашей бизнес-моделью проблемы, и это не связано с использованием метода описания/метода моделирования/viewpoint/метаУ-модели. Помнить о важных для бизнес-моделирования типах объектов внимания надо, но крайне важны и сами объекты внимания, которые имеют эти типы, сама бизнес-модель для вас должна быть важнее выбора типов для бизнес-модели (метаУ-бизнес-модели). Но без мета-модели вы будете моделировать что попало без разбору, потеряете время на моделирование лишнего и можете пропустить моделирование нужного, поэтому думать о бизнес-модели, но не думать о типах её частей — это тоже нехорошо.

Модель оргразвития

Ещё одна модель, используемая для стратегирования, условно может быть названа моделью оргразвития: какие новые практики работы, основанные на каких принципах и упомянутых в них объектах (дисциплина практики) нужно освоить организации, чтобы в изменяющихся условиях у неё появились новые оргвозможности. Одна из самых наработанных практик подобного моделирования стратегии была разработана Eli Goldratt в 2002 году, она получила название strategy and tactic tree (SnT)⁷⁹ и вошла как отдельный процесс в состав TOC thinking processes. Сам Eli Goldratt подходил к типизации предложенной им метаУ-модели не слишком строго. Он придумал интересный ход: предложил типовые модели стратегии развития для машиностроительного производства под заказ и розничной торговли со складами. Стратегия для него — это ответ на вопрос «какой результат хотим получить», а тактика — это «какой практикой хотим получить этот результат». Мы под стратегией понимаем набор моделей (а не результат применения практики), а слова «тактика» у нас вообще нет (табуировано, ибо если про стратегию ещё хоть как-то можно договариваться, то про тактику договариваться обычно бесполезно, все понимают под ней что-то своё), так что мы будем «голдраттовскую стратегию» называть «целевым состоянием мира» (в 4D — это важно! Доводить описания до изменений в физическом мире!), а приводящее к этому состоянию мира действие будем называть целевой практикой. По-другому мы переводим и другие термины предложенной Eli Goldratt метаУ-модели, чтобы меньше путаться. Вот эта метаУ-модель в виде диаграммы:

В этом способе моделирования ключевым является абсолютно традиционный для инженерии ход на отделение (1) результата работ от (3) метода его получения, функционального описания от аффордансов конструктивного описания, хотя тут есть тонкости: функциональное описание дано как состояние мира, в котором выполнимы необходимые целевые функции, а аффордансы даны как оргвозможности в виде сервисов, способных выполнить какие-то оргпрактики. Верхний уровень такой стратегии в части описания будущего мира, в котором стратегия реализована — это vision/видение/вижн организации. А верхний уровень практики, которая должна быть реализована, чтобы получить целевое состояние мира — это миссия/mission. «Найдётся всё::vision, так как «будем программировать самый крутой поисковик в интернете»::mission». Главное — это различение практики и её результатов, не такая тривиальная задача для очень и очень многих не-инженеров. В этом варианте моделирования категорически запрещается формулировать практику через глаголы «получить», «сделать» и прочие подобные способы. Помним: если у вас нет понимания affordances, то есть концепции системы, в проект нельзя ввязываться! Вы легко себя обманете, если напишете «мир во всём мире»::vision, а дальше «обеспечить/получить/сделать/воплотить мир во всём мире»::mission. Нет, вам придётся прямо назвать практику какого-то domain, которой вы хотите это сделать, ибо ваше оргразвитие будет реализацией этой практики. Если практика содержательно непонятна, то стратегия просто не будет воплощаться — утопиями никто не занимается.

Защита от утопий в этом методе моделирования/viewpoint/meta-model двойная:

(2) Нужно написать обоснование, почему вы хотите именно того, что записано. Решение хотеть должно быть рациональным: то есть вы должны описать, почему вы вообще должны тут принять решение и не можете просто пройти мимо, затем должны описать догадки об альтернативах, затем принятие решения по выбору из альтернатив. Если этого нет, есть все шансы, что ваши хотелки утопичны, это не может быть стратегией.
(4) Нужно написать обоснование, почему то, что вы обоснованно хотите получить в предыдущем пункте, достижимо той практикой, которую вы предлагаете. И тут всё то же самое, разве что не надо описывать, почему вы этого хотите. Но надо описывать, какие варианты практик рассматривались, и почему вы выбрали именно эту практику изо всех (как воспользовались теорией решений, как рационально рассуждали при выборе).

Дальше вы делаете предположение о том, что эта стратегия начинает выполняться, и в явном виде выписываете, что перестаёт выполняться в организации, что не соответствует этой стратегии, (5) — это практики-жертвы. Вы честно описываете последствия принятия стратегии.

Дальше вы декомпозируете состояние мира и практику его получения на части, которые достаточны для реализации стратегии (6) — и для каждой части выполняете все нужные описания, и так где-то три уровня, пока состояния мира и приводящие к ним практики не будут абсолютно очевидными и не будут требовать каких-то обоснований. Конечно, нужно позаботиться о полноте этих практик. Обычно полезен такой приём: «много было организаций, которые реализовывали видение X практикой Y, но у них не получилось. Мы понимаем трудности и риски, поэтому нам будут нужны вот такие особенности в их реализации: X1-Y1, X2-Y2, и т.д.» (всё, конечно, с обоснованиями и выписыванием «жертв» того, что делаем всё теперь по-новому, а по-старому не делаем).

Если посмотреть на важность обоснований в этой метаУ-модели организационного развития, то можно дать ей название strategy case/«стратегическое дело», по аналогии с assurance case/«дело инженерного обоснования». Помним материал по инженерным обоснованиям из курсе «Системной инженерии»: папка «Дело №___» заводится в первый день существования инженерного проекта, и ведётся непрерывно до момента окончания проекта. То же самое можно сказать про организационное развитие, которое является таким же инженерным проектом, требующим обоснования. Такого сорта модель может быть документирована как «стратегическое дело», представляющее собой актуальное состояние обоснованных видения и миссии организации, а также обоснованную их декомпозицию.

Конечно, работать с таким «делом» в форме диаграммы невозможно. Вот пример так документированной части (только части!) дерева транспортной стратегии областного уровня, четыре уровня декомпозиции (в жизни это было распечатано на рулонном принтере в виде ленты больше метра шириной и трёх метров длиной)⁸⁰:

Это только маленький кусочек, выполненный в моделере FlyingLogic. Вот верхушка этой части стратегии «крупным планом»:

Цель тут — связка с остальными элементами стратегии, стратегия тут была весьма детальной и включала много элементов оргразвития для министерства транспорта области. Типы мета-модели были названы по-другому: «результат» тут состояние мира в результате применения практики, «действие» — это целевая практика, «обстоятельства» это обоснование того, почему хотим такого состояния мира, а «аргументы» (rationale, помним рассказ про обоснования — в ходе выполнения стратегии там должны бы появиться и свидетельства/evidence, а «результат» будет пониматься как претензия/claim) — это почему предложенная практика («действие») принесёт желаемое состояние физического мира («результат»). Контраргумент — это обоснование того, что требуется пояснение в реализации какой-то части практики, ибо много что может пойти не так.

Пример от самого Eli Goldratt — это колода слайдов, где один слайд представляет собой узел дерева⁸¹:

Nessesary assumptions — это обоснование целевого состояния мира, parallel assumptions — это обоснование действий («параллельные» — это «параллельные две стороны одной медали», как пояснил Eli Goldratt в одном из своих интервью, мы уже говорили, что язык у него довольно поэтичен), sufficient assumption это как раз выход на декомпозицию. И ещё заметим, что сам Eli Goldratt очень «творчески» относился к типизации, и не очень точно соблюдал предложенные им же самим типы. Его примеры работают с типизацией так же творчески, как предлагался термин «параллельный» на основе выражения «две стороны одной медали».

Ещё одна интересная параллель этой модели с материалом «Системной инженерии» — это похожесть стратегии на язык паттернов/pattern language. Стратегия задаёт паттерн деятельности компании, поэтому язык паттернов вполне может быть той формой, в которой излагается эта модель:

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

Понятно, что такая «слайдовая» форма моделирования с табличкой на каждом слайде довольно легко представима в универсальных моделерах (типа notion.so, coda.io и т.д.).

Модель целеполагания/motivation для согласования интересов

Третья модель — целеполагания. Она используется для согласования интересов, то есть каким деятельностным ролям каких предпочтительных значений важных характеристик каких систем нужно добиться, какие практики для этого можно применить. Помним, что «целеполагание», «роли», «интересы» и «предметы интереса» — это понятия подхода goal-oriented requirements engineering, GORE (рассматривался в курсе системной инженерии), в котором основное внимание уделялось как раз нахождению ролей, которые добиваются удовлетворения своих противоположных предпочтений/interests в каких-то общих для них предметах интереса, а затем описание договорённостей по этому поводу.

В зарубежной литературе такие модели, описывающие противоположные интересы ролей и цели/goals, с которыми эти роли согласились, часто называются моделями целеполагания/motivation. В моделях целеполагания также включается и обоснование, почему люди выбирают какие-то определённые цели. Интересно, что в таких моделях не используют слово strategy, ибо оно часто зарезервировано за понятием плана работ по реализации стратегии.

Помним, что пелотон смены практик растягивается на десятки лет, не все успели перестроиться. И вот когда выясняется, что перед планированием (которое вы по-старинке называете стратегированием) нужно делать ещё что-то, указывающее на цели планирования, вы это называете motivation — то, что мотивирует на составление и выполнения плана (который вы по старинке называете стратегией).

Помним, что в менеджменте «стратегическое планирование» считается плохой практикой, которая не оправдалась — как раз планирование и считалось «стратегированием» (причём однократным!), а результирующий план — стратегией. Так что ещё с тех пор осталось много людей, для которых стратегия и план — синонимы! Хотя стратегия работает с практиками/деятельностями/способами работы, а планирование идёт работ/стадий/этапов (это должно быть понятно после курса методологии).

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

Примерами используемых в стратегировании моделей могут служить business motivation model (OMG BMM)⁸², ArchiMate motivation elements⁸³. Эти модели предполагают примерно тот же ход, который когда-то использовал Alexander Osterwalder: мощный формальный диаграммный («квадратики и стрелочки») язык моделирования, поддержанный специализированными компьютерными моделерами. Как мы помним, это было очень модно в первом десятилетии 21 века, а во втором десятилетии окончательно вышло из моды в негосударственных (где отсутствует заведомо излишнее финансирование за счёт бюджета) проектах в связи с появлением непрерывной разработки. Диаграммы очень плохо обновляются, поэтому первая версия их хоть как-то появляется, а вот развивать эти диаграммы (исправлять ошибки, перерабатывать структуру, вносить дополнительные детали) уже не удаётся. Выжили только те моделеры, где редактировать можно было не только представление модели диаграммой, но и текстовое представление модели (даже на формальных языках, но не визуальных, а текстовых) или табличное представление модели.

Вот метаУ-модель стратегических интересов (целеполагания):

Деятельностная роль — это для вас уже должно быть хорошо знакомо из курсов системного мышления, методологии, системной инженерии. Например, бизнесмен, инженер по безопасности (назовём его «безопасник»).
Предмет интереса/важная характеристика — например, затраты (в том числе затраты на безопасность системы). Это тоже подробно разбиралось в курсе системного мышления.
Интерес/предпочтение в значении важной характеристики — и это тоже знакомое понятие, тоже разбиралось в курсе системного мышления. Бизнесмен заинтересован уменьшать затраты, ибо это даёт прибыль. Безопасник заинтересован повышать затраты на безопасность, что даёт ему дополнительные ресурсы. Предмет интереса один, желания разные. Вредные предпочтения тоже указывать («кому война, а кому мать родна»).
Цель/желаемое состояние мира. Часто формулируется через глаголы, указывающие предпочтительное движение значений предметов интереса/важных характеристик. Например, «уменьшить затраты на создание системы, не уменьшая безопасность».
Принцип — берётся из дисциплины практики, используется какое-то самое важное положение, и ему даётся обоснование/rationale. Например, «Принцип унификации оборудования: цена резко падает при оптовых закупках, ремонты становятся проще, запчастей нужно меньше, плюс обоснование безопасности проще в силу её однообразия». Этот «принцип» — ключевой в моделировании, должен быть кратким изложением объяснительной теории.
Практика — практика, которую нужно поставить в организации, и которая позволяет воплотить указанный принцип (то есть из дисциплины которой взят принцип). Например, практика обязательного использования каталога предварительно одобренной номенклатуры оборудования («предпочтительные изделия», в какой-то мере это эквивалентно использованию предпочтительных чисел в технике⁸⁴ — вместо бесконечного разнообразия возможных значений используют только некоторые дискретные значения. Это существенно экономит на стандартизации инструментария. То же самое можно делать для стандартизации оборудования, хотя задача тут сложнее). И ещё практика ревизии проектов на предмет унификации оборудования.

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

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

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

Не ленитесь, не выпускайте каких-то объектов из этих цепочек, явно проговаривайте всё это рассуждение. Стратегирование должно приводить к абсолютно банальным понятным выводам, не должно быть ни малейшего дребезга в логических выводах. Вся эта цепочка от ролей через предметы их интереса и часто противоположные предпочтения к целям (общим для самых разных ролей), обязательное вытаскивание из какой-то дисциплины принципа, а затем и указание разных практик, реализующих этот принцип — вот это надо тщательно записать так, чтобы ни у кого не появилось ни малейшего сомнения в железной логике написанного.

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

Упражнения

Заполните табличку для модели целеполагания (описания стратегии, подчёркивающей обоснование постановки практики) в вашем рабочем проекте. Помним, что речь идёт о графе «рассуждений» (цепочек «внешняя проектная роль R имеет предпочтение P в предмете интереса C, это предпочтение реализуется целью G, которую можно достичь использованием принципа T, для чего нужно поставить практику A», и совсем необязательно представлять его табличкой (текстом на пару страничек может оказаться удобней. Табличка нужна только для тренировки соотнесения типов с высказываниями, поэтому в упражнении мы задействуем табличку. Но это особенная табличка, в ней представлен многоуровневый список, аутлайн).

Представьте от трёх стратегических рассуждений в табличном виде.

Номер рассуждения п/п	Деятельностная роль	Предмет интереса (concern)	Интерес/предпочтение	Цель	Принцип	Практика к постановке
1.
2.
3.

Заполните табличку модели оргразвития для вашего рабочего проекта, где каждая строчка соответствует одному узлу дерева, паре «целевое состояние — целевая практика» (верхний уровень, пара 0 — это миссия. Номера пар состояние-практика: первый уровень дерева: 1, 2, 3, …, второй уровень — 1.1., 1.2. и т.д., как обычно в аутлайнах или содержаниях (это обычное «дерево», как оглавление с главами, подразделами и т.д.). Во второй колонке указываем номер узла из первой колонки, в поддержку которой даётся данная пара. Помним, что пары вида «мир в крапинку — добиться мира в крапинку» писать нельзя, нужно указывать на способ того, как именно вы собираетесь добиться vision, mission не так просто формулируется, как «достичь vision» — принятие решения о способе достижения не откладывается на потом, на камушек в тумане не прыгаем.

Номер узла (пары «состояние-практика», строки в табличке)	В поддержку какого узла стратегии предложен данный узел	Целевое состояние мира (vision)	Обоснования vision: зачем нужно получить это состояние мира	Целевая практика/деятельность (mission)	Обоснования mission (почему эта mission приведёт к vision)	Рассмотренные, но отвергнутые варианты mission.	В случае принятия стратегии, что придётся прекратить делать
0	-

Культура съедает стратегию на завтрак, а реорганизацию на обед

Питер Друкер говорил, что «культура съедает стратегию на завтрак», дальше эту фразу дополнили: «культура съедает стратегию на завтрак, а трансформацию/реорганизацию/оргразвитие на обед»⁸⁵. Организационная культура как набор мемов, определяющий отношения сотрудничества, это предмет заботы лидера как подроли организатора:

Если культура бюрократична, то нового не дождётесь: будет бережно храниться всё старое, а новое не пробьётся через хорошо налаженную машину согласований, просто не будет вовремя согласовываться. Бюрократия — это очень хорошо для удержания текущей стратегии, но вот при смене стратегии (помним о непрерывном стратегировании) она вредна.
Если культура поэтична, новое утонет в броуновском движении. Всё, что может быть неправильно понятно, будет понято неправильно. Все метафоры и художественные образы будут «резиновыми», под них будут подводиться любые безумные идеи, стратегия-фильтр не сможет ничего отфильтровать. «Мы будем выпускать вот эти пробки для раковин, чтобы проложить ими дорогу к межпланетному будущему человечества», для поэта это абсолютно понятно и приемлемо!
Если культура экономна, то новое не получит финансирования, ибо на что тратятся деньги — это понятно, а вот на что их нужно будет потратить, обоснуйте получше (и это «получше» будет вечным, придраться ведь можно всегда: стратегия — это ведь всего лишь гипотеза, «когда будущее наступит, тогда и проверим, а пока посидите без денег, их у нас и так мало, рисковать не можем»).

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

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

В любом случае, стратегия (её очередной вариант) только старт большой организационной работы:

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

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

Так что непрерывное стратегирование требует соответствующей организационной культуры. Как в случае архитектуры важнейшей характеристикой оказалась evolvability, так и в организационной культуре должна быть признана полезность изменения стратегии, полезность отказа от меднолобой упёртости в достижении «стратегических планов», если всем уже очевидно, что они недостижимы («прыжок в воду вместо прыжка на stepping stone»), надлежащая работа лидеров по проведению стратегирования и разъяснению полученной стратегии, сотрудничество по проведению стратегических решений в жизнь (уважение к стратегии, принятие её всерьёз).

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

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

TEST Получение инвестиций

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

--- модель целеполагания ### Нет, модель целеполагания удобна для менеджеров, принимающих решения о шаге развития и обосновывающих его у собственника, но она не слишком удобна для инвестора, ибо а) не так привычна, как шаблон бизнес-стратегии (canvas) и б) не факт, что будет содержать информацию по финансам (собственно «бизнес-модель»: структуру выручки и структуру затрат).

--- модель оргразвития ### нет, эта форма хороша для менеджеров, планирующих шаг развития, но не слишком удобна для инвестора, ибо а) не так привычна, как шаблон бизнес-стратегии (canvas) и б) не факт, что будет содержать информацию по финансам (собственно «бизнес-модель»: структуру выручки и структуру затрат).

+++ какой-то «шаблон» (canvas) из серии «генератор бизнес-моделей» ### Да, это привычная для инвесторов форма обсуждения стратегии. Можно брать любой вариант, какой понравится: инвестор и сам задаст вопросы, если что-то ему будет непонятно. Это буквально чеклист для разговора именно с инвестором: в том числе вы не забудете поговорить не только о ваших шагах развития (ключевых практиках, ключевых партнёрах), но и о финансах, и о рынке.

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

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

--- надо было разрабатывать стратегию в рабочее время ### Нет, абсолютно неважно, когда разрабатываешь стратегии. Хорошая идея могла и присниться.

--- надо было разрабатывать стратегию самому, а друга-консультанта просить её только проверить. Чужие стратегии — это не стратегии. ### Нет, это только ухудшит ситуацию. Один человек может породить идею стратегии, но не стратегию.

+++ надо было разрабатывать стратегию всей фирмой ### Да, чем больше людей вовлечено в стратегирование («партисипативное стратегирование»), тем больше вероятность понимания стратегии и её последующей реализации после принятия.

+++ надо было как минимум, использовать стратегию в её организующей роли: её формулировки и обоснования должны быть известны всем. Просто выдать распоряжения по реализации — недостаточно. ### Да, верно. Без понимания стратегии распоряжения будут выполнены без понимания их приоритетности, взаимосвязанности, стратегической важности, без проявления какой-то инициативы.

+++ тут что-то не так: похоже на однократно выработанную стратегию, которая потом не будет меняться. ### Да, в тексте нет и намёка на постоянное стратегирование. Стратегия однократно разработана и должна вроде как быть реализована однократным выполнением набора распоряжений. Если на следующий день что-то пойдёт не так (а при указанном подходе всё пойдёт не так, например, мало кто бросится бегом выполнять распоряжения, в стратегии и в распоряжениях из-за их необсуждённости могут быть грубые ошибки, обстоятельства изменятся утром следующего дня, и т.д.), то непонятно что делать — опять звать друга, опять уговаривать совет директоров?

5. Теория стратегирования

Будущее уже здесь

Будущее уже здесь, только оно неравномерно распределено.

У.Гибсон

Сегодня к этому высказыванию добавляют «и ужасно дорого стоит». А когда цена на «товар/услугу из будущего» падает (часто в несколько раз за год — экспоненциальная зависимость), это будущее вдруг становится широко распространённым, то есть настоящим. А новое будущее опять уже здесь, и опять дорого стоит.

Будущее как туман: на расстоянии вытянутой руки всё прозрачно, а в трёх метрах может оказаться абсолютно невидимая стена. Метафора тумана для будущего была предложена одним из отцов современного искусственного интеллекта Geoffrey Hinton как вполне адекватная, туман ведь имеет экспоненциальную зависимость его прозрачности от расстояния⁸⁶, и это основная проблема для мышления людей о будущем: человек ожидает линейного развития ситуаций, но по отношению к будущему развитие идёт по экспоненциальным законам: совсем ничего, ничего, почти ничего, и вдруг ай-ай-ай сколько и сразу потом ой-ой-ой, уже всё!

Почему будущее так неопределённо? Почему нельзя выделить один какой-то ведущий тренд, и всё подробно и точно предсказать? Почему футурологи ничего не могут толком сказать?

В мире всё со всем связано неочевидным способом, мир целостен, он системен — части его взаимодействуют, и эти взаимодействия очень трудно предсказать, кроме того, что системы всё усложняются и усложняются. То говорили, что на орбиту выводят спутник — и каждый спутник был победой, а сегодня счёт уже идёт на «констелляции» спутников, спутников в них сотни и планируются десятки тысяч, проекты типа Starlink⁸⁷, OneWeb⁸⁸, СФЕРА⁸⁹. Возможности таких «констелляций» растут экспоненциально, если вырастают возможности ракет. Например, когда начнутся запуски спутников Starlink 2.0 при помощи Starship, то их длина может достигать 7 метров с антеннами в 5-6 метров. Эти огромные аппараты непосредственно смогут работать с сотовыми телефонами без дополнительных антенн, и это уже обсуждается с телефонными провайдерами⁹⁰.

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

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

Первый компьютер сделали на радиолампах в середине 20 века, хотя всё программирование уже было изобретено ещё Бэббиджем в середине 19 века⁹¹. Триоды пришли в компьютеры «сбоку», они совсем не для этого изобретались, изобретены были ещё в 1906 году⁹², но технология массового производства была отлажена много позже, результирующая дешевизна триодов появилась отнюдь не сразу.

Дешёвые триоды придумали использовать как элементную базу для логических цепей в компьютерах только в августе 1942 года, когда Джон Мокли⁹³ написал 7-страничный документ «The Use of High-Speed Vacuum Tube Devices for Calculation», в котором предлагал Электротехнической школе Мура (подразделение Пенсильванского университета) построить электронную вычислительную машину, основанную на электронных лампах. Руководство Школы работу не оценило и сдало документ в архив, где он вообще был утерян.

В апреле 1943 года Мокли по памяти восстановил документ уже для Баллистической лаборатории, он был одобрен. В проекте машина называлась «электронный дифф. анализатор» (electronic diff. analyzer). Это была уловка, чтобы новизна проекта не вызвала отторжения у военных. Все они были уже знакомы с дифференциальным анализатором, и проект в их представлении просто предлагал сделать его не механическим, а электрическим. Проект обещал, что построенный компьютер будет вычислять одну траекторию за 5 минут. Военные сказали «ОК», и выделили деньги: $61700 на первые 6 месяцев исследовательских работ. В контракте под номером W-670-ORD-4926, заключенном 5 июня 1943 года, машина называлась «Electronic Numerical Integrator» («Электронный числовой интегратор»), позднее к названию было добавлено «and Computer» («и компьютер»), в результате чего получилась знаменитая аббревиатура первого в мире универсального (то есть программируемого на самые разные вычисления) электронного компьютера ENIAC⁹⁴. Абсолютно засекреченный компьютер был полностью готов лишь осенью 1945 года, а первыми его программистами стали шесть девушек⁹⁵.

Такая витиеватая последовательность событий в начале, середине, конце (в любом месте!) технологических революций типична. Будущее непредсказуемо: ни содержание изобретения электронного компьютера, ни время изобретения, ни место изобретения — предсказать это всё было невозможно, хотя все необходимые для изобретения компьютера идеи были хорошо известны. Зато можно было предсказать, что дальше события развивались не линейно в части скорости распространения, а экспоненциально: разработка ENIAC на вакуумных радиолампах дала старт компьютерной революции, далее компьютерная революция следовала уже экспоненциальным, «революционным» законам.

Электронные вычислительные машины оказались быстры и надёжны, в отличие от механических, пневматических и даже электрических (реле) вычислителей. Вычисления от электронных ламп перешли к транзисторам, потом к транзисторным микросхемам, а сейчас вы уже можете купить и квантовый компьютер (прямо через облако, не выходя из дома, у более чем дюжины провайдеров⁹⁶), и оптические вычисления (оптический компьютер можно купить было ещё в 2021 году, хотя не все даже профессионалы знают об этом⁹⁷). Обещание вычисления одной баллистической траектории за 5 минут кажется милым и наивным, сегодня такой счёт шел бы микросекунды, но начиналось всё именно так: это было запредельно круто для 1943 года!

Будущее как бы растягивается на некоторое время:

Оно сначала очень долго невозможно в принципе. Функция чего-то нового уже обсуждается, но конструкция ещё непонятна. Это «знаем что, но не знаем как» может длиться сотни лет, а то и тысячи (летать-то людям хотелось давно! А сумели это осуществить не так давно. Кстати, между первым полётом братьев Райт и полётом человека на Луну прошло всего 60 лет, тут тоже была экспонента). Скажем, машинный интеллект казался невозможно далёким будущим (а многим и сейчас таким кажется, хотя с его применениями люди сталкиваются ежедневно: ожидается появление «человекоподобного искусственного существа», которого никогда и не будет — машинный интеллект просто приходит в неожиданных формах).
Затем это «будущее-в-настоящем» очень дорого стоит и его немного, то есть оно недоступно для большинства. Скажем, искусственный интеллект ещё в начале 2012 в общественном мнении был невозможным за любые деньги. Но в конце 2012 года (после победы нейронных сетей в соревновании распознавания изображений ImageNet Challenge⁹⁸) уже было понятно, что с машинным интеллектом всё в порядке, и развитие будет быстрым. Но стоимость машинного интеллекта высокого качества (это «высокое качество» всегда будет недосягаемым для большинства, как бы ни был умён дешёвый доступный всем интеллект, всегда будет хотеться иметь для себя самого умного машинного агента) даже сегодня запредельно высока⁹⁹. Очень немногие компании могут себе позволить с ним работать «на фронтире», хотя эксперименты с уже имеющимся интеллектом всегда будут относительно дешевы (вырастить и хорошо обучить мудрого человека – очень дорого, а вот задать ему вопрос или подучить какой-то одной новой практике – это обычно дёшево!).
Наконец, оно становится уже настоящим и повсеместным, «не будущим». Новые технологии (то самое «будущее») стоят дёшево, это не роскошь. Машинный интеллект, понимающий команды с микрофона уже обыден, все разговаривают со своими телефонами и даже не удивляются, что телефон отвечает не жестяным голосом робота, а нормальным голосом с человеческими интонациями, да ещё показывает картинку говорящего с вами никогда не существовавшего человека, робота-аватара. Будущим считают уже что-то другое, а не эту повседневность, которая ещё вчера была далёкой мечтой. Будущее — как стена тумана, отходящая с каждым шагом. Как горизонт, ускользающий при быстром к нему движении.

До сих пор принято мечтать о том, что будет в 21 веке — в будущем. Но мы давно уже в этом будущем, уже прошла почти четверть 21 века!

Подрыв подо всей цивилизацией сразу

Disruption technologies принято переводить как подрывные технологии¹⁰⁰ — это такие технологии, которые закрывают одни отрасли и открывают другие. Типичная такая цепочка — это телеграф, который был подорван технологией проводного телефона, который был подорван технологией сотового телефона, который был подорван технологией смартфона, и дальше через чаты происходит возврат к телеграфу, а звонки всё больше групповые видеозвонки. Виниловые пластинки стали CD-дисками, а потом и вовсе превратились в сетевые музыкальные сервисы. Гибкие магнитные диски появились, уступили место «флешкам» буквально на несколько лет, а затем и флешки исчезли из употребления, данные передаются через облачные сервисы.

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

Кто помнит извозчиков? Буквально за 13 лет с 1900 по 1913 год гужевой транспорт в Нью-Йорке был заменён автоперевозками, с чего Tony Seba и начинает свою серию презентаций в 2014 году¹⁰¹, которую потом он повторял и уточнял вплоть до 2020 года, когда тренд с электромобилями стал уже всем очевиден¹⁰². Но это в мегаполисе, в Нью-Йорке. А в целом по США с 1910 по 1920 всего за десять лет доля пассажиро-километров на автомобилях была поднята с 11% до 81%. Для этого была построена автомобильная промышленность, развёрнуты производство бензина и сеть автозаправок — и это в то время, когда страна отвлекала ресурсы на участие в первой мировой войне.

Лучшая на сегодня бизнес-теория техно-эволюции (то есть объяснение «где деньги во всём этом бурном прогрессе») создана Tony Seba. Вам нужно просмотреть его короткие видео, которые вышли в конце 2022 года¹⁰³, и дальше обратиться к его книгам (они упоминаются в этих видео, хотя не ожидайте там какого-то очень точного рассказа: как бы ни был прозорлив Tony Seba, предсказать будущее не может и он, тем более что затронуты оказываются все сферы жизни).

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

Можно ли назвать занятость, приходящую и уходящую на несколько лет «профессией»? Нет, нельзя. Это просто «занятость», практикование какого-то мастерства. В долгой жизни можно стать мастером во многих деятельностях, но необязательно каждый вид своего мастерства называть «профессией». То же самое относится и к фирмам, ни одна фирма не может гарантировать себе «профессию» и позицию на рынке на долгие годы. С июня по ноябрь 2022 Amazon потеряла один триллион долларов в капитализации. Microsoft недалеко ушла, потеря примерно $0.9 триллиона. Всего 5 крупнейших технологических компаний США потеряли вместе четыре триллиона долларов¹⁰⁴. Это больше, чем совокупный ВВП Турции, Аргентины и Швейцарии. У лидирующей социальной сети была капитализация больше триллиона долларов, компания входила в первую пятёрку компаний мира по своей капитализации, а теперь не входит даже в верхние 20, капитализация всего $270 миллиардов (немало, но 16 месяцев назад это было чуть ли не вчетверо больше)¹⁰⁵.

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

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

Ничего линейного в будущем нет, это цепочка «неожиданных» (на самом деле вы должны это ожидать!) экспоненциальных подрывов — и в каждом таком подрыве есть период с «ничего вроде не происходит» с последующим периодом «неожиданно всё стремительно». Вкладываться в устаревшую технологию становится неправильно по чисто экономическим соображениям, и происходит шаг развития — переход к новой технологии, у которой совершенно другой потенциал развития. Это и есть большой техно-эволюционный переход (major techno-evolutionary transition), причём всё происходит быстро за счёт того, что мемом (информационные модели технологий, сегодня ведь даже бумажных чертежей нет, а только информационные модели, по которым непосредственно и часто в автоматическом режиме изготавливается огромное число воплощений описанных систем с определяемым этим мемомом феномом) отделён от целевой системы, и в нём идут умные мутации, а не происходит медленная дарвиновская биологическая эволюция.

Главное тут то, что самые разные «экспоненциальные технологии», каждая с каким-то своим «законом» (то есть коэффициентом к экспоненте, чаще всего этот «закон» называют по имени инженера, определившего этот коэффициент) кратного падения цены за год складываются вместе в одной результирующей технологии, и в этот момент начинается подрыв: эта технология стремительно распространяется, её использование в силу дешевизны вырастает кратно в год.

На картинке показана скорость распространения новых технологий. Видно, что чем позже появляется технология, тем быстрей она распространяется. Первый успешный смартфон (iPhone) появился в 2007 году, чуть больше пятнадцати лет назад. Первый планшет (iPad) — в 2010 году, чуть больше десятка лет назад.

Почему iPhone появился в 2007 году и имел сразу такой успех? Потому что в этом продукте сошлись множество других экспоненциальных технологий: экспоненциально падала стоимость транзистора в чипе (закон Мура), бита во внешней памяти (закон Кридера), числа пикселей в матрице камеры (закон Хенди), передачи данных (закон Баттера), а ещё сенсорный экран, литий-ионные аккумуляторы, GPS и датчики акселерометра. И когда всё это стало достаточно дешёвым и слиплось в один продукт за $600, он «взлетел». Помним, что Apple пыталась запустить до iPhone абсолютно инновационный наладонный компьютер Newton, это был 1993 год¹⁰⁶. И ничего не получилось: технологии были ещё не готовы, они уже все были в наличии, но слишком дорого стоили. И речь идёт о продуктах, в которых этих разных стремительно дешевеющих технологий много. В какой-то момент цена самых разных составляющих падает в разы, стоимость самого сложного продукта падает (неожиданно для всех) в разы — и он мгновенно разлетается по планете.

Через пару лет после появления смартфона в 2009 году появился Uber, он предложил бизнес-модель заказа такси с использованием смартфона и облачных вычислений, и через 7 лет (в 2016 году) число заказов через Uber стало больше, чем во всех таксомоторных парках США. Через 8 лет (в 2017 году) Uber и Lyft с начального нуля получили 20% от всего объёма перевозок (в милях) в таких городах, как Сан-Франциско и Нью-Йорк. А в декабре 2020 Uber продал своё подразделение автопилотируемых автомобилей¹⁰⁷ — там уже несколько лет ожидалось экспоненциальное развитие, но его не случилось! Самоуправляемые/беспилотные/автономные автомобили находятся пока на начальной стадии S-образной кривой. А потом? А потом, через несколько лет будет традиционное — «ах, когда же это всё успело произойти?!». Разговоры вдруг станут реальностью, и ключевое тут будет слово «вдруг», ведь роботакси без водителя уже доступны широкой публике¹⁰⁸.

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

Никакие эксперты не в состоянии предсказать будущее: каждая из технологий неочевидным образом снижает цены и делает доступными огромному количеству людей те технологии, в состав которых они входят. А если и не снижается цена, то при той же цене можно получить характеристику в разы лучше. Пять лет назад за $2000 можно было купить ноутбук с 8Gb памяти, 4 ядрами процессора и FullHD дисплеем. Сегодня за ту же сумму можно купить ноутбук с 32Gb памяти, 8 ядрами процессора и 4К дисплеем. И ещё там будет 1Tb твёрдотельный «диск» (который уже давно не диск!). Такие ноутбуки, какие были 5 лет назад, стоят $1000, вдвое дешевле, а то и меньше. «Вдвое за пару лет» гласит закон Мура по поводу числа транзисторов на микросхеме — это начальник службы исследований и разработки компании Fairchild Semiconductor Гордон Мур сформулировал ещё в 1975 году, он предположил тогда, что так будет ещё лет десять. Но это было 46 лет назад! Сейчас скорость падения цены по закону Мура немного уменьшилась, но закон до сих пор продолжает действовать. И даже «вдвое за четыре года» вместо «вдвое за два года» — это тоже экспонента, и это тоже очень быстро!

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

Быстрое распространение подрывных технологий можно очень приблизительно разделить на следующие стадии¹⁰⁹:

стандартизация (standardization, возникновение промышленных стандартов, позволяющих организовать встраивание новой технологии во внешние системы). Если вы обнаружили перспективную технологию, в которой ещё нет стандартов, то вам повезло: вы близки к началу её распространения.
удобство использования (usability, обеспечение удобного интерфейса к технологии, иногда речь идёт о «ключевом приложении», killer application)
переход в массовое потребление (сonsumerization)
переход в инфраструктуру (foundationalization, «изо всех утюгов», «потребление незаметно»).

В компьютерах сначала появились открытые архитектуры (стандартизация), затем графические интерфейсы (удобство использования), потом они стали потребительским товаром (iPhone и магазин приложений), а теперь основной компьютинг идёт вообще в инфраструктурных организациях — дата-центрах. Интернет начался со стандарта HTML (стандартизация), затем появилось удобное его использование (разделение оформления и содержания страниц через стилевые описания CSS), затем появились социальные сети, а сейчас по факту интернет стал основой для большинства рабочих, промышленных и торговых коммуникаций. В AI стандарты уже появились (например, ONNX¹¹⁰), удобство использования — это голосовые и чат-интерфейсы, это пока только появляется, так что ещё ждём перехода к массовому использованию (по аналогии с интернетом это может быть ситуация, в которой AI создаются самими пользователями, а не специалистами), и некоторое время ещё нужно ждать до инфраструктурности.

Эти все этапы довольно быстро пробегаются самыми разными технологиями.

Пример подрыва: электромобили уже сейчас дешевле бензиновых автомобилей

В своих презентациях (например, по транспорту 22 апреля 2020 года¹¹¹) Tony Seba рассказывает, что по итогам «чистого подрыва» с 2025 года все новые автомобили будут электрическими, и, несмотря на замедление прогресса из-за пандемии и связанной с войной и финансовой политикой инфляции, этот прогноз вполне может сбыться. Jensen Huang (CEO компании NVIDIA) выпустил в 2021 году автомобильный компьютер Orin (по факту это стандартизация автомобильного компьютинга), который может обеспечить необходимую вычислительную мощность для полностью автономного (роботакси, высший уровень автономности 5) безопасного вождения, в 2022 году на его основе уже будут выпускаться автомобили¹¹². Новые электромобили будут беспилотными, им не потребуются водители. Удобство использования технологии нейронных сетей: автомобиль без водителя как ключевое приложение.

Уже сегодня несколько китайских производителей имеют электромобили со стоимостью до $30тыс. при батарее с дальностью поездки от 300 километров. В 2021 году стоимость бензинового и электрического автомобилей из расчёта жизненного цикла на километр пробега сравнялись. Переход на электромобили стал чисто экономическим решением, например в расчёте на три года владения автомобилем и 12 тыс. миль пробега ежегодно в UK нужно платить за электромобиль 67 пенсов за милю, а за бензиновый автомобиль 74 пенса за милю, это уже сегодня¹¹³. Через пару лет разница будет настолько ощутима, что бензиновые автомобили просто перестанут покупать даже «по привычке» (при этом учитываем, что затраты на разные виды автомобилей никто не считает! Смотрят на совсем другие факторы, но эти факторы учитываются в конечном итоге в цене).

А дальше будут нелинейные эффекты от сочетания быстро проходящих свои стадии развития технологий: обычный легковой автомобиль 96% времени простаивает, и только 4% времени находится в движении. Автономный электромобиль, предоставляемый как сервис по вызову такси, будет в работе весь день. Иметь собственный автомобиль станет невыгодным. Стоимость поездки резко упадёт, и можно будет покупать абонемент на поездки за цену существенно меньшую, чем стоимость обслуживания и страховки собственного автомобиля. Это уже происходит с сервисами car sharing (аренда автомобиля на одну поездку, при этом ты сам его ведёшь) в крупных городах.

Меньше автомобилей обслужат больше жителей, и они не будут долго стоять. 80% парковочного места освободятся. Они экономичны, и нефти для автомобилей потребуется меньше, цена нефти резко упадёт, этому помогает ещё и солнечная энергетика плюс наличие дешёвых аккумуляторных батарей (а дешевизна аккумуляторов объясняется в том числе и тем, что они нужны прежде всего для электромобилей, но и их с удовольствием используют и для солнечных и ветровых электростанций).

Там будет и много других чудесных следствий — но тут главное в скорости, с какой изменится мир уже в ближайшее время. Точка перегиба S-образной кривой автономного электротранспорта на быстрый взлёт уже была — это 2021 год, до этого момента изменения были практически незаметны, а после — неизбежно стремительны, и всяческие «энергокризисы» этому будут только способствовать. В 2030 году автомобили с бензиновым двигателем будут как гужевой транспорт в 1930 году. Для этого не хватает только инфраструктуры «электрозаправок», но она появляется очень быстро, у всех ведущих автопроизводителей есть планы на этот счёт. Как понять, что происходит? Вот отчёт о продажах автомобилей за 9 месяцев 2022: у всех лидеров рынка традиционных автомобилей идёт падение продаж на 5-16%, у лидеров рынка электромобилей идёт рост продаж (у BYD на 165%, а у Tesla на 56%). Пока BYD занимает на этом рынке 13 место по объёму продаж, а Tesla — 15 место в мире. Но при таком тренде ситуация с электромобилями изменится очень быстро.

Переход на электромобили — это не единственный тренд, который изменит городской транспорт. Удалённая работа больше не считается чем-то неправильным (и дело тут даже не в экспериментах на живых людях, которые провели правительства всех стран в 2020 году, пандемия ковида просто немного ускорила ход событий в этой сфере). Сервисы доставки продемонстрировали, что они реально экономят время на походы в магазины, а доставка необязательно через пять лет будет делаться людьми. Конечно, возврат людей в «оффлайн» на рабочие места и магазины происходит, но это не будет возврат к старому состоянию.

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

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

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

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

TEST Технологический подрыв

!!!Есть знаменитые задачи, которые стоят перед разработчиками много лет. Отметьте те из них, которые были решены ещё до 2021 года:

+++ программа пишет новостную заметку так же хорошо, как человек — люди не могут отличить компьютерные заметки от человеческих ### Да, это ещё в 2020 году делала нейронная сеть GPT-3, https://arxiv.org/abs/2005.14165

+++ программа пишет краткое содержание статьи так же хорошо, как человек ### Да, это ещё в 2020 году делал алгоритм PEGASUS, https://ai.googleblog.com/2020/06/pegasus-state-of-art-model-for.html

+++ компьютер сдал экзамен ЕГЭ по русскому языку по официальным правилам без исключений на проходной балл в университет ### Да, это было сделано ещё в 2019 году — https://rg.ru/2019/11/09/iskusstvennyj-intellekt-sdal-ege-po-russkomu-iazyku.html

+++ батарея электромобиля имеет запас зарядок на два миллиона километров (16 лет беспрерывного заряда/разряда) ### Да, ещё в 2020 это сделала компания Contemporary Amperex Technology Co.Ltd., запаса прочности батарей хватит для того, чтобы совершить кругосветное путешествие 50 раз — https://www.bbc.com/news/technology-52966178

+++ больше десятка человек гуляло по поверхности Луны ### Да, это было совершено ещё к 1972 году, по самой Луне гуляло 12 человек, а на орбите Луны было даже 24 человека (1969-1972, программа США Apollo — https://en.wikipedia.org/wiki/Apollo_program)

Задания

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

Прочитаны материалы о многоуровневой стратегии NVIDIA — https://ailev.livejournal.com/1561799.html, опубликованы собственные мысли.
Изучены многоуровневые стратегии электроавтомобилей по материалам Battery (Tesla) и Power (Volkswagen, https://www.forbes.com/sites/jamesmorris/2021/03/20/power-day-volkswagens-imitation-of-tesla-is-the-sincerest-form-of-flattery/) Days. Электромобильные компании устроили эти дни обсуждения roadmap одного из нижних системных уровней автомобиля — аккумуляторных батарей, причём с попыткой трассировать характеристики электромобиля не только к батарее в целом, но и к частям самой батареи (анод, катод, электролит, корпус — это всё есть в презентации Volkswagen, https://www.volkswagenag.com/presence/konzern/power-day/Powerday_Chart-183.pdf), а также с целью предъявить публике выход на уровень окружения (уровень выше автомобиля), например, предъявить планы по росту числа быстрых зарядок на дорожной сети. Многоуровневость: внимание к развитию частей целевой системы и развитию систем в окружении, если без них нельзя (NVIDIA уже в 2017 году говорила, что для тех же роботакси она не может продать им просто голые чипы, а нужно демонстрировать полный технологический стек, на много уровней выше чипов — https://ailev.livejournal.com/1384766.html. В статье Forbes по первой ссылке из текущего пункта задания говорится: «Toyota’s emphasis on Hydrogen Fuel Cells might have fared better if the company had invested in refueling stations rather than leaving that up to other companies. Volkswagen isn’t making this mistake and is putting serious money into solving the charging infrastructure problem». Многоуровневость, абсолютно разные задачи на каждом системном уровне. В Volkswagen для уровня той же батареи отмечали, что идти нужно и за пределы традиционно понимаемого жизненного цикла — и можно обнаружить, что ключевые интервенции развития нужно делать там, слайды 51 и 52 презентации Volkswagen как раз кривоватые слайды про жизненный цикл. Опубликованы ваши собственные мысли по поводу многоуровневых стратегий технологического предпринимательства.
Написано эссе о том, какие новинки появились на разных системных уровнях продукта вашего текущего рабочего проекта (как самого продукта, так и его частей на несколько уровней вверх, так и уровня окружения). В эссе отражены ваши рыночные перспективы в связи с этими изменениями. Когда вы ожидаете прихода этих изменений? Какие действия вы предпринимаете, чтобы быть к этим изменениям готовыми?
Отсмотрены свежие видео на странице Tony Seba, https://www.youtube.com/user/tonyseba/videos, прочитаны свежие записи в блоге его фирмы RethinkX https://rethinkdisruption.com/. Опубликованы посты с собственными мыслями по поводу материалов Tony Seba и RethinkX.

Роботы заберут работу? Нет!

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

Tony Seba особо отмечает, что развитие машинного интеллекта не экспоненциально, а гиперэкспоненциально. Похоже, что он прав. Использован машинный интеллект может быть так же, как и любой человеческий интеллект: везде, где используется интеллект людей. Интеллект универсален, нет закрытых от него сфер. Как эта гиперэкспоненциальная подрывная технология повлияет на мир, предсказать нельзя — как нельзя предсказать, как именно повлияет на мир интеллект естественный. Это покрыто туманом будущего.

Изменения в мире произойдут стремительно. В древнем отчёте 2017 года от McKinsey в 2030 году ожидалось, что 400-800 млн. нынешних рабочих мест будут автоматизированы, труд на этих местах существенно изменится (читай: «исчезнет в его текущем виде»). Как раз о таких отчётах Tony Seba предупреждает в своих презентациях и книгах: они недооценивают масштабы перемен в разы из-за неучёта экспоненциального характера затрагиваемых ими технологий. Автоматизация к 2030 году коснётся миллиардов рабочих мест, хотя в мире население всего 8 млрд. человек. Помним, что в телефоны у миллиардов людей в кармане никто тоже не верил, в интернет у миллиардов людей в кармане тоже никто не верил, в автоматизацию труда миллиардов людей пока тоже не верят, а зря. То, что сейчас говорят «цифровая трансформация», а иногда и «гиперавтоматизация», ничего не меняет: это всё маркетинговые замены термина, но суть дела остаётся: человеческий труд повсеместно заменяется машинным, как физический труд, так и умственный.

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

Почему применяют роботов, а не людей? Часто не потому, что роботы не болеют, не уходят в отпуск, не спят, а работают быстрее. Нет, роботы работают лучше, чем люди — часто настолько лучше, что делают недостижимое людьми (быстрее, точнее, меньше ошибок), плюс меньше отвлечений при решении рутинных задач и отсутствует время для отдыха. Это как замена землекопов экскаваторами, только в качестве землекопов выступают люди самых разных профессий.

Так, с января 2019 в Walmart вместо уборщиков вышли 360 роботов фирмы BrainOS, в апреле к ним добавили ещё 1500. Эти роботы убирают лучше и быстрее, управляя обычными уборочными машинами, плюс их не нужно часто нанимать и дополнительно учить (среди уборщиков в год меняется от 30% до 100% персонала. И всех этих новеньких нужно найти, нанять, обучить — с роботами этого не нужно, их покупка, ввод в эксплуатацию и настройка занимают меньше времени). Чтобы покупатели не катались на этих машинах, место водителя на них отгораживают жёлтыми ленточками¹¹⁴. А ещё 600 роботов BrainOS в 2022 вышли на работу по сканированию товарной выкладки¹¹⁵. Всего только на этой платформе роботов на конец 2022 года выпущено было 26 тысяч роботов, которые проработали 9 миллионов часов в автономном (без участия человека) режиме¹¹⁶. Если считать, что один робот заменяет одного человека (что не совсем так), то это небольшой городок. А ведь речь идёт только об одной робототехнической фирме!

И это даже не единственное использование роботов в магазинах, сами магазины становятся роботами (из них исчезают в том числе и кассиры, контролем наличия товара на полках занимаются роботы, и всё остальное тоже переходит к роботам)¹¹⁷.

Это нормально, этого не нужно бояться. Ещё недавно 90% людей были заняты сельским хозяйством, а сегодня — именно благодаря машинам — осталось всего 3% «крестьян» (хотя работников современных ферм меньше можно назвать «крестьянами», они больше похожи на заводских работников по стилю их жизни и виду занятий). Несмотря на это, все высвободившиеся из сельского хозяйства люди оказались заняты, даже с учётом того, что число людей на Земле сильно подросло! Более того, и пролетариата, заводских рабочих, сегодня тоже не так много, как ещё полвека назад! А бедность, тем не менее, существенно в планетарных масштабах уменьшилась.

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

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

Этот тренд на сокращение рабочих часов для нормальной жизни проявляется и в росте свободной занятости (freelance, gig economy, platform economy¹¹⁸) с использованием для поиска работы онлайн-платформ для самых разных видов мастерства. Есть даже платформы для оплаты меценатами чьих-то хобби (patronization). Если ты мастер в каком-то хобби, то тебе за это могут заплатить! Хобби и работа постепенно теряют чёткую границу между ними, спорт (демонстрация того, что человек не утратил качества обезьяны — быстро бегает, хорошо дерётся, далеко кидает тяжёлые предметы, умеет командой загнать никому не нужный мяч в ворота при противодействии другой команды, и т.д.) стал для профессиональных спортсменов работой, а для миллиардов людей развлечением — вместо чтения книг, просмотра художественных фильмов или хотя бы какой-то физической активности (бег трусцой, танцы). Киберспорт продолжает эту традицию и тоже стремительно профессионализуется. Шоу-бизнес — это тоже бизнес, это не художественная самодеятельность, это серьёзные деньги. Праздной публике в Риме, как мы помним, нужно было хлеба и зрелищ, игнорировать это нельзя. Чем больше избыток хлеба, тем (при отрицательной полезности труда, помним об этом!) больше желание развлечений — и избыток средств люди будут тратить на это.

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

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

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

Инновации: всегда сбоку

Проблема с непредсказуемостью будущего в том, что все подрывные инновации приходят не из тех отраслей, где они появляются — поэтому-то их и невозможно предвидеть. Микроволновку изобрели спецы по радарам, а не производители мясорубок и холодильников. Компьютер на радиолампах радиоэлектронщики, а не математики. Самолёт — владельцы мотоциклетной мастерской братья Райт¹¹⁹. Роботами-юристами начали торговать в России провайдеры сотовой связи МТС и Мегафон¹²⁰. Рынок такси взрывает не только Uber, но в России это Яндекс.такси (в России Uber и Яндекс уже слились вместе)¹²¹. Сбербанк уже торгует музыкой¹²², и он уже не «банк», а просто «Сбер».

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

Экспоненциальные технологии делают эти подрывы стремительными. Вот пример вычислительной оптики:

На рисунке¹²³ один из снимков сделан в сентябре 2016 году смартфоном iPhone 7 Plus, а другой — камерой-зеркалкой с большим объективом EOS650D. Вы можете угадать, какой снимок чем был сделан? Левый — смартфоном, правый — зеркалкой.

До сентября 2016 года было принято считать, что позиции производителей больших фотоаппаратов хорошо защищены законами физики: эффект bokeh¹²⁴ красивого размытия фона при чёткой фигуре на переднем плане мог проявляться только на фотоаппаратах с большими объективами.

Apple пришёл на фоторынок, где его никто не ждал, принёс вычислительную оптику, а не большой объектив. Экспоненциальные технологии сделали дешёвыми процессоры и маленькую точную механику — потребовалось две дешёвые маленькие камеры, а не один большой дорогой объектив. На улице 2016 года тем временем соревновались хипстеры: у кого фотоаппарат больше, тот и победил в качестве снимков!

Дальше всё быстро: эффект bokeh в сентябре 2016 года был продемонстрирован на двух камерах iPhone 7 Plus, но уже в сентябре 2018 года цена опять упала, AI даёт тот же эффект на одном сенсоре — Google Pixel 2 series, Apple iPhone XR. Да ещё и телефоны с 3-5 камерами стали обыденными. Потребность в фотоаппаратах стала нишевой (и эта история произошла уже после того, как цифровая фотография вытеснила плёночную), продажи фотоаппаратов (включая цифровые) идут уже на уровне 1977 года, причём эти цифры падают¹²⁵.

И это было не последней точкой в удешевлении. Во время перехода на удалённую работу практически все сервисы видеоконференций предоставили возможность не только размыть фон, но и вовсе его заменить. Речь идёт уже о супердешёвых веб-камерах на ноутбуках и в компьютерах, и не о неподвижных картинках, а о видео, и ещё об универсальных процессорах. Экспоненциальные технологии делают своё дело: что было диковинкой на самых дорогих моделях телефонов в 2017 году, стало дешёвым общим местом везде. Заодно люди, которые до этой технологии стеснялись своей домашней обстановки, просто перестали её показывать, они заменили её на выбранный ими фон — и сэкономили на интерьере. Наоборот, показать крутую домашнюю обстановку стало привилегией богатых! Повторяется история с нейлоновыми рубашками: сначала их носили только самые богатые, а затем их стали носить только самые бедные. Такое типично для экспоненциальных технологий.

Вычислительная оптика также помогла к 2021 году разобраться со съёмкой смартфонами в темноте, в том числе и съёмкой видео высокого разрешения и повышенным контрастом. Нужда в больших и дорогих фото- и видеокамерах с особыми их возможностями резко упала. Tony Seba приводит хорошие примеры, почему прогнозы не оправдываются. Они не учитывают экспоненциальных зависимостей! Пару десятков лет назад точно такой же переход шёл от плёночной фотографии к цифровой — и всё началось и закончилось за пяток лет. С фотоаппаратами как таковыми происходит всё то же самое.

Производители смартфонов, а теперь и производители ноутбуков пришли в сферу фотографии «сбоку» и буквально за несколько лет дали доступ к качественному фото и видео для практически всех жителей планеты. Это дало возможность необычным применениям фото: контроль качества работы удалёнными сотрудниками (они фотографируют результаты своей работы, это практически бесплатно), платёж по карте, когда не нужно вводить её номер, а он распознаётся автоматически, платежи по штрих-кодам и QR-кодам, автоматизация переводов надписей на иностранных языках, прокторинг для онлайн-сдачи экзаменов. Идут пробы новых применений, например было массовое увлечение играми типа Pokemon Go, где изображение покемонов накладывается на изображение реального мира, но широкого распространения это не получило. Тем не мене, представьте, сколько людей приложили свои знания и умения, участвуя в этих изменениях. А ведь это только один из небольших сюжетов происходящих перемен! Фотография, бывшая уделом немногих, превратилось в видеографию, доступную практически всем. У каждого видеокамера в кармане, и даже не одна (в смартфоне есть и камера для селфи, и камера для съемки, и встроенный микрофон для записи звука на видео, и можно сделать «захват экрана» для видео происходящего на экране). К этому добавьте возможности нейрохудожников, сервисы по изготовлению персонализированных аватаров для социальных систем.

Но и это ещё не конец истории про «физика не позволит сделать объектив меньше»! В 2021 году физиками был предложен новый оптический элемент: «пространственная пластина», которая позволяет убрать пространство между линзой и матрицей. Если заменить линзу плоской металинзой, а необходимое пространство за этой линзой заменить пространственной пластиной, то можно сделать реально плоский объектив. Как пишут изобретатели, вполне можно всю заднюю стенку смартфона превратить в объектив, получив в 14 раз лучше разрешение и чувствительность при съемках в темноте, чем у больших фотоаппаратов с большими объективами¹²⁶.

Say goodbye to your camera bump: uOttawa researchers miniaturize optics by discovering counterpart to lens

Если перейти на подобную оптику, то можно получить плоские телескопы, плоские микроскопы, и никаких утолщений для камер на задней панели смартфонов. И это тоже приходит сбоку, производители телескопов и микроскопов никак не ожидают (предыдущий тип оптического элемента «линза» был предложен 400 лет назад, и с тех пор не было новинок — до 2021 года!), что подобная новинка появилась не от конкурирующих производителей телескопов и микроскопов. Изобретатели этой технологии пришли из лаборатории квантовой оптики, а завод-производитель пространственных пластин будет не заводом оптического оборудования с парком шлифующих стёкла станков, а заводом нанометаматериалов с абсолютно другим оборудованием!

Когда речь идёт об информационных технологиях, всё происходит ещё быстрее и неожиданней. На удалённую работу даже там, где это было нельзя себе представить, мир перетянулся разве что не за пару месяцев. MS Teams как средство удалённой работы (отнюдь не все пользуются Zoom) поднял пользовательскую базу с 0 до 18 миллионов человек за два года, а потом за три месяца пандемии дорастил её до 77 миллионов человек. Ещё через год в MS Teams было уже 145 млн. человек¹²⁷. Много фирм буквально за пару месяцев начала пандемии сообразили, что дорогой офис — это не преимущество, а недостаток. И начали нанимать сотрудников по всему миру, а не только проживающих недалеко от офиса. Это означает, что рынок офисной недвижимости был по факту подорван софтверными фирмами, обеспечивающими сервисы удалённой работы¹²⁸, беда пришла «сбоку».

Мир меняется от принципиально непредсказуемых факторов. Вы не можете предсказать изобретения 8 миллиардов человек (хотя в реальности немного меньше, вычтите детей и необразованное население отсталых стран). В том числе и «антиизобретения» законодателей, типа пандемических локдаунов как неконституционно вводимых ограничений на передвижение, или запрета каких-то вычислений типа вычислений для криптовалютного рынка или вычислений для показа вебсайта кем-то запрещённой социальной сети. Вы не можете предсказать войну. Эти непредсказуемые изменения распространяются по земному шару крайне быстро — речь идёт об экспоненциальных, и даже гиперэкспоненциальных изменениях, у которых нет единого руководящего центра. Это техно-эволюция.

Примеры мы привели главным образом из производства, но примерно то же самое творится в науке. Современная лингвистика была закрыта буквально за несколько лет: много лет нарабатываемые лингвистами языковые модели оказались менее точными, и менее полезными на практике, чем языковые модели на основе нейронных сетей — и делали их отнюдь не лингвисты, а специалисты по машинному интеллекту. Математики, специалисты по архитектуре нейронных сетей, программисты пришли в лингвистику «сбоку» — и они теперь на лингвистическом фронтире, буквально за три года (с момента появления архитектуры transformer¹²⁹ в 2017 году), а не лингвисты с их тысячелетним багажом знаний. А теперь появились на базе этих изменившихся представлений о естественном языке и его природе научные работы, где по-новому оценивается роль естественного языка по сравнению с использованием формального математического языка в логике¹³⁰.

Даже если брать математику в приложении к физике, то и тут всё быстро, и «классические учёные» могут уже не поспевать за прогрессом. Графовую нейронную сетку «дистиллировали» в алгебру, а затем подобрали в этой алгебре математическую форму (символьная регрессия¹³¹, или выявление/discovery символьных моделей) для выражения закономерностей в физических наборах данных. Чтобы проверить подход, переоткрыли уравнения ньютоновской механики, переоткрыли гамильтониан из квантовой механики, и предложили закон (математическую формулу) для описания гало тёмной материи в космологии — чтобы продемонстрировать не «переоткрытие», а «открытие»¹³². Основная физическая интуиция как раз и берётся символьной регрессией, в основе которой эволюционный алгоритм. Лидер в этой области символьной регрессии вполне уже коммерциализован: эволюционный/генетический алгоритм символьной регрессии Eureqa, вошёл в состав DataRobot¹³³.

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

Выдвижением гипотез/догадок (каких-то объяснений, дающих предсказания будущего — порождающих/generative моделей) и их проверкой (логической и экспериментальной) занимаются ежедневно миллионы учёных, но также и миллиарды инженеров, менеджеров, продвиженцев, разглядывающих многочисленные данные по их предметам интереса. Идеи для стратегирования — это гипотезы, догадки, они не научные гипотезы, но они одной природы с научными гипотезами, это догадки, которые должны выдержать проверку логикой, а затем и проверку жизнью (эксперимент)!

Eureqa предлагает облегчение труда для самых разных людей, занимающихся выдвижением догадок/гипотез/guesses в самых разных деятельностях, и таких AI-сервисов по выдвижению гипотез будет много, они будут конкурировать, цена типовых «объяснений» будет падать. При этом цена самых трудных объяснений будет оставаться прежней и не падать, зато доступная для этой высокой цены трудность поиска и разнообразность доступных приёмов объяснения будет всё время расти.

Сама физика в текущих работах только привлекает внимание к новым алгоритмам, демонстрирует работоспособность алгоритмов научного мышления. Разработчики Eureqa не имеют какого-то отношения ко всей этой космологии и гамильтонианам, они просто «разрабатывают искусственный интеллект», что бы это ни значило. Им всё равно, объяснять движение планет, или движение курсов акций на фондовом рынке. Но они со своими объяснениями сначала пришли в науку, и продемонстрировали, что их алгоритм выдвигает гипотезы не хуже Кеплера!

Наука уже не будет прежней, и к ней пришли «сбоку»: к физикам пришли люди, занимающиеся нейронными сетями и символьной регрессией, а не физикой. К биологам (в том числе фармацевтам) пришли с решением задач складывания белка люди, которые отработали алгоритмы на играх, таких как игра Го¹³⁴.

Почему все эти вопросы обсуждаются в курсе менеджмента? Потому что стратегирование это всё должно учитывать.

Копают люди давно уже не руками, и не палкой-копалкой, и не лопатой, а экскаватором. Для вытаскивания законов природы из данных палка-копалка из нейронных сетей и символьной регрессии уже готова, статья опубликована. А лет через пять ждём, что новые законы природы будут грести уже лопатой. Лет через двадцать-тридцать можно ждать и «научного экскаватора». Просто удивительно, как мало людей, понимающих суть происходящих перемен. Если вы занимаетесь личным или корпоративным стратегированием, ваш горизонт прогнозирования (и затем горизонт планирования) хотя бы пара-тройка лет (а иногда и больше), то вы не имеете права игнорировать эти тренды.

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

Искусственный (он же машинный) интеллект развивается сейчас особенно быстро, и Тим Урбан даже нарисовал про это иллюстрирующую экспоненциальные технологии картинку¹³⁵:

Это картинка 2015 года. В то время трудно было представить, что робот-юрист возьмёт на себя 80% юридической работы в фирме, держащей миллионы контрактов. Или что AI победит чемпионов мира в Го, в StarCraft II — а потом эти алгоритмы будут использованы в промышленности.

Машинный интеллект по сфере своего использования такой же, как естественный: он может применяться везде. В том числе и в диджействе. Технология NeuralMix в приложении DjayProAI для iOS получила апдейт¹³⁶: раньше она могла разделить запись музыки на вокал, перкуссию и всё остальное, а теперь может разделить на вокал, перкуссию, бас и всё остальное. Смешивать два трека диджею можно уже не целиком, а отдельно каждую из четырёх частей трека. Но тут нейронные сети не просто автоматизируют труд диджея, но делают то, что человек раньше делать не умел. А ведь диджейство по факту массовая профессия: раньше учились массово семь лет в музыкальной школе, а теперь учатся год в школе диджеев — и пультов диджеев продаётся уж не меньше, чем роялей, просто на это уже мало кто обращает внимания. Сочиняет ли компьютер музыку? Да, конечно. Сочиняет ли новую музыку, или только перемешивает в новых сочетаниях давно известное? Сочиняет, проверено¹³⁷.

Последствия гиперэкспоненциального развития машинного интеллекта закрыты туманом будущего. Но уже сегодня понятно, что эти последствия будут весьма заметными для каждого человека на Земле. Масштабы? Например, треть IT-бюджетов реального сектора сегодня направлены на проекты с AI, это неожиданный, но факт¹³⁸. Если вы занимаетесь стратегированием, учтите это!

Сегодняшние инвестиции дадут отдачу через пару лет, поэтому дайте время на разработку и запуск новых интеллектуальных IT-систем в производство. Жизнь на производстве будет меняться, и быстро: деньги-то в это изменение уходят не маленькие! Скажем, переход с плановых ремонтов (35% этих ремонтов «чинят не поломанное», то есть бесполезны) на ремонты по состоянию, моменты которых определяются программами AI, высвобождает в масштабах планеты огромное количество труда, который сейчас абсолютно бесполезен. Представляете, сколько это труда на планете — треть плановых ремонтов? Плановые ремонты — это зло! И победит их машинный интеллект. Дело не только в бесполезном труде людей. Если оборудование (например, турбину электростанции) не останавливать для ремонта, это дополнительный выигрыш. Человечество будет богаче. Машинный интеллект выгоден.

Машинный интеллект научился переводить с иностранных языков (включая самые экзотические) на уровне восьмиклассника (или уже десятиклассника? Или первокурсника? Или третьекурсника технического вуза? Качество перевода меняется так быстро, что не уследишь!). Профессиональные переводчики пока не потеряли работу, но изменения в мире оказались в другом — миллиарды людей получили доступ к плохому, но переводу через Гугл, Яндекс, и даже улучшенному качеству перевода через специализированный сервис DeepL¹³⁹ и отчуждённое от людей умение машины редактировать английский текст в соответствии с каким-то стилем в сервисе Grammarly¹⁴⁰. И это существенно добавило возможностей этих миллиардов людей на рынке труда. Никаких людей-переводчиков и редакторов-корректоров не хватило бы на такой объём обслуживания. Конкуренция на рынке труда возросла для многих работ, языковой барьер с учётом машинного перевода для этих работ перестал быть существенным.

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

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

TEST Скорость обучения нейросети

!!! Прогресс в машинном интеллекте существенно зависит от мощности вычислителя и качества алгоритма. Известно, что мощность вычислителя растёт экспоненциально, по закону Мура. В 2021 году что растёт быстрее — мощность аппаратуры, или качество алгоритмов обучения нейросети?

--- мощность аппаратуры, она растёт экспоненциально по закону Мура. С 2012 года, когда начали тренировать нейронные сети, к 2020 году согласно закону Мура скорость обучения была бы выше в 11 раз ### Нет, в реальности алгоритмы ускоряются быстрее — скорость вычислений стала больше в 44 раза за счёт алгоритмов, https://openai.com/blog/ai-and-efficiency/

+++ рост скорости алгоритмов обучения нейросети быстрее скорости роста аппаратуры ### Да, каждые 16 месяцев скорость алгоритмов увеличивается вдвое с 2012 года, это даёт x44 алгоритмически, а по закону Мура это было бы только x11, https://openai.com/blog/ai-and-efficiency/

Упражнения

Если бы во времена Чарльза Бэббиджа знали, как сделать вычислительную машину, то начали бы с отработки технологии надёжно работающих ламповых триодов. Если бы хотели сделать ракетную технику во время первой мировой войны, то начали бы с технологии жидкостных ракетных двигателей, если хотели бы делать микросхемы 100 лет назад, то начали бы с отработки технологии получения сверхчистого германия (или даже сразу кремния). Всё новое приходит сбоку. Заполните табличку для от трёх ключевых (основных, обеспечивающих конкурентное преимущество) практик вашего проекта.

Номер п/п	Ключевая практика	Если бы вам пришлось изобретать эту практику за пару десятков лет до её появления, то развитием чего нужно было бы заняться, чтобы ускорить появление этой практики?	Если бы вы попали в то время (пару десятков лет до появления практики) и решили её изобрести — какая вероятность (в процентах), что вы бы догадались отрабатывать для этого её ключевую технологию, потом «пришедшую сбоку» в вашу область?
1.
2.
3.

Заполните табличку для более чем трёх ключевых (основных, обеспечивающих конкурентное преимущество) практик вашего проекта.

Номер п/п	Текущая ключевая практика	Обеспечиваемое текущей практикой конкурентное преимущество	Наиболее перспективная новая практика	Прогноз, когда альтернативная практика даст аналогичные результаты, как и текущая практика	Учитываете ли вы скорость (экспонента в скорости развития альтернативной практики)	Срок, когда нужно переходить на новую технологию	Когда начинать подготовку для перехода на новую технологию	Текущие действия по переходу на новую технологию	Ответственный за переход исполнитель роли менеджера по развитию, и знает ли он об этом
1.
2.
3.

Неудачная практика Коллинза: стратегирование ежа

Джим Коллинз в материалах своего сайта¹⁴² для книжки по корпоративной стратегии «От хорошего к великому»¹⁴³ предложил вариант нахождения своего «призвания» (иногда сегодня это называют японским словом «икигай»¹⁴⁴ — то, для чего вы просыпаетесь утром и вытаскиваете себя из постели).

При этом он неявно исходил из того, что в своей книжке назвал архистратегией (архистратегия — общий тип стратегии) ежа. Ёж использует один и тот же приём: чуть что, он сворачивается в клубочек и выставляет миру свои иголки. Одно и то же действие в ответ на любое изменение вовне — каждый раз. И это ежа почти каждый раз спасает, стратегия оказывается эффективна.

Поэтому Коллинз предлагает в личном стратегировании найти эту стратегию ежа, найти своё главное преимущество, главное дело жизни. И дальше развивать это преимущество, сделать это своей профессией.

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

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

Но мы живём даже не во время перемен, а во время перемен перемен (меняется уже способ, которым проходят сами перемены), стратегия ежа сегодня перестала срабатывать! Коллинза критикуют, его теории стратегирования для компаний оказались не работающими!

Почему его способ не срабатывает даже для личного стратегирования? Все пункты в трёх списках закрываются туманом будущего. Меняется то, к чему у нас страсть (мы ещё не знаем, от чего будем без ума через пару месяцев, оно просто ещё не открыто, а к чему страсть была, к тому мы охладеваем — надоедает!), меняется то, к чему талант (мы тоже можем не знать об этой деятельности, но завтра выяснится, что у нас к ней талант!), а уж за что платят — так это и так очевидно, что существенно меняется каждые несколько лет.

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

Все эти рассуждения идентичны для личного, командного (внутри крупной компании), корпоративного стратегирования.

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

Что же делать? Стыдно ведь не быть романтиком (хоть человеку, хоть компании — рассуждения тут похожи), не иметь какой-то очень далёкой и плохо сформулированной цели существования?! Ежу-человеку или ежу-компании легче рассказывать о себе, ему не нужно думать: у него стратегический день сурка. Как жить, когда тебя с детства учат, что в плане мечты ты должен устроить себе этот день сурка, но обстоятельства жизни меняются с такой скоростью, что невозможность многолетнего преследования одной цели в резко изменяющихся обстоятельствах становится очевидной? Если не можешь бежать в направлении цели, не можешь идти, то лежать в направлении цели — это же враньё? Поэтический язык? Что делать с этой романтикой, с этой утопией вечной мечты, к которой тебя приучают с детства, но которая очевидно не работает — ибо реализуешь давнюю мечту не ты, и не твоя компания, а те, кто придут в эту мечту сбоку, из совсем других предметных областей?

Упражнения

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

К чему страсть сейчас	К чему была страсть пять лет назад	К чему талант сейчас	К чему был талант пять лет назад	За что платят сейчас	За что платили пять лет назад

Задания

Поставьте отметку о выполнении следующих заданий:

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

Стратегирование вместо мечтаний

Если вам стыдно, что вы ещё не нашли смысла жизни, у вас нет долгосрочных планов, вам трудно сформулировать мечту — познакомьтесь с литературой, обсуждающей порочность долгосрочного мечтательного целеполагания. Такой литературы сегодня много, и это счастье. Раньше таких книжек не было, всех поголовно уговаривали выбрать «дело жизни», желательно в раннем детстве. Люди страдали, если у них не обнаруживалось цели в жизни, или эту цель в жизни приходилось менять каждые несколько лет. А страдать не нужно, это ведь нормально! Концепт «цель жизни» и для людей, и для компаний (только там говорят «цель существования», а не «жизни») — придуманный, он абсолютно искусственный, в нём нет ничего естественного В стратегировании вы должны вовремя замечать, что цели жизни у вас и цели существования компании неадекватны изменившейся ситуации — и заменить их! Никаких «скреп», «заветов предков/основателей», «детской мечты», «столетней традиции». Жизнь изменилась — меняй цели, хоть личные, хоть корпоративные.

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

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

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

Поэтому от «долгосрочных целей» переходим к разговору о стратегии.

Нужно просто часто обновлять (изменять частично, изменять полностью, то есть делать «вираж»/pivot) стратегию. Стратегирование должно быть непрерывным, не прекращаться. Круто не меднолобо преследовать всю жизнь детскую мечту (личную или корпоративную), но всю жизнь развиваться самому и развивать мир вокруг себя, на многих системных уровнях. Бесконечно развиваться, преследуя самые разные цели развития — это много круче, чем быть романтиком-фанатиком и тем более пытаться сделать из компании романтика-фанатика, то есть слепо преследовать долгосрочную мечту!

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

Пожалуй, самая известная книжка из литературы по постановке краткосрочных жизненных и корпоративных целей и избеганию долгосрочных — это «Антихрупкость» Нассима Талеба¹⁴⁵.

Книга "Антихрупкость. Как извлечь выгоду из хаоса"

Описанный в книжке идеал — быть «рациональным фланёром¹⁴⁶», который пересматривает свой маршрут на каждом шагу, чтобы сделать его зависимым от полученной новой информации. Это ключевой момент: никогда не планировать «в будущее» на расстояние больше, чем один шаг. Никогда не бежать «куда», не иметь долгосрочной цели, которую вы хотите достигнуть. Нужно всегда бежать «откуда», отталкиваясь от того, что вам уже известно. На следующем шагу будет известно больше, меняйте цели, делайте новые ставки.

Это хорошо соответствует теории active/embodied inference, где агент (личность, организация, сообщество, что угодно) избегает неприятного сюрприза (выживает, старается быть стабильным), а не стремится к какой-то особой цели. Если всё вокруг хорошо, то речь идёт о предсказании: важно обеспечить, чтобы предсказание тоже говорило, что всё будет хорошо! И для этого соответствия предсказания жизни чем надо будет заняться в плане изменения агентом окружения и себя, а также изменения моделей окружения и себя, тем и придётся заниматься. Это полностью соответствует тому, что говорит мизевская праксеология: действовать человека заставляет чувство неудовлетворённости, беспокойства от возможных в будущем проблем. Жизнь меняется, меняется предсказание возможных проблем, меняется предсказание лучшего способа ухода от этих проблем, предсказание лучшего способа добычи ресурсов для ухода от проблем. Поэтому стратегия будет меняться!

Не нужно быть рабом собственной мечты и уверенности. Долгосрочная мечта призрачна, она обманет. Не чувствуйте вины от того, что вы и/или ваша компания «поменяли мечту»¹⁴⁷. Идите за текущим интересом, ибо ваш интерес тоже может меняться. Фланируйте, доверяйте интуиции. Но фланировать нужно рационально, не делать очевидных ошибок.

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

На рисунке 24 в книге Нассим Талеб приводит картинку «штанги» во временном ряду, как главного способа достижения успеха и заработка:

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

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

Талеб предупреждает: если вы знаете, куда идёте, или считаете, что знаете, куда идут другие (внешне «целеустремлённые», но вы же не знаете, что у них там на самом деле в мыслях!), то это ваше телеологическое (связанное с целеполаганием) заблуждение. Не заблуждайтесь, никакой разумной цели нет ни у вас, ни у других, честно фланируйте — рационально решайте куда идёте на каждом шагу, не стройте длинного маршрута заранее. И удача время от времени будет вам улыбаться, случай будет работать на вас.

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

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

Если вы понимаете, что проект «дохлый» — бросайте его немедленно, даже если вы (человек или компания) долго им занимались! О затратах просто забудьте, не умножайте их. Каждая новая вложенная в этот проект копейка, каждая новая вложенная в такой проект минута, каждое новое вложенное усилие — это чистые потери, они не вернутся! Потратьте ресурсы на поиск нового, более выгодного проекта! Переключайтесь немедленно! Если лодка тонет, не тоните вместе с ней, тонуть долго — это не доблесть! «Крысы бегут с тонущего корабля» — они ведь правильно делают, если очевидно, что корабль уже не спасти! А кто остаётся на безнадёжно тонущем корабле — герой? Да, герой для рассказов об упёртых неудачниках, в назидание потомкам. Если есть возможность спасти проект — спасайте, но если нет такой возможности — не ждите, что «как-нибудь наладится». Не наладится! Бегите, и не жалейте об уже потраченных силах, времени, деньгах.

Когда тебе весь мир из каждого утюга говорит «напрягись и вот-вот тебе будет счастье!» — не верьте, что вы такой гений, не верьте, что ваша компания такая гениальная. Не верьте, что вы и даже целая большая компания сможете быстро что-то изобрести. Не впадайте в ошибку выжившего¹⁴⁹: приводимые вам из каждого говорящего утюга примеры показывают только отдельных счастливчиков, избежавших неудачи. Не факт, что вы повторите судьбу этих счастливчиков и станете вторым Биллом Гейтсом или Илоном Маском. Миллионы и миллионы проигравших безвестны, вас поэтому никто не предупредит об огромной вероятности неудачи, а пример ничтожной вероятности удачи подвесят как морковку, повторят сотню-другую раз в день.

Если собака укусила человека — это не новость, новость — это когда человек укусил собаку! Если кто-то (или какая-то большая фирма) потерпел неудачу в своих инвестициях — это не новость, в СМИ это не напишут, в соцсетях не прокомментируют. Новость, если вдруг инвестиции принесли огромный доход, вот это точно попадёт в СМИ, это точно будет обсуждаться в соцсетях! Если вы ввяжетесь в авантюру с неограниченным проигрышем, то с огромной вероятностью пополните ряды безвестных неудачников. Пополнить компанию миллиардеров вы тоже можете, но с вероятностью чуда. Не верьте пропаганде упорства, не верьте пропаганде безусловного выигрыша, связанного с бизнесом. Работает не пропаганда, а статистика.

При этом нужно понимать, что уклониться от принятия бизнес-решений нельзя. Любое ваше действие — это ваш бизнес-выбор о том, куда инвестировать собственные (в том числе вашей компании, даже и не собственные) ресурсы: вы выбрали делать именно то, что вы делаете, и тем самым выбрали не делать чего-то другого. Вы не завели собственного дела, но поступили к кому-то на работу (фирма не стала сама торговать в розницу, но продаёт свои товары и сервисы какой-то большой фирме, как единственному клиенту. Это то же самое, что «поступить на работу» для личности): это бизнес-решение. Если речь идёт о вас самих, то вы вложились собой, своим временем, в которое вы могли бы зарабатывать каким-то другим способом. Например, поступив на работу в другое место; или совершая какие-то торговые или даже чисто финансовые операции; или отдыхать и набираться сил для другой работы, которая будет более выгодна — отложить заработок; или учиться для другой работы — тоже отложенный заработок; или путешествовать автостопом и питаться объедками в столовой — это неявный заработок, но он есть; или жить в лесу и питаться как дикарь, что тоже приносит доход, которого едва хватает на жизнь, и он не выражен в деньгах; или ещё делать что-то, и при этом не голодать: люди удивительно изобретательны в выборе того, чем им заняться. К фирмам это относится в полной мере. Если был выбран для обслуживания этот продукт, этот клиент — это означает, что ресурсы (время сотрудников, деньги) были вложены в это, а не что-то другое.

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

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

Наука вместе с Талебом по этой теме говорит, что вы не должны быть лохом (то есть должны быть минимально умны, чтобы не делать явных глупых ошибок), но вот всё остальное — и впрямь дело случая! Вы должны оказаться в правильное время на правильном месте, и быть минимально умны (то есть должны быть умней кошки, хотя и кошек кормят). Люди и компании различаются по их интеллекту и умениям по абсолютной шкале (по сравнению с теми же кошками или слонами или даже кошачьими стаями и стадами слонов) весьма незначительно, а богатство/капиталы их различаются в миллионы раз. Главный виновник этих различий не уровень работоспособности, прозорливость, мудрость и т.д., главный виновник тут случай. Этот «успех» был выражен количественно и проверен в компьютерных экспериментах в 2018 году, модель хорошо соответствует реальности¹⁵⁰. Должно ли это нас смущать? Нет, не должно. Богатые тоже плачут, а бедные тоже смеются. Уровень удовлетворённости жизнью и богатство не так уж сильно связаны.

Самая подробная книжка на тему «бесцельного» фланирования против достигательства далёких заранее намеченных целей — Kennet Stanley, Joel Lehman, «Why Greatness Cannot Be Planned: The Myth of the Objective»¹⁵¹.

Целеполагание типа «мечта» объявляется в этой книге цивилизационным пороком. Мечта — это цель, рассчитанная на долгий срок её достижения, с отсутствием на момент её постановки понимания, как этой цели достичь, ибо эволюция ещё не предоставила набор технологий для её достижения, все экспоненты подрыва ещё не отработали (то есть для концепции использования нет понимания концепции системы: какие физические объекты нужно взять, чтобы из их взаимодействия получить требуемую в использовании функцию). Мечта/утопия получить микроволновку в 19 веке, смартфон во времена изобретения радио, возвращаемую на землю ракету в двадцатом веке. Утопия — это всегда красиво, романтично, но гибельно.

Правильная жизнь по версии этой книжки — это не преследование мечты, не ввязывание в утопический проект длиною в жизнь, а поиск сокровищ (treasure hunt), который может продолжаться вечно. Реализация мечты, решение проблемы — однократно, оно имеет конец во времени и амбициях. Развитие может быть вечным по времени и бесконечным по амбициям!

Книжка вводит понятие шагов бесконечного развития как череды проектов, имеющих разные целевые системы (а не как череды проектов по достижению одной общей цели). Каждый проект — это stepping stone, камушки, по которым переходят ручейки или лужи. На русском эквивалента нет, но мы будем называть их «ступеньки», на что наступают в каждом очередном шаге. Ты видишь ближайшие к тебе проекты, ближайшие камушки-ступеньки, на которые понятно как перескочить. И на ступеньке может оказаться сокровище, выигрыш — удачный бизнес: целевая система, которую можно успеть сделать и удачно продать в обозримое время. Или сокровище там может не оказаться, туман будущего не позволяет это разглядеть наверняка. Остальные ступеньки — в тумане будущего, их вообще не видно, где они, этих целей пока нельзя даже поставить. Метафора подходит и для описания занятий бесконечным развитием какой-то одной системы, где каждая новая фича, каждый вариант архитектуры — это вначале гипотеза, которая может и не оправдаться, и проект в целом выглядит как перескакивание с камушка на камушек, где в любой момент может не хватить денежного потока от клиентов скакать дальше, так и для ситуации с виражами/pivot, когда каждый камешек — это совсем новый вид целевой системы, совсем новая ситуация.

В книге говорится, что ввязываться в проект, то есть вкладывать ресурсы/инвестировать, можно только для видной тебе ступеньки. Планировать (говорить, какие ресурсы делают какие работы по каким практикам) можно шаг только тогда, когда видишь, куда шагать, вероятность выигрыша велика. Когда сделаешь шаг — планируй делать следующий шаг на ту ступеньку, которая открылась с только что достигнутого. Если нет идеи, как реализовать проект (что-то типа ситуации «придумал скатерть-самобранку, продаваться будет на-ура по цене не выше тысячи долларов за штуку, осталось придумать, как она должна быть устроена»), не инвестируй в него, не ввязывайся. Не шагай в туман, не надейся на «авось»! На каждой ступеньке сокровище или есть, или нет. Где-то там, через много-много ступенек может быть большое сокровище, другой берег, ты на него придёшь раньше конкурентов и вытопчешь себе и всем твоим сотрудникам огромную полянку. А потом? А потом полянка окажется вытоптана, и ты опять куда-то будешь скакать по камням, заниматься догадками об умных мутациях каких-то целевых систем — дадут ли эти мутации бизнес, или нет (т.е. выгодно ли будет заниматься этими новыми системами).

Вот так это примерно выглядит, это фрагмент картины Rob Gonsalves «Stepping Stones»¹⁵². Сама картина примерно это и показывает: камушки-ступеньки, прикрытые туманом будущего. Kennet Stanley и Joel Lehman дают именно такую картинку, в которой другого берега вообще не видно, и непонятно поэтому, на какой камушек прыгать, чтобы добраться туда быстрее. Задним числом придут историки и биографы, туман будущего для них отсутствует, и всё это путешествие к успеху для немногих прорвавшихся будет описано как очевидный «прорыв к успеху», как будто было понятно куда и как прыгать, и нужно было только упорство в прыжках:

Правда же в том, что полная картина без тумана доступна только потом, когда развеется туман будущего. А прыгать приходится тогда, когда не очень понятно, какой камушек ведёт к другому берегу кратчайшим путём. Совет у авторов книги тут один: прыгайте в тот проект, которым ещё никто не занимался, новизна важна. Как узнать новизну? Мнения экспертов (например, какого-нибудь инвестиционного комитета) разделятся: половина будут кричать, что там смерть, а половина признают, что там успешный успех. Это означает, что эксперты ничего понять не могут, вы на новой полянке. У вас есть шанс крупного выигрыша. И если вы не будете делать явных ошибок, что-нибудь может выгореть. Или не выгореть. При этом само наличие комитета не позволит вам прыгнуть: если вероятность того, что 10 членов комитета каждый проголосует «за» рисковый проект будет 50%, то вероятность того, что инвестиция будет получена, будет ничтожна (вероятности-то перемножаются!). Поэтому в ситуациях, когда никто ничего не понимает, коллективное принятие решений голосованием не будет работать.

А если эксперты и друзья кричат хором, что проект неудачный? Так и есть, вы попали в хорошо известную им область. Будет неудача, не ввязывайтесь. А если эксперты и друзья кричат хором, что это гениальная идея, и немедленно идите в этот проект? Это опасно, потому как область знакомая, и если там и впрямь так хорошо, то вы встретите жесточайшую конкуренцию, и вас вышибут более богатые, умные и шустрые. Так что новизна — ваш шанс (но не более чем шанс!) и потенциальная защита. В случае успеха, пока богатые и шустрые развернутся и начнут с вами конкурировать, вы и/или ваша компания успеете что-то сделать, что-то заработать в этом проекте. Скорость и новизна важны.

Из мечтателя в реализации одной далёкой идеи с непонятным приходом сбоку какого-то решения по концепции системы (изобретения нельзя планировать, а если и планировать, то изобретение может оказаться не вашим, а ваших конкурентов) нужно стать коллекционером проектов (stepping stone collector) — собирать прохождение ступенек, на которых лежат сокровища/ресурсы/бизнес, и с которых что-то видно дальше (умные мутации, которые могут дать успех бизнесу). Коллекционирование никогда не заканчивается, это не цель, это условие игры, архистратегия. Нахождение сокровищ в проекте не гарантируется, но шанс всегда есть. Выбирайте проекты на границе тумана, выбирайте проекты, в которых вы знаете, как их реализовать — есть гипотеза о том, какую конструкцию нужно сделать, чтобы получить требуемую функцию. Скажем, если у вас есть идея сделать скатерть-самобранку, это отличная «мечта»! Не занимайтесь ей, если у вас нет гипотезы, какая конструкция будет у этой скатерти-самобранки. Но если есть идея по поводу конструкции — смело занимайтесь! Или наоборот: у вас понятная идея, как сделать супер-пупер-генератор-чанста! Это тоже «мечта», не занимайтесь им, пока не будет понятно, кому и как пригодится эта конструкция: будут ли люди готовы заплатить за её функции больше, чем вы потратите на создание конструкции этого генератора-чанста. Помним, что до 2007 года iPhone был невозможным: он был бы слишком дорогим, чтобы проект имел успех. В 2007 году туман будущего рассеялся, как сделать работающий смартфон за вменяемые деньги стало абсолютно понятно (точнее, это стало понятно чуть раньше: разработка iPhone, конечно, началась раньше 2007 года — но не сильно раньше).

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

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

Но вы сделали шаг, граница тумана отодвинулась. Что не было видно при вчерашнем стратегировании, стало видно сегодня — и нужно просто это учесть. И двинуться вперёд с обновлённой стратегией.

Важна не сама стратегия, важно стратегирование как постоянный пересмотр стратегии, чтобы учитывать постоянно меняющийся мир и постоянно меняющегося себя. Стратегия — это не клятва её придерживаться, это рабочий документ, всегда черновик. Если что-то пошло не так, меняем стратегию! Стратегия ничто, стратегирование — всё.

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

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

Вираж (коренное изменение стратегии) — это просто часть стратегирования как постоянной деятельности. «Целеустремлённость» как приверженность стремительно устаревающей стратегии — это синоним меднолобости, путь к провалу.

Фокус тут в том, что вы не знаете, какой сорт успеха вас может ожидать в новом проекте. Цели «добыть то-то и то-то», «победить вон того босса» у вас нет. Речь тут идёт об участии в техно-эволюции (книжка написана исследователями эволюции, занимающимися машинным интеллектом), а у эволюции содержательной цели нет, если не считать реализацию физического принципа минимума свободной энергии путём попыток найти всё более и более усложняющиеся конструкции систем самых разных системных уровней, появляющиеся в ходе этой вселенской (в буквальном смысле слова) оптимизации. Каждое техническое (по целевой системе) и бизнес (по системе создания) решение будет квазиоптимальным, у конкурентов будут абсолютно другие решения, но тоже не слишком оптимальные — близкие к вашим. Время от времени будут происходить большие эволюционные переходы (major evolutionary transitions), когда вы или конкуренты будете находить решения, приводящие к уменьшению конфликтов между системами разных системных уровней, неустроенности/frustrations будут меньше. Эволюция будет находить всё более и более сложные и универсальные (хорошо адаптирующиеся к самым разным ситуациям) формы систем, отражающие всё больше и больше аспектов мира и позволяющие системам и создающим их бизнесам выживать во всё большем и большем разнообразии ситуаций.

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

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

«Lean Startup»¹⁵³ (2011, уже упоминалась и в нашем курсе, и в курсе «Системная инженерия»), написанная Eric Ries книжка по современному бизнесу, которую изучают практически во всех бизнес-школах, рассказывает ту же идею: непрерывно экспериментируй с продуктом, фланируй, а если всё-таки «не взлетает», то делай крутой вираж/pivot, т.е. пробуй совсем другой продукт. И продолжай эксперименты, пока к тебе не повернётся лицом удача — не упирайся, не долбись в одну точку, не ставь все средства на заведомо неверную идею, получай знания на каждом шаге, в каждом эксперименте. Учись, учись, учись — ищи, ищи, ищи. Бесконечно в цикле новых возможностей (цикл! Нет надежды на одну попытку!) развивай свой продукт или сервис, бесконечно в цикле продуктов развивай свою компанию.

Книга "Бизнес с нуля. Метод Lean Startup для быстрого тестирования ...

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

В книге описано, что крутятся два цикла: совершенствования продукта (новые и новые фичи, эволюция продукта) и резкой смены продукта (вираж/pivot, организация при этом претерпевает существенные изменения, научается делать новый продукт — ибо старый продукт оказался бесперспективным).

А вот «видение» (у Эрика Риса это примерное понимание, чем занимается предприятие — блины печёт или ракеты в космос запускает) остаётся более-менее стабильным. Сейчас есть множество примеров, показывающих, что и этот «общий тип продукта» тоже существенно меняется. Фирма Tesla вроде как занимается электромобилями, и была создана для этого, но по факту выпускает и аккумуляторы для энергосети PowerWall¹⁵⁴, и довольно активно готовится продавать человекоподобного робота Optimus¹⁵⁵. Принципы стратегирования, которые предлагает Eric Ries в своей книге:

Тестируй твои предположения (имей численные оценки)
Фокусируйся на том, чего хочет клиент
Уменьшай время цикла (но их там два!)
Меньше документируй, больше делай (прямая отсылка к agile-манифесту, легко её понять неправильно как «вообще не документируй», но моделирование оказывается более чем важным)
Правильные действия в правильные моменты (это так Рис говорит о lean/элегантности ведения работ организацией/стартапом как недопустимости потерь на ненужную работу/waste/muda/rework + «удавливание» многозадачности, об этом подробней будет в разделе курса, рассказывающем об операционном менеджменте)

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

Так, «недеяние» (у-вэй¹⁵⁶) из восточных философий — оно оказывается про то же, про непостановку длинных целей. Вроде как «неделание», оно оказывается на поверку жутко деятельным, оно очень активно следует цепочкой дел за сиюминутной (привязанной к текущему знанию) интуицией о том, к чему нужно стремиться вот прямо сейчас. Прямо сейчас в каждый момент времени, но не всю жизнь. Нет долгосрочных установок на достижение какой-то мечты, в этом и есть плохо понимаемый западным умом секрет «деятельного недеяния».

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

Ещё одна книжка, в которой эволюции как постоянному развитию посвящён довольно большой кусок, написана Pedro Domingos, исследователем машинного интеллекта — «The Master Algorithm: How the Quest for the Ultimate Learning Machine Will Remake Our World» (2015)¹⁵⁷.

Эволюция преподносится там не как поиск/search в возможном «пространстве решений», а как вариант обучения/learn, что ближе к постановке оптимизационной задачи. Можно считать, что ты учишься сложности мира, то есть предсказанию поступающих от мира сюрпризов — в том числе учишься без учителя (unsupervised learning), или выступаешь учителем самому себе (self-supervised learning), давая самому себе задания и пытаясь их выполнять. Про это же самое можно рассказывать и как о «поиске сокровищ». Бесконечное развитие можно обсуждать и как бесконечный поиск, и как бесконечное обучение (людей и организаций, Peter Senge говорит об «обучающейся организации», об этом будет позже): поиск бизнес-сокровищ в длинной череде проектов подразумевает обучение справляться с заранее неизвестными проблемами этих проектов. В машинном интеллекте парадигма бесконечного развития, бесконечного (life-long learning) обучения решать всё новые и новые проблемы вместо «решения одной хорошо поставленной проблемы» стремительно набирает вес.

Педро Домингос - Верховный алгоритм. Как машинное обучение изменит наш мир обложка книги

Проектов создания и развития каких-то систем (и целевых, и систем создания, и даже системы себя, любимого) хватит для всех, особенно если учитывать критерий новизны при выборе проекта. Исследуйте новое на самой границе известного, это на долгих периодах окупается! И каждый шаг развития, каждый удачный бизнес (то есть создание и развитие какой-то целевой системы, предоставление сервисов для этого) позволит вам увидеть что-то ещё, шагнуть дальше. Если не ходить проторенными туристическими тропами, на которых уже давно все сокровища расхватаны, то вам этих сокровищ на жизнь хватит. Главное — не загадывать заранее, какими должны быть эти новые камушки, новые проекты, какие именно сокровища там должны быть. Главное — не загадывать заранее мечту-утопию. В мечте будет встреча с изумрудом, а встретится вам алмаз. Не проходите мимо алмаза!

Из курса австрийской школы экономики вам уже понятно, почему не может работать госплан¹⁵⁸ — невозможно рационально вычислить потребности большого числа людей, да ещё и на достаточно длительном интервале времени, поэтому, сколько каких продуктов производить, и по какой цене, вычислить не удастся. Будущее покрыто туманом, и мы ничего не можем сказать о будущих продуктах, поэтому не можем знать, сколько каких деталей нужно произвести для того, чтобы собрать эти будущие продукты. Рыночная экономика — это процесс техно-эволюции, он подразумевает бесконечное создание и развитие всё новых и новых продуктов, появление всё новых и новых сервисов, какие-то из них будут быстро отмирать, другие жить долгие и долгие годы, всё как в биологической эволюции, только быстрее.

Нет никакой «божественной миссии», «смысла жизни», есть вот эта техно-эволюция, которая детерминистична (то есть не случайна! Все события имеют физические причины!), но принципиально непредсказуема в силу квантовой природы физического мира¹⁵⁹.

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

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

Упражнения

Мечты нужно регулярно обновлять, чтобы оставаться современным. Вспомните более трёх последних вариантов того, что могли бы назвать своей мечтой (или честно напишите, что «мечты нет»):

Вариант мечты	Начал мечтать (год)	Закончил мечтать (год)	Мечта сбылась?	Если мечтать вот прямо сейчас заново, эта мечта выглядит лучше, чем все остальные?

Бесконечное развитие (open-endedness)

Бесконечное развитие (open-endedness) — это идея, которая позволяет в разы компактней и точнее (т.е. с использованием математических моделей) говорить про сложные вопросы «прогресса», «развития», «целеполагания», «эволюции», «вечного обучения», «постоянной инновации» и т.д. Идея бесконечного развития помогает отбросить бессмысленные споры по вопросам типа «труба ржавеет: можно ли сказать, что она развивается? Что будет прогрессом для трубы?».

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

О чём угодно «лучшем» можно говорить как о «лучшем известном на сегодня», state-of-the-art (SoTA). Завтра лучшее будет другим, SoTA всегда имеет дату. Лучшая теория гравитации в 1600 году не включала силы гравитации, в 1800 году гравитация объяснялась как сила притяжения массивных тел, в 2000 году лучшая теория гравитации (теория относительности) говорит об искривлениях пространства-времени, и гравитация не является силой! SoTA в науке, инженерии и много чём другом меняется со временем, и это будет бесконечно.

Open-endedness переводится обычно как «открытость» или в крайнем случае «незавершённость», и весь аромат английского слова немедленно теряется. Поскольку это применяется к алгоритмам, которые всё время научаются делать что-то новое, то это мы будем переводить как «бесконечное развитие». Это «что-то новое» в подобных алгоритмах и называется stepping stone/ступенька. Это может быть биологический вид в эволюции, вид продукта или сервиса в техно-эволюции, или даже отдельная «фича» в продукте, вид мастерства в эволюции деятельности.

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

Люди на Земле владеют всё более и более разными видами мастерства (углубление разделения труда), и эти виды мастерства всё более сложно освоить, для надлежащего уровня требуется 4-10 тыс. часов прохождения ступенек в мастерстве от «полный новичок» через «иногда получается» до «настоящий мастер». Компании для выпуска хорошего продукта нужно обучить самым разным видам мастерства иногда одного человека, а иногда и десятки тысяч людей. Развитие целевых систем по факту означает и развитие создающих систем. Бесконечность развития целевых систем означает бесконечность развития бизнеса, бесконечность прибыльности.

Базовый текст декабря 2017 года «Open-endedness: The last grand challenge you’ve never heard of»¹⁶⁰ написан в соавторстве с Lisa Soros теми же Kenneth O.Stanley и Joel Lehman, которые в 2015 году написали книжку про важность новизны, «Why Greatness Cannot Be Planned: The Myth of the Objective».

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

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

В январе 2019 года Stanley (он сейчас возглавляет лабораторию искусственного интеллекта в OpenAI) и Lehman сделали алгоритм бесконечного развития¹⁶¹, а в марте 2020 года этот алгоритм был усилен¹⁶². Алгоритм порождает своей стратегирующей частью всё более и более сложные рельефы местности (даёт параметры генератору рельефов: «ставит цель»), а затем его решающая часть-робот решает эти проблемы, то есть учится проходить заданные частью целеполагания рельефы. Оказалось, что постепенно наученные через «проблемы в зоне ближнего развития» роботы могут проходить в конечном итоге самые сложные среды, а попытки просто «решить проблему» без этих промежуточных научений, а просто «научиться с нуля», без stepping stones/ступенек проваливаются. Оказывается, без эволюции, без промежуточных ступенек мы не можем научиться чему-то сложному! Обучение какой-то деятельности должно быть многоступенчатым, развитие должно проходить через ступеньки, находящиеся на границе тумана — ни слишком трудные (тогда научение невозможно), ни слишком лёгкие (тогда не будет накоплен опыт).

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

Для алгоритма бесконечного развития (как мы знаем, вселенная реализует именно такой алгоритм, и рыночная экономика тоже реализует такой алгоритм в техно-эволюции) нужно достаточное время, и мы получим удивительные результаты. Эволюция на Земле получила удивительный результат, ибо она как раз реализует такой алгоритм: условия существования Земли предъявляют всё более и более разнообразные и сложные проблемы развивающимся на ней животным и растительным видам, а эти виды достигают удивительного мастерства и универсальности в решении этих проблем. Один из самых интересных моментов тут — это получение биологического интеллекта, затем развитие интеллекта цивилизации, а сейчас и получение машинного интеллекта. Человечество ставит и ставит себе всё более и более сложные проблемы, и научается эти проблемы решать. Эволюция и техно-эволюция описываются не столько как «появление новых и новых видов», сколько как «решение новых и новых проблем».

Этот алгоритм реализуется не только всей Землёй, не только всей цивилизацией, но даже в одном мозге. Автор когда-то задавал вопрос проф. John Grinder (одному из основоположников нейролингвистического программирования), считает ли он перспективными «остановку внутреннего диалога» и прочие средства обеспечения «единства сознания», «недуальности». John Grinder отвечал, что не считает: для развития всегда должно быть некоторое противоборство, критика, а хоть и в одном мозге. Единство — это путь к стагнации, а не к развитию/эволюции/прогрессу, как это ни назови. Поэтому даже в одном и том же мозге постановщик проблем должен всё время предлагать проблемы к решению, а решатель проблем должен учиться их преодолевать — и так развиваться до бесконечности. Никакой остановки, никакой стагнации, никакого успокоения при достижении «конечной цели». Каждая новая цель, каждая новая ступень сложней предыдущей, цепочка этих ступеней никогда не заканчивается, это и есть жизнь.

Да, в науке всё то же самое: наука ищет всё более и более точные объяснения того, как устроен мир. SoTA в научных объяснениях постоянно меняется. И эти изменения будут бесконечны. Люди не знали о существовании микробов и вирусов, и поэтому смертность от инфекционных заболеваний (родильная горячка, например, как первое, с чем сталкивались буквально при рождении) была запредельно высока. Затем появились объяснения, которые рассказали о микробах и вирусах и их связи с заболеваниями, на основе этих объяснений были выработаны простые, но контринтуитивные предложения по борьбе с болезнями. Родильную горячку победило мытьё рук! Этот рецепт «мойте руки, и не будет родильной горячки» был совсем, совсем неочевиден, пока не было объяснения причин: не рассматривались микробы как причина болезни. А теперь производством моющих средств занято огромное количество людей, это огромный бизнес.

Но можно ли сказать, что всё уже известно про инфекционные болезни? Конечно, нет! Пример пандемии показывает, что неизвестного ещё много. Или даже по-другому: неизвестно, что из известного действительно известно! Может быть, SoTA в знаниях об эпидемиях уже есть, но конкурирующие теории ещё не опровергнуты (или об их опровержении ещё не догадываются, не признают этого, обычное ведь дело в истории!), поэтому текущее SoTA не позволяет выработать хорошие предложения. И защита от эпидемий ограничивается всё тем же мытьём рук и бессмысленными ритуалами типа поливания тротуаров хлоркой (что приносит вред здоровью и честно квалифицируется политиками не как защитная мера, а как «психологический сигнал гражданам»). Наука игнорируется, ибо сама суть науки — это свободное обсуждение теорий, но теории эпидемий обсуждать свободно сегодня нельзя. Например, SoTA в прививках от гриппа и коронавирусов говорит, что ввиду большой изменчивости штаммов прививки для этих классов вирусов оказываются неэффективны, хотя для других могут быть эффективны¹⁶³. Фармакологические компании, понятно, с этим не согласны. Кто победит в дискуссии, если одной из сторон рты затыкают не учёные своими аргументами и экспериментами, а власти и даже частные СМИ? И ещё в этом участвуют не просто деньги, а очень большие деньги фармацевтического лобби?

Но уже очевидно: двигаясь по этой линии улучшения объяснений жизни (включая тем самым и объяснение болезней) можно надеяться на достаточный объем знаний для получения людьми биологического бессмертия. А дальше уже понятно, что можно будет менять и саму природу человека, почему бы и нет! Для этого не хватает знаний, а их получение — то же бесконечное развитие. Всё это — возможные темы для продуктов, выбираемых визионерами и для бизнесов, выбираемых бизнесменами в ходе стратегирования.

Существование звёзд-квазаров тоже было абсолютно неочевидно, объяснение того, что с ними происходит, было невозможно в рамках ньютоновской физики. Появилась эйнштейновская физика, которая разбирается с искривлениями пространства-времени в присутствии больших масс, и она решила много космологических загадок. Квантовая физика по историческим меркам появилась очень недавно, но она уже объяснила многое из происходящего на другом конце спектра размеров — поведение фотонов управляется её законами. А дальше? Бесконечное развитие: остаётся проблема квантовой гравитации. Поиск новых научных проблем и последующее их решение, приводящее к постановке новых проблем, будет вечным. Мы исторически находимся в самом начале этого бесконечного развития, наука ещё очень и очень молода, если рассматривать её существование во вселенском масштабе времени.

Книжка Давида Дойча о бесконечном росте знания, бесконечном росте человечества так и называется «Начало бесконечности. Объяснения, которые меняют мир»¹⁶⁴.

Начало бесконечности. Объяснения, которые меняют мир

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

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

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

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

Эволюционной эпистемологии (научное, инженерное, менеджерское и т.д. знание/episteme развивается в ходе бесконечной/open-endedness эволюции и техно-эволюции, непрерывного выдвижения новых идей).
Критического рационализма (имеющееся знание критикуется на основе принципов рационального, то есть основанного на логике, следующего каким-то правилам, а не произвольного рассуждения, и эти рассуждения проверяются ещё и экспериментами в физическом мире, а не только мыслительными экспериментами). И помним, что речь идёт не только о «мышлении», но и действии, мышление деятельно, рационализм тем самым подразумевает действия, в него входит в том числе и теория решений.

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

Бесконечное развитие, «непрерывное всё» и критика-обоснование пронизывает всю жизнь, происходит на всех системных уровнях — и в науке, и в искусстве, и в инженерии, и в бизнесе/менеджменте, и в создании сообществ, и в политике.

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

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

У людей и организаций ситуация другая: детёныши людей и молодые стартапы тоже играют, в ходе игры ставят себе задачи сами — и сами научаются эти задачи решать. Но значительную часть задач ставят перед ними взрослые (или для стартапов акселераторы, серийные предприниматели, менторы), они предлагают некоторый обязательный (обязательное школьное образование! И даже вузовское образование такое же) учебный план/curriculum. А потом эти внешние задачи заканчиваются — и развитие опять переходит к бывшему ученику. И дальше всё зависит от него самого, «взрослые» могут сказать о мире не больше, чем бывший ученик и сам уже знает.

Освоение новых видов мастерства этот бывший ученик себе может не запланировать, и его текущие знания и умения тогда быстро устареют, он рискует остаться на обочине жизни (всегда помним, что не нужно волноваться: котят и морских свинок кормят повсеместно, а уж человеку точно не дадут от голода помереть, если тот будет достаточно ласков с другими людьми. А вот компании дадут умереть, это ж не люди!). В другом варианте стратегом выступит начальник: на работе сотруднику будут ставить задачи из ближней зоны развития, и развитие случится. Если же на работе будут одни и те же однотипные задачи — развития не будет. Ещё возможно, что человек после первичного обучения возьмёт ответственность за собственное развитие на себя — сам будет ставить перед собой всё более и более сложные и разнообразные проблемы, а потом учиться их решать. И так всю жизнь, а если это компания, то всё время существования компании.

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

TEST бесконечного развития

Укажите процессы бесконечного развития:

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

+++ улучшение характеристик микропроцессоров ### Да, это бесконечное развитие. Непрерывно ставятся и решаются новые и новые проблемы (скорость работы, размеры чипа, число элементов на чипе, энергопотребление, виды аппаратно поддерживаемых вычислений, и т.д.) и выдвигаются новые и новые способы их решения (материал подложки, конструкция транзисторов, компоновка элементов по вертикали, способы охлаждения, другая элементная база — мемристоры, и т.д.)

+++ предложение образовательных программ ### Да, это бесконечное развитие. Предлагается обучение всё новым и новым практикам, для самых разных входных и выходных уровней мастерства, за самое разное время, по самым разным бизнес-моделям, и это обучение предлагается делать всё более и более продвинутыми методами — blended learning, flip teaching, collaborative interactive learning, adaptive learning и т.д.

--- рост мастерства пианиста ### нет, это не бесконечное развитие, ибо речь идёт о решении одних и тех же проблем одними и теми же способами, просто растут количественные характеристики: прежде всего более точное звукоизвлечение. И известен потолок (если не переходить на другие виды инструментов, другие виды музыки). Если речь идёт о мастерстве музыкального исполнения как такового и выходе за пределы именно человека-пианиста, то ответ мог бы быть другим (бесконечный рост возможностей музыкального исполнения — сначала людьми на акустических музыкальных инструментах, потом машинным интеллектом, в том числе интеллектом-мультиинструментом)

+++ развитие музыкальной культуры ### да, постоянно ставятся новые проблемы (звукозапись, музак/muzak, дискотеки, создание самых разных новых музыкальных стилей, в том числе на основе разнообразия world music, альтернативные тональные шкалы и эстетические принципы) и предлагаются новые их решения (прежде всего, это переход к электронной музыке — включая электромузыкальные инструменты, синтезаторы, диджеинг, в последнее время использование «нейрокомпозиторов» с алгоритмами AI)

Упражнения

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

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

Когда вы слышали про использование стратегии для быстрого отклонения или принятия нового проекта? Опишите более трёх случаев.

Номер п/п	Предложенный проект	Приняли его или отклонили на основе соответствия стратегии	Примерная длительность его обсуждения до момента, когда вспомнили о стратегии и приняли или отклонили на этом основании
1.
2.
3.

Задания

Поставьте отметки о выполнении следующих заданий:

Прочтена книга Kenneth O. Stanley, Joel Lehman «Why Greatness Cannot Be Planned: The Myth of the Objective», 2015. Опубликован пост с вашими мыслями по поводу прочтённой книги.
Прочтён текст Kenneth O.Stanley, Joel Lehman, Lisa Soros, "Open-endedness: The last grand challenge you’ve never heard of", 2017, https://www.oreilly.com/ideas/open-endedness-the-last-grand-challenge-youve-never-heard-of. Опубликован пост с вашими мыслями по поводу прочтённого текста.
Прочтена книга Эрик Рис, «Бизнес с нуля: Метод Lean Startup для быстрого тестирования идей и выбора бизнес-модели» (оригинал вышел в 2011 году), и опубликованы свои мысли о бесконечном стратегировании, пришедшие в голову по ходу чтения этой книги.
Проведены беседы с десятком ваших сотрудников и по их итогам опубликовано эссе «Что знают о нашей текущей корпоративной стратегии сотрудники, и как они используют её в своей работе».

Теории счастья и богатства

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

Научных исследований по счастью достаточно много. Подробный исторический обзор того, что происходит со счастьем в разных странах приводится в книге Стивена Пинкера 2018 года «Просвещение сегодня. В защиту разума, науки, гуманизма и прогресса»¹⁶⁵.

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

Американец в 2015 году по сравнению с аналогичным полвека назад живёт на девять лет дольше, образовывается на три года больше, получает дополнительных $33000 в год на члена семьи (только треть из которых, а не половина как раньше, уходит на необходимое для жизни) и имеет дополнительных восемь часов в неделю на досуг. Он или она могут провести это досуговое время читая интернет, слушая музыку на смартфоне, просматривая фильмы на телевизоре высокого разрешения, разговаривая с друзьями или родственниками по скайпу или обедая тайской едой вместо жареных мясных консервов.

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

Дальше рассматривается само понятие «счастье», и оказывается, что оно само по себе довольно бессмысленно — усредняется по многим другим показателям, как «средняя температура по больнице», когда часть с нулевой температурой в морге, а часть в реанимации — но в целом температура нормальная! «Счастье» само по себе имеет мало смысла, нужно сразу уточнять, что имеется в виду. Так, слово «счастье» используется для сразу двух разных характеристик: обозначения кратковременного эмоционального состояния, настроения веселья и безмятежности, но также и для более-менее рациональной оценки долгосрочной (день или даже жизнь) характеристики качества жизни.

Социологи нашли, что люди плохо различают счастье, удовлетворённость жизнью, а также простое предпочтение широко понимаемой «жизни получше» против «жизни похуже». Да ещё оказывается, что долгие периоды качественной жизни, полной смысла и оцениваемой в этом плане очень положительно, не связаны с постоянным ощущением веселья и безмятежности, ибо какая уж тут безмятежность, когда ты тяжело работаешь? Зато потом есть что вспомнить, и это очень приятные воспоминания, ибо твоя жизнь в этим моменты была полна смысла, да ещё и принесла много важных результатов! А вот какая-нибудь вечеринка с друзьями, где ты вроде как бы был абсолютно счастлив несколько часов подряд — вот она даже не запомнилась, забыта через неделю!

Но и этих странностей мало для понятия «счастье». Пинкер приводит вот такой график:

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

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

Вот ответ на вопрос о счастье в проведённом агентством Ipsos опросе по удовлетворённостью жизни в 28 странах в августе 2019 года¹⁶⁶:

В Австралии 86% чувствуют себя счастливыми, а вот в России — 47%, вдвое меньше. Но почему люди так себя ощущают? В разных странах в среднем по разным причинам! Во всех странах причиной ощущения счастья называют хорошее здоровье и физическую форму, наличие детей, отношения в супружестве, ощущение того, что жизнь имеет смысл, а также ощущение безопасности и защищённости от всяких рисков. Но в некоторых странах по-другому. Скажем, в Перу и Турции 87% населения считают, что источником счастья является признание тебя со стороны других людей успешным человеком! В Малайзии и Саудовской Аравии для 86% населения наибольшее ощущение счастья приходит от религии и духовных практик.

Важно, что благосостояние на Земле постоянно растёт. Люди со временем богатеют, и в последние годы человечество богатеет очень быстро. То есть жизнь ускоряется, люди при этом становятся богаче (впрочем, всё это ускорение как раз и приносит новые цивилизационные блага). Растёт здоровье людей, это во всех странах ведёт к большей удовлетворённости жизнью. Но вот даже наличие детей в одних странах коррелирует с тем, что человек-родитель чувствует себя более счастливым, чем бездетный, а в других странах — ровно наоборот!

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

Восприятие счастье меняется со временем, у разных поколений оно разное. Так, раньше самые разные исследования показывали, что с возрастом счастье растёт. Современные исследования показывают, что с возрастом счастья становится меньше¹⁶⁷:

Как поднять счастье? В 2006 году было исследование¹⁶⁸, что уровень счастья начиная с какого-то не слишком высокого уровня дохода не зависит от денег. Но в прошлом году провели ещё исследования, и выяснили, что чем больше денег, тем больше ощущение собственного благополучия¹⁶⁹. И это новый тренд, тут тоже всё меняется: в прошлом веке счастье действительно меньше зависело от дохода! И уже понятно, что ответ на вопрос зависит даже не от дохода, а от страны проживания и от возраста!

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

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

Так что лучше не задаваться вопросом «буду ли я счастлив в будущем», а задаваться какими-то другими, более определёнными вопросами.

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

Если вы (и как человек, и как компания/организация) действуете, если ввязываетесь в разные проекты, то статистически время от времени вам должно везти, равно как часто будут и неудачи — как из-за ваших ошибок, так и просто из-за никак не зависящих от вас причин. При этом нельзя как ожидать, что вам удастся быть существенно счастливей, чем чувствуют себя люди в вашей стране, так и нельзя ожидать, что вы будете существенно несчастней!

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

Но всё-таки: что с богатством? Как связано вечное развитие с богатством? Вот вы развиваетесь, становитесь очень умным — станете ли вы богатым, и поднимет ли вследствие этого развитие уровень вашего счастья? Скорее всего — нет. Исследования (в том числе компьютерное моделирование)¹⁷⁰ показывают, что богатство таки даётся случаем, и если человек минимально умён, чтобы не профукать свой шанс, то он будет богатеть. Богатство людей различается в миллионы раз (сто миллиардов долларов против ста тысяч долларов — это ведь как раз миллион), а умность людей на сегодняшний день различается не так сильно (особенно если сравнивать с маленькими детьми или животными, не только образованных взрослых друг с другом).

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

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

В любом случае: если вы не учитесь, то вряд ли станете миллионером (хотя и в этом может помочь случай, например — получите наследство). Если учитесь — вполне можете стать миллионером, заработать миллионы. Но вот стать миллиардером, становясь умнее и умнее — это уже не получится, тут должна сопутствовать удача. Миллиардеров довольно мало, а умных людей — очень много. Компаний-единорогов (с капитализацией выше миллиарда долларов) мало, а самых разных больших, средних и маленьких компаний с очень талантливым руководством — очень много. Трезво оценивайте свои шансы!

Упражнения

Напишите в таблице ниже цель, которую вы достигаете прямо сейчас (что хотите изменить в физическом мире сейчас, какую систему создать и/или развить) — и чему для этого учитесь (что хотите изменить в себе).
Выпишите дальше список разных целей, которые вы хотели бы достичь когда-нибудь (что хотите изменить в физическом мире когда-нибудь, какую систему создать и/или развить).
Для этих целей напишите известные вам средства (конкретные известные на настоящий момент практики, будущие изобретения использовать нельзя!), которыми можно достичь цели. Вычеркните те цели, для которых нет известных вам средств их достижения (нет реализуемой концепции системы).
В оставшемся списке целей отметьте те, достижение которых не потребует от вас никакого дополнительного обучения, дополнительного мастерства (типа «наконец-то сходить в Большой Театр, развлечься»). Вычеркните их, это не ведёт к росту ваших возможностей, это не стратегические цели.
Сравните текущую цель и потенциальные другие цели (например, поставьте им оценки желаемости по десятибалльной шкале). Ответьте себе на вопрос, почему вы сейчас занимаетесь тем, чем занимаетесь, учитесь тому, чему учитесь — и не занимаетесь чем-то другим из вашего списка.

Хочу изменить в мире сейчас:

Я хочу изменить в мире сейчас	Я буду это делать способом	Для этого я научусь	Сила желания (по десятибалльной шкале)

Хочу изменить в мире когда-нибудь:

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

Задания

Поставьте отметки о выполнении следующих заданий:

Текущая рабочая стратегия вашего уровня (всей фирмы, или подразделения, или лично вас как оргзвена из одного человека) документирована в одном из предложенных в курсе (возможно, адаптированном в ходе коллективных обсуждений) формате в каком-то универсальном моделере, наиболее удобном и привычном для работников (confluence, notion.io, coda.io и т.д.).
Вы провели не менее трёх раундов обсуждения документированной в моделере стратегии с сотрудниками, руководителями, собственниками/инвесторами и другими причастными к формулированию и реализации рабочей стратегии вашего уровня людьми. Вы хорошо понимаете, что происходит с результатами этих обсуждений.
Вы предложили, обосновали и приступили к выполнению хотя бы одного шага развития, исходящего из текущей стратегии вашего уровня.
Вы помогли в обсуждении (обязательно с документированием обсуждённого и рассылкой документа участникам обсуждения!) стратегии не менее чем троим вашим друзьям и/или сотрудникам.
В блоге опубликован пост по теме «Стратегирование», где вы отметили, что изменилось в ваших представлениях о стратегировании после знакомства с материалами курса, а также даны рекомендации для студентов, идущих по курсу после вас.

6. Практика управления работами (операционный менеджмент)

Практика управления проектами

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

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

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

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

Есть нормы производительности труда, то есть можно как-то планировать продолжительность работ (скажем, в строительстве кирпичных домов для кирпича есть норма, сколько каменщик укладывает кирпичей в час — и на эту оценку можно как-то опираться).
Есть учёт ресурсов (то есть можно сказать, сколько строительный рабочий работал, выполняя какую именно работу: сколько каменщик укладывал кирпичей, сколько замешивал раствор, если вдруг он оказался ещё и на этой операции).
Заранее известна последовательность работ (up front plan), в том числе это означает, что заранее известен состав системы (ибо план получают из того, что для каждой части системы планируют работы по её проектированию, изготовлению, логистике к месту сборки/монтажа, сборке/монтажу, испытаниям).

Если внимательно приглядеться, то это всё будет работать или на заводском машиностроительном производстве/manufacturing под заказ (без работы конструкторского бюро! Только производство!), или на стройке на стадии именно «строительство» (но не стадии проектирования). Везде, где есть хоть какие-то неопределённости (скажем, в умственной работе не установишь норму на решение проблем, типа «полторы проблемы в сутки», или в условиях выдвижения и критики гипотез не скажешь заранее последовательность их выдвижения и критики, включая экспериментальные проверки, то есть нет «плана работ по изобретению системы»), классическое проектное управление не работает.

Само это классическое проектное управление прошло несколько поколений, сейчас мы наблюдаем четвёртое (которое по большому счёту уже не очень классическое именно «проектное управление», смысл понятия поменялся):

Первое поколение говорило только то, что есть отдельные работы, которые хитро связаны друг с другом (представляются какой-то сетью/network), и их нужно как-то выполнить ограниченным ресурсом за минимальное время — представить график. Метод получил русскоязычное название «сетевое планирование» (основной объект там — «сетевой график»¹⁷¹, отражающий зависимость работ друг от друга), по-английски получил распространение как Program (Project) Evaluation and Review Technique, или PERT¹⁷². Суть этой техники в том, что находился критический путь/critical path как собранная от начала работ до конца проекта самая длинная цепочка работ, которые нельзя начинать раньше, чем закончится предыдущая работа по цепочке. Если сократить длительность работ в этой цепочке (скажем, не допускать пауз при переходе от одной работы в цепочке к другой работе), это автоматически уменьшало время работ по проекту, или хотя бы давало какую-то предсказуемость времени ожидаемого окончания работ.

Второе поколение родилось, когда появилось понятие процесса как повторяемого паттерна работ (по факту речь шла о практиках). Процесс считался реализацией какой-то практики, и всё стали изображать как базовые единицы-процессы. Процессы рассматривались как commodities¹⁷³ (базовые товары на товарно-сырьевой бирже, типа зерна или нефти: качественные различия мало волнуют, поставщики мало волнуют, одна партия легко заменяется другой партией). Проект же во втором поколении рассматривался как нечто уникальное, составленное из более-менее похожих процессов. Скажем, процессы «открытие проекта», «планирование работ», «ведение работ» не уникальны (они определяются практикой проектного управления, которая будет одинакова, где бы она ни применялась — хоть в проектах выращивания арбузов, хоть в проектах производства кремниевых микросхем). Но вот сами работы, которые по ним ведутся, в совокупности уникальные — это и будет «проект». Появилось множество самых разных практик второго поколения управления проектами как отдельной дисциплины: Project Management body of Knowledge (PMBoK)¹⁷⁴ от PMI (Project Management Institute), PRojects IN Controlled Environments (PRINCE2)¹⁷⁵ и многие другие.

Проблем с этим вторым поколением было две:

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

Ответом было появление систем проектного управления третьего поколения, где «проект» оказывался более-менее элементарной работой (хотя и сложно устроенной), а на передний план выходило понятие программы проектов¹⁷⁶ как совокупности всех проектов, возможно ещё не начатых. Можно долго обсуждать, чем портфель проектов как совокупность всех проектов отличается от программы¹⁷⁷, но понятие портфеля проектов попросту отсылает к отдельным проектам, лежащим в портфеле (оно вполне присутствовало и в первом поколении проектного управления). А вот программа работ особо напирала на то, что очередные проекты в программе появляются по мере осознания в них необходимости, а уже появившиеся проекты пересекаются по ресурсам, параллельны по времени, а также все могут быть оптимизированы под понятный результат программы. И, конечно, все эти рассуждения сильно затуманивались тем, что во втором поколении проектного управления менеджмент весь в целом и менеджмент проекта по факту отождествлялись: если взять руководителя проекта и директора фирмы, то сразу и не поймёшь, чем они различаются — оба должны вроде как быть лидерами, организовать вверенные им коллективы, вести переговоры с контрагентами, следить за финансами и т.д. Суть «управления работами» оказалась существенно размыта в общеменеджерских рассуждениях.

В третьем поколении классического проектного подхода была сделана попытка преодоления замеченных проблем. Основным объектом проектного управления стал не проект, а программа проектов (производственная программа, программа развития и т.д.), частями которой стали проекты. Управление проектами (уже объявленными) осуществлялось в рамках перераспределения ресурсов во всём текущем портфеле проектов (то есть уже известных проектов), но смысл «программности» был в том, что по мере осознания того, что нужно делать для достижения целей программы, формулировались и запускались новые проекты программами. Это получило название управления программами, в котором с одной стороны нужно вовремя запускать новые проекты::работы, чтобы двигаться к объявленным целям программы (выполнять миссию достижения видения, где отдельные шаги ещё не известны и будут определяться по мере продвижения в выполнении миссии), а с другой стороны, как можно быстрее выполнять на ограниченном множестве ресурсов те проекты::работы, которые уже известны на данный момент. Так сказать, оптимизировать известное, пытаясь оптимизировать ещё и неизвестное. К этому классу методик проектного управления третьего поколения относились популярное в Японии Program and Project Management (P2M)¹⁷⁸, проектное управление из теории ограничений (TOC)¹⁷⁹.

Основное, что было выявлено в ходе всех этих попыток сформулировать проектное управление:

Важнейшим является управление потоками работ через какие-то рабочие станции. Ресурсами тут будут сырьё и промежуточные материалы, но и сами рабочие станции. Задача проектного управляющего в том, чтобы убирать ограничения в производительности. Логисты (в supply chain), проектные управляющие — это всё одно и то же в части моделирования происходящего, ключевой объект — поток/flow, который течёт по сети рабочих станций/ресурсов.

Рассматривать приходится сразу все потоки работ, ибо оптимизировать один поток работ (проект) так, чтобы не ухудшить при этом протекание всех потоков работ (производственную программу) невозможно. «Оптимизировать» тут сводится к выполнению чисто арифметической задачи: какие работы в какой последовательности поручать выполнять рабочим станциям. Арифметика решает всё, и она контринтуитивна. В каждой производственной сети есть ограничение на общее время выполнения работ, и оно зависит не только от последовательности работ (первое и второе поколение проектного подхода — в них упор делался на метод критического пути/critical path), но и от наличия ресурсов, которые доступны (метод критического ресурсного пути/critical resource path/критической цепи/critical chain). В случае, когда для многих проектов у нас одни и те же ресурсы (множество проектов идёт через одних и тех же людей), практически бесполезно стало говорить о критических путях — ибо всё уже решали не длительности работ, а доступность ресурсов, которые разрывались по разным проектам.

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

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

Если бы было три Васи, то все работы закончились бы на тридцатый день. Но Вася один. У нас есть самые разные варианты того, как загрузить Васю работой.

Первый вариант «бесчеловечный», основан на чистой арифметике: Васе говорим, что он не имеет права заниматься ничем другим, пока не сделает работу MX для одного проекта, потом для другого, потом для третьего. Относимся к Васе как к станку! Дальше никаких чудес: первый клиент получает результаты через тридцать дней, второй через сорок, третий через пятьдесят дней. Это обсуждается обычно в управлении процессами, и там в основе теория массового обслуживания/теория очередей¹⁸⁰ и исследование операций¹⁸¹. Упор на то, что работа MX признаётся одинаковой, и всё это описывается как процесс MX с тремя экземплярами работ. Дальше математика потока работ через ресурс Васю. Проблемы появляются в тот момент, когда выясняется, что кроме одинаковых работ у Васи есть куча самых разных других работ, которые все разные у разных исполнителей. Процессное управление тут говорит «если всё такое неодинаковое, то это к проектному управлению, но наш одинаковый кусок у Васи мы бы обрабатывали именно так, относясь к Васе как к станку». В теории массового обслуживания это абсолютно нормально, там есть расхожий анекдот про общность постановки задачи в самых разных ситуациях процессного управления: «к городу подлетает эскадрилья бомбардировщиков, становясь в очередь на обслуживание зенитной батареей».

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

Есть ли пути улучшения этой ситуации? Да, есть. Нужно только заметить, что «одинаковая работа» всё-таки занимает обычно разное время, но чаще всего ровно столько, сколько запланировано (бывает, что позже, но никогда не раньше). Если учесть статистику опозданий и запланировать работу с риском неокончания её в этот укороченный срок, то можно запланировать половину времени на работу, а половину времени поместить в «буфер неокончания в запланированное время» в конце проекта. Если спросить Васю, сколько он будет делать MX, то Вася ответит 10 дней — ибо считает, что это будет с вероятностью 99%. И он таки потратит все десять дней! Но если ему дать на работу 8 дней, то он её завершит с вероятностью, скажем, 90% именно в этот срок — просто он для надёжности добавляет дни в своей оценке). Если сделать это «укорочение плана исходя из оценки 90% вероятности» с каждой работой, то можно рассчитывать на тот же эффект, который используется в страховых компаниях: проблемы будут не у всех работ, поэтому в реальности буфер можно делать меньшей длины. На диаграмме показано, что вот этот вариант с буферизацией за счёт учёта разницы во времени актуального выполнения работ по сравнению с запланированным может сэкономить ещё пять дней даже при использовании всего буфера проекта — и первый клиент получит результат через двадцать пять дней, а не через тридцать дней. Но буфер совсем не обязательно будет использован весь, поэтому в реальности результат может быть получен и на двадцатый день!

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

Практики управления процессами и управления кейсами

В начале 21 века позиции проектного управления были существенно подвинуты сторонниками процессного управления, которое главным образом развивалось в среде «автоматизаторов» (айтишников). Увы, из этой истории тоже ничего хорошего не получилось. Вот пример описания простейшего «процесса» похода к доктору, который выписывает рецепт к врачу, это выдержка из стандарта Business Process Model and Notation (BPMN) 2.0¹⁸²:

Такие диаграммы очень нравятся «автоматизаторам», которые пытаются описать в проектах всё одинаковое, назвать эти проекты «процессами» и затем это всё одинаковое автоматизировать. Особенность тут в том, что вроде как по такой диаграмме можно попытаться рассчитать и оптимальную загрузку каждого помянутого ресурса по типу рассуждений, которые были для проектного управления (найти критическую ресурсную цепь, где есть ограничение в виде Васи — и загрузить дальше Васю как станок, удавить мультитаскинг), но на практике это оказалось невозможным. Если у вас одиночный простой процесс (типа «забрать деньги, выдать товар» или «собрать вот эти три подписи на договоре»), то всё ОК. Но если речь идёт о хоть какой-то разработке, о какой-то уникальности, то всё пропало: сложность описания становится запредельной. А ещё ситуацию усугубляет то, что используются для описания процессов визуальные нотации, то есть любые изменения становятся проблемой при внешней наглядности. А в проектах? Там по факту используется «разбиение работ» (аутлайн, «дерево») и много более простые диаграммы Гантта¹⁸³.

Итого: управление процессами для целей операционного менеджмента «не пошло», оно помогало айтишникам что-то автоматизировать, но для работы с людьми по части управления порядком загрузки ресурсов (а мы только что убедились, что этот порядок важен для минимизации сроков выполнения проектов, «чистая арифметика» важна) оказывалось не очень пригодно. По факту «процесс» стало синонимом слову «практика» (труд, деятельность), а «работа» по этой практике — это «экземпляр процесса». С экземплярами процесса предмет (дисциплина из учебников) процессного управления не работал, отсылая к предметам дисциплин теории массового обслуживания/теории очередей и исследования операций. Но для «процесса заключения договора» в софте процессного управления всегда можно было найти, что происходит с каждым конкретным договором. Учебники управления (организационными) процессами/business-process management не рассказывали про то, что и как делать с «экземплярами», но софт работу с экземплярами поддерживал. Так что «управление процессами» по факту оказалось инженерной (про содержание работ, про практики), а не менеджерской (про логистику, про работы) практикой.

Засилье процессного подхода кончилось в одночасье:

Всё процессное автоматизируется и перестаёт называться «процессом» (и даже «автоматизацией»: при автоматизации часто меняется суть работы, одна практика заменяется совсем другой, управлять нужно уже совсем другим набором работ)
«Процессом» называют всё что ни попадя, но кроме названия там уже мало что остаётся от классической пошаговости¹⁸⁴. Это только кажется, что у людей в головах именно «процессы». В головах у них «практики», BoK вместо «пошаговых расписаний». Процессом также часто называют и вид жизненного цикла в целом (agile process, engineering process).
Упор на рабочие продукты (case management, issue tracking), облегчает договорённости — это отсылка к 4D, об этом мы расскажем чуть подробней ниже.
Практики мы описываем не как огромные методологии, в которых чётко прописаны длинные сценарии, а как отдельные короткие элементы практик, из которых можно по обстоятельствам собирать длинные цепочки — гранулярность обеспечивает ситуационная инженерия методов, которая рассказывает нам, из каких элементов состоят практики (всё это крутится вокруг альф, изменения состояния альф и т.д.). Акцент поэтому оказался не на собственно «процессах» как длинных цепочках (иногда это «маршруты» и обсуждается маршрутизация/routing, иногда это обсуждается как «сценарии», иногда как поток работ/workflow, то есть работы, идущие/flow через людей и компьютеры), а на инструментарии описания коротеньких процессов из их элементарных частей.
Декларативность (правила пред- и постусловий, а не указание последовательности), то есть длинные описания сценариев не существуют. Просто из какой-то библиотеки элементов кейсов последовательность работ собирается путём подбора нужных по предусловиям. Появился OMG CMMN (Case Management Model and Notation)¹⁸⁵ в дополнение к процедурному BPMN 2.0 как поддерживающий это язык, но он не получил распространения, декларативное программирование очень удобно для разных описаний, но очень тяжело в понимании (в классическом программировании «все хотят писать декларативно¹⁸⁶ — функционально или на логическом языке, но получается всё равно императивно» — с составлением длинных цепочек работ то же самое, «все хотят описывать их функционально или логически, но получается императивно», в процессном управлении приняты императивные описания «шагов программы/шагов работ»). Так же не получил большого распространения механизм декларативного описания организационных норм/business rules¹⁸⁷, не стали популярными реализующие его стандарты OMG SBVR¹⁸⁸ и привязанный к стандартам описания процессов OMG CMMN (декларативный) и OMG BPMN (императивный) стандарт описания принятия решений в ходе выполнения работ OMG DMN¹⁸⁹.

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

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

В ответ на все эти сложности и в проектном, и в процессном управлении родился ещё один подход, который по факту стал центральным/mainstream (пару раз поменяв при этом название): управление кейсами/ведение дел/case management. Сам этот подход появился из лечебных дел/case и судебных дел/case и тесно связан в его понимании как «папки Дело №___» или «папки истории болезни» (папка дела/case file).

Внимание для всех практик и работ в управлении кейсами удерживалось тем, что какой-то объект (предмет дела/кейса), который нужно было перевести из начального в конечное состояние становился точкой сборки. Это как vision в стратегировании определяет разные варианты mission и допускает разные работы по его получению, это как программа проектов должна достичь целей программы, а уж проекты в её составе могут быть самыми разными для достижения целей. Тем самым постулировалось, что «прибыть из точки А в точку Б можно огромным числом способов, работы могут быть разными, а вот закончиться они должны одинаково: прибытием в точку Б». При этом цель задавалась как vision (состояние мира), но сам кейс был mission, и тип кейса — даже не «практика», а «работа» (кейсы уникальны, если не уникальны, то это «шаблоны»). Запомнили: кейс::работа, «шаблон кейса»::практика.

Основной режим планирования в управлении кейсами — когда ты не знаешь заранее/upfront, что делать, поэтому планируешь работы «в связи с открывающимися обстоятельствами дела/case», как в судебных делах — с каждой новой найденной уликой или доказанным алиби планы следствия и суда меняются. Так же и в больнице, каждый новый анализ может открыть что-то такое, что полностью поменяет диагноз и направление лечения. С одной стороны, когда больной поступает в больницу, невозможно представить его прохождение по кабинетам в виде связного «процесса лечения», ибо там будет всё дико запутано — сто кабинетов со ста видами анализа и диагностики и ещё сто кабинетов со ста видами процедур лечения. С другой стороны, цель понятна: пациент здоров и выписывается. То есть каждый кабинет вроде как процессный (всё там одинаково — укол ставят и анализ крови делают «на потоке», всем более-менее по одной процедуре), а вот последовательность прохода по кабинетам разная для каждого кейса (где больной пациент — предмет кейса: его надо перевести в состояние «здоровый человек, не пациент»). И планирование идёт на каждом шаге.

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

Софт для такого отслеживания/tracking называется трекерами. Каждый кейс может быть назван проблемой/issue, поэтому софт этот — issue trackers (bug tracker, incident tracker и т.д.). Главное, что в трекере up front планирование вроде как не поддерживается отсутствует (непонятно, когда что будет делаться), но зато поддерживается up front «шаблонирование», в том числе если понятна грубо цепочка/маршрут, по которому должны будут пройти работы какого-то типа (работы по какой-то практике), то это можно заранее тоже записать в шаблоне. Но можно и без шаблона — записать просто для учёта/отслеживания. Помним, что очередной кандидат на пятое обязательное описание — это WBS, work breakdown structure (по факту это описание работ создателя). Это вот то же самое: попытка описать конфигурацию текущих работ, отследить возможный «развал конфигурации» (работы не имеют предмета работ, работы идут с игнорированием SoTA практики работ, работы идут по пять штук одинаковых над одним предметом работ, все ресурсы/исполнители назначены не на самые нужные работы и т.д.), но в case management разрешается планирование работы делать прямо перед её выполнением.

Тем самым issue trackers работ обычно идут в связке с репозиторием версий предмета кейсов (помним, что у каждой работы есть её основной предмет), но issues появляются там или up front (например, я заранее знаю, что ошибки будут, и делаю шаблон работ по исправлению ошибки, то есть прописываю практику, по которой будет порождена работа в момент появления экземпляра ошибки), или вот прямо после понимания, что какая-то работа должна быть сделана в ситуации, которую никто не предполагал (кейс «убрать царапину неизвестного происхождения, которая появилась на корпусе прибора вчера ночью»). Кейс таким образом проходит самые разные состояния, например: issue («непонятно, что делать и с чем, но vision есть — чтобы на корпусе не было царапины»), далее это становится task::«работа из проектного управления, которая понятно по какой практике делается, и понятно когда и кем» (mission — закрасить царапину и заполировать, делает Женя как самое срочное дело), но затем ещё и обязательно notice (мир изменился, и всех заинтересованных в его изменении надо оповестить об этом — этот шаг нельзя пропускать).

Итак, к программам проектного управления (диаграмма Гантта на экране и часами идущее «планирование» перед «выполнением плана работ») добавились программы процессного управления (заполнение формочек параметров экземпляра процесса по заранее подготовленным моделям процессов, если речь идёт о людях, но это может быть и полностью автоматизировано — тогда ничего заполнять не надо, но «процесс идёт хорошо, экземпляры процесса порождаются автоматически»), добавилось управление кейсами, где и практики (шаблоны кейсов) и работы (сами кейсы), и возможно upfront планирование, и возможно планирование работ, ведущихся «открывающимися обстоятельствами дела» и дальше не столько планирование и отслеживание выполнения плана, сколько отслеживание/tracking хода работ (ибо плана-то нет, разве что «шаблоны», где они осознанны и документированы).

Управление программами тем самым — это такое управление кейсами, где работа-проект планируется непосредственно перед её выполнением, но для неё не говорится о практике (шаблоне), ибо вроде как для проектов не должно быть какой-то повторяемости. Управление кейсами оказалось всеохватным, при этом чтобы как-то отстроиться от чисто медицинских «историй болезни» и судебных «дел», это всеохватное управление кейсами начало себя называть как динамическое/dynamic управление кейсами, адаптивное/adaptive управление кейсами (самое популярное), были и другие модификаторы названия.

В реальности в каждом большом проекте можно встретить какие-то его части, которые были сделаны согласно требованиям какой-то из школ управления. Хорошим примером тут был случай зимней олимпиады 2014 года в Сочи, где в управлении было примерно 5000 кейсов от строительства (внутри эти кейсы велись программами проектного управления), примерно 5000 кейсов пришли от системы управления качеством собственно Олимпиады (выполнение требований Олимпийского комитета) и ещё примерно 5000 кейсов пришли в качестве поручений от первых-вторых лиц государства. Тем самым под управление российской командой организации олимпиады попало примерно 15 тысяч кейсов¹⁹⁰. Поскольку в самом начале работ было непонятно, что это за такой странный объект у них в управлении (кейс-менеджмент не рассматривался, ибо на слуху у всех было «проект» и люди хотели получать премии за выполнение проектов), то примерно 35 человек из Microsoft написали специальный софт для сопровождения этого винегрета «проектов на контроле». Терминология использовалась проектного управления, но перед самым стартом Олимпиады люди сообразили, что это кейс-менеджмент! И появилась идея по-быстрому перегрузить все 15 тысяч кейсов в простую программу issue tracker (предлагался open source Redmine¹⁹¹, тем более что он позиционировался не как issue tracker, а как «flexible project management web application»). Этого не случилось, поскольку эти идеи появились буквально за три недели до старта Олимпиады, и просто испугались каких-то потерь данных при переливе информации по 15 тысячам кейсов плюс какому-то переучиванию людей команды. Решили, что «продержимся ещё три недели, потом Олимпиада — и всё, конец истории». Но если бы люди понимали суть управления кейсами, то жизнь их была бы проще!

Управление кейсами потребовало не только отдельной идеологии, но и отдельных программ (простые issue trackers явно не учитывали полноценного варианта case management в части адаптивности, которая понималась как «шаблоны готовят непрограммисты») — а поскольку выяснилось, что эти программы решают огромное количество проблем, то они были выпущены и стоили баснословные деньги. Это всё случилось как раз в 2013-2015 году, и потом идеи адаптивного управления кейсами исчезли под этим названием, но не исчезли из жизни:

Большинство issue trackers были переименованы в «программы управления проектами», хотя помним, что они появились сначала по линии процессного управления, ибо «шаблоны кейсов» были по факту описанием практик! Но процессное управление «про практики», а работами-проектами надо было управлять, поэтому победило слово «проектное управление», но оно оказалось не тем, что в классическом проектном управлении, совсем другое body of knowledge! С другой стороны, чтобы быть более похожими на программы проектного управления кейсы могли быть представлены на верхнем уровне в современных программах в виде диаграмм Гантта!
Появились универсальные табличные моделеры (notion.so, coda.io и прочие), которые хорошо подходили под идеи LowCode и NoCode. Это LowCode формулировалось как «непрограммисты могут написать какие-то простейшие процессы/workflow», то есть код, поддерживающий отслеживание/tracking работ по какому-то шаблону. Но это как раз совпадало с тем, о чём говорилось в adaptive case management. Дорогие специализированные программы управления кейсами массово начали отпадать, и прототипирование работы с шаблонами кейсов массово перешло в это универсальное моделирование. Но если кейсы по каким-то шаблонам оказывались реально массовыми, или оказывались кейсами не изменений в реальном виде, а кейсами обработки информации, то это просто переносилось в специализированный «процессный софт».

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

Тут важно, что вопрос из предыдущего абзаца задан некорректно. Для этого вернёмся к 4D представлению мира:

Вот Вася готовит капучино для Клавдии в реальном мире, прямо в физическом мире, в 4D (то есть он, кофе, молоко, кофе-машина, чашка и т.д. занимают пространство-время), он работает.
А вот Илья, имеющий знания по проектному управлению, описывает это как проект (каждая чашка кофе уникальна, каждый посетитель требует что-то своё! Это неважно, что эти проекты похожи: в учебниках этого нет, но просто задействуем софт проектного управления достаточно мощный, чтобы в нём был «шаблон проекта». При этом помним, что в проектах есть подпроекты, а проекты получаются из программ. Так что берём программу «сделать Клавдию довольной», порождаем проект «напоить капучино», там внутри, конечно, подпроекты приготовления кофе, капучинирования, подачи. Можно хорошо описывать разделение труда, привлечь Петю для капучинирования!). Получается, что работа сама происходит в 4D уж как происходит, но она описана как проект! Проектное управление в его классическом варианте — это метод описания, viewpoint, а описание — это всего лишь view на работу, а не сама работа! Правильно говорить не «работа Васи — это проект», а «работа Васи описана/классифицирована как проект»!
То же рассуждение для Ольги, имеющей знания по процессному управлению, она описывает это как процесс. Не будем расписывать подробно. Работа в физическом мире, но она будет описана как процесс, это только одно из возможных описаний.
И Крис, который только-только узнал об управлении кейсами, он опишет эту работу Васи как кейс — но это никак не помешает существовать описаниям Ильи этой работы как проекта (и даже программы работ!), и описанию Ольги как процесса, и описанию Криса как кейса.

Нет «на самом деле» проектов, процессов, кейсов! Это всё разные акценты моделирования одной и той же реальности живой работы (а хоть и будущей, у нас 4D).

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

Каждый вариант нарезки мира работ по факту ведёт к выбору софта, который хорошо поддерживает ответы на какие-то определённые вопросы:

Проектное управление (графики работ и задействования ресурсов — отвечает на вопрос «когда кто что должен делать»? И помним, что без нормирования работ, учёта ресурсов, возможности знать все работы до начала проекта — не работает, ответа на вопрос не будет!)
Теория массового обслуживания (потоки и очереди — переварим всё однородное за минимальное время! Сколько надо иметь ресурсов, чтобы мы справились? Но нет ответов на вопрос «когда и кто будет делать», это всё «в рабочем порядке»)
Процессный подход в смысле BPMN (кто что должен делать, но вот когда — непонятно, «когда работа будет готова»)
Адаптивное ведение дел/case management/«отслеживание/tracking проблем/issue, багов/bugs, происшествий/incident» и дальше разные варианты Workflow с LowCode и даже NoCode (тут обычно agile/шустрость в реакции на непредсказуемое: удерживать во внимании цель, чтобы её достичь, но по какому маршруту пойдут работы, и какие они будут, заранее неведомо. Но мы удержим внимание!)
Потоки пользы / value networks¹⁹² (бизнес, т.е. кому это выгодно). Мы не поминали это, но в некоторых организационных практиках такое описание работ тоже может использоваться — чтобы обнаруживать работы, которые не приносят никакой пользы. В этих сетях указывают оргроли, и кто кому что предоставляет (deliverables) — чтобы на выходе получить итоговую систему, дающую пользу. Но легко представить, что речь идёт о работах, которые надо выполнить, чтобы получить эти deliverables.

Так что мы рекомендуем:

Где можно, используйте кейс-менеджмент, ибо там наиболее общее описание работ. Объявляйте альфы как объекты внимания в проекте кейсами, описывайте их состояния, формулируйте для этого контрольные вопросы, добивайтесь ответов на контрольные вопросы путём выполнения работ, которые ведутся по каким-то практикам. Всё это моделирование записывайте в табличном формате, или используйте какой-то подходящий софт (например, PLM-систему, если речь идёт о машиностроении или стройке).
Смело смешивайте любые описания, если вам нужны какие-то ответы на вопросы, или решение каких-то проблем. Например, смело называйте кейс проектом, или даже программой. И задействуйте issue trackers, которые сейчас тоже называются софтом управления проектами (хотя этот софт совсем не похож на софт классического управления проектами). На верхней паре уровней декомпозиции кейсов на подкейсы огромного проекта говорите «директивный график» и переходите на язык классического управления проектами (ибо там будут «директивные сроки», которые даже не прогнозные, а предписанные по интуитивным оценкам дедлайны, конкретные даты). Вас поймут все менеджеры. А ниже переходите на язык разговора о кейсах и отслеживания/tracking проблем/issues, только часть из которых известна upfront/перед началом работ — и вас будут понимать все разработчики, архитекторы и инженеры платформы/DevOps/internal development platform engineers. Общий принцип: с менеджерами старой закалки говорите на языке классического управления, это будет ласкать им слух (даже в случае работ по разработке, к чему категорически проектное управление противопоказано), а с инженерами «от сохи» говорите на языке управления кейсами.
На забывайте, что основных альф у нас много — на каждое звено цепочки создания по нескольку, и нужно ещё добавлять подальфы, ибо основных альф обычно не хватает для разбирательства с состоянием проекта. То есть работы должны быть и непосредственно меняющие состояния альфы «воплощение системы», и альфы описания системы, и альфы описания работ системы, и для нужных вам альф в зоне интересов к надсистеме — и это для каждой системы в цепочке создания.
Все неожиданности (включая обнаружение и исправление ошибок, а также выдача поручений начальством «из ниоткуда») должны рассматриваться как кейсы, иначе запутаетесь.

TEST Проекты, программы, процессы, кейсы

!!! Серафима на заседании настаивает, что выполнение договора по высадке 100 деревьев в парке — это процесс. Дженнифер утверждает, что это кейс. Нуржигит говорит, что это проект. Кто прав?

--- Серафима, ибо 100 деревьев это точно что-то повторяющееся. ### Нет, выполнение договора — это выполнение договора, хотя можно рассмотреть его как процесс. Процесс — это только одно из возможных описаний/view этих работ.

--- Дженнифер, ибо непонятно, что мы встретим в выполнении этих 100 работ как целого, и работ по высадке отдельных деревьев. Да, там будет что-то повторяться, так это просто шаблон кейса. ### Нет, выполнение договора — это выполнение договора, хотя можно рассмотреть его как кейс с подкейсами. Кейс — это только одно из возможных описаний/view этих работ.

--- Нуржигит, ибо это совершенно уникальные работы в уникальном месте с уникальными условиями, и мы хорошо понимаем, сколько примерно времени займёт высадка одного дерева, можно говорить о нормировании работ. ### Нет, выполнение договора — это выполнение договора, хотя можно рассмотреть его как проект. Проект — это только одно из возможных описаний/view этих работ.

+++ Все ошибаются. Выполнение работ — это выполнение работ, изменения в физическом мире, само по себе выполнение работ не есть «процесс», или «проект», или «кейс». ### Да, мы какие-то работы можем описать как процесс, проект, или кейс. Это не означает, что сами работы вдруг стали процессом, проектом, кейсом, программой.

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

!!! Можно ли одновременно использовать разные методы управления работами?

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

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

!!! Когда говорят «процесс проектного управления», что имеют в виду?

--- последовательность шагов процедуры/алгоритма, по которому идёт управления проектом (сначала открыть проект, потом запланировать работы, после этого начать работы и следить за выполнением плана и т.д.). ### Нет, слово «процесс» давно уже не относят именно к шагам, чаще всего оно означает «практику» или даже «метод». Хотя и могут говорить о практике открытия проекта, практике планирования работ, но это не последовательность шагов — это именно практики.

+++ просто это практики проектного управления, «процесс» тут синоним «практики» ### Да, это наиболее вероятно. «Процесс» как развёртка чего-то во времени уже редко используется в менеджменте, чаще в инженерии. Хотя «процессное управление» ещё работает с шагами процесса.

!!! Вам нужно выбрать софт для управления работами в вашей компании. Вы ожидаете, что будет довольно много работ по разработке, плюс придётся время от времени управлять муторными однообразными процедурами тестирования оборудования, а ещё обрабатывать мелкие поручения клиентов, вечно чем-то недовольных. Феликс предложил для управления работами использовать софт проектного управления, хотя бы входящий в MS Office Microsoft Project, ибо такой софт предназначен как раз для управления работами! Лидия предложила купить софт управления процессами, ибо процесс разработки, процесс тестирования, процесс выполнения поручений клиентов — это всё бизнес-процессы, а в этом софте есть и BPMN, можно написать это всё на языке Business Process Model and Notation. Виталия предложила использовать issue tracker, который используют программисты и системные администраторы компании: просто начать использовать его ещё и для всех некомпьютерных работ. Чьей рекомендации нужно последовать?

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

--- Лидии. ### Нет, ничего особо повторяющегося в разработке и в поручениях нет, и ход на компьютеризацию/автоматизацию тут тоже не пройдёт. BPMN будет бесполезен, хотя можно думать о его использовании при автоматизации помянутых «муторных однообразных процедур тестирования», но вот отработку неожиданных результатов этого тестирования (непрохождение тестов) всё равно придётся делать другими средствами.

+++ Виталии. ### Да, вполне можно приспособить issue tracker для управления работами, если там есть разработка и выполнение поручений. И можно даже использовать issue tracker для работы с чеклистами при выполнении «муторных однообразных процедур тестирования», а то и автоматизировать их (скриптование каких-то «процессов» есть в большинстве issue trackers, хотя необязательно на языке BPMN).

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

--- будем вести обычные протоколы на совещаниях по управлению работами, никакого софта, софт — это лишние хлопоты по его разворачиванию и поддержанию в актуальном состоянии. А протоколы — это классика, она вечно живая! ### Нет, протоколы непригодны для дел, которые не успеваются выполниться за неделю. В даже небольших программных проектах, например, проходит от 6 тысяч работ: какие протоколы переварят это количество? А ведь ни одну из них нельзя пропустить! Так что нужно от протоколов всё равно переходить к софту управления работами.

!!! К вам пришёл Гарегин, которому вы поручили на предыдущих трёх совещаниях 15 дел, а ещё до этого у него уже было недовыполненных 8 дел (всего ему поручили 23 дела). Каждое дело небольшое, на несколько часов или максимум на пару дней. Вы понимаете, что месяца на них всех вполне должно хватить. Гарегин рассказывает, что тратит на выполнение каждого дела примерно по 20 минут в день, иначе он не может гарантировать, что хоть как-то движутся все порученные ему вами дела. Что он делает не так?

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

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

Упражнение

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

Номер п/п	Название работы	Какой термин используют?	Какую методологию управления работами используют?
1.
2.
3.

«Распожаризация» и управление работами

Главное — это понимать, что операционный менеджмент в конечном итоге сведётся к правильному размещению во времени потока/flow работ (по-русски вместо «потока» говорят «ход», отсюда и неминуемые «шаги», в английском используются разные слова, чтобы подчеркнуть непрерывность и дискретность — поток, работы текут!) по ресурсам-агентам, которые ведут эти работы. Так что организация для управляющего работами/операционного менеджера — это сеть, по которой текут работы, а главный интерес — поднять throughput/«проход» как то, что протекает через сеть ресурсов-агентов, работающих по каким-то практикам, чтобы получить на выходе или товар-продукт, или обработанную чужую целевую систему как «предоставление сервиса». В одну сторону (от поставщиков сырья или исходной информации) текут потоки вещества, информации, работ и вытекают из фирмы к клиентам, а в другую встречным потоком текут деньги, из которых происходит оплата за каждый ресурс, проводящий обработку потока. Поэтому на обложку книги по нашему курсу попал фрагмент дорожной сети, в которой всё запутанно, но пока вроде как всё едет. Тем не менее, в дорожной сети легко образуются «пробки», когда уже никто никуда не едет. На работе это характеризуется «пожарами» и «авралами», когда самые разные люди вдруг обнаруживают, что всё вдруг резко остановилось или вот-вот встанет в масштабах фирмы из-за того, что они что-то не успевают. Как выполнять «распожаризацию»? Понятно ведь, что если автомобильчиков много, то пробки всё равно будут — а уж если всё остановилось, то и убрать пробку быстро нельзя! Будет «непрерывный пожар и аврал», но это совсем не та «непрерывность всего», которую мы хотим!

Тут есть следующие шаги:

Нужно выполнить инженерную работу по принципам Lean/элегантности. То есть надо найти то, что можно не делать — и при этом риски что-то ухудшить останутся более-менее приемлемыми. Учтите, что вы сейчас собираетесь резко ускорить работу. Ненужную работу не нужно ускорять, она вредит делу! Поэтому просто перестаньте эту работу делать. Элон Маск как-то сделал замечание, что если вам не приходится возвращать одну из десяти убранных работ, то вы слишком мало убираете ненужных работ: ищите их тщательней! Это инженерная, содержательная работа.
Ни в коем случае не начинайте ускорять работы, пока вы не наладили управление конфигурацией (помним про учёт и контроль, в том числе про включение разбиения работ/WBS в управление конфигурацией, в том числе это относится к кейсам — все кейсы, которые знаете, надо учитывать/отслеживать/track, используйте правильный софт для этого). Операционный менеджмент требует операционного учёта, учёта экземпляров, и учёт тут всего, включая деньги. То есть сначала надо добиться того, что вы ничего не делаете дважды и трижды из-за конфигурационных коллизий. Если у вас в проекте беспорядок, то вы будете быстро-быстро производить эти конфигурационные коллизии: подавать к супу вилку, варить в супе вместо картошки хлеб, потом говорить «ай, извините» — и переделывать это всё. Нет, сначала наладьте управление конфигурацией. Помним, что это «серая зона» между менеджментом (поскольку вроде как «учёт») и инженерией целевой системы (поскольку объекты учёта дают инженеры целевой системы, при этом если речь идёт о собственно организации-создателе в цепочке создания и оргпроектах, то тут менеджеры и есть те самые инженеры, к ним все слова про управление конфигурацией организации тоже относятся. Автор этих строк как-то консультировал холдинг, в котором невозможно было найти актуальную версию органиграммы: вроде как в фирме были подразделения, только никто не знал, на текущий момент, какие они!). Это тоже инженерная работа, в «Системной инженерии» делали замечание, что эту «серую зону» мы отдаём инженерам, а не менеджерам (кроме, конечно, управления конфигурацией самой организации). В какой-то мере это обратная работа для первого пункта: если по первому пункту делалась лишняя работа, то тут наоборот, не делалась какая-то важная работа по управлению конфигурацией, что вело к коллизиям и повторным работам. Чтобы убрать много инженерной работы, нужно добавить немного учётной работы, «навести бюрократию».
Дальше устраняем wait time, время пауз в работе. Берётся специфическая точка зрения «изнутри работы», то есть это время, которое объект обработки готов принять работу ресурса над собой, но его не трогают, поскольку ресурсы заняты чем-то другим, или просто не знают, что нужно обрабатывать этот объект. Это терминология подхода TameFlow, которая по большому счёту и отражает современное состояние операционного менеджмента — то, как именно нужно «управлять работами» (помним, что без предыдущих двух пунктов использование этой книги будет вредным! Вы резко ускорите беспорядок! Будет не хаос и пожары на работе, а крайне быстрый хаос и пожары!). Вот это «устранение времени пауз», предотвращение «пробок» в работе, поддержание стабильного скоростного потока — это и есть операционный менеджмент.
После того, как вы добились успеха в устранении времени пауз (там очень, очень много нюансов, для их понимания нужно читать специализированные учебники операционного менеджмента, в нашем общем курсе менеджмента мы не сможем об этих нюансах рассказать, но только скажем, какие учебники надо читать), вам нужно опять обратиться к инженерии и заняться уменьшением времени обработки рабочих продуктов на определённых операциях (touch time), которые будут вам даны по итогам предыдущего шага. Важно, что не нужно сокращать время любых производственных операций, а только находящихся на критических местах в потоке работ — вся арифметика для нахождения этих мест вам будет дана на предыдущих шагах. И это опять будет инженерная задача, которая потребует уже решений по существу инженерного вопроса, а не чисто менеджерская задача по распределению работ по ресурсам и учёту выполнения этих работ.
Не давайте инерции себя остановить! Вернитесь к пункту 1 и повторите всё с самого начала: выкиньте лишние операции, наладьте управление конфигурацией (операционный учёт), займитесь принятием решений по уменьшению времени пауз в работе, а затем вернитесь к определению тех операций, которые нужно изменить инженерно, чтобы сократить их время.

Упражнение

Опишите от трёх потоков в вашем рабочем проекте.

Номер п/п	Что течёт (конфигурационные единицы)	Примеры «рабочих станций» для обработки потока	Являетесь ли вы рабочей станцией, перед которой есть «затор»?	Кто исполняет роль операционного менеджера, увеличивающего проход этого потока?
1.
2.
3.

TEST Управление кейсами

!!! На чём фокусируется кейс?

--- На действиях ### Нет, на действиях фокусируются практики проектного и процессного управления прежде всего.

+++ На предмете, над которым производятся действия ### Да, именно так. Кейс — ситуация, обстоятельства или начинание, которые требуют набора действий для получения приемлемого результата или достижения цели. Кейс фокусируется на предмете, над которым производятся действия (например, человек, судебное дело, страховой случай), и ведется постепенно появляющимися обстоятельствами дела.

--- на исполнителях действий с каким-либо предметом ### Нет, на исполнителях действий (акторах/актёрах) фокусируются подходы, обсуждающие организацию команды, это вопрос оргдизайнеров.

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

!!! Почему приложения low code могут не оправдывать ожиданий?

--- они работают очень медленно ### Нет, у них скорость работы не больше и не меньше, чем у любых других приложений.

--- софт low code очень дорогой ### Нет, стоит такой софт очень по-разному, нельзя сказать, что дороже любых других приложений.

+++ хорошо работают на простых демонстрациях с малым числом объектов, но всё равно требуют профессионального программирования для массовой работы (то есть свойство low code не выполняется) ### Да, именно так: заявление, что программисты не нужны, верно только для прототипирования, в массовой эксплуатации всё равно нужны программисты. Но справедливости ради, надо заметить, что огромное число прототипов оказывается достаточным: отнюдь не всеми приложениями пользуются тысячи и тысячи людей, а для нескольких человек LowCode может дать отличные результаты.

+++ они используют визуальные языки описания процессов, которые ужасны при росте объёма программ ### Да, именно так: визуальные языки описания очень хороши и наглядны только для крошечных примеров, демонстрируемых менеджменту в момент покупки. Для сложных программ работает только текстовое представление, профессиональные программисты не пишут на визуальных языках, они «не тянут». В приложениях low code всё равно нужны профессиональные программисты, и они получают при этом неудобный для них инструмент: визуальное программирование.

Упражнение

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

Номер п/п	Кейс или подкейс	Состояния	Подкейсы	Примечание
1.
2.
3.

Заполните табличку по операционному софту (от трёх приложений), который вы используете в проекте:

Номер п/п	Приложение	Учёт каких экземпляров ведётся в софте	Какую дисциплину поддерживает приложение
1.
2.
3.

Заполните табличку по софту трекинга кейсов/issue tracker, который вы используете для рабочих и личных дел (от трёх, включая списки дел на бумаге и в файлах Ворда):

Номер п/п	Приложение для issue tracking	Специализировано ли приложение для case management/issue tracking	Какие дела в нём ведутся
1.
2.
3.

Основные книги по современному операционному менеджменту

Вот базовая книга по управлению работами: Steve Tendon, «The Book of TameFlow», 2022:

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

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

Основные идеи, которые лежат в основе менеджерских решений в части операционного управления — это идеи по управлению самыми разными типами потоков (не только потоков работ) из практик:

сomputer operating systems
control engineering
data communications networks
finance and economics
information theory
maneuver warfare
manufacturing
operations research
probability and statistics
queueing theory

Идеи изо всех этих практик были собраны и относительно популярно (без зубодробительных формул) изложены в книге Donald Reinertsen «The Principles of Product Development Flow», 2011 (по сути — это книга «теории» операционного менеджмента, в то время как предыдущая книга больше была посвящена нормативной практике):

В этой книге в том числе очень чётко объясняется про использование принципов управления потоком при разработке/development, а не при производстве/manufacturing. Легко увидеть «пробку» на пути каких-нибудь заготовок на заводе, это будет «затор» в виде груды заготовок перед каким-нибудь станком, или затоваренного продукцией или сырьём склада. А как увидеть «затор» в разработке, где «станки» — это компьютеры? В разработке:

Есть циклы (пробы гипотез), их число заранее неизвестно.
Есть тупики (отброшенные гипотезы), их число заранее неизвестно.
Иногда требуется время на размышление, а поскольку это не физическая работа, нормировать её невозможно, это время нельзя точно оценить.
Собрать результаты размышлений вместе — это совсем не похоже на то, как собирается конструкция из точно изготовленных деталей! Время на такую сборку плохо поддаётся оценке.
Модели/описания систем легко изменить по сравнению с самими системами/воплощениями систем. В описаниях легко исправить ошибку, но легко её и внести (а найти ошибку одинаково трудно и в описании, и в воплощении).
Хорошо известные способы оптимизации проектов и процессов (например, «маленькая партия для обработки») плохо работают: какая такая «маленькая партия для размышления», как её выделить из всех размышлений?

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

Мы не даём много дополнительной литературы, ибо она сегодня общеизвестна (например, книги Элияху Голдратта и его коллег по теории ограничений, или книги Давида Андерсона десятилетней давности по канбану в разработке). На все эти книги есть ссылки в предложенных нами двух книгах.

Тут ещё много нюансов, но в нашем обзорном курсе вряд ли мы сможем рассказать о них всех. Например, использование визуальных средств для управления работами: скажем, Trello очень нравится менеджерам старой закалки, потому что у них редко бывает 200-300 кейсов/issues на контроле, и красивые раскладки карточек на бумаге радуют глаз. У программистов легко в небольшом очень проекте получаются 6000 кейсов/issues, и они ещё привязаны к системе версионирования, и тут нужна нормальная табличная работа в программах, которые не будут нравиться менеджерам старой закалки. В некоторых фирмах вместо issue tracker используют протоколы, которые не выживают больше одного приноса на совещание (максимум двух приносов), поэтому всегда проблемы с «забытыми задачами». Некоторым особо ценным сотрудникам разрешают нарушать принцип «не записано в issue tracker, значит, работа не сделана» — и не увольняют их за нарушение производственной дисциплины, ведущей к конфигурационным коллизиям, потом удивляются, что никак не удаётся потушить авралы и пожары (но это же пункт 2 в нашей истории — наладить контроль конфигурации).

В принципе, весь этот материал пригоден и для управления собственными работами. Поэтому в курсе «Собранность» довольно много отсылок к TameFlow именно для операционного менеджмента личных работ, но вам не помешает также и знакомство с идеями Product Development Flow, их тоже вполне можно применить к менеджменту личных работ. В курсе «Собранность» тоже подчёркивается важность моделирования (ничего не держать в голове! Мозгу не верим! Всё записывать!), весь операционный менеджмент держится на хорошо налаженном моделировании работ и рабочих продуктов, то есть на хорошо налаженном операционном учёте. В основе практик time management (так иногда называют операционный учёт для личности), или практик личной продуктивности (есть и такое название) лежат модификации довольно древней практики GTD¹⁹³, где главное ровно вот это: всё записывать, ничего не помнить, голова должна быть свободна от планов — все планы нужно выгрузить из головы в экзокортекс, но иметь привычку регулярно (несколько раз в день!) заглядывать в списки дел и заниматься стратегированием и планированием. Из современной литературы по управлению собственными работами можно посоветовать книги Максима Дорофеева¹⁹⁴.

Задания

Поставьте отметки о выполнении следующих дел:

Прочтена книга Steve Tendon, «The Book of TameFlow», 2022. Опубликовано в блоге эссе с мыслями, пришедшими в голову по ходу прочтения книги (без этого эссе книгу нельзя считать прочитанной).
Прочтена книга Donald G Reinertsen «The Principles of Product Development Flow: Second Generation Lean Product Development». Опубликовано в блоге эссе с мыслями, пришедшими в голову по ходу прочтения книги (без этого эссе книгу нельзя считать прочитанной).
В рабочем проекте использована как минимум одна практика операционного менеджмента книги «The Book of TameFlow» и опубликовано эссе с описанием этого эксперимента и его результатов.
Опубликовано эссе о том, что наиболее контринтуитивно в принципах, изложенных в книге «The Principles of Product Development Flow».
Опубликовано эссе с обзором современных практик управления личной эффективностью (включая, но не ограничиваясь практиками из литературы, приведённой в нашем курсе. В эссе включить результаты эксперимента по использованию каких-то из практик управления личной эффективностью, в том числе и личного опыта попыток переноса практик корпоративного операционного менеджмента в адаптированный для себя метод достижения личной продуктивности).

Управленческий финансовый учёт и контроллинг

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

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

TameFlow рекомендует Throughput Accounting, построенный на идеях маржинализма (вы должны были уже понимать эти идеи из материала по австрийской школе экономики, именно эта экономическая школа совершила маржинальную революцию в экономике). Вся экономика фирмы базируется на маржинальных рассуждениях, которые операционным менеджерам надо хорошо понимать. Так, бессмысленно спрашивать о выгоде проекта, если непонятны текущие производственные мощности и их текущая загрузка. Сферический проект в вакууме не может быть оценен как выгодный или невыгодный! А ещё все рассуждения про «себестоимость» немаржинальны, ими опасно пользоваться при оценке работы фирмы. Так что управленческий СебеУчёт должен строиться на принципах маржинализма, и этому хорошо соответствует как раз Throughput Accounting. Подробности можно узнать в паре книжек. Первая — это Томас Корбет, «Учёт прохода. Управленческий учёт по ТОС» (оригинал вышел в 1998, финансовый учёт — очень консервативная практика!):

Вторая книга — это John and Pamela Caspari, «Management Dynamics: Merging Constraints Accounting to Drive Improvement», 2004:

Добавить сюда нужно идеи юнит-экономики, но книг по ней нет, ибо материал важный, но укладывается в размер статьи¹⁹⁵:

Тоже плод маржинальной революции, отвечает на вопрос «зарабатываем ли мы на конкретном потребителе» — особенно популярен для «цифровой экономики» (где один сервер обслуживает тысячи клиентов).
Учитывает то, что потребителей не бесконечное количество, и стоимость продукции падает с увеличением выпуска, а привлечения новых покупателей (юнитов, приносящих прибыль — их число предполагается увеличивать, «масштабирование») — растёт. Это «маркетинг-озабоченный учёт», важен для привлечения внимания к факту зависимости экономики от масштаба выпуска, а масштаба выпуска от маркетинга (а не от производства!).
В зарубежной литературе могут по-старинке пользоваться ROI (return on investment) или ROMI (return on marketing investment) — всё то же самое, что в юнит-экономике, но относимое к инвестициям в конкретную продукцию и конкретный канал дистрибуции (показатели для разных продуктов и разных каналов дистрибуции будут разными)
Главный показатель — LTV (lifetime value — сколько принесёт один юнит за всю свою историю) и CA (cost of acquisition — сколько нужно денег на маркетинг, чтобы заполучить юнит).

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

Из современных трендов нужно указать также тренд перехода от ежегодного бюджетирования к ежеквартальному, ежемесячному, а затем (в пределе) ежедневному — когда решения о направлениях траты денег принимаются не заранее за год, а по мере возникновения потребности в деньгах и с учётом текущих приоритетов, а не приоритетов, которые были, возможно, аж за год до момента актуального расходования бюджета. Это движение «скользящего окна финансового планирования» «за пределами бюджета», beyond budgeting¹⁹⁶. Для этого направления есть уже довольно много литературы, оно скрывается под разными именами. Там есть довольно много особенностей¹⁹⁷ (большинство из них связаны с тем, что планировать расходы ограниченно, но можно, но есть большой соблазн планировать и доходы! А вот это опасно. Помним, что «стратегирование» в менеджменте появилось в 40х годах прошлого века как раз как «бюджетирование» и только потом стало независимой практикой, потихоньку избавляясь от ошибок. Но эти старинные ошибки все вполне могут присутствовать в практиках бюджетирования).

TEST Много разных финансовых учётов

Мария утверждает, что учёт должен быть в фирме один: нельзя считать разные показатели из одних и тех же первичных финансовых документов! Ольга считает, что наоборот: из одних и тех же документов нужно выводить разные показатели. Кто прав?

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

+++ Ольга. ### Да, показателей должно быть много, хотя они и выводятся из одних и тех же первичных финансовых документов. Разные проектные роли используют разные принципы финансового учёта, и каждая проектная роль должна получить понятные и удобные для принятия их управленческих решений цифры. Другое дело, что все эти решения должны быть согласованы между собой, но это не отрицает идеи множественности учётов.

Задание

Поставьте отметку о выполнении:

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

7. Практика организационного дизайна

Оргразвитие: оргдизайнеры и лидеры

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

Оргдизайнер/оргпроектировщик — проектирует организацию (с учётом архитектурных и бизнес-решений, задаваемых архитектором организации и бизнесменом соответственно)
Лидер — «изготавливает» организацию, проводя организационные изменения (размещая людей или даже более крупные оргзвенья на предназначенные им организационные места, мотивируя их выполнять оргроли, на которые этим оргместа назначены и катализируя сотрудничество между оргзвеньями, действующими в этих ролях).

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

Результатом практики организационного развития будут новые оргвозможности/capabilities. Проекты/кейсы/шаги организационного развития имеют предметом кейса новые оргвозможности: выпуск нового продукта, переход на новую технологию, переход к какой-то новой практике.

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

Проекты организационного совершенствования не связаны с освоением новых практик, но связаны главным образом с решением задач операционного менеджмента: это оптимизации прохода и оптимизации в администрировании. Основное в них то, что людей не нужно учить новым понятиям, потому как не меняются практики, хотя могут меняться технологии. Process of ongoing improvement (POOGI)/Практика непрерывного совершенствования в теории ограничений — это цикл непрерывного ускорения прохода. Совершенствованием могут заниматься люди с менеджерской специализацией, это главным образом разбирательство с уменьшением времени пауз, а также уменьшением времени на координацию (этого мы коснёмся чуть позже: когда работу какая-нибудь Николь делает пять минут, но чтобы она этим занялась, вам нужно получить 12 виз от разных очень занятых людей — и это занимает полгода разговоров. Не нужно осваивать никаких новых практик, нужно просто прекратить собирать эти подписи в таком количестве, и жизнь существенно ускорится!).
Проекты организационного развития связаны с освоением новых практик, которые определяются их дисциплинами, описывающими новые объекты внимания, новые domains. Организация заводит новые оргвозможности, которые позволяют сделать что-то новое (совершенствование этого не позволяет, оно позволяет только быстрее делать всё то же самое, замена одного станка старой марки на станок новой марки — это ещё не оргразвитие, это просто «гигиена», но если у нового станка новый принцип работы и нужно научить людей новой дисциплине, то да — это будет оргразвитие). Интересно, что новые практики совершенствования (практики принятия решений операционными менеджерами) — это тоже будет результатом шагов/проектов/кейсов развития. И изменение организационной культуры тоже будет результатом оргразвития, ибо это означает изменение практики думать и делать что-то согласно каким-то паттернам мышления и поведения в организации, нужно людей переучить. Не говорим «внедрение» практик — организаторы ничего не «впихивают-внедряют, а люди пищат-сопротивляются этому вторжению». Говорим про проекты развития со стороны организаторов о постановке практик, а со стороны организуемых — об освоении практик, и не забываем, что после постановки и освоения практик нужно ещё дать полномочия по тратам ресурсов на выполнение новых практик («уметь делать» — это ещё не «делать»).

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

Оргдизайнеры проектируют части организации, которые реализуют стратегию развития предприятия в части того мастерства выполнения практики, которое это предприятие должно получить и затем превратить в оргвозможность (всегда помним, что «мочь и уметь что-то сделать» вовсе не означает «хотеть и делать» или даже «иметь возможность делать, и делать». Это верно и для личностей, это верно и для организаций. Ещё раз подчёркиваем, что разговор про личности и организации очень похож, хотя терминология может различаться). Лидеры затем работают с людьми, чтобы они воплотили оргпроект — катализируют сотрудничество людей, причём в этом сотрудничестве каждый сотрудник должен выполнять какую-то предписанную ему роль и быть обеспеченным необходимыми для выполнения этой роли ресурсами.

Из курса «Системная инженерия» мы знаем, что разработчики:

Руководствуясь стратегией и информацией от продвиженцев по поводу надсистем и внешних проектных ролей, а также лично общаясь с потенциальными и актуальными клиентами, делают предположение о том, что нужно от целевой системы для того, чтобы она выполнила какую-то полезную клиентам функцию в надсистеме. Отражают это в модели «концепция использования» (ConOps или OpsCon, и иногда есть нюансы в их различении, но это неважно. Главное — это описание поведения целевой системы как «чёрного ящика»). Это может быть, конечно, не вся система (скажем, MVP), но какая-то отдельная фича или набор фич, то есть речь идёт о «непрерывной модернизации имеющейся уже целевой системы».
Находят аффордансы для реализации концепции использования, отражают в модели «концепция системы». Тут важно отметить, что ещё несколько лет назад эта модель называлась «архитектура системы», и путаница в названиях будет ещё несколько лет.
Предлагают способы изготовления, согласованные с возможностями внутренней платформы разработчиков (design for manufacturing).
Получают «добро» от визионера (business case — ожидание того, что создаваемая система или фича будет обходиться дешевле, чем её можно продать, иногда это design for cost).
Проектируют систему или её фичу с точностью, достаточной для изготовления, изготавливают и тестируют, пользуясь инструментами (станками, программами) внутренней платформы разработчиков и учитывая ограничения архитектуры.
Эксплуатируют у клиента (при изготовлении может быть изготовлен и введён в эксплуатацию и цифровой двойник), по факту могут быть и операторами, you build it, you run it. После чего могут возникать разные идеи о том, что можно сделать лучше, и идёт переход к началу цикла (подготовка новой концепции использования для новой версии, или новой фичи) или принимается решение о том, что развивать далее систему бесперспективно.
Тратят 20% времени (в среднем) на выплаты технического/архитектурного долга (работы по реализации архитектурных решений: правильной нарезки их целевой системы на модули и реализацию правильных способов связи между модулями).

Организаторы делают то же самое, что разработчики целевой системы, но для системы-организации:

Руководствуясь бизнес-моделью и информацией от бизнесменов по поводу их оценки фирмы, а также в личном общении с инженерными командами и бизнесменами делают предположение о том, какие оргвозможности/capabilities нужны организации, чтобы она могла лучше адаптироваться к непрерывно меняющемуся внешнему миру (запросам клиентов, инвестиционному климату) и текущему состоянию самой организации (прежде всего — выплаты орг-архитектурного долга). Это отражают в стратегической модели оргразвития (по факту это показ декомпозиции практик, ведущих к каким-то изменениям мира с обоснованием того, почему этим вообще надо заниматься) и модели целеполагания (учёт интересов самых разнообразных проектных ролей). Этим обычно занимается подроль организатора — оргдизайнер (в разработке «железа» это был бы проектировщик или конструктор). Конечно, это необязательно оргвозможности всей компании в целом, они вполне могут быть какими-то частными оргвозможностями, но в любом случае — это согласовывается в ходе стратегирования.
Находят или проектируют аффордансы для реализации концепции оргразвития (оргзвенья из людей и оборудования — уже имеющиеся внутри, или которые нужно создать, или которые нужно законтрактовать/outsource), отражают в модели «концепция организации». Тут важно отметить, что ещё несколько лет назад эта модель называлась «архитектура системы», и путаница в названиях будет ещё несколько лет. Это тоже делают оргдизайнеры.
Предлагают способы изготовления, согласованные с возможностями внутренней платформы разработчиков (design for manufacturing), изготовлением занимаются лидеры (управляющие организационными изменениями, в разработке «железа» это были бы технологи производства, представители завода) — оценки получаем в том числе от них.
Получают «добро» от бизнесмена (business case — ожидание того, что создаваемая организация или её новая оргвозможность/орг-фича будет обходиться дешевле, чем её можно продать потом инвесторам, это тоже можно назвать orgdesign for cost. Помним, что на организационное развитие платят деньги инвесторы, а не клиенты — бизнесмены могут решить, что фирма бесперспективна, поэтому просто проэксплуатировать текущую клиентуру на зарабатывание в рамках текущей организации, не согласиться вложить деньги в фирму как «машинку по зарабатыванию денег», сочтут это невыгодным). Это обычно делают оргдизайнеры.
Проектируют (этим заняты оргдизайнеры, в том числе они связаны с разработчиками корпоративного софта) организацию или её орг-фичу с точностью, достаточной для организационного изменения (аналог изготовления в случае «железа»), проводят организационные изменения (этим заняты лидеры, аналог «изготовления» и «тестирования» в случае «железа»), пользуясь административной платформой (предоставляется администраторами организации) и учитывая ограничения орг-архитектуры.
Эксплуатируют созданную организацию (при изготовлении может быть изготовлен и введён в эксплуатацию и цифровой двойник), по факту это делают операционные менеджеры — они и есть «операторы организации», они заняты «настройкой» организации, которая обычно называется «непрерывным совершенствованием». Оргдизайнеры, лидеры, операционные менеджеры — это всё подроли организатора, и тут выполняется принцип you build it, you run it (в данном случае — «ты это организовал, ты этой организацией и рули», хотя «рулить» будет главным образом подроль, но в небольших организациях все три роли будет выполнять один человек, а в крупных даже и подроли будут играть множество разных людей). После чего могут возникать разные идеи о том, что можно сделать лучше, и идёт переход к началу цикла (подготовка новой модели оргразвития и новой модели целеполагания для нового шага развития) или приниматься решение о том, что развивать далее организацию бесперспективно.
Менеджеры оргразвития (оргдизайнеры и лидеры) тратят 20% времени (в среднем) на выплаты орг-архитектурного долга (работы по реализации орг-архитектурных решений: правильной нарезки организации на оргзвенья, реализацию правильных способов взаимодействия оргзвеньев).

Упражнение

Опишите от трёх текущих проектов развития в вашей компании.

Номер п/п	Практика, которую меняют	Практика, на которую меняют	Основная выгода от изменения	Основное препятствие для изменения	Уровень, с которого инициировано изменение (бизнесмен или оргдизайнер)	Сколько времени идёт изменение	Комментарии
1.
2.
3.

Опишите от трёх проектов развития, которые вы хотели бы провести для вашего подразделения.

Номер п/п	Практика, которую вы бы меняли	Практика, на которую меняли	Основная выгода от изменения	Основное препятствие для изменения	Уровень, с которого нужно инициировать изменение (должность, исполнителя которой нужно уговорить)	Комментарии
1.
2.
3.

Опишите от трёх проектов развития целевой системы (не замены, а именно развития — использование альтернативных принципов работы, задействования иных инженерных дисциплин).

Номер п/п	Меняемое инженерное решение	Какая ключевая характеристика станет существенно лучше, чем у конкурентов	Практики, которые нужно будет менять проектами организационного развития	Вероятность, что этот проект развития будет начат (если уже начат, то 100%)	Вероятность, что этот проект развития будет завершён и принесёт пользу
1.
2.
3.

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

Номер п/п	Рабочий продукт	Практики работы с ним	Оргроли, выполняющие эти практики
1.

Работа оргдизайнеров

Как создавать модели оргразвития и целеполагания было рассмотрено в разделе по практике стратегирования, а здесь (в разделе по организационному дизайну) рассмотрим создание концепции организации и оргпроекта (проекта организации с точностью и детальностью, достаточной для воплощения в жизнь — управления изменениями/лидерства). В текущей литературе эти вопросы относятся к вопросам архитектуры предприятия, но мы учитываем свежие тренды:

Архитектор предприятия находится по отношению к оргдизайнерам и лидерам в отношениях надзора и «продуктивного конфликта». Лидеры тут тоже важны, ибо организация может быть спроектирована с учётом орг-архитектурных решений, а вот лидеры потом могут эти архитектурные решения при воплощении проекта проигнорировать (например, «для скорости сейчас» в ущерб «скорости потом», о которой заботятся архитекторы).
В рамках тренда на автоматизацию/цифровую трансформацию всё больше и больше функций операционного менеджера возлагается на софт, поэтому разработчики корпоративной информационной системы в существенной мере привлекаются к оргдизайну/оргпроектированию. По факту сегодня многие решения оргдизайнеров сразу отражаются в «настройках» корпоративного софта, которые не столько «настройки», сколько структура таблиц базы данных, какие-то маршрутизации в скриптах автоматизации и прочая специфика современного верхнеуровневого программирования софта, что трудно передаётся словом «настройка». Поэтому часто оргдизайнеры становятся неотличимыми от каких-нибудь «аналитиков при CIO», а дальше вместо лидеров выступают они же, чтобы обучить сотрудников пользоваться этими «настройками софта», а «лидеры для корпоративного софта» (лидеры — это роли, которые уговаривают людей заняться не тем, чем они хотят сами по себе, а чем надо для успеха организации, а тут надо уговорить этим заняться компьютеры со сложным софтом) — это программисты, которые делают эту самую «настройку».

Концепция организации создаётся ровно по тому же образцу, что и концепция любой системы: надо с учётом архитектурных ограничений разбить организацию на какие-то модули-оргзвенья (люди и их компьютеры, от одиночных людей и даже частей личности в случае part time работы до частей крупных холдингов с десятками тысяч сотрудников и огромными датацентрами), на которые назначить функции, требуемые для успешности во внешней среде. Вот как это схематически изображается для общего случая, описанного в «Системной инженерии»:

Далее внесём специфику менеджмента как инженерии организации:

Разработчик тут стал оргдизайнером (мы расщепили роль разработчика-организатора на подроли менеджера оргразвития и операционного менеджера, а менеджера развития на подроли занимающегося проектированием оргдизайнера/оргпроектировщика и лидера, оставили на диаграмме только оргдизайнера, а уж он согласует оргпроект со всеми остальными ролями, это его работа). Визионер (который смотрит, можно ли продать целевую систему клиентам) стал в организации как системе создания целевой системы бизнесменом (который смотрит, можно ли продать организацию инвесторам и использует для этого бизнес-модель). Уточнены и названия моделей. Use case при этом стали просто «сценариями» (ибо странно говорить про «сценарий использования дирекции инжиниринга», но можно говорить, например, о «сценариях взаимодействия с дирекцией инжиниринга», что то же самое с точки зрения окружения, просто перевели не двумя словами, а одним, но людям в дирекции инжиниринга это на слух много приятнее, нет оттенка «нас используют»). Юнит-тесты стали уже хорошо знакомыми нам чеклистами — организацию не принято «испытывать», хотя вполне можно «проверять», а уж чеклисты вообще не вызывают особых вопросов. Так что отношения между ролями и характер разрабатываемых моделей не изменились, но все они были уточнены для организации: это мы отразили переход от самой абстрактной мета-мета-модели системной инженерии к более конкретной метаУ-модели менеджмента как инженерии не вообще любой системы, а именно инженерии организации.

В вашей конкретной организации вам придётся сделать ещё одно уточнение: перейти к метаС-модели, ибо у вас будут приняты уже не общие модели из учебников менеджмента (таких, как наш курс), но модели ситуационные — о которых договорились в самой организации и которые отражают идеи каких-то определённых школ менеджмента и даже идеи каких-то определённых людей в самой организации, которые могут в том числе и противоречить идеям из учебников менеджмента (и быть как лучше, то есть отражать ещё не документированную SoTA, так и хуже, принятые в организации просто по общему незнанию текущей SoTA в менеджменте. С незнанием SoTA идей будут бороться оргдизайнеры, а вот с неприятием SoTA идей будут бороться лидеры — всё это как раз и будет организационным развитием, переходом на современные практики менеджмента).

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

Архитектор целевой системы предписывает ещё разбиение на какие-то модули с тщательно спроектированными интерфейсами и прописанными взаимодействиями через эти интерфейсы, это разбиение следует какому-то архитектурному стилю. Это делает архитектор, которого заботит «что будет потом» в терминах архитектурных характеристик целевой системы. Команды разработчиков по возможности независимо далее развивают каждая команда свой модуль для «что важно для клиента прямо сейчас», добавляя в него нужные для успешности надсистемы функции. При этом они могут мешать друг другу, часто ненамеренно. Грубо говоря, «мы хотим вот тут взять немножко энергии для печки, нам удобно взять 12 вольт, а рядом идёт провод 12 вольт из какого-то другого модуля, мы к нему подцепимся, то есть сделаем «неучтённый интерфейс» мимо публично объявленного той командой», и после этого в машине почему-то не срабатывает тормозная система после того, как включается печка: эти 12 вольт взяты из питания для тормозной системы, которое не было рассчитано на печку. Архитекторы целевой системы следят, чтобы такого не было, чтобы сиюминутные технические решения одной команды не влияли на характеристики системы на следующих шагах развития. Их отношение к разработчикам: сначала принятие обязательных для соблюдения разработчиками решений, затем менторство по разъяснению этих решений (не только «что надо делать», но и «почему надо делать», ибо разработчики будут придумывать хитрые способы обходить решения архитекторов — «по форме всё в порядке, а по сути — сущее безобразие»), а затем ещё и осуществлять надзор за выполнением этих решений. Разработчики и архитекторы в конфликте из-за разных межвременных предпочтений: архитекторы больше думают обычно про «потом», а разработчики про то, что клиенту нужно вот прямо сейчас: «давай реализуем грязный и быстрый способ решения текущей проблемы, а нормальную реализацию отложим на когда-нибудь». Разработчики постоянно накапливают долг по работам, нужным для выполнения архитектурных решений (на этот «технический/архитектурный долг» в среднем планируют до 20% ресурса разработчиков, задача только в том, чтобы у них обязательно было время выполнять эти планы).
Оргдизайнер как разработчик организации должен спроектировать организацию: ровно вот те команды, которые будут выполнять работы по созданию системы, но и предусмотреть архитекторов, и визионеров, а ещё разработчиков и эксплуататоров внутреннего «конвейера» (platform engineers/DevOps). То есть он должен предложить организационную структуру (модель иерархической организационной структуры с делением организации на оргзвенья называется органиграмма), в которой будут для оргзвеньев отражены играемые ими организационные роли, о которых мы говорим — то есть транзитом он должен учесть предложения разработчиков (ибо там определяется предметное содержание модулей, важное для определения требуемых ролей — «для электронных модулей нужна роль электронщика») и архитектора целевой системы (сама нарезка на модули и принципы этой нарезки, помним о законе Конвея и обратном манёвре Конвея), чтобы отразить команды разработчиков на органиграмме, назначив им соответствующие функции в разработке. Всё ещё запутанней, ибо оргдизайнер в органиграмме должен отразить и менеджерские службы, в том числе отразить себя, а ещё тех, кто организует самого оргдизайнера, выполняющего практику оргдизайна. Оргпроектировщик/оргдизайнер тоже не «самозарождается» в организации, а его кто-то проектирует, а затем он сам будет объектом лидерства со стороны разных подролей организатора организаторов инженерных команд целевого проекта, цепочки создания обычно длинны. Ещё раз вернитесь к системной схеме инженерного проекта, представьте себе, что в организации множество проектов, которые делят между собой ресурсы — и вот эту задачу создания организационной структуры и решают архитектор организации и оргдизайнеры (которые занимаются вообще-то проектированием более-менее автономных модулей общей организационной структуры, определённых орг-архитектором). Довольно верный признак того, что вопрос должен решаться оргдизайнером — это звучащая в разговоре лексика каких-то отдельных специфических предметных практик, которыми занимается организация. Организация учится чему-то новому, для этого нужно запроектировать оргструктуру, которая будет поддерживать эту новую практику, поэтому «новая практика» тут будет ключевым. Архитектор же будет говорить самые общие слова, которые обычно говорят архитекторы: скорость, надёжность, безопасность, гибкость, масштабируемость, взаимонезависимость и т.д., только по отношению к организации, а не к целевой системе.

Упражнение

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

Номер п/п	Модуль целевой системы (первый уровень)	Оргзвено, в основном занимающееся этим модулем	Какие подмодули не охвачены в модуле оргзвеном	Что прихвачено оргзвеном из других модулей	Рекомендации в соответствии с обратным законом Конвея
1.
2.
3.

Концепция организации и оргпроект

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

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

Какие принципы разбиения организации на модули в различных орг-архитектурных стилях, по каким принципам взаимодействуют оргзвенья в этих разных архитектурных стилях, будет обсуждаться в разделе по архитектуре организации/предприятия. Но в этом архитектурном разговоре ничего не будет говориться о самих оргвозможностях в части необходимых к исполнению практик, то есть умению оргзвеньев выполнять работы определёнными способами (работать по каким-то практикам), при этом ещё и быть обеспеченным для этого ресурсами и иметь административное позволение выполнять работы по нужным практикам — про роли и практики думают не столько орг-архитекторы, сколько орг-дизайнеры. Архитекторы думают про архитектурные характеристики, организационные -ilities.

В стратегии, конечно, будет указана какая-то высокоспецифичная для данной организации практика работы в какой-то предметной области, которую должна уметь выполнять организация, причём указана на минимум уровне метаУ-модели, а не мета-мета-модели. Оргдизайнеру надо как-то разбираться в разных предметных областях, чтобы разрабатывать специфические для организации модели в составе стратегии. Если оргдизайнер в моделях стратегии будет просто цитировать общие места из курса системного мышления или даже менеджмента — это не будет стратегией, это все и без стратегии понимают, что «так устроен мир», такое обычно называют «гигиеной», «все так делают, не стоит особого внимания». Недостаточно в стратегии написать «мы должны быть гибкими, богатыми, быстро расти, а нашей отличительной чертой будет клиентоориентированность». Оргдизайнеру (самому или при помощи приглашаемого им для работы эксперта предметной области/subject matter expert) нужно разбираться в практике на уровне учебников самых разных практик, которые лежат в основе работы его организации, то есть работать на уровне метаУ-модели. Далее эту практику оргдизайнер (часто при помощи эксперта по предметной области практики) должен представить как метаС-модель, адаптировав к местной производственной культуре, чтобы у лидера могла быть возможность как-то объяснить сотрудникам, которые будут выполнять эту практику, что им надо будет делать во время работы по этой практике.

Мы тут говорим о мета-модели, а не об операционной модели, ибо проектирование ведётся всегда в типах, работа оргпроектировщика — это работа с мета-моделями! Организация при этом как раз попадает под ситуацию, описанную ещё в «Системном мышлении» как «если у вас проект Эйфелевой башни, единственной в мире, то её проект — это всё равно описание не отдельных деталей, а типов деталей. Потом эти детали будут изготовлены как экземпляры, и учтены в модели конкретной физической Эйфелевой башни. И при необходимости по этим же описаниям они будут изготовлены снова и снова, ибо это описание множества деталей, которое потенциально может быть изготовлено». А вот операционные менеджеры и рабочие сборки будут работать с экземплярами и их модели будут содержать не описания типов как тегов/tags/кодов отдельных частей конструкции, а серийные номера экземпляров этих частей, которые типизированы этими тегами. Так что в мета-мета-моделях не будет слов предметных областей, а в мета-моделях они будут, в то же время в мета-моделях не будет конкретных имён людей, инвентарных номеров оборудования, но будут только их типы (скажем, должности как оргместа будут, но что на этой должности «Иван Иванович» — этого не будет, это решится потом, в ходе «изготовления», то есть в ходе проведения оргизменений/лидерства).

Итак, в моделях оргдизайнеров сначала появляются вот эти предметные практики, которые должны быть поставлены в организации. Большинство из этих практик — это целевые практики, которыми занимаются инженеры целевой системы (если это университет, то практики создания мастерства, практики организации абитуры/клиентуры). Конечно, там будут и практики администрирования (ведение бухучёта, офис-менеджмент, работа с кадрами), а иногда и практики собственно менеджмента (скажем, переход на методы beyond budgeting, если по каким-то причинам этого ещё не произошло). Но эти практики администрирования и менеджмента — это не главное в стратегиях. Если вы красите заборы плохой краской, забываете их почистить, эти заборы облезают после первого дождя, то никакой современный менеджмент и как часики работающий финансовый учёт вашей организации не поможет. Впрочем, поможет: инженеры узнают от клиентов, что «так жить нельзя, не хотим вам за это давать денег», предложат способы устранения ошибок в практиках работы, а оргдизайнеры как раз должны запроектировать организационные изменения (изменения практик) и провести их в жизнь. Конечно, оргдизайнеров может быть тоже несколько команд, какие-то из них могут заниматься чисткой-блисткой менеджмента, но большинство команд таки должны заниматься инженерными практиками и практиками маркетинга.

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

Органиграмма (структура деления организации на оргзвенья, обычно неполная, ибо в ней не показываются обычно всякие научно-технические советы, комиссии, рабочие группы проекта и прочие реальные оргзвенья, но только структура «мест найма» в части официального учёта занятых — и нужны способы учёта полной оргструктуры. Но тут проблема: у генерального директора как единоличного исполнительного органа может не быть полномочий управлять каким-нибудь советом, поэтому органиграмма не может указать этот совет в структуре подчинения! Это не означает, что такого оргзвена в организации нет, и что это оргзвено не выполняет каких-то работ по каким-то практикам).
Каталог сервисов: это перечень работ, которые могут быть выполнены оргзвеньями в организации на оргинтерфейсах этих оргзвеньев. Обсуждаются обычно в терминах кейсов (что предмет кейса, какое состояние его до задействования сервиса, какое состояние после сервиса). При оргпроектировании назначаем эти сервисы на конкретные оргзвенья.
Оргфункциональная структура/модель, это модель практик (часто дающаяся в тех же терминах «типовых кейсов», что и каталог сервисов»). Но тут уже функции оргролей и порты, описывающие потоки чего-то, что течёт через организацию. И вот эти оргфункции становятся потом сервисами, которые оказываются оргзвеньями. Помним, что в инженерии в 9 случаях из 10 функциональные части и конструктивные совпадают друг с другом полностью, но в одном из десяти случаев возникает ситуация типа «ножницы» или «чайник», это же приложимо к концепциям организационных систем: оргроли и практики могут соответствовать оргзвеньям и оргсервисам 1:1 в девяти случаях из десяти, но в десятом случае могут и не соответствовать — и будут тщетные попытки лидеров разобраться, что же им нужно изготавливать (помним, как завод пытался поручить изготовить вместо половинок ножниц и винтика отдельно «ручку», отдельно «ножевой блок» на разных заводах, или пример компрессора с попыткой отдельного изготовления «двигателя» и «турбины» из «Системного мышления»). Вот эта оргфункциональная модель получается из содержательного рассмотрения происходящего в рабочих процессах. В оргфункциональной модели чаще всего дело не доводится до практик в их привычном виде шаблонов кейсов, ибо шаблоны кейсов с их предметами работ — это всё-таки типизация работ/сервисов с их рабочими продуктами, а практики — это типы работ, работающие с альфами. Конечно, соответствие (и термины, выбранные для названий) будут также в большинстве случаев 1:1, но потом вдруг окажется, что какая-нибудь «модель» как альфа будет отражена в нескольких «документах»/«отчётах» как рабочих продуктах. Это всё опять, было обсуждено в курсе «Методология», и нужно только это общее знание использовать в работе оргдизайнера.

Дальше это всё доводится до оргпроекта, но это чаще всего не up-front design, а вполне обычный процесс создания MVP реализующей новую практику организации (MVP — это с точки зрения бизнесмена, как он определит её «продаваемость»), а затем бесконечное развитие (выкидывание лишних функций, добавка гипотетически полезных — и тут акцент на «гипотетически» полезных, это всё такая же работа с догадками-гипотезами, как и любая другая инженерная работа. Техно-эволюция быстрее эволюции, но каждая мутация всё одно должна проверяться жизнью, в том числе она может быть полезна «вчера» или «завтра», но не «сегодня» — и это тоже надо учитывать, жизнь ведь изменчива). Таким образом оргпроектирование тоже непрерывно, а не разово, нет никакого «жизненного цикла организации», а есть создание и последующее (по возможности бесконечное) развитие.

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

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

У этого моделирования есть принципы непубличности работы с мета-мета-моделью:

Работники предприятия должны разбираться в экземплярах предметной области, заполняя таблички. Типы этих экземпляров (метаС-модель) должны быть прописаны в названиях колонок таблички.
Эксперты предметной области (владеющие метаУ-моделью, «образованные специалисты») вместе с оргпроектировщиком должны приготовить табличку, проставив заголовки таблички в терминах метаС-модели. Типы этих элементов (мета-мета-модель) должны быть в голове у оргдизайнера, и он должен задавать вопросы эксперту предметной области, если обнаружит, что эксперт забыл отразить в табличке какие-то важные объекты. Эту работу исполнители ролей эксперта предметной области (subject matter expert) и оргдизайнера выполняют вместе! Идеально, когда эксперт предметной области и оргдизайнер (помним, что это половинка менеджера по развитию) совмещены в одном человеке, но это обычно нереально: разных предметных областей много, а ещё оргдизайнер должен получить образование в части мета-моделирования (например, пройти курсы ШСМ, начиная от «Моделирования и собранности» до «Системного менеджмента» включительно, чтобы понимать, о чём говорится в текущем абзаце и что именно он делает, когда проектирует эти таблички. Это ровно та работа, которую он делал уже много раз, когда выполнял упражнения этих курсов). Важно, что оргдизайнер всю типизацию мета-мета-модели и рассуждения по мета-мета-модели проводит в голове. Он не говорит «система микроволновка», он говорит «микроволновка», если речь идёт о микроволновке (а в голове у него микроволновка::система). Но если у него подозрение, что «микроволновка» в словах эксперта предметной области означает описание микроволновки в проектирующем микроволновку конструкторском бюро, а не саму микроволновку как физический объект, то он должен уточнять — и в табличке потом всё должно быть однозначно (например, «3D-модель микроволновки», а не «микроволновка»). Если не соблюдать этот принцип, то разговора не получится: эксперт будет спотыкаться о каждое слово из мета-мета-модели, поэтому в обсуждениях заголовков таблички эти слова про типы не должны звучать, но должны звучать слова из предметной области эксперта. В обсуждении с экспертами эти термины типов мета-мета-модели оргдизайнером табуируются.
Оргдизайнер обязан владеть мета-мета-моделью, чтобы в таблицах оргмодели не было нетипизированных сущностей. Но типизация эта должна быть только у него в голове, в таблице её указывать не надо! Хотя для себя он может и делать заметки по отображению типов из мета-мета-модели в явном виде. Исполнитель роли оргдизайнера ведь «не гроссмейстер», чтобы такие сложные мыслительные действия делать «в уме», как шахматисты-гроссмейстеры. Нет, используем экзокортекс, всё пишем — «мышление моделированием». Но не говорим и не показываем эти типы эксперту!

Другими словами, кто не проектирует таблички, а только их заполняет, может не изучать системного мышления и не знать мета-мета-модели, а кто проектирует таблички — он должен владеть системным мышлением, пройти курсы системной инженерии и менеджмента. Тем самым менеджеры оргразвития должны пройти курсы всей линейки от «Моделирования и собранности» до «Системного менеджмента», а основная их работа будет в оргдизайне (моделировании табличек оргмодели вместе с экспертами по практике, которую они хотят превратить в оргвозможность) и лидерстве (уговорить людей сотрудничать в воплощении в жизнь этой модели, выраженной в табличках — люди должны выполнять описанные в табличках практики, играя описанные в табличках роли и передавая друг другу рабочие продукты предметов их кейсов).

Выбор оргмоделера

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

Для документирования используются моделеры. Вы можете сделать моделер даже из воздуха (указав на места в пространстве, где ваши собеседники будут помнить, какие объекты каких типов вы ассоциируете с этими местами в пространстве — полностью эквивалентно «пусть S — это путь, а V — это скорость», только запись не буквами на бумаге, а указанием на место в пространстве), вы можете сделать моделер из своей руки (указывая место на руке, где ваши собеседники будут помнить, какие объекты каких типов вы ассоциируете с этими «именами»), и это много лучше, чем когда вы держите модель только «в чертогах разума». Это может пригодиться в разговоре «на бегу». Но для нормальной работы у вас должно быть управление конфигурацией, а вот этого таким моделированием не добьёшься: нужно использовать компьютерное моделирование (даже не бумажное!):

Вам нужно уменьшить число ошибок моделирования. Если у вас в модели больше пяти объектов, то человеческая память будет крайне ненадёжна. Если пройдёт всего день с момента моделирования, вы уже можете вспомнить очень немного (кривые забывания¹⁹⁸ работают даже в случае работ по проектированию, не только при обучении).
вам нужно управлять информацией проекта (нашем случае проекта оргизменений, то есть надо управлять информацией оргпроекта, включая стратегические модели и концепцию системы, а также всё остальное, что нужно для реализации запроектированных оргизменений). Это означает, что модели проекта должны быть доступны всем, кто имеет к этому проекту отношение, так что вам придётся часто пересылать документацию моделей (или давать доступ к моделеру с этой моделью, что то же самое). В этом плане ящик с мокрым песком и веточкой, в отличие от воздуха и руки хотя бы могут быть сфотографированы.
Вам нужно легко вносить изменения, «непрерывное всё»: оргпроект будет непрерывно меняться. Компьютерные модели легко менять, модели на мокром песке и на бумаге менять трудно. В том числе вам нужно будет менять модели дистантно, поэтому стена со стикерами тоже не подойдёт, придётся всё равно сдублировать результаты моделирования стикерами на стене в компьютер, чтобы иметь возможность корректировать модель удалённо. Так что должен быть моделер, доступный через интернет.
Вам нужно управлять конфигурацией: какая из многочисленных версий проекта/design (это набор самых разных моделей, которые тоже имеют версии!) будет воплощаться, должно быть точно известно в любой момент. Исправления, внесённые не в ту версию — не исправления. Оргизменения, сделанные по «не той версии, извините» — это будет вред, а не развитие. Это означает, что должен быть репозиторий моделей, в котором поддерживается версионирование (и тут проблема даже с моделями в отличных универсальных моделерах типа coda.io или notion.so).

Почему делается такой упор на табличное моделирование? Моделирование текстом получается совсем не наглядным, ибо очень трудно указывать типы и очень трудно показывать много похожих (например, одного типа) сущностей. Таблички тут представляют вариант много лучше, хотя у них есть определённые недостатки — но эти недостатки с лихвой перекрываются удобным визуальным представлением и доступными моделерами (редакторы таблиц повсеместны, к тому же большинство современных баз данных реляционные, то есть по факту «табличные»). Многочисленные попытки наладить редактирование в диаграммных представлениях («квадратики и стрелочки»/box and arrows) успешны только там, где удаётся выделить огромные (как выяснилось позже) совершенно ненужные ресурсы: это моделирование особо плохо в части непрерывных изменений. Ещё как-то удаётся один раз отмоделировать оргмодели диаграммами, но вот потом не удаётся постоянно корректировать эти модели и удерживать управление конфигурацией. По факту все эти «диаграммные моделеры» (иногда их называют «архитектурные моделеры», иногда «моделеры архитектуры предприятия») имеют альтернативное текстовое представление (например, XML или JSON документы, которые могут редактировать профессионалы-программисты) или табличное представление (которое могут редактировать «продвинутые пользователи»), и оказывается, что основное время модельеры-оргдизайнеры проводят в этих представлениях, а не в визуальном редакторе диаграмм. Поэтому проще оказалось сразу использовать табличные представления.

Но и тут есть несколько вариантов: электронные таблицы (например, MS Excel, Airtable) и базы данных (например, PostrgeSQL, MySQL), а также лет пять назад появившиеся универсальные редакторы, сочетающие в себе свойства редакторов текста с возможностью вёрстки, электронных таблиц и баз данных (coda.io, notion.so). И тут надо указать, что в рамках практики lean в большинстве случаев оказалось не нужным разрабатывать отдельные корпоративные приложения для поддержки новых практик работы, достаточно было использовать LowCode средства этих моделеров, если речь не идёт о сотнях и тысячах однотипных работ, для которых этих средств LowCode универсальных моделеров не хватает (обычно там проблемы масштабирования для большого числа операций: 1. лицензионная политика, делающая цену использования запредельно высокой, и своё приложение написать оказывается дешевле, 2. Отсутствие управления конфигурацией и версионирования, что заставляет прибегать к сложным ухищрениям для репликации данных где-то ещё, и своё приложение оказывается в конечном итоге проще, 3. Низкая производительность, ибо речь идёт об универсальном моделере, который платит за универсальность низкой скоростью, 4. Проблемы с безопасностью и защитой, ибо в собственных приложениях проще прописать доступ разных ролей к разной информации. Все эти проблемы, впрочем, можно в существенной мере убрать, если за универсальными моделерами оставить роль «пользовательского интерфейса», а информацию хранить в корпоративных базах данных, обеспечив какую-то интеграцию между моделером и хранилищем информации).

Оргдизайнеры помогают экспертам (владеющим метаУ-моделями и метаС-моделями) разработать таблички в универсальных моделерах, разъяснения к этим табличкам писать текстом, а дальше «автоматизацию» обеспечивать или простейшим LowCode программированием «на кнопках» (вроде как послать кому-нибудь письмо, что «Сегодня вы появились в табличке «Проект мытья полов» в колонке «Исполнитель»»), или же путём такой же необременительной в части программирования связи с другими корпоративными информационными системами. То есть оргпроекты в ходе моделирования становятся исполняемыми/actionable, в табличках могут быть кнопки. Это общий ход: редактор Lists (редактор списков, которые выражаются в табличной форме) в MS Teams прежде всего задействуется как issue tracker.

Что надо добавить в issue tracker, чтобы он отражал оргмодель? Не так много, ибо отслеживание самой работы (issue, потом task, потом notice) в issue tracker уже есть: указание на «собственника кейса/issue», обычно это сотрудник, который открыл кейс, и он же проверит, можно ли кейс закрыть. Как всегда с людьми, тут нужно знать и исполнителя роли, и роль, и должность, а часто ещё и понимать, где именно в организации находится эта должность, в каком оргзвене её искать, к какому начальнику обращаться, если встретится неожиданное «внеролевое» поведение и нужно будет его корректировать.

Если речь идёт о новом шаблоне кейса, то это и есть описание новой практики. Вот это и есть работа оргразвития: оргдизайнер сделает шаблон кейса, а лидер потом наладит работу по практике, описанной в шаблоне кейса. Так что оргдизайнер в качестве моделера часто использует сразу issue tracker как систему моделирования. Не надо одну и ту же модель отражать в issue tracker, в специальной системе моделирования оргдизайнера, в слайдах презентации для начальства красивыми картинками, в виде регламентов для сотрудников (которые никто не будет читать) и т.д. Меньше дублирования — меньше вероятности развала конфигурации.

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

TEST концепция организации

!!! Какое организационное решение самое важное в предприятии?

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

--- централизованное или децентрализованное управление ### Нет, это не самое главное решение, хотя от него в фирме многое зависит — это архитектурное решение по архитектурному стилю. Более важным является то, какое оргзвено какие практики выполняет, концепция организации.

+++ кто что делает ### Да, это одна из формулировок концепции организации: какие конструктивные единицы (кто, оргзвенья) какие функциональные единицы, оргроли (что делают, выполняют какие деятельностные практики)

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

--- кто какие имеет полномочия по распоряжению трудом и капиталом ### Нет, знание о полномочиях не объясняет того, чем будут заняты (какие практики будут выполнять) люди с полномочиями. Важнейшим решением является основное: модульный синтез (организационная структура предприятия: разбиение на оргзвенья — как раз органиграмма, кто какие имеет полномочия), но всё-таки предварённый функциональным анализом (функциональная структура, занятая выполнением практик: разбиение на оргроли).

!!! Концепция организации должна быть публичной?

--- Нет, лишние знания об устройстве организации умножают зависть, сбивают с толку ### Неверно, модели оргпроекта (в том числе концепция предприятия, высокоуровнево описывающая, кто что делает) — это основной коммуникационный рабочий продукт, помогающий людям договориться о том, как они организованы и что делают.

+++ Да, это главный способ донести до людей ответ на вопрос «кто что делает» ### Да, концепция организации — это основной рабочий продукт для коммуникации по поводу того, как устроена организация.

+++ Да, если концепция организации не документирована и опубликована, то никто не будет точно знать, кто что делает — организация будет работать плохо ### Да, модели концепции организации с основными организационными решениями должны быть доступны, чтобы люди понимали, кто что делает, к кому за чем можно обратиться, у кого какая «зона ответственности».

!!! Отметьте функциональные части предприятия:

+++ организационные роли, которые играются организационными звеньями ### Да, именно так, оргроли — это функциональные части организации. А организационные звенья — это конструктивные части/модули предприятия, они играют организационные роли.

--- практики, которые выполняют оргроли ### Нет, практики — это поведение организационной роли, а функциональной частью является сама оргроль.

--- подразделение предприятия ### Нет, подразделение — это один из видов организационных звеньев/модулей, конструктивных частей.

--- люди, работающие на предприятии ### Нет, люди — это оргзвенья (минимальное оргзвено состоит из одного человека, а то и части личности), это конструктивные элементы.

--- сервис ### Нет, сервис — это поведение оргзвена, конструктивной части предприятия, а не сама конструктивная часть.

+++ оргвозможности/capabilities ### Да, это оргроли, для выполнения которых уже есть оргзвенья, имеющие полномочия и ресурсы выполнять практики этих оргролей, то есть функциональные части предприятия.

!!! Отметьте конструктивные части предприятия

--- организационные роли, которые играются организационными звеньями ### Нет, организационные роли — это функциональные части.

--- практики, которые выполняют оргроли ### Нет, практики — это поведение организационной роли, то есть практики — это поведение функциональной части предприятия, и даже не функциональная часть.

+++ подразделение предприятия ### Да, подразделение — это один из видов организационных звеньев/модулей, конструктивных частей.

+++ люди, работающие на предприятии ### Да, люди — это оргзвенья (минимальное оргзвено состоит из одного человека, а то и части личности), это конструктивные элементы.

--- оргвозможности/capabilities ### Нет, это оргроли, для выполнения которых уже есть оргзвенья, имеющие полномочия и ресурсы выполнять практики этих оргролей — то есть функциональные части предприятия.

--- сервис ### Нет, сервис — это поведение оргзвена, поведение конструктивной части предприятия, а не сама конструктивная часть.

Конструкция организации и координация работ

Если кто угодно в организации обращается к кому угодно и просит выполнить какую-то работу по какой-то практике, то организация тут же остановится: все окажутся перегруженными ненужными работами, или наоборот, будут с удовольствием бездельничать — право попросить ведь всегда сопровождается правом отказать. Попробуйте в пиццерии заказать вместо пиццы женские босоножки 37 размера, у вас вряд ли получится. Попросить программиста заварить вам кофе можно, но это не будет воспринято как рабочее задание — даже если кофе вам нужно, чтобы напоить людей перед важным совещанием, это ведь сильно поднимает продуктивность совещания¹⁹⁹. Конструкция организации (кто кого о чём может попросить, и от кого не ожидается отказа в выполнении просьбы) крайне важна. Если у вас отличный оргпроект в части описания функциональных ролей, выполняемых ими практик, перечислены очень удачно выбранные альфы и их состояния и даже всё запрограммировано, то это только половина дела:

Надо определить, какие оргзвенья будут назначены на исполнение этих ролей, и дать этим оргзвеньям полномочия выполнять практику и тратить свои ресурсы на выполнение работ по новым практикам. Это работа оргпроектировщика, но дальше нужно как-то разобраться с полномочиями (скажем, подписать оргпроект как приложение к приказу какого-то начальника).
Обучить людей в этих оргзвеньях и запрограммировать компьютеры (хотя на предыдущем такте это уже может быть сделано — «описать практику в моделере» и «запрограммировать компьютер» может оказаться одним и тем же делом, которое может сделать оргпроектировщик, оргмодель сегодня обычно actionable orgmodel), снабдить их необходимым инструментарием (и настроить или адаптировать эти инструменты), материалами. Это работа лидера, который пользуется административными службами для «изготовления» запроектированного оргпроектировщиком (помним, что администратор — это аналог инженера внутренней платформы разработки, DevOps в варианте организации).

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

Обсуждение конструкции (структуры оргзвеньев и их полномочий) предприятия, абстрагированное от обсуждения функциональной специфики, наиболее подробно даётся в книге Ian Dietz и Hans Mulder «Enterprise Ontology», 2021:

«Онтология предприятия» — это важные в предприятии объекты, о которых легко договориться. Авторы книги справедливо утверждают, что проще всего в предприятии обнаружить оргзвенья, которые они называют «акторами» (actors), и эти акторы заказывают работы (оказание сервисов) друг у друга. Если какое-то оргзвено считает, что работу у него запрашивают неправомерно, происходит «выход в дискурс», работа прекращается, начинается обсуждение того, кто прав, кто виноват (если в пиццерии заказать женские босоножки, то работа прекратится и начнётся разговор о том, кто пришёл, кого попросил, почему это нельзя сделать — тот самый «дискурс»). Главное, что книга предлагает кроме традиционного для операционного менеджмента деления на время паузы (wait time) и время обработки (touch time) вводить другое различение, тоже влияющее на скорость работы: это coordination time (время договаривания о работах, связанных с полномочиями) и production time (собственно время обработки).

«Договаривание» или по обсуждаемой книге Dietz и Mulder (общее название представленной там методологии — DEMO) «координация» относится к таким речевым актам/действиям, как просьбы, обещания, предъявления выполненной работы, акцепты результатов, отказы. Речевые акты тут упомянуты не случайно, ибо DEMO основывается на теории речевых актов. Речевые акты — это такие высказывания, которые порождают действия в реальном мире (то есть как раз просьбы, обещания, предъявления выполненной работы, акцепты результатов, отказы). В частности, делается утверждение, что надо специально договариваться о моментах, когда считаем работу выполненной (то есть кейс закрытым), и основные события в мире координации должны происходить по явным речевым актам, то есть «не сказал/не написал — не считаем, что что-нибудь произошло в обработке». При этом можно договариваться, что «если положил результат вот сюда, это означает, что я закончил работать и выдал результат по цепочке дальше», но если договорённости не было — окончание работы считаем не произошедшим, пока об этом исполнитель не скажет явно, а заказчик не получит это сообщение. Основная ошибка оргдизайнера — это пропуск стадий координации и пропуск того, что будет происходить, если на любой из стадий будет отказано в продолжении (например, что будет происходить, если поручение будет выдано, но работа не будет взята, то есть обещание выполнить работу не будет получено):

Осознание нужности инициатором трансакции/заказчиком/поручителем какой-то работы/кейса
Поручение/заказ/просьба выполнения работы/кейса (предъявление потенциальному исполнителю). Работа тут поручена, но не взята!
Обещание исполнителя выполнить работу (явный приём к исполнению)
Выполнение работы (это собственно обработка/производство/работа/труд)
Объявление о том, что работа выполнена. Работа тут выполнена, но не принята!
Объявление о принятии работы

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

Конечно, дальше можно усложнять и усложнять ситуацию, например потребовать 12 виз при подписании договора (договор тут — это поручение на работу и обещание выполнения оплаты при условии выполнения работ, совмещённое с обещанием выполнить работу и выражением требования при условии выполнения работы получить деньги). Понятно, что договора просто прекратят подписываться. Это вопрос оргдизайнера сделать так, чтобы координационные акты занимали минимум времени.

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

TEST

!!! Что говорит DEMO о работах, которые делаются пять минут, но от запроса до приёмки которых проходит пять дней, при этом нет недостатка в ресурсах для выполнения работы?

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

+++ продукционный акт может быть коротким, а время съедают координационные акты ### Да, именно так: пять минут выполнение дела, а ожидания согласований занимает пять дней.

--- это разгильдяйство, нужно чётко отрабатывать поручения ### Нет, DEMO говорит о том, что продукционный акт выполняется пять минут, а вот координационные акты (выдача поручения, выдача обещания, сообщение о сдаче, сообщение о приёмке) занимают много времени.

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

!!! Пётр сделал 3D-модель, но Анна страшно ругалась, что он ей не сказал ещё три дня назад, что модель готова. Пётр считает, что раз Анна заинтересована в этой модели, то она и должна узнавать, готова модель, или ещё не готова: если три дня она не забирала готовую 3D-модель, то эта модель ей не так уж и нужна, поэтому ругаться должен сам Пётр: он поставил работу Анны в приоритет, а мог бы спокойно отложить её на те самые три дня, ничего не изменилось бы. Кто прав?

+++ Анна ### Да, в цикле запрос-обещание-(изготовление)-сдача-приёмка исполнитель обязан сообщить о том, что работа сделана, этот координационный факт нельзя получить другим образом. Пётр должен был известить Анну, что он сдаёт работу (а Анна затем должна известить Петра, что она приняла работу).

--- Пётр ### Нет, Пётр выполнил продукционный акт (сделал 3D модель), но не выполнил связанный с этим координационный акт: не сообщил о том, что работа им сдаётся — исполнитель обязан сообщать о том, что работа им обещана, и о том, что она им сделана/сдаётся. Инициатор работы должен объявлять факт, что он запрашивает работу, и что работа принята.

Упражнение

Представьте в виде таблицы основное организационное решение вашей компании: каким образом организационные роли исполняются оргзвеньями/подразделениями вашей компании (или более мелкие подразделения вашего более крупного подразделения, если вы слишком далеки от принятия решений по всей компании в целом).

Номер п/п	Кейс (работы, называемые по изменяемому состоянию продукта)	Практика, используемая для кейса	Организационная роль для этой практики	Оргзвено, выполняющее роль для этой практики	Проблемы в связи с текущей ситуацией	Ваши предложения по улучшению ситуации
1.
2.
3.

Модель органиграммы

Ещё один важный вопрос — это как в системах моделирования отображать иерархию оргзвеньев (все вы выдели органиграммы, где на самом верху «люди», отражаемые названиями должностей «генеральный директор», «финансовый директор», а ниже вдруг идут подразделения, которые в их «зоне ответственности», а дальше указываются подразделения, входящие в эти подразделения — если читать такую диаграмму буквально, то получается, что какой-нибудь отдел входит в состав директора по направлению, а директор по направлению входит в состав гендиректора. Альтернативный вариант не лучше: если читать связи в органиграмме как «подчиняется», то какой-нибудь отдел будет подчиняться департаменту, в котором он находится — но как?! Модельерами было предложено множество решений этой проблемы, но меньше всего проблем (проблемы есть у всех решений!) получило использование двух правил, которые полномочия выступать от имени оргзвена из нескольких человек присваивают его руководителю:

Руководитель — один из сотрудников, но «сотрудниками» у него могут быть и другие оргзвенья
Если нет явного подначального подразделения «оргзвена», то используйте слово «направление» или «служба» и тем самым создайте его!

Вот пример для «конкретной организации» (КонкОрг):

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

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

Вот примерная «логическая» (в реальности это «непрерывная разработка», и все действия итеративны) последовательность работ оргдизайнера:

Начинаем с основных изменяемых объектов работы (прежде всего — целевой системы!). Определяем список кейсов, готовим шаблоны этих кейсов (с экспертами предметной области смотрим на SoTA практики, учитываем ресурсы, прописываем чеклисты для определения моментов перехода предмета кейса по графу его состояний и т.д.). Делаем подкейсы (разбиения) на столько уровней, сколько представляется удобным — понимая, что на самом верхнем уровне принимать решения по кейсам нижнего уровня нельзя, там будут свои оргдизайнеры. Как-то раскладываем эти кейсы по оргролям. Это всё будет функциональная декомпозиция организации.
Прописываем органиграмму: определяем оргзвенья, которые будут выполнять прописанные роли — учитываем при этом решения орг-архитектора.
Прописываем, какие информационные системы поддерживают какие кейсы и как организована маршрутизация предметов кейса по оргзвеньям (проектирование IT-решения, при этом учитывается и IT-архитектура). В простых случаях это будет LowCode моделирование, в сложных — придётся разрабатывать или дорабатывать какой-то корпоративный софт.
Определяем, что ещё будет надо (помещения, оборудование, разделы бюджета и т.д.), доводим концепцию предприятия до полноценного орг-проекта/design, готового к воплощению.

Итого в практике оргдизайна помните:

Оргдизайнер — это роль, оргдизайнеров много, часто эту роль для своего звена выполняет какой-нибудь начальник оргзвена, а свободу его творчества ограничивает орг-архитектор, действующий в масштабах предприятия (архитектор предприятия/enterprise architect).
Средства оргпроектирования/моделирования (моделеры) для оргдизайнера не так уж важны. Но стремиться нужно к моделеру, который даст вам исполняемую/actionable оргмодель. Важна не форма модели, а её содержание и то, насколько люди готовы следовать этой модели (записать вы можете любую фантастику в самом лучшем и дорогом моделере, но люди будут делать что-то совсем другое, что им кажется более полезным, в том числе ничего не делать. Содержание сначала, формат моделирования — потом).
Не стремитесь сделать оргмодель формальной, использовать какой-то формальный язык моделирования. Это обычно только ухудшает ситуацию, ибо становится трудно договариваться с другими подразделениями по сквозным кейсам, работы которых выполняются многими оргзвеньями. Оргмодель надо писать не как «программистский код», а как «псевдокод» (и табличная форма тут что-то типа оптимума между «просто текстом» и «текстом на формальном языке»). Делайте какие-то соглашения о моделировании — «что в какой табличке что означает», это часто помогает договориться. Система типов важна, но если ошиблись с типизацией какого-то объекта модели, или даже по-крупному ошиблись с разбиением на оргзвенья (оргдизайн, как и любое современное проектирование, вполне попадает под принцип «непрерывное всё»), то просто переделайте, и будьте готовы постоянно переделывать оргмодели и дальше.
Начинайте с небольшой очень грубой модели, постепенно уточняйте модель. Не стремитесь сразу всё прописать подробно: оргмодель распухнет и без вашей помощи (от вас наоборот, потребуются огромные усилия держать её компактной, не давать распухнуть).
Не забывайте об управлении конфигурацией.

Упражнение

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

Номер п/п	С каким оргзвеном взаимодействие	Предоставляемый вашим оргзвеном сервис	Предоставляемый контрагентом сервис	Документ, описывающий протокол взаимодействия	Issue tracker, учитывающий вытекающие из взаимодействия работы

Задания

Поставьте отметку о выполнении.

Прочитана книга Ian Dietz и Hans Mulder «Enterprise Ontology», 2021.
Опубликован пост, описывающий контринтуитивные идеи книги «Enterprise Ontology».
Описана концепция организации верхнего уровня (не погружаясь на более низкие системные уровни) вашего оргзвена (подразделения или всей компании). В ней отражены в том числе и внешние интерфейсы к окружению (другим оргзвеньям, клиентам, надзорным организациям, контракторам и аутсорсерам и т.д.).
Концепция предприятия обсуждена с коллегами, в документацию (в том числе «исполняемые/actionable» модели в универсальных моделерах и трекерах/программах управления проектами) внесены изменения по итогам обсуждений. Организовано управление конфигурацией концепции организации.
Концепция организации доступна для ваших коллег, они могут использовать её в организации своей деятельности.
Опубликовано эссе с вашими мыслями по поводу результатов проведённой работы оргдизайнера.

8. Практика архитектуры предприятия

Архитектурные характеристики предприятия

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

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

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

Всё это делается для того, чтобы привести в приемлемые значения архитектурные характеристики предприятия (-ilities/-ости, то есть надёжность, масштабируемость и т.д.). Они те же, что и для систем общего вида, небольшое их число отбирается как самые важные для организации и дальше предлагаются меры, чтобы удержать приемлемые для бизнесмена значения этих характеристик. Бизнесмен тут важен, потому как ему надо будет продавать организацию, а её цена будет существенно зависеть от значения этих характеристик. Можно думать об архитектурной работе и так, что оргдизайнеры стремятся удовлетворить прежде всего сиюминутные интересы визионеров (по-быстрому реализовать в организации оргвозможности, позволяющие удовлетворить текущих клиентов, выдать рынку как можно быстрее и дешевле хорошо продающиеся сейчас продукты и сервисы компании), но вот архитекторы следят, что бы формула «деньги сейчас» была более полной (этот вариант был предложен в такой формулировке Элияху Голдраттом): «деньги сейчас и в будущем». Вот архитекторы как раз стоят на страже «денег в будущем»: их задача в том, чтобы организация могла быстро приспособиться к непредвиденным изменениям, которые несёт будущее. В будущем могут быть виражи/pivots (смена направлений деятельности фирмы), резкий рост (проблемы масштабируемости), резкое изменение текущей технологии (переход на иные принципы работы, например, переход к 3D-печати готовых изделий вместо литья заготовок и последующей их долгой обработки), покупка субконтракторов для слияния их организаций с купившей их фирмой, и что угодно ещё. Архитекторы должны держать организацию в форме, которая позволяет это всё «переварить», причём быстро.

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

Каждая связь между модулями имеет свою цену на её организацию, поддержание и отслеживание. Не было бы цены такой связи, не было бы модульности, и это показывается в исследованиях по биологической эволюции²⁰⁰:

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

Для эволюции сугубо технических систем получены похожие результаты, и там считалось, каким образом можно изолировать ошибки в модулях, если пытаться их улучшить в ходе эволюции. В работе «Role of design complexity in technology improvement»²⁰¹ проверялось, насколько хорошо выполняется примерно тот сюжет, который рассказывает Tony Seba в разделе по стратегированию: насколько при наличии улучшений в отдельных модулях системы мы можем уменьшить цену (или, что то же самое — улучшить характеристики, не меняя цены). Бралось число модулей N, число взаимодействий между модулями (connectivity) D и оценивалось падение цены в зависимости от попыток улучшений при случайных мутациях. Вот результат:

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

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

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

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

Исторические подходы к орг-архитектуре

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

Линейная структура управления, которая выживала лучше всего там, где речь шла о каком-то узком ассортименте и массовом производстве. Компания разбивалась на части (а там ещё на части, и так «до самого низу») по стадиям жизненного цикла, «этапам» (жизненный цикл 1.0) — и там осуществлялась попытка реализовать «водопад» или «конвейер». Во главе стоял начальник (мы говорим о полномочиях) как условный «менеджер проекта/продукта»::роль, чья задача была — выпустить работающий продукт (в голове у него — целевая система). Специалисты по самым разным практикам подчинялись этому «менеджеру проекта» (операционному менеджеру) по иерархии управления. И всё отлично работало, пока продукт был один. Проблемы были, когда продуктов оказалось несколько.
Функциональная структура управления, в которой учитывалось, что продуктов выпускается много, жизненные циклы у них разные, а функционально все работы делаются специалистами по каким-то практикам. Это соответствовало пониманию жизненного цикла 2.0. Эти специалисты по разным практикам и стали главными, ибо менеджеров проектов было много, и они торговались за то, чтобы какой-нибудь Олег выполнил свою уникальную работу на ограниченном ресурсе этого Олега в его проекте, а не на проекте другого менеджера. Эта структура оказалась более живучей (в голове у функциональных менеджеров была система создания), но и там были проблемы: вечный скандал за ресурсы. А ещё в дело вмешивались администраторы, которые непосредственно в работе не участвовали, но могли запросто перекрыть кислород любому подразделению, если им что-то не нравилось. В ходу был мем про «леди-хранительницу печати», которая была без полномочий и просто ставила печать на бумаги, подписанные боссом. Но когда она невзлюбила какое-то подразделение, то по самым разным очень творчески придумываемым причинам печать на документах этого подразделения не ставилась — то она была всегда «на обеде, вышла» для этого подразделения, то печать ставилась смазанной, то случайно рвался сам документ, и так всегда. Смысл мема в том, что в функциональной структуре была вечная склока борьбы за ресурсы — ибо операционных менеджеров было много.
Матричная структура управления просто заявила, что она одновременно и линейная, и функциональная. А отдельные люди и отдельные команды подчиняются одновременно и функциональным менеджерам, и менеджерам проектов, причём в случае конфликтов требований они обращаются к своим менеджерам, а те к своим менеджерам, и так до самого верха иерархии, где всё сходилось на генеральном директоре. Формально это было неработоспособно, но по факту работало относительно хорошо: люди уторговывали свои ресурсы в неформальной схеме работы, которая никак не совпадала с формальной структурой полномочий. Поэтому неформально люди понимали, кто в каждой ситуации может давать указания о распределении ресурсов (проектный начальник какого-то уровня или функциональный начальник какого-то оргзвена, связанного с практиками).
Кроссфункциональные команды стали ответом на вопрос о том, что делать отдельным специалистам в матричной структуре. Люди формально оставались работниками в штатном расписании функциональной структуры (подразделение), но их переводили особыми приказами во временное подчинение проектным менеджерам в команды проектов, набирая команду спецов по всем необходимым практикам (кросс-функционально, «через все практики»). Команда проекта подчинялась начальнику проекта, но люди «числились» за функциональными подразделениями. То есть это по факту было восстановление линейной структуры управления при наличии одновременно и функциональной структуры — но жизнь была уже полегче, ибо функциональная структура не менялась, а вот кроссфункциональные команды менялись. Уже не лихорадило с выплатой зарплаты, уходом в отпуск, обеспечением рабочего места и прочим администрированием, ибо работник вроде как постоянно работал на одном рабочем месте, но по факту его оргзвеном была кроссфункциональная команда — и как только она становилась большой и таких команд становилось много, это наследовало все проблемы линейной организации, функциональной организации и матричной организации с её «неформальными коммуникациями».
Горизонтальная структура управления была попыткой отразить тот факт, что люди как-то общаются и утрясают свои дела в неформальной структуре, не совпадающей с границами команд. Рассуждения эти питались двумя идеями: 1. Раз уж ни линейная/проектно-продуктная, ни функциональная по практикам работы иерархии не работают, а матричная структура и кроссфункциональные команды не могут решить этих противоречий, то откажемся от них вообще. Как-нибудь разберёмся неформально, позволим общаться людям всем со всеми, сотрудничать во всём. 2. Утопические социалистические идеи коммунального существования (фирма-колхоз, коллективное хозяйство, «у нас тут дружная семья, все занимаются всем, нет должностей/оргмест, свободная работа свободных людей над тем, что им нравится»). Такой «коммунизм», конечно, в природе существует, но обычно где-то там находится какой-то источник сверхприбыли, который обслуживается очень узкой неформальной группой хорошо организованных (то есть все там понимают, кто чем занят, у кого какие роли, кто что кому делает и как быстро) людей, а остальные изображают «семью» вместо рабочего коллектива, при этом нравы в этой семье часто нездоровые. Этот тренд ухода от иерархии в оргструктуре имеет множество названий. Например, пять-восемь лет назад была очень модна холакратия, но лидеры этого подхода успели отказаться от неё в пользу других оргструктур²⁰². Сторонники спиральной динамики²⁰³ напирают на жёсткую последовательность так называемых «уровней развития», при этом подход общих для всех ступенек развития опровергнут, но до сих пор любят говорить о «бирюзовых/teal организациях», которые тоже игнорируют идею авторитарного подчинения воле руководителя-вождя или даже идею жёсткого следования организационным нормам²⁰⁴, что тоже было в острой моде пять-восемь лет назад, и тоже сегодня уже не модно (но помним про растянутость пелотона: люди, которые узнали об этой идее десяток лет назад, до сих пор продолжают говорить о «бирюзовых организациях» как о менеджерском фронтире).

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

В итоге исторически победила формальная функциональная структура, в которой вроде бы считается, что подразделения (не оргзвенья! «подразделения согласно иерархическому штатному расписанию, со структурой подчинения строго по иерархии») организованы 1:1 в соответствии с функциональной декомпозицией (одна практика работы, выполняемая одной организационной ролью, соответствует одному подразделению). Поэтому функциональная декомпозиция по оргролям вроде как была достаточна для понимания концепции организации — а сам такой принцип был как раз архитектурным: «делим всё на оргроли, создаём подразделения, а уж как они общаются — это уж как получится, но при надобности создадим кросс-функциональные команды, в наших архитектурных диаграммах они отражаться не будут». После этого стали популярными изображения типовых функциональный декомпозиций, которые получили название справочных/reference архитектур. Эти типовые функциональные декомпозиции разрабатывались поставщиками корпоративного софта, которым было удобно по подобным диаграммам объяснять, какие функции поддерживает этот софт. Ещё такие функциональные декомпозиции были удобны оргпроектировщикам (называвшим себя архитекторами предприятия), которые брали их за начальную точку в своей работе по оргпроектированию верхнего уровня.

Вот пример справочной архитектуры для банковской деятельности²⁰⁵, и обратите внимание на невозможность обсуждения архитектуры — непонятны взаимодействия между отдельными функциями, это не функциональная диаграмма/принципиальная схема предприятия, а именно что декомпозиция функций. То есть вроде как в названии слово «архитектура» есть, а ничего про интерфейсы и взаимодействие модулей мы сказать не можем, обсудить связность/coupling не можем:

Эта справочная архитектура по старой традиции показана в диаграммном языке архитектуры предприятия ArchiMate²⁰⁶, и в ней выбраны значки практик::поведение «шеврончики вверх», а названия даны вообще для оргролей::функциональных объектов.

Справочная архитектура предприятия ArchiSurance из примера использования языка ArchiMate выглядит так²⁰⁷:

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

Даже диаграммная форма тут лишняя: показана просто функциональная декомпозиция предприятия (отношения часть-целое показаны вложением графических элементов, но могли бы быть показаны стрелочкой с ромбиком на конце, как это рассказывалось в курсе «Системное мышление»). Эти справочные архитектуры вполне могут быть отражены в аутлайне/outlines (иерархическое оглавление, вложенные списки).

Эти типовые/справочные разбиения практик чисто исторически называются «архитектурами». Архитектура занимается не столько функциональными описаниями в концепции системы, сколько накладывает ограничения на конструктивное описание. Орг-архитектура сегодня — это:

принципы разбиения предприятия на модули (часто и само верхнеуровневое разбиение), то есть на оргзвенья (не только подразделения, но и структуры вне штатного расписания — комиссии, кросс-функциональные программы, интегральные команды введения в эксплуатацию/integrated delivery teams, «производственные кооперации» из организованных согласно договору подрядчиков вне границ текущего юридического лица и т.д.).
принципы организации взаимодействия этих модулей между собой (интерфейсы, возможность непосредственного взаимодействия оргзвеньев/«видимость модулей», средства коммуникации, способы организации совместной работы).

Мы намеренно не упоминаем в нашем курсе многочисленную литературу по классической архитектуре предприятия, рассказывающие о старинных идеях. Мы намеренно не даём ссылки (то есть не рекомендуем к использованию!) на

литературу по ArchiMate (хотя и привели ссылку на спецификацию стандарта, чтобы можно было узнать подробней, что же именно указывалось на диаграммах справочных архитектур),
стандарты IDEFx (из многочисленных этих стандартов берут главным образом стандарт функциональной декомпозиции IDEF0, но читают его как декомпозицию стадий работ — другой стандарт IDEF3, но это опять оказывается не про архитектуру), моделях Захмана (там общие слова, что «оргпроекты нужно моделировать»),
стандарт TOGAF, который очень нравится госчиновникам и бюрократам в крупных организациях — если вам не нужно много общаться с архитекторами организаций, воспитанными на идеях прошлых поколений орг-архитектурной мысли, вам этого не нужно. А если вам нужно с ними много общаться, то вы и сами со всем этим разберётесь, всю литературу найдёте сами.

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

Оргпроект (концепция предприятия и в целом модели деятельности предприятия, раньше «архитектура предприятия»): практики, проекты-процессы-контрольные точки, оргроли и оргзвенья (структура оргзвеньев и их связь: современная орг-архитектура тут), IT-поддержка управления работами.
Стратегия (раньше «бизнес-архитектура»): бизнес-модель, мотивация (полезность, цели), справимся ли мы (capabilities, resources), с какими партнёрами и на каких рынках. А где «архитектура»? Тут, скорее, прописываются архитектурные решения по структурированию рыночной ниши, которую хочет занять предприятие, реверс-инжиниринг архитектурных решений, которые можно предположить (а иногда при формировании новых рынков и навязать) для надсистем целевой системы предприятия прежде всего, а также для надсистемы предприятия как инвестиционной среды. Ну, и слово «архитектура» тут исторически, от древнего понимания «архитектуры предприятия».

Бизнес-архитекторы, тем не менее, имеют уже свои профессиональные стандарты и корпуса знаний (BABoK²⁰⁸ — business analysis body of knowledge, и обратите внимание на ещё один сдвиг в терминологии: уже не бизнес-архитектура, а бизнес-анализ, акцент не на архитектурном синтезе, а на декомпозиции, анализе), свою ассоциацию²⁰⁹ — и если речь идёт о стратегировании и роли бизнесмена, то вам может быть интересно поработать с этими материалами, только не обращайте внимания на слово «архитектура», когда будете читать тексты этих «аналитиков» (тамошние описания имеют далёкое отношение к принципам разбиения чего бы то ни было на оргзвенья и налаживания интерфейсов между этими оргзвеньями).

TEST Бирюзовая организация

!!! Тимофей начитался книг по горизонтальным организационным структурам и настаивает, чтобы кто угодно мог поручить работу кому угодно, игнорируя организационную структуру. Это он называет «бирюзовой организацией» и призывает всех идти в это светлое будущее. Он прав?

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

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

+++ нет, это приведёт к катастрофе в части операционного менеджмента ### Да, выполнение рекомендаций Тимофея опасно для организации: она потеряет модульную структуру. Вместо отмены неудачно проведённых границ оргзвеньев/подразделений/модулей нужно просто лучше провести эти границы (использовать, например, методики DSM/design structure matrix по улучшению модульности).

Современная (SoTA) орг-архитектура

Как всегда, передовые идеи по инженерии надо смотреть в современной литературе по инженерии корпоративных информационных систем, а уже с лагом в десяток лет они появятся в инженерии других видов систем (в том числе инженерии предприятия). Передовые идеи по архитектуре надо тем самым тоже смотреть в литературе по архитектуре корпоративных информационных систем и ожидать далее их появления в практике архитектуры предприятия. Тем не менее, можно уже сегодня использовать эти идеи, строить архитектурную работу на их основе. Эта литература была приведена в курсе «Системная инженерия», самое время вернуться к этому курсу и посмотреть указанную литературу в разделе по архитектуре. Вот основные книги, которые следует хотя бы полистать:

Над каждой книгой стоит год её издания, читать надо слева направо: в 2017 году уточнили понятие архитектуры и в 2022 году выпустили второе издание книги Building Evolutionary Architecture, в 2019 году прояснили каким образом неиерархически думать об оргструктурах в Team Topologies, далее идея архитектуры как отдельной от разработки дисциплины получала развитие по части уточнения как архитектурных характеристик и предложения для них метрик, так и архитектурных паттернов для трудных случаев.

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

Эта современная литература очень контринтуитивна, она противоречит общераспространённым верованиям/мифам про организацию (например, в курсе «Системная инженерия» приводится пример исследования, в котором показывается, что скорости выполнения работы маленькими и большими командами оказываются примерно равными, а вот число дефектов в результатах работы больших команд оказывается больше из-за неизбежного развала конфигурации в силу невозможности точно скоординировать сложную деятельность большого числа людей. Вернитесь к материалу курса «Системная инженерия», найдите это место, посмотрите этот материал с точки зрения идей по архитектуре организации, это ведь не связано с функциональной направленностью работы оргзвена, чем занимался бы оргпроектировщик, это связано с принципами разбиения на оргзвенья, это вопрос орг-архитектора. Оргпроектировщик, конечно, учтёт этот принцип в своей работе — спроектирует организацию с маленькими командами, но вот само указание о том, что команды должны быть маленькие, поступит к нему от орг-архитектора, и ещё орг-архитектор выполнит менторскую функцию, разъясняя оргпроектировщику, почему маленькие команды правильны, и потом ещё выполнит надзор/governance на предмет выполнения этого архитектурного решения).

Материал раздела по орг-архитектуре намеренно короткий (если не считать, что вам обязательно надо прочесть в рамках работы над материалом этого раздела ещё и пару книжек по архитектуре софта и архитектуре организации). Много больше в нашем курсе рассказано (и ещё будет рассказано в следующем разделе, про лидерство) про работу организатора («разработчика» организации), и много меньше — про работу бизнесмена («визионера» организации), орг-архитектора («архитектора» организации), администратора («инженера внутренней платформы разработки/DevOps» организации). Идея тут в том, что большинству придётся так или иначе столкнуться с организацией работы в каком-то проекте — побыть операционным менеджером и менеджером по развитию (оргпроектировщиком, лидером), никуда от этого не деться. И лучше бы это знание разработчика (организатора, в том числе «самоорганизатора» как организатора собственной личности) всем иметь «из коробки», готовое к использованию. А вот знание орг-архитектора и администратора — оно более редкое, поэтому его обязательно нужно иметь на обзорном уровне, чтобы понимать работу архитектора и администратора, когда вы с ними сталкиваетесь, но если вы становитесь профессиональным архитектором и администратором, то вам придётся довольно много доучиваться.

Задания

Поставьте отметку о выполнении:

Прочтена книга Neal Ford, Rebecca Parsons, Patrick Kua «Building Evolutionary Architectures», 2022 (второе издание).
Написан пост с эссе, где вы описываете историю изменения ваших представлений о том, что такое архитектура системы (не ограничивайте себя только архитектурами программных систем, рассуждайте об общеинженерной практике, включая и архитектуры организаций).
Прочтена книга Matthew Skelton, Manuel Pais, «Team Topologies», 2019
Написан пост с эссе, где вы обсуждаете на основе материала книги Building Evolutionary Architecture, что в книге Team Topologies можно отнести к практикам оргпроектирования, а что к практикам орг-архитектуры.
Опубликовано эссе, в котором характеризуется оргструктура (архитектурный стиль) вашей текущей организации. Эта оргструктура линейная, функциональная, матричная, «горизонтальная», или вы её видите как-то по-другому? Какие порождаемые этой оргструктурой основные проблемы наиболее часто обсуждаются в компании? Какие вы могли бы дать предложения по совершенствованию оргструктуры? Приведите примеры орг-архитектурных решений в формате ADR (подробности по этому формату приводились в курсе «Системная инженерия»).

9. Практика лидерства

Лидерство как практика изготовления организаций

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

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

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

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

При этом организация отличается от сообществ, обществ, рынков — отличия хорошо показаны в книге Jan Dietz «The Enterprise Ontology» и связаны с тем, что агенты (actors, оргзвенья) могут давать какие-то поручения друг другу и проверять их выполнение, чтобы удерживать своё существование. Грубый критерий: если у вас есть issue tracker, в котором вы можете завести issue/вопрос, дальше переформировать его в task как единицу работы, которую кому-то можно назначить, потом отследить обещание выполнить работу и факт выполнения работы, затем известить всех, что работа выполнена (notice), то это организация, а если всё это трудно представить — это что-то другое (сообщества, общества, рынки и т.д.), где ничего не надо создавать и развивать, но только разговаривать по этому поводу. Даже если речь идёт о какой-то ассоциации или церкви, то есть работники ассоциации или церкви, которые обеспечивают сервисы членам ассоциации. Но сами члены ассоциации или церкви никаких систем не создают, хотя могут пользоваться сервисами организаций, их обслуживающих, то есть сервисами предприятия/организации, которое и будет называться «ассоциация» или «церковь», и вот возможный issue tracker для этих предприятий как раз будет верным свидетельством того, что мы говорим об организации, а не просто сообществе, рынке или каком-то другом объекте из многих людей. Организованные люди — это когда ясны их полномочия по распоряжению трудом и капиталом в достижении какой-то цели (создании и развитии какой-то системы).

Лидерство может рассматриваться на трёх уровнях сложности систем из людей:

Личный уровень, когда надо как-то «уболтать» себя занять те или иные роли, прекратить спорить внутри себя и заняться каким-то полезным вовне делом.
Уровень организации как оргзвена из нескольких организованных людей и их компьютеров, то есть команды, коллектива, предприятия, холдинга, когда надо «уболтать» занять роли, которые предписаны оргпроектировщиком с учётом ограничений, выданных архитектором и наладить сотрудничество друг с другом на достижение общей цели — создания и развития целевой системы такого, что цепочки создания при этом будут расти в цене.
Уровень сообщества (community of practice, субкультура и т.д. — подробней об этом говорилось в курсе «Системная инженерия», когда обсуждались уровни сложности целевых систем) или даже общества, когда лидер «убалтывает» людей на выполнение ими каких-то практик в чужих организациях. Тут тоже есть оргпроектировщики: иногда это идеологи (например, для политического лидерства или лидерства в какой-то субкультуре искусства или спорта), иногда это всё происходит прямо в организации, если речь идёт о создании клиентуры (продвижение — маркетинг, реклама, продажи), то есть от потенциальных клиентов требуют выполнить практику получения сервиса или товара фирмы, выполнить роль клиента фирмы. Это немножко непривычно, но это тоже вполне лидерство, мало «запроектировать роль клиента компании и практики, которые должен выполнить клиент», отразить их в оргпроекте, надо ещё и «изготовить» этих клиентов.

Наш курс сосредоточится на втором уровне, оставив материал по лидерству в инженерии личности (включая практику саморазвития) и инженерии сообществ (включая практику продвижения как инженерии клиентуры) для других курсов, в которых будет уточнён и вопрос о лидерстве.

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

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

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

Другое название лидерства как практики «изготовления» организации из «просто группы людей и их оборудования» — управление организационными изменениями (organizational change management), или просто управление изменениями (change management — и в этом случае нельзя путать с управлением изменениями в configuration and change management как подпрактикой «железной» или программной инженерии, совпадают только термины).

Какие способы можно предложить для катализирования сотрудничества, то есть объединения труда, разделённого на роли, выполняющиеся отдельными агентами? Henry Mintzberg предложил шесть исторически сложившихся способов:

Взаимная подгонка (как в джазовом ансамбле: договариваются примерно о том, что хотят играть — а потом просто импровизируют и поглядывают друг на друга, подстраиваясь под исполнение друг друга) — хорошо работает в самых простых (когда все понимают, что произойдёт) и самых сложных (когда никто не понимает, что произойдёт) случаях. В менеджменте этому соответствует классическое (без шаблонов) управление кейсами: issues решаются по мере их поступления, необходимые для выполнения работ роли заранее неизвестны, планы работ неизвестны, ничего up-front неизвестно, поэтому и оргпроект неизвестен. Так что перераспределение ролей происходит на каждом шагу. Требуется огромное доверие друг ко другу, а также высокий уровень мастерства команды, коллектива, предприятия. Ибо если приходится заниматься выполнением практик, которые никто делать не умеет, то получится очень плохо. Если джазовый ансамбль из Европы приедет в Индию, то вряд ли он сможет дать хорошее исполнение классических индийских мелодий — сколько бы они не занимались взаимной подгонкой, как бы ни было хорошо устроено договаривание между ними и доверительные отношения внутри команды/ансамбля.
Прямой надзор (приказы из центра, авторитарность). Иногда про это говорят, «руководство» — и понимать надо буквально как «водить чужими руками». Прямой надзор работает в простейших случаях, ибо при принятии всех решений центром (начальством) это становится бутылочным горлышком, масштабируемость будет на нуле, это плохое архитектурное решение. Но помним, что в архитектуре выбирают из плохих решений, а хороших решений нет. Вполне возможны ситуации, когда приказы из центра могут быть полезны.
Стандартизация процессов работы (формализация поведения, бюрократия). Если каждый выполняет точно предписанную ему оргпроектом роль, точно следуя всем деталям прописанной практики, то на выходе ожидается идеальное качество результата. Увы, так не получается — итальянская забастовка как раз сводится к работе только по правилам, с соблюдением всех правил. Жизнь всегда разнообразней любых стандартов. Это основная идея серии стандартов ISO 9000, популярность этого подхода огромная, но исследования регулярно приходили к выводу, что эти стандарты никак не влияют ни на качество работы, ни на культуру предприятия. Бюрократия хороша, когда и впрямь есть много абсолютно одинаковых работ, но тогда всё отлично автоматизируется, и люди не нужны. Но бюрократия обычно означает и стагнацию: вы не сможете изменить процесс даже тогда, когда это абсолютно необходимо. И это будет катастрофой. Поэтому бюрократия — это очень хорошо, но это точно не панацея, и «борьба с бюрократией» совершенно не зря стала устойчивым словосочетанием.
Стандартизация результатов (унификация из ISO 11354). Идея в том, что вы должны унифицировать не процесс, а результат. И тогда успешность деятельности будет гарантироваться тем, что эти результаты соберутся вместе без особых подгонок — если стандартизовать детальки Лего, то даже если их делают разные люди из разных материалов по разным процессам, результаты легко объединяются в общую конструкцию. Это уже много лучше, чем предыдущий пункт! Вы тем самым стандартизируете интерфейс, которым ваше оргзвено обращается в мир — и какой-то продукт можно провести по этим оргзвеньям и получить для него стандартные результаты, поскольку неважно, что за процесс происходит внутри оргзвена, но результат будет предсказуем и понятен. Проблемы тут те же, что при бюрократии: если надо поменять стандарт, то непонятно, как это координировать (те же проблемы, что с микросервисами: они хорошо развиваются, пока не оказывается, что надо менять их интерфейсы — и тут возникает множество проблем по поиску и устранению ошибок). Архитекторы (в том числе орг-архитекторы) очень любят этот способ.
Стандартизация навыков (общий тренинг). Он часто используется в военном деле (если все заканчивали одну и ту же военную академию, то вам хорошо известно, что бы предпринял в той или иной ситуации ваш сосед — примерно то же, что и вы, вас же этому учили в одном классе! Учили и какой-то практике, и какому-то стандарту на результат, при этом «документация» в ваших головах), в медицине (протоколы лечения, конечно, пытаются делать письменно, но когда в американской операционной встречаются впервые хирург, два анестезиолога, линейная сестра, представляются друг другу, проходят чеклист и начинают операцию — они могут надеяться на совместную работу ровно в силу того, что они прошли общий медицинский тренинг, они хорошо понимают, что они делают и как им объединить свой труд).
Стандартизация убеждений и целей (индоктринация). Чаще всего это используется не на уровне организации, а на уровне сообществ. Вы просто говорите, чего нужно достичь, и каждый участник движения сам принимает решение об участии, сам придумывает способ, как приблизиться к цели, сам ищет ресурсы для реализации цели. Например, так устроены разные «движения»: у них нет лидера, нет устава, нет единого центра, нет общего источника финансирования, но люди там индоктринированы: у них одинаковые убеждения и цели, они очень хотят эти цели реализовать. Движение agile в программировании как раз такое, движение экологов как раз такое.

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

Рабочие продукты и корпоративные ритуалы как видимая форма оргизменений

Шаг оргразвития — это когда люди выполняли одну практику (реализовывали одну оргвозможность), а стали выполнять другую практику (реализовывать другую оргвозможность). Каким образом убедиться, что этот шаг сделан? Практики вообще-то невидимы, оргизменения незаметны. Их надо сделать видимыми, для этого нужно использовать моделирование, документированные модели сделают практики видимыми.

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

Чего-то не хватает в постановке практики (не настроено оборудование, не настроен софт, нет ожидания нового продукта дальше по конвейеру, невозможно протестировать старыми тестами новый продукт, и даже «не настроена голова», то есть не проведено обучение новой практике, а ещё нет комплектующих, сырья, форм учёта для новой практики).
Нет времени разбираться и получать беглость в новой практике, а кто-то стоит над душой — принимаем решение работать бегло по старой практике. А поскольку всегда некогда, то по новой практике так и не работаем.
Есть сомнения, что новая практика даст хорошие результаты (при этом «хорошие результаты» понимаются очень по-разному разными людьми!)
Не хочется быть «белой вороной» и делать что-то необычное, поэтому делаем всё по-старому и не выделяемся из массы, к нам не будет лишних вопросов «а что это ты делаешь и зачем».
Банально не выданы полномочия работать по новой практике в форме, которая будет сочтена достаточной (например, устное указание есть, но письменного приказа не было). То есть «практика поставлена, но это не оргвозможность».

Поэтому в простейшей форме новая практика оформляется как чеклист, который необходимо пройти. Внимание к выполнению именно новой практики должно быть поддержано внешне, технически, удерживаться рабочими продуктами (и чеклист прохождения операций по новой практике тут — хорошее решение). Конечно, это требует дисциплины прохождения чеклистов. Но кто недисциплинирован настолько, что не в состоянии проходить чеклисты (то есть не удерживает внимания на важном, даже если это внимание поддержано технологически в экзокортексе или других рабочих продуктах) — те должны быть уволены как не способные к коллективному труду вообще. Ну, или они должны быть настолько выгодны, что к ним может быть приставлен сотрудник-нянька, который заполняет для них чеклисты, но честно рапортует, если практика по этим чеклистам была не выполнена. В любом случае: нет перехода на новые рабочие продукты (и эти новые рабочие продукты надо тщательно готовить) — нет выполнения новой практики. Проверьте, есть ли в вашем шаге развития новые рабочие продукты, по которым вы сможете проверить, выполняется ли в жизни новая практика, или старая, или вообще никакая.

Внимание к новой практике также должно быть поддержано социотехнически, её выполнение должно быть социально приемлемым. Это происходит путём выполнения «ритуальных совещаний» по старту выполнения новой практики. У этих совещаний нет никаких других функций, кроме как продемонстрировать всем причастным (и по возможности непричастным! Их одобрение для причастных тоже нужно!) общеизвестность новой практики, что у этой новой практики нет противников, все возражения сняты, все замечания учтены. На этих совещаниях работает не рациональное мышление, а интуитивное — и считывается не столько содержание речей, сколько «общая атмосфера»: согласие или несогласие с новой практикой, отсутствие возражений и энтузиазм или наоборот, известные проблемы и общая осторожность. Такие «ритуальные» совещания могут быть во множестве самых разных форм, начиная от классического kick-off meeting в проектном управлении и заканчивая тематическим семинаром-совещанием. Семинар-совещание — это такая форма, где основное время идёт «семинар» по содержательным аспектам новой практики (выступают эксперты, консультанты, опытные пользователи, научные работники и т.д.), это происходит как университетский семинар, без учёта полномочий, «все равны перед наукой», а последние пять минут происходит «совещание», где присутствующий начальник раздаёт поручения под запись их в issue tracker, или как раньше говорили, «под протокол», и главные поручения тут — «выделить ресурсы, начать практиковать».

Для подобных «ритуальных встреч» важно, чтобы вся ознакомительная работа по новой практике была проведена до совещания. На самом таком совещании нет прояснения непонятностей, нет принятия решений по каким-то важным вопросам, никакой содержательной работы. Если будут обсуждаться какие-то всплывшие проблемы, то это просто означает, что «новая практика ещё не готова, ей заниматься рановато», и если люди поймут результаты совещания так, то это будет неуспех. Придётся эти все вопросы решать, доводить результаты решения этих вопросов до всех участников до совещания (а не в ходе совещания!), а потом делать новое совещание — чтобы все убедились, что «проблем нет, все это знают». Это совещание — просто «социальный ритуал»: люди должны поглядеть друг на друга и осознать, что нет проблем с новой практикой не только у них самих (ибо с ними самими уже поговорили, возможно неоднократно, ещё до этого совещания), но и у коллег.

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

Табло и визуальный менеджмент

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

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

Этот же принцип «табло», перенесённый на всё то, что происходит в компаниях, называют визуальный менеджмент/visual management²¹⁰. Это не надо путать с «визуальным мышлением» или диаграммным моделированием! Тут имеется ввиду только то, что какая-то модель происходящего оперативно доступна для того, чтобы участники работ могли разобраться в происходящем и скоординировать по ней свои собственные действия. До широкого распространения компьютеров для этого использовались буквально стены, которые обвешивались графиками и диаграммами. Впрочем, «настенные табло» до сих пор в ходу. Вот примеры табло, называемого «канбан-доска»:

Сейчас такое моделирование всё менее и менее популярно, табло/dashboards ушли в компьютеры, и даже дальше — в смартфоны, они доступны отовсюду, не нужно вставать с места и подходить к табло, чтобы оценить ситуацию. Но менеджменту с самыми разными инженерами надо тщательно готовить эти табло и их использование для организации труда в больших коллективах (это не всегда так очевидно, как использование табло для нахождения места регистрации багажа и гейта выхода к самолёту в аэропортах). Если не иметь табло, вам придётся переходить к координации путём выдачи указаний, это сразу создаёт проблему дополнительного человека, который будет выдавать указания многим людям и немедленно станет ограничением потока — но и тут будет проблема, ибо принимать решение «что кто с чем когда будет делать» такому человеку-руководителю (буквально, от «водить чужими руками») всё равно придётся, и ему нужно будет ровно то же табло, по которому разумные люди и сами могли бы принять решение о том, что и когда им нужно делать. Поэтому по возможности переходите на визуальный менеджмент, старайтесь, чтобы работу выдавали не одни люди другим, а люди её брали сами, ориентируясь на тщательно спроектированные табло — всевозможные компьютерные dashboard.

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

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

Лидерство для достижения уровней сотрудничества

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

Игнорирование (ignorance) того, что делают другие люди, можем даже нанести им вред. При этом иногда заявляют «ничего личного, это бизнес» — и что самое интересное, и заявитель такого верит, что это отличное оправдание, и даже те, кому вредят, вроде как «понимают мотивы». А поскольку игнорируем, то никакого общения, делами других не интересуемся, свои дела никому не показываем.
Информирование и общение (networking): готовы общаться, но не готовы ничего менять в своих планах и действиях. Если кто-то готов подстроиться под нас, то и хорошо. Но сами работаем, как работаем. Скажем, вывешиваем часы своей работы — но не готовы их менять даже когда кому-то очень надо.
Координация (coordinated networking): готовы поменять какие-то свои планы и действия. Например, поглядеть на часы работы соседа и прийти в его рабочие часы. Заполнить форму, какую от меня требуют в той системе, в которой требуют, а не написать заявку в произвольном формате и отослать личным письмом.
Кооперация (cooperation): участвуем в разделении труда и ресурсов, то есть договариваемся о том, как взаимодействуем на входных и выходных интерфейсах, согласовываем всё с соседями. При этом ответственность за то, что всё в целом будет как надо, у участников кооперации отсутствует. Если пиджачок сшит криво, и он ко мне попал на пришивание пуговиц, то я пришью пуговицы крепко, зубами не оторвёшь: к пуговицам точно претензий не будет, а что пиджачок в итоге кривой — не моя забота.
Сотрудничество (collaboration): делёжка не только трудом и ресурсами, но и ответственностью за общий результат всех участников работы. Но это труднодостигаемо, ибо требует удержания у каждого участника понимания не только его собственных операций, но и их влияния на результаты в целом (по факту — требует системного мышления от участников кооперации).

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

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

Это огромная проблема: непонимание того, что относится к плохому оргпроекту и плохой администрации (плохая работа оргпроектировщика, работа администратора), плохим практикам работы инженеров целевой системы, а что относится к «менталитету», «психологии и социологии», «корпоративной культуре» и прочим «человеческим» аспектам, с которыми должны работать лидеры. Показательным примером тут может быть американское автомобилестроение. В конце 70х годов прошлого века обнаружилось, что американские автомобили по качеству и характеристикам сильно хуже японских. Это было удивительно, поскольку Япония традиционно ассоциировалась со страной удивительно низкокачественной техники. Но было найдено «объяснение»: качество японских автомобилей лучше, ибо их делают японцы, у которых национальная культура сотрудничества, менталитет принадлежности к группе, и тут американцам с их ярым индивидуализмом делать нечего. В 1981 году политическое давление со стороны США привело к появлению экспортных ограничений на автомобили из Японии²¹², и Тойота решила, что она откроет производство автомобилей в США. Приехало несколько менеджеров из Японии, и организовали из тех самых «рабочих-индивидуалистов» обычный для них завод Тойоты, в котором использовались тогда абсолютно новые и мало известные средства организации труда, потомки которых мы рассматриваем в наших курсах (lean manufacturing, цикл обеспечения качества Дёминга-Шухарта, и т.д.). И с этих «американских японских заводов» начали выпускаться автомобили вполне японского качества, японской цены, абсолютно конкурентоспособные в США. Тем самым оказалось, что роль корпоративной культуры в части «менталитета рабочих» сильно преувеличена: в хорошо организованной производственной системе сотрудничество людей получается проще. Поэтому первый ход на обеспечение сотрудничества, улучшение корпоративной культуры — это та самая «распожаризация», потом нормальная архитектура организации, потом надлежащее документирование оргпроекта. Нельзя сказать, что корпоративная культура наладится сама собой в хорошо спроектированной организации, но хорошая корпоративная культура в плохо спроектированной организации не появится вообще. Результатов не будет. Хороший лидер без хорошего оргпроекта делает бесполезную работу: все поголовно будут любить друг друга и воевать против жестокого к ним внешнего мира, но результатов не будет, бизнеса не будет. Но и хороший оргпроект сам не заработает, без лидера его не сделать.

Лидер тем самым работает одновременно с тремя описаниями/views сотрудников:

Модульное организационное рассмотрение, каждый сотрудник — оргзвено, имеет некоторые полномочия, известна его структура подчинения, известна ресурсная обеспеченность, на него назначены некоторые роли. Это берётся из оргпроекта.
Деятельностное/проектное/оргролевое рассмотрение, какую деятельность должен уметь исполнять человек-актёр в своей роли. Это тоже берётся из оргпроекта.
Рассмотрением воли/актёра/«психологического и социологического человека» — вопрос о целях работы по роли, умении работы по роли, ролевом мастерстве (в том числе умению быстро входить в роль, быть собранным и произвольно не выпадать из деятельности по роли в связи с потерей внимания к важным для роли объектам, умение безопасно выходить из роли, умение не отождествлять себя и роль — нам на сцене не нужен принц Гамлет, это будет означать, что Вася сошёл с ума и его надо отправить в психушку. Нам нужен Вася, играющий принца Гамлета и не путающий реплики по игре и реплики самого Васи, поведение принца Гамлета и поведение самого Васи).

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

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

Современное лидерство заключается не в работе лидера по «убалтыванию» каждого конкретного человека заняться в режиме сотрудничества (а если не получится, то хотя бы в режиме кооперации, а если не получится, то хотя бы в режиме координации) работой по какой-то практике в какой-то роли в составе какого-то назначенного на эту роль оргзвена (то есть «убалтывание работать и сотрудничать согласно оргпроекту»), но в создании атмосферы/культуры лидерства, в которой буквально каждый человек становится лидером. Это означает, что оргпроект должен быть известен всем, и все помогают друг другу организоваться на выполнение работ и сотрудничество в ходе этих работ.

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

Рэкет: вас обещают оставить в покое и защищать, только делайте своё дело. Если не будете делать, то вас побьют. Иногда буквально («тёмная» — это когда в детдомах или тюрьмах накидывают на голову избиваемого одеяло, чтобы было не видно, кто бьёт). В колонии Макаренко мы охотно верим, что никто из педагогов пальцем не трогал вчерашних беспризорников. Но вот что там делали старые беспризорники с новыми, чтобы те вдруг резко улучшили своё поведение — это история умалчивает. «Пахан берёт зону» примерно теми же методами. Он никогда не действует сам, он просто объясняет людям, какие там правила поведения, реплицирует «правильные» для него мемы. И одни люди вдруг начинают насилие в отношении других, которые нарушили эти «справедливые правила», разве что это на самом деле не «справедливые правила», а тщательно сконструированный мемокомплекс. Кто не хочет исполнять правила — тех банально бьют, устраивают им бойкот.
Манипуляция. Скажем, вам нужно уговорить свежепришедшего в театр Васю играть в пьесе роль Офелии (ибо актёров на неё нет), а он хочет играть принца Гамлета (но на неё есть уже пятеро претендентов, один лучше другого). Вы хвалите Васю за его способности, и мимоходом замечаете, что у вас есть роль Офелии, но мастерства у Васи не хватит эту роль сыграть. И упоминаете театр кабуки, где развита традиция мужской игры женских ролей. Через неделю Вася приходит и говорит, что он погуглил про кабуки, и признаёт, что это большое искусство, но у него впечатление, что он бы там вполне справился, ибо талантлив. Вы говорите, что это Япония и традиции, а у вас тут Шекспир, и многое придётся не просто повторять за мастерами, а придумывать самому, и кроме талантливости нужны ещё и мозги. Вася через неделю приходит и рассказывает, что выходил в образе из дома, прогулял по городу пару часов — и никто ни о чём не догадался! Вы изображаете большое сомнение и даёте Васе попробовать роль Офелии в дневном спектакле, снимаете на видео и пару часов разбираете ошибки. Через пару лет Вася докладывает на международной конференции театрального искусства об опыте игры роли Офелии по традициям Кабуки.
Индоктринирование: прямое объяснение, что нужно жить дружно, «нипочему, просто нужно, потому что мы команда и один за всех, все за одного, и своих не выдаём».

В жизни, конечно, встречаются все формы. Рэкет, конечно, будет не в форме устраивания «тёмной», но может быть и в более тяжёлой форме «подсидки» (намеренное создание какими-то людьми такой ситуации, когда вы будете обвинены в решениях и действиях, которые привели к большим убыткам — и там выговор и даже увольнение могут оказаться не самым большим наказанием, а вам придётся иметь дело со службой безопасности или даже полицией). Задача лидера в том числе и в том, чтобы минимизировать рэкет как форму.

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

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

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

Лидерство — это практика всех актёров, которую надо организовать, всех в организации надо научить быть лидерами. Этому посвящено довольно много книг. В частности, в серии книг подхода TameFlow кроме потока работ, финансов, информации вводят ещё и психологический поток, который ровно про эту самую корпоративную культуру²¹³. В принципе, все эти рекомендации сводятся к свободе критики, свободе инициативы, выполнению правил содержательной ролевой коммуникации (критика поступков, критика решений, но не критика личности, которая всё это делает). Ещё важно учитывать разницу страновых (а иногда и региональных внутри страны, а иногда и отраслевых в каких-то бизнес-экосистемах) культур. Мы не будем тут рассказывать о разных методах, которыми вы должны работать с корпоративной культурой, о разных заблуждениях. Например, типичное заблуждение тут — это использование выдвигаемых психологами идей типа «давайте соберём людей с какими-то разнообразными мыслительными стилями, и они составят замечательную команду». Далее предлагается больше сотни вариантов этих «мыслительных стилей», «черт характера» и т.п. Увы, не работает. Вот уровень интеллекта повыше у членов команды, умение его поднять при помощи технических средств, то есть личных и коллективного экзокортексов — это работает, знание интеллект-стека работает, а также знание всех необходимых для работы прикладных практик. Если просто собрать команду, совместимую «по гороскопу», «по слаженности характеров», «по соционике», «по мыслительным стилям Адизеса» или любым другим «психологическим», «астрологическим», «социологическим» характеристикам, то содержательно она не сможет работать. Хотя, может быть, сможет «дружить», но повторим: цель лидерства — это не любовь и доверие друг ко другу, это сотрудничество, то есть продуктивная/результативная слаженная работа, предполагающая решение проблем. Важно не «дружить», важно работать и решать проблемы. А работать надо уметь. Не умеешь — будь ты трижды совместимым с командой, ты команде не поможешь! Умеешь, но не можешь удержаться в нужной роли — результат тот же, то есть отсутствие результата! И вот таких заблуждений по поводу продуктивности идей психологии и социологии в менеджменте в целом и в лидерстве в частности — множество.

Это вовсе не означает, что лидер (то есть каждый человек в организации! И вдвойне менеджер, ответственный за организацию атмосферы, где катализируют сотрудничество все, а не только он один) не должен быть образован в области психологии, социологии и их приложений в форме практик лидерства. Лидерству как подпрактике менеджмента развития тоже надо учиться, как и любой другой подпрактике менеджмента.

Так что внимательно читаем самые разные книги по лидерству (в частности, вопросам корпоративной культуры, вопросам лидерства уделено много внимания в рекомендованных в курсе «Системная инженерия» книгах по DevOps, а также в нашем курсе), но учитываем при этом, что задача лидерства не просто «катализировать сотрудничество», но «катализировать сотрудничество в рамках оргпроекта» и сделать так, чтобы лидерство продолжало работать в условиях отсутствия организатора выполнения этой практики: если кто-то заартачился и перестал выполнять требования работы по своей роли (например, отказался проходить чеклисты в своей практике), то ему укажут на недопустимость такого поведения все находящиеся рядом сотрудники, даже если рядом не будет «главного лидера, ответственного за лидерство».

Шаг развития: постановка оргвозможности

Решение о шаге развития принимает бизнесмен, ибо это инвестиция в новую оргвозможность, которая может быть удачной (вести к повышению стоимости фирмы) или неудачной (инвестиции будут сделаны, но приведут к чистым убыткам), и бизнесмен должен как-то оценить выгоду от предпринимаемого шага развития. Это решение бизнесмена отражается в стратегировании: стратегия либо будет предусматривать какой-то шаг развития, либо этот шаг развития в стратегии будет отсутствовать.

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

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

Это очень, очень дорогие решения. Например, возьмём классический управленческий/финансовый учёт «мира себестоимости» и управленческий учёт по методу учёта прохода/throughput accounting, да ещё и с идеями beyond budgeting. Предположим, что вы всех уговорили (что очень непросто! Об этом будет чуть дальше), но дальше:

Вам надо поменять учебники, поменять образовательные программы. Вы обнаружите, что по реально новым практикам ничего этого нет. Зато изобилие дешёвых программ отличного качества по старым практикам, о которых вы знаете, что они уже не работают.
Обойти законодательство (придумать схемы, ибо законодательство настроено обычно на старые практики), выработать рекомендации (хотя в фирме ещё нет опыта работы по новой практике и эти рекомендации надо где-то брать), заменить все наработанные ходы и лазейки, которые работали для старых методов управленческого учёта.
Поменять софт, который поддерживает только старые практики. Это неожиданно будет больно и дорого, ибо в софте «всё со всем связано», а финансовый учёт вездесущ.
Если вы собственник, то вам польза новой практики управленческого учёта очевидна. Но если не собственник — то вас всё устраивает, вам непонятно, зачем менять что-то привычное на кому-то зачем-то нужное непривычное. Более того, вы хорошо разобрались в старом методе учёта, а тут все ваши знания в одночасье превратятся в тыкву: не факт, что вы быстро разберётесь в новой практике.

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

Eliyahu Goldratt постоянно подчёркивал во всех своих работах, что «что менять» — это технический вопрос, «на что менять» — это тоже технический вопрос, тут никаких эмоций. А вот «как вызвать изменение» — это вопрос психологический, и дальше он обсуждал «снятие сопротивления» примерно так же, как обсуждают продвижение, например, в методе SPIN Neil Rackham²¹⁴. По большому счёту, речь в «технических вопросах» идёт об обычной процедуре принятия технических решений (но акцент тут делается на разъяснениях: не просто признание проблемы, на решение которой надо тратить время кем-то одним в организации, но на достижение согласия большинства коллектива по этой проблеме. Не просто генерирование альтернатив, но и получение общего согласия по возможным путям решения. Не только выбор альтернативы согласно SoTA теории решений кем-то одним, но получение общего согласия, что решение действительно решит проблему с наибольшей вероятностью и наименьшим риском по сравнению с другими альтернативами.

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

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

Шаг развития — это один кейс из их бесконечной цепочки. Пока развитие есть, организация живёт. Если развития нет, то организация по факту мертва. Вот некоторые замечания об условной последовательности подкейсов в кейсе/шаге развития²¹⁵:

Выработать стратегию. Стратегирование нужно для того, чтобы рационально понять: что на что менять (технический вопрос). Это самый сложный вопрос: понять, что с какой-то практикой и исполнителями ролей в этой практике проблема, и как именно решать эту проблему. В части лидерства само признание проблемы может быть неочевидным, и уж тем более выбор способа решения проблемы.
Выполнить «Пропитку», одну из ведущих лидерских практик. «Пропитка» примерно соответствует работам стадии снятия возражений по Goldratt и Rackham: нужно дать людям ощущение безопасности (отсутствия вредных последствий для всех вместе и для каждого). В крупных организациях для больших изменений это может занимать от 4 месяцев (не «до четырёх месяцев», а «от четырёх месяцев»). Почему «пропитка»? Вам нужно пропитать знаниями о предлагаемой оргвозможности всех, как губка пропитывает воду. Проблема в том, что люди общаются, а ЛПР (лица, принимающие решения) понимают, что сами они не во всём разбираются, поэтому советуются с самыми неожиданными людьми. И решение по факту принимают не они, а кто-то рядом с ними. Вы не знаете, кто этот «кто-то рядом» и в какой момент он, пользуясь безусловным доверием ЛПР, будет давать ему советы, которые для ЛПР будут важнее ваших обоснований, поэтому ваша задача — объяснить осмысленность и безопасность предлагаемого оргпроекта всем вообще (при этом «серые кардиналы» могут быть и за пределами предприятия, поэтому иногда полезно к пропитке подключать и PR-службы, чтобы и вовне предприятия понимали происходящее). Не будет «пропитки» — будет вечный саботаж, и вы не будете понимать, откуда этот саботаж происходит. И не поймёте, люди общительны и не раскрывают вам того, как они принимают решения в ситуациях сильных эмоций (помним, что реформы/трансформации/оргизменения — это всегда сильные эмоции, ибо затрагивают чувство безопасности, повышают неопределённость ожиданий по поводу будущего. Ещё важно обсуждать только технические вопросы: «как и почему всё будет работать», «как и почему мы преодолеем все возможные препятствия», «почему не будет нежелательных последствий», а вот «кто именно это будет делать» не обсуждать, ибо пока нет понимания, что именно делается, согласия по тому, кто это будет делать не удастся достичь, плюс появится лишняя линия разговоров про делёжку полномочий и ресурсов, это только замедлит обсуждение. В части проведения ритуальных совещаний по старту изменений — это ровно стадия «готовить вопрос». Это долго, реально долго.
Принять оргрешение. Нужно правильно определить момент, когда можно будет принять оргрешение так, чтобы оно дальше не саботировалось. Если раньше, чем сняты все возражения, то получите войну всех со всеми. Если позже — просто потеряете время, то есть потеряете конкурентоспособность. Оргрешение — это принятие решения по поводу полномочий. Обычно документирование этого решения (устное оргрешение решением не считаем) делается в форме приказа по предприятию (подразделению, оргзвену), но это может быть письмо, изменение каких-то организационных реестров, что угодно в части документирования. Главное, чтобы это было в виде решения для немедленного исполнения, принятое кем-то полномочным для распоряжения упомянутыми в решении трудовыми ресурсами, а иногда и капиталом. Это решение иногда идёт с демонстрацией самых разных виз, чтобы уж точно не было сомнения, что решение хорошо подготовлено и со всеми согласовано. Очень часто принятию оргрешения сопутствует проведение «ритуального совещания по старту оргпроекта» (где полномочное для принятия решения лицо убеждается, что особо возражающих нет, все основные проблемы отвечены), и решение документируется сразу по итогам такого совещания. В приказе указываются двое ответственных: 1. Кто будет менеджером проекта развития и 2. Кто будет менеджером создаваемой оргструктуры. Это не про роли, это про должности, и не факт, что это одно и то же лицо. Скажем, директор фирмы выпускает приказ, что создаётся отдел вышивки крестиком цифровой нитью, которое возглавит Фёдор как начальник отдела, а созданием подразделения будет заниматься Ксения как начальник дирекции по развитию. С Ксении будут спрашивать, как двигается проект создания отдела, а с Фёдора будут спрашивать результаты первых вышивок крестиком.
Найти специалистов. Эта стадия может быть неожиданно долгой, ибо всё время будут не оправдываться ожидания. Например, не удастся нанять их «с рынка», ибо для новой практики (тем более, если она реально остромодна) специалисты будут стоить примерно столько же, сколько футболисты в лучших командах мира, и у вашего предприятия на них банально не будет денег. Переобучить имеющихся специалистов не получится не потому, что они старые (старые — это умные, опытные) или не хотят учиться (ещё как хотят! Они всё понимают, что с ними будет, если они не выучатся новой практике): просто кто будет делать работы по старым практикам? Самые опытные специалисты как раз перегружены работой по текущим проектам, и если их отвлекать на обучение новым практикам, то это затянет сроки выполнения текущих работ. Поэтому надо нанимать новых людей — и отсаживать их отдельно, чтобы они получили возможность развернуть работы по новым практикам, не мешая ведению старых работ. Самое простое — это взять необученных людей с хорошим общим интеллектом (скажем, не потерявшим вкус к математике, это хороший критерий) и за три месяца обучить их целевой практике. Кто будет учить? Скорее всего, поставщик технологий, что будет рассмотрено в следующем пункте. Но сначала нужно иметь того, кто будет учиться. Запоминаем: от трёх месяцев на обучение, затем ещё от трёх месяцев на получение первых результатов, которые можно без слёз использовать в деле. Да, так долго: вам нужно примерно полгода, чтобы у вас появились специалисты. Но зато они у вас будут, и будут по приемлемой цене. Главное тут не ошибаться: например, если вы берёте человека на то, чтобы он занялся моделированием каких-нибудь теплообменников, берите инженера по теплообменникам, а не программиста (надо понимать хоть что-то в теплообменниках хотя бы в общих чертах, опыт программирования как записи результатов моделирования на формальном языке тут не главный!), так что будьте тут внимательны к общему образованию. Это обсуждается в курсе «Образование для образованных».
Выбрать и закупить технологию. Этим будет заниматься вновь нанятый будущий специалист. Ему не придётся много работать, ибо поставщики технологий обычно занимаются активным маркетингом, и вы обнаружите несколько таких конкурирующих поставщиков, которые сами выйдут на контакт с вашим специалистом, они ведь мониторят ровно такие оргпроекты, какой вы затеваете. Это обычное принятие решения с разными альтернативами (вы довольно быстро разберётесь). Тут надо понимать, что решение принимается политически, а не присуждается «победа по очкам: 514 очков победили 511 очков для решения ближайшего кандидата». Надо помнить, что «текущий лидер отрасли» — это именно «текущий лидер», вчера там мог быть кто-то другой, завтра будет кто-то другой. То есть вы можете быть правы на прямо сейчас, а завтра всё поменяется. Но и это не главное. Главное — это помнить о неустроенностях/frustrations, самые разные текущие системы имеют примерно одинаковую приспособленность (техно-эволюционный fit) к текущему окружению. Любое решение придётся дорабатывать, адаптировать. Чтобы воспользоваться какими-то тонкими настройками, придётся разобраться в этих решениях — и если вдруг этих настроек не обнаружится, то к этому моменту у вас будет какой-то опыт работы и всё сведётся к решению задачи совершенствования (поменяете инструмент, а не всю практику, включая обучение людей дисциплине практики), что в разы проще и быстрее. Поэтому выбираете из тех технологий, которые поддерживают нужную вам дисциплину, но вот необязательно самую дорогую и навороченную, или необязательно самую разрекламированную — но ту, по которой вам легче всего получить согласие на закупку, не останавливайтесь в analysis paralysis, то есть не теряйте времени на попытках разобраться в ситуации неустроенности/frustrations, лучше и понятней не станет, просто потеряете несколько месяцев. И вот тут не ошибитесь: закупать надо одновременно эту технологию и услуги по «настройке» (доработкам технологии для работы в условиях вашего предприятия плюс обучение ваших людей работать с этой технологией, включая обучение вашего будущего главного специалиста, которого вы только что наняли и который будет главным ответственным за выполнение этого контракта). Один контракт (технология плюс настройка с обучением). Избегайте оказаться с закупленной технологией в тот момент, когда непонятно, кто будет вам помогать её освоить. А ещё бойтесь консультантов, которые пришлют работать в проекте очень умных людей в попытках научить их новой технологии за счёт вашей фирмы прямо по ходу проекта (это в жизни случается регулярно). Нет, вам нужны люди, у которых уже есть опыт работы по этой технологии и которые её уже где-то развернули. Да, эти специалисты могут быть чуть дороже, но зато дело будет быстрее, тут время — деньги.
Развернуть/настроить технологию и обучить людей. Выполняется контракт на разворачивание технологии и обучение людей. В этот момент могут выполняться какие угодно проекты, но вряд ли они будут кому-то полезны.
Начать работать. Вряд ли вы переключите на новую технологию всю фирму, но в тот момент, когда технология уже более-менее развёрнута и люди более-менее научились избегать новичковых ошибок, надо взять самые срочные, самые «горящие» проекты и начать тушить тамошние пожары при помощи новой технологии. Все будут удивлены, что новая технология работает и даже помогает. Дальше надо выполнить более-менее собранно множество шагов совершенствования, то есть довести результаты до абсолютно приемлемых по качеству в основной работе фирмы, а также чётко определить входные и выходные интерфейсы для заказа работ по этой новой практике, возможно придётся предпринять какое-то масштабирование. Если всё очень удачно, то можно даже вывести сервис этой оргвозможности на рынок как отдельное продуктное/сервисное предложение предприятия, но это бывает редко.
Вести непрерывное совершенствование. В этот момент по факту шаг развития закончен, оргвозможность есть. Работаем над её совершенствованием, но помним: приоритеты совершенствования определяются глобально по предприятию, а не локально (то есть нужно помнить про подход TameFlow, чтобы не трогать неважное и не тратить на это ресурсы, но каждый раз решать проблемы ограничения. Если новая практика перестаёт быть ограничением, то на её совершенствование не должно уходить много ресурсов, лучше эти ресурсы использовать для работы с другими практиками).
Упразднить морально устаревшую оргвозможность. Не забывайте, что в какой-то момент вся эта «новая практика» окажется совсем не новой, она морально устареет, её саму нужно будет менять. Не прозевайте учесть это моральное старение и только технологии практики (если просто речь идёт о старом оборудовании или древних поколениях софта), и всей практики (технологии и дисциплины) в ходе непрерывного стратегирования, переходите на начало цикла.

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

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

Осваивать что новую практику человеком, что организацией из многих людей в принципе одинаково. Как учатся водить? Учатся одновременно крутить руль, следить за дорогой, нажимать на педали, следить за приборной панелью, ориентироваться по карте — и это кажется крайне сложным. Тем не менее, через некоторое время вы обнаруживаете, что не просто ведёте автомобиль в довольно сложных дорожных условиях, но ещё и ухитряетесь при этом разговаривать с пассажирами. Но освоение — по ломтику/slice/chunk (принципу, микросервису, освоенной операции) за раз. Каждый раз реализуем не полный сценарий использования, а частичный (как в Use Case 2.0²¹⁶, к организационным системам эта практика и аргументы в её поддержку полностью применимы).

Немножко совершенствоваться после каждой существенного продвижения в функциональности, то есть не копить грубых ошибок и добиваться хоть какого-то привыкания-автоматизма, но и не застревать! Тут напомним практику SRE (site reliability engineering²¹⁷, этой практики касались в курсе «Системная инженерия»), вариант DevOps, где один из основных акцентов — это не торопиться с новой функциональностью, если не преодолены дефекты текущей функциональности, не двигаемся вперёд, пока работаем за пределами какого-то достаточно низкого уровня дефектов. Исправили дефекты — и тогда опять вперёд!

Нельзя запускать в освоение сразу много практик, никаких ресурсов не хватит. Помним, что все из идей TameFlow и The Principles of Product Development Flow универсальны, и приложимы в том числе к проектам оргразвития. Или вы работаете над рабочими проектами для клиентов, или работаете над развитием для вашей организации — время каждого работника вы делите между этими двумя деятельностями. Нельзя только обслуживать клиентов, ибо накопится организационный и стратегический долг, но и заниматься только развитием нельзя, ибо тогда некому будет просто работать и зарабатывать деньги на то самое развитие. Ну, или у вас есть богатые инвесторы, которые оплатят вам время развития, и клиенты, которые готовы долго ждать. Но это может быть у маленького стартапа, в крупной фирме такой роскоши не будет.

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

Проблемы с неумением людей и неумением (например, отсутствием) софта — это одни и те же проблемы. Увы, довольно часто мы видим набранных сотрудников, которым предлагается работать по новой практике, но софта, который бы поддерживал эту практику, ещё нет. Руками в 21 веке уже не работают, запускайтесь только с поддержкой со стороны софта, только с работающим оборудованием! Почему-то людям не приходит в голову куда-то ехать на автомобиле, в котором не хватает пары колёс и который не заправлен бензином. Но в случае работы какой-то службы с неё начинают требовать результатов ровно в похожей ситуации, ибо люди вроде как универсальны и могут стать сами кем угодно или даже чем угодно. Но нет, чудес не бывает, люди не так уж и универсальны. Поэтому разбирайтесь каждый раз, в чём причина невозможности работы по новой практике: это не всегда саботаж.

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

Собранность при этом должна быть на удержании принципов/дисциплины («духа практики»), а не технологии («буквы практики», внешней формы практикования). Для этого сотрудники должны обучаться не только и не столько технологии, но прежде всего дисциплине практики, это занимает много больше времени.

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

Выработать стратегию.
Выполнить «пропитку» себя самого: это будет относительно медленное понимание масштаба проблемы, в том числе осознание, что нужна внешняя помощь провайдера обучения. Это может занять и несколько лет!
Принять решение о приобретении мастерства: перейти к действиям, выделить ресурсы (поставить дела в текущий список приоритетных в личном списке дел к исполнению).
Выбрать провайдера обучения, заключить контракт. При необходимости закупить технологию, а иногда и расходные материалы.
Перестроить образ жизни, выделить достаточное время ежедневно (не менее часа-двух в день, иначе не получится «зажечь мастерство»²¹⁸)
Пройти курс, не бросить при первых же трудностях (собранность).
Практиковать, то есть использовать результаты курса в жизни, иначе зачем учились?!
Продолжать совершенствовать мастерство, при этом освоение компетенции обычно конечно, это не вечная учёба! В случае иностранного языка в какой-то момент надо перестать его учить! В случае школы танцев надо в какой-то момент перестать ходить на занятия и ходить на вечеринки! Конечно, время от времени можно поднимать квалификацию, но это не означает, что это нужно постоянно делать с любым своим мастерством. Хотя учителя будут настаивать на продолжении занятий, помним, что ресурсы на совершенствование определяются глобально, а не локально. Если хотите стать лучшим в мире, и это профессия — занимайтесь. Если нет — занимайтесь тем, что приоритетнее.
В какой-то момент — выкинуть своё морально устаревшее мастерство на помойку и идти учиться чему-то новому, более актуальному.

Упражнение

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

Номер п/п	Организационный конфликт	Роль, выполнение которой под вопросом	Исполнитель роли	Ваша позиция по конфликту	Что говорит оргпроект (и как он документирован, насколько он актуален)	Предложения по решению конфликта

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

Номер по/п	Проект оргразвития (какая оргвозможность ожидается)	Текущая стадия	Предложения по сдвижке к следующей стадии: что нужно предпринять?
1.
2.
3.

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

Номер по/п	Проект личного развития (какое мастерство ожидается)	Текущая стадия	Планы по сдвижке к следующей стадии: что будет предпринято?
1.
2.
3.

Задания

Посмотрен дополнительный материал по переходу от пропитки к принятию оргрешения (для розового слайда): доклад А.Левенчука про постановку практик и его обсуждение, видео с 1:02 до 1:43 (41 минута доклада) — https://youtu.be/3iokMv1Sdpk?t=3709
Опубликовано эссе с вашими соображениями по текущим проблемам в известных вам проектах организационного развития.
Запланировано, подготовлено и проведено «ритуальное мероприятие» для продвижения организационного изменения, в котором вы заинтересованы. Учтено, что на самом мероприятии ничего неожиданного и содержательного для участников не должно происходить: цель — чтобы все убедились в том, что предлагаемое организационное изменение хорошо обсуждено и нет существенных возражений. Поэтому основной акцент — на подготовку к мероприятию.
Вами организовано и опубликовано (все знают, где находится) табло с постоянно обновляющейся информацией по вашему текущему рабочему проекту организационного развития.

Личное целеполагание как практика лидерства

Вся деятельность организации глубоко ритмична. Если вы не замечаете повторения у себя каких-то действий во времени (паттернов во времени/ритмов/циклов/cadence), вы что-то делаете не так. Есть два основных метода планирования неожиданных работ:

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

Работа по опросу более надёжна, чем по прерыванию²¹⁹. С одной стороны, работа по опросу оказывается надёжной, с другой стороны — она требует особой личной и коллективной собранности, ибо по факту это цикл управления вниманием: речь идёт о разделении практики мониторинга состояния окружения и выставления целей (целеполагания) и практики удержания внимания на какой-то деятельности в соответствии с её приоритетом. Поэтому основные циклы в менеджменте устроены ровно как циклы мониторинга чего-то важного, затем установление приоритетов (понимание ситуации, оценка сюрпризов и потенциальных сюрпризов), а затем приоритетных изменений (планирование как целеполагание и выполнение действий):

Цикл Бойда (сражения с конкурентами, изменения внешней среды, он же основной цикл стратегирования): наблюдение (мониторинг), ориентация (понимание приоритетов), решение (планирование действия на текущий такт), действие (изменение окружающего мира).
Цикл lean startup двойной: совершенствования продукта как внешние изменения (и там то же самое, в цикле каждый раз наблюдаем за тем, как используется продукт, принимаем решение, что в нём менять, и затем меняем) и более редкие циклы полной смены продукта (вираж/pivot), что неизбежно влечёт изменение создателя.
Цикл Шухарта-Деминга управления качеством — он начинается с того, что создателю создателя (который в том числе занимается операционным управлением создателя, operator) надо сразу планировать порцию работы по изменению целевой системы/окружающего мира (Plan), а не просто непрерывно делать эти изменения в текущем состоянии создателя. Затем делать эту порцию работы по изменению окружения (Do), затем та самая ориентация (оценка сюрприза, Cheсk), затем коррекция создателя как планирования и выполнение работы создателем создателя (Act).
Цикл Голдратта или POOGI сводится к тому, что на каждом такте выполнения работы определяется ограничение (наблюдение и понимание приоритета, целеполагание), затем происходит подстройка всей системы под ограничение (эксплуатирование ограничения создателя), и тем самым выигрывается время и производительность немедленно. Затем происходит снятие ограничения (это дольше и дороже, поэтому не сразу). То есть этот цикл тоже работает по изменению создателя.
Подход beyond budgeting, предполагающий переход к более коротким циклам бюджетирования, всё более и более коротким.
… множество самых разных других циклов, в нашем курсе мы их даже не упоминаем, но вы наверняка их встречали.

Эти «циклы» все предполагают реализацию общего принципа планирования по опросу. Конечно, большинство из них описывают не совсем уж «стадии», а практики (вряд ли вы будете закрывать глаза в цикле Бойда, когда переходите к анализу ситуации, а потом выработке решения — всё это будет происходить «параллельно»), но это вовсе не означает, что вы прекратите действия по уже принятым решениям до окончания какого-то периода, а хоть и довольно короткого периода. Более того, вам придётся увязывать и действия по изменению мира (создаваемой системы), и по изменению системы-создателя: в подходе active/embodied inference говорится, что агент постоянно мониторит происходящие внутри себя и вовне изменения, потом принимает решение исходя из наличных ресурсов — что на данный момент менять в модели себя, что менять в модели окружения, что менять в себе (а не модели себя), что менять в окружении (а не модели окружения), чтобы улучшить прогноз на следующие циклы. Эти все циклы меняют разное, они все нужны, все взаимосвязаны, но требуется понимать, как распределить ресурсы на все эти изменения: исследования себя и мира по изменению моделей себя и мира, а также планирование на базе этих изменённых моделей работ по изменению себя и мира.

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

Это всё кажется довольно абстрактным, но нет ничего практичней этой теории. Так, все процедуры планирования, полагающиеся на неверно понимаемый «системный подход в целеполагании», оказались негодными — они предусматривали крайне медленное каскадное целеполагание: когда с верхних уровней управления идёт предложение составить какой-то план, оно проваливается по нескольким организационным уровням до конкретных сотрудников, а затем поставленные ими «проекты целей» обобщаются как-то, как-то согласуются и спускаются уже сверху вниз в виде плановых показателей, которых надо достичь. И дело даже не в том, что KPI (key performance indicators) прекращают быть индикаторами чего бы то ни было, если они становятся целевыми показателями, с которыми связано ещё и благосостояние. Можете погуглить, к чему такое приводит в правоохране, это как раз пресловутая «палочная система», в бизнесе ведь ровно то же самое: KPI будут выполнены и перевыполнены, а фирма будет лежать в развалинах. Даже не будем останавливаться на этом, не превращать индикаторы в цели — это просто гигиена лидерства.

Целеполагание — это вопрос практики лидерства! Это социологический и психологический вопрос не меньше, чем вопрос технический, особенно в части привязки каких-то результатов достижения целей к вознаграждению. Мы уже упоминали, что в практике управления проектами успешное выполнение проекта «в срок и в бюджет» — это повод попросить вознаграждения. А в процессном управлении выполнение ровно той же работы будет проверено на соответствие регламентам — и поскольку надо будет найти несоответствия, их обязательно найдут. И за «нарушения процесса» оштрафуют. А в проектном управлении это будет подвиг «актуализации проекта», а изменение результатов — это будет «управление предметом проекта/scope» и оно приведёт к получению премии. Не очень понятно, за что платить премию при процессном управлении, вот оно и выживает только в среде выполняющих процессы компьютеров, а не в среде выполняющих процессы людей. Лидерство — это как раз про такое.

Возвращаясь к целеполаганию, проблемой оказалась не только привязка достижения целей к значениям каких-то индикаторов (помним: эти индикаторы будут обязательно достигнуты за счёт полной разрухи в разных других показателях), но и медленность каскадного целеполагания. Оно легко не успевало пройти за год даже в не очень крупных организациях, поэтому ни тебе быстрого стратегирования, ни тебе быстрого бюджетирования. Поэтому отказались от практик каскадного целеполагания management by objectives, balanced scorecards, key performance indicators: они не только приводят к разрухе, они ещё и медленны, не успевают вовремя менять цели.

Текущая SoTA в целеполагании — это быстрое прохождение всевозможных циклов, но ещё и переход от командных целей к личным, это оказалось крайне важным для лидерства. Командные цели, как выяснилось, съедают личные цели на завтрак: если вы ставите командную цель, то получаете все эффекты колхоза — у работящих нет стимула что-то делать дополнительно, потому как их индивидуальная работа по достижению коллективной цели обесценивается «в общем котле», а у не очень работящих нет стимула что-то делать, потому как их не слишком больше рвение тоже не видно в результатах коллективного труда. Увязывание личного и общественного как в колхозах обычно оказывается не слишком продуктивным, хотя до сих пор высших менеджеров пытаются привлечь опционами — это ровно такая же увязка. Но результаты работы высших менеджеров не так уж легко теряются в общем котле: их работа обычно хорошо отслеживается, а на отслеживание работ рядовых сотрудников никаких ресурсов не хватит.

Книга John Doerr «Measure What Matters», 2018 рассказывает о практике личного целеполагания OKR (objectives and key results, цели и ключевые результаты), которую предложил Andy Grove (который работал в Intel, в частности 11 лет был Intel CEO), а затем был продемонстрирован успех этой практики в быстро растущих (это важно! Скорость важна!) технологических компаниях во всё мире:

Практика OKR — это одна из важных современных практик лидерства. Она снимает основные претензии к прошлым вариантам практик целеполагания:

Цели там не командные, а личные, они не входят в иерархию целей. Это инструмент лидерства, практика помощи каждому сотруднику осознать его роль в организации и запланировать какие-то улучшения. Но если речь идёт о начальнике, то вполне можно ставить производственные цели — но это цели не подразделения, а лично начальника.
За достижение этих целей не платят. Чтобы это было понятно наверняка, результаты сразу рекомендуют формулировать как заведомо недостижимые.
Эти цели отслеживаются в коротком цикле (месячное и квартальное планирование, это точно не раз в год), они не задерживаются «увязкой целей разных уровней» в разных вариантах каскадирования (иерархичного сбора предложений и взаимоувязки на самых разных уровнях) целей.
Эти цели публичны, то есть могут быть использованы для взаимокоординации, принцип «табло». Оргпроект (а личные цели вполне себе часть оргпроекта) должен быть публичным.

Сами цели больше похожи на обсуждаемые в системном мышлении интересы/предпочтения в характеристиках какой-то системы (типа «чем наш гаджет будет меньше и легче, тем лучше»), чем цели-target, которые нужно достичь и успокоиться — но какие-то ориентиры по недостижимым уровням характеристик всё-таки даются как ключевые результаты. Пример такой двухуровневости:

Цель/objective: клиенты постоянно находят наш продукт полезным.
- Ключевой результат (key result) 1: 80% новых клиентов продолжают свои подписки после первых двух месяцев
- Ключевой результат (key result) 2: 50% новых клиентов возвращаются в течение двух недель
- Ключевой результат (key result) 3: в этом квартале замена старых клиентов новыми (churn rate) меньше 2%

Практика целеполагания подтверждается исследованиями: если раньше верили, что цели должны быть SMART (Specific, Measurable, Achievable, Realistic, Time-Bound), то теперь в личном целеполагании предпочтение отдаётся целям FAST²²⁰ (Frequently discussed — способствующие лидерству, Ambitious — за пределами возможного, «предпочтения», Specific — конкретные события достижения каких-то метрик, наступление которых можно проверить, Transparent — цели и уровень их достижения должны быть публичными, «на табло»).

Целеполагание OKR — один из важнейших инструментов лидерства, ибо нет другого способа лидерства, кроме как людям разговаривать между собой о том, чего они хотят или не хотят (причём «не хотят» часто важнее) и как этого можно было бы достичь, меняя себя и мир вокруг. Методы OKR просто предписывают лидерам (обычно непосредственным начальникам, но необязательно) беседовать с сотрудниками в относительно коротком (месяц и квартал) цикле.

Упражнения

Опишите от трёх практик цикличности, которые вы задействуете в ваших проектах.

Номер п/п	Практика цикличности (вид цикла: Бойда, Дёминга, непрерывного совершенствования, другое — укажите)	Практики в цикле (содержание выполняемых в цикле практик)	Ваша роль	Оценка числа прошедших циклов, в которых вы участвовали
1.
2.
3.

Задания

Поставьте отметку о выполнении.

Опубликовано эссе по мыслям, приходившим в голову по мере чтения книги John Doerr «Measure what matters: OKRs, the simple idea that drives 10x growth», 2018
Опубликовано эссе по мыслям, приходившим в голову по мере чтения книги Douglas W. Hubbard, «How to Measure Anything: Finding the Value of Intangibles in Business», 3^rd edition, 2014
Опубликовано эссе на тему «Цикличность в менеджменте», в котором изложены мысли, приходившие вам в голову по мере нахождения и чтения литературы (как указанной в лекции, так и за её пределами) по циклам Бойда, Дёминга-Шухарта, оптимизации продукта и виражей в Lean startup, непрерывного совершенствования Голдратта и других, найденных вами.

10. Практика администрирования

Администрация как оператор внутрифирменной организационной платформы

Мы тут просто следуем за последними трендами системной инженерии design for manufacturing и строительство более-менее универсальных заводов/фабрик/plants, которая вслед за программной инженерией и вместе с идеями переходит к линии развития DevOps/SRE к идеям инженерии внутренней платформы разработки/internal development platform engineering или коротко platform engineering. Мы избегаем говорить просто «инженерия платформы», потому как слишком много разных значений у слова платформа. Впрочем, у нас «разработчик» — это «организатор», поэтому «внутренняя платформа организации», занимается ей обычно администрация. Но тут есть некоторый общий тренд: раньше администраторами были люди, а сейчас это всё больше и больше переходит к софту, IT-инфраструктуре и другому безлюдному (даже такому «оборудованию» в кавычках, как здания и сооружения). Администрация тем самым становится «инженерами организационной платформы». То есть у нас появляется ещё одна система, которую надо делать внутри организации, это «организационная платформа», которая должна выполнять для организации примерно те же функции, что и любая другая производственная система, с учётом последних трендов разделения труда²²¹:

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

Поставку материала: людей с рынка труда, постановку их на кадровый учёт, выплаты зарплаты, учёт труда, поддержание кадрового резерва (HR).
Мониторинг характеристик, которые требуются внешними проектными ролями организации (регуляторы рынка труда, финансовые регуляторы, технадзоры/безопасность, экология, санитария), но могут быть и инициативные требования, они отслеживаются тоже администрацией.
Помещения для работы (цеха, офисные площади)
Официальный документооборот и делопроизводство, а также поддержку управления работами. Вообще, отслеживание корпоративных учётных систем (официальные архивы, стратегии и оргпроекты, операционные модели организации, репозитории целеполагания, всё что кому-то может понадобиться — управление информацией) как раз тут.
Компьютерный парк, поддержка со стороны общих информационных систем предприятия (но не специфических информационных систем, направленных на решение каких-то задач в инженерии целевой системы, или продвижения, или бизнеса).
Отслеживание орг-архитектурных решений (перед тем, как лидер начинает проводить в жизнь решения оргпроектировщика, орг-проект проверяется на то, насколько она соответствует орг-архитектурным решениям. Если орг-проект не соответствует — об этом сообщается орг-архитектору. Это похоже на реализацию fit functions в архитектурной работе программных инженеров, это обсуждалось в курсе «Системная инженерия»).
Юридический сервис (включая учёт договорных обязательств), учёт финансов и казначейские функции (проплаты по договорам).
Защита бизнеса (security, ибо безопасность/safety чаще идёт по линии учёта требований надзоров)
… всё остальное, что требуется организации для её деятельности (включая заказ внешних административных сервисов при недостаточности собственных трудовых ресурсов и оборудования, например, заказ офисных или производственных площадей на условиях аренды, если нет помещений во владении фирмы).

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

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

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

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

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

Опасность: администрация для организаторов или организаторы для администрации?

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

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

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

Госчиновники пытаются из любого предприятия сделать военное предприятие с госприёмкой. Это неважно, что речь идёт о продовольствии, или детских игрушках, или транспортных средствах, или производстве электроники — вам легко объяснят, что вы не имеете права делать, что угодно, поэтому вам нужно делать только то, что можно, а для этого нужно хорошо документировать ваше производство.
Менеджеры и инженеры разных частей предприятия из любого предприятия пытаются сделать гибкое/шустрое/agile (и ещё в agile манифесте сказано о том, что польза для клиентов ценится выше, чем документирование — это как раз про те самые документы, по которым точно можно найти «кто виноват», но которые не помогают что-то сделать лучше и быстрее), а ещё элегантное/lean — то есть не делать того, что можно не делать и оно бесполезно, документирование на предмет юридически значимых (правильно оформленных и зарегистрированных) документов с ответами на вопросы «кто виноват» чаще всего относится именно к такому классу. Вы или чекаете ответ на вопрос чек-листа в длинном списке, или оформляете целый документ на этот ответ «да/нет»: что, кому, когда, зачем, подпись, подпись того, кто удостоверяет вашу подпись, выполнение правил архивирования ответа, способ осуществления выписки для официального предъявления и т.д.

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

связанных с требованиями госчиновников по самым разным линиям: бухгалтерия, кадры, технические стандарты, экологические стандарты, стандарты безопасности и всё самое неожиданное, что может выдать бешеный принтер под напором лоббистов из самых разных сфер бизнеса. Скажем, двадцать лет назад подписываемая директором пачка бухгалтерской отчётности была тоненькой, а сейчас она много толще — и хотя компьютеры существенно помогают производить эту бухгалтерскую отчётность быстрее, но и требования по её сдаче становятся жёстче и жёстче, и так во всех сферах жизни: чем больше возможностей выполнить требования регулятора, тем жёстче начинает требовать регулятор.
связанных с требованиями сотрудников службы защиты (по традиции на русском языке — это будет называться требованиями сотрудников службы безопасности, но не safety/безопасности, а защиты/security). При этом что из этого идёт по линии требований законодательства (часто лоббируемого как раз бизнесом организаций защиты), а что по линии инициативы сотрудников службы защиты — это обычно трудно разобраться. Службы защиты обычно вполне себе силовые подразделения, а преимущество в силе часто реализуется в непроизводительные траты на неэффективные мероприятия. Конечно, специалисты по защите выполняют для агента функции иммунной системы, но аутоиммунные заболевания не так уж редки, поэтому полиция вполне может разрастаться до уровня полицейского государства (помним об исследованиях John Doyle²²²).

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

Системам документооборота и делопроизводства противопоставляются системы не слишком формального, то есть юридически не слишком значимого управления информацией, где важны скорость и удобство работы, возможность получить информацию для всех, кто в ней заинтересован, а официальный статус этой информации волнует мало. Главный тут будет какой-то организатор (например, технический директор, которого интересует issue tracker, чтобы учитывать все дефекты, но меньше заботит, чтобы были в любой момент готовы юридически обоснованные документы для передачи в суд материалов, говорящих, кто в этих дефектах виноват. Скажем, какой-нибудь low code modeler (типа coda.io, notion.so) полностью устроит менеджера и инженера, но служба безопасности будет запрещать такую работу (и трудно будет сразу сказать, осмысленный этот запрет, или неосмысленный). Большинство производств выбирают не борьбу со службой безопасности (они силовики, с ними бороться трудно: у них оружие есть, а у вас нет — они ваши аргументы обычно просто игнорируют и отвечают какими-нибудь фразами из каких-нибудь произвольно подобранных документов), а выбирают сразу оба способа ведения дел (схема):

Учётная система «для работы» на базе универсальных моделеров, корпоративных информационных систем и т.д., причём не все из них показывают «безопасникам» и тем более чиновникам.
Часть информации оформляют в каких-то «официальных системах», передавая туда (если повезёт) через электронный интерфейс, а иногда и (если не повезёт) вбивая эту часть информации руками.

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

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

Поэтому имейте у себя управление информацией (репо для версионирования, issue trackers), а официальный документооборот (архивы, системы управления документами) — по минимуму. Бойтесь, когда поставщики средств документооборота, бухгалтерских систем, систем обеспечения информационной защиты пытаются вам выдать их за средства повышения производительности труда. Нет, смотрите внимательно на практики, которые они поддерживают. Например, это информационная система не для поддержки работы, а для ответа на вопрос «кто виноват», если там проще отвечать на вопросы «в какой момент меняется юридический статус», «не имеет ли юридический статус в какой-то момент сразу два противоречащих значения». Для производственных систем это обычно не так важно, а важно совсем другое. Вряд ли вы будете задаваться этими вопросами в ходе работы с issue tracker²²³. Но если ваше предприятие само по себе занимается поддержкой формального документооборота, то тогда наоборот — ровно эти вопросы будут для ваших информационных систем главными.

Основные функции бухгалтерии:

Вести первичный учёт так, чтобы были возможны все виды ТебеУчёта (государству, и часто даже не одному государству, иногда раскрытие части учёта клиентам, иногда раскрытие части учёта владельцам в порядке раскрытия информации), а также СебеУчёта (прежде всего для throughput accounting). Сюда же можно отнести учёт операций по корпоративным финансам (инвестиции, займы, траты на слияния-поглощения).
Это надзорный орган выполнения требований законодательства, но оплачивается он из денег предприятия. Важно не забывать это и чётко контролировать, в чьих интересах работает бухгалтерия: она защищает вас от внешнего произвола, или наоборот, это чужие люди, работающие против ваших интересов.
Проведение биллинга (сбора платежей с клиентов) и учёт договоров (хотя учёт договоров может быть и отделён куда-нибудь в делопроизводство)
Проведение казначейских операций, то есть выплаты контрагентам и учёт соответствующих договоров (хотя учёт договоров может быть и отделён куда-нибудь в делопроизводство)

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

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

Ещё одна служба администрации, для которой нужно быть внимательным в перехвате инициативы — это управление человеческими ресурсами/human resource management (HR). Типичный тут сюжет — это спросить на каком-нибудь совещании перед начальниками самых разных оргзвеньев у начальника HR про то, что делает его служба. После обычных утверждений о том, что служба заботится о наличии в организации запаса людей, которые могут быть использованы для развития организации (иногда это называют «управление талантами»/talent management²²⁴), обслуживает «кадры» (то есть формальный найм, увольнение, администрирование выплаты зарплаты), удивлённые начальники узнают, что HR-менеджеры занимаются планированием карьерного роста сотрудников, обучением этих сотрудников, назначают вознаграждение за успехи в работе и общий уровень зарплаты, оценивают качество работы сотрудников в различных опросах — и у начальников оргзвеньев появляется общий для них вопрос: они-то тут зачем? Дальше события развиваются по двум сценариям:

HR-менеджер почему-то увольняется через пару недель (ибо хором все менеджеры понимают, что или они руководят сотрудниками, или все кнуты и пряники в руках у HR-службы — и вопрос ставится «или мы, или они»).
HR-менеджер оказывается опытным психологом и/или социологом (что часто профильное образование) и как-то удерживается на своей позиции, для него эта ситуация лишь «политическая борьба, групповая динамика», никаких проблем с разделением труда HR-менеджер не усматривает, корпоративную культуру и лидерство оставляет за собой, равно как вопросы оценки сотрудников и принципы выплаты зарплат и вознаграждений за какое-то поведение (incentives²²⁵ — то, что меняет поведение людей).

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

Есть и другие опасности. Например, HR-менеджер даже не сам, а через своих сотрудников фильтрует образовательные программы «для развития» так, чтобы они были понятны этим сотрудникам (помним: базовое образование там чаще всего психологическое и социологическое). Это означает, что более-менее нормальные программы уровня сложности третьего курса инженерного или менеджерского вуза никогда не прорвутся в предприятие, будут сочтены как «слишком сложные и заумные, это не для наших сотрудников». Мало кто понимает, какой жёсткий этот фильтр. Поэтому единственный шанс получить нормальное развитие сотрудников — это заказ таких курсов по развитию непосредственно от начальников тех, кому это развитие или дообучение нужно, а затем прислеживание за тем, чтобы всякие «конкурсы на закупки» не попали в HR-службу, иначе лучшие курсы будут объявлены «заумными», а закуплен будет броский «инфобизнес» в худшем значении этого слова.

Примерно то же самое происходит со службой айтишников, которых надо чётко делить на «электронщиков» и «программистов». У них там между собой тоже продуктивный конфликт: программисты всегда хотят поставить новый софт, на который никогда не хватает аппаратуры или проблемы с закупками мощностей датацентра, с другой стороны, «электронщики» всегда хотят закупить аппаратуру впрок — но вот только почему-то всегда оказывается, что закупленная впрок аппаратура не подходит для того софта, который на этой аппаратуре должен быть запущен. Обращение к облачным сервисам вроде как должно решать все проблемы, но по факту не решает: тут и сразу ограничения со стороны софта, и ограничения со стороны службы информационной защиты («информационная безопасность», но это security, а не safety), и ограничения по финансам (облако оказывается не таким уж дешёвым), и ограничения по устройствам, с которых сотрудники намерены работать с облаком, и архитектурные ограничения корпоративной информационной системы.

Ещё одно различение — это программисты разных служб, которые помогают инженерам самых разных целевых систем и работающего над этими системами оборудования и софта против программистов, которые разворачивают корпоративные информационные системы, поддерживающие администрирование и взаимодействие между оргзвеньями по координации работ. Их часто путают и объединяют в общий пул «программистов». Не надо этого делать, программисты отличаются одни от других больше, чем врачи друг от друга: объединение кардиохирургов с венерологами ещё выглядит осмысленно, но вот программисты встроенных/embedded систем (прошивок аппаратуры) и программисты языков запросов корпоративных баз данных — между ними не так много общего, чтобы объединять их в рамках одного оргзвена просто по принципу «у них общее образование». И образование у них может быть совсем даже не одинаковым.

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

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

Задания

Поставьте отметку о выполнении.

Опубликовано эссе, в котором вы рассказываете, что в пройденном курсе системного менеджмента было самым непонятным, что было самым контринтуитивным, что было очень неприятно обнаружить в части собственных ошибок, что оказалось немедленно полезным, что вы не смогли себя заставить одолеть сразу и отложили на потом. Изложите общие впечатления от курса.
Вами проведён для ваших коллег семинар с кратким обзором пройденного курса: что им было бы хорошо знать о менеджменте?
Намечены планы по личному развитию в части каких-то менеджерских практик.
В чат поддержки курса «Системный менеджмент» (https://t.me/sys_mngmt_course) сделана запись, в которой вы делитесь опытом прохождения курса и даёте советы новым студентам, которые только-только начинают изучать курс. На что им обратить особое внимание? Что им поможет пройти курс легче и быстрее? На чём им нельзя экономить?

Что потом?

На этом курс системного менеджмента вами закончен. Курс очень короткий (несколько сотен книжных страниц, несколько десятков упражнений), поэтому не может заменить полноценного вузовского курса MBA, где вас просто заставят проштудировать множество толстых книг и выполнить множество упражнений. Но выпускники MBA отзывались о материале нашего курса как о крайне важном: наш курс позволяет разложить по полочкам в голове те знания, которые обычно даются в курсе MBA, а также наш курс даёт инструкцию по тому, как и когда использовать эти знания. Удивительно, но в самом курсе MBA такого не предусмотрено!

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

Основное, что вы должны при этом понять — это даже не то, как и что происходит в ходе практикования менеджмента. Вы должны прежде всего понять, что менеджмент — это просто приложение идей системной инженерии к инженерии организаций самых разных форм — предприятий, фирм, подразделений фирм, хоббийных кружков, партийных ячеек. Формы организаций, для которых приложим материал нашего курса могут быть какими угодно, отнюдь не только вариантами классического «юридического лица». В тексте мы старались реже использовать термин «предприятие» (или его синонимы: компания/фирма и даже бизнес), а использовали главным образом термин «организация», включающий и самые разные другие формы оргзвеньев — как подразделения компаний, так и объединения компаний для выполнения каких-то проектов, но также и всяческие не-подразделения типа советов и комиссий, рабочих групп проектов, и множество самых разных других оргформ. Важно лишь, чтобы в этих организациях создавались какие-то системы, даже если эти создаваемые системы — личности самих участников организаций (например, такое можно найти в учебных группах/study group). Конечно, в организации должны быть понятны полномочия по распоряжению трудом и имуществом организации, прежде всего средствами производства и сырьём.

А ещё идеи менеджмента в существенной мере приложимы и к личности (можно говорить и об инженерии личности, и о менеджменте личности, и о личной организованности), и отчасти даже к сообществам (организовывание сообществ тоже вполне можно обсуждать).

Что делать дальше?

продолжать участвовать в неформальном чате обсуждений курса https://t.me/sys_mngmt_course, где общаются студенты и выпускники. Там ответят на оставшиеся вопросы по курсу и составят вам компанию практикующих системный менеджмент.
просто применять материал курса в своей работе. Договорить всех вокруг («договориться со всеми вокруг» — это более слабая формулировка!), скорректировать свой способ управления работами, отмоделировать происходящее вокруг вас (или даже на предприятии в целом), используя простые таблички, выполнить «распожаризацию», дальше развивать и совершенствовать свою организацию.
Есть и вариант «ничего не делать»! Но понимание того, что происходит в головах у менеджеров, останется с вами на всю жизнь. Ну, не на всю жизнь — но только до тех пор, пока значительную часть менеджерской работы не возьмёт на себя машинный интеллект. А ещё прохождение курса добавило вам практики в системном мышлении, методологии и системной инженерии. Это более сильное и точное мышление останется с вами на всю жизнь, оно меняется не так быстро, как менеджмент.

https://system-school.ru/engineering

https://system-school.ru/2-org-dev

https://ailev.livejournal.com/1583706.html

⁴

https://system-school.ru/open-endedness

⁵

https://system-school.ru/

⁶

https://system-school.ru/2-org-dev

⁷

https://en.wikipedia.org/wiki/Systems_management

⁸

https://en.wikipedia.org/wiki/Praxeology

⁹

https://system-school.ru/open-endedness

¹⁰

https://corporatefinanceinstitute.com/resources/careers/soft-skills/management-theories/, https://www.indeed.com/career-advice/career-development/types-of-management-theories

¹¹

https://en.wikipedia.org/wiki/Master_of_Business_Administration

¹²

https://mintzberg.org/

¹³

https://www.mcgill.ca/desautels/programs/international-masters-health-leadership, https://impm.org/, https://coachingourselves.com/ — Henry Mintzberg участвует во всех этих программах, и в них подчёркивается, что они выходят за пределы MBA.

¹⁴

https://en.wikipedia.org/wiki/Organization_development

¹⁵

https://en.wikipedia.org/wiki/Operations_management

¹⁶

https://en.wikipedia.org/wiki/Engineering_management

¹⁷

https://www.mempc.org/

¹⁸

https://asem.org/

¹⁹

https://en.wikipedia.org/wiki/Organizational_engineering

²⁰

http://www.oeinstitute.org/

²¹

https://www.smartcapitalmind.com/what-is-business-engineering.htm, https://fourweekmba.com/business-engineer/

²²

https://en.wikipedia.org/wiki/Business_model

²³

Вот тут некоторое количество определений: https://studme.org/226132/informatika/biznes_inzhiniring

²⁴

http://bigc.ru/about/manifest/

²⁵

https://en.wikipedia.org/wiki/Business_analysis

²⁶

https://www.iiba.org/

²⁷

https://www.iiba.org/career-resources/a-business-analysis-professionals-foundation-for-success/babok/

²⁸

https://en.wikipedia.org/wiki/Enterprise_engineering

²⁹

https://ru.wikipedia.org/wiki/Праксеология

³⁰

https://plato.stanford.edu/entries/rationalism-empiricism/

³¹

Рациональность-2022: https://ailev.livejournal.com/1619025.html

³²

https://www.investopedia.com/terms/e/environmental-social-and-governance-esg-criteria.asp

³³

https://ru.wikipedia.org/wiki/Правовой_позитивизм

³⁴

https://ifs-institute.com/

³⁵

https://humanitec.com/blog/what-developer-self-service-shouldnt-look-like

³⁶

Особенности, отличающие platform engineering от традиционных DevOps и SRE ровно в этом: кто строит конвейер и кто нажимает кнопки на оборудовании конвейера — https://thenewstack.io/how-is-platform-engineering-different-from-devops-and-sre/

³⁷

https://ic.pics.livejournal.com/ailev/696279/212554/212554_original.png

³⁸

Диаграмма в формате .graphml для редактора графов yEd — https://disk.yandex.ru/d/iXHqLTB6k3Q3nA

³⁹

https://en.wikipedia.org/wiki/Break-even

⁴⁰

https://www.toptal.com/project-managers/agile/what-is-an-agile-coach

⁴¹

у https://americanstaffing.net/staffing-industry/what-staffing-firms-do/

⁴²

https://www.youtube.com/watch?v=RszF-Kl4-f4

⁴³

https://www.embroker.com/blog/cofounder-conflict-guide/

⁴⁴

https://www.marketwatch.com/articles/tesla-ceo-elon-musk-51637708903

⁴⁵

https://en.wikipedia.org/wiki/Robotic_process_automation

⁴⁶

Сейчас это часть предложения более продвинутого сервиса https://www.visier.com, то суть та же: автоматизация решения проблем, связанных с людьми, вроде предсказания «неожиданных» увольнений. И это не единственный такой продукт на рынке, и эта технология реально работает.

⁴⁷

https://ailev.livejournal.com/1511183.html

⁴⁸

https://ailev.livejournal.com/1158826.html

⁴⁹

https://chiefmartec.com/2020/04/marketing-technology-landscape-2020-martech-5000/

⁵⁰

https://www.kinopoisk.ru/film/11835/

⁵¹

https://en.wikipedia.org/wiki/Corporate_finance

⁵²

https://www.investopedia.com/terms/o/organicgrowth.asp

⁵³

https://www.investopedia.com/terms/i/inorganicgrowth.asp

⁵⁴

https://kaylanpepin.com/finacing-tech-with-term-loans/ по презентации https://www.bdc.ca/en/bdc-capital/venture-capital/funds/energy-cleantech-venture-fund

⁵⁵

https://en.wikipedia.org/wiki/Force_majeure

⁵⁶

https://en.wikipedia.org/wiki/Corporate_governance

⁵⁷

https://ru.wikipedia.org/wiki/Трекер_(специальность)

⁵⁸

https://www.investopedia.com/terms/m/mbo.asp

⁵⁹

https://en.wikipedia.org/wiki/Henry_Mintzberg

⁶⁰

https://www.informit.com/articles/article.aspx?p=378964&seqNum=5

⁶¹

Henry Mintzberg, The Rise and Fall of Strategic Planning, 1994.

⁶²

http://vijaykumarbhatia.weebly.com/strategic-management-history-and-development.html

⁶³

https://ailev.livejournal.com/1622346.html

⁶⁴

https://en.wikipedia.org/wiki/Michael_Porter

⁶⁵

https://en.wikipedia.org/wiki/Getting_Things_Done

⁶⁶

https://en.wikipedia.org/wiki/John_Boyd_(military_strategist)

⁶⁷

https://en.wikipedia.org/wiki/French_aircraft_carrier_Clemenceau

⁶⁸

Схема 27 из https://gtmarket.ru/library/basis/6654/6658, там дано и более подробное описание.

⁶⁹

https://myslang.ru/slovo/spasibo-kep

⁷⁰

https://info.boardofinnovation.com/hubfs/A1_B2C%20Revenue%20model%20flowchart-1.pdf

⁷¹

https://www.alexosterwalder.com/

⁷²

http://www.hec.unil.ch/aosterwa/PhD/Osterwalder_PhD_BM_Ontology.pdf

⁷³

https://www.strategyzer.com/books/business-model-generation

⁷⁴

https://www.researchgate.net/publication/307872870_Business_Model_Ontology_BMO_An_Examination_Analysis_and_Evaluation

⁷⁵

https://cnvs.online/en/w/-NH3t7i1N82C8LkUGs2Y и там все canvas позволяют себя редактировать.

⁷⁶

https://cnvs.online/en/feature/-NH3t7i1N82C8LkUGs2Z

⁷⁷

https://www.facebook.com/academictoolkit/posts/126529044587676

⁷⁸

https://www.aha.io/

⁷⁹

Много материалов в https://www.tocico.org/page/strat_tact_portal, перевод варианта методики 2006 года на русский — http://www.deming.ru/TehnUpr/PostrDerStrTak.htm

⁸⁰

http://techinvestlab.ru/files/394450/Org_Preobr.pdf

⁸¹

http://www.slideshare.net/utkanuluay/rapid-replenishment-st-tree

⁸²

https://www.omg.org/spec/BMM

⁸³

https://pubs.opengroup.org/architecture/archimate3-doc/chap06.html

⁸⁴

https://ru.wikipedia.org/wiki/Ряды_предпочтительных_чисел_(в_технике)

⁸⁵

https://journal.jabian.com/culture-eats-strategy-for-breakfast-and-transformation-for-lunch/

⁸⁶

Geoffrey Hinton, The Fog of Progress, https://youtu.be/FOqMeBM3EIE

⁸⁷

https://en.wikipedia.org/wiki/Starlink

⁸⁸

https://en.wikipedia.org/wiki/OneWeb

⁸⁹

https://ru.wikipedia.org/wiki/Сфера_(целевая_программа)

⁹⁰

https://www.theverge.com/2022/8/25/23320722/spacex-starlink-t-mobile-satellite-internet-mobile-messaging

⁹¹

https://ru.wikipedia.org/wiki/Бэббидж,_Чарлз

⁹²

https://ru.wikipedia.org/wiki/Электронная_лампа

⁹³

https://ru.wikipedia.org/wiki/Мокли,_Джон

⁹⁴

https://ru.wikipedia.org/wiki/ЭНИАК

⁹⁵

https://www.lifehacker.com.au/2015/11/invisible-women-the-six-human-computers-behind-the-eniac/

⁹⁶

Вы можете заказать вычисления на квантовых компьютерах у десятка разных провайдеров, https://en.wikipedia.org/wiki/Cloud-based_quantum_computing. Один расчёт можно было купить ещё в 2021 году за единицы долларов.

⁹⁷

https://www.lightelligence.ai/

⁹⁸

https://en.wikipedia.org/wiki/ImageNet

⁹⁹

Занятия машинным интеллектом «на фронтире» в 2020 году требовали суперкомпьютерные вычислительные мощности, это миллионы долларов: https://ailev.livejournal.com/1536283.html, в 2021 году в этом плане ничего не поменялось (суперкомпьютеры на единицу мощности стали дешевле, но и их размеры выросли).

¹⁰⁰

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

¹⁰¹

Версия доклада 2018 года (видео 37 минут): https://youtu.be/KVm74yE0aUE, пересказ доклада 2016 года по-русски: http://tv2.today/TV2Old/Budushchee-uzhe-nastupilo-lekciya-andreya-pozdnyakova-0

¹⁰²

А в 2021 году переключился на изменения в энергетике, они не менее драматические: на наших глазах стремительно исчезают угольные электростанции, шахтёры остаются без работы! Вот его видео: https://www.youtube.com/user/tonyseba/videos

¹⁰³

https://www.youtube.com/watch?v=z7vhMcKvHo8, https://www.youtube.com/watch?v=Vqs0_3M-18c, https://www.youtube.com/watch?v=fsnkPLkf1ao, https://www.youtube.com/watch?v=g6gZHbfK8Vo

¹⁰⁴

https://gizmodo.com/amazon-market-cap-amazon-prime-e-commerce-1849764529

¹⁰⁵

https://www.cnbc.com/2022/10/27/meta-is-no-longer-one-of-the-20-biggest-us-companies.html

¹⁰⁶

https://ru.wikipedia.org/wiki/Apple_Newton

¹⁰⁷

https://www.bbc.com/news/business-55224462

¹⁰⁸

https://www.fox10phoenix.com/news/waymo-self-driving-ride-hailing-service-now-available-in-downtown-phoenix

¹⁰⁹

https://arxiv.org/abs/1905.13178

¹¹⁰

https://onnx.ai/

¹¹¹

https://www.youtube.com/watch?v=O-kbzfWzvSI

¹¹²

https://blogs.nvidia.com/blog/2020/05/14/drive-platform-nvidia-ampere-architecture/, https://blogs.nvidia.com/blog/2021/04/12/volvo-cars-extends-partnership-nvidia-drive-orin/

¹¹³

https://www.buyacar.co.uk/cars/economical-cars/electric-cars/650/cost-of-running-an-electric-car

¹¹⁴

https://www.braincorp.com/newsroom/brain-corp-to-expand-ai-services-in-retail-industry

¹¹⁵

https://roboticsandautomationnews.com/2022/10/27/walmart-makes-brain-corp-the-worlds-largest-supplier-of-inventory-scanning-robots/55342/

¹¹⁶

https://braincorp.com/

¹¹⁷

https://www.roboticsbusinessreview.com/opinion/robots-will-transform-retail-operations-in-2021-heres-why-how/

¹¹⁸

https://en.wikipedia.org/wiki/Gig_worker

¹¹⁹

https://en.wikipedia.org/wiki/Wright_brothers — и дело даже не в том, что они догадались поставить на самолёт лёгкий мотоциклетный двигатель, изготовленный в их мастерской. Они придумали проводить эксперименты в аэродинамической трубе, а ещё придумали систему управления самолёта по трём осям воздушными рулями. Но они не были «профессиональными авиаторами»!

¹²⁰

Мегафон — https://www.cnews.ru/news/top/2020-01-29_novyj_servis_megafona, МТС — https://rb.ru/news/mts-norma/.

¹²¹

https://www.rbc.ru/technology_and_media/07/02/2018/5a7b20d29a79473903543eaa

¹²²

Сервис «Сбер-звук», https://sber-zvuk.com/

¹²³

http://www.macdigger.ru/iphone-ipod/iphone-7-plus-protiv-zerkalki-canon-semka-fotografij-s-effektom-boke.html

¹²⁴

https://en.wikipedia.org/wiki/Bokeh

¹²⁵

https://www.cipa.jp/stats/documents/common/cr200.pdf

¹²⁶

https://phys.org/news/2021-06-goodbye-camera-miniaturized-optics-counterpart.html, https://www.nature.com/articles/s41467-021-23358-8

¹²⁷

https://venturebeat.com/2020/04/29/microsoft-teams-passes-75-million-daily-active-users/, https://www.statista.com/statistics/1033742/worldwide-microsoft-teams-daily-and-monthly-users/

¹²⁸

https://vc.ru/office/127764-pochemu-my-reshili-dat-vozmozhnost-sotrudnikam-ostatsya-na-udalenke-navsegda

¹²⁹

https://arxiv.org/abs/1706.03762

¹³⁰

https://ailev.livejournal.com/1551283.html

¹³¹

https://en.wikipedia.org/wiki/Symbolic_regression, https://arxiv.org/abs/1912.04825

¹³²

https://arxiv.org/abs/2006.11287

¹³³

https://www.datarobot.com/nutonian/

¹³⁴

https://ailev.livejournal.com/1637656.html

¹³⁵

https://waitbutwhy.com/2015/01/artificial-intelligence-revolution-1.html

¹³⁶

https://www.youtube.com/watch?v=yP5cavP4eWc, https://www.algoriddim.com/djay-ios/releasenotes

¹³⁷

https://arxiv.org/abs/2011.13062

¹³⁸

https://www.zdnet.com/article/manufacturers-allocate-one-third-of-overall-it-spend-to-ai-survey-shows/

¹³⁹

https://www.deepl.com

¹⁴⁰

https://www.grammarly.com/

¹⁴¹

https://www.youtube.com/watch?v=0XpRhQX7BpU

¹⁴²

https://www.jimcollins.com/

¹⁴³

https://www.amazon.com/От-хорошего-великому-компании-совершают-прорыв-ebook/dp/B06XP1H8LQ/

¹⁴⁴

https://ru.wikipedia.org/wiki/Икигаи

¹⁴⁵

https://www.amazon.com/Антихрупкость-извлечь-выгоду-Азбука-Бизнес-Russian-ebook/dp/B0156M8ISC/

¹⁴⁶

https://ru.wikipedia.org/wiki/Фланёр — городской тип, впервые отмеченный в Париже середины XIX века (также boulevardier). Фланирование означало гуляние по бульварам с целью развлечения и получения удовольствия от наблюдения городской жизни.

¹⁴⁷

Вот мемуар, сделанный под влиянием предыдущей версии нашего курса, https://danielko.medium.com/musings-of-tech-space-enthusiast-part-i-428c28655b44. Автор мемуара (Даниэль Корнев) радуется, что у него пропало чувство вины от того, что он недостаточно жёстко много лет преследует одну и ту же мечту. Оказывается, мечту просто можно время от времени менять, чтобы оставаться современным! И никакого чувства вины при этом, наоборот — радость от того, что остаёшься современным!

¹⁴⁸

Слово, использованное в переводе книги, https://ru.wikipedia.org/wiki/Лох_(жаргонизм)

¹⁴⁹

https://ru.wikipedia.org/wiki/Систематическая_ошибка_выжившего

¹⁵⁰

https://arxiv.org/abs/1802.07068

¹⁵¹

https://www.amazon.com/Why-Greatness-Cannot-Planned-Objective-ebook/dp/B00X57B4JG/

¹⁵²

Original Painting on Canvas, 2001

¹⁵³

https://www.amazon.com/Бизнес-нуля-быстрого-тестирования-бизнес-модели-ebook/dp/B00K4YYUHG/

¹⁵⁴

https://en.wikipedia.org/wiki/Tesla_Powerwall

¹⁵⁵

https://en.wikipedia.org/wiki/Optimus_(robot)

¹⁵⁶

https://ru.wikipedia.org/wiki/У-вэй

¹⁵⁷

http://www.amazon.com/dp/0465065708/

¹⁵⁸

https://ru.wikipedia.org/wiki/Калькуляционный_аргумент

¹⁵⁹

Различение детерминистичности и непредсказуемости https://royalsocietypublishing.org/doi/10.1098/rspa.2015.0883

¹⁶⁰

https://www.oreilly.com/ideas/open-endedness-the-last-grand-challenge-youve-never-heard-of

¹⁶¹

https://eng.uber.com/poet-open-ended-deep-learning/

¹⁶²

https://eng.uber.com/enhanced-poet-machine-learning/

¹⁶³

Уже через три месяца эффективность аденовирусной вакцины AstraZeneca становилась жестко отрицательной (т.е. привитые начинали попадать в больницу и умирать от ковида чаще, чем непривитые), https://academic.oup.com/ije/advance-article/doi/10.1093/ije/dyac199/6770060. И таких работ всё больше и больше.

¹⁶⁴

https://www.litres.ru/devid-doych/nachalo-beskonechnosti-obyasneniya-kotorye-menyaut-mir/chitat-onlayn/

¹⁶⁵

https://www.amazon.com/Enlightenment-Now-Science-Humanism-Progress-ebook/dp/B073TJBYTB/

¹⁶⁶

https://www.ipsos.com/sites/default/files/ct/news/documents/2019-08/Happiness-Study-report-August-2019.pdf

¹⁶⁷

https://www.facebook.com/kapterev/posts/10222689292514882, https://psyarxiv.com/d8f2z/

¹⁶⁸

https://www.princeton.edu/news/2006/06/29/link-between-income-and-happiness-mainly-illusion

¹⁶⁹

https://newscenter.sdsu.edu/sdsu_newscenter/news_story.aspx?sid=78079

¹⁷⁰

Talent vs. Luck: The Role of Randomness in Success and Failure, http://arxiv.org/abs/1802.07068

¹⁷¹

https://ru.wikipedia.org/wiki/Сетевой_график

¹⁷²

https://ru.wikipedia.org/wiki/PERT

¹⁷³

https://en.wikipedia.org/wiki/Commodity

¹⁷⁴

https://www.pmi.org/pmbok-guide-standards/foundational/pmbok

¹⁷⁵

https://en.wikipedia.org/wiki/PRINCE2

¹⁷⁶

https://ru.wikipedia.org/wiki/Программа_проектов

¹⁷⁷

https://ru.wikipedia.org/wiki/Портфель_проектов

¹⁷⁸

https://www.pmaj.or.jp/ENG/p2m/p2m_guide/p2m_guide.html

¹⁷⁹

https://asana.com/resources/theory-of-constraints

¹⁸⁰

https://ru.wikipedia.org/wiki/Теория_массового_обслуживания

¹⁸¹

https://ru.wikipedia.org/wiki/Исследование_операций

¹⁸²

https://www.omg.org/spec/BPMN/

¹⁸³

https://ru.wikipedia.org/wiki/Диаграмма_Ганта

¹⁸⁴

http://ailev.livejournal.com/1195297.html

¹⁸⁵

https://www.omg.org/spec/CMMN

¹⁸⁶

https://ru.wikipedia.org/wiki/Декларативное_программирование

¹⁸⁷

https://ailev.livejournal.com/693597.html

¹⁸⁸

https://www.omg.org/spec/SBVR/

¹⁸⁹

https://www.omg.org/spec/DMN

¹⁹⁰

https://ailev.livejournal.com/1176241.html

¹⁹¹

https://www.redmine.org/

¹⁹²

https://en.wikipedia.org/wiki/Value_network

¹⁹³

https://en.wikipedia.org/wiki/Getting_Things_Done

¹⁹⁴

https://mnogosdelal.ru/

¹⁹⁵

https://medium.com/@oliverjwang/summary-a5afeb3d83f3

¹⁹⁶

https://bbrt.org/product-category/books/

¹⁹⁷

https://corporate-rebels.com/beyond-budgeting-model/

¹⁹⁸

Подробно обсуждаются в BORO Book, https://disk.yandex.ru/i/2SgjvILB3PqJEZ

¹⁹⁹

https://medicalxpress.com/news/2018-06-coffee-teams.html

²⁰⁰

https://arxiv.org/abs/1207.2743

²⁰¹

https://www.pnas.org/doi/full/10.1073/pnas.1017298108

²⁰²

https://enliveningedge.org/organizations/zapposs-evolution-holacracy-market-based-dynamics/

²⁰³

https://en.wikipedia.org/wiki/Spiral_Dynamics

²⁰⁴

https://ailev.livejournal.com/693597.html

²⁰⁵

http://blog.bizzdesign.com/reference-architecture-models-with-archimate

²⁰⁶

https://pubs.opengroup.org/architecture/archimate32-doc/ (версия 3.2, опубликована в октябре 2022)

²⁰⁷

https://bizzdesign.com/blog/archimate-3-0-capability-mapping/

²⁰⁸

https://www.iiba.org/career-resources/a-business-analysis-professionals-foundation-for-success/babok/

²⁰⁹

https://www.iiba.org/

²¹⁰

https://www.lean.org/the-lean-post/articles/visual-management-the-good-the-bad-and-the-ugly/

²¹¹

По мотивам https://www.researchgate.net/publication/200026050_Collaborative_Networks_Reference_Modeling

²¹²

https://en.wikipedia.org/wiki/Toyota_Motor_North_America

²¹³

https://tameflow.com/books/

²¹⁴

https://www.amazon.com/Making-Major-Sales-Neil-Rackham/dp/0566026279, это хорошая, но очень старая книга, 1987 год, так что мы берём оттуда не слишком много и немного переформулируем.

²¹⁵

Видео доклада с обсуждением этой последовательности см https://www.youtube.com/watch?v=3iokMv1Sdpk&t=3709s. В этом докладе основной акцент делается на переход от «пропитки» к «принятию решения». Поним, что это доклад мая 2019 года, поэтому там много устаревшей уже терминологии и устаревших схем, но мы считаем, что вы сможете разобраться сами, что там актуально, а что нет, и что подходит для ситуации в вашем проекте оргразвития, а что нет.

²¹⁶

https://www.ivarjacobson.com/files/field_iji_file/article/use-case_2.0_final_rev3.pdf

²¹⁷

https://en.wikipedia.org/wiki/Site_reliability_engineering

²¹⁸

http://ailev.livejournal.com/1130190.html

²¹⁹

https://disk.yandex.ru/i/syeadDw9vPtkLg

²²⁰

https://sloanreview.mit.edu/article/with-goals-fast-beats-smart/, 2018

²²¹

https://thenewstack.io/how-is-platform-engineering-different-from-devops-and-sre/

²²²

https://ailev.livejournal.com/1622346.html

²²³

https://ailev.livejournal.com/213182.html

²²⁴

https://en.wikipedia.org/wiki/Talent_management

²²⁵

https://en.wikipedia.org/wiki/Incentive

Системный менеджмент

Введение

Дополнительные материалы

Оглавление

1. Системный менеджмент и системная инженерия

Менеджмент как прикладная системная инженерия для организаций

TEST

Задания

Теории менеджмента

Упражнения

Праксеология, экономика и менеджмент

Задания

Право, этика и менеджмент

Менеджмент и эволюция

Задания

2. Практики менеджмента и роли менеджеров

Конкретизация мета-мета-модели инженерии до мета-модели прикладной практики

Конкретизация системноинженерных практик и ролей для менеджмента

Примеры соответствия системноинженерных и прикладных ролей

Упражнения

Широкое, узкое и слишком узкое понимание менеджмента. Менеджерские (под)практики и (под)роли

Роли, должности, организационные статусы

Менеджмент, предпринимательство и начальничество

Задания

Тренды современного менеджмента и выбор SoTA

Упражнения

Задания

3. Практика бизнеса (прибыльности)

Предприятие как продукт: оно тоже продаётся

TEST Бизнес

Упражнения

Задания

Практика корпоративных финансов (инвестиции и займы)

Практика корпоративной подназдорности (corporate governance)

4. Практика стратегирования

Понятие стратегии

Практика стратегирования

Задания

Качества хорошей стратегии: это фильтр

Задания

Бизнес-модель и её «холстовое» моделирование

Модель оргразвития

Модель целеполагания/motivation для согласования интересов

Упражнения

Культура съедает стратегию на завтрак, а реорганизацию на обед

TEST Получение инвестиций

5. Теория стратегирования

Будущее уже здесь

Подрыв подо всей цивилизацией сразу

Пример подрыва: электромобили уже сейчас дешевле бензиновых автомобилей

TEST Технологический подрыв

Задания

Роботы заберут работу? Нет!

Инновации: всегда сбоку

TEST Скорость обучения нейросети

Упражнения

Неудачная практика Коллинза: стратегирование ежа

Упражнения

Задания

Стратегирование вместо мечтаний

Упражнения

Бесконечное развитие (open-endedness)

TEST бесконечного развития

Упражнения

Задания

Теории счастья и богатства

Упражнения

Задания

6. Практика управления работами (операционный менеджмент)

Практика управления проектами

Практики управления процессами и управления кейсами

TEST Проекты, программы, процессы, кейсы

Упражнение

«Распожаризация» и управление работами

Упражнение

TEST Управление кейсами

Упражнение

Основные книги по современному операционному менеджменту

Задания

Управленческий финансовый учёт и контроллинг