Управление инцидентами Archives – Страница 13 из 18

Вторжение, набег, нашествие… Кого воспитывать – пользователей или программы?

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

Роман Журавлёв, 3 марта 2013, последний комментарий 26 сентября 2013

Безальтернативность Service Desk

Много раз обсуждали эту тему с заказчиками – правда ли необходима единая точка контакта по вопросам поддержки пользователей (Service Desk)? А если нет, то при каких условиях от неё можно или даже нужно отказываться? Могу сказать, что за свою карьеру я несколько раз советовал заказчикам воздержаться от организации такой службы, которая стала бы обязательной первой точкой контакта. Основных причин для такой рекомендации я вижу две: нехватка ресурсов для организации SD. Благо потребность в ресурсах в данном случае оценить очень просто (например, используя формулу Эрланга или упрощенные аналоги); наличие отдельных узкоспециализированных групп, которые поддерживают своих пользователей, которые пользуются только соответствующими отдельными…

Дмитрий Исайченко, 25 февраля 2013, последний комментарий 1 сентября 2014

Почему случаются инциденты

Один из авторов ITSMPortal, Robert S. Falkowitz, провел интернет-опрос о причинах инцидентов. Как объясняет Роберт, таким образом он хотел проверить увиденное в одной из публикаций утверждение, что "80% инцидентов являются следствием проводимых изменений". В обзоре результатов опроса Роберт отмечает, что собранные им данные так же недостоверны, как любые другие результаты подобных опросов: Выборка участников нерепрезентативна и невелика Как ни старался автор сделать вопросы максимально простыми, нашлись те, кто их не понял или понял неверно Знания, на которых участники основывают свои ответы, могут быть неверны; при этом сами участники склонны переоценивать свою практику и качество доступной им информации Тем не менее, опрос проведен…

Своевременность реакции на назначение как KPI?

В процессе управления инцидентами есть очень важный показатель – своевременность реакции на инцидент в группе 2-ой и последующих линий. Его обязательно надо измерять и контролировать, особенно на раннем этапе работы по процессу, поскольку он позволяет выявлять задержки в обработке, связанные с отсутствием должного внимания к инцидентам руководителей функциональных групп. Напрашивается идея: сделать его KPI для руководителей групп. И я так делал, не один раз. Но думаю, в долгосрочной перспективе это может быть не очень хорошая идея. Почему? Инциденты могут решаться долго не потому, что они очень сложные, а потому, что они долго лежат в очереди. Мы даже как-то обсуждали это не так…

Дмитрий Исайченко, 2 февраля 2013, последний комментарий 1 сентября 2014

Конвейер в ИТ

Совсем недавно обсуждали распределение ресурсов в рамках работ по сопровождению систем автоматизации. Работы включают в себя, в том числе разработку новых функциональных возможностей по требованию заказчика. Сам я не специалист по производственным процессам, не так давно читал книгу "Цель" Э.Голдратта, поэтому сразу же в глаза бросилась схожесть задач, с которыми приходится сталкиваться в ИТ, с задачами, описанными автором в отношении производственных процессов на заводах. Вопросы узких мест, загрузки и простоев ценных ресурсов, выделения доп.ресурсов и соответствия спросу, цепочек работ со стохастическими колебаниями их длительности и т.д. Дмитрий уже как-то упоминал эту книгу применительно к процессу управления инцидентами. Если еще не…

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

Самое лучшее в ITSM по-русски

Этот декабрь выдался богатым на анонсы книжного рынка. Параллельно с книгой Романа Журавлёва коллектив авторов портала Real ITSM подготовил к изданию сборник собственных статей. Самое лучшее и практичное из мира ITSM уже доступно для загрузки в формате PDF. В сборнике вы найдёте: фундаментальные статьи: и напечатанные в альманахах itSMF, и выходившие в печатной прессе, и не издававшиеся ранее дотошные вопросы к западным ITSM-экспертам и их робкие точные ответы картинки и опечатки идеальную вёрстку линейки и градусники модели и формулы итоги многодневных дискуссий с вами на портале Real ITSM Читайте на здоровье. А свои отклики и замечания оставляйте здесь, в комментариях.

Поддержка пользователей и удаленное управление ПК

Есть такая тема – использование удаленного управления рабочими столами для поддержки пользователей (опять недавно всплыла). С одной стороны вещь полезная, поскольку позволяет и проблемы устранять в территориально распределенной сети без квалифицированного локального персонала, и FLR поднимать (поскольку первая линия ногами, как правило, не пользуется), и скриншоты для профильных специалистов снимать при регистрации обращения. Но да – есть и вопросы безопасности. По мне так это именно вопросы, а не проблемы, которые не преодолеть. Работал с многими компаниями, где безопасники давали разрешение на применение таких средств после того, как проводили экспертизу и получали гарантию, что подключение к ПК пользователя можно выполнить только…

Дмитрий Исайченко, 17 декабря 2012, последний комментарий 22 декабря 2012

ServiceDesk для маленьких

Много раз сталкивался с ситуацией, когда в относительно небольшой компании, в которой трудится 5-10 ИТ-специалистов, организуется ServiceDesk. При этом всегда встает вопрос: "Каким он должен быть с учетом ограниченности ресурсов?". Во-первых, давайте поймем, есть ли вообще смысл выделять службу поддержки в небольшой компании. С одной стороны, ИТ-специалистов немного, скорее всего, у каждого своя специализация, пользователи знают всех поименно, и вводить дополнительное звено между ними и пользователями – значит усложнять простые процедуры. С другой стороны, недостаток ресурсов приводит к реализации рисков, например: обращения пользователей забываются/теряются в общем потоке пользователям сложно найти ИТ-специалистов для того чтобы сообщить о своих проблемах не всегда…

Инструкция по выбору ПО для Service Desk

Британский Service Desk Institute не только проводит виртуальные и очные конференции по управлению ИТ-услугами, собирая мировых ITSM-звезд и внушительные аудитории, но и выпускает интересные и полезные материалы для профессионалов. Один из таких материалов – вышедшее в ноябре руководство по выбору и покупке ПО для автоматизации Service Desk. Бесплатно доступный для просмотра в интернете и скачивания (в формате Yudu, похожем на djvu) справочник содержит обзоры 20 продуктов, три кейса, рекомендации по выбору вендора и построению взаимовыгодных отношений с ним и полезную главу How to Avoid Being Fools with Tools. Документ немаленький – 52 страницы, а завершает его алфавитный справочник систем автоматизации…

Новостной поток, 2 декабря 2012, последний комментарий 3 декабря 2012

Для тех, кто не любит ждать

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

Евгений Шилов, 25 октября 2012, последний комментарий 13 ноября 2012

Вопрос из зала: штрафы за неработающее ПО

Константин задаёт вопрос: Здравствуйте, коллеги. Компания, в которой я работаю, занимается разработкой, внедрением и поддержкой сложных программных комплексов. Время простоя нашего ПО у заказчика не должно превышать 30 минут. При этом заказчик устраняет проблемы собственными силами, но при нашей поддержке. Заказчик хочет в новом договоре на поддержку указать штраф, в случае если нарушение в работе ПО не устраняется за заданное время (например 4 часа). При этом совершенно все равно почему не работает ПО (проблемы с железом, ошибки персонала и т.д.). Вопрос штрафов принципиальный. Может, есть какие-нибудь типовые соглашения о поддержке, где прописаны нормальные условия а не фантастические? За что надо…

Вопрос из зала, 23 октября 2012, последний комментарий 31 октября 2012

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

Управление инцидентами

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