Читать онлайн Системный менеджмент – 2023 бесплатно

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

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

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

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

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

3. Организационная система рассматривается не сама по себе, а как создатель (constructor system), входящая в цепочку создания целевой системы (system of interest). То есть организация в менеджменте не целевая система (мы считаем ошибкой считать организацию-создатель целевой системой), а «наша система» (system-in-hand, engineered system). И может быть довольно много организаций в цепочке создания (даже «цепочка» тут очень условно, это направленный граф), связанных с созданием какой-то целевой системы. И наличие целевой системы позволяет всем этим организациям как-то договариваться о действиях, людям с их оборудованием достигать каких-то согласованных целей – и эти цели обычно связаны с созданием и далее бесконечным развитием целевых систем.

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

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

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

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

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

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

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

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

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

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

⠀

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

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

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

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

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

• организационного развития/organizational development13, посвящённые главным образом construction/dev-time в части изменения поведения людей,

• операционного менеджмента/operations management14, затрагивающем прохождение потока обрабатываемых материалов, информации и работ по рабочим местам компании,

• стратегирования, как предпринимательства в менеджменте.

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

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

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

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

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

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

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

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

…

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

…

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

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

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

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

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

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

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

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

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

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

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

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

1. Разработки (стратегирование, архитектурирование/architecting, проектирование организации или её части/оргвозможности/capability),

2. создания (организационные изменения: претворение стратегии и оргпроекта/orgdesign в жизнь),

3. непрерывного развития (эволюция).

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

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

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

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

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

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

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

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

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

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

• Организация оргвозможности маркетинга в предприятии (оргвозможности пропаганды в госорганах, партийных организациях, организация просвещения) это создание и развитие организации, для оргзвеньев таким занимается системный менеджмент.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

⠀⠀2.1. Находится в мозгах сотрудников. Сотрудники

⠀⠀перетаскивают отдельные идеи менеджмента,

⠀⠀перемещаясь из одной организации в другую.

⠀⠀2.2. Находится в софте, который поддерживает какие-то

⠀⠀практики. Сотрудники задействуют какие-то

⠀⠀менеджерские идеи (например, какие объекты

⠀⠀считать важными в менеджменте, именно эти объекты

⠀⠀будут отражены в базе данных софта).

⠀⠀2.3. Находятся в учебниках менеджмента, материалах

⠀⠀менеджерских курсов.

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

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

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

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

• Есть множество вариантов, которые на данном этапе эволюции можно назвать «лучшими» (множество вариантов SoTA примерно одной результативности и эффективности)

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

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

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

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

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

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

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

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

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

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

⠀

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

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

• Нарезка на объекты (роли и их функции-практики) должна быть достаточно мелкой, чтобы отражать самые разные причудливые сочетания функций, которые выполняют самые разные универсальные аффордансы (конструктивные части, которые можно приспособить под выполнение тех или иных функций). Как компьютер может выполнять огромное количество функций, так и оргзвено может выполнять огромное количество функций. Функции должны быть достаточно мелкими, чтобы указать, какие функции какой аффорданс (конструктивный объект, который мы задействовали) выполняет. Поэтому берём какого-нибудь 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-service35. Если таки надо дорабатывать IDP, то это обеспечивают инженеры конвейера/платформы, то есть исполнители ролей DevOps, но они сами ничего не изготавливают в целевой системе, занимаются только «станочным парком». Кнопку «изготовить» нажимает сам разработчик, а не DevOps, и он же имеет дело с последствиями, это принципиально: you build it, you run it – ты это строишь, ты и эксплуатируешь36). Тут сразу сложно, ибо мы получаем «систему создания внутри системы создания», создатели-операторы целевой системы «холдинг из конструкторского бюро (КБ) и завода» и «создатели-операторы КБ плюс завода». При этом понимаем, что в большинстве случаев это совсем не похоже на «конструкторское бюро» и «завод», например, трудно говорить о «конструкторском бюро для оргсистем» и «заводе оргсистем», «конструкторском бюро мастерства» и «заводе мастерства» и даже для компьютерных программ это не так очевидно. Но структура производства и эксплуатации везде будет одинаковой.

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

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

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

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

