Системное мышление vs мышление системами

"Системноинженерное мышление в управлении жизненным циклом" -- это материалы учебного курса TechInvestLab, который можно использовать как в ВУЗах (так, этот материал был использован в семестровом курсе 2014 года для пятикурсников межфакультетской кафедры технологического предпринимательства МФТИ в весеннем семестре 2014г.), так и в системах повышения квалификации инженеров и менеджеров (например, он был использован для организации четырёх дней тьюториала корпоративным университетом ГК "Росатом" зимой-весной 2014г. для участников программы Global Professionals, а также во ВНИИХОЛОДМАШе в ходе проекта повышения квалификации сотрудников). Материалы курса неоднократно обсуждались на заседаниях Русского отделения INCOSE и в SEMAT. Это черновые "рабочие" материалы, в которых пока не было уделено внимания гладкости и художественности изложения.

Практическую направленность курса гарантируют разбирательства с примерами из проектов проходящих этот курс. То есть материалы курса привязываются к практике и разъясняются в ходе преподавательской или консультационной работы (так называемый flip teaching -- "перевернутое обучение", т.е. лекционная/объяснительная работа преподавателя отсутствует, зато преподаватель/тьютор/консультант помогает выполнять упражнения -- т.е. помогает в "домашних заданиях"). Так что эти материалы никак не подходят для того, чтобы быть "самоучителем", они предполагают обязательную работу с преподавателем или консультантом.

---

Главная задача этого текста -- компактное представление минимально связного и компактного материала по системноинженерному мышлению. Специфика курса в том, что его содержание базируется не на постоянно отстающей от требований времени учебной литературе, а на международных стандартах системной инженерии, разработанных или обновлённых за последние примерно пять лет -- ISO 15288, ISO 42010, ISO 15926, ISO 81346, OMG Essence. Раздел инженерии предпринятия является факультативным и дан не столько для подробного изучения, сколько для ознакомления с тем, как изложенные принципы системноинженерного мышления могут быть применены к нестандартным для классической инженерии сложным системам.

---

Просьба присылать ваши замечания и предложения по поводу данных материалов

---

Анатолию Левенчуку (ailev@asmp.msk.su).

1. Системная инженерия

---

Курс "Системноинженерное мышление в управлении жизненным циклом" является

---

одной из двух частей курса "Введение в системную инженерию" (второй частью

---

будет "Практики жизненного цикла системной инженерии"). Так что перед тем,

---

как приступить к собственно изучению курса, необходимо будет разобраться с

---

тем, что такое системная инженерия.

---

Самое современное определение системной инженерии дано в Guide to the

---

Systems Engineering Body of Knowledge (руководство по корпусу знаний системной

---

инженерии,

---

http://www.sebokwiki.org/wiki/Guide_to_the_Systems_Engineering_Body_of_Knowledg

---

e_%28SEBoK%29).

Короткое определение: системная инженерия -- это междисциплинарный подход и способы обеспечения воплощения успешной системы. (Systems engineering is an interdisciplinary approach and means to enable the realization of successful systems). В этом определении можно подчеркнуть:

---

● Успешные системы -- это то, чем занимается системная инженерия. Слово "успешные" тут крайне важно и означает, что система должна удовлетворить нужды заказчиков, пользователей и других стейкхолдеров (стейкхолдеры -- это те, кто затрагивается системой, или кто затрагивает систему).

---

● Слово "системы" используется в очень специальном значении: это "системы" из системного подхода. TechInvestLab, 14 июня 2014 3

---

● Междисциплинарный подход -- системная инженерия претендует на то, что она работает со всеми остальными инженерными специальностями (впрочем, не только инженерными). "Подход" обычно означает какие-то наработки в одной предметной области, которые можно перенести на другие предметные области. Междисциплинарность -- это очень сильное заявление, оно означает, что системная инженерия может в одну упряжку впрячь коня и трепетную лань (например, инженеров-механиков, баллистиков, криогенщиков, психологов, медиков, астрономов, программистов и т.д. в проектах пилотируемой космонавтики).

---

● Слово "воплощение" (realization, "перевод в реальность") означает буквально это: создание материальной (из вещества и полей) успешной системы.

---

По-английски "системная инженерия" -- systems engineering, хотя более ранние написания были как system engineering. Правильная интерпретация (и правильный перевод) -- именно "системная" (подразумевающая использование системного подхода) инженерия, а не "инженерия систем" (engineering of systems) -- когда любой "объект" обзывается "системой", но не используется системный подход во всей его полноте.

Более длинное определение включает ещё одну фразу: Она фокусируется на целостном и параллельном понимании нужд стейкхолдеров; исследования возможностей; документирования требований; и синтезирования, проверки, приёмки и постепенного появления инженерных решений, в то время как в расчёт принимается полная проблема, от исследования концепции системы до вывода

---

системы из эксплуатации

---

(It focuses on holistically and concurrently understanding stakeholder needs; exploring opportunities; documenting requirements; and synthesizing, verifying, validating, and evolving solutions while considering the complete problem, from system concept exploration through system disposal). Тут нужно подчеркнуть:

---

● Целостность, которая подчёркнута многократно -- от

---

"междисциплинарности" в первой половине определения до целостности всех действий по созданию системы во второй половине определения, до целостности/полноты проблемы, до охвата всего жизненного цикла системы "от рождения до смерти". Целостность (полнота охвата), междисциплинарность -- это ключевое, что отличает системную инженерию от всех остальных инженерных дисциплин.

---

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

---

● Много особенностей, которые будут понятны позднее (различение нужд пользователей и требований, проверки и приёмки, упор на синтез для противопоставления "аналитическим" дисциплинам и т.д.). TechInvestLab, 14 июня 2014

---

4 Упражнение: посмотрите разные определения системной инженерии и найдите их сходство и различия

---

(http://www.sebokwiki.org/wiki/Systems_Engineering_%28glossary%29,

---

http://www.sie.arizona.edu/sysengr/whatis/whatis.html,

---

http://syse.pdx.edu/program/about.php и так далее -- погуглите, чтобы найти больше определений). Обратите внимание на разнообразие используемой в этих определениях терминологии.

Кто ответственен за правильность проекта, правильность выбранного решения? Системные инженеры в этих проектах: именно они должны придумать такие технические решения, чтобы при изготовлении, эксплуатации и последующем выводе из эксплуатации всех этих сложнейших проектов не было неожиданностей. И эти системные инженеры справляются -- каждый год сверхсложные проекты прошлых лет становятся просто сложными, а сложные проекты -- типовыми. Это не значит, что такие проекты, как полёт на луну или создание атомной станции становятся более простыми. Нет, не становятся: наоборот. Сложность этих проектов год от года растёт за счёт опережающего роста требований, прежде

---

всего требований безопасности.

---

Создавать такие сложные системы могут только большие многодисциплинарные TechInvestLab, 14 июня 2014 9 коллективы, которые требуют какой-то междисциплинарной организации в разделении умственного труда. Именно вопросы удержания междисциплинарной целостности и организации междисциплинарных работ и решает системная инженерия. Она:

---

● удерживает целое всего инженерного решения для самых разных стейкхолдеров. Это основной предмет курса "Системноинженерное мышление в управлении жизненном циклом"

---

● Использует практики системной инженерии для создания успешного решения. Это основной предмет курса "Практики жизненного цикла моделеориентированной системной инженерии" (тут нужно отметить, что классическая системная инженерия и моделеориентированная системная инженерия немного отличаются, но с течением времени вся системная инженерия станет моделеориентированной, и необходимость добавлять

---

слово "моделеориентированная исчезнет" -- но об этом позже).

---

Но почему системную инженерию назвали именно системной, а не какой-то другой инженерией? Потому как на сегодняшний день единственным способом удержать сверхсложное целое в междисциплинарных проектах является использование системного подхода, в котором термин "система" используется в специальном смысле, и который подразумевает специальное устройство мышления для применяющих системный подход людей.

Философская линия Гуссерля-Витгенштейна-Бунге гласит, что знание выражается фактами: мы ничего не можем сказать про объекты мира, представляя их понятиями языка, но мы можем представлять отношения объектов мира, представляя их выраженными в понятиях фактами. Следуя этой линии рассуждения, мы не можем давать определения отдельным понятиям, мы можем определять только совокупности понятий в их отношениях друг с другом. Так, для определения понятия "целевая система инженерного проекта" нужны другие TechInvestLab, 14 июня 2014 14 понятия ("стейкхолдер", "описание системы", "работы", "возможности" и т.д.).

---

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

---

Это означает, что в нашем курсе мы будем использовать диаграммы, отражающие основные факты об отношениях объектов в предметной области системного мышления, системной инженерии, ситуационной инженерии методов и других дисциплин. Рассуждения после этого будут строиться с учётом представляемых фактов.

---

В данном курсе мы будем мягко относиться к логической стороне дела и не будем требовать полностью формальных (понятных даже компьютерам) суждений, но следование в рассуждениях предлагаемым диаграммам ("схемам") необходимо. Иногда говорят про "схемное мышление" -- мышление, которое следует некоторым предварительно заданным понятийным схемам. Схемность мышления вовсе не означает ограниченность мышления. Оно означает просто, что объекты реального мира "подводятся под понятия" никогда не по одному, а соответствующими схемам группами, и между объектами реального мира предполагаются прописанные в схеме отношения.

Например, схема инженерного проекта предполагает набор из семи понятий:

---

---

Эта схема предполагает, что мы ничего не можем сказать, например, о "воплощении системы" -- но зато мы знаем факты "стейкхолдеры используют

---

воплощение системы", "команда производит воплощение системы", "воплощение системы удовлетворяет определению системы" и т.д. В любом рассказе затем о "воплощении системы" мы затем, следуя этой схеме, будем искать "команду", "стейкхолдеров", "определение системы" и т.д. -- под какими бы конкретными словами (терминами) они ни скрывались.

---

Конечно, может быть несколько схем (онтологических диаграмм, наборов фактов) с использованием одних и тех же объектов и отношений, эти схемы обычно используются для организации размышления об этих объектов и отношений в различных ситуациях или для рассуждений о различных аспектах одной ситуации.

---

Ситуация -- это когда нужно что-то делать, и нужно понять, что именно делать [кстати, обратили внимание, что в определении ситуации неявно присутствует понятие деятельности? Это и есть схемное мышление: трогаешь одно понятие, а через определение или через схему в рассуждение притягиваются другие связанные с ним понятия]

---

Те, кто знают схему -- это и есть "семантическое сообщество". Они знают, что "команда применяет технологии", как бы ни называлась "команда" (бригада, компания, рабочая группа", как бы ни произносилось "применяет" (использует, опирается на, задействует, владеет), как бы по-разному появлялись бы в речи TechInvestLab, 14 июня 2014 16 "технологии" (способы работы и инструменты, методы и их поддержка, производственная среда).

---

Знание курса предполагает не просто знание основных схем этого курса (запоминания онтологии предметной области), а умение рассуждать с использованием этих схем -- подводить объекты реального мира под понятия на схемах и вести рассуждение в терминах этих понятий.

Знания системной инженерии в голову укладываются ступенечками, от простого к сложному. Как выделить такие ступеньки? Что нужно тренировать в мозгу, какую непривычную мозгу мыслительную работу делать привычной? Тут я должен ввести понятие контринтуитивности. Мы живем в интуитивно понимаемом мире. Наши мозги ездят по интуитивным, невесть откуда взявшимся мыслительным рельсам в очень известном направлении, как трамвай – одним и тем же маршрутом. Мы родились, постепенно откуда-то у нас эти рельсы в мозгу проложились, и мышление по ним ездит, и ездит обычно мимо удобных способов решения задач, делая невозможным решение задач сложных.

---

Вот, посмотрел в окно – а там земля плоская. Когда мне говорят, что Земля круглая, я что отвечаю? Я говорю: «это неправда, посмотрите в окно». Мне отвечают: «вы что, Земля круглая, потому что если посмотреть за горизонт..., а я упорствую: «Вы мне рассказываете много всего лишнего, что там за горизонтом, за горизонтом я и сам вижу, что ничего нет. Вы мне про горизонт и что за ним, а я про Землю, вот же она – Земля плоская». Смотрите: вся моя жизненная интуиция показывает, что Земля плоская, я по ней хожу, вот этими ногами хожу и уж ноги-то точно знают, что Земля не круглая! Но каким-то людям, которых заботят масштабы не только 10 километров, но и 1000 километров, в голову откуда-то приходит мысль про «Земля – круглая», они начинают так мыслить.

---

Через некоторое время выясняется, что кроме Земли ещё и Космос с его вакуумом есть, космические корабли там летают «всё время падая, но никогда не падая». Вот это я уже понять не могу, потому что при идее плоской Земли летание космических кораблей по кругу с достаточной скоростью, чтобы не падать никогда – это понять невозможно. Мысль о круглой земле контринтуитивна, она соответствует «народной теории» (folk theory), она нетехнологична.

---

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

Гений почему-то, сам часто не осознавая, сделал что-то совсем не так, как все остальные, он просто начал что-то делать в противоречии с интуицией всех остальных, и у него начало получаться. А все остальные действуют интуитивно, «по-народному», «как все», и у них не получается. И пока на уровень сознания гения, или тех людей, которые пытаются отмоделировать мышление гения, не вышло, в чем именно эта контринтуитивность, вы не можете передать это знание другим людям, не можете никого этому научить.

---

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

---

нужны технологии, дающие неизменно превосходный результат.

---

Меня учили в детстве: никогда не работай с художниками, всегда работай с архитекторами. Почему, знаете? Художник – он всегда ждет вдохновения, у него вот такой подход к своему творчеству, и его именно так учат. А архитектор получает абсолютно то же самое образование в смысле всех творческих техник, но его приучают, чтобы он сдавал работы в срок, чтобы он учитывал техзадание, что нужно приходить на работу, а рабочий день начинается во сколько и заканчивается во сколько. С архитектором ты будешь уверен в результате, который будет соответствовать каким-то критериям качества, ожиданиям заказчика, и будет получен вовремя. А рисуют архитекторы обычно не хуже художника, так что и с этим всё в порядке.

---

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

Когда вы находите правильные объекты и правильные мыслительные операции, и правильные упражнения – то ученики после обучения даже не будут понимать, что им было трудно делать до обучения. Они будут неспособны вспомнить, по каким рельсам катилось их мышление до обучения, и поэтому они будут изумляться поведению необученных новичков, включая собственному поведению в период до освоения той или иной практики. Спросите моего ребёнка, почему он очень плохо умножал всего год назад – он не сможет объяснить, почему. Сейчас умножение для него вполне естественно, и не требует напряжения всех его умственных сил, как это было год назад.

---

Назовём это свойство прохождения какого-то порога понимания метанойей. Слово удивительное, попробуйте его написать в разных падежах, да ещё и во

---

множественном числе, получите очень интересные эффекты. Это слово пришло из религиозных практик и означает «перемену мыслей», полный разрыв прошлого и текущего мышления. Ты занимаешься, занимаешься в какой-нибудь семинарии, и вроде как мышление у тебя не так поставлено, как это ожидают от тебя священники. Потом вдруг в какой-то момент щелк – и ты демонстрируешь всем, что вот у тебя такое же мышление, как это принято у священнослужителя, с этого момента ты «настоящий», а не притворяешься. Вот слово это – метанойя, такой малый западный вариант просветления. Слово "метанойя" рекомендовал использовать и гуру менеджмента Питер Сенж вместо слова "обучение", ибо слово "обучение" с его точки зрения уже совсем затасканное и не означает коренную смену образа мышления в результате обучения.

---

Когда метанойя произошла, то в новом состоянии мозгов человеку совершенно непонятно, в чём была проблема в старом состоянии мозгов. Представим: я знаю, что земля плоская, я долго спорю, что земля никак не может быть не круглая, но меня в какой-то момент убеждают. И я каждый раз в своих действиях сначала действую, как будто земля плоская, потом усилием воли вспоминаю, что рационально вроде бы она должна быть круглая, потом делаю это уже на уровне рефлекса, и вижу тысячу свидетельств этой круглости Земли. И вот в этот-то момент я не могу понять, почему я считал, что земля плоская. Рационально-то вспомнить, что я так считал, я могу. Но понять, как я именно перешел из состояния знания «интуитивной теории» в состояние владения «контринтуитивной теорией» я не могу. И поэтому не могу осознать те учебные действия, которые нужны для того, чтобы я добивался этой метанойи круглости Земли у своих учеников. Работа по составлению правильных упражнений для такой метанойи – это трудная работа, и приведенные мной ниже примеры школьной алгоритмики, просветления, тайцзицюаня показывают, что создание адекватного учебного курса вполне может занять пару-тройку десятков лет, а то и тысяч лет. Это в полной мере относится и к системной инженерии.

Главная метанойя системной инженерии в том, что вы начинаете думать о мире, как состоящем из систем, и описываемом многодисциплинарно для каждой

---

системы. Это крайне контринтуитивно, поэтому требует специального обучения и последующей длительной тренировки такого системного мышления.

---

В математике термин "интуитивный" часто подменяется термином "тривиальное" -- возможность повторения "любым" в данном сообществе, а нетривиальность -- невозможность повторения (спасибо за обсуждение этого вопроса математику Роману Михайлову). Демонстрация интересного нетривиального делает его тривиальным через пару тактов тренировки заинтересовавшихся, ибо в определение "интуитивности/тривиальности" и "контринтуитивности/нетривиальности" неявно входит момент времени "прямо сейчас". Любое "контринтуитивное/нетривиальное" одного поколения становится "интуитивным/тривиальным" для другого поколения думателей.

---

Эту "тривиальность" вполне можно добавить в список синонимов к "интуитивности" (ибо использование "интуитивности" иногда идёт вразрез с бытовым пониманием и означает ровно наоборот -- "нетривиальность, полученную инсайтом, вдохновением, озарением").

---

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

---

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

Итак, в конце восьмидесятых стало очевидным, что в сложных технических устройствах завелось что-то трудноуловимое, что уже не охватывается мышлением среднего человека. Почему только тогда?

---

Вспомните 1985-й год, где в СССР были персональные компьютеры, хоть какие-нибудь? IBM PC выпускался на Западе только с 1980 года, в СССР его практически не видели ещё. Какого размера тогда были доступные компьютеры? Если не считать простейших калькуляторов, то самая маленька СМ-4 была размером со стенной шкаф. Но вычислительная мощность у неё была несопоставимо меньше, чем у меня сейчас в телефоне – в разы и разы меньше. Если взять разрешение экрана современного телефона, то в крупных научных институтах пикселей на экранов всех компьютеров, наверное, не хватало бы в 1985 году, чтобы сравниться с числом пикселей экрана этого карманного телефона.

---

Я уже молчу про цветные пиксели, тогда ещё экраны были главным образом монохромными. Компьютеры ставились в машинных залах с фальшполами, это был 85-й год. У меня самого СМ-4 была с номером 00047, в 1982 году. Это как раз вот 82-й год, а с сентября 85-го решением политбюро ввели информатику в школах СССР. До власти дошло, что что-то такое происходит в военной сфере именно потому, что компьютеров мало и простые солдаты недостаточно обучены для адекватной работы операторами сложной военной техники.

---

Принимались безумные решения по линии «догнать и перегнать», то есть не развивать свои разработки, великолепную машину БЭСМ-6, а «слизать» мейнфреймы IBM. В этот момент уже начали выпускать и мини-компьютеры. Та самая СМ-4 – это была копия PDP-11. Наши ЕС ЭВМ – это IBMsystem/360. И в этих условиях вся страна вдруг начала учить информатику.

---

Никто не знал, как её учить. В МГУ на мехмате собралась группа «Аттик», которая разработала вузовский учебник информатики, а затем разработала школьный учебник информатики и определила в нём, в чем, собственно это обучение информатике заключается. Выяснилось, что в голове среднего человека действительно нет сформированного куска мозга, умеющего выполнять вполне определенные операции, связанные с планированием действий в неопределенном будущем. То, что я сейчас вам буду говорить, это и есть вот настройка мозга на какую-то определенную деятельность. Мозг настраивается на деятельность, «становится на рельсы» -- и далее по этим рельсам привычно выполняет все необходимые операции.

Курс алгоритмики, который считался на тот момент курсом высшего образования, в существенной его части был опущен до уровня курса для седьмого класса. В те бескомпьютерные времена были легенды о соревнованиях между учениками, которых учили алгоритмике с компьютерами и без компьютеров. Выяснилось, что ученики тех классов, кто учили вот школьный алгоритмический язык без компьютеров (с доской, тряпкой и листочками бумаги), часто побеждали учеников тех классов, которые учились с компьютерами. Почему? Для алгоритмики важно, чтобы в голове были сформированы навыки правильных мыслительных операций, чтобы в голове проложились рельсы, по которым двигается мышление. А с инструментом, или без инструмента – для скорости мышления это уже неважно. То есть вам поставили какой-то особый тип мышления, и это мышление начало работать, вы можете решать задачи в какой-то предметной области. В случае алгоритмики вы можете разворачивать какие-то конструкции с ветвлениями, у вас в голове появляется понятие последовательности, понятие цикла, понятие ветвления, условного оператора, понятие логических переменных, сложных условий. И когда это всё у вас в голове есть, вам все равно, на каком языке писать, и какие именно алгоритмы или планы писать.

Выяснилось, что в обучении алгоритмике есть три существенных части, которые нужно учитывать. Первая часть – это, собственно, алгоритмическое мышление, это вот те самые рельсы в мозгу, которым нужно научить. Вторая часть – это синтаксис языка программирования, потому что алгоритм нужно как-то выражать, и без синтаксиса конктретного языка его не выразить. Третья часть – это необходимость работы алгоритмического мышления с объектами из какой-то среды, и поэтому учить на языках чисто процедурных нельзя, а надо подняться хотя бы на ступеньку так называемых «пакетных» языков типа Модула или Ада. Замечу, что речь даже не идет об объект-ориентированном современном программировании, это более элементарный уровень. Для школьного алгоритмического языка эта «пакетность» была сформулирована как необходимость наличия какого-то предметного мира, и связанного с этим миром исполнителя (а программное средство, поддерживающее этот подход назвали КуМиром – Комплектом Учебных Миров).

---

Раньше считалось, что учить алгоритмику нужно на примере математики. Люди из группы «Аттик» сказали, что нужно мир математики заменить на мир двигающегося на клетчатом поле робота с командами «вверх», «вниз», «влево», «вправо», «закрасить клетку». Я думаю, это многим знакомо, потому что я

---

рассказываю самый обычный школьный курс для седьмого класса.

---

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

---

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

---

И если раньше это называлось «школьная алгоритмика», то появляются первые работы, первые доклады об успехах, в которых закрепляется термин «дошкольная алгоритмика». Алгоритмика – это ведь не просто расхожая уже «информатика для малышей», понимаемая как крайне упрощенная «логика» с задачками типа «вот уточки розовые, уточки желтые, вперемешку, найди общий признак и рассортируй на две кучки». Да, нынешние учебники «Информатика» в большинстве своём вообще не содержат алгоритмики, которая про составление и записи планов действий в неопределенном будущем. В «дошкольной алгоритмике» дети реальные программы пишут, причем не все взрослые такие программы смогут написать, смогут решить предлагаемые дошколятам задачи. Почему? У этих взрослых в голове просто нет этих «рельсов для мышления» в части алгоритмики.

Когда с простейшим синтаксисом и учебным миром мы проходим ступенечку понимания с маленькими детками и кладём первый участок этих «рельс

---

алгоритмического мышления», то дальше оказывается возможным пройти и весь курс седьмого класса. Секрет был просто в облегчении прохождения маленькой первой части большого сложного курса. Дитенка не может сразу одолеть сложный текстовый синтаксис, сложный мир робота, понятия алгоритмики. А упрощённый синтаксис и упрощенный мир на меньшем числе операторов алгоритмического языка он одолеть может, и после одоления первой ступеньки этой лестницы сложности дальше легко проходится вся лестница – до самой её вершины. На это изобретение ушло двадцать лет, а без первой ступеньки вся лестница была недоступна.

---

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

В качестве примера можно взять программу магистерского курса системной инженерии, который даёт великобританский Loughborough University, всего в этом курсе 180 кредитов (условно можно считать, что один кредит -- это 10 аудиторных учебных часов плюс столько же на самостоятельную подготовку). Обратите внимание на обязательные предметы: системное мышление, системная архитектура, "мягкие" системы (системы, включающие в себя людей), системное конструирование/проектирование (в английском используется одно слово: design, создание трехмерной кострукции материальной системы) -- это всё вместе занимает 60 кредитов , и столько же времени отводится на обязательный индивидуальный учебный проект. Ну, и ещё 60 кредитов тратится на курсы по выбору (инженерные и менеджерские возможности, управление инновациями и предпринимательство, холистическая инженерия, проверка и приёмка, понимание сложности, датчики и приводы).

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

---

решает казалось бы неразрешимые проблемы.

---

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

---

(http://gothicsstyle.ru/2011/02/02/srednevekovaya-alximiya-recepty/)

---

Современное пояснение: "Философская ртуть -- свинец. Прокалив его, получаем массикот (желтую окись свинца). Это зеленый лев, который при дальнейшем прокаливании превращается в красного льва--красный сурик. Затем алхимик нагревает сурик с кислый виноградным спиртом -- винным уксусом, который растворяет окись свинца. После выпаривания остается свинцовый сахар -- нечистый ацетат свинца (чистый Рb (С2Н302) 2 · 3Н20--это бесцветные прозрачные кристаллы). При его постепенном нагревании в растворе сперва перегоняется кристаллизационная вода (флегма), затем горючая вода -- «пригорелоуксусный спирт» (ацетон) и, наконец, красно-бурая маслянистая жидкость. В реторте остается черная масса, или черный дракон. Это мелко раздробленный свинец. При соприкосновении с раскаленным углем он начинает тлеть и превращается в желтую окись свинца: черный дракон пожрал свой хвост и обратился в зеленого льва. Его опять переводят в свинцовый сахар и повторяют все вновь.

---

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

---

Классическая системная инженерия использует диаграммную технику -- это уже не вольные поэтические метафоры, как в алхинженерии, но много более строгие определения системы: чертежи, диаграммы, таблицы и т.д.. Но это не полностью формальное описание: его нельзя как-то формально проверить, оно предназначено для чтения и интерпретации только людьми. Если уподобить описание системы компьютерной программе по изготовлению системы, то это такая "программа", которую может выполнить только человек, но не станок-компьютер. Можно назвать это "псевдокодом": непосвящённый человек легко спутает псеводокод с компьютерной программой, но программист понимает, что псевдокод пишется для других людей, а не для компьютера. От псевдокода до реальной программы, реального формального текста на каком-то языке программирования примерно столько же работы, как от общего неформального понимания ситуации человеком до написания программы на псевдокоде.

---

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

---

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

Системноинженерное мышление коллективно

---

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

---

● Системный подход (как думать о системах)

---

● Ситуационная инженерия методов (как думать о деятельности)

Ситуационная инженерия методов

---

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

---

Описанием инженерной деятельности занимаются в рамках дисциплины "ситуационная инженерия методов". Она была основана идеологами объект-ориентированного движения, которые задали два основных структурированных (ибо неструктурированные в форме "просто книжки" никто не отменял) вида описания своих способов работы:

---

● использование "языков паттернов" (ищутся некоторые "паттерны" -- неформально определяемые способы решения задач, при этом каждый паттерн описывается по заранее известному шаблону, в который обычно входит описание проблемы и типовой способ её решения). Ассорти ссылок про языки паттернов тут:

---

http://ailev.livejournal.com/487783.html.

---

Паттерны -- это чистой воды эвристики, никаких попыток выйти на какие-то более-менее формальные "языки паттернов" не делалось. Само слово "язык" в

---

словосочетании "язык паттернов" используется неформально (просто чтобы указать на то, что в проекте используются разные паттерны в разных сочетаниях, как слова из какого-то языка).

---

● ситуационную инженерию методов, как дисциплина. Стандарты описания метода в такой дисциплине обычно представляет собой "мета-модель": описание языка, используемого для моделирования способов работы.

Настоящий курс системноинженерного мышления будет использовать адаптированный (существенно упрощённый, изменённый для работы с системноинженерными, а не софтверными проектами, а также переведённый на русский язык) стандарт OMG Essence. Этот стандарт разработан в рамках

---

инициативы SEMAT (http://semat.org).

---

Утверждение его происходит в консорциуме по стандартизации OMG (Object Management Group, http://www.omg.org).

---

Адаптация для системной инженерии проводилась TechInvestLab (http://techinvestlab.ru).

---

Обсуждение этой адаптации и перевода на русский язык проходило на заседаниях Русского отделения INCOSE (http://incose_ru.livejournal.com).

---

---

Это схема инженерного проекта, она же диаграмма альф инженерного проекта, она же диаграмма основ системной инженерии (systems engineering essence, от OMG Essence -- "основа", имени стандарта, где подобная диаграмма была предложена), она же диаграмма инженерной деятельности, она же онтология инженерного проекта.

---

На этой диаграмме основ отражены основные объекты, за изменением которых следит системный инженер, и которые всегда присутствуют в его мышлении. Это не "реальные предметы", это абстрактные сущности (типа "физическое тело", "химическая связь связь"), но с этими сущностями как раз и проводятся реальные размышления -- точно так же, как механик, вычисляющий траекторию выпущенной из ружья пули или летящей от пинка поручика Ржевского болонки абстрагируется от сущности летящих предметов и размышления свои ведёт в терминах "физического тела", про которое ему известны формулы.

---

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

---

Что мы обсуждаем по диаграмме альф инженерного проекта:

---

● О чём в проекте нельзя забывать

---

● Где границы инженерного проекта, отделяющие его от других проектов

---

● Кто в проекте за что ответственен

---

● Какие максимальные риски, которые на себя может взять команда и её отдельные члены

---

● В каком состоянии сейчас проект, что уже сделано и что нужно ещё сделать для получения успешной системы

---

● ... многое другое, ибо эта диаграмма отражает основные изменяющиеся в ходе проекта сущности и основные связи этих сущностей.

---

Рекомендуется эту диаграмму распечатать как плакат и повесить на стенку в том помещении, где работают системные инженеры. Это должно гарантировать, что при размышлениях о "воплощении системы" не будут забыты "стейкхолдеры", при обсуждении "команды" не будут забыты "технологии" и т.д.: схема задаёт некоторую мыслительную конструкцию, которой необходимо следовать в рассуждениях. Это не теория, использование данной схемы должно быть практикой.

Альфы -- это функциональные (выполняющие определённую функцию, играющие определённую роль, идеальные) объекты, по которым мы судим о продвижении (progress, "как много мы уже сделали?") и здоровье (health, "в проекте всё идёт хорошо") проекта. Альфы -- это абстракция того же сорта, какого "физическое тело" является абстракцией реальных физических объектов (да, это физическое тело имеет массу, а геометрическая точка имеет координаты.

---

Но мы связываем физические тела и математические точки как идеальные объекты с реальными объектами, и после надлежащего тренинга "склеиваем" в мышлении идеальные и реальные объекты. Поэтому об экземплярах альф в проекте принято говорить так, как будто они вполне реальны и существуют в мире, несмотря на все абстракции.

---

Альфы фиксируют компактное описание мира/теорию, удобную для решения каких-то практических проблем. Это нужно, чтобы иметь возможность повторно использовать известные нам способы рассуждений и решения задач для самых разных объектов. Так, мы думаем о "физическом теле" и "математических точках" единообразно, "как в учебниках физики и геометрии", а применимо это мышление к самым разным "реальным объектам вокруг нас" -- от летящей после удара ногой болонки до крутящегося по марсианской орбите космического корабля. В этой экономии мышления (учимся думать один раз, затем похоже думаем в самых разных ситуациях) и заключается смысл разделения альф и рабочих продуктов.

---

Например, учимся думать о "требованиях" -- а применяем потом это мышление к конкретным рабочим продуктам, которые можно найти на производстве "в реале": спецификациям требований, требованиям из текстов стандартов, user stories на карточках, записям в базе данных системы управления требованиями и т.д..

---

Несмотря на всю "идеальность" и "абстрактность", об альфах говорят как о вполне существующих в физическом мире -- поразумевая при этом их тождественность тем рабочим продкутам, по которым мы можем судить об их существовании. Так, можно определить альфу "моя любимая игрушка" -- и, хотя в детстве у меня это был нарисованный на ватмане пульт управления космическим кораблём, а сегодня это мой ноутбук, я могу говорить про прохождение "моей любимой игрушкой" состояний "полюбил", "разлюбил", "поломалась", "играю", "забросил" и т.д. -- независимо от того, какая именно это игрушка прямо сейчас. Если я говорю о "требовании" -- то меня не волнует, пункт ли это протокола совещания с представителями заказчика, или запись в базе данных системы управления требований, или фрагмент диаграммы какой-то модели требований. Для меня это "требование" -- и я после этого знаю, что с ним делать, и как о нём думать, я обсуждаю "требование" как реальный объект, существующий в мире, имеющий своё состояние и меня в этот момент мало волнует, что у этого требования есть ещё и какие-то особенности выражения (как при счёте яблок меня мало волнует, что их ещё и едят).

---

Формально ALPHA это Abstract-Level Progress Health Attribute, но неформально это просто "идеальный рабочий продукт", названный "альфой" для уменьшения путаницы с "реальными рабочими продуктами" и аббревиатура для него была подобрана задним числом. Альфы -- это то, что изменяется в проекте, и изменения чего мы хотим понимать, отслеживать, обеспечивать, направлять, контролировать.

Экономия мышления заключается в том, что часто одна альфа представляет до десятка разных рабочих продуктов. Обсуждение и мышление тем самым ведётся только для одного объекта, и только при разбирательстве с какими-то конкретными деталями вытаскиваются отдельные рабочие продукты.

---

Например, "воплощение системы готово к проведению пуско-наладочных работ?" -- в то же время доказательство готовности воплощения системы к пуско-наладочным работам может быть разбросано (кроме факта наличия самих рабочих продуктов, представляющих воплощение системы "в металле") по десяткам разных рабочих продуктов: документов типа актов сдачи работ различными подрядчиками, актов предварительных испытаний, писем контрагентов, записей в базах данных систем управления активами предприятия, сообщений о наличии расходных материалов и т.д.

---

Альфы обозначаются значком, напоминающим альфу (в диаграмме Основ системной инженерии именно эти значки), со вписанным названием альфы.

Семь основных альф инженерного проекта

---

Основы системной инженерии: альфы инженерного проекта

---

Основы (kernel из OMG Essence) включают в себя семь альф трёх дисциплин. Все эти альфы тесно связаны друг с другом, на диаграмме приведены лишь некоторые основные связи. Нужно чётко понимать, что представление инженерного проекта через эти основные альфы -- это существенное огрубление реальности. Но именно это огрубление реальности позволяет из "цветущей сложности" выделить главное, на чём нужно будет сосредоточить мышление -- какие-то детали при этом неизбежно потеряются, но ситуация "слона-то я и не заметил" будет встречаться реже. В каждом инженерном проекте минимально нужно отслеживать семь альф в трёх дисциплинах, меньше объектов внимания и дисциплин работы с ними иметь нельзя.

---

Это отслеживание и работа по изменению всех семи основных альф происходит в течение всего проекта. Когда в проекте происходит "пожар", люди работают по ночам и всё внимание уделяется провальной составляющей проекта, знание этого простого факта -- необходимости удержания во внимании всех семи альф на протяжении всего проекта -- позволяет уберечься от "глупых ошибок".

Стейкхолдеры

---

Никаких инженерных проектов не происходит, если нет их выполняющих людей. Инженерные проекты затрагиваются самыми разными людьми, и инженерные проекты затрагивают самых разных людей. Эти люди могут быть как "одиночками", так и организованными в группы, в том числе организованные в группы с известным им распределением полномочий (организации). Эти люди, группы и организациии, которые затрагивают проект, или которых затрагивает проект, называются стейхколдерами (stakeholders/заинтересованные стороны. Перевод "заинтересованные лица" не так хорош, ибо этот термин закреплён в законодательстве за юридическими лицами и при общении с менеджерами-юристами и экономистами возможна путаница).

---

Стейкхолдеры -- это "действующие лица" как в театре) проекта, а исполнители этих ролей -- конкретные люди и организации. Мы назовём это "театральной метафорой", при работе со стейкхолдерами всегда нужно помнить формулировку из театральной программки: "действующие лица и исполнители". Нельзя путать "архитектора" и "Василия Петровича" -- так же нельзя, как нельзя путать "принца Гамлета" и исполняющего его роль "Василия Петровича".

---

Стейкхолдеры условно делятся на "внешних" и "членов команды". Стейкхолдеры дают возможности (opportunity) для проведения инженерного проекта: если

---

проект никого не затрагивает (никому не нужен), то его попросту невозможно делать. Если команда может делать проект, но пользователям он не нужен, то такого проекта не будет -- разве что члены команды будут работать бесплатно, и будут исполнителями также и в других ролей (инвесторов, владельцев, пользователей, клиентов и т.д.).

---

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

---

Простейший рабочий продукт, отражающий альфу "стейкхолдеры" -- это список стейкхолдеров. Из информационных систем со стейкхолдерами работают CRM (customet relationship management).

---

Специально нет никаких особых дисциплин, которые позволяют работать со стейкхолдерами, но можно выделить:

---

● Конфликтологию (например, метод "принципиальных переговоров" или "гарвардский метод" -- найдите в Сети литературу по этому вопросу), чтобы снимать противоречия между требованиями различных стейкхолдеров.

---

● Коммуникации (communications) для налаживания продуктивного диалога со стейкхолдерами

---

● Особые техники представления стейкхолдеров (например, "метод персонажа" из книжки Алана Купера "Психбольница в руках пациентов" --

---

http://rutracker.org/forum/viewtopic.php?t=1227489, который обобщается с пользователей на любых других стейкхолдеров --

---

http://praxos.ru/index.php/%D0%98%D0%B4%D0%B5%D0%B0%D0%BB%D1

---

%8C%D0%BD%D1%8B%D0%B9%D0%90%D0%BA%D1%86%D0%B8%D0%

---

BE%D0%BD%D0%B5%D1%80).

Возможности

---

Сам инженерный проект начинается с появления возможностей (opportunity) по его проведению -- это обстоятельства, которые делают возможным разработку (или доработку -- изменение уже имеющейся) системы. Наличие возможности существенно зависит от времени ("окно возможностей" -- период времени, в течение которого существует возможность выполнения проекта).

---

Возможности прежде всего характеризуют пользовательские потребности (пользовательские нужды, user needs -- то, что хотят пользователи такого, для

---

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

---

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

---

Эти возможности описываются целым рядом возможных рабочих продуктов: "бизнес-планом", "концепцией", "интервью пользователей", "обоснованием

---

инвестиций" и т.д.. -- в этих рабочих продуктах обосновывается польза разным стейкхолдерам от выполнения инженерного проекта, ибо если нет обоснованных возможностей, то выполнение инженерный проекта не приносит пользы, а приносит вред (например, убытки для инженерной компании).

---

Из задействуемых для изменений в состоянии возможностей дисциплин нужно указать прежде всего:

---

● Маркетинг и продажи, стратегирование и предпринимательство -- для установления user needs);

---

● Управленческий (финансовый) учёт -- для обоснования прибыльности. Конечно, в возможностях важны не только нужды/потребности/ожидания пользователей (user needs), но и нужды/потребности/ожидания/ и остальных стейкхолдеров. Как вы помните, успешная система (точнее, воплощение системы) -- это та, которая реализует возможности, т.е. отвечает нуждам/потребностям/ожиданиям стейкхолдеров инженерного проекта.

Определение системы

---

Перед тем, как сделать любую систему, её нужно определить (define), ибо нельзя сделать то, что "неопределено" (задача "пойди туда, не знаю куда, найди то, не

---

знаю что" -- это больше ведь исследовательская задача, а не инженерная. Чтобы воплотить в нашем четырехмерном пространстве-времени какую-то систему,

---

нужно как минимум иметь представление об этой системе, "определить" её). Альфа "определение системы" (system definition) служит как раз для этой цели. У альфы определения системы (system definition) главные подальфы (части) прежде всего:

---

● Требования (описание назначения системы в её операционном окружении. Требования определяют систему как "чёрный ящик")

---

● Архитектура (набор ключевых инженерных решений/decisions по тому, как будет устроена система -- описание "прозрачного ящика". Изменение каждого из архитектурных решений на поздних стадиях проектирования ведёт к существенному перепроектированию всей системы).

---

● Неархитектурная часть проекта (все остальные решения/decisions, т.е. изменение которых на альтернативные не приводит к существенному перепроектированию всей системы)

---

С определением системы работает прежде всего наука: если какая-то часть системы (или аспект системы) определены, то это означает, что выбран

---

соответствующий метод описания. Наука -- это как раз про создание методов описания. Научное знание позволяет определять системы, описывать их в рабочих продуктах -- описаниях (descriptions). Но, конечно, определять и описывать системы можно и на основе эвристик, не прибегая к научному знанию.

---

Более того, переход от определения системы (идеального объекта) к описанию системы (материальному объекту) возможен с использованием нотационной инженерии -- т.е. для записи определения системы как "мыслей по поводу системы, свойств системы" можно создать инженерный артефакт: нотацию.

---

Итого: определение системы -- это про биты, про информацию, про то, как мы говорим о системе. Основные дисциплины работы над определением системы -- это проектирование и конструирование. Альфой определения системы занимается системный инженер.

Воплощение системы

---

Воплощение системы (system realization, буквально: вынос в реальность) -- это четырехмерное воплощение системы в нашем материалом мире, это про

---

организованные в пространстве-времени хитрым образом вещества и поля, атомы (а не биты!). Это не про информацию о системе, это сама система.

---

Конечно, воплощение системы будет называться везде по-разному:

---

● У конструкторов это чаще всего "изделие" или "продукт" (product)

---

● У проектантов это часто "установка" (plant)

---

● У проектантов очень крупных объектов (например, атомных станций) это "сложный инженерный объект"

---

Мы принимаем, что когда мы пишем название системы ("насос"), то мы имеем тут ввиду сам насос как он есть в реальном мире, а не описание насоса (рабочий продукт определения системы).

---

Пользователям прежде всего нужно воплощение системы, для получения воплощения системы и создаётся инженерный проект. Очень часто говорят об инженерном проекте по создании сервиса -- например, "сервис стрижки волос". Но это не должно смущать: на самом деле это не проект по созданию сервиса, а проект по созданию системы, оказывающей сервис, например, "парикмахерская", которая будет оказывать "сервис стрижки волос".

---

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

---

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

---

Воплощение системы удовлетворяет определению системы. Основная дисциплина работы над воплощением системы -- это производство. Альфой воплощения системы занимается системный инженер.

Команда

---

Команда (team) инженерного проекта -- это не просто какие-то люди или организации (группы людей с оборудованием и известным распределением

---

полномочий). Это люди с совершенно определённым набором компетенций, нужных для реализации проекта, при этом речь идёт не только об инженерных, но и о менеджерских и других прикладных компетенциях.

---

Команда создаёт определение и воплощение системы, команда выполняет работы, команда применяет технологии (практики, поддержанные инструментами).

---

Команда должна работать как слаженный коллектив, для этого её нужно организовать из отдельных составляющих её людей. Для того, чтобы каждый

---

человек занял своё место на логистическом "конвейере" (ибо если какие-то места на этом "конвейере" не будут заполнены людьми, то целевая система просто не

---

сможет выпуститься -- необходимые на этом рабочем месте работы не будут произведены), нужно его "уговорить". Это функция "комиссара", пропагандиста, специалиста по менеджерской дисциплине "лидерство" (leadership). Лидер выполняет работы, которые можно описать двояко (помним, что это два разных описания одной и той же деятельности):

---

● Убалтывает исполнителей ролей команды играть в этой команде необходимые роли (убалтывает путать "личное" и "общественное").

---

● Осмысляет жизнь исполнителей ролей тем, что они приносят стейкхолдерам пользу, их жизнь и работа имеют значение для окружающих.

Работы

---

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

---

● учитывать во всём их содержательном разнообразии, чтобы ответить на вопрос "что делать"

---

● Планировать (schedule), т.е. предлагать распределение этих работ во времени и приписывание этих работ исполнителям.

---

● Определять достаточность ресурсов и контролировать выполнение плана работ для понимания того, вовремя ли работы будут закончены (т.е. не закроется ли окно возможностей раньше того момента, когда эти возможности будут удовлетворены результатом проекта) С точки зрения операционного менеджера вся организация представляет собой набор рабочих мест/станций, на которых требуемые проектом различные ресурсы (люди, инструменты, расходные материалы) задействованы для выполнения содержательных работ, а также продукты работ движутся между этими рабочими

---

местами/станциями.

---

У того, кто занимается работой, мышление представляет проект как некоторую трубопроводную сеть, по которой текут (flow, но по-русски тут будет "идут", "проходят") работы, материалы, люди, информация так, что из "входного" информационного, человеческого, материального сырья получаются "выходные" воплощения системы -- а обратным ходом текут/идут/проходят вырученные за воплощения системы деньги. Это логистическое, операционное мышление.

---

Из дисциплин, которые работают над альфой "работа", можно указать:

---

● Операционный менеджмент (из Lingvo: operations management -- управление операциями [производством]. Управление производственным процессом фирмы, в отличие от стратегического менеджмента, управления персоналом и других составных частей управления организацией; исторически первое название этой деятельности production management было изменено на operations management, т.к. по сути "производство" существует практически во всех организациях, и в том числе в сфере услуг, страховании, банковском деле и т. д., а слово production ассоциируется лишь с материальным производством).

---

На английском языке общепринятое определение проще -- Operations Management is the process by which an organization converts inputs (e.g. labor, material, knowledge, equipment) into outputs (goods and services).

---

На русском языке наиболее часто используется до сих пор старая форма "управление производством" и много реже "управление операциями" или прямая калька "операционный менеджмент".

---

"Исследование операций" и даже "теория массового обслуживания" также довольно частый термины, хотя под ними чаще имеется ввиду использование специального математического аппарата для расчёта времени работы.

---

● управление цепочками поставок (supply chain management)

---

● управление проектами (project management), управление процессами (process management), ведение дел (case management)

---

● планирование и управление производством (planning and production management)

---

● логистика (logistics)

---

● операционная стратегия (operation strategy)

---

● управление сервисными операциями (management of service operations)

---

● улучшение производительности (performans improvement)

---

● планирование ресурсов предприятия (enterprise resource planning) и управление ресурсами (resource management)

---

● get things done (GTD) -- система персонального планирования, "как доводить дела до конца"

---

Вот один из видов рабочих продуктов, отражающих альфу "работы" (это простейший issue tracker):

*Технология

---

Дисциплина -- она в головах. Но в организации есть технология: поддержанный необходимыми рабочими продуктами и инструментами способ работы (way of working). Практика = дисциплина+технология (метод = полный набор дисциплин и технологий для выполнения какой-то работы).

---

Технология существенно зависит от состава выполняемых работ (технология пошива обуви не нужна при проектировании медицинской аппаратуры анализа крови, и наоборот), технология требуется для команды (компетенция проектирования в 2014 году не может быть реализована без компьютеров с установленными на них информационными системами САПР -- системами автоматизации проектирования, системами инженерных мультифизических расчётов, системами управления жизненным циклом PLM/product lifecycle management). Бессмысленно привлекать в команду человека и одновременно не

---

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

---

Управление технологиями (каждая из которых имеет свои плюсы и минусы и требует для своего использования людей в команде с разными компетенциями) это отдельная дисциплина инженерного менеджмента. Удивительно, но люди часто не задумываются о тех технологиях, которые они используют. Что будет, если бригаде землекопов дать экскаватор?

---

*Они потратят целый день на то, чтобы отвинтить "лопату" от экскаватора, а потом попробуют организовать бригаду лопатодержателей, ибо одному человеку трудно будет управляться с такой большой лопатой! Ну, и затребуют пару сотен килограмм изоленты: обмотать неудобную ручку у этой огромной лопаты. А остальное (кабину, двигатель, систему тросов, гусеницы) выбросят: землекопы не знают, для чего все эти лишние детали, привинченные к лопате. Так что инструменты поддерживают те или иные дисциплины, а исполнители должны быть компетентны в использовани инструментов и дисциплинированы в своём мышлении.

---

Упражнение: Какие технологии используются в вашем проекте? Приведите три примера и для каждого дайте пару альтернативных технологий (например, 3D-моделирование с использованием Autodesk Inventor вместо 2D-моделирования в Autodesk AutoCAD или порождающего проектирования/generative design в специально написанном программном средстве).

3. Системный подход

---

Понятие "подхода"

---

"Подход" -- это когда разработанные в рамках одной дисциплины приёмы работы (в том числе приёмы мышления) переносят в какие-то другие области.

---

Очень часто "подход" является синонимом "практики" или даже "метода" (помним, что в разных речевых сообществах слова "практика" и "метод" отнюдь не используются в точных терминологических значениях, в отличие от нашего курса -- тем не менее, общее сходство в их значениях несомненно).

---

Слово "подход" означает обычно, что какие-то "практики" или даже целый "метод" работы были отработаны в какой-то одной предметной области, отрефлектированы (т.е. явно описаны в отрыве от предметной области, на объектах которой они отрабатывались), а затем перенесены туда, где раньше они не использовались. Так что использование слов "подход" или "метод" по большей части ситуативно: научный подход вы используете при описании какого-то фрагмента реальности или научный метод -- это не так важно.

---

Все поисковые системы подразумевают синонимичность подхода (approach) и метода (method). Если вы будете искать "научный подход", то вам покажут "научный метод": перенос методологического знания из одной предметной области в другую по мере развития ситуационной инженерии методов становится обыденным. Тем самым и саму системную инженерию можно считать "подходом", если мы придём с её практиками и методами в те области, в которых она раньше не использовалась -- например, будем использовать системную инженерию при создании искусственных живых организмов или наноботов.

---

Ну, или "подход системной инженерии" уместно говорить в ситуациях, когда мы пытаемся от советских инженерных методов перейти к методам системной инженерии.

---

В самой системной инженерии используется "системный подход", и можно найти множество других "подходов", например, архитектурный подход (где методы архитектурной работы распространились из традиционной архитектуры на работу со сложными техническими системами и даже программными системами).

Системный подход

---

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

---

Есть много легенд, почему системная инженерия взяла на вооружение системный подход. Вот одна из них в вольном пересказе:

---

Когда два суперсложных проекта 20 века попытались объединить -- речь идёт об американских "Манхэттенском проекте" создания атомной бомбы и проекте разработки баллистических ракет как средства доставки получаемых бомб -- совокупная сложность проекта, подразумевающая учёт в одном проекте результатов работы множества дисциплин, перестала умещаться в одной голове "генерального конструктора".

---

В те далёкие времена, когда самолёты назывались по имени генерального конструктора-гения (все эти "мессершмиты" и "ильюшины"), встретились

---

задачи, которые по сложности выходили за возможности конкретного гения овладеть множеством разных дисциплин, и нужно было выработать какой-то отчуждаемый от гениального человека способ совладания с этой сложностью. Тогда вспомнили, что инженеры-иммигранты с заводов "Мерседес-Бенц" используют для своей работы "системный подход", который они позаимствовали у биологов, изучавших биогеоценозы -- сложнейшие биологические системы, затрагивающие уровень сложности выше, чем сложность отдельного организма. Этот "системный подход" -- использование мышления в терминах систем -- появился в инженерном деле и после этого уже было не сложно наращивать сложность разрабатываемых систем, не опасаясь выхода этой сложности за пределы одной гениальной головы.

Системный подход с его вниманием не только к частям, но и целому (холизм) противопоставляется прежде всего редукционистскому подходу. В редукционистском подходе (часто неявно) утверждается, что мы должны дать детальное "научное" (то есть в рамках определённого научного предмета) описание любого объекта, просто повышая уровень его детальности при любых встречающихся затруднениях, сводя изучение целого к изучению его отдельных частей.

---

Но почему представители системного мышления называют это"редукционистским" подходом? Потому как доктрина редукционизма полагала, что любое "высшее проявление" можно свести к "низшему, в частях системы", если постараться. Бег зайца можно свести к химическим реакциям в молекулах зайца, то есть заяц сводим к его химии. Или атомная электростанция сводима к набору атомов физических элементов, которые нужно только собрать в правильные места в пространстве.

---

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

Системное мышление (system thinking) -- это приложение системного подхода к решению практических задач. Так, системная инженерия -- это приложение системного подхода к решению инженерных задач. Этот вариант системного мышления мы будем называть системноинженерным мышлением.

---

Еесть и другие варианты системного мышления, ибо существует множество разновидностей системного подхода, значительное число этих разновидностей посвящено попыткам разбирательства с системами из людей

---

(см., например, обзоры http://www.situation.ru/app/j_art_1052.htm и

---

http://rudocs.exdat.com/docs/index-421147.html?page=8

---

-- при этом помним, что systems engineering до середины 80-х годов по-русски переводили словом "системотехника", которое и использовано в этих обзорах).

---

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

Варианты системного подхода

---

Есть огромное число вариантов системного подхода, каждый из них по-своему определяет систему и развивается на базе разных областей деятельности:

---

● Биологии. Например, http://en.wikipedia.org/wiki/Systems_biology -- Systems biology is a biology-based inter-disciplinary field of study that focuses on complex interactions within biological systems, using a holistic approach (holism instead of the more traditional reductionism) to biological and biomedical research. Particularly from year 2000 onwards, the concept has been used widely in the biosciences in a variety of contexts. One of the outreaching aims of systems biology is to model and discover emergent properties, properties of cells, tissues and organisms functioning as a system whose theoretical description is only possible using techniques which fall under the remit of systems biology. These typically involve metabolic networks or cell signaling networks. Systems biology makes heavy use of mathematical and computational models.

---

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

---

● Экологии (http://en.wikipedia.org/wiki/Ecology -- помним, что одно из основных понятий экологии это "экосистема", а принцип -- тот же противопоставляемый редукционизму холизм).

---

● Менеджменте и теории организации (довольно старый обзор, но на русском языке см. В статье М.С.Джексона "Системному мышлению в менеджменте -- 50 лет" -- http://cyberleninka.ru/article/n/sistemnomu-myshleniyu-v-menedzhmente-pyatdesyat-let). Учитывая то, что системная инженерия всё больше и больше от создания успешных физических систем переходит к созданию успешных киберфизических систем, а современный тренд в ней -- переход к созданию киберфизикосоциальных (cyber-physic-human) или иначе социотехнических (sociotechnical) систем, внимание системных инженеров к этому направлению системного движения сейчас очень велико.

---

Кстати, обратите внимание, что слово governance по традиции в статье переводится как "управление". Пожалуй, его более точно переводить как "контроль" (в смысле "невозможности вырваться из-под контроля"). Так, corporate governance это про то, как организацию держат подотчётной собственникам, и менеджерам и сотрудникам не дают самоуправничать в ней. Поэтому "theory of governance" на первой странице статьи по ссылке -- это про теорию "удержания под контролем собственника".

---

● Исследование операций (теория массового обслуживания, производственное планирование и т.д. -- http://en.wikipedia.org/wiki/Operations_research).

---

Когда-то в классической книжке Л.Берталанфи по общей теории систем он определил в качестве прикладных областей использования системного подхода (общей теории систем в широком смысле) системную инженерию, исследование операций и инженерную психологию. Исследование операций по факту это часть менеджмента (иногда говорят, что использование идей исследования операций это "научный менеджмент"), но должна быть очевидна связь системного движения и этой дисциплины.

---

● Системная инженерия -- приложение идей системного подхода (использование системного мышления) в инженерной деятельности.

---

● Множество других использований. Постепенно системный подход становится основным способом представления знаний о мире. То, что мир состоит из систем, становится общепринятым, и поэтому иногда говорят про системный подход как современную онтологию (онтология -- это как раз ответ на вопрос "каков мир? Что в нём есть?". Ответ системного подхода -- мир системен, в нём есть системы).

Развитие системного подхода проходит в рамках так называемого "системного движения". От другого рода организованностей (например, научных школ, профессиональных сообществ, научных дисциплин и т.д.) "движение" (movement) отличается отсутствием координационного центра при полной автономии входящих в него групп, разнообразием форм организации и деятельности, отсутствием какого-то явного механизма согласования целей и форм обмена опыта.

---

Тем не менее, при полной независимости участников движения друг от друга, свободе и автономии в выборе ими целей и методов работы, все участники движения обнаруживают некоторую общность (в нашем случае -- общность использования системного подхода для задач в своих предметных областях, развитие системного мышления на материале своих предметных областей).

Термин "система"

---

Термин (слово) "система" используется минимально в трёх различных смыслах, которые следует различать:

---

---

1. Для обозначения понятия "система" из системного подхода (мы тут будем главным образом использовать варианте системного подхода, наиболее типичный для современной системной инженерии). Увы, это не самое частое использование слова. В системном подходе система определяется как иерархия холонов -- холархия. Иерархия -- это структура из дерева отношений похожих элементов. В холархии как виде иерархии это отношения "часть-целое", а элементы этих отношений называются "холон" (holon) -- по предложению Артура Кёстлера. Холон -- это что-то, что является одновременно целым для своих частей и само является частью для какого-то объемлющего целого. Система -- это холон, у которого есть появляющиеся (emergent) свойства, получающиеся от взаимодействия его частей.

---

"Эмерджентность" -- это главное свойство системы: "целое больше, чем сумма его частей". Часы больше, чем сумма их шестерёнок или микросхем. Часы могут показывать время, а шестерёнки или микросхемы времени показывать не могут. Обязательно нужно добавить, что в системной инженерии холоны представляют собой индивиды, имеющие пространственно-временную протяжённость (extension, "основные свойства любой вещи -- длина, ширина, высота: место, занимаемое в пространстве" как сформулировал Декарт, а современная физика добавила к этому протяжённость во времени -- системы занимают место в четырехмерном пространстве-времени). Простой критерий: индивиды (а, следовательно, и системы) можно "пнуть" (kick) или "погрузить в тачку".

---

Для контраста посмотрите, как обсуждают холон гуманитарии не-инженеры: , http://en.wikipedia.org/wiki/Holon_%28philosophy%29. Дальше мы будем обсуждать главным образом системы из системного подхода в варианте системной инженерии.

2. "Система" из систематики -- различные классификационные (таксономические) "системы". Это тоже иерархии, но элементами в них являются классы (множества), отсюда и название -- классификаторы. Между классами в классификациях отношения специализации (класс-подкласс: подкласс это специализированный класс). Классифицируются в конечном итоге индивиды, которые связаны с классом отношением классификации.

---

Конечно, в системном подходе системы часто классифицируются по самым разным признакам, но нужно помнить, что "система классификации" -- это не система из системного подхода, там нет эмерджетности, нет отношений часть-целое и холонов.

---

Класс (множество) центробежных насосов это не часть класса насосов как целого, а специализированный класс насосов. Все классифицированные как насосы индивиды не взаимодействуют между собой, порождая новое свойство. Они просто "сгруппированы в уме", так как похожи друг на друга (все они -- насосы).

---

Классификаторы и таксономии -- это предмет систематики, а не системного подхода. Системы из инженерного системного подхода классифицируются "системами" из систематики.

---

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

---

Хотя и тут опытный глаз сможет уловить какие-то "части-правила" и эмерджентность "целой системы", демонстрирующей в целом наборе правил что-то большее, чего нет в каждом отдельном правиле.

---

Но нужно помнить, что скорее всего, ни при создании всех этих "систем", ни при попытках их как-то понять и проанализировать никакого системного мышления не использовалось. В настоящем курсе системноинженерного мышления мы будем настаивать, что любая система -- это материальный (из вещества и полей) объект, и уж точно не набор правил, не абстрактный объект типа "множество".

Холархии

---

В холархии (иерархии холонов, отношения "часть-целое", показаны на диаграмме линиями с ромбиками на конце "целого") каждая система сначала характеризуется своей основной функцией в качестве части надсистемы, а уж только затем --из каких она состоит частей, какая у нее конструкция, как она устроена.

---

Правильно задавать сначала вопрос "в какой надсистеме какую функцию выполняет наша система" и пока нет ответа на этот вопрос -- пытаться найти ответ на этот вопрос прежде всего.

---

Более того, системным инженерам рекомендовано сознательно откладывать понимание внутреннего устройства системы до того момента, как они поймут устройство надсистемы -- т.е. пока не разберутся, в каком операционном окружении будет находиться их целевая система, зачем она нужна надсистеме, какая функция целевой системе в её операционном окружении.

---

Это очень трудно, это нужна особая постановка мышления, чтобы вместо того, чтобы говорить "часы состоят из шестерёнок и пружинок" или "часы состоят из чипа, батарейки и дисплея" говорить "часы служат для показа времени на спортивных соревнованиях для 40 тысяч зрителей" или "часы служат для демонстрации высокого социального статуса их владельца, а заодно уж пусть показывают время".

---

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

Театральная метафора.

---

Деятельность -- это в чём-то повторяющиеся работы с похожими объектами. Деятельность ведут стейкхолдеры с системами. Одно уникальное действие -- это не деятельность. Один конкретный человек -- это не стейкхолдер. Деятельность мы описываем как бы "безлично", в культурно-обусловленных типах участвующих объектов, субъектов, действий/операций.

---

Проще всего обсуждать деятельность как своего рода театральную пьесу, которую разыгрывают по ролям в разных театрах. Несмотря на огромную разницу в интерпретации этих ролей актёрами и их режиссёрами в разных театрах, и даже в одном театре в разные дни, всё-таки есть огромный смысл обсуждать сами пьесы ("методологическую действительность", methodology realm), а не только их отдельные исполнения ("действительность предпринятия", endeavour realm). Театральная метафора сравнивает деятельность с пьесой, практики и даже целый метод -- со сценарием этой пьесы. Пьеса играется много раз, деятельность повторяется много раз -- хотя каждое исполнение пьесы и каждое действие в чём-то уникальны, но мышление экономится за счёт "выноса за скобки" всего того, что повторяемо.

---

Знание принципов освобождает от знания фактов (тут можно указать на интересную книжку "Программистский камень" http://progstone.narod.ru/reciprocality/r0/index.html -- там людей делят на "картостроителей" и "паковщиков" ровно на этом основании: строят ли они карту "принципов", или запоминают каждый отдельный встреченный маршрут, т.е. знают много фактов и их "двадцатилетний опыт работы -- это однолетний опыт, повторённый двадцать раз").

---

Программка в театре содержит важнейшую информацию: "действующие лица и исполнители".

---

Действующие лица -- это вдумчивый Принц Гамлет и безумная Офелия.

---

Исполнители -- это актёр-стажёр Вася Пупкин в утренних спектаклях и народный артист Василий Петрович Черезколеноногузадерищенский в вечерних спектаклях, плюс Елена Ефимовна во всех спектаклях, и она не болеет и не замещается.

---

Когда говорим о стейкхолдере, то всегда имеем ввиду ту пьесу, которую он играет (ту деятельность, которой стейкхолдер занимается), т.е. стейкхолдеры -- это всегда "действующее лицо", роль.

---

*Конечно, в реальной жизни мы видим только исполнителей -- конкретных актёров, а не "роли". Но обсуждаем мы исключительно роли, если только речь не идёт о качестве исполнения!

---

Кто говорит фразу "быть или не быть?". Принц Гамлет, или Вася Пупкин? На момент исполнения роли оба они -- один и тот же объект, только называются по-разному и мы обращаем в зависимости от этого внимание на разные свойства этого объекта. Когда речь идёт о "действующем лице", то мы обращаем внимание на текст и сюжет пьесы, а когда речь идёт об "исполнителе", то на качество исполнения и доступность исполнителя в момент спектакля.

---

Мы всегда можем указать Васе Пупкину, что он плохо выучил роль, или играет чужую роль и всяко по-другому дать понять, что "ты не прав, Вася", если нам известна пьеса, которую он играет. Если пьеса неизвестна, то мы не можем понять -- прав, или не прав Вася в своих действиях.

---

Мы можем даже потребовать заменить актёра-исполнителя (безвестного Пупкина на талантливого народного артиста Черезколеноногузадерищенского), но обычно не можем потребовать заменить действующее лицо (вместо Принца Гамлета вдруг потребовать вставить в пьесу Бармалея и Бэтмена). Это огромное достижение цивилизации: роли культурно-обусловлены, а исполнители привносят в них личное -- и это сливается в одно "исполнение роли".

---

Упражнение: пометьте, что неправильно в списке стейкхолдеров (помним, что стейкхолдер -- это как один человек, так и группа, так и организация):

---

1. Системный архитектор

---

2. Инженер по требованиям, А.К.Щеплынтов

---

3. Разработчик подсистемы Z, завод "Тепломонтажагрегатика".

---

4. Завод "Промпереработка"

---

5. Геннадий Павлович

---

6. Пятый цех.

---

7. Жители района строительства атомной станции.

---

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

---

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

"Просто" системы и системы систем.

---

Различают "просто" системы (system) и "системы систем" (system of systems, SoS). Оба варианта с точки зрения самого воплощения системы как физического объекта в реальности (system realization) представляют собой какие-то холархии (иерархии по отношениям "часть-целое", разбиения/breakdowns). В обоих случаях "подсистемы" очень часто называются точно так же: "системы" (и поэтому новички в системной инженерии часто пытаются обозвать просто систему "системой систем" -- но это ошибочно). Вот, например, диаграмма "просто системы" из ISO 15288 -- обратите внимание, что термины "подсистема" и "надсистема" не используются, чтобы подчеркнуть единообразность понимания "системы" на всех уровнях разбиения системы на части-системы и части-элементы (в ISO 15288 элементом называется та часть системы, которая будет оставаться в данном инженерном проекте "чёрным ящиком" и поэтому дальше не будет разбита на части -- например, закуплена целиком или изготовлена как целое из какого-то материала):

---

---

Этот рисунок структуры системы говорит, что ISO 15288 рассматривает целевую систему как набор из частей-систем и частей-элементов и продолжает разбиение систем на части-системы и части элементы. Но неправильно такие картинки называть "система систем" (system of systems, SoS), ибо этот термин закреплён за другой ситуацией.

Системой систем называют такую систему, которая (критерии Maier):

---

● Имеет независимое управление её систем-элементов (нет, кому

---

скомандовать общее развитие-модернизацию)

---

● Независимая работа элементов (нет, кому скомандовать работу в общем

---

сервисе)

---

● Эмерджентность от объединения в систему (кто-то желает получить от

---

целевой системы систем функцию, которую невозможно получить от работы

---

с отдельными входящими в систему систем элементами, и требуется

---

совместная работа этих элементов).

---

● Эволюционное развитие (понимание того, что будет происходить в системе

---

систем на каждом следующем шаге проекта требует исследований, ибо нет

---

точки, которая знает as built для всех)

---

● Географическое распределение элементов

---

Эти критерии различаются, конечно, в разных инженерных школах, но общее остаётся: обычные "системы" подразумевают централизованное "владение" системой -- наличие стейкхолдеров, полномочных принимать решения по всем частям системы, полномочных распоряжаться всем, что в границах их системы. Это традиционный случай: автомобиль с двигателем и колёсами,

---

железнодорожный мост и компьютер -- это типичные "просто системы", у них есть свои системные инженеры, которые полностью определяют их функции, конструкцию, интерфейсы с системами в операционном окружении, планы по модернизации и выводу из эксплуатации. У каждой из этих систем есть один хозяин, один владелец. А вот в системе систем каждая из систем имеет своего хозяина, и система может функционировать автономно, без вхождения в систему систем. Тем самым разница между "просто системой" и "системой систем" определяется не через особую структуру или конструкцию системы, а через наличие независимых друг от друга стейкхолдеров, определяющих и создающих системы, а затем независимо использующих их.

---

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

---

космические войска получили несовместимое оборудование и вооружение -- и никакими силами нельзя было создать из этих несовместимых между собой систем-элементов систему систем, ведущую бой как единое целое. NATO выделило четыре типа систем систем, отличающихся степенью их автономности:

---

● управляемые (directed), в которых есть назначенный архитектор, который может выдавать приказы составляющим системам и распоряжается ресурсами.

---

● подтвержденные (acknowledged), в которых признаваемый архитектор есть, но он может только уговаривать составляющие системы самоизмениться согласно разработанной им архитектуре.

---

● сотрудничающие (collaborative), в которых все системы договариваются друг с другом по каждому чиху, но архитектора, менеджера проекта или аналогичного выделенного органа управления нет.

---

● виртуальные (virtual), в которых системы вообще не знают друг о друге ничего и не влияют друг на друга явно.

---

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

---

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

---

Работы по системо-системной инженерии объединяют с использованием системного мышления достижения отдельных гуманитарных дисциплин: социологии, политологии, психологии, менеджмента, конфликтологии. Тем не менее нельзя системо-системную инженерию считать "системным менеджментом", ибо в ней таки ставятся задачи не столько главным образом по созданию системы из людей, сколько задачи по созданию главным образом технических систем, но с активным участием людей -- что требует изменения инженерных практик и методов.

Навигация по уровням холархии.

---

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

---

Harold "Bud" Lawson приводит следующий пример для транспортной системы: (рис.)

---

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

---

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

---

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

Системная инженерия и государство

---

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

---

нельзя, она предназначена прежде всего для кибер-физико-человеческих систем.

---

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

У проекта системной инженерии всегда есть вполне определённые стейкхолдеры, которые платят за этот проект: заказчики. Кто заказчик в госстроительстве? Политики? Чиновники? "Народ" (например, опрос общественного мнения или фокус-группа)? "Элита" (и кто её определяет)? Группы экспертов (вариант "экспертократии" -- но как выбрать из этих групп "правильную", все эксперты ведь говорят разное)? Нужно чётко понимать, что в случае госстроительства речь идёт о политике, а не о классических стейкхолдерах системноинженерного проекта. Не нужно себя обманывать, говоря, что "есть заказ, оплачивается о из бюджета, следовательно заказчиком является тот чиновник, который будет подписывать мне акт приёмки работ".

---

Госстроительство -- это прежде всего политика, в политике подобные рассуждения неприемлемы. Более того, строить государство вы будете не из своего материала, а из всегда чужого: из других людей.

---

Люди -- это не железо, и не компьютеры. Не считайте, что именно вы из них что-то построите удачное, и не считайте, что вы как системный инженер (или программист, или сапожник) квалифицированы что-то строить из людей (таких же, как вы, между прочим).

---

Эти люди, эти системы, из которых вы будете пытаться строить, не ваши, и не ваших заказчиков-чиновников, заказчиков-

---

политиков.

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

---

Нельзя также считать, что можно получить помощь от государства в развитии системной инженерии (часто об этом говорят, как о "промышленной политике"). Чиновники ничего не понимают в системной инженерии. Даже если они выделят деньги на развитие каких-либо практик системной инженерии, или создание курсов -- вовсе не факт, что это будут конкурентоспособные практики, конкурентоспособные курсы. Пусть проблемы инженеров решает рынок, дело чиновников -- не вмешиваться в решения рынка (не поддерживать рыночно слабых и давать им разоряться, не тормозить рыночно сильных и давать им заработать, и не путать рыночно сильных и слабых с административно сильными и слабыми).

---

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

---

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

---

На свободном рынке фирмы с такими методологиями бы не выжили, но на военных якобы рынках действуют совсем другие закономерности. И конечно, каждый системный инженер решает для себя сам: хочет ли он проектировать и строить машины для убийства (именно этим занимается военная системная инженерия).

---

Подробней на эту тему см. доклад "Системная инженерия в государственном строительстве: почему нельзя" -- видео http://ailev.livejournal.com/1075745.html, слайды http://g-l-memorial.ice.ru/files/186790/ailev_syseng_may13.ppt

4. Воплощение системы: компоненты, модули, размещения

---

Альфа воплощения системы -- это сама система, состоящая из вещества и полей. Воплощение системы входит (в том числе потенциально входит, если речь идёт о какой-то серийной продукции) в какую-то использующую надсистему, а также состоит из частей.

---

При работе с воплощением системы от разных стейкхолдеров можно (а точнее -- нужно!) получить разные ответы на два основных вопроса "что это за система" (игнорируем части системы: система как "чёрный ящик"), и "из чего состоит система" (интересуемся частями системы: система как "прозрачный ящик"), это нужно отчётливо осознавать.

---

Конечно, воплощение системы связано с определением системы (минимальное определение системы -- это имена, которыми мы определяем части системы).

---

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

---

Так что про собственно определение системы ("как определять систему", а не "из чего состоит система") разговор будет позже, в следующем разделе.

*Многерица

---

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

---

В христианстве есть довольно сложное понятие троицы: бог представляется одновременно и единым, и существующим в трёх ипостасях (отца, сына и святого духа). Проблема в том, что думать о боге нужно одновременно и о как едином, и как об отдельных ипостасях.

---

То же самое есть и во многих других религиях, хотя там необязательно троица. Так, в даосизме единое (дао) одновременно представляется как двоица (противоположности инь и янь). Впрочем, некоторые и тут видят троицу:

---

"Он принял свой аспект и поднял атрибут" ("He has taken on his Aspect and raised up an Attribute" -- "Бог/князь/Lord света", Роджер Желязны -- это уже фантазийные перепевы индуизма и буддизма). Все религии как-то учитывают возможность различных обликов/аспектов/ипостасей для какой-то божественной сущности -- и тут нужно добавить, что религиозность и божественность тут не при

---

чём. Но метанойя думать об одном как о разном и как об одном и том же вам потребуется. Трудность мышления в том, что нужно о какой-то системе одновременно думать как о чём-то, совмещающем разные свои ипостаси, так и как об отдельных ипостасях -- в том числе при той трудности, что ипостаси этой системы нередко имеют ещё и разные имена, обозначающие систему-как-ипостась (хотя одинаковые имена для разных ипостасей встречаются даже чаще).

---

Мы уже знакомились с ситуацией, когда Принц Гамлет, народный артист и Черезколеноногузадерищенский могут быть одним человеком, но называться по-разному в зависимости от того, что нам от него нужно -- понять, какая фраза будет следующая в его пьесе, когда он планирует выучить новую роль в новом спектакле или есть ли у него дети. То же можно сказать и о системе: "измеритель давления", "манометр KLM-23 завода "Давижмимонтажавтоматика"" и "датчик в пятом ящике на третьей полке склада номер 4" вполне могут оказаться одним и тем же прибором -- но разные имена свидетельствуют о том, что мы планируем совершенно разные действия с этим прибором, поэтому для нас один и тот же прибор выступает в разных ипостасях и имеет поэтому разные имена. Для разных стейкхолдеров система будет представляться в своих аспектах-ипостасях совершенно по-разному -- но при этом оставаться целостной, холистичной, целокупностью всех своих ипостасей/аспектов.

---

Одному стейкхолдеру на этой картинке нужно знать, как работает эта система, и он выбирает для этого одни объекты-части. Другому стейкхолдеру нужно систему собирать, третьему -- какое место она будет занимать. И поэтому каждый стейкхолдер по-своему находит части в так "односторонне" (со стороны нужд его деятельности) понимаемой системе.

---

Это "не единое" просто нормально, так и должно быть! Единым может быть только единонемыслие (Салтыков-Щедрин). Много разных профессионалов по-разному определяют одну и ту же систему, это нормально.

---

Кстати, шутка про наполовину полный стакан существует и для системных инженеров: "стакан вдвое больше, чем нужно" (помним, что системный инженер переделывает систему -- все инженерные описания нужны именно для этого!).

Экстенсионализм

---

Тут придётся вспомнить о трудах Декарта, который задавался вопросом: а как вообще понять, об одном и том же объекте говорят люди, когда они отмечают в объекте самые разные свойства, или всё-таки о разных? Скажем, один инженер говорит о тяжёлой и светлой системе, а другой -- о громкой и убойной. Как понять, что речь идёт об одной и той же системе? Декарт предложил экстенсионализм (extensionalism): считать, что если экстенты (extensions), т.е. протяжённости в пространстве (длина, ширина, высота) у двух объектов совпадают, то это один и тот же объект! В XX веке к этому добавили ещё и протяжённость во времени (временнОй экстент), и идея получила название 4D экстенсионализма (4D extensionalism). Эта сугубо философская поначалу концепция сейчас широко принимается в инженерии: на ней основаны:

---

● Стандарт ISO 15926, который считается перспективным для обмена инженерной информацией (практически все крупные поставщики САПР заявили о его поддержке) -- последовательность самообразования по этому стандарту см. В http://levenchuk.com/2012/10/01/iso-15926-self-education-sequence/

---

● Онтология IDEAS, которая легла в основу DM2 (онтологического представления для инженерных архитектурных описаний стран NATO, например http://dodcio.defense.gov/dodaf20/dodaf20_ontology1.aspx -- обратите там внимание: Individuals are Things that exist in 3D space and time, i.e., have 4D spatial-temporal extent).

---

Мы уже упоминали, что системы существуют в мире как уникальные физические объекты, которые имеют 4D пространственно-временную протяжённость, то есть являются онтологическими "индивидами". И если один видит дом, другой видит детский сад, третий видит объект ЖКХ, четвертый видит "строение", и все эти разные люди (для целей своей деятельности) настаивают на своём понимании

---

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

---

Такие рассуждения позволяют системным инженерам более-менее формально работать с системой как "многерицей" -- одновременно единой и одновременно различной в каждой её ипостаси.

Роботы такие, роботы сякие http://ailev.livejournal.com/1174770.html

Два типа "целого"

---

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

---

● По отношениям часть-целое (разбиения) -- это когда система представляется состоящей из частей и сама является частью другой

---

системы. Холархии, "зум" и "уровни рассмотрения" как уровни разбиения системы на части, эмерджентность от взаимодействия частей. Когда говорят о частях и целом, обычно имеют ввиду воплощение системы.

---

● Целое, проявляющее себя в разных ипостасях, рассматриваемое разными стейкхолдерами по-разному -- в системном подходе это "мультидисциплинарность", объединение описаний, отсутствие редукционизма (сведения к одной дисциплине), холизм (та же "целостность", но не про части! Про "разносторонность"!). Когда говорят о частных и целостных описаниях, то обычно имеют ввиду определение системы (разные описания системы).

---

Не путайте эти две разных "целостности" системы. Конечно, сам разговор о воплощении системы подразумевает какое-то описание этого воплощения -- как минимум, описание самого воплощения: называние его по имени, учитывая какой-то аспект/ипостась. Именно поэтому, говоря в этом разделе про воплощение системы мы вынужденно касаемся и определения системы, её частей-подсистем и элементов, надсистемы, использующей системы, систем в операционном окружении, обеспечивающей системы и т.д. -- как минимум, называние их с учётом аспекта/ипостаси.

6. Виды жизненного цикла

---

Жизненный цикл чего?

---

Жизненный цикл (life cycle) -- это не "жизненный" и не "цикл". Название произошло от биологического "жизненного цикла", ибо особь каждого вида рождается, живёт, затем умирает. И потом следующая особь рождается -- и так далее, по циклу, игнорируя факт, что "по циклу" проходят совсем разные существа.

---

Технические системы тоже "рождаются" и "умирают", а затем появляются новые системы -- но это и не "жизнь" и не такой уж "цикл". Жизненных циклов бывает много разных (системы, проекта, разные виды жизненного цикла), и нужно в этом не запутаться -- всех их, конечно, называют просто "жизненный цикл", забывая уточнить, какое использование термина имелось ввиду. Жизненный цикл системы (system life cycle) -- это деятельность всех обеспечивающих систем, ведущих целевую систему от её замысла ("рождения" определения системы) до вывода из эксплуатации ("смерти" воплощения системы), обычно эта деятельность разбита на стадии (stages), которые вполне могут быть не только последовательными, но и перекрываться во времени друг с другом.

---

Жизненный цикл (деятельность) начинается в какой-то момент времени, а затем заканчивается в какой-то момент времени, стадии его тоже начинаются и заканчиваются в какие-то моменты. Когда говорят "жизненный цикл", то всегда подразумевают полный отрезок времени "от замысла до вывода из эксплуатации", "от рождения до смерти", причём разбитый на стадии. Но отрезками времени не "управляют", а вот когда говорят "управление жизненным циклом" как раз говорят об управлении деятельностью (управлении обеспечивающей системой), обеспечивающей переход от одной стадии жизненного цикла к другой. Стадии жизненного цикла выделяют по изменению в ходе жизненного цикла преимущественного образа мышления (согласно ISO 24744 -- change of mental framework).

---

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

---

Жизненный цикл проекта (project life cycle) -- это часть жизненного цикла системы, которая укладывается в рамки проекта. Иногда жизненный цикл проекта совпадает во времени с какой-то стадией жизненного цикла, иногда не совпадает. Более того, совершенно необязательно, что в рамки жизненного цикла проекта

---

(деятельности проекта) попадает вся деятельность какой-то стадии жизненного цикла системы. Проект обычно бьётся на этапы.

Управление жизненным циклом

---

Управление жизненным циклом (life cycle management) -- инженерная дисциплина, в отличие от менеджерской дисциплины управления проектами. Управление жизненным циклом может рассматриваться по-разному:

---

● Как синоним управления конфигурацией, управления инженерной документацией, управления жизненным циклом продукта (product life cycle management), плюс управление информаций. Основная задача -- предотвращение конфигурационных коллизий (т.е. ошибок, возникающих от несоответствия и противоречивости различных документов и моделей друг другу, а также их несоответствие воплощённой системе).

---

● Как дисциплина, описывающая разные логистические организации распределения инженерных практик (инженерии требований, инженерии системной архитектуры, и т.д.) по стадиям жизненного цикла (последовательное выполнение практик, параллельное выполнение практик, регулярность проведения проверок, ритмичность проведения совещаний и перепланирования, и т.д.).

---

● Так называется ситуационная инженерия методов с точки зрения менеджеров (это неслучайно. Именно языки и стандарты ситуационной инженерии методов используются для описания жизненного цикла: описываются практики, а затем показывается их распределение по стадиям жизненного цикла. Стандарты ситуационной инженерии методов -- OMG Essence, а также часто поминающийся в этой главе ISO 24744.

---

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

---

Есть особое понимание "управления жизненным циклом" в атомной отрасли, задаваемое документами МАГАТЭ (международного регулятора): у атомщиков управление жизненным циклом понимается как практика продления жизни действующих атомных станций, "управление старением". Тем не менее, это особое использование термина сегодня сменяется постепенно на общепринятое в системной инженерии понимание.

---

Управление жизненным циклом в любом случае охватывает полный жизненный цикл системы (т.е. охватывает множество проектов) и сосредотачивается не на "сдаче вовремя", а на содержательном объединении работ разных стадий жизненного цикла, использовании необходимых инженерных практик. Акцент тут на содержательном change of mental frameworks (изменении преимущественного мышления) в ходе смены стадий жизненного цикла, а не на точном выполнении графика. В управлении жизненным циклом волнует такая организация работы, которая подразумевает наличие содержательно необходимых ресурсов (а не ресурсов в достаточном количестве для выполнения содержательных инженерных практик, этим занимается проектное управление).

Информационные системы управления жизненным циклом

---

Информационные системы управления жизненным циклом (PLM, product life cycle management) по факту поддерживают не полный жизненный цикл, а главным образом стадию проектирования. Хотя часто пытаются говорить о PLM как product life cycle management (практике управления жизненным циклом изделия/продукта/установки/сложного инженерного объекта/системы), аббревиатура PLM чаще всего используется для указания на вид инженерных информационных систем, выполняющих следующие функции:

---

● Управление конфигурацией инженерной системы на стадии архитектурного проектирования (хранилище информации проекта -- PDM, product data management). Самые различные (механические, электрические, технологические и т.д.) САПР и системы инженерных расчётов работают со связанными между собой моделями в этом хранилище. Хранилище поддерживает версионирование моделей.

---

● Управление изменениями (отслеживание дел, главным образом запросов на изменение проекта/design), наиболее часто в виде issue tracker

---

● Формирование и передача информации конфигурации на следующие стадии жизненного цикла (прежде всего -- выпуск спецификаций для закупки). Для этого в состав PLM входит генератор отчётов, берущий информацию из PDM. Вот информационные системы в жизненном цикле мотора, появляющегося в инженерном проекте:

---

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

---

Модуль на стадии закупки -- это уже "предмет снабжения", информация о нём, скорее всего, содержится в ERP-системе. Закупленный мотор-модуль монтируется, и становится "установленным оборудованием". Информация о нём (индивидуальный журнал для конкретного мотора с серийным номером, куда попадают записи о поломках, техобслуживании и т.д.) теперь находится в EAM системе (Enterprise asset management), используемой службой эксплуатации.

Карточки состояний

---

Обычно контрольные вопросы оформляются в виде карточек состояний альф (да, карточек из плотной бумаги -- типа игральных карт, cards). Вот пример оформления такой карточки для альфы "стейкхолдеры", состояния "признаны" (первое состояние из шести): ...

---

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

---

С другой стороны, команда решает (а иногда за команду решают ГОСТы, внутренние регламенты/стандарты организации, распоряжения, условия договора и т.д. -- когда у команды нет права определять свой способ работы), какие рабочие продукты и в какой степени детальности их разработки нужно использовать для ответов на утверждения карточек альф.

---

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

Системноинженерное мышление и инженерия предпринятия

---

Все наработки системного подхода вполне приложимы к предпринятиям-системам:

---

● Предпринятия материальны (согласно многим стандартам предпринятие/организация определяется как люди, здания, сооружения,

---

оборудование и другие ресурсы, причём среди людей есть договорённости по полномочиям в использовании этих ресурсов).

---

● Предпринятия состоят из структурных иерархий компонент, модулей, размещений (хотя о них говорят в такой терминологии редко, но подобного типа мышление сохраняется). Архитектура предпринятия (для современного предпринятия при этом обязательно подробное рассмотрение информационных систем в составе архитектуры предприятия) уже давно является одной из признанных дисциплин. Но, конечно, "принципиальные схемы" у предпринятия отличаются от оптических и гидравлических схем.

---

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

---

Конечно, терминология отличается (хотя стейкхолдера назовут стейкхолдером и архитектуру архитектурой), но мы не зря тренировались абстрагироваться от конкретных слов и больше заниматься смыслом говоримого. Тем самым весь материал предыдущих разделов вполне применим для обсуждения предпринятия.

"Развития для развития"

---

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

---

-- только как хорошее (ибо всем очевидно, что этому ещё совершенствоваться и совершенствоваться, чтобы сравниться с уже имеющимся).

---

"Хорошее -- враг лучшего!" -- и развитие прекращается, не начавшись. Старые парадигмы, старые cognitive frameworks умирают только с их носителями... Первый шаг решения проблемы "развитие против совершенствование" -- это возможность её коллективного (ага, в том числе в коллективе с самим собой!

---

Попробуйте написать ваши мысли, а затем прочесть -- и при написании, и при прочтении вы откроете для себя много нового!) обсуждения.

---

Для самой возможности обсуждения совершенствования и развития нужно опереться на системноинженерное мышление. Harold Lawson писал в комьюнити INCOSE в LinkedIn в треде "Building SE into an Organization", -- "...it is all about understanding and communication. If you do not get people on the same page you are simply talking in the air. That is why learning fundamental paradigms, concepts and principles of systems is so important".

---

Развитие начинается в тот момент, когда его можно обсуждать, когда выучен язык, на котором говорят о развитии. Нужно освоить "fundamental paradigms, concepts and principles of systems" -- и пройти ступеньку совершенствования, чтобы научиться этим пользоваться. Нужно сделать шаг "развития для развития". Это трудно: прекратить индивидуальное или корпоративное совершенствование в том, чем вы прямо сейчас сами или с коллегами заняты, и пройти ряд образовательных ступенек "о ни о чём".

---

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

---

Самое эффективное для развития предпринятия -- это не сразу бросаться в преобразования и менять технологическое шило на технологическое мыло, а сначала научить людей говорить об их предпринятии, научить людей говорить о стратегировании/развитии на языке системноинженерного подхода. Люди получают возможность быстро договориться между собой и скооперироваться (в том числе договориться "внутри себя с собой", если ваше предпринятие -- это только вы сами). И тогда начинают происходить чудеса, тогда начинается настоящее развитие и осмысленное для него совершенствование -- в маркетинге, инженерии, операциях.

*Основные альфы организационного и технологического решения предпринятия

---

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

---

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

---

В принципе, все такие инженерные деятельности можно также переформулировать как "сервисы". Так, благотворительный фонд -- это сервис для благотворителей, но вот бенефициары у него -- получатели благ, они бенефициары, но не клиенты!

---

Если переформулировать систему-предпринятие в сервис, это оказывается чрезвычайно плодотворным. Предприятие, продуктом которого являются чугунные чушки мыслится совсем по-другому, чем *предпринятие у которого сервис "поставка чугунных чушек". Ибо сами чушки много менее разнообразный объект, нежели сервис "поставка" (в этом сервисе можно варьировать сроки поставки, распределение поставки во времени -- чтобы она коррелировала с распределением потребления чушек по времени, включать "дополнительное обслуживание" типа логистики, в том числе погрузочно-разгрузочных операций и т.д.).

---

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

Это всё системный подход

---

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

---

Эти разные описания удовлетворяют интересы разных заинтересованных сторон (stakeholders) предпринятия путём задействования разных тематических методов описания (viewpoints) для создания разных тематических групп описаний (views), включающих в себя отдельные более и менее формальные модели -- разве что методы описания предпринятия/деятельности не похожи модели для "железных" или "программных" систем. Но вот то, как и что описывается в предпринятии-системе можно обсуждать примерно так же, как это можно обсуждать в отношении любой другой (программной или "железной") системы.

---

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

ArchiMate

---

Для описания архитектуры предприятий разработано много подходов (frameworks), определяющих различные наборы viewpoints -- TOGAF, Zachman's, ArchiMate. Также определено какое-то количество архитектурных языков, которые предназначены для выражения идей, содержащихся в подходах к моделированию предприятий (из которых на сегодняшний день выделяется стандарт OpenGroup ArchiMate 2.0 -- его полный текст http://pubs.opengroup.org/architecture/archimate2-doc/, набор ссылок на русскоязычные тексты по Архимейту:

---

http://ailev.livejournal.com/988360.html).

---

Основная дизайн-цель при создании Архимейта была учесть необходимость указания в архитектуре предприятия одновременно:

---

● Структур деятельности (людей)

---

● Структур функционирования компьютерных программ

---

● Структур поддержки инфраструктуры (компьютеров и линий связи) для программ.

---

Для этого был придуман язык, на одной и той же диаграмме которого можно было отразить объекты и связи всех этих разных категорий. Вот пример того, как изображаюсь я, занимающийся архитектурой предприятия своего клиента в редакторе Archi (свободный редактор для софта Archimate):

---

Жёлтым выделена структура деятельности людей (консультант в роли архитектора, занимающийся архитектурной практиикой), голубым -- работа программ, зелёным -- оборудование, на котором работают программы. Все эти три уровня показаны на одной диаграмме, это и было главным достижением предложенного подхода и языка.

---

В 21 веке предприятия координирются уже не столько непосредственной коммуникацией людей, которые держат основной объем координационной информации в головах, сколько опосредованной компьютерами коммуникацией и хранящейся в компьютерах координационной информацией. Архимейт (как и вся дисциплина архитектуры предприятия) учитывает этот факт -- но Архимейт стимулирует архитекторов не забывать о том, что кроме компьютеров и программ на предприятии есть ещё и люди (удивительно, но чаще архитекторы предприятия забывают про людей, прописывая подробно решения IT-архитектуры, а не забывают про IT-архитектуру, прописывая подробно деятельность людей. Якобы "архитекторы предприятия", а на самом деле "айтишники" иногда забываются до того, что "архитектура предприятия" воспринимается ими чуть ли не как синоним "архитектуры IT-решения". Это неправильно!).

---

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

Зачем нужен Архимейт

---

Моделирование на Архимейте -- это создание таких диаграмм, при помощи которых мы можем что-то узнавать про предприятие. Архимейт имеет встроенные в него способы извлечения знаний о предприятии -- он заставляет архитектора задавать вопросы (в том числе и самому себе) там, где есть неочевидные сразу "непонятки". Ответы на вопросы чаще всего требуют либо изобрести чего-нибудь (если речь идет о проектировании нового предприятия), либо разузнать чего-нибудь (если описывается уже имеющееся предприятие), либо просто исправить очевидную ошибку.

---

Архитектор не гроссмейстер -- он не умеет играть без доски, он использует диаграммы, чтобы смотреть на них и думать. Тем самым работа его двухтактна: писать диаграммы и затем читать их. Эти диаграммы для него -- "экзокортекс", продолжение его мозга, участвующее в размышлении. Он думает, ставя перед собой (или перед другими -- если организуемое им размышление коллективное) вопросы, появляющиеся от соприкосновения формализма Архимейта с неформально устроенной жизнью предприятия. Тут неважно, это только проектируемая будущая жизнь, или реальная уже идущая жизнь (всё одно мы и об одной, и о другой узнаём только то, что думают об этой жизни люди, а не то, что было или есть "на самом деле"). Мысль -- диаграмма -- вопрос -- мысль.

---

Главным механизмом Архимейта, стимулирующим задание вопросов, является механизм типов для объектов и отношений. Например, для процессов вы можете указать связь по передаче информации (но ничего не сказано про последовательность исполнения), или по запуску (подразумевающему указание последовательности выполнения) -- и у вас будет много вопросов про сами процессы, как только вы начнете выбирать тип их связи в отношении. Если у вас два объекта деятельности, и вы хотите указать какое-то отношение между ними, а

---

Архимейт предлагает из подходящих типов только "связь" без дальнейшей спецификации ("связь без причины -- признак дурачины"), то вам нужно попробовать поискать в жизни какое-то поведение, связывающее эти объекты -- и отмоделировать это поведение явно на диаграмме. Нужно запомнить: "за отношением обычно стоит глагол, а за объектом -- существительное", и попытаться отыскать этот "глагол" (работу) в жизни.

---

Механизм типов подразумевает задание главным образом одного простого вопроса, ответ на который обычно очень сложно получить. Для каждого встречающегося в жизни объекта спросите "что это?!", "часть чего это?", "с чем это связано?". Подберите тип Архимейта. Получите удовольствие: до вас мало кто задумывался, "что это". Ответ на этот вопрос может оказаться очень нетривиальным, а получение этого ответа заставит задать десятки других вопросов.

Архимейт

---

Формальные диаграммы из типизированных объектов и отношений и предписанные виды имён направляют архитектурное мышление, они ведут его по рельсам (да, так жестко!), предусмотренным авторами Архимейта. Это не так плохо, ибо если никак не ограничивать мышление архитектора, оно будет крайне нетехнологично, т.е. хорошие результаты не будут предсказуемо повторяться: один раз из ста у одного архитектора вдруг получится гениальный результат в сто раз лучше, чем с использованием Архимейта (обычно такие гении как раз и создают Архимейты и другие архитектурные языки), а девяносто девять раз у девяносто девяти архитекторов из ста получатся результаты сильно хуже.

---

"Неограниченные Архимейтом архитекторы" в меру своей гениальности найдут на предприятиях "организационный флогистон", отношение "духоподъёма" между людьми, да и вместо "людей" неожиданно могут обнаружить какое-нибудь "быдло" или "ангелоидов". Плюс нужно будет для этих "флогистона" и "ангелоидов" придумывать графическую нотацию. Архимейт даёт специальные понятийные очки, через которые предприятие видится исключительно предписанным авторами этого стандарта способом. Способ это современен: сервисы, трехуровневость реализационного описания; различение объектов работы, работ и выполнителей (людей, программ, оборудования); и т.д..

---

Это всё контринтуитивно, и не соответствует интуиции людей, хорошо знакомых с предприятиями и хорошо знакомых с программированием. Контринтуитивность предлагаемого Архимейтом взгляда на предприятие порождает много вопросов -- неформальное предприятие не укладывается в новомодные формулы. Но формальность диаграмм позволяет их хоть как-то проверять, а также соотносить с жизнью.

---

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

Организация операций/операционное управление

---

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

---

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

---

Музыканты слышат, что делают соседи. Работники могут и не подозревать, что происходит на соседних местах. Они даже могут не знать, какие им нужно играть ноты. Цели работ, планы работ и сам ход работ должны стать видимы: эту проблему решают организационная модель и система учета, компьютерное моделирование и расчёты планов.

---

Ещё одна сложность -- время организовывания (build time) и время выполнения работ (run time) оказываются все более и более тесно переплетены ("рабочие места" перестали существовать десятилетиями в неизменном виде), поэтому архитектурная работа по определению предпринятия и операционное управление по его подстройке под текущую ситуацию оказываются тесно переплетены. И, конечно, кроме планирующей работы нужно ещё выдавать конкретные команды исполнителям, выбивающимся из плана -- это уже не организация или управление, а руководство (буквально: "руками водство").

В рамках АНО НИСИПП (nisse.ru) совместно с Anatoly Levenchuk решили создать Школу системного мышления и действия, целью которой будет менять мышление менеджеров. Ведь выиграть конкуренцию можно только путем правильного системного мышления и для этого нужно сначала у себя в голове создать модель бизнеса (технологического бизнеса, тк другого крупного бизнеса в 21 веке не будет). Эта модель должна увязывать и раскладывать по полочкам "как в Ашане" все области деятельности предприятия (от миссии предприятия и производимого продукта до системы организации деятельности предприятия), а также позволять осознанно выбирать и использовать лучшие современные методы и практики повышения эффективности деятельности предприятий.

---

https://www.facebook.com/tseren.tserenov/posts/736689613095664

...ибо моделирование художников ближе к моделированию композиторов. И тех и других следует моделировать по их Vc и по их Ac.

---

http://metapractice.livejournal.com/468341.html?thread=11959925#t11959925

---

и системных инженеров по Vc.