Всего на сайте:
166 тыс. 848 статей

Главная | Финансы, Менеджмент

Жизненный цикл  Просмотрен 145

Лекция 4

Продолжим разговор о жизненном цикле. Жизненный цикл можно считать дополнением системы как двоицы (функция, конструкция) до троицы. Функция – это назначение, сервис, который система выдает во внешнюю среду. Система также может быть рассмотрена с точки зрения ее конструкции: из каких подсистем (как функций) состоит, каков ее механизм работы, как части взаимодействуют, чтобы система могла выдавать функцию – сервис. Наконец с третьей точки зрения (жизненного цикла) система меняется во времени, проходит длинный путь, от «рождения» до «смерти». Точнее, от замысла, поскольку она обычно начинает «жить» задолго до своего физического появления. Классический курс основ системной инженерии (foundational systems engineering) состоит в проходе по типовому жизненному циклу конкретной системы, однако мы идем другим путем. Наша задача – выработка общего системного мышления и понимания того, почему системный инженер способен построить не только небольшое изделие из нескольких частей, но и космический корабль, основываясь на одной и той же дисциплине – системной инженерии. Для этого нужно выяснить, какие концепты существуют в системной инженерии, каков механизм системного мышления – мышления в терминах систем, функций, холархий, жизненного цикла, практик, методов работы.

Ниже рассмотрим некоторые распространенные формализмы отображения жизненных циклов. Упрощенные средства описания жизненного цикла уже были использованы в предыдущей лекции, а именно – «нарезанная колбаса» и «вобла».

 

Далее рассматривается V-диаграмма (автор – Кевин Форсберг), «изогнутая колбаска». Это классическая нотация для изображения жизненного цикла.

Здесь показано, что приемка в эксплуатацию осуществляется в соответствии с требованиями, интеграция системы – в соответствии с архитектурным проектированием, изготовление – в соответствии с рабочим проектированием (это важная особенность использования буквы V – соответствующие пары оказываются на одном горизонтальном уровне). Левая часть буквы V – это system definition, правая – system realization, верхняя правая горизонтальная линия соответствует эксплуатации системы. Горизонтальная пунктирная линия разделяет верхнюю часть – область системных инженеров и нижнюю часть – область инженеров по специальностям. Такая диаграмма проста и наглядна, объясняет суть и взаимодействие стадий, но многого не содержит, поэтому может использоваться в различных модификациях, например:

 

Существуют еще много различных нотаций для аналогичной цели: T-диаграмма, «горбатая» диаграмма, диаграмма Гантта и т.д. Рассмотрим вторую из них, так как она имеет существенную особенность. Дело в том, что в современной системной инженерии важно учитывать не только стадии жизненного цикла, но и выполняемые на этих стадиях практики (часто называемые также «дисциплинами», иногда «бизнес-процессами» – не путать с «процессами» – worlkflow). Это двумерное отображение жизненного цикла, на котором по горизонтали задаётся время и соответствующие фазы (стадии), а по вертикали следуют графики трудозатрат для каждой из практик. Практики – это не периоды времени, а компетенции, т.е. «что мы потенциально умеем». А когда и в каком объеме это выполнять – определяется вдоль горизонтальной оси времени. Стадии (напомним – это периоды с cognitive framework) характеризуются своими нагрузками на практики. Такое изображение называется hump diagram («горбатая» диаграмма), поскольку на графиках имеются «горбы» – периоды интенсивной траты ресурсов на выполнение тех или иных видов работ. Диаграмма показывает сплошной поток работ, разбитый на практики. Горизонтальные полосы напоминают дорожки «для плавания», для одних и тех же людей, выполняющих конкретные виды работ, с разной интенсивностью, определяемой высотой «горба». Заметим, что в V-диаграмме практики тоже присутствуют, но неявно.