• Редко так мало звеньев в цепочке создания. На диаграмме три звена, а в жизни в типовых ситуациях 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 и прочих администраторов, которые явно не справляются с должностями, требующими компетенций в других ролях. Они «работники производственного конвейера для поддержки жизни организации, поддержки развития», а после приобретения какого-то опыта могут пытаться ещё и строить такой конвейер. Но вот использование этого конвейера для развития организации в целом требует других специализаций: организатора, бизнесмена, архитектора организации. И мы понимаем, что слово «администратор» очень широкое, но всё-таки означает чаще «исполнительные» роли поддержки какого-то конвейера, а не роли, занятые использованием этого конвейера для какого-то дела (при всём понимании, что «всё со всем связано, конвейер должен быть согласован с типом тех систем, которые по нему проходят»).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Все, кто занимаются инженерией (созданием и развитием) целевой системы – инженеры целевой системы. Мы оставляем тут общее слово «инженеры», понимая, что для каждой предметной области это слово будет меняться. Например, если целевая система – это тело человека, то это «врачи». Помним, что нас тут интересуют не слова, а роли в деятельности. Если интересно, как должны работать эти люди, надо брать учебник «Системная инженерия» и адаптировать его для предметной области примерно так же, как мы это делаем для системы-организации. Среди прикладных инженеров, например, корпоративных информационных систем можно найти разработчиков, визионеров, архитекторов, DevOps. И мы дальше для краткости будем говорить, что прикладные инженеры создают целевую систему (а длинно – создают и развивают, continuous everything).

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

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

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

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

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

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

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

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

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

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

2.2. Лидерство/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 coach40 и дальше оргстатусы приглашённых консультантов по отдельным практикам) и подумать о том, что происходит в жизни там, где вроде как должна существовать практика наставничества. Потом попробовать вспомнить, где практика наставничества реально существует и даёт результаты, и как она там организована (автор в своей менеджерской практике нигде такого не видел: наставничество «пожилыми молодых» как таковое жило только на бумаге, а реальное всегда было организовано в рамках какой-то организации труда с обычным распределением обычных полномочий обычных сотрудников, а не «как в наставничестве» каким-то особым порядком. С «консультантами» и «учителями/тренерами» обычно понятно, а вот с «наставниками» – нет. Вот и переходите от названий ролей к подробному описанию практик и не забывайте оценить реалистичность выполнения этих практик).

• На должность может быть назначено целое предприятие, даже на должность директора. Например, как поменять CEO мимо решения акционеров? Назначаем ООО «Директор» единоличным исполнительным органом АО «Марионетка» решением собрания акционеров. Затем директор ООО «Директор» назначает Васю исполняющим роль директора АО «Марионетка» от имени ООО «Директор». И если затем нужно по-быстрому сменить Васю на Дашу, то это пять минут на оформление приказа по ООО «Директор», а не внеочередной созыв собрания акционеров. Такая схема (помним, что у нас это термин: когда официальное/юридически признаваемое оформление организационных статусов по-одному, а реализация в жизни – совсем по-другому) используется повсеместно. Например, при реорганизации РАО «ЕЭС России» было именно так: директора региональных энергокомпаний могли быть переназначены за минуты, никаких месячных ожиданий на созыв собраний акционеров, договорённости с местными властями и прочие реверансы. Второй пример: стаффинговые компании41, которые одалживают людей для работы в других фирмах, но формально эти люди работают у них в штате (случай директоров РАО «ЕЭС России» на это очень похож, «одалживают директора», хотя не по просьбе одалживающей фирмы, но принудительно). Консалтинговые фирмы занимаются примерно тем же: могут одолжить тебе целый отдел консультантов (скажем, аудиторов), но формально люди работают у них в штате. Должности как организационные статусы этих людей обычно отсутствуют, но могут существовать невнятные организационные статусы в самой организации, по этим статусам вообще невозможно понять ролей. Скажем, консультантов по новым технологиям так и представляют: «это наш консультант» (организационный статус) и часто даже не добавляют, по чему именно (какой практике) консультант: потому как приходится консультировать и по какой-то прикладной инженерии чего-то в целевой системе, и по организовыванию на эту инженерию какой-то службы, и по многому ещё, что понадобится. За словом «консультант» точно так же может скрываться огромное число ролей, и надо разбираться специально, о чём в каждый момент времени идёт с ним разговор).

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

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

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

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

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

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

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

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

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

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

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

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

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

