Опочтарение и problem management

Есть еще такая болезнь — профессиональная деформация... Кто не может выражать свои мысли без помощи power point'a, видит в окружающем мире проявления ITSM-процессов и разговаривает терминами ITIL, тот я. 

Вот хочу поделиться замечательным примером управления проблемами, случившимся, впрочем, задолго до того, как кто-то придумал этот термин. Рассказали мне эту историю в музее американской почты, что в городе Вашингтоне. Мы там случайно попали на экскурсию, проводившуюся пожилым волонтером и оказавшуюся скорее экскурсией по почтовым маркам США — волонтер на вопрос о причинах его такой работы ответил "я с шести лет собираю марки, а тут столько марок...", то есть его интерес к почте США был узко, но увлекательно специализирован. 

История такова (извините меня, филателисты, за возможные исторические неточности — привожу по памяти, с источниками не сверялся):

В 1918 в связи с открытием первого направления регулярной авиапочты в США была выпущена двухцветная марка с изображением самолета. Двухцветная печать тогда выполнялась последовательно: сначала на бумагу наносился один цвет, потом — второй. И вот с первым тиражом авиамарок случилась неприятность: синий самолет в красной рамке оказался перевернут вверх ногами шасси, поскольку лист с нанесенным первым слоем был вставлен в печатный станок не той стороной. Есть версия, что исполнитель этой работы потом оправдывался тем, что самолетов в глаза не видел и где у них верх, где низ, не знал. Было напечатано довольно много таких марок, но куплен в итоге был только один лист из ста штук, остальной тираж уничтожили. Зато этот лист сначала был дорого продан целиком, а потом (еще дороже) частям, причем каждая марка была при этом пронумерована. Сейчас это чуть ли не самая известная ошибка в истории американской филателии и одновременно одна из самых популярных редкостей в коллекциях филателистов и музеев. 

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

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

Говоря возвышенным языком управления проблемами, были внесены изменения в процедуры, инфраструктуру и сам продукт, добавлены новые контроли. Все это снизило риск повторения ошибок и связанных с ними инцидентов. 

Была и другая история, очень похожая на эту: как-то раз на лист из ста двухцентовых марок попали три пятицентовых — причем не на один лист, а на авторизованный и неоднократно проверенный шаблон, с которого потом было напечатано множество копий. Последствия инцидента пытались снижать путем рассылки циркуляров вида "считать такие-то пятицентовые марки двухцентовыми" (не думаю, чтобы это работало). А причин называют, как минимум, две: во-первых, в то время все марки номиналом до десяти центов выглядели практически одинаково, отличались только цифры, обозначающие стоимость. Немудрено спутать. А во-вторых, согласно записям о проверке злополучного листа, проверка эта осуществлялась утром в понедельник, когда , вероятно, внимание сотрудников было рассеяно и отвлекалось, например, головной болью. Очевидные решения: создать уникальный дизайн для каждого номинала марок и утверждать эталонные экземпляры не по понедельникам. 


А какие вы знаете жизненные примеры решения проблем по итогам расследования инцидентов? 

ITIL ITIL Intermediate: Operational Support and Analysis

Учебный курс: эксплуатация и поддержка ИТ-услуг, Service Desk, инциденты, проблемы, операции и запросы пользователей — в ITIL и на практике.
 

Узнайте больше!

Комментарии и мнения

  1. Андрей

    У меня есть пример, даже много. Есть такое расхожее выражение — "уставы писаны кровью". Суть этого выражения в том, что за каждым пунктом устава стоит чья-то смерть или увечие. По инциденту провели расследование и внесли в устав пункт, чтобы предотвратить трагедию в будущем. Еще пример — правила дорожного движения. Их создавали не империческим образом и они не были дарованы в виде заповедей. У каждого пункта ПДД в основе лежит чья-то трагедия. И беда в том, что про трагедию уже никто не помнит и многие считают пункты устава и правил искусственными ограничениями их свободы, что эти ограничения можно немножко нарушать. В результате — повторение трагедии. Вот. В части, касающейся Problem management относительно процессов — важно не только и не столько исправить процесс, но и обеспечить точность исполнения нового процесса. Либо технологически, чтобы исполнитель роли не мог поступать неправильно, либо через неотвратимость наказания.

  2. Алексей Лосев

    Если кто-то что-то может сделать не так, то он рано или поздно это сделает. Например, программисты помещают изменения в хранилище кода. Через неделю, месяй или год нереально вспонить зачем было сделано то или иное изменение. Ставятся ограничения: 1. Check-In должен быть привязан к элементу бэклога. 2. Check-In должен содержать комментарий.

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

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Ближайшие мероприятия

Зарегистрируйтесь, чтобы получить больше полезных знаний:

ИЮН
26