Системное мышление 2019 Левенчук Анатолий
Чтобы определить использующую систему, в состав которой (в момент эксплуатации) входят смарт-часы, придётся рассмотреть западную христианскую традицию отношения людей к собственности. Люди-как-бессмертная-душа считаются владеющими собственным телом, которое при этом рассматривается не столько как человек, сколько как просто носитель его личности, его вещь. Человек владеет своим телом, это его собственность, он принадлежит сам себе. Это свойство людей называют обычно самопринадлежностью. Собственные вещи человека считаются просто продолжением его тела. Никто не может взять тело человека или повредить его, но никто не может взять и его рубашку, часы – они считаются входящими в состав человека, буквально (отношение is_part_of). Это и есть «священная частная собственность».
Тем самым мы с некоторой условностью можем считать использующей системой для смарт-часов самого владельца этих часов: часы будем считать буквально входящими в состав тела его владельца. Для многих личных предметов и инструментов это подтверждается и психологическими экспериментами: люди относятся к ним буквально как к продолжению их тела89, «экзотелу».
Ещё одна интересная использующая система этого класса, включающая людей – это домашнее хозяйство (household), которое может включать и самих владельцев, и дом, и домашнюю утварь.
В подобного сорта системах входящие в них люди одновременно и являются стейкхолдерами, и представляют из себя «просто тело», с которым мы работаем ровно как и с другими материалами, т.е. просто учитывая его физические свойства – размеры, влажность, прочность и т. п.
В примере со смарт-часами использующая система – лично пользователь этих часов, но не пользователь как стейкхолдер, а больше принадлежащее ему тело со всем на него надетым: рубашкой, туфлями, часами! Использование в «использующей системе» – это «использование проектировщиком или конструктором целевой системы как части в составе объемлющей/использующей системы», то есть в составе одетого тела. И, конечно, пользователь как пользующийся часами будет находиться в системном окружении часов!
Потребности пользователя как внешнего стейкхолдера – он должен быть информирован о времени, но этот список потребностей по большому счёту остаётся открытым. Функция часов весьма сложна в формулировании, ибо речь идёт о многофункциональном гаджете. Требования поэтому будут относиться не столько к самим часам, сколько к самым разным предполагаемым вариантам их эксплуатации – это могут быть как собственно часы, так и радио, плеер, измеритель пульса, от смарт-часов ожидается, что они не натирают руку (рука как часть использующей системы-тела находится в операционном окружении смарт-часов!), они должны быть модной на момент продажи расцветки, работать без подзарядки не менее 20 часов, вес должен быть не более 50 грамм, с ними должен работать магазин приложений, у них должна быть связь с внешним компьютером (смартфоном, планшетом, десктопом).
Системы в операционном окружении – рука, одежда (как минимум, рукав рубашки или пиджака), зарядное устройство. Подсистема – защитное стекло из Gorilla glass.
Обеспечивающие системы смарт-часов: конструкторское бюро, завод в Китае, магазин по их продаже. И вот если взять магазин как одну из обеспечивающих систем и рассмотреть стейкхолдера-продавца, то про смарт-часы можно узнать много нового. Потребность продавца – это продажи на какую-то немаленькую сумму, что легко переводится в требование удобной упаковки для складской обработки, красочной упаковки и буклетов для выкладывания в торговом зале, а также хорошей рекламы (то есть услуга рекламы рассматривается магазином как часть продукта – без какого-то уровня рекламы хороший магазин может просто эти часы не взять в продажу).
Это очень важно – рассматривать стейкхолдеров, чтобы определить границы целевой системы. Уже понятно, что в состав целевой системы входят и упаковка, и рекламные буклеты и даже транслируемая по каким-то каналам реклама. Можно считать, что магазин приложений находится в системном окружении часов, но вот с упаковкой так считать уже не получится.
Современная инженерия часто имеет дело с киберфизическими системами (cyber-physical systems), которые имеют в своём составе датчики (sensors), воздействующие на внешний физический мир исполнительные устройства (actuators: чаще всего разные моторы, но это могут быть и осветительные приборы, электрические выключатели) и компьютер (cyber-, кибер-, управляющую часть), который обеспечивает управление работой всей системы. Примером такой системы может быть дрон для аэрофотосъемки.
Использующая система – строительство. Один из внешних стейкхолдеров – это заказчик-застройщик, потребность которого – подконтрольность строительства. Функция дрона тем самым – делать фотографии высокого разрешения строительства с интересных заказчику-застройщику ракурсов. Требования: полётное время не менее 1 часа, изображение разрешением не менее 11 Мпикселей, зарядка между полётами не более 1 часа. Подсистема – фотокамера. Системы в операционном окружении: зарядка, стройка с её зданиями, сооружениями и оборудованием (краны), в воздухе они могут рассматриваться как препятствия (например, трос от крана).
Обеспечивающие системы дрона – конструкторское бюро, завод-изготовитель, магазин, ремонтная мастерская, эксплуатационная служба с оператором дрона.
Системы систем
Иногда холон-система, который состоит из других холонов-систем называют «системой систем». Это неправильно, это просто система – не нужно специально подчёркивать тот факт, что любая система состоит из систем. Тем не менее, термин система систем (system of systems, SoS) есть и он закреплён за особым случаем выделения систем по их социальным характеристикам, а не по чисто техническим. Системой систем называют такую систему, которая (критерии Maier90):
• Имеет независимое управление её систем-элементов (нет, кому скомандовать и профинансировать общее развитие-модернизацию)
• Независимая работа элементов (нет, кому скомандовать работу в общем сервисе этой системы систем)
• Эмерджентность/системный эффект от объединения в систему (кто-то желает получить от целевой системы систем функцию, которую невозможно получить от работы с отдельными входящими в систему систем элементами, и требуется совместная работа этих элементов).
• Эволюционное развитие (понимание того, что будет происходить в системе систем на каждом следующем шаге проекта требует исследований, ибо нет стейкхолдера, который знает как в каждый момент устроена система систем и может обеспечить команду проекта по изменению системы этим знанием)
• Географическое распределение элементов
Эти критерии различаются, конечно, в разных инженерных и менеджерских школах, но общее остаётся: обычные «системы» подразумевают централизованное «владение» системой – наличие стейкхолдеров, полномочных принимать решения по всем частям системы, полномочных распоряжаться всем, что в границах их системы. Это традиционный случай: автомобиль с двигателем и колёсами, железнодорожный мост и компьютер – это типичные «просто системы», у них есть свои системные инженеры, которые полностью определяют их функции, конструкцию, интерфейсы с системами в операционном окружении, планы по модернизации и выводу из эксплуатации. У каждой из этих систем есть один хозяин, один владелец.
А вот в системе систем каждая из систем имеет своего хозяина, и система может функционировать автономно, без вхождения в систему систем. Тем самым разница между «просто системой» и «системой систем» определяется не через особую структуру или конструкцию системы, а через наличие независимых друг от друга стейкхолдеров, определяющих и создающих системы, а затем независимо использующих их.
В системе систем важны прежде всего владеющие частями-системами люди-стейкхолдеры, именно они делают систему систем особым случаем.
В ISO 15288:2015 выделено четыре типа систем систем, отличающихся степенью их автономности:
• управляемые (directed), в которых есть назначенный архитектор, который может выдавать приказы командам проектов составляющих систем и распоряжается общими ресурсами.
• подтвержденные (acknowledged), в которых признаваемый архитектор есть, но он может только уговаривать составляющие системы самоизмениться согласно разработанной им архитектуре.
• сотрудничающие (collaborative), в которых все системы договариваются друг с другом по каждому чиху, но архитектора, менеджера проекта или аналогичного выделенного органа управления нет.
• виртуальные (virtual), в которых системы вообще не знают друг о друге ничего и не влияют друг на друга явно.
Был выведен основной способ работы с системами систем: совместная постепенная асинхронная эволюция (модернизация) входящих в систему систем автономных систем – ибо согласованность и синхронность изменений в этих автономных системах крайне сложно обеспечить: даты утверждения проектов модернизации будут различаться, получаемое на модернизацию финансирование будет выделяться в разные моменты и нельзя будет гарантировать его достаточность, некому будет вести общий проект реформирования как инженерно, так и менеджерски, не говоря уже об общем целеполагании (технологическое предпринимательство). Хозяева автономных систем могут иметь разные мнения по поводу взаимодействия их систем с другими автономными системами в составе системы систем, они могут сопротивляться переменам, ибо их вполне может удовлетворять и автономная работа их систем в их использующих системах, а желание какого-то даже влиятельного стейкхолдера системы систем об объединении автономных систем в общую систему систем они могут не разделять.
Для работы с системами систем тем самым необходимо лидерство, опирающееся на гуманитарные дисциплины социологии, политологии, психологии, конфликтологии и т. п. – стейкхолдеры автономных систем должны занять позиции стейкхолдеров команды проекта системы систем.
Люди в системах
Человек в составе систем учитывается сложно, ибо он одновременно может быть и целевой системой («продуктом»), и «оборудованием» в составе обеспечивающей системы, и служить использующей системой, но всегда при этом человек остаётся стейкхолдером: мы можем не учитывать мнений и интересов животных (хотя и это плохо), но мы принципиально не можем не учитывать мнений людей.
В случае же, если это не один человек, а их несколько, всё становится ещё сложней: люди могут договариваться друг с другом по самым неожиданным поводам и предпринимать в этой связи самые неожиданные для команды проекта действия.
Один из простейших примеров системы с входящими в её состав людьми – это танец. В танце люди выступают и как материал, и как стейкхолдеры (в разных танцах они бывают самые разные), танец является при этом процессом, но при этом танец не обладает сложностью предприятия и тем самым не требует рассмотрения сложных вопросов корпоративного управления, стратегирования, операционного менеджмента/управления работами. Это отличный пример, на котором можно тренировать своё системное мышление91.
Мероприятия так же являются классическим примером систем с людьми. Менеджмент мероприятий (event management92) даже стал университетской дисциплиной – сделать (задумать, спроектировать, изготовить, проэксплуатировать и затем вывести из эксплуатации) концерт или фестиваль трудно, но ничего необычного в этом уже нет, рассмотреть тысячи людей в составе системы-мероприятия вполне возможно.
Домашнее хозяйство, где есть дом с утварью и его жильцы, уже рассмотренный случай потребителя одежды и гаджетов – это всё примеры систем с людьми.
Сложнейшими системами с людьми являются обеспечивающие системы – предприятия, рабочие группы проекта, расширенные предприятия (extended enterprise), предприятие с его контракторами, занимающееся какой-то большой целевой системой (например, самолётом или автомобилем). Мы будем называть такие системы предпринятиями (endeavor, предприНятие), чтобы в число этих систем попали не только предприятия-юридические лица, но и другие виды организаций, которые что-то предпринимают.
Главное, что нужно понимать – что системы с людьми по определению являются системами систем в силу того, что люди обладают свойством самопринадлежности. И это означает, что с этими системами систем нельзя работать простыми инженерными методами, в которых можно сконструировать простую механическую или механическую с элементами электроники систему, изготовить её части и собрать их в работоспособное целое.
Нет, метафора часовщика с изготовлением деталей и их сборкой не работает, с людьми (как и любыми другими живыми системами) больше работают «сельскохозяйственные» метафоры садовника (который имеет контроль над тем, что выращивает) и в больших системах систем с людьми лесника (который не имеет контроля над своим лесом – где какое дерево или кустик вырастет, но тем не менее достаточно влияния, чтобы предотвратить какие-то серьёзные негативные события: может предотвратить пожар, подкормить зимой животных, отогнать браконьеров).
В особо крупных системах (большое сообщество, общество в масштабах государства, всё человечество) говорят уже не просто о сложности системы, а сложностности или даже сложносистемном мышлении93, что не позволяет как-то строить действия с предсказуемым результатом.
Государственное строительство и госпроекты
Если ребёнку в руки попадает молоток, то все предметы в доме превращаются в гвозди – и это означает, что не ребёнок владеет инструментом, а инструмент владеет ребёнком. Если системный инженер или менеджер встречается с госстроительством, то он непременно хочет им заняться (ибо это обычно прибыльно: деньги ведь на проект собирают со многих, а отдают ему одному, поэтому почему бы и не заняться?). Если госстроитель (политик) знакомится с системным подходом, системной инженерией или менеджментом, то он непременно захочет их использовать. Системную инженерию в её классическом виде для целей госстроительства использовать нельзя, она предназначена прежде всего для кибер-физико-человеческих систем совсем небольших масштабов – в которых чётко определены стейкхолдеры, занимающимися какой-то «традиционной» аппаратной или даже программно-аппаратной системой.
В госстроительстве имеют дело главным образом с системами из людей, игнорируют кибер-составляющую (которой становится всё больше и больше в связи с распространением интернета, и появлением интернета вещей), и совсем не имеют дела с физическими («железными») системами, с которыми системная инженерия справляется лучше всего. Краткий тут совет – если уж нужно заняться госстроительством, то используйте знания по политологии, конфликтологии, праву, экономике, социологии и системное мышление в его «мягких» вариантах, но не используйте системную инженерию, от неё будет только хуже. Государство и люди в нём – это не отсеки подводной лодки, это не детали медицинской аппаратуры, это даже не атомная электростанция вместе с её персоналом.
У проекта системной инженерии всегда есть вполне определённые стейкхолдеры, которые платят за этот проект: заказчики. Кто заказчик в госстроительстве? Политики? Чиновники? «Народ» (например, опрос общественного мнения или фокус-группа)? «Элита» (и кто её определяет)? Группы экспертов (вариант «экспертократии» – но как выбрать из этих групп «правильную», все эксперты ведь говорят разное)? Нужно чётко понимать, что в случае госстроительства речь идёт о политике, а не о классических стейкхолдерах системноинженерного проекта. Не нужно себя обманывать, говоря, что «есть заказ, оплачивается он из бюджета, следовательно заказчиком является тот чиновник, который будет подписывать мне акт приёмки работ». Госстроительство – это прежде всего политика, в политике подобные рассуждения неприемлемы. Что для одного политического стейкхолдера успех, для другого будет полным провалом, и наоборот, и таких стейкхолдеров столько, сколько разных политических групп. Поэтому государственные проекты будут неуспешными по определению: в них никогда не будут учтены интересы всех стейкхолдеров, эти интересы нельзя будет определить честно и справедливо (напомним, что по определению системной инженерии успешная система – это которая учитывает интересы всех своих стейкхолдеров).
Конечно, формально для госпроекта может быть и подписанный какими-то стейкхолдерами паспорт проекта, и даже отчёт о его реализации, «успешной» с точки зрения именно этих стейкхолдеров, но никаких других. Одни стейкхолдеры будут что-то подписывать в бумагах по паспорту проекта, а другие стейкхолдеры будут делать пикеты ровно на эту же тему, писать статьи в газетах и разными другими способами пытаться выразить своё недовольство – в системной инженерии и системном менеджменте игнорировать их считается не лучшей практикой, такой проект нельзя будет считать успешным. Когда у кого-то берут деньги в виде налогов, а потом тратят на чей-то проект, с самим фактом наличия которого налогоплательщик не согласен – это оно и есть, неучёт мнения главнейшего стейкхолдера. Главный стейкхолдер это «народ», желающих что-то сказать в строчке бюджета и в паспорте проекта, а также от его имени расписаться в отчёте очень много. Для этого политиками и чиновниками много говорится о субсидиарности, партисипативности, сдержках и противовесах, но факт остаётся фактом: по гамбургскому счёту успешных проектов в государстве нет – мнение об успешности всегда является частным мнением какой-то группы людей, другие группы людей могут быть недовольны. Но поскольку на стороне властей сила полиции и деньги налогов этих же недовольных, они ничего сделать не смогут. Это всё политика, это не менеджмент, не проектное управление, не инженерия.
Строить государство и организовывать госпроекты вы будете не из своего материала, а всегда из чужого: из других людей. Но люди – это не железо, и не компьютеры. Не считайте, что именно вы из них что-то построите удачное для вас или них самих, и не считайте, что вы как системный мыслитель (системный менеджер, или инженер, или даже просто программист, или сапожник, или деятель культуры) квалифицированы что-то строить из людей. Эти люди, эти самопринадлежные системы, из которых вы будете пытаться строить системы систем, не ваши материалы для строительства, и они не материалы ваших заказчиков-чиновников, заказчиков-политиков. Они самопринадлежны, они все свои собственные. И они так же точно могут хотеть что-то построить из вас – в том числе и то, что вам не понравится. Золотое правило работает и тут: не делайте с людьми того, чего не хотели бы, чтобы делали с вами.
Инженер по безопасности может защищать систему от врагов (антиклиентов). Инженер-госстроитель не может быть инженером по безопасности, разве что он строит тюрьму. Разработчики государственного регулирования все строят тюрьму, им платят именно за это, никто никогда не платит за дерегулирование94. Задумайтесь над этим перед тем, как построить очередной блок государства, который дальше получит властные полномочия и употребит их для того, чтобы разрастись и получить ещё больше власти.
Нельзя также считать, что можно получить помощь от государства в развитии системного мышления, системного менеджмента, системной инженерии, системной биологии и других системных дисциплин (часто об этом говорят, как о «промышленной политике»). Чиновники ничего не понимают в этих сферах деятельности. Даже если они выделят деньги на развитие каких-либо практик из этих сфер, или создание курсов – вовсе не факт, что это будут конкурентоспособные практики, конкурентоспособные курсы. Пусть проблемы инженеров и менеджеров решает рынок, дело чиновников – не вмешиваться в решения рынка (не поддерживать рыночно слабых и давать им разоряться, не тормозить рыночно сильных и давать им заработать, и не путать рыночно сильных и слабых с административно сильными и слабыми – то есть умеющих расположить к себе инвесторов и клиентов с умеющими расположить к себе чиновников).
Нужно также очень осторожно относиться к примерам системной инженерии из военных проектов (и проектов из других областей, которые полностью зарегулированы государством – например, проектов атомной энергетики). Поскольку в этих отраслях принят Принцип оплаты из бюджета «затраты плюс» (затраты, реально понесённые в ходе проекта, плюс оговорённый небольшой процент прибыли), то только полные идиоты не будут потихоньку год от года повышать стоимость проектов и сроки их выполнения, повышая тем самым и процент прибыли. Посмотрите на гражданскую технику, её стоимость, рост технических характеристик, сроки разработки за последние двадцать лет (возьмите хоть те же смартфоны: двадцать лет назад даже сотовых телефонов толком не было, не говоря уже о смартфонах) и сравните с военной техникой – сроками и стоимостями разработки. Разница будет разительна. Поэтому нужно признавать, что в военной системной инженерии есть множество интересных методологических находок, но слепо копировать этот опыт нельзя: вполне возможно, что вы откопируете заодно и прилично выглядящие способы повышения стоимости и удлинения разработки. На свободном рынке фирмы с такими методологиями бы не выжили, но на военных якобы рынках действуют совсем другие закономерности. И конечно, каждый системный инженер решает для себя сам: хочет ли он проектировать и строить машины для убийства (именно этим занимается военная системная инженерия).
Всё то же самое верно и для системного менеджмента: военный менеджмент явно не является образцом того, как должен быть устроен менеджмент в гражданском мире, хотя многие начальники и хотели бы, чтобы их подчинённые ходили строем.
Будущее
Системное мышление даёт возможность понять, как думать о будущем.
Будущее физично – это просто весь мир как 4D индивид, только интересует его временной срез не прямо сейчас, а через некоторое время.
Будущее – это полная темпоральная часть мира в будущем времени. Конечно, в будущем каждому интересно что-то своё, будущее определяется не объективно, а субъективно. Поэтому для каждого человека неинтересно всё будущее в целом, а интересно только то, что обычно интересно тем стейкхолдерским ролям, которые люди играют в своей жизни.
Будущее представляется людям как использующая система для множества использующих систем, для которых эти люди-стейкхолдеры будут делать свои целевые системы.
Что будут люди делать в будущем? Это описывается требованиями.
В каких системах это будет использоваться? Это описывается потребностями.
Мы узнаём будущее по описаниям его целевых и использующих систем – по требованиям и потребностям. «Будущеведение» тем самым – инженерия требований.
Предприниматели зарабатывают на том, что могут предвидеть будущее. Тем самым ведущая дисциплина предпринимательства – это инженерия требований (requirements engineering), которая занимается выявлением потребностей (stakeholder needs/requirements) и требований (system requirements).
Общность мышления по мере усложнения систем
В июне 2014 года INCOSE (International Council on Systems Engineering, Международный совет по системной инженерии95 выпустила публичный документ System Engineering Vision 202596, в котором описала в том числе и рейтинг систем по их сложности для инженерии.
Самые простые системы – это системы с механическими и электрическими элементами (mechanical and electrical elements), вроде велосипеда, насоса или холодильника. Более сложные – это в которых можно найти электронику, и контроллеры с программным обеспечением, управляющие логикой работы каких-то элементов системы (electronic, isolated islands of software), например, стиральная машина или современный автомобиль с двигателем внутреннего сгорания. Но вот уже реактивный самолёт или космический корабль с трудом попадает в эту категорию: логика их работы уже полностью определяется программным обеспечением, поэтому такие системы называют программоёмкими (software-intensive). Это граница применения классической инженерии, все учебники системной инженерии, все стандарты по факту описывают практики создания именно таких систем.
Но человечество не останавливается на создании только таких систем, для которых есть хорошо разработанные методологии. Нет, есть и более сложные системы, и относительно новый класс таких систем – это сетеёмкие (network-intensive). Сеть – это обычно какой-то набор узлов и связей между узлами, и поток чего-то по этим узлам. По сети интернет бегут потоки данных, по водопроводной сети – вода, по сети датчиков – данные. Сетеёмкие системы сложнее программоёмких, потому как обычно для сложных сетей в каждом конкретном месте сети неизвестны все остальные узлы, и неизвестны все связи. Более того, каждый момент времени ситуация может меняться, поэтому программы управления потоками для такой сети должны учитывать эти изменения. Это крайне сложно делать: сеть по факту имеет меняющуюся на ходу структуру, и её нельзя спроектировать и реализовать, для неё можно только сформулировать общие Принципы, определить структуру узлов и виды связей – и дальше опять мы оказываемся в мире сложностности с сельскохозяйственными метафорами садовника и лесника. Сетеёмкие системы сегодня – фронтир системной инженерии.
Ещё более сложные системы – это предпринятия, т.е. предприятия и другие системы с организационным надзором, в том числе децентрализованным (enterprise, organizational governance (decentralized)). Governance рекомендуем переводить как «поднадзорность», а не «управление»: governance означает, что подназорный субъект не выскальзывает из-под надзора, а продолжает выполнять свои обязательства исполнять поручения полномочного менеджера предпринятия. Созданием таких организационных систем занимаются не системные инженеры, а инженеры предприятий (которые, впрочем, с удовольствием пользуются учебниками и стандартами системного подхода и системной инженерии, равно как и менеджерскими учебниками, стандартами и публичными документами). В состав этих систем входят люди, поэтому в силу самопринадлежности людей предпринятия мы сразу говорим о нём как о системе систем. Но на этом уровне хотя бы есть поднадзорность/governance, то есть существуют стейкхолдеры, полномочные выдавать общие распоряжения по использованию ресурсов.
Самый сложный вид систем – это системы систем. С ними не может быть гарантии, что они все по степени автономности управляемые, как на предыдущем уровне предпринятия (где известны полномочия людей по распоряжению ресурсами организации). Нет, тут могут быть и подтверждённые, и сотрудничающие, и виртуальные системы систем. Инженерия систем систем сейчас бурно развивается, хотя в ней нельзя указать каких-то надёжно работающих методов. То же самое относится к построению всевозможных бизнес-эко-систем97. Это пока больше искусство.
А ещё в этой классификации присутствуют только инженерные системы, которые делают люди. Тут не указаны природные системы, которые могут быть сложными или простыми в зависимости от того, какие функции от них ожидают стейкхолдеры и что они хотят сделать с этими природными системами, включая их в состав своих систем, используя их как разработчики в ходе проектирования и изготовления, или даже используя их как пользователи в ходе эксплуатации. Интуитивно понятно, что сложность биологических систем очень и очень высока. Недаром системный подход как способ мыслительной работы со сложностью сначала использовался главным образом для разбирательства с биологическими и природными системами.
Сложность и меры сложности
Понятие сложности интенсивно разрабатывалось не только в рамках системных исследований (т.е. исследований по развитию системного подхода), но и во многих других дисциплинах. Окончательного согласия по тому, что такое сложность нет, и не предвидится. Так, Seth Lloyd собрал различные определения для мер сложности98. Все эти определения он отнёс к попыткам ответа на три вопроса:
1. Как трудно описать систему? Обычно это измеряется в битах, затрачиваемых на представление описания. Мерами сложности тут будут информация, энтропия, алгоритмическая сложность или алгоритмическое содержание информации, максимальная длина описания, информация Фишера (Fisher), энтропия Рени (Rnyi), длина кода (беспрефиксного, Хаффмана, Шэннона-Фано, корректирующего ошибки, Хамминга), информация Чернова, размерность, фрактальная размерность, сложность Lempel-Ziv.
2. Как трудно создать систему? Сложность как трудность создания измеряется во времени, энергии, долларах и т. д. Меры сложности тут вычислительная сложность, временная вычислительная сложность, пространственная вычислительная сложность, основанная на информации сложност, логическая глубина (depth), термодинамическая глубина, цена, шифрованность (crypticity).
3. Какая степень организованности? Тут может быть два варианта:
а) «результирующая сложность» (effective complexity), трудность описания организационной структуры, неважно корпоративной, химической, клеточной. Приведём их по-английски: Metric Entropy; Fractal Dimension; Excess Entropy; Stochastic Complexity; Sophistication; Effective Measure Complexity; True Measure Complexity; Topological epsilon-machine size; Conditional Information; Conditional Algorithmic Information Content; Schema length; Ideal Complexity; Hierarchical Complexity; Tree subgraph diversity; Homogeneous Complexity; Grammatical Complexity.
б) количество информации, которой нужно обмениваться между частями системы из-за такой организационной структуры: Algorithmic Mutual Information; Channel Capacity; Correlation; Stored Information; Organization.
Есть и понятия, которые не являются понятиями сложности, но очень близки: Long – Range Order; Self – Organization; Complex Adaptive Systems; Edge of Chaos. Есть и совсем альтернативные меры сложности (например, основанные на скорости описания оцениваемых объектов, а не объёме этого описания99).
Ситуация с понятием «сложность» очень характерна для системного подхода: употребляемые в нём слова кажутся вполне «бытовыми» и имеющими ясные и интуитивно понятные с детства значения. Но нет, слова эти вдруг оказываются терминами, за которыми скрываются очень сложные и противоречивые понятия, с этими понятиями работают самые разные логические или количественные модели, проводятся количественные измерения самых разных их характеристик.
В рамках настоящей книги мы будем считать сложной систему из достаточно большого количества элементов, настолько большого, чтобы в одной голове не получалось оценить все связи и взаимодействия. Если в системе пятьсот человек, этого вполне достаточно, чтобы в одной голове не получилось оценить все связи и взаимодействия этих людей. Это сложная система. В одной голове так же трудно удержать все связи и взаимодействия в системе смартфона, в системе атомной электростанции, многих других инженерных системах. Для наших целей обучения системному мышлению такого неформального понимания сложности вполне достаточно, но вы должны помнить, что кроме этого неформального понимания есть и другие, формальные понимания сложности, есть множество теорий сложности, из которых пришли эти формальные понимания.
Системное мышление не даёт никаких «объективных ответов» на вопросы о системах. Эти ответы всегда зависят от того, какой стейкхолдер спрашивает, и какой стейкхолдер даёт ответ. В системном мышлении нет никакого алгоритма, приводящего к правильному ответу, нет последовательности шагов, гарантирующих какой-то приемлемый результат этого мышления. Системное мышление сложно, его долго осваивать – этим оно напоминает какую-то «необъективную высшую математику». Системное мышление даже не трудится давать точные определения своим понятиям: разные стейкхолдеры норовят приспособить эти понятия для своих самых разных потребностей. Но понятия системного мышления позволяют компактно и просто описывать сложный мир!
4. Целевая и использующая система
Сначала найти целевую систему
Первое, что нужно делать в системном мышлении – это не думать о всех системах сразу, а сначала определить ту главную систему, которую вы хотите сделать, или изменить, или эксплуатировать, или уничтожить. Сначала нужно найти целевую систему (system-of-interest). Это очень непросто, а ошибки часты и дорогостоящи. Если нет беглости в системном мышлении, то вы будете определять целевую систему неправильно, а если вы её определите неправильно, то вы просто будете заниматься не тем, чем надо, будете зря тратить время: фокус вашего внимания будет не на важном, а «рядом с важным» или даже «далеко от важного». (фото100)
Целевая система в системном мышлении – это как начало координат в ментальных «полярных координатах». Все остальные решения по поводу выделения других систем – использующей, систем в операционном окружении, подсистем, обеспечивающей системы – делаются по отношению к целевой системе.
Целевая система определяется субъективно, «система в глазах смотрящего», поэтому вопрос определения «системы, которую вы хотите сделать» начинается с внимания к тому, кто такие «вы»: сколько вас, какие у вас интересы.
Системное мышление – это мышление коллективной/групповой деятельности, оно позволяет большим командам договариваться в проектах с миллионами индивидуальных деталей в целевых системах, удерживая внимание разных людей на их общем важном, чтобы без потери этого внимания к системному целому позволить заботиться о деталях подсистем отдельным членам каждой команды.
Для выявления целевой системы нет строгих правил, алгоритма, последовательности мыслительных шагов, порядка опроса стейкхолдеров. Так или иначе в решении по поводу выбора целевой системы будут участвовать самые разные люди, и речь идёт не только о членах команды, но и о внешних стейкхолдерах.
Если у вас проект, который вы можете сделать в одиночку, то вам не потребуется развёрнутого системного мышления. Но если проект сложный и работает группа, то в принятии решений заведомо будет сложный переговорный процесс и о целевой системе придётся договариваться по ходу дела.
Обычно целевую систему нельзя определить, сидя на своём рабочем месте и размышляя: требуется не только читать самые разные документы и хорошо знать свою предметную область, но встречаться и разговаривать со многими людьми.
При этом каждый проект уникален, каждая ситуация уникальна, так что ничего нельзя будет запомнить и применить потом в том виде, в котором запомнили. Даже если вы (как команда!) подряд второй раз делаете что-то очень похожее, то у вас по сравнению с первым разом появляется опыт, вы лучше знаете риски, чем это было в первый раз – и вы уже на основании этого опыта может принять совсем другие решения. «Запомните, так всегда делают» – это не про системное мышление.
И ещё раз напомним, что рассуждения по поводу определения целевой системы (как и все остальные рассуждения по проектированию системы) обычно делаются «в классах», с типами систем, а не с индивидуальными системами, несмотря на то, что вы работаете в уникальной ситуации.
Система – это продукт, или сервис?
Целевая система раньше часто мыслилась как поставляемый продукт.
Система как индивид изготавливается командой проекта, а затем поставляется его потребителю. И уже у потребителя этот продукт выполняет свою функцию, назначенное ему поведение в ходе эксплуатации.
Клиент использует продукт двумя способами:
• в составе своей целевой системы
(например, ваши часы-продукт он устанавливает в
свой автомобиль-продукт, а затем продаёт автомобиль
своему клиенту)
• в составе своей обеспечивающей системы
(например, ваши часы-продукт он устанавливает в свой цех
на стену, чтобы рабочие могли следить за временем в ходе
сборки ими автомобиля – продаёт же клиенту автомобиль
без часов или с какими-то другими часами).
Альтернативное представление продукта – это представление его как целевой системы, принадлежащей клиенту.
Но что тогда делает команда проекта?
Она предоставляет сервис (service, услугу) обеспечивающей системы101. Например, парикмахерская оказывает услуги по стрижке головы. Голова и причёска на голове принадлежат клиенту, парикмахерская – обеспечивающая система, производит внешнее поведение (сервис), меняющий голову так, чтобы на ней появилась причёска.
Если вы создаёте сервис, то вам нужно думать о двух системах: целевой системе, изменяемой сервисом и обеспечивающей системе, которая делает это изменение. Они принадлежат разным холархиям, и нужно заниматься ими обеими. Причёски не будет без парикмахерской, парикмахерская без производимых ей причёсок никому не нужна, поэтому её тоже не будет. И определение системы делается и для причёски, и для парикмахерской. Воплощение системы будет и у парикмахерской, и у причёски. Стейкхолдеры (внешние) будут и у парикмахерской, и у причёски. Но целевая система будет – причёска, ибо только упустишь из виду, что делать в конечном итоге нужно причёску (а не парикмахерскую), парикмахерская будет отлично работать, только недолго, пока не кончатся деньги инвестора, ибо вся «клиентоориентированность» или «продуктоориентированность» будут утеряны.
Платят обычно за результаты приложения внешнего поведения (сервиса) обеспечивающей системы к целевой системе – платят за то, что целевая система перешла в новое состояние, что-то во внешнем мире поменялось к лучшему.
Если сервис стрижки, то платят за причёску, которая начинает потом эксплуатироваться. За эскиз причёски и разговоры парикмахера по поводу выбора модели причёски могут заплатить, но только в том случае, когда конечная причёска окажется годной к эксплуатации. Если окажется, что это в реальности не происходит, то заказчики вернутся в парикмахерскую и опротестуют и причёску, и эскиз, и результаты разговоров с парикмахером: это уже внутреннее дело сервиса разбираться, кто там в его внутренней структуре дал такой сбой, что внешнее поведение и его результаты оказались неправильными. Целевой же системой всё равно будут причёски, и от класса этих причёсок будет зависеть, брать за сервис стрижки будут 100 рублей или 1000 рублей.
Переход в мышлении от поставки продуктов к оказанию сервисов оказался очень продуктивным и в современном языке называется сервис-ориентацией.
Например, традиционный продукт – чугунные чушки, «чугун серый литейный»:
Если учесть сервис-ориентацию, то услугой будет «поставка чугуна», и это резко увеличивает возможности предприятия: сам чугун, как продукт, остаётся тот же самый – но могут существенно меняться условия его поставки. Поставка точно вовремя, через склад предприятия или прямо к точке переплавки, поддержание минимального запаса в течение года или просто поставка одной крупной партии, возможности кредитования при поставке и т. п.
Сервисы (как и функции) обычно легко распознать в языке – это отглагольные существительные, в которых скрыт глагол (поведение), но тем не менее в языке сохраняется словоупотребление по их поводу, как для вещи. Если действие/процесс «обучить», то сервис будет «обучение». Если действие/процесс «поставить», то сервис будет «поставка». В английском языке сервисы обычно выражены глаголами в их ing-форме.
Сервис-ориентация чудесным образом расширяет возможные рынки: разных видов действий в мире не так много, несколько тысяч (и поэтому глаголов в языках всего несколько тысяч), а вот разных видов вещей – миллионы и миллионы (поэтому существительных миллионы). Мышление о сервисах экономно: с миллионами и миллионами разных товаров работают одни и те же всё более и более универсальные сервисы.
Переход от «вещей» к «поведению», изменениям, динамике оказывается очень продуктивен, поэтому сервис-ориентация стремительно вытесняет ориентацию на продукт.
Операционная система Windows 10 уже рассматривается фирмой Microsoft не столько как продукт, но как сервис по её поддержанию. Магазин поставляет не продукт, а сервис по продаже продукта. Программы не нужно поставлять клиенту, ему нужно поставить сервис (внешнее поведение) этой программы – сама программа может остаться у компании, которая эту программу разрабатывает.
В этот момент можно совершить крупную ошибку: считать, что целевой системой является оказывающая сервис система. Нет, целевой системой является та система, которую мы изменяем сервисом, а сервис в данном случае – это обеспечивающая система! Целевой системой парикмахера является причёска, сервисом – стрижка, а парикмахерская вместе с парикмахером – обеспечивающая система. Шикарный сервис стрижки (поведение парикмахерской) с результирующей плохой причёской это ведь не то, что нам нужно? Никогда не нужно забывать о целевой системе, когда мы занимаемся обеспечивающей системой, чтобы получить сервис: легко забыть, для чего существует обеспечивающая система, для чего существует сервис – и в этот момент потерять клиентов.
Для размышлений о сервисах с участием людей очень полезно обращаться к танцевальной метафоре. Например, магазин предоставляет сервис покупки – он обеспечивает покупку как оргпроцесс: танец покупателя среди полок, облегчая покупателю максимальное наполнение корзины и максимальное опустошение его кошелька, минимизируя специально организованной выкладкой товаров в торговом зале возможности покупателя принять рациональные решения по поводу покупок.
Существенным элементом оказания сервиса (элементом обеспечивающей системы) является торговый зал магазина. Торговый зал обеспечивает целевой «танец покупки», ибо зал важен не сам по себе, но как существенный реквизит «танца покупки», он мыслится только в контексте оказания сервиса.
Мышление о танце и о покупке оказывается похожим: вот эта экономия мышления и интересна, возможность более легко менять предметные контексты, рассматривать разные жизненные ситуации похоже – отслеживать их целостность, не теряя из виду деталей. Если о покупке мыслить как о танце, то кроме поведения обеспечивающей системы (торгового зала) придётся учитывать и поведение покупателя, чтобы их совместный танец-покупка получился. Системное мышление не просто позволяет отдельно мыслить о торговом зале и покупателе, оно позволяет удержать во внимании их взаимодействующее целое: процесс покупки.
Этот сервисный подход сдвигает внимание с рассмотрения только собственных проблем на рассмотрение также и проблем клиента: обеспечивающая система выживает в долгосрочной перспективе только в том случае, когда нет вопросов к качеству результирующей целевой системы. Если целевая система в ходе оказания сервиса получается плохая, а обеспечивающая система при этом восхитительна, то её жизнь закончится в момент окончания инвестиций102. Если владелец магазина будет заботиться не о «танце покупателя», а просто о своём торговом зале – то покупатели будут только мешать торговому залу быть в идеальном состоянии!
В любом случае: вы можете менять две системы вашим поведением – обеспечивающую (команду и оборудование, предпринятие) и целевую. Не забывайте, что изменения обеспечивающей системы делаются для того, чтобы надлежащим образом менять целевую систему. Если целевая система оказывается не нужна каким-то клиентам (не учитывает интересов клиентов-стейкхолдеров), то у вас просто довольно скоро не будет денег поддерживать обеспечивающую систему – неучёт интересов внешних стейкхолдеров в пользу команды ведёт к созданию неуспешной системы.
При этом всё сказанное про формулирование целевой системы как принадлежащей клиенту и обслуживаемой/изменяемой каким-то сервисом обеспечивающей системы команды проекта не является «объективной истиной»: разнообразие ситуаций в самых разных деятельностях очень велико, и конкретные решения придётся принимать самостоятельно: в каждом конкретном проекте, с учётом интересов всех стейкхолдеров – и внешних, и внутренних.
Ты – член команды
Целевая система обычно определяется для команды проекта, а не индивидуально – это делается как раз для того, чтобы системное мышление позволило скоординировать деятельность, а не просто обеспечить мыслительное превосходство одних людей над другими. Это не боевое/спортивное мышление соревнования и победы, а мышление договорённостей и сотрудничества.
Вы как стейкхолдер совсем необязательно заняты работой над целевой системой в её целостности. Вы можете быть заняты разработкой подсистемы для целевой системы, или даже подсистемой подсистемы – но это будет просто ваше личное мнение, что вы занимаетесь «собственной целевой системой», вы может оставить это мнение при себе. В рамках проекта, в общении с командой вы всё равно должны говорить про вверенную вам подсистему или даже подсистему подсистемы, а не требовать от команды признания вашей целевой системы полноценной целевой системой для всей команды.
Вы можете быть также заняты разработкой обеспечивающей системы (например, реализовывать проект развития), то есть непосредственно сами не заниматься целевой системой – но и это не означает, что вы не обязаны называть целевую систему команды целевой системой. Вам нельзя считать, что ваша целевая система это та, которая для всех остальных обеспечивающая. Нет, ваша целевая система та же, что у всех, а именно, которая изменяется обеспечивающей системой (если строите авиазавод, то целевая система – самолёт).
Как в картах, каждый человек не строит карту с полярными координатами вокруг себя! Договорились в масштабах планеты о Северном полюсе – и все на планете пользуются единой системой отсчёта. В системном подходе рекомендуется именно такой подход: договориться об общей целевой системе для всей команды проекта.
Команда проекта – это совсем необязательно группа проекта под твоим руководством! Скорее всего, «ты» в этом «мы» занимаешь какую-то стейкхолдерскую позицию, делаешь часть большого дела, не удерживаешь в сознании целую систему, а занимаешься либо какой-то отдельной практикой (теплотехникой, менеджментом, программированием, хореографией), либо какой-то частью системы.
Большая ошибка – это считать себя объективным и нейтральным системным инженером, эдаким системным рыцарем, который весь в белом и с нимбом над головой ведёт команду к успеху проекта. Отнюдь. Системное мышление чаще всего нужно именно для того, чтобы так не думать, чтобы поднять свою осознанность: позволить осознать, какой именно ты стейкхолдер (или даже исполнитель не одной, а нескольких стейкхолдерских ролей), какие твои стейкхолдерские интересы, какое твоё место в команде, какой подсистемой целевой системы твоей команды или подсистемой одной из многочисленных обеспечивающих систем ты занимаешься.
Команда проекта может быть и на пару тысяч человек сотрудников предприятия, а может состоять и из пары человек, и даже одного человека. Разделение на внешних стейкхолдеров и команду как внутренних стейкхолдеров может быть даже более дробным: внутренние стейкхолдеры предприятия (юрлица) и команда предпринятия (отдельного проекта внутри предприятия). Внутренние стейкхолдеры предприятия (например, финансисты, юристы, высшие менеджеры предприятия) заинтересованы в успехе целевой системы, но преследуют совсем иные интересы, нежели команда проекта. Если у вас появятся лишние $1000 в проекте – вы куда их потратите? Улучшите на эту сумму целевую систему, не увеличивая её стоимости – т.е. подарите клиенту? Улучшите ресурсы команды – наймёте более квалифицированных людей, закупите более дорогое оборудование? Отдадите на дивиденды владельцам предприятия? Интересы всех стейкхолдеров разные, критерии принятия ими решений разные.
Нужно коллективно/группой договориться, что считать целевой системой, какие цели преследует проект, в чём состоят возможности проекта. И ещё нужно понять, какой именно коллектив/группа договариваются.
Каждые пять минут менять то, что ты/вы называешь/называете целевой системой – это неправильно. Релятивизм (когда всё на свете считается субъективным и относительным, зыбким и неопределённым – заведомо отсутствует точка отсчёта) в мышлении не поможет. Договорённость по поводу целевой системы должна достигаться из каких-то Принципов, и на достаточно долгое время – желательно, не менять целевую систему во время всего проекта.
Признаки целевой системы
Целевая система определяется ситуативно, о ней договариваются командно, нет никакого алгоритма. Тем не менее, есть эвристики (правила, которые срабатывают часто, но не всегда103), которые помогают найти свою целевую систему среди многочисленных чужих систем в самых разных холархиях. Да, в системном мире царит хаос из совокупности самых разных субъективных мнений, но человек склонен упорядочивать хаос, наводить в нём структуру – символ хаоса совсем не случайно выглядит весьма структурированно:
Так что всё не так плохо: есть множество признаков, которые помогут не ошибиться при выявлении целевой системы. Слово «выявление» (discovery) тут использовано не случайно: считается, что целевая система есть, и её нужно только найти/выявить – возможно, поговорив при этом с большим количеством самых разных стейкхолдеров. Требования, как описание целевой системы как чёрного ящика – их как раз выявляют. Собственно, определить целевую систему – это выявить её системные требования, описать как «чёрный ящик».
Целевая система находится в физическом мире, это точно не какое-то описание. Если вы делаете какие-то информационные модели, пишете тексты, создаёте базы данных, рисуете схемы или чертежи, то это вы делаете описание системы. Это описание ваш рабочий продукт (вы работаете с ним, и это продукт, или вы оказываете сервис по описанию системы), но это описание – не целевая система, даже если речь идёт о толстой пачке проектной документации для высотного здания или даже если речь идёт об исходном тексте компьютерной программы, или даже если речь идёт о каком-то сценарии городского праздника. Возможно, целевая система – это то, что вы описываете. Возможно, вы описываете даже не целевую систему, а систему в операционном окружении целевой системы, или подсистему целевой системы. Главное – не путать системы и описания. Целевая система – это не описание.
Целевая система – это то, что делает (то есть полномочно меняет, а не «влияет на то, что кто-то другой поменяет») команда проекта. Если команда делает описание, по которому потом сделают систему – это непосредственное изменение мира, план этого изменения. Это не уговоры кого-то, чтобы он изменил свою систему. У команды есть какие-то полномочия по отношению к целевой системе, по отношению к другим системам полномочия команды сильно ограничены.
Целевая система – это то, за что команде в конечном итоге (после того, как система окончательно изготовлена и начинает успешно эксплуатироваться) платят деньги. Если команда делает информационную модель велосипеда, то в конечном итоге заплатит деньги потребитель за велосипед. Вот целевой системой тут и будет велосипед, деньги именно за это – информационная модель велосипеда просто описание велосипеда. Но если команда делает алюминиевую раму велосипеда, и эта рама продаётся только как велосипед, то и рама не будет хорошо выбранной целевой системой. Она будет подсистемой целевой системы. Вместе с тем двигатель самолёта – хороший кандидат в целевые системы. Двигатель обычно (с небольшими модификациями) может поставляться для включения в состав разных моделей самолётов, двигателестроители работают в составе независимых более-менее автономных предприятий, поэтому двигатель хороший кандидат. Но Роллс-Ройс продаёт авиастроителям не авиадвигатели, а часы работы двигателя, так что и тут возможны варианты: двигатель тут неразрывно связан с системами его обслуживания.
Целевая система-продукт часто пересекает границу предприятия, идёт её «поставка» (delivery). Подсистемы обычно границу предприятия сами по себе не пересекают, только в сборе в составе целевой системы. И помним, что у разных компаний/групп/команд проекта могут быть разные представления о том, что такое целевая система, каковы её границы, какой её уровень в системной холархии. У поставщика авиадвигателей целевой системой является двигатель. Но у поставщика авиалайнеров двигатель – это заказная подсистема.
У целевой системы обычно есть требования, активно обсуждается её архитектура, вопросы её проверки и приёмки. Если её перепутали с обеспечивающей системой, то этих слов не будет: о предпринятии как системе говорят другие слова – «стратегия», «ключевые индикаторы» и т. п.
Принцип почтальона
Адреса составлены обычно так, чтобы разные уровни адресации позволяли чётко найти объект, объект уникален внутри какого-то уровня адресации, его легко найти – это и есть принцип почтальона (был предложен А. Нечипоренко в ходе одного из наших семинаров). Скажем, вот адрес пластиковой накладки на ножке стола: Вселенная, комплекс сверхскоплений Рыб-Кита104, Ланиакея105, сверхскопление Девы106, местная группа галактик107, Млечный Путь108, Рукав Ориона109, Солнечная система, планета Земля, Россия, Ростов-на-Дону, ул. Большая Садовая, дом 105, аудитория 323, первый стол от доски у окна, левая ножка стола, пластиковая накладка. Адрес «Вселенная, Солнечная система, Дом 105, пластиковая накладка» – это неправильный адрес целевой системы, неправильное указание на целевую систему.
В холархии использующая система должна определяться по возможности близко по уровням отношений «часть-целое» от целевой системы. Тут возможно много разных типов ошибок:
• пропуск уровней, обычно заявляется слишком большой системный уровень, например, сразу использующая система, или даже система на несколько уровней холархии выше использующей. Типичный пример: я делаю автомобиль! После чего следует длинный рассказ о морозоустойчивых аккумуляторах. Почему? – Ну, меня интересуют морозоустойчивые аккумуляторы, они используются в автомобилях. – Могут ли использоваться, например, для гайковёртов? – Да, вполне. – А если гайковёрты в Якутии? Да, это много лучше автомобиля, для моих морозоустойчивых аккумуляторов это отличный рынок! Я занимаюсь гайковёртами! (после некоторых вопросов становится понятным, что и аккумулятор тоже не интересует, речь идёт о морозоустойчивом электролите).
• Сверхобобщение. Это в некотором роде нарушение адресации, но отношение не часть-целое, а уровня специализации в классификаторе. Например, не «одноместный учебный самолёт», и даже не просто «самолёт», а «летательный аппарат».
• Указание не всей системы, или соседней системы, в надежде, что целевая система будет собеседником определена самостоятельно, умозаключением. По сути, речь идёт о метонимии110 – один индивид (или класс этого индивида) заменяется другим (или его классом), находящимся в какой-то связи/отношении с предметом, замещающимся этим словом. Связь эта может быть как «часть-целое», так и любой другой. «Я три тарелки съел» – не тарелки, а находящуюся на тарелке еду. «Ведро расплескалось» – не ведро, а вода в ведре. По метонимии целевой системой могут назвать что угодно, находящееся в каких-то отношениях с целевой системой: всё, что попадает в сферу внимания. Проверять метонимию нужно, отслеживая, что речь идёт об отношениях «часть-целое».
Типовые ошибки определения целевой системы
Признаков целевой системы не так много, но всё равно люди делают ошибки: проблема в том, что системное мышление не подсказывает, что является правильным выбором.
Мы уже о них писали, но повторим ещё раз, чтобы под рукой был маленький чеклист:
• Описание системы как целевая система. Программисты считают, что их система – исходный код, а не программа в момент её выполнения для пользователя. Проектировщики и конструкторы считают, что это проектная и конструкторская документация (неважно, в электронной или бумажной форме). Сценарист считает, что это сценарий спектакля или фильма, а не сам спектакль или фильм в момент его просмотра. Хореограф считает, что это его тщательно продуманный набор движений, который он показывает танцорам, а не тот танец, который потом станцуют танцоры. Модельер данных – что это модель данных, а не данные, структурированные в соответствии с моделью (например, база данных). Нет, это всё описания целевых систем. Нам нужно доводить мысль до изменения реальности, а не до описания изменения реальности! Описать – не сделать! При этом недостаточно даже использовать «проектирование для изготовления» (design for manufacturing), хотя и это тоже нужно, тоже важно. Проектирование должно быть прежде всего озабочено эксплуатацией, изготовление тут только промежуточная стадия.
• Обеспечивающая система как целевая система. Это типичная ошибка менеджеров. Ошибка ведёт к процветанию организации на короткий период, пока не кончатся деньги инвестора. Если такому менеджеру поручить построить авиазавод, то он построит авиазавод, который будет восхитительно работать – но самолёты этого авиазавода летать не будут, ибо завод будет строиться как целевая система, а выпускаемые самолёты не будут в центре внимания этого менеджера и менеджер не будет выделять достаточно ресурсов для обеспечения качества выпускаемых самолётов, а не качества заводской жизни. Справедливости ради нужно отметить, что инженеры часто делают обратную ошибку: не замечают обеспечивающей системы, без которой целевая система невозможна, но об этом в нашей книге мы будем говорить позже.
• Одинаковые имена целевой системы и её части (или целевой системы и использующей системы), скорее всего нужно уточнить какое-то из использованных имён, обозвав неполную систему (скажем, дом как целевая система состоит из «строительной части дома, коммуникаций, отделки», но не «дома, коммуникаций и отделки»).
• Сверхобобщения (Принцип почтальона): это частая инженерная ошибка: игнорирование при определении целевой системы использующей системы. Маскируется словами «используется везде», или совершенно неопределённым адресом. « – Где используется ваш сверлильный станок? – В машиностроении!», «Какие танцы вы будете принимать к постановке? – Любые!».
– Релятивизм – это ошибка всех тех, кто не уверен в принадлежности к какой-то команде. При релятивизме что угодно определяется «целевой системой», игнорируя наличие обеспечивающих систем (команды), просто для целей текущего рассмотрения. Системное мышление в этом случае перестаёт служить целям координации коллективной/групповой деятельности.
• Игнорирование первичности основного назначения (функции) в определении системы. То есть система выявляется не по её назначенному каким-то стейкхолдером поведению в составе использующей системы в момент эксплуатации, а по каким-то иным соображениям (например, в холархии собственности присутствуют отношения часть-целое в разных совокупностях предметов, но без опоры на взаимодействие с системным окружением и без возникающего системного эффекта). Например, «информационная система предпринятия» очень часто определяется именно через отношение принадлежности к предприятию, а не по основной функции этой информационной системы, и это ошибка. Сказать, что «информационная система предприятия информирует» – это ничего не сказать про её функцию. Принцип почтальона говорит, что это слишком общая характеристика. Пример с собакой обычно все понимают в части соблюдения этого принципа: нужно говорить «сторожевая собака», а не «домашнее животное Василия» или «дворовой зверь». Но вот для какой-то инфраструктурной или программной системы часто упускается эта необходимая первичность рассмотрения функциональности целевой системы, протягивание мысли к эксплуатационному времени, а не времени создания системы или отношениям владения.
Не расстраивайтесь, если вы поначалу будете постоянно совершать эти ошибки, даже зная, что это ошибки. Беглость и безошибочность в системном мышлении, как и в любом другом деле, приобретается только путём долгих упражнений, путём набора опыта работы.
Именование системы
Система обычно именуется по типу (некоторому узкому классу) её основной функции, оказываемому ей сервису – т.е. по основному назначенному ей поведению в её использующей системе/операционном окружении. Так именуются не только целевые системы, но и все остальные (использующая, системы в операционном окружении, подсистемы), т.е. именование системы оказывается именованием её «чёрного ящика», а не прозрачного ящика. Именование системы зависит, прежде всего, от окружения системы.
Микроскоп именуется по его основной функции – внешнему поведению, которое от него ожидается в использующих системах. Так, микроскоп предназначен для того, чтобы рассматривать мелкие предметы. Если иногда им заколачивают гвозди, то это не считают его основным назначением, хотя это иногда и будет его функцией в использующей системе.
Именуется при этом класс/тип систем, а не уникальный экземпляр системы. И это очень часто «исполнитель деятельности» (сборщик, погрузчик, нарезчик), но не только. Назначение «ножниц» (что-то резать, это производное от «ножа») хорошо известно, так что ножницы назовут, скорее всего, ножницами – только добавят уточнения (например, «ножницы по металлу»).
Первая ошибка, которую делают при именовании – это перечисление всей возможной функциональности. Вместо «автобус» это будет «система посадки, перевозки по автомобильным дорогам, оповещения об остановках и коммуникации водителя и пассажиров, высадки пассажиров и закрывания дверей в целях безопасности». Так нельзя: любое длинное перечисление функций в названии недопустимо. И иногда есть уже устоявшееся название, его и нужно использовать – тот же «автобус».
Вторая ошибка – это указание не на функцию, а на конструкцию. Вместо «ножницы по металлу» это будет «система лезвий, ручек и винта», явная ошибка. Вместо «антистатик для пластмасс» (целевая функция) это будет «система введения углеродных трубок в пластмассы» (обеспечивающая целевую функцию конструкция, ошибка). Нет, название системы даётся по первичному/обычному/типовому назначению системы, по функциональности в типовой использующей системе.
Третья ошибка – это нарушение «Принципа почтальона», указание слишком общей функции. «Система разрезания» вместо «ножницы по металлу» или «автотранспортное средство» вместо «автобуса». Функция должна быть специфицирована точно, без лишнего обобщения. Нельзя говорить «расчёты», нужно указывать, какие именно расчёты. В названии должна чётко угадываться предметная область, никаких сверхобобщений.
Ещё можно указать на неоправданное использование слова «система» в названиях: «система ножниц по металлу» лучше сразу заменять на «ножницы по металлу».
Использующая система
Использующая система (обычно не говорят «надсистема», хотя в некоторых школах системной мысли используется и термин «надсистема», например, в движении ТРИЗ111) прежде всего должна проверяться на то, что целевая система является в момент эксплуатации (operation, работы) неотъемлемой частью этой системы, то есть буквально входит в её состав (composition). Увы, большинство ошибок происходят именно по невниманию к этому её признаку. Системная холархия – это иерархия по отношению состава/сборки/часть-целое, а не по каким-то другим отношениям. На ошибку выделения использующей и целевой системы указывают обнаружение между ними отношений вызова подпрограммы, классификации и специализации, принадлежности в части имущества, назначения на роль – ведь есть огромное количество других отношений, кроме предписанного для холархии отношения состава (composition, is_part_of, включения как физической части).
Например, рассмотрим мужчину и женщину. Один из студентов высказал мысль, что если женщина целевая система, то мужчина – это использующая система. С этим можно согласиться, но только если мужчина съел женщину! А как ещё женщина может быть составной частью (is_part_of) мужчины?
В студенческих аудиториях эту загадку решают минут пять, а в более взрослых аудиториях на это тратят пятнадцать секунд: использующей системой женщины и мужчины тут является семья (студенты часто говорят «пара», подчёркивая возможность более слабой связи), а женщина и мужчина находятся друг у друга в операционном окружении. Загадка решается путём выявления пропущенной, не названной, не выявленной системы в холархии. Это типичная ситуация: использующие системы обычно плохо различимы, иногда для них нет устоявшихся названий. Эти «пропущенные» системы приходится определять (то есть описывать их функции, границы) и как-то называть.
Признаком использующей системы в её отделении от целевой системы (а команде проекта обычно приходится иметь дело с обоими этими системами) является то, что команда не уполномочена как-то самостоятельно изменять саму эту систему или даже её определение (требования, архитектуру). Ещё десяток лет назад не предполагалось, что команда как-то может повлиять на использующую систему – она брала её в проект как данное, и должна была просто стыковать свою целевую систему с имеющимся системным окружением. Сегодня это не так: команда проекта не уполномочена изменять системное окружение непосредственно, но она может влиять на то, чтобы в целях согласования характеристик целевой и использующей системы использующая система была изменена – самостоятельно её стейкхолдерами, или командой проекта по согласованию со стейкхолдерами. Для этого команда проекта (внутренние стейкхолдеры) активно работает с внешними стейкхолдерами, влияет на них.
При определении использующей системы важно, чтобы это был ближайший уровень (Принцип почтальона), на котором ожидается эмерджентность/системный эффект от работы целевой системы в её составе. Верный способ найти использующую систему – это разобраться, с какими людьми приходится разговаривать, чтобы проект состоялся. Они обычно и есть владельцы использующей системы. Скажем, вы делаете «систему перевозки самолётов», используемую во время ремонтов самолёта. Использующая система – авиация страны, министерство промышленности? Нет, Принцип почтальона говорит, что это «правда, но бесполезная правда», с равным успехом можно говорить и о «человечестве» как использующей системе, и даже о «всей вселенной»! В данном случае довольно просто выясняется, что «системой перевозки самолётов» интересуются главным образом люди из эксплуатационной службы одного из авиапредприятий. Эксплуатационная служба этого авиапредприятия (и даже не всё авиапредприятие!) и является использующей системой. Именно у её команды (внешние стейкхолдеры по отношению к системе перевозки самолётов) есть потребности – им нужно ремонтировать самолёты, которые не летают. И поэтому у них есть какие-то требования к наземной системе перевозки самолётов (заведомо не летающих). Всё, с этого момента (система перевозки самолётов как часть эксплуатирующей службы авиапредприятия = целевая система как часть использующей системы) можно начинать обсуждать проект по созданию системы перевозки самолётов. Ход на выявление владельцев использующей системы (если только это не система систем) обычно крайне продуктивен: всё равно с этими владельцами нужно общаться, они важнейшие внешние стейкхолдеры в вашем проекте.
Ещё одна ошибка, когда использующая и целевая система называются одинаково. Холархии типа «А состоит из А и Б» недопустимы, может быть только «А состоит из Б и В» – и скорее всего эта ошибка не в том, что сама холархия в жизни какая-то неправильная, а просто неправильно выбраны имена для холонов. Например, «ячейка состоит из ячейки и прокладки». Подробное обсуждение показывает, что речь идёт о ячейке, которая состоит из корпуса и прокладки. «Жилая комната состоит из комнаты и интерьера». Подробное обсуждение показывает, что жилая комната состоит из помещения (строительной части, даже без отделки) и интерьера (в который входят даже приклеенные к стенам помещения обои).
Холархия человеческого движения
Какая целевая система должна быть выбрана в человеке, чтобы заниматься его двигательным фитнесом (fitness, готовность к действию)? Чем танцует человек? Чем он бегает и прыгает? Ответ на этот вопрос так же не прост, как и ответ на вопрос «чем едет автомобиль» (двигателем? колёсами? Креслами и кондиционером в салоне? Заправочной станцией, ибо без неё тоже ведь никак?). Для ответа на вопрос о целевой системе нужно рассмотреть холархию, где на верхних уровнях всегда будет вселенная (туда входит всё на свете) и на нижних уровнях будут атомы (которые входят во всё на свете, ибо всё из них и состоит – кроме тех редких случаев, когда речь идёт о ядерных реакциях или существенными являются поля и энергия).
А вот где-то в середине будут интересующие нас уровни – их нужно выбирать так, чтобы они были наилучшими для нас кандидатами на ответы на наши вопросы. Для вопроса «чем едет автомобиль» нужно, чтобы мы как-то отразили в нашем описании холархии двигатель, колёса, и как-то обозвали их объединение со всем остальным, что может ответить на вопрос «чем автомобиль едет», проигнорировав находящиеся в холархии, но не требующие нашего внимания и поэтому не отображаемыми нами в описании кресла, кондиционер и даже заправочную станцию из системного окружения.
А вот пример нескольких уровней такой холархии для ответа на вопрос «чем двигается человек». Речь идёт о 4D объектах-холонах в пространстве-времени, но нас интересуют прежде всего полные темпоральные части всех этих систем/холонов каждого уровня на момент функционирования/«эксплуатации». Ещё помним, что ничего объективного в наших выборах нет (другие люди для каких-то других целей и проектов могут предложить другое описание), поэтому ориентируемся на всех уровнях на каких-то стейкхолдеров:
• Вселенная
•…
• Живая природа на Земле
• Человечество (цивилизация, человеческая культура) как часть природы. Люди, которые думают, строят, радуются и страдают, но в том числе и «ритуально двигаются» в рамках каких-то двигательных культурах/практиках из уровня ниже. Этим интересуются культурологи, а иногда министры культуры (помним про сложностность!).
• Вид двигательной культуры/практики (все совокупности поз и прохождений через них, возможно групп людей – партнёров или противников в разных двигательных культурных практиках). Это отдельные виды танцев, виды спорта, школы боевых искусств как культурные единицы – некоторый набор наложенных на «стилевой движок» (уровень ниже) фигур танца или приёмов спортивных движений во всём их разнообразии. Этим занимаются тренеры определённых стилей движения, не обязательно родоначальники этих стилей.
• «Стилевой движок» – набор поз (положений частей тела) и «прокачанных мышц» (не только и не столько крупных мышц, сколько множество мелких «глубоких» мышц), позволяющих далее строить из них широкое разнообразие движений выбранного стиля. «Стилевой движок» сам строится на базе развития той или иной (зависящей от стиля) части миофасциальной системы, «фитнес-движка»: как из натяжений-сжатий-обмяканий по струнам-поездам-мачтам, движений «от сочленений» конструировать прохождение в динамике тех или иных предписанных стилем поз. Этим занимаются тренеры определённых стилей, но разрабатывают «стилевые движки» обычно родоначальники какой-то школы.
• «Фитнес-движок», развитая и осознанная миофасциальная система112: анатомические поезда (ощущаются как некоторые «струны» внутри тренированного тела). Человеческое тело как структура сжатия-растяжения (тенсёгрити113). Двигательная платформа, «мачты для тела движения», работа нервной системы и мозга – виды ощущений и управление «струнами»: как из мышц, костей, фасции, психики/мозга говорить о работе тенсёгрити – добиваться работы или неработы отдельных мышц в миофасциальной системе (предыдущий уровень), обеспечивать постепенное исправление формы суставов и основных поз (осанки, баланса), как добиваться управления какими-то ощущениями и т. д. – вот тут работают тренеры системного фитнеса. Это уровень «общедвигательной», «телесной» (не общефизической!) подготовки, только маргинально известный сегодня в обществе114.
• Ткани: мышцы, кости, фасции + мозг/рефлексы. На этом уровне работают хирурги и неврологи, тут никакого спорта, никаких танцев – медицина и неврология. Как починить ткани, зная, как работают их клетки (знания устройства предыдущего уровня), как починить нервы.
• Клетки
– Клеточные органеллы
• Молекулы
•…
При обсуждении сегодняшних двигательных практик распространено игнорирование в выделении системных уровней «стилевого движка», а также «фитнес-движка» миофасциальной системы. Нельзя говорить, что кто-то танцует молекулами, или клетками – хотя это верно. Это типичный редукционизм, игнорирование эмерджентности. Но нельзя говорить и то, что кто-то танцует мышцами (которых около семисот!) и костями – взяв всего один уровень вверх. Нет, движение передаётся по структуре сжатий (обеспечивается костями и фасциями, «межмышечными плёнками») и натяжений (обеспечивается мышцами), тенсёгрити.
Так, в бейсболе порядка 50—55% силы броска обеспечивается за счёт работы ног, а не бросающей руки – и торс и рука должны провести эту силу через себя, их нужно к этому подготовить. Это явно системное рассмотрение, как движения проходят через тело – возникает эмерджентность прохождения движения через тело, недоступная при обсуждениях как тела целиком, так и отдельных его мышц.
Танцоры и спортсмены, объясняя, как проводить движение через тело, используют метафорические высказывания: движение у них может идти «от солнечного сплетения», «от колена». То, что при этом пропускается уровень «фитнес-движка», опирающегося на понимание анатомических подструктур из групп мышц, фасций и костей («анатомических поездов» миофасциальной системы») затрудняет подготовку спортсменов, танцоров, особенно в высокоспецифичных стилях, требующих высокоточных движений («телесной каллиграфии»), а не грубых силовых достижений от накачки нескольких давно известных групп мышц.
Но системный подход уже начал своё проникновение и в эту сферу, она становится более структурирована, в ней возможно более глубокое разделение труда, специализация по системным уровням: рекурсивно на каждом уровне холархии применяется мышление инженера, который собирает приемлемую для использующей системы (уровень выше) целевую систему (текущий уровень), используя эмерджентность от взаимодействия собранных вместе подсистем (уровень ниже). Каждый уровень специализируется на своей эмерджентности. Так, в двигательной культуре медики лечат, тренеры создают виды телесных/двигательных практик и их стили и тренируют адептов, культуртрегеры заботятся о культурном разнообразии.
Разделение труда продолжается и на более низких системных уровнях. Например, генетики позволяют выявить людей с особым клеточным метаболизмом, что даёт возможность заранее отобрать для участия в соревнованиях людей, например, устойчивых к нехватке кислорода – и они не будут ограничены там, где другим спортсменам будет трудно из-за недостатка кислорода в клетках мышц во время нагрузки. Спорт высоких достижений всё больше и больше превращается сейчас в соревнование молекулярных биологов и генетиков, а не тренеров.
Это общий Принцип системного мышления: на каждом системном уровне, то есть уровне холархии есть специалисты, которые искусны в достижении системного эффекта этого уровня – они получают его, зная, как собрать целевую систему из её подсистем. Но мало этого, они ещё знают, где можно использовать собранную ими целевую систему, чтобы такие же специалисты на уровне выше смогли использовать их целевую систему как подсистему. Каждый специалист разбирается в своём системном эффекте и связывает своей работой три уровня системной холархии – а все вместе специалисты могут создать очень и очень сложную систему.
Это верно для инженерии, но это верно и для сферы телесных практик. Как сотни людей сегодня делают кинофильм, так и множество человек могут помочь кому-то делать, например, танец. Танец при этом оказывается многоуровневым, его сложность можно преодолеть, если использовать по отношению к нему системное мышление, которое в одном проекте позволяет использовать преимущества разделения труда: каждый участник проекта глубоко понимает то, что происходит на его уровне холархии и способен выставить требования к подсистемам (требования: описание чёрного ящика! Решениями прозрачного ящика будут заниматься уже другие люди!) и принять необходимые решения по удовлетворению выставленных к нему требований со стороны использующей системы. Если это произойдёт на многих уровнях, а на каждом уровне со всеми холонами этого уровня, то мы получим успешную систему.
Наш пример холархии верен для ситуации, в которой мы хотим создать более-менее универсальную систему-человека, культурно (то есть не случайно, не по наитию, а цивилизованно) двигающегося. Если же речь идёт о какой-то двигательной монокультуре (скажем, только тяжёлая атлетика, или только бокс), то бОльшая часть этой холархии может быть схлопнута за ненужностью: после подготовки клеток (например, отбора людей, у которых есть генетические задатки для «правильной энергетики» данного вида спорта – при этом путь в другие виды спорта этим людям может быть заказан115) можно сразу приступать к тренировке очень ограниченного набора движений, поддерживаемого ограниченным набором мышц, игнорируя все остальные потенциальные возможности развития на каждом уровне, возможности лёгкого освоения других паттернов движений.
В инженерии происходит то же самое: гоночный автомобиль не так универсален, как «просто легковой автомобиль», и его холархия существенно отличается от холархии «просто легкового автомобиля», в ней отсутствует множество холонов, ответственных за разнообразие функций. Так что описанная работа с холархией специфична для каждого проекта, в системном мышлении нет ничего универсального, нет никаких универсальных рецептов.
Системный подход: для всех видов систем, не только для целевой
Системное мышление обладает свойством рекурсивности в его применении: оно похожим образом разворачивается для каждой из систем в обширных холархиях. Например, любая система встроена в какую-то системную холархию, не только целевая. Так что понимание того, что система это холон относится и к системе в операционном окружении, и подсистеме, и даже обеспечивающей системе.
Как-то специально выделять целевую систему нужно главным образом из-за необходимости помнить, что является коллективной целью, для работы в каких-то командных проектах. Это новинка системного подхода в его втором поколении, деятельностное введение целевой системы/system-of-interest – деятельный интерес ведь всегда чей-то, это и подчёркивается. Но различать определение системы и воплощение системы нужно для всех видов систем. Функциональное задание системы по её назначению тоже проводится для всех видов систем, для всех уровней холархии.
Ещё одно важное замечание – это что система какого-то вида обязательно одна, например, использующая система в проекте обязательно одна. Нет, целевая система вполне может входить в состав множества использующих систем, у которых может быть у каждой своя группа внешних стейкхолдеров. И обеспечивающих систем у одной целевой системы также может быть множество (скажем, одна компания проектирует здание, другая его строит, третья эксплуатирует, третья сносит – все эти компании будут обеспечивающими системами каждая). Конечно, можно всегда подчеркнуть эмерджентность/системный эффект, возникающий от того, что все эти компании работают в каком-то смысле совместно (и часто эта совместность оговаривается в договорах между этими компаниями), и сказать, что всё это не отдельные обеспечивающие системы, а подсистемы одной обеспечивающей системы, но это совсем необязательно.
Часто у менеджеров встречается ещё одна ошибка: попытка выделить типовую целевую систему, которой они занимаются в самых разных непохожих друг на друга проектах. При этом возникают серьёзные осложнения, поскольку использующие системы оказываются у этих систем совсем разные, поэтому получается невозможно обобщить разные потребности самых разных внешних стейкхолдеров для одной целевой системы.
Наличие нескольких холархий (как минимум, наличие в рассмотрении для якобы одной целевой системы различных использующих систем с их различными внешними стейкхолдерами) в рассмотрении должно настораживать: скорее всего, речь идёт не столько об одном проекте, а о нескольких. В этих случаях необходимо честно выделить разные проекты, скорее всего в этих проектах будут совсем разные ситуации, они потребуют разных инженерных, менеджерских, творческих решений, разного моделирования, взаимодействия с разными стейкхолдерами. Каждый раз, когда происходит обобщение, нужно задавать вопрос: какие вопросы станет легче решать при этом обобщении? Вполне возможно, что никакие – и лучше разворачивать системное мышление индивидуально в разных проектах, не пытаться из них сделать «суперпроект».
Читать бесплатно другие книги:
