Human-system integration. Человеко-системная интеграция
Software-intensive systems уже стали общим местом: как только в системе появляется махонький компьютер, вся система ведет себя уже не просто как набор железяк, а как компьютер -- и разработка софта начинает занимать у такой системы все больше и больше времени от версии к версии.
Human-intensive systems являются пока в системной инженерии предметом много меньшего изучения. А ведь как только в системе появляется самый завалящий человечек (стейкхолдер, притязатель) вся система ведет себя уже не просто как компьютер, облаченный во множество железяк, но как (часто непредсказуемый) человек -- и в жизненном цикле системы работа с людьми и вокруг людей (изменение людей под систему -- "разработка людей", равно как и доработка системы под особенности и притязания людей) начинает занимать все больше и больше времени. Пока не замечено плотного общения между системными инженерами и специалистами в работе с людьми. Если software engineering и systems engineering уже по факту слились, то human systems engineering до сих пор стоит от них особнячком, и никакого слияния пока не наблюдается.
Человеко-системная интеграция -- это учет с самых ранних стадий жизненного цикла особенностей людей, проявляющихся при столкновении их с "механическими" сложными системами. Эти "механические системы" могут быть составлены из самих людей -- процессными организациями, например, предприятиями). Это тоже вполне "механические" структуры, несмотря на то, что людей в них прекратили называть "человеческим фактором" и сейчас называют "человеческий актор"). Метод "просто добавь людей" не работает, если речь идет о системе, в том числе и обеспечивающей системе (например, системе-предприятии). К тому же мало предусмотреть в системе дырки с резьбой для болтиков или комфортные места для людей. Так же, как болтики в железную систему нужно вкрутить, а не просто насыпать сверху, так и с людьми нужно что-то делать, чтобы они слились в симбиозе с какой-то полезной рукотворной системой (в том числе с системой-организацией), и чтобы этим людям от этого была радость, да и для системы не наступила печаль и деградация.
В системной инженерии людей чаще всего назвают stakeholder, что я пытаюсь переводить как "притязатель". Ибо у людей есть притязания на систему, даже если они и не ее владельцы. Притязатели могут быть разработчиками, собственниками, инвесторами, работниками, пользователями, бенефициарами, экологами и всеми остальными -- а суть системной инженерии в том, чтобы всех их удовлетворить. Далее ставится вопрос: как должна быть устроена деятельность системной инженерии, чтобы все эти притязатели становились счастливыми и спокойно спали по ночам?
1. Первый уровень рассмотрения -- найти обобщенное описание жизненного цикла, в котором учитывается множественность притязателей с самого начала и адресуется неуверенность всех них в успехе проекта. В этот же уровень рассмотрения входит вопрос приспосабливания этого общего описания ЖЦ для конкретного паттерна рисков конкретного проекта -- ибо организация каждого жизненного цикла уникальна и определяется наиболее вероятными проектными рисками. Результатом такого рассмотрения будет конкретный вариант управления жизненным циклом (набор процессов), который обеспечит слаженную работу всех стейкхолдеров.
Литературы о том, как организовать разработку системы так, чтобы все были счастливы -- навалом. Разных типовых нормативных описаний жизненных циклов -- огромное количество. Каскадное (водопадное) описание ЖЦ, спиральное описание ЖЦ, Rational Unified Model -- RUP, экстремальное программирование и SCRUM с их итерационным описанием процесса разработки, требованием непрерывной интеграции и раннего выпуска -- опробованных вариантов нормативных описаний ЖЦ для software-intensive systems десятки. Мне представляется, что на сегодняшний день наиболее продвинуто описание пошаговых обещаний (Incremental Commitment Model, ICM).
2. Второй уровень рассмотрения -- это как уболтать самых разных людей пользоваться этим описанием жизненного цикла в своей деятельности, научить их реализовывать свои притязания, используя весь арсенал методов и инфраструктуры системной инженерии. Как сделать так, чтобы каждый из притязателей на какую-то часть своей натуры стал системным инженером, чтобы иметь хоть что-то общее со своими коллегами по проекту -- ибо если ничего общего не будет, то воспроизведется ситуация Вавилонской башни, никто ни с кем не договорится, даже при всеобщей любви друг ко другу. Клятвы в любви будут говорить хором, но систему не сделают -- после чего придет лесник-собственник или инвестор и всех (не справившихся с договорками между собой милых людей) разгонит.
В принципе, это направление работы давно известно в менеджменте: "управление изменениями", "постановка бизнес-процессов", "управление знаниями" и т.д.
Я предлагаю все то же самое, но в чуть новой упаковке. Сейчас новое прорывается через стандартизацию (новые слова появляются вначале для обслуживания новой практики, а затем эти практики фиксируются в стандартах -- и только потом эти стандарты попадают в учебники). И управление изменениями, и постановка бизнес-процессов и управление знаниями имеют дело прежде всего с созданием (или нахождением подходящих) и затем применением в жизни стандартов. Поэтому я предлагаю обратить особое внимание на стандартизацию (выработку стандартов и их привнесение в жизнь) как на форму, в которой организация может изменять свои процессы.
Рреформирование (скажем, отраслевое реформирование) по типу реформы в РАО "ЕЭС России" обычно происходит путем обсуждения вопросов в рабочих группах по тем или иным аспектам реформы. Грамотно организованная микрореформа одного предприятия (в том числе реформа по переходу на нормы того или иного описания процессов жизненного цикла) наверняка будет проходить в той же форме -- заседания рабочих групп, разработка письменных документов, фиксирующих результаты договоренностей в этих рабочих группах, утверждение этих договоренностей начальством, выполнение договоренностей всеми участниками процесса.
Я предлагаю использовать культурную форму, в которой обычно существуют такие рабочие группы -- стандартизацию. Ибо речь тут идет не больше и не меньше, как о процессах стандартизации. Культура стандартизации требует групповой работы, консенсуса, заимствования внешних по отношению к сообществу практик, признания наличия конкурирующих стандартов, признания необходимости придерживаться традиции, признания неотрыва от практики, проверки экспериментом приемлемости решений стандарта перед его выпуском, обучения людей выполнению требований стандарта, оценку выполнения требований стандарта в жизни, непрерывное улучшение стандарта путем выпуска новых его версий, институализацию доверия к внешним структурам (fast track) и т.д. и т.п. Ровно это и нужно, когда организация пытается перейти к тому или иному варианту нормативного описания процессов системной инженерии.
По сути дела, я предлагаю человеко-системную интеграцию в случае организационной инженерии (т.е. разработки системы-организации) оформлять институционально как систему стандартизации, включая в эту систему и вопросы орг.развития, и исследования, и обучение и тренинг. Эту же систему стандартизации можно рассматривать как систему управления знаниями -- ведь стандарты организации и есть ее знания, знаковое воплощение ее лучших практик.
* * *
Это мы стремительно переходим от рассказа о том, как хороша и что из себя представляет системная инженерия к рассказу о том, как перейти к ней в условиях конкретной организации.
Human-intensive systems являются пока в системной инженерии предметом много меньшего изучения. А ведь как только в системе появляется самый завалящий человечек (стейкхолдер, притязатель) вся система ведет себя уже не просто как компьютер, облаченный во множество железяк, но как (часто непредсказуемый) человек -- и в жизненном цикле системы работа с людьми и вокруг людей (изменение людей под систему -- "разработка людей", равно как и доработка системы под особенности и притязания людей) начинает занимать все больше и больше времени. Пока не замечено плотного общения между системными инженерами и специалистами в работе с людьми. Если software engineering и systems engineering уже по факту слились, то human systems engineering до сих пор стоит от них особнячком, и никакого слияния пока не наблюдается.
Человеко-системная интеграция -- это учет с самых ранних стадий жизненного цикла особенностей людей, проявляющихся при столкновении их с "механическими" сложными системами. Эти "механические системы" могут быть составлены из самих людей -- процессными организациями, например, предприятиями). Это тоже вполне "механические" структуры, несмотря на то, что людей в них прекратили называть "человеческим фактором" и сейчас называют "человеческий актор"). Метод "просто добавь людей" не работает, если речь идет о системе, в том числе и обеспечивающей системе (например, системе-предприятии). К тому же мало предусмотреть в системе дырки с резьбой для болтиков или комфортные места для людей. Так же, как болтики в железную систему нужно вкрутить, а не просто насыпать сверху, так и с людьми нужно что-то делать, чтобы они слились в симбиозе с какой-то полезной рукотворной системой (в том числе с системой-организацией), и чтобы этим людям от этого была радость, да и для системы не наступила печаль и деградация.
В системной инженерии людей чаще всего назвают stakeholder, что я пытаюсь переводить как "притязатель". Ибо у людей есть притязания на систему, даже если они и не ее владельцы. Притязатели могут быть разработчиками, собственниками, инвесторами, работниками, пользователями, бенефициарами, экологами и всеми остальными -- а суть системной инженерии в том, чтобы всех их удовлетворить. Далее ставится вопрос: как должна быть устроена деятельность системной инженерии, чтобы все эти притязатели становились счастливыми и спокойно спали по ночам?
1. Первый уровень рассмотрения -- найти обобщенное описание жизненного цикла, в котором учитывается множественность притязателей с самого начала и адресуется неуверенность всех них в успехе проекта. В этот же уровень рассмотрения входит вопрос приспосабливания этого общего описания ЖЦ для конкретного паттерна рисков конкретного проекта -- ибо организация каждого жизненного цикла уникальна и определяется наиболее вероятными проектными рисками. Результатом такого рассмотрения будет конкретный вариант управления жизненным циклом (набор процессов), который обеспечит слаженную работу всех стейкхолдеров.
Литературы о том, как организовать разработку системы так, чтобы все были счастливы -- навалом. Разных типовых нормативных описаний жизненных циклов -- огромное количество. Каскадное (водопадное) описание ЖЦ, спиральное описание ЖЦ, Rational Unified Model -- RUP, экстремальное программирование и SCRUM с их итерационным описанием процесса разработки, требованием непрерывной интеграции и раннего выпуска -- опробованных вариантов нормативных описаний ЖЦ для software-intensive systems десятки. Мне представляется, что на сегодняшний день наиболее продвинуто описание пошаговых обещаний (Incremental Commitment Model, ICM).
2. Второй уровень рассмотрения -- это как уболтать самых разных людей пользоваться этим описанием жизненного цикла в своей деятельности, научить их реализовывать свои притязания, используя весь арсенал методов и инфраструктуры системной инженерии. Как сделать так, чтобы каждый из притязателей на какую-то часть своей натуры стал системным инженером, чтобы иметь хоть что-то общее со своими коллегами по проекту -- ибо если ничего общего не будет, то воспроизведется ситуация Вавилонской башни, никто ни с кем не договорится, даже при всеобщей любви друг ко другу. Клятвы в любви будут говорить хором, но систему не сделают -- после чего придет лесник-собственник или инвестор и всех (не справившихся с договорками между собой милых людей) разгонит.
В принципе, это направление работы давно известно в менеджменте: "управление изменениями", "постановка бизнес-процессов", "управление знаниями" и т.д.
Я предлагаю все то же самое, но в чуть новой упаковке. Сейчас новое прорывается через стандартизацию (новые слова появляются вначале для обслуживания новой практики, а затем эти практики фиксируются в стандартах -- и только потом эти стандарты попадают в учебники). И управление изменениями, и постановка бизнес-процессов и управление знаниями имеют дело прежде всего с созданием (или нахождением подходящих) и затем применением в жизни стандартов. Поэтому я предлагаю обратить особое внимание на стандартизацию (выработку стандартов и их привнесение в жизнь) как на форму, в которой организация может изменять свои процессы.
Рреформирование (скажем, отраслевое реформирование) по типу реформы в РАО "ЕЭС России" обычно происходит путем обсуждения вопросов в рабочих группах по тем или иным аспектам реформы. Грамотно организованная микрореформа одного предприятия (в том числе реформа по переходу на нормы того или иного описания процессов жизненного цикла) наверняка будет проходить в той же форме -- заседания рабочих групп, разработка письменных документов, фиксирующих результаты договоренностей в этих рабочих группах, утверждение этих договоренностей начальством, выполнение договоренностей всеми участниками процесса.
Я предлагаю использовать культурную форму, в которой обычно существуют такие рабочие группы -- стандартизацию. Ибо речь тут идет не больше и не меньше, как о процессах стандартизации. Культура стандартизации требует групповой работы, консенсуса, заимствования внешних по отношению к сообществу практик, признания наличия конкурирующих стандартов, признания необходимости придерживаться традиции, признания неотрыва от практики, проверки экспериментом приемлемости решений стандарта перед его выпуском, обучения людей выполнению требований стандарта, оценку выполнения требований стандарта в жизни, непрерывное улучшение стандарта путем выпуска новых его версий, институализацию доверия к внешним структурам (fast track) и т.д. и т.п. Ровно это и нужно, когда организация пытается перейти к тому или иному варианту нормативного описания процессов системной инженерии.
По сути дела, я предлагаю человеко-системную интеграцию в случае организационной инженерии (т.е. разработки системы-организации) оформлять институционально как систему стандартизации, включая в эту систему и вопросы орг.развития, и исследования, и обучение и тренинг. Эту же систему стандартизации можно рассматривать как систему управления знаниями -- ведь стандарты организации и есть ее знания, знаковое воплощение ее лучших практик.
* * *
Это мы стремительно переходим от рассказа о том, как хороша и что из себя представляет системная инженерия к рассказу о том, как перейти к ней в условиях конкретной организации.