других лидеров, и возможности организации постоянно увеличиваются.

Каждое из этих условий необходимо для безопасной работы в сложной системе. В следующих разделах описаны первые два условия и их значение, а также как они были созданы в других областях и каковы методы включения их в технологический поток создания ценности (третье и четвертое условия описаны в главе 4).

Видеть проблемы сразу после появления

При безопасной системе работы необходимо постоянно проверять проектное решение и эксплуатационные допущения. Цель — увеличить поток информации в системе как можно раньше, быстрее, дешевле и с прозрачной взаимосвязью между причинами и следствиями. Чем больше предположений мы сможем проверить, тем быстрее сумеем найти и устранить проблемы, увеличить устойчивость, гибкость и способность к обучению и инновациям.

Мы можем сделать это, создав петли обратной и прямой связи в системе работы. Доктор Питер Сенге в книге «Пятая дисциплина. Искусство и практика самообучающейся организации»[31] описал петли обратной связи как чрезвычайно важную часть процесса обучения мышлению в категориях организаций и систем. Петли обратной и прямой связи дают возможность компонентам системы взаимно усиливать или нейтрализовать друг друга.

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

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

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

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

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

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

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

Как сказала Элизабет Хендрисон, технический директор компании Pivotal Software и автор книги Explore It!: Reduce Risk and Increase Confidence with Exploratory Testing, «когда я возглавляла подразделение тестирования, я описывала свою работу как “создание циклов обратной связи”. Обратная связь — важнейший фактор, поскольку она позволяет управлять разработкой. Мы должны постоянно сверять нужды клиентов с нашими стремлениями и тем, что у нас получается. Тестирование — это лишь одна из форм обратной связи».

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

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

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

Пример — шнур Toyota Andon (далее в качестве равнозначного будет использоваться термин «шнур-андон»). На заводах Toyota на каждом рабочем месте натянут сигнальный шнур, всех работников и менеджеров учат дергать за него, когда что-то выходит из строя, например деталь имеет дефект, нужная деталь отсутствует или работа занимает больше времени, чем положено по графику[32].

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

Вместо того чтобы ходить вокруг да около или планировать поиск решения проблемы на тот момент, «когда у нас будет больше времени», мы объединяемся, чтобы исправить ситуацию немедленно, — это практически полная противоположность описанной выше ситуации на заводе General Motors во Фримонте. Объединиться, решая проблему, необходимо по следующим причинам.

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

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

• Если проблема не будет решена, то на следующей операции (например, спустя 55 секунд) могут возникнуть те же проблемы на тех же рабочих местах. Однако они потребуют больше исправлений и дополнительной работы (см. приложение 6).

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

Как отмечает Спир, объединиться вокруг проблемы — это часть программы «учиться распознавать проблемы в реальном времени, определять их причины… и лечить (принимать контрмеры или корректировать производственный процесс). Это обычная практика цикла Стюарта (планирование — действие — проверка — корректировка), популяризированного Эдвардсом Демингом, но форсированного до сверхзвуковой скорости».

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