← Ко всем статьям
МышлениеДенис Михин · · 13 мин чтения

Системное мышление против линейной логики

Системное мышление против линейной логики

В управлении очень привлекательны простые объяснения.

Продажи падают — значит, плохо работает отдел продаж.

Проект задерживается — значит, плохо работает руководитель проекта.

Текучесть растёт — значит, HR недостаточно удерживает сотрудников.

Производительность снизилась — значит, люди стали работать хуже.

Руководители перегружены — значит, нужно нанять больше людей.

Клиенты недовольны — значит, сотрудники недостаточно клиентоориентированы.

В каждом таком объяснении есть понятная логика.

Есть проблема.

Есть предполагаемая причина.

Нужно воздействовать на причину — и проблема исчезнет.

Это и есть линейная модель мышления:

А вызывает B. Значит, чтобы изменить B, нужно изменить А.

Для простых ситуаций такая логика прекрасно работает.

Если в помещении темно, можно включить свет.

Если закончилась бумага, её нужно добавить.

Если сломалось оборудование, его можно отремонтировать.

Но организация — не набор независимых элементов.

Это система, в которой решения, люди, процессы, показатели, ресурсы, стимулы и ограничения постоянно влияют друг на друга.

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

Именно здесь начинается системное мышление.

Линейная логика ищет причину. Системная — механизм

Представим, что компания сталкивается с высокой текучестью сотрудников.

Линейная логика быстро создаёт объяснение:

сотрудники уходят из-за слабых руководителей.

Следующее решение кажется очевидным:

обучить руководителей.

Запускается программа развития.

Через несколько месяцев текучесть почти не меняется.

Можно сделать вывод:

обучение было слабым.

Но системный анализ способен показать совсем другую картину.

Компания быстро растёт.

Из-за этого постоянно не хватает сотрудников.

Руководители работают в недоукомплектованных командах.

Нагрузка на существующих людей увеличивается.

Из-за нагрузки растёт количество ошибок.

Руководители усиливают контроль.

Сотрудники получают меньше самостоятельности.

Удовлетворённость падает.

Люди начинают уходить.

После увольнений нагрузка на оставшихся становится ещё выше.

Возникает замкнутый цикл.

Теперь проблема выглядит иначе.

Слабое управленческое поведение может действительно присутствовать.

Но оно уже не является единственной причиной.

Оно является частью механизма.

Системное мышление поэтому задаёт не только вопрос:

«Что вызвало проблему?»

Оно спрашивает:

«Какая структура отношений снова и снова производит этот результат?»

В системе почти никогда нет одной причины

Руководителю хочется найти корневую причину.

Это естественно.

Одна причина создаёт ощущение управляемости.

Нашли — исправили — проблема исчезла.

Но в организационных системах результат часто возникает из сочетания факторов.

Допустим, проект постоянно задерживается.

Можно обнаружить:

неточная первоначальная оценка;

изменение требований;

перегруженные специалисты;

долгие согласования;

несколько параллельных проектов;

нестабильные приоритеты;

позднее обнаружение рисков.

Что из этого является настоящей причиной?

Возможно, неправильный вопрос.

Потому что каждый фактор усиливает остальные.

Перегрузка снижает качество оценки.

Ошибочная оценка создаёт давление.

Давление заставляет людей брать больше работы одновременно.

Параллельная работа увеличивает переключения.

Переключения создают задержки.

Задержки приводят к эскалациям.

После эскалаций приоритеты снова меняются.

Получается не цепочка.

Получается сеть.

Системное мышление работает именно с этой сетью взаимосвязей. В материалах по системному мышлению такой подход строится вокруг поиска структуры проблемы, закономерностей, ограничений и причин, которые находятся внутри устройства самой системы.

Линейное мышление особенно любит искать виноватого

Когда произошло отклонение, один из самых быстрых способов объяснить ситуацию — найти человека, который принял неправильное решение.

Менеджер плохо спланировал.

Сотрудник не проверил.

Руководитель поздно отреагировал.

Команда недостаточно контролировала.

Иногда персональная ответственность действительно существует.

Но здесь важно разделять два вопроса.

Первый:

кто совершил конкретную ошибку?

Второй:

почему система позволила этой ошибке привести именно к таким последствиям?

Представим, сотрудник неправильно внёс данные, из-за чего клиент получил ошибочный расчёт.

Линейная реакция:

сотрудник невнимателен.

Провести разговор.

Усилить контроль.

Но системный взгляд продолжает анализ.

Почему критически важный расчёт зависит от одного ручного действия?

Почему система не проверяет аномалию?

Почему ошибка обнаруживается клиентом, а не внутри процесса?

Почему сотрудник одновременно выполняет несколько операций?

Почему интерфейс позволяет выбрать неправильный параметр?

После этого одна человеческая ошибка превращается в источник информации о конструкции процесса.