Первая дисциплина – Business Modelling, переводится как «моделирование деятельности» (ни в коем случае не «бизнеса»!). Если с помощью моделей разобраться, как устроена деятельность, то становится понятным, для чего нужна система. И поэтому можно сформировать (описать) требования – Requirements. Далее занимаются анализом и дизайном. Здесь «далее» – не по времени, а по диаграмме, поскольку время направлено по горизонтали, и все практики осуществляются параллельно, с разной интенсивностью. Как видно из диаграммы, вначале есть окружение, затем начинают работать проектные менеджеры, далее стартует моделирование и почти сразу, но чуть позднее, начинается работа над требованиями, еще позже – тестирование и анализ с дизайном. Следующими, почти сразу, начинаются фиксация конфигураций и управление изменениями (Change Management). Потом идет реализация – изготовление, и самое позднее – развертывание системы на местности. Развертывание – это не обязательно сама система. Оно может стартовать задолго до ее физического воплощения. Например, прежде чем начнется строительство объекта, нужно проложить дороги, подготовить специалистов, установить палатки для строителей и т.п. Видно, что Project Management работает в режиме скачков: «пожар» – нормально, «пожар» – нормально и т.д. Например, если кончились ресурсы (деньги) – их нужно интенсивно «добывать». Взаимодействие системы с Environment усиливается в начале каждой стадии, т.е. при появлении какого-то принципиально нового результата и переходе системы в следующее качество.

 

Следует отметить, что эта диаграмма изображает лишь часть жизненного цикла системы, до ее сдачи в эксплуатацию, хотя жизненный цикл на этом не заканчивается. Показаны только процессы разработки, потому что «горбатая диаграмма» – лучший способ описать именно разработку и ее практики на каждой стадии. Еще раз разграничим понятия «процессы» и «практики». Процессы – это то, что развертывается и происходит во времени. В то же время практики – это потенциальные возможности, которые не измеряются временем. Когда говорят о жизненном цикле в системной инженерии, то имеют в виду процессы.

 

Возвращаясь к V-диаграмме, заметим, что и на ней есть определенный намек на то, как разделены практики. Время и процессы на V-диаграмме тоже виртуально расположены в горизонтальном направлении, а практики –вертикально. Идеальное движение направлено по линии буквы V, то есть как по горизонтали, так и по вертикали. Однако в реалиях это движение не поступательно, оно похоже на муравейник, идет интенсивный обмен информацией вверх-вниз. Рассмотрим пример. Инженер по требованиям (специально подготовленный, умеющий общаться с людьми) находит всех стейкхолдеров, ведет переговоры, собирает требования и передает их системному архитектору. Тот должен предложить решение проблемы – принципы построения системы, удовлетворяющей требованиям. Например, рисует некую схему (архитектурное описание). Инженер по требованиям, видя эту схему, понимает, что появляются еще чьи-то интересы, какие-то дополнительные стейкхолдеры, с которыми нужно провести переговоры. Проведя их, он приносит новые требования. Архитектор должен предложить усовершенствованную архитектуру, учитывающую все текущие требования.

Если он это сделать не в состоянии (например, не хватает знаний о каких-то материалах, «рухнет здание или нет?»), обращается за консультацией ниже по V – в рабочее проектирование. В результате у архитектора появляется решение, которое он вновь передает инженеру по требованиям. Тот опять находит стейкхолдеров, чтобы скорректировать требования. Вообще корректировка требований и архитектуры – нормальный процесс, проходящий в жизненном цикле системы на нескольких стадиях (см. «горбатую» диаграмму). За результат этого процесса (учет всех стейкхолдеров, всех требований, согласование архитектурного решения со стейкхолдерами) ответственен системный инженер по требованиям. Архитектурный системный инженер ответственен за то, чтобы требования перевести в конструкцию, такую, чтобы архитектура системы выдавала функцию, удовлетворяющую сформированным требованиям. Еще раз подчеркнем, что все требования – функциональны, т.е. предъявляются извне к функции системы. Таким образом, диаграммы отражают некоторое обобщенное продвижение системы по жизненному циклу, а в реальности оно происходит значительно сложнее.

 

Следующая таблица показывает матрицу некоторого жизненного цикла. Она имеет важное значение для иллюстрации системного подхода и понимания сложности систем.

