- •1. Системная инженерия
- •Определения системной инженерии
- •Ответственность за целокупность и междисциплинарность
- •Для чего нужна системная инженерия: победить сложность
- •Профессия системного инженера
- •Системный инженер как профессия
- •Профессиональные организации системных инженеров
- •Можно ли научить творчеству?
- •Метанойя — не просто обучение, а смена способа мышления
- •Можно ли научить системного инженера, или им нужно родиться?
- •Моделирование творчества в виде, понятном даже компьютеру
- •Методология системной инженерии
- •Образование системных инженеров
- •Отличия системной инженерии от других дисциплин
- •Системная инженерия против других инженерий
- •Системная инженерия против советской инженерии
- •Системная инженерия и системотехника
- •Системная инженерия и менеджмент
- •Инженерный менеджмент
- •Управление технологией
- •Системная инженерия и государство
- •2. Формализмы системной инженерии
- •Терминология и онтология
- •Соглашение по терминологии
- •Выбирайте слова
- •Что такое онтология
- •Индивиды, классы и классификаторы
- •Экстенсионализм и интенсионализм
- •Функциональные объекты
- •Процессы и действия
- •О логических уровнях
- •Выбор уровней
- •Математические формализмы
- •Объекты и атрибуты
- •Объекты и факты
- •Факты и графы
- •Теория категорий
- •Моделеориентированность
- •Что такое модели
- •Онтологизирование, моделирование, программирование
- •Зачем моделировать
- •Почему моделирование не повсеместно
- •Информатика
- •Принципы моделеориентированности
- •3. Инженерия и наука
- •Инженерия не научна
- •Разница между инженерами и учёными
- •Предмет инженерии и научные предметы для инженерных объектов
- •Ненаучность инженерии. Эвристики
- •Наука как “научение птиц полёту”
- •Инженерия научна
- •Инженерная наука
- •Научное (формальное) основание системной инженерии
- •Системный подход как научное основание системной инженерии
- •Системноинженерное мышление коллективно
- •А в чём мышление?
- •Наука/менеджмент = наука/инженерия
- •4. Схема/онтология инженерного проекта
- •Схемное/онтологичное мышление
- •Ситуационная инженерия методов
- •Описание метода в настоящем курсе системноинженерного мышления
- •Яблоки из жизни и яблоки из задачи
- •Альфы
- •Метонимия и схемы
- •Методологическая действительность: дисциплины, практики, методы
- •Дисциплины/области интереса
- •Практики
- •Метод
- •Методологическая действительность и действительность предпринятия
- •Семь основных альф инженерного проекта
- •Основы системной инженерии: альфы инженерного проекта
- •Стейкхолдеры
- •Возможности
- •Определение системы
- •Воплощение системы
- •Команда
- •Работы
- •Технология
- •5. Системный подход
- •Понятие “подхода”
- •Системный подход в системной инженерии
- •Варианты системного подхода
- •Системный подход и кибернетика
- •Сложность и меры сложности
- •Термин “система”
- •Классификация систем по ISO 15288
- •Системная медитация
- •“Сначала как часть надсистемы”
- •Стейкхолдеры. Театральная метафора
- •Система — это субъективное понятие
- •Театральная метафора.
- •Позиция
- •Работа со стейкхолдерами
- •Граница системы и деятельностная субъективность её проведения
- •“Просто” системы и системы систем.
- •Навигация по уровням холархии ”zoom — select”.
- •Системы с участием людей: осторожно!
- •6. Воплощение системы: компоненты, модули, размещения
- •Многерица
- •Сколько разных ипостасей в одной системе?
- •Принцип разделения интересов
- •Закрытый и открытый миры
- •Два типа “целого”
- •Компоненты, модули, размещения
- •Компоненты
- •Модули
- •Размещения
- •Структура системы: разбиения.
- •Разбиения (breakdowns)
- •Представления разбиений
- •Обозначения систем
- •Практики изготовления (производства)
- •7. Определение системы: требования, архитектура, неархитектурная часть проекта
- •Определения и описания
- •Обобщение ISO 42010 на определение системы
- •Контроль конфигурации
- •Фокусирование определений системы
- •Практики проверки и приёмки
- •Практики описания системы
- •Требования
- •Два смысла слова “требования”.
- •Модальности в требованиях
- •Инженерные обоснования
- •Рабочие продукты требований
- •Требования стейкхолдеров
- •Требования и ограничения
- •Требования к системе
- •Инженерия требований
- •Какие бывают виды требований
- •Кто должен делать требования
- •Целеориентированная инженерия требований
- •Архитектура
- •Практики архитектурного проектирования
- •Минимальная архитектура
- •Субъективность и относительность архитектуры.
- •Архитектурные описания
- •Как объединять разные модели и группы описаний
- •Архитектурные модели и другие виды описаний
- •Архитектурные знания
- •Неархитектурная часть проекта
- •8. Жизненный цикл системы и проекта
- •Понятие жизненного цикла
- •Жизненный цикл чего?
- •Управление жизненным циклом
- •Типовой жизненный цикл и разнообразие
- •Гейты и вехи
- •Рабочие продукты для определения жизненного цикла
- •Информационные системы управления жизненным циклом
- •Управление информацией/данными жизненного цикла
- •Практики жизненного цикла
- •V-диаграмма
- •Горбатая диаграмма
- •Водопад и agile
- •Вид жизненного цикла
- •Стили разработки: водопад и agile
- •Паттерны жизненного цикла
- •Основной жизненный цикл
- •Состояния альф
- •Основной жизненный цикл
- •Практики жизненного цикла в версии ISO 15288
- •9. Практика контрольных вопросов
- •Контрольные вопросы для управления жизненным циклом
- •Успех контрольных вопросов
- •Контрольные вопросы к состояниям альф
- •Карточки состояний
- •Когда заводить подальфы
- •Карточные игры
- •Контрольные вопросы инженерного проекта
- •Карточки основных альф инженерного проекта
- •Стейкхолдеры
- •Возможности
- •Определение системы
- •Воплощение системы
- •Команда
- •Работа
- •Технологии
- •Пример введения новой альфы: подальфа «подрядчик»
- •10. Инженерия предпринятия
- •Инженерия: организационная, предприятия, бизнеса, предпринятия
- •Сообщества и их отличия от предпринятия: целенаправленная коллективная деятельность
- •Миссия предпринятия
- •Корпоративное управление
- •Стратегирование, маркетинг, продажи
- •Предпринятие как система-машина, а не толпа людей
- •Развитие и совершенствование предпринятия
- •Проект технологического развития: постановка практик
- •Организационное развитие. Закон Конвея
- •Системноинженерное мышление и инженерия предпринятия
- •Цикл непрерывного совершенствования
- •Цикл Деминга
- •Шесть Сигм
- •Архитектура предпринятия
- •Основные альфы организационного и технологического решения предпринятия
- •Подальфы определения предпринятия
- •Подальфы воплощения предпринятия
- •Виды практик описания деятельности
- •Предпринятия-киборги, workflow
- •Организация, координация, коммуникация
- •Архитектура предприятия
- •Подход Захмана к архитектуре предприятия
- •Бизнес-архитектура
- •Органиграмма
- •Писцы против инженеров
- •Неархитектурные описания предпринятия
- •Это всё системный подход
- •ArchiMate
- •Зачем нужен Архимейт
- •Люди, программы, оборудование
- •Элементы и отношения
- •Нужен не ты, нужен твой сервис.
- •Люди
- •Роли
- •Работы людей
- •Архитектура IT-решения
- •Управление операциями
- •Инженерия предпринятия и управление операциями
- •Проектное управление
- •Управление процессами
- •Ведение дел/кейс-менеджмент
- •Управление проектами и управление жизненным циклом
- •Проектное управление и ведение дел: не “или”, а “и”.
- •Управление мероприятиями
- •Финансы
- •Управление знаниями, НСИ, (справочными и мастер, а также проектными) данными
- •Инженерия и предпринятия-киборги.
- •Инженерия знаний и управление знаниями.
Системноинженерное мышление |
TechInvestLab, 2 апреля 2015 |
195 |
менеджеров они означают обычно даты принятия и исполнения бюджетных, ресурсных и других логистических решений, а у инженеров это означает сроки проведения инженерных мероприятий, выполнения всех необходимых для создания целевой системы работ.
Рабочие продукты для определения жизненного цикла
Как необходимо определять (проектировать, конструировать) целевую систему, так необходимо определять (проектировать) деятельность обеспечивающих систем, т.е. жизненный цикл. Альфа определения (definition) жизненного цикла выражается в рабочих продуктах — описаниях (description) жизненного цикла, чаще всего это разного сорта диаграммы (простейшими из которых являются одномерные “стрелочки времени с зарубками на границах стадий” и “колбаски с именами стадий”, более сложные представляются двумерными диаграммами, а самые сложные подразумевают использование графических языков ситуационной инженерии методов).
Вот пример диаграммы жизненного цикла, используемого консорциумом FIATECH в качестве roadmap (долгосрочного плана работ) по развитию отрасли капиталоёмких проектов (capital projects — строительство заводов, инфраструктурных сооружений типа мостов и эстакад и т.д.), эта диаграмма жизненного цикла разработана в 2004г:
Обратите внимание на то, что наименования части стадий даются по именам практик (отглагольные существительные), а часть по состояниям целевой системы на этой стадии. Кроме этого авторы диаграммы вынуждены были показать практики (управление проектом, управление данными) и ресурсы (новые материалы, рабочая сила и т.д.), которые должны быть использованы на всём протяжении жизненного цикла. Различные передачи рабочих продуктов (hand over) показаны стрелками, но
Системноинженерное мышление |
TechInvestLab, 2 апреля 2015 |
196 |
и природа этих стрелок различна (так, “обратная связь от опыта и знаний” относится вообще к разным системам из разных проектов: когда объект уже построен, сценарное планирование будет вестись уже для другого проекта). Очевидно, что для составления этой диаграммы не было использовано никакого метода описания жизненного цикла, но сама идея для рассказа о какой-то сложной деятельности иметь в основе жизненный цикл целевой системы этой деятельности
— это правильная и продуктивная идея.
Информационные системы управления жизненным циклом
Информационные системы управления жизненным циклом (PLM, product life cycle management) по факту поддерживают не полный жизненный цикл, а главным образом стадию проектирования. Хотя часто пытаются говорить о PLM как product life cycle management (практике управления жизненным циклом изделия/продукта/установки/сложного инженерного объекта/системы), аббревиатура PLM чаще всего используется для указания на вид инженерных информационных систем, выполняющих следующие функции:
●Управление конфигурацией инженерной системы на стадии архитектурного проектирования (хранилище информации проекта — PDM, product data management). Самые различные (механические, электрические, технологические и т.д.) САПР и системы инженерных расчётов работают со связанными между собой моделями в этом хранилище. Хранилище поддерживает версионирование моделей.
●Управление изменениями (отслеживание дел, главным образом запросов на изменение проекта/design), наиболее часто в виде issue tracker
●Формирование и передача информации конфигурации на следующие стадии жизненного цикла (прежде всего — выпуск спецификаций для закупки). Для этого в состав PLM входит генератор отчётов, берущий информацию из PDM.
Вот информационные системы в жизненном цикле мотора, появляющегося в инженерном проекте:
Сначала мотор появляется в виде компонента на принципиальной схеме (спецификация функции), затем у мотора появляются его характеристики, получающиеся в результате инженерных расчётов. До этих пор мотор — это “комплектующее” и информация о нём находится в PLM. Спецификация продукта — это спецификация модуля, который можно заказать по промышленному каталогу, о
Системноинженерное мышление |
TechInvestLab, 2 апреля 2015 |
197 |
нём известно только имя модели (но не серийный номер!). Модуль на стадии закупки — это уже “предмет снабжения”, информация о нём, скорее всего, содержится в ERP-системе. Закупленный мотор-модуль монтируется, и становится “установленным оборудованием”. Информация о нём (индивидуальный журнал для конкретного мотора с серийным номером, куда попадают записи о поломках, техобслуживании и т.д.) теперь находится в EAM системе (Enterprise asset management), используемой службой эксплуатации.
Управление информацией/данными жизненного цикла
Информацией (данными) жизненного цикла называются данные, которые появляются, хранятся, передаются, обрабатываются и используются в любой момент жизненного цикла. Одной из важнейших практик управления информацией (данными) жизненного цикла является передача нужной информации (данных) между информационными системами различных организаций, обеспечивающих работу по ведущим практикам различных стадий жизненного цикла — hand over (эта передача подразумевает, что “меняется владелец”, т.е. ответственность за управление конфигурацией переданной информации переходит тоже).
На практике это означает, что информация по мотору из предыдущего раздела будет перевведена руками в среднем 7 раз за время проекта. Это медленно, при этом вносятся ошибки, и это очень дорого (ибо работают не компьютеры, а люди). Ситуация осложняется и тем, что PLM, ERP, EAM системы часто находятся в разных организациях, ответственных за разные стадии жизненного цикла целевой системы (например, атомной станции или судна-контейнеровоза, куда должен быть установлен мотор из примера).
Основная задача управления информацией/управления данными — это то, чтобы информация/данные были доступны там и тогда, где и когда они нужны в ходе жизненного цикла. По факту это означает интеграцию информационных систем и их данных (сейчас всё чаще говорят “федерирование”, подчёркивая факт независимости отдельных информационных систем и их данных). Это весьма нетривиальная задача, которая для своего решения требует привлечения особого рода специалистов: модельеров данных (они отличаются и от инженеров, и от программистов. Их задача — разработка структур данных, отражающих предметную область и реализующихся затем в конкретных базах данных. То есть они работают в тесном контакте с инженерами и программистами). Можно назвать модельеров данных “прикладными онтологами”, ибо корректное и достаточно формальное, чтобы его можно было “объяснить компьютеру” описание мира является их основной задачей.
Вот пример модели данных (онтологии), отображающей жизненный цикл трубопроводной задвижки (Control Valve), описываемый примерно так, как описывался жизненный цикл мотора из предыдущего раздела. Это описание использует метод описания из ISO 15926: