Управление проблемами Archives – Страница 6 из 9

Герои в ИТ – повод задуматься

В культуре многих ИТ-организаций существуют ИТ-герои – сотрудники, которые время от время в критические моменты выправляют ситуацию. В подобных организациях инцидент, потребовавший больших усилий на устранение, однотипный элемент в цепи таких же похожих – уже произошедших и возникнущих. Мало кто анализирует произошедший сбой, делает выводы, принимает меры, чтобы предотвратить его появление в будущем. Героями считаются ИТ-специалисты, мастерски решающие проблемы, тушащие внезапные инциденты. Им воздаётся честь и хвала – поскольку результат их работы на виду. При этом в тени остаются те, кто работает проактивно, предотвращая сами предпосылки для развития инцидентов. Или заранее создаёт планы по скорейшему восстановлению работоспособности для случаев, когда…

Новостной поток, 24 апреля 2015, последний комментарий 27 апреля 2015

Инциденты, проблемы и производительность

Наверняка вам встречалась ситуация, когда конечные пользователи недовольны производительностью приложения, а внутри ИТ происходит перекладывание ответственности за "тормоза". Ответственные за программное обеспечение обвиняют ответственных за оборудование и наоборот или говорят пользователю, что так и должно быть. В чем сложность данной ситуации? 1. Понятие "тормозит" весьма субъективно, для одного пользователя приемлемо подождать 5 минут, для другого – 1 минута ожидания, уже вечность. Операции тоже могут быть разными. Что делать: Зафиксировать, что есть нормальная производительность, то есть, что значит "не тормозит". При этом измерение должно производиться в терминах максимально понятных конечным пользователям, желательно, чтобы пользователи могли самостоятельно повторить операцию и оценить скорость ее выполнения….

Евгений Шилов, 22 марта 2015, последний комментарий 22 апреля 2015

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

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

Роман Журавлёв, 25 января 2015, последний комментарий 28 января 2015

ITSM. Руководство по измерению

Каждый год мы с друзьями вместо похода в баню выпускаем книжки по управлению ИТ. Некоторые – смешные, некоторые – серьёзные. Некоторые мы пишем сами, некоторые – переводные. Но все – полезные (во всяком случае, мы очень стараемся). В этом году книга будет серьёзной, и написали мы её сами. Она называется «ITSM. Руководство по измерению» и, как следует из названия, посвящена вопросам измерения процессов ITSM, а также оценки деятельности специалистов, подразделений и руководителей, вовлечённых в исполнение этих процессов. В книге три главы. В первой мы обсуждаем базовые понятия и методику формирования структурированной системы оценки, основанной на измерении. Во второй, применяя данную…

Дмитрий Исайченко, 30 сентября 2014, последний комментарий 29 декабря 2019

Количество проблем в обработке

«Разрешите поинтересоваться в целях повышения образованности…» Из м/ф «Зима в Простоквашино» Задал мне недавно один клиент отличный вопрос. Не в бровь, а в глаз. Сколько проблем одновременно может эффективно обрабатывать координатор / менеджер? Обсудили разные принципы определения такой границы – число Миллера, Top 5-10. Но однозначного ответа, конечно, нет. А вопрос важен, поскольку бороться с меньшим числом проблем и побеждать гораздо лучше, чем тонуть в потоке проблем, не достигая результатов. Лучше и с моральной, и с экономической точек зрения. Вот и Kanban, например, одним из принципов провозглашает ограничения уровня максимальной загрузки (work-in-progress limit) и, как мне кажется, не зря….

Дмитрий Исайченко, 12 июня 2014, последний комментарий 19 июня 2014

О проблемах англичан

Отделение itSMF в Великобритании, как известно, является одним из самых больших и развитых среди себе подобных. Некоторые члены itSMF UK входят в так называемые Special Interests Group (SIG) – группы по интересам, занимающиеся исследованиями какой-то определенной темы. Недавно одна из таких групп подготовила отчет о состоянии процесса управления проблемами в организациях Великобритании. В качестве входных данных использовались результаты опроса, проведенного между 25 организациями, активно участвующими в мероприятиях Problem Management SIG. Сам опрос содержал 20 вопросов, среди которых встречались, например, такие: Каким образом расставляются приоритеты в работе в рамках процесса управления проблемами? Какие техники/методы используются для поиска корневых причин? Какие политики существуют для управления обходными…

