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

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

Должна ли компания заботиться о каких-то социальных целях? То есть насколько нужно придерживаться идей Environmental, Social, and Governance (ESG) Investing[32 - https://www.investopedia.com/terms/e/environmental-social-and-governance-esg-criteria.asp (https://www.investopedia.com/terms/e/environmental-social-and-governance-esg-criteria.asp)]? Как всегда в таких случаях, когда речь идёт о социалистических идеях (примат кем-то озвучиваемых «общественных интересов» над любыми другими), то в период моды на такие идеи трудно получить какую-то взвешенную и уж тем более критическую оценку. Скажем, вам предлагается брать не лучших работников, которые вам доступны, а всех подряд, чтобы выполнить условие по достаточному для госорганов количеству работающих у вас инвалидов и «национальных кадров» (как говорили раньше про представителей национальных меньшинств) – надо ли это делать, ибо компания очевидно будет при этом работать хуже, зато это вроде как «правильно»? Или компания строит ещё один кусочек города на планете, вместо удержания Земли в первозданной дикости – тренд на урбанизацию разве не прогрессивен, а «назад к нетронутой природе» это разве не «назад к дикости»? Должна ли компания поддерживать тот или иной международный бойкот, не работая на какой-то «оккупированной территории» (что ещё больше ухудшит жизнь «оккупированных»)? Должна ли поддерживать «культуру отмены», исключая использование заведомо хороших продуктов и сервисов людей и компаний, которые чем-то не понравились тем или иным лидерам общественного мнения? Должна ли компания работать на военных?

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

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

Например, насколько этично использование схем, описанных в текущем подразделе? Мы считаем, что абсолютно этично: нельзя признавать безумные требования (даже не гипотезы, как в инженерии), предъявляемые самыми разными проектными ролями, утверждающими, что они говорят от имени «народа», если вы понимаете, что эти требования всем делают только хуже, а лучше станет некоторым, и то ненадолго. Не надо делать итальянскую забастовку, не надо бездумно тратить деньги инвесторов, надо просто сконструировать подходящую схему, минимизирующую риски. Этично ли это? Авторы курса считают, что абсолютно этично: законность («что написано в законах и регламентах, то и справедливо», правовой позитивизм в его этатистской версии, легизм[33 - https://ru.wikipedia.org/wiki/Правовой_позитивизм (https://ru.wikipedia.org/wiki/%D0%9F%D1%80%D0%B0%D0%B2%D0%BE%D0%B2%D0%BE%D0%B9_%D0%BF%D0%BE%D0%B7%D0%B8%D1%82%D0%B8%D0%B2%D0%B8%D0%B7%D0%BC)], закон вполне может санкционировать и произвол и даже необоснованное никак насилие) и правозаконность (справедливо то, что справедливо – результат многоуровневой оптимизации конфликтов разных системных уровней, законы и приказы это отражают, а где не отражают, должны не исполняться).

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

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

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

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, IFS[34 - https://ifs-institute.com/ (https://ifs-institute.com/)]).

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

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

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

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

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

?

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

?

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

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

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

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

?

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

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

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

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

?

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

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