Skip to content

Как системное мышление помогает в рабочей деятельности

В предыдущих разделах мы рассмотрели основные идеи и приемы системного подхода. Теперь дадим общие объяснения того, как смотреть на любую коллективную деятельность с точки зрения системного мышления. То есть как нарезать мир на отдельные части и как их связывать между собой, чтобы в конечном итоге создать успешную целевую систему и не упустить из виду систему-создателя. Вам это поможет не только работать в команде, которая создает целевую систему или «нашу систему», но и взаимодействовать[1] с другими командами, которые создают надсистемы или системы в окружении, подсистемы или системы создания.

Начнем с краткого описания того, что вы уже изучили в прошлых разделах о системном подходе. Обратите особое внимание на вторую часть следующего описания, где речь пойдет о системе-создателе. Это продолжение описания сути системного подхода, начало которого было предложено в подразделе «Систематичность и системность», раздела 1, а потом уточнялось в подразделе «Области интересов» раздела 5.

Теперь пришло время дать более полное описание с учетом всех изученных системных понятий. Логическая последовательность рассуждений при этом не меняется. Начинаем с области интересов надсистемы, то есть смотрим на мир, который хотим как-то поменять. Потом переходим к целевой системе и её устройству. И далее обсуждаем систему-создателя, в том числе методы создания, роли и ресурсы.

Деятель[2] меняет мир к лучшему за счет создания успешной системы, которая прогнозируемо решит определенные проблемы (неудовлетворенности) какой-то группы людей (целевых аудиторий). Эти люди, как предполагает продвиженец, будут менять свое поведение, а потому важно понять их проектные роли и методы, в т.ч. инструменты. Успех системы зависит от удовлетворения интересов внешних проектных ролей[3], а для этого нужно предположить функцию работающей системы (роль целевой системы) в её окружении и учесть предметы интересов проектных ролей.

Для этого product owner[4] создает концепцию использования системы как «черного ящика». Это помогает разработчикам сделать концепцию системы, в которой описываются взаимодействие функциональных частей системы[5] и предлагается её конструкция. Она также увязывается с пространственной компоновкой и с оценкой полной стоимости владения системой[6]. Данные концепции также используются визионером для принятия решения о коммерческой эффективности выхода на рынок с данной целевой системой.

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

Архитектор, руководствуясь принципом непрерывности всего[9], старается организовать автономные команды систем создания для выпуска инкрементов системы для максимально несвязанных между собой модулей. Общая команда старается добиться детализации описания всех систем[10] с точностью, достаточной для изготовления целевой системы на выбранной производственной платформе, — и изготовить[11] её по предложенным технологами и DevOps методам. Далее происходит эксплуатация системы, снова и снова повторяя всё сделанное для улучшения каких-то частей системы[12], а то и для её полного изменения, или изменения подсистем, или для выпуска других целевых систем.

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

Мышление про систему-создателя устроено примерно так же — функциональные части в ней — это проектные роли (оргроли), которые выполняют самые разные работы по методам[13], а конструктивные части — оргзвенья. Сотрудники предприятия в разных проектных ролях выполняют работы по определенным методам (практикам), как бы находясь на производственном конвейере (с другими агентами, в т.ч. другими предприятиями, AI, оборудованием). Руководит же этой производственной деятельностью операционный менеджер[14]. А инициирует создание или организовывает конвейер – директор по развитию[15]. Он же может в процессе создания и/или непрерывного развития целевой системы запустить проект развития системы-создателя для того, чтобы перестроить текущую производственную платформу.

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

Возможно, что представленное описание[16] применения системного мышления вам не полностью понятно, но полная картинка будет складываться по мере прохождения основной программы AISYSTANT. Скорее всего, вам была хорошо понятна первая часть этого текста, и не совсем понятна вторая, где пошла речь о системе-создателе. Расшифровкой этой второй части мы займемся в этом разделе.


  1. Иногда и договаривать всех членов разных команд между собой, а не только самому с ними договориться. ↩︎

  2. В предпринимательских ролях он решает изменить мир, при этом может одновременно решить заработать деньги. И то, и другое лучше осознавать, ведь часто про деньги не забывают, а про физическое изменение мира не особо думают. ↩︎

  3. Которые будут играть люди из определенной группы (целевая аудитория). ↩︎

  4. Или продакт менеджер (как должность), хотя в российской культуре говорят про системных аналитиков. ↩︎

  5. Декомпозиция от функции работающей системы. ↩︎

  6. Полная стоимость владения учитывает время эксплуатации системы, которое описывается в концепции использования, а также время создания системы, то есть стоимостное описание системы как «прозрачного ящика». ↩︎

  7. Так называемые «–ilities/-ости», то есть такие архитектурные характеристики системы (предметы интересов), как доступность, непрерывность, производительность, возможность восстановления, надёжность и безопасность, устойчивость, масштабируемость, конфигурируемость, расширяемость, устанавливаемость, повторное использование, локализация, сопровождаемость, переносимость, поддерживаемость, возможность апгрейда. А еще архитекторы используют 4 ключевые метрики «непрерывности всего»: частота ввода в эксплуатацию; длительность прохождения изменений; процент сбоев для изменений; время восстановления обслуживания. ↩︎

  8. Архитекторы вынуждены выбирать наименее плохие решения, ибо хороших решений не будет, поскольку, согласно системному подходу 3.0 нельзя мечтать об устаканенности, наоборот, в мире сплошные неустроенности. Поэтому с более высокого или более низкого системного уровня обязательно придет какая-то проблема. ↩︎

  9. Про принцип непрерывности будет подробнее в подразделе «Инкремент и итерация». ↩︎

  10. Не забывайте, что в проекте описывается сразу несколько систем, а не только целевая. Некоторым командам будет еще необходимо изготовить подсистемы, а другим и системы создания. ↩︎

  11. Желательно изготовить MVP, а не сразу идеальную систему. ↩︎

  12. Инкрементальная разработка вместо итерационной. ↩︎

  13. В том числе методы описания разных систем, включая систему-создателя. Её тоже надо описывать. ↩︎

  14. Операционный менеджер – это экземпляр класса «менеджеры». Еще мы выделяем в этом классе менеджера по связям с окружением (public relations или government relations), который следит за удовлетворением интересов внешних проектных ролей, интересующихся деятельностью предприятия. Например, налоговые органы, экологи или представители общественности. А также выделяем администратора, который отвечает за административный конвейер, то есть работу таких служб как бухгалтерия, кадры и т.п. ↩︎

  15. Это может быть отдельная должность или человек на должности CIO может одновременно быть и директором по развитию. ↩︎

  16. То есть это некоторая призма, через которую удобно смотреть на любую деятельность. ↩︎