- •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 |
210 |
2.1.Определение вида (описывание, моделирование) жизненного цикла
2.2.Управление инфраструктурой
2.3.Управление портфелем проектов
2.4.Управление персоналом
2.5.Управление качеством
3. Проектные 3.1. Управление проектами
3.1.1.Планирование проекта
3.1.2.Управление выполнением и контроль проекта 3.2. Поддержка проектов
3.2.1.Управление решениями
3.2.2.Управление рисками
3.2.3.Управление конфигурацией
3.2.4.Управление информацией
3.2.5.Измерения
4. Технические
4.1.Сбор требований
4.2.Анализ требований
4.3.Архитектурное проектирование (дизайн)
4.4.Изготовление
4.5.Верификация (проверка)
4.6.Переход к эксплуатации
4.7.Валидация (приёмка)
4.8.Эксплуатация
4.9.Обслуживание
4.10.Вывод из эксплуатации
Сцелевой системой в плане продвижения альф определения и воплощения системы непосредственно работают главным образом технические практики из ISO 15288. Остальные практики жизненного цикла системной инженерии работают с обеспечивающей системой, продвигая альфы работы, технологии, команды, возможностей и стейкхолдеров. Само определение вида жизненного цикла входит как отдельная практика (2.1).
9. Практика контрольных вопросов
Контрольные вопросы для управления жизненным циклом
Успех контрольных вопросов
Человеческая деятельность становится сверхсложной до такой степени, что одним виртуозом уже не выполнима, как бы ни был велик этот виртуоз в своём мастерстве. В силу сверхсложности этой деятельности на каждого виртуоза бывает проруха: пропуск какого-нибудь из самых существенных (базовых, известных наизусть всем, невозможных к пропуску, критических для успеха) шагов в выполняемых ими работах. Просто по общей затурканности сверхспециалистов, у которых в голове ой-ой-ой сколько всякого, нужного для выполнения работы.
Сверхспециалистов в проекте много разных, и критическими шагами является не просто выполнение процедур, но и простое знакомство друг с другом (ибо в каждом
Системноинженерное мышление |
TechInvestLab, 2 апреля 2015 |
211 |
даже простом действии встречаются ранее незнакомые друг с другом люди, не имеющие опыта совместной работы), а также знакомство друг друга с выполнением этих базовых и критических для успеха всего проекта действий, выполненных каждым человеком. Часто происходит так, что все члены команды уверены, что ктото выполнил важнейшее, но тривиальное и банальное действие — но оказывается, что его никто так и не выполнял, некогда было всем!
Одна из самых мощных практик, позволяющая снизить фатальные ошибки от досадных промахов в сложной деятельности — это практика контрольных вопросов.
Она лучше всего описана в книге Atul Gawande "The Checklist Manifesto", http://gawande.com/the-checklist-manifesto (перевод на русский: http://www.alpinabook.ru/catalogue/2118996.html). Её суть: "мало что более эффективно в сверхсложных коллективных проектах, чем дисциплинированно проходимые чеклисты, но это мало где признаётся, кроме авиации, космонавтики, медицины".
Контрольные вопросы (checklist, “список контрольных вопросов”, а “отдельный вопрос” будет “checkpoint”) существуют в самых разных формах: от “классического” авиационного, космического или хирургического списка контрольных вопросов до списка работ в строительном проекте в составе структуры разбиения работ, от списка проверок due diligence в инвестиционных фондах до таблички на дверях “выключил ли ты свет?”. Чеклист обычно — это короткий список (пять-семь, и лишь иногда семьдесят или семьсот) действий, каждое из которых должно быть сделано во время зачитывания списка (чеклист типа READ-DO), или результатов/условий/действий, которые должны быть подтверждены по мере зачитывания списка (DO-CONFIRM).
Использование чеклиста происходит во время "точек паузы" (pause points, как они называются в авиации), где вся рутинная и сложная деятельность прекращается, и происходит прогон чеклиста. При ближайшем рассмотрении оказывается, что наиболее эффективно использование чеклиста при смене состояний каких-то альф, в которых принимается решение Go-NoGo в ходе жизненного цикла альфы, т.е. в точках возможного “невозврата”. Чеклист "прочти-подтверди" (DO-CONFIRM) представляет собой проверку того, что сделано на предыдущей стадии, чтобы попасть в следующую стадию. Ну, или чтобы попасть в следующую стадию, нужно прогнать чеклист "прочти-сделай" (READ-DO, этот тип чеклиста обычно выполняется при попадании во внештатную ситуацию). Поэтому в каждом деле
Системноинженерное мышление |
TechInvestLab, 2 апреля 2015 |
212 |
главных чеклистов обычно буквально несколько штук, а вот "аварийных" могут быть сотни.
Прохождение одного "классического" подтверждающего чеклиста (опять же — недаром его выполнение происходит в точке "паузы"!) занимает одну-две минуты нужно вслух подтвердить для всего коллектива выполнение указанных в нём условий (типа "снято с ручного тормоза", "выпуск релиза происходит не вечером пятницы", "антибиотик введён не раньше часа до операции, и не позже момента начала операции"), а самих условий обычно 5-9. Конечно, "неклассические" варианты отличаются разнообразием, особенно в случаях, когда речь идёт об использовании графика проекта в качестве чеклиста, чтобы иметь уверенность в том, что работы по каждому пункту были действительно выполнены и ничего не забыто.
Дисциплина чеклистов выглядит очень бюрократической — но это ровно то же самое, что отличает системных инженеров, которых совершенно недаром с их приверженностью к формальным процедурам (aka прогону чеклистов) называют "бюрократами от инженерии", что они признают, и чего они не стесняются. Объясняют это своё нестеснение они просто: зато ракеты долетают куда надо, а атомные станции начинают давать ток и даже более безопасны в целом, чем угольные в расчёте на киловатт-час.
Чеклисты, тем не менее, существенно отличаются от похожих на них описаний работ (например, описанных по традициям ситуационной инженерии методов, или традициям архитектуры предпринятий, или традициям описания лучших практик, или просто пошаговых инструкций по выполнению работ). В чеклистах приводится не 100% описания работ и не цитируется содержание учебников и регламентов. В чеклистах спрашивается только самое существенное (и обычно “банальное”), что может быть упущено и приведёт к epic fail. Так, первый пункт чеклиста, выполняемого при остановке двигателя самолёта — “1. Fly the aircraft”. Все знают, что нужно не забывать управлять самолётом, но когда у самолёта останавливается двигатель, лётчик начинает интересоваться двигателем, топливом, состоянием электропроводки и забывает управлять самолётом. Потеря управления при остановке двигателя является причиной бОльшего числа аварий, чем собственно остановка двигателя! И это при том, что лётчики обычно хорошо тренированы! То же можно сказать и про врачей, проходящих серьёзный профессиональный тренинг. В литературе приводится цифра, что использование чеклистов, предлагаемых Всемирной организацией здравоохранения для хирургических вмешательств снижает риск смерти вплоть до 47%! И это без изменения самой техники хирургических вмешательств, без изменения используемых медикаментов или организации операции — только за счёт использования чеклистов, предотвращающих “глупые” ошибки (один из вопросов, например, “проверить, на какой стороне тела проводится операция”).
То же самое происходит и в проектах системной инженерии. Если есть проблемы с какой-то альфой проекта, то очень вероятно, что не выполнятся какие-то банальные процедуры (типа “забыли провести испытания” или “давно не общались со стейкхолдерами”). Лучше бы вовремя вспомнить о таких важных вещах, чтобы потом не иметь проблем из-за отвлечения внимания.
Главным образом чеклисты делаются на основе анализа статистики, а в более редкие "аварийные" чеклисты шаги включаются на базе расследований крупных катастроф. Ибо 10% провалов происходит не из-за чрезвычайной сложности какого-то процесса, а именно из-за того, что очевидные шаги пропускают на основе
Системноинженерное мышление |
TechInvestLab, 2 апреля 2015 |
213 |
того, что "всё тут обычно бывает гладко", а то и банально из-за отвлечений, надежды, что кто-то другой это сделал, общей суеты вблизи смены стадий жизненного цикла, плохого знакомства команды друг с другом. Теория швейцарского сыра (http://en.wikipedia.org/wiki/Swiss_cheese_model) — это как раз про чеклисты. Утверждается, что в 9 случаях из 10 чеклист будет пройден без сучка и задоринки, а в одном из десяти случаев будет что-то обнаружено, что исправится за несколько секунд, но убережёт от дорогостоящих и трудно исправляемых ошибок.
Чеклистам доверяют и их рутинно выполняют — как чистят зубы, как одевают уличную обувь, на уровне рефлекса. Их выполняют по сути, их не сачкуют, хотя и известно, что выполнять их бессмысленно в девяти случаях из десяти. Но в одном из десяти случаев ошибка таки выявляется, и этот честный прогон чеклиста окупает всё то время, что было на него потрачено во всех остальных прогонах: исправлять ошибки в разы дороже и затратнее, чем читать чеклисты.
Кровью написаны не уставы, а чеклисты. Ибо уставы/стандарты/нормы наизусть выучить — дело бесполезное, и требует сверхгероя. Никто не способен прочесть всю нормативную документацию, запомнить все требования, освоить пару десятков учебников ("уставы") так, чтобы обязательно их все вспомнить в критической ситуации. Но короткий чеклист имеет шанс быть вытащенным и прогнанным — это не заменяет учебников, требования высокой квалификации людей и непрестанного тренинга, стандартов, регламентов, инструкций и прочих обязательных к исполнению “уставов” (чтобы было кого наказывать за их несоблюдение, и чтобы было где-то хранилище полного знания). Но чеклисты позволяют из сверхгероев делать просто героев, а потом и рутинизировать процесс. По мере внедрения в инженерную и лётную практику чеклистов особость генконструкторов перестала волновать, и их именами перестали называть самолёты, пилоты-испытатели перестали быть национальными героями. А сейчас примерно то же самое происходит с медицинскими светилами (и об этом подробно рассказывает в своей книге Atul Gawande — эпоха Master Builders заканчивается, на смену ей идёт эпоха командной работы).
А уставы и чеклисты отличаются хотя бы тем, что уставы требуется выполнять полностью в их целостности, а чеклисты — прогонять (например, проговаривать вслух вопросы и проговаривать вслух ответы — причём в присутствии всей команды), прогонять всегда.
Важно прохождение чеклиста всей командой, это средство убедиться, что "все на одной странице книги", "играют одну и ту же партию", имеют "одну и ту же версию правды". При прохождении чеклиста важен как раз консенсус, что все члены команды (а часто и внешние стейкхолдеры) согласны с тем, что чеклист пройден, и принимается решение "go — no go" для возможного перехода к следующему состоянию альфы.
В самом чеклисте проверяется/делаются в обязательном порядке не только производственные акты (преобразуется информация и вещество), но и коммуникационные акты (поручения, обязательства, обещания, отчёты о выполнении и т.д. — то, что связано с выполнениями людьми своих полномочий). Чеклисты являются важным инструментом командообразования: вплоть до обязательно представления команды друг другу перед началом работы и требования вот прямо сейчас, во время точки паузы и прогона чеклиста предъявить план действий на следующей стадии, а также рассказать о подозрениях каждого члена команды о возможных трудностях в ходе реализации плана. Важно, что