«Уровни воплощения» – это стадии жизненного цикла. Сначала были мысли, затем они перешли в требования. Когда люди поняли, что нужно сделать, появилась архитектура. На следующем шаге создали рабочий проект, показывающий, как это можно создать. Далее система собирается и, наконец, сдается в эксплуатацию. Жизненный цикл – это стадии, отвечающие за разные уровни воплощения системы. Однако системный инженер должен поддерживать целостность системы не только по уровням воплощения, но также и по уровням «вещества». Уровень «макро» – это сборка целой системы (например, самолета) из ее частей (фюзеляж, крыло и т.д.). Уровню «мезо» соответствуют отдельные модули, собираемые на заводе. «Микро» – это маленькие детали, микросхемы. На уровне «нано» речь идет о структуре самого вещества (например, композитные материалы, определяющие вес крыла). Уменьшив за счет вещества вес самого самолета, можно добавить посадочные места для пассажиров. Все это – решения системного инженера, его интересуют связки всех уровней. На каждом уровне есть системные инженеры, которые этими уровнями занимаются – в своей клетке матрицы. Например, есть требования к конкретному нано-материалу – покрытию; разрабатывается его архитектура, чтобы покрытие держалось, но было не очень толстым, потому что стоит дорого. Рабочий проект – это проектирование вещества, далее – изготовление и нанесение. Наконец наступает эксплуатация этого вещества в составе всей системы. Таким образом, в каждой клетке матрицы существует своя система. Возьмем, например, просто архитектурное описание, есть ли у него жизненный цикл? – Да, архитектурное описание можно рассматривать и создавать как систему, со стадиями в собственном жизненном цикле.

 

Эта матрица в реальности представляет собой не раздельные клетки, а «паутину» производственных цепочек. Ее клетки взаимодействуют друг с другом посредством множества различных связей. Она часто называется эко-системой, и системный инженер обязан обеспечивать ее целостность. Ему это удается, несмотря на сложность и различия имеющихся систем. Причина в том, что каждую из них (целую и части) он рассматривает с одной и той же позиции – системной инженерии (функция, конструкция, архитектура, жизненный цикл, обеспечивающая система и т.п.). О самолете, его крыле, фюзеляже или винтике он думает одинаково – как о системе. Поэтому гениальности, как раньше у генерального конструктора, ему не требуется. Он единообразно представляет себе мир, при этом любую предметную область переводит в одну и ту же систему понятий. Это в некотором роде «экономичное мышление», унифицированный подход.

Тема 4. Основной стандарт системной инженерии.

Капитальные проекты. Нотация сложного жизненного цикла. Стандартизация как методологическая и онтологическая работа. Краткая характеристика ISO 15288 (практики жизненного цикла системной инженерии). Четыре основные группы практик. Разграничение областей системного инженера и проектного менеджера. Жизненный цикл практик системной инженерии.

Далее наш курс будет усложняться, поскольку системная инженерия – это методология «борьбы» со сложностью мира. Соответственно изложить такой курс, ничего не сказав о сложности мира, невозможно. Системная инженерия как дисциплина противоречива, поскольку разные ее компоненты появлялись на разных стадиях ее же жизненного цикла. Некоторые из них более зрелые, некоторые – менее. Часть из них оформлена в каких-то нотациях, часть – нет. Некоторые нотации реализованы в программном обеспечении, некоторые – нет. Часть идей системной инженерии отображена в каких-то учебниках и примечаниях, а часть существует только в устных общениях 2-3 человек на планете. Конечно, со временем они распространятся. И все это работает одновременно. Здесь нет никакого управления конфигурацией (см. Лекцию 3), потому что это – система систем.

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

 

Западный консорциум FIATECH объединяет компании, работающие в сфере создания и эксплуатации сложных капиталоемких объектов, таких как нефтяные и газовые морские платформы, крупные заводы, энергоблоки электростанций. Это проекты, которые не могут обойтись без использования системной инженерии. Капитальный проект – большой проект, разрабатываемый с нуля. Ниже приводится диаграмма – учебная разработка FIATECH – его видение будущего жизненного цикла капитального проекта, его планирования, автоматизированного проектирования. Это не только жизненный цикл, но также и еще один способ его представления – сценарный (например, содержит блоки «что, если…»).

 

 

На диаграмме изображены стадии жизненного цикла, а также что и куда между этими стадиями передается. Здесь есть клиент, заказчик, нужды, пожелания. Далее (по времени) идут технические подходы, ориентировочный бюджет, график. За ними следуют целевой бюджет и график. Между стадиями передаются научные данные. Работают бизнес-сценарии – финансовые и стратегические. Предусмотрено даже обсуждение обстановки в мире, имеется обратная связь от опыта эксплуатации, ремонта. Представлена интеллектуальная автоматизированная строительная площадка, далее – интеллектуальный, самообслуживающийся, саморемонтирующийся объект. Имеется интегрированная и автоматизированная сеть закупок и поставок, что есть, в сущности, часть стадии изготовления – некоторые части вместо изготовления можно купить. К таковым относятся материалы, оборудование, труд (тоже закупается), инструменты, произведенные продукты и т.д. Это нотация сложного жизненного цикла, причем типовая. Системный инженер, задумывая подобный проект (например, атомную станцию), должен учитывать, что на его создание уйдет много времени (порядка 10 лет), поэтому он должен мыслить категориями будущего. За указанный период научно-технический прогресс может уйти далеко, а продавать готовую систему придется именно тогда. Для сравнения отметим, что, например, планшетных компьютеров 5 лет назад еще не было, HD телевизоры тоже появились не так давно, поэтому все предвидеть невозможно. Системный инженер – это тот, кто «бежит впереди паровоза».

 

В инженерии есть дисциплины (изучаются), а есть практики (выполняются). Практику невозможно идеально регламентировать правилами, иногда это – искусство. Однако, подобные правила есть. ISO – это International Organization for Standardization. Стандарт ISO 15288 посвящен практикам жизненного цикла. Он содержит описание того, что предписано практиковать в жизненном цикле. Сейчас, после знакомства с жизненным циклом, мы можем понять содержание этого стандарта. Ранее были рассмотрены аспекты деятельности системного инженера, проявляющейся в развертке жизненного цикла системы, теперь можно начать ее структурировать. Как определить, использует ли некоторое предприятие системную инженерию? Это делается на основе содержания ISO 15288. В нем примерно полторы страницы текста, и можно по пунктам рассмотреть, поддерживаются ли они в деятельности конкретного предприятия.

Системные инженеры критикуют этот стандарт за то, что в нем нет многих терминов методологии системной инженерии (например, инженерии требований). («Пришли менеджеры, убрали метод, оставили только действия»). Однако хорошо уже то, что специалистам удалось договориться хотя бы насчет действий. Важно, что это практики не только отдельного проекта, а системной инженерии в целом. Этот стандарт необходимо знать, поскольку он выражает суть того, чем занимается системный инженер. Представлены 25 обязательных практик, но неявно есть и 26-я – «практика адаптации» этого стандарта к конкретным условиям. В реальности все это практиковать трудно, поэтому рекомендуется начать хоть с чего-то, т.е. хоть как-то структурировать свою деятельность. Еще одна оговорка: эти практики сформулированы для «бумажной» системной инженерии, но не компьютерной. Конечно, все бумаги можно хранить и распечатывать на компьютере, но дальше здесь использование компьютера не требуется.

 

Итак, имеются 4 группы практик. Собственно классическая системная инженерия описывается 4-ой группой – «технические практики» (они связаны непосредственно с целевой системой), а все остальные группы связаны с обеспечивающей системой. Системный инженер является частью обеспечивающей системы, поэтому должен в первую очередь организовать собственную систему (наладить «свое производство», развернуть свою технологию), после чего заниматься целевой системой. Поэтому в стандарт намеренно помещена значительная часть практик об организации, которая ведет проект целевой системы.

 

