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

И снова (N+C)/(O+C)

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

Дмитрий Исайченко, 27 ноября 2015, последний комментарий 10 декабря 2015

Вопрос из зала: где должен быть Problem management?

Читатель нашего портала Дмитрий интересуется управлением проблемами: Добрый день, Внутри команды Service Managers возникло бурное обсуждение, откуда должен предоставляться Problem Management, так как в ITIL нет четкого описания ( или мы его не нашли), кто за это отвечает ( понятно, тут не обойтисть без Problem Manager) и откуда (ServiceDesk?) , есть лишь описание , что проблемы поднимаються со 2-й линни в Problem Management процесс. Cреди вариантов есть такие мнение: 1) Не должен предоставляться Service Desk, так как возникает конфликт интересов, и всегда должен предоставляться на уровнях 2 или 3 линий поддержки, которая обязательно находится не в ServiceDesk 2) Предоствляется из…

Вопрос из зала, 26 ноября 2015, последний комментарий 10 декабря 2015

Более 3 часов уходит у 65% компаний на анализ проблем, связанных с приложениями

AppDynamics совместно с Enterprise Management Associates (EMA) опубликовала в августе отчет об исследовании, основанном на опросе 302 специалистов и менеджеров, отвечающих за управление приложениями. По данным отчёта, для проблем, связанных с приложениями и выходящих за пределы компетенции 1-й линии поддержки: 65% компаний требуется более 3 часов на определение корневой причины; 77% компаний требуется более 5 человеко-часов на решение. (Графики из статьи, опубликованной Anand Akela в корпоративном блоге AppDynamics) Некоторые факты из отчёта: Только 30% компаний имеют в настоящее время специализированные решения для мониторинга приложений Не более 50% приобретённых инструментов используются для мониторинга приложений 27% проблем, связанных с приложениями, обнаруживаются с помощью систем…

Когда Problem Management – проблема.

Как понять, что можно существенно улучшить процесс управления проблемами (Problem Management)? В недавно опубликованном посте «When Problem Management is the Problem» Michael Keeling задаётся вопросом, почему, несмотря на то, что человечество занимается решением проблем всю свою историю, нельзя сказать, что эта практика полностью изучена, освоена и не вызывает вопросов. Если говорить об ITSM, то, по мнению автора, во многих организациях процесс управления проблемами работает не так, как им хотелось бы. Более того, иногда приглашённые для анализа такой ситуации консультанты приходят к выводу, что реализованный процесс управления проблемами на самом деле является частью проблемы. Если вы подозреваете, что процесс управления проблемами…

Новостной поток, 12 августа 2015, последний комментарий 9 июля 2018

5 советов по улучшению управления проблемами

Стюарт Рэнс (Stuart Rance) в своем блоге опубликовал интересный материал, посвященный управлению проблемами. Он предлагает обратить внимание на 5 важных советов, которые могут помочь в улучшении данного процесса. Совет 1. Регистрируйте проблемы Добейтесь того, чтобы проблемы регистрировались для часто повторяющихся инцидентов и инцидентов с высоким влиянием. Выберите TOP5 или TOP10 проблем и сосредоточьтесь на них. Решение проблем имеющих максимальное влияние позволит добиться максимального эффекта. Совет 2. Сосредоточьтесь на обходных решениях, а не корневых причинах. Не тратьте недели на поиски корневой причины, в то время как бизнес не может нормально работать. Начните с выявления способов идентификации инцидентов связанных с данной проблемой и обходных решений, которые помогут…

Новостной поток, 9 июля 2015, последний комментарий 15 июля 2015

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

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

Новостной поток, 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 вопросов, среди которых встречались, например, такие: Каким образом расставляются приоритеты в работе в рамках процесса управления проблемами? Какие техники/методы используются для поиска корневых причин? Какие политики существуют для управления обходными…

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

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

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