Альфа описания системы ​

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

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

Для разных типов систем подальфы описания системы называются по-разному. Например, что для информационных и «железных» систем«архитектурные решения», для предприятия они жемогут называться «орг-архитектурные решения», а для спортивного события они будут называться «правилами».

Состояние альфы описания системы свидетельствуется документацией, описание ставится под управление конфигурацией (так, описано может быть несколько вариантов системы, только один из них может быть реализован).

Вот очень обобщённый пример набора состояний альфы описания для «железной» системы, для других видов систем (скажем, вы занимаетесь менеджментом, или политикой, или разведением редких видов жуков, или образованием) рекомендуется адаптировать эти состояния. Как обычно, мы нейтральный к размеру термин «организация проекта» заменяем привычным «команда проекта» или просто «команда», но это легко может быть и «проектная кооперация по поводу строительства атомной электростанции» с тысячами «команд» по самым разным цепочкам создания. Помним, что речь может идти не о создании всего описания для впервые создаваемого MVP системы, но об описании инкремента/модернизации или какой-то отдельной фичи системы (и, соответственно, имеется ввиду не полное описание, а тоже инкремент --- при этом лучше бы разу работать с подальфами, но альфа описания системы нужна, чтобы был пункт чеклиста, где вы задумаетесь, какие там вообще описания есть, какие нужны подальфы для отслеживания состояния отдельных частных описаний/views).

Описание системы (или её инкремента) может иметь состояния:

• Замыслено (concieved): внешние проектные роли и команда согласны, что система будет сделана; методы описания системы согласованы; способ согласования частных описаний с внешними проектными ролями согласован; механизмы управления конфигурацией документации согласованы.
• Непротиворечиво (coherent): частные описания системы документированы, и документация доступна команде и внешним проектным ролям; происхождение описаний ясно; описания проверяются; противоречивые описания выявлены и ими занимаются; команда понимает описания и соглашается их воплотить; соответствующая описаниям система ожидается как успешная (в ней учтены интересы внешних проектных ролей).
• Используется для изготовления (in use for manufacturing): изготавливающая систему часть команды считает, что описаний системы хватает для начала изготовления/производства; практики изготовления по этим описаниям системы сами описаны и документированы; возникающие при изготовлении системы проблемы приводят к доработке и актуализации описаний системы.
• Используется для инженерных обоснований воплощения (in usefor assurance): есть все описания, нужные для инженерного обоснования успешности системы (assurance case); испытания, критерии их успешности и способ проведения определены; внешние проектные роли согласны с объёмом испытаний.
• Используется для эксплуатации (in use for operations): описание системы используется для сбора информации о состоянии эксплуатируемого воплощения системы (цифровой двойник, digital twin); описание системы наряду с информацией цифрового двойника используется для принятия решений о техобслуживании, ремонтах, модернизации/развитии системы.
• Используется для вывода из эксплуатации (in use forretirement): используется для определения момента вывода из эксплуатации или принятии решения о продлении эксплуатации; демонстрирует отсутствие вредных эффектов (например, загрязнения окружающей среды) при выводе из эксплуатации; используется для планирования и проведения работ по уничтожению и/или переработке воплощения системы.

Приведённые выше состояния альфы описания целевой системы являются настолько общими, что для реального проекта должны быть обязательно конкретизированы --- и в части терминологии и самих состояний, принятых для описания системы, но также и в части подальф.

Вот как могла бы выглядеть альфа описания организации в цепочке создания. Описание организации (или её инкремента/оргизменения) может иметь состояния:

• Замыслено (concieved): команда развития согласна, что организация проекта будет создана; методы описания организации согласованы; способ согласования описаний с внешними проектными ролями оргразвития согласован; механизмы управления конфигурацией орг-документации согласованы.
• Непротиворечиво (coherent): описания организации документированы, и документация доступна команде развития и команде инженерии; происхождение описаний ясно; описания проверяются; противоречивые описания выявлены и ими занимаются; команда развития и команда инженерии целевой системы понимает описания и соглашается их воплотить; соответствующая описаниям организация принимается командой развития и как заслуживающая воплощения.
• Используется для лидерства (in use for leadership): организовывающая инженерную команду команда менеджеров развития считает, что описаний системы хватает для начала создания; практики создания организации по этим описаниям организации сами описаны и документированы; возникающие при организации инженерной команды проблемы приводят к доработке и актуализации описаний организации.
• Используется для работы (in use for operations): описание системы используется для сбора информации о состоянии организации (цифровой двойник, digital twin); описание организации наряду с информацией цифрового двойника используется для принятия решений о совершенствовании (непрерывных улучшениях) и развитии.
• Используется для роспуска организации (in use for adjuorn): используется для определения момента роспуска организации или принятии решения о продолжении работы; демонстрирует отсутствие вредных эффектов (например, выполнение каких-то сервисов, до сих пор нужных для внешних по отношению к организации проекта оргзвеньев предприятия) при роспуске организации; используется для планирования и проведения работ по роспуску или перепрофилированию.

Методология говорит о прохождении альфой описания системы (мы привели лишь пример альфы для целевой системы и для организации инженеров целевой системы, но систем много и в цепочках создания, и в окружении систем в цепочках создания) и её подальфами всех запланированных состояний в ходе проекта, и это описание нужно делать по каким-то методам описания/viewpoints, то есть использовать различные практики описаний с их дисциплинами и технологией/моделерами. Системное мышление говорит, что описание должно быть выполнено с учётом всех требований системного моделирования. Всё, что в курсе системного мышления было про описания и моделирование --- всё это важно для работы с альфой описания системы.

В целом в описании создателей особо можно выделить описание подальфы метода работы/way of working/метода создания и развития целевой системы. Конечно, для конкретного проекта их рекомендуется адаптировать (как минимум, переформулировать так, чтобы текст описаний этих состояний понимала вся команда и эти состояния отражали метод в целом или какие-то инкременты/модернизации метода. По большому счёту, содержание курса «Системная инженерия» --- это весьма обобщённое/абстрактное изложение метода создания и развития самых разных систем, курс «Системный менеджмент» --- это тоже довольно абстрактное изложение метода создания организационных систем, а наш курс «Методология» посвящён в том числе и методам описания методов. Так что моделирование метода работы путём определения альф, их состояний, контрольных вопросов, которые удостоверяют достижение состояний как прохождение контрольных событий/вех/milestones --- это и есть описание метода, и его можно рассматривать как подальфу описания организации.

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

Если несобранные сотрудники с рассеянным бессистемнымвниманием, которое не отслеживает важное, а отслеживает только знакомое по предыдущему «опыту работы» и придут в проекты,то они начнут приносить этому проекту несчастья.

Можно будет посочувствовать инвесторам: у проекта с такими внимательными к неважному и невнимательностью к важному сотрудникамибольшие риски, и мало кто будет понимать, почему всё так плохо, все ведь упорно работают! А плохо в проектах бывает главным образом из-за невнимания к важному, путанного внимания, то есть бессистемности, несобранности, непрактичности. Надо непросто много и упорно работать, но много и упорноработать над важными объектами, а не над теми, о которых случайно вспомнили. Основные альфы и их подальфы --- это и есть такие важные объекты, с них нельзя спускать глаз в ходе всего проекта, они будутпостоянно менять состояния, в том числе откатываясь по состояниям назад, менять эти состояния позже ожидаемого, и всёэто нужно отслеживать.