А можно сосредоточиться на Тропе и вообще проигнорировать умы и сердца. Представьте, что вы сразу исходите из того, что рабочие безнадежны и плюют на технику безопасности несмотря ни на что. Есть ли шанс не дать им порезать себя на куски?
Несомненно. Многие предприятия именно так и поступили. Например, один станок сконструирован так, что его можно включить только нажатием двух кнопок одновременно, и для этого человеку необходимо широко развести руки. Красота этого решения состоит в том, что руки при этом находятся далеко от опасных зон.
Так опасный маневр оказался невозможным.
– 8 –
Подумайте обо всех инновациях, которые исключили или почти исключили «рискованное поведение»: недоступные для детей крышки на банках с лекарствами; машины, которые не сдвинутся со стоянки, если перед этим не проверить работу тормозной системы; всевозможные противопожарные приспособления. Эти дизайнерские чудеса были созданы для предотвращения травм. Профилактика травматизма – благодатная область. В правительстве каждого американского штата есть несколько постоянных сотрудников – обычно им постыдно мало платят, – работа которых заключается в том, чтобы беспокоиться за других. Их задача – обезопасить маленьких детей, которые падают в плавательные бассейны, пожилых людей, получающих травмы у себя дома, снизить смертность в результате автокатастроф. Несчастные случаи сложно исключить совсем, но можно уменьшить травматизм, к которому они приводят.
Пытаясь свести к минимуму риск печальных последствий, эксперты по профилактике травматизма часто обращаются к «матрице Хэддона»
{91} – простой схеме, позволяющей рассматривать происшествия системно. В ней выделены три ключевые фазы: до аварии, во время аварии и после аварии.
Допустим, наша цель – уменьшить тяжкие последствия автокатастроф. Мероприятия до аварии будут включать все, что способно предотвратить само происшествие: яркое освещение шоссе, четкая дорожная разметка, реклама антиблокировочных тормозных систем, проведение кампаний против вождения в нетрезвом состоянии.
Рассматривая вмешательства во время аварии, мы исходим из того, что она, увы, произойдет, и спрашиваем себя, как предотвратить последствия для здоровья. Классические меры такого рода – ремни безопасности и воздушные подушки, но не забывайте о разрушаемых фонарных столбах, больших оранжевых бочках, которыми обозначают съезды с эстакады (они призваны смягчить удар) и так далее.
Занимаясь мерами после аварии, мы признаем, что авария произошла и люди пострадали. Цель этих мероприятий – минимизировать тяжесть повреждений. Здесь важна быстрая, эффективная реанимация и последующая реабилитация.
Матрица Хэддона полезна и в менее экстремальных вопросах. Скажем, вы отвечаете за компьютерные технологии в маленькой компании. Одна из многих ваших обязанностей – предотвратить потерю важных данных, которая часто происходит при сбое системы. Некоторые сотрудники службы поддержки в таких ситуациях прибегают не к матрице Хэддона, а к «Хамскому манифесту», браня коллег за то, что те не сделали резервную копию. (Тем самым системные администраторы совершают фундаментальную ошибку атрибуции: «Я работаю с беспечными лентяями».) Но если подумать о ситуации в категориях матрицы Хэддона, картина вырисовывается более целостная.
Давайте посмотрим на вмешательство до происшествия: если компьютеры будут работать без сбоев, данные останутся целы. Может быть, запланировать ежемесячную проверку компьютеров, купить всем амортизирующие сумки для ноутбуков и внести в бюджет строку о полной замене техники каждые три года?
Для вмешательства во время происшествия потребуется предотвратить потерю данных в результате сбоя. В частности, в некоторых компьютерах установлен дополнительный жесткий диск, где в реальном времени создается зеркало всей информации. Вероятность, что падение затронет оба привода сразу, гораздо меньше.
Меры после происшествия подразумевают, что потеря данных произошла и необходимо сосредоточиться на уменьшении вреда. Самая очевидная стратегия – внедрить автоматически создаваемую каждую ночь сетевую резервную копию, чтобы после сбоя системы и потери данных восстановить вчерашнюю версию. Еще одна стратегия – полностью предотвратить попадание на ноутбуки критически важных для работы данных. В частности, можно использовать онлайн-приложения, например SalesForce.com, и держать там контактную информацию клиентов и другие драгоценные данные. Тогда они вообще не будут зависеть от состояния локального жесткого диска.
Обратите внимание, что нам удалось набросать план борьбы с потерей данных, не беспокоясь о том, что думают и чувствуют сотрудники. Мы не упомянули ни Слонов, ни их Погонщиков, а просто поработали со средой, чтобы сделать плохое поведение невозможным.
– 9 –
В 1999 году компания Rackspace внезапно исключила из своей деятельности некоторые виды неправильного поведения
{92}. В какой-то момент сотрудники перестали делать одно и начали делать другое, и этот сдвиг стал переломной точкой в истории компании. Но прежде чем рассказать о том, как это произошло, ненадолго погрузимся в предысторию.
Rackspace занимается предоставлением интернет-хостинга другим компаниям. Она гордится качеством работы с клиентами, и это отражено в ее слогане – «Фанатичная поддержка». Внимание к клиенту оправдывает себя. На протяжении своего существования Rackspace завоевала бессчетное число отраслевых премий за уровень обслуживания и, к зависти конкурентов, получила высокий рейтинг Net Promoter
[24]
, который пользуется у клиентов большой популярностью.
Но так было не всегда. В 1999 году компания не слишком пеклась о потребителях и своем дружелюбном имидже. Основатель компании Грэм Уэстон вспоминает, что в те дни Rackspace исповедовала бизнес-модель «отрицания сервиса». На возню с клиентом смотрели как на лишние затраты, которые надо минимизировать. Чем реже звонит телефон, тем меньше приходится отвлекаться. (Обратите внимание, как откликается матрица Хэддона: если звонки клиентов – плохое поведение и его надо устранить, вы сделаете все, что в ваших силах, чтобы их отпугнуть. Не забывайте, что на протяжении многих лет Amazon не публиковала номер телефона клиентской службы.)
Но как-то осенью 1999 года в Rackspace раздался звонок судьбы – один настойчивый клиент попытался дозвониться до службы поддержки. Он нажал 5, чтобы получить помощь, но вместо этого услышал автоответчик, который заявил: «Вы можете оставить сообщение, но мы проверяем голосовую почту не очень часто, поэтому лучше напишите нам электронное сообщение». Клиент нехотя отправил письмо на указанный адрес, но команда Rackspace так и не удостоила его ответом.
