?Неуязвимость! Отчего системы дают сбой и как с этим бороться

Это парадокс: дополнительные функции безопасности снижают общий ее уровень{134}. Мало кто так отчетливо это понимает, как Боб Уотчер, врач и автор книг из Калифорнийского университета в Сан-Франциско. В своей книге «Цифровой доктор» (The Digital Doctor){135} Уотчер вспоминает случай с Пабло Гарсия, подростком, который чуть не умер, когда медсестра случайно дала ему гигантскую дозу антибиотиков.

В 2012 году в университетском госпитале внедрили новую компьютерную систему. Она управляла в том числе и роботом-фармацевтом, который занимал целую комнату и при помощи манипуляторов комплектовал лекарства для больных, набирая их из специальных ящичков. Врачи и медсестры надеялись, что новые технологии устранят человеческие ошибки и повысят безопасность пациентов. «Компьютеризированный процесс заказа лекарств сделал рукописные назначения врачей таким же достоянием прошлого, как царапины на грампластинках, – писал Уотчер. – Робот-фармацевт мог гарантировать, что доставалось нужное лекарство, а его доза отмерялась с ювелирной точностью. Штрихкод на упаковке представлял собой еще один элемент безопасности, поскольку в том случае, если сестра взяла неправильное лекарство или ошибочно принесла его не тому больному, подавался сигнал»{136}.

Это замечательные функции безопасности, и они действительно устранили много обычных ошибок. Но они же добавили системе и сложности. А в случае с Пабло Гарсия проблема началась с того, что интерфейс системы заказа лекарств, который был разработан так, чтобы избежать канцелярских ошибок, ввел в заблуждение молодого врача-педиатра. Она была уверена, что заказала только одну таблетку 160 мг. Однако в заказе она указала 160 мг/кг, поэтому система автоматически помножила его на вес мальчика, который составлял 38,6 кг. Таким образом, врач заказала 38,5 таблетки.

Сразу же включилась система предупреждения, и на экране компьютера высветился сигнал тревоги о передозировке. Однако доктор отключила его, поскольку ненужные предупредительные сигналы появлялись на экране монитора постоянно. Фармацевт, который проверял заказ (разумеется, в электронном виде), тоже пропустил ошибку. Робот стоимостью в миллион долларов с радостью упаковал пилюли. И хотя медсестра, пришедшая к Гарсия, и сомневалась по поводу такой большой дозы, штрихкод – еще одна ступень безопасности системы – показал ей, что она находится в нужной палате у нужного пациента. Это развеяло ее сомнения, и она дала мальчику лекарство – все 38 с половиной таблетки.

Колокольчики, свистки и дополнительные функции безопасности устраняют некоторые ошибки. Но в то же время они повышают сложность систем и могут стать причиной серьезных происшествий и аварий. Однако, когда мы хотим оградить себя от них – даже от тех происшествий, виновницей которых была высокая сложность систем, – мы испытываем соблазн добавить в них еще больше функций безопасности. Во время обсуждения случая с передозировкой лекарств{137} один из коллег Уотчера задумчиво произнес: «Думаю, нам надо ввести здесь еще один тревожный сигнал». Уотчер почти закричал в ответ: «Проблема как раз и состоит в том, что у нас слишком много сигналов тревоги! Добавление еще одного только ухудшит дело!»

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

Первый разумный шаг – это их диагностирование. Матрица Перроу с указанием сложности и жесткости связей в системах позволяет нам оценить их уязвимость с точки зрения противодействия чрезвычайным происшествиям или непредвиденным противоправным деяниям. «Матрица демонстрирует, где в вашем проекте или бизнесе следует ожидать неприятных сюрпризов»{138}, – говорит Гэри Миллер, инженер-атомщик, переквалифицировавшийся в консультанта по менеджменту. Он стал кем-то наподобие проповедника концепции Перроу в своей компании.

Миллер привел пример ретейлерской сети, которая намеревается открыть новые магазины. «У вас очень жесткий план их запуска и нет никакого “зазора” на ошибку? Тогда это жестко соединенная система. У вас также сложная система складов, за которой трудно следить прямо? Это сложность системы. Если в вашем проекте присутствуют оба этих компонента, вы должны знать, что на каком-то этапе вас может постигнуть “дурацкая неудача”. Поэтому необходимо изменить ситуацию еще до начала реализации проекта».