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

Посчитаем срок решения инцидента?

Опубликовано 26 октября 2011
Рубрики: Измерение и оценка ИТ, Обо всём на свете, Практика и опыт, Управление инцидентами
Комментарии

Поступил очередной интересный вопрос от постоянного читателя. По согласованию с ним, мы выносим ситуацию на публичное обсуждение:

Внедряем ServiceDesk в своей организации с 400+ пользователями, учитывая рекомендации ITILv3 Очереди не используются, в связи с малым количеством пользователей и сотрудников СТП (3 человека на тех поддержке), кроме этого есть программисты и аналитики в самом отделе. Количество инцидентов=100/месяц Столкнулся с показателями, не понятно, что считать за время решения инцидента в некоторых ситуациях:

1. Пользователь запросил для некой автоматизированной системы ввести некую "фичу". После анализа выяснилось что требуется доработка ПО, что займет 2 недели. Запрос передан программисту, который выполнил данный запрос.

2. Пользователь создал запрос на изменение конфигурации ПК. Требуется покупка комплектующих. На основании запроса выписан счет, который пролежал в бухгалтерии 2 месяца, после чего был оплачен и произведена модернизация ПК. Т.е. ИТ служба свою задачу выполнила, время на решение инцидента исчисляется минутами, но были проблемы с финансами, которые увеличили время решения до 2 месяцев. Закрыть запрос после выставления счета нельзя, т.к. инцидент не исчерпан 

3. Пользователь создал запрос на переустановку MS Office. После анализа и переустановки ПО выяснилось что требуется переустановка ОС, а после и это не помогло и требуется замена комплектующих.Понятно что есть вопрос к компетенции ИТ-специалиста, здесь стоит рассматривать запрос как сложный инцидент.

4. Пользователь создал запрос на функционал ПО. На это ПО осуществляется гарантийная стандартная техподдержка, сроки решения запросов имеют большую длительность (так как техподдержка стандартная). ИТ-специалист, проанализировав запрос и произведя определенные действия, которые показали, что требуется поддержка вендора, перевел запрос в техподдержку производителя ПК, который решил запрос за 2 месяца. Т.е. ИТ-специалист затратил минимуму времени. Ситуация аналогична п.2

Данный показатель необходим для мотивации персонала ИТ службы

Итак: четыре сценария – один целостный и внятный механизм определения срока выполнения работ. Какой?

Поделитесь вашим опытом в комментариях. Убедительно просим экспертов не пускаться здесь в споры о терминах: "инциденты", "сбои", "запросы", "обращения" – пусть это будет непринципиально.

ИНТЕНСИВ С ТРЕНЕРОМ
VAP: Построение системы KPI для ИТ
Как обеспечить управление процессами, проектами, услугами, персоналом

