Показаны записи 7061 - 7070 из 30962
"Развития для развития"
Совершенствование предпринятия -- это необходимость практиковать какую-то ступень зрелости практик, чтобы получить хоть какой-то шанс шагнуть вперёд, на следующую ступень развития. Совершенствование зрелой уже практики -- это часто путь к загниванию, это прекращение развития. После того, как вы довели до блеска бумажный документооборот, у вас могут быть огромные проблемы с развитием в сторону электронной коллаборации, ибо там не просто "электронный документооборот", но проблемы с самим понятием документа как универсальной сущности -- речь ведь идёт главным образом о совместной работе разных приложений с общими базами данных! Отказаться от документов в этот момент -- это будет восприниматься не как развитие, а как махровое антисовершенствование, разрушение основ и крах того совершенства, которым нужно гордиться! Совершенное воспринимается, как лучшее, а результат развития
-- только как хорошее (ибо всем очевидно, что этому ещё совершенствоваться и совершенствоваться, чтобы сравниться с уже имеющимся).
"Хорошее -- враг лучшего!" -- и развитие прекращается, не начавшись. Старые парадигмы, старые 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" -- и пройти ступеньку совершенствования, чтобы научиться этим пользоваться. Нужно сделать шаг "развития для развития". Это трудно: прекратить индивидуальное или корпоративное совершенствование в том, чем вы прямо сейчас сами или с коллегами заняты, и пройти ряд образовательных ступенек "о ни о чём".
Но эти "ступеньки ни о чём" лежат в основе любого общего образования, которое готовит развитых людей -- т.е. людей, не теряющихся в широком разнообразии ситуаций. Это совсем не "совершенствование", которое имеет своим предметом что-то предельно конкретное, и результаты которого довольно легко измерить (ибо совершенствование -- это повышенная эффективность поведения в одной и той же ситуации).
Самое эффективное для развития предпринятия -- это не сразу бросаться в преобразования и менять технологическое шило на технологическое мыло, а сначала научить людей говорить об их предпринятии, научить людей говорить о стратегировании/развитии на языке системноинженерного подхода. Люди получают возможность быстро договориться между собой и скооперироваться (в том числе договориться "внутри себя с собой", если ваше предпринятие -- это только вы сами). И тогда начинают происходить чудеса, тогда начинается настоящее развитие и осмысленное для него совершенствование -- в маркетинге, инженерии, операциях.
Совершенствование предпринятия -- это необходимость практиковать какую-то ступень зрелости практик, чтобы получить хоть какой-то шанс шагнуть вперёд, на следующую ступень развития. Совершенствование зрелой уже практики -- это часто путь к загниванию, это прекращение развития. После того, как вы довели до блеска бумажный документооборот, у вас могут быть огромные проблемы с развитием в сторону электронной коллаборации, ибо там не просто "электронный документооборот", но проблемы с самим понятием документа как универсальной сущности -- речь ведь идёт главным образом о совместной работе разных приложений с общими базами данных! Отказаться от документов в этот момент -- это будет восприниматься не как развитие, а как махровое антисовершенствование, разрушение основ и крах того совершенства, которым нужно гордиться! Совершенное воспринимается, как лучшее, а результат развития
-- только как хорошее (ибо всем очевидно, что этому ещё совершенствоваться и совершенствоваться, чтобы сравниться с уже имеющимся).
"Хорошее -- враг лучшего!" -- и развитие прекращается, не начавшись. Старые парадигмы, старые 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" -- и пройти ступеньку совершенствования, чтобы научиться этим пользоваться. Нужно сделать шаг "развития для развития". Это трудно: прекратить индивидуальное или корпоративное совершенствование в том, чем вы прямо сейчас сами или с коллегами заняты, и пройти ряд образовательных ступенек "о ни о чём".
Но эти "ступеньки ни о чём" лежат в основе любого общего образования, которое готовит развитых людей -- т.е. людей, не теряющихся в широком разнообразии ситуаций. Это совсем не "совершенствование", которое имеет своим предметом что-то предельно конкретное, и результаты которого довольно легко измерить (ибо совершенствование -- это повышенная эффективность поведения в одной и той же ситуации).
Самое эффективное для развития предпринятия -- это не сразу бросаться в преобразования и менять технологическое шило на технологическое мыло, а сначала научить людей говорить об их предпринятии, научить людей говорить о стратегировании/развитии на языке системноинженерного подхода. Люди получают возможность быстро договориться между собой и скооперироваться (в том числе договориться "внутри себя с собой", если ваше предпринятие -- это только вы сами). И тогда начинают происходить чудеса, тогда начинается настоящее развитие и осмысленное для него совершенствование -- в маркетинге, инженерии, операциях.
</>
Системноинженерное мышление и инженерия предпринятия
metanymous в посте Metapractice (оригинал в ЖЖ)
Системноинженерное мышление и инженерия предпринятия
Все наработки системного подхода вполне приложимы к предпринятиям-системам:
● Предпринятия материальны (согласно многим стандартам предпринятие/организация определяется как люди, здания, сооружения,
оборудование и другие ресурсы, причём среди людей есть договорённости по полномочиям в использовании этих ресурсов).
● Предпринятия состоят из структурных иерархий компонент, модулей, размещений (хотя о них говорят в такой терминологии редко, но подобного типа мышление сохраняется). Архитектура предпринятия (для современного предпринятия при этом обязательно подробное рассмотрение информационных систем в составе архитектуры предприятия) уже давно является одной из признанных дисциплин. Но, конечно, "принципиальные схемы" у предпринятия отличаются от оптических и гидравлических схем.
● Предпринятие имеет жизненный цикл (но тут нужно обратить внимание на особенность: как барон Мюнхгаузен вытягивал себя за волосы, так и предпринятие обычно само себя протаскивает через жизненный цикл: оно само себе обеспечивающая система и целевая система: само себя проектирует/стратегирует, само себя строит, само себя эксплуатирует -- но всё-таки различают производственную деятельность предпринятия и деятельность по развитию предпринятия).
Конечно, терминология отличается (хотя стейкхолдера назовут стейкхолдером и архитектуру архитектурой), но мы не зря тренировались абстрагироваться от конкретных слов и больше заниматься смыслом говоримого. Тем самым весь материал предыдущих разделов вполне применим для обсуждения предпринятия.
Все наработки системного подхода вполне приложимы к предпринятиям-системам:
● Предпринятия материальны (согласно многим стандартам предпринятие/организация определяется как люди, здания, сооружения,
оборудование и другие ресурсы, причём среди людей есть договорённости по полномочиям в использовании этих ресурсов).
● Предпринятия состоят из структурных иерархий компонент, модулей, размещений (хотя о них говорят в такой терминологии редко, но подобного типа мышление сохраняется). Архитектура предпринятия (для современного предпринятия при этом обязательно подробное рассмотрение информационных систем в составе архитектуры предприятия) уже давно является одной из признанных дисциплин. Но, конечно, "принципиальные схемы" у предпринятия отличаются от оптических и гидравлических схем.
● Предпринятие имеет жизненный цикл (но тут нужно обратить внимание на особенность: как барон Мюнхгаузен вытягивал себя за волосы, так и предпринятие обычно само себя протаскивает через жизненный цикл: оно само себе обеспечивающая система и целевая система: само себя проектирует/стратегирует, само себя строит, само себя эксплуатирует -- но всё-таки различают производственную деятельность предпринятия и деятельность по развитию предпринятия).
Конечно, терминология отличается (хотя стейкхолдера назовут стейкхолдером и архитектуру архитектурой), но мы не зря тренировались абстрагироваться от конкретных слов и больше заниматься смыслом говоримого. Тем самым весь материал предыдущих разделов вполне применим для обсуждения предпринятия.
Карточки состояний
Обычно контрольные вопросы оформляются в виде карточек состояний альф (да, карточек из плотной бумаги -- типа игральных карт, cards). Вот пример оформления такой карточки для альфы "стейкхолдеры", состояния "признаны" (первое состояние из шести): ...
Обратите внимание, что контрольные вопросы на карточках задаются не в терминах рабочих продуктов, а в терминах конечных результатов деятельности, в терминах дисциплины: напомним, что состояние одной альфы может свидетельствоваться десятком рабочих продуктов, но именно альфы используются для понимания ситуации. В этом-то и прелесть использования альф-из-дисциплины: они экономят мышление в ситуации с разнообразными рабочими продуктами и использующимися при их подготовке инструментами (компьютерными программами, бумажными формами и т.д.).
С другой стороны, команда решает (а иногда за команду решают ГОСТы, внутренние регламенты/стандарты организации, распоряжения, условия договора и т.д. -- когда у команды нет права определять свой способ работы), какие рабочие продукты и в какой степени детальности их разработки нужно использовать для ответов на утверждения карточек альф.
Ответы на вопросы карточек предполагают не только устное согласие членов команды с утверждением (в маленьких командах и небольших проектах это вполне приемлемо), но и возможность демонстрации рабочих продуктов в любой момент -- чтобы прояснить или удостоверить ответ. "Доверяй, но проверяй" -- это и есть системная инженерия. В авиационных чеклистах при ответе на вопрос, достаточно ли топлива, нужно не просто отвечать "да" по "внутренней уверенности", а действительно убедиться в достаточности топлива, взглянув на прибор. Состояние рабочих продуктов должно соответствовать ответам на вопросы, и это должно быть демонстрируемо.
Обычно контрольные вопросы оформляются в виде карточек состояний альф (да, карточек из плотной бумаги -- типа игральных карт, cards). Вот пример оформления такой карточки для альфы "стейкхолдеры", состояния "признаны" (первое состояние из шести): ...
Обратите внимание, что контрольные вопросы на карточках задаются не в терминах рабочих продуктов, а в терминах конечных результатов деятельности, в терминах дисциплины: напомним, что состояние одной альфы может свидетельствоваться десятком рабочих продуктов, но именно альфы используются для понимания ситуации. В этом-то и прелесть использования альф-из-дисциплины: они экономят мышление в ситуации с разнообразными рабочими продуктами и использующимися при их подготовке инструментами (компьютерными программами, бумажными формами и т.д.).
С другой стороны, команда решает (а иногда за команду решают ГОСТы, внутренние регламенты/стандарты организации, распоряжения, условия договора и т.д. -- когда у команды нет права определять свой способ работы), какие рабочие продукты и в какой степени детальности их разработки нужно использовать для ответов на утверждения карточек альф.
Ответы на вопросы карточек предполагают не только устное согласие членов команды с утверждением (в маленьких командах и небольших проектах это вполне приемлемо), но и возможность демонстрации рабочих продуктов в любой момент -- чтобы прояснить или удостоверить ответ. "Доверяй, но проверяй" -- это и есть системная инженерия. В авиационных чеклистах при ответе на вопрос, достаточно ли топлива, нужно не просто отвечать "да" по "внутренней уверенности", а действительно убедиться в достаточности топлива, взглянув на прибор. Состояние рабочих продуктов должно соответствовать ответам на вопросы, и это должно быть демонстрируемо.
</>
Информационные системы управления жизненным циклом
metanymous в посте Metapractice (оригинал в ЖЖ)
Информационные системы управления жизненным циклом
Информационные системы управления жизненным циклом (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), используемой службой эксплуатации.
Информационные системы управления жизненным циклом (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), используемой службой эксплуатации.
Управление жизненным циклом
Управление жизненным циклом (life cycle management) -- инженерная дисциплина, в отличие от менеджерской дисциплины управления проектами. Управление жизненным циклом может рассматриваться по-разному:
● Как синоним управления конфигурацией, управления инженерной документацией, управления жизненным циклом продукта (product life cycle management), плюс управление информаций. Основная задача -- предотвращение конфигурационных коллизий (т.е. ошибок, возникающих от несоответствия и противоречивости различных документов и моделей друг другу, а также их несоответствие воплощённой системе).
● Как дисциплина, описывающая разные логистические организации распределения инженерных практик (инженерии требований, инженерии системной архитектуры, и т.д.) по стадиям жизненного цикла (последовательное выполнение практик, параллельное выполнение практик, регулярность проведения проверок, ритмичность проведения совещаний и перепланирования, и т.д.).
● Так называется ситуационная инженерия методов с точки зрения менеджеров (это неслучайно. Именно языки и стандарты ситуационной инженерии методов используются для описания жизненного цикла: описываются практики, а затем показывается их распределение по стадиям жизненного цикла. Стандарты ситуационной инженерии методов -- OMG Essence, а также часто поминающийся в этой главе ISO 24744.
Проектное управление -- это главным образом календарное планирование и контроль выполнения плана, обеспечение плана ресурсами занимает главное место в управлении проектами, отслеживание графика центрально. При этом управление проектами работает именно с проектами, а проекты обычно занимают малую часть жизненного цикла.
Есть особое понимание "управления жизненным циклом" в атомной отрасли, задаваемое документами МАГАТЭ (международного регулятора): у атомщиков управление жизненным циклом понимается как практика продления жизни действующих атомных станций, "управление старением". Тем не менее, это особое использование термина сегодня сменяется постепенно на общепринятое в системной инженерии понимание.
Управление жизненным циклом в любом случае охватывает полный жизненный цикл системы (т.е. охватывает множество проектов) и сосредотачивается не на "сдаче вовремя", а на содержательном объединении работ разных стадий жизненного цикла, использовании необходимых инженерных практик. Акцент тут на содержательном change of mental frameworks (изменении преимущественного мышления) в ходе смены стадий жизненного цикла, а не на точном выполнении графика. В управлении жизненным циклом волнует такая организация работы, которая подразумевает наличие содержательно необходимых ресурсов (а не ресурсов в достаточном количестве для выполнения содержательных инженерных практик, этим занимается проектное управление).
Управление жизненным циклом (life cycle management) -- инженерная дисциплина, в отличие от менеджерской дисциплины управления проектами. Управление жизненным циклом может рассматриваться по-разному:
● Как синоним управления конфигурацией, управления инженерной документацией, управления жизненным циклом продукта (product life cycle management), плюс управление информаций. Основная задача -- предотвращение конфигурационных коллизий (т.е. ошибок, возникающих от несоответствия и противоречивости различных документов и моделей друг другу, а также их несоответствие воплощённой системе).
● Как дисциплина, описывающая разные логистические организации распределения инженерных практик (инженерии требований, инженерии системной архитектуры, и т.д.) по стадиям жизненного цикла (последовательное выполнение практик, параллельное выполнение практик, регулярность проведения проверок, ритмичность проведения совещаний и перепланирования, и т.д.).
● Так называется ситуационная инженерия методов с точки зрения менеджеров (это неслучайно. Именно языки и стандарты ситуационной инженерии методов используются для описания жизненного цикла: описываются практики, а затем показывается их распределение по стадиям жизненного цикла. Стандарты ситуационной инженерии методов -- OMG Essence, а также часто поминающийся в этой главе ISO 24744.
Проектное управление -- это главным образом календарное планирование и контроль выполнения плана, обеспечение плана ресурсами занимает главное место в управлении проектами, отслеживание графика центрально. При этом управление проектами работает именно с проектами, а проекты обычно занимают малую часть жизненного цикла.
Есть особое понимание "управления жизненным циклом" в атомной отрасли, задаваемое документами МАГАТЭ (международного регулятора): у атомщиков управление жизненным циклом понимается как практика продления жизни действующих атомных станций, "управление старением". Тем не менее, это особое использование термина сегодня сменяется постепенно на общепринятое в системной инженерии понимание.
Управление жизненным циклом в любом случае охватывает полный жизненный цикл системы (т.е. охватывает множество проектов) и сосредотачивается не на "сдаче вовремя", а на содержательном объединении работ разных стадий жизненного цикла, использовании необходимых инженерных практик. Акцент тут на содержательном change of mental frameworks (изменении преимущественного мышления) в ходе смены стадий жизненного цикла, а не на точном выполнении графика. В управлении жизненным циклом волнует такая организация работы, которая подразумевает наличие содержательно необходимых ресурсов (а не ресурсов в достаточном количестве для выполнения содержательных инженерных практик, этим занимается проектное управление).
6. Виды жизненного цикла
Жизненный цикл чего?
Жизненный цикл (life cycle) -- это не "жизненный" и не "цикл". Название произошло от биологического "жизненного цикла", ибо особь каждого вида рождается, живёт, затем умирает. И потом следующая особь рождается -- и так далее, по циклу, игнорируя факт, что "по циклу" проходят совсем разные существа.
Технические системы тоже "рождаются" и "умирают", а затем появляются новые системы -- но это и не "жизнь" и не такой уж "цикл". Жизненных циклов бывает много разных (системы, проекта, разные виды жизненного цикла), и нужно в этом не запутаться -- всех их, конечно, называют просто "жизненный цикл", забывая уточнить, какое использование термина имелось ввиду. Жизненный цикл системы (system life cycle) -- это деятельность всех обеспечивающих систем, ведущих целевую систему от её замысла ("рождения" определения системы) до вывода из эксплуатации ("смерти" воплощения системы), обычно эта деятельность разбита на стадии (stages), которые вполне могут быть не только последовательными, но и перекрываться во времени друг с другом.
Жизненный цикл (деятельность) начинается в какой-то момент времени, а затем заканчивается в какой-то момент времени, стадии его тоже начинаются и заканчиваются в какие-то моменты. Когда говорят "жизненный цикл", то всегда подразумевают полный отрезок времени "от замысла до вывода из эксплуатации", "от рождения до смерти", причём разбитый на стадии. Но отрезками времени не "управляют", а вот когда говорят "управление жизненным циклом" как раз говорят об управлении деятельностью (управлении обеспечивающей системой), обеспечивающей переход от одной стадии жизненного цикла к другой. Стадии жизненного цикла выделяют по изменению в ходе жизненного цикла преимущественного образа мышления (согласно ISO 24744 -- change of mental framework).
Это не слишком формальное определение, но оно как минимум не предлагает сосредотачиваться на "состоянии целевой системы", а даётся именно в терминах обеспечивающих систем. На разных стадиях жизненного цикла системы (изделия, установки, сложного инженерного объекта и т.д. -- помним, что мы тут про суть дела, а не про терминологию и выбор обозначающих суть дела слов) люди думают про разное: на стадии проектирования люди думают о проектировании, на стадии строительства о стройке, на стадии эксплуатации -- об эксплуатации.
Жизненный цикл проекта (project life cycle) -- это часть жизненного цикла системы, которая укладывается в рамки проекта. Иногда жизненный цикл проекта совпадает во времени с какой-то стадией жизненного цикла, иногда не совпадает. Более того, совершенно необязательно, что в рамки жизненного цикла проекта
(деятельности проекта) попадает вся деятельность какой-то стадии жизненного цикла системы. Проект обычно бьётся на этапы.
Жизненный цикл чего?
Жизненный цикл (life cycle) -- это не "жизненный" и не "цикл". Название произошло от биологического "жизненного цикла", ибо особь каждого вида рождается, живёт, затем умирает. И потом следующая особь рождается -- и так далее, по циклу, игнорируя факт, что "по циклу" проходят совсем разные существа.
Технические системы тоже "рождаются" и "умирают", а затем появляются новые системы -- но это и не "жизнь" и не такой уж "цикл". Жизненных циклов бывает много разных (системы, проекта, разные виды жизненного цикла), и нужно в этом не запутаться -- всех их, конечно, называют просто "жизненный цикл", забывая уточнить, какое использование термина имелось ввиду. Жизненный цикл системы (system life cycle) -- это деятельность всех обеспечивающих систем, ведущих целевую систему от её замысла ("рождения" определения системы) до вывода из эксплуатации ("смерти" воплощения системы), обычно эта деятельность разбита на стадии (stages), которые вполне могут быть не только последовательными, но и перекрываться во времени друг с другом.
Жизненный цикл (деятельность) начинается в какой-то момент времени, а затем заканчивается в какой-то момент времени, стадии его тоже начинаются и заканчиваются в какие-то моменты. Когда говорят "жизненный цикл", то всегда подразумевают полный отрезок времени "от замысла до вывода из эксплуатации", "от рождения до смерти", причём разбитый на стадии. Но отрезками времени не "управляют", а вот когда говорят "управление жизненным циклом" как раз говорят об управлении деятельностью (управлении обеспечивающей системой), обеспечивающей переход от одной стадии жизненного цикла к другой. Стадии жизненного цикла выделяют по изменению в ходе жизненного цикла преимущественного образа мышления (согласно ISO 24744 -- change of mental framework).
Это не слишком формальное определение, но оно как минимум не предлагает сосредотачиваться на "состоянии целевой системы", а даётся именно в терминах обеспечивающих систем. На разных стадиях жизненного цикла системы (изделия, установки, сложного инженерного объекта и т.д. -- помним, что мы тут про суть дела, а не про терминологию и выбор обозначающих суть дела слов) люди думают про разное: на стадии проектирования люди думают о проектировании, на стадии строительства о стройке, на стадии эксплуатации -- об эксплуатации.
Жизненный цикл проекта (project life cycle) -- это часть жизненного цикла системы, которая укладывается в рамки проекта. Иногда жизненный цикл проекта совпадает во времени с какой-то стадией жизненного цикла, иногда не совпадает. Более того, совершенно необязательно, что в рамки жизненного цикла проекта
(деятельности проекта) попадает вся деятельность какой-то стадии жизненного цикла системы. Проект обычно бьётся на этапы.
Два типа "целого"
Про то, как описывать систему, много подробней будет в следующем разделе. Сейчас нас волнует только то, как описывается воплощение системы как целое -- но с учётом того факта, что разные люди видят даже это "целое" как ипостаси! И тут нужно не путать два использования слово "целое" (единое, совокупное, целокупное и т.д.):
● По отношениям часть-целое (разбиения) -- это когда система представляется состоящей из частей и сама является частью другой
системы. Холархии, "зум" и "уровни рассмотрения" как уровни разбиения системы на части, эмерджентность от взаимодействия частей. Когда говорят о частях и целом, обычно имеют ввиду воплощение системы.
● Целое, проявляющее себя в разных ипостасях, рассматриваемое разными стейкхолдерами по-разному -- в системном подходе это "мультидисциплинарность", объединение описаний, отсутствие редукционизма (сведения к одной дисциплине), холизм (та же "целостность", но не про части! Про "разносторонность"!). Когда говорят о частных и целостных описаниях, то обычно имеют ввиду определение системы (разные описания системы).
Не путайте эти две разных "целостности" системы. Конечно, сам разговор о воплощении системы подразумевает какое-то описание этого воплощения -- как минимум, описание самого воплощения: называние его по имени, учитывая какой-то аспект/ипостась. Именно поэтому, говоря в этом разделе про воплощение системы мы вынужденно касаемся и определения системы, её частей-подсистем и элементов, надсистемы, использующей системы, систем в операционном окружении, обеспечивающей системы и т.д. -- как минимум, называние их с учётом аспекта/ипостаси.
Про то, как описывать систему, много подробней будет в следующем разделе. Сейчас нас волнует только то, как описывается воплощение системы как целое -- но с учётом того факта, что разные люди видят даже это "целое" как ипостаси! И тут нужно не путать два использования слово "целое" (единое, совокупное, целокупное и т.д.):
● По отношениям часть-целое (разбиения) -- это когда система представляется состоящей из частей и сама является частью другой
системы. Холархии, "зум" и "уровни рассмотрения" как уровни разбиения системы на части, эмерджентность от взаимодействия частей. Когда говорят о частях и целом, обычно имеют ввиду воплощение системы.
● Целое, проявляющее себя в разных ипостасях, рассматриваемое разными стейкхолдерами по-разному -- в системном подходе это "мультидисциплинарность", объединение описаний, отсутствие редукционизма (сведения к одной дисциплине), холизм (та же "целостность", но не про части! Про "разносторонность"!). Когда говорят о частных и целостных описаниях, то обычно имеют ввиду определение системы (разные описания системы).
Не путайте эти две разных "целостности" системы. Конечно, сам разговор о воплощении системы подразумевает какое-то описание этого воплощения -- как минимум, описание самого воплощения: называние его по имени, учитывая какой-то аспект/ипостась. Именно поэтому, говоря в этом разделе про воплощение системы мы вынужденно касаемся и определения системы, её частей-подсистем и элементов, надсистемы, использующей системы, систем в операционном окружении, обеспечивающей системы и т.д. -- как минимум, называние их с учётом аспекта/ипостаси.
Роботы такие, роботы сякие http://ailev.livejournal.com/1174770.html
Экстенсионализм
Тут придётся вспомнить о трудах Декарта, который задавался вопросом: а как вообще понять, об одном и том же объекте говорят люди, когда они отмечают в объекте самые разные свойства, или всё-таки о разных? Скажем, один инженер говорит о тяжёлой и светлой системе, а другой -- о громкой и убойной. Как понять, что речь идёт об одной и той же системе? Декарт предложил экстенсионализм (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 пространственно-временную протяжённость, то есть являются онтологическими "индивидами". И если один видит дом, другой видит детский сад, третий видит объект ЖКХ, четвертый видит "строение", и все эти разные люди (для целей своей деятельности) настаивают на своём понимании
системы, то между ними всеми очень легко договориться: если обсуждаемые ими якобы разные системы занимают одно и то же место в пространстве-времени, то это одна и та же система, независимо на столь разные имена, столь разное понимание, деление на части, описание свойств и т.д.. Всё просто, если не отрываться от того, что мы живём в нашем физическом мире, и все наши фантазии и мысли в конечном итоге как-то связаны с этим миром, а не чем-то потусторонним (трансцедентным).
Такие рассуждения позволяют системным инженерам более-менее формально работать с системой как "многерицей" -- одновременно единой и одновременно различной в каждой её ипостаси.
Тут придётся вспомнить о трудах Декарта, который задавался вопросом: а как вообще понять, об одном и том же объекте говорят люди, когда они отмечают в объекте самые разные свойства, или всё-таки о разных? Скажем, один инженер говорит о тяжёлой и светлой системе, а другой -- о громкой и убойной. Как понять, что речь идёт об одной и той же системе? Декарт предложил экстенсионализм (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 пространственно-временную протяжённость, то есть являются онтологическими "индивидами". И если один видит дом, другой видит детский сад, третий видит объект ЖКХ, четвертый видит "строение", и все эти разные люди (для целей своей деятельности) настаивают на своём понимании
системы, то между ними всеми очень легко договориться: если обсуждаемые ими якобы разные системы занимают одно и то же место в пространстве-времени, то это одна и та же система, независимо на столь разные имена, столь разное понимание, деление на части, описание свойств и т.д.. Всё просто, если не отрываться от того, что мы живём в нашем физическом мире, и все наши фантазии и мысли в конечном итоге как-то связаны с этим миром, а не чем-то потусторонним (трансцедентным).
Такие рассуждения позволяют системным инженерам более-менее формально работать с системой как "многерицей" -- одновременно единой и одновременно различной в каждой её ипостаси.
*Многерица
Разные люди видят в одной и той же системе абсолютно разные объекты -- ибо они смотрят на них согласно своей роли, своей позиции. Это суть системного подхода, это и есть холизм (полноты рассмотрения с разных позиций стейкхолдеров по отношению к деятельности) против редукционизма (когда всё-всё связанное с системой можно объяснить с позиции одного научного предмета).
В христианстве есть довольно сложное понятие троицы: бог представляется одновременно и единым, и существующим в трёх ипостасях (отца, сына и святого духа). Проблема в том, что думать о боге нужно одновременно и о как едином, и как об отдельных ипостасях.
То же самое есть и во многих других религиях, хотя там необязательно троица. Так, в даосизме единое (дао) одновременно представляется как двоица (противоположности инь и янь). Впрочем, некоторые и тут видят троицу:
"Он принял свой аспект и поднял атрибут" ("He has taken on his Aspect and raised up an Attribute" -- "Бог/князь/Lord света", Роджер Желязны -- это уже фантазийные перепевы индуизма и буддизма). Все религии как-то учитывают возможность различных обликов/аспектов/ипостасей для какой-то божественной сущности -- и тут нужно добавить, что религиозность и божественность тут не при
чём. Но метанойя думать об одном как о разном и как об одном и том же вам потребуется. Трудность мышления в том, что нужно о какой-то системе одновременно думать как о чём-то, совмещающем разные свои ипостаси, так и как об отдельных ипостасях -- в том числе при той трудности, что ипостаси этой системы нередко имеют ещё и разные имена, обозначающие систему-как-ипостась (хотя одинаковые имена для разных ипостасей встречаются даже чаще).
Мы уже знакомились с ситуацией, когда Принц Гамлет, народный артист и Черезколеноногузадерищенский могут быть одним человеком, но называться по-разному в зависимости от того, что нам от него нужно -- понять, какая фраза будет следующая в его пьесе, когда он планирует выучить новую роль в новом спектакле или есть ли у него дети. То же можно сказать и о системе: "измеритель давления", "манометр KLM-23 завода "Давижмимонтажавтоматика"" и "датчик в пятом ящике на третьей полке склада номер 4" вполне могут оказаться одним и тем же прибором -- но разные имена свидетельствуют о том, что мы планируем совершенно разные действия с этим прибором, поэтому для нас один и тот же прибор выступает в разных ипостасях и имеет поэтому разные имена. Для разных стейкхолдеров система будет представляться в своих аспектах-ипостасях совершенно по-разному -- но при этом оставаться целостной, холистичной, целокупностью всех своих ипостасей/аспектов.
Одному стейкхолдеру на этой картинке нужно знать, как работает эта система, и он выбирает для этого одни объекты-части. Другому стейкхолдеру нужно систему собирать, третьему -- какое место она будет занимать. И поэтому каждый стейкхолдер по-своему находит части в так "односторонне" (со стороны нужд его деятельности) понимаемой системе.
Это "не единое" просто нормально, так и должно быть! Единым может быть только единонемыслие (Салтыков-Щедрин). Много разных профессионалов по-разному определяют одну и ту же систему, это нормально.
Кстати, шутка про наполовину полный стакан существует и для системных инженеров: "стакан вдвое больше, чем нужно" (помним, что системный инженер переделывает систему -- все инженерные описания нужны именно для этого!).
Разные люди видят в одной и той же системе абсолютно разные объекты -- ибо они смотрят на них согласно своей роли, своей позиции. Это суть системного подхода, это и есть холизм (полноты рассмотрения с разных позиций стейкхолдеров по отношению к деятельности) против редукционизма (когда всё-всё связанное с системой можно объяснить с позиции одного научного предмета).
В христианстве есть довольно сложное понятие троицы: бог представляется одновременно и единым, и существующим в трёх ипостасях (отца, сына и святого духа). Проблема в том, что думать о боге нужно одновременно и о как едином, и как об отдельных ипостасях.
То же самое есть и во многих других религиях, хотя там необязательно троица. Так, в даосизме единое (дао) одновременно представляется как двоица (противоположности инь и янь). Впрочем, некоторые и тут видят троицу:
"Он принял свой аспект и поднял атрибут" ("He has taken on his Aspect and raised up an Attribute" -- "Бог/князь/Lord света", Роджер Желязны -- это уже фантазийные перепевы индуизма и буддизма). Все религии как-то учитывают возможность различных обликов/аспектов/ипостасей для какой-то божественной сущности -- и тут нужно добавить, что религиозность и божественность тут не при
чём. Но метанойя думать об одном как о разном и как об одном и том же вам потребуется. Трудность мышления в том, что нужно о какой-то системе одновременно думать как о чём-то, совмещающем разные свои ипостаси, так и как об отдельных ипостасях -- в том числе при той трудности, что ипостаси этой системы нередко имеют ещё и разные имена, обозначающие систему-как-ипостась (хотя одинаковые имена для разных ипостасей встречаются даже чаще).
Мы уже знакомились с ситуацией, когда Принц Гамлет, народный артист и Черезколеноногузадерищенский могут быть одним человеком, но называться по-разному в зависимости от того, что нам от него нужно -- понять, какая фраза будет следующая в его пьесе, когда он планирует выучить новую роль в новом спектакле или есть ли у него дети. То же можно сказать и о системе: "измеритель давления", "манометр KLM-23 завода "Давижмимонтажавтоматика"" и "датчик в пятом ящике на третьей полке склада номер 4" вполне могут оказаться одним и тем же прибором -- но разные имена свидетельствуют о том, что мы планируем совершенно разные действия с этим прибором, поэтому для нас один и тот же прибор выступает в разных ипостасях и имеет поэтому разные имена. Для разных стейкхолдеров система будет представляться в своих аспектах-ипостасях совершенно по-разному -- но при этом оставаться целостной, холистичной, целокупностью всех своих ипостасей/аспектов.
Одному стейкхолдеру на этой картинке нужно знать, как работает эта система, и он выбирает для этого одни объекты-части. Другому стейкхолдеру нужно систему собирать, третьему -- какое место она будет занимать. И поэтому каждый стейкхолдер по-своему находит части в так "односторонне" (со стороны нужд его деятельности) понимаемой системе.
Это "не единое" просто нормально, так и должно быть! Единым может быть только единонемыслие (Салтыков-Щедрин). Много разных профессионалов по-разному определяют одну и ту же систему, это нормально.
Кстати, шутка про наполовину полный стакан существует и для системных инженеров: "стакан вдвое больше, чем нужно" (помним, что системный инженер переделывает систему -- все инженерные описания нужны именно для этого!).
Дочитали до конца.