- •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 |
292 |
между собой работы/соорганизуют свои сервисы
(http://www.bpminstitute.org/community/bpm-group/choreography-vs-orchestration).
Проектное управление
Проектное управление озабочено тем, чтобы спланировать и выполнить некоторую целенаправленную работу, ограниченную во времени и ресурсах.
Проект считается уникальным, имеет даты начала и окончания, связан с использованием ресурсов (людей, инструментов, материалов). Главная подальфа работ для проектного управления — график выполнения работ, проектное управление должно в какой-то мере гарантировать его составление и соблюдение (прохождение всех необходимых работ к моменту окончания проекта, с учётом ресурсных ограничений). Конечно, понятие проекта в разных школах проектного управления отличается, но все школы сходятся в том, что работы можно как-то предварительно (up front) спланировать, а затем выполнить план в том виде, как он задуман.
Разные школы проектного управления по-разному относятся к тому, как называть работы (например, PRINCE2 рекомендует названия работ заменять названиями основных рабочих продуктов, меняющихся в результате этих работ), как составлять график (в теории ограничений рекомендуют отводить на выполнение работы половину времени, заявленную экспертом по данной работе — но зато отдельно иметь “буфер проекта” для того, чтобы компенсировать неизбежные при этом задержки), как находит критические для контроля их выполнения работы (практики нахождения критического пути и критической цепи).
Оно существует в нескольких поколениях:
●первое поколение “сетевого планирования” (когда было предложено составлять “сетевые графики”, в существенной мере облегчающие планирование заранее известных последовательностей работ — по этим графикам можно было найти “критический путь” (цепочку связанных предопределённой последовательностью работ, задержка каждой из которых приводит к задержке завершения всего проекта в целом).
●второго поколения (методологии PMI PMBoK, PRINCE2), в которой кроме самых разных аспектов планирования и контроля выполнения работ говорится также и о самых разных других аспектах управления проектом: стейкхолдерах и команде проекта,
●третьего поколения (методологии P2M/Project&Program Management, TOC/Theory of Constraints, LastPlanner/Lean Project management). Одним из ключевых положений третьего поколения этих методологий является рассмотрение всех проектов для данной совокупности ресурсов (т.е. проектов всего предпринятия в целом, а не проекта как отдельного предпринятия) в совокупности — т.е. переход к программам (совокупностям проектов) как основному объекту рассмотрения. Ибо нет другого способа управлять проектами, как перекидывать некритические ресурсы из одних проектов на критические задачи других проектов.
●Четвёртого поколения — исследования в области теории планирования, переходящие в задачи искусственного интеллекта и гибридным статистикологическим вычислениям (вообще, теорию планирования относят к задачам искусственного интеллекта: пока алгоритма составления эффективного плана не придумано).
Системноинженерное мышление |
TechInvestLab, 2 апреля 2015 |
293 |
Традиционно проектное управление делят на управление портфелем проектов (если включить управление портфелем проектов и все проекты портфеля управляются тоже, то это управление программой — программа это множество проектов определённой темы, необязательно начинающиеся и заканчивающиеся одновременно), планирование проекта и контроль выполнения проекта. Но в третьем поколении проектного управления это деление не так уж очевидно.
Методы (наборы практик) проектного управления обладают некоторым “шовинизмом” (идеология превосходства с целью обоснования права на дискриминацию и угнетение других), т.е. пытается в рамках редукционистского подхода (в рамках представлений своей школы проектного управления) распространить свою дисциплину проектного управления на все смежные практики
— от лидерства (ибо проектные команды нужно как-то формировать и воодушевлять) до инженерии требований (ибо для выполнения проектов нужны практики системной инженерии). Необходимо использовать из проектного управления лучшее, что оно может дать (т.е. оценку времени выполнения заранее запланированных работ и распределение ресурсов по работам такое, чтобы время выполнения этих работ было минимальным) и критически относиться к тому, что попадает на его “периферию” и много глубже изучено и лучше реализуется практиками других дисциплин — системной инженерии, лидерства.
Управление процессами
Управление процессами имеет предположение, что заранее известные целенаправленные последовательности работ повторяемы — и это повторение относится не к самим работам (этот вопрос повторяемости видов работ решает представление о практиках, ситуационная инженерия методов описывает именно отдельные работы), а именно к последовательностям (цепочкам) работ.
Процессы часто называют business proccesses (по недоразумению переводятся как “бизнес-процессы”, хотя к бизнесу никакого отношения не имеют — business ведь это просто какое-то “дело”). Так же часто процессы путают с практиками (т.е. используют средства описания процессов для того, чтобы описать практики, получая неполные их описания — прежде всего описывающие “глаголы”, действия,
Системноинженерное мышление |
TechInvestLab, 2 апреля 2015 |
294 |
но опускающие описания альф и рабочих продуктов), наиболее часто эта путаница возникает при использовании набора стандартов ISO 9000. Так что в некоторых случаях правильно переводить process как “практика” (когда не говорится о последовательностях работ, а они только перечисляются). Так в ISO 15288 в английском оригинале говорится life cycle processes, но просто там в команде редакторов стандарта были люди-разработчики из стандарта ISO 9000 и поэтому там закрепилось слово “process”. Конечно, в самом стандарте описаны практики: никакой последовательности выполнения работ, разворачивания работ во времени, упоминаний того, какие работы должны производиться в начале, а какие в конце, в ISO 15288 нет.
Что в проектном управлении называется “шаблоном проекта” и существует только в виде предоставляемых софтом проектного управления рабочих продуктов (но не альф, определяемых дисциплиной), то в управлении процессов — важнейшая альфа. И наоборот, что в проектном управлении важнейшая альфа — последовательность уникальных работ с конкретными временами исполнения, то в управлении процессов называется “экземпляр процесса”, который также доступен главным образом в виде рабочего продукта процессного софта, но не обсуждается как альфа дисциплины.
Тем самым управление процессов хорошо применять тогда, когда нужно описать типовые последовательности работ, и для этого применяются даже специальные языки такого описания для workflow, когда работа идёт и через компьютеры и через людей — наиболее часто для этого сейчас используется OMG BPMN 2.0 (Business process model and notation, http://www.bpmn.org/).
Управление процессами трудно применять тогда, когда нужно дать оценку времени завершения отдельных экземпляров процессов (”проектов”), хотя при обилии экземпляров процессов и можно моделировать какие-то оценки загруженности ресурсов (людей и оборудования) и тем самым планировать проход потока работ по предпринятию-системе.
Ведение дел/кейс-менеджмент
Ведение дел (case management и разные его современные варианты adaptive case management, dynamic case management, advanced case management — слово case
тут того же происхождения, что и “судебное дело”. “Управление делами” в русском закреплено больше за обслуживанием документооборота и/или материальнотехническим обеспечением основной деятельности предприятий, поэтому мы и не используем этот вариант) — координационная и целе-ориентированная дисциплина, занимающаяся ведением дел от их открытия до закрытия, во взаимодействиях между людьми, вовлеченными в предмет дела и ведущим дело или командой дела (Case management. A coordinative and goal-oriented discipline, to handle cases from opening to closure, interactively between persons involved with the subject of the case and a case manager or case team).
Дело в русском языке (как и в английском) обычно отождествляется как с выполнением работ (деланием дела), так и с информацией по делу — case file (case folder) — уголовное дело, история болезни и т.д.
Ведение дел используется тогда, когда хочется отследить целенаправленную деятельность при невозможности заранее составить план (распределить работы во времени — т.е. использовать проектное управление) и последовательность (какая цепочка работ, что раньше из них, что позже — т.е. использовать процессное
Системноинженерное мышление |
TechInvestLab, 2 апреля 2015 |
295 |
управление) выполнения отдельных работ.
Дело — ситуация, обстоятельства или начинание, которые требуют набора действий для получения приемлемого результата или достижения цели. Дело фокусируется на предмете, над которым производятся действия (например, человек, судебное дело, страховой случай), и ведется постепенно появляющимися обстоятельствами дела (Case. A situation, set of circumstances or initiative that requires a set of actions to achieve an acceptable outcome or objective. A case focuses on a subject that is the focus of the actions such as a person, a lawsuit or an insurance claim, and is driven by the evolving circumstances of the subject).
Именно поэтому ведение дел относится к базированным на рабочих продуктах (и, соответственно, альфах) способам описания деятельности и близко к описаниям ситуационной инженерии методов, используемым в управлении жизненным циклом. Конечно, в ведении дел можно задать какой-то “шаблон” из последовательности действий (как и “шаблон проекта” в проектном управлении), но чаще речь идёт о задании каких-то правил выбора используемых следующими практик — и практики эти выбираются по правилам после оценивания ситуации после очередного такта работы (а то и вообще предлагаются новые практики). Это часто делается не “в софте”, а при обсуждениях — судебных заседаниях, врачебных консилиумах, заседаний комитета по изменениям в инженерной компании.
Ведение дел совместимо с ситуационной инженерией методов (ведение дел происходит главным образом в ходе работы, а ситуационная инженерия методов — перед выполнением работы). Практики в ситуационной инженерии методов описываются так, что выполнение любой операции связывается с другими операциями не непосредственно указанной последовательностью (жарим яичницу, затем проветриваем помещение), а пред-условиями и пост-условиями этих последовательностей (”когда хотим есть — жарим яичницу”, “если в помещении дым, проветриваем помещение”).
Если грубо, то управление делами занимается работами, которые носят в какой-то мере исследовательский характер (классические примеры — это судебные дела, в которых каждый новый свидетель и предъявленная улика вызывают неожиданные повороты дела и изменяют все планы, но в конце концов приводят к вынесению приговора; медицинские “кейсы”, когда в больницу поступает пациент с неизвестным диагнозом, и каждый анализ и назначенное лечение приводят к неожиданным поворотам в планах врачей, но в конце концов больной выздоравливает и выписывается). К таким работам относится и инженерия требований, и архитектурное проектирование — когда каждое новое обнаруженное требование, каждый новый предложенный вариант архитектуры могут привести к переработке проекта-design (3D-моделей и расчётных моделей) и проекта-project (плана в смысле проектного управления), но в конце концов проектирование заканчивается и переходят к воплощению.
В программной инженерии используется issue tracking (иногда про это говорят как “младший брат для case management”) и переводят сейчас часто как “управление задачами”. Возникающие в программировании проблемы/вопросы/дела (issues) часто относятся к непредвиденным в планах и неожиданным для процессов, непредусмотренным практиками ошибкам, поэтому их нельзя запланировать в рамках проектного управления, нельзя предусмотреть и учесть в рамках процессной работы, но они всё одно требуют учёта. Поэтому в программной инженерии используют специальный класс программного обеспечения — issue trackers (системы управления задачами).