Но зачем нам нужны описания, если их нельзя использовать?! Они нам нужны для мышления, которое используется для переноса опыта из одного проекта по созданию систем в другие проекты.
Мышление происходит не для отдельных систем, а сразу для множеств систем. Разработка (замысливание, проектирование) всегда ведётся не для конкретных экземпляров систем, а «в общем случае», то есть для множества подобных систем.
Множество (как математический объект, другие имена для множества — это класс, тип, вид) абстрактно. В математике множество из одного объекта не эквивалентно этому одному объекту: свойства множества отличаются от свойств самого объекта в этом множестве.
В системном мышлении то же самое: нас интересуют отдельные конкретные системы, воплощённые в нашем физическом мире, но мыслим мы классами систем, их множествами. Мышление ухватывает что-то общее во всех ситуациях, мышление происходит не для конкретных систем, о которых мы знаем разные факты. Мышление происходит для классов/типов/множеств/видов систем/воплощений_систем/экземпляров_систем. И, конечно, множества легко изменять: для изменения абстрактных объектов не нужно тратить энергию на перетаскивание вещества воплощения системы, нужно тратить энергию только для изменения вещества для воплощения знаков, это неизмеримо меньшее количество.
Информационные технологии работают с описаниями, так что это первые кандидаты на ошибки. Вы сможете сообразить, что фотография человека — это не человек, на ней изображённый. Чуть трудней будет сообразить, что табличка с данными температуры ракетного двигателя на листочке бумаги — это описание ракетного двигателя, а сам листочек бумаги тут не важен. Но вот если речь идёт о небольшой базе данных, в которой описывается поведение ракетного двигателя в серии испытаний — вот тут наступает ступор, ибо сама база данных представляется какой-то системой. Нет, база данных тут — описание ракетного двигателя, просто в менее привычной форме, не на бумаге. Умение восстановить описываемый объект в физической реальности — это ключевое умение для всех, кто встречается со современными информационными технологиями.
Это не означает, что в какой-то момент нас не будет интересовать программная система как физический объект. Будет, как бумажная книга интересует типографа. Но мы не обсуждаем с типографом сюжет книги. Так и с администратором датацентра, который обеспечивает физическое существование компьютерной программы, мы не обсуждаем её «сюжет». Интересуйтесь не самой программой, интересуйтесь теми воплощениями системы, которые описывает программа, на изменения которых хотят влиять авторы программы. А потом уже судите о том, насколько авторам программы удалось реализовать их замысел. Если это софт покупок в магазине, то он описывает реальные физические продукты, находящиеся на складе в магазине и потенциально приезжающие к вам, приезжающие в физическом мире. Если это не так, то к программе появляются вопросы. Сама по себе программа не нужна, нужна она только для того, чтобы изменять физический мир при помощи заключённых в ней описаний. Не обольщайтесь физичностью происходящего в типографии, физичностью происходящего в датацентре. Удерживайте внимание на физичности того, что описывается носителями информации.
Для этого нужно обладать кругозором и прикладным мастерством. Если вы изготавливаете ERP-систему (enterprise resource planning, планирование ресурсов предприятия), то вы должны понимать: это всё самые разные описания потока ресурсов (ресурсы — это сырьё, полуфабрикаты разной степени обработки и сборки, конечная продукция, «застрявшие» в предприятии, которое что-то выпускает — всё это физические предметы, занимающие место в пространстве-времени). Вот ERP-система существует как информационная модель, современная «ручка-бумажка», отражающая состояние этого потока ресурсов. Её единственная цель — учёт этих ресурсов с целью максимизации прохода этих ресурсов по предприятию (ибо чем больше пройдёт через предприятие сырья и выйдет готовой продукции, тем больше будет встречный денежный поток). Если не брать в расчёт решений по физическому изменению потока ресурсов (заказ новых партий сырья, загрузки того или иного оборудования, задействования тех или иных складов, открузки по тем или иным контрактам), то ERP-программу со всеми её базами данных можно бы не делать, физический мир не изменился бы!
Фотография/проект/описание всегда чего-то, ERP-программа делает «фотографию» потока ресурсов предприятия как воплощения системы. Воплощение системы, которое нас интересует — это не воплощение самой ERP-системы как воплощение «фотографии». Оно, скорее всего, банально, как воплощение книги — все они более-менее похожи, пара сотен склеенных страниц с частицами краски на них. Разница только в содержании книг, так и со софтом — воплощения софта похожи, разница только в содержании софта, что отражает софт в физическом мире, что он описывает! Воплощение системы в случае ERP-софта — это поток ресурсов предприятия, физический объект. Если вы ничего не знаете про этот физический объект, то вы будете безуспешны, никакая системность мышления вам не поможет. Фотограф, который ничего не знает, как снимать во внешнем мире, но отлично обрабатывает фотокарточки — он не будет успешным фотографом. Системное мышление помогает мыслить тем, кто знает свою предметную область. А кто не знает свою предметную область, им уже ничего не поможет. Они будут описывать странное, реализовывать случайные изменения в физическом мире, или вообще не затрагивать физический мир своими фантазиями. Это не так плохо. Котята мало что меняют в физическом мире, но всегда накормлены и ухожены. Люди, если они не кусаются, тоже будут всегда накормлены, независимо от результата их работы.
Ищите воплощения системы, системное мышление — про физический мир, хотя и имеет дело с описаниями. Но описания ничто, а вот описанное ими — всё. Все описания делаются только ради того, чтобы менять описанное в физическом мире!
Источник: учебник А.Левенчука «Системное мышление 2020»