Переход к системной инженерии в инжиниринговой компании
Предположим, что случилось чудо, и какая-то российская инжиниринговая компания захотела последовать опыту всяких разных Boeing Commercial Airplane Co., Rollce-Royce, Mitsubishi Electric Corporation и прочих мирных и военных инжиниринговых компаний со странички http://incose.org/about/organization/cab.cfm -- то есть заменить свою бессистемную инженерию системной инженерией.
1. Нужно четко понимать, что речь идет об управлении технологией -- замены одного метода инженерной работы на другую в масштабах предприятия. Это подразумевает выполнение минимально следующих практик (обычно поначалу этим занимается "служба развития", http://praxos.livejournal.com/11299.html и минимально требующийся для выполнения этих практик персонал включает Предпринимателя/заказчика, методолога/стратега/технолога, онтолога/модельера данных и программиста/айтишника плюс Организатора):
-- выбор метода системной инженерии
-- освоение дисциплины данного метода (получение людей, которые следуют дисциплине мышления и действия)
-- разворачивание технологии данного метода (закупка и настройка софта, постановка практик с использованием данной технологии, подготовка форм документов, наполнение баз данных и т.д.)
-- организация работы (разделение труда, определение полномочий и обязанностей, "расстановка по местам", организация взаимодействия и сотрудничества, правила дележки ресурсов)
-- запуск механизма непрерывного совершенствования ("уровни зрелости")
2. Прежде всего, нужно понять, какое поколение системной инженерии интересует (http://ailev.livejournal.com/936356.html -- я выделяю четыре поколения). Ибо можно запросто ошибиться, пригласив стареньких и знаменитых иностранных консультантов, которые заменят бессистемное шило на системное мыло двадцатилетней давности. Или попытаться внедрить маленький сверхсовременный кусочек супер-пупер-системной инженерии, который не будет иметь никаких шансов выжить в окружающей бессистемной грязи.
3. Системная инженерия (рассматриваемая в части технических практик -- инженерия требований, инженерия системной архитектуры, системная интеграция и т.д.) не может быть освоена организацией без сопутствующих изменений в используемых методах инженерного менеджмента. Хорошим примером тут является ISO 15288, в котором освоение системной инженерии связывается с освоением не только группы технических практик, но и еще трёх других групп практик (а именно, проектных, организационных/программных, а также организационных/трансакционных -- обзовём их пока таким способом, чтобы показать суть дела, а не просто формальное "следование стандарту и его терминологии"). Так что "перехода к системной инженерии" будет маловато, нужен также переход от ad hoc менеджмента к какому-то конкретному варианту инженерного менеджмента (например, моделе-ориентированному -- http://ailev.livejournal.com/928876.html, если мы уж взялись тут говорить об управлении технологией, в данном случае технологией инженерного менеджмента).
4. Для того, чтобы получить нужных людей, требуется их либо нанять уже обученных (что считаю невероятным -- в лучшем случае будут наняты люди, обученные несовместимым между собой методам работы), либо обучить. Проблема в том, что переход к системной инженерии требует существенной перестройки в мышлении (т.е. перехода к использованию системного подхода на деле, а не "оформления обычной работы в терминологии системной инженерии". Иначе можно получить систеноинженерные аналоги высказываний типа "парламент -- не место для дебатов!"). Увы, краткосрочных (недельных, или двухнедельных) курсов системной инженерии достаточно, чтобы познакомить с основными идеями и даже терминологией, но недостаточно, чтобы из "просто инженера" получить системного инженера. Не нужно забывать, что системная инженерия -- это магистерская специальность, ей учат пять лет. Даже если рассматривать вариант дополнительного высшего образования (прикидки по образовательным объемам: http://ailev.livejournal.com/871079.html), то это освоение материала 30 не слишком толстых учебников и стандартов (ага, счет страниц стандартов в этой предметной области легко выходит на сотни), а также руководств к программному обеспечению и организационных регламентов. (ибо мало "знать предмет", нужно еще и "знать технологию").
Ежели эти слова не убедили, то вот анализ "образования" и "тренинга" в развитии системного мышления (там очень убедительная табличка, тренинг в развитии системного мышления является наименее действенным средством изо всех -- а ведь без системного мышления никакой системной инженерии не будет): http://www.aero.org/publications/crosslink/spring2007/04.html
Поэтому образовательные программы западных инжиниринговых фирм устроены "многоуровнево": обычно для инженерного корпуса корпорации руководством задаётся требуемый процент Ph.D., магистров, бакалавров, повысивших квалификацию на краткосрочных курсах (таких обычно 100%), и далее разворачивается многолетняя и дорогая программа по достижению этих показателей -- в партнерстве с большим числом учебных заведений (например, поглядите, как выглядят цены для курсов, если вы работаете на Boeing -- http://dce.mst.edu/admissions/fee_schedule.html, это из-за довольно типового корпоративного соглашения с университетом, в котором Boeing employees and its suppliers worldwide have the opportunity to earn a Master of Science degree, Graduate Certificate, or Ph.D. in Systems Engineering -- http://emse.mst.edu/boeing/index.html). Вот еще опыт MITRE (7тыс.человек) -- http://www.mitre.org/work/tech_papers/2010/10_0678/10_0678.pdf, вот подход NASA -- http://www.worldscinet.com/srf/03/0302/free-access/S1793966609000080.pdf (и, кстати, моя критика этого подхода: http://ailev.livejournal.com/803770.html).
5. Нужно быть готовым заплатить $много за софт и его настройку. Нужны разные САПРы, нужны системы моделирования, нужны PLM. Нет шансов купить всё это в коробочном варианте. Чтобы всё это заработало, нужны исследования и суперусилия. И нужны люди, которые понимают, зачем им этот софт и готовы с ним работать -- то есть для работы нужны обученные люди. Отдельно скажу, что никакое "внедрение софта" или "переход к 3D-проектированию" при этом не является переходом к системной инженерии. Этот переход совершается прежде всего в головах людей, а системноинженерный софт в руках инженеров дикарей является "файлами на диске", так же как ружьё в руках дикаря -- не более чем кусок железа. Но без софта и его настройки не будет никакой системной инженерии, будут только разговоры о ней.
6. Нужны экстраординарные усилия по организации работы по-новому -- определить жизненный цикл, назначить людей на акторские роли, определить полномочия этих людей в выделении людских и денежных ресурсов, обеспечивать адекватное выбранным методам (а не поперек и мимо них) планирование ежедневной работы. Это требует искусного организатора, ибо речь тут идёт о масштабной реорганизации. Если у вас были ГИПы, которые главным образом представляли из себя проектных менеджеров, то появление системных архитекторов и инженеров по требованиям может вызвать чисто человеческие конфликты между старыми привычками работы и вновь предлагаемыми методами моделе-ориентированной работы. А уж если на первых порах что-нибудь не будет получаться (а ведь на первых, и часто даже на вторых порах не будет получаться -- сразу без ошибок-то ведь никакая организация не проходит!), то есть риск провала проекта из-за "отсутствия политической воли", "недостатка leadership" (то есть недостатка умения убалтывать других людей следовать целям организации, а не своим личным хотелкам) и других абсолютно нетехнических причин.
7. После того, как работа хоть как-то пошла по новому, нужно идти по циклу непрерывного совершенствования, "процессной зрелости". Эту работу нужно обязательно предусматривать (иногда ее рассматривают как "текущую организационную" в противовес "реорганизационной" -- и этот переход нужно планировать). Например, использовать сочетание голдратовской техники обнаружения ограничений и lean & 6 sigma методов подстройки под ограничения и снятия ограничений. Опять же, этот цикл подъема по ступенькам процессной зрелости в новом методе работы нужно "запускать" сознательно, что требует дополнительных усилий в ходе реорганизации -- и об этих усилиях нельзя забывать.
8. Каждый из предыдущих пунктов -- "самый критический". Нет поддержки Предпринимателя/Заказчика -- данного оргпроекта не будет вообще. Не найдётся организатора, который сможет всё это вытянуть, будет грандиозная неудача. Выбрано неверное содержание образования -- овчинка окажется не стоящей выделки, а конкуренты будут радоваться. Недостаточно времени и усилий ушло на обучение -- не видать вам следования дисциплине системной инженерии, в работе будут только использовать новомодные слова, а работать и думать будут по-старинке. Не будет развернута технология -- никакого толку от обученных людей не будет (ибо не только экскаваторщик без экскаватора не копает, но даже и землекоп без лопаты. Что уж говорить о моделе-ориентированной системной инженерии без настроенного софта, который поддерживает те самые модели!). Ну, и так далее по всему списку.
9. С чего начать? С организации хоть какой-то команды озабоченных технологическим менеджментом людей, и прикидок силами этой команды имеющегося задора и поддерживающего этот задор административных, знаниевых, людских, финансовых и прочих ресурсов по каждому пункту из списка. А дальше всё зависит от задора и полномочий людей, оказавшихся в команде -- и от наличия ресурсов и длинной многолетней воли, чтобы дождаться таки успеха, а не бросить дело на полпути.
1. Нужно четко понимать, что речь идет об управлении технологией -- замены одного метода инженерной работы на другую в масштабах предприятия. Это подразумевает выполнение минимально следующих практик (обычно поначалу этим занимается "служба развития", http://praxos.livejournal.com/11299.html и минимально требующийся для выполнения этих практик персонал включает Предпринимателя/заказчика, методолога/стратега/технолога, онтолога/модельера данных и программиста/айтишника плюс Организатора):
-- выбор метода системной инженерии
-- освоение дисциплины данного метода (получение людей, которые следуют дисциплине мышления и действия)
-- разворачивание технологии данного метода (закупка и настройка софта, постановка практик с использованием данной технологии, подготовка форм документов, наполнение баз данных и т.д.)
-- организация работы (разделение труда, определение полномочий и обязанностей, "расстановка по местам", организация взаимодействия и сотрудничества, правила дележки ресурсов)
-- запуск механизма непрерывного совершенствования ("уровни зрелости")
2. Прежде всего, нужно понять, какое поколение системной инженерии интересует (http://ailev.livejournal.com/936356.html -- я выделяю четыре поколения). Ибо можно запросто ошибиться, пригласив стареньких и знаменитых иностранных консультантов, которые заменят бессистемное шило на системное мыло двадцатилетней давности. Или попытаться внедрить маленький сверхсовременный кусочек супер-пупер-системной инженерии, который не будет иметь никаких шансов выжить в окружающей бессистемной грязи.
3. Системная инженерия (рассматриваемая в части технических практик -- инженерия требований, инженерия системной архитектуры, системная интеграция и т.д.) не может быть освоена организацией без сопутствующих изменений в используемых методах инженерного менеджмента. Хорошим примером тут является ISO 15288, в котором освоение системной инженерии связывается с освоением не только группы технических практик, но и еще трёх других групп практик (а именно, проектных, организационных/программных, а также организационных/трансакционных -- обзовём их пока таким способом, чтобы показать суть дела, а не просто формальное "следование стандарту и его терминологии"). Так что "перехода к системной инженерии" будет маловато, нужен также переход от ad hoc менеджмента к какому-то конкретному варианту инженерного менеджмента (например, моделе-ориентированному -- http://ailev.livejournal.com/928876.html, если мы уж взялись тут говорить об управлении технологией, в данном случае технологией инженерного менеджмента).
4. Для того, чтобы получить нужных людей, требуется их либо нанять уже обученных (что считаю невероятным -- в лучшем случае будут наняты люди, обученные несовместимым между собой методам работы), либо обучить. Проблема в том, что переход к системной инженерии требует существенной перестройки в мышлении (т.е. перехода к использованию системного подхода на деле, а не "оформления обычной работы в терминологии системной инженерии". Иначе можно получить систеноинженерные аналоги высказываний типа "парламент -- не место для дебатов!"). Увы, краткосрочных (недельных, или двухнедельных) курсов системной инженерии достаточно, чтобы познакомить с основными идеями и даже терминологией, но недостаточно, чтобы из "просто инженера" получить системного инженера. Не нужно забывать, что системная инженерия -- это магистерская специальность, ей учат пять лет. Даже если рассматривать вариант дополнительного высшего образования (прикидки по образовательным объемам: http://ailev.livejournal.com/871079.html), то это освоение материала 30 не слишком толстых учебников и стандартов (ага, счет страниц стандартов в этой предметной области легко выходит на сотни), а также руководств к программному обеспечению и организационных регламентов. (ибо мало "знать предмет", нужно еще и "знать технологию").
Ежели эти слова не убедили, то вот анализ "образования" и "тренинга" в развитии системного мышления (там очень убедительная табличка, тренинг в развитии системного мышления является наименее действенным средством изо всех -- а ведь без системного мышления никакой системной инженерии не будет): http://www.aero.org/publications/crosslink/spring2007/04.html
Поэтому образовательные программы западных инжиниринговых фирм устроены "многоуровнево": обычно для инженерного корпуса корпорации руководством задаётся требуемый процент Ph.D., магистров, бакалавров, повысивших квалификацию на краткосрочных курсах (таких обычно 100%), и далее разворачивается многолетняя и дорогая программа по достижению этих показателей -- в партнерстве с большим числом учебных заведений (например, поглядите, как выглядят цены для курсов, если вы работаете на Boeing -- http://dce.mst.edu/admissions/fee_schedule.html, это из-за довольно типового корпоративного соглашения с университетом, в котором Boeing employees and its suppliers worldwide have the opportunity to earn a Master of Science degree, Graduate Certificate, or Ph.D. in Systems Engineering -- http://emse.mst.edu/boeing/index.html). Вот еще опыт MITRE (7тыс.человек) -- http://www.mitre.org/work/tech_papers/2010/10_0678/10_0678.pdf, вот подход NASA -- http://www.worldscinet.com/srf/03/0302/free-access/S1793966609000080.pdf (и, кстати, моя критика этого подхода: http://ailev.livejournal.com/803770.html).
5. Нужно быть готовым заплатить $много за софт и его настройку. Нужны разные САПРы, нужны системы моделирования, нужны PLM. Нет шансов купить всё это в коробочном варианте. Чтобы всё это заработало, нужны исследования и суперусилия. И нужны люди, которые понимают, зачем им этот софт и готовы с ним работать -- то есть для работы нужны обученные люди. Отдельно скажу, что никакое "внедрение софта" или "переход к 3D-проектированию" при этом не является переходом к системной инженерии. Этот переход совершается прежде всего в головах людей, а системноинженерный софт в руках инженеров дикарей является "файлами на диске", так же как ружьё в руках дикаря -- не более чем кусок железа. Но без софта и его настройки не будет никакой системной инженерии, будут только разговоры о ней.
6. Нужны экстраординарные усилия по организации работы по-новому -- определить жизненный цикл, назначить людей на акторские роли, определить полномочия этих людей в выделении людских и денежных ресурсов, обеспечивать адекватное выбранным методам (а не поперек и мимо них) планирование ежедневной работы. Это требует искусного организатора, ибо речь тут идёт о масштабной реорганизации. Если у вас были ГИПы, которые главным образом представляли из себя проектных менеджеров, то появление системных архитекторов и инженеров по требованиям может вызвать чисто человеческие конфликты между старыми привычками работы и вновь предлагаемыми методами моделе-ориентированной работы. А уж если на первых порах что-нибудь не будет получаться (а ведь на первых, и часто даже на вторых порах не будет получаться -- сразу без ошибок-то ведь никакая организация не проходит!), то есть риск провала проекта из-за "отсутствия политической воли", "недостатка leadership" (то есть недостатка умения убалтывать других людей следовать целям организации, а не своим личным хотелкам) и других абсолютно нетехнических причин.
7. После того, как работа хоть как-то пошла по новому, нужно идти по циклу непрерывного совершенствования, "процессной зрелости". Эту работу нужно обязательно предусматривать (иногда ее рассматривают как "текущую организационную" в противовес "реорганизационной" -- и этот переход нужно планировать). Например, использовать сочетание голдратовской техники обнаружения ограничений и lean & 6 sigma методов подстройки под ограничения и снятия ограничений. Опять же, этот цикл подъема по ступенькам процессной зрелости в новом методе работы нужно "запускать" сознательно, что требует дополнительных усилий в ходе реорганизации -- и об этих усилиях нельзя забывать.
8. Каждый из предыдущих пунктов -- "самый критический". Нет поддержки Предпринимателя/Заказчика -- данного оргпроекта не будет вообще. Не найдётся организатора, который сможет всё это вытянуть, будет грандиозная неудача. Выбрано неверное содержание образования -- овчинка окажется не стоящей выделки, а конкуренты будут радоваться. Недостаточно времени и усилий ушло на обучение -- не видать вам следования дисциплине системной инженерии, в работе будут только использовать новомодные слова, а работать и думать будут по-старинке. Не будет развернута технология -- никакого толку от обученных людей не будет (ибо не только экскаваторщик без экскаватора не копает, но даже и землекоп без лопаты. Что уж говорить о моделе-ориентированной системной инженерии без настроенного софта, который поддерживает те самые модели!). Ну, и так далее по всему списку.
9. С чего начать? С организации хоть какой-то команды озабоченных технологическим менеджментом людей, и прикидок силами этой команды имеющегося задора и поддерживающего этот задор административных, знаниевых, людских, финансовых и прочих ресурсов по каждому пункту из списка. А дальше всё зависит от задора и полномочий людей, оказавшихся в команде -- и от наличия ресурсов и длинной многолетней воли, чтобы дождаться таки успеха, а не бросить дело на полпути.