
- •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 |
251 |
В этом плане инженерия предпринятия вполне подобна системной инженерии — разве что:
●вместо инженерии требований по отношению к предпринятию говорят чаще о стратегировании/целеполагании (как и в случае инженерии требований, работа с user needs тесно связана с работой над требованиями — в данном случае определением функций предпринятия как “чёрного ящика”, с выходом
на функциональную декомпозицию), системную архитектуру называют архитектурой предприятия,
●по факту не говорят о проверках и приёмках, но занимаются измерениями
(measurements — выставляют KPIs/Key Performance Indicators и проверяют их выполнение),
●задачи операционного управления (operation management — максимизации прохода работ через систему-предпринятие), лидерства (leadership) и управления организационными изменениями (change management) системы систем предприятия рассматривают совместно больше с менеджерской (т.е. учитывая человеческий и социальный аспекты предпринятия), нежели инженерной (предпринятие-машина) точки зрения.
●Классические представления системной инженерии не слишком применимы к предпринятию: в силу самопринадлежности каждого человека, как основной организационной единицы, речь всегда идёт о системо-системной инженерии. Это означает, что можно сколь угодно тщательно определять предпринятие, но вот воплощение предпринятия может проходить с огромным трудом: совместные организационные изменения частей предпринятия-с-людьми могут проходить не так легко и просто, как совместные изменения чисто технических систем, в состав которых не входят люди. Железка не разочаруется в жизни и не уйдёт в монастырь или к системе-конкуренту, а вот сотрудник, которого планировалось с его уникальными компетенциями использовать в каком-то определённом месте организационной “машины” — вот сотрудник это вполне может сделать.
Несмотря на все оговорки про непохожесть человеческого коллектива в его смеси со зданиями, оборудованием, программами на “машину”, если инженер не определит (спроектирует) и затем надлежащим образом не воплотит такую системупредпринятие, то вряд ли эта недоопределённая система-предпринятие сможет надлежащим образом выполнить свою функцию: толпа дикарей на острове не составит конструкторского бюро, разумное и глубокое разделение труда в этой толпе вряд ли проявится. И даже и толпа инженеров в центре мегаполиса тоже конструкторского бюро не составит: сначала нужно определить технологии проектирования, затем нужные для этой технологии квалификации людей, затем подготовить для них рабочие места, затем дообучить людей и/или нанять новых квалифицированных, затем организовать их (т.е. распределить полномочия согласно задуманному для реализации технологии разделению труда), и только потом можно ожидать выпуска продукта или оказания сервиса.
Развитие и совершенствование предпринятия
Управление технологиями — это замена практик: осознание и вывод из использования старых практик и освоение новых практик (слово “внедрение” тут лучше не использовать: оно подразумевает активную позицию кого-то внешнего по отношению к осваивающим новую практику сотрудникам предпринятия и
Системноинженерное мышление |
TechInvestLab, 2 апреля 2015 |
252 |
пассивную позицию самих сотрудников. А ведь “лошадь нельзя заставить напиться, можно только подвести её к воде”. Так и тут: нельзя “внедрить” какую-то технологию, но можно создать условия для её освоения).
Управление технологиями настолько важно, что специальность “инженерный менеджмент” иногда называют “инженерный менеджмент и управление технологиями” (engineering and technology management, изредка engineering, technology and innovation management). Есть множество университетских курсов, и
даже научные журналы по этой тематике (например, http://www.mines.edu/ETM_GS, http://www.journals.elsevier.com/journal-of-engineering-and-technology- management/).
Нужно различать развитие и совершенствование предпринятия. Развитие — это смена технологии, совершенствование — это сохранение технологии. Развитие — это управление технологиями (переход от одних практик к другим), совершенствование — это отлаживание технологии, её “настройка”, операционное управление, “зрелость процессов”.
Развитие — это рост спектра возможных адекватных ответов человека или предпринятия на самые разные ситуации. Развитие — это когда всё реже и реже выдаются неадекватные реакции в незнакомых ситуациях из-за незнания и неумения, невладения инструментами, незнакомства с рабочими продуктами. Совершенствование — это когда всё реже и реже проявляются неуместные в знакомой ситуации поведенческие стереотипы человека или предпринятия. Развитие — это шаги вперёд, в новые ситуации. Совершенствование — это занятие круговой обороны в знакомой ситуации, и выигрыш за счёт этого. Развитие и совершенствование также легко спутать: например, при совершенствовании можно начинать замечать много нового в, казалось бы, знакомой ситуации — и это будет превращать совершенствование в развитие. Есть вариант и вообще не обращать внимания на разницу между развитием и совершенствованием, но я бы не рекомендовал это делать — как минимум, в учебном контексте.
Учебный же контекст есть всегда: и когда мы учим детишек (и сами устанавливаем баланс между их развитием и совершенствованием), и когда учим предпринятие (или оно само учится — learning organization Питера Сенджа, помним про “освоение” vs “внедрение”), и когда сами учимся жизни в ходе её проживания (“не перехождения поля”).
Когда человек научается стоять, он не совершенствуется в этом бесконечно. Когда человек научается ходить, он не совершенствуется в этом бесконечно — но у него есть шанс стать победителем олимпийских игр по спортивной ходьбе. Когда человек научается бегать, то тоже можно или становиться чемпионом олимпийских игр по бегу. А можно учиться танцам, или вождению самолёта, или каким-то другим сложным двигательным практикам. Развитие это всегда лестница, на ней крутые ступеньки.
Проблема в развитии в том, что часто непонятно, зачем это — если нет зависти или любопытства к новым, более сложным навыкам. Бегунов и так неплохо кормят, как впрочем, и ходоков. Но оставим в стороне дискуссию о том, что заставляет развиваться человека. Предпринятия заставляет развиваться только конкуренция: если предпринятие не меняет свои технологии, то рано или поздно его продукция в силу совокупности причин (если нет “административного ресурса”) перестанет покупаться — она будет или несовременна, или слишком дорога по сравнению с продуктами конкурентов.
Системноинженерное мышление |
TechInvestLab, 2 апреля 2015 |
253 |
Управление технологиями страшно, ибо прекращает совершенствование. Управление технологиями начинает с того, что показывает бесперспективность совершенствования в применяющихся на предпринятии практиках стратегирования/маркетинга, операционного управления, инженерных практиках. Контрольный вопрос для управления технологиями не в том, какие новые практики будут освоены, а какие старые практики будут прекращены.
Совершенствование комфортно и обманчиво безопасно. Если жизненные или рыночные ситуации не имеют шанса поменяться, то совершенствование — верный путь к успеху. Если жизненные ситуации меняются, то тратить время на совершенствование — смертельно. Нужно найти в себе силы перейти к развитию, оторвать задницу (свою или предпринятия) от приятного и общественно поощряемого.
Но без совершенствования нет ступенек на лестнице развития. Не закрепившись на какой-то ступеньке, невозможно шагнуть вперёд. Если нет опыта какой-то деятельности, то на эту деятельность нельзя будет опереться и шагнуть дальше. Поэтому нужно прекращать ежедневно прыгать с деятельности на деятельность в "ознакомительном" режиме. Если вы круто переразвиты, но при этом ни в чём не совершенны — не удивляйтесь, что у вас непрекращающиеся проблемы, вам одинаково будет тяжело и в знакомых ситуациях, и в незнакомых.
Так что же делать? Как найти правильное время пребывания на каждой образовательной/технологической ступеньке — правильное время совершенствования какой-то практики? Общих рецептов тут нет. Но над этим нужно специально думать, нужно кроме утопания в тактическом совершенствовательном планировании постоянно заниматься развивательным стратегированием (альфа технологий существенно связана с альфой “возможности”: возможность выполнить проект появляются не только тогда, когда клиенты хотят, но и когда предпринятие может!), и наоборот — не забывать кроме вечного маниловского стратегирования ещё и что-то планировать, чтобы быть совершенным.
Проект технологического развития: постановка практик
Помним театральную метафору: каждый и внутренний и внешний по отношению к команде проекта стейкхолдер играет свою роль в спектакле инженерного проекта, у него определённые работы по определённым технологиям в предпринятии. Но для того, чтобы актёры смогли совместно сыграть спекталь, его ставят — закупают реквизит и шьют новые костюмы, изготавливают декорации, актёры учат роли, потом долго репетируют. То же самое происходит в ходе управления технологиями: для новой технологии закупают инструменты, разрабатывают форматы новых продуктов, исполнители учат новую дисциплину и получают навыки работы с новыми инструментами и видами рабочих продкутов (а иногда приходится приглашать новых исполнителей: не всех извозчиков берут в таксисты).
У предприятия различают производственные (целевые) проекты и проекты развития. “Производственные” — это просто чтобы отличить проекты по оказанию услуг клиентам, проектированию, конструированию, изготовлению целевых для клиентов систем. В системно-мыследеятельностной методологии предпочитают говорить даже “воспроизводство” — чтобы показать неизменность, повторяемость, цикличную воспроизводимость практики: неизменность дисциплины, неизменность инструментов, неизменность видов рабочих продуктов. То есть используемое слово “производство” (producing, production) включает и замысел, и разработку, и изготовление, и испытания, и эксплуатацию, и вывод из эксплуатации целевой

Системноинженерное мышление |
TechInvestLab, 2 апреля 2015 |
254 |
системы — всё, кроме развития, понимаемого как развитие обеспечивающей системы, развития предпринятия, т.е. изменения технологий (и по сопричастности изменения полномочий — организационное развитие).
Целевой системой инженерного (инженерии предпринятия!) проекта развития является технология производственного проекта (в части разворачивания новых инструментов и рабочих продуктов) и команда производственного проекта (в части образования членов команды по новым дисциплинам и научения их работе с инструментами и рабочими продуктами). Предпринятие развития является обеспечивающей системой для производственного предпринятия.
В ISO 15288 это изображается так:
“Целевая система” это инженерное предпринятие в части производства, его услуги (оказываемое вовне поведение системы) операционному окружению — это выпуск продукции, а системы замысливания-разработки-поддержки и т.д. это системы управления технологиями (службы стратегирования, отделы развития, консультанты по отдельным дисциплинам и инструментам и т.д.).
Более удобно и просто показывать разделение проектов развития (организационных изменений, управления технологиями) и производственных проектов (создания целевых систем/продуктов/изделий/сервисов) на диаграмме альф инженерного проекта: