Анатолий Левенчук – Системный менеджмент – 2023 (страница 12)

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

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

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

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

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

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

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

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

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