Система – это продукт, или сервис?

 

Целевая система раньше часто мыслилась как поставляемый продукт.

Система как индивид изготавливается командой проекта, а затем поставляется его потребителю. И уже у потребителя этот продукт выполняет свою функцию, назначенное ему поведение в ходе эксплуатации.

 

Клиент использует продукт двумя способами:

• в составе своей целевой системы

(например, ваши часы-продукт он устанавливает в

свой автомобиль-продукт, а затем продаёт автомобиль

своему клиенту)

• в составе своей обеспечивающей системы

(например, ваши часы-продукт он устанавливает в свой цех

на стену, чтобы рабочие могли следить за временем в ходе

сборки ими автомобиля – продаёт же клиенту автомобиль

без часов или с какими-то другими часами).

 

Альтернативное представление продукта – это представление его как целевой системы, принадлежащей клиенту.

Но что тогда делает команда проекта?

Она предоставляет сервис (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) мужчины?

 

 

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

Признаком использующей системы в её отделении от целевой системы (а команде проекта обычно приходится иметь дело с обоими этими системами) является то, что команда не уполномочена как-то самостоятельно изменять саму эту систему или даже её определение (требования, архитектуру). Ещё десяток лет назад не предполагалось, что команда как-то может повлиять на использующую систему – она брала её в проект как данное, и должна была просто стыковать свою целевую систему с имеющимся системным окружением. Сегодня это не так: команда проекта не уполномочена изменять системное окружение непосредственно, но она может влиять на то, чтобы в целях согласования характеристик целевой и использующей системы использующая система была изменена – самостоятельно её стейкхолдерами, или командой проекта по согласованию со стейкхолдерами. Для этого команда проекта (внутренние стейкхолдеры) активно работает с внешними стейкхолдерами, влияет на них.

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

Ещё одна ошибка, когда использующая и целевая система называются одинаково. Холархии типа «А состоит из А и Б» недопустимы, может быть только «А состоит из Б и В» – и скорее всего эта ошибка не в том, что сама холархия в жизни какая-то неправильная, а просто неправильно выбраны имена для холонов. Например, «ячейка состоит из ячейки и прокладки». Подробное обсуждение показывает, что речь идёт о ячейке, которая состоит из корпуса и прокладки. «Жилая комната состоит из комнаты и интерьера». Подробное обсуждение показывает, что жилая комната состоит из помещения (строительной части, даже без отделки) и интерьера (в который входят даже приклеенные к стенам помещения обои).