Это не отменяет ответственности человека.

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

Событие и закономерность — разные уровни анализа

Линейная логика хорошо работает с событиями.

Клиент пожаловался.

Сотрудник уволился.

Проект задержался.

Показатель снизился.

Но отдельное событие содержит мало информации о системе.

Значительно интереснее посмотреть на повторяемость.

Клиенты регулярно жалуются на одном этапе.

Сотрудники чаще уходят после шестого месяца.

Проекты системно задерживаются при переходе между двумя функциями.

Показатель падает каждый раз после увеличения объёма.

Теперь появляется закономерность.

А за закономерностью можно искать структуру.

Почему именно здесь?

Что повторяется?

Какие условия остаются неизменными?

Какие решения создают этот эффект?

Именно поэтому системный руководитель старается подняться от события к паттерну, а затем — к механизму.

Причина может находиться далеко от места, где появилась проблема

Это одна из самых сложных особенностей систем.

Если отдел продаж не выполняет план, естественно искать проблему внутри отдела продаж.

Но причина может находиться значительно раньше.

Маркетинг изменил структуру лидов.

Продукт изменил ценовую модель.

Финансы ужесточили условия оплаты.

ИТ внедрило новую CRM, увеличив время обработки сделки.

Компания одновременно изменила систему мотивации.

Каждое решение отдельно могло быть рациональным.

Но совокупный эффект проявился в показателях продаж.

Линейная логика ищет проблему там, где виден симптом.

Системная логика ищет её там, где формируется поведение системы.

Это принципиально разные подходы.

Причина может находиться и значительно раньше во времени

Есть ещё одна проблема — задержка между действием и последствием.

Сегодня компания сокращает обучение.

Через месяц ничего страшного не происходит.

Через полгода начинает снижаться качество работы новых сотрудников.

Через год увеличивается количество ошибок.

Руководство видит ошибки и усиливает контроль.

Но решение, создавшее часть проблемы, было принято значительно раньше.

Или компания резко увеличивает продажи.

Первые месяцы результат выглядит прекрасно.

Затем операционные подразделения начинают перегружаться.

Снижается качество.

Растёт количество претензий.

Появляется текучесть.

Через некоторое время продажи начинают страдать уже из-за репутационных проблем.

Первоначально положительное решение через цепочку взаимосвязей создало отрицательное последствие.

Если анализировать только текущий момент, связь легко потерять.

Системы содержат обратные связи

Линейная логика представляет мир примерно так:

решение → результат.

Но в реальной организации результат часто возвращается назад и начинает влиять на первоначальную причину.

Например:

растёт нагрузка;

увеличивается количество ошибок;

руководитель усиливает контроль;

решения принимаются медленнее;

работа накапливается;

нагрузка растёт ещё сильнее.

Получается усиливающий цикл.

Или другая ситуация:

увеличивается спрос;

компания повышает производство;

запасы растут;

рынок насыщается;

спрос начинает снижаться;

производство сокращается.

Здесь работает балансирующий механизм.

Обратные связи объясняют, почему воздействие на систему не всегда приводит к пропорциональному результату.

Иногда небольшое изменение запускает большой эффект.

Иногда огромное управленческое усилие почти ничего не меняет.

Хорошее решение может создать плохой результат

Это особенно неудобная мысль.

Мы привыкли оценивать решения по намерению.

Если решение разумное, результат должен быть хорошим.

Но в системе всё зависит от контекста.

Допустим, руководитель хочет повысить скорость работы.

Он вводит жёсткие показатели производительности.

Люди начинают работать быстрее.

Показатель растёт.

Решение выглядит успешным.

Но одновременно сотрудники начинают меньше времени тратить на проверку качества.

Количество ошибок увеличивается.

Появляется повторная работа.

Через несколько месяцев общая производительность системы снижается.

Руководитель реагирует новым усилением контроля.

Количество проверок растёт.

Процесс становится ещё медленнее.

Первоначальное решение было логичным.

Но оно воздействовало только на одну часть системы.

Не учитывая ответную реакцию остальных элементов.

Система сопротивляется изменениям не потому, что люди обязательно против

Фраза «сопротивление изменениям» часто сразу направляет внимание на сотрудников.

Люди боятся нового.

Не хотят выходить из зоны комфорта.

Не понимают ценность.

Но сопротивляться может сама архитектура организации.

Например, компания хочет кросс-функциональные команды.

При этом бюджет остаётся функциональным.

KPI — функциональными.

Карьера — функциональной.

Ресурсами управляют функциональные директора.

Приоритеты тоже определяются внутри функций.

На уровне коммуникации организация говорит:

«Работайте как единая команда».

На уровне системы:

«Защищайте интересы своей функции».

Что окажется сильнее?

Скорее всего, система.

Люди адаптируются не к презентации о трансформации.

