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

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

• Мета-модель domain ситуационная, как это принято в вашей организации, где термины могут быть совсем не «из учебника», а исторически сложившимся сленгом, изо всего разнообразия практик выбраны какие-то конкретные практики (необязательно SoTA, а уж какие исторически сложились, при этом адаптированные под конкретный подвид систем или особенности систем создания – скажем, не просто жарка картошки, а жарка картошки особых сортов, как в McDonalds). Для краткости можем называть её метаС-модель (Ситуационная).

Предметная область/domain в каждом звене цепочки создания, представленном отдельной зоной интересов своя! Где-то это domain целевой системы, где-то это domain менеджмента, где-то будет domain маркетинга как работы с сообществами, и т. д. Когда у вас не мета-мета-модель, а просто мета-модель с одним «мета» – это уже не «безмасштабно» и «беспредметно» типа «каких угодно систем», а для какого-то масштаба, какой-то предметной области работы с какими-то конкретными типами систем.

Примеры ошибок, которые делают практически все наши студенты, проверьте, что вы их не делаете (тут приведены, конечно, не все ошибки, люди очень изобретательны в ошибках, но вот эти делают практически все новички в системном менеджменте):

• Число звеньев цепочки создания (включая то, что разветвления цепочек создания даже не рассматривается, там ведь дерево, а в общем случае направленный граф из таких цепочек) ровно такое, как на наших картинках. Нет, выше было написано, что там граф, и даже в линейном случае очень часто 5—6 звеньев в такой цепочке. Поэтому нельзя копировать схему из учебника, в ней просто другое число элементов! А почему случай не будет линейным? Например, вы тут не видите организации, которая создаёт клиентуру (команда, выполняющая практику продвижения), а она обычно есть.

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

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

• Обращается внимание не на понятие, а на термин, «совпадение слов», а не совпадение значений – это грубая ошибка. Так, на первом уровне создания «организация», «организация проекта», «предприятие», «инженерная команда», «поток студентов на курсе» – это всё про одно и то же: организованную группу людей.

Теперь надо показать, как оргпроект (создание организации какого-то звена в цепочке создания, плавно переходящее в бесконечное развитие этой организации – мы будем называть это «проектом оргразвития», с акцентом не столько на момент создания, сколько на момент continuous delivery новых оргвозможностей/capabilities и фич в этих оргвозможностях) раскладывается на вышеописанные роли из «Системной инженерии». Различаем при этом время развития организации/«организационных изменений»/«change management» (не путаем «organizational change management»/«управление организационными изменениями»/организовывание с «configuration and change management» из инженерии целевой системы) и время работы/функционирования/operations организации/оргзвена/предприятия/проекта (тут мы показываем эти термины как синонимы: организации/оргзвена/предприятия/проекта, но в реальности за ними могут скрываться разные сущности, будьте внимательны).

Итак, менеджмент как инженерия предприятия включает в себя следующие практики и роли:

• Организатор (аналог developer в системной инженерии) выполняет организовывание. Он предлагает концепцию использования организации (зачем её делать, каких изменений в мире ожидать, какие оргизменения нужно сделать, какие практики нужно освоить организации как development и затем превратить их в оргвозможности/capability как delivery, чему научиться новому). Предлагает, ибо это «гипотеза», организационная гипотеза/guess. Он затем разрабатывает концепцию организации (как и из чего сделать организацию – с ограничениями от архитектора), затем проектирует (моделеры! Корпоративный софт!) с точностью, достаточной для «изготовления» (конечно, это не заводское изготовление! Потребуются закупки оборудования, найм сотрудников, лидерство и т.д.), будет работать администрация (аналог DevOps/internal development platform engineering), затем введение в эксплуатацию – и всё это непрерывно, цикл непрерывного оргразвития.

• Практику прибыльности осуществляет бизнесмен, ответственный за отношения с инвесторами (IR, investor relations) и надзор за прибыльностью. Так же как визионер/стратег (например, как одна из ролей должности product manager) отслеживает, что клиентура «покупает» целевую систему дороже, чем затрачивается на её изготовление, бизнесмен отслеживает, что инвестура (все владельцы, их часто называют одним словом «инвесторы») «покупает» организацию не дешевле, чем нужно для начала зарабатывания, выхода на break even. Если денег от инвесторов не удалось собрать, то организация никому не нужна, её не будет. При этом инвесторы сами контролируют то, что на эти деньги будет прибыль в рамках corporate governance (это как бы «потребительский надзор», «клиентский контроль за качеством целевой системы» – только этой системой тут будет организация, а «клиентом» будет «инвестор»)! Бизнесмен компании отслеживает обратную ситуацию: чтобы инвестиций хватило для организации нового дела, он должен проверить идею/орггипотезу организатора, которая достаточно убедительна для инвесторов. Отдельно можно обсуждать, как все упомянутые роли разложены по должностям в некоммерческих организациях, в небольших стартапах, в крупных холдингах, государственных/правительственных организациях, и даже командах агентов внутри личности (internal team в практике ролевого мастерства личности, команды из частей личности с интеллектом меньше, чем у полной личности). При этом как визионер сам не осуществляет продвижения (маркетинг, реклама, продажа), а лишь выполняет оценку выгодности производства продукта, сервиса, фичи, так и бизнесмен не сам выполняет практику привлечения инвестиций, но он занимается стратегированием: согласует все идеи о том, как компания может зарабатывать деньги для инвесторов. И если эти идеи будут убедительными, то как «в основе хорошей рекламы лежит хороший товар», то и тут «в основе хорошего привлечения инвестиций лежит прибыльная фирма». Вот бизнесмен и озабочен этой прибыльностью.

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