Рассмотрим технические практики. Следуя стандарту, вначале нужно собрать требования. Далее – проанализировать, поскольку они могут быть разнообразными и противоречивыми. Для урегулирования (снятия) противоречий, как правило, необходимо провести переговоры, внести дополнения к требованиям. Архитектурный дизайн (слово «архитектурный» здесь не случайно) проводится на основе требований – формируются общие принципы построения системы в целом. Речь идет не о проектировании «деталей», а именно об архитектурном дизайне, чтобы потом, когда будут розданы поручения и изготовлены детали, они (детали) «сошлись» в рамках целой системы, и она удовлетворяла набору проанализированных требований. Далее, если есть архитектура, систему можно изготовить (по частям, возможно, что-то закупая). Здесь работают субподрядчики, контроль на уровни вглубь и т.п. Интеграция – это объединение частей в единое целое. Верификация – проверка на соответствие требованиям, т.е. фактически тому, что выявлено и спроектировано системным инженером. Если, например, требовалось создать колесо диаметром 200, то действительно ли оно такое? Переход к эксплуатации – это начало использования системы. Валидация – фактически приемка, то есть проверка на практике самих требований. Например, выяснилось, что согласно проекту есть колесо диаметром 200.

Значит ли это, что можно будет ехать со скоростью 180 км/час? – Нет, с таким колесом это невозможно! Изначально были пожелания клиента, по которым записаны (сформулированы) требования к системе. Эти записи проанализированы, (клиент им поверил) и начали реализовываться. Далее клиент получает систему и оказывается, что на этом автомобиле ездить невозможно, или его скорость не та, или из сиденья торчит шип – сидеть нельзя, но на нем держится вся конструкция. Валидация – это проверка работоспособности, с участием заказчика (или его представителей). Клиент при приемке дома проверяет, может ли он там жить. Все конкретные случаи «не могу жить» в требованиях предусмотреть невозможно. В них описаны лишь конкретные параметры (кол-во этажей, высота потолка и т.п.). Следует четко понимать разницу между верификацией и валидацией – это две разные практики. Далее идут эксплуатация, обслуживание, вывод из эксплуатации – они соответствуют стадиям типового жизненного цикла. Обслуживание – это интересная практика, поскольку при его выполнении эксплуатация системы не должна останавливаться. Модернизация системы, как правило, занимает несколько практик стандарта.

 

Технические практики – это основная работа системного инженера. Однако чтобы ее действительно можно было выполнять, для определения конкретных действий существуют проектные практики. Они относятся в основном к проектному менеджменту. На лекции 1 обсуждалось, как обучают системного менеджера (много дисциплин, много математики, 4D планирование строительства и т.п.). График, кадровый состав, организация команды сосредоточены в этих практиках – управление проектами, поддержка проектов. Интересная и важная практика – управление решениями. Кто принимает решения, тот несет ответственность за них. Все решения должны быть документированы, включая саму процедуру их принятия. Нельзя собраться в кружок и что-то решать. Нужно сначала договориться, как будет приниматься решение, затем – принять его в соответствии с определенной выше процедурой и задокументировать ее результаты. Это тоже системная инженерия («систематическая» инженерия). Здесь проявляется бюрократизм системного инженера.

 

Управление решениями отличается от инженерии решений. Аналогично управление требованиями – это их документирование, проверка синтаксиса, согласование с нужными людьми, каталогизирование и т.п – работа менеджера. Управление – и есть менеджмент. Инженерия требований – это создание требований к системе. Управление решениями – это реализация процедур. Инженерия решений – принятие решений относительно системы (например, какой должна быть турбина), это работа системного инженера. В инженерии решения, как правило, не принимаются голосованием. Есть процедуры и ответственное лицо, которое должно принять решение. (Информированное решение – «Я всех выслушал и решил»). Такое лицо не имеет права принять решение, не выслушав всех, однако может проигнорировать мнение большинства – такова одна из практик принятия решений. Таким образом, инженерные проекты реализуются не по демократическим процедурам. Еще один способ принятия решения – приписывание коэффициентов различным его вариантам, на основе свойств этих вариантов. Затем по коэффициентам выбирается оптимальное решение.

 

