Смартсорсинг.ру

Сообщество руководителей ИТ-компаний, ИТ-подразделений и сервисных центров

Статьи в блогах Вопросы и ответы Темы в лентах ITSM 365 Пользователи Компании Лента заказов Курс по ITSM

Время решения инцидента

Коллеги, требуется Ваше мнение по показателю: Время решения инцидента

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

Столкнулся с показателями, не понятно, что считать за время решения инцидента в некоторых ситуациях:

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

Комментарии (31)

  • Аватар

    Рубинштейн Кирилл [krubinshteyn], 24 октября 2011, 18:35

    2
    Владимир, добрый день!
    Время решения инцидента это всегда то, что вы сами определите в соответствии со здравым смыслом :) Вот пример дискуссии, где на этот счет немного похоливарили в комментах.

    Если говорить о перечисленных пунктах, то:
    1. Это не инцидент, а вполне себе запрос на изменение. Регламентное время решения у него может быть только в случае стандартных изменений, к чему доработки ПО не относятся. Единственное, что тут можно стандартизовать -- это некое подобие времени реакции: через какое время будет оценка сроков реализации требования.
    2. Это тоже не инцидент, а запрос на стандартное (?) изменение. Тут может быть определенный дедлайн. Но тат как в решении запроса участвует стороннее подразделение, то необходимо либо прописывать SLA для OLA (внутренние солгашения), что является фантастикой (потому как не просто внутреннее с ИТ, а внутреннее с бухгалтерией). Либо сделать нормативы на "выставление счета" и "сборку-установку купленного" по отдельности.
    3. Переустановка едва ли может быть вызвана самим пользователем. А если ИТ-служба такие запросы необдуманно решает, то это странно. Если переустановка требуется для решения реального инцидента (не запускается и т.д.) то тут вне зависимости от дальнейших последствий должен быть норматив. Если же это прихоть пользователя, то инцидентом тут не пахнет.
    4. В данном случае вендор вам выдает свое SLA. Вы, опираясь на него, с учетом возможных рисков, должны предлагать своим пользователям свой SLA. В труъ сервисной модели говорить о том, что зафейлены сроки из-за другого поставщика нельзя.
    Надеюсь, кто-нибудь ещё что-нибудь напишет.
  • Аватар

    Пешков Николай [peshkov], 24 октября 2011, 19:25

    0

    Владимир, добрый вечер!
    Внедряем ServiceDesk в своей организации с 400+ пользователями, учитывая рекомендации ITILv3. Линии ТП не используются, в связи с малым количеством пользователей и сотрудников СТП (3 человека на тех поддержке) - немного непонятна фраза про малое кол-во пользователей.
    А если по пунктам, то:
    вопрос 1: Это запрос на изменение, при чем время согласовывается с заказчиком

    вопрос 2: Для того, чтобы не простаивал счет в смежных подразделениях, необходимо иметь склад зап.частей (своевременно пополняя его запасы), а также иметь на складе несколько подменнных рабочих станций для "горячей замены".

    вопрос 3: А на каком основании пользователь решил, что ему нужно переустановить MS Office?
    Итог по 2 и 3 вопросам: разработайте у себя в компании корпоративный стандарт ит-обрудования, который будет гарантировать уверенную работу со всеми приложениями и не будет сподвигать пользователей на переустановку приложений и изменение конфигурации компов. И необходимо иметь склад.

    вопрос 4: если ситуация аналогична вопросу 2, то ответ такой же. Если это функционал ПО, то это запрос на изменение - время согласовывается с заказчиком.

    • Аватар

      Владимир Владимир [vvsmart], 24 октября 2011, 21:51

      0
      ...малым количеством активных пользователей. Проблем много, но просвещение о пользе обращений в СТП идет медленно, поэтому регистрируются запросы только тогда, когда все совсем плохо
  • Аватар

    Юсов Алексей [alexus], 24 октября 2011, 20:37

    0
    Однозначно 1, 2 и 4 - запросы на изменения. А это уже процесс управления изменениями. Изменения могут быть стандартными и нет. Для стандартных изменений можно установить плановый срок исполнения.
    Пункт 3 не очень понятен. Но скорее всего тянет на инцидент. И не разделяю категоричность коллег, что, мол, не должен пользователь такие запросы делать. Может от чистого сердца он, чтобы сервисдеск не мучался, все продиагностировал и и выдал вот такое. Но тут никаких проблем со временем решения не вижу. От момента запроса - до победного конца.
  • Аватар

    Перерва Станислав [paranoya], 24 октября 2011, 20:59

    0
    Запрос на переустановку офиса от пользователя нарушает всё, о чем говорится в книжках. Пользователь должен объяснить, что у него не так работает. А решение о переустановке принимается в службе поддержке на основе очень многих факторов и процессов.
    Если же обратиться к названию темы, то время решения инцидента - есть синоним сферического коня в вакууме. Потому как, инцидент должен быть предварительно проверен и отнесен к определенной группе. После этого смотрится на группу и по ее рисковости назначается максимальный срок решения конкретного инцидента. При этом, стоит принять во внимание тот факт, что фиксированное время решения инцидента можно назначать только тогда, когда исключены 99% всех возможных рисков. Как пример, было высказано ранее, замена комплектующих должно нести за собой шлейф из регламентов стандартизации оборудования для рабочих станций и наличия их на локальном складе .
  • Аватар

    Владимир Владимир [vvsmart], 24 октября 2011, 21:47

    0
    Спасибо за комментарии.
    Ок, согласен-есть запросы на изменения.Тогда следующая декомпозиция:
    Вышел из строя ПК, выдали временно резервный ПК. Когда в этом случае будет закрыт инцидент-когда восстановили бизнес-функцию, т.е. предоставили резервный ПК, либо когда восстановили выведенный из строя ПК? Отсюда и разное время решения инцидента, так что не сферический конь в вакууме, а 2 разных значения показателя. Если принимаем первый вариант, то по отчету имеем эффективного специалиста СТП, а на самом деле выведенный из строя ПК может лежать на ремонте длительное время.
    • Аватар

      Перерва Станислав [paranoya], 24 октября 2011, 22:36

      0
      Если резервный ПК имеет все те же функции, что и сломанный, то инцидент является закрытым и в CMDB соответственно прописываются все действия по замене и компьютер не выдается временно, смысл временного, если он такой же? Если же резервный ПК слаб по характеристикам, к примеру для монтажа видео, то это является workaround, функциональность восстановлена не полностью и инцидент не закрыт. Но! Это все зависит от того, как это надо фирме, замена на более слабый может считаться закрытым инцидентом. Потому как, Итил не есть свод обязательных правил, а есть рекомендации, которые можно подстраивать под себя, сохраняя общее.
      Если же на фирме счет на комплектующие может пролежать два месяца, то время закрытия инцидента - 2 месяца, плюс время оплаты и прихода денег поставщику, плюс время привоза деталей на склад и оформление по бухгалтерии, плюс забирание со склада и установка в сломанный ПК, плюс установка отремонтированного ПК на рабочем месте пользователя после тестового прогона.
      • Аватар

        Владимир Владимир [vvsmart], 25 октября 2011, 08:25

        0
         то время закрытия инцидента - 2 месяца
        Это не совсем так, по Вашей логике получается из-за недальновидности служб снабжения, ИТ-руководителя - виноват ИТ-специалист, к которому попал данный инцидент.
        Свод рекомендаций-это понятно, но разбирается конкретный случай: как оценить эффективность ИТ-специалиста в приведенных примерах. Какими метриками, инструментами?
        • Аватар

          Перерва Станислав [paranoya], 25 октября 2011, 12:01

          0
          Всё, что непосредственно влияет на данную метрику, и не зависит от действий сотрудника, говорит о том, что метрика, либо неправильна, либо не доработана.
          • Аватар

            Владимир Владимир [vvsmart], 25 октября 2011, 12:19

            0
            Так для этого и создана тема. Каким должен быть этот показатель?
            • Аватар

              Перерва Станислав [paranoya], 25 октября 2011, 13:58

              0
              Показатель время решения инцидента вообще или с привязкой к сотруднику СП?
              Время решения инцидента прописывается в SLA, если это время необходимо.
              Время решения инцидента сотрудником СП, об это я уже говорил, требует доработки классификации инцидентов и внесения дополнительных атрибутов: сложность инцидентов.
    • Аватар

      Забелин Максим Анатольевич [stecker], 25 октября 2011, 01:32

      0
      Тут у вас два разных события:
      - недоступность сервиса aka неработающий компьютер у пользователя;
      - ремонт техники.
      Соответственно, это два разных инцидента. И их генерируют разные позиции. И сроки решения инцидентов могут быть разные. Ведь ремонтом может заниматься и внешняя структура например.

      • Аватар

        Красников Евгений [Krasnikov], 25 октября 2011, 06:38

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

          Красников Евгений [Krasnikov], 25 октября 2011, 06:51

          0
          Хотя, количество инцидентов в данном случае может быть и бОльшим, если у пользователя есть несколько сервисов в SLA, которые стали недоступны из-за неисправности компьютера, но все эти инциденты закрываются с предоставлением другого ПК. А время ремонта является метрикой другого процесса.
  • Аватар

    Перерва Станислав [paranoya], 25 октября 2011, 11:57

    0

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

    Тема обсуждения, в том понимании, которое автор хотел вложить недоработана изначально. Мерить эффективность работы сотрудника СП, временем решения инцидента не очень хорошая мысль. Эффективность сотрудника СП измеряется в количестве назначенных ему инцидентов и количестве закрытых инцидентов из назначеных ему за определенный период, к примеру, месяц. В дальнейшем, развитие этого kpi, должно привести к тому, что, инциденты должны поделиться, к примеру, на такие:

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

    На счет же замены ПК, то тут, кроме инцидента открытого пользователем (стоит не забывать, что пользователь должен описать возникшую у него проблему, а не говорить что делать СП). Мы получаем:
    • Запрос на изменение от СП в change management, после установления факта о том, что нжна замена ПК.
    • Решение группы по управлению изменениями о замене, которое основывается на управлении доступностью (наличия комплектующих или резервного ПК), управлении мощностью (при необходимости установить мощный ПК для видеообработки), если используется.
    • Соответствующие изменения в CMDB (резерв начал использоваться, старый ПК стал нерабочим)
    • После чего в управление финансами передается заявка на приобретение нового резерва, либо компектующих.
    • И далее очень много других регламентированных действий.
    Дерево подчинения всех запросов и заявок будет выглядеть красиво и все только благодаря тому, что у пользователя "при запуске видеоредактора компьютер перезагружается".
  • Аватар

    Владимир Владимир [vvsmart], 25 октября 2011, 12:32

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

    Т.е. в данном случае можем оценить как отработал сотрудник СТП с запросом пользователя. Также можем оценить время, затраченное на ожидание проплаты по всем инцидентам или время на ремонт.
    • Аватар

      Peshkov Alexander [PA], 25 октября 2011, 12:51

      0

      Мои пять копеек. Безусловно, это запросы на изменение и принебрегать этим в контексте вопросов совершенно невозможно. Что считает там по этому поводу пользователь - никакого значения не имеет.
      Для инцидента можно определить время решения инцидента (в соответствии с пакетами уровней сервиса) для конкретного подразделения, для конкретного сервиса, для конкретных периодов времени.
      Для запроса на изменение время исполнения определяется в проектном решении для этого изменения. Этот срок можно назвать пользователю, но будет всегда индивидуальным - для каждого изменения.

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

    • Аватар

      Красников Евгений [Krasnikov], 25 октября 2011, 13:02

      0
      По-моему, надо добиваться того, чтобы пользователь понимал разницу между инцидентом и изменением. Т.к. инцидент ИТ-служба обязана закрыть за оговоренное время, а изменение всё-таки по другой процедуре выполняется (оценка необходимости, ресурсов и т.д.).
      Теперь насчёт заморозки. По-моему, замораживать инцидент можно только, если пользователь не даёт возможности его закрыть (например, ушёл в отпуск, кабинет закрыл, доступа к компьютеру нет), внутренние заморочки ИТ-службы не могут быть основанием для заморозки.
      • Аватар

        Перерва Станислав [paranoya], 25 октября 2011, 13:48

        0
        Добиваться того, чтобы пользователь знал разницу между инцидентом и изменением - дорого и неоправдано. Самый простой способ - от пользователя поступают заявки/тикеты, а классификация заявки идет на уровне сотрудника, которому её назначили. После чего заводят две метрики для сотрудника СП:
        • Количество запросов изначально правильно классфицированных
        • Количество запросов изначально неправильно классифицированных
        Изменение инцидентов за фиксированное время, требует от ИТ департамента так организованой ИТ инфраструктуры, чтобы можно было соблюдать фиксированое время решения инцидента. То есть, любой писк в системном блоке устраняется до того, как он возникнет. И на каждое оборудование имется резерв или оплачиваемая поставщику поддержка с гарантированной доставкой вне зависимости от форс-мажорных транспортных ситуаций.
        • Аватар

          Красников Евгений [Krasnikov], 25 октября 2011, 14:32

          0
          Не понял, что значит "изменение инцидентов".
          А добиваться того, чтобы пользователь знал разницу между инцидентом и изменением необходимо. И не должно быть дорого, и будет очень оправдано.
          Инциденты закрываются за оговоренное и согласованное время
          Типовые изменения реализуются за оговоренное и согласованное время.
          Все остальные изменения требуют рассмотрения и принятия решения. Если же пользователь не будет понимать разницы между инцидентом и изменением, то у него будут неоправданные ожидания от ИТ, а это ни к чему хорошему не приведёт.
          • Аватар

            Владимир Владимир [vvsmart], 25 октября 2011, 14:58

            0
            Во главе угла-ориентация на пользователя, следовательно не должен разбираться пользователь в ИТ-терминах. Простой пример: когда Вы звоните сантехнику, Вы ему говорите, что течет кран и Вас не интересует, что он будет делать: менять прокладку (инцидент), либо менять трубопроводы по всему стояку (изменение)
            • Аватар

              Красников Евгений [Krasnikov], 25 октября 2011, 15:38

              0
              Ни в коем случае не возражаю против ориентации на пользователя.
              Давайте в терминах про сантехника.
              Если у меня кран стал течь, я звоню сантехнику. В договоре записано, что этот инцидент он обязан устранить за один день. И мне как пользователю неинтересно сколько и каких изменений он произведёт. Я знаю срок - один день, потому что сантехник на этот срок подписался.
              Теперь другая ситуация. Я вдруг захотел, чтобы у меня смеситель был не с барашками, а с педалью. Начинается моё общение с сантехником, идёт обсуждение, чьи материалы, когда у него будет время его установить, сколько это будет стоить, и надо ли вообще это делать. Я, как пользователь, знаю, что это не инцидент, а запрос на изменение и сроки мы должны согласовать вместе с исполнителем.
              • Аватар

                Перерва Станислав [paranoya], 25 октября 2011, 15:51

                1
                Итишники не люди. Поэтому знают разницу между инцидентом и изменением. :)
                Пример с сантехником прост, в ИТ не всегда специалист СП с первого раза сможет определить изменение это или инцидент, а пользователь и подавно. В терминах пользователя сантехники мы оставляем заявку и не важно на устранение течи или замену смесителя на красивый со стразами. Как только заявка поступила сантехнику, он смотрит и видит что замена смесителя на красивый - это изменение, поэтому сроки одни, а устранение течи - сроки другие и решать надо быстро. Но пользователь может, и скорее всего именно так и сделает, напишет что хочет новый смеситель потому, что у старого есть течь, но про течь ничего не напишет в заявке.
                К тому же эта заявка, сначала может быть со статусом "инцидент", а после расследования оказаться "запросом на изменение" или наоборот.
              • Аватар

                Владимир Владимир [vvsmart], 25 октября 2011, 16:47

                0
                а если так:
                я говорю сантехнику-у меня кран течет, а сантехник у себя посмотрел в "базе смесителей" и оказалось, что смеситель у меня уже 20 раз чинился, да и вообще его ставили во времена прадеда. И сантехник говорит, что предстоит изменение, но мне то не важно, мне главное чтобы вода из крана текла.
                )
                • Аватар

                  Перерва Станислав [paranoya], 25 октября 2011, 19:19

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

                  Красников Евгений [Krasnikov], 26 октября 2011, 06:33

                  0
                  Процессу "управление инцидентами" неважно, сколько раз чинился смеситель и когда он был установлен - надо срочно устранять течь.
                  А затем должен подключиться процесс "управление проблемами", увидеть что имеет место повторяющийся инцидент, определить причину, запланировать необходимые изменения для предотвращения, если он не отработает, то завтра опять потечёт ...
          • Аватар

            Перерва Станислав [paranoya], 25 октября 2011, 16:03

            0
            Моя ошибка, :( вместо "изменения инцидентов", следует читать "время решения инцидентов".
            По мере работы со службой поддержки, пользователь самостоятельно научиться понимать разницу между инцидентом и изменением. Но как только вы их начнете учить этому, то количество обращений пользователей в СП увеличиться в несколько раз за счет того, что они будут звонить и спрашивать: - принтер не печатает потому, что закончился тонер, это инцидент или изменение? И эти запросы надо будет так же фиксировать. Причем, заявку он офромляет через веб, а звонит потому, что неумеет оформить две зявки, одну на инцидент/измение, другую на запрос. И тут мы приходим к тому, что пользователю нужно будет объяснять что есть еще "запросы на получение информации", что в конце концов его запутает настолько, что он плюнет на все и будет все заявки через веб оформлять запросом или инцидентом.
            Кроме этого, пользователи могут звонить по телефону и тогда бремя определения типа заявки ложится на плечи сотрудника СП, потому как сотрудник будет вносить её в базу СП. И тут как-то не посрашиваешь у пользователя какой тип заявки он хочет установить, тут задаванием наводящих вопросов сам сотрудник СП присваевает заявке определенный тип.
  • Аватар

    Юсов Алексей [alexus], 26 октября 2011, 00:24

    0
    Уважаемые коллеги! Предлагаю все-таки определиться, о чем идет речь. Мне кажется, что об инцидентах спрашивает Владимир. Мое мнение пока не изменилось. Пп. 1,2 и 4 - это запросы на изменения, и к теме относится не могут. Их надо измерять по-другому.
    По пункту 3. Допустим пользователь неверно классифицировал тип запроса, т.е. поставил на "Инцидент", а "Запрос на изменение". Это ничего не меняет. Надо в любом случае связываться с юзером и уточнять у него, на каком основании он запрашивает что-либо. Если выясняется, что ПК глючит и его надо менять, то надо RFC закрывать, и открывать новый инцидент (юзера при этом слегка профилактировать, т.е. обучать его разнице Inc-RFC). И вот с этого момента считать время решения инцидента.
    Допустим юзеру поставили слабый, но рабочий ПК. Тогда Инцидент закрывается обходным решением. И создается RFC закупку/поставку со склада/сборку из остатков нового компа, который удовлетворяет корпоративным стандартам для данной группы пользователей.
    Если нет нового компа и заменить его нечем, то инцидент закрывается сотрудником СТП "неуспешно". А потом уже будут разборы, почему закрыто было "неуспешно".
    Что касается заморозки по задержке пользователя, то лучше закрывать по сроку давности при условии, что мяч остался на стороне клиента, конечно же. Само собой, это надо предусмотреть в регламенте, чтобы потом не было наездов на ИТ. Т.е. наезды, конечно, будут, но так можно будет от них отбиться. Хотя при высоком уровне зрелости ИТ и пользователей наездов не будет, т.к. редко кто хочет быть в беспомощном состоянии "сам дурак".
  • Аватар

    Федулов Кирилл [kfedulov], 26 октября 2011, 01:07

    1
    Владимир, добрый день!

    Не читал всю переписку, потому заранее приношу извинения, если повторюсь. Сразу оговорюсь, что "так правильно" - нет и это "правильно" зависит от многих факторов, которые к ITIL уж точно далеко не всегда имеют отношение. Заранее прошу прощения за много букв :)

     Итак, по порядку:
    1. В первую очередь у Вас должны быть описаны спецификации услуг (или каталог услуг, состоящий из спецификаций), которые определяют множество факторов предоставления услуги, в том числе ее характеристики, описание "базовой" функциональности и т.д. Они должны быть согласованы с бизнесом. Помимо этого для каждой услуги могут быть (точнее должны быть) описаны специфичные запросы на обслуживание (ЗНО). Если запрос "фичи" является ЗНО с точки зрения описания услуги, то его так и следует классифицировать. Для ЗНО описываются регламентные времена решений. Если это изначально запрос на изменение (ЗНИ), то вероятно, сроков здесь быть не может и это в упрощенной модели можно также описывать в спецификации услуг. Если же получаем, что изначально классифицированный как ЗНО оказался в реальности ЗНИ, то вариантов 2 (они, правда, тоже должны быть описаны в спецификации услуги для прозрачности оба или один конкретный варинт): 1. закрывать ЗНО и регистрировать связанный ЗНИ без указания четкого времени 2. В рамках ЗНО иметь состояние, в котором регламентное не "тикает" в связи с необходимостью привлечения разработчика, о чем в любом случае уведомить пользователя
    2. В идеале у Вас должна быть так называемая DML (definitive media library) в которой прописаны базовые конфигурации пользователей (пояснения для чего она нужна найдете в ITIL). Если запрос выходит за рамки DML, то его по этой же причине необходимо отклонять. Если же это в рамках DML или у Вас ее нет и опять же в спецификации услуги (например, поддержка рабочих мест) прописаны параметры замены и времена, то тогда у Вас должен быть склад (иначе в рамках процесса управления непрерывностью и теми же инцидентами/запросами на обслуживание, вы не сможете соблюдать согласованные времена решения). Если и его нет, пропишите в спецификации, что время на закупку не учитывается, сделайте такое состояние и опять же, при переводе в него - уведомьте пользователя. Главное фидбек + прозрачность.
    3. Это что-то совсем странное. Вот так, по желанию, просить переустанавливать ПО некорректно в принципе и такие запросы нужно "заворачивать" (опять же, если бы в спецификации услуги у Вас были прописаны всевозможные ЗНО, то вариантов что делать - не возникло бы). А если они есть - то для них должно быть прописано время решения, а коль время решения есть - ваши риски в том, что Вы их прописали, не детализируя вариант связанный с переустановкой ОС. Тем не менее, раз мы живем не в идеальном мире (поэтому про ту же DML и стандарты рабочих мест я повторяться не буду), в такой ситуации я бы считал все время. С точки зрения поддержки условного сервиса "Поддержка стандартного ПО на рабочих станциях" его работоспособность вы восстановили только после замены комплектующих и точка. При этом в рамках инцидента вполне разумно было самостоятельно создавать связанные ЗНО или ЗНИ (опять таки, смотря какие процессы есть, что описано и т.д.) и по ним отдельно считать времена, планируя тем самым аналогичные ситуации в будущем с точки зрения отчетности.
    4. Ну это типичная связка SLA-UC (упуская OLA). В идеальном ITIL мире времена решения инцидентов, связанных с бизнес сервисами (это прописано в SLA) не должны быть меньше времен прописанных в UC (поддерживающем контракте, заключенным между Вашей компанией и вендором). Реальность в таких случаях на мой взгляд, достаточно опять же описанием в спецификации услуги пункта "Дополнительные условия", в котором достаточно условной строки "Описанные времена решения запросов/инцидентов/чего угодно не учитывают время, связанное с задействованием внешнего поставщика/подрядчика". И еще раз напомню, что даже если у Вас есть такие вот "неучитываемые" состояния - уведомляйте о переводе в них пользователя, а согласованная спецификация будет являться весомым аргументом, если начнутся споры :)

    Еще раз простите за объем! Надеюсь, хотя бы что-то из написанного будет полезно :)
  • Аватар

    Яковлев Андрей Михайлович [swtws], 30 октября 2011, 17:36

    0

    Для достижения поставленной цели ответьте на следующие вопросы:

    1.  Применяются ли KPI в самой компании?
    2. По Вашему достаточно ли численности и компетенций персонала для перекрытия сервисов?
    3. Вы уверены, что опустив термометр в воду Вы узнаете температуру воды?

    Если ответы нет, нет и уверен, не мучайтесь. Персонал должен премироваться по доступности системы - все хорошо премия, плохо - будем разбираться. Изменения прошли - хорошо, нет, кто был против?
    Кстати правильный ответ на третий вопрос - "не уверен", подобно тому, как Вы узнаете температуру термометра, а не воды, так и KPI даст Вам то, что хотят показать сотрудники СТП. На фоне низкого оргуровня и недостатка людей  и навыков KPI просто иностранное слово. Держитесь принципа Keep It Simple  Stupid и люди к Вам потянутся.