Классификация практик инженерного предпринятия по отношению их к целевой системе
Художник, паталогоанатом и политик смотрят на женщин в ходе своих профессиональных занятий абсолютно по-разному. Разные практики работают с одними и теми же объектами работ абсолютно по-разному. Эти практики можно классифицировать разными способами, в зависимости от того, что вы собираетесь с этими практиками делать.
В постинге "системная инженерия, инженерный менеджмент и инженерные сервисы" (http://ailev.livejournal.com/1005515.html) я приводил классификацию дисциплин как группирование практик по "социологическому" основанию: какие есть профессиональные тусовки с их конференциями, учебниками, ассоциациями и сертификациями. Эта классификация удобна для закупки/подготовки специалистов и закупки софта. Проблемы начинаются там и тогда, где и когда требуется обеспечить интеграцию всех этих практик в работе конкретного предпринятия. Для такой интеграции нужно описать практики содержательно: чтобы можно было легко найти дублирования практик отдельных дисциплин (в силу неизбежного профессионального шовинизма), чтобы иметь достаточную детальность описания типовых практик для выбора из них нужных шаблонов и увязывания фрагментов практик в целостный набор сервисов предпринятия, способный породить целевую систему.
Для этого рассортируем практики по отношению практикующих (выполнителей, деятелей) к целевой системе, уточняя почти трёхлетней давности постинг "Четыре группы описаний жизненного цикла в PraxOS" (http://ailev.livejournal.com/764492.html).
Минимально есть три отношения выполнителей к целевой системе (любой -- от коробка спичек, до марсохода):
1. отношение целеполагания: со стороны внешних системы, в которой целевая система является частью с определенной функцией (назначением).
2. инженерное отношение: со стороны устройства самой системы (части системы и их взаимодействие) -- 4D проект "в классах", а затем и "в бетоне и железе", как его видят проектанты с технологами.
3. логистическое отношение: со стороны работы обеспечивающей системы по протягиванию конфигурации целевой системы по жизненному циклу, как его видят специалисты по операционному менеджменту.
А поскольку у нас появилась еще и обеспечивающая система, то введем дополнительно косвенное для целевой системе отношение к обеспечивающей системе:
4. (косвенное) отношение организовывания и развития: практику создания и развития предпринятия, как обеспечивающей системы из выполнителей, их сервисов и объектов работы.
Тут, конечно, много спорных мест (например, выделение целеполагания вместе с инженерией требований в отдельную группу практик, но у меня есть основания считать, что так будет лучше).
Это очень похоже на группирование практик жизненного цикла системной инженерии в ISO 15288 (куда тоже попали отнюдь не только "инженерные", т.е. технические, практики). Но есть и множество отличий. В качестве упражнения, найдите их сами. Хинт: обратите внимание на подход с "описыванием жизненного цикла" vs подхода с "архитектурой предпринятия", обращение к теории ограничений и adaptive case management против подхода проектного управления и ISO 9000 -- ну, вы поняли идею. Ну, и терминологические замены. Я всегда с трудом объяснял людям про "обеспечение проектов" в ISO 15288. Так что я постарался выбирать слова, наиболее точно отражающие специфический профессиональный взгляд на целевую систему со стороны той или иной практики. Один и тот же болт может быть одновременно для совместно работающих выполнителей разных практик и "элементом конструкции", и "конфигурационной единицей", и "элементом очереди на обработку", и "комплектующим", и "предметом снабжения". Вот я и постарался как то подчеркнуть в названиях специфику разных по типу отношения к целевой системе групп практик:
1. Практики целеполагания (стратегирования, мотивирования, определения требований, маркетинговых исследований).
Внешние требования к целевой системе, которые может понять заказчик, надзоры, операторы и другие стейкхолдеры времени эксплуатации целевой системы: назначение, эксплуатационные свойства и требования к операционному (времени эксплуатации) окружению. Получением этих описаний занимается инженерия требований. Ключевое тут -- "польза", value.
Для собачьей будки это будут:
-- интерфейс к собаке: внутренние размеры, размер входа, нетоксичность, теплопроводность пола и стенок, наличие крепления для привязи и т.д.
-- интерфейс ко двору: внешние размеры, внешний вид
-- интерфейс к оператору: удобство уборки, удобство крепления на месте и последующего переноса,
-- интерфейс к собственнику будки: срок службы, стоимость эксплуатации и ремонтопригодность, стоимость приобретения.
-- интерфейс к собственнику предпринятия-будкостроителя: прибыльность начинания.
Из софта используется бумажный блокнот и скайп.
2. Инженерные (технические) практики.
Инженерное задание целевой системы, и технологическая часть производства: как функция поддерживается конструкцией (какие там части системы -- 3D модель) и механизмом (как части системы взаимодействуют -- "модель поведения", процесс времени эксплуатации), и инженерные планы (планы разработки -- говорят о 4D, процесс времени проектирования). Получением этих описаний занимается архитектурное проектирование (куда входят как инженерия системной архитектуры, так и разные специальные инженерии, включая работу технологов). Ключевое тут -- "4D проект: геометрия, схемы и имитационные модели, технологические карты хода изготовления".
Для собачьей будки это будет:
-- 3D модель из крыши, разных стенок, крепежа.
-- прочностные модели, модели теплообмена (имитационные собаки в имитационной будке в имитационном климате)
-- заказная спецификация на детали (сами детали делаются инженерами по специальности, а также закупаются)
-- технологическая последовательность изготовления, а затем и сборки (4D)
Из софта тут используются самые разные САПРы и системы инженерного моделирования.
3. Инженерные сервисы и логистика: "оперативное управление".
Задание движения объектов (как материальных, так и привязанных к носителям данных) в пространстве-времени: по пространственно размещенным выполнителям в ходе жизненного цикла:
-- оформление объектов работы (конфигурационных единиц), которые нужно передавать по логистическим маршрутам. Это configuration and data management.
-- оформление маршрутов (передач конфигурационных единиц между выполнителями). Это шаблоны adaptive case management. Часть знания о маршрутах при этом приходит из инженерных технологических описаний (методологий разработки и технологических карт), а часть задаётся принятым способом учёта инженерной неопределённости (change management) и тесно связано с практиками configuration and data management.
-- определение и снятие ограничений (заторов) на маршрутах. Это operation research в разных его вариантах (например, теория ограничений).
-- работа с логистикой особого объекта: денег (throughput accounting, подход "прохода денег через производственную сеть" к управленческому финансовому учёту).
Для собачьей будки это будет:
-- выбор системы кодирования, идентификация конфигурационных единиц 4D проекта (будка breakdown structure, breakdowd structure работ по сборке будки и т.д.), определение процедуры "выпуска" (окончания изменений, готовность к передаче дальше -- для согласования или использования) по облегчённой процедуре (ибо вопрос "кому сидеть" для будок не такой острый).
-- оформление маршрута проектирования по рабочим местам, а затем маршрута закупки, изготовления, сборки и испытаний с учётом существующих производственных мощностей-сервисов (взятых из моделей архитектуры предприятия). Подготовка рабочих заданий, контроль их исполнения.
-- компьютерное моделирование хода разработки и изготовления, калибровка моделей.
-- ведение учёта переменных финансовых издержек (затрат и расходов) на проектирование и производство будок.
Из софта тут используются PLM (как интегрирующие инженерные данные) и ERP-системы (в которых важны алгоритмы планирования), системы supply change management, issue trackers и системы документооборота для работы с кейсами и процессами, 1С бухгалтерия для финансовой работы, спец.софт управления проектами (в которых важен алгоритм определения критического ресурсного пути -- "критической цепочки работ") -- то есть софт для "единого информационного пространства", "управления процессами", "управления проектами" и "управленческой бухгалтерии".
4. Организация и развитие предпринятия как пула доступных сервисов необходимых выполнителей: добыча/развитие качественных личностей и закрепление за ними ответственности и полномочий по распоряжению ресурсами, включая оборудование, деньги, и выдачу поручений другим людям (организация обеспечивающей системы), а также удовлетворение потребностей производства в технологиях (оборудовании).
-- практики организационной инженерии: задание архитектуры предпринятия (из людей, софта и оборудования), выполняющей все необходимые работы практик из предыдущих пунктов, а также реализация этой архитектуры в жизни (включая снятие ограничений -- ибо оперативное управление может и должно не столько снимать ограничения, сколько подстраиваться под них) -- "управление изменениями" aka "проекты развития" (не путать с "управлением изменениями" у инженеров). Это вотчина организационных инженеров.
-- лидерство (какие конкретные люди какой деятельностью займутся: назначение живых индивидов на занятие позиций в неживой оргструктуре). Это вотчина менеджеров, которые умеют работать с людьми. Оргинженеры тут отдыхают.
Конечно, "инженерный менеджер" подразумевается при этом как профессия человека, который может и архитектуру предпринятия разработать, и с людьми договориться -- как амфибия, выжить в обоих мирах. Но нам сейчас это неважно, нам бы на типы практик указать, в которых целевой системой является обеспечивающая система первых трех (целеполагания, инженерии, логистики) практик.
Из софта изредка используется система моделирования предприятия (чаще органиграмма составляется в Ворде), и MS Office для всех мыслимых потребноестей, которые есть у менеджеров. Ну, и данные всех остальных систем, которые есть. И даже данные социальных сетей, а чо!
Для собачьей будки это будет:
-- проверить, всё ли у нас есть для старта будкоделательного предпринятия. Докупить софт моделирования (ишь ты, конкуренты начали публиковать тепловые характеристики своих будок!) в службу Проектирования обиталищ.
-- назначить Василия Петровича на все роли системных инженеров по этому проекту, он собак любит, и у него много друзей собачников (а во включении кинолога в команду разработчиков в качестве "голоса пользователя" -- отказать). И студента Колю поставить на все САПРы сразу, ему давно пора расти как инженеру. Не будет справляться -- терпеть, пока научится.
-- последовательное прокручивание цикла снятия ограничений (студент Коля зашился со своими САПРами, ему нужно срочно подмогу! Комплектующие приходят неправильные, от обратной логистики лихорадит всех -- срочно разобраться, почему у нас заказывают эту гадость!).
-- уговорить Дядю Петю потратить полдня на учёт интересов собаки при проектировании 3D, и уговорить Тётю Дусю всё-таки закупать метизы в фирме "Заваляшка", где ей грубят и хамят, но зато там не бывает задержек с поставками и грубых ошибок комплектации.
-- троих из сборочного кошачьих домиков, у которых аллергия к кошкам (вот идиоты! Кошек же на сборке этих домиков нет!) переучить на работу по сборке будок. Или даже лучше набрать новых, а тех троих уволить. Зачем нам люди с заморочками?
В постинге "системная инженерия, инженерный менеджмент и инженерные сервисы" (http://ailev.livejournal.com/1005515.html) я приводил классификацию дисциплин как группирование практик по "социологическому" основанию: какие есть профессиональные тусовки с их конференциями, учебниками, ассоциациями и сертификациями. Эта классификация удобна для закупки/подготовки специалистов и закупки софта. Проблемы начинаются там и тогда, где и когда требуется обеспечить интеграцию всех этих практик в работе конкретного предпринятия. Для такой интеграции нужно описать практики содержательно: чтобы можно было легко найти дублирования практик отдельных дисциплин (в силу неизбежного профессионального шовинизма), чтобы иметь достаточную детальность описания типовых практик для выбора из них нужных шаблонов и увязывания фрагментов практик в целостный набор сервисов предпринятия, способный породить целевую систему.
Для этого рассортируем практики по отношению практикующих (выполнителей, деятелей) к целевой системе, уточняя почти трёхлетней давности постинг "Четыре группы описаний жизненного цикла в PraxOS" (http://ailev.livejournal.com/764492.html).
Минимально есть три отношения выполнителей к целевой системе (любой -- от коробка спичек, до марсохода):
1. отношение целеполагания: со стороны внешних системы, в которой целевая система является частью с определенной функцией (назначением).
2. инженерное отношение: со стороны устройства самой системы (части системы и их взаимодействие) -- 4D проект "в классах", а затем и "в бетоне и железе", как его видят проектанты с технологами.
3. логистическое отношение: со стороны работы обеспечивающей системы по протягиванию конфигурации целевой системы по жизненному циклу, как его видят специалисты по операционному менеджменту.
А поскольку у нас появилась еще и обеспечивающая система, то введем дополнительно косвенное для целевой системе отношение к обеспечивающей системе:
4. (косвенное) отношение организовывания и развития: практику создания и развития предпринятия, как обеспечивающей системы из выполнителей, их сервисов и объектов работы.
Тут, конечно, много спорных мест (например, выделение целеполагания вместе с инженерией требований в отдельную группу практик, но у меня есть основания считать, что так будет лучше).
Это очень похоже на группирование практик жизненного цикла системной инженерии в ISO 15288 (куда тоже попали отнюдь не только "инженерные", т.е. технические, практики). Но есть и множество отличий. В качестве упражнения, найдите их сами. Хинт: обратите внимание на подход с "описыванием жизненного цикла" vs подхода с "архитектурой предпринятия", обращение к теории ограничений и adaptive case management против подхода проектного управления и ISO 9000 -- ну, вы поняли идею. Ну, и терминологические замены. Я всегда с трудом объяснял людям про "обеспечение проектов" в ISO 15288. Так что я постарался выбирать слова, наиболее точно отражающие специфический профессиональный взгляд на целевую систему со стороны той или иной практики. Один и тот же болт может быть одновременно для совместно работающих выполнителей разных практик и "элементом конструкции", и "конфигурационной единицей", и "элементом очереди на обработку", и "комплектующим", и "предметом снабжения". Вот я и постарался как то подчеркнуть в названиях специфику разных по типу отношения к целевой системе групп практик:
1. Практики целеполагания (стратегирования, мотивирования, определения требований, маркетинговых исследований).
Внешние требования к целевой системе, которые может понять заказчик, надзоры, операторы и другие стейкхолдеры времени эксплуатации целевой системы: назначение, эксплуатационные свойства и требования к операционному (времени эксплуатации) окружению. Получением этих описаний занимается инженерия требований. Ключевое тут -- "польза", value.
Для собачьей будки это будут:
-- интерфейс к собаке: внутренние размеры, размер входа, нетоксичность, теплопроводность пола и стенок, наличие крепления для привязи и т.д.
-- интерфейс ко двору: внешние размеры, внешний вид
-- интерфейс к оператору: удобство уборки, удобство крепления на месте и последующего переноса,
-- интерфейс к собственнику будки: срок службы, стоимость эксплуатации и ремонтопригодность, стоимость приобретения.
-- интерфейс к собственнику предпринятия-будкостроителя: прибыльность начинания.
Из софта используется бумажный блокнот и скайп.
2. Инженерные (технические) практики.
Инженерное задание целевой системы, и технологическая часть производства: как функция поддерживается конструкцией (какие там части системы -- 3D модель) и механизмом (как части системы взаимодействуют -- "модель поведения", процесс времени эксплуатации), и инженерные планы (планы разработки -- говорят о 4D, процесс времени проектирования). Получением этих описаний занимается архитектурное проектирование (куда входят как инженерия системной архитектуры, так и разные специальные инженерии, включая работу технологов). Ключевое тут -- "4D проект: геометрия, схемы и имитационные модели, технологические карты хода изготовления".
Для собачьей будки это будет:
-- 3D модель из крыши, разных стенок, крепежа.
-- прочностные модели, модели теплообмена (имитационные собаки в имитационной будке в имитационном климате)
-- заказная спецификация на детали (сами детали делаются инженерами по специальности, а также закупаются)
-- технологическая последовательность изготовления, а затем и сборки (4D)
Из софта тут используются самые разные САПРы и системы инженерного моделирования.
3. Инженерные сервисы и логистика: "оперативное управление".
Задание движения объектов (как материальных, так и привязанных к носителям данных) в пространстве-времени: по пространственно размещенным выполнителям в ходе жизненного цикла:
-- оформление объектов работы (конфигурационных единиц), которые нужно передавать по логистическим маршрутам. Это configuration and data management.
-- оформление маршрутов (передач конфигурационных единиц между выполнителями). Это шаблоны adaptive case management. Часть знания о маршрутах при этом приходит из инженерных технологических описаний (методологий разработки и технологических карт), а часть задаётся принятым способом учёта инженерной неопределённости (change management) и тесно связано с практиками configuration and data management.
-- определение и снятие ограничений (заторов) на маршрутах. Это operation research в разных его вариантах (например, теория ограничений).
-- работа с логистикой особого объекта: денег (throughput accounting, подход "прохода денег через производственную сеть" к управленческому финансовому учёту).
Для собачьей будки это будет:
-- выбор системы кодирования, идентификация конфигурационных единиц 4D проекта (будка breakdown structure, breakdowd structure работ по сборке будки и т.д.), определение процедуры "выпуска" (окончания изменений, готовность к передаче дальше -- для согласования или использования) по облегчённой процедуре (ибо вопрос "кому сидеть" для будок не такой острый).
-- оформление маршрута проектирования по рабочим местам, а затем маршрута закупки, изготовления, сборки и испытаний с учётом существующих производственных мощностей-сервисов (взятых из моделей архитектуры предприятия). Подготовка рабочих заданий, контроль их исполнения.
-- компьютерное моделирование хода разработки и изготовления, калибровка моделей.
-- ведение учёта переменных финансовых издержек (затрат и расходов) на проектирование и производство будок.
Из софта тут используются PLM (как интегрирующие инженерные данные) и ERP-системы (в которых важны алгоритмы планирования), системы supply change management, issue trackers и системы документооборота для работы с кейсами и процессами, 1С бухгалтерия для финансовой работы, спец.софт управления проектами (в которых важен алгоритм определения критического ресурсного пути -- "критической цепочки работ") -- то есть софт для "единого информационного пространства", "управления процессами", "управления проектами" и "управленческой бухгалтерии".
4. Организация и развитие предпринятия как пула доступных сервисов необходимых выполнителей: добыча/развитие качественных личностей и закрепление за ними ответственности и полномочий по распоряжению ресурсами, включая оборудование, деньги, и выдачу поручений другим людям (организация обеспечивающей системы), а также удовлетворение потребностей производства в технологиях (оборудовании).
-- практики организационной инженерии: задание архитектуры предпринятия (из людей, софта и оборудования), выполняющей все необходимые работы практик из предыдущих пунктов, а также реализация этой архитектуры в жизни (включая снятие ограничений -- ибо оперативное управление может и должно не столько снимать ограничения, сколько подстраиваться под них) -- "управление изменениями" aka "проекты развития" (не путать с "управлением изменениями" у инженеров). Это вотчина организационных инженеров.
-- лидерство (какие конкретные люди какой деятельностью займутся: назначение живых индивидов на занятие позиций в неживой оргструктуре). Это вотчина менеджеров, которые умеют работать с людьми. Оргинженеры тут отдыхают.
Конечно, "инженерный менеджер" подразумевается при этом как профессия человека, который может и архитектуру предпринятия разработать, и с людьми договориться -- как амфибия, выжить в обоих мирах. Но нам сейчас это неважно, нам бы на типы практик указать, в которых целевой системой является обеспечивающая система первых трех (целеполагания, инженерии, логистики) практик.
Из софта изредка используется система моделирования предприятия (чаще органиграмма составляется в Ворде), и MS Office для всех мыслимых потребноестей, которые есть у менеджеров. Ну, и данные всех остальных систем, которые есть. И даже данные социальных сетей, а чо!
Для собачьей будки это будет:
-- проверить, всё ли у нас есть для старта будкоделательного предпринятия. Докупить софт моделирования (ишь ты, конкуренты начали публиковать тепловые характеристики своих будок!) в службу Проектирования обиталищ.
-- назначить Василия Петровича на все роли системных инженеров по этому проекту, он собак любит, и у него много друзей собачников (а во включении кинолога в команду разработчиков в качестве "голоса пользователя" -- отказать). И студента Колю поставить на все САПРы сразу, ему давно пора расти как инженеру. Не будет справляться -- терпеть, пока научится.
-- последовательное прокручивание цикла снятия ограничений (студент Коля зашился со своими САПРами, ему нужно срочно подмогу! Комплектующие приходят неправильные, от обратной логистики лихорадит всех -- срочно разобраться, почему у нас заказывают эту гадость!).
-- уговорить Дядю Петю потратить полдня на учёт интересов собаки при проектировании 3D, и уговорить Тётю Дусю всё-таки закупать метизы в фирме "Заваляшка", где ей грубят и хамят, но зато там не бывает задержек с поставками и грубых ошибок комплектации.
-- троих из сборочного кошачьих домиков, у которых аллергия к кошкам (вот идиоты! Кошек же на сборке этих домиков нет!) переучить на работу по сборке будок. Или даже лучше набрать новых, а тех троих уволить. Зачем нам люди с заморочками?