Портал №1 по управлению цифровыми
и информационными технологиями

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

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

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

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

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

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

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

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

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


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

«VAP: Управление поддержкой ИТ-услуг»
Строим эффективную ИТ-поддержку, оптимизируем существующую

Комментариев: 2

  • Андрей

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

  • Алексей Лосев

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

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


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

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

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM