Инженерия и наука: инженерия научна.

попалась интересная статья
Пишет Anatoly Levenchuk
К спорам о научности или ненаучности инженерии -- фрагмент из моего учебника (версия апреля 2015 года, полный учебник лежит тут: http://techinvestlab.ru/systems_engineering_thinking).
Инженерия и наука: инженерия не научна.
Инженерия и наука
Системноинженерное мышление и деятельность — как нам их описать?! Их ведь нельзя пощупать, нельзя наглядно продемонстрировать. Если попробовать пронаблюдать, что делает инженер — он спокойно сидит на стуле и кликает время от времени кнопками мышки. Или спокойно стоит и смотрит на приборы сложной установки, иногда крутит какие-то ручки и нажимает какие-то кнопки. И в то же время понятно, что его мышление и деятельность отличаются от мышления и деятельности пианиста, который тоже спокойно сидит на стуле и кликает время от времени кнопками рояля.

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

Инженерия занимается изменением реальности — двигает горы, создаёт спички и зажигалки, строит марсоходы и медицинские роботы Да Винчи. Пространство-время физического мира были устроены одним способом, пришли инженеры, пространство-время стало устроено по-другому.
Производством компактных описаний реальности занимается наука — придумывает диаграммы Фейнмана, теории мышления, понятия системы и деятельности. Пространство-время думали, что устроено одним способом, пришли учёные, пространство-время теперь думают, что устроено другим способом.
Обучить науке — это обучить тому, как строить компактные и понятные людям описания того, как устроен мир. Например, 4 уравнения Максвелла описывают все электромагнитные явления мира, а уравнение Шрёдингера описывает волновые функции элементарных частиц. Можно ли “выучить на учёного” — это отдельный вопрос, мы его тут не будем рассматривать.
Но для начала нам придётся заняться инженерной наукой: попытками компактно описать то, что делают лучшие инженеры мира.
Тут нужно учитывать, что само понимание того, что такое наука, исследования, инженерия непрерывно меняется, чуть ли не каждый десяток лет. Интересующиеся могут ориентироваться на следующую последовательность ключевых работ по истории и философии науки (подборка Антона Николаенко, https://www.facebook.com/nikolaenko.ant ... 2053939232):

в 1934 Поппер выпускает свою "Логику научного исследования",
в 1935 Флек публикует "Возникновение и развитие научного факта",
в 1937 Мертон - работу "Наука и социальный порядок",
в 1946 Полани - книгу "Наука, вера и общество",
в 1962 Кун - свою "Структуру научных революций",
в 1971 Бен-Дэвид - свою "Роль ученого в обществе",
в 1972 Тулмин - работу "Человеческое понимание",
в 1975 Фейерабенд - свою книгу "Против метода",
в 1976 Блур - свою "сильную" программу - книгу "Знание и социальное представление",
в 1978 Лакатос - свою "Методологию научно-исследовательских программ",
в 1978 Хюбнер - свою "Критику научного разума",
в 1979 Латур - свою "Лабораторную жизнь",
в 1979 Малкей - свою работу "Наука и социология знания",
в 1998 Шейпин - свою "Научную революцию",
в 1998 Коллинз - свою "Социологию философий",
в 2008 Деар - свою книгу «Событие революции в науке".
Всё из перечисленного переведено целиком на русский язык.

Разница между инженерами и учёными

Нельзя путать инженеров и учёных. Учёные ровно обратны инженерам: если инженеры делают реальные материальные вещи, опираясь на мысль, то учёные делают мысли из реальности — получают компактные, понятные и формальные описания действительности. Конечно, инженерия и исследования тесно связаны:
● когда инженер получает инженерный объект, поведение которого не отвечает его замыслу, он исследует проблему: пытается найти наиболее компактное описание работы этой инженерной системы, из которого было бы понятно, в чём он ошибся при замысле и его воплощении. Затем исправляет ошибку: меняет систему.
● когда учёный придумывает новый способ описания, более компактный и лучше объясняющий мир, чем предыдущие способы, то он проводит эксперименты. Отнюдь не все эксперименты “мысленные”. Некоторые из них требуют создания весьма и весьма сложных инженерных объектов (например, ускорители — это одни из самых сложных на Земле инженерных объектов). Когда эксперимент проведён, учёные корректируют свои теории в зависимости от результатов эксперимента.

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

Главное тут — цель объемлющей деятельности, а не собственно сама работа “исследований” или “разработки” (“науки” или “инженерии”): целью является либо появление какой-то материальной системы, приносящей пользу пользователям, либо появление какого-то компактного описания/объяснения того, как устроен мир. В любом случае, либо инженерия оказывается спрятана в исследованиях, либо исследования спрятаны в инженерии.

Эта путаница, отражающая связь инженерии и науки, весьма распространена:
● В большинстве мультфильмов “учёный” в белом халате меньше всего учёный, это “инженер-изобретатель”. Эти якобы “учёные” не ставят эксперименты: они придумывают какие-то необходимые для их целей системы, и воплощают эти системы в реальности. Это “лаборатории Эдисона”.
● “Прикладная наука” (applied research, прикладные исследования) тоже меньше всего наука, несмотря на слово “исследования”. Никаких “теорий” от этой науки ожидать не приходится, а результаты НИОКР (научных и опытно-конструкторских разработок) как правило — вполне себе инженерные объекты, а не способы описаний. Единственная их разница с результатами классической инженерной разработки, так это то, что результатом является прототип или опытный образец, а не идущий потребителю продукт (между “работающим прототипом” и “выпускаемым продуктом” могут быть годы и годы разработки, development — и результатом являются не “изобретения”, а “инновации”, определяемые как успешно выведенные на рынок изобретения).
● Очень часто прикладные исследования (research) и классическую разработку вообще не разделяют, отсюда устойчивое сокращение R&D (research and development). Есть ли разница? Есть: “лаборатория Эдисона” (лаборатория Bell Labs, лаборатория IBM и т.д.) всё-таки отличаются существенно по организации труда и проходящим в них работам от классической инженерной разработки. Но они не отличаются принципиально! Менеджментом R&D как раз и занимается technology and innovation management.
Настоящая наука — это “basic research”, которые ведутся в “лабораториях Эйнштейна”. На выходе не “опытные образцы” (inventions, “изобретения”, прототипы систем и идеи для этих прототипов), а теории — компактные и формальные описания природы. В отличие от R&D менеджмент и финансирование науки происходят совершенно другим образом, часто они происходят вообще вне рамок предприятий.

Системная инженерия — это тоже инженерия, не наука. Системная инженерия вполне может включать R&D, изобретения, создание прототипов.

Ещё одна связь науки и инженерии — это конструирование экспериментальных установок, в какой-то мере создание инженерных прототипов может быть отнесено к научным исследованиям (хотя речь может идти не о подтверждении научной теории, а подтверждении какой-то догадки или замеченной эвристики).
Если мы хотим создать формальное компактное описание самой системной инженерии — то это наука, “инженерная наука” (engineering science).

Нужно различать предмет самой инженерии (engineering) и предметы, изучающие объекты инженерии — механику, электрику, компьютерную науку и т.д. Инженерия (в том числе системная инженерия) описывает то, как работают инженеры. Инженерная наука (engineering science) даёт описание того, что делают люди в инженерном проекте. Другие предметы и другие науки описывают поведение инженерных объектов, то, как работают они: механические устройства, электрические схемы, компьютерные программы.

Наиболее просто понять разницу между такой “наукой про инженерный объект” и самой инженерией можно на примере computer science (компьютерной науки) и software engineering (программной инженерии). В блоге http://gaperton.livejournal.com/ была замечательная история, как его автор, отличник по computer science, пошёл после ВУЗа покорять иностранную софтверную компанию. Но там ему буквально за два дня объяснили, что он (может быть) умеет программировать, но совершенно точно не умеет работать: нужно было разбираться с тем, как составляются требования, писать нужно было не столько какой-то хитрый алгоритм, сколько заплатку к уже написанному коду на миллион строк, и нужное место для заплатки в этом коде нужно было как-то найти, кроме этого нужно было разобраться в управлении конфигурацией (версионированием), системой управления изменениями, наладить отношения с менеджерами и тестировщиками, понять суть принятой в проекте методологии разработки и т.д. — при этом ничему этому в ВУЗе не учили. Работа оказалась совсем не тем, чему учили: огромное количество времени уходит на общение с коллегами, а не на “думание”, время решения задачи не “сколько нужно”, а “сколько отведено графиком”. Учили computer science (ключевые слова: алгоритм, оценка скорости выполнения алгоритма, нотация, грамматика, реляционная модель данных) и не учили software engineering (ключевые слова: требования, архитектура, тестирование, изменения, сопровождение). Точно так же инженера-механика могут научить работать с прочностью, формой, скоростями, трением с использованием всяческих теорий, но могут не научить работать с требованиями, архитектурой, испытаниями и инженерными обоснованиями. Именно поэтому хороший физик может быть хорошим специалистом по сопротивлению материалов, но не быть хорошим инженером — у него знания про инженерные объекты, но не про саму инженерию.

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

Ненаучность инженерии. Эвристика

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

В книге Discussion of the Method [http://bookzz.org/book/1244348/d69dbc] исследователь инженерии Billy Koen приводил пример: если бы в средние века к инженеру пришли с просьбой построить мост, а он бы отказался на основании того, что сопромат изобретут только через 200 лет — что можно сказать о таком инженере? Или если бы современный инженер при просьбе построить ракету, летящую на Луну или Марс, отказался бы от проекта на основании того, что достаточно подробной “теории Луны” или “теории Марса” ещё не создано? Или при необходимости создать робота инженер вдруг говорит, что “теории о том, что делать, чтобы создавать робота пока нет — поэтому я не знаю, что в каком порядке делать, поэтому подождём до тех пор, пока у учёных не появится соответствующего раздела инженерной теории”. Отказы на таких основаниях не свойственны инженерам, их не останавливает отсутствие научного знания в том, чем они занимаются.
Инженерия кроме научных теорий активно использует эвристики (heuristics) — это догадки о закономерностях, которые вовсе необязательно “научны” в традиционном смысле этого слова, т.е. это не “фальсифицируемая теория” по Попперу: инженер с самого начала знает, что эвристики вполне могут быть в его случае ошибочны и неприменимы. Плюс обратите внимание, что инженерные эвристики определяются отличным образом от философской “эвристики”, найдите соответствующую литературу сами). Вот примеры инженерных эвристик:
Из Turton, Richard, et al. (2003) Analysis, Synthesis, and Design of Chemical Processes, Upper Saddle River, NJ: Prentice Hall.:
● Используй вертикальный резервуар на опорах, когда его объем меньше 3.8м3
● Используй горизонтальный резервуар на бетонных опорах, когда его объем между 3.8 и 38м3
● Используй вертикальный резервуар на бетонных опорах, когда его объем больше 38м3
Большая подборка подобных эвристик для инженерии химических производств дана тут: http://people.clarkson.edu/~wwilcox/Design/heurist.pdf

На эту тему есть хороший анекдот: Физику, математику и инженеру дали задание найти объём красного резинового мячика. Физик погрузил мяч в стакан с водой и измерил объём вытесненной жидкости. Математик измерил диаметр мяча и рассчитал тройной интеграл. Инженер достал из стола свою “Таблицу объёмов красных резиновых мячей” и нашёл нужное значение.

Есть и другие типы инженерных эвристик, совсем не связанных с инженерными расчётами и приёмами конструирования-проектирования:
● Стейкхолдеров всегда на один больше, чем вы знаете; известные вам стейкхолдеры всегда имеют потребность (need) на одну больше, чем вам известно (это шестая из основных инженерных эвристик Tom Glib, http://www.gilb.com/dl97).
● Порядок бьёт класс (в больших проектах упорядоченная работа команды заурядных специалистов бьёт беспорядочную работу высококлассных звёзд).

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

В связи с этим любые достижения в инженерии по предложению Billy Koen нужно оценивать не по абсолютной шкале, а на конкретный момент времени, в соответствии с накопленным на этот момент объёмом научного и эвристического инженерного знания — и это “текущее состояние инженерии” Billy Koen предложил называть SoTA (state-of-the-art). Инженерный проект плох, ежели он не использует всей полноты научного и эвристического знания, накопленного на конкретный момент времени. Со временем объем знаний растёт, и инженерные проекты становятся более и более сложными, достигая невозможных для предыдущего времени характеристик.

Наука как “научение птиц полёту”
Существует мнение, что наука для практической деятельности бесполезна. Практики добиваются успеха не на основе научных знаний, а на основе “возни” (tinkering, ср. “He is tinkering with a car” — “он возится с автомобилем”).

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

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

Ещё один аспект инженерной работы — она не делается одиночками. Нужна координация усилий сотен, тысяч и даже десятков тысяч людей. Все эти люди должны как-то договариваться между собой. Как они могут договориться, если каждый про свою часть дела может рассказать примерно столько же, сколько едущий на велосипеде мальчик про свою езду “я чувствую, что я держу равновесие и я чувствую, что на большой скорости надо бы пригнуться”? Компактные описания нам нужны, чтобы люди могли иметь одинаковое описание того, что они делают, чтобы не возникло проблемы строительства Вавилонской башни.
Излагаемый в нашей книге подход к системноинженерному мышлению и действию совершенно необязателен для инженеров-одиночек, среди одиночек всегда найдётся Кулибин или Левша. Но вот если речь пойдёт о какой-то более-менее масштабной коллективной инженерной деятельности, то синхронизация способов обсуждения проекта может сэкономить много-много времени — все ведь помнят проблему, возникшую при строительстве Вавилонской башни? Мы должны научиться описывать другим людям, что мы делаем и почему, чтобы другие люди могли к нам присоединиться.
Конечно, уметь что-то описывать и в инженерии, и в менеджменте (и даже в литературе) вовсе не означает то, что вы опишете что-то ценное и важное. Графоманам никогда не получить Букеровскую премию, хотя они умеют писать. Научиться думать об архитектуре или проектном предложении, научиться компактно “по науке” записывать свои мысли вовсе не означает, что вы что-то придумаете интересное. “Думать и придумать” в этом плане похожи на “учить и выучить”, “делать и сделать” — процесс ничто, результат всё. Но если не думать, то и не придумаешь. Если не учить, то и не выучишь. Если не делать, то и не сделаешь. Процесс важен, без него не будет результата.

Так что для начала нам нужна инженерная наука (engineering science), хотя мы точно знаем, что инженерия (”инжиниринг”, как сейчас всё чаще говорят) — это не наука. Но нам нужны компактные описания инженерии и менеджмента как минимум для того, чтобы договариваться об инженерии и менеджменте с другими людьми.
И нам нужна наука о мышлении, хотя мы точно знаем, что само мышление — это не наука. Но нам нужны компактные описания мышления, чтобы договариваться о них с другими людьми, чтобы реализовать коллективное мышление. Построить такую ракету, чтобы она долетела до Марса или даже крошечной по космическим меркам кометы — для этого метода проб и ошибок явно недостаточно, но системные инженеры строить такие ракеты научились.

Инженерия научна

Можно думать о науке, ищущей компактное описание самой инженерии (engineering science) — эта наука должна рассказать о том, что делает системный инженер в ходе инженерного проекта.
Отношение к системной инженерии как к науке среди системных инженеров обычно отрицательное (хотя они и признают её полезность). Это отношение связано с тем, что “наука” обычно никогда не рассказывает, как породить ту или иную идею. Без “науки” трудно решать практические задачи, но сама наука обычно ничего не говорит о том, как породить идею решения. Наука лишь рассказывает о том, какие есть объекты, их характеристики и отношения друг с другом и что можно с ними делать. Что с этими объектами делать для решения конкретных задач — неведомо. Никакое знание физики не помогает решать даже олимпиадные задачки, что уж говорить о решении реальных проблем. Но без знания физики и олимпиадные задачки и инженерные проблемы решать труднее. Наука аналитична, инженерия же связана с решением проблем (проблема — когда никто не знает, что делать) и требует синтеза.

К сожалению, сведение всей инженерии только к науке и “аналитике” в ущерб практической деятельности по решению проблем, в том числе с помощью “ненаучных” по своей природе догадок-эвристик отражено и в учебных курсах по инженерии. Так, руководитель NASA Michael Griffin в речи 2007 г. System Engineering and the Two Cultures of Engineering (http://www.spaceref.com/news/viewsr.html?pid=23775) пишет, что:

I have always loved the view of the engineering profession captured by the great Theodore von Karman when he said, "Scientists study the world as it is; engineers create the world that has never been." Less eloquently, engineers are designers; they synthesize knowledge to produce new artifacts. Von Karman speaks to what most of us, and certainly most laymen, would consider the essence of engineering: engineers create things to solve problems.
But all of us who are engineers know that the engineering profession also has a rich scientific side, the analysis of these artifacts and the prediction of their behavior under various environmental and operational conditions. Adapting von Karman's observations, it may be said that engineering science is the study of that part of the world which has been created by man.
Sadly, many students have been led to believe that engineering science is engineering! In a curriculum of 120 or more credits leading to a bachelor's degree in a branch of engineering, the typical student is required to take one, or maybe two, courses in design. Everything else, aside from general-education requirements, focuses on the analysis, rather than the creation, of engineered objects. Graduate education often has no design orientation at all. So, engineering as taught really deals with only a part of engineering as it is practiced.

Мне всегда нравился взгляд на профессию инженера, сформулированный великим Теодором фон Карманом, когда он сказал: «Ученые изучают мир таким, какой он есть; инженеры создают мир, которого никогда не было». Менее красноречиво: инженеры — это дизайнеры; они синтезируют знания для создания новых артефактов. Фон Карман говорит о том, что большинство из нас и, конечно, большинство непрофессионалов считают сутью инженерного дела: инженеры создают вещи для решения проблем.
Но все мы, инженеры, знаем, что инженерная профессия также имеет богатую научную сторону: анализ этих артефактов и прогнозирование их поведения в различных условиях окружающей среды и эксплуатации. Адаптируя наблюдения фон Кармана, можно сказать, что инженерная наука — это изучение той части мира, которая была создана человеком.
К сожалению, многих студентов заставили поверить, что инженерные науки – это инженерия! В учебной программе, состоящей из 120 или более кредитов, ведущей к получению степени бакалавра в инженерной отрасли, типичному студенту необходимо пройти один или, возможно, два курса дизайна. Все остальное, кроме общеобразовательных требований, ориентировано на анализ, а не на создание инженерных объектов. Высшее образование часто вообще не имеет дизайнерской направленности. Таким образом, инженерное дело в том виде, в котором его преподают, на самом деле касается лишь части инженерного дела в том виде, в каком оно практикуется.

Основное, что должен уметь делать системный инженер — это создавать материальные объекты, а не анализировать их. Упор на синтез, а не на анализ характеризует инженера.

Интересно, что примерно такое же рассуждение проводится про образование менеджеров-предпринимателей. Henry Minzberg считает, что выпускников MBA (Master of Business Administration) готовят как аналитиков, а не синтетиков. Из них получаются не столько предприниматели-руководители предприятий, сколько начальники финансовых и прочих аналитических отделов компаний — тех подразделений, где основным продуктом являются “отчёты”. А потом совсем другие люди (часто с инженерным образованием) по этим отчётам принимают синтетические решения и реализуют какие-то идеи на практике.

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

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

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

Научное (формальное) основание системной инженерии

Системная инженерия и менеджмент опираются не на теории, а на эвристики. Они эмпирические, а не “строго научные” дисциплины типа физики или химии.
И тем не менее, есть ли какое-то научное (формальное, теоретическое) основание системной инженерии, т.е. существует ли компактное формализованное описание системноинженерного знания? Существует ли оно, или речь идёт только об искусстве (humanities, куда относятся литература, изобразительное искусство, кино и т.д.)? Почему системным инженерам выдают master of science, а не master of art in Systems Engineering?

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

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

В последнее время предприняты некоторые попытки разобраться с понятиями системноинженерного проекта (в рамках работ Русского отделения INCOSE и SEMAT). Настоящий курс использует все эти наработки (http://www.slideshare.net/ailev/course- ... ngomgsep13), задавая научное основание для описания практик системной инженерии.

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

Первое поколение — это алхинженерия (”алхимическая” инженерия), по аналогии с алхимией по сравнению с химией. Помните алхимические неформальные описания химических реакций в те времена, когда не было ещё развитой химической нотации и понимания различий между химическими элементами и сложными веществами? Вот пример (http://gothicsstyle.ru/2011/02/02/sredn ... a-recepty/): «Чтобы приготовить эликсир мудрецов, или философский камень, возьми, сын мой, философской ртути и накаливай, пока она не превратится в зелёного льва. После этого прокаливай сильнее, и она превратится в красного льва. Дигерируй (нагревание твёрдого тела с жидкостью, не доводя её до кипения) этого красного льва на песчаной бане с кислым виноградным спиртом, выпари жидкость, и ртуть превратится в камедеобразное вещество, которое можно резать ножом. Положи его в обмазанную глиной реторту и не спеша дистиллируй. Собери отдельно жидкости различной природы, которые появятся при этом. Ты получишь безвкусную флегму, спирт и красные капли. Киммерийские тени покроют реторту своим темным покрывалом, и ты найдёшь внутри неё истинного дракона, потому что он пожирает свой хвост. Возьми этого чёрного дракона, разотри на камне и прикоснись к нему раскалённым углём. Он загорится и, приняв вскоре великолепный лимонный цвет, вновь воспроизведёт зелёного льва. Сделай так, чтобы он пожрал свой хвост, и снова дистиллируй продукт. Наконец, мой сын, тщательно ректифицируй, и ты увидишь появление горючей воды и человеческой крови (Dumas, 1837, с. 30).

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

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

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

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

Системный подход как научное основание системной инженерии

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

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

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

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

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

Тем самым в основании системноинженерного мышления лежат:
● Системный подход (как думать о системах)
● Ситуационная инженерия методов (как думать о деятельности)

А в чём мышление?

Мышление появляется там и тогда, где и когда нужно решить проблемы — что-то, что непонятно как решать. До этого момента можно не мыслить, можно заимствовать какие-то справочные решения, использовать уже имеющиеся знания, “на автомате”. Хорошо сформулированная проблема обычно в себе содержит явное противоречие, которое необходимо “снять” — только в этот момент включается мышление, только в этот момент нужно “сесть и подумать” (а не “вспомнить и применить”). Иногда говорят, что мышление появляется, когда нужно “перевести проблемы в задачи”, т.е. создать список работ, которые понятно, как делать, и которые вместе решают проблему.

Системная инженерия тут неоригинальна, решение проблем путём формулирования и снятия противоречий (коллизий) присуще и теории ограничений Элияху Голдратта (”грозовая туча”), и ТРИЗ+, и системомыследеятельной методологии (школа Г.П.Щедровицкого).

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

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

Системноинженерное мышление как минимум помогает поделить решение проблемы между разными людьми в инженерном коллективе (более того, часто решение не может быть найдено одним гениальным человеком, требуется работа больших коллективов). Для этого системные инженеры явно обсуждают метод своей работы. Так, они не просто “генерируют основные инженерные решения”, а “создают архитектуру системы” — профессиональный язык системных инженеров (он основан на системном подходе) позволяет быстрее договариваться о том, что делать и о чём думать, чем при использовании бытового языка.

Итого: системноинженерное мышление ничего не говорит про содержание мышления, только про его форму. Более того, системная инженерия делает всё, чтобы не нужно было мыслить, а нужно было бы просто применять в проекте уже известные технические решения. Но мощь системной инженерии будет проявляться в тот момент, когда известных технических решений не будет и нужно делать первую из данного вида (first of a kind, FOAK) систему, или обходить какие-то жёсткие ограничения, которые не встречались раньше.

Наука/менеджмент = наука/инженерия

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

По большому счёту, к менеджменту более-менее приложимы те же рассуждения, которые приведены тут про инженерию. Менеджмент тоже ориентирован на синтез, а не на анализ. Он основан на эвристиках, и использует теории тогда, когда эти теории есть. Конечно, значительная часть этих эвристик отличается от инженерных эвристик. Более того, менеджерские эвристики не записывают в толстые справочники (хотя посмотрите на многочисленные регламенты по организации работ в любом предприятии — не напоминает инженерные справочники? Единственное отличие, что такие справочники готовят на каждом отдельном предприятии, редко используются общие справочники для многих предприятий).

пришлось поместить статью в раздел техники
так как пока инженерика ненаучна

Socioniks.org