Следующая практика – управление рисками. Реальное управление рисками осуществляется применительно к техническим практикам, при их осуществлении. Однако требуется, чтобы риски выписывались (документировались) отдельно (в рамках бюрократии обеспечивающей системы), отдельно оценивались вероятности их наступления, отдельно создавались планы избегания или снижения рисков, или выделялись риски, которые можно принять не избегая. В этом состоит управление рисками, чем и занимаются системные инженеры. Это довольно полезная процедура, поскольку, если рисками занимаются специально, то больше шансов их выявить и снизить их влияние. Пример риска: планируется использование компьютеров или мониторов будущего. А затем окажется, что случился кризис или изменились приоритеты прогресса (стали выпускать мониторы не повышенного разрешения, а миниатюрных размеров). Как уже говорилось на лекции 1, при наступлении риска менеджер просит увеличить финансирование и сроки, а системный инженер – меняет архитектуру, дизайн, закупку, способ монтажа, даже меняет требования (т.е. выполняет технические практики – вот более точный ответ на вопрос о его действиях). Главное – он работает с целевой системой, а не обеспечивающей (как и говорилось ранее) и делает это в терминах технических практик.

 

Об управлении конфигурацией достаточно было сказано на прошлой лекции.

Суть управления информацией в краткой формулировке определяется так: вся информация 1) должна быть у людей, которым она нужна, причем 2) вовремя. Заметим, что здесь говорится лишь об управлении информацией, а не ее создании. Предполагается, что она уже есть, и ее нужно только предоставлять. Может оказаться, что системному инженеру не удается найти информацию, поскольку, например, ее слишком много и она неупорядочена. Во-вторых, нередко производственный процесс идет одним способом, а фиксирование информации – другим, то есть не синхронизированно, поскольку этому не придали должного значения («главное – производство, творческий процесс, а фиксирование – это бюрократия»). Если срочно потребуется информация, ее может не оказаться или она окажется труднодоступной (например, не в тех форматах). Еще одна ситуация: купили новую информационную систему, а сама информация осталась в устаревшей. Например, в некоторой графической системе графика чертежей сосредоточена в .dll файлах, а ее нужно извлечь в базу данных. Возникает одна из существенных проблем – интеграция данных. Если хранится «вся информация в электронном виде», это не означает, что ее можно легко интегрировать. Есть металлурги, электрики, атомщики и прочие, причем у каждой группы могут быть собственные стандарты форматов данных. Когда передается информация, то иногда надо еще передать тома описаний на тему, как ее можно прочитать.

Еще один пример: недостаточно кому-то передать реляционную базу данных (БД), поскольку для чтения из нее информации надо знать структуру таблиц и их связей (проблема «перекачки» данных из одной БД в другую). Управление информацией – одна из ключевых практик системной инженерии, она крайне необходима, без нее система создаваться не может. К основным задачам управления информацией добавляется еще необходимость ее защиты, соблюдения патентов, коммерческой тайны и т.п. Последнее еще более затрудняет процессы передачи информации.

 

Измерения – нужно измерять все – производительность труда, квалификации, объемы работ, стоимость и т.п. Этому учат проектных менеджеров, тоже как бюрократов.

 

Контрактации (закупки и поставки) необходимы для обеспечения процесса создания целевой системы.

 

Системные инженеры и проектные менеджеры работают с документами. Технические практики выполняют специально обученные люди – системные инженеры (они «создают», «порождают» целевую систему). Проектные практики реализуются частично инженерами, частично менеджерами – специально обученными аналитиками. Они немного «создают» (практика «планирование проекта»), а в основном – учитывают, анализируют, контролируют, критикуют. Однако проектные практики сами по себе не работают. Для этого нужны автоматизированные системы документооборота, шкафы, канцелярия и т.д. Соответственно нужна группа практик «Обеспечение проектов». К таковым относятся следующие практики.

 

