Диаграммы CLD
Causal Loop Diagrams
02.2 Causal Loop Diagrams
Диаграмма причинно-следственных связей (CLD — Causal Loop Diagram) — основной инструмент визуализации системной структуры в STAF. Она показывает не процесс ("что за чем следует"), а динамику ("что на что влияет и через какие петли"). Это принципиальное отличие от блок-схемы или диаграммы процесса.
Что показывает CLD — и чего не показывает
Показывает:
- Переменные и элементы системы
- Направление причинного влияния между ними
- Знак влияния (+/-)
- Петли обратной связи (замкнутые причинные пути)
- Задержки в ключевых связях
Не показывает:
- Количественные значения переменных
- Точные математические зависимости
- Временны́е шкалы (только порядок задержки: короткая/длинная)
- Вероятности событий
CLD — это карта структуры, не прогнозная модель. Её ценность в том, что она делает видимым то, что обычно существует только в головах разных людей в разных версиях.
Элементы диаграммы
Переменная / элемент
Изображается как текстовый узел. Подписывается существительным или субстантивным словосочетанием: "уровень доверия", "время обработки заявки", "квалификация команды".
Правило именования: переменная должна иметь направление изменения — можно сказать, что она "растёт" или "снижается". Если формулировка не допускает этого — это не переменная CLD, а категория или тип.
Хорошо: "скорость обработки", "число активных клиентов", "уровень задолженности" Плохо: "процесс онбординга", "команда поддержки", "грантовая программа" — это описания, а не переменные.
Стрелка причинной связи
Изображается направленной стрелкой от причины к следствию. Рядом со стрелкой — знак (+) или (-) и при необходимости — символ задержки (двойная черта на стрелке).
Знак (+)
Читается: "если причина растёт, следствие тоже растёт (при прочих равных)". Или: "если причина снижается, следствие тоже снижается". Оба направления работают одинаково — знак описывает тип влияния, не абсолютное движение.
Пример: "уровень доверия →(+) вовлечённость команды" означает, что рост доверия ведёт к росту вовлечённости, а снижение доверия — к снижению вовлечённости.
Знак (-)
Читается: "если причина растёт, следствие снижается (при прочих равных)". Или: "если причина снижается, следствие растёт".
Пример: "длина очереди →(-) скорость обработки каждой заявки" означает, что рост очереди снижает качество обработки (перегрузка), а снижение очереди — позволяет уделять больше внимания каждой заявке.
Задержка
Обозначается двойной чертой на стрелке (||). Указывается там, где разрыв во времени между причиной и следствием значителен для понимания динамики системы. Длительность задержки — качественно: "короткая" (дни-недели), "средняя" (месяцы), "длинная" (кварталы-годы).
Метка петли
В центре каждого замкнутого цикла ставится метка: R (Reinforcing, усиливающая) или B (Balancing, балансирующая) с порядковым номером. Пример: R1, B2, R3.
Тип петли определяется математически: подсчитать число отрицательных связей в цикле. Чётное (включая ноль) — петля R. Нечётное — петля B.
Как строить CLD: пошаговый порядок
Шаг 1: Выбрать фокусную переменную
Начать с элемента, который вызывает наибольшую озабоченность или является центральным для вопроса-катализатора. Это не обязательно начало процесса — это то, что важнее всего понять.
Шаг 2: Задать вопросы "что влияет на это?" и "на что влияет это?"
Для фокусной переменной и каждого нового элемента:
- Что заставляет это расти или снижаться?
- К чему ведёт рост / снижение этого?
Двигаться итерационно: каждый новый элемент становится источником следующих вопросов.
Шаг 3: Подписывать знаки немедленно
Не откладывать знак "на потом". Неподписанная стрелка — это неопределённость, которая позволяет видеть в диаграмме то, чего в ней нет. Если знак неизвестен — это сигнал, что причинная связь не обоснована.
Шаг 4: Искать циклы
Проследить, есть ли путь от нового элемента обратно к уже нарисованному. Замкнутый путь — это петля. Определить её тип (R или B) и подписать.
Шаг 5: Добавить задержки
Пройти по всем связям и отметить те, где задержка значима для понимания динамики. Не обозначать задержки везде — только там, где они реально влияют на поведение.
Шаг 6: Проверить читаемость
Стрелки не должны перекрещиваться больше необходимого. Петли должны быть видны как замкнутые структуры, а не теряться в общем клубке связей. Если диаграмма нечитаема — разбить на несколько (по подсистемам) или упростить.
Типичные ошибки при построении CLD
Ошибка 1: Путать CLD с блок-схемой процесса
Блок-схема показывает последовательность шагов: "сначала это, потом то". CLD показывает причинное влияние: "это влияет на то". Смешение ведёт к диаграмме, которая выглядит как CLD, но не содержит петель — потому что последовательный процесс сам по себе петель не имеет.
Признак ошибки: в диаграмме нет ни одной петли, или все стрелки направлены в одну сторону.
Ошибка 2: Неправильные знаки
Знак определяется однозначно: в каком направлении изменяется следствие при росте причины? Ошибка возникает, когда знак ставится по интуиции ("это плохо влияет, значит минус") вместо аналитического определения.
Проверка: прочитать стрелку вслух — "если [причина] растёт, то [следствие]... (растёт / снижается)". Если формулировка неестественна или неоднозначна — связь, скорее всего, описывает не причинность, а последовательность.
Ошибка 3: Слишком много элементов
CLD теряет ценность, когда содержит 30+ переменных в одном клубке. Такая диаграмма технически может быть правильной, но непригодна для работы.
Правило практика: если петля не видна с первого взгляда — диаграмма переусложнена. Решение: выделить ключевые 2-3 петли в отдельные диаграммы, связав их через общие переменные.
Ошибка 4: Переменные без направления изменения
"Система отчётности" — это не переменная. "Качество отчётности" — переменная. "Команда разработки" — не переменная. "Продуктивность команды разработки" — переменная.
Именование имеет значение: если переменная не может "расти" или "снижаться", она не является переменной CLD — это категория или описание контекста.
Ошибка 5: Причинность из последовательности
"После A идёт B" не означает "A вызывает B". Корреляция во времени — не причинность. Каждая стрелка на CLD должна быть обоснована как причинная: почему именно изменение A меняет B, а не просто одно следует за другим?
Как читать CLD: протокол для верификации
При предъявлении CLD носителю системы использовать этот порядок:
1. Назвать переменные. "Вот что мы выделили как ключевые элементы в вашем процессе. Что-то отсутствует? Что-то названо неточно?"
2. Пройти по связям — сначала по очевидным. "Когда [A] растёт — [B] тоже растёт. Это соответствует вашему опыту?" Для каждой связи с типом "inferred" — задать вопрос явно как вопрос, не утверждение.
3. Показать петли и их типы. "Вот эта цепочка замыкается — [A → B → C → A]. Это усиливающая петля: если она начинает расти, она будет ускорять рост. Вы видите это поведение в реальности?"
4. Задать вопрос о задержках. "Насколько быстро изменение в [A] проявляется в [B] на практике? Это дни, месяцы?"
5. Спросить о пропущенном. "Что важно в этом процессе, что мы не показали?"
CLD как живой документ
CLD не является финальным артефактом — это рабочий инструмент, который меняется при верификации и при каждом пересмотре цикла. Хорошая практика: указывать версию и дату на каждой CLD. Сравнение версий часто само по себе является диагностически ценным — где изменилось понимание системы и почему.
STAF 1.0 · SysMindLab · 2026