?

Log in

No account? Create an account
Лабораторный журнал -- Day [entries|friends|calendar]
Anatoly Levenchuk

[ website | Лабораторный журнал ]
[ userinfo | livejournal userinfo ]
[ calendar | livejournal calendar ]

Human-system integration. Человеко-системная интеграция [23 Mar 2009|10:44am]
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) и т.д. и т.п. Ровно это и нужно, когда организация пытается перейти к тому или иному варианту нормативного описания процессов системной инженерии.

По сути дела, я предлагаю человеко-системную интеграцию в случае организационной инженерии (т.е. разработки системы-организации) оформлять институционально как систему стандартизации, включая в эту систему и вопросы орг.развития, и исследования, и обучение и тренинг. Эту же систему стандартизации можно рассматривать как систему управления знаниями -- ведь стандарты организации и есть ее знания, знаковое воплощение ее лучших практик.
* * *
Это мы стремительно переходим от рассказа о том, как хороша и что из себя представляет системная инженерия к рассказу о том, как перейти к ней в условиях конкретной организации.
11 comments|post comment

Этот длинный понедельник [23 Mar 2009|11:09pm]
Час проговорили с ответственным в INCOSE за организацию русского отделения INCOSE -- http://community.livejournal.com/incose_ru/586.html
* * *
Как СССР остался без системной инженерии, но приобрел системотехнику, или о роли редакторов в истории (http://www.tsisa.ru/schools/personnel/temnikov_f_e):
В 1961 г. при переводе монографии Г.Гуда и Р.Макола «System Engineering» [49] Ф.Е.Темников предложил термин «системотехника». Редакции издательства «Советское радио» (в последующем «Радио и связь») не нравился буквальный перевод «системная инженерия» или «инженерия систем», и Федор Евгеньевич предложил обобщающее понятие, имея в виду не системотехнику в точном смысле, а системотехнологию.

Термин «системотехника» в то время будоражил прогрессивный научный мир Москвы, вошел в историю становления системных исследований в нашей стране, хотя и претерпел некоторые изменения по сравнению с первоначальным смыслом.

Если бы термин «System Engineering» был принят редакцией «Советское радио» в более точном переводе «инженерия систем», «системная инженерия» или хотя бы «системотехнология», то, возможно, не потребовалось бы поиска новых терминов для прикладных направлений теории систем. Но поскольку в термине в явном виде звучала «техника», термин «системотехника» довольно быстро стал использоваться в основном в приложениях системных методов только к техническим направлениям.
Так оно и пошло дальше: книжка А.Холла "A Methodology for System Engineering" вышла в 1975г. под названием "Опыт методологии для системотехники" (http://www.tsisa.ru/history/1/2/).

Потом системотехника с потрохами ушла в АСУ, а затем и вообще заглохла вместе с окончанием эпохи широкомасштабного асучивания и асунизации.
* * *
В тексте ISO TR 24774 остался артефакт -- слово считать обрусевшим, а негативные коннотации (типа "артефакты изображения") пренебрежимыми. Всем комментировавшим большое спасибо.
* * *
Ровно год назад я писал про госкорпорации (http://ailev.livejournal.com/567853.html). И рад узнать, что тема не заглохла (http://www.novayagazeta.ru/data/2009/029/01.html). Хотя для сегодняшней политической ситуации это все вопросы не сущностные, а лишь оформительского мастерства. Ну типа как Госдуму парламентом назвать.
1 comment|post comment

navigation
[ viewing | March 23rd, 2009 ]
[ go | previous day|next day ]