Описывание жизненного цикла. Нужно описать, какой жизненный цикл будет осуществляться для целевой системы. Эта практика записана до проектного управления, поскольку проектный менеджер получает такое описание на входе. Как говорилось ранее, жизненные циклы бывают различных типов: последовательный, инкрементальный (история версий iPad), итеративный. Еще вариант организации цикла – делать несколько прототипов (макетов), и пока они не заработают, денег на собственно систему не будет. И здесь нужно, в том числе, принять решение, по какому виду цикла будет развиваться новая целевая система. Описание жизненного цикла должно быть известно всем исполнителям. Они должны быть психологически настроены на его реализацию, чтобы знать свое место в этом описании и чтобы осуществлялась их координация.

 

Управление инфраструктурой. Это в частности означает, что нужно приобрести и выдать инструменты, предоставить здания и сооружения, подключить их к ресурсам (вода, электричество), обеспечить финансирование. Другими словами, создать рабочие места.

 

Управление портфелем проектов – не то же самое, что управление отдельным проектом. Это в первую очередь решение о том, какие из проектов будут выполняться, а какие – нет. Это важное решение и часто осуществляется не только исходя из достоверных знаний (о стоимости, собственных ресурсах), но и интуиции. Например, нужны важные ресурсы, которые через год могут существенно подорожать, а цены уже зафиксированы в договоре. Решение о еще одном проекте существенно зависит от того, сколько и каких проектов уже взято для выполнения. Кроме этого решения, управление портфелем проектов – это распределение и перераспределение ресурсов между выполняемыми проектами.

 

Управление персоналом – должны быть люди, которые все выполняют. Ими нужно управлять, иначе в смысле системы ничего не будет создано.

 

Управление качеством – вещь достаточно «туманная». Конечно, качество должно быть, но управление им фактически проявляется в организации труда, производства, распределении обязанностей. Цель всего этого – получение качественного результата. Типичная ситуация: люди договорились, как они будут работать и нормально работают. Другие люди (ответственные за качество) пытаются их интервьюировать, записать, описать процесс диаграммами, схемами, пригласить аудиторов (иногда международных), чтобы получить сертификат качества. В последнее время также пытаются заставить работать по этим диаграммам и схемам. Но пока получение сертификата можно обеспечить подготовкой отчетности. По-видимому, такое управление дает не столько качество, сколько некий престиж обладания соответствующими сертификатами. Тем не менее, такие сертификаты порой необходимы, например, для участия в тендерах. Если что-то действительно придает качества процессам создания целевой системы, то это выполнение всех практик, о которых говорилось выше. Если они выполняются, то работает системная инженерия.

 

В заключение рассмотрим некоторый сущностный вопрос – есть ли жизненный цикл у самих практик? – Да, есть. Он изображен на рисунке ниже. Практики – это сервисы (их выполняет предприятие). Если есть сервисы, то есть и предоставляющая их система. В данном случае – это предприятие. Рассмотрим ступеньки по возрастанию. Новые практики применяются просто потому, что так было. С помощью них достигаются положительные результаты – это уже неплохо. Однако это лишь первый уровень (например, бегать, как умеешь, то есть интуитивно), ниже – это если результатов нет. Далее практики начали обсуждаться и как-то описываться. Люди сообразили, что практики есть, и они полезны – это второй уровень (обсуждение стиля бега с тренером). Если что-то не описано (не осознано – «не отрефлектировано»), то это трудно улучшать. Следующий уровень – когда практики описаны, и применяются по описанию (тренер дал советы, описал, как бежать, например, расслабленно).

Необходимо исполнять описания как правила (результаты бега повышаются). Это исполнение может быть контринтуитивным, но оно улучшает результаты. Третья ступенька коварна: улучшение результатов может оказать негативное влияние, поэтому не нужно «почивать на лаврах». Важно не остановиться на этом уровне. Практики со временем устаревают, появляются новые обстоятельства, техники, технологии. Поэтому необходим еще уровень – пересмотр и изменение, совершенствование практик. Все это – тоже жизненный цикл. Системный инженер все рассматривает как систему и в ее жизненном цикле.

Предыдущая статья:Понятие жизненного цикла Следующая статья:Практики определения системы – требования
page speed (0.0313 sec, direct)