Обсуждение

а где-то вас можно живьем послушать?

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

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

А я обычно всегда так и делаю, анонсирую у себя в блоге.

> А поскольку "подход" в сути своей мы определяем как метод получения описаний (как описывать действительность, чтобы углядеть в ней то, с чем потом можно работать ... Уточнение 1. Следовало написать "как описывать реальность". Для пояснения можно воспользоваться вашими картинками от 16 ноября: -- Реальность - это "треугольничек" под названием Concrete System -- Действительность - это "треугольничек" под названием Conceptual System -- Знания (Symbolic System) - это, соответственно, описание реальности в действительности. Или другими словами, описание (отражение на знаках, знаниях) наших представлений об объектах. Уточнение 2. В определении системы не случайно есть понятие субъекта. Система - это "процесс с субъектом" и именно этим она отличается от "просто процесса". Примечание 3. Мне очень нравится ваша идея трактовки framework как подхода. Хотелось бы дополнить, что следует в "метод получения описания" включать не только систему "в чистом виде", а систему в контексте. Это становится особенно явно при рассмотрении системы при форсайте (foresight). Форсайтные фреймворки системы просто немыслимы без контекста среды.

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

> Тем более, что я не вводил термины "действительность" и "реальность" (хотя и знаю эту различалку). Некоим образом не хотел вас упрекнуть. Я знаю ваше критическое отношение к философии. И поэтому, я хотел обратить внимание, что сегодняшней системной инженерии очень сложно, поскольку и философия, и программная инженерия претендуют на неё как на свою неотъемлемую часть. Философия пытается модели вогнать в философские определения, а программной инженерии (ISO 12207) приходится указывать её место в структуре системной инженерии (ISO 15288). :-) > отражение в знаках может быть не наших представлений об объектах, а данных прямо от датчиков (историческое описание главным образом идет оттуда) Датчики (и техника вообще) - это продолжение органов чувств и, главное, представлений человека о мире. Термометр - это наше представление о температуре, а не о том, что там на самом деле на микроуровне творится. Да и БАК для измерения температуры тоже не очень удобен, хотя и даёт некоторые представления о мелкомире. Поэтому, пишет человек вручную или посредством датчика не имеет значения. Любыми средствами он пишет это для себя так, как может интерпретировать, т.е. представить себе. Согласен, что понятие "субъект системы" прагматичнее заменить понятием "актор", поскольку сразу понятна ролевая реализация (особенно программерам). Но я имел ввиду не это. В вашей фразе "углядеть процесс как систему" зарыта бритва Оккама. Если определён "процесс", то зачём в нём углядывать "систему". А есть есть система, то зачем её обзывать "процессом"?

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

> поглядите на первый же содержательный слайд О! На первом же слайте вы упустити _очень_ важный момент. В перечислении подходов первым должен стоять холистический подход. Именно он является тем "клеем", с помощью которого вы сможете объединить перечисленные подходы. Сейчас набор выглядит мозаичным, а не целостным. Другими словами, названные вами подходы - это компоненты некоторой (методологической) системы. Но саму систему, от которой эти компоненты, вы не обозначаете. :-) И ещё. На первом слайде скзано "система _может_ включать людей и организации". Нет! Система _обязана_ включать людей. Системы без людей просто не существует. По определению. Система - это артефакт, созданный людьми и для людей. Реальные Природа и Вселенная системами не являются (научный, реалистический взгляд). А вот действительный мир системой является, поскольку там есть Творец (но это не естественнонаучный взгляд). И поскольку ваша методологическая система является лишь "узким" взглядом на мир нужно где-то аккуратно оговориться о каком мире вы говорите. Для этого достаточно "помянуть в суе" слова "научный" или "реальный" (мир, подход, взгляд и т.п.). > я говорю о гармонизации подходов -- системного, процессного, архитектурного и т.д. (моё субъективное и, конечно, неправильное мнение) Нужно говорить не о компромиссе (гармонизации) методов, а об объединении методов под одной крышей холистического подхода. Все перечисленные вами методы - это лишь "описание слона с разных сторон". Холистический слон от этого не меняется.

