Семь основных альф инженерного проекта ↑
metanymous в посте Metapractice (оригинал в ЖЖ)
Основы системной инженерии: альфы инженерного проекта
Основы (kernel из OMG Essence) включают в себя семь альф трёх дисциплин. Все эти альфы тесно связаны друг с другом, на диаграмме приведены лишь некоторые основные связи. Нужно чётко понимать, что представление инженерного проекта через эти основные альфы -- это существенное огрубление реальности. Но именно это огрубление реальности позволяет из "цветущей сложности" выделить главное, на чём нужно будет сосредоточить мышление -- какие-то детали при этом неизбежно потеряются, но ситуация "слона-то я и не заметил" будет встречаться реже. В каждом инженерном проекте минимально нужно отслеживать семь альф в трёх дисциплинах, меньше объектов внимания и дисциплин работы с ними иметь нельзя.
Это отслеживание и работа по изменению всех семи основных альф происходит в течение всего проекта. Когда в проекте происходит "пожар", люди работают по ночам и всё внимание уделяется провальной составляющей проекта, знание этого простого факта -- необходимости удержания во внимании всех семи альф на протяжении всего проекта -- позволяет уберечься от "глупых ошибок".
7 комментариев
сначала старые сначала новые
Стейкхолдеры
Никаких инженерных проектов не происходит, если нет их выполняющих людей. Инженерные проекты затрагиваются самыми разными людьми, и инженерные проекты затрагивают самых разных людей. Эти люди могут быть как "одиночками", так и организованными в группы, в том числе организованные в группы с известным им распределением полномочий (организации). Эти люди, группы и организациии, которые затрагивают проект, или которых затрагивает проект, называются стейхколдерами (stakeholders/заинтересованные стороны. Перевод "заинтересованные лица" не так хорош, ибо этот термин закреплён в законодательстве за юридическими лицами и при общении с менеджерами-юристами и экономистами возможна путаница).
Стейкхолдеры -- это "действующие лица" как в театре) проекта, а исполнители этих ролей -- конкретные люди и организации. Мы назовём это "театральной метафорой", при работе со стейкхолдерами всегда нужно помнить формулировку из театральной программки: "действующие лица и исполнители". Нельзя путать "архитектора" и "Василия Петровича" -- так же нельзя, как нельзя путать "принца Гамлета" и исполняющего его роль "Василия Петровича".
Стейкхолдеры условно делятся на "внешних" и "членов команды". Стейкхолдеры дают возможности (opportunity) для проведения инженерного проекта: если
проект никого не затрагивает (никому не нужен), то его попросту невозможно делать. Если команда может делать проект, но пользователям он не нужен, то такого проекта не будет -- разве что члены команды будут работать бесплатно, и будут исполнителями также и в других ролей (инвесторов, владельцев, пользователей, клиентов и т.д.).
Стейкхолдеры требуют согласовать с ними определение системы (прежде всего требования -- определение системы как "чёрного ящика", ибо как устроена система внутри интересует отнюдь не всех стейкхолдеров) и используют (стейкхолдеры-пользователи) воплощение системы, ради создания которого и затевается инженерный проект.
Простейший рабочий продукт, отражающий альфу "стейкхолдеры" -- это список стейкхолдеров. Из информационных систем со стейкхолдерами работают CRM (customet relationship management).
Специально нет никаких особых дисциплин, которые позволяют работать со стейкхолдерами, но можно выделить:
● Конфликтологию (например, метод "принципиальных переговоров" или "гарвардский метод" -- найдите в Сети литературу по этому вопросу), чтобы снимать противоречия между требованиями различных стейкхолдеров.
● Коммуникации (communications) для налаживания продуктивного диалога со стейкхолдерами
● Особые техники представления стейкхолдеров (например, "метод персонажа" из книжки Алана Купера "Психбольница в руках пациентов" --
http://rutracker.org/forum/viewtopic.php?t=1227489, который обобщается с пользователей на любых других стейкхолдеров --
http://praxos.ru/index.php/%D0%98%D0%B4%D0%B5%D0%B0%D0%BB%D1
%8C%D0%BD%D1%8B%D0%B9%D0%90%D0%BA%D1%86%D0%B8%D0%
BE%D0%BD%D0%B5%D1%80).
Никаких инженерных проектов не происходит, если нет их выполняющих людей. Инженерные проекты затрагиваются самыми разными людьми, и инженерные проекты затрагивают самых разных людей. Эти люди могут быть как "одиночками", так и организованными в группы, в том числе организованные в группы с известным им распределением полномочий (организации). Эти люди, группы и организациии, которые затрагивают проект, или которых затрагивает проект, называются стейхколдерами (stakeholders/заинтересованные стороны. Перевод "заинтересованные лица" не так хорош, ибо этот термин закреплён в законодательстве за юридическими лицами и при общении с менеджерами-юристами и экономистами возможна путаница).
Стейкхолдеры -- это "действующие лица" как в театре) проекта, а исполнители этих ролей -- конкретные люди и организации. Мы назовём это "театральной метафорой", при работе со стейкхолдерами всегда нужно помнить формулировку из театральной программки: "действующие лица и исполнители". Нельзя путать "архитектора" и "Василия Петровича" -- так же нельзя, как нельзя путать "принца Гамлета" и исполняющего его роль "Василия Петровича".
Стейкхолдеры условно делятся на "внешних" и "членов команды". Стейкхолдеры дают возможности (opportunity) для проведения инженерного проекта: если
проект никого не затрагивает (никому не нужен), то его попросту невозможно делать. Если команда может делать проект, но пользователям он не нужен, то такого проекта не будет -- разве что члены команды будут работать бесплатно, и будут исполнителями также и в других ролей (инвесторов, владельцев, пользователей, клиентов и т.д.).
Стейкхолдеры требуют согласовать с ними определение системы (прежде всего требования -- определение системы как "чёрного ящика", ибо как устроена система внутри интересует отнюдь не всех стейкхолдеров) и используют (стейкхолдеры-пользователи) воплощение системы, ради создания которого и затевается инженерный проект.
Простейший рабочий продукт, отражающий альфу "стейкхолдеры" -- это список стейкхолдеров. Из информационных систем со стейкхолдерами работают CRM (customet relationship management).
Специально нет никаких особых дисциплин, которые позволяют работать со стейкхолдерами, но можно выделить:
● Конфликтологию (например, метод "принципиальных переговоров" или "гарвардский метод" -- найдите в Сети литературу по этому вопросу), чтобы снимать противоречия между требованиями различных стейкхолдеров.
● Коммуникации (communications) для налаживания продуктивного диалога со стейкхолдерами
● Особые техники представления стейкхолдеров (например, "метод персонажа" из книжки Алана Купера "Психбольница в руках пациентов" --
http://rutracker.org/forum/viewtopic.php?t=1227489, который обобщается с пользователей на любых других стейкхолдеров --
http://praxos.ru/index.php/%D0%98%D0%B4%D0%B5%D0%B0%D0%BB%D1
%8C%D0%BD%D1%8B%D0%B9%D0%90%D0%BA%D1%86%D0%B8%D0%
BE%D0%BD%D0%B5%D1%80).
Возможности
Сам инженерный проект начинается с появления возможностей (opportunity) по его проведению -- это обстоятельства, которые делают возможным разработку (или доработку -- изменение уже имеющейся) системы. Наличие возможности существенно зависит от времени ("окно возможностей" -- период времени, в течение которого существует возможность выполнения проекта).
Возможности прежде всего характеризуют пользовательские потребности (пользовательские нужды, user needs -- то, что хотят пользователи такого, для
чего им поможет наличие воплощения системы), но они также отражают и наличие возможностей команды с развёрнутыми для этой команды технологиями и доступными финансовыми ресурсами в удовлетворении этих потребностей.
Именно возможности мотивируют стейкхолдеров заниматься инженерным проектом, именно возможности объединяют стейкхолдеров на цели выполнения инженерного проекта по созданию целевой системы.
Эти возможности описываются целым рядом возможных рабочих продуктов: "бизнес-планом", "концепцией", "интервью пользователей", "обоснованием
инвестиций" и т.д.. -- в этих рабочих продуктах обосновывается польза разным стейкхолдерам от выполнения инженерного проекта, ибо если нет обоснованных возможностей, то выполнение инженерный проекта не приносит пользы, а приносит вред (например, убытки для инженерной компании).
Из задействуемых для изменений в состоянии возможностей дисциплин нужно указать прежде всего:
● Маркетинг и продажи, стратегирование и предпринимательство -- для установления user needs);
● Управленческий (финансовый) учёт -- для обоснования прибыльности. Конечно, в возможностях важны не только нужды/потребности/ожидания пользователей (user needs), но и нужды/потребности/ожидания/ и остальных стейкхолдеров. Как вы помните, успешная система (точнее, воплощение системы) -- это та, которая реализует возможности, т.е. отвечает нуждам/потребностям/ожиданиям стейкхолдеров инженерного проекта.
Сам инженерный проект начинается с появления возможностей (opportunity) по его проведению -- это обстоятельства, которые делают возможным разработку (или доработку -- изменение уже имеющейся) системы. Наличие возможности существенно зависит от времени ("окно возможностей" -- период времени, в течение которого существует возможность выполнения проекта).
Возможности прежде всего характеризуют пользовательские потребности (пользовательские нужды, user needs -- то, что хотят пользователи такого, для
чего им поможет наличие воплощения системы), но они также отражают и наличие возможностей команды с развёрнутыми для этой команды технологиями и доступными финансовыми ресурсами в удовлетворении этих потребностей.
Именно возможности мотивируют стейкхолдеров заниматься инженерным проектом, именно возможности объединяют стейкхолдеров на цели выполнения инженерного проекта по созданию целевой системы.
Эти возможности описываются целым рядом возможных рабочих продуктов: "бизнес-планом", "концепцией", "интервью пользователей", "обоснованием
инвестиций" и т.д.. -- в этих рабочих продуктах обосновывается польза разным стейкхолдерам от выполнения инженерного проекта, ибо если нет обоснованных возможностей, то выполнение инженерный проекта не приносит пользы, а приносит вред (например, убытки для инженерной компании).
Из задействуемых для изменений в состоянии возможностей дисциплин нужно указать прежде всего:
● Маркетинг и продажи, стратегирование и предпринимательство -- для установления user needs);
● Управленческий (финансовый) учёт -- для обоснования прибыльности. Конечно, в возможностях важны не только нужды/потребности/ожидания пользователей (user needs), но и нужды/потребности/ожидания/ и остальных стейкхолдеров. Как вы помните, успешная система (точнее, воплощение системы) -- это та, которая реализует возможности, т.е. отвечает нуждам/потребностям/ожиданиям стейкхолдеров инженерного проекта.
Определение системы
Перед тем, как сделать любую систему, её нужно определить (define), ибо нельзя сделать то, что "неопределено" (задача "пойди туда, не знаю куда, найди то, не
знаю что" -- это больше ведь исследовательская задача, а не инженерная. Чтобы воплотить в нашем четырехмерном пространстве-времени какую-то систему,
нужно как минимум иметь представление об этой системе, "определить" её). Альфа "определение системы" (system definition) служит как раз для этой цели. У альфы определения системы (system definition) главные подальфы (части) прежде всего:
● Требования (описание назначения системы в её операционном окружении. Требования определяют систему как "чёрный ящик")
● Архитектура (набор ключевых инженерных решений/decisions по тому, как будет устроена система -- описание "прозрачного ящика". Изменение каждого из архитектурных решений на поздних стадиях проектирования ведёт к существенному перепроектированию всей системы).
● Неархитектурная часть проекта (все остальные решения/decisions, т.е. изменение которых на альтернативные не приводит к существенному перепроектированию всей системы)
С определением системы работает прежде всего наука: если какая-то часть системы (или аспект системы) определены, то это означает, что выбран
соответствующий метод описания. Наука -- это как раз про создание методов описания. Научное знание позволяет определять системы, описывать их в рабочих продуктах -- описаниях (descriptions). Но, конечно, определять и описывать системы можно и на основе эвристик, не прибегая к научному знанию.
Более того, переход от определения системы (идеального объекта) к описанию системы (материальному объекту) возможен с использованием нотационной инженерии -- т.е. для записи определения системы как "мыслей по поводу системы, свойств системы" можно создать инженерный артефакт: нотацию.
Итого: определение системы -- это про биты, про информацию, про то, как мы говорим о системе. Основные дисциплины работы над определением системы -- это проектирование и конструирование. Альфой определения системы занимается системный инженер.
Перед тем, как сделать любую систему, её нужно определить (define), ибо нельзя сделать то, что "неопределено" (задача "пойди туда, не знаю куда, найди то, не
знаю что" -- это больше ведь исследовательская задача, а не инженерная. Чтобы воплотить в нашем четырехмерном пространстве-времени какую-то систему,
нужно как минимум иметь представление об этой системе, "определить" её). Альфа "определение системы" (system definition) служит как раз для этой цели. У альфы определения системы (system definition) главные подальфы (части) прежде всего:
● Требования (описание назначения системы в её операционном окружении. Требования определяют систему как "чёрный ящик")
● Архитектура (набор ключевых инженерных решений/decisions по тому, как будет устроена система -- описание "прозрачного ящика". Изменение каждого из архитектурных решений на поздних стадиях проектирования ведёт к существенному перепроектированию всей системы).
● Неархитектурная часть проекта (все остальные решения/decisions, т.е. изменение которых на альтернативные не приводит к существенному перепроектированию всей системы)
С определением системы работает прежде всего наука: если какая-то часть системы (или аспект системы) определены, то это означает, что выбран
соответствующий метод описания. Наука -- это как раз про создание методов описания. Научное знание позволяет определять системы, описывать их в рабочих продуктах -- описаниях (descriptions). Но, конечно, определять и описывать системы можно и на основе эвристик, не прибегая к научному знанию.
Более того, переход от определения системы (идеального объекта) к описанию системы (материальному объекту) возможен с использованием нотационной инженерии -- т.е. для записи определения системы как "мыслей по поводу системы, свойств системы" можно создать инженерный артефакт: нотацию.
Итого: определение системы -- это про биты, про информацию, про то, как мы говорим о системе. Основные дисциплины работы над определением системы -- это проектирование и конструирование. Альфой определения системы занимается системный инженер.
Воплощение системы
Воплощение системы (system realization, буквально: вынос в реальность) -- это четырехмерное воплощение системы в нашем материалом мире, это про
организованные в пространстве-времени хитрым образом вещества и поля, атомы (а не биты!). Это не про информацию о системе, это сама система.
Конечно, воплощение системы будет называться везде по-разному:
● У конструкторов это чаще всего "изделие" или "продукт" (product)
● У проектантов это часто "установка" (plant)
● У проектантов очень крупных объектов (например, атомных станций) это "сложный инженерный объект"
Мы принимаем, что когда мы пишем название системы ("насос"), то мы имеем тут ввиду сам насос как он есть в реальном мире, а не описание насоса (рабочий продукт определения системы).
Пользователям прежде всего нужно воплощение системы, для получения воплощения системы и создаётся инженерный проект. Очень часто говорят об инженерном проекте по создании сервиса -- например, "сервис стрижки волос". Но это не должно смущать: на самом деле это не проект по созданию сервиса, а проект по созданию системы, оказывающей сервис, например, "парикмахерская", которая будет оказывать "сервис стрижки волос".
Воплощение системы в материальном мире есть и у программной системы: программа ведь не существует без носителя. Но в конкретном случае исполняемая программа в машинном коде, взятая в какой-то момент её существования подразумевает конкретное сочетание вещества и полей (магнитных доменов в флешках, заряженных ячеек в оперативной памяти, в регистрах процессора) -- каждому такту выполнения программы соответствует какое-то определённое состояние вещества, как и каждому такту работы какой-то другой "железной" системы. Конечно, при рассуждениях происходит абстрагирование от этой "физикализации" программы, но полезно помнить, что исходный код -- это рабочий продукт определения системы.
Одно определение системы обычно может пригодиться при создании тысяч и тысяч воплощений системы. Так и в случае софта: воплощение программной системы -- это исполняющаяся (иногда в тысячах и миллионах экземплярах) программа, а не исходный её код. Воплощение системы используется стейкхолдерами, оно реализует возможности.
Воплощение системы удовлетворяет определению системы. Основная дисциплина работы над воплощением системы -- это производство. Альфой воплощения системы занимается системный инженер.
Воплощение системы (system realization, буквально: вынос в реальность) -- это четырехмерное воплощение системы в нашем материалом мире, это про
организованные в пространстве-времени хитрым образом вещества и поля, атомы (а не биты!). Это не про информацию о системе, это сама система.
Конечно, воплощение системы будет называться везде по-разному:
● У конструкторов это чаще всего "изделие" или "продукт" (product)
● У проектантов это часто "установка" (plant)
● У проектантов очень крупных объектов (например, атомных станций) это "сложный инженерный объект"
Мы принимаем, что когда мы пишем название системы ("насос"), то мы имеем тут ввиду сам насос как он есть в реальном мире, а не описание насоса (рабочий продукт определения системы).
Пользователям прежде всего нужно воплощение системы, для получения воплощения системы и создаётся инженерный проект. Очень часто говорят об инженерном проекте по создании сервиса -- например, "сервис стрижки волос". Но это не должно смущать: на самом деле это не проект по созданию сервиса, а проект по созданию системы, оказывающей сервис, например, "парикмахерская", которая будет оказывать "сервис стрижки волос".
Воплощение системы в материальном мире есть и у программной системы: программа ведь не существует без носителя. Но в конкретном случае исполняемая программа в машинном коде, взятая в какой-то момент её существования подразумевает конкретное сочетание вещества и полей (магнитных доменов в флешках, заряженных ячеек в оперативной памяти, в регистрах процессора) -- каждому такту выполнения программы соответствует какое-то определённое состояние вещества, как и каждому такту работы какой-то другой "железной" системы. Конечно, при рассуждениях происходит абстрагирование от этой "физикализации" программы, но полезно помнить, что исходный код -- это рабочий продукт определения системы.
Одно определение системы обычно может пригодиться при создании тысяч и тысяч воплощений системы. Так и в случае софта: воплощение программной системы -- это исполняющаяся (иногда в тысячах и миллионах экземплярах) программа, а не исходный её код. Воплощение системы используется стейкхолдерами, оно реализует возможности.
Воплощение системы удовлетворяет определению системы. Основная дисциплина работы над воплощением системы -- это производство. Альфой воплощения системы занимается системный инженер.
Команда
Команда (team) инженерного проекта -- это не просто какие-то люди или организации (группы людей с оборудованием и известным распределением
полномочий). Это люди с совершенно определённым набором компетенций, нужных для реализации проекта, при этом речь идёт не только об инженерных, но и о менеджерских и других прикладных компетенциях.
Команда создаёт определение и воплощение системы, команда выполняет работы, команда применяет технологии (практики, поддержанные инструментами).
Команда должна работать как слаженный коллектив, для этого её нужно организовать из отдельных составляющих её людей. Для того, чтобы каждый
человек занял своё место на логистическом "конвейере" (ибо если какие-то места на этом "конвейере" не будут заполнены людьми, то целевая система просто не
сможет выпуститься -- необходимые на этом рабочем месте работы не будут произведены), нужно его "уговорить". Это функция "комиссара", пропагандиста, специалиста по менеджерской дисциплине "лидерство" (leadership). Лидер выполняет работы, которые можно описать двояко (помним, что это два разных описания одной и той же деятельности):
● Убалтывает исполнителей ролей команды играть в этой команде необходимые роли (убалтывает путать "личное" и "общественное").
● Осмысляет жизнь исполнителей ролей тем, что они приносят стейкхолдерам пользу, их жизнь и работа имеют значение для окружающих.
Команда (team) инженерного проекта -- это не просто какие-то люди или организации (группы людей с оборудованием и известным распределением
полномочий). Это люди с совершенно определённым набором компетенций, нужных для реализации проекта, при этом речь идёт не только об инженерных, но и о менеджерских и других прикладных компетенциях.
Команда создаёт определение и воплощение системы, команда выполняет работы, команда применяет технологии (практики, поддержанные инструментами).
Команда должна работать как слаженный коллектив, для этого её нужно организовать из отдельных составляющих её людей. Для того, чтобы каждый
человек занял своё место на логистическом "конвейере" (ибо если какие-то места на этом "конвейере" не будут заполнены людьми, то целевая система просто не
сможет выпуститься -- необходимые на этом рабочем месте работы не будут произведены), нужно его "уговорить". Это функция "комиссара", пропагандиста, специалиста по менеджерской дисциплине "лидерство" (leadership). Лидер выполняет работы, которые можно описать двояко (помним, что это два разных описания одной и той же деятельности):
● Убалтывает исполнителей ролей команды играть в этой команде необходимые роли (убалтывает путать "личное" и "общественное").
● Осмысляет жизнь исполнителей ролей тем, что они приносят стейкхолдерам пользу, их жизнь и работа имеют значение для окружающих.
Работы
Для того, чтобы инженерный проект был успешен, команде проекта нужно провести работы (works) -- и отслеживать состояние этих работ в ходе всего инженерного проекта. Конечно, содержание этих работ определяется каждым из членов команды проекта -- но есть особая работа по проведению работ (operations management), это работа операционного менеджера. Прежде всего, требуемые работы нужно:
● учитывать во всём их содержательном разнообразии, чтобы ответить на вопрос "что делать"
● Планировать (schedule), т.е. предлагать распределение этих работ во времени и приписывание этих работ исполнителям.
● Определять достаточность ресурсов и контролировать выполнение плана работ для понимания того, вовремя ли работы будут закончены (т.е. не закроется ли окно возможностей раньше того момента, когда эти возможности будут удовлетворены результатом проекта) С точки зрения операционного менеджера вся организация представляет собой набор рабочих мест/станций, на которых требуемые проектом различные ресурсы (люди, инструменты, расходные материалы) задействованы для выполнения содержательных работ, а также продукты работ движутся между этими рабочими
местами/станциями.
У того, кто занимается работой, мышление представляет проект как некоторую трубопроводную сеть, по которой текут (flow, но по-русски тут будет "идут", "проходят") работы, материалы, люди, информация так, что из "входного" информационного, человеческого, материального сырья получаются "выходные" воплощения системы -- а обратным ходом текут/идут/проходят вырученные за воплощения системы деньги. Это логистическое, операционное мышление.
Из дисциплин, которые работают над альфой "работа", можно указать:
● Операционный менеджмент (из Lingvo: operations management -- управление операциями [производством]. Управление производственным процессом фирмы, в отличие от стратегического менеджмента, управления персоналом и других составных частей управления организацией; исторически первое название этой деятельности production management было изменено на operations management, т.к. по сути "производство" существует практически во всех организациях, и в том числе в сфере услуг, страховании, банковском деле и т. д., а слово production ассоциируется лишь с материальным производством).
На английском языке общепринятое определение проще -- Operations Management is the process by which an organization converts inputs (e.g. labor, material, knowledge, equipment) into outputs (goods and services).
На русском языке наиболее часто используется до сих пор старая форма "управление производством" и много реже "управление операциями" или прямая калька "операционный менеджмент".
"Исследование операций" и даже "теория массового обслуживания" также довольно частый термины, хотя под ними чаще имеется ввиду использование специального математического аппарата для расчёта времени работы.
● управление цепочками поставок (supply chain management)
● управление проектами (project management), управление процессами (process management), ведение дел (case management)
● планирование и управление производством (planning and production management)
● логистика (logistics)
● операционная стратегия (operation strategy)
● управление сервисными операциями (management of service operations)
● улучшение производительности (performans improvement)
● планирование ресурсов предприятия (enterprise resource planning) и управление ресурсами (resource management)
● get things done (GTD) -- система персонального планирования, "как доводить дела до конца"
Вот один из видов рабочих продуктов, отражающих альфу "работы" (это простейший issue tracker):
Для того, чтобы инженерный проект был успешен, команде проекта нужно провести работы (works) -- и отслеживать состояние этих работ в ходе всего инженерного проекта. Конечно, содержание этих работ определяется каждым из членов команды проекта -- но есть особая работа по проведению работ (operations management), это работа операционного менеджера. Прежде всего, требуемые работы нужно:
● учитывать во всём их содержательном разнообразии, чтобы ответить на вопрос "что делать"
● Планировать (schedule), т.е. предлагать распределение этих работ во времени и приписывание этих работ исполнителям.
● Определять достаточность ресурсов и контролировать выполнение плана работ для понимания того, вовремя ли работы будут закончены (т.е. не закроется ли окно возможностей раньше того момента, когда эти возможности будут удовлетворены результатом проекта) С точки зрения операционного менеджера вся организация представляет собой набор рабочих мест/станций, на которых требуемые проектом различные ресурсы (люди, инструменты, расходные материалы) задействованы для выполнения содержательных работ, а также продукты работ движутся между этими рабочими
местами/станциями.
У того, кто занимается работой, мышление представляет проект как некоторую трубопроводную сеть, по которой текут (flow, но по-русски тут будет "идут", "проходят") работы, материалы, люди, информация так, что из "входного" информационного, человеческого, материального сырья получаются "выходные" воплощения системы -- а обратным ходом текут/идут/проходят вырученные за воплощения системы деньги. Это логистическое, операционное мышление.
Из дисциплин, которые работают над альфой "работа", можно указать:
● Операционный менеджмент (из Lingvo: operations management -- управление операциями [производством]. Управление производственным процессом фирмы, в отличие от стратегического менеджмента, управления персоналом и других составных частей управления организацией; исторически первое название этой деятельности production management было изменено на operations management, т.к. по сути "производство" существует практически во всех организациях, и в том числе в сфере услуг, страховании, банковском деле и т. д., а слово production ассоциируется лишь с материальным производством).
На английском языке общепринятое определение проще -- Operations Management is the process by which an organization converts inputs (e.g. labor, material, knowledge, equipment) into outputs (goods and services).
На русском языке наиболее часто используется до сих пор старая форма "управление производством" и много реже "управление операциями" или прямая калька "операционный менеджмент".
"Исследование операций" и даже "теория массового обслуживания" также довольно частый термины, хотя под ними чаще имеется ввиду использование специального математического аппарата для расчёта времени работы.
● управление цепочками поставок (supply chain management)
● управление проектами (project management), управление процессами (process management), ведение дел (case management)
● планирование и управление производством (planning and production management)
● логистика (logistics)
● операционная стратегия (operation strategy)
● управление сервисными операциями (management of service operations)
● улучшение производительности (performans improvement)
● планирование ресурсов предприятия (enterprise resource planning) и управление ресурсами (resource management)
● get things done (GTD) -- система персонального планирования, "как доводить дела до конца"
Вот один из видов рабочих продуктов, отражающих альфу "работы" (это простейший issue tracker):
*Технология
Дисциплина -- она в головах. Но в организации есть технология: поддержанный необходимыми рабочими продуктами и инструментами способ работы (way of working). Практика = дисциплина+технология (метод = полный набор дисциплин и технологий для выполнения какой-то работы).
Технология существенно зависит от состава выполняемых работ (технология пошива обуви не нужна при проектировании медицинской аппаратуры анализа крови, и наоборот), технология требуется для команды (компетенция проектирования в 2014 году не может быть реализована без компьютеров с установленными на них информационными системами САПР -- системами автоматизации проектирования, системами инженерных мультифизических расчётов, системами управления жизненным циклом PLM/product lifecycle management). Бессмысленно привлекать в команду человека и одновременно не
обеспечивать его технологией, и не давать фронта работ: все альфы предпринятия тесно зависят друг от друга. Если есть работа "копать траншею длиной 500 метров", то нужно озаботиться не только нужным количеством землекопов или экскаваторщиков, но и лопатами или экскаваторами. Этот пример также показывает, что для каждой работы могут быть использованы самые разные технологии, и тем самым выполнение инженерного проекта включает выбор (а иногда -- выбор, закупку и разворачивание) для его выполнения технологий.
Управление технологиями (каждая из которых имеет свои плюсы и минусы и требует для своего использования людей в команде с разными компетенциями) это отдельная дисциплина инженерного менеджмента. Удивительно, но люди часто не задумываются о тех технологиях, которые они используют. Что будет, если бригаде землекопов дать экскаватор?
*Они потратят целый день на то, чтобы отвинтить "лопату" от экскаватора, а потом попробуют организовать бригаду лопатодержателей, ибо одному человеку трудно будет управляться с такой большой лопатой! Ну, и затребуют пару сотен килограмм изоленты: обмотать неудобную ручку у этой огромной лопаты. А остальное (кабину, двигатель, систему тросов, гусеницы) выбросят: землекопы не знают, для чего все эти лишние детали, привинченные к лопате. Так что инструменты поддерживают те или иные дисциплины, а исполнители должны быть компетентны в использовани инструментов и дисциплинированы в своём мышлении.
Упражнение: Какие технологии используются в вашем проекте? Приведите три примера и для каждого дайте пару альтернативных технологий (например, 3D-моделирование с использованием Autodesk Inventor вместо 2D-моделирования в Autodesk AutoCAD или порождающего проектирования/generative design в специально написанном программном средстве).
Дисциплина -- она в головах. Но в организации есть технология: поддержанный необходимыми рабочими продуктами и инструментами способ работы (way of working). Практика = дисциплина+технология (метод = полный набор дисциплин и технологий для выполнения какой-то работы).
Технология существенно зависит от состава выполняемых работ (технология пошива обуви не нужна при проектировании медицинской аппаратуры анализа крови, и наоборот), технология требуется для команды (компетенция проектирования в 2014 году не может быть реализована без компьютеров с установленными на них информационными системами САПР -- системами автоматизации проектирования, системами инженерных мультифизических расчётов, системами управления жизненным циклом PLM/product lifecycle management). Бессмысленно привлекать в команду человека и одновременно не
обеспечивать его технологией, и не давать фронта работ: все альфы предпринятия тесно зависят друг от друга. Если есть работа "копать траншею длиной 500 метров", то нужно озаботиться не только нужным количеством землекопов или экскаваторщиков, но и лопатами или экскаваторами. Этот пример также показывает, что для каждой работы могут быть использованы самые разные технологии, и тем самым выполнение инженерного проекта включает выбор (а иногда -- выбор, закупку и разворачивание) для его выполнения технологий.
Управление технологиями (каждая из которых имеет свои плюсы и минусы и требует для своего использования людей в команде с разными компетенциями) это отдельная дисциплина инженерного менеджмента. Удивительно, но люди часто не задумываются о тех технологиях, которые они используют. Что будет, если бригаде землекопов дать экскаватор?
*Они потратят целый день на то, чтобы отвинтить "лопату" от экскаватора, а потом попробуют организовать бригаду лопатодержателей, ибо одному человеку трудно будет управляться с такой большой лопатой! Ну, и затребуют пару сотен килограмм изоленты: обмотать неудобную ручку у этой огромной лопаты. А остальное (кабину, двигатель, систему тросов, гусеницы) выбросят: землекопы не знают, для чего все эти лишние детали, привинченные к лопате. Так что инструменты поддерживают те или иные дисциплины, а исполнители должны быть компетентны в использовани инструментов и дисциплинированы в своём мышлении.
Упражнение: Какие технологии используются в вашем проекте? Приведите три примера и для каждого дайте пару альтернативных технологий (например, 3D-моделирование с использованием Autodesk Inventor вместо 2D-моделирования в Autodesk AutoCAD или порождающего проектирования/generative design в специально написанном программном средстве).