Метрики управления проблемами от ИТ-скептика

ИТ-скептик (в миру Роб Ингланд), споря со статьей Симона Хиггинсона на портале The ITSM Review, предлагает несколько собственных KPI для управления проблемами. Есть несколько замечаний: У проблемы обычно несколько причин. Объявлять единственную причину «корневой» – значит быть субъективным. Например, если время диагностики ограничено: «ой, наше время вышло, волевым решением объявляем обнаруженную причину корневой». Продолжительность диагностики и продолжительность исправления нужно измерять, чтобы выявлять тенденции. Но можно ли использовать их в качестве целевых показателей? «Доктор, вам нужно продиагностировать всех пациентов за два часа». Или: «Пожарный, вы должны устранять маленькие пожары за три дня, средние за восемь часов, а огромные пожары за два часа». Надо помнить,…

Новостной поток, 3 февраля 2014, последний комментарий 4 февраля 2014

Вопрос из зала: управляем рисками вместо проблем

Наш читатель Андрей задает еще один короткий, но, уж точно, ёмкий вопрос: Расскажите, можно ли активно развивая процесс управления рисками, заменить или покрыть управление проблемами? Что скажете, коллеги?

Вопрос из зала, 16 января 2014, последний комментарий 29 ноября 2024

Проблемы и известные ошибки

Интересную задачку нам предложили некоторое время назад в разделе "Задать вопрос": Расскажите пожалуйста преимущества (пользу) и недостатки (затраты) вариантов: 1. Известная ошибка это статус проблемы и тогда в системе автоматизации один объект. 2. Известная ошибка и проблема это 2 отдельных объекта. Любой, кто участвовал в построении процесса управления проблемами, наверняка, размышлял о разных вариантах реализации такого объекта, как известная ошибка. Поделитесь своим мнением, коллеги!

Вопрос из зала, 11 декабря 2013, последний комментарий 1 июня 2017

Определяем сроки обработки проблем

Как известно передовой ITSM-общественности, в общем случае нормативы обработки проблем установить нельзя. Это, в частности, связано с тем, что в большинстве случаев для решения проблемы необходимо реализовать изменение, причем вряд ли стандартное, а срок реализации изменений есть результат индивидуального планирования. Более того, в случае управления проблемами дело, как правило, осложняется тем, что у проблемы может быть несколько решений, отличных по степени надежности, стоимости, срокам реализации – оптимальный вариант придется выбирать. Время, в течение которого выполняется тестирование результативности решения, также не поддается нормировке. Например, если проблема проявляется ежедневно, то тестирование можно выполнить за 2-3 дня. А если проблема связана с недопустимым торможением…

Дмитрий Исайченко, 20 октября 2013, последний комментарий 11 мая 2017

ITIL: чтобы не отучаться, можно улучшить

Пока новая управляющая компания активно слушает экспертов и участников рынка, многие стараются не упустить возможность и делают различные предложения по улучшению ITIL. Наш друг Аале Роос, известный идеями "Отучения от ITIL", тоже старается внести свою лепту и видит три области, которые можно улучшить: Жизненный цикл услуги; Слишком сложная и избыточная процессная модель; Сервис деск, управление инцидентами, событиями, запросами на обслуживание, проблемами; Он решил начать с конца и озвучил три процесса, которые, по его мнению, реально нужны в операционной деятельности ИТ-департамента: Обработка заявок, сконцентрированная вокруг продуктов или услуг (и их конкретных характеристик), необходимых заказчику. В большинстве случаев обработка заявок должна представлять из…

Новостной поток, 5 сентября 2013, последний комментарий 17 сентября 2013

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

Управление проблемами

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