Читать книгу Системный менеджмент – 2023 - Анатолий Левенчук - Страница 11

Только что мы определили, что если создаём и развиваем организацию, то нам нужны следующие роли для инженерии организации как общей практики: организатор::разработчик, бизнесмен::визионер, орг-архитектор::архитектор, администратор::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».