Системная инженерия, инженерный менеджмент и инженерные сервисы
Некоторое время я варился в материалах самых разных профессиональных тусовок, членом которых я являюсь:
-- INCOSE (международный совет системных инженеров), http://incose.org
-- ASEM (американская, но по факту -- международное общество инженерного менеджмента), http://asem.org
-- ACDM (ассоциация управления конфигурацией и управления данными), http://acdm.org/.
Я много лет еще и член ACM (ассоциация компьютерной машинерии), http://acm.org, а в ней SIGSOFT (специальная группа по интересам, занимающаяся программной инженерией), но тамошнее членство позволяет лишь сказать, что новейшие IT-технологии будут продолжать взрывать содержание текущих практик системной инженерии, инженерного менеджмента и управления конфигурацией и данными с неменьшей скоростью, чем это происходило до сих пор. Я думаю, что скорость этих изменений ещё и увеличится: переход к моделеориентированной системной инженерии и порождающему проектированию и производству обеспечивается прежде всего новыми алгоритмами, новым софтом.
Есть минимум три (основных, а так их много больше) смежных профессиональных практик (дисциплин), каждая из которых соревнуется с другими в своём шовинизме и желании поглотить сотоварищей:
-- системная инженерия
-- инженерный менеджмент
-- инженерные сервисы
Например, ISO 15288 (определяет практики жизненного цикла системной инженерии -- вот список: ), из четырех групп практик только одну (технические практики) определяет как собственно "системная инженерия" в узком смысле слова (практики того, что делают с целевой системой: задумывают, проектируют, изготавливают, проверяют и сдают, эксплуатируют, выводят из эксплуатации и т.д.). Остальные группы практик -- контрактные, проектные и обеспечения проектов -- это про то, что делает обеспечивающая система, сиречь предпринятие, занимающееся работами по продвижению целевой системы по её жизненному циклу. В эти практики попадает и управление портфелем проектов, и управление персоналом проектами, и управление конфигурацией, и даже заключение контрактов. Это было абсолютно сознательное склеивание системной инженерии и инженерного менеджмента (с выходом на организационную инженерию) со стороны разработчиков стандарта, я обсуждал эту тему с редактором первой версии Бадом Лоусоном. Вот это разбиение (т.е. набор частей) системной инженерии по версии ISO 15288 (на английском это цитируется вот тут -- http://ailev.livejournal.com/632128.html -- заодно там обсуждается и бессмысленность какого-то содержательного анализа использования слова management в названии дисциплины/практики, например, обоснование отнесения к широкой дисциплине "менеджмент" на основании использования этого слова в названии практики):
Системная инженерия:
1. Контрактация
1.1. Закупка
1.2. Поставка
2. Обеспечения проектов
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. Вывод из эксплуатации
Инженерный менеджмент тоже крут в плане своего шовинизма. Он, вообще-то говоря, псевдодисциплина: скомпонованный для целей совместного маркетинга учебными заведениями набор разных полезных дисциплин. "Истинные дисциплины" -- это которые имеют свои собственные объекты (типа "требования" и "архитектура" в системной инженерии), и поэтому "истинные части" (типа "инженерии требований" и "инженерии системной архитектуры"). Разбиение истинных дисциплин -- это отношение состава (часть-целое, композиция). Псевдодисциплины -- это объединения (агрегация) по каким-то критериям фрагментов разных других "истинных дисциплин": информационная архитектура (но не моделирование данных!), инженерный менеджмент и много-много других. Так вот, инженерный менеджмент включает в себя не только лидерство и управление проектами, но и системную инженерию! Почему? "Инженерный менеджер должен знать основы системной инженерии". Ага, ибо мало кто в ASEM интересуется, что делает инженерный менеджер -- но всех волнует, что должен знать инженерный менеджер. Вот главы Handbook of Engineering Management, сравните их с практиками системной инженерии:
1. Инженерный менеджмент -- настоящее, прошлое, и будущее.
2. Вопросы профессиональной ответственности, этики и законодательства.
3. Теория и понятия менеджмента
4. Управление знаниевыми работниками.
5. Исследование операций
6. Имитационное моделирование
7. Анализ при принятии решений (decision analisys)
8. Мультикритериальный анализ
9. Основы бухучёта и финансов
10. Инженерная экономика
11. Роль управления проектами в стоимости жизненного цикла
12. Системная инженерия [только технические практики]
13. Управление рисками
14. Стратегическое управление
15. Системное мышление
16. Лидерство для индивидуальных работников и команд инженерных проектов.
Тамошнее Body of Knowledge не лучше, но в нём хотя бы системной инженерии на верхнем уровне нет (оглавление на английском -- http://asmedl.org/ebooks/asme/asme_press/802991):
1. Исследования рынка, оценки и прогнозы
2. Стратегическое планирование и управление изменениями
3. Разработка продукта, сервиса и процесса
4. Управление инженерными проектами и процессами
5. Управление финансовыми ресурсами
6. Маркетинг, продажи, и управление коммуникациями
7. Лидерство и организационное управление
8. Вопросы профессиональной ответственности, этики и законодательства.
Инженерные сервисы (engineering services) -- это весьма спорное название для группы инфраструктурных практик типа управления конфигурацией и управления данными, которые системные инженеры относят к "поддержке проектов" (ISO 15288), инженерные менеджеры вообще не замечают, соответствующие функциональные подразделения на предприятиях часто так и называют. Ирония судьбы в том, что в инженерные сервисы свободно записывают и системную инженерию, и вообще любую инженерию в целом, равно как и configuration and data management (вот, например, обратите внимание, в каком разделе и среди каких других практик configuration and data management тут: http://www.windmill-intl.com/professional/engineeringservices/configuration.htm, а вот configuration change control вынут из engineering services и засунут в management services -- www.control-pt.com/services/engineering-services, вот управление конфигурацией прямо внутри проектного управления, но не в инженерных сервисах -- http://www.novasystems.com/services/project_management/configuration_management, и так дальше везде: некоторый ряд инфраструктурных практик обеспечивающей системы системной инженерии имеет неопределённое отнесение и претендует на какую-то самость (ибо имеет собственные понятия, не встречающиеся в менеджменте и системной инженерии -- конфигурация, данные жизненного цикла и т.д.).
Ещё одно мнение -- это синонимичность управления конфигурацией и управления данными с управлением инженерной документацией и управлением жизненным циклом продукта. Вот что об этом говорится в четвертом издании одной из самых популярных книжек по управлению конфигурацией (Watts, Frank B. (2011-11-07). Engineering Documentation Control Handbook: Configuration Management and Product Lifecycle Management): The title of this book indicates that Engineering Documentation Control - Configuration Management and Product Lifecycle Management are equivalent terms. But are they really? Many people feel that EDC is a subset of CM. Some think of EDC as what they are currently doing and CM as what they ought to be doing. PLM is a term used primarily by software applications for engineering - but it certainly implies a cycle that transcends engineering into manufacturing and to the customer. Much of the truth in this discussion is in “the eyes of the beholder.”
Другими словами: есть некоторая дисциплина, набор практик, а как уж его назвать и к какой наддисциплине это принадлежит -- зависит от называльщика.
Жизнь также показывает, что управление конфигурацией, в том числе и управление изменениями (опять же -- то включается, то исключается из "управления конфигурацией" и рассматривается отдельно) невозможно рассматривать отдельно от управления данными (управления информацией, интеграции данных жизненного цикла и т.д.) -- это подтверждает и неразрывность CM и PLM, и само именование профильной ассоциации (Association of Configuration and Data Management, http://acdm.org/).
Какие практики попадают в этот блок, нужно изучать специально. Похоже, сюда попадают:
-- практика выпуска (release) инженерных артефактов (например, выпуск чертежей) -- и можно обсуждать, является ли hand-over данных входящим в эту практику, или должен рассматриваться отдельно
-- практика выпуска [сводных] заказных спецификаций (BOM, bill of materials)
-- практика запросов на изменения
-- практика изменения проекта
-- практика управления данными (чтобы нужные заинтересованным сторонам данные оказывались у них в нужное время. Да, "управление требованиями", как часть инженерии требований, отвечающая именно за то, чтобы требования адекватно хранились и адекватно предоставлялись по запросам заинтересованных сторон -- это часть именно этой практики. Ибо нет никаких особенностей именно у "управления требованиями" в отличии их от управления любыми другими данными. Ну, и помним, что слово "управление" тут ничего не означает, как обычно. Никаких управленцев в управлении данными!).
Все эти бесхозные инфраструктурные дисциплины, которые попадают в зазор между чисто менеджерскими (типа лидерства -- когда живых людей убалтывают занять позиции в бездушной машине-предпринятии) и чисто техническими (когда придумывают и изготавливают конструктивные решения для целевой системы) я бы назвал не "практики поддержки проектов" (чтобы на слово "проект" не набежали технически неподготовленные MBA с сертификатами PMI), а "инженерными сервисами" -- подчеркнув тем самым, что они относятся к инженерам-проектировщикам (Watts, Frank B. (2011-11-07). Engineering Documentation Control Handbook: Configuration Management and Product Lifecycle Management): The CM title is preferred when the responsibilities are generally as outlined in this book. When the responsibilities are broader (include functions such as publications, reproduction, data backup, software system input/control, etc.), then the generally preferred name is Engineering Services.
Тут нужно учесть, что книжка корнями уходит (это ведь четвертое издание!) в бумажную систему инженерного документооборота. Появление PLM систем уже не позволяет обсуждать configuration management без data management -- и неминуемо организационное звено предпринятия, ответственное за engineering documentation control, configuration management и PLM будет ответственным и за data and information management. Так что -- инженерные сервисы, однозначно, причем эти инженерные сервисы в связи с переходом к моделеориентированной системной инженерии претерпевают коренную ломку, включая всё больше и больше сервисов по работе с данными (ага, "инженерная шина предприятия" или что-то типа этого, управление инженерными справочными/мастер данными -- это ведь тоже сюда).
Аналогично, из традиционного менеджерского блока выпадают практики проектного управления в той мере, в какой они зацепляют:
-- создание графика изготовления/сооружения так, как это понимают технологии (все эти Multi-D, когда информация из 3D проекта и информация по технологиям изготовления/сборки/стройки/монтажа используется для создания графика работ).
-- исследование операций (приложения к логистике, к расчетам supply chain, эвристики планирования потоков работ/комплектующих из теории ограничений Голдратта, "заводская физика" и т.д.), ибо это требует не столько "менеджерской", сколько чисто расчётной инженерной экспертизы.
Вообще, это огромная дискуссия, что в "проектном управлении" останется, если из тамошнего проектного шовинизма выделить "это просто менеджмент, учись расставлять людей, детка" и "это просто инженерия, учи математику, детка". А если следовать логике теории ограничений, то управленческий финансовый учёт (как логистика денежных потоков) тоже уйдёт сюда -- и тоже как инженерная дисциплина. Но я бы не рискнул эту инженерную составляющую считать "инженерным сервисом". Я хорошо понимаю, почему авторы ISO 15288 группу проектных практик (единственную) разбили на две подгруппы. Я бы считал практику планирования проектов частью практики архитектурного проектирования (это очень удобно в русском языке, где "проект" понимается и как project и как design), а контроль исполнения проекта -- частью практики интеграции, подчеркивая это самое Multi-D как в проектировании, так и в интеграции/сооружении (недаром на практике часто путают -- то Multi-D означает "все D", то "только начиная с 4D и дальше, но не 3D").
Но лучше я пока оставлю вопрос "истинно проектных практик в инженерии" для отдельного рассмотрения, а постинг на этом закончу.
-- INCOSE (международный совет системных инженеров), http://incose.org
-- ASEM (американская, но по факту -- международное общество инженерного менеджмента), http://asem.org
-- ACDM (ассоциация управления конфигурацией и управления данными), http://acdm.org/.
Я много лет еще и член ACM (ассоциация компьютерной машинерии), http://acm.org, а в ней SIGSOFT (специальная группа по интересам, занимающаяся программной инженерией), но тамошнее членство позволяет лишь сказать, что новейшие IT-технологии будут продолжать взрывать содержание текущих практик системной инженерии, инженерного менеджмента и управления конфигурацией и данными с неменьшей скоростью, чем это происходило до сих пор. Я думаю, что скорость этих изменений ещё и увеличится: переход к моделеориентированной системной инженерии и порождающему проектированию и производству обеспечивается прежде всего новыми алгоритмами, новым софтом.
Есть минимум три (основных, а так их много больше) смежных профессиональных практик (дисциплин), каждая из которых соревнуется с другими в своём шовинизме и желании поглотить сотоварищей:
-- системная инженерия
-- инженерный менеджмент
-- инженерные сервисы
Например, ISO 15288 (определяет практики жизненного цикла системной инженерии -- вот список: ), из четырех групп практик только одну (технические практики) определяет как собственно "системная инженерия" в узком смысле слова (практики того, что делают с целевой системой: задумывают, проектируют, изготавливают, проверяют и сдают, эксплуатируют, выводят из эксплуатации и т.д.). Остальные группы практик -- контрактные, проектные и обеспечения проектов -- это про то, что делает обеспечивающая система, сиречь предпринятие, занимающееся работами по продвижению целевой системы по её жизненному циклу. В эти практики попадает и управление портфелем проектов, и управление персоналом проектами, и управление конфигурацией, и даже заключение контрактов. Это было абсолютно сознательное склеивание системной инженерии и инженерного менеджмента (с выходом на организационную инженерию) со стороны разработчиков стандарта, я обсуждал эту тему с редактором первой версии Бадом Лоусоном. Вот это разбиение (т.е. набор частей) системной инженерии по версии ISO 15288 (на английском это цитируется вот тут -- http://ailev.livejournal.com/632128.html -- заодно там обсуждается и бессмысленность какого-то содержательного анализа использования слова management в названии дисциплины/практики, например, обоснование отнесения к широкой дисциплине "менеджмент" на основании использования этого слова в названии практики):
Системная инженерия:
1. Контрактация
1.1. Закупка
1.2. Поставка
2. Обеспечения проектов
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. Вывод из эксплуатации
Инженерный менеджмент тоже крут в плане своего шовинизма. Он, вообще-то говоря, псевдодисциплина: скомпонованный для целей совместного маркетинга учебными заведениями набор разных полезных дисциплин. "Истинные дисциплины" -- это которые имеют свои собственные объекты (типа "требования" и "архитектура" в системной инженерии), и поэтому "истинные части" (типа "инженерии требований" и "инженерии системной архитектуры"). Разбиение истинных дисциплин -- это отношение состава (часть-целое, композиция). Псевдодисциплины -- это объединения (агрегация) по каким-то критериям фрагментов разных других "истинных дисциплин": информационная архитектура (но не моделирование данных!), инженерный менеджмент и много-много других. Так вот, инженерный менеджмент включает в себя не только лидерство и управление проектами, но и системную инженерию! Почему? "Инженерный менеджер должен знать основы системной инженерии". Ага, ибо мало кто в ASEM интересуется, что делает инженерный менеджер -- но всех волнует, что должен знать инженерный менеджер. Вот главы Handbook of Engineering Management, сравните их с практиками системной инженерии:
1. Инженерный менеджмент -- настоящее, прошлое, и будущее.
2. Вопросы профессиональной ответственности, этики и законодательства.
3. Теория и понятия менеджмента
4. Управление знаниевыми работниками.
5. Исследование операций
6. Имитационное моделирование
7. Анализ при принятии решений (decision analisys)
8. Мультикритериальный анализ
9. Основы бухучёта и финансов
10. Инженерная экономика
11. Роль управления проектами в стоимости жизненного цикла
12. Системная инженерия [только технические практики]
13. Управление рисками
14. Стратегическое управление
15. Системное мышление
16. Лидерство для индивидуальных работников и команд инженерных проектов.
Тамошнее Body of Knowledge не лучше, но в нём хотя бы системной инженерии на верхнем уровне нет (оглавление на английском -- http://asmedl.org/ebooks/asme/asme_press/802991):
1. Исследования рынка, оценки и прогнозы
2. Стратегическое планирование и управление изменениями
3. Разработка продукта, сервиса и процесса
4. Управление инженерными проектами и процессами
5. Управление финансовыми ресурсами
6. Маркетинг, продажи, и управление коммуникациями
7. Лидерство и организационное управление
8. Вопросы профессиональной ответственности, этики и законодательства.
Инженерные сервисы (engineering services) -- это весьма спорное название для группы инфраструктурных практик типа управления конфигурацией и управления данными, которые системные инженеры относят к "поддержке проектов" (ISO 15288), инженерные менеджеры вообще не замечают, соответствующие функциональные подразделения на предприятиях часто так и называют. Ирония судьбы в том, что в инженерные сервисы свободно записывают и системную инженерию, и вообще любую инженерию в целом, равно как и configuration and data management (вот, например, обратите внимание, в каком разделе и среди каких других практик configuration and data management тут: http://www.windmill-intl.com/professional/engineeringservices/configuration.htm, а вот configuration change control вынут из engineering services и засунут в management services -- www.control-pt.com/services/engineering-services, вот управление конфигурацией прямо внутри проектного управления, но не в инженерных сервисах -- http://www.novasystems.com/services/project_management/configuration_management, и так дальше везде: некоторый ряд инфраструктурных практик обеспечивающей системы системной инженерии имеет неопределённое отнесение и претендует на какую-то самость (ибо имеет собственные понятия, не встречающиеся в менеджменте и системной инженерии -- конфигурация, данные жизненного цикла и т.д.).
Ещё одно мнение -- это синонимичность управления конфигурацией и управления данными с управлением инженерной документацией и управлением жизненным циклом продукта. Вот что об этом говорится в четвертом издании одной из самых популярных книжек по управлению конфигурацией (Watts, Frank B. (2011-11-07). Engineering Documentation Control Handbook: Configuration Management and Product Lifecycle Management): The title of this book indicates that Engineering Documentation Control - Configuration Management and Product Lifecycle Management are equivalent terms. But are they really? Many people feel that EDC is a subset of CM. Some think of EDC as what they are currently doing and CM as what they ought to be doing. PLM is a term used primarily by software applications for engineering - but it certainly implies a cycle that transcends engineering into manufacturing and to the customer. Much of the truth in this discussion is in “the eyes of the beholder.”
Другими словами: есть некоторая дисциплина, набор практик, а как уж его назвать и к какой наддисциплине это принадлежит -- зависит от называльщика.
Жизнь также показывает, что управление конфигурацией, в том числе и управление изменениями (опять же -- то включается, то исключается из "управления конфигурацией" и рассматривается отдельно) невозможно рассматривать отдельно от управления данными (управления информацией, интеграции данных жизненного цикла и т.д.) -- это подтверждает и неразрывность CM и PLM, и само именование профильной ассоциации (Association of Configuration and Data Management, http://acdm.org/).
Какие практики попадают в этот блок, нужно изучать специально. Похоже, сюда попадают:
-- практика выпуска (release) инженерных артефактов (например, выпуск чертежей) -- и можно обсуждать, является ли hand-over данных входящим в эту практику, или должен рассматриваться отдельно
-- практика выпуска [сводных] заказных спецификаций (BOM, bill of materials)
-- практика запросов на изменения
-- практика изменения проекта
-- практика управления данными (чтобы нужные заинтересованным сторонам данные оказывались у них в нужное время. Да, "управление требованиями", как часть инженерии требований, отвечающая именно за то, чтобы требования адекватно хранились и адекватно предоставлялись по запросам заинтересованных сторон -- это часть именно этой практики. Ибо нет никаких особенностей именно у "управления требованиями" в отличии их от управления любыми другими данными. Ну, и помним, что слово "управление" тут ничего не означает, как обычно. Никаких управленцев в управлении данными!).
Все эти бесхозные инфраструктурные дисциплины, которые попадают в зазор между чисто менеджерскими (типа лидерства -- когда живых людей убалтывают занять позиции в бездушной машине-предпринятии) и чисто техническими (когда придумывают и изготавливают конструктивные решения для целевой системы) я бы назвал не "практики поддержки проектов" (чтобы на слово "проект" не набежали технически неподготовленные MBA с сертификатами PMI), а "инженерными сервисами" -- подчеркнув тем самым, что они относятся к инженерам-проектировщикам (Watts, Frank B. (2011-11-07). Engineering Documentation Control Handbook: Configuration Management and Product Lifecycle Management): The CM title is preferred when the responsibilities are generally as outlined in this book. When the responsibilities are broader (include functions such as publications, reproduction, data backup, software system input/control, etc.), then the generally preferred name is Engineering Services.
Тут нужно учесть, что книжка корнями уходит (это ведь четвертое издание!) в бумажную систему инженерного документооборота. Появление PLM систем уже не позволяет обсуждать configuration management без data management -- и неминуемо организационное звено предпринятия, ответственное за engineering documentation control, configuration management и PLM будет ответственным и за data and information management. Так что -- инженерные сервисы, однозначно, причем эти инженерные сервисы в связи с переходом к моделеориентированной системной инженерии претерпевают коренную ломку, включая всё больше и больше сервисов по работе с данными (ага, "инженерная шина предприятия" или что-то типа этого, управление инженерными справочными/мастер данными -- это ведь тоже сюда).
Аналогично, из традиционного менеджерского блока выпадают практики проектного управления в той мере, в какой они зацепляют:
-- создание графика изготовления/сооружения так, как это понимают технологии (все эти Multi-D, когда информация из 3D проекта и информация по технологиям изготовления/сборки/стройки/монтажа используется для создания графика работ).
-- исследование операций (приложения к логистике, к расчетам supply chain, эвристики планирования потоков работ/комплектующих из теории ограничений Голдратта, "заводская физика" и т.д.), ибо это требует не столько "менеджерской", сколько чисто расчётной инженерной экспертизы.
Вообще, это огромная дискуссия, что в "проектном управлении" останется, если из тамошнего проектного шовинизма выделить "это просто менеджмент, учись расставлять людей, детка" и "это просто инженерия, учи математику, детка". А если следовать логике теории ограничений, то управленческий финансовый учёт (как логистика денежных потоков) тоже уйдёт сюда -- и тоже как инженерная дисциплина. Но я бы не рискнул эту инженерную составляющую считать "инженерным сервисом". Я хорошо понимаю, почему авторы ISO 15288 группу проектных практик (единственную) разбили на две подгруппы. Я бы считал практику планирования проектов частью практики архитектурного проектирования (это очень удобно в русском языке, где "проект" понимается и как project и как design), а контроль исполнения проекта -- частью практики интеграции, подчеркивая это самое Multi-D как в проектировании, так и в интеграции/сооружении (недаром на практике часто путают -- то Multi-D означает "все D", то "только начиная с 4D и дальше, но не 3D").
Но лучше я пока оставлю вопрос "истинно проектных практик в инженерии" для отдельного рассмотрения, а постинг на этом закончу.