Они адаптируются к реальным правилам распределения власти, ресурсов, ответственности и вознаграждения.

Локальная оптимизация может ухудшать общий результат

Это один из важнейших переходов от линейного к системному мышлению.

Представим процесс из трёх этапов.

Первый способен обрабатывать 100 единиц работы в день.

Второй — 50.

Третий — 90.

Руководитель первого участка увеличивает производительность до 130.

Его локальный KPI улучшается.

Но система в целом продолжает выдавать примерно 50.

Более того, перед вторым этапом начинает накапливаться очередь.

Увеличивается незавершённая работа.

Появляются дополнительные расходы.

Локальное улучшение ухудшило состояние всей системы.

То же происходит в организациях.

Закупки минимизируют стоимость и увеличивают срок поставки.

Финансы минимизируют риск и замедляют решения.

Продажи максимизируют объём сделок, часть которых операционно невыгодна.

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

Каждая функция может выполнять собственный KPI.

Компания в целом — терять результат.

Системное мышление меняет сам вопрос руководителя

Линейный подход спрашивает:

«Как исправить проблему?»

Системный добавляет:

«Что произойдёт после того, как мы её исправим именно таким способом?»

Допустим, есть очередь.

Простое решение — добавить людей.

Но дальше возникают вопросы.

Почему очередь появилась?

Она постоянная или временная?

Где настоящее ограничение?

Если добавить ресурс здесь, не переместится ли очередь на следующий этап?

Не увеличит ли дополнительная мощность объём незавершённой работы?

Есть ли вообще спрос на дополнительный результат?

Таким образом, решение перестаёт оцениваться только по его прямому эффекту.

Нужно учитывать вторичные последствия.

Нужно искать не просто причину, а точку воздействия

Системное мышление иногда ошибочно воспринимают как необходимость бесконечно анализировать сложность.

Если всё связано со всем, значит, невозможно ничего решить.

На самом деле цель обратная.

Понять систему достаточно хорошо, чтобы найти место, где относительно небольшое изменение способно заметно изменить результат.

Например, компания может месяцами пытаться ускорять команды.

Но если основное ограничение — решение, которое принимает один комитет раз в две недели, повышение производительности команд почти ничего не изменит.

Нужно воздействовать на контур принятия решений.

Или организация пытается улучшить качество найма.

Меняет рекрутеров.

Добавляет инструменты оценки.

Переписывает вакансии.

Но выясняется, что основной источник проблемы — руководители по три недели дают обратную связь по кандидатам.

Тогда точка воздействия находится не в подборе.

Она находится в управленческом процессе.

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

Иногда очевидное решение усиливает проблему

Представим перегруженное подразделение.

Логичное решение:

нанять людей.

Новые сотрудники приходят.

Но их необходимо обучать.

Опытные специалисты начинают тратить время на адаптацию новичков.

Их производительность временно снижается.

Очередь растёт.

Руководитель видит ухудшение и решает нанять ещё больше людей.

Теперь обучение требует ещё больше времени.

Получается парадокс:

попытка увеличить мощность системы временно уменьшает её.

Это не означает, что нанимать не нужно.

Это означает, что решение необходимо оценивать с учётом динамики системы.

Как быстро люди выйдут на производительность?

Кто будет их обучать?

Есть ли у системы пропускная способность для адаптации?

Когда появится эффект?

Что произойдёт до этого момента?

Управлять системой — значит видеть ограничения

Организация может содержать сотни процессов и тысячи сотрудников.

Но её результат в конкретный момент часто ограничивает небольшое количество факторов.

Дефицитный специалист.

Пропускная способность оборудования.

Скорость принятия решения.

Недостаток спроса.

Ограничение бюджета.

Качество данных.

Слабый управленческий уровень.

Системное мышление требует искать именно такие ограничения.

Потому что улучшение любого другого участка может почти не изменить итоговый результат.

Это особенно важно на уровне портфеля проектов.

Можно улучшать методологии.

Обучать руководителей проектов.

Добавлять отчётность.

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

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

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

Допустим, компания сокращает затраты на 10%.

Первый порядок последствий очевиден:

расходы уменьшаются.

Но что произойдёт дальше?

Какие позиции будут сокращены?

Какие процессы станут медленнее?

Увеличится ли нагрузка?

Какие компетенции потеряет организация?

Не придётся ли через год покупать ту же работу у подрядчиков дороже?

Как решение повлияет на качество?

Какие инвестиции будут остановлены?

Возможно, сокращение полностью оправданно.

Но системное мышление требует видеть не только первый эффект.

Потому что сильное управленческое решение — это не решение без отрицательных последствий.

Таких решений часто просто не существует.

Сильное решение — это решение, где последствия достаточно хорошо поняты и сознательно приняты.

Системный руководитель осторожнее относится к быстрым выводам

Когда происходит проблема, особенно хочется действовать.

Это естественная управленческая реакция.

Но скорость действия и скорость понимания — не одно и то же.

Иногда дополнительный контроль помогает.

Иногда он уничтожает самостоятельность.

Иногда новые сотрудники решают проблему.

Иногда увеличивают координационную нагрузку.

Иногда новый KPI фокусирует организацию.

Иногда создаёт локальную оптимизацию.

Иногда централизация ускоряет решения.

Иногда превращает руководителя в узкое место.

Поэтому системное мышление не предлагает отказаться от этих инструментов.

Оно предлагает перестать считать их универсальными.

Один и тот же инструмент в разных системах способен дать противоположный результат.

Это не отказ от простоты

Системное мышление не означает, что каждое решение должно сопровождаться огромной схемой из сотни элементов.

Хороший системный анализ, наоборот, часто приводит к достаточно простому объяснению.

Но эта простота появляется после понимания сложности, а не вместо неё.

Например:

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

Это простое объяснение.

Но чтобы его увидеть, пришлось подняться выше отдельных проектов и посмотреть на весь портфель.

Или:

руководители не делегируют не потому, что не доверяют людям, а потому что система ответственности наказывает их за результат, не передавая подчинённым достаточных полномочий.

Снова достаточно простая формулировка.

Но она описывает механизм, а не симптом.

Системное мышление меняет роль руководителя

В линейной модели руководитель постоянно исправляет отклонения.

Возникла проблема — вмешался.

Появилась следующая — решил.

Ещё одна — снова подключился.

Чем больше проблем способен лично решить руководитель, тем сильнее он кажется.

Системный подход постепенно меняет эту роль.

Руководитель начинает замечать повторяемость.

Почему этот тип проблем вообще возникает?

Какие условия его создают?

Какое ограничение находится глубже?

Как изменение одного элемента повлияет на остальные?

Можно ли изменить архитектуру так, чтобы проблема перестала воспроизводиться?

Это переход от управления событиями к проектированию системы.

Самая дорогая ошибка — решить не ту проблему

Организации способны очень профессионально реализовывать неправильные решения.

Создать проект.

Выделить бюджет.

Назначить сильную команду.

Установить KPI.

Провести трансформацию.

Автоматизировать процесс.

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

Именно поэтому качество управленческого решения определяется не только качеством исполнения.

До вопроса:

«Как это сделать?»

должен существовать вопрос:

«Почему мы считаем, что делать нужно именно это?»

Линейная логика быстро соединяет симптом и действие.

Системное мышление вставляет между ними анализ механизма.

И иногда именно эта пауза экономит компании месяцы работы и значительные ресурсы.

Линейная логика нужна. Но нужно понимать границы её применения

Не каждая проблема требует системного анализа.

Если сломался принтер, необязательно исследовать архитектуру организации.

Если сотрудник забыл отправить документ один раз, возможно, он действительно просто забыл.

Если поставщик задержал единственную поставку из-за аварии, нет необходимости немедленно перестраивать всю цепочку.

Системное мышление становится особенно важным, когда проблема:

повторяется;

затрагивает несколько функций;

имеет отложенные последствия;

не исчезает после очевидного решения;

возвращается в другой форме;

создаёт неожиданные побочные эффекты;

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

В этот момент очередная попытка исправить отдельное событие становится всё менее эффективной.

Сильный руководитель ищет не простое объяснение, а полезную модель реальности

Линейная логика привлекательна своей определённостью.

Есть причина.

Есть виновник.

Есть действие.

Есть ожидаемый результат.

Система значительно менее удобна.

В ней несколько причин могут действовать одновременно.

Последствия появляются с задержкой.

Решения меняют поведение людей.

Локальное улучшение ухудшает общий результат.

Причина может находиться далеко от симптома.

А сегодняшнее решение способно стать завтрашней проблемой.

Но именно так устроены реальные организации.

Поэтому системное мышление не делает управление сложнее.

Оно признаёт сложность, которая уже существует.

И позволяет перестать удивляться тому, что очередное очевидное решение снова не дало ожидаемого результата.

Линейная логика спрашивает:

«Что стало причиной проблемы?»

Системное мышление идёт дальше:

«Какая структура делает эту проблему закономерной?»

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

Данный материал носит исключительно ознакомительный и дискуссионный характер и отражает личное мнение автора.

Денис Михин

Автор статьи

Денис Михин

Денис Михин — практик управления, HR, проектного менеджмента и организационных изменений. Автор экспертного журнала и образовательных программ по управлению, Agile, системному мышлению и искусственному интеллекту.

Начать программу

Agile AI Transformation

Понимание, как реально работают Agile, системное мышление и AI

Перейти

Навыки

Развиваемые навыки

Связанные рабочие задачи

Эта статья поможет, если…