Насчет "холистического подхода" -- одна из многочисленных заморочек, не более. Не годится на роль "объединителя всего". Чем, например, "интегральный подход" Кена Уилбера хуже? Или СМД-методология, которая про "холистичность" не любит распространяться? Сама обсуждаемая (system of interest) система у меня обозначена -- это системная инженерия, инженерный подход, который сплавлен с системным, процессным, архитектурным и т.д. Насчет "научности" или "реальности" даже не хочу заикаться. Мир у меня -- мир инженера, а поскольку инженер работает во множестве подходов по определению, то иногда это проектный мир, иногда научный, иногда вполне человечий-субъективный. То, что гармонизация всех проблем не решает -- это факт. Правильный ход, конечно, на мэппирование подходов друг на друга. Но и отступаться от задачи гармонизации совсем тоже нельзя. Если у меня все равно стоит задача перевода, то я в этот момент могу подкрутить значения некоторых понятий. Никакого компромисса, но разные мэппированные друг на друга понятия я могу попробовать хотя бы одинаково обозвать, чем и занимаюсь. Это у меня такой вариант гармонизации. Могут ли люди входить в систему? Могут. А могут и не входить, а только подразумеваться. Подразумевание не в счет. Это большая беда всяких "систем безопасности", что в них то программно-аппаратный комплекс входит, то (кроме того самого программно-аппаратного комплекса) еще и все люди, и все оборудование, и вся планета Земля. Фокус обсуждения тут же разбивается в мелкую пыль. Когда вы обсуждаете систему типа ГЭС во время эксплуатации, вы должны определиться: то ли это система, с которой работают люди-"эксплуататоры", то ли ГЭС+ее сотрудники составляют единую систему, и тогда кто работает с этой системой? Рядом стоящий "контур управления"? Тогда и возникает соблазн оторваться от производства и учинить этот самый отдельный "контур управления"...

Ещё раз про субъектов и акторов. Вы акторов помещаете вовне, за границей системы. Например, слайд "Процессный подход" написано "... акторы над/с системой". А акторы, воплощённые (реализованные) в процессы, находятся _внутри_ границ системы. Это звучало-бы как "акторы системы". Можно привести такой пример. Фирма - система. Акторы - это руководство фирмы, а стейкхолдеры - это акционеры, поставщики, потребители, налоговые органы, бандиты и т.п.

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

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

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

Это кестлеровские холоны ("матрешка систем"), я их недавно поминал. Но чтобы не впасть в дурацкое философствование, нужно четко понимать, чего хочешь добиться таким рассмотрением. Есть принцип бритвы Оккама про неумножение числа сущностей в объяснениях. Так и тут. У меня нет желания преподать людям урок философии, у меня есть желание объяснить людям, что им писать в Концепции управления жизненным циклом. С какого бодуна я им буду про холоны рассказывать? У меня на весь системный подход один слайд выделен! Я даже про enabling system не рассказываю (прямой термин из стандарта), и system in operative environment (тоже из стандарта ISO 15288), а вы мне про холоны советуете приплести! Я был бы благодарен за ровно обратную работу: показать, какие термины лишние и не требуются для понимания при написании Концепции управления жизненным циклом. А увеличить число сущностей без труда можно в любом направлении. Например, можно сделать совершенно отдельную презентацию по тому, что жизненный цикл процесса -- это прохождение им уровней зрелости. Правда, и там про холоны необязательно будет рассказывать.

Еще раз: мои системы могут быть с людьми, а могут быть и без людей -- в зависимости от того, какие описания системы меня интересуют. У меня есть выбор. А у вас (с обязательными людьми в системе) догма.

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

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

> Я был бы благодарен за ровно обратную работу: показать, какие термины лишние и не требуются для понимания при написании Концепции управления жизненным циклом. Я задал себе вопрос, а как бы я рассказывал о том же самом, на основе материала вашей презентации. Я бы это делал так (это не значит, что это правильно!): 1) Начал бы с наличия существующей методологической проблемы (слайд 14 Проблемы текущего подхода) 2) Сказал бы, что в современных условиях прагматично строить методологию на основе международных стандартов (слайд 10). Что первым делом нужно построить профиль стандартов, состоящих из двух разделов "Как описывать?" (ISO 42010, ISO 9000, ISO 90000, CMM) и "Что описывать?" (ISO 15288, 15026, ISO 12207, 15504). Стандарты группы "Как" описывают компоненты системы в разделе "Что". 3) Сказал бы, что на основе профиля стандартов получается эталонная модель (системы) (слайд 2). 4) А все остальные слайды - это демонстрация применения стандартов группы "Как" к группе "Что" и полученные фрагменты описания (фрагменты фреймворков). Примечание 1. Некоторые стандарты придётся "раздербанить" между двумя разделами. Например, 15504 как CMM (оценка) и как "группа процессов". Примечание 2. Получил бы ДВА глоссария - методологический и инженерный. Количество терминов в инженерном глоссарии сократилось бы. Не могу сходу сказать какие термины вошли бы туда, поскольку для этого пришлось бы проделать всю вышеописанную работу. Могу лишь эмпирически с уверенностью сказать, что часть - это меньше целого :-)

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