Четвёртый день "Системного менеджмента и стратегирования", двадцать пятый поток

Почти весь день обсуждали одинаковость рассуждений про практики и роли по отношению к целевой системе, системе создания целевой и системе развития системы создания целевой. Трудности были с тем, что в фирме создавать нужно минимально четыре системы (в скобках -- кто создаёт): целевую (инженеры целевой), клиентуру (продвиженцы -- вот эту систему вспомнили с трудом, а ведь без её создания фирма не живёт!), создания целевой и клиентуры как собственно предприятия (менеджеры/оргразвитие), оргразвития (например, основатели или консультанты). Мало кто понимает особенности структуры кейса. В первом звене цепочки создания предмет кейса -- это рабочий продукт, и он относится к целевой системе, а вот работа -- это уже про систему создания. Сам кейс::работа. Поэтому рабочим продуктом занимаются инженеры, а работами -- менеджеры. И тут тонкости: если кладём кейс в бэклог, то какого типа там объект в бэклоге? Работа по пока неизвестной даже практике, или рабочий продукт? В учебнике говорится, что пятое обязательное системное описание наиболее вероятно -- это WBS. И в бэклоге вроде как работы, там ведь кейсы. И архитектурный должок (целевой архитектурный как "технический долг" и оргархитектурный) -- это работы. И стоят деньги работы, для которых нужно предусмотреть ресурсы, поэтому появляется прямой разговор архитектора с менеджерами по поводу ресурсов. И это всё переводит вопрос о кейсах::работы в разговор про операционный менеджмент. А вот дальше вопрос про то, где лежат предметы кейса, в какой системе моделирования того, что будет результатом работ. И потом обсуждается, что из многочисленных альтернатив выбирается вот такой результат (trade-off studies/прохождение развилки) и затем планируется работа вот такая-то, дело из инженерного (продукт, который станет предметом кейса) становится кейсом (работой). И в учебнике же указано, что надо проверять: что у каждого нужного продукта по нему есть работа, а каждая работа делается с нужным продуктом. Вот тут выяснилось, что "в жизни" большие пропущенные куски, которые ведут к проблемам в общении с менеджерами или инженерами: нет контроля того самого стыка, развал конфигурации. А ещё пообсуждали сложную должность CTO, на которую навешаны самые разные роли, в том числе отслеживание обратного манёвра Конвея, а также стыковка концепции системы и концепции организации. Ещё было удивление, что жизненный цикл -- это что практики, что работы создающей системы, как ни описывай, это не описание изменения состояний целевой системы (гусеница-куколка-бабочка), ибо у нас же техноэволюция и техногусеница не сама в технокуколку превращается своими работами. Кто-то её должен превратить, и "жизненный цикл" -- это отсылка к поведению этого кого-то, а не самой куколки. В учебнике вроде бы это явно говорится, но нет. Похоже, надо этот материал по техноэволюции как-то более развёрнуто излагать. Основная особенность техноэволюции -- что мемом (а не мемотип! геном физичен, это сами хромосомы, "совокупность наследственного материала", генотип -- это описание, тип. С мемомом то же самое, мемом физичен -- база данных с мемами, а хоть и мозг с мемами, а мемотип -- это перечисление мемов, информация) вынесен за пределы целевой системы. Из интересного -- так это сразу двое в группе заметили чёткий стык материала по австрийской школе экономики и статей по термодинамическому рассмотрению эволюции. И ещё отметили, что доверия к рассказываемому существенно возросло после знакомства с материалом по физичность эволюции: стало понятней про неустроенности от конфликтов системных уровней, их неизбежность, многоуровневость оптимизации и невозможность достижения оптимума. Но удивительно: статьи эти цитировались в "Практическом системном мышлении", "Методологии", "Системной инженерии", и теперь "Системном менеджменте". Прочтены ("по диагонали", как признались студенты) только в ходе изучения "Системного менеджмента". Интересно пообсуждали "схемы" и людей из compliance как "перчатку на руке господней" (какой-нибудь технадзор на предприятии, или юрист: он представитель полиции внутри компании, да ещё и на зарплате компании, или сотрудник компании? Как общается со службами компании: требует исполнять нормативы под страхом шрафов, или изобретает "схемы"? Вопрос сложный: для каждой ситуации решается этическая задача -- находим природу норматива, и дальше или менторинг с объяснением работникам, почему этот норматив нужно выполнять, или изобретение "схемы", позволяющей отчитаться, но норматив по сути не выполнять, ибо "бешеный принтер" законодателей напечатал очередную ахинею, и исполнять её не то что не нужно, но определённо вредно. То есть представители compliance основное время думают и изобретают "схемы", а не тупо проверяют исполнение пришедших извне норм. Было много и всякого другого, всё-таки просидели с 11:30 до 19:30 (при этом один перерыв я таки пропустил -- не прерывать же интересный разговор). Заодно обсудили и то, чем материалы для этой группы отличаются от материалов предыдущих групп: -- ввели обязательные (SoTA, нормативная системная инженерия) практики и соответствующие им роли. -- более детальное обсуждение цепочки создания (ибо понятно, как именно обсуждать, какие практики и роли) -- меньше путаницы с "предпринимательством" (слово табуировано, порождение идеи продукта как концепции использования и идеи реализации как концепции системы вынесено разработчикам целевой, оценка рынка продвиженцам как разработчикам клиентуры, но есть роли визионера, бизнесмена и стратегирование как договаривание всех по поводу того, чем заняться) -- безмасштабность менеджмента (регулярно касаемся "менеджмента себя") Примерный план на остаток курса выглядит следующим образом: -- день пятый: стратегирование, операционный и финансовый менеджмент -- день шестой: оргразвитие/оргизменения (оргдизайн и лидерство) -- день седьмой: архитектура организации и администрирование UPDATE: комментарии в фейсбуке -- https://www.facebook.com/ailevenchuk/posts/pfbid0WcpDrXXECjGE1tXuqdhPFr5sMHnfg3a6vgybdM6KCfZgEHFp3nhyhfGBs2ETUzwql