Системный инженер. Как начать карьеру в новом технологическом укладе - Вячеслав Мизгулин

Комфорт = <Температура воздуха, Влажность воздуха, Уровень автоматизации, Экономия>

Можно декомпозировать дальше:

Уровень автоматизации = <Включение и выключение эскалаторов, Автоматическая подача воды порциями и т.д.>

Когда мы знаем структуру, можно предложить различные математические критерии оценивания этого самого комфорта, например с помощью развесовки и суммирования. Каждый из субкритериев можно привести к нормализованному виду от 0 до 1, тогда задача оценки уровня комфорта не составит никакого труда. Но не будем углубляться в оценку – это предмет системного анализа, а не системной инженерии. Проблема в том, что поддержать тот или иной уровень комфорта система может только тогда, когда в неё входят приборы, взаимодействующие со средой, например, тот же кондиционер. Коробка с проводами сама по себе комфорт не обеспечивает – это не ее функция. Системный инженер должен обязательно обсудить с менеджерами такую проблему. Скорее всего, будет предложено не выходить за рамки идеи – коробки с проводами. Оборудовать здание кондиционерами, электроприборами и батареями – не совсем та задача, которую мы хотели решать сначала.

Рис. 4. Контекстная функциональная модель системы поддержки комфорта в бизнес-центре

Второй вариант функции системы (в сторону уменьшения задачи) – минимизация денежных расходов на ресурсы в бизнес-центре в реальном времени (рис. 5). Чем интересен этот вариант? Во-первых, в названии появились деньги. Мы говорим не о разных системах, которые регулируют разные ресурсы, а пересчитываем всё в деньги – тут просматривается системный эффект. Во-вторых, минимизация, как любая оптимизация, может решаться при заданных ограничениях, например, на тот самый уровень комфорта. Но для целевой системы не важно, что будет стоять за этими ограничениями. В-третьих, мы указали, что всё происходит в реальном времени, то есть целевая система не подводит итоги в конце квартала, чем мог бы заниматься рядовой специалист, а принимает и воплощает решения непосредственно в процессе потребления ресурсов. Такая формулировка уже наводит на мысль, что этим занимается компьютер, потому что, в противном случае, пришлось бы нанимать слишком много персонала и организовать их коммуникации с помощью, например, комплекта раций: один на электрощитке, а другой – у стояка и т. д. Обратите внимание, что, по сравнению с первой схемой, изменилось только название, но как принципиально это отразится на всей дальнейшей работе.

Рис. 5. Контекстная функциональная модель системы минимизации денежных расходов на ресурсы в бизнес-центре в реальном времени

Интуитивно может показаться, что сейчас самое время начать функциональную декомпозицию системы, чтобы понять, как она должна работать, но это не так. Я настоятельно рекомендую выполнить обратное действие – давайте представим функцию нашей системы в составе функциональной декомпозиции использующей системы, то есть той системы, которая использует целевую систему. Чтобы это сделать, надо понять – что есть использующая система? В русскоязычной литературе часто встречается термин «надсистема», но он мне не нравится, поскольку не задает «потолок» рассуждениям о границах. Мы будем говорить именно о той системе, которая использует целевую систему «умный бизнес-центр», то есть «коробочку с проводами», то есть «систему минимизации денежных расходов бизнес-центра в реальном времени». Судя по всему, использующая система и есть бизнес-центр, но какая у него функция?

Мы уже вели рассуждения о комфорте. Если немного переформулировать функцию, связанную с комфортом, получим неплохую формулировку для использующей системы – система поддержки комфортных условий для ведения бизнеса. Вполне логично, что для комфортного ведения бизнеса нужна близкая к комнатной температура, продуманное управление потоками людей, наличие санузлов, электричества и многое другое. Немаловажно – чтобы все это укладывалось в реалистичный бюджет. Было бы неплохо весь список этих условий включить в новый кортеж, характеризующий уровень комфорта. Он будет похож на предыдущий, но более полный, потому что мы теперь правильно определили системные уровни для поставленной задачи.

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

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

Итак, обратимся к использующей системе – бизнес-центру. Мы определили функцию использующей системы и можем выполнить функциональную декомпозицию следующим способом.

Определяем входные потоки:

– внешние условия, включая погоду, механические воздействия, городской шум и другое;

– ресурсы, приходящие к нам через инженерные коммуникации: вода, электричество, газ или еще что-то;

– запросы на сервисы – в любом бизнес-центре нужны санузлы, уборщицы или что-то более специфичное типа эскалаторов (сервис транспорта), центров печати.

Определяем выходные потоки:

– мы ожидаем, что здание обеспечит нам внутренний комфортный климат, огородив от внешней среды;

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

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

Рис. 6. Функциональная диаграмма использующей системы без целевой системы (как есть)

Далее нам надо понять, какие изменения претерпевают потоки, пока они доходят от входа к выходу, и как они влияют друг на друга внутри использующей системы. Это творческая задача, требующая хорошей технической подготовки. Каждый факт изменения потока мы фиксируем в виде той или иной функции, которую использующая система должна выполнять, чтобы реализовать свою главную функцию. Так и получается декомпозиция использующей системы.

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

Стейкхолдер (СХ1), то есть владелец бизнес-центра, хочет экономить. То есть хочет регулировать использование ресурсов так, чтобы ему это обходилось дешевле, а условия ведения бизнеса при этом держались на заданном уровне. Вставляем целевую систему в качестве новой функции и смотрим, что получилось (рис. 7). Будем целевую систему и потоки, связанные с ней, рисовать жирными линиями, чтобы смотрелось нагляднее. Введем идетификаторы для элементов: ПТ – потоки; ИС – использующая система; СОО – системы в операционном окружении; ЦС – целевая система, которую вы сейчас проектируете.

Рис. 7. Функциональная диаграмма использующей системы с целевой системой

Каждый поток, входящий или выходящий из использующей системы, может быть ассоциирован с потребностью.

Например, «ПТ3. Внешние условия» может быть ассоциирован с потребностью обеспечивать комфортные условия в условиях пустыни. «ПТ1. Запросы на сервисы» может быть ассоциирован с потребностью в определенном количестве людей, которых должен обслуживать центр. «ПТ2. Результаты сервисов» может быть связан с потребностями ускорения процессов, повышения качества. Условия среды в (ПТ6) сами по себе являются важной потребностью, ведь если мы просто будем экономить на всём, в бизнес-центре может стать, например, душно и жарко. Потоки (ПТ8) и (ПТ9), с одной стороны внешние, а с другой – относятся к целевой системе. Эти потоки могут быть связаны с потребностями сервисного обслуживания, то есть дополнительно – (СХ6) техобслуживание.