С точностью до довольно запутанных цепочек создания (то есть в предельном упрощении) в организации вы найдёте множество самых разных ролей:
Все, кто занимаются инженерией (созданием и развитием) целевой системы инженеры целевой системы. Мы оставляем тут общее слово «инженеры», понимая, что для каждой предметной области это слово будет меняться. Например, если целевая система это тело человека, то это «врачи». Помним, что нас тут интересуют не слова, а роли в деятельности. Если интересно, как должны работать эти люди, надо брать учебник «Системная инженерия» и адаптировать его для предметной области примерно так же, как мы это делаем для системы-организации. Среди прикладных инженеров, например, корпоративных информационных систем можно найти разработчиков, визионеров, архитекторов, 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».
Роли, должности, организационные статусы
Главное, что нужно помнить, когда разбираетесь с устройством какой-то организации не надо честно верить всем произносимым разными людьми словам, всем табличкам на дверях. Помним высказывание Козьмы Пруткова: «Если на клетке слона прочтешь надпись: буйвол, не верь глазам своим». Люди вроде бы называются «на слух» понятно и можно вроде ожидать от них выполнения каких-то понятных из их названия работ, но это не так:
Работа может выполняться не человеком-начальником, а его подчинённым («я это выполню» может означать «мой сотрудник Петя это сделает»), поэтому разговаривать о деталях дела надо не с начальником, а с подчинённым. С начальником надо договариваться о координационных актах (поручения, обещания, информирование о моменте выполнения обещания, подтверждение приёмки работы как выполнения вашего обещания её сделать, и т.д.). Мы называем «начальником» человека с ролевым аспектом распоряжения трудом и ресурсами.
Должности часто называются по ведущей роли, но это не обязательно. Есть штатное расписание, и там будет какой-нибудь «специалист второй категории» как должность (организационное место), на этой должности может находиться человек с самым разным мастерством, выполняющий самые разные роли. И даже начальник, который распоряжается его трудом, у него может оказаться не тот, который записан в штатном расписании. Это «схема»: штатное расписание нужно только для того, чтобы «официально» выписывать человеку зарплату, а реальное положение дел закреплено устными договорённостями.