Рассмотрим подробно понятия «Воплощение системы» и «Определение системы».

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

Воплощение системы (system realization) — это реальный физический объект (он занимает место в пространстве-времени, например, «Эйфелева башня»), а Определение системы (system definition) – это информация о Воплощении системы (например, информация об «Эйфелевой башни», содержащаяся в её чертеже). Объекты, относящиеся к Определению системы легко отличить – они не имеют экстента (протяженности в пространстве-времени). Они абстрактны. Можно сказать, «идеальны» как противоположность материальному или физическому объекту. В чертеже «Эйфелевой башни» материален носитель информации (бумага), но не сама информация чертежа.

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

Начну с того, почему важна альфа «Определение системы». Этой альфой в современном системном подходе или системном подходе 2.0 обозначают множество описаний системы[i] для разных стейкхолдеров или такое же большое количество моделей системы. Конечно, людей намного больше интересуют «Воплощение системы» (4D-объекты), а описания системы их интересуют ровно постольку, поскольку без них Систему трудно сделать[ii]. Не забываем, что в системном подходе 2.0 мы работаем с многочисленными заинтересованными сторонами (стейкхолдерами), и важно учесть их интересы в ходе жизненного цикла Системы. Именно поэтому нам, в первую очередь, и необходимо работать с «Определением системы».

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

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

И вот тут необходимо различать следующее. В состав альфы «Определение системы» входят такие важные подальфы как «Требования», «Архитектура», и могут быть другие (например, «Неархитектурная часть проекта» и т.п.). С другой стороны, у разных стейкхолдеров существуют разные виды, аспекты или интересы к Системе. Мы обычно выделяем как минимум 3 самых важных — функциональное, модульное, размещение[iii]. Если эти интересы будут описаны в конкретных документах (а не просто существовать на словах или в головах), то мы можем говорить эти 3 описания являются рабочим продуктом альфы «Определение системы».

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

В этой связи, например, нельзя путать в работе, в обсуждении или в написании различных документов архитектуру, архитектурное описание и функциональную архитектуру. В первом случае речь идет об альфе, а во втором – о рабочем продукте, а в третьем – об альфе, но только в части определения функциональной архитектуры. Необходимо отметить, что внутри таблицы красным цветом выделены функциональные объекты (по своей природе – альфы), но им в жизни соответствуют рабочие продукты, которые могут «образовываться» из данных подподальф добавлением слова «описание»[iv].

Также надо понимать, что есть разные Требования к системе как к «черному ящику». Главные Требования – это функциональные требования, это требования, которые вытекают из Потребностей стейкхолдеров использующей системы. Но тут необходимо понимать, что, например, функциональные[v] и модульные требования могут быть записаны вперемешку в самых разных рабочих продуктах, например, разных частях документов «Спецификация требований», нескольких стандартах, документе «Технические условия».

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

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

Так, например, самое важное понимание состоит в том, что архитектурное функциональное описание Предпринятия – это сочетание всех поставленных Практик жизненного цикла целевой системы предприятия. А, например, требования к предприятию называются Стратегией[vi].

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

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

——
[i] Описание системы – это рабочий продукт, который реализует альфу «Определение системы». Тут имеется ввиду полное описание системы.

[ii] Тут небольшое отвлечение, которое обязательно помнить: результат работы проектировщика атомной электростанции, в конечном итоге, это Воплощение атомной электростанции, а не бумажная документация на её строительство или информационная модель. И это несмотря на то, что проектировщик сам не строит атомные электростанции, а только их описывает.

[iii] Не забываем, что описаний может быть намного больше. И это зависит от стейкхолдеров. Например, может быть финансовое описание.

[iv] Очень часто слово «описание» опускают. Из контекста должно быть понятно, о чем идет речь: об архитектуре (как подальфы альфы «Определение системы») или об архитектурном описании (рабочем продукте).

[v] Функциональные требования – это главные требования к системе, не говорят о «нефункциональных требованиях» (говорят о других требованиях, например, требования к качеству). Функциональные или системные требования – это (часть) «Определения системы» как «черного ящика».

[vi] Стратегия – это альфа «Определение системы», но уже для обеспечивающей системы. Стратегическое описание, например, документ «Текущая стратегия нашего предприятия» или «Бизнес-план», или «Как мы будем жить сегодня и завтра» — это уже рабочий продукт. Иногда даже говорят, что Стратегия – это не просто требование, а архитектурное требование, поскольку эти требования очень сильно влияют на архитектуру предприятия.
——

Автор – Церен Церенов, управляющий партнер Школы системного менеджмента

По материалам учебника А.Левенчука «Системное мышление» и по результатам общения со слушателями курса «Системный менеджмент и стратегирование».