• основатель/founder какого-то предприятия как юрлица. Поскольку речь идёт именно об открытии нового предприятия, то его называют стартапом. То есть если не стартап, и ты в нём не в числе учредителей, то вроде не предприниматель. То, что там собственность делится с инвесторами, которые пришли со стороны, это уже неважно, важен сам момент участия в основании дела как юрлица. Если в стартап пришёл CEO, который делает ровно то же, что месяц назад делал основатель/founder, и которому инвесторы дали такую же долю, какую имел founder, то его не будут называть предпринимателем, но назовут менеджером (ещё и «наёмным менеджером»). А менеджера (или даже инженера), который в свободное от работы по найму время уболтал инвестора дать начальные деньги и зарегистрировал стартап как отдельный проект – вот его назовут предпринимателем. И тут надо вспомнить, что Eric Ries в Lean Startup писал, что любое дело – это стартап, ибо предусматривает примерно одинаковое поведение при ведении каких угодно проектов по созданию систем и предоставлению сервисов. То есть необязательно это «предприятие», запуск любого проекта внутри большой фирмы, запуск проекта в порядке хобби. Получается, что и само понятие основателя/founder тоже размыто, предприниматель-как-основатель – это основатель любого проекта, даже меньше, чем организационный статус, просто замечание про момент формализации проекта. Плюс множество споров, кто же основатель: в основании фирм обычно участвует множество людей с различным ролевым вкладом. Некоторые больше озабочены, чтобы оформить результат основания фирмы юридически, и не забывают при этом оформить кусочек себе побольше, а некоторые больше озабочены, чтобы создать успешный MVP и мало заботятся о юридическом оформлении своей доли, и их вклад содержательно оказывается определяющий, а юридически оказывается не закреплён. Это ведёт к конфликтам43.

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

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

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

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

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

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

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

• Если не было действий по предыдущим пунктам, то указание нужно просто выполнить. Но нельзя промолчать и не выполнить: переспросы и возражения должны быть явными (и письменными). Если промолчать и не выполнить – лучше сразу увольняться.

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

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

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

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

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

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

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

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

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

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

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

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

1. инженерия целевой системы – инженер целевой системы

⠀⠀1.1. визионерство целевой системы (прогноз

⠀⠀целесообразности создания целевой системы) —

⠀⠀визионер

⠀⠀1.2. архитектурная деятельность для целевой

⠀⠀системы – архитектор

⠀⠀1.3. разработка – разработчик

⠀⠀⠀⠀1.3.1. проектирование – проектировщик

⠀⠀⠀⠀1.3.2. изготовление/производство —

⠀⠀⠀⠀инженер-технолог

⠀⠀⠀⠀1.3.3. эксплуатация – оператор целевой системы

⠀⠀1.4. инженерия платформы разработки (DevOps) —

⠀⠀инженер платформы разработки

2. менеджмент (инженерия организации) – менеджер в широком понимании (инженер организации)

⠀⠀2.1. стратегирования (для удержания стоимости

⠀⠀бизнеса) – бизнесмен

⠀⠀2.2. орг-архитектурная деятельность – орг-архитектор

⠀⠀2.3. организовывание – организатор, менеджер

⠀⠀в узком понимании

⠀⠀⠀⠀2.3.1. организационное развитие – менеджер

⠀⠀⠀⠀по оргразвитию

⠀⠀⠀⠀⠀⠀2.3.1.1. оргпроектирование – оргпроектировщик

⠀⠀⠀⠀⠀⠀2.3.1.2. лидерство – лидер, менеджер

⠀⠀⠀⠀⠀⠀в слишком узком понимании

⠀⠀⠀⠀2.3.2. операционный менеджмент – операционный

⠀⠀⠀⠀менеджер

⠀⠀2.4. администрирование – администратор

3. продвижение продукта или услуги (инженерия клиентуры: маркетинг, реклама, продажи) – продвиженец (там тоже разбиение на подпрактики и подроли!)

4. привлечение инвестиций (инженерия инвестуры, fundraising) – фандрайзер

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

⠀

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

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

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

• Автоматизация (ибо вроде как компьютеры заменяют людей)

• Автоматизация с разными эпитетами – экстремальная, тотальная, гипер).

• Цифровая трансформация (ибо в основе лежит цифровое, то есть численное/дискретное моделирование, опора на данные – хотя тут тоже есть разночтения о том, что такое «цифра» и что такое «трансформация»)

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

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

• … много других имён, маркетинг поставщиков компьютерных технологий для практик менеджмента не дремлет.

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

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

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

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

Но всякий присмотр за людьми-роботами (типа «кто там матом из сейлзов ругался на наших клиентов?») плюс попытки автоматизировать HR (у наших студентов был хороший пример с роботом HR Yva46