скачать книгу бесплатно
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 coach[40 - https://www.toptal.com/project-managers/agile/what-is-an-agile-coach (https://www.toptal.com/project-managers/agile/what-is-an-agile-coach)] и дальше оргстатусы приглашённых консультантов по отдельным практикам) и подумать о том, что происходит в жизни там, где вроде как должна существовать практика наставничества. Потом попробовать вспомнить, где практика наставничества реально существует и даёт результаты, и как она там организована (автор в своей менеджерской практике нигде такого не видел: наставничество «пожилыми молодых» как таковое жило только на бумаге, а реальное всегда было организовано в рамках какой-то организации труда с обычным распределением обычных полномочий обычных сотрудников, а не «как в наставничестве» каким-то особым порядком. С «консультантами» и «учителями/тренерами» обычно понятно, а вот с «наставниками» – нет. Вот и переходите от названий ролей к подробному описанию практик и не забывайте оценить реалистичность выполнения этих практик).
• На должность может быть назначено целое предприятие, даже на должность директора. Например, как поменять CEO мимо решения акционеров? Назначаем ООО «Директор» единоличным исполнительным органом АО «Марионетка» решением собрания акционеров. Затем директор ООО «Директор» назначает Васю исполняющим роль директора АО «Марионетка» от имени ООО «Директор». И если затем нужно по-быстрому сменить Васю на Дашу, то это пять минут на оформление приказа по ООО «Директор», а не внеочередной созыв собрания акционеров. Такая схема (помним, что у нас это термин: когда официальное/юридически признаваемое оформление организационных статусов по-одному, а реализация в жизни – совсем по-другому) используется повсеместно. Например, при реорганизации РАО «ЕЭС России» было именно так: директора региональных энергокомпаний могли быть переназначены за минуты, никаких месячных ожиданий на созыв собраний акционеров, договорённости с местными властями и прочие реверансы. Второй пример: стаффинговые компании[41 - у https://americanstaffing.net/staffing-industry/what-staffing-firms-do/ (https://americanstaffing.net/staffing-industry/what-staffing-firms-do/)], которые одалживают людей для работы в других фирмах, но формально эти люди работают у них в штате (случай директоров РАО «ЕЭС России» на это очень похож, «одалживают директора», хотя не по просьбе одалживающей фирмы, но принудительно). Консалтинговые фирмы занимаются примерно тем же: могут одолжить тебе целый отдел консультантов (скажем, аудиторов), но формально люди работают у них в штате. Должности как организационные статусы этих людей обычно отсутствуют, но могут существовать невнятные организационные статусы в самой организации, по этим статусам вообще невозможно понять ролей. Скажем, консультантов по новым технологиям так и представляют: «это наш консультант» (организационный статус) и часто даже не добавляют, по чему именно (какой практике) консультант: потому как приходится консультировать и по какой-то прикладной инженерии чего-то в целевой системе, и по организовыванию на эту инженерию какой-то службы, и по многому ещё, что понадобится. За словом «консультант» точно так же может скрываться огромное число ролей, и надо разбираться специально, о чём в каждый момент времени идёт с ним разговор).
Общие замечания: разбирайтесь не по названиям оргстатусов, но по практикам и ролям с их интересами, интересуйтесь системой в цепочке создания, для изменений которой применяются эти практики, интересуйтесь уровнем квалификации в практике оргзвена, выполняющего эту практику (помним, что практику выполняет необязательно один человек. Практика разработки, например, может выполняться командой, и «квалификация команды» эмерджентна, не равна сумме квалификаций её членов – например, они могут внутри себя не договориться, как выполнять разработку, хотя каждый из них может быть более чем умел в разработке, поэтому не могут быть коллективным разработчиком, не могут выполнять эту роль как оргзвено).
Должности (и подразделения как аналоги должностей уровня выше личности) и другие оргстатусы – это чаще всего просто элемент «схемы для найма на работу и выплаты зарплаты», возможность как-то платить зарплату (в случае подразделения то же самое, плюс может речь идти о делёжке бюджета, квотам на разные бонусы) разных размеров разным нужным для выполнения каких-то практик (играющих какие-то нужные роли) людям, возможность понятным образом назначить «формального начальника». Это нельзя путать с ролями. Когда говорят «исполнение должности», то это «исполнение большого количества ролей, на которые назначена эта должность».
При этом первым же шагом в реальности, а не формальной модели из «схемы» после назначения на должность может быть передача сотрудника (или даже целого подразделения) в какой-то проект и назначение премии за успехи в этом проекте – и сумма премии и выполнение задач этого проекта после чего будет в разы и разы больше, чем сумма зарплаты и выполнение задач по линии основной должности. Поэтому задавайте вопросы и уточняйте роль, выполняемую ролью практику и ролевые интересы. Иначе договориться будет невозможно.
Если встретились «скользкие типы», с которыми невозможно понять, чем же они занимаются (роль и её практику), задействуйте лидерство: совместите человека с какой-то важной ролью и отследите, чтобы всё его окружение заставляло этого «скользкого типа» заниматься именно этой ролью, а не увиливать от работы. В явном виде называйте роль и практику, требуйте их исполнения и расскажите всем окружающим об этом: у них ведь наверняка такие же проблемы с этим «скользким типом». Может быть, это не скользкий тип, а просто запутавшийся в своих делах человек. Сосредоточение на какой-то роли (поначалу с мягким внешним понуканием к её занятию) осмыслит его существование на предприятии, он будет благодарен. Если нет – расставайтесь под любым предлогом, люди без глубокой ролевой специализации, но ласковые общительные и поэтому часто с полномочиями (кто из начальников не даст какой-то организационный статус своей ласковой мимими-кошечке в лице приятного человека! Ему ж нетрудно!) не нужны.
Автору курса пришлось как-то уволить системного администратора, который был ласков, общителен и работоспособен, но не владел практикой системного администрирования: коллектив его очень любил, но по своей роли он работать не мог, ни одна задача системного администрирования не решалась вовремя (и вообще не решалась, приходилось эти задачи решать другим людям). Коллективу было жалко расставаться с приятным сотрудником, но после увольнения все облегчённо вздохнули: сильно уменьшилось количество проблем по линии системного администрирования. Это тоже рассказ про агентов с их ролями и выполнением практик, должностями/оргместами/организационными статусами, психологическими особенностями и квалификацией в выполнении практики выполняемой роли. Обсуждать такие случаи нужно ровно так: это и есть набор важных объектов при работе с оргзвеньями (включая internal team частей личности уровня ниже уровня личности, а также крупные подразделения больших компаний уровня много выше уровня личности).
Роли и выполнение практик – главное, приучайтесь обращать внимание на них в первую очередь, на реальные (не по штатному расписанию и должностям, а по линии «кто на кого влияет, кто с кем дружит») полномочия во вторую очередь, на психологические особенности – в третью.
Тем не менее, если вы имеете возможность влиять на штатное расписание, то старайтесь давать должностям наименование согласно культурно-обусловленным ролям, это существенно повышает возможности сотрудникам понимать: о чём с кем договариваться. Сотрудники будут, конечно, обращаться друг ко другу как к «должностям» (у них ведь нет тренинга в системном мышлении, да и роли для всех должностей им обычно неоткуда знать, если они не очень давно в организации, а организация большая). Но поскольку вы позаботились, что названия должностей и основных ролей по возможности совпадают, то коммуникация будет более качественной, как-то связанной с ролями и ролевыми интересами, а не произвольной, поскольку роли и интересы неясны, и нужно тратить время, чтобы их выяснить для каждой ситуации встречи с «должностью». Помним про «аналитика» из примеров разбирательства с должностями выше, попробуйте сделать так же и с другими должностями по аналогии с «аналитиком».
Менеджмент, предпринимательство и начальничество
Безусловно, менеджмент и «предпринимательство» (какую бы практику ни означало это слово) тесно связаны. Менеджмент как практику создания и развития организаций (включая операционный менеджмент как практику эксплуатации организаций, бизнес как практику продажи организаций) мы уже определили.
«Предпринимательство» вроде как то же самое, что «менеджмент», чем же они отличаются? Разве не любой менеджер или даже инженер там и тогда, когда они задумываются о стоимости (а это, заметим, обязательный аспект в системных описаниях, наряду с функциональным, конструктивным и размещением) – это предприниматель? А если речь идёт о собственнике, то разве не он предприниматель, тогда странно, что создают и развивают фирму (принимают решения по поводу деятельности) менеджеры, а собственник (скажем, миноритарный акционер) может вообще не знать, что там у фирмы внутри, то есть вроде как не собственник создаёт и развивает фирму, так что предприниматель вроде и не обязательно собственник!
Наше предложение: не использовать/табуировать слово «предприниматель», так как оно очень многозначно и порождает многочисленные ассоциации, затрудняющие обсуждения:
• это шумпетеровский предприниматель из австрийской школы экономики (с уточнениями Кирцнера и многих других исследователей этой школы). Роль, которая имеет межвременные предпочтения: считает, что использование каких-то ресурсов сейчас по сравнению с будущим даст больше NPV (net present value). Смотрит в будущее, угадывает спрос и говорит, что «это выгодно» или «это невыгодно». Капиталист (владелец предприятия, инвестор), изобретатель/инженер с идеей аффорданса для надсистемы – это другие роли. Шумпетеровского предпринимателя мы будем называть «стратег/визионер» в его роли по отношению к выгодности продаж целевой системы и «бизнесмен» в его роли по отношению к выгодности инвестиций в организацию. Конечно, есть и другие варианты трактовки предпринимателя в экономике, появившиеся позже предложений Шумпетера, но для нас сейчас эти нюансы неважны, берём самое распространённое на сейчас понимание.
• человек, который затевает какое-то дело и поэтому имеет определённый склад характера, то есть «предприимчивость» и склонность к принятию рисков (в отличие от людей, которые затевают свои дела без такого склада характера, а просто затевают и затевают – не выпячивая свою «предприимчивость», а просто всё время что-то предпринимая). Основное качество этого человека-агента: толерантен к рискам, в том числе невосприимчив к критике (выслушивает всех и делает наоборот, меднолобый фанатик, только не религиозный, а какой-то другой идеи, что мало меняет суть дела), «прёт напролом». Если тихо что-то делает, быстро соглашается, то вроде «не предприимчив». Когда мы говорим о «предпринимательстве» с сотрудниками стартап-акселераторов и инвестиционных фондов, то сразу речь заходит о людях с подобными психологическими характеристиками[42 - https://www.youtube.com/watch?v=RszF-Kl4-f4 (https://www.youtube.com/watch?v=RszF-Kl4-f4)] – они просто описывают психологические характеристики людей, с которыми общаются. То есть в данном случае «предприниматель» – это психотип.
• основатель/founder какого-то предприятия как юрлица. Поскольку речь идёт именно об открытии нового предприятия, то его называют стартапом. То есть если не стартап, и ты в нём не в числе учредителей, то вроде не предприниматель. То, что там собственность делится с инвесторами, которые пришли со стороны, это уже неважно, важен сам момент участия в основании дела как юрлица. Если в стартап пришёл CEO, который делает ровно то же, что месяц назад делал основатель/founder, и которому инвесторы дали такую же долю, какую имел founder, то его не будут называть предпринимателем, но назовут менеджером (ещё и «наёмным менеджером»). А менеджера (или даже инженера), который в свободное от работы по найму время уболтал инвестора дать начальные деньги и зарегистрировал стартап как отдельный проект – вот его назовут предпринимателем. И тут надо вспомнить, что Eric Ries в Lean Startup писал, что любое дело – это стартап, ибо предусматривает примерно одинаковое поведение при ведении каких угодно проектов по созданию систем и предоставлению сервисов. То есть необязательно это «предприятие», запуск любого проекта внутри большой фирмы, запуск проекта в порядке хобби. Получается, что и само понятие основателя/founder тоже размыто, предприниматель-как-основатель – это основатель любого проекта, даже меньше, чем организационный статус, просто замечание про момент формализации проекта. Плюс множество споров, кто же основатель: в основании фирм обычно участвует множество людей с различным ролевым вкладом. Некоторые больше озабочены, чтобы оформить результат основания фирмы юридически, и не забывают при этом оформить кусочек себе побольше, а некоторые больше озабочены, чтобы создать успешный MVP и мало заботятся о юридическом оформлении своей доли, и их вклад содержательно оказывается определяющий, а юридически оказывается не закреплён. Это ведёт к конфликтам[43 - https://www.embroker.com/blog/cofounder-conflict-guide/ (https://www.embroker.com/blog/cofounder-conflict-guide/)].
• просто деятель, который всё время что-то предпринимает, предприниматель как синоним «предприимчивый человек». Необязательно предприимчивый человек (предприниматель) вообще как-то озабочен коммерческой стороной вопроса, «бизнесом». Например, могут сказать, что предприимчивый человек приспособил камень вместо молотка как «забивало». Вот прямо «предпринимателем» такого человека не назовут, но язык не проведёшь: это и называют предприимчивостью, умение приспособить какой-то аффорданс (какой-то физический объект, найденный в окружающей среде) для выполнения какой-то нужной функции. То есть любой инженер – это предприниматель, предприимчивый человек. Если эти аффордансы описаны в литературе, то предприимчивости тут мало, если не описаны, но не очень оригинальны – это рационализатор, а если оригинальны – изобретатель. Предпринимателем часто называют изобретателя, который хочет на своей или даже чужой идее аффорданса заработать деньги, открыв дело/бизнес: сочетание изобретателя, шумпетеровского предпринимателя и основателя в одном лице. То есть это и агент, и психотип агента, и букет ролей (выполняемых по разным практикам), и организационный статус, и психотип, и всё что угодно, обсуждать такое профессионально невозможно, предмет обсуждения всё время плывёт.
• инвестор, имеющий собственные деньги (или управляющий деньгами других людей) и вложивший их куда-нибудь, чтобы иметь ещё больше денег. Капиталист, владелец предприятий (то есть не шумпетеровский предприниматель: сам ничего не делает, его интересует только «пассивный доход» от деятельности других людей).
• … ещё множество самых разных значений слова «предприниматель»: богатый человек, представитель «бизнеса» в отличие от «чиновничества» (даже неважно, собственник он предприятия или нет), и т. д. У каждого человека в голове при слове «предприниматель» возникает что-то своё. У кого это роль, у кого агент, у кого должность/организационный статус, у кого социальный статус (принадлежность к сословию, это неважно, что сословий уже вроде нет), у кого психотип – в сложных их сочетаниях.
Так что лучше табуировать слово «предприниматель» и использовать альтернативные термины с более узкими значениями. Часть этих терминов может быть из менеджмента, когда будет обсуждаться менеджерская деятельность того, кого обозвали «предпринимателем». Трудности могут быть в том, что у «предпринимателя» менеджерская часть его практик не будет таковой признаваться. А нам надо вытащить эту часть практик и обсудить её явно, включая квалификацию агента в исполнении менеджерских ролей (в их широком, узком и слишком узком значениях. Если не помните, что имеется в виду, найдите в учебнике этот материал и повторите его, вы должны уже это помнить).
Ровно такие же рассуждения проходят по поводу ролей «начальников»: их организационный статус полностью заслоняет рассмотрение их ролей и практик, что не позволяет разобраться в интересах, что не позволяет как-то проводить рациональное мышление для понимания действий «начальников». Однажды автор учебника наблюдал, как проходящий мимо начальник дал указание группе сотрудников, ознакомившихся с материалом про практики и роли, должности и полномочия. Вопрос был: в какой роли был начальник, когда давал указания, и в чём его интерес. Увы, сотрудники не смогли даже удержать внимания на вопросе про роли, собранность (понятийное наведение, а затем удержание внимания на каких-то важных объектах, в данном случае роли и практики) оказалась на нуле: «он ведь начальник, какая разница» был ответ хором, и обсуждения не получалось. А потом точно так же не получится выполнение поручения. Или поручение будет выполнено, но никто не сообразит, что оно было безумным ввиду некомпетентности «начальника» в практике. Начальник – это «джокер», который может по идее играть любые роли, выполнять любые практики. Но некоторые практики начальник выполняет в силу своей плохой квалификации в этой практике плохо, то есть делает новичковые ошибки. Тогда нужно явно указывать на эти ошибки и просить аргументы (инженерные обоснования: претензия-аргументы-свидетельства), почему надо делать так, как указано, а не иначе (хорошо задавать вопрос в форме «правильно ли я понял указание: я делаю так-то и так-то, получая в итоге из-за того-то и того-то то-то и то-то». Элон Маск разослал в Tesla записку[44 - https://www.marketwatch.com/articles/tesla-ceo-elon-musk-51637708903 (https://www.marketwatch.com/articles/tesla-ceo-elon-musk-51637708903)], где описал три варианта действий при получении от него указаний как «от начальства»:
• Можно и нужно указать на ошибку (и вот тут тоже надо понимать, какая практика что говорит по поводу таких действий, о системах какого уровня идёт речь, ибо то, что кажется ошибкой с одного системного уровня, «человека нельзя резать ножом!» может казаться совсем не ошибкой на другом уровне «мы делаем хирургическую операцию! Если не сделать – помрёт ведь!». Но может быть и наоборот: «при хирургической операции режут не ножом, а скальпелем, от простого ножа помрёт ведь!». Так что надо разобраться, о какой практике в отношении какой системы говорится, что именно надо сделать и почему там ошибка)
• Можно и нужно переспросить, если не понял (и тут очень полезно разобраться, исходя из какой практики какой роли было сделано начальственное указание, какие интересы должны быть соблюдены, что именно переспрашивать можно, а что нельзя. В курсе «Практическое системное мышление» были на эту тему вопросы про ситуацию с посылкой царём мудрецов описывать самоходную тележку).
• Если не было действий по предыдущим пунктам, то указание нужно просто выполнить. Но нельзя промолчать и не выполнить: переспросы и возражения должны быть явными (и письменными). Если промолчать и не выполнить – лучше сразу увольняться.
Разбирательство с ролями и практиками начальства должно происходить содержательно, психологические (кто что там подумает, на что обидится и т.д.) рассмотрения в порядке лидерства (с кем надо дружить на уровне выше начальника, чтобы чувствовать себя защищённым от психологически мотивированных реакций) обсуждать нужно отдельно и после того, как будет понятно, что же надо делать, почему делать, как сделать правильно и быстро, чтобы не было новичковых ошибок, что произойдёт после того, как будет сделано, кого и как предупреждать о неизбежных последствиях выполнения той или иной практики – всё это вопросы обсуждения практик и ролей, а не вопросы кто главный и кому это выгодно. Но если речь идёт о содержательном обсуждении, то «кому это выгодно» вполне можно обсуждать в терминах ролевых интересов, но не должностей и психологических особенностей занимающих должности людей.
«Начальника» не надо путать с «менеджером», хотя в быту эти слова разве что не взаимозаменяемы. Так 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, RPA[45 - https://en.wikipedia.org/wiki/Robotic_process_automation (https://en.wikipedia.org/wiki/Robotic_process_automation)])
• Интеллектуализация (и тут даже необязательно использование алгоритмов искусственного интеллекта, просто это попытка сказать, что речь идёт не о самых простых алгоритмах, а о машинном обучении, которое может оказаться банальной и простейшей линейной регрессией из первой главы курса статистики).
• … много других имён, маркетинг поставщиков компьютерных технологий для практик менеджмента не дремлет.
Дальше идёт игра словами: пытаются различать «автоматизированные» (что-то делают компьютеры, что-то человек) и автоматические (всё делает компьютер) системы, но это разделение не прижилось. Понятно, что без людей не обходится вообще нигде. Другой вариант игры словами идёт по типу того, что происходит сейчас в сфере AI и роботов – всё, что большинству людей непонятно как автоматизировать, называют AI и «робот», а что уже понятно – «обычные алгоритмы». С менеджментом происходит то же самое: автоматизация практик/процессов, которые понятно стало как автоматизировать – это уже не считают менеджментом, а что осталось непонятным как автоматизировать – это и считают «настоящим менеджментом».
Операционный менеджмент уже весь почти ушёл в алгоритмику и там всё меньше остаётся решений, которые должны принимать люди. Администрирование загрузки конвейера/pipeline (помним, что это термин из DevOps/SRE/internal development platform практик, а не только настоящий заводской конвейер) при его работе оказывается хорошо автоматизируемым навыком, люди нужны только при изменении структуры самого конвейера (ремонтах, замене оборудования, изменении самих операций, которые должны выполняться на конвейере). В операционном менеджменте всё сводится к вычислениям и остаётся только лидерство: объяснение необходимости следовать при загрузке людей и оборудования работами не интуиции, а результатам расчётов (а эти расчёты делает компьютер на базе формул из учебников, причём даже не учебников менеджмента). Смогли уболтать людей верить контринтуитивным результатам бездушных расчётов – получите на сегодня даже не конкурентное преимущество (конкурентным преимуществом это было вчера, а сегодня это как гигиена, «все так давно делают»), а отсутствие ошибок в загрузке оборудования, небольшой запас прочности.
«Архитектура предприятия» тоже во многом уходит к архитекторам, но дальше можно придётся обсуждать – это архитекторы предприятия или архитекторы корпоративного софта, так как в силу той самой цифровой трансформации эти две роли стремительно сливаются в одну. Взаимосвязь архитектуры предприятия и архитектуры софта будет подробней рассмотрено в курсе дальше, хотя в «Системной инженерии» было уже дано достаточно литературы, чтобы это заметить. Современные фирмы склеиваются из своих частей оргзвеньев-модулей не столько людьми, сколько корпоративным софтом. Этот софт даёт «один источник правды»/one source of truth (расхожий термин управления конфигурацией) и одни и те же объекты внимания (организационная собранность) и понятные каналы коммуникации между максимально автономными модулями-оргзвеньями. В курсе «Собранность» ШСМ об этом понятийно наведённом коллективном внимании рассказывается подробно.
Остаётся стратегирование: визионерство (по отношению к целевой системе и потенциальной клиентуре) и бизнес (по отношению к организации и потенциальной инвестуре). Некоторые не относят их к менеджменту, но если речь идёт о системе предприятия, мы будем относить это тоже к менеджменту как части инженерии. И ещё есть собственно «организовывание» (organizational change management, оргизменения, практика развития предприятия). Это да: что менять, на что менять и как менять (а менять нужно постоянно) – это плохо алгоритмизируется.
Но всякий присмотр за людьми-роботами (типа «кто там матом из сейлзов ругался на наших клиентов?») плюс попытки автоматизировать HR (у наших студентов был хороший пример с роботом HR Yva[46 - Сейчас это часть предложения более продвинутого сервиса https://www.visier.com (https://www.visier.com/), то суть та же: автоматизация решения проблем, связанных с людьми, вроде предсказания «неожиданных» увольнений. И это не единственный такой продукт на рынке, и эта технология реально работает.]