Также по теме:

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

  • Анатолий Павлюченко

    Без “споров о терминологии” не обойтись 🙂
    Без _проблем_ и _запросов на изменения_ описать данные ситуации не представляется возможным, так как каждая из описаных действительно имеет короткий _срок решения инцидента_ и более долгие сроки для других последующих действий.

    • Константин Нарыжный

      Анатолий, проблемы то у пользователей в каждом из 4 случаев: они не могут получать и использовать ИТ-услуги так, как им хотелось бы. Может быть, даже кушать не могут и спят плохо=)
      Если серьёзно, то термин “проблема” воспринимается теми, кто впервые знакомится с ITSM хуже всех остальных . Вот.
      Поэтому, мне кажется, чтобы не отвечать на вопрос “это проблема, а это изменение”, можно предложить автору вопроса просто ввести первичную классификацию: запросы на работы с ПК, запросы на работы с ПО и проч. и для них уже предлагать различные целевые сроки. Нет?
      PS: Кстати, про сроки обработки именно корневых причин сбоев (aka проблем) 10го ноября всем расскажет Роман: http://www.cleverics.ru/ru/subject-field/webinars
      UPD: робот заблокировал глагол “потребить”, в его несовершенной форме;)
      UPD: поэтому указанный глагол был заменён на “получать и использовать”.

      • Анатолий Павлюченко

        А может “в консерватории подправить”? (с) М. Жванецкий
        Нет, серьёзно. Я бы начал с поиска общего языка и зафиксировал бы терминологию. Это сильно помогло бы с разъяснениями происходящих процессов и установке “целевых сроков”. Иначе и этот термин останется не до конца понятым. Нет? 🙂

        • Константин Нарыжный

          Ну вот Максим ниже справился без этих опасных слов =)

          • Анатолий Павлюченко

            Ага, а как же “регламентный срок”, “запускаем таймер после получения фичи” или “считать от поступления обращения до подтверждения выполнения”? 🙂
            Я тоже ЗА простоту и понятность. Но ПРОТИВ называния вещей не своими именами. Это не просто бомба замедленного действия, а, скорее, антиматерия для мира RealITSM!

  • Максим

    “Данный показатель необходим для мотивации персонала ИТ службы”
    А какова цель мотивации персонала?

    Варианты, которые вижу я:

    1. Максимально быстрое исполнение любых обращений, касающихся ИТ. Тогда во всех 4х примерах время решения будет от момента поступления заявки в поддержку до момента, когда заявитель подтвердил выполнение заявки. При расчете личных показателей сотрудника можем учитывать, что у него нет инструментов, чтоб ускорить решение некоторых заявок (например, номер 4) и считать, что эти заявки выполнены в регламентный срок, а можно наоборот, считать что сотрудник ИТ-должен общаться с смежниками (контрагенты, бухгалтерия и т. д.) и пытаться форсировать решение задачи (пример 2). В данном случае выбор зависит от корпоративной культуры организации.

    2. Максимально быстро делать “свою работу”. Тогда в первом примере считаем время от поступления заявки до передачи программисту, дальше вешаем на холд и останавливаем таймер, снова запускаем таймер после получения фичи и останавливаем после подтверждения выполнения со стороны пользователя.
    Во втором – аналогично первому.
    В третьем меня смущает формулировка. Скорее всего пользователь хотел не чтоб ему переставили Office, а чтоб у него заработала конкретная опция. Даже если он изложил пожелание не совсем корректно, все равно время надо считать от поступления обращения до подтверждения выполнения.
    В четвертом – аналогично первому.

    Если цель мотивации какая-то другая – с удовольствием обсужу методы учета время.

    Честно попытался избежать cлов “инцидент”, “проблема”, “изменение” и др;-)

  • Александр Жилинский

    К сожалению, вопрос поставлен некорректно, и корректного ответа для него не будет.

    • Олег Скрынник

      Ну ладно, ладно уж…

      Давайте заменим слово “инцидент” на слово “заявка” – станет вопрос более корректным?

      Автор вопроса привёл несколько примеров жизненных ситуаций разных (почти) обращений граждан в ИТ. Можем ли мы структурировать эти ситуации и предложить для них варианты ответа? Думаю, что да. Максим вот попытался, и неплохо получилось 🙂

      • Александр Жилинский

        Олег, я давно последний раз спорил о терминах? ) Попробуй меня найти в очередной эпохальной ветке о сервисе.

        Конечно же, я не об этом – а о формулировке вопроса. Контекст вопроса подразумевает уже разработанную систему мотивации персонала (именно персонала) в которой некое “время решения” определяющий параметр. И весь вопрос – просто как считать это время: целиком? всеми кусочкам? частью кусочков? Любой ответ будет только ответом на поставленный вопрос. То есть вопрос “скажите, мне для отпирания двери использовать зеленый шарик? или красный? или два синих надувных?”

        А по-моему, во-первых смотри во-первых эксперимент Деминга с шарами (время решения – результаты системы, а не человека), во-вторых любую литературу tqm-toc-lean для верной постановки вопроса – в данном случае лучше всего toc, которая позволит быстро определить, где здесь ограничение.

        ps и конечно – мерять “только нашу работу” в любом случае наихудший вариант.

        • Вадим

          тут также важно и то “за что платит клиент?”
          возможно у описанной компании нет такой отдельной услуги как техподдержка, и она включена в доработку ПО и прочие изменения конфигурации. возможно тогда клиент платит именно за доработку, тогда я бы максимально отделил время разрешения инцидента (тем самым минимизировав объем “бесплатной услуги”), заканчивающегося максимум формированием плана доработки (или определением состава необходимой закупки), и непосредственное выполнение работ по доработке ли, приобретению ли, переустановке ли …

    • Вадим

      неее, неправильно… не “корректного”, а “ожидаемого”

  • Дмитрий Исайченко

    Мне кажется, здесь принципиален вопрос потока. 100 обращений в месяц это порядка 5 обращений в день. На таких объёмах любые средние времена буду слишком сильно гулять для надёжной оценки. Нужен другой механизм. Какой – зависит от ответа на вопрос “Зачем?”, справедливо поднятый Сашей Жилинским.

  • Максим Люзин

    Без полноценного диалога с заказчиком сложно выдать действительно ценные рекомендации.
    Больше всего это похоже на вопрос – а чему у вас обычно равен {X}? Прежде чем определить что и как считаем может определимся с задачей?
    “Данный показатель необходим для мотивации персонала ИТ службы”
    Так мы хотим улучшить схему мотивации сотрудников?
    А быть может цель – увеличение уровня удовлетворенности пользователя?
    Так уж устроено, что для получения точного ответа необходимо задать корректный вопрос. Если нет возможности привлечь автора к обсуждению, то хорошим вариантом ответа будет – 42.

  • Автор-Владимир

    Спасибо, все очень хорошо пошутили)
    Отвечаю на вопрос “зачем” для увеличения уровня удовлетворенности пользователей через улучшенную схему мотивации персонала. Как критерий предлагается использовать показатель “время решения инцидента” (хорошо, запроса).
    На данный момент действует предложенный Максимом второй вариант, т.е. заморозка запроса на время закупки, либо разработки.

    • Дмитрий Исайченко

      “Отвечаю на вопрос «зачем» для увеличения уровня удовлетворенности пользователей через улучшенную схему мотивации персонала.”

      Мне кажется это разные задачи. Уровень удовлетворённости пользователей я бы не стал измерять по своевременности решения инцидентов / запросов. во-первых, как я уже говорил, у Вас очень маленький поток, во-вторых всегда возникает вопрос норматива и его соответствия ожиданиям. Лучше непосредственно спросить пользователей. Механизма 2: при закрытии запроса (пользователь ставит 1-2 оценки) и регулярный опрос.

      “Спасибо, все очень хорошо пошутили”

      Я не шутил. Я серьёзно ответил.

    • Вадим

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

      P.S. IMHO для избежания ситуаций номер 3 я бы еще посоветовал поработать по направлению управления конфигурацией, документировать, например, стандартные конфигурации компьютеров и ПО и отработать ситуацию, когда можно и когда нельзя что-то ставить на комп.

    • Александр Жилинский

      Владимир, как я уже говорил – мерять «только нашу работу» (т.е. заморозим, пока работают другие) в любом случае наихудший вариант

      • Дмитрий Исайченко

        Саша, а почему так категорично? Мне кажется, является ли такой подход к измерению наихудшим зависит от двух факторов:
        1. Как определена услуга (если определена)?
        2. Зачем проводится измерение – для внутреннего контроля или для оценки удовлетворённости заказчика (пока у автора эти две темы в вопросе мне кажутся смешанными – удовлетворённость через внутренний контроль)?

        • Николай

          Присоединяюсь – “мерять только свою работу” плохо всегда, так как это убивает accountability за результат и мотивацию на него.

        • Александр Жилинский

          Можно обсудить как-нибудь отдельно, тема долгая, а я уже пережевал все много раз – почти целая глава в будущей книге посвящена именно этому (сделай уже узкую секцию по решению сложных вопросов IncM? 🙂

          Но ниже вот Николай верно намекает на результат.

          • Дмитрий Исайченко

            Намекает Николай хорошо. Только жаль, что на вопрос не отвечает 😉 Жизнь, однако, на мой взгляд немного сложнее. Декларативное измерение времени от регистрации до решения (не зависимо от …) тоже убивает accountability, поскольку будет прилично случаев нарушения сроков без вины поставщика. Значит или отсутствие наказания (не взирая на измерения), или наказание в том числе за то, на что я не влияю. Результат похож – демотивация.
            Например, телеком-провайдер. Должны устранить нарушение связи в течение N часов, но требуется доступ к оборудованию на территории клиента. Пока клиент доступ не предоставит работать нельзя (о чём конечно сказано в договоре об оказании услуг). Другой пример – запрос на предоставление доступа к информационной системе (ИС). Первый шаг обработки – согласование с владельцами ИС (бизнес-представители), нарушение сроков согласования весьма вероятно. И таких примеров масса. Если за такие случаи наказывать исполнителей, accountability не прибавится.
            Поэтому я и удивляюсь – что позволяет делать столь общее утверждение: “заморозим, пока работают другие … в любом случае наихудший вариант”?

          • Георгий

            Offtop: ты пишешь книгу?

    • Pavel Solopov

      Не знаю, актуальна ли вам ещё тема.
      Коллеги тут всё вокруг, да около. Спрошу у вас напрямую: вы хотели бы мотивировать сотрудников СТП проталкивать задачи в бухгалтерии, в поддержке вендоров, в группе программистов?

      Какая доля случаев 1,2 и 4 от общего числа? Может просто их исключать из общего расчёта, и не усложнять схему?

      P.S. 3 человека на 100 запросов в месяц многова-то получается (если конечно они только поддержкой занимаются).

  • Георгий

    Что то крайне фееричное тут описано и рассказано… Хочу порадовать коллег своей маленькой ложкой дегтя
    Нам предлагают не спорить о терминах и задают вопрос как посчитать время решения инцидента. При этом речь идет об обращении пользвоателя (да бог с этим), временных затратах специалистов поддержки и попытке оценить их “вклад в решение”, чтобы от этого строить систему мотивации/демотивации, ну и вдовесок это еще вопрос о возможных классификациях обращения
    Ну ловко, ничего не скажешь, очень ловко 🙂
    1. Отчечая на главный вопрос – время решения обращения – с момента его поступления до момента подтверждения пользователем закрытия записи об обращении. Не больше и не меньше
    2. Отвечая на вопросы о временных затратах – можно обратиться с статье с этого сайта, уже этот вопрос рассматривался, там есть с моей точки зрения здравые жизненные варианты
    3. Про вопрос мотивации – ответа нет, тк я не понял цели вашей. Как только вы определите какая в реальности у вас бизнес-цель, можете начинать мотивировать народ на ее достижение
    4. Про вопрос классификации обращений – ну я вот навскидку не вспомню, но почти наверняка на этом сайте тоже что-то такое было 🙂 сейчас меня дополнят наверное владельцы статей 🙂

    а вообще – такие вопросы задавать нечестно 🙂 название одно а вопроса 4 🙂

  • Максим

    Коллеги, простите, не удержался;-)

    bash.org.ru:

    xxx: Словно умудренные жизненным опытом стервятники в пустыне, они смотрят вслед проползающим путникам. На вопрос, где можно напиться, они долго обсуждают, нужна ли тебе вода и неизменно приходят к выводу, что нет, тебе, брат, вода ни к чему. Неспешно перечисляют причины, по которым тебе лучше жить без воды. И ни один из них не покажет в какой стороне колодец.

    xxx: Е**** ИТ-форумы.

    • Вадим

      по-моему, картина обратная:
      человек спрашивает, где колодец. а ему отвечают: у тебя жажда – на! воды попей. а он – не нужна мне вода, мне колодец нужен, я там стрелку с друзьями забил…

      • Георгий

        колодец так колодец 🙂

        Мотивация персонала на время решения инцидента, в случае описанном выше, когда мы считаем все эти случаи инцидентами – не самое верное решение. Единой методы мотивации на все случаи по метрике время решения, имхо быть не должно 🙂
        ну или вам придется “забить на пользователя и его беды” и считать, что раз “наша” работа сделана, то и все хорошо

    • Георгий

      вода так вода.
      повторяю ответ – время решения инцидента во всех случаях – от открытия заявки пользователем, до его (пользователем) подтверждения ее закрытия
      🙂
      будем считать остальное моими домыслами о ситуации 🙂

  • Grigory Kornilov

    Мотивация … имхо важно, чтобы возложенные на сотрудника обязательства он смог выполнить качественно, вовремя и они были интересны.

    Направления для повышения мотивации
    1. надо ЗИП и менять из него диск, а не ждать недели бухгалтерию
    2. надо получить от программиста реальный и хорошо бы гарантированный срок доработки ПО по заявке

  • Слава Бельков

    Здравствуйте гуру (всем), осмелюсь задать вопрос дилетантский – причем, сразу прошу прощения, я не придираюсь, а просто хочу у гуру уточнить – пост называется “Посчитаем срок решения инцидента?”. Я всегда считал, что инцидент – это сбой в работе, и решается он двумя способами – или устраняется последствия и причина или устраняется тоже самое, но обходным маневром- причем время решения зависит от многих факторов и все это расписано в СЛА. Все это должно делаться быстро и считается легко – как говорили выше – от прихода заявки, до ее решения. Описанные варианты 1-4, по моему мнению, никакого отношения к инцидентам/сбоям не имеют и, соответственно, решаются – или “как договоришься с пользователем”, или как прописано в СЛА. Подскажите, плиз – в чем моя ошибка?

  • Денис Денисов

    Слава, осмелюсь Вам ответить :).
    Думаю, что нет никакой Вашей ошибки – просто взгляните на тему шире, а не только с позиции определения “инцидент”. Как, собственно, это предложил сделать Олег Скрынник в комментарии выше.

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

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

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM
Авторы и редакторы портала — консультанты и тренеры компании Cleverics.
Использование материалов данного сайта допускается исключительно с разрешения правообладателя.
Использование данного сайта означает согласие с обязательством соблюдать нашу Политику конфиденциальности и Согласие на